一步步实现SDDC-Edge负载均衡

正文：

在上一篇的介绍中，迷你SDDC环境的逻辑网络和物理网络已经实现三层互通，具备了部署业务的基本条件。

在实际业务场景中，出于系统稳定性和可用性的考量，企业会选择部署负载均衡器来实现业务负载平衡。拿NSX DC产品来说，既支持与第三方硬件厂商解决方案的集成(如F5)，也可以选择由NSX DC原生组件承载负载均衡器的角色。

如下图所示，我将部署2台Edge，分别作为Web业务服务器和App业务服务器的负载均衡设备：

其中Web业务服务器的负载均衡设备，将由上一篇文章中演示创建的dev-esg承载，可以看到该Edge串联在逻辑网络中，所有的流量均会经过该设备，是一台In-Line负载均衡器。

在本文中，我还将新建一台Edge Services Gateway，但不将它串联进逻辑网络，而是选择以单臂或者说旁挂模式连接到dev-app-tier逻辑交换机上，只有相关的访问流量才会经过该负载均衡器。

通过上述描述，各位可以发现，NSX提供了多种负载均衡器接入模式提供给用户使用；但是无论哪一种模式，负载均衡都是一种“有状态的服务”；承载这类服务的Edge Services Gateway本身不能以ECMP作为高可用，只能选择HA方式；类似负载均衡的“有状态服务”还包括：网络地址转换NAT、NSX-V支持的三种VPN等。

对于NSX-T来说，包括负载均衡在内的多种服务，可以通过T0 SR或者T1 SR实现，在以后的分享中，我也会演示在NSX-T的使用场景下，如何实现多台服务器的负载均衡。

主题：迷你SDDC环境搭建

任务32：In-Line Edge负载均衡器的配置

现在，我将首先演示利用上篇部署的dev-esg，部署承载Web服务的负载均衡器。

之前，我们定义了dev-esg的上联接口Uplink Interface地址为172.20.12.100，现在我将为dev-esg添加一个辅助地址172.20.12.200，用来作为Web01和Web02两台服务器的负载均衡VIP地址。

• 为dev-esg添加一个辅助地址，网络地址为172.20.12.200
  

• 进入到Load Balancer负载均衡器配置界面，在默认的Global Configuration页面，点击Edit编辑全局设置
  
• 勾选Enable Load Balancer，激活这台Edge的负载均衡功能
  

• 进入Application Profiles页面，创建一个应用配置文件
  

• NSX DC支持七层负载均衡，定义配置文件名为profile-web-vms，类型为七层协议HTTP；
  
• 一般来说，为了统计访问量，可以选择勾选插入X-Forwarded字段；同时，管理员可以出于对安全的考量，为HTTP通信加密，客户端将会通过HTTPS协议访问业务。
  
• 完成应用配置文件定义后，进入Pools页面，点击绿色加好，添加负载均衡的服务器池
  
• 定义服务器池命名为pool-web-vms，将Web01和Web02添加到这个服务器池，作为负载均衡的成员服务器；管理员也可以为负载均衡定义多种算法，如常见的Round-Robin
  
• 完成添加操作后，服务器池将会自动编号并出现在Pools页面的清单中；管理员可以编辑服务器池，添加新的成员服务器
  

• 应用配置文件定义了用户希望负载均衡的服务，如TCP8443端口的Tomcat服务或者HTTP/HTTPS这类七层应用；服务器池定义了负载均衡的目标服务器成员，如Web01和Web02；而Virtual Servers虚拟服务器定义了负载均衡VIP地址，并且关联之前定义的多个配置；
  
• 点击绿色加号，创建虚拟服务器
  

• 指定VIP地址为dev-esg的辅助地址，即172.20.12.200
  

• 将虚拟服务器与之前定义的应用配置文件profile-web-vms和服务器池pool-web-vms关联；
  
• 如果管理员希望借助HTTPS加密访问流量的，可以选择HTTPS作为访问协议，端口默认是443，前提是至少创建了一张自签名证书或者上传了服务器证书，用于HTTP流量的加密
  

完成上述配置后，当用户访问http://172.20.12.200，In-Line负载均衡器会把访问流量负载均衡到Web01服务器或Web02服务器。

如上图所示，如果对负载均衡流量进行抓包分析，可以看到如下的源和目的地址特征：

1. 客户端IP地址->VIP地址（Edge Uplink地址段的一个辅助地址）
   
2. 客户端IP地址->服务器IP地址（Web-01a或者Web-02a）
   
3. 服务器IP地址->客户端IP地址
   
4. VIP地址->客户端IP地址
   

主题：迷你SDDC环境搭建

任务33：One-Arm Edge负载均衡器的配置

阶段1：部署One-Arm Edge Services Gateway

在实现Web服务器负载均衡后，我们还需要对App服务器实现负载均衡，这个功能将由一台One-Arm单臂ESG实现。

与之前部署dev-esg步骤类似，首先要部署一台Edge Services Gateway设备，并命名为dev-lb-app：

• 过程基本与创建dev-esg相同，我就不赘述了，请各位参看截图
  

• 由于这台Edge是以单臂模式实现负载均衡，不需要串联进逻辑网络，因此只需要定义一个Internal Interface内部接口即可
  
• 选择将Edge连接到dev-app-tier逻辑交换网络，并定义内部接口网络地址为10.0.20.10/24，与App01和App02是相同的地址段
  

• 只有一个内部接口的Edge设备无法定义默认的网关
  
• dev-app-tier的网关是分布式逻辑路由器dev-dlr上的一个内部接口地址，即10.0.20.1
  

