手机支付系统两地三中心的应用级云容灾方案V2.pptVIP

* 空间管理要求 资源管理 集中化告警监控 降低投资成本 清点存储设备 了解资源的消耗 准确反映当前整体情况 科学决策/预测发展趋势 采购过程更明确 性能监控 端到端拓扑发现 动态跟随网络变化 事前主动监控 使用更经济 快速定位事故原因 存储环境故障响应 集中处理平台 业务影响关联策略 提高反应速度 减少管理工具 端到端管理 软件独立性 统一管理提高适应能力 统一工具减少人为失误 从业务应用到物理设备 可视性管理要求 可靠性管理要求 可变性管理要求 云管理 议程 * 金融业容灾规范 1 手机支付方案设计 2 方案----手机支付应用级云容灾的落地 3 数据复制技术的比较 4 案例借鉴 5 * 同城数据复制方案----SF mirror * 生产卷 EMC盘阵 SAN 容灾阵列 镜像卷 异构镜像盘阵 1. 本地阵列故障，应用不切换 2. 本地阵列修复，数据增量同步，不影响业务 3 容灾阵列故障，业务无影响 4. 容灾阵列修复 增量同步，业务 无影响 * 硬件厂商同城容灾方案---SRDF的复制模式 Limited distance Host 1 4 2 3 Source Target SRDF瓶颈 单个LUN最多只能处理每秒300个写左右 DMX3只能处理每秒15000个写左右 同城数据复制方案比较 Presentation Identifier Goes Here * 功能描述 SF mirror SRDF 阵列故障零停机 本地/远程阵列故障应用不受影响 本地阵列故障应用停止 内部逻辑错误 完全避免 无法避免 阵列异构 完全支持 必须同构 云储存功能 完全实现 无法实现 成本 硬件 无需增加额外的硬件模块 还需额外购买硬件复制卡，增加阵列cache，cpu，port等配置用于复制时的阵列消耗 必须加买复制软件，BCV等 SF中包含复制，快照等无额外投资， 软件 快照数据保护 可以跨异构阵列作快照 阵列内部实现 异地数据复制比较 A SAN Replication A IP Replication A A SRL SRL SRDF/A SF /VVR 异地数据复制方案比较 Presentation Identifier Goes Here * 功能描述 SF/ VVR SRDF/A 内部逻辑错误 完全避免 无法避免 阵列异构 完全支持 必须同构 复制链路要求 基于单个I/O块为单位，收到一个I/O就传一个I/O, 链路不增加额外开销 在阵列cache中累积30 秒的I/O后，一起同步到远程的阵列cache中，所以对链路和阵列cache开销大 成本 阵列档次 由于有三中心的容灾，岳阳又是异步复制，因此可以采用中低端的阵列 硬件复制方案，异步复制必须是高端阵列，中低端阵列不具备复制功能 阵列配置 阵列内无需增加额外的硬件模块 增加阵列的cache，cpu，port等配置用于复制时的阵列消耗 增加河西主机房的实施方法 四方坪VVR异步同步到岳阳 河西建成后，在四方坪的主卷上增加一个河西的镜像卷 完成2地3中心，河西和四方坪在数据镜像关系上不存在主次之分 1.四方坪异步到岳阳 2.河西建成后，复制完全重建以实现2地3中心 3. 重建过程中，数据无容灾 两地三中心的整体方案 Presentation Identifier Goes Here * 纯软件 纯硬件 软硬结合 方案 1.河西 和四方：镜像 2.镜像完的数据 VVR到岳阳 1.河西同步到西方坪 2.四方坪异步到岳阳 1.河西同步到四方坪 2.河西异步到四方坪 1. 实现河西和四方坪的镜像同步 2. 硬件厂商完成异步复制 可行性 完全可行 完全可行行 完全可行 四方坪和河西主机房互换的实施 先实现异步远程复制， 异步不停，直接增加镜像。 四方坪到岳阳异步 中断原先的异步复制，完全重新建立同步和异步复制关系。 硬件实现四方坪到河西 软件加入河西镜像卷 硬件重新建立异步复制 实施方案比较 延续性实施，实施简单无风险，实施最简单 实施最复杂，实施过程无连续性，新增河西时实施过程中，可能会有一定时间无容灾保护 实施较复杂，但河西加入时，始终有容灾保护 阵列逻辑错 完全避免阵列逻辑错 完全无法避免阵列的逻辑错，河西，四方坪两个逻辑错可能点 避免部分逻辑错。四方坪阵列逻辑错不影响，河西阵列逻辑错无法避免 几乎避免阵列逻辑错，同时减小河西主机房逻辑错的影响。 方案主要优势 除数据同步外，实施云存储，云管理等。 硬件环境单纯，责任制简单 除数据同步外，实施云存储，云管理等。 Presentation Identifier Goes Here * Fire Drill splits BCV snaps at remote site, mounts the BCV, then s