亚马逊AWS官方博客

新一代负载均衡器服务NLB概述

在去年9月份,AWS发布了托管的网络负载均衡器服务Network Load Balancer,NLB是继Classic Load Balancer,Application Load Balancer之后,AWS发布的第三款负载均衡器服务,本文将着重介绍NLB的工作原理,特点以及在使用配置上的注意事项,帮助读者更好地在自己的业务场景中运用NLB服务。

NLB能够在极低的延迟下,支持每秒数千万的请求,在API上兼容现有的ALB应用负载均衡器,下面是NLB的一些主要功能和特点:

  • 静态IP地址

每个NLB在每个可用区中提供单个静态IP地址,用户端发往该IP地址的流量会被负载分发到同可用区内的多个后端实例上,用户可以为NLB在每个可用区中分配固定的弹性IP,如此设计使得NLB能够被纳入企业现有的防火墙安全策略中,并且能够避免DNS缓存带来的问题。

  • 同可用区内分发流量

客户端的流量到达NLB在某个可用区提供的IP后,NLB会向相同可用区内的后端实例分发流量,通过避免跨可用区的流量分发能够获得更好的延迟性能。

  • 源地址保留

NLB在转发流量的同时,并不会修改数据包的源IP地址,后端实例无需支持诸如X-Forward-For,proxy协议,就能够直接从数据包的包头获取客户端的IP,从而很方便地分析客户端的地理位置等信息。

  • 长连接支持

NLB内置的容错机制能够保证长连接应用的稳定运行,从而更好的贴合诸如IoT,游戏,消息应用等业务场景。

  • 故障切换

利用Route 53的健康检查,NLB支持在一个区域内及跨区域和本地站点实现故障切换。

下面我们来看一下如何在AWS控制台创建NLB,可以看到,客户在创建负载均衡器页面中,目前可以有三种负载均衡器可选,我们选择NLB。

NLB和其他AWS提供的负载均衡器一样,支持创建面向internet及internal两种场景,除此之外,用户需要配置NLB监听的端口及所处的子网,如果创建面向internet的NLB,需要注意将NLB放到公有子网中。

考虑NLB本身的冗余,建议至少选择2个可用区,同时用户可以根据需要为NLB在每个可用区绑定弹性IP。

后续的配置与ALB的配置十分类似,用户需要配置目标组,目标组监听的协议、端口以及健康检查等相关配置,目前无论ALB还是NLB都支持将EC2实例及某个IP作为目标,前者实现VPC内部的负载均衡,后者通过IP可以为本地站点的实例提供负载均衡。

这里选择实例类型的目标类型,之后需要选择注册的实例。

需要注意的是,为了能够接受外部客户端的访问以及健康检查流量,建议后端实例的安全组做如下设置,如果用户觉得健康检查源地址设置VPC CIDR过于宽泛的话,建议可以设置为NLB的私有IP,NLB的私有IP可以在ENI界面通过NLB名字搜索到相关NLB的ENI来获取。

除了安全组设置上的考虑,对于面向internet的NLB来说,后端实例收到的流量的源IP地址是处于公网的客户端IP,对于接收internet流量的这部分后端实例,建议放到公有子网中,即默认路由指向IGW,如果用户不希望后端实例能够被外界直接访问,可以在将后端实例放入公有子网的同时,选择不分配公网IP,从而保证外界只能通过NLB来访问到后端实例。

选择完后端实例后,就可以完成NLB的创建。

NLB对外提供的是一个域名,客户端通过访问该域名将流量发给NLB,用户可以通过设置DNS CNAME记录来方便客户端通过自定义的域名来访问用户的后端系统。

以上介绍了面向internet的NLB的配置方法,对于面向internal的NLB,用户可以做类似的配置,这里不做过多的介绍,只是如果NLB后端对接的是容器业务,并且网络模式是bridge模式,需要做额外的考虑。

这里先给出结论再解释相关的原理,对于两个需要通过NLB互访的内部容器应用,建议将这两个应用的容器调度到不同的EC2节点上,对于AWS ECS,用户可以通过为两个应用创建不同的ECS Cluster或者在一个ECS Cluster内通过亲和性调度算法实现。

为什么需要做上述的设置呢?下面解释下如果将这两个应用调度到相同的ECS Cluster上会出现什么问题。

在上面这个场景中,App1和App2使用容器部署在EC2中,App1需要通过NLB来访问App2,如果网络模式使用bridge,App1的流量在发出所在EC2实例的时候,源IP地址会从App1的容器IP转换成EC2的IP,如果NLB通过负载分发算法将流量发往处于相同EC2上的App2容器,NLB会将目的IP转换成相同的EC2的IP地址,流量到达EC2后,EC2会将目的IP转换成App2的容器IP,问题在于App2回包的时候,当流量到达EC2 OS层,OS通过查询路由表发现目的地址是自己,会在OS层面直接处理流量,而不会将流量返回给NLB,导致App1访问App2失败。

这个问题是由于NLB的工作原理导致的,NLB在接收到流量后,保持源IP地址不变,通过负载均衡算法选择后端实例,并将目的IP转换成后端实例的IP地址进行流量分发,我们需要在设计上避免上述问题,将App1和App2的容器调度到不同的EC2实例上,从而在根本上避免App1访问App2的流量的发起和终止在同一台EC2实例上。

以上我们的介绍了NLB的主要特点,配置方法及常见的配置注意事项,读者如果感兴趣的话,可以通过下面的链接来进一步学习NLB的相关内容:

https://aws.amazon.com/documentation/elastic-load-balancing/

https://aws.amazon.com/elasticloadbalancing/faqs/

作者介绍

余骏,AWS解决方案架构师,负责基于AWS的云计算方案架构的咨询和设计,同时致力于AWS云服务在国内的应用和推广。在加入AWS之前,在思科中国担任系统工程师,负责方案咨询和架构设计,在企业私有云和基础网络方面有丰富经验。