数据中心和服务的可用性是IT基础架构最重要的主题之一，并且每天都引起更多关注。 站点之间的数据复制是最大程度地减少业务中断的好方法，因为备份还原操作可能需要很长时间才能满足业务需求，或者设备可能会损坏，并且根据灾难的程度，可能无法恢复数据。 恢复选项的成本从最便宜的（需要更长的恢复时间）到最昂贵的（提供最短的恢复时间，最接近零数据丢失）不等。

PowerHA SystemMirror 7.1.2 Enterprise Edition提供了一种这样的灾难恢复和高可用性解决方案，可帮助自动执行节点故障和应用程序事件并提供高可用性。 它有助于针对选定存储的存储故障自动执行恢复操作，控制站点之间（不同数据中心）之间的存储复制，并实现整个站点故障的恢复，从而确保副本处于一致状态以进行故障转移，从而使您能够构建灾难恢复解决方案。

HyperSwap是PowerHA SystemMirror 7.1.2 Enterprise Edition产品组合的产品之一。 此功能可针对存储错误提供连续可用性。 它基于基于存储的同步复制[对等远程复制（PPRC）或Metro Mirror]。 在定向时（或在磁盘发生故障时），访问主磁盘子系统的IBMAIX®主机可能会透明地切换到数据的备份副本，以使磁盘的客户（例如中间件）不受影响。

背景

HyperSwap是几年前最初在GDPS中引入的一项功能，适用于Metro Mirror PPRC（​​同步）环境，该环境通过促进立即切换PPRC镜像磁盘子系统来增强Parallel Sysplex的弹性。

HyperSwap技术使主机可以透明地将应用程序的I / O操作切换到辅助Metro Mirror卷，前提是主机和辅助存储子系统之间存在物理连接。 这提供了从一个站点或地铁距离内的多个位置提供连续操作的能力。 通过实施HyperSwap，可以承受磁盘故障和维护功能，而不会中断应用程序服务。

该解决方案可以为客户提供更好的灾难恢复解决方案，并可以证明PowerHA与IBM存储的紧密集成。

HyperSwap技术可以使PowerHA SystemMirror为客户支持以下功能：

• 消除作为主要故障点的主磁盘子系统，以在城域距离内提供下一级别的连续操作支持。
• 启用存储维护，而无需任何应用程序停机。
• 启用从旧存储到新存储的迁移。

所有这些用例均属于HyperSwap活动的两种类型之一：

• 计划外的HyperSwap ：当主存储发生故障时，承载应用程序的OS通过执行PPRC故障转移来检测事件并做出React，从而将应用程序的I / O活动透明地重定向到辅助存储子系统，从而允许应用程序继续运行没有任何中断。 请注意，在这种情况下，操作系统中的操作系统的小型计算机系统接口（SCSI）磁盘驱动程序会检测到错误，并在多个主机之间做出决定以完全切换到辅助存储子系统。 在HyperSwap交换过程中，I / O活动将暂时冻结，无法继续进行。 在这段时间内，请注意，应用程序不会遇到故障，而是会遇到非致命的延迟。

• 计划的HyperSwap ：在这种情况下，管理员会主动从主存储子系统到辅助存储子系统启动HyperSwap。 当管理员请求计划的HyperSwap时，在群集中的主机之间进行协调后，将冻结I / O活动。 执行交换，然后允许I / O操作继续。 计划的HyperSwap对在主存储上执行维护任务以及将数据从旧存储迁移到新购买的存储子系统很有帮助。

图1：PowerHA SystemMirror HyperSwap配置示例

AIX对HyperSwap的支持

图2显示了支持HyperSwap的组件。

图2：HyperSwap的AIX组件

与AIX的HyperSwap相关的组件包括：

• 集群感知AIX（CAA）
  • 编排集群范围内的动作
• PowerHA HyperSwap内核扩展
  • 与CAA合作以协调与其他节点的行动
  • 分析来自PowerHA框架和AIX存储框架的消息并采取适当的措施
  • 确定交换动作
• AIX存储框架
  • 使用带有存储的AIX界面
  • 与PowerHA HyperSwap内核扩展紧密合作
  • 管理存储状态
  • 通知PowerHA HyperSwap内核扩展有关I / O错误的信息
  • 从PowerHA HyperSwap内核扩展获取交换决定，并将订单发送到AIX PCM（MPIO）

好处

PowerHA对HyperSwap的支持具有以下优点：

• 提供持续的可用性以防止存储故障
• 替换辅助存储来代替发生故障的主设备
• 无干扰，并保持应用程序运行
  

  图3：PowerHA集群HyperSwap支持

  
• 对应用程序透明
  

  图4：HyperSwap磁盘表示

  
• 支持跨IBM SystemStorage®DS8000®系统的一致性组管理
• 为关键系统磁盘提供HyperSwap支持，包括：
  • 根vg
  • 分页设备
  • 转储设备
  • 储存库磁盘
• 提供磁盘分组支持
• 提供对AIX逻辑卷管理器（LVM）和原始磁盘的支持
  • 磁盘或VG复制
  • 磁盘错误处理
  • Oracle可以与LVM或地址空间管理器（ASM）磁盘一起部署
• 为多站点部署提供支持
  • 计算节点中断
    • 主动-主动工作负载提供持续可用性
  • 仓储中断
    • HyperSwap提供持续可用性
  • 主动被动站点
    • 站点内的双活工作负载
    • 跨站点主动-被动
    • 站点存储中断的连续可用性

图5：主动-被动HyperSwap

要求

本节列出了PowerHA SystemMirror Enterprise Metro Mirror HyperSwap支持的硬件和软件要求。

硬件要求

PowerHA SystemMirror HyperSwap的硬件要求包括：

• DS8800存储设备
• 电源固件级别：IBMPOWER7®或更高
• DS8800固件：6.3或更高版本，微代码：86.30.49.0或更高版本
• 地铁镜牌照
• 存储子系统之间的存储区域网络（SAN）连接
• Metro Mirror的存储之间的光纤通道（FC）连接

软件需求

使用PowerHA配置HyperSwap的软件要求包括：

• PowerHA企业版7.1.2版
• AIX 6.1 TL8或AIX 7.1 TL2
• IBM DSCLI 7或更高版本

注意事项

在计划使用PowerHA的HyperSwap时，需要记录以下注意事项。

• HyperSwap for PowerHA仅在IBM DS8800设备上受支持
• 当前不支持跨站点的并行工作负载，例如Oracle RAC。 请注意，这可能会在将来的版本中更改。
• 存储子系统之间的SAN连接
• 虚拟SCSI（VSCSI）不支持DS8800 Metro Mirror（带内）功能，包括HyperSwap。
• 要使用实时分区移动性（LPM），必须为所有联机镜像组禁用HyperSwap。 LPM完成后，启用HyperSwap。
• 磁盘复制关系必须遵守基础逻辑子系统（LSS）之间的一对一关系。
• 使用HyperSwap功能的镜像组不支持SCSI保留
• 交换时间必须计算。 这是PowerHA在镜像组上执行HyperSwap操作时导致的I / O延迟时间（以秒为单位）。 交换超时值特定于群集中的每个镜像组。 计划的HyperSwap的交换超时为120秒，无法更改。 计划外的HyperSwap的交换超时在0到180秒之间。 要确定计划外的HyperSwap的交换超时，应考虑以下因素：
  • 托管应用程序的节点数。 节点数越大，意味着共享更多的信息。
  • 网络延迟和应用程序网络使用率。
  • 应用程序使用的磁盘数。
  • 应用程序的I / O响应时间要求。

性能考量

请注意以下性能注意事项，这一点很重要。

• HyperSwap处理将以有时间限制的方式执行（时序特性应可调整，并由AIX Storage Framework强制执行）。

• 在处理计划内或计划外的HyperSwap时，与其他群集节点的网络通信可以作为尽力而为的操作。 预计这些通信重量较轻，应尽力使响应时间短。

• 由于带内通信，使用DS8800带内Metro Mirror的资源组的计划故障转移预计将很快完成。 传统上，带外性能次优（由于DSCLI性能问题）。

