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

在容灾端进行切换的时候，相对普通 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. 计划外切换流程

查看本栏目更多精彩内容：http://www.bianceng.cn/OS/unix/

步骤一，容灾切换：

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

请注意，本文中的方案并不一定适用于您的 IT 环境或问题。具体情况请经过实际测试或咨询当地 IBM IT 专家进行论证。

（编辑：济南站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!