计划内外切换场景步骤详解--AIX LVM Mirror + DS8000 Metro Mirror 整体存储高可用和

两种业界成熟技术如何充分结合组成整体的存储高可用和容灾解决方案？在日常运维和站点切换流程中，又如何使增加的运维成本相对可控？

本文给出了详细可行的方案。

（本文曾是AIX高手挑战赛指定辅导资料）

原题：AIX 的存储高可用和容灾解决方案实现

作者：

杨奕 IBM Advisory IT Architect 

廖志泓 IBM 资深技术专家

朱凯 IBM IT专家

摘要：本文介绍如何结合使用 AIX LVM Mirror 和 DS8000 Metro Mirror 技术，在存储架构层面实现存储高可用的同时满足企业同城容灾需求。本文同时就该方法最受人关注的容灾切换部分，分别就计划内和计划外两种场景进行详细讨论，并结合实验，充分论证了该方案的可行性。

AIX LVM Mirror 本地存储高可用解决方案介绍

Logical Volume Manager(LVM)是 AIX 上用于逻辑卷管理的软件。LVM 本身提供 Logical Volume (LV)数据在多个 Physical Volume (PV)之间做数据镜像的功能，以达到存储的本地高可用性。在 LVM Mirror 方案中写 I/O 与底层设备交互如下图所示。

图 1. LVM Mirror 方案架构

当服务器发出写 I/O 时，该 I/O 在 Parallel 模式下会同时并行发送到两台存储设备上。如上图中 Step 1, Step 2 和 Step 1’, Step 2’。只有当 Step 2 和 Step 2’都完成时，一个写 I/O 才会被服务器认为完成。

在该解决方案中，当底层任一存储，即 PV，出现故障时，LVM 会自动将停止该 PV 上所有的 I/O 活动，并将相应读写切换到剩下的正常 PV 上。整个切换过程在 LVM 层完成，所有 LV 在故障切换过程中状态保持在线，对应用层透明。切换时间最低在 15 秒左右，甚至更短。

同城容灾解决方案介绍

DS8000 Metro Mirror (MM)技术是一种满足 Recovery Point Object (RPO)为 0 的存储级同城容灾解决方案。该方案中，数据通过存储底层的 I/O 同步复制到容灾站点来达到相应的容灾目的。在 DS8000 MM 方案中写 I/O 与不同站点间 DS8000 存储交互如下图所示。

图 2. DS8000 MM 方案架构

当服务器发出写 I/O 时，首先该写 I/O 首先放往在生产站点主存储设备上；其次该写 I/O 由生产站点主存储发往灾备站点备存储；接着备存储发回写 I/O 完成信息；最后主存储向服务端发送写 I/O 完成信息。整个过程中，每个写 I/O 保证会在生产和容灾站点间同步完成。

在该解决方案中，当生产站点发生灾难时，会触发站点切换场景，即生产站点所有设备宕机，灾备站点服务器和存储在容灾端被启用并提供服务。由于容灾端存储的数据是通过同步复制技术产生，数据与生产保持一致，从而保证了 RPO 为 0。值得注意的时 DS8000 MM 该方案本身不提供生产站点的本地存储高可用保证。当本地存储发生故障且无法恢复时，最终需要将生产切换到容灾站点。整个过程一般为几个小时或更高。

AIX LVM Mirror 结合 DS8000 Metro Mirror 解决方案介绍

AIX LVM Mirror 结合 DS8000 Metro Mirror 解决方案是一种融合两种方案优点的存储高可用加容灾解决方案。该解决方案的基本架构图如下图所示。

图 3. AIX LVM Mirror 结合 DS8000 Metro Mirror 架构

AIX LVM Mirror 结合 DS8000 Metro Mirror 解决方案其优点是显而易见的：其为企业基础架构提供本地存储高可用保护的同时，也提供了存储级同城容灾的能力。

但是在本方案中，由于生产端服务器的 AIX LVM 的 LV Copy 存在两份，而容灾端只有一份，因此在容灾端的单份 Copy 对容灾切换的影响成为客户主要关注点，主要有以下几点：

• 容灾切换时影响：容灾端应用在单份 Copy 情况下其 LVM VG 和应用是否能正常拉起，以及相应 RTO 影响。

• 生产回切时影响：生产端 LVM Mirror 能否正常重新同步，及其对生产的性能影响。

