变形金刚外传0x03:进一步讨论NSX-T的传输节点就绪

简介: 话接上篇,对于NSX-T来说,由于传输节点配置文件将传输区域与主机交换机进行了严格意义上的绑定,因此不会出现在NSX-V场景中传输区域与分布式交换机覆盖不一致的情况。

在创建传输区域和配置传输节点配置文件的时候,管理员需要对Overlay流量和VLAN流量分别创建对应的传输区域和主机交换机;如下图所示:

image.png

image.png

由于传输区域与主机交换机有绑定关系,一般来说,Overlay流量的主机交换机和VLAN流量的主机交换机是区分开的。在配置Edge传输节点的时候,管理员需要将Edge传输节点同时关联到Overlay传输区域和VLAN传输区域,以实现逻辑网络与数据中心物理网络的互通。由于两个传输区域分别有自己独立的主机交换机,Edge节点至少会有三种不同的流量:

  • Overlay流量,逻辑网络
  • VLAN流量,物理网络
  • 管理流量,物理网络

我们先不考虑以ESXi承载虚拟机版本Edge节点那种方式,假定用户采用一台物理机作为Edge节点,需要多少网络适配器,才能在满足业务需求的基础上,提供冗余高可用呢?

  • Edge节点本身用于和NSXMGR通信的管理网络,由于不涉及业务生产,考虑用1块千兆网络适配器承载;
  • 承载Overlay流量和VLAN流量业务的主机交换机共有2台,考虑冗余,至少需要4块vmnic,并且基于业务带宽的需要,至少万兆以上。

综上所示,理想情况下,至少需要2块双口万兆网络适配器+1块千兆网络适配器才能同时满足业务的性能要求与高可用标准。

在实际项目中,如果用户出于预算的考量或者利旧服务器,只能满足1块双口万兆网络适配器的时候,这台服务器还能满足Edge节点的业务需求么?

有人说,当然可以!既然是双口万兆网络适配器,其中一个万兆口用于承载VLAN主机交换机的流量,另一个万兆口用于承载Overlay主机交换机的流量不就解决问题了么?

不可否认,这是一种可行的方案,代价是Overlay或者VLAN都存在单点故障的风险。而且,由于Edge节点的角色特征,导致了无论是Overlay还是VLAN流量出现中断,总体的业务都会受到严重的影响。

因此,上面的方案可以用于PoC或者项目演示,但无法满足生产业务的需求。我们需要一个B方案:用1台主机交换机,同时承载Overlay和VLAN流量,这样可以同时保证2个传输区域的高可用


0x03:公用主机交换机的传输节点配置文件创建

===============================

  • 访问NSXMGR,在系统-结构层-传输区域页面,添加新的传输区域

image.png

  • 添加一个Overlay传输区域,命名为Global-Overlay-TZ,N-VDS命名为Production-Overlay-N-VDS,流量类型为覆盖网络
    注:Global-Overlay-TZ与Global-VLAN-TZ将共用一个N-VDS

image.png

image.png

  • 添加一个VLAN传输区域,命名为Global-VLAN-TZ,N-VDS命名同样为Production-Overlay-N-VDS,流量类型为VLAN
    在上一篇,我提到了传输区域会与主机交换机有绑定关系,但并没说明这种关系具有1:1的强制绑定

image.png

image.png

  • 进入传输节点配置文件,添加新的配置文件

image.png

  • 命名配置文件为Global-Overlay_VLAN-TZ-Profile,同时关联两个传输区域

image.png

  • 定义一个新的IP地址池,命名为Global-VTEP-Pool
    地址为172.18.11.51/24-172.18.11.56/24

image.png

  • 为传输节点配置文件关联N-VDS,设置双网卡上联
    可以看到,虽然只有一个主机交换机Production-Overlay-N-VDS,但是可以承载包括Global-Overlay-TZ和Global-VLAN-TZ两个不同的传输区域流量

