迁移协调器:方法和模式
Migration Coordinator (迁移协调器)是一款完全免费的工具,内置于 NSX Data Center 中,可帮助将NSX for vSphere迁移到 NSX(又名 NSX-T)。Migration Coordinator最初是在 NSX-T 2.4 中引入的,有几种实现迁移的模式。通过多年来与客户的交流,我们不断扩展Migration Coordinator的功能。如今,Migration Coordinator 支持 10 多种不同的方式将NSX for vSphere迁移到 NSX。
在本系列博客中,我们将介绍可用的迁移方法以及每种方法所涉及的准备工作。本系列博客将从多个不同角度帮助您选择将NSX for vSphere迁移到 NSX 的正确模式。
- 3 个标准迁移模式
- 3个高级迁移模式
- 3 个用户自定义拓扑结构下的模式
- 最后,NSX Global Manager UI上还提供了 2 种专用于Cross-VC 到 Federation的模式
这些模式中,有些采用的是"cookie-cutter"方法,只需很少的准备工作即可完成迁移,而有些则允许你根据自己的需求自定义迁移。在本篇博客中,我们将对这些模式进行深入探讨。
迁移协调器的方法
在高层级上,迁移协调器支持两种迁移方法。
1. 就地迁移(In-Place)
2. 提升和转移迁徙(Lift and Shift)
就地迁移(In-Place Migration)
就地迁移模式使用针对 vSphere的NSX 运行相同的硬件,从 NSX for vSphere迁移到 NSX。在这种迁移模式下,不需要引入新硬件。如果有足够的容量运行所需的 NSX 基础架构(如 NSX managers、edges等),就可以使用迁移协调器。
配置迁移(Config migration)
这些模式通常会迁移所有内容、配置和工作负载。但 "分布式防火墙、主机和工作负载模式 "是个例外,因为客户只想迁移分布式防火墙相关配置,而不想迁移整个配置。
工作负载迁移(Workload migration)
在就地迁移模式中,迁移协调器负责将工作负载从 NSX for vSphere迁移到 NSX。工作负载迁移不需要单独的工具或方法。这些模式还支持一种内置机制,允许 NSX for vSphere上的工作负载在迁移过程中与 NSX 上的工作负载对话。这种模式不需要在两个环境(NSX for vSphere 和 NSX)之间创建任何桥接。
桥接(Bridging)
部署规模较小的客户可以在一个维护窗口内完成所有迁移。对于部署规模较大的客户,由于工作负载分布在 NSX for vSphere 和 NSX 上,迁移可能需要较长的时间。迁移协调器的就地迁移模式允许工作负载相互通信,并且没有任何网络连接性和安全性的丢失。
在这些模式下,迁移协调器可以完全控制实际工作负载迁移的时间。虽然许多客户都采用了这种方法,但一些需要处理多个租户的客户可能更希望对工作负载的迁移时间进行精细控制。对于此类用例,请查看迁移、提升和转移的第二种高级方法。
提升和转移迁移(Lift and Shift)
提升和转移迁移模式可将一组硬件上的 NSX for vSphere 迁移到新的 NSX 实例上,该实例安装在完全不同的一组硬件上,这些硬件可能是新的,也可能是从 NSX for vSphere 重新利用的。正处于硬件刷新周期的用户或希望对每个工作负载的迁移时间以及北向连接和设计进行细粒度控制的用户通常会选择这些模式。
配置迁移(Configuration migration)
这些模式迁移 T0s 和 NSX 实体(如 T0s 南部的 DFW 规则)的配置。用户应在利用迁移协调器运行迁移之前,提前准备好NSX的北向配置,如BGP连接等。
工作负载迁移(Workload migration)
在这些模式下,Migration Coordinator不会迁移工作负载。在所有这些模式中,都可以使用vMotion来迁移工作负载。 在本博客稍后讨论一种特殊模式, "用户自定义拓扑 :配置和边缘迁移模式 "中,用户可以选择使用 vMotion 或 HCX。
桥接(Bridging)
在提升和转移模式中,可能需要使用 NSX 桥接器或 HCX 设置桥接器,以确保迁移期间网络连接不会中断。这取决于迁移的持续时间。
迁移模式(Migration Modes)
下面介绍了迁移协调器在以下两种高级方法下提供的迁移模式:(1) 就地迁移;(2) 提升和转移迁移。
就地迁移模式
1. NSX for vSphere: 固定拓扑
2.NSX for vSphere with vRealize Auto-mation:与第一种模式 "NSX for vSphere: 固定拓扑"类似,但采用与 vRA 同步的方法。
3.分布式防火墙、主机和工作负载
4.NSX for vSphere: 用户自定义拓扑 - 完全迁移
5.NSX Global Manager: 用户自定义拓扑 - 完全迁移
提升和转移模式
1. 分布式防火墙
2. NSX for vSphere:用户定义拓扑 - 配置迁移
3. NSX for vSphere:用户定义拓扑 - 配置迁移和边缘迁移
4. NSX Global Manager:用户定义拓扑 - 配置迁移
本文作者:Samuel Kommu, Vmware网络安全部门
内容来源|公众号:VMware 中国研发中心
有任何疑问,欢迎扫描下方公众号联系我们哦~

