Half Coffee Blog!
我热爱的一切东西~-
NSX 书单
关于NSX书单
此博客收藏与NSX相关的官方或者非官方设计文档、最佳实践、技术白皮书等资料
文中大部分资料可以在 VMware Community 看到，链接：https://communities.vmware.com/community/vmtn/nsx/content
-
如何使用 NSX python工具箱
什么是 Pynsxv
pynsxc 是 VMware 使用 Python 开发的针对于NSX的工具箱。方便用户通过 Python 脚本来查看或配置 NSX 环境，甚至可以做到 NSX 自动化运维。
项目可以在 Github 上看到：https://github.com/vmware/pynsxv
安装
在上面 Github 地址上的 docs 目录中已经有安装文档，推荐使用 pip (Python包管理器)安装。pip安装方式自行搜索，不同系统不一样，Linux 使用系统自带包管理器就可以安装。MacOS 使用
sudo easy_install pip安装。然后使用 pip 一键安装 pynsxv：
sudo pip install pynsxv安装完成后，第一件事是配置 pynsxv的配置文件。
在Linux下，配置文件路径为：
/usr/lib/python2.7/site-packages/pynsxv/nsx.iniMacOS 下，配置文件：
/Library/Python/2.7/site-packages/pynsxv/nsx.ini根据配置文件的提示设置 NSX manager 和 vcenter 信息。
使用
在官方文档中文档有说明如何使用此工具箱。工具箱功能相对比较简单，可以添加逻辑交换机、DLR、ESG、防火墙策略等。下面举例如何查看及创建 LSW ：
使用
pynsxv lswitch list查看所有逻辑交换机
运行命令
pynsx lswitch create -n python_cli_LS1
等待命令执行完毕后，即可在vCenter中看到新建的逻辑交换机。
-
NSX 6.3 CDO 模式
什么叫 CDO ？
CDO 全称为 Controller Disconnected Operation，中文翻译为控制器断连操作模式。用于解决 Controller Cluster 集群所有节点都宕机时可能带来的VXLAN网络通信故障。一般用于 Cross-VC 环境。
原理
CDO mode 在 Tranport Zone 级别设置，支持 Local Transport Zone 以及 Universal Tranport Zone，如果 Local Tranport Zone 和 Universal Tranport Zone 公用一个 VDS，则 CDO 只会在Universal Tranport Zone 生效。
配置过NSX可能会发现在添加 Logical Switch 时 VNI 是按照设置的 Segment ID（分段ID）自动进行设置的。比如设置 SegmentID 为5000-6000，则第一个创建的 Logical Switch 会使用 VNI 5000；在启动 CDO 模式后，会自动创建一个隐藏的 Logical Switch，会为其设置下一个可用的 VNI。
在启用 CDO 后，所有在这个 Tranport Zone 的主机都会加入创建的 CDO Logical Switch，Controller Cluster 中的某台 Controller 会负责创建一个 Global VTEP List，这个 List 就包含所有在 Tranport Zone 的主机。如果 Controller Cluster 故障，所有主机会将网络中的 BUM（Broadcast，unknown unicast，Multicast）通过 CDO Logical Switch 发给其他所有主机，保证通信正常。
CDO mode 类似于硬件网络中说的软件 Bypass，即软件在检测出自己功能故障导致网络通信中断时，自动放行所有流量，不再通过这些功能来处理流量。
解决的问题
一般来说，Controller Cluster 已经提供了一定的冗余，自身为多节点设计，任意节点的故障不会导致 Controller Cluster 故障。另 NSX 将控制层和数据层分离的机制也保证 Controller Cluster 即使失效，数据层的转发也不受影响。
但是在某些特殊情况下，Controller 集群的故障会带来网络中断，下面看一些场景：
1、在下图场景中，两个虚拟机运行在同一个 Logical Switch 上，运行在同一台主机虚拟机能够正常访问。
-
使用 NSX+SRM 搭建灾备环境
传统DR面临的挑战
当前的灾备系统依然比较复杂，因为灾备包含存储、计算和网络资源，当前的解决方案例如SRM可以完成计算以及存储的恢复，但是网络受限于物理架构，比较难通过SRM实现自动恢复。网络方面具体的问题如下
- 需要在备份站点和主站点建设等同的二层和三层网络架构，维护管理不方便。
- 需要在两个数据中心使用一致的安全策略，使用传统安全解决方案手工配置，管理不方便。
- 在创建安全策略时依赖于IP地址
- 如果主中心和灾备中心建设不一样的网络，在DR时修改虚拟机的IP（IP Re-mapping），则依赖的安全策略都需要进行修改
- 如果要做到主中心和备份中心的计算资源灵活调度，则需要OTV、VPLS等技术实现网络大二层。这样会扩大二层广播域。
DR 场景
- 恢复部分应用
- 恢复一个应用的部分虚拟机，恢复之后要保证其网络正常。
- 恢复整个应用
- 完整恢复一套应用
- 整个站点恢复
- 整个站点，包含 NSX 组件都需要恢复
资源需求
ESXI 和 vCenter
为了确保灾难发生后两个数据中心都可管理，需要分离管理平面，即两个数据中心都有自己的vCenter管理本地的虚拟机。
SRM
SRM依然可以沿用其最佳实践，在使用NSX后，SRM不在需要PortGroup的Mapping，只需要通过NSX创建全局逻辑网络。
Storage Replication
在使用SRM时，Storage Replication是必须用到的，可以使用Array-Based Replication或者vSphere Replication。
如果使用 Array-Based Replication，则需要在SRM上安装SRA（Storage Replication Adapter），让SRM可以与存储阵列通信。
NSX
两个数据中心分别安装自己的NSX manager，关联到本数据中心的vCenter，这时候需要使用Cross-VC NSX解决方案，使用 Universal 逻辑网络。
使用 Cross-VC NSX 时网络有以下特点：
- Cross-VC 可以将二层网络、三层网络以及安全延展到两个数据中心
- Cross-VC 支持 Universal 对象，如：Universal Logical Switch、Universal Distributed Router、Universal DFW等。这些对象在 Primary NSX manager 被创建，可以同步到其他 NSX manager。
- Cross-VC 部署时有一个 Primary NSX manager，其他都是 Secondary NSX Manager。
- Cross-VC 解决方案只能有一个 Universal Controller Cluster，同时控制 Universal 网络和 Local NSX逻辑网络。
- Universal 逻辑网络只能在 Primary NSX manager上进行创建，但是在其他 NSX manager 上可以查看这些配置。
- Cross-VC NSX 支持 Universal DFW 规则，任何在 Universal Section 创建的防火墙规则都可以同步到所有 NSX manager。
- Universal DFW 只支持使用 IP Set、MAC Set、Security Groups（包含 IP Set和 MAC Set）来做防火墙策略
- Universal DLR 在进行 Egress 优化时，需要在两个数据中心分别部署一台 UDLR VM，和本地的 ESG 建立邻居关系。
- 如果 Primary NSX Manager 故障， NSX 网络可以被恢复，配置信息不会丢失
-
NSX 多站点设计1：几种部署方案
为什么有多站点
- DR
- 扩建
- 公司合并
- 多个公司在不同的地方，为本地员工提供服务
- 新旧数据中心迁移
- 公司
传统的多站点解决方案面临的挑战
- 如果进行了业务迁移，需要更改业务 IP 地址
- 需要重新配置业务所需的L2-L3网络
- 安全策略需要在备份站点手动创建/同步，如果应用更改了IP地址，安全策略也需要更改IP
- 其他相关设备也要跟着做改变，例如LB
- ACL、DNS等也要随之更改
传统解决方案
1、使用裸光纤打通二层网络
-
如何测试物理网络 MTU 修改成功
摘要：在进行 NSX VXLAN 配置的时候，先决条件是物理承载网络的二层以及三层 MTU ≥ 1600，否则可能出现数据中心内部访问、外部访问 ping 均正常，但是某些高层业务(例如 web服务)不通的情况，以下介绍下如何在不同平台进行大包 ping 测试
ESXi 之间测试
命令格式：
vmkping ++netstack=vxlan -d -s 1570 Destination-VTEP-IP使用 ESXi 的 vmkping 时，选择 1570 bytes，1570 代表 ICMP 包载荷大小，加上 ICMP 包头 8 bytes，再加上 IP 包头 20 bytes，总 IP 包大小 1598，刚好小于物理网络设置的 1600。实际最大可以发的包为 1572 bytes，1570 只是为了好记忆。
目的地址必须是其他 ESXi 主机的 VTEP VMkernel 地址。
root@esxcomp-02a ~ # vmkping ++netstack=vxlan -d -s 1570 192.168.250.100 PING 192.168.250.100 (192.168.250.100): 1570 data bytes 1578 bytes from 192.168.250.100: icmp_seq=0 ttl=64 time=1.294 ms 1578 bytes from 192.168.250.100: icmp_seq=1 ttl=64 time=0.686 ms 1578 bytes from 192.168.250.100: icmp_seq=2 ttl=64 time=0.758 ms --- 192.168.250.100 ping statistics --- 3 packets transmitted, 3 packets received, 0% packet loss round-trip min/avg/max = 0.686/0.913/1.294 ms root@esxcomp-01a ~ # vmkping ++netstack=vxlan -d -s 1570 192.168.250.101 PING 192.168.250.101 (192.168.250.101): 1570 data bytes 1578 bytes from 192.168.250.101: icmp_seq=0 ttl=64 time=0.065 ms 1578 bytes from 192.168.250.101: icmp_seq=1 ttl=64 time=0.118 ms --- 192.168.250.101 ping statistics --- 2 packets transmitted, 2 packets received, 0% packet loss round-trip min/avg/max = 0.065/0.091/0.118 ms
如果ESXI的VTEP在同一段，vmkping 测试不通过，那一定是物理交换机对应物理接口的MTU未设置好。
如果ESXi的VTEP不在同一网段，vmkping 测试不通过，需要逐段去 vmkping 测试沿途哪台交换机设置有问题(ping VTEP网关的IP地址，以及沿途三层网络互连IP)。
- [Series:4/4]nsx-t powercli script to get loadbalancer infos
- [Series:3/4]nsx-t powercli script to batch create T1 router ports
- [Series:2/4]nsx-t powercli script to batch create logical switches
- [Series:1/4]nsx-t powercli script to batch create firewall rules
- Operationalize Your World 中文版-2
- Operationalize Your World 中文版-1
- vCenter 被 NSX 防火墙阻断后怎么办?
- NSX高阶操作：利用 API 控制管理员可访问范围
- NSX从入门到精通(11)：NSX 微分段的使用场景之云安全
- 如何卸载趋势无代理防病毒