实施注意事项

在计划实施时应牢记以下注意事项：

• DS8800上的I / O冻结操作在整个LSS上运行。 如果单个DS8800 LSS包含来自多个应用程序的PPRC卷，并且其中一个复制链接断开，则所有PPRC路径都将被销毁。 而且，如果其中一些应用程序不是由PowerHA管理的，则客户必须手动重新创建某些PPRC路径。
• 任何存储级PPRC配置更改后，PowerHA重新发现实用程序都必须运行。 这包括在任何时候执行新PPRC路径的更新（例如添加，删除或更改）。 此外，在此时间窗口内执行（或自动触发）的HyperSwap功能可能会导致意外行为。
• 磁盘复制关系必须遵守基础LSS之间的一对一关系。
• 为存储库磁盘启用HyperSwap将需要指定备用磁盘。
• 使用原始磁盘的应用程序应提前打开所有磁盘以启用HyperSwap功能。
• HyperSwap不会自动将SCSI保留（如果有）从主磁盘转移到辅助磁盘。

限制与限制

在计划使用PowerHA的HyperSwap时，请牢记以下限制和当前限制：

• VSCSI不支持带有PowerHA的HyperSwap。
• 仅在IBM DS8800和更高版本的系统上支持它。
• 必须预先定义存储级PPRC关系和PPRC路径（在PowerHA配置之前）。
• DS8800的冻结操作在整个LSS上运行。 如果单个DS8800 LSS包含来自多个应用程序的PPRC卷，并且其中一个复制链接断开，则所有PPRC路径都将被销毁。 如果其中一些应用程序不是由PowerHA管理的，那么客户将必须手动重新创建某些PPRC路径。
• 在执行任何存储级PPRC配置更改（例如，添加，删除或更改新的PPRC路径）之后，必须运行PowerHA重新发现实用程序。 此外，在此时间窗口内执行（或自动触发）的HyperSwap功能可能会导致意外或不良行为。
• 受基本AIX设备驱动程序支持的限制，应可提供对实时分区移动性（LPM）的支持。
• rootvg镜像组上的HyperSwap启用/禁用操作应适用于群集的所有节点。 同样，对存储库磁盘镜像组的HyperSwap启用/禁用操作应适用于两个站点。
• 磁盘复制关系必须遵守基础LSS之间的一对一关系。
• 为存储库磁盘启用HyperSwap将需要指定备用磁盘。
• 使用原始磁盘的应用程序有望提前打开所有磁盘，并且在满足此条件之前，HyperSwap功能可能不可用。
• 对于由PowerHA Inband / HyperSwap支持管理的磁盘，不支持在PowerHA外部执行的PPRC操作，这可能会导致未定义或意外的结果。
• 不能同时访问同一（主）PPRC磁盘但跨越多个站点的并发工作负载。 将来可能会改变。
• 不支持对PPRC主卷和PPRC辅助卷执行I / O的主动-主动工作负载。

初始磁盘配置

在开始之前，请注意以下几点：

• 使用了AIX路径控制模块（PCM）驱动程序。 输入以下命令，将属于存储系统的所有磁盘配置为使用AIX_AAPCM驱动程序。 将需要重新启动。
  manage_disk_drivers –d device –o AIX_AAPCM
• HyperSwap镜像组中使用的磁盘不支持SCSI保留。 验证是否未设置磁盘预留。
  devsrv –c query –l hdisk_name
  
  该命令返回以下数据：
  ODM Reservation Policy : NO RESERVE
Device Reservation Policy : NO RESERVE
• 要创建HyperSwap磁盘，请先在存储子系统和AIX中准备磁盘对，然后再在PowerHA中进行配置。
  1. 选择两个磁盘（每个子系统一个），以对HyperSwap磁盘进行镜像。 选择两个磁盘，每个存储子系统中一个磁盘，以配对PPRC（​​例如，hdiskA和hdiskB）。

     我们需要两个磁盘，每个DS8800存储系统一个磁盘。 已经使用的磁盘可以用于HyperSwap； 但是，必须特别注意确保数据完整性。

     / opt / ibm / dscli / bin中的lshostvol.sh命令显示磁盘属性，包括存储系统LSS ID。 卷ID包含以下数据：

     <vendor_name>.<storage_type>-<serial_number>/<LSS_ID><volume_ID>

     示例： IBM.2107-75TL771/BC00

     选择两个磁盘进行PPRC对。 要创建PPRC对，我们需要两个存储都使用WWPN，这可以通过lssi命令从每个存储系统中获得。

     我们还需要知道可用于连接这对磁盘的端口号。 可以使用lsavailpprcpair命令获得它。

  2. 建立从hdiskA到hdiskB的连接路径（使用mkpprcpath命令）。

     我们使用从hdiskA建立连接路径hdiskB mkpprcpath DSCLI命令，并使用检查状态lspprcpath命令。

     句法：

     /opt/ibm/dscli/dscli/mkpprcpath –dev <Local Storage ID -srclss <Source LSS ID> 
     -tgtlss <Target LSS ID> -remotewwnn <Remote Storage WWNN> <IO Port1>:<IO Port2>

     例：

     /opt/ibm/dscli/dscli/mkpprcpath –dev IBM.2107-75TL771 
     –srclss 9A –tgtlss BC –remotewwnn 50050763081B06D4 I0102:I0334

  3. 建立从hdiskB到hdiskA的连接路径（使用mkpprcpath命令）。

     我们可以使用从hdiskB建立连接路径hdiskA mkpprcpath DSCLI命令，并使用检查状态lspprcpath命令。

     句法：

     /opt/ibm/dscli/dscli/mkpprcpath –dev <Local Storage ID -srclss <Source LSS ID> 
     -tgtlss <Target LSS ID> -remotewwnn <Remote Storage WWNN> <IO Port1>:< IO Port2>

     例：

     /opt/ibm/dscli/dscli/mkpprcpath –dev IBM.2107-75LY981 
     –srclss BC –tgtlss 9A –remotewwnn 500507630AFFC16B I0334:I0102

  4. 在一个方向上建立hdiskA和hdiskB的卷对（使用mkpprc命令）。

     现在，我们使用mkpprc命令在一个方向上建立hdiskA和hdiskB的卷对。

     句法：

     /opt/ibm/dscli/dscli/mkpprc –dev <Local Storage ID> -remotedev 
     <Remote Storage ID> -mode <value> -type <mmir/gcp> <Local LSS>:<Remote LSS>

     例：

     /opt/ibm/dscli/dscli/mkpprc –dev IBM.2107-75TL771 
     –remotedev IBM.2107-75LY981 –mode full –type mmir BC00:9A00

  5. 在所有节点上（使用chdev命令从所有节点上）为hdiskA启用HyperSwap。

     接下来，我们需要为PPRC对启用HyperSwap功能。 使用chdev命令使磁盘具有HyperSwap功能。

     句法：

     $ chdev –a san_rep_cfg=migrate_disk –l hdiskX –U

     例：

     $ chdev –a san_rep_cfg=migrate_disk –l hdisk25 –U

     命令成功后，辅助磁盘将不可用。 更改为定义状态。 对所有其他节点重复此步骤。

与HyperSwap有关的AIX可调参数

本节介绍了为HyperSwap设置的一些可调参数。

表1：HyperSwap相关的配置设置

表中引用的大多数值是AIX 7.1中的缺省设置。 但是，可能需要将它们设置为AIX 6.1上表1中所示的值。

与HyperSwap相关的活动取决于两个时间组件，即故障检测时间和实际交换时间。

• 故障检测时间取决于故障的环境和情况，并且与上表中提到的许多时间部分有关。 超时和重试是失败声明时间的重要部分。
• 实际交换时间取决于AIX设备驱动程序和PowerHA集群组件一起工作，以建立对HyperSwap的需求，在整个集群中进行协调，然后执行实际交换（任何网络问题都可能导致网络协调方面的延迟，并可能导致超时/延迟或HyperSwap失败）。 交换操作时间本身取决于磁盘数量，因此取决于DS8800执行交换所花费的时间。 此外，实际的交换时间取决于发出交换操作时遇到的软可恢复错误的超时和重试（如果有）。

