联盟时代II.管理与控制服务器部署

简介: 话接上回,说起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的管理界面也出现了“管理器”和“策略器”两种

     上一篇分享联盟时代I. 为什么需要Federation联盟”中,笔者简单介绍了Federation架构(F模型)。在自己的Homelab中,笔者也完成了Federation演示环境的部署工作。因此,今天的分享会有三个主题:🌸 NSX-T Federation架构下,管理与控制平面组件概述🌸 Homelab的准备工作🌸 Federation架构下,管理与控制平面的部署流程

01

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也能实现基本的维护与操作了。

02

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以上。

接下来,笔者将“晒出”具体的配置步骤,提供各位参考。


03x01

Federation 管理服务器部署之第一台GM

  • 通过OVA部署NSX-T Global Manager。

  • 在资源充分的情况下,建议以中型以上规模部署。

  • 定义管理员账号与密码等信息。

  • 义网络配置。

  • 等待第一台Global Manager部署完成。

  • 访问第一台Global Manager UI界面。

  • 将这台Global Manger设置为“活动”。


03x02

Federation 管理服务器部署之第二台GM

  • 部署第二台Global Manager。


  • 接下来是几种不同情况的后续操作:

对于采用群集方式部署的情况,应该使用cluster命令。# get certificate cluster thumbprint对于采用单点方式部署的情况,应该使用api命令。# get certificate api thumbprint

  • 同时,也可以通过vCenter命令行来获取信息:

# echo -n | openssl s_client -connect gnsxmgr-02.homelab.local:443 2>/dev/null | openssl x509 -noout -fingerprint -sha256

  • 最后添加备份全局管理器。

  • 完成所有GM的部署操作后,在管理员界面可以清楚地看到所有的“全局管理器”状态。

至此,所有的GM组件部署完毕。需要注意的是,对于需要部署3台GM服务器组成集群的情况,管理员需要在GM管理页面添加vCenter作为计算管理器。


03x03

Federation 管理服务器部署之LM服务器

  • Local Manager的导入与Global Manager没有太大的差别;
    通过OVA导入的方式部署服务器。

  • 获取指纹信息。

即便只有一台Local Manager节点,同样需要为他分配一个虚拟IP;同时采用群集指纹获取命令抓取指纹。# get certificate cluster thumbprint

  • Global Manager添加新位置。

  • 采用Local Manager集群的VIP作为IP地址进行添加。

注:部署NSX Federation需要企业增强版授权(截止2022.05发布本分享

  • 完成Local Manager的添加操作后,可以在面板清晰地看到这些更新;
    常情况下,添加至少两个数据中心站点。

至此,Federation相关的GM与LM服务器部署就全部完成了。当然,与3台GM服务器组成集群相同,对于需要采用3节点部署的LM服务器集群来说,管理员同样需要添加vCenter作为计算管理器,来对NSX-T部署其他节点提供充足的硬件资源。


最后做个简单的总结吧:Federation的问世既然能完美规避NSX-T Multi-Site架构存在的“悖论”以及管控平面面临的高可用性缺失问题,那么从架构层面来说,F模型和T模型一定是存在差异的。可能有人会觉得Global Manager和Local Manager的两级管控平面略显复杂,但笔者认为无论是从逻辑清晰角度来看,还是功能加强角度来看,都是进步和必要的。同时,无论是Federation的网络地址规划,还是Federation管控平面的部署,都有一些需要特别注意的点(比如RTEP的MTU1700,以及即使单节点LM同样需要VIP的设置)。实际上,在后续对跨站点的延伸分段、延伸Tier0网关等组件的配置中,也存在一些需要特别注意地方,这与之前Multi-Site或者Single-Site场景的实现都有着显著的区别。当然,上文提到的这些问题,笔者也会在后续的连载中继续为大家讲解和说明,敬请持续关注。

相关文章
|
1月前
|
弹性计算 监控 负载均衡
|
2月前
|
监控 安全 Linux
RHEL 环境下 Subversion 服务器部署与配置
【10月更文挑战第18天】在RHEL环境下部署Subversion服务器需依次完成安装Subversion、创建版本库、配置服务器、启动服务、客户端连接及备份维护等步骤。确保遵循安全最佳实践,保障数据安全。
119 1
|
2月前
|
Prometheus Kubernetes 监控
k8s部署针对外部服务器的prometheus服务
通过上述步骤,您不仅成功地在Kubernetes集群内部署了Prometheus,还实现了对集群外服务器的有效监控。理解并实施网络配置是关键,确保监控数据的准确无误传输。随着监控需求的增长,您还可以进一步探索Prometheus生态中的其他组件,如Alertmanager、Grafana等,以构建完整的监控与报警体系。
141 60
|
2月前
|
Prometheus Kubernetes 监控
k8s部署针对外部服务器的prometheus服务
通过上述步骤,您不仅成功地在Kubernetes集群内部署了Prometheus,还实现了对集群外服务器的有效监控。理解并实施网络配置是关键,确保监控数据的准确无误传输。随着监控需求的增长,您还可以进一步探索Prometheus生态中的其他组件,如Alertmanager、Grafana等,以构建完整的监控与报警体系。
271 62
|
1月前
|
弹性计算 开发工具 git
2分钟在阿里云ECS控制台部署个人应用(图文示例)
作为一名程序员,我在部署托管于Github/Gitee的代码到阿里云ECS服务器时,经常遇到繁琐的手动配置问题。近期,阿里云ECS控制台推出了一键构建部署功能,简化了这一过程,支持Gitee和GitHub仓库,自动处理git、docker等安装配置,无需手动登录服务器执行命令,大大提升了部署效率。本文将详细介绍该功能的使用方法和适用场景。
2分钟在阿里云ECS控制台部署个人应用(图文示例)
|
1月前
|
NoSQL 容灾 MongoDB
MongoDB主备副本集方案:两台服务器使用非对称部署的方式实现高可用与容灾备份
在资源受限的情况下,为了实现MongoDB的高可用性,本文探讨了两种在两台服务器上部署MongoDB的方案。方案一是通过主备身份轮换,即一台服务器作为主节点,另一台同时部署备节点和仲裁节点;方案二是利用`priority`设置实现自动主备切换。两者相比,方案二自动化程度更高,适合追求快速故障恢复的场景,而方案一则提供了更多的手动控制选项。文章最后对比了这两种方案与标准三节点副本集的优缺点,指出三节点方案在高可用性和数据一致性方面表现更佳。
|
1月前
|
PHP 数据库 数据安全/隐私保护
布谷直播源码部署服务器关于数据库配置的详细说明
布谷直播系统源码搭建部署时数据库配置明细!
|
2月前
|
关系型数据库 MySQL Linux
基于阿里云服务器Linux系统安装Docker完整图文教程(附部署开源项目)
基于阿里云服务器Linux系统安装Docker完整图文教程(附部署开源项目)
469 3
|
2月前
|
NoSQL Linux PHP
|
2月前
|
弹性计算 数据库连接 Nacos
阿里云ECS服务器在docker中部署nacos
docker pull nacos 失败,docker部署nacos遇到的问题,nacos数据库连接,nacos端口映射
193 1