不少朋友认为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)来实现。
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服务器。
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云管理与自动化等产品，能提供包括实实时应用性能与网络流量监控、闭环分析、深度机器学习、应用交付自动化等更为强大的功能。
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互通。
接下来，晓冬就用配置用例来演示使用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和他们的具体版本，需要查询官网手册）。
在Network界面，管理员需要定义SE被创建后，用于和AVI控制器互通的管理网络，以及可用的地址段。
比如，在晓冬的环境，定义SE管理地址是预先规划的172.30.82.0/24。
当管理员创建一个负载均衡器用于应用交付的时候，如果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地址采用同一个地址段；
对于后端地址池和服务器地址段L3互通的情况，需要定义路由，告诉SE，所有去往服务器地址段的流量应该发往SE的后端地址池，如下图所示：
否则可能导致SE网络连通性测试失败，SE不会自动创建的情况。
至此，我们交付了一个应用（为了后续的连载演示用，本次负载均衡器后端服务器仅有1台，但是不妨碍各位了解ALB的配置过程）。当用户访问前端地址映射到公网的IP地址后，就可以访问该应用了。
接下来，我们通过在vCenter上SE的变化，来验证一些原理。
0x05.来看看vCenter上的SE有什么变化吧！
如果采用后端地址池与服务器地址段L2互通，那么当创建第一台VS后，会有2个SE实例虚拟机被创建(因为晓冬定义了SE采用Active-Standby冗余)；
SE管理地址段，会自动分配2个地址，用于SE与ALB管理器互通；
前端地址池，会自动分配1个地址，用于SE前端地址；两台SE中，只有承载VS的实例(Active节点)，才会被分配到这个前段地址；
后端地址池，会自动分配1个地址，用于SE后端地址；两台SE中，只有承载VS的实例，才会被分配到这个后端地址。
在vCenter上，可以看到活动的SE实例虚拟机分别连接到了前端地址池和后端地址池关联的分布式虚拟机端口组上；
目前后端地址池采用和真实服务器相同的地址段，因此连接到了10.1.10.0/24这个服务器地址段上。
而备用的SE实例虚拟机，并不会连接到对应的虚拟机端口组。
如果管理员采用独立的后端地址池，不和真实服务器同一个地址段，那么SE会连接到管理员定义的后端地址池关联的分布式虚拟机端口组。
比如，管理员将后端地址池定义为特定的10.1.2.0/24；
在完成更新后，SE会立刻从后端地址池中获取一个IP地址，这个IP地址同样只会被承载VS的活动SE所占用；
在vCenter上，同样可以看到SE实例连接到了后端地址池相关的虚拟机网络；
管理员可以点击查看具体的SE的接口地址，来进一步验证之前我们所说的原理。
以上，就是NSX提供的另一种负载均衡Advanced Load Balancer的基础概念和最简单的配置用例。我们可以重复用例的操作，将HQ站点的两台Web01和Web02进行负载均衡，实现应用交付，真正做到一个跨多云网络的应用上线。
如上图所示，由ALB的SE引擎作为Web应用的负载均衡设备，提供外部访问；以NSX DC、VeloCloud、传统网络组成的虚拟云网络，最终将请求从HQ站点转发到BO站点，再由NSX DC提供的软件负载均衡器进行转发，最终经过逻辑网关的“最后一公里”，到达DB，完成访问请求的整个数据包传输路径。
