不少朋友认为NSX提供的负载均衡“并不靠谱”，无论是从功能还是性能上，都不如一些传统硬件厂商的产品。在讨论这个话题前，我们先来老生常谈地说说NSX DC产品的三大功能集合：软件定义网络组件+包括分布式防火墙在内的安全组件+包括负载均衡、VPN在内的网络功能虚拟化组件。
In 晓冬's humble opinion，用户选择NSX是注重这款云网络产品本身在SDN以及安全方面的特性，尤其是“分布式防火墙提供了数据中心工作负载域内部端到端的安全防护，无论是针对虚拟机、裸金属还是容器都适用”这个亮点功能。而在用户实现了这些功能的基础上，NSX的负载均衡能实现用户“不产生额外的成本花销”前提下，提供基础的L4/L7应用交付能力。因此，NSX的负载均衡更像是“锦上添花”，将它与硬件负载均衡设备(专用设备)进行对比，本身就是一个误区或者说一种偏见。
再者，NSX DC的负载均衡也不见得是“鸡肋”功能。比如：
apiVersion:extensions/v1beta1
kind:Ingress
metadata:
name: nsx-demo-ingress
spec:
rules:
- host: nsx01.tcc.local
http:
paths:
- backend:
serviceName: nsx-demo
servicePort: 80
管理员可以使用NSX来为容器业务构建Ingress(南北向的负载均衡器，如上YAML文件);
NSX DC会在几秒内响应该请求，并创建出用户渴望的面向容器应用的负载均衡器；
这其实就是NSX DC负载均衡器一个典型的应用场景：提供容器应用南北向/东西向负载均衡，提供灵活地应用交付能力，加快业务上线。
在晓冬负责设计和实施的NSX-T的项目中，负载均衡会由Tier1网关的【服务路由器】来承载。这种设计的优势在于不会影响Tier0网关以Active-Active模式部署，支持ECMP来提高吞吐和满足高可用性，同时提供了包括负载均衡在内的有状态的服务。
当访问负载均衡VIP的请求到达Tier1网关，负载均衡器会根据配置文件Profile的定义，使用对应的算法将请求负载到后端可用的服务器。监视器Monitors会按照配置文件的定义，主动/被动地监控服务器的状态，当所有服务器都无法提供服务的时候，SorryServer就会响应，给出一个类似“对不起，您的访问出错了，我们会尽快修复”这样的页面。这是NSX DC能够提供的L4/L7负载均衡的模型，其实在很大程度上已经可以满足工作负载域内的业务需求。
比如在下图的典型3-Tier应用拓扑中，Web前端访问App中间件属于VMware虚拟云网络的内部访问流量，在NSX DC的分布式防火墙构建了端到端安全防护的前期下，App中间件的负载均衡器其实并不需要考虑太多网络安全方面的影响。使用NSX-T自带的负载均衡器在满足网络吞吐的前提下，完全可以胜任业务需求。
但有时，如果负载均衡是面向类似处理大量用户请求的Web前端应用的场景，那设计者必须考虑更多：
1. 更强大性能的负载均衡器，比如吞吐、并发数等；
2. 更灵活的负载均衡器，比如当大量合法请求涌入，负载均衡器能实现“自动弹性扩张”，最大程度地满足可用性；当并发量减少，负载均衡器又能实现“自动弹性收缩”，提高硬件利用率，减少不必要的花销；
3. 更安全的负载均衡器，比如能实现WAF功能，能对DDoS等常见攻击做出告警及进一步的响应等。
显然，在面对这种场景的时候，NSX DC自带的负载均衡功能就会显得“捉襟见肘”。此时，不妨来看看另一种NSX的负载均衡，由NSX Advanced Load Balancer(原来的AVI)来实现。
0x01.NSX ALB是什么？
NSX Advanced Load Balancer(后文简称ALB)是一款功能强大的商用负载均衡产品。并且继承了VMware的一贯作风，是一款纯软件的应用交付控制器产品(后文简称ADC)。
与NSX DC相同，ALB有“集中式的策略管理器”，叫做控制器，用于统一的管理，类似于NSX-T Manager(策略器、管理器和控制器)；提供跨私有云(如VMware、OpenStack)、公有云(AWS、Azure等)、容器(Openshift、K8S等)、裸金属等多种工作负载一致的体验。
与传统硬件ADC不同的是，ALB的“数据平面”游离于“管控平面”之外，由服务引擎Service Engine(后文简称SE)来真正承载负载均衡功能。SE是一台运行的虚拟机，一个应用可同时由多台SE来承载。如上图所示，两台SE以“Active-Standby”模式负载均衡两台Web服务器。
0x02.ALB的优势在哪里？
ALB除了能提供多种工作负载一致的交付体验外，还能为用户带来哪些收益呢？
首先，ALB是软件定义的产品，默认带有“与硬件解耦”的天然优势。在“虚拟化已经在企业普及”的大背景下，部署ALB意味着可以跳过繁琐的物理上架、跳线、固件升级等步骤，敏捷性是第一大优势。
再者，硬件设备不可避免地存在短则3年，长则5年的使用寿命；硬件设备的替换可能是一次“牵一发动全身”的变更；区别于这种场景，SE作为虚拟机不存在硬件的关联性，即使是ESXi服务器要进行维护，利用vMotion、vSphere HA等VMware服务器虚拟化功能，可以提供计划内/外的业务连续性、可用性。
此外，硬件设备存在50%硬件利用率的尴尬；无论业务是否繁重，所有的压力全部集中在其中一台设备。ALB能最大程度地解决这个问题，利用vSphere DRS和反关联规则，能动态地实现分布式资源调度，避免出现硬件服务器资源竞争和资源过剩的弊端，同时满足业务连续性的合规要求。而多台SE之间的“N+1”冗余模式，能在大规模部署场景下，提供几近100%的利用率；“Auto-Scaling”能提供适应并发数的弹性伸缩，从多个角度最大化IT投入的效益。
最后，作为NSX家族的一员，结合vRealize Network Insight网络流量洞察力与可见性、vRealize Automation云管理与自动化等产品，能提供包括实实时应用性能与网络流量监控、闭环分析、深度机器学习、应用交付自动化等更为强大的功能。
0x03.如何才能玩转ALB？
ALB控制器的部署是通过OVA导入的方式来进行的。
由于过程太过枯燥(其实是简单)，此处省略若干字数......
晓冬选择将ALB控制器部署在HQ站点，由于演示环境是全部运行在ESXi服务器上的，选择VMware vCenter作为ALB的编排器，用来进行SE虚拟机服务器的部署等操作。
在开始用ALB实现HQ站点的Web前端服务器负载均衡之前，首先要理解ALB的基本拓扑是如何的！
如上图所示，ALB交付一个应用，涉及到多个IP地址及地址段。
SE管理网络：这是一个类似于“带外管理”的网段，本身并不需要与业务相关的网络L3互通，比如172.30.82.0/24这个SE管理网络不需要和Web服务器所在的10.1.10.0/24互通；但是由于SE需要接受来自ALB控制器的策略，因此需要与ALB控制器实现L3互通。说明一下，在晓冬的环境里，SE和ALB控制器采用了相同的IP地址段。
前端地址：一个SE用于接受访问请求的IP地址段，当多台SE用于承载并冗余某一个业务的时候，这几台SE会分别获取一个前端地址池内可用的IP地址(备用的不会)；对用户来说，只需要访问VIP地址，SE就会受到这些访问请求，然后进行处理。从网络连通性上说，前端地址并不需要与SE管理地址、服务器的真实IP地址互通，因为SE本身就会是一台“路由器”。
后端地址：一个SE用于和业务服务器通信的IP地址段，当前端地址接收到客户端请求后，最终会“横穿”SE，通过后端地址将请求分发到真实服务器。如果管理员未明确定义后端地址池，那么SE会自动分配一个与真实服务器同一个网段的IP地址，用于后端地址与其进行通讯。在实际的项目中，晓冬建议管理员创建一个“专用”的后端地址池，这样便于网络管理员进行地址规划与管理。后端地址并不需要与SE管理网络、前端地址实现L3互通，但是必须和真实服务器L3互通。
0x04.如何配置ALB，交付一个应用呢？
接下来，晓冬就用配置用例来演示使用NSX ALB交付一个应用。
通过初始化向导配置的云Cloud配置，将会被自动命名为Default-Cloud；管理员可以沿用这个默认配置，也可以自建一个云Cloud；
管理员可以点击查看Default-Cloud配置，比如vCenter、NSX DC的这些集成参数都是在ALB初始化阶段由管理员设置的。当用于集成的vCenter、NSX DC账户凭据发生了改变的情况下，管理员同样需要在此处进行更新。
AVI原生支持多租户、多云环境，管理员可以根据需要，添加不同的云。
比如，晓冬添加了一个命名为“s12-alb-clouds”的云；
在基础架构页面，管理员可以定义vCenter服务器，在键入用户名和密码后，相关SE引擎会自动在后续“DataCenter”定义的vCenter数据中心纳管的服务器上被部署。
同时，AVI支持与NSX数据中心集成，具体支持的版本（如NSX-V或者NSX-T和他们的具体版本，需要查询官网手册）。
当管理员创建一个负载均衡器用于应用交付的时候，如果ALB当前无任何可用的SE，系统会提供管理员立刻创建一个SE用于承载业务；管理员也可以在创建负载均衡器之前，首先创建可用的SE。
选择在新建的Cloud中创建新的服务引擎组SE Group；
定义SE的冗余模式，一般情况下建议选择N+M；晓冬本次演示用例选择A-S模式。
以及其他SE虚拟机的硬件配置，如CPU数量、内存数量和预留的占比等；
同时根据实际情况，自定义SE管理地址采用的地址段。
如果管理员未定义SE管理地址段，那么创建的SE将沿用Cloud默认配置；在本用例中，晓冬指定SE管理地址为“172.30.82.0/24”;
当SE被创建以后，第一个虚拟网络适配器vNIC0就会自动连接到这个网络地址段关联的分布式虚拟机端口组。
在创建服务器池之前，首先需要选择Cloud云，后端地址池将会调用对应的Cloud下定义的地址池；
定义服务器池名称，默认的服务端口号，负载均衡算法和持续性配置文件等设置；
由于VS需要在SE上被创建，因此需要定义VS被创建时会关联的Cloud；
定义服务器VIP地址，一般建议与前端地址池位于相同的地址段，
定义服务器端口，一般采用TCP443，即HTTPS，以及对应的SSL配置文件，
根据实际情况，选择合适的WAF配置文件，同样可以根据需要，创建WAF配置文件；
根据实际情况，选择前端地址池，一般情况下前端地址池和VIP地址采用同一个地址段；
否则可能导致SE网络连通性测试失败，SE不会自动创建的情况。
至此，我们交付了一个应用（为了后续的连载演示用，本次负载均衡器后端服务器仅有1台，但是不妨碍各位了解ALB的配置过程）。当用户访问前端地址映射到公网的IP地址后，就可以访问该应用了。
接下来，我们通过在vCenter上SE的变化，来验证一些原理。
0x05.来看看vCenter上的SE有什么变化吧！
如果采用后端地址池与服务器地址段L2互通，那么当创建第一台VS后，会有2个SE实例虚拟机被创建(因为晓冬定义了SE采用Active-Standby冗余)；
而备用的SE实例虚拟机，并不会连接到对应的虚拟机端口组。
以上，就是NSX提供的另一种负载均衡Advanced Load Balancer的基础概念和最简单的配置用例。我们可以重复用例的操作，将HQ站点的两台Web01和Web02进行负载均衡，实现应用交付，真正做到一个跨多云网络的应用上线。
如上图所示，由ALB的SE引擎作为Web应用的负载均衡设备，提供外部访问；以NSX DC、VeloCloud、传统网络组成的虚拟云网络，最终将请求从HQ站点转发到BO站点，再由NSX DC提供的软件负载均衡器进行转发，最终经过逻辑网关的“最后一公里”，到达DB，完成访问请求的整个数据包传输路径。
现在，我们基本已经聊完了网络。在下次分享中，晓冬将聊一聊这种网络框架下，VMware的NSX家族能带来哪些安全防护？区别于NSX DC的软件负载均衡器，ALB能做的是否更多？欢迎各位持续关注。
