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提供了多种负载均衡器接入模式提供给用户使用;但是无论哪一种模式,负载均衡都是一种“有状态的服务”;承载这类服务的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服务器。
如上图所示,如果对负载均衡流量进行抓包分析,可以看到如下的源和目的地址特征:
-
客户端IP地址->VIP地址(Edge Uplink地址段的一个辅助地址)
-
客户端IP地址->服务器IP地址(Web-01a或者Web-02a)
-
服务器IP地址->客户端IP地址
-
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负载均衡架构,数据流走向包括:
-
客户端IP地址->VIP地址
-
NSX Edge IP地址->服务器IP地址(Web-01a或者Web-02a)
-
服务器IP地址->NSX Edge IP地址
-
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的安全微分段实现对业务虚拟机的保护;
-
规则示例如下:
规则命名 |
源 |
目的 |
服务/端口 |
策略 |
生效对象 |
备注 |
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集成的架构中,如何精准快速地实现安全微分段,实现对业务的安全防护,敬请期待~
来源:CSDN
作者:z136370204
链接:https://blog.csdn.net/z136370204/article/details/104110049