管理与控制服务器部署

说起Federation架构的问世，早在NSX-T3.0版本的时候就有“苗头”了。我们一直说NSX-T的架构是由“管理平面MP”、“控制平面CP”和“数据平面DP”组成的。在NSX-T2.4版本之后，作为中央控制平面CCP的NSX-T Controller角色和NSX-T Manager角色合并。意味着在NSX-T Manager服务器内核中，同时具有“Manager Server”和“Controller Server”两种角色。但是在后来的官方教材中，不少朋友也发现有了一个新的角色叫“Policy Server”。相对应的，NSX-T的管理界面也出现了“管理器”和“策略器”两种不同的UI。上述这些，其实都是Federation诞生的“苗头”。

上一篇分享“联盟时代I. 为什么需要Federation联盟”中，笔者简单介绍了Federation架构（F模型）。在自己的Homelab中，笔者也完成了Federation演示环境的部署工作。因此，今天的分享会有三个主题：

🌸 NSX-T Federation架构下，管理与控制平面组件概述

🌸 Homelab的准备工作

🌸 Federation架构下，管理与控制平面的部署流程

—

Federation的管理与控制平面组件概述

回到笔者定义的“F模型”本身，我们看到其管理与控制平面包含了Global Manager全局管理器和Local Manager本地管理器两种角色。

🌸 先来说说Global Manager

为了便于叙述，后文中所有的NSX-T Global Manager缩写为GM，NSX-T Local Manager缩写为LM。GM通常会有两组，每一组GM集群都可以由3台GM服务器组成。如下图所示：在Primary数据中心，管理员可以部署3台GM服务器组成集群，并且定义一个VIP，作为统一的接口提供给管理员UI访问或者通过RestAPI与云管理平台对接。从高可用性来说，3台GM服务器中如果有1台出现了故障，其余2台能继续提供Policy Server的相关服务。而在Secondary数据中心，管理员可以再部署3台GM服务器组成集群，同样定义一个VIP。两个集群以Active-Standby的主备模式，共同承载下属LM的Policy Server角色。当故障发生的时候，Standby的GM集群可以接管角色功能，提供数据中心级的管理功能连续性。并且“完美”规避了T模型存在的几个“悖论”。

这种3+3的Active-Standby模式，结合vSphere HA的可用特性以及虚拟机与服务器的关联或者虚拟机与虚拟机的反关联规则，已经能最大程度地覆盖虚拟机（服务器）级、宿主机级、群集级等各类灾备场景。但是笔者还是要强调一点，GM集群的数据备份依旧很重要。做好备份，当灾难来临时，才能直击面对，成为流传的故事；没有备份，当灾难来临时，难免焦头烂额，沦为议论的事故。

🌸 再来说说Local Manager

虽然从上图看，似乎只有2个LM服务器集群。但实际上，Federation最多支持8个站点。

这说明不局限于上图中的两个数据中心，对于多数据中心、多分支站点，NSX-T Federation都是适用的。管理员会在每一个站点部署3台NSX-T LM组成一个集群，用于“承上启下”。所谓“承上”，是指LM作为Manager Server角色，接收来自GM的策略和配置，比如“定义一个全局的延伸分段”“定义一个延伸的Tier0网关”等等。所谓“启下”，就是它依旧作为站点内所有传输节点的集中管理平面，用于管理包括ESXi宿主机、KVM宿主机、Edge传输节点等数据平面相关的组件。当然，有一些配置，是必须由LM去定义和配置的，比如“本站点Edge传输节点的注册”、“虚拟机Edge传输节点的部署”这类操作。

对于3台NSX-T LM服务器组成的集群来说，站点管控平面的高可用性依赖于本身的3节点冗余以及vSphere HA、虚拟机-宿主机关联规则等带来的补充。其可恢复性同样依赖于日常备份与还原。A站点的LM不会和其他站点的LM进行交互。对于只负责自身站点的管理员来说，也不需要拥有GM的超级管理员权限，日常访问LM也能实现基本的维护与操作了。

—

Federation Homelab准备工作

Federation Homelab对于服务器硬件资源是有要求的。从基础架构服务器的层面来说，至少需要1台域控制器（同时作为DNS服务器和NTP服务我），2台vCenter服务器（以链接模式部署），4台NSX-T Manager服务器（2台GM和2台LM），以及至少4台Edge传输节点。因此建议至少3台ESXi宿主机，其中1台作为专门的管理服务器使用，用于安装上述所说的这类基础架构服务器，2台分别作为不同数据中心的计算服务器使用。

在笔者的Homelab环境中，像vCenter、NSX-T Manager这些虚拟机由团队服务器承载，另外6台服务器以3+3的形式作为计算服务器来使用。

下面将笔者环境中的服务器和网络地址段划分与各位分享：

🐈对于vSphere环境来说，包含2台vCenter服务器和6台ESXi服务器。建议vCenter采用中等以上规模部署，且管理网络应该L3划分，以完全模拟数据中心实际的网络情况。

🐕对于NSX环境来说，主要是2台GM、2台LM以及4台Edge传输节点。建议NSX-T组件以中等以上规模部署，Edge传输节点根据实际情况来调整。

这里需要注意2点：

第一点，Edge传输节点除了管理地址以外，还会使用到2个不同的IP，分别用于承载本地的Overlay TEP封装，以及跨区域的RTEP封装。

第二点，可以看到笔者的GM和LM分别都只有1台NSX-T服务器，并未部署集群模式。这当然是因为硬件资源的限制。但即便如此，LM也需要2个管理IP，其中1个作为单节点组成集群VIP地址来使用。下方是官网对于这个情况的说明：

🐈接下来是非常重要的Underlay，也就是TEP用到的IP地址信息：

可以看到每1台传输节点（包括主机传输节点和Edge传输节点）都至少需要1个IP用于TEP封装，且建议是不同的地址段。同时针对Edge传输节点，还需要有额外的1个IP地址，用于跨区域的L2流量封装，且该IP地址（VLAN）必须与TEP为不同的地址段。

🐕最后再来看看总体的IP地址段规划：

为了简化，大家可以将所有的基础架构服务器按照区域的划分，归纳为1个地址段。每个区域额外的3个地址段，用于该区域的Overlay封装使用。特别注意的是，管理服务器使用的网络，其MTU保持默认的1500即可。但作为Underlay网络来说，本地TEP地址段需要满足MTU1600，跨数据中心的Underlay网络来说，远端RTEP地址段需要满足MTU1700以上。为了确保“一劳永逸”，大家完全可以将MTU设置为9000以上。