- 资产清单:列出所有服务器、应用、数据库、依赖服务与端口(使用nmap、ansible-inventory导出);
- 依赖映射:用应用拓扑绘图(如Draw.io或ServiceMap),标注延迟敏感和合规数据;
- 基线与SLA:采集当前CPU/内存/磁盘IO/网络带宽(sar、iostat、iftop),确定目标云的资源规格与SLA要求。
- 比较要点:在新加坡区域的可用性、网络延迟、合规与费用(AWS ap-southeast-1 / GCP asia-southeast1 / Azure southeastasia);
- 服务映射:把本地功能(如负载均衡、对象存储、数据库托管)映射到云服务(ELB/S3/RDS等);
- 决策输出:确认主用云、是否采用多云或混合云,以及所需连接方式(VPN/Direct Connect/ExpressRoute)。
- VPC/VNet设计:子网划分、路由表、NAT网关、最小权限安全组与NACL;
- 连接方案:短期用Site-to-Site VPN做安全通道,长期建议Direct Connect/ExpressRoute或云厂商的专线服务;
- 身份与访问:制定IAM策略、使用MFA、集中审计(CloudTrail/CloudWatch/Stackdriver),准备证书和密钥管理(KMS/Cloud KMS)。
- 策略选择:按应用分类:可替换(rehost/lift-and-shift)、重平台(replatform)、重构(refactor);
- 工具推荐:整机迁移用CloudEndure/AWS Server Migration Service/Azure Migrate;数据库用AWS DMS/Cloud SQL迁移工具或Percona XtraBackup;文件用rsync/rsnapshot/ossutil;
- 计划制定:按业务窗口规划批次迁移、并发数与验证方案。
- 初始准备:在目标云创建目标实例、用户与网络安全规则,打开binlog并记录当前binlog位置;
- 全量导出:使用mysqldump或xtrabackup进行全量备份:mysqldump --single-transaction --master-data=2 -u root -p db > dump.sql;
- 增量同步:启动binlog复制或用AWS DMS做CDC,验证复制延迟低于可接受阈值;
- 切换时点:在切换前把应用改为只读/暂停写入,执行最后一次binlog应用并验证数据一致性(select count(*)等)。
- 环境准备:在云上构建相同的运行时(OS、依赖库、环境变量、配置管理使用Ansible/Terraform);
- 部署方式:建议先使用容器化或镜像(Docker + ECR/ACR),然后用Blue/Green或Canary发布减少风险;
- 验证工具:健康检查(curl /health),集成测试、回放脚本与性能压测(wrk/jmeter),确认日志与追踪(ELK/CloudWatch/Stackdriver)完整。
- 混合流量分配:使用流量镜像或负载均衡做线上比对,逐步把流量从托管切到云端;
- 监控告警:统一采集指标并设置阈值(Prometheus+Grafana或云监控),建立告警与SOP;
- 备份与恢复:在云端配置自动快照、跨区复制与定期恢复演练。
- 切换前准备:降低DNS TTL到60s,通知相关方并准备回退脚本;
- 执行切换:最后同步数据、停止源站写入、更新DNS指向云负载均衡并监控;
- 回退方案:若失败,立即把DNS回指源站并用备份快照恢复,记录原因并触发问题复盘。
- 资源标记:强制Tag(项目/环境/负责人)便于计费归集;
- Auto-scaling与Rightsize:根据监控做实例规格调整与自动伸缩策略;
- 预算告警:设置成本阈值通知并周期性审计闲置资源与快照。
问:如何在迁移期间保证最小停机时间?
答:使用CDC增量同步(如AWS DMS或MySQL binlog),先做全量导入并持续增量复制,切换窗口将应用设置为只写转发/短暂停写,更新DNS TTL并在低峰期完成最终切换,准备回退机制以缩短恢复时间。
问:如何确保新加坡托管与云端的网络延迟可控?
答:优先选择新加坡区域云服务并使用专线(Direct Connect/ExpressRoute);在两端部署健康探测与TCMPing/traceroute测试,必要时使用CDN或边缘缓存减少东南亚用户延迟。
问:迁移后如何做长期协同运维?
答:建立混合运维SLA与Runbook,统一日志/指标平台,制定备份与故障演练计划,并通过IaC(Terraform/Ansible)保持环境可重建性与配置一致性,从而实现托管与公有云的平滑协同。