- 简述
- 我们通过第二个实验来验证我们的观点:
- 1.部署一台DLR逻辑路由器,接口定义如下:
- 2.选择新部署的Edge类型是逻辑路由器DLR,勾选“部署Edge设备”,即同时部署DLR-CVM控制虚拟机
- 3.选择DLR-CVM部署的位置,一般建议部署在Edge Cluster边界集群
- 4.根据拓扑规划,配置DLR直连的网络
- 5.为了验证静态路由流程,不配置默认网关
- 6.确认各项参数设置无误后,开始部署DLR
- 7.在完成DLR-Instance部署后,相比无DLR-CVM的情况,可以看到2个明显的不同
- 8.SSH访问ESXi命令行,查看ESXi内核空间中,创建的逻辑路由器实例DLR-Instance
- 9.管理员通过Web Client添加一条静态路由
- 10.很快,我们就能看到JUMP虚拟机可以PING通172.20.5.180
- 11.访问NSX Controller,检查路由的更新源;可以看到路由的更新源从原来的API,变成了CONTROL_VM
- 12.查看DLR-Instance的路由表,可以看到多了一条静态路由条目
- 13.对比有无DLR-CVM的两种情况,不难发现:两种模式下,netcpad在路由更新的过程中,都扮演着无法替代的角色,现在我们通过命令行,停止在用户空间运行的netcpad服务
- 14.此时可以看到DLR-instance的路由条目没有发生改变,JUMP虚拟机也可以继续PING通172.20.5.180,说明NSX架构中,控制平面与转发平面完全隔离
- 15.管理员保持ESXi用户空间的netcpad停止服务状态的同时,通过Web Client删除静态路由
- 17.ESXi底层命令行查看DLR-Instance实例的信息,也可以看到路由条目没有发生变化
- 18.由于netcpad服务的停止,不会影响NSX Manager通过vsfwd,将路由配置下发到DLR-CVM,因此在DLR-CVM的底层,我们是可以看到“172.20.5.0/24 NH=172.18.0.1”这条静态路由已经不存在了
- 19.管理员通过命令行,重新启动netcpad服务
- 20.可以看到,在netcpad服务重新启动后,DLR-instance的路由条目发生了更新
- 21.相对应的,JUMP虚拟机也无法再PING通172.20.5.180地址
- 22.下面我们关闭DLR-CVM控制虚拟机电源
- 23.管理员重新添加一条静态路由
- 24.表面上看,似乎没有什么问题,但是在Publish Changes之后,再次刷新页面,这条静态路由会自动消失
- 25.很明显,这条静态路由并没有下发到DLR-CVM,当然也就不存在DLR-CVM报告给Controller,最终转发到DLR-Instance的后续步骤了,因此JUMP肯定无法PING通172.20.5.180
- 26.在ESXi底层,查看DLR-Instance信息,也可以证明这一点
- 27.访问Controller底层,也可以看到没有任何路由更新的信息
- 28.重新打开DLR-CVM控制虚拟机的电源,同时停止ESXi用户空间运行的vsfwd服务,验证vsfwd对于静态路由更新流程的影响
- 29.管理员添加一条静态路由
- 30.在这种情况下,管理员刷新Web Client,这条静态路由的配置是不会自动消失的
- 31.在Controller底层查看路由更新的信息,由于DLR-CVM没有收到vsfwd转发过来的路由配置,因此DLR-CVM也没有新的路由更新报告给Controller
- 32.在DLR-CVM命令行,确认没有收到静态路由配置的更新
- 33.我们在ESXi命令行,重新启动vsfwd服务
- 34.这时,DLR-CVM马上就收到了静态路由配置条目,这条路由更新是NSX Manager通过管理平面组件vsfwd下发给DLR-CVM的
- 35.在Controller底层,可以看到DLR-CVM通过netcpad报告的路由更新
- 36.集群每一台ESXi主机的netcpad在收到Controller的路由表更新后,转发给DLR-Instance
- 更新流程:
简述
在上一篇里,我们介绍了NSX控制平面的组件,包括NSX Controller集群、DLR-CVM控制虚拟机和很容易被忽略的netcpa。
通过一个简单的实验,我们一同验证了在没有DLR-CVM的前提下,管理员配置静态路由并更新的流程:
- 管理员通过vCenter Web Client配置静态路由,通过NSX Manager将静态路由配置推送给NSX控制器(Internal API)
- NSX控制器将Routing Information Base (RIB)转发到集群每一台ESXi的netcpa
- netcpa通过vmkIink,将更新的路由表FIB写入到DLR-Instance内核中
那么,对于有DLR-CVM参与的情况,管理员配置静态路由并更新的流程,又是如何的呢?
- 管理员通过vCenter Web Client配置静态路由,通过NSX Manager将静态路由配置推送给DLR-CVM所在ESXi的vsfwd
- vsfwd通过VMCI,将静态路由配置推送给DLR-CVM
- DLR-CVM通过VMCI,将Routing Information Base (RIB)报告给netcpa
- netcpa通过TCP1234连接,将Routing Information Base (RIB)报告给Controller控制器集群
- NSX控制器将Routing Information Base (RIB)转发到集群每一台ESXi的netcpa
- netcpa通过vmkIink,将更新的路由表FIB写入到DLR-Instance内核中
可以看到,在上述情况下,管理平面组件vsfwd也参与了静态路由配置并更新的流程。
我们通过第二个实验来验证我们的观点:
1.部署一台DLR逻辑路由器,接口定义如下:
- Dev-Web-Tier-0118:172.18.10.1/24(Internal)
- Dev-App-Tier-0118:172.18.20.1/24(Internal)
- Dev-DB-Tier-0118:172.18.30.1/24(Internal)
- Dev-Transit-0118:172.18.0.2/29(Uplink)
2.选择新部署的Edge类型是逻辑路由器DLR,勾选“部署Edge设备”,即同时部署DLR-CVM控制虚拟机
3.选择DLR-CVM部署的位置,一般建议部署在Edge Cluster边界集群
4.根据拓扑规划,配置DLR直连的网络
5.为了验证静态路由流程,不配置默认网关
6.确认各项参数设置无误后,开始部署DLR
7.在完成DLR-Instance部署后,相比无DLR-CVM的情况,可以看到2个明显的不同
- 多了一台DLR-CVM控制虚拟机
- DLR-Instance的部署状态是Deployed已部署
8.SSH访问ESXi命令行,查看ESXi内核空间中,创建的逻辑路由器实例DLR-Instance
在ESXi主机使用命令:# net-vdr -l —instance
- 可以看到Edge Active状态已经是Active
- 新创建的DLR-Instance的VDR ID是0x00001771,VDR Name是default+edge-31
9.管理员通过Web Client添加一条静态路由
10.很快,我们就能看到JUMP虚拟机可以PING通172.20.5.180
11.访问NSX Controller,检查路由的更新源;可以看到路由的更新源从原来的API,变成了CONTROL_VM
12.查看DLR-Instance的路由表,可以看到多了一条静态路由条目
13.对比有无DLR-CVM的两种情况,不难发现:两种模式下,netcpad在路由更新的过程中,都扮演着无法替代的角色,现在我们通过命令行,停止在用户空间运行的netcpad服务
14.此时可以看到DLR-instance的路由条目没有发生改变,JUMP虚拟机也可以继续PING通172.20.5.180,说明NSX架构中,控制平面与转发平面完全隔离
注:这并不代表说,DLR-CVM控制虚拟机的故障不会影响DLR-Instance的无状态转发,相反,在配置动态路由的情况下,南北向流量可能会因为DLR-CVM的故障受到严重的影响。
15.管理员保持ESXi用户空间的netcpad停止服务状态的同时,通过Web Client删除静态路由
16.在保持netcapd停止的情况下,JUMP虚拟机可以继续PING通172.20.5.180
17.ESXi底层命令行查看DLR-Instance实例的信息,也可以看到路由条目没有发生变化
18.由于netcpad服务的停止,不会影响NSX Manager通过vsfwd,将路由配置下发到DLR-CVM,因此在DLR-CVM的底层,我们是可以看到“172.20.5.0/24 NH=172.18.0.1”这条静态路由已经不存在了
19.管理员通过命令行,重新启动netcpad服务
20.可以看到,在netcpad服务重新启动后,DLR-instance的路由条目发生了更新
21.相对应的,JUMP虚拟机也无法再PING通172.20.5.180地址
22.下面我们关闭DLR-CVM控制虚拟机电源
23.管理员重新添加一条静态路由
24.表面上看,似乎没有什么问题,但是在Publish Changes之后,再次刷新页面,这条静态路由会自动消失
25.很明显,这条静态路由并没有下发到DLR-CVM,当然也就不存在DLR-CVM报告给Controller,最终转发到DLR-Instance的后续步骤了,因此JUMP肯定无法PING通172.20.5.180
26.在ESXi底层,查看DLR-Instance信息,也可以证明这一点
27.访问Controller底层,也可以看到没有任何路由更新的信息
28.重新打开DLR-CVM控制虚拟机的电源,同时停止ESXi用户空间运行的vsfwd服务,验证vsfwd对于静态路由更新流程的影响
29.管理员添加一条静态路由
30.在这种情况下,管理员刷新Web Client,这条静态路由的配置是不会自动消失的
31.在Controller底层查看路由更新的信息,由于DLR-CVM没有收到vsfwd转发过来的路由配置,因此DLR-CVM也没有新的路由更新报告给Controller
32.在DLR-CVM命令行,确认没有收到静态路由配置的更新
33.我们在ESXi命令行,重新启动vsfwd服务
34.这时,DLR-CVM马上就收到了静态路由配置条目,这条路由更新是NSX Manager通过管理平面组件vsfwd下发给DLR-CVM的
35.在Controller底层,可以看到DLR-CVM通过netcpad报告的路由更新
36.集群每一台ESXi主机的netcpad在收到Controller的路由表更新后,转发给DLR-Instance
根据上文的描述,我们验证了在部署DLR-CVM的情况下,管理员配置静态路由后的
更新流程:
vCenter———API———NSX Manager——-Internal API——-vsfwd——-VMCI——-DLR CVM——-VMCI——-netcpa——-TCP1234——-Controller——-TCP1234——-netcpa——-vmklink——-DLR Instance
通过前后两篇文字的讨论,相信各位对NSX控制平面组件及静态路由更新的流程,有了比较深入的了解,这也是晓冬在年前的最后一次更新。
在己亥新年到来之际,晓冬祝各位:
新春吉祥 万事如意 身体健康 阖家团圆~