表2提供了与交换时间有关的度量标准，以及它在各种情况下对应用程序的影响。

表2：交换时间指标

PowerHA配置

在满足所有先决条件并完成初始磁盘配置之后，我们需要配置PowerHA SystemMirror集群并将HyperSwap磁盘添加到资源组。 您需要执行以下步骤来配置PowerHA。

1. 确保已安装所有必需的文件集（包括cluster.es.genxd） 。
2. 在所有节点上填充要用于通信路径的IP标签的CAA rhosts文件（/ etc / cluster / rhosts）。 重新启动clcomd守护程序。
3. 通过smitty sysmirror > 群集节点和网络 > 多站点群集部署 > 设置群集，节点和网络来配置群集 。 选择集群类型为“ 拉伸”或“ 链接” 。 对于我们的测试，我们使用Stretched 。
4. 然后，选择要由CAA使用的存储库磁盘和多播地址。 这可以通过smitty sysmirror > 群集节点和网络 > 多站点群集部署 > 定义存储库磁盘和群集IP地址来完成。
5. 验证并同步集群。 成功完成验证过程后，将配置CAA群集。
6. 使用支持HyperSwap的磁盘为所有节点创建一个卷组。
7. 定义存储和站点关联。 使用路径smitty cm_add_strg_system或smitty sysmirror > 群集应用程序和资源 > 资源 > 配置DS8800 Metro Mirror（带内）资源 > 配置存储系统 > 添加存储系统 。 也对辅助站点存储重复此步骤。
8. 为HyperSwap磁盘设置以下镜像组。
   • 用户镜像组
   • Cluster_repository镜像组
   • SystemMirror组

   使用路径smitty cm_cfg_mirror_grps或smitty sysmirror >群集应用程序和资源 > 资源 > 配置DS8800 Metro Mirror（带内）资源 > 配置镜像组 > 添加镜像组。 您可以选择配置user ， system或cluster_repository镜像组。 有关各种镜像组的更多详细信息，请参阅IBMRedbooks®的PowerHA SystemMirror 7.1.2 Enterprise Edition for AIX 。

9. 创建具有站点策略的资源组。 选择“ 首选主站点”或“在任一站点上联机”作为站点间管理策略。
10. 将镜像组和卷组添加到资源组。 使用smitty sysmirror > 群集应用程序和资源 > 资源组 。
11. 验证并同步。
12. 启动群集服务。

提示

以下提示可在配置过程中提供帮助，并有助于实现高可用性。

• 每个DS8800在生产中使用多个控制器，以实现高可用性。
• 在生产环境中，建议将存储库磁盘放在两个站点上（通过使用链接集群安装程序），以避免站点故障，从而对系统造成多重影响，或者使用HyperSwap功能支持存储库镜像组。
• 建议遵循以下规则，以实现HyperSwap的更好性能：
  • 尽可能将同一应用程序的所有HyperSwap磁盘保留在同一LSS中。
  • 尽可能不要在同一个LSS中混合使用不同应用程序的HyperSwap磁盘。
• 最佳做法是在使用磁盘之前修改可调参数。 您可以使用chdev命令更改可调参数：
  # chdev –l hdiskX –a rw_timeout=60
• 您可以将PowerHA工具用于计划的HyperSwap。 这可用于维护存储子系统，从而不会中断应用程序。
• 应用程序或数据库的所有群集节点上的用户和组定义必须相同。
• 对于AIX上的Oracle 11g，为了在分配共享内存时允许操作系统使用16 MB页面或固定内存，Oracle用户ID必须设置以下功能： CAP_BYPASS_RAC_VMM和CAP_PROPAGATE 。

翻译自: https://www.ibm.com/developerworks/aix/library/au-aix-hyper-swap/index.html

在本文中，我将分享一些在虚拟I / O（VIO）环境中构建PowerHA™集群的技巧。 我将简要描述一个简单的两节点PowerHA集群的LPAR和VIO服务器（VIOS）设计和布局。 但是，我将不涉及特定的PowerHA配置，因为该主题太大而无法在此处详细介绍。 有关详细信息，请参考IBM PowerHA官方文档（请参阅参考资料 ）。 本文还假定您具有AIX®，VIO和PowerHA的经验。

总览

本文涵盖的示例环境由两个POWER6®595服务器组成。 每个595都配置有双VIO服务器以实现冗余，并且已经在两个物理框架之间构建了两个节点的群集，即，一个PowerHA节点驻留在每个Power 595服务器上。 LPAR正在运行带有PowerHA 5.4.1.3。的AIX 5.3 TL7 SP5。 每个VIOS都在整个虚拟I / O环境中使用1.5.2.1-FP11.1版构建。 图1显示了此配置。

图1. PowerHA集群概述

在以下各节中，我将简要介绍群集节点的虚拟网络和虚拟（共享）存储配置。 我将特别强调以下方面：

• PowerHA引导和服务网络以及地址
• PowerHA网络的共享以太网适配器（SEA）配置
• 共享卷组注意事项

虚拟网络

虚拟网络配置是PowerHA配置的重要方面。 图2显示了VIOS网络的配置方式。 在此示例中，在一个595帧上。 VIOS网络配置在第二帧上重复。 （ 单击以查看大图。）

图2. VIOS网络概述

如图2所示，有PowerHA和非HA LPAR作为同一VIOS对的客户端。 您还将注意到多个SEA，即每个VLAN和一种使用类型： SEB ， BACKUP和PowerHA 。 每个VLAN都有一个唯一的IP范围： PUBLIC 10.2.2， BACKUP 10.3.3和PowerHA 10.1.1。 10.4.4网络上的每个LPAR上也都有一个接口，用于通过POWER Hypervisor虚拟网络在LPAR之间进行内部（专用）通信。

HA节点通过VLAN40（PVID40 / 41）（即PowerHA网络）与外界通信。 非HA LPAR通过PUBLIC网络通过VLAN10（PVID10）进行通信。 每个VIOS还在VLAN20上还有另一个SEA，用作网络上备份的专用VLAN，因此称为网络名称BACKUP 。

同时为PUBLIC和BACKUP网络配置了共享以太网适配器故障转移（SEA FO）。 PowerHA网络没有SEA FO。 如果针对PowerHA网络的VIA上的SEA失败，则服务IP将移至由冗余VIOS服务的另一个引导适配器。

没有任何SEA使用VLAN标记。 不需要，因为此网络中只有少数几个VLAN需要处理。 但是，您的要求可能会有所不同。

使用cltopinfo命令查看PowerHA集群网络时，每个节点上的网络定义如下：

清单1.网络定义

# cltopinfo
Cluster Name: CLUSTER-A
Cluster Connection Authentication Mode: Standard
Cluster Message Authentication Mode: None
Cluster Message Encryption: None
Use Persistent Labels for Communication: No
There are 2 node(s) and 3 network(s) defined

NODE aix01adm:
        Network net_diskhb_01
                aix01adm_hdisk1_01    /dev/hdisk1
        Network net_ether_01
                aix01adm		10.2.2.8
        Network net_ether_02aix01			10.1.1.12
                aix01b2v1		10.1.1.76
                aix01b1v2		10.1.1.140

NODE aix02adm:
        Network net_diskhb_01
                aix02adm_hdisk1_01    /dev/hdisk1
        Network net_ether_01
                aix02adm		10.2.2.15
        Network net_ether_02
                aix01			10.1.1.12
                aix02b1v3		10.1.1.77
                aix02b2v4		10.1.1.141

Resource Group HARG1
        Startup Policy		Online On Home Node Only
        Fallover Policy	Fallover To Next Priority Node In The List
        Fallback Policy	Never Fallback
        Participating Nodes	aix01adm aix02adm
        Service IP Label	aix01

如您所见，服务适配器和引导适配器都在同一个子网（分段的）IP网络中，其中b1v1定义与第一个VIOS（v1）关联的第一个引导适配器（b1），依此类推。 服务地址是没有附加adm的hostname 。

