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

Posted 2021-04-15 大居学V

实验摘要：

1>In-Line Edge负载均衡器的配置 [难度★复杂度★★]

2>One-Arm Edge负载均衡器的配置 [难度★复杂度★★★]

正文：

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

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

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

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

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

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

主题：迷你SDDC环境搭建

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

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

• 进入到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页面的清单中；管理员可以编辑服务器池，添加新的成员服务器

• 点击绿色加号，创建虚拟服务器

• 将虚拟服务器与之前定义的应用配置文件profile-web-vms和服务器池pool-web-vms关联；

• 如果管理员希望借助HTTPS加密访问流量的，可以选择HTTPS作为访问协议，端口默认是443，前提是至少创建了一张自签名证书或者上传了服务器证书，用于HTTP流量的加密
  

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

主题：迷你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-lb-app各项设置无误后，点击完成，等待dev-lb-app设备部署完成

主题：迷你SDDC环境搭建

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

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

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

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

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

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

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

• 同样的，管理员日后可以编辑该服务器池，添加新的App服务器，实现多服务器的负载均衡
  

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

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

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

• 访问Web01虚拟机的命令行，进行相同的测试，可以发现Web01无法与dev-lb-app实现三层互访；

  如果管理员在Web02进行测试，其结果也是相同的；在“文中，我们验证过：dev-web-tier与dev-app-tier之间的三层互访，已经由dev-dlr这台分布式逻辑路由器实现；为什么现在Web01和dev-lb-app之间无法互通呢？

原因很简单：

• 完成静态路由的设置后，不要忘记发布更改
  

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

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

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

• 演示环境一共有5台虚拟机，分别是2台Web虚拟机，2台App虚拟机和1台DB虚拟机；

• 一共有2台负载均衡设备(Edge)，分别承载Web业务和App业务的负载均衡

• 当前用户在访问3Tier应用的时候，是通过Web02-App01-DB01的服务器链实现业务访问的

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

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

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

• 规则示例如下：

规则命名	源	目的	服务/端口	策略	生效对象	备注
Allow-any-to-web	Any	Dev-Web-Tier	HTTP	In/ Allow	Dev-Web-Tier
Allow-web-to-appvip	Dev-Web-Tier	APPVIP	HTTP	In/ Allow	Dev-App-Tier
Allow-appvip-to-app	APPVIP	Dev-App-Tier	HTTP	In/ Allow	Dev-App-Tier
Allow-app-to-db	Dev-App-Tier	Dev-DB-Tier	mysql	In/ Allow	Dev-DB-Tier
Block-others	Any	Dev-Web-Tier Dev-App-Tier Dev-DB-Tier	Any	In/Block	Dev-Web-Tier Dev-App-Tier Dev-DB-Tier

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

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

那么问题来了：

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