• 确认dev-lb-app各项设置无误后，点击完成，等待dev-lb-app设备部署完成
  

主题：迷你SDDC环境搭建

任务33：One-Arm Edge负载均衡器的配置

阶段2：One-Arm Edge负载均衡器的配置

现在，我将借助刚才部署的dev-lb-app，实现App01和App02两台虚拟机的负载均衡。

无论是In-Line负载均衡器还是One-Arm负载均衡器，虽然部署的模式不同，但是配置的步骤基本类似；与配置Web服务器相类似，在配置App服务器的负载均衡时，我们也需要创建应用配置文件，定义服务器池和成员，最后设置一个VIP地址，用于负载均衡流量访问：

• 同样地，首先在全局配置下，激活dev-lb-app Edge的负载均衡功能
  

• 定义应用配置文件；与之前的设置不同，这次是针对4层的负载均衡，因此选择类型为TCP
  

• 定义服务器池pol-app-vms，将App01和App02设置为池成员
  

• 在我的演示环境中，App01服务器和App02服务器对外以TCP80端口提供服务
  

• 同样的，管理员日后可以编辑该服务器池，添加新的App服务器，实现多服务器的负载均衡
  
• 最后配置一台虚拟服务器，并设置dev-lb-app Edge的内部接口地址(10.0.20.10)作为App服务器负载均衡的VIP地址
  

至此，One-Arm负载均衡器的配置基本结束；

不知道是否有细心的朋友发现，在dev-lb-app设备的部署和配置过程中，有一个会对业务产生致命影响的漏洞存在。

对此，我先卖个关子，请各位先浏览下文的测试内容：

• 访问App01虚拟机的命令行，尝试ping dev-lb-app的内部接口地址，也是App服务负载均衡器的VIP地址，即10.0.20.10；
  
• 可以看到由于App01与dev-lb-app都连接到dev-app-tier这台逻辑交换机，网络地址也都是10.0.20.0/24地址段，因此在默认情况下，两者就可以实现互通。
  
• 
• 访问Web01虚拟机的命令行，进行相同的测试，可以发现Web01无法与dev-lb-app实现三层互访；
  如果管理员在Web02进行测试，其结果也是相同的；在“一步步实现SDDC-逻辑交换与逻辑路由”文中，我们验证过：dev-web-tier与dev-app-tier之间的三层互访，已经由dev-dlr这台分布式逻辑路由器实现；为什么现在Web01和dev-lb-app之间无法互通呢？
  

原因很简单：

在创建dev-lb-app的步骤中，我定义了内部接口的IP地址为10.0.20.10/24，但是尚未定义网关；这也是单臂模式与路由模式在配置过程中主要的区别之一。

• 因此，需要为dev-lb-app设置一条静态路由，0.0.0.0/0 NH=10.0.20.1，即dev-dlr的一个内部接口地址
  
• 完成静态路由的设置后，不要忘记发布更改
  
• 再次访问Web01命令行，测试结果表明，Web01可以正常访问dev-lb-app这台设备的内部地址了
  
• 

演示了两种负载均衡模式的部署和配置后，各位不难发现：虽然负载均衡的模式不同，但是配置步骤基本相似；如果管理员对One-Arm负载均衡进行网络流量分析，看到的数据流是否与之前In-Line负载均衡模式下的相同呢？

上图所示，是一个典型的One-Arm负载均衡架构，数据流走向包括：

1. 1.客户端IP地址->VIP地址
   
2. 2.NSX Edge IP地址->服务器IP地址（Web-01a或者Web-02a）
   
3. 3.服务器IP地址->NSX Edge IP地址
   
4. 4.VIP地址->客户端IP地址
   

在Web服务器和App服务器的负载均衡设置均完成后，通过JUMP服务器访问http://172.20.12.200，用户可以看到如下界面：

• ▪ 演示环境一共有5台虚拟机，分别是2台Web虚拟机，2台App虚拟机和1台DB虚拟机；
  
• ▪ 一共有2台负载均衡设备(Edge)，分别承载Web业务和App业务的负载均衡
  
• ▪ 当前用户在访问3Tier应用的时候，是通过Web02-App01-DB01的服务器链实现业务访问的
  

至此，迷你SDDC环境的业务正式上线了，用户通过访问业务地址http://172.20.12.200，系统会自动负载均衡访问流量，并反馈结果给用户；

当然，在实际的生产环境中，一般会对HTTP访问进行加密，同时以域名代替IP的方式发布给用户。

下方是迷你SDDC环境所有涉及到的服务器和虚拟机清单：

除此以外，出于对安全性的考量，我还需要为3-Tier-App业务设置分布式防火墙规则，借助于NSX的安全微分段实现对业务虚拟机的保护；

• 规则示例如下：
  

由于我对迷你SDDC环境承载的3-Tier-App业务非常了解，根据Web-App-DB的网络数据流走向，我可以比较快速和精准地完成分布式防火墙规则的设置；

通过上述示例和下图，各位不难发现，VMware NSX DC的软件定义防火墙规则可以针对任何虚拟化参数进行设置，其中包括：安全组、七层应用、固定IP、逻辑交换网络、四层端口等；强大的灵活性，也是NSX DC分布式防火墙吸引用户选择的原因之一。

那么问题来了：

如果您是一位刚入职的安全管理员，对之前已经上线的业务并不十分了解；您该如何借助VMware NSX DC解决方案，定义分布式防火墙规则，精准快速地实现对业务的安全防护呢？
在本系列的最后一篇分享中，我将演示在VMware NSX DC与vRealize Network Insight集成的架构中，如何精准快速地实现安全微分段，实现对业务的安全防护，敬请期待~