清单2.服务和启动适配器

Service address:	aix01		10.1.1.12	
							Netmask 255.255.255.192 
							IP range 10.1.1.1 - 62

boot1 address:		aix01b1v1		10.1.1.76	
							Netmask 255.255.255.192
							IP range 10.1.1.65 - 126

boot2 address:		aix01b2v2		10.1.1.140	
							Netmask 255.255.255.192
							IP range 10.1.1.129 - 190

boot1 address:		aix02b1v3		10.1.1.77	
							Netmask 255.255.255.192
							IP range 10.1.1.65 - 126

boot2 address:		aix02b2v4		10.1.1.141
							Netmask 255.255.255.192
							IP range 10.1.1.129 - 190

通常，在VIOS上配置SEA时，应部署SEA故障转移以确保在VIOS发生故障时保护网络连接。 但是，在此PowerHA环境中，方法不同。 SEA FO不用于PowerHA网络。 这样，PowerHA可以知道并控制网络故障和故障转移。 在这种情况下，每个VIOS中都有一个针对PowerHA网络的SEA。 如果VIOS发生故障，服务地址将移至冗余VIOS服务的引导适配器。

此方法的主要驱动因素是PowerHA集群在虚拟网络环境中进行通信的方式。 如果配置了SEA FO且发生了故障，则HA将无法检测到故障。 同样，如果物理层上的所有通信都丢失了，则HA仍会认为网络正常，因为它仍然能够在虚拟机管理程序上通过虚拟LAN路由流量。

这就是为什么在群集中的所有节点上配置netmon.cf文件很重要的原因。

该文件指导HA如何确定何时失去与网络或其伙伴HA节点的连接。 如果未正确配置此文件，那么PowerHA可能无法检测到网络故障。

netmon.cf文件和VIO

与在VIO环境中配置netmon.cf文件有关，我建议您回顾两个APAR。 您很快就会了解此文件为何如此重要以及何时应实施。

APAR IZ01331描述了将VIO与PowerHA集群一起使用的场景以及检测网络故障时面临的挑战。 例如，如果从网络上拔出了整个CEC，则该Frame上的PowerHA节点将不会检测到本地适配器关闭事件，因为在VIO客户端之间（在同一框架上）传递的流量看起来像来自该VEC客户端的正常外部流量。 LPAR操作系统的视角 。”

为了解决此问题，netmon.cf文件用于允许客户声明给定的适配器仅在可以ping通一组指定目标的情况下才应考虑使用。

如果VIOS在同一网络上具有多个物理接口，或者在同一帧中有两个或多个使用一个或多个VIOS的PowerHA节点，则不会通知PowerHA（因此不会对单个物理接口故障做出React）。

在极端情况下，由VIO服务器管理的所有物理接口均发生故障，VIOS将继续在同一帧中将流量从一个LPAR路由到另一个LPAR，PowerHA使用的虚拟以太网接口不会被报告为发生故障，而PowerHA将不React。

群集中的每个节点都有一个自定义的netmon.cf文件，该文件列出了它必须能够ping通以将接口标记为向上或向下的所有IP地址。 例如， aix01adm驻留在框架1（595-1）上，而aix02adm驻留在框架2（595-2）上。 如果595-1上所有VIOS上所有物理接口的所有网络连接丢失，则aix01adm仍将继续运行，因为它仍能够通过虚拟网络路由数据包。 为了使该节点（和其他节点）能够检测到问题，请在netmon.cf文件中填充它应该能够在特定接口上访问的地址。 如果不能，则将这些接口标记为已关闭，并且PowerHA能够做出相应的React。

APAR IZ01874阐明了如何为netmon.cf文件选择IP地址。 该文件应包含不在集群配置中的远程IP地址和主机名，可以通过PowerHA网络接口进行访问。 这些地址之前必须加!REQD 。

目标的一些不错的选择是名称服务器（DNS服务器）和网关（路由器），或者将响应ping的可靠外部IP地址（例如NTP服务器）。 您可以使用以下ping命令来验证将在特定接口上应答ping：

# ping -S <Boot IP address> <IP addr in netmon.cf>

其中<Boot IP address>是在引导接口上配置的IP地址。 例如，

清单4.特定接口上的ping命令响应

# ping -c5 -S aix01b1v1 aix02b1v3
PING bxaix04b1v1: (10.1.1.77): 56 data bytes
64 bytes from 10.1.1.77: icmp_seq=0 ttl=255 time=0 ms
64 bytes from 10.1.1.77: icmp_seq=1 ttl=255 time=0 ms
64 bytes from 10.1.1.77: icmp_seq=2 ttl=255 time=0 ms
64 bytes from 10.1.1.77: icmp_seq=3 ttl=255 time=0 ms
64 bytes from 10.1.1.77: icmp_seq=4 ttl=255 time=0 ms

----aix02b1v3 PING Statistics----
5 packets transmitted, 5 packets received, 0% packet loss
round-trip min/avg/max = 0/0/0 ms

清单5显示了来自两个节点的两个不同物理帧上的一些netmon.cf示例。

清单5. netmon.cf示例

HOST: aix01adm 595-1
--------------------
# Care is required when modifying this file!
# The nature of the VIO/PowerHA environment means the contents
# of netmon.cf on each cluster node is different.
# IP labels/addresses on virtual interfaces in any VIO client LPAR
# within this server frame, must be excluded from this file!
!REQD aix01b1v1 10.2.2.1
!REQD aix01b2v2 10.2.2.1
!REQD aix01b1v1 10.1.1.1
!REQD aix01b2v2 10.1.1.1
!REQD aix01b1v2 10.1.1.77
!REQD aix01b2v2 10.1.1.141
!REQD aix01b1v1 aix02b1v3
!REQD aix01b2v2 aix02b2v4
!REQD aix01b1v1 10.1.9.2
!REQD aix01b2v2 10.1.9.3
10.2.2.1
10.1.9.2
10.1.9.3
ntp-srvr
ntp-srvr

HOST: aix02adm 595-2
--------------------
# Care is required when modifying this file!
# The nature of the VIO/PowerHA environment means the contents
# of netmon.cf on each cluster node is different.
# IP labels/addresses on virtual interfaces in any VIO client LPAR
# within this server frame, must be excluded from this file!
!REQD aix02b1v3 10.2.2.1
!REQD aix02b2v4 10.2.2.1
!REQD aix02b1v3 10.1.1.1
!REQD aix02b2v4 10.1.1.1
!REQD aix02b1v3 10.1.1.76
!REQD aix02b2v4 10.1.1.140
!REQD aix02b1v3 aix01b1v1
!REQD aix02b2v4 aix01b2v2
!REQD aix02b1v3 10.1.9.2
!REQD aix02b2v4 10.1.9.3
10.2.2.1
10.1.9.2
10.1.9.3
ntp-srvr
ntp-srvr

如果以一行为例，

!REQD aix01b1v1 aix02b1v3

!REQD标记指定适配器（aix01b1v1）可以对目标（aix02b1v3）进行ping操作。 aix01b1v1条目指定要用于测试的接口，即aix01b1v1解析为10.1.1.76，这是en2接口上的地址。 如果能够ping通目标aix02b1v3，则该接口将被视为已启用。

清单6.确定适配器主机名

# host aix01b1v1
aix01b1v1 is 10.1.1.76

# ifconfig en2
en2: flags=1e080863,480<UP,BROADCAST,NOTRAILERS,RUNNING,SIMPLEX,MULTICAST,GROUPRT,64BIT,CHECKSUM_OFFLOAD(ACTIVE),CHAIN>
        inet 10.1.1.76 netmask 0xffffffc0 broadcast 10.1.1.127
        inet 10.1.1.12 netmask 0xffffffc0 broadcast 10.1.1.63
         tcp_sendspace 262144 tcp_recvspace 262144 rfc1323 1

en2将用于连接到aix02b1v3，这是其595-2上其伙伴节点上的接口。 如果无法通信，则接口en2（aix01b1v1）将被标记为关闭。 不要在此文件中包含同一框架上存在的任何节点。 所有条目都应针对驻留在物理框架之外的系统，以确保检测到物理（非虚拟）网络上外界发生的实际物理网络故障。

