存储容灾规划及自动化实现讲解.ppt

存储容灾系统规划及自动化 建设 刘文 0. 自我介绍 • 目前就职于一家银行科技部门从事存储和小机的管理工作 • 曾经在IBM工作三年，主要从事IBM 软件服务，同时参与过几个 个存储灾备建设的项目，在存储管理方面有一些小小的经验希望 能跟大家分享一下 • 我今天的选题是存储容灾规划及自动化实现，关于今天的选题， 之前刘启军曾讲过关于数据中心的建设，我今天主要分享一下存 储灾备的技术规划和实现 主要内容 • 1. 主流中端存储灾备解决方案和技术解读(两大类) • 2. 存储灾备选型、规划考虑，以V7000容灾规划举例 • 3. 存储灾备切换的自动化实现 1.1 双活技术 今年的6月11号，AIX china有过一次大型的双活技术讨论，对这一部分的讨论非常精 彩 双活技术适用于对于业务连续性要求高，RTO时间低的业务，包括建立在GPFS基础上 数据库层面的IBM GDPC实现方案，ORACLE golden gate，今天主要讲存储级别的容灾 • IBM SVC（联想有一套大的SVC架构）, powerha+hyperswap(对存储平台、软件版本 要求较高，国内有几家中小银行开始采用这种架构). • EMC vplex（我行正在vnx5500+vmware+vplex环境中测试，目前反响还不错 ，但由 于要保证存储的性能，对vplex和链路租赁的投入会比较大，主要问题：1.第三站点 的问题实现自动切换，否则需要vplex的单点不能解决。

2. 一致性组的规划 • 华为vis • Netapp metrocluster. • 双活技术对于交换机和链路质量要求比较高 1.2 主流存储级容灾技术及比较 高端存储： • IBM DS8000高端存储系列 • Metro mirror/global mirror • EMC Vmax SRDF/STAR • HDS • True copy/Universal Replicator 中端 • EMC vnx Mirror view replication manager • IBM XIV V7000 • Metro/global mirror 面对种类繁多的存储产品和容灾技术，怎么去建设一个适合自己的容灾系统？这是 我第二部分想要阐述的内容 2.1 结合容灾的存储选型考虑 • 1)业务特点，选择合适的容灾技术并确定具体的实现策略，满足业务恢复时相应的RTO、RPO指标(监 控部门，例如金融行业，这是硬性需求) • 2)业务关联程度业务关联紧密，数据的藕合程度高，可能会造成所有关联的业务都要采用同一种容 灾技术，反之，可能会针对不同的业务要求进行区分，分别用不同的容灾技术 • 3)系统现状，核心业务系统容灾技术必须充分考虑与现有系统的配合。

现有核心业务系统的应用分布 、应用的实现方式（对于F5和双活技术的支持）、硬件设备平台的种类、存储数据量的大小、IO吞吐 量的大小等，都会对容灾技术的选择产生影响 • 4)技术成熟度，容灾系统必须采用成熟可靠的技术，保证系统特续，稳定的运行该技术应具有类似 于电信业务运营支撑系统容灾建设的成功案例，不能由于技术手段的不成熟或不稳定而增加核心业务 系统新的风险 • 5)容灾系统环境，核心业务系统容灾技术必须考虑生产中心与容灾中心之间的距离，网络环境等因素 ，不同的技术对距离，网络带宽的要求会有所不同 • 6)成本分析，软硬件投资，链路租赁，实施维护成本 2.2 V7000选型参考 有点像在打广告 环境考虑： • 考虑到服务器的兼容性，服务器操作系统版本5.3 • 数据的扩展，V7000过渡架构，满足以后横向扩展的需要，可作为一个虚拟化存储平台/存 储资源池 V7000的特点，它是一款采众家之长的存储产品 • 源代码部分大部分来自于Svc/XIV: 管理界面人性化设计 /DS8000：raid, 自动分层, easy tier • GPFS最新成果，active cloud engine技术 文件系统存储/SVC集群技术，横向扩展 • V7k免费为所有旧存储增加了快照，精简配置，透明数据迁移等功能 容灾特性 • Licence 单独收费 MM支持300KM同步 GM 80ms延迟 旧版4000KM，新版本突破限制 • 最大支持与三个v7000组成伙伴关系 • 支持集群内-集群间metro-mirror关系 • Metro-mirror支持数据的增量复制（关系断开后重新建立不需要重新初始化） 限制：两地三中心/性能限制，列举DPFv7000性能 2.3 某行V7000规划设计架构1 架构： MM + flashcopy方式 灾备验证方式： • A. 灾备区验证（模拟环境） • 生产系统正常运行情况下，暂停MetroMirror存储复制，使MetroMirror目标卷变为可读写，在灾备区 服务器上启动数据库和应用，进行业务验证。

