在线系统迁移与升级方案题库.ppt

在线系统迁移与升级 练习题 提纲 迁移割接的目标 设备迁移? 数据迁移？ 失败案例 (1) 一刀切迁移？ 失败案例 (2) 广研的搬迁方案 广研的搬迁方案 广研的搬迁方案 总结广研的方案 在线系统升级要求 DB平滑扩容 DB平滑扩容 多版本支持 多版本支持 QQServer代码例子 多版本支持 灰度割接 灰度割接 单机软件发布 网络软件快速验证 总结 谢谢 如果不强制升级RTX2005，试用的人很少，因为大部分人都在用RTX3.61，新版本无法与旧版本互联 广研自评 优点： 搬迁操作一步到位，干脆； 人力和时间投入少； 对搬迁资源，入后备设备、两地带宽等要求较少； 缺点： 风险大，不可控制因素多 回退可能性非常小 QQMAIL系统停止服务时间至少一天以上； 如出严重交通事故，QQMAIL系统有可能永久丢失 广研自评 优点： 搬迁过程中不影响系统服务； 新旧系统切换时间短； 数据两地相互备份，无论新系统中出现任何问题，都可回退到旧系统； 风险低； 缺点： 对深广两地带宽要求较大； 需要投入与QQMAIL现有设备数量基本相同的切换设备，投入成本高； 数据同步所花费时间较长； * *  QQMAIL系统提供 @ 域名的邮件服务，原来是的网站部维护，后来转由广州研发中心维护 广州研发中心为了日常维护方便，建议将QQMail从深圳枢纽机房搬迁到广州电信较场西机房 请用15分钟设计一个系统搬迁方案 深圳电信枢纽机房 注册用户约6千万 开通用户数约4千万 邮件存储总使用空间约13T 64台在用机器 广州电信较场西机房 23台备用机器 2M专线 搬迁和割接的风险 广研的搬迁方案 在线系统平滑升级 小版本迭代升级 用户体验更好 减低搬迁的费用及风险 不采用任何可能做成错误或损失的迁移方式 搬迁和割接的风险 IDC2 结果可能是… 拨错线（电线、网线） 整柜跳线 搬错设备 运输过程摔坏 IDC1 错综复杂的机房 物理设备搬迁 IDC2 IDC1 有限的专线网络带宽 结果是… 全套的设备投入 漫长的等待 复杂的增量同步 不可遇见的风险 海量的数据 某运营商原来的用户数据是集中式处理，需要按省处理，新系统在各省已建设完成，需要通过网络进行数据迁移操作。 方案：用10Mbit的网络带宽分批传输5Gbytes的数据，计划数据传输需要时间1个多小时，共停止系统3个小时，结果… 网络质量抖动，传输用了3个多小时 数据倒入数据库，完成倒入接近85%时，数据库崩溃 数据库修复用了3个多小时 继续倒入直到完成为止(幸运的是当时设备及数据库都没有大的损坏) 如果事情可能出错，就一定会出错。 旧Server 旧系统 旧DB 旧client 新系统 有BUG会导致数据丢失、支撑不了压力 数据库缺少必要数据 新Server 新DB 新client 结果是… 回滚 新系统无法上线测试 一刀切 某美国软件开发商给日本网络运营商开发了新的邮件系统，需要用新的系统替换旧的系统 方案：将所有用户数据及邮件倒入新系统，结果… 用户数据开始迁移顺利，新系统运行正常了几天 运行一周后，出现造成用户全部邮件丢失的bug 开发商以最快的速度修复软件bug，但用户邮件已经丢失，找不回来 运营商威胁不支付软件费用 开发商用一年时间才使运营商恢复信心(幸运的是数据是分批倒入的) 新系统存在bug是难以避免。 广研的搬迁方案 方案一： 搬迁前准备，QQMAIL数据与应用完成备份； QQMAIL系统停服务； 修改DNS指向； 设备停机、下架、装车、由深圳搬运至广州、上架、开机； QQMAIL在广州重新架设，重新提供服务； 没回退性，风险太大，绝对不可行 方案二： 在广州IDC机房架设基本满足QQMAIL系统运营和存所有QQMAIL数据的设备 在新设备上架设QQMAIL应用 使用工具软件让深圳与枢纽的数据进行同步 保证两地数据一致和应用一致后，修改DNS指向 QQMAIL服务由广州设备接替 一次迁移所有用户数据，操作时间长，风险不可控，没长期需要而临时扩充带宽浪费资源 方案三： 同样需要架设一套基本与现有QQMAIL相同的系统：在广州架设服务器，安装QQMAIL应用模块(WEBMAIL、SMTP/POP3等)； 在深圳枢纽架设服务器，安装QQMAIL后台存储； 利用枢纽带宽，把旧系统数据同步到枢纽新存储上； 搬迁安装后台存储的服务器到广州，修改广州新系统的配置，让应用与后台存储完成接合 再使用工具软件进行深广新旧系统数据增量同步； DNS切换，新系统提供服务； 物理搬迁，容易做成物理损坏 任一台机器物理损坏都会导致迁移失败 物理搬迁，风险大，而且劳民伤财。 在线系统平滑升级 尽量保持7×24小时服务 用户不受任何影响或影响很小 QQGame的DB分裂，不需停止用户的游戏过程