注意不要在netmon.cf文件中指定接口名称，例如：

!REQD en2 10.1.1.10

包括接口名称在VIO环境中不起作用。 我上次检查时，HA开发团队加入了设计变更请求（DCR），以解决此问题。 由于RSCT（netmon）确定netmon.cf中的第二个字段是IP /主机名还是接口名称，某些客户的接管速度很慢。 在某些情况下，netmon将尝试解析主机名的IP地址，例如$ host en2 ，它将失败。 IBM开发人员正在研究一种新的算法，以防止接口名称被视为主机名，特别是对于诸如enX之类的明显格式。 现在，最好在netmon.cf文件中取消使用接口名称，例如en X。

建议仅在您的VIO环境中使用netmon.cf方法。 使用此方法可以从“我可以接收任何网络流量吗？”来更改所谓的良好适配器的定义。 到“我可以成功ping通某些地址吗？（无论我​​能看到多少流量）”。

这会使适配器更容易被错误地认为是宕机。 如果必须使用此新功能，建议您为需要监视的每个接口包含尽可能多的目标。

虚拟（共享）存储

有关PowerHA和虚拟SCSI（VSCSI）的IBM技术文档明确定义了VIO环境中受支持的存储配置。 共享卷组（VG）必须定义为“增强的并发模式”。 通常，增强型并发模式是在PowerHA集群中共享卷组的推荐模式。 在这种模式下，多个PowerHA节点可以访问共享的卷组，从而在发生节点故障时可以更快地进行故障转移（磁盘接管）。 这些共享磁盘上的所有卷组管理都是通过PowerHA节点而不是VIOS完成的。

在示例环境中，在主节点上运行lspv确认共享卷组处于并发模式。

清单7.在主节点上运行lspv

root@aix01adm / # lspv
hdisk0  00c79a70a6858137          rootvg
hdisk1  00c79a70a20c321c          sapvg           concurrent

图3显示每个节点上有两个卷组。 每个节点都有自己的（非共享的）根卷组（ rootvg ）。

图3. VIOS VSCSI概述

主节点拥有共享卷组并处于激活状态，因此拥有所有权。 我可以通过在主服务器上运行lsvg命令并注意其某些特征来确认这一点。 VG STATE处于活动状态， VG Mode为并发， Concurrent设置为增强型功能，并且VG PERMISSION处于读/写状态。 共享卷组中的逻辑卷处于打开状态。

清单8.在主节点上运行lsvg

root@aix01adm / # lsvg sapvg
VOLUME GROUP:       sapvg                    VG IDENTIFIER:  00c79a6000004c0000000123a2278720VG STATE:           active                   PP SIZE:        64 megabyte(s)
VG PERMISSION:      read/write               TOTAL PPs:      6398 (409472 megabytes)
MAX LVs:            256                      FREE PPs:       1596 (102144 megabytes)
LVs:                13                       USED PPs:       4802 (307328 megabytes)
OPEN LVs:           13                       QUORUM:         2 (Enabled)
TOTAL PVs:          1                        VG DESCRIPTORS: 2
STALE PVs:          0                        STALE PPs:      0
ACTIVE PVs:         1                        AUTO ON:        no
Concurrent:         Enhanced-Capable         Auto-Concurrent: Disabled
VG Mode:            Concurrent
Node ID:            2                        Active Nodes:       1
MAX PPs per VG:     32512
MAX PPs per PV:     4064                     MAX PVs:        8
LTG size (Dynamic): 256 kilobyte(s)          AUTO SYNC:      no
HOT SPARE:          no                       BB POLICY:      relocatable

root@aix01adm / # lsvg -l sapvg
sapvg:
LV NAME             TYPE       LPs     PPs     PVs  LV STATE      MOUNT POINT
oraclelv            jfs2       192     192     1    open/syncd    /oracle
sapmnt_CG1lv        jfs2       144     144     1    open/syncd    /sapmnt
usrsap_CG1lv        jfs2       144     144     1    open/syncd    /usr/sap
oraclestagelv       jfs2       128     128     1    open/syncd    /oracle/stage
sapreorg_CG1lv      jfs2       64      64      1    open/syncd    /oracle/CG1/sapreorg
sapbackup_CG1lv     jfs2       16      16      1    open/syncd    /oracle/CG1/sapbackup
mirrlogA_CG1lv      jfs2       8       8       1    open/syncd    /oracle/CG1/mirrlogA
mirrlogB_CG1lv      jfs2       8       8       1    open/syncd    /oracle/CG1/mirrlogB
origlogA_CG1lv      jfs2       8       8       1    open/syncd    /oracle/CG1/origlogA
origlogB_CG1lv      jfs2       8       8       1    open/syncd    /oracle/CG1/origlogB
sapdata1_CG1lv      jfs2       1600    1600    1    open/syncd    /oracle/CG1/sapdata1
oraarch_CG1lv       jfs2       80      80      1    open/syncd    /oracle/CG1/oraarch
loglv01             jfs2log    1       1       1    open/syncd    N/A

在故障转移点之前，不会挂载备用节点上的文件系统，因此不可能意外使用备用节点上的数据。 在备用节点上，它可以访问共享的增强并发卷组，但只能以被动，只读模式进行。 VG PERMISSION设置为“仅被动”。 共享卷组中的逻辑卷已关闭。

清单9.备用节点

root@aix02adm / # lsvg sapvg
VOLUME GROUP:       sapvg                    VG IDENTIFIER:  00c79a6000004c0000000123a2278720
VG STATE:           active                   PP SIZE:        64 megabyte(s)
VG PERMISSION:      passive-only             TOTAL PPs:      6398 (409472 megabytes)
MAX LVs:            256                      FREE PPs:       1596 (102144 megabytes)
LVs:                13                       USED PPs:       4802 (307328 megabytes)
OPEN LVs:           0                        QUORUM:         2 (Enabled)
TOTAL PVs:          1                        VG DESCRIPTORS: 2
STALE PVs:          0                        STALE PPs:      0
ACTIVE PVs:         1                        AUTO ON:        no
Concurrent:         Enhanced-Capable         Auto-Concurrent: Disabled
VG Mode:            Concurrent
Node ID:            1                        Active Nodes:       2
MAX PPs per VG:     32512
MAX PPs per PV:     4064                     MAX PVs:        8
LTG size (Dynamic): 256 kilobyte(s)          AUTO SYNC:      no
HOT SPARE:          no                       BB POLICY:      relocatable

root@aix02adm / # lsvg -l sapvg
sapvg:
LV NAME             TYPE       LPs     PPs     PVs  LV STATE      MOUNT POINT
oraclelv            jfs2       192     192     1    closed/syncd  /oracle
sapmnt_CG1lv        jfs2       144     144     1    closed/syncd  /sapmnt
usrsap_CG1lv        jfs2       144     144     1    closed/syncd  /usr/sap
oraclestagelv       jfs2       128     128     1    closed/syncd  /oracle/stage
sapreorg_CG1lv      jfs2       64      64      1    closed/syncd  /oracle/CG1/sapreorg
sapbackup_CG1lv     jfs2       16      16      1    closed/syncd  /oracle/CG1/sapbackup
mirrlogA_CG1lv      jfs2       8       8       1    closed/syncd  /oracle/CG1/mirrlogA
mirrlogB_CG1lv      jfs2       8       8       1    closed/syncd  /oracle/CG1/mirrlogB
origlogA_CG1lv      jfs2       8       8       1    closed/syncd  /oracle/CG1/origlogA
origlogB_CG1lv      jfs2       8       8       1    closed/syncd  /oracle/CG1/origlogB
sapdata1_CG1lv      jfs2       1600    1600    1    closed/syncd  /oracle/CG1/sapdata1
oraarch_CG1lv       jfs2       80      80      1    closed/syncd  /oracle/CG1/oraarch
loglv01             jfs2log    1       1       1    closed/syncd  N/A