• 整个操作流程复杂度：复杂度是否可控，是否会对运维团队带来额外负担。

对于以上问题我们将分计划内和计划外两种切换场景在后续章节进行详细讨论。

AIX LVM Mirror 结合 DS8000 Metro Mirror 容灾切换和恢复步骤

一般容灾切换场景可分为计划内和计划外两种，以下章节分别就该两种场景进行讨论。所有讨论均基于实际测试结果，测试环境如下:

• 硬件为 Power 570，4 核 CPU，16G 内存。

• 操作系统 AIX 6100-05 + PowerHA 6.1.0.9，双机配置为 Active-Standby 方式。

• 应用为 Oracle 10g。（这里以 Oracle 应用为例，本方案也适用于其他应用场景。）

• 整个测试数据容量大小约为 1 TB。

计划内切换和恢复步骤

计划内切换特点在于容灾站点切换以业务验证为主，容灾端应用运行时间短，期间 AIX LVM 和存储不会做变更。因此在此短时间期间 AIX LVM 可以以非健康状态运行。针对其特点，设计 LVM Mirror + DS8000 MetroMirror 的存储架构切换流程如下图。

图 4. 计划内切换流程

步骤一，容灾切换：

• 停止生产端应用和卸载相关文件系统。

• 在生产端应用服务器执行 varyoffvg 和 exportvg 操作。

• 将 DS8000 MetroMirror Failover 到容灾端。

• 在容灾端服务器通过 importvg –f 方式导入 VG 配置信息，varyonvg。注意，importvg 增加-f 参数将保证 vg 即使在单份 copy 不存在的情况下也会被导入。

• 在容灾端启动应用。

步骤二，数据回迁：

• 将 DS8000 MetroMirror 配置从容灾端 failback 到生产端，该过程不影响容灾端应用运行。经过此步骤，生产端的两台 DS8000 数据将不一致。

步骤三，生产恢复：

• 停止容灾端应用和卸载相关文件系统。

• 在容灾端应用服务器执行 varyoffvg 和 exportvg 操作。

• 将 DS8000 MetroMirror Failover 到生产端。

• 在生产端应用服务器执行 importvg 和 varyonvg -n 操作。注意，varyonvg 增加-n 参数将保证 vg 在两份 copy 不一致的情况下不会被自动同步，而以最新 copy 为准。

• 在生产端启动应用。经过此步骤，生产应用正常启动，但是两份 DS8000 的 LV Copy 还处于不一致阶段，数据还未进行同步。

步骤四，结束：

• 在选取适当时间段，如业务不繁忙的时间，执行 syncvg 操作，将两份 LV Copy 进行同步。

至此，计划内容灾切换演练结束，生产端应用恢复正常。

计划内切换流程主要关注点讨论

以下对本方案和常规 DS8000 MetroMirror 非 LVM Mirror 容灾方案就计划内切换流程作三方面对比。

• 容灾切换时 RTO 影响和其他影响。

在容灾端进行切换的时候，相对普通 DS8000 MetroMirror 方案，由于生产端采用了 LVM Mirror 的方式，在容灾端少了一组 LV Copy，因此在容灾端服务器需要通过 importvg –f 方式在容灾端导入 vg 信息。相比直接 importvg 方式，经过实测，总计 1T 共 4 个 VG 导入过程正常，时间并未有明显增加，耗时仅增加约 2%不到，RTO 影响几乎可以忽略不计。随后应用能正常启动无异常。

• 生产回切时 RTO 影响、性能和其他影响。

当应用在生产端进行回切时，相对普通 DS8000 MetroMirror 方案，由于生产端的两份 LVM 的 LV Copy 在回切后数据不一致，需要有一个数据同步过程。由于数据同步期间性能会对生产应用造成一定影响，因此在恢复过程中，生产端 LVM 采用 varyonvg –n 的方式拉起 VG，以最快速度挂载 VG，正常启动应用，且避免数据提前同步。在应用正常运行后，挑选合适阶段设置合适的同步线程数目再进行数据同步。因此整个恢复过程中，比对普通非 LVM Mirror 方式，RTO 无影响，性能影响相对可控。