image.png

  • 等待传输区域文件添加完成

image.png

这种配置方式不仅适用于Edge节点,对于主机传输节点,如果网络适配器的数量不足以满足“物理隔离Overlay流量和VLAN流量的同时,提供高可用冗余”,可以选择用一台公用的主机交换机同时承载两个传输区域的流量负载。(这种情况往往用于承载虚拟机版本的Edge主机场景)

话到这里,请各位思考一个问题,如果所有的ESXi和KVM主机都是部署在一台ESXi服务器上的虚拟机,现在需要在虚拟机版本的ESXi上再部署若干虚拟机版本的Edge节点,网络环境又需要如何准备?这个答案我会在Edge节点准备和逻辑路由章节揭晓。


在我之前的几篇分享“NSX分布式防火墙是如何工作的?”“NSX控制平面和静态路由更新流程1”“NSX控制平面和静态路由更新流程2”中,我介绍了NSX-V的三层架构。那么在NSX-T环境中,三层架构具体又有哪些变化呢?

首先,NSX-T的架构中,vCenter已经从必要的组件成为只针对vSphere环境的计算管理器,不再作为管理平面组件出现;这一点在上一篇分享中已经有比较详细的演示了。在NSX-V环境中,NSXMGR借助于VC的EAM,会在ESXi内核中安装VIB,并运行包括vsip、vdl2和vdrb等模块。在NSX-T环境中,NSXMGR同样会在传输节点内核中安装若干模块,请看下文我的演示:

  • 对于没有进行过“配置NSX”的普通ESXi主机,内核中不会运行NSX相关的模块

image.png

  • 对于进行过“配置NSX”的主机节点,内核中运行了NSX相关的诸多模块;可以看到,在数量上要远远大于NSX-V环境中的ESXi主机

image.png

  • NSX会在主机传输节点内核中安装各类NSX VIB,而不是NSX-V环境中的一个

image.png

  • 与NSX-V相同,在NSX-T传输节点的用户空间,运行着消息总线代理MPA,它依旧作为管理平面的组件存在,但是功能更趋向于传输节点运行状态的收集;与NSX-V的MPA(vswfd)相同,它与NSXMGR保持着TCP5671的长连接;
  • 不过笔者并没有充足的物理环境支撑部署3台NSXMGR,以群集模式验证传输节点与NSXMGR的长连接状态:
    究竟是主机节点同时与所有三台NSXMGR建立TCP5671连接;还是单独与其中的某一台NSXMGR建立连接?不知道是否有大拿做过类似的验证,晓冬恳请分享。

image.png

  • 由于NSXMGR和NSXCTRL合二为一,可以看到传输节点除了与NSXMGR的TCP5671保持长连接,也与TCP1235保持长连接
  • 这里面有两个变化,在NSX-V的环境中,ESXi用户空间运行的控制平面组件netcpad与所有NSXCTRL的TCP1234保持着长连接,在NSX-T中,这个端口变更成了TCP1235;同时由于NSXCTRL的角色合并到NSXMGR,在传输节点上只能看到与NSXMGR的两条长连接信息

image.png

image.png

一般来说,在NSX-T的架构中,称呼在传输节点用户空间运行的控制平面组件为LCP,在NSXMGR上运行的控制平面组件为CCP。

在NSX-T2.3版本以前,由于NSXMGR和NSXCTRL是独立的组件,因此架构简图如下:

image.png

而到了NSX-T2.4版本,由于管理平面与控制平面的合二为一,架构发生了比较大的变化:

image.png

在完成了主机传输节点的就绪工作后,管理员可以创建逻辑交换机实现跨Hypervisor的虚拟机二层通信。在下篇的分享中,我将演示如何创建逻辑交换网络,实现ESXi主机与KVM主机上运行的虚拟机二层互通;并且将演示在配置KVM环境中需要注意的若干事项。