低调大师中文资讯倾力打造互联网数据资讯、行业资源、电子商务、移动互联网、网络营销平台。
持续更新报道IT业界、互联网、市场资讯、驱动更新,是最及时权威的产业资讯及硬件资讯报道平台。
转载内容版权归作者及来源网站所有,本站原创内容转载请注明来源。
- 上一篇
OceanBase 4.1.0 clog 目录探究
基于OceanBase 4.x 版本如何统计租户每日 clog 日志生成量的背景下,探究以及如何查看租户 clog 的使用情况。 作者:姜宇 爱可生 DBA 团队成员,擅长数据库故障排查和处理。对技术抱有热忱,实践是检验真理的唯一标准~ 本文来源:原创投稿 爱可生开源社区出品,原创内容未经授权不得随意使用,转载请联系小编并注明来源。 作者:姜宇,爱可生 DBA 团队成员,擅长数据库故障排查和处理。对技术抱有热忱,实践是检验真理的唯一标准~ 我们知道 clog 目录是存放 OceanBase 数据库记录修改操作的物理日志目录。目录具体的物理存放位置为 /data/log1/clustername/clog。比如,集群 ACTION_OB 的 clog 目录如下图所示: OceanBase 4.1.0 版本采用了租户级别的日志流,将物理的变更记录聚合成了组织良好的若干日志流:一个系统日志流和多个用户日志流。系统的所有物理变更信息被记录在这些日志流中,故障恢复、日志归档、备库同步等均使用一套物理变更信息。在一个租户内,一个日志流允许有多个副本,多个副本之间基于 Paxos 协议同步数据。 O...
- 下一篇
实录:利用OpenNJet实现动态upstream域名解析
场景 在使用NGINX做负载均衡进行反向代理的场景中,使用upstream 管理一组有效的上游服务器地址。 地址可以包含两类:server ip 和server name。 其中server name在nginx 启动时,必须统一解析为server ip,在整个运行过程中,upstream 中只包含解析后的server ip,并且数量,以及ip 是不会改变的,即使dns 服务器上相应的server name 对应的ip 地址列表,已经进行了更新,删除,添加。Nginx 也不会进行动态更新,如果要更新,只能重新reload nginx。 启动nginx 前: upstream backend { server backend1.example.com; server 127.0.0.1:888; } 启动nginx 后: upstream backend { server 192.168.40.139; server 127.0.0.1:888; } 问题 运行过程中,如果域名对应的某个IP的机器或服务出现故障,无法进行动态隔离,必须修改 DNS服务器上Server ...
相关文章
文章评论
共有0条评论来说两句吧...
文章二维码
点击排行
推荐阅读
最新文章
- CentOS7安装Docker,走上虚拟化容器引擎之路
- SpringBoot2编写第一个Controller,响应你的http请求并返回结果
- CentOS关闭SELinux安全模块
- CentOS7,CentOS8安装Elasticsearch6.8.6
- Jdk安装(Linux,MacOS,Windows),包含三大操作系统的最全安装
- Linux系统CentOS6、CentOS7手动修改IP地址
- Windows10,CentOS7,CentOS8安装MongoDB4.0.16
- CentOS8安装Docker,最新的服务器搭配容器使用
- Docker快速安装Oracle11G,搭建oracle11g学习环境
- SpringBoot2配置默认Tomcat设置,开启更多高级功能