另外 LVM Mirror 重新同步的方式 Physical Partition(PP)级别的增量同步方式进行同步，因此同步数据量较少，具体大小取决于应用特征和数据规模。在本例中 1T 总容量的的重新同步的数据量约占 1/3。采用双线程同步，同步速率约 200MB 左右，同步时间约半小时。

• 整个操作流程复杂度。

在整个流程中，唯一增加的复杂度在于在生产回切时，需要重新对 LVM Mirror 的两份数据进行重新同步。在实际操作中，使用 syncvg 对整个 VG 进行同步。该过程可通过设定同步线程数来平衡同步速率和对生产的性能影响，操作相对简单直接。

计划外切换和恢复步骤

计划外切换特点在于生产站点不可用，容灾端应用运行时间可能会较长，期间 AIX LVM 和存储有可能做变更。因此在此长时间期间 AIX LVM 须以健康状态运行。针对其特点，设计其切换流程如下图。

图 5. 计划外切换流程

步骤一，容灾切换：

• 直接将 DS8000 MetroMirror Failover 到容灾端。

• 在容灾端服务器通过 importvg –f 方式导入 VG 配置信息，varyonvg。注意，importvg 增加-f 参数将保证 vg 即使在单份 copy 不存在的情况下也会被导入。

• 在容灾端启动应用。

步骤二，在线删除单份不存在的 copy：

• 使用 rmlvcopy 命令将不存在的 copy 在线删除。

• 使用 reducevg 命令将不存在的 pv 通过制定 pv id 的方式在线删除。经过该步骤后，LVM Mirror 被拆除，整个 LVM 恢复单份 copy 正常状态，容灾端应用存储可进行常规的变更。

步骤三，数据回迁：

• 在生产站点恢复后，将 DS8000 MetroMirror 配置从容灾端 failback 到生产端，该过程不影响容灾端应用运行。

步骤四，生产恢复：

• 停止容灾端应用和卸载相关文件系统。

• 在容灾端应用服务器执行 varyoffvg 和 exportvg 操作。

• 将 DS8000 MetroMirror Failover 到生产端。

• 在生产端应用服务器执行 importvg 和 varyonvgn 操作。

• 在生产端启动应用，经过此步骤，生产应用正常启动，但是只有单份 LV Copy，本地还不具备存储高可用能力。

步骤五，结束：

• 在选取适当时间段，如业务不繁忙的时间，重新执行 mklvcopy 和 syncvg 操作，实施 LVM Mirror。

至此，计划外容灾切换演练结束，生产端应用恢复正常。

计划外切换流程主要关注点讨论

以下对本方案和常规 DS8000 MetroMirror 非 LVM Mirror 容灾方案就计划外切换流程作三方面对比。

• 容灾切换时 RTO 影响和其他影响。

计划内切换流程和计划外切换流程对 RTO 影响相同，且亦能保证应用正常启动。唯一不同在于需要额外使用 rmlvcopy 和 reducevg 命令将多余的不存在的 lv copy 删除，保证系统正常长时间运行。在本例中整个过程操作不到半小时完成，且此过程对生产透明，亦可在线运行，因此影响很低。

• 生产回切时 RTO 影响、性能和其他影响。

计划外的生产回切其实和常规 DS8000 MetroMirror 非 LVM Mirror 容灾方案计划外回切相同，因此无 RTO 影响和性能影响。但是为了恢复到本地存储高可用状态，需要重新建立 LVM Mirror 关系，因此在这里多了重新实施 LVM Mirror 的过程。整个过程长短与应用规模有关系。在本例中 1TB 的数据量采用双线程同步速率大约 200MB 左右，总计后台同步时间约一个半小时，加上实际操作时间总计约两个半小时左右。

• 整个操作流程复杂度。

在整个流程中，增加的复杂度主要在于切换时在容灾端需要在线删除不存在的 lv copy，在生产回切后，需要重新再次实施 LVM Mirror。这些操作虽然相对比较复杂，但在理论和实际实验中都能对应用做到透明，在性能方面通过合理规划都能将影响降到最低。

结论

AIX LVM Mirror 和 DS8000 Metro Mirror 分别是业界内成熟的技术。通过实践证明，其两者结合可以充分结合组成一种整体的存储高可用和容灾解决方案。该方案有效为客户消除了本地存储单点故障和带来了同城容灾能力的同时，在日常运维，特别是站点切换流程中，使增加的运维成本相对可控。