验证通过之后，在灾备区停止应用和数据库，释放存储 ，恢复MetroMirror存储复制 • 此种场景下不影响生产系统运行 • B. 测试区验证（模拟环境） • 生产系统和存储复制正常运行情况下，重新生成一份新的flashcopy，在测试区服务器上启动数据库和 应用，进行业务验证 • 此种场景下不影响生产系统运行，不需中断存储复制 • C. 灾备切换和回切（真实环境） 2.4 某行V7000规划设计架构2 • A. 我行V7000的应用现状 • 两套V7000, 一套集群，另一套MM架构 • V7000 + SVC组合应用 • 业务分层 • 通过SVC减轻存储IO压力，同时管理其它存储 • B. 灾备验证方式 • SVC enable disable端口 • MM自动化切换 2.5 可能遇到的问题 • 性能问题 • 容量规划考虑，如果采用Global mirror方式，根据异步原理，如果架构 GPFS环境中，避免做restripe等动作，即发生存储数据的瞬间大副变动 ，不仅占用大带宽，同时在由于超过RTOsnapshot空间用满后，可能导 致复制中断 • 流程问题，比如灾备端卷组可以激活，文件系统无法挂载。

由此，我们会想到如果这些操作能够自动化实现就好了，下面一部分我 想阐述存储灾备的自动化建设 3.1 灾备切换自动化的必要性 根据刚才的描述，在我们设计了一套复杂的灾备环境之后，怎么发挥它 的价值，更好的使用它根据监管部门的要求，需要定期对灾备系统进 行验证，每个企业都有自己的灾备演练方案，涉及到繁冗复杂的操作 • 1. 很多企业的灾备演练方案，都是一大堆的重复工作，演练一般又安 排在晚上，运维人员很劳累，面对很多的重复工作很容易出问题 • 2. 我们发现，实际灾备演练过程中，很多的错误都是人工疏忽造成的 • 3. 除了双活，存储卷复制级别的容灾一个很重要的问题就是RTO时间 过长，自动化的应急机制可以有效规避该问题 3.2 自动化工具应用现状 • 目前多为自主开发，IBM(tsa), HP(oo平台), • 某些自动化软件例如Autoswitch • 半自动化工具，例如华为replication director, 通过agent插件来实 现主机上操作的自动化 • 银行，多为自主开发，实现级别： • 存储切换自动化（关于存储这一块涉及到shell脚本和python的操作和标 准化输出） • 服务器卷组/双机操作的自动化 • 应用起停自动化 3.3 自动化的规划设计实现 SAN环境很复杂，不同的存储容灾管理平台用到的软件不一样，比 如DS8000 容灾管理的tpc-R安装在windows机器上，Solution enabler 可能安装在一台AIX主机上。

自动化规划是一个庞大而复杂的工程 • 存储的集中管理，存储控制机操作终端的选定（不同的存储所采 用的切换实现方式不同） • 流程和场景制定（桌面演练/计划内/计划外） • 原子步骤设定 • 核心部分：脚本 3.4 行内灾备自动化现状 • 四个基本组件：灾备指挥平台、自动化引擎组件OO、服务器自动 化组件SA、网络自动化组件NA • 灾备指挥平台界面，后台通过HP OO流调度实现 • 切换的流程和逻辑在OO平台定义 • SA/NA主机 • Python中间件，将命令发给存储控制器， • 返回日志,判断日志结果，是否需要进行一下步操作 3.5 容易出问题的环节 • 流程设计 • 数据的同步方向 • 重试机制/状态异常的处理机制 3.6 V7000的自动化切换实现 • Ssh互信 • 停应用 • 切换前检查 • Failover • 状态判定 • Failback • 状态判定 3.7 netapp切换自动化步骤 • Quiece/break • changeconf • resync • break • changeconf • resync • release • snapdelete 3.4 容灾切换脚本心得 • 安全性，脚本风险大，不管是操作系统，还是应用的启停，很多 时候只是启停失败。

存储的每一步操作，都可能，比如在更新数 据时，一旦方向弄反了像netapp snapmirror, 把源和目标写反了 ，都会酿成很严重的后果 • 智能化，做好每一步状态检查的判断工作，能自动化处理的则自 动化处理，不能自动化处理的则需要人工介入，例如对异常状态 的判断要充分，否则自动化反而带来不好的效果 • 标准化，输入输出的，SAN环境中涉及到不同的存储，怎么实现 ，规范标准化输出，让自动化工具能正确识别每一步操作的返回 结果，比如failover之后，一致性的状态是idle还是 consistentstopped，需要经过测试 • 流程化，按流程决定每一步的操作，比如SRDF的灾备端数据验证 过程，只需要验证数据，split之后establish就可以了。