HDS数据迁移解决方案要点.pdf

《HDS数据迁移解决方案要点.pdf》由会员分享，可在线阅读，更多相关《HDS数据迁移解决方案要点.pdf（14页珍藏版）》请在三一文库上搜索。

1、HDS 数据迁移解决方案 1. 数据迁移概述 数据迁移是企业IT 建设经常面对的工作。在开发环境向运行环 境转换、低版本数据库向高版本数据库转换、两个不同数据库之间进 行转换以至系统硬件升级时， 数据均可能需要被转移并使之迁移后正 常运行。 基于存储的数据迁移是一次性的将数据从一个存储转移到另一 个存储系统上， 它包括对新存储的启用和数据可用性的保证。在一些 情况下，基于存储的数据迁移是进行数据大集中的手段，非常适合大 规模数据迁移需求。 基于存储的数据迁移又可分为同构存储迁移和异构存储迁移两 大类。目前基于同构存储的迁移是指在同厂家同型号产品之间数据迁 移，需要配置支持基于磁盘阵列内（间）的

2、数据复制软件，在HDS 同系列存储环境下， 经常性的数据迁移可利用存储产品中的迁移复制 （Volume Migration， ShadowImage） 及存储间的复制 TrueCopy 功能简化数据迁移工作；对EMC而言是配置SRDF-DM或 TIMEFINDER等。 异构存储间数据迁移需要虚拟化技术支持，HDS虚拟化技术非 常成熟，在虚拟化基础上将原来不能完成数据复制的存储设备整合在 一起， 形成统一存储池，这时物理上在两个磁盘的数据卷之间的迁移， 在逻辑上来讲是在整合虚拟后的同一个磁盘阵列内卷迁移，大大简化 了数据迁移的复杂性。 许许多多国内外客户都通过这种数据迁移方式 实现了在线数据迁移

3、。 2. 数据迁移的难题 当今数据迁移的主要难题是进行一次成功的数据迁移时间要求 越来越短。然而应用在存储方面的需求不断增加，存储的升级和更替 更加频繁；同时， 用户的应用趋向于全年不停顿运行、对系统的可靠 性、可用性要求不断提高， 维护时间窗口的不断减少等因素，使得进 行一次平滑的成功数据迁移越来越具挑战。 在进行数据迁移项目计划时，一些因素是必须考虑的。 2.1 数据的保护 数据的保护是最重要的， 在数据迁移中数据的安全必须得到完全 的保护。任何一个更换过个人计算机中的硬盘的人，都对因为在更换 过程中对某些细节的忽视造成的数据丢失有预期和经验。当在企业级 数据迁移中， 数据备份、 实施步骤

4、的回退计划是保证数据在迁移后的 可用性的必需准备。 2.2 在线或离线迁移 如果应用可以暂停， 则迁移过程可以更快捷； 但是当今大多数系 统有着严格的可用性要求。 当数据迁移在生产环境中进行时，不仅要 密切监控数据迁移的过程，而且要将迁移对生产系统的影响降到最 低。 2.3 维护时间窗口 通常迁移工作只能在预先确定的维护时间窗口中进行。通常时间 窗口是在夜间或周末生产活动最少的时候。这些严格的时间窗口的存 在使得迁移项目可能表现出不规则间断的情况：紧张的迁移在时间窗 口中进行，然后在时间窗口关闭时停止，业务继续运行；迁移工作只 有在时间窗口再次打开后才可以继续进行。从而使得迁移工作分散成 数成

5、不连续的多个阶段性工作。 2.4 迁移技术 在开放系统环境中， 没有一个完美的数据迁移技术。每个迁移技 术均有优势和劣势。 针对每个特定的业务环境， 应该根据不同技术的 特点进行仔细甄别选择。直接费用（人力、硬件和软件等）因素应 该和间接因素 （应用停止和生产系统性能影响等）结合起来作为选择 迁移技术的判据。 有些需要更大的维护时间窗口，而有些对生产系统 的性能会有较大影响。这些都会成为选择相应存储技术的考虑因素。 2.5 计划和应用停顿的容忍程度 数据迁移会对生产系统有着或多或少的影响，当分析完应用可用 性要求，完成维护时间窗口的选择后， 可供选择的技术就相对比较固 定。 2.6 测试需求

6、根据应用的情况，特定时间的迁移前测试和迁移后测试是必须 的。因为没有一个普遍适用的测试计划，所以针对每个特定的环境都 需要做出详细的有针对性的测试计划。测试的时间跨度也与应用情况 相关，时间长短也是根据应用的需求决定。 2.7 数据迁移的时间跨度 总的来说，决定数据迁移时间跨度的最主要因素是用户对迁移对 原应用的影响的容忍程度。而时间跨度与应用可用性之间密切相关。 通常，在费用和可以接受的应用可用性之间有着一定的关系。越高要 求的应用可用性意味着越多的费用，从而也就制约了时间跨度。 经验 表明，在没有详细彻底的评估环境和项目目标的情况下，进行迁移时 间的预测是很困难的。一般来说，需要经过评估，

