最近这两个月，工作强度陡然提升。前不久为了归纳和总结NSX DC分别与HOST-VM容器和裸金属容器的最佳实践和“特殊部署”，已经起早贪黑了两个多礼拜。因此，公众号的更新频率有所下降。好在功夫不负有心人，届时我也会推出专门的篇幅来介绍云原生场景的技术实现。
在今天的分享中，我将继续上一篇的内容，向大家展示管理员通过Openstack Horizon或者命令行执行配置的时候，NSX DC后端究竟发生了什么变化。
如上图所示，各位可以看到OpenStack的Neutron网络组件，包括了交换、路由、负载均衡、防火墙等。在与NSX DC集成的场景中，这些原先由Neutron插件提供的功能，将通过NSX Neutron Plugin，由NSX DC来提供。
简单来说，Openstack与NSX DC的集成：
1. 保留用户原先OpenStack的使用习惯，用户在Horizon或者OpenStack命令行进行日常操作
2. 包括L2交换、L3路由、负载均衡器、安全组等常用功能在内的原Neutron功能不变；并且因为NSX DC的关系，多了些原OpenStack没有的功能，比如动态路由协议支持。
3. 由于NSX DC能够支持包括vSphere、OpenStack、Container、Bare Metal在内的异构平台，因此管理员可以将整个私有云的网络与安全进行统一纳管，构建虚拟云网络，承载企业业务。
接下来，我们看看管理员在OpenStack Horizon UI界面或者命令行进行配置的时候，NSX DC后端究竟发生了什么变化。这有助于我们更好地理解OpenStack与NSX DC集成的原理。
=======
I.逻辑交换机
============
首先来看看OpenStack上的配置：
进入项目-网络-网络界面，点击“创建网络”。
创建一个用于Web应用的Neutron网络，如：Dev-Web-Tier-0613。
定义网络地址、网关地址等信息
选择是否开启DHCP。
依次完成Web、App、DB三个网络的创建。
在完成上述配置后，NSX DC上又能看到哪些变化呢？
可以看到在NSX DC上，出现了自动创建的三个逻辑交换网络，对应在Openstack创建的三个Neutron网络。
由于该Overlay传输区域同样关联了ESXi服务器，因此可以在ESXi上同样看到创建的三个逻辑交换机。
相当于实现了跨OpenStack与VMware的逻辑网络互联（目前只有二层，需要逻辑路由才能实现三层）。
对于开启了DHCP自动分配IP地址的场景，在Openstack上可以看到该Neutron网络自动连接到了一个DHCP服务器。
在NSX MGR上，同样可以看到该逻辑交换机连接到了DHCP Service Router和元数据代理服务器。
对于一般的VLAN类型的逻辑交换机、以及TRUNK类型的VLAN逻辑交换机，实现的原理与Overlay类型的逻辑交换机相类似，只有一点不同：
TRUNK类型的VLAN逻辑交换机必须通过命令行实现，无法通过Horizon UI界面进行配置。
=======
II.逻辑路由器
============
进入项目-网络-路由界面，添加一台路由设备。
定义名称为T1_Tenant1。
暂时不选择连接到外部网络，启动SNAT；
等待路由器实例创建完成。
为路由器实例添加内联LIF，连接到Web、App、DB三个Neutron网络。
设计Dev-Web-Tier：10.0.10.1/24
设计App-Web-Tier：10.0.20.1/24
设计DB-Web-Tier：10.0.30.1/24
在NSXMGR上，可以看到创建了一个Tier-1级别的逻辑路由器。
该逻辑路由器下联三个逻辑交换网络，并定义了接口地址（网关地址）。
当实例连接到逻辑交换机后，在Hypervisor(KVM)命令行，可以看到创建的逻辑路由器实例和三个对应的逻辑交换。
可以看到，管理员在OpenStack上创建L2交换机或者L3路由器，会在NSX DC创建对应的逻辑交换机和逻辑路由器。通过命令行，我们可以非常简单地去验证这些。
接下来，我将尝试把OpenStack上的路由器连接到外部网络，这里会发生一些有趣的事情。
=======
III.外部网络
============
在Horiozn页面，创建一个外部网络。
创建一个Local类型的外部网络。
这个网络在OpenStack和NSX DC集成的世界，似乎毫无意义~
定义子网信息。
等待外部网络创建完成。
在Horizon的网络拓扑页面，可以看到该外部网络已经创建。
但是，请注意，管理员在NSXMGR上是看不到该网络的。
虽然这个“外部网络”在NSXMGR上没有任何蛛丝马迹，但是在OpenStack控制器命令行可以查看到该网络信息。
# openstack network show 网络名称
现在，编辑之前创建的路由器实例，选择连接到该外部网络。
在完成上述操作后，可以看到该Tier1逻辑路由器连接到了Tier0逻辑路由器。
可以看到，只有管理员在OpenStack上将某一个路由器连接到外部网络后，这些变更才会呈现在NSXMGR上。
上一回分享中，我提及：OpenStack和NSX DC的集成是借助于Neutron Plugin实现的，管理员需要配置nsx.ini来告诉OpenStack，将来创建的对象应该在哪些区域。比如：
L2交换机应该在UUID为A的Overlay传输控制区域被创建；
L3路由器应该在UUID为A的Overlay传输控制区域被创建；
当管理员尝试将路由器连接到外部网络的时候，实际上Tier1逻辑路由器会被连接到UUID为B的Tier0逻辑路由器；
当管理员在创建L2交换机，并且勾选了启用DHCP的时候，相关的配置会被自动添加到UUID为C的DHCP配置文件，并且由UUID为D的元数据代理处理。
因此，各位一定可以想到，如果管理员配置了负载均衡器，那么LB实例一定会被创建在UUID为E的Edge Cluster；接下来，就一起来验证一下猜想。
=======
IV.网络功能虚拟化-负载均衡器
============
由于在Horizon页面，无法选择HTTPS作为负载均衡协议，因此选择采用命令行方式进行；创建负载均衡器。
# neutron lbaas-loadbalancer-create --nameT1_Tenant_LB Dev-Web-Tier-0613--vip-address 10.0.10.10
注：此时不会在NSXMGR上创建负载均衡器实例。
创建侦听器。
# neutron lbaas-listener-create--loadbalancer T1_Tenant_LB --protocol HTTPS --protocol-port 443--name HTTPS-Listener
注：在Horizon上可以看到负载均衡器和侦听器已经被创建。
创建服务器池。
# neutron lbaas-pool-create --lb-algorithmROUND_ROBIN --listener HTTPS-Listener --protocol HTTPs--name WEBPOOL
注：截止目前，不会有任何负载均衡器相关对象在NSXMGR上被创建。
将Web-01a和Web-02a添加到服务器池。
# neutron lbaas-member-create --subnet Dev-Web-Tier-0613 --address 10.0.10.12 --protocol-port 443WEBPOOL
# neutron lbaas-member-create --subnet Dev-Web-Tier-0613 --address 10.0.10.7--protocol-port 443WEBPOOL
注：此时会在NSX上创建负载均衡器，该负载均衡器会以单臂形式创建，关联到Dev-Web-Tier-0613逻辑交换机；负载均衡器将会在Tier-1路由器所在的Edge节点上被创建（本质上是因为管理员定义了Edge Cluster的UUID，因此相关的Service Router实例均会在对应的Edge节点上被创建）。
注：如果是虚拟机版本的Edge，必须是中等规模以上，否则系统会反馈：由于Edge节点是Small小型部署，无足够空间创建负载均衡器。
设置健康检查。
# neutron lbaas-healthmonitor-create --typeHTTPS --url-path / --delay 3--max-retries 3 --timeout 3 --pool WEBPOOL --name HC_HTTPS
在Horizon页面可以查看负载均衡器的信息，其中正常情况下：
操作状态=在线；
置备状态=运行中。
在OpenStack控制器命令行，可以查看相应的配置。
查看负载均衡器：
# neutron lbaas-loadbalancer-list
查看侦听器：
# neutron lbaas-listener-list
查看服务器池：
neutronlbaas-pool-list
查看池成员，如WEBPOOL成员：
neutron lbaas-member-list WEBPOOl
查看健康状态检查设置：
neutronlbaas-healthmonitor-list
需要注意的是，如果管理员在此之前已经配置防火墙，那么此时需要开放正确的端口访问。
在NSXMGR上，找到Dev-Web-Tier-0613逻辑交换机，在相关选项中可以看到负载均衡器已经被关联。
由于是单臂负载均衡器，管理状态和操作状态均为关闭，这是正常现象。
在负载平衡器界面，可以查看该负载均衡器的详细设置，如虚拟服务器，即定义的VIP。
负载均衡的服务器池以及成员。
外部网络访问该VIP地址，确认已经可达。
通过负载均衡器访问业务；可以看到访问流量被负载均衡到Web-01a和Web-02a。
介绍完逻辑网络和网络功能虚拟化，最后我们再来看看“分布式防火墙”是如何提供OpenStack安全防护的。
=======
V.分布式防火墙-安全组
============
进入项目-网络-安全组，添加新的安全组。
创建一个安全组，如SG-Web-Tenant1。
以此类推，完成SG-App-Tenant1，SG-DB-Tenant1。
SG-Web-Tenant1添加规则，允许任意源入向HTTPS访问。
添加源为Web，TCP8443入向到App的规则。
添加源为App，TCP80入向到DB的规则。
等待安全组完成配置后，需要将实例关联到安全组。
编辑实例，关联到安全组。
将Web-01a关联到安全组SG-Web-Tenant1。
在NSXMGR上可以看到对应的安全组、安全策略。
在NSXMGR的安全组NS清单中，可以查看对应的安全组和关联的成员信息。
由于DB-01a并非是Openstack环境的虚拟机，因此手动添加到SG-DB-Tenant1安全组。
系统会有一条默认Deny any的策略，命名为os_default_section_ns_group，将所有Openstack业务虚拟机全部纳管。
通过五个简单的实例，我向各位演示了OpenStack与NSX DC集成后，管理员在Horizon或者命令行进行配置后，NSX DC如何去响应这些配置，以实现集成的初衷：用户习惯不改变，功能不改变，用NSX DC代替Neutron全部功能。
可以看到，NSX DC将Neutron网络的功能全部替换由自己来承载；因此，不难想象，在NSX DC与容器集成的场景中，逻辑交换机和逻辑路由器将代替容器的NameSpace，来实现云原生网络。
现在，NSX DC如何与vSphere、KVM以及OpenStack集成，相信各位已经有了一定的认识。我们知道NSX DC的几大适用场景中，还有裸机和容器。我会在后续的分享中，与各位共同探讨，敬请关注。
