使用M2VM迁移VMware至GCP：Backend、Manager与Connector的角色困惑

核心结论 #

采用v5.0的Connector方案时，无需单独部署传统的Manager和Backend实例——Connector组件已经整合了这两个实例的核心功能，是v5.0版本推出的简化架构模式。

组件作用与版本差异解析 #

• v4.9及更早版本的传统架构
  早期版本采用分离式架构：

  • Backend实例部署在vSphere环境，负责与ESXi主机交互、读取源VM数据；
  • Manager实例部署在GCP，负责协调迁移流程、与GCE服务交互；
  • 两者必须通过VPN/专线互联，才能完成数据同步与迁移控制。

• v5.0的Connector架构优化
  v5.0彻底重构了架构，将Manager的协调功能和Backend的源端交互功能整合到单个Connector组件中：

  • Connector部署在vSphere环境（或可访问vSphere的网络环境）；
  • 通过SSH密钥完成与GCP项目的注册后，直接与GCP的Migrate服务API通信，无需额外的Manager实例；
  • 源VM的发现、数据复制、迁移调度全流程都可通过Google Cloud Console直接操作，不再依赖独立的Backend实例。

官方文档模糊性的原因 #

谷歌在v5.0迭代时，部分旧文档（针对v4.9）未及时更新，同时新架构的过渡说明不够清晰，导致出现内容不一致。核心判断标准是：如果你选择的是Connector-based migration流程，就只需要部署Connector；如果是遗留的classic migration流程，才需要部署Manager和Backend。

内容的提问来源于stack exchange，提问作者Junior Cloud Enginner