检测到您已登录华为云国际站账号,为了您更好的体验,建议您访问国际站服务网站 https://www.huaweicloud.com/intl/zh-cn
不再显示此消息
L实例(需先迁到云服务再迁移到自建) mysqldump导出导入 全量迁移 不依赖网络,操作较为复杂,只能全量迁移,不支持增量数据同步 停服时间窗较长场景 主从复制replication 全量+增量迁移 操作复杂 仅适用于源端和目标端均为自建MySQL数据库,由于源端和目的端版本
不停服切换方案 应用层切换不停服方案 若只涉及到应用层的切换,可参考章节 停服切换方案 中提到的应用灰度切流方案,切换期间不停服。 数据层或应用整体切换不停服方案 准备工作: 华为云应用层和数据层已完成迁移; 华为云应用层和数据层已完成业务验证,可正常使用。 业务切换: 修改两边
云上可扩展性 云相较于传统IDC非常大的一个优势具备丰富的资源和强大的扩展能力;根据业务场景的不同需求,可以将扩展能力分成如下3类: 纵向(垂直)扩展:适用于单体应用、独立应用、有状态应用等场景下,随着业务不断发展和变化,需要快速升级硬件以应对业务变化。如在进行一些促销活动时,对
部署主要是进行云上目标环境的资源开通和配置,并做好上云前的各项检查和测试,并进行迁移环境的准备。 要按照应用部署架构设计方案进行云上资源的开通和配置,云上资源开通主要有如下3种方式: 在云平台Console控制台手动创建云资源。 编写脚本或通过自动化平台对接,调用云平台的API接口,批量发放云资源,每个云服务都有
Master高可用:ES Master节点3AZ分布(2+2+1)。在任意一个可用区不可用时,集群依旧有超过半数的法定主节点选举个数,保证Master的正常选主。 数据节点:ES Data节点3AZ分布(2+2+1)。索引shard分片至少设置2副本,加上主分片副本有3副本。假如3AZ中任意一个AZ整
250K 2~5ms 125MB/s/TiB 100 百万级 1~3ms 250MB/s/TiB 100 百万级 1~3ms 500MB/s/TiB 200 百万级 1~3ms 1000MB/s/TiB 200 百万级 1~3ms SFS通用型 容量型 50 100K 7ms 性能型 200
幅加速新产品的TTM和已有产品的迭代周期。如果新产品的TTM从6个月缩短至3个月,假设新产品每个月带来200万元的收入,那么提前3个月上市将带来600万元的额外收入。对于已有产品,如果将其版本迭代周期从3个月缩短至1个月,假设新版本每个月能带来100万元收入,那么新版本提前2个月上市将带来200万元额外收入。
设计切换方案 如何选择停服不停服 停服切换方案 停写不停读切换方案 不停服切换方案 父主题: 应用迁移上云
停服切换方案 停服时长评估 基于华为云的迁移经验,切换期间大部分应用停服时长在0.5小时~3.5小时,下面停服时长可供参考: 表1 停服时长分析 上云迁移停服时长评估 总停服时长(36~211分钟) 源端停机(12~75分钟) 增量数据同步及校验(6~40分钟) 目的端拉起(18~96分钟)
-port); 使用备份功能将rdb文件输出到S3中。 备份数据上传至OBS: EC2:使用OBS Browser/obsutil工具将备份文件(aof/rdb)上传至DCS所在的Region的OBS。 S3:创建OMS任务,将S3中的rdb备份文件迁移传输到DCS所在的Region的OBS。
业务系统的可用性SLO 业务系统全年可用性SLO从99%提升到99.95%。 新产品或新版本的TTM 将新产品的TTM从6个月缩短至3个月,已有产品的迭代周期从3个月缩短至1个月。 不合规及安全事件造成的经济损失 将不合规及安全事件数量减少75%,经济损失减少75%。 IT基础设施的TCO
计划开始时间 计划结束时间 1 XXX 1.1 - - - 必须解决 - - - - - 2 1.1 - - - 必须解决 - - - - - 3 1.2 - - - 必须解决 - - - - - 4 1.3 - - - 必须解决 - - - - - 5 1.3 - - - 必须解决 -
如何选择停服不停服 业务切换是整个上云迁移的关键环节,出问题会直接影响企业业务,不同业务对停服的要求是不一样的,比如,有些业务在切换期间是不允许停服的,停服会造成较大的业务损失;有些业务在切换期间是允许停服的,比如办公OA系统,夜间非工作期间可以停服;有些业务系统,为了更好的客户
切换方案不同,对应的Runbook的操作步骤也不同。切换方案可以分停服切换和不停服切换。不停服切换方案对应用架构的要求比较高,通常需要对应用架构进行大规模改造,所以业界普遍采用的切换方案是停服切换。下面以停服切换为例,介绍Runbook设计的注意事项。 设计正向操作步骤 依据切
停写不停读切换方案 停写不停读,主要指切换期间,为了追求较好的用户体验,保持一部分读的服务不停服,保持在线可使用状态;为了保持数据一致性,写的服务仍然采用停服方式进行切换。从业务对外体验上,多数用户感知不到停服的影响,比如某购物平台,用户仍然可以浏览商品,但是不能下单,下单时可友好的提示:系
多个分项确认人在线刷新确认进展)。 引导人通常是1~2个,是整个切换的总指挥(对于大规模切换,参与人员多,操作时间长的场景,也可以设计2~3名引导人,互为备份),引导人需要对整个Runbook非常熟悉,尤其对于每个步骤执行时序,多个步骤的并行情况要熟悉。 父主题: 设计Runbook
务迁移方案的设计。 设计数据迁移方案 大数据的数据迁移涉及到3类数据,如下表: 表1 大数据迁移的三类数据 分类 说明 元数据 Hive元数据或外置元数据 存量数据 历史数据,短期内不会变化 增量数据 数据定期更新 这3类数据的迁移方法如下: 表2 大数据三类数据的迁移方式 数据分类
切换相关人员通知和核对 企业项目经理 确认切换参与人员是否可以出席 是 否 企业项目经理 第三方配合切换当晚参与人员和联系方式确定 是 是 企业项目经理 停服切换期间,运营中心值班人员就位 是 是 企业内部发送内部通知 企业项目经理 切换通知群名:XX项目切换群 是 是 云厂家建立后端保障团队 云厂家项目经理
开发 5 测试 3 生产 1 业务重要性 一般 5 重要 3 核心 1 关联性 简单 5 复杂 3 非常复杂 1 基础架构复杂度 简单(实例数1~3) 5 复杂(实例数4~10) 3 很复杂(实例数11~) 1 允许停服时长 120分钟以上 5 60~120分钟 3 <60分钟 1
切换 大数据的切换主要是指大数据应用的切换,其切换演练和正式切换的步骤请参考章节切换。本节重点介绍大数据应用切换的3个切换点,以便更好的指导大数据应用的切换。 双跑场景:大数据应用分别在源环境和目标环境各部署一套,实现双跑,切换点在域名,业务切换时只需要进行域名的切换,将业务流量切换到新应用。