NSX-T 3.0 多站点vs 联合
介绍
在我使用NSX-V 的经验中，部署最多的功能之一是Cross vCenter NSX，它允许多站点部署。
为了降低许可成本和自动故障转移，您可以部署拉伸集，因此只需要单个vCenter 和NSX 许可证，但需要扩展网络的成本和潜在的扩展存储成本，除非当然使用DR 恢复解决方案（如SRM）来故障转移vCenter 和NSX 管理器。
直到现在，阻止许多客户部署NSX-T 的，是缺乏功能齐全的Cross 站点部署。
NSX-T Multisite 已经存在了一段时间，被一些人采用，但它遵循拉伸集模型或需要在DC 2 站点上手动备份恢
复NSX Manager，因此这有一些限制，也就是说，直到NSX-T 3.0，我们现在有NSX-T 联盟，这是一
个游戏规则的改变者，因此没有什么能阻止客户迁移到NSX-T。
NSX-T 多站点
NSX-T Multisite 仍然是NSX-T 3.0 的有效部署选项，据我了解，它只需要高级许可证，因此它比进行联合构建更便宜，但是由于多站点的运行过程，它确实存在限制。
NSX-T 数据中心支持多站点部署，您可以在其中从一个NSX 管理器集管理所有站点。支持两种类型的多站点部署：
灾难恢复
主动-主动
下图显示了灾难恢复部署。
在灾难恢复部署中，主站点的NSX-T 负责企业网络。如果主站点发生灾难性故障，辅助站点将处于一个支持的位置。
所有通过主站点的流量出口。
下图显示了主动-主动部署。
在活动-主动部署中，所有站点都处于活动状态，第2 层流量跨越站点边界。每个站点都配置了第0 层，第1 层网关VM 连接到主站点第1 层网关，并且仅从主站点出口，或者它们连接到辅助站点第1 层网关，并且仅从辅助站点出口。
在这两种情况下，系统都可以以两种不同的方式进行配置，一种允许管理和数据平面的自动故障转移，另一种需要手动/脚本化的故障转移。
自动故障转移管理平面
若要允许管理平面的自动故障转移，必须按以下要求配置系统
：
跨配置站点的带HA 的拉伸vCenter 集。
拉伸管理VLAN。
NSX Manager 集部署在管理VLAN 上，并且物理上位于主站点中，主站点中也有一个用于管理的vCenter 服务器。
如果存在主站点故障，vSphere HA 将重新启动辅助站点中的NSX 管理器和vCenter 服务器。
所有传输节点将自动重新连接到重新启动的NSX 管理器。这大约需要10 分钟，在此期间，管理平面不可用，但数据平面不会受到影响。
下图显示了管理平面的自动恢复。
自动故障转移数据平面
要允许数据平面的自动故障转移，必须按以下要求配置系统
：
边缘节点之间的最大延迟为 10 ms 。  第 0 层网关的 HA 模式必须是主动待机，故障转移模式必须是抢占。 注意：第 1 层网关的故障转移模式可以是先发制人或非抢占模式。
大多数配置是通过 API 完成的，包括创建失败域，该边缘集跨站点拉伸，以便集在主站点中具有边缘节点EdgeNode1A 和EdgeNode1B ，在辅助站点中具有边缘节点 EdgeNode2A 和EdgeNode2B 。
活动的第 0 层和第 1 层网关将在EdgeNode1A 和 EdgeNode1B 上运行。
备用第 0 层和第 1 层网关将在EdgeNode2A 和EdgeNode 2B 上运行。
然后，每个边缘 nand 后续边缘集将关联到相关的失败域。
最后，通过 API 或 UI 部署第 0 层和第 1 层网关。
下图显示了数据平面的自动恢复。
本田nsx-r
由于 T0 和 T1 网关配置为"活动/待机"模式，因此在主站点故障期间自动故障转移。
手动/脚本故障转移管理平面
若要允许手动/脚本化管理平面的故障转移，必须按以下要求配置系统
：
具有短 TTL 的 NSX 经理的 DNS （例如，5 分钟）。  连续备份。 vSphere HA 或拉伸管理 VLAN 不是必需的。
每个站点都有自己的管理 vCenter 服务器，这些 vCenter 将作为计算管理器添加到 NSX-T
NSX-T 管理器中，这些服务器必须与具有短 TTL 的 DNS 名称关联。
所有传输节点（边缘节点和虚拟机管理程序）必须使用其 DNS 名称连接到 NSX 管理器。为了节省时间，您可以选择在辅助站点中预安装 NSX 管理器集。
恢复步骤包括：
1. 更改 DNS 记录，使 NSX 管理器集具有不同的 IP 地址。
2. 从备份还原 NSX 管理器集。
3. 将传输节点连接到新的 NSX 管理器集。
下图显示了管理平面的手动/脚本恢复。