7、分析，计划和实施 等几个步骤。 2.8 整个环境的复杂性 在数据迁移过程中涉及到各种应用和数据之间的关系，越复杂的 应用环境，则相应的计划和实施就越复杂。 3. 数据迁移技术的选择 客户的原系统应用系统架构中包括了HP、IBM等多种主机平 台，存储为 HDS9970V，将来可扩展个多种存储平台，在进行初步 分析的基础上， 针对未来主机操作系统改变与否，我们认为未来系统 的选择可以分为两大类：同构环境和异构环境。 3.1 同构环境的数据迁移技术 针对与现有系统同构， 我们认为至少可以有以下一些技术手段可 以选择： 基于磁盘阵列远程数据复制技术的数据迁移。 基于主机操作系统逻辑卷镜像技术的数据迁移

8、。 基于数据库备份和恢复技术的数据迁移。 基于三方工具的数据迁移。 基于存储虚拟化技术的数据迁移 3.2 异构环境的数据迁移技术 针对异构计算环境， 一般推荐可以使用以下几种方法之一，具体 方法的选择还需进一步详细了解现有系统运行环境： 基于主机操作系统逻辑卷镜像技术的数据迁移。 基于数据库备份和恢复技术的数据迁移。 基于三方工具的数据迁移。 基于存储虚拟化技术的数据迁移 3.3 可选的数据迁移技术 对于业务数据的迁移，目前主要采用如下五种方法： 基于磁盘阵列远程数据复制技术的数据迁移。 基于主机操作系统逻辑卷镜像技术的数据迁移。 基于数据库备份和恢复技术的数据迁移。 基于第三方工具的数据迁移

9、。 基于存储虚拟化技术的数据迁移 最后的迁移方案应该是上述方案的结合，我们会在上述方法结合 过程中找到最佳数据迁移方案。 3.3.1 基于主机操作系统逻辑卷镜像技术的数据迁移 此种数据迁移方法，主要利用业务主机操作系统内置的逻辑卷管 理系统的逻辑卷镜像（ LV Mirror）技术，对于业务系统所使用的每 个 LV，都进行 PV 映射扩展，在新的目标磁盘阵列上扩展一个PV 映射，这样，通过数据的初始化同步，可以保证业务数据在原有的磁 盘阵列和新的磁盘阵列上保持同步，两边数据完全一致。然后，在删 除每个 LV 到原有磁盘阵列的PV 映射，这样，数据就完全从原有磁 盘阵列迁移到新的磁盘阵列。 原有磁

10、盘阵列上的数据在一段时间内保 持不变，以用来回退，一旦数据迁移因各种原因无法成功，则还可以 利用原来的磁盘阵列提供数据访问。此种方法存在如下优点： *步骤简单，容易实现，速度快； *不需要考虑到上层数据应用系统的内部的结构； *可以在线进行，只需要较短的停机时间（在所有的LV 镜像完成后， 需要停机断开 LV 和原有磁盘阵列上的PV 的映射） ； *LV 在进行 PV 映射扩展时，在经过初始化数据同步后，保持镜像状 态对系统的性能影响很小（大概会消耗2%的系统资源）； 但是，利用这种方法，也存在如下的问题： *在 LV 进行初始化数据同步的时候， 需要消耗主机系统较大的CPU、 memory以

11、及 IO 资源，因此在进行LV 初始化数据同步的时候，会 对在线系统的性能造成较大的冲击； 基于主机的数据迁移方案对于安徽邮政存储银行信息中心本次 项目是可行的， 采用该方案可以逐步实现数据迁移，但需要较多的实 施步骤和停机次数。采用该种数据迁移方案各公司间是没有根本区 别，HDS 公司在这类数据迁移实践中也积累了大量经验。 3.3.2 基于数据库备份和恢复技术的数据迁移 此种数据迁移方法， 主要通过数据库自带的备份和恢复功能以及 逻辑日志追加的技术， 实现一个数据逐步迁移的方法，最后达到把数 据从原有的磁盘阵列完全迁移到新的磁盘阵列的目的。本方法比较安 全，当数据迁移不成功时， 不影响生产系

