新一代负载均衡器服务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之前，在思科中国担任系统工程师，负责方案咨询和架构设计，在企业私有云和基础网络方面有丰富经验。