简介中国电信天翼混合云服务平台解决方案PDF面向企业IT决策者、云计算架构师与售前解决方案人员聚焦私有云平滑扩展至混合云、统一资源管理与安全可控的实际诉求。内容以官方宣讲材料形式依次介绍混合云市场趋势、中国电信与VMware联合架构、虚拟数据中心VDC的小包/中包/大包及增量包服务模式并覆盖容灾即服务、桌面即服务、基于vSphere与vCloud Suite的软件定义数据中心设计以及客户最关注的应用迁移、网络连通、数据安全等问题的应对思路。资源共1个PDF文件压缩包大小6.3MB版式清晰、目录完整适合作为了解天翼混合云全貌、撰写解决方案或对比云服务模式的参考资料。已有124人学习下载具有较好的参考价值。1. 混合云不是上云是让本地数据中心长出第二个可用区有同行问我混合云和公有云的区别到底在哪。2014年中国电信和VMware联合发布天翼混合云时给了一个很明确的答案它不要求你改应用也不要求你换管理工具而是把电信机房变成企业本地vSphere环境的一块延伸资源。目标客户很清晰——已经有vSphere虚拟化平台、又不想把关键业务全部交给公有云的政企用户。对运维团队来说真正要关心的只有三件事资源包怎么选、网络怎么打通、容灾和运维怎么并进本地流程。这篇就基于当时的平台设计方案把服务模型、容灾链路、网络策略迁移和统一管理拆开讲。2. 天翼混合云的服务架构与VDC资源包设计2.1 为什么服务架构要参考vCloud Air天翼混合云不是凭空搭一套独立云平台而是参考vCloud Air的整体架构再按照国内政企客户的需求做裁剪。架构里可以看到三层最底下是vSphere计算、存储和网络池中间是vCenter和统一管理API最上面是虚拟数据中心、容灾和虚拟桌面服务。这样的好处是本地用vSphere的客户几乎不需要做技术转换就能理解云端的资源模型。另一个关键设计是独享和共享物理服务器的拆分。共享池适合开发和测试独享池适合对合规有要求的正式业务。设计时还要保证资源池可以承载500公里内20ms网络时延的覆盖这对国内多分支企业比较重要。实际项目里我一般会建议客户先把业务分成“可上共享池”和“必须上独享池”两类再做资源规划而不是所有工作负载都往同一个池子里塞。2.2 VDC资源包规格共享和独享怎么选天翼混合云的虚拟数据中心服务分共享和独享两类每类又有小、中、大和增量包。下表整理自当时的服务清单。资源包类型典型场景vCPU内存硬盘高可用共享-小包开发测试、轻量Web32 GHz180 GB1.5 TBHA共享-中包生产业务集群96 GHz540 GB3 TBHA共享-大包大内存计算型业务160 GHz900 GB4.5 TBHA共享-增量包资源扩容32 GHz180 GB1.5 TBHA独享-小包合规要求高的轻量业务5 GHz20 GB500 GBHA独享-中包独立安全域15 GHz60 GB1.5 TBHA独享-大包核心生产系统25 GHz100 GB2.5 TBHA独享-增量包扩容5 GHz20 GB500 GBHA注意这里的vCPU单位是GHz不是核数说明资源包是按CPU时间片来划分的评估时不能只看核数。比如一个共享大包标称160 GHz如果一台物理机是2.6 GHz主频那它对应的CPU占用量要结合超配比来折算。运维侧更应该关注的是业务峰值时段的CPU压力而不是平均负载。2.3 年度计费和增量包的使用边界虚拟数据中心服务按年度收费增量包必须基于已经购买的小、中、大包且不能超过基础服务的时限。也就是说如果基础包还剩6个月增量包最多也买6个月。这样设计是为了避免客户用增量包绕过主套餐的计费周期。从采购角度看增量包适合两种场景一是业务增长不确定先用小包顶着二是大促、财报季这种短周期算力突增。如果预测增长持续超过三个季度直接升级主包通常比基础包加增量包更划算。原因是增量包单价一般高于同规格主包折算出来的单价这是套餐设计的常见逻辑。2.4 用脚本做资源包选型估算选型阶段我一般会把业务负载的峰值CPU、内存和存储需求列出来再对照资源包做减法。下面是一个简单的Python脚本按现有虚拟机清单估算需要几个共享大包# resource_pack_planner.py # 根据虚拟机清单估算天翼混合云共享资源包数量 vm_list [ {name: app-01, cpu_ghz: 8, ram_gb: 32, disk_gb: 200}, {name: app-02, cpu_ghz: 8, ram_gb: 32, disk_gb: 200}, {name: db-01, cpu_ghz: 16, ram_gb: 64, disk_gb: 500}, ] pack_cpu 160 # 共享大包的CPU配额GHz pack_ram 900 # 共享大包的内存配额GB pack_disk 4500 # 共享大包的存储配额GB total_cpu sum(v[cpu_ghz] for v in vm_list) total_ram sum(v[ram_gb] for v in vm_list) total_disk sum(v[disk_gb] for v in vm_list) n_cpu (total_cpu pack_cpu - 1) // pack_cpu n_ram (total_ram pack_ram - 1) // pack_ram n_disk (total_disk pack_disk - 1) // pack_disk print(fCPU需求{total_cpu} GHz建议大包数{n_cpu}) print(f内存需求{total_ram} GB建议大包数{n_ram}) print(f存储需求{total_disk} GB建议大包数{n_disk})逻辑说明脚本把每个虚拟机的CPU、内存、磁盘需求累加再分别除以共享大包的配额向上取整得到各维度最少需要的资源包数。实际使用中三者的最大值才是你要采购的大包数量还要额外加10%到15%的余量用于HA和突发流量。参数说明pack_cpu、pack_ram、pack_disk分别对应共享大包的配额如果换成独享大包就改成25 GHz、100 GB、2.5 TB。注意独享包的单位容量小很多通常在合规场景下牺牲弹性换取资源隔离。脚本还可以扩展加入“业务允许降级”的权重把非核心VM的CPU峰值削减一半结果会不同。3. 容灾服务DR2C的实现机制与配置要点3.1 为什么DR2C不依赖存储阵列天翼混合云把容灾服务设计成DR2CData Center to Cloud。它利用vSphere Replication在虚拟机层做异步复制把本地数据中心的VM文件包括应用、操作系统和数据完整复制到云端。与阵列复制不同它对客户端的存储没有要求也不需要额外采购备份软件或硬件。实施时只需要在客户数据中心导入一个容灾复制设备让它和混合云端的对应网段IP可达。这个设计最大的价值在运维层面。传统容灾项目通常要动核心交换机、存储阵列至少要协调存储、网络、虚拟化和应用四个团队。DR2C把复制的边界收敛在虚拟机层面本地存储是集中式还是分布式都不影响云端接收数据。客户端硬件变更时只要vSphere版本兼容复制任务一般不需要重建。3.2 复制链路中的关键角色复制链路涉及三个角色本地vSphere主机负责读取VMDK变更块复制管理服务器负责调度复制任务云端复制设备接收数据并写入目标存储。整个通道走异步复制RPO可设置为15分钟到24小时。异步的意思是生产VM每15分钟或更长时间产生一个复制周期而不是实时同步因此对链路带宽的容忍度更高。需要强调的是RPO不是RTO。DR2C保证的是“丢多少数据”而恢复虚拟机、启动应用、切换网络的时间取决于容灾演练做得好不好。我一般会建议客户把RPO和RTO分开写进验收表RPO由复制间隔决定RTO则要实测。文档里没有承诺RTO实际项目中要靠演练数据来评估。3.3 配置流程和容灾演练一个标准配置流程如下步骤操作说明1在本地vCenter中导入复制设备OVA设备名可自定义需要分配静态IP2在vSphere Web Client安装vSphere Replication插件插件同时管理本地和云端复制任务3登录插件添加远程站点远程站点填天翼混合云端站点地址4为需要保护的VM配置复制选择目标存储、RPO和网络映射5执行初始同步观察复制状态和延迟6创建隔离的演练环境在云端VPC中恢复VM不干扰生产这里最容易被忽略的是第4步的网络映射。复制任务需要把本地VM的源端口组映射到云端的分布式端口组如果映射错容灾切换后VM可能拿不到正确IP地址。另外演练环境建议单独划一个VPC用与生产隔离的网段避免恢复出来的测试VM影响到正常业务。3.4 用PowerCLI批量创建复制任务当要保护的VM超过几十个时手工点击不现实。常见做法是用vSphere Replication PowerCLI写批量脚本# 连接vSphere Replication管理端 Connect-VrServer -Server vrms.example.com -User admin -Password $password # 连接本地vCenter并获取目标VM Connect-VIServer -Server vc.example.com -User admin -Password $password $targetVm Get-VM -Name db-prod-01 # 创建复制任务RPO设为30分钟 New-VrReplication -VM $targetVm -TargetSite HybridCloud -TargetDatastore (Get-Datastore -Server $cloudVc -Name hybrid-storage-01) -RpoMinutes 30逻辑说明Connect-VrServer先建立与复制管理端的会话New-VrReplication把指定VM的复制任务创建到远端站点目标存储、RPO都在这一行里完成。-RpoMinutes的单位是分钟15分钟对应1524小时对应1440。参数说明如果PowerCLI版本较旧部分参数名可能不同常见的是-Rpo而不是-RpoMinutes。我一般会在批量执行前先对一台非生产VM做一次完整流程验证确认参数可用后再放开全量执行。实际操作中复制任务创建后还要启动初始同步然后关注同步百分比和剩余时间确认数据追赶完成后再批量复制下一批VM。4. 混合云网络打通与安全策略迁移4.1 软件定义网络能力清单天翼混合云在云端提供相互隔离的子网同时提供防火墙、NAT路由、负载均衡和Site-to-site IPsec隧道。这些功能由软件定义网络层提供客户不需要额外采购物理网络设备。网络策略可以随虚拟机的迁移动态漂移因此当应用从本地迁移到云端时防火墙规则不需要重新绑定物理IP。这个特性的价值要放在多租户环境下看。共享资源池里不同客户的虚拟机可能落在同一台物理主机上如果只靠传统VLAN隔离网络规划和策略下发都会变得很重。软件定义网络把隔离和策略从物理拓扑里解耦出来租户看到的是自己的虚拟网络边界。4.2 典型网络拓扑四类业务网段怎么划分企业客户通常会在虚拟数据中心里划分业务网络、DMZ网络、开发测试网络和审计网络。参考常见做法网络子网示例访问方向关键策略业务网络10.10.1.0/24内部访问数据库、中间件只开放业务端口DMZ网络10.10.2.0/24外部访问Web统一入口映射开发测试网络10.10.3.0/24开发人员访问禁止连接生产数据库审计网络10.10.4.0/24运维人员只读访问双向白名单这些子网在云端可以独立创建子网之间的访问策略由边缘网关控制不需要在物理交换机上做配置。对于已有本地VLAN规划的企业建议在规划阶段就把云端子网和本地子网错开避免地址重叠。一旦两端出现相同网段路由策略会变得很难处理。4.3 本地数据中心如何和云端打通首先要选择连接方式专线还是加密隧道。专线适合数据量大的生产同步加密隧道适合传输非关键数据。两者都必须保证源和目标IP不冲突。打通后本地VM和云端VM之间通过三层路由通信运维人员需要维护一张路由表明确哪些网段在本地、哪些在云端。在打通前建议先做一次链路质量测试。常见做法是在两端各放一台Linux虚拟机用ping和iperf3分别测时延和带宽# 从云端测试到本地业务网关统计0.5秒间隔共100个包 ping -c 100 -i 0.5 10.10.1.1 # 测试到本地的TCP吞吐持续60秒每10秒输出一次 iperf3 -c 10.10.1.1 -t 60 -i 10逻辑说明ping的-c指定包数量-i指定间隔秒数。100个包足以看出平均时延和丢包率如果丢包超过0.1%不太适合承载同步复制类业务。iperf3客户端模式连接到服务端-t 60表示持续60秒-i 10表示每10秒打印一次结果可以观察带宽是否稳定抖动。参数说明10.10.1.1要替换成对端实际可达IPiperf3另一端需要先启动服务端模式iperf3 -s。如果测试结果不达标先查防火墙策略和物理线路不要急着调复制参数。4.4 安全策略随应用漂移的实现文档强调“安全策略随应用漂移无需更改”。这背后的实现机制是安全组绑定到虚拟机的对象而不是绑定到IP地址。企业只需在本地vSphere环境中把VM加入指定安全组迁移到云端后安全组标签仍然保留防火墙规则按标签执行。验证时要做一次真实迁移测试观察业务流量是否会因策略不匹配而中断。如果一个应用依赖三层会话跟踪比如F5负载均衡设备上记录的会话迁移后可能会遇到连接中断。这类设备通常需要在云端导入对应的镜像让应用继续通过原有方式的负载均衡器对外提供访问。天翼混合云支持导入企业自用的Appliance虚拟机这给复杂应用留了兼容空间。5. 统一管理平面从vSphere Web Client插件到API集成5.1 插件化管理的价值天翼混合云另一个关键设计是在原有维护工具中增加插件即可管理混合云。对企业运维团队来说不需要每天登录电信侧Portal而是直接在熟悉的vSphere Web Client里操作。对已有vCenter的客户来说这套方式的学习成本几乎为零。我接触过不少云迁移项目最大的阻力往往不是技术而是运维习惯。让一个用了五六年vSphere的团队去接受一套完全陌生的云管平台排障效率会明显下降。插件化方案保留了原有的告警、拓扑和操作路径混合云的资源以文件夹或数据中心的形式出现在vCenter视图里团队可以沿用现有权限模型。5.2 本地和云端的管理边界管理上要明确哪些事能在本地vCenter做哪些必须去云端界面做。我一般会给团队一张表操作场景本地vSphere Web Client天翼混合云Portal查看本地VM监控可以不适用部署云端VM通过插件可以可以调整云端虚拟网络部分可以完整能力容灾演练和切换通过插件可以可以管理物理服务器和存储池不适用可以按照这个分工本地团队负责业务生命周期云平台团队负责物理资源。两边同时改配置可能导致状态漂移比如云端网络策略被Portal修改后本地插件里的缓存视图不会马上刷新需要重新登录才会拉取最新状态。5.3 插件之外的API集成如果企业有工单系统流程一般需要自动创建资源可以绕过插件直接调用vCloud API。下面是Python示例import requests base_url https://hybrid.example.com/api session requests.Session() session.auth (api_user, api_password) session.headers.update({Accept: application/*;version30.0}) # 获取组织VDC列表用于后续在指定VDC中创建VM resp session.get(f{base_url}/admin/vdcs, verifyFalse) vdcs resp.json() for vdc in vdcs: print(vdc[name])逻辑说明requests.Session复用连接session.auth处理HTTP Basic认证verifyFalse只适合测试环境。/admin/vdcs会返回环境内所有组织VDC拿到VDC的ID后再调用/api/vApp创建vApp和虚拟机。参数说明API域名、用户名和密码建议配置在环境变量或密钥管理系统中不要写死在脚本里。如果只是查看也可以直接用curl命令但Python更适合做后续关联工单系统。实际生产环境中注意把API请求放到独立流程里做不要和日常巡检脚本混在一起。5.4 运维侧需要保留的最小组件在混合云落地时至少要在本地保留一台可以连通云端API的跳板机并保证它不在容灾范围外。否则本地发生故障时运维人员无法登录云端执行恢复操作。常见做法是把跳板机放在独立的运维网段配置双因素认证并只开放API和SSH端口。再配一个单向只读的监控账号用于平时巡检云端资源状态避免每次都使用管理员权限操作。6. 落地时最容易踩的坑和验证方法6.1 RPO设定不等于数据丢失上限很多人看到RPO 15分钟就以为最多丢15分钟数据其实测试时还要看两点复制是否真的按计划执行以及出现故障时复制链路是否能快速切换到云端。实际验证方法是人为断开生产网络一部VM的写入连续观察15到30分钟查看复制延迟是否持续上涨。如果延迟超过设定的RPO说明复制周期实际没有达标。6.2 应用不需要改代码不代表可以盲迁文档说的“Any Application No Changes”是指虚拟机层面的兼容性。应用程序内部如果有硬编码IP、主机名或共享存储路径迁移后一样会出问题。上线前应该先在隔离VLAN中恢复完整环境让业务做一轮冒烟测试。测试项至少要包括登录认证、数据库连接、文件上传下载和对外接口调用。6.3 安全策略漂移验证不能只看VM状态安全策略随应用漂移是分布式防火墙标签能力。验证时要重点确认迁移后的VM是否还带着原有安全标签跨子网访问是否走预期规则。最简单的方法是在迁移前后各抓一次五元组流量用对比工具看一下访问记录确认策略生效的对象是VM标签而不是物理网段。6.4 验收清单里的三个容易被跳过的小项复制任务在vSphere Web Client里是否显示绿色、延迟是否在RPO范围内。云端子网和本地子网是否出现地址重叠尤其是两端都用了10.0.0.0/8这类大段地址。容灾演练恢复出的VM是否保留了静态IP地址并且能被业务部门按原主机名访问。每次演练完把恢复出来的VM关机等待下一轮增量同步即可。本文还有配套的精品资源点击获取
混合云落地指南：资源包选型、DR2C容灾与网络策略迁移
简介中国电信天翼混合云服务平台解决方案PDF面向企业IT决策者、云计算架构师与售前解决方案人员聚焦私有云平滑扩展至混合云、统一资源管理与安全可控的实际诉求。内容以官方宣讲材料形式依次介绍混合云市场趋势、中国电信与VMware联合架构、虚拟数据中心VDC的小包/中包/大包及增量包服务模式并覆盖容灾即服务、桌面即服务、基于vSphere与vCloud Suite的软件定义数据中心设计以及客户最关注的应用迁移、网络连通、数据安全等问题的应对思路。资源共1个PDF文件压缩包大小6.3MB版式清晰、目录完整适合作为了解天翼混合云全貌、撰写解决方案或对比云服务模式的参考资料。已有124人学习下载具有较好的参考价值。1. 混合云不是上云是让本地数据中心长出第二个可用区有同行问我混合云和公有云的区别到底在哪。2014年中国电信和VMware联合发布天翼混合云时给了一个很明确的答案它不要求你改应用也不要求你换管理工具而是把电信机房变成企业本地vSphere环境的一块延伸资源。目标客户很清晰——已经有vSphere虚拟化平台、又不想把关键业务全部交给公有云的政企用户。对运维团队来说真正要关心的只有三件事资源包怎么选、网络怎么打通、容灾和运维怎么并进本地流程。这篇就基于当时的平台设计方案把服务模型、容灾链路、网络策略迁移和统一管理拆开讲。2. 天翼混合云的服务架构与VDC资源包设计2.1 为什么服务架构要参考vCloud Air天翼混合云不是凭空搭一套独立云平台而是参考vCloud Air的整体架构再按照国内政企客户的需求做裁剪。架构里可以看到三层最底下是vSphere计算、存储和网络池中间是vCenter和统一管理API最上面是虚拟数据中心、容灾和虚拟桌面服务。这样的好处是本地用vSphere的客户几乎不需要做技术转换就能理解云端的资源模型。另一个关键设计是独享和共享物理服务器的拆分。共享池适合开发和测试独享池适合对合规有要求的正式业务。设计时还要保证资源池可以承载500公里内20ms网络时延的覆盖这对国内多分支企业比较重要。实际项目里我一般会建议客户先把业务分成“可上共享池”和“必须上独享池”两类再做资源规划而不是所有工作负载都往同一个池子里塞。2.2 VDC资源包规格共享和独享怎么选天翼混合云的虚拟数据中心服务分共享和独享两类每类又有小、中、大和增量包。下表整理自当时的服务清单。资源包类型典型场景vCPU内存硬盘高可用共享-小包开发测试、轻量Web32 GHz180 GB1.5 TBHA共享-中包生产业务集群96 GHz540 GB3 TBHA共享-大包大内存计算型业务160 GHz900 GB4.5 TBHA共享-增量包资源扩容32 GHz180 GB1.5 TBHA独享-小包合规要求高的轻量业务5 GHz20 GB500 GBHA独享-中包独立安全域15 GHz60 GB1.5 TBHA独享-大包核心生产系统25 GHz100 GB2.5 TBHA独享-增量包扩容5 GHz20 GB500 GBHA注意这里的vCPU单位是GHz不是核数说明资源包是按CPU时间片来划分的评估时不能只看核数。比如一个共享大包标称160 GHz如果一台物理机是2.6 GHz主频那它对应的CPU占用量要结合超配比来折算。运维侧更应该关注的是业务峰值时段的CPU压力而不是平均负载。2.3 年度计费和增量包的使用边界虚拟数据中心服务按年度收费增量包必须基于已经购买的小、中、大包且不能超过基础服务的时限。也就是说如果基础包还剩6个月增量包最多也买6个月。这样设计是为了避免客户用增量包绕过主套餐的计费周期。从采购角度看增量包适合两种场景一是业务增长不确定先用小包顶着二是大促、财报季这种短周期算力突增。如果预测增长持续超过三个季度直接升级主包通常比基础包加增量包更划算。原因是增量包单价一般高于同规格主包折算出来的单价这是套餐设计的常见逻辑。2.4 用脚本做资源包选型估算选型阶段我一般会把业务负载的峰值CPU、内存和存储需求列出来再对照资源包做减法。下面是一个简单的Python脚本按现有虚拟机清单估算需要几个共享大包# resource_pack_planner.py # 根据虚拟机清单估算天翼混合云共享资源包数量 vm_list [ {name: app-01, cpu_ghz: 8, ram_gb: 32, disk_gb: 200}, {name: app-02, cpu_ghz: 8, ram_gb: 32, disk_gb: 200}, {name: db-01, cpu_ghz: 16, ram_gb: 64, disk_gb: 500}, ] pack_cpu 160 # 共享大包的CPU配额GHz pack_ram 900 # 共享大包的内存配额GB pack_disk 4500 # 共享大包的存储配额GB total_cpu sum(v[cpu_ghz] for v in vm_list) total_ram sum(v[ram_gb] for v in vm_list) total_disk sum(v[disk_gb] for v in vm_list) n_cpu (total_cpu pack_cpu - 1) // pack_cpu n_ram (total_ram pack_ram - 1) // pack_ram n_disk (total_disk pack_disk - 1) // pack_disk print(fCPU需求{total_cpu} GHz建议大包数{n_cpu}) print(f内存需求{total_ram} GB建议大包数{n_ram}) print(f存储需求{total_disk} GB建议大包数{n_disk})逻辑说明脚本把每个虚拟机的CPU、内存、磁盘需求累加再分别除以共享大包的配额向上取整得到各维度最少需要的资源包数。实际使用中三者的最大值才是你要采购的大包数量还要额外加10%到15%的余量用于HA和突发流量。参数说明pack_cpu、pack_ram、pack_disk分别对应共享大包的配额如果换成独享大包就改成25 GHz、100 GB、2.5 TB。注意独享包的单位容量小很多通常在合规场景下牺牲弹性换取资源隔离。脚本还可以扩展加入“业务允许降级”的权重把非核心VM的CPU峰值削减一半结果会不同。3. 容灾服务DR2C的实现机制与配置要点3.1 为什么DR2C不依赖存储阵列天翼混合云把容灾服务设计成DR2CData Center to Cloud。它利用vSphere Replication在虚拟机层做异步复制把本地数据中心的VM文件包括应用、操作系统和数据完整复制到云端。与阵列复制不同它对客户端的存储没有要求也不需要额外采购备份软件或硬件。实施时只需要在客户数据中心导入一个容灾复制设备让它和混合云端的对应网段IP可达。这个设计最大的价值在运维层面。传统容灾项目通常要动核心交换机、存储阵列至少要协调存储、网络、虚拟化和应用四个团队。DR2C把复制的边界收敛在虚拟机层面本地存储是集中式还是分布式都不影响云端接收数据。客户端硬件变更时只要vSphere版本兼容复制任务一般不需要重建。3.2 复制链路中的关键角色复制链路涉及三个角色本地vSphere主机负责读取VMDK变更块复制管理服务器负责调度复制任务云端复制设备接收数据并写入目标存储。整个通道走异步复制RPO可设置为15分钟到24小时。异步的意思是生产VM每15分钟或更长时间产生一个复制周期而不是实时同步因此对链路带宽的容忍度更高。需要强调的是RPO不是RTO。DR2C保证的是“丢多少数据”而恢复虚拟机、启动应用、切换网络的时间取决于容灾演练做得好不好。我一般会建议客户把RPO和RTO分开写进验收表RPO由复制间隔决定RTO则要实测。文档里没有承诺RTO实际项目中要靠演练数据来评估。3.3 配置流程和容灾演练一个标准配置流程如下步骤操作说明1在本地vCenter中导入复制设备OVA设备名可自定义需要分配静态IP2在vSphere Web Client安装vSphere Replication插件插件同时管理本地和云端复制任务3登录插件添加远程站点远程站点填天翼混合云端站点地址4为需要保护的VM配置复制选择目标存储、RPO和网络映射5执行初始同步观察复制状态和延迟6创建隔离的演练环境在云端VPC中恢复VM不干扰生产这里最容易被忽略的是第4步的网络映射。复制任务需要把本地VM的源端口组映射到云端的分布式端口组如果映射错容灾切换后VM可能拿不到正确IP地址。另外演练环境建议单独划一个VPC用与生产隔离的网段避免恢复出来的测试VM影响到正常业务。3.4 用PowerCLI批量创建复制任务当要保护的VM超过几十个时手工点击不现实。常见做法是用vSphere Replication PowerCLI写批量脚本# 连接vSphere Replication管理端 Connect-VrServer -Server vrms.example.com -User admin -Password $password # 连接本地vCenter并获取目标VM Connect-VIServer -Server vc.example.com -User admin -Password $password $targetVm Get-VM -Name db-prod-01 # 创建复制任务RPO设为30分钟 New-VrReplication -VM $targetVm -TargetSite HybridCloud -TargetDatastore (Get-Datastore -Server $cloudVc -Name hybrid-storage-01) -RpoMinutes 30逻辑说明Connect-VrServer先建立与复制管理端的会话New-VrReplication把指定VM的复制任务创建到远端站点目标存储、RPO都在这一行里完成。-RpoMinutes的单位是分钟15分钟对应1524小时对应1440。参数说明如果PowerCLI版本较旧部分参数名可能不同常见的是-Rpo而不是-RpoMinutes。我一般会在批量执行前先对一台非生产VM做一次完整流程验证确认参数可用后再放开全量执行。实际操作中复制任务创建后还要启动初始同步然后关注同步百分比和剩余时间确认数据追赶完成后再批量复制下一批VM。4. 混合云网络打通与安全策略迁移4.1 软件定义网络能力清单天翼混合云在云端提供相互隔离的子网同时提供防火墙、NAT路由、负载均衡和Site-to-site IPsec隧道。这些功能由软件定义网络层提供客户不需要额外采购物理网络设备。网络策略可以随虚拟机的迁移动态漂移因此当应用从本地迁移到云端时防火墙规则不需要重新绑定物理IP。这个特性的价值要放在多租户环境下看。共享资源池里不同客户的虚拟机可能落在同一台物理主机上如果只靠传统VLAN隔离网络规划和策略下发都会变得很重。软件定义网络把隔离和策略从物理拓扑里解耦出来租户看到的是自己的虚拟网络边界。4.2 典型网络拓扑四类业务网段怎么划分企业客户通常会在虚拟数据中心里划分业务网络、DMZ网络、开发测试网络和审计网络。参考常见做法网络子网示例访问方向关键策略业务网络10.10.1.0/24内部访问数据库、中间件只开放业务端口DMZ网络10.10.2.0/24外部访问Web统一入口映射开发测试网络10.10.3.0/24开发人员访问禁止连接生产数据库审计网络10.10.4.0/24运维人员只读访问双向白名单这些子网在云端可以独立创建子网之间的访问策略由边缘网关控制不需要在物理交换机上做配置。对于已有本地VLAN规划的企业建议在规划阶段就把云端子网和本地子网错开避免地址重叠。一旦两端出现相同网段路由策略会变得很难处理。4.3 本地数据中心如何和云端打通首先要选择连接方式专线还是加密隧道。专线适合数据量大的生产同步加密隧道适合传输非关键数据。两者都必须保证源和目标IP不冲突。打通后本地VM和云端VM之间通过三层路由通信运维人员需要维护一张路由表明确哪些网段在本地、哪些在云端。在打通前建议先做一次链路质量测试。常见做法是在两端各放一台Linux虚拟机用ping和iperf3分别测时延和带宽# 从云端测试到本地业务网关统计0.5秒间隔共100个包 ping -c 100 -i 0.5 10.10.1.1 # 测试到本地的TCP吞吐持续60秒每10秒输出一次 iperf3 -c 10.10.1.1 -t 60 -i 10逻辑说明ping的-c指定包数量-i指定间隔秒数。100个包足以看出平均时延和丢包率如果丢包超过0.1%不太适合承载同步复制类业务。iperf3客户端模式连接到服务端-t 60表示持续60秒-i 10表示每10秒打印一次结果可以观察带宽是否稳定抖动。参数说明10.10.1.1要替换成对端实际可达IPiperf3另一端需要先启动服务端模式iperf3 -s。如果测试结果不达标先查防火墙策略和物理线路不要急着调复制参数。4.4 安全策略随应用漂移的实现文档强调“安全策略随应用漂移无需更改”。这背后的实现机制是安全组绑定到虚拟机的对象而不是绑定到IP地址。企业只需在本地vSphere环境中把VM加入指定安全组迁移到云端后安全组标签仍然保留防火墙规则按标签执行。验证时要做一次真实迁移测试观察业务流量是否会因策略不匹配而中断。如果一个应用依赖三层会话跟踪比如F5负载均衡设备上记录的会话迁移后可能会遇到连接中断。这类设备通常需要在云端导入对应的镜像让应用继续通过原有方式的负载均衡器对外提供访问。天翼混合云支持导入企业自用的Appliance虚拟机这给复杂应用留了兼容空间。5. 统一管理平面从vSphere Web Client插件到API集成5.1 插件化管理的价值天翼混合云另一个关键设计是在原有维护工具中增加插件即可管理混合云。对企业运维团队来说不需要每天登录电信侧Portal而是直接在熟悉的vSphere Web Client里操作。对已有vCenter的客户来说这套方式的学习成本几乎为零。我接触过不少云迁移项目最大的阻力往往不是技术而是运维习惯。让一个用了五六年vSphere的团队去接受一套完全陌生的云管平台排障效率会明显下降。插件化方案保留了原有的告警、拓扑和操作路径混合云的资源以文件夹或数据中心的形式出现在vCenter视图里团队可以沿用现有权限模型。5.2 本地和云端的管理边界管理上要明确哪些事能在本地vCenter做哪些必须去云端界面做。我一般会给团队一张表操作场景本地vSphere Web Client天翼混合云Portal查看本地VM监控可以不适用部署云端VM通过插件可以可以调整云端虚拟网络部分可以完整能力容灾演练和切换通过插件可以可以管理物理服务器和存储池不适用可以按照这个分工本地团队负责业务生命周期云平台团队负责物理资源。两边同时改配置可能导致状态漂移比如云端网络策略被Portal修改后本地插件里的缓存视图不会马上刷新需要重新登录才会拉取最新状态。5.3 插件之外的API集成如果企业有工单系统流程一般需要自动创建资源可以绕过插件直接调用vCloud API。下面是Python示例import requests base_url https://hybrid.example.com/api session requests.Session() session.auth (api_user, api_password) session.headers.update({Accept: application/*;version30.0}) # 获取组织VDC列表用于后续在指定VDC中创建VM resp session.get(f{base_url}/admin/vdcs, verifyFalse) vdcs resp.json() for vdc in vdcs: print(vdc[name])逻辑说明requests.Session复用连接session.auth处理HTTP Basic认证verifyFalse只适合测试环境。/admin/vdcs会返回环境内所有组织VDC拿到VDC的ID后再调用/api/vApp创建vApp和虚拟机。参数说明API域名、用户名和密码建议配置在环境变量或密钥管理系统中不要写死在脚本里。如果只是查看也可以直接用curl命令但Python更适合做后续关联工单系统。实际生产环境中注意把API请求放到独立流程里做不要和日常巡检脚本混在一起。5.4 运维侧需要保留的最小组件在混合云落地时至少要在本地保留一台可以连通云端API的跳板机并保证它不在容灾范围外。否则本地发生故障时运维人员无法登录云端执行恢复操作。常见做法是把跳板机放在独立的运维网段配置双因素认证并只开放API和SSH端口。再配一个单向只读的监控账号用于平时巡检云端资源状态避免每次都使用管理员权限操作。6. 落地时最容易踩的坑和验证方法6.1 RPO设定不等于数据丢失上限很多人看到RPO 15分钟就以为最多丢15分钟数据其实测试时还要看两点复制是否真的按计划执行以及出现故障时复制链路是否能快速切换到云端。实际验证方法是人为断开生产网络一部VM的写入连续观察15到30分钟查看复制延迟是否持续上涨。如果延迟超过设定的RPO说明复制周期实际没有达标。6.2 应用不需要改代码不代表可以盲迁文档说的“Any Application No Changes”是指虚拟机层面的兼容性。应用程序内部如果有硬编码IP、主机名或共享存储路径迁移后一样会出问题。上线前应该先在隔离VLAN中恢复完整环境让业务做一轮冒烟测试。测试项至少要包括登录认证、数据库连接、文件上传下载和对外接口调用。6.3 安全策略漂移验证不能只看VM状态安全策略随应用漂移是分布式防火墙标签能力。验证时要重点确认迁移后的VM是否还带着原有安全标签跨子网访问是否走预期规则。最简单的方法是在迁移前后各抓一次五元组流量用对比工具看一下访问记录确认策略生效的对象是VM标签而不是物理网段。6.4 验收清单里的三个容易被跳过的小项复制任务在vSphere Web Client里是否显示绿色、延迟是否在RPO范围内。云端子网和本地子网是否出现地址重叠尤其是两端都用了10.0.0.0/8这类大段地址。容灾演练恢复出的VM是否保留了静态IP地址并且能被业务部门按原主机名访问。每次演练完把恢复出来的VM关机等待下一轮增量同步即可。本文还有配套的精品资源点击获取