12、统的正常运行，但是迁移时 间较长，对技术要求较高， 而且需要专门用于数据迁移的一台与生产 主机环境一样的主机，硬件配置可以稍低一点。 基于数据库的数据迁移方案仅仅能够迁移数据库业务应用，对非 数据库应用不可行。 因此，对于安徽邮政存储银行信息中心本次项目 是不可行的。 3.3.3 基于磁盘阵列远程数据复制技术的数据迁移 此种数据迁移方法， 可以在同一个磁盘阵列内通过基于磁盘阵列 的克隆软件或卷迁移软件实现数据复制，完成数据迁移。 如果两个异 构的磁盘阵列通过HDS 虚拟化技术整合在一起，那么在两个异构的 磁盘阵列间的数据复制就转化为在同一磁盘阵列间的数据复制，这就 是 HDS 异构磁盘阵列数据

13、迁移核心所在。 对于两套同型号磁盘阵列， 可以通过阵列之间的数据复制技术来 实现数据的迁移，如目前的 HDS 的 TureCopy技术， EMC 的 SRDF 技术，都可以实现在两套磁盘阵列之间的数据迁移，并且此种方法不 占用主机资源， 对应用透明。 但是源磁盘阵列和目标磁盘阵列必须是 同一厂家的同一系列的产品， 而且迁移过程对生产系统有一定的性能 影响。 3.3.4 基于第三方工具的数据迁移 此种数据迁移的方法，利用一些第三方的工具实现数据迁移，如 Veritas的 VVR 。这种方法， 不仅需要额外购买第三方工具，实施比 较复杂，同时，对于特定的第三方工具，需要满足一些前提条件，如 Ver

14、itas的 VVR 只能基于 VxFS 文件系统上的卷复制，对于其它的 文件系统或 raw device ，则无法使用。 3.3.5 基于 HDS 存储虚拟化的数据迁移 此种数据迁移的方法，利用HDS 特有的USPv/USPvm的 UVM(Universal volume manager)+ 卷迁移复制 VolumeMigration实现数据迁移。这种方法，可以采用HDS UVM 和 Volume Migration功能软件，通过UVM 实现 USPv 对外部存 储的虚拟化管理和应用重新映射访问，然后用卷迁移软件Volume Migration将数据应用不停止的在线迁移到USPv 内部，由于不

15、涉 及主机的任何设置修改，实施比较简单, 迁移速度非常快。 数据迁移方案的比较 迁移方案是否需要计 划性停机， 几次 数据迁移速度、 性能 迁移所需要消耗的资源实施难度 操 作 系 统 镜 像数据命令 1 次可 以 根 据 业 务 情况， LUN级 灵 活 控 制 拷 贝 需要消耗较少的主机端资 源（文件系统层次镜像） 完全采用系统管理员熟悉 的文件系统命令，难度很 小但管理非常复杂，手工 速度操作容灾出错， 风险较大。 Oracle Standy by 方 式 备 份 和 恢复 2 次中等需要消耗一定的主机端资 源（数据库层次log） 取决于对数据库的熟悉程 度（注意数据库的no log 操

