迁移 NSX-V 到 NSX-T: Lift & Shift - 2 部署 Edge Bridge 并迁移
继续介绍如何使用 Lift & Shift + Edge 桥接的方式来迁移现存的 NSX-V 环境到 NSX-T. 这部分将准备新的 NSX-T Edge 集群将 NSX-V 和 NSX-T 的逻辑网段进行桥接, 然后迁移工作负载.
继续介绍如何使用 Lift & Shift + Edge 桥接的方式来迁移现存的 NSX-V 环境到 NSX-T. 这部分将准备新的 NSX-T Edge 集群将 NSX-V 和 NSX-T 的逻辑网段进行桥接, 然后迁移工作负载.
本系列将介绍如何使用 Lift & Shift + Edge 桥接的方式来迁移现存的 NSX-V 环境到 NSX-T. 第一部分将先创建新的 NSX-T 环境. 和前面类似, 此迁移将保证所有的外部地址/DNS条目/VPN peer 配置保持不变.
本文将完成使用 Migration Coordinator 基于用户自定义拓扑迁移现有的 NSX-V 到 NSX-T 环境的剩余部分
本文将介绍如何使用 Migration Coordinator 的用户自定义拓扑模式来迁移现有的 NSX-V 到 NSX-T 环境的第一部分, 迁移前的准备工作.
NSX-V 将在 2024 年 1 月停止支持, 在 NSX-V 上运行工作负载的企业会被建议尽快迁移到 NSX-T. 在一个长期稳定运行的企业环境中更换其网络底座通常是一个相当麻烦的过程. 如何尽量减少网络迁移对业务的影响, 将会是很多企业需要考量的问题. 这里将使用一个实际的例子给出不同的迁移方案, 并分析各个方案的复杂性和宕机时间.
AWS Control Tower 定制化有 CfCT (customization for control tower) 和 AFT (Account Factory for Terraform) 的方式. 这里将介绍如何使用 CfCT 方式为 Control Tower Landing Zone 添加资源.
AWS Landing Zone 方案已经进入长期维护期, 不会再引入任何新的功能. AWS 建议用户使用 Control Tower 方案来管理企业多账户环境. 本文将示例如何从现有的 Landing Zone 方案迁移至 Control Tower 并列举迁移中的注意事项
使用手工方式部署单节点 OKD SNO 4.12, 记录其中的坑和解决方法. 前文介绍的 assisted installer 方式比较简单, 但是需要用户的交互. 这里虽然是手工方式, 但是很容易转化为自动化流水线. 使用的 OKD 版本依然是 4.12.0-0.okd-2023-04-01-051724
Single Node Openshift (SNO), 顾名思义就是只有一个节点的 Openshift. 让用户可以在资源紧缺的边缘设备上运行 Openshift 工作负载. 对于动辄需要几十上百G内存的普通集群, SNO 也非常适合本地开发/测试环境. 这里将记录如何使用 Assisted Installer 方式来部署单节点 OKD (SNO) 4.12
记录下如何解决 ESXi 7 主机上的 Intel(R) I350-T4 网卡周期性出现的高延迟丢包问题.