针对存储替换迁移中风险点的关键策略分析 | 运维进阶
【作者】陈萍春，现就职于保险行业，拥有多年的系统、存储以及数据备份等运维工作经验。
前言
随着企业业务应用的拓展和业务数据不断增长，作为 IT 基础架构的重要组成，存储系统不仅面临着存储容量与性能提升的需求，还需要适应系统架构的变化。由于系统架构越来越复杂、数据类型越来越多样性，存储替换迁移工作也需要越来越细致。为了高效、安全、完整地完成存储替换迁移任务，我们需要结合不同存储及各自系统特点有策略地开展迁移相关的工作。
数据迁移方法
存储替换迁移其实也是一个数据迁移的过程，首先我们需要先了解下常用的存储数据迁移技术，其实现方法可以大致分为如下几类：
1) 基于应用软件层的数据迁移
这种方法一般采用应用软件自身的迁移程序或其他第三方迁移工具来实现数据迁移。比较典型的比如 Oracle 数据同步工具 DataGuard ，数据库的备份恢复程序等等数据同步或复制方法。这类方法的优势在于可以定制化数据迁移的过程，不受限于主机、存储，但是只适用于特定的应用。
2) 基于主机系统层的数据迁移
这种方法是通过主机系统层的数据拷贝或迁移来实现数据的迁移的。比较典型的比如虚拟化环境中的 VMotion 迁移数据存储，或者通过支持 LVM 的系统的逻辑卷镜像来实现数据迁移。这类方法优势在于可以方便的在线迁移，但缺点是主机系统层较复杂的情况下，需要消耗较多的精力完成迁移所需的系统配置。
3) 基于存储层的数据迁移
这种方法一般采用两种方法来实现：一是借助存储虚拟化技术来很方便地实现数据迁移，比较典型的产品是 VPLEX 或 SVC 这类的存储虚拟化设备，或者自带存储虚拟化技术的存储阵列比如 HDS VSP 等，存储虚拟化则是在服务器与存储之间插入一个中间层，通过存储虚拟逻辑卷的可以实现类似于异构存储系统间的数据镜像等功能，这样只需要在存储虚拟化层创建镜像再拆除镜像，就可以更加高效的完成存储间的数据迁移；二是通过存储自带的数据复制软件或支持的数据复制工具，完成存储卷的复制，一般在同类型的存储系统中完成。基于存储的数据迁移的优势在于不受主机层、应用层限制，迁移效率更高。
存储替换迁移实践案例
以本人曾参与的存储替换迁移工作为例，某银行同城双机房原有 7 套高端存储及两套 VPLEX 设备，其中生产机房 5 台存储按照数据类型分为 2 个区域：交易域和数据域，交易域存放交易类数据，数据域存放统计分析类数据，灾备机房则是 2 台存储组成灾备域。其存储架构如下图所示：
而主机系统则包括了 IBM 小型机、 X86 服务器以及 VMWare 虚拟机等多种类型的系统架构，应用则包括 DB2 、 ORACLE 等数据库以及其他关键业务应用。
由于业务数据量的迅速增长等多种因素，原有的存储架构存在着存储替换、扩容以及分域规划等需求，并确立了三个新的存储体系规划建设目标：一是数据域和交易域的存储需要隔离分开；二是这三个存储区域都需要扩容；三个需要实施存储镜像，消除存储单点隐患。最终，通过在数据域另外引入一套 SVC 设备，其他三个存储域各新增一台存储设备，并通过存储间的替换迁移实现最终的架构规划。
迁移难点分析
存储替换迁移本质上是一个通过数据迁移技术完成存储设备之间的数据迁移，并将原有的数据存储路径切换为新的存储路径的实施过程。结合该银行存储替换迁移的案例来看，存储替换迁移的难点可以大致总结为如下几点：
1) 迁移方法的选择
各种数据迁移方法都有各自的优缺点，也适用于不同的数据迁移需求和迁移场景。在该银行存储替换迁移案例中，存储方面涉及到了多个厂家多种型号的存储系统，另外主机层面和应用层面的架构也不统一，而且涉及到几乎全行的业务系统，存储替换迁移整体的工作量也较大，具体该如何选择存储层的数据迁移方案。
2) 迁移时间窗口控制
由于待迁移的存储容量较大或者涉及的系统较多或者迁移方法所限，整个迁移工作可能会持续较长时间。特别是本案例中，部分待迁移系统的业务连续性要求较高，停机窗口都有一些限制。所以怎么去控制迁移时间窗口，做好迁移计划也很关键。
3) 迁移影响性分析
存储的替换迁移不仅仅涉及到存储设备自身，还与系统以及其上运行的应用也密不可分。整个迁移过程中会给哪些系统带来怎样的影响，会持续多长时间，这些也是系统管理员需要充分评估的，并需要与其他同事沟通清楚的点。
4) 迁移的风险控制
存储的替换迁移总是存在一定安全风险，如迁移失败、数据不一致或丢失等等情况。这就涉及到了如何回退操作，控制迁移风险。另外存储替换迁移后，数据又是否需要校验，数据的完整性要求又如何保证等等风险。
应对策略
那么存储替换迁移工作又改如何开展，来应对上述的迁移难点呢？本文还将结合上述案例以及个人的存储替换迁移实践经验，来谈谈具体的应对策略：
1) 存储架构的提前规划
首先我们需要明确存储替换迁移的目的，一般存储替换迁移都带着明确的目标，比如旧设备更新换代，比如架构规划调整等等。对于设备更新换代的，我们需要在存储规划之初就应该确定如何兼顾更新换代与存储迁移的需求，更早地规划好存储架构；对于架构规划调整的，我们也需要提前做好规划，在架构规划调整与存储替换迁移之间找到平衡点。提前做好存储规划，选择替换迁移阻力最小的方向，尽量减少系统的改造量
在本文的案例中，考虑到在线迁移需求且迁移数据量较大的情况，我们基本锁定了存储层的数据迁移方法。另外由于涉及到多厂商异构存储和存储镜像双活技术，存储虚拟化技术成了唯一选项。但如果全部接入到原 VPLEX 设备下，还会存在无法满足存储分域及 VPLEX 性能不足等情况。所以最终的存储规划方案设计为在数据域另外引入一套 SVC 设备，其他三个存储域各新增一台存储设备，并通过存储替换迁移实现最终的架构规划，如下图所示：
2) 迁移测试及分析
在正式迁移前，设计好迁移测试方案，并能完整模拟整个迁移过程，是一项很有意义的工作。在本文的案例中，迁移测试的内容主要包括异构存储接入 SVC 纳管的功能测试、原 VPLEX 环境下主机迁移到 SVC 的改造测试以及虚拟存储卷数据迁移速度等测试。这可以让我们更熟悉迁移方法和流程，是下一步工作的基础。结合迁移测试的数据，我们可以估算迁移造成的影响以及大致的迁移时间窗口。
同时迁移测试也能验证迁移方法的有效性，综合对比各种迁移方法的优劣，结合实际环境，选出最优的替换迁移方法。以 NAS 存储迁移为例，之前实施过一个文件数接近 3000 万的 NAS 文件系统，目标 NAS 存储是 isilon ，原本考虑到文件权限等因素，计划采用的是主机层面 rsync 数据同步工具来同步的，但是同步速度很慢，预估需要 5 天时间才能完成数据同步。后来测试了下 isilon 内置的基于 NDMP 协议的数据迁移工具，发现迁移速度更快，且文件权限也能迁移过来，最终 30 多个小时就能迁移完成。
3) 迁移前的环境检查与影响性分析
环境检查也是替换迁移重要的一步，对替换迁移所涉及的系统，都需要做进一步的健康性检查。在本文的存储替换迁移案例中， SVC 接入改造涉及到了多个数据域系统的停机维护变更，这些系统主要是 DB2 结合 PowerHA 的高可用架构 , 也有 GPFS 文件系统集群应用。而待迁移改造系统本身的操作系统问题或 PowerHA 配置存在的问题，也给 SVC 接入改造工作带来了不小的麻烦。
所以迁移前的环境检查主要是从两方面考虑的：一是为了避免本身系统隐患在替换迁移中彻底暴露出来，比如说系统本身高可用或集群配置存在隐患，在存储替换迁移中可能会大大影响变更的实施进度，需要花费大量的精力来解决这类问题；二是可以摸清存储迁移替换变更的影响范围，结合迁移测试的部分，进一步分析迁移替换对整个系统的影响性，有利于把控存储替换迁移的风险。
4) 制定合理的迁移替换计划
合理的迁移替换计划是存储替换迁移工作中最关键的一个环节，在通过上述的三个关键环节的铺垫之后，还需要制定具体的存储迁移替换计划。其主要包括如下的几个部分工作：
制定迁移批次及迁移时间计划
前文提到，存储替换迁移很多时候会涉及到较大的数据量，架构众多复杂的系统以及停机时间窗口限制。那么合理的规划迁移批次，估算每个批次的迁移时间是必要的应对策略。在具体迁移批次规划方面，我们可能设置很多规则，但是总体来说，要考虑迁移的工作量的合理分配，要考虑尽量减少停机时间窗口和停机频次，还要考虑人员资源的分配。
在本文的案例中，存储替换迁移工作主要是数据类系统 SVC 接入改造、存储间的数据迁移这两类工作。而 VC 接入改造工作的难点在于涉及到 10 套系统环境的改造，都需要做停机维护，所以最终根据停机时间窗口及整体工作量分了三个批次来迁移改造；存储间的数据迁移主要是通过 SVC 或 VPLEX 的双活镜像来实现的，但是涉及的存储卷较多，迁移的数据量接近 80T ，最终对每批次的迁移数据量做了平衡，同样也计划了三个批次的存储间数据迁移。
迁移前准备
针对每个批次的数据迁移，我们需要做好迁移前准备。考虑存储数据的重要性以及迁移变更存在的极端异常情况，数据备份是迁移前不可忽视的部分。数据备份的范围一定要尽可能的考虑周详，不同类型的数据采用不同的备份方式，比如应用配置信息、集群配置信息、数据库备份、数据备份等等。另外数据备份要保证可恢复性，同时也是有时效性的，哪些数据相对静态，哪些是增量数据，如何保证数据能尽可能地恢复到迁移前的时间点，都是需要重点考虑的。
人员协调
存储替换迁移是基础架构层面比较重要的调整动作，很多时候不是单个个体的力量就能很妥善的完成的，需要学会借力，协调各方面的资源参与进来。像本文的案例中这样的存储替换迁移工作，除了存储管理方面的工作外，还涉及到了操作系统层的配置、数据库的启停和备份、应用的启停和验证等等工作。所以，从前期制定迁移计划开始，到迁移方案的评审，再到迁移工作的开展，尽可能让更多的人员参与进来，让参与人员了解迁移工作的整个流程。这样不仅给方案的提出更多宝贵的合理性建议，也能减少迁移工作的阻力，集思广益，让存储替换迁移工作更加顺利的推进。
迁移顺序和操作流程
在做好上述工作之后，制定具体的迁移顺序和操作流程会更加容易。下表是 SVC 迁移改造的操作流程模板，可供参考：
一般来说，需要将迁移所涉及的工作主要包括准备工作、系统启停、数据迁移、存储割接、系统验证、应用验证等待。我们还需要对这些工作进行原子化细分，详细分析每个步骤所需时间，考虑迁移工作的关联关系，梳理出哪些工作是串行的，哪些工作是可以并行的，做到科学地人员工作分配，减少迁移工作中本来就紧张的时间窗口下的等待时间。
应急方案
应急预案和回退方案是每个变更操作必须充分考虑的，在实际存储替换迁移工作的过程中，依然会存在很多实施前未充分论证的细节，比如数据替换迁移过程中，由于各种原因迁移命令执行失败，比如系统 HA 或者某个应用起不来等等异常情况。这些异常情况除了临场的应对解决之外，还需要我们能事前制定完整的存储替换迁移的应急预案和回退方案。一旦在计划时间内无法解决异常问题，需要果断采取应急预案和回退方案，毕竟数据丢失或者存储不可用会造成极其恶劣的影响。
善后工作
由于迁移工作本身就占用较多的精力以及善后工作可能会拉长时间周期，存储替换迁移的善后工作很多时候会被忽视。在本文案例中的存储替换工作，善后工作主要包括：一是数据完整性、一致性验证工作，比如替换前后数据库信息的校对，文件系统则可以统计文件 inode 数和文件 MD5 校验；二是旧配置信息或者临时配置信息清理工作，配置信息是否暂时保留，保留多久，一般来说旧的存储配置信息都是在变更实施的第二天才做清理，主要是方便回退；三是存储替换迁移前后的对比，替换迁移是否达到了迁移工作的预期，比如可以观察迁移前后的批处理作业或其他性能监控指标。这些工作有些是迁移完成后就必须开展的，有些是需要观察期的，都需要我们去落实完成的，否则会留下各种隐患，存储替换迁移工作的质量也得不到保证。
结语
存储替换迁移是一项涉及到了存储、操作系统、应用系统、数据库等等不同类型系统的工作，需要灵活应对不同的数据迁移需求。本文首先介绍了常用的数据迁移方法，再结合某银行存储体系规划建设的实践工作，分析存储替换迁移过程中存在的难点、风险点，并具体解析其应对策略，包括存储架构规划、制定迁移计划、迁移测试、迁移流程以及回退方案等方面工作，也希望给同行在存储替换迁移工作方面提供一种借鉴。
原题：存储替换迁移的关键策略分析
如有任何问题，可以点击文末阅读原文，到社区原文下提问交流 觉得本文有用，请转发或点击“在 看”，让更多同行看到
资料/文章推荐：
欢迎关注社区 “存储平台”技术主题 ，将会不断更新优质资料、文章。地址：
http://www.talkwithtrend.com/Topic/179
下载 twt 社区客户端 APP
长按识别二维码即可下载
或到应用商店搜索“twt”
长按二维码关注公众号
*本公众号所发布内容仅代表作者观点，不代表社区立场