16、作） 磁 盘 阵 列 复 制 (只能在同 构 阵 列 间 实 施） 1-2 次较快，但不能灵 活调节 1. 需消耗阵列的控制器能 力和大量缓存资源；2. 主机IO 需增加一定的时 延，若在同机房迁移则影 响较小 需仔细规划，确保阵列和 主机之间的数据完整性。 迁移结束后测试验证可回 退性差。存在安全隐患， 实施案例很少。 第三方工具2 次速度可控TDMF需要占用5-10% 的主机系统资源 取决于数据迁移服务人员 实施能力。 HDS存储虚 拟化 +卷迁移 1 次速度最快， 非常 灵活 1不消耗任何主机资源， 需消耗阵列的控制器能力 和大量缓存资源；2. 主机 IO需增加微不足道的时 延 需要将外

17、部存储FC 端口 和 USPv 逻辑连接，以便 USPv能识别和虚拟化外 部存储的LUN, 然后通过 卷迁移将外部存储的卷在 线迁移到USPv 内部。 非常多成功案例。 4. 安徽邮政存储银行数据迁移方法 数据迁移方法的选择要依据客户的现状选择相应的迁移技术。例 如：是否可以停机做数据迁移、可以停机时间、是否需要在线做数据 迁移。 通过对多种数据迁移方法的分析和比较，根据安徽邮政存储银行 信 息 中 心的 实 际 状况 ， 由 于新 存 储 系统 选 用 的是HDS中 端 AMS2300 ，与原有高端 9970V 存储系统无法进行直接的数据复制。 因此，建议采用操作系统镜像方式的实际数据迁移方

18、案。 4.1 数据迁移方案描述 数据迁移方案架构 如上图所示，数据迁移方案需要通过操作系统的镜像，在原9970V 和新购得 AMS2300间进行数据复制。数据迁移的操作前需要对业 务系统主机进行比较繁琐的配置，需要较长的准备时间。 4.2 数据迁移方案步骤 4.2.1 数据迁移的测试 为了保证数据迁移的成功实施，必须在正式进行数据迁移前， 对 所采用的技术进行测试。一方面验证技术是否切实可行，另一方面， 通过测试，可以大致了解数据同步的速度，这样就可以计算整个数据 迁移所需要的时间。 同时，为了避免数据迁移在业务高峰时段对应用 系统的性能造成冲击， 可以根据测试得到的数据同步的速度值和每个 业

19、务低峰时段持续的时间， 把所有相关的 LV 进行分组，保证每组 LV 都可以在一个业务低峰时段完成数据同步。这样就可以把对系统性能 冲击最大的数据同步操作控制在业务低峰时断进行。 4.2.2 数据迁移的准备 1.安装并配置新储存HDS AMS2300 2.将 AMS2300划分的 LUN 按用户要求分配给相应的主机 3.在主机端识别新加的LUN （PV） AIX: #cfgmgr v #lspv Linux: #dmesg #fdisk l 4.确认原有的 HDLM是否支持 AMS2300 ，如果不支持，则需要升 级 HDLM ，具体升级步骤按HDLM手册执行，需要停机。（HDLM 不支持红旗

20、 Linux ） 5.主机认到新的 LUN （PV）后，加入到需要迁移的VG 中 #extendvg vgname hdiskx hdisky 6.确认添加后的 VG 的状态是否正常 #lsvg l vgname 4.2.3 数据迁移的实施 在准备工作完成的情况下， 就可以进行生产数据的迁移工作。为 了避免数据迁移在业务高峰时段对应用系统的性能造成冲击，可以根 据测试得到的数据同步的速度值和每个业务低峰时段持续的时间，来 确定执行数据同步的时间， 这样就可以把对系统性能冲击最大的数据 同步操作控制在业务低峰时断进行。 同步速度主要依赖于主机和存储的性能，目前2G SAN 架构下 的主流速度约在

21、150GB/小时左右，综合用户的环境保守估计同步 速度约在100GB/小时左右，而用户的关键业务数据库总数据量约 在 300GB 左右， 即迁移关键业务数据库的同步时间约在3 小时左右。 关键业务其他数据约1200GB ，迁移时间约要12 小时。 对于次关键业务数据库数据（150GB ）迁移时间约需2 小时。 次关键业务其他数据（ 500GB ）迁移时间约需 6 小时。 1.创建镜像 #mirrorvg m vgname hdiskx hdisky 2.确认镜像同步完成 #lsvg -l vgname -所有 lv 都是 syncd 状态 3.测试数据库的可用性，正常则数据库数据镜像成功 回退

22、： a.去除新加 PV 的镜像 #unmirror vgname hdiskx hdisky b.将新盘从 VG 中去除 #reducevg vgname hdiskx hdisky 4.开始停应用，确保对磁盘无任何IO 操作 5. 将 9970 的光纤线拔出，可以确保原数据保存 6.去除原有 PV 的镜像 #unmirror vgname hdiska hdiskb 7.将原盘从 VG 中去除 #reducevg vgname hdiska hdiskb #varroffvg vgname #varronvg vgname 8.启动应用，测试数据库的可用性，正常则数据库数据迁移成功 回退：

23、a. 停应用，确保对磁盘无任何IO 操作 #varyoffvg vgname #exportvg vgname b.将 9970 光纤线插回，重新识别 #cfgmgr v #importvg vgname 9.最后将原盘从系统中去除，此时可进行 HDLM 的升级工作。 #rmdev dl hdiska hdiskb 10. 收尾，数据迁移完成 4.3 迁移停机周期 在迁移时间规划上，一个重要的衡量标准是停机周期，HDS 的 迁移方法将提供最短的停机时间： 在进行设备安装、 产品配置和数据迁移时， 业务系统均不需要停 机。但在进行数据迁移前需要进行大量的操作系统镜像配置，由于在 生产系统主机中进

24、行操作， 有一定的风险性， 同时数据同步也会占用 大量的系统资源，所以需选择业务不繁忙的时间进行操作。 在完成数据迁移后 （卷镜像完成后），业务系统需要停机1-2 次， 进行原存储和新储存的切换，以及可能的HDLM升级。根据经验估 计业务系统的停机时间，大概为3 小时。 工作内容需要时间备注 准备工作 AMS2300硬件安装3 小时 AMS2300存储划分1 小时 主机新存储识别及配置0.5 小时 主机原有 VG 变更（extendvg ）0.5 小时 数据迁移 创建镜像（ mirrorvg）- 数据库数据5 小时根据情况 创建镜像（ mirrorvg）- 其他数据18 小时根据情况 数据可用性测试0.5 小时 回退1 小时 停应用，确保对磁盘无任何IO 操作0.5 小时 将 9970 从系统中去除0.5 小时 数据可用性测试0.5 小时 回退1 小时 HDLM 安装1.5 小时根据情况 收尾收尾工作1 小时