必须安装bos.clvm.enh文件集（在集群中的所有节点上）以支持增强的并发卷组。 使用增强的并发卷组启动新的子系统（gsclvmd）。 您可以查询该子系统以确定活动的增强并发卷组。

清单10.查询gsclvmd子系统

# lssrc -s gsclvmd
Subsystem         Group            PID          Status
 gsclvmd                           327756       active

# ps -fp 462906
UID     PID    PPID   C    STIME    TTY TIME CMD
root  462906  327756   0   Nov 04   -   0:02 /usr/sbin/gsclvmd -r 30 -i 300 -t 300 -c 00c79a6000004c0000000123a2278720 -v 0

# lssrc -ls gsclvmd
 Subsystem       Group           PID     Status
 gsclvmd         gsclvmd        327756  active

 Active VGs # 1
 vgid                                   pid
 00c79a6000004c0000000123a2278720       462906

要为共享卷组启用增强的并发模式（快速磁盘接管），可以使用CSPOC。

清单11.启用增强的并发模式

# smit cl_vg
                                                                    Shared Volume Groups

Move cursor to desired item and press Enter.

  List All Shared Volume Groups
  Create a Shared Volume Group
  Create a Shared Volume Group with Data Path Devices
  Enable a Shared Volume Group for Fast Disk Takeover
  Set Characteristics of a Shared Volume Group
  Import a Shared Volume Group
  Mirror a Shared Volume Group
  Unmirror a Shared Volume Group

请参阅IBM技术文档和PowerHA文档，以获取有关PowerHA和虚拟存储支持的更多信息。

摘要

这只是这种配置的一种方法。 我希望这些简短的提示为您提供一些有关如何在VIO环境中使用PowerHA的想法。

翻译自: https://www.ibm.com/developerworks/aix/library/au-powerha/index.html

IBM PowerHA SystemMirror

IBM®PowerHA®SystemMirror®是一种高可用性和灾难恢复解决方案，可通过计划内和计划外的中断提供近乎连续的资源可用性。 资源可以是数据，应用程序，网络接口等。

PowerHA SystemMirror可以与不同的存储一起使用（例如，IBM SystemStorage®DS8000®，IBMXIV®StorageSystem®，EMC和Hitachi），从而实现灾难恢复和高可用性。 本文介绍了如何配置Hitachi Storage System与PowerHA SystemMirror一起使用。

日立存储系统

Hitachi Storage System通过使用Hitachi Universal Replicator（HUR）技术的TrueCopy同步和异步复制来支持短距离复制和长距离复制。 本文将与PowerHA SystemMirror一起处理Hitachi TrueCopy配置。

日立TrueCopy：

• 是基于存储的复制解决方案
• 允许同步操作模式，其中：
  • 主阵列仅在目标阵列确认已接收并检查数据后才对主机写入作出响应
  • 源设备和目标设备包含相同的副本

PowerHA SystemMirror与Hitachi的交互

PowerHA SystemMirror支持用于从Hitachi Storage System进行存储的高可用性灾难恢复（HADR）。

镜像需要两个或多个Hitachi Storage系统。 镜像的源和目标可以驻留在同一站点上并形成本地镜像，或者源和目标可以驻留在不同的站点上并启用灾难恢复计划。

Hitachi TrueCopy操作涉及主要（主要）子系统和次要（远程）子系统。 主子系统包含TrueCopy主卷（P-VOL），它们是原始数据卷。 辅助子系统包含TrueCopy辅助卷（S-VOL），它们是P-VOL的同步或异步副本。

日立可以将一组远程镜像分组到一个设备组中。 设备组是同一日立系统上的一组相关卷，被视为单个一致的单元。 使用镜像时，设备组作为一组处理许多远程镜像对，以使镜像卷保持一致。

图1：具有存储镜像的两站点群集配置

如图1所示，我们有两个站点。 这里的站点表示在相同地理位置上放置在一起的一组节点。 PowerHA SystemMirror当前支持两个站点，即，一个站点中存在一组节点，而另一个站点中存在另一组节点，但它们都是同一集群的一部分。 在这里，两个位置都可以在附近或在地理位置上分开。

如果由于火灾或地震等灾难而导致整个站点发生故障，PowerHA SystemMirror会将资源移至另一个站点。 由于数据是在两个站点中的Hitachi Storage系统上镜像的并且是一致的，因此资源将在另一个站点中启动并运行，从而保持高可用性。

先决条件

确保使用HItachi Storage配置PowerHA SystemMirror满足以下先决条件：

• PowerHA SystemMirror 6.1（企业版）
  • PowerHA 6.1 SP3或更高版本
• IBMAIX®和RSCT需求
  • AIX 6.1 TL4或更高版本
    • RSCT V2.5.4.0或更高版本
  • AIX 7.1或更高版本
    • RSCT V3.1.0.0或更高版本
• 日立USPV / VM存储
  • 固件软件包V60-06-05 / 00或更高版本
• Hitachi Command Control Interface（CCI）版本01-23-03 / 06或更高版本（必须安装在所有PowerHA节点上

假设条件

我们的测试设置包括以下软件版本：

• PowerHA SystemMirror版本7.1.3 SP2
• Hitachi命令控制界面（CCI）版本01-23-03 / 06

使用Hitachi Storage Navigator将逻辑单元号（LUN）分配给节点。

在两节点群集上安装和配置Hitachi / PowerHA XD的步骤

实现Hitachi镜像存储的高可用性和灾难恢复（HADR）的PowerHA SystemMirror Enterprise Edition涉及两个步骤。

步骤1：安装和配置Hitachi / PowerHA XD

步骤2：使用PowerHA SystemMirror Enterprise Edition界面发现已部署的存储设备并定义HA策略。

安装适用于AIX的Hitachi CCI软件

需要在集群的所有测试节点上执行以下步骤。

1. 将RMHORC文件复制到根目录（/）。
2. 运行以下命令： cpio -idmu < RMHORC
   将创建一个名称为HORCM的目录。
3. 转到上面的目录并运行horcminstall.sh文件以安装Hitachi CLI。
4. 使用以下命令验证Hitachi软件是否已正确安装，并注意显示的版本信息。

# raidqry -h
Model: RAID-Manager/AIX
Ver&Rev: 01-23-03/06
Usage: raidqry [options] for HORC

配置Hitachi镜像和AIX

Hitachi系统同时提供GUI和CLI命令来配置和监视系统。 本节说明使用GUI创建镜像或日立镜像对。

以下是测试环境的群集节点和相应IP的详细信息。

• 节点1 <IP1>
• 节点2 <IP2>
• 节点3 <IP3>
• 节点4 <IP4>

站点A是主站点（也称为生产站点），它包含以下节点：node1和node2。 它还包括主存储Hitachi1。

站点B是辅助站点（也称为恢复站点），它包括以下节点：node3和node4。 它还包括辅助存储Hitachi2。

• Hitachi1：主存储（Hitachi_IP1）也称为主存储。
• Hitachi2：辅助存储（Hitachi_IP2）也称为从属。

Hitachi磁盘必须在同一站点的所有节点之间共享。

执行以下步骤来配置Hitachi镜像和AIX：

1. 确保系统上存在Hitachi磁盘。 在/ HORCM / usr / bin目录中的所有节点上运行以下命令。
   lsdev -Cc disk | grep hdisk | inqraid

   将显示hdisk列表。 搜索参数CM （命令设备）。 对于每个节点，将有一个带有此参数的磁盘。 该磁盘稍后将在horcm.conf文件中用作COMMAND_DEV 。

   例如，在以下输出中，将hdisk11配置为该节点的命令设备。
   hdisk11 -> [SQ] CL4-C Ser = 53105 LDEV =40961 [HITACHI ] [OPEN-V-CM]