相关文章
|
安全 测试技术 网络安全
NSX分布式防火墙是如何工作的?
今天我们来聊一聊VMware NSX的分布式防火墙DFW,本文提及的NSX,均指NSX for vSphere,即NSX-V,有关NSX-T的讨论,将在后续推出。
NSX分布式防火墙是如何工作的?
|
SDN 网络虚拟化 虚拟化
NSX干货分享·Edge传输节点和路由
笔者最近持续跟进了一个客户的NSX-T数据中心实施项目。对于用户来说,这个项目最难的地方就是实现业务网络从传统拓扑“渐进式”过渡到NSX逻辑网络。我们知道,VMware NSX-T是一款纯软件方式实现SDN架构的产品,其带给用户网络的灵活性体现在能够满足在网络拓扑中同时存在SDN拓扑和传统拓扑的需求。
|
安全 Ubuntu KVM
变形金刚外传0x02:从V的主机准备到T的传输节点就绪
本篇我们继续来闲谈VMware出品的“变形金刚”。 最近在和关注公众号的朋友交流过程中,发现不少朋友都有一些疑惑: 想要学习NSX DC,有什么推荐的参考书么? 想要学习NSX-T,是否一定要有NSX-V的基础? 想要自己动手搞一搞NSX,服务器需要多少资源?
|
存储 网络协议 虚拟化
一步步实现SDDC--学习平台环境的搭建(1)
新年伊始,晓冬将分享如何一步步搭建一个超迷你但又完整的VMware软件定义的数据中心。
一步步实现SDDC--学习平台环境的搭建(1)
|
消息中间件 存储 缓存
RocketMQ 监控告警:生产环境如何快速通过监控预警发现堆积、收发失败等问题?
本文主要向大家介绍如何利用 RocketMQ 可观测体系中的指标监控,对生产环境中典型场景:消息堆积、消息收发失败等场景配置合理的监控预警,快速发现问题,定位问题。
1852 0
RocketMQ 监控告警:生产环境如何快速通过监控预警发现堆积、收发失败等问题?
|
算法 计算机视觉
OpenCV对图像进行Otsu二值分割、Canny边缘检测、Harris角点检测实战(附源码)
OpenCV对图像进行Otsu二值分割、Canny边缘检测、Harris角点检测实战(附源码)
237 0
|
运维 监控 物联网
快速开发光伏电站数字孪生运维系统(二)
简介: 本文重点介绍如何从零开始构建出光伏电站数字孪生系统的详细步骤。
15441 0
快速开发光伏电站数字孪生运维系统(二)
|
存储 SQL JSON
一种关于低代码平台(LCDP)建设实践与设计思路
作者在负责菜鸟商业中心CRM系统开发过程中发现有一个痛点:业务线很多,每个业务线对同一个页面都有个性化布局和不同的字段需求,而他所在的团队就3个人,那么在资源有限的情况下该如何支撑呢?本文就降本的情况下,和大家分享下作者是如何低成本构建产品能力去支撑多条业务线、多租户的。
一种关于低代码平台(LCDP)建设实践与设计思路
|
Linux 开发工具
centos中vim中文乱码问题
centos中vim中文乱码问题
512 0
centos中vim中文乱码问题
|
搜索推荐 索引
[ELK实战] Elasticsearch 聚合查询二: Bucketing/桶聚合
目前在[官方文档]有4种聚合(Aggregations )方式分别是: 1. Metric (指标聚合): 最常用的聚合方式例如 平均值,求和等等 3. Bucketing (桶聚合): 就是常说的分组聚合 5. Matrix (矩阵聚合) : 在多个字段上操作并根据从请求的文档字段提取的值生成矩阵结果的聚合族。与度量聚合和桶聚合不同,此聚合族尚不支持脚本。 7. Pipeline (管道聚合
373 0
[ELK实战] Elasticsearch 聚合查询二: Bucketing/桶聚合