存储容灾规划及自动化实现全解.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目标卷变为可读写，在灾备区服务器上启动数据库和应用，进行业务验证。验证通过之后，在灾备区停止应用和数据库，释放存储，