RAID5[Group 1- 2] SSID = 0x00A4

   在以下输出中，两个磁盘hdisk2和hdisk7也是Hitachi磁盘，将在Hitachi TrueCopy关系中使用。

   hdisk2 -> [SQ] CL4-C Ser =   53105 LDEV =   2 [HITACHI ] [OPEN-V]
   HORC = S-VOL  HOMRCF[MU#0 = SMPL MU#1 = SMPL MU#2 = SMPL]
   RAID5[Group  1- 1] SSID = 0x0004
   
   hdisk7 -> [SQ] CL4-C Ser =   53105 LDEV =  64 [HITACHI ] [OPEN-V]
   HORC = P-VOL  HOMRCF[MU#0 = SMPL MU#1 = SMPL MU#2 = SMPL]
   RAID5[Group  1- 1] SSID = 0x0004

   在此，S-VOL是次要音量，P-VOL是主要音量。

   从这一步，我们可以确定Hitachi Command Device和镜像磁盘。

2. 创建一个HORCM实例。

   转到/ HORCM / usr / bin目录。 使用mkconf.sh创建实例。 此处，0是实例编号。

   注意：您可以使用任何数字。 如果使用0，则文件名将为horcm0.conf。
   ./mkconf.sh -i 0

   这将在同一目录中创建horcm0.conf文件。 将horcm0.conf文件移动到/ etc /。 在所有节点上重复此步骤。

   注意：该命令可能会挂起，但是无论如何它将创建文件。 挂起时使用

   Ctrl + C退出。 / etc中应该存在指向文件/ HORCM / etc / horcmgr的软链接horcmgr。 如果不存在，请创建软链接，然后使用/ HORCM / usr / bin中的horcmstart.sh 0命令启动horcm服务。

3. 配置horcm0.conf文件。

   来自站点A的样本horcm.conf文件：

   # Created by mkconf.sh on Thu Jan 22 03:32:09 CST 2015
   
   HORCM_MON
   #ip_address        service         poll(10ms)     timeout(10ms)
   node1 IP         52323                 1000              3000
   
   HORCM_CMD
   #dev_name               dev_name                dev_name
   #UnitID 0 (Serial# 53105)
   /dev/rhdisk9
   
   HORCM_LDEV
   #dev_group        dev_name        Serial#   CU:LDEV(LDEV#)   MU#
   DVGP1             DVNM1           53105        548            0
   
   HORCM_INST
   #dev_group ip_address service
   DVGP1      node3 IP  52323

   来自站点B的样本horcm.conf文件：

   # Created by mkconf.sh on Thu Jan 22 03:34:37 CST 2015
   
   HORCM_MON
   #ip_address        service         poll(10ms)     timeout(10ms)
   node3 IP          52323                 1000              3000
   
   HORCM_CMD
   #dev_name               dev_name                dev_name
   #UnitID 0 (Serial# 53105)
   /dev/rhdisk5
   
   HORCM_LDEV
   #dev_group        dev_name        Serial#   CU:LDEV(LDEV#)   MU#
   DVGP1             DVNM1           53105        553            0
   
   HORCM_INST
   #dev_group ip_address service
   DVGP1      node1 IP  52323

   horcm0.conf文件的内容对于特定站点的所有节点应该相同。

   相应地在所有节点上编辑horcm0.conf文件，并使用/ HORCM / usr / bin目录中的horcmstart.sh 0启动horcm实例。

   下表说明了horcm.conf文件中使用的术语。

   表1：horcm.conf文件中使用的术语

   术语	描述
   HORCM_MON	在IP地址下，提供节点IP地址（其余所有字段均与示例文件中所示的相同）。
   HORCM_CMD	在此条目下，使用我们之前选择的具有参数CM的hdisk。
   HORCM_LDEV	在此条目下，输入用户定义的设备组名称（例如DVGP1）和用户定义的设备名称（例如DVNM1）。 在一个组中，我们可以有多个具有不同设备名称的设备，每个设备名称代表一个镜像。 为所有节点创建horcm.conf文件时，群集中的设备组名称和设备名称应相同。
   CU：LDEV（LDEV＃）	运行lsdev -Cc disk | inqraid lsdev -Cc disk | inqraid命令获取将在用户定义的设备名称（例如DVNM1）中使用的磁盘的LDEV编号。
   HORCM_INST	在此条目下，输入设备组名称和另一个站点的远程节点的IP。 所有站点的所有节点的设备组名称均相同。

4. 创建对。

   通过在所有节点上运行以下命令来停止horcm0实例。
   horcmshutdown.sh 0

   对于配对创建，我们将使用Hitachi Storage Navigator。 使用Hitachi Storage Navigator IP和登录凭据连接到Hitachi Storage Navigator。

   1. 在主页上，单击操作 → 远程复制 → TrueCopy → 配对 操作 。
      
      图2：配对操作
   2. 使用Java Web Start启动器启动servlet。
      
      图3：Java Web Start启动器
   3. 请注意显示的TrueCopy Pair Operation页面。
      
      图4：存储子系统列表
   4. 选择子系统（端口）所在的磁盘。 在此示例中，它是CL4-C（我们可以使用以下命令获取此信息：
      lsdev -Cc disk | inqraid lsdev -Cc disk | inqraid （注意：在所有节点上运行命令）
      output - hdisk2 -> [SQ] CL4-C Ser = 53105 LDEV = 2 [HITACHI ] ...
      在输出中，我们可以看到CL4-C。
      
      图5：CL4-C的日立磁盘列表
   5. 如下图所示，将视图模式更改为编辑模式。
      
      图6：查看模式
      
      图7：编辑模式
   6. 选择主站点的磁盘，然后与辅助站点的磁盘配对。
   7. 执行以下步骤，选择主站点节点的磁盘及其在辅助站点上的相应磁盘。

      从站点A的节点1：

      # lsdev -Cc disk | grep hdisk | inqraid
      hdisk0 -> NOT supported INQ.                  [IBM] [IC35L073UCDY10-0]
      hdisk1 -> NOT supported INQ.                  [IBM] [IC35L073UCDY10-0]
      hdisk2 -> NOT supported INQ.                  [IBM] [IC35L073UCDY10-0]
      hdisk3 -> NOT supported INQ.                  [IBM] [IC35L073UCDY10-0]
      hdisk4 -> NOT supported INQ.                  [IBM] [IC35L073UCDY10-0]
      hdisk5 -> NOT supported INQ.                  [IBM] [IC35L073UCDY10-0]
      hdisk6 -> [SQ] CL4-C Ser =   53105 LDEV =  63 [HITACHI ] [OPEN-V]
                HORC = SMPL  HOMRCF[MU#0 = SMPL MU#1 = SMPL MU#2 = SMPL]
                RAID5[Group  1- 1] SSID = 0x0004
      hdisk7 -> [SQ] CL4-C Ser =   53105 LDEV =  64 [HITACHI ] [OPEN-V]
                HORC = SMPL  HOMRCF[MU#0 = SMPL MU#1 = SMPL MU#2 = SMPL]
                RAID5[Group  1- 1] SSID = 0x0004
      hdisk8 -> [SQ] CL4-C Ser =   53105 LDEV =  65 [HITACHI ] [OPEN-V]
                HORC = SMPL  HOMRCF[MU#0 = SMPL MU#1 = SMPL MU#2 = SMPL]
                RAID5[Group  1- 1] SSID = 0x0004
      hdisk9 -> [SQ] CL4-C Ser =   53105 LDEV =  66 [HITACHI ] [OPEN-V]
                HORC = P-VOL  HOMRCF[MU#0 = SMPL MU#1 = SMPL MU#2 = SMPL]
                RAID5[Group  1- 1] SSID = 0x0004
      hdisk10 -> [SQ] CL4-C Ser =   53105 LDEV =  67 [HITACHI ] [OPEN-V]
                 HORC = P-VOL  HOMRCF[MU#0 = SMPL MU#1 = SMPL MU#2 = SMPL]
                 RAID5[Group  1- 1] SSID = 0x0004
      hdisk11 -> [SQ] CL4-C Ser =   53105 LDEV =  68 [HITACHI ] [OPEN-V]
                 HORC = P-VOL  HOMRCF[MU#0 = SMPL MU#1 = SMPL MU#2 = SMPL]
                 RAID5[Group  1- 1] SSID = 0x0004
      hdisk12 -> [SQ] CL4-C Ser =   53105 LDEV =  69 [HITACHI ] [OPEN-V]
                 HORC = SMPL  HOMRCF[MU#0 = SMPL MU#1 = SMPL MU#2 = SMPL]
                 RAID5[Group  1- 1] SSID = 0x0004
      hdisk13 -> [SQ] CL4-C Ser =   53105 LDEV =  70 [HITACHI ] [OPEN-V]
                 HORC = P-VOL  HOMRCF[MU#0 = SMPL MU#1 = SMPL MU#2 = SMPL]
                 RAID5[Group  1- 1] SSID = 0x0004
      hdisk14 -> [SQ] CL4-C Ser =   53105 LDEV =  71 [HITACHI ] [OPEN-V]
                 HORC = P-VOL  HOMRCF[MU#0 = SMPL MU#1 = SMPL MU#2 = SMPL]
                 RAID5[Group  1- 1] SSID = 0x0004
      hdisk15 -> [SQ] CL4-C Ser =   53105 LDEV =  72 [HITACHI ] [OPEN-V]
                 HORC = SMPL  HOMRCF[MU#0 = SMPL MU#1 = SMPL MU#2 = SMPL]
                 RAID5[Group  1- 1] SSID = 0x0004
      hdisk16 -> [SQ] CL4-C Ser =   53105 LDEV =40968 [HITACHI ] [OPEN-V-CM]
                 RAID5[Group 1- 2] SSID = 0x00A4

      从输出中可以看出，hdisk6到hdisk16是Hitachi磁盘。

      
      图8：CL4-C的日立磁盘列表

      在图8所示的Storage Navigator页面上，我们可以看到从CL4-C-02-000开始的磁盘。 因此，映射如下所示：

      • hdisk6→CL4-C02-000
      • 硬盘7→CL4-C02-001
      • 硬盘8→CL4-C02-002
      • 硬盘9→CL4-C02-003

      …。

      相同的情况适用于站点B的其他节点3。我们给出相同的命令来获取Hitachi的hdisk列表。 在存储导航器GUI中，选择站点B的节点3，然后检查该站点下的磁盘。 我们执行相同的顺序映射。

      例如，在Storage Navigator页面的CL4-C下，单击node1（在本示例中为02：love2_russel） 。

      在右窗格上，右键单击CL4-C-02-001 ，然后单击Paircreate → 同步 。

      
      图9：同步选项
      
      图10：Paircreate选项

      P-VOL是我们从站点A的节点1中选择的一个。我们现在必须选择S-VOL。 S-VOL是要从站点B的node3中选择的辅助卷。

      S-VOL具有三个字段。

      • 第一个字段与P-VOL相同（根据图9，它是CL4-C）。
      • 第二个字段是站点B磁盘列表标签的索引。 例如，如图11所示，站点B磁盘列表标签为01：r1r4-eth_parseghia。 因此，这里的索引是01。
        
        图11：CL4-C下的LPAR列表
      • 第三字段与P-VOL的第三字段相同（如图10所示，为000 ）。
        当磁盘处于SMPL（Simplex）状态时，我们可以创建一个对。 如果它已经处于PAIR状态，则可以在不使用它的情况下使用它。 如果它处于PSUS状态或任何其他状态，我们可以通过删除配对将其更改为SMPL状态。 右键单击磁盘时，将显示Pairsplit -S选项。
        
        图12：创建对后的磁盘状态页面

        点击应用以创建TrueCopy对。

5. 验证配对创建成功。
   
   图13：创建对后的磁盘状态

   通过运行horcmstart.sh 0 （请注意在所有节点上启动）来启动horcm0实例。

   要验证对是否正确创建，以及是否可以从当前节点访问另一个节点的horcm0实例，请在所有节点上运行必要的命令。

   以下命令检查本地节点上的对状态。
   pairvolchk -ss -g DVGP1 -IH0

   命令输出：
   pairvolchk : Volstat is P-VOL.[status = PAIR fence = NEVER MINAP = 2 ]

   以下命令检查远程节点上的配对状态。
   pairvolchk -c -ss -g DVGP1 -IH0

   命令输出：
   pairvolchk : Volstat is P-VOL.[status = PAIR fence = NEVER MINAP = 2 ]

   以下命令显示设备组的配对状态。
   pairdisplay -g DVGP1 -IH0

   命令输出：

   Group   PairVol(L/R) (Port#,TID, LU),Seq#,LDEV#.P/S,Status,Fence,Seq#,P-LDEV# M
   DVGP1   DVNM1(L)    (CL2-C-3, 0,   1)53105   548.P-VOL PAIR NEVER ,53105   553 -
   DVGP1   DVNM1(R)    (CL4-C-4, 0,   1)53105   553.S-VOL PAIR NEVER ,-----   548 -

   
   这三个命令都应该起作用，并提供正确的输出，如上所示。
6. 确保所有节点上的Hitachi磁盘都可以使用相同的PVID。
   成功完成配对后，我们必须确保集群的所有节点对于为其创建配对的磁盘都具有相同的PVID。 为此，请在所有站点B节点上运行以下命令。
   rmdev 0dl hdisk#
cfgmgr
   这将确保站点B节点磁盘具有与站点A节点磁盘相同的PVID。
7. 创建卷组，逻辑卷和文件系统。
   执行以下步骤在群集节点上创建卷组（VG），逻辑卷（LV）和文件系统：
   1. 确保所有节点上的VG的主号码相同。 要获得免费的主号码，请在所有节点上运行lvlstmajor命令，并选择一个在所有节点上可用的号码。
   2. 使用我们刚得到的主编号在站点A的node1的选定Hitachi磁盘上创建一个卷组，例如VG1。 为VG1创建逻辑卷和文件系统。
   3. 将VG导入具有相同主编号的所有其他节点。
8. 将Hitachi磁盘添加到PowerHA SystemMirror资源组。
   至此，我们已经在Hitachi磁盘之间创建了镜像，并且该镜像处于活动状态。 此外，VG在所有站点上所有节点的所需磁盘上创建。 这样就完成了Hitachi镜像及其相应的AIX配置。

配置PowerHA SystemMirror以监视和管理Hitachi镜像池

执行以下步骤，将PowerHA SystemMirror配置为监视和管理Hitachi镜像池。

1. 在shell提示符下运行smit sysmirror 。 然后，单击群集应用程序和资源 → 资源 → 配置HITACHI TRUECOPY（R）/ HUR复制的资源 。
   
   图14：Hitachi资源的PowerHA SystemMirror菜单
2. 要定义Truecopy / HUR管理的复制资源，请完成以下步骤：
   移至“ 添加Hitachi Truecopy / HUR复制资源”选项，然后按Enter键（或直接使用smit tc_def ）。
   
   图15：Hitachi资源的Change / Show菜单
   填写字段，如图15所示。
   资源名称字段中的值可以是您选择的任何名称。
3. 要将TrueCopy复制的资源添加到PowerHA SystemMirror Enterprise Edition资源组，请完成以下步骤：
   1. 在命令行中，输入smitty hacmp。
   2. 在SMIT中，选择“ 集群应用程序和资源” →“ 资源组” →“ 添加资源组” 。
   3. 添加资源组后，我们需要向其中添加Hitachi资源。
   4. 在SMIT中，选择集群应用程序和资源→资源组→更改/显示资源组的所有资源和属性 。
   5. 确保在“资源组”配置页面上选择的卷组与TrueCopy / HUR复制资源中使用的卷组匹配。
   6. Truecopy复制资源条目显示在SMIT页面的底部。 此项是一个选择列表，显示了在上一步中创建的资源名称。
      
      图16：资源组属性
      
      图17：资源组属性（续）
      注意：卷组与您在上一步中创建的VG1相同。
      
      图18：资源组属性（续）
4. 验证并同步集群，然后在所有节点上启动集群服务。

注意：
使用CCI进行配对操作时发生错误时，您可以通过参考以下日志文​​件来确定错误原因：
/ HORCM /日志* / curlog / horcmlog_HOST / horcm.log
*是实例号，而HOST是主机名。

翻译自: https://www.ibm.com/developerworks/aix/library/au-hitachi-truecopy-mirroring/index.html