经典负载平衡器的实际操作演示。
文 | 沉默恶魔(禁止转载,可转发)
关注公众号:AWS爱好者网站:www.iloveaws.cn如果您觉得本公众号内容尚可,可能的话希望您能关注此公众号,或转发您有兴趣的内容,让更多的人看到,这也是目前我能坚持此公众号的唯一动力,谢谢支持,鞠躬!
Hello大家好,欢迎来到《AWS解决方案架构师认证 Professional(SAP)中文视频培训课程》,今天的课程内容为Classic Load Balancer。
我们开始今天的课程内容。
Classic Load Balancer是AWS的上一代负载均衡器,支持实例位于VPC网络和实例位于EC2-Classic网络。
Classic Load Balancer支持TCP、SSL/TLS、HTTP、HTTPS协议,是AWS的三种负载均衡器支持协议最多的。
Classic Load Balancer支持负载均衡器的一些基本功能。但也有很多必要的功能Classic Load Balancer是不支持的,如果您的业务需要这些新的功能和特性,需要使用新一代的负载均衡器,也就是网络负载均衡器和应用程序负载均衡器。
实操演示:配置EC2实例NGINX
接下来的内容我将演示通过 AWS 管理控制台(基于 Web 的界面)创建 Classic Load Balancer 的实际操作。我们将创建一个Classic Load Balancer,然后让Classic Load Balancer接收公网 HTTP 流量并将其发送到 EC2 实例。
完成这个测试需要启动两台EC2实例,并将两台实例安装配置NGINX,然后创建一个Classic Load Balancer,最后通过浏览器访问Classic Load Balancer的地址让其接收公网的 HTTP 流量并将其发送到 这两台EC2 实例。
先看下我目前已准备好的测试环境,我已经启动了两个EC2实例,CLBTEST1和CLBTEST2。为了节省时间,CLBTEST1实例我已经配置好了,实例上已经安装了NGINX,并修改了默认的INDEX文件,让浏览器访问这个实例页面显示为SERVER 1。
我们现在来测试下,复制CLBTEST1的公有IP地址,然后通过浏览器访问这个IP。可以看到页面显示Welcome to Server 1,为CLBTEST1实例的INDEX页面。
为了能让大家跟着一起做,我使用同样的方式配置CLBTEST2实例,让其页面显示Welcome to Server 2。请大家按照此方式配置好自己测试的两个实例。
第一步:SSH到CLBTEST2实例后,先运行命令添加NGINX的源,为了节省时间我直接复制下命令,然后执行:
sudo rpm -Uvh http://nginx.org/packages/centos/7/noarch/RPMS/nginx-release-centos-7-0.el7.ngx.noarch.rpm
第二步:通过YUM安装NGINX,运行命令:
yum -y install nginx
第三步:修改默认INDEX文件,让其页面显示Welcome to Server 2。我们cd到INDEX文件目录,运行命令:
cd /usr/share/nginx/html
然后编辑index.html文件,运行命令:
vim index.html
将文件内容的welcome to xxxx修改为Welcome to Server 2,然后保存退出。
最后,运行命令:
systemctl start nginx
启动nginx。
这样CLBTEST2实例就配置完了,我们复制下公网IP,然后通过浏览器访问测试是否可显示nginx页面,可以看到“welcome to server 2”信息,配置没有问题。
到这里我们就配置好了两台实例的页面,访问第一台显示welcome to server 1,第二台显示welcome to server 2,分别对应两个实例。
这里需要注意一点,如果访问页面出现问题,请检查实例安全组的配置,为了测试方便,我已将两个实例的安全组的80端口对外开放。
实操演示:创建Classic Load Balancer
两台实例的测试环境已经准备好了,接下来我们将创建一个Classic Load Balancer,然后进行配置让Classic Load Balancer接收公网 HTTP 流量,并将其发送到我们准备的这两台 EC2 实例。
进入“负载均衡器”页面,然后点击“创建负载均衡器”,可以看到三种负载均衡器类型,这节课我们选择创建Classic Load Balancer。
负载均衡器名称,我们输入iloveawscn-clb。选择LB的VPC,注意这里要选择和之前创建的两个实例的相同VPC,我这里因为是测试环境,所以都在默认VPC里。
然后配置监听器,可以选择负载均衡器的协议,我们刚才配置的实例页面是HTTP的,端口是默认的80,所以在这里配置负载均衡器的协议为HTTP,实例协议同样为HTTP,端口号都为80。意思是负载均衡器收到公网的HTTP的80请求,发送到注册实例的80端口,使用HTTP协议。
接下来为负载均衡器选择安全组,我们选择创建一个新的安全组,安全组名称为clbtest-clb,然后确保80端口对外。
配置运行状况检查,PING协议,端口,和路径我们测试就保持默认,为了减少我们测试的等待时间,我们将运行状况检查的时间改为10秒,继续。
然后添加EC2实例,我们将之前创建的两个实例添加到此负载均衡器,然后继续直到完成负载均衡器的创建。
Classic Load Balancer已经创建完成了,点击下面的实例选项卡,看在实例状态列,如果这里显示部分实例未处于可用状态,则可能是因为实例仍在注册过程中,需要等一会,一般所需时间大概为1-2分钟。
另外需要注意一点,之前创建的两个实例的安全组需要允许Classic Load Balancer对其的访问,我的实例因为是测试之前已经开放了80端口对所有地址访问,所以不需要在另行配置,如果您在测试过程中遇到问题,请检查负载均衡器以及实例的安全组,是否开放了对应的策略。
好,目前我们注册的两个实例的状态都为“inService”了,切换到“描述”选项卡,DNS名称这里为刚创建的Classic Load Balancer的域名,我们复制一下:iloveawscn-clb-831592552.ap-northeast-1.elb.amazonaws.com ,然后切换到浏览器,访问下这个地址。
通过刷新,可以看到我们创建的Classic Load Balancer已经可以正常工作了,它在分发我们的请求,CLBTEST1和CLBTEST2实例的页面交替显示,通过访问Classic Load Balancer的地址,负载均衡器接收公网 HTTP 请求并将其发送到注册的 EC2 实例。
我们选择创建的Classic Load Balancer后,通过下面的选项卡,可以查看和编辑Classic Load Balancer的配置,Classic Load Balancer提供了基础的功能,包括运行状况检查,监听器,监控等。
我们选择迁移选项卡,可以看到AWS建议将创建的Classic Load Balancer迁移至应用程序负载均衡器。
如果您确信 应用程序负载均衡器 或 网络负载均衡器 满足您的需求,那么您就可以迁移 Classic Load Balancer。在迁移过程完成后,您就可以使用新一代负载均衡器的提供的功能了。
为什么AWS建议要迁移 Classic Load Balancer
那为什么AWS建议要迁移 Classic Load Balancer 呢?
首先,Classic Load Balancer不支持 本机 HTTP/2 协议,该协议只有应用程序负载均衡器支持。
无法支持注册IP 地址即目标。Classic Load Balancer只支持将EC2实例注册为负载均衡器的目标,而应用程序负载均衡器支持将 IP 地址注册目标,所以您也可以将位于负载均衡器的 VPC 之外的资源注册为目标,这样的话就能够使用同一负载均衡器在 AWS 资源和不同区域或您本地资源之间进行负载均衡。这个功能能够让我们轻松将本地应用程序迁移、应对业务突增或故障转移至云端,但是Classic Load Balancer不支持此功能。
Classic Load Balancer不支持服务器名称指示 (SNI)
第四点不支持基于路径的路由,比如将URL请求/images路由至server1,将URL请求/php路由至server2,Classic Load Balancer是不支持的。
另外Classic Load Balancer也不支持将负载 均衡到同一实例上的多个端口等等等,还有以上没有列出的很多的功能是 Classic Load Balancer不支持的。
所以如果您的业务需要以上功能,那么您就可以评估将其迁移至应用程序负载均衡器。
好的,以上就是我们今天的课程内容,今天我们介绍了 Classic Load Balancer,并实操演示了创建 Classic Load Balancer,并注册两个EC2,演示通过 Classic Load Balancer让负载均衡器接收公有 HTTP 流量并将其发送到 注册的EC2 实例。另外我们也介绍了使用 Classic Load Balancer功能的一些限制。
后面的课程我们会介绍应用程序负载均衡器,讨论应用程序均衡器提供的一些重要的功能和特性。
希望此系列教程能为您通过 AWS解决方案架构师认证 Professional 认证考试带来帮助,如您有任何疑问,请联系我们:
- AWS爱好者的网址是www.iloveaws.cn。
- 可以通过扫码加入【AWS爱好者】微信公众号,查看原创的AWS知识点相关文章
- 加入【AWS爱好者】微信群,和其他同学一起备考,以及探讨交流AWS相关知识
我们今天的视频课程就到这里,感谢大家的观看,我们下一课程再见。
上一篇: 网络负载平衡器(NLB)
推荐阅读
-
像首席技术官一样思考:如何高效管理 30 人的研发团队?-管理越多越轻松。好的研发团队,应该是上拨下用,即下级对上级的向上管理;而不是反过来,总是向下管理,甚至是 CTO 做经理的事,经理做工程师的事,工程师最终会被当成实习生。如果是这样,就会越管越累,不仅团队无法成长,而且团队整天很忙还效率低下,问题一大堆。 有这样一个小故事:一位高级经理下班后帮忙倒垃圾,结果被老板训斥了一顿。这就好比首席技术官做了实习生自己该做的事。事情本身没有对错之分,只是从不同的角度有不同的理解。 古人云:"用人不疑,疑人不用"。在面对自己的研发团队时,应该相信他们能做好,授权一线开发人员充分发挥专业特长,不要限制他们的工作。但在相信他们的同时,也要进行二次确认,始终秉持 "我相信,但我要确认 "的原则和严谨的精神。因为每个人都会犯错和疏忽,通过发挥团队的智慧,团队犯错的机会就会大大减少。比如回归测试、代码审查、开发演示、变更审批等等。 如前所述,每个人都难免会犯错。但作为管理者,你所设计和商定的流程不能出错。管理者的每一个决定和沟通都应该经过深思熟虑。就像红绿灯的交通设计,某辆车不小心闯红灯可能会扣分,但红绿灯的设计一定要正确、人性化、统一。再比如,开发人员可能会因为疏忽大意写出 bug,但研发流程的设计和上线流程的发布不能有任何差错。因此,流程体系的设计,一方面要结合当前团队规模、业务特点和需要重点解决的问题来设计,另一方面也要在人员防错、效率提升、发挥团队集体智慧等维度进行综合考量。应该站在更高更抽象的角度去思考,不断思考一个倍受欢迎的园区应该如何设计,思考一个灵动、经典、永恒的建筑应该遵循怎样的模式,思考一个成功、优秀、卓越的研发团队应该需要怎样的流程和制度。 最后,反馈很重要。向上汇报很重要,向下反馈也很重要。能够保持顺畅的双向反馈和闭环管理,对研发团队的协作和沟通有着非常明显的积极作用。在向上汇报方面,要培养团队在正式汇报、会议汇报、私下沟通、书面总结、非正式场合等方面的沟通能力,提醒下属报喜也要报忧。凡事先记录,再跟进,最后反馈。反馈很重要,主动汇报更难得。 另一方面,同时也不要忽视向下反馈。好的爱,是双向的。团队也是如此,没有严格的上下级之分,只是分工和角色不同而已。作为管理者,不必总保持一种 "神秘感",让人 "捉摸不透 "才是牛。当团队做得好或有人做得好时,要记得在公开或私下场合给予肯定和赞许。业务有增长、业绩有提升时,别忘了给团队一些鼓励,或者安排一次下午茶或聚餐。在例会或正式会议上,也可以同步向大家传达一些重要信息和高层指示。"欲速则不达,欲远则同行"。 当向上汇报、向下反馈的沟通闭环形成后,同时结合前面研发过程的管理闭环,双管齐下,就能形成良性循环。如此反复,持之以恒,优秀卓越的研发团队,必将呈现。 能力、产出和效率 接下来,继续重复关于能力、产出和效率的话题。 站在不同的角色,以及一个企业经营、生存和发展所需要的基础上,我把研发生产力分为三个层次,分别是:一线员工关心的研发能力、管理层关心的软件产出和操作人员关心的企业生产效率。简单概括就是:既要把工作做好,又要能出成果,还要能帮企业赚钱。
-
经典负载平衡器的实际操作演示。
-
深入解析VMware虚拟机vmnet2(NAT)网络,并进行两台虚拟机与一台主机的实际操作演示
-
【实际操作】从实际应用中学习游戏开发技巧:下载原神模型,将PMX格式转换为FBX格式,成功导入Unity,并进行卡通渲染以及人形动画的绑定(附带演示工程)