精华内容
下载资源
问答
  • 2020-06-20 14:43:58

    IBMPowerHA®SystemMirror V7集群软件是IBMAIX®集群的下一版。 为了提供与AIX操作系统的更紧密的集成,开发了一个新的内核级别层,称为Cluster Aware AIX(CAA)。 群集软件利用这种新的基础进行心跳和消息通信。 在内核级别运行可确保群集通信获得最高优先级,并且在发生内存泄漏或恶意应用程序占用系统资源的情况下不会受到影响。 通过这种重新设计,可以跨所有网络接口进行运行状况监视,并具有从外部存储区域网络(SAN)存储柜启动时对根卷组(rootvg)丢失做出React的能力。 此外,光纤通道(FC)适配器中的新目标模式功能允许进行新的存储框架通信,以通过SAN进行运行状况监视。 以下说明旨在帮助您利用新的clmgr CLI快速部署PowerHA SystemMirror V7集群。 它们还提供了常见管理任务,示例配置文件和有用日志的示例。

    最低先决条件
    PowerHA SystemMirror版本 一般可用 最低AIX级别
    PowerHA SM版本7.1.0 2010年9月 带有RSCT 3.1.0.1的AIX 7.1
    带有RSCT 3.1.0.1的AIX 6.1 TL6 SP1
    PowerHA SM版本7.1.1 2011年12月 带有RSCT 3.1.2.0的AIX 7.1 TL1 SP3
    带有RSCT 3.1.2.0的AIX 6.1 TL7 SP3
    PowerHA SM版本7.1.2 2012年11月 带有RSCT 3.1.2.0的AIX 7.1 TL2 SP1
    带有RSCT 3.1.2.0的AIX 6.1 TL8 SP3
    PowerHA SM版本7.1.3 2013年12月 带有RSCT 3.1.5.0的AIX 7.1 TL3 SP1
    带有RSCT 3.1.5.0的AIX 6.1 TL9 SP1
    • CAA功能所需的软件包包括:
      • bos.cluster.rte
      • Bos.ahafs
      • bos.cluster.solid(在HA 7.1.0之后不再需要)
    • 版本7群集中的所有共享卷组(VG)必须是企业并行模式(ECM)VG:
      • bos.clvm.enh

    群集资源清单

    • IP地址规划
      • 请求IP(引导/基本IP,永久IP和服务IP的数量)。
      • 注册域名服务器(DNS)名称。
      • 更新配置文件:/ etc / hosts / etc / cluster / rhosts。
      • 接口上的硬IP。
    • 共享存储计划
      • 确定空间要求[数据逻辑单元号(LUN)和集群存储库磁盘的数量]
      • 确定驱动程序和多路径要求
      • 定义LUN映射
      • 创建SAN区域
      • 创建或导入共享卷组,逻辑卷和文件系统信息
      • 对跨集群成员导入的资源使用唯一的名称
    • 高度可用的应用程序规划
      • 确定安装位置和空间要求。
      • 识别用户和权限设置。
      • 测试和部署应用程序启动和停止脚本。
      • (可选)测试和部署应用程序监视脚本。
    • PowerHA SystemMirror集群部署:
      • 识别并在所有节点上安装AIX级别要求[包括CAA和可靠的可伸缩集群技术(RSCT)软件包]。
      • 在所有节点上标识并安装所需的PowerHA SystemMirror代码级别。
      • 重新启动逻辑分区(LPAR)以获取内核Bos更新
    • 从节点1:
      • 定义集群名称
      • 定义集群存储库磁盘
      • 定义多播地址(自动或手动)
      • 定义节点名称
      • 定义网络
      • 定义接口
      • 定义应用程序控制器
      • 定义服务IP
      • 定义资源组
      • 为资源组定义资源
      • 验证并同步集群。
      • 在所有节点上启动群集服务。

    配置完成并同步后,您可以继续执行以下任务:

    • 故障转移测试:与重新启动–q(硬)相比,通过接管和资源组移动(软)平稳停止。
    • 监控环境。
    • 配置文件:
      • / etc / hosts:此文件的内容应包括所有群集IP地址及其相应的IP标签,因为最好让群集在本地解析,然后在必要时还原为DNS。
      • / etc / cluster / rhosts:在两个节点上填充文件,然后刷新集群通信守护程序。 ( refresh –s clcomd )。 在每行中明确定义的群集IP有助于避免名称解析问题。 确保在此文件中仅定义有效的可访问群集IP。
      • /usr/es/sbin/cluster/netmon.cf:单个适配器网络中的集群使用此文件来尝试在发生故障时确定适配器状态。 虚拟化环境应部署此文件以指向位于物理框架外部的默认网关或IP,以验证外部连接性。
    • IP地址:
      • 组播地址(自动或手动分配):版本7集群上的集群心跳使用IP组播,默认情况下,在集群创建过程中分配组播地址。 它通过根据在网络接口上检测到的第一个IP定义一个地址来尝试避免在群集之间重复(例如,en0 – 9.10.10.1基本IP可能会导致228.10.10.1多播地址)。 如果您想定义自己的多播地址,也可以在集群配置的该部分中进行定义。 此默认值在版本7.1.3中改回为单播通信,但是IP多播仍然是可用的选项。
      • 基本IP地址:AIX中的每个适配器通常在其ODM上都存储有一个IP地址,并设置为在系统引导过程中联机。 如果这些适配器要在PowerHA网络中,则可以在集群定义中将它们定义为基础/引导适配器。 请注意,除非管理员在PowerHA 专用网络中明确定义了它们,否则CAA都会尝试使用LPAR中的所有接口。 具有将承载潜在服务IP的接口的虚拟局域网(VLAN)必须启用IP多播。 否则,CAA会将这些接口视为关闭状态,并且从不尝试在其上获取服务IP别名。
      • 永久IP:这是特定于群集节点的别名,无论HA服务是否在运行,它都将在系统启动时可用。 这些可以用作每个节点的管理IP,也可以用作群集故障转移时用于保存可路由子网路由的IP。 一段时间以来,PowerHA允许单个适配器网络在同一可路由子网上定义基本/引导IP和服务IP。 因此,对持久性IP的需求不像早期版本那样普遍,因此,通常不需要这些。
      • 服务IP:任何定义的服务IP地址别名都将由群集管理,只要它们在资源组中定义即可。 根据资源组及其对应资源的托管位置,将确定服务IP别名的位置
    • 共享磁盘:
      • CAA存储库磁盘(大小要求:最小512 MB和最大460 GB):这是新的CAA要求,必须对所有集群成员可见。 通常的做法是将此LUN定义为环境中的标准LUN大小,只要它在最小和最大大小要求之内即可。 在第一次验证和同步操作时,群集在设备上创建一个私有卷组。
      • 共享数据卷:必须创建所有群集管理的共享卷组,或者将其转换为增强的并发模式,然后进行映射,然后将其导入所有群集节点。 应将相应的LUN定义为在其后端多路径驱动程序中未设置保留。 在群集处理期间,群集使用其自己的磁盘防护寄存器来管理设备,并且仅允许将文件系统安装在托管资源组的节点上。
    • 群集资源组策略:
      • 群集配置中的资源组是不同高可用性资源的容器。 在规划阶段应建立不同的资源组启动,故障转移和回退策略,并应充分理解。

    资源组策略

    资源组策略 可用选项
    启动政策
    • 在主节点上联机仅在第一个可用节点上联机
    • 在线使用分配政策
    • 在所有可用节点上联机
    失败转移政策
    • 过渡到列表中的下一个节点
    • 使用动态节点优先级进行故障转移
    • 脱机
    后备政策
    • 后退到列表中的较高优先级节点
    • 脱机
    • 集群应用程序(应用程序控制器定义)
      • 启动/停止脚本:应用程序控制器脚本必须位于所有参与群集成员的公共路径中。 它们还必须由root用户可执行。 脚本的内容不需要在所有集群成员之间都匹配。 但是,如果内容需要根据应用程序要求进行匹配,则可以使用PowerHA文件收集功能来确保每10分钟自动复制一次更改。
      • (可选)应用程序监视脚本:群集软件提供了可在任何部署中使用的可选应用程序监视框架。 集群为在托管其资源组和相应应用程序控制器的节点上定义的每个监视器运行clappmon进程。 任何监视脚本都应可以由root用户执行,经过全面测试,具有适当的脚本终止功能,并且应位于所有群集成员的公共位置。

    CAA心跳通讯

    • 存储库磁盘版本7群集通信要求使用共享的LUN(存储库磁盘)进行心跳并存储群集配置信息。 7.1.1和7.1.2发行版的大小要求为最小大小为512 MB,最大为460 GB。 客户端通常使用其标准LUN大小而不是指定小于其当前数据LUN的卷。
    • IP接口:版本7群集使用的新通信协议要求在支持网络接口的第2层设备上启用IP多播。 CAA默认情况下使用系统上的所有接口,除非它们被定义为高度可用的专用网络。 群集需要IP网络定义才能在群集成员之间执行IP地址接管。 如果多播通信不起作用,群集将不会在接口上使服务IP别名联机,因为该接口将被视为不可用。
    • (可选)存储框架通信[SANCOMM]:在版本7群集中,基于SAN的通信是附加的检测信号选项。 如果正确启用,则存储框架通信将在共享SAN环境中的光纤通道适配器之间传递心跳,以提供其他心跳通信路径。 此配置仅在SAS或4 GB和8 GB光纤通道适配器上受支持,并且可以在专用主机总线适配器(HBA)或使用虚拟小型计算机系统接口(VSCSI)或N端口ID虚拟化(NPIV)的虚拟化适配器中使用。 在支持的HBA上,必须在拥有卡的LPAR上启用目标模式,并确保SAN分区提供所有集群成员上所有适用适配器之间的可见性。
    chdev –l fscsi# -a dyntrk=yes –a fc_err_recov=fast_fail –P
    chdev –l fcs# -a tme=yes –P (reboot is required)

    注意 –P仅在HBA上存在子设备时才用于更新AIX ODM,因此为什么需要重新引导才能使设置生效。

    虚拟化环境要求在客户端LPAR和相应的虚拟I / O服务器(VIOS)实例之间使用保留的以太网VLAN(3358)。 必须在客户端LPAR和VIOS上定义虚拟以太网适配器,以创建允许SAN心跳通信到达VIOS实例上的物理HBA的桥。 虚拟以太网适配器不需要在其上定义IP地址。 为了使存储数据包在跨物理服务器框架定义的群集成员之间传递,SAN分区必须包括所有对应的HBA全球端口号(WWPN)。 在虚拟化环境中,需要在同一SAN区域中定义每个VIOS中HBA的物理WWPN(而不是客户端虚拟WWPN)。 查看当前的在线文档或最新的红皮书出版物,以获取使用此功能的示例。

    CLI快速部署说明

    可以完全通过新的CLI创建PowerHA SystemMirror V7集群。 在此示例中,IP已经被附加到/ etc / hosts文件中。 该卷组已经导入到所有集群成员中,并且已经编写了应用程序脚本并将其传播到每个集群节点中的公共/ usr / local / hascripts目录。 以下说明创建一个基本的两节点群集:

    集群拓扑配置
    网络 标签 功能 接口 节点
    net_ether_01 Nodeb_base1 开机 en0 节点A
    net_ether_01 Nodeb_base1 开机 en0 节点B
    net_ether_01 共享IP 服务 别名 共享
    资源组配置
    资源组名称 DB_app1_rg
    启动政策 仅在主节点上联机
    失败转移政策 转移到下一个优先级节点
    后备政策 永不回退
    参与节点 节点A
    服务IP标签 共享IP
    卷组 共享vg
    应用控制器 DB_App1

    注意:在此示例中,资源组策略设置为“仅在主节点上联机”(命令中的默认值,并且不需要输入),“切换到下一个可用节点”和“从不回退”等最常用的策略。

    需要使用具有不同clmgr命令的以下任务来创建上表中概述的集群拓扑和资源组配置:

    • 创建一个集群。
      clmgr add cluster SampleCluster repository=hdisk10 nodes=nodea.dfw.ibm.com, nodeb.dfw.ibm.com
    • 添加服务IP。
      clmgr add service_ip sharedIP network=net_ether_01
    • 定义应用程序控制器: clmgr add application_controller DB_app1 startscript="/usr/local/hascripts/DB_app_start.sh" stopscript="/usr/local/hascripts/DB_app_stop.sh"
    • 创建资源组:
      clmgr add rg DB_app1_rg nodes=nodea.dfw.ibm.com, nodeb.dfw.ibm.com startup=ohn fallback=nfb service_label=sharedIP volume_group=sharedvg application=DB_app1
    • 验证和同步集群:
      clmgr sync cluster

    注意:仅在首次同步集群定义之后,才会显示在存储库磁盘上创建的CAA私有卷组。 这是一个手动卷组,不应通过AIX LVM对其进行修改,镜像或扩展。 另请注意,可以修改示例中的语法选项以包括其他群集功能。

    常见的管理任务

    本节概述了可以有效完成相同任务但可以使用clmgr或较旧的旧命令的不同操作或命令。

    • 访问PowerHA SystemMirror SMIT菜单:
      • smitty sysmirror
      • smitty cl_admin
    • 启动集群服务:(不同的选择)
      • clmgr start cluster
      • clmgr online node nodeA
      • clmgr start node node A
      • smitty clstart
    • 停止集群服务:(不同的选择)
      • clmgr stop cluster
      • clmgr offline node nodeA
      • clmgr stop node nodeA
      • smitty clstop
    • 验证/同步集群:
      • clmgr verify cluster
      • clmgr sync cluster
    • 移动资源组:(不同的选择)
      • clmgr move rg rgA, rgB node=nodeA (具有多个RG的移动是串行执行的)
      • clRGmove -g RGname -n nodeA -m
    • 添加一个应用程序监视器:
      • clmgr add mon appA_mon TYPE=Custom APPLICATION=appA MONITORINTERVAL=60 FAILUREACTION=fallover STABILIZATION=300 RESTARTINTERVAL=1200 CLEANUPMETHOD=/usr/local/hascripts/appA_cleanup.sh RESTARTMETHOD=/usr/local/hascripts/appA_restart.sh RESTARTCOUNT=3 MONITORMETHOD=/usr/local/hascripts/appA_monitor.sh
    • 暂停/恢复应用程序监视:
      • clmgr manage application_controller suspend test_app1
      • clmgr resume application_controller resume test_app1

    注意: clmgr操作将自动挂载文件系统,并更新其他集群节点中的ODM和/ etc / filesystems文件。 如果已将卷组定义为资源组,则群集将自动管理文件系统。

    • 验证IP多播流量:(必须在每个节点上运行)
      • mping –v –r –a 228.10.10.1 (nodeA – receive flag)
      • mping –v –s –a 228.10.10.1 (nodeB – send flag)
    • 显示/修改可调项:
      • clctrl – tune –L display default and set tunable values
    样本输出:
    root@mhoracle1 /> clctrl -tune -L
    NAME                      DEF    MIN    MAX    UNIT           SCOPE
    ENTITY_NAME(UUID)                                                CUR
    config_timeout            240    0      2G-1   seconds        c n
      sapdemo71_cluster(1de50be8-6ab0-11e2-ace9-46a6ba546402)          240
    
    deadman_mode              a                                   c n
      sapdemo71_cluster(1de50be8-6ab0-11e2-ace9-46a6ba546402)          a
    
    hb_src_disk               1      -1     3                     c
      sapdemo71_cluster(1de50be8-6ab0-11e2-ace9-46a6ba546402)          1
    
    hb_src_lan                1      -1     3                     c
      sapdemo71_cluster(1de50be8-6ab0-11e2-ace9-46a6ba546402)          1
    
    hb_src_san                2      -1     3                     c
      sapdemo71_cluster(1de50be8-6ab0-11e2-ace9-46a6ba546402)          2
    
    link_timeout              30000  0      1171K  milliseconds   c n
      sapdemo71_cluster(1de50be8-6ab0-11e2-ace9-46a6ba546402)          30000
    
    node_down_delay           10000  5000   600000 milliseconds   c n
      sapdemo71_cluster(1de50be8-6ab0-11e2-ace9-46a6ba546402)          10000
    
    node_timeout              20000  10000  600000 milliseconds   c n
      sapdemo71_cluster(1de50be8-6ab0-11e2-ace9-46a6ba546402)          20000
    
    packet_ttl                32     1      64                    c n
      sapdemo71_cluster(1de50be8-6ab0-11e2-ace9-46a6ba546402)          32
    
    remote_hb_factor          10     1      100                   c
      sapdemo71_cluster(1de50be8-6ab0-11e2-ace9-46a6ba546402)          10
    
    repos_mode                e                                   c n
      sapdemo71_cluster(1de50be8-6ab0-11e2-ace9-46a6ba546402)          e
    
    site_merge_policy         p                                   c
      sapdemo71_cluster(1de50be8-6ab0-11e2-ace9-46a6ba546402)          p
    
    n/a means parameter not supported by the current platform or kernel
    
    Scope codes:
    c = clusterwide: applies to the entire cluster
    s = per site: may be applied to one or more sites
    n = per node: may be applied to one or more nodes
    i = per interface: may be applied to one or more communication interfaces
    
    Value conventions:
    K = Kilo: 2^10       G = Giga: 2^30       P = Peta: 2^50
    M = Mega: 2^20       T = Tera: 2^40       E = Exa: 2^60

    注意:在AIX 61 TL9和AIX 71 TL3中,可用性得到增强,允许用户在[-b address]上指定要映射的接口的IP地址。 请注意,在以前的版本中,只要命令可以关闭服务器上的接口之一,这些命令就可以报告成功。

    • CAA增强了可用性:
      bos.cluster.rte CAA软件包引入了clcmd命令。 它使管理员可以在单个窗口中执行命令并从所有群集节点收集信息。
      • clcmd netstat –in显示所有群集节点的所有接口和IP
      • clcmd lspv显示来自所有群集节点的所有物理卷标识符( clcmd lspv )和VG信息
    样本输出:
    root@mhoracle1 /> clcmd netstat –in
    -------------------------------
    NODE mhoracle2.dfw.ibm.com
    -------------------------------
    Name  Mtu   Network     Address           Ipkts Ierrs    Opkts Oerrs  Coll
    en0   1500  link#2      32.43.2b.33.8a.2  3256281  0   267653     0     0
    en0   1500  9.19.51     9.19.51.212       3256281  0   267653     0     0
    lo0   16896 link#1                         378442  0   378442     0     0
    lo0   16896 127         127.0.0.1          378442  0   378442     0     0
    lo0   16896 ::1%1                          378442  0   378442     0     0
    
    -------------------------------
    NODE mhoracle1.dfw.ibm.com
    -------------------------------
    Name  Mtu   Network     Address           Ipkts Ierrs    Opkts Oerrs  Coll
    en0   1500  link#2      46.a6.ba.54.64.2  3318895  0   251392     0     0
    en0   1500  9.19.51     9.19.51.239       3318895  0   251392     0     0
    en0   1500  9.19.51     9.19.51.211       3318895  0   251392     0     0
    lo0 16896 link#1 283853 0 283853 0 0
    lo0   16896 127         127.0.0.1          283853  0   283853     0     0
    lo0   16896 ::1%1                          283853  0   283853     0     0
    样本输出:
    root@mhoracle1 /> clcmd lspv
    
    -------------------------------
    NODE mhoracle2.dfw.ibm.com
    -------------------------------
    hdisk0          00c23c9fedcf8f86              rootvg         active	
    hdisk1          00f604142514be43              sapvg          concurrent
    hdisk2          00f604142514beb0              oravg          concurrent
    hdisk3          00f604142514bf1c              None
    hdisk4          00f604142514bfb3              None
    hdisk5          00f604142514c023              None
    hdisk6          00f604142514c090              None
    hdisk9          00f626d13aa3645a              caavg_private  active
    hdisk7          00f604143a421dd3              sapersvg       concurrent
    hdisk8          00f604143a4243c4              sapsgfvg       concurrent
    
    -------------------------------
    NODE mhoracle1.dfw.ibm.com
    -------------------------------
    hdisk0          00f60414ed2ecec2              rootvg         active
    hdisk1          00f604142514be43              sapvg          concurrent
    hdisk2          00f604142514beb0              oravg          concurrent
    hdisk3          00f604142514bf1c              None
    hdisk4          00f604142514bfb3              None
    hdisk5          00f604142514c023              None
    hdisk6          00f626d1ffcc98bb              scrap_backup_vg active
    hdisk9          00f626d13aa3645a              caavg_private  active
    hdisk7          00f604143a421dd3              sapersvg       concurrent
    hdisk8          00f604143a4243c4              sapsgfvg       concurrent
    • 更换存储库磁盘:
      • clmgr replace repository new_disk

    集群状态监控

    本节概述了许多命令,以检查所使用的代码级别以及相应的群集守护程序和服务的状态。 提供了示例输出,但是您可能需要在自己的环境中进行实验,以查看哪些对您最有用。

    • 产品版本
    • halevel –s
    • lslpp -l cluster.es.server.rte
    • lssrc –ls clstrmgrES | grep fix
    • clmgr query version
    样本输出:
    root@mhoracle1 /> halevel -s
    7.1.2 SP3
    
    root@mhoracle1 /> lslpp -l cluster.es.server.rte
    Fileset                      Level  State      Description
    
    Path: /usr/lib/objrepos
    cluster.es.server.rte      7.1.2.3  COMMITTED  Base Server Runtime
    
    Path: /etc/objrepos
    cluster.es.server.rte      7.1.2.3  COMMITTED  Base Server Runtime
    
    
    root@mhoracle1 /> lssrc -ls clstrmgrES | grep fix
    cluster fix level is "3"
    
    root@mhoracle1 /> clmgr query version
    
    SystemMirror Information:
    =========================
    Version:            7.1.2 SP3
    Build Level:        1323C_hacmp712 (Jul 12 2013, 14:21:00)
    Cluster Type:       Multi Site Cluster Deployment (Stretched Cluster)
    
    CAA Information:
    ================
    Oct 30 2012
    14:30:59
    h2012_44A1
    @(#) _kdb_buildinfo unix_64 Oct 30 2012 14:30:59 h2012_44A1
    
    Cluster Configured:  Yes.
    
    Host Information:
    =================
    HOSTNAME:       mhoracle1.dfw.ibm.com
    IPADDRESS:      9.19.51.211
    LOCALHOST:      true
    HAVERSION:      7.1.2.3
    VERSION_NUMBER: 14
    HAEDITION:      STANDARD
    AIX_LEVEL:      7100-02-01-1245
    
    Director Information:
    =====================
    DIRECTOR_AGENT_STATUS:            ACTIVE
    DIRECTOR_AGENT_PLUGIN_STATUS:     ACTIVE
    DIRECTOR_AGENT_PLUGIN_VERSION:    7.1.2.0
    DIRECTOR_AGENT_PLUGIN_INST_DATE:  Tue Jan 29 13:39:55 CST6CDT 2013
    DIRECTOR_AGENT_PLUGIN_BUILD_DATE: Monday October 08, 2012 at 10:09:01 
    DIRECTOR_AGENT_FILE_SYSTEM:       96%
    DIRECTOR_AGENT_TRACE_LEVEL:       NORMAL
    DIRECTOR_AGENT_MANAGER:
    DIRECTOR_AGENT_EVENT_STATUS:      ERROR
    • 查询集群设置/状态:
    • clmgr query cluster
    • clmgr –v –a name,state,raw_state query node
    • lssrc –ls clstrmgrES | grep state
    • clshowsrv –v
    样本输出:
    root@mhoracle1 /> clmgr query cluster
    CLUSTER_NAME="sapdemo71_cluster"
    CLUSTER_ID="1120652512"
    STATE="STABLE"
    TYPE="SC"
    VERSION="7.1.2.3"
    VERSION_NUMBER="14"
    EDITION="STANDARD"
    CLUSTER_IP="228.19.51.211"
    UNSYNCED_CHANGES="false"
    SECURITY="Standard"
    FC_SYNC_INTERVAL="10"
    RG_SETTLING_TIME="0"
    RG_DIST_POLICY="node"
    MAX_EVENT_TIME="180"
    MAX_RG_PROCESSING_TIME="180"
    DAILY_VERIFICATION="Enabled"
    VERIFICATION_NODE="Default"
    VERIFICATION_HOUR="0"
    VERIFICATION_DEBUGGING="Enabled"
    LEVEL="DISABLED"
    ALGORITHM=""
    GRACE_PERIOD_SEC=""
    REFRESH=""
    MECHANISM=""
    CERTIFICATE=""
    PRIVATE_KEY=""
    HEARTBEAT_FREQUENCY="20"
    GRACE_PERIOD="10"
    SITE_POLICY_FAILURE_ACTION="fallover"
    SITE_POLICY_NOTIFY_METHOD=""
    SITE_HEARTBEAT_CYCLE="0"
    SITE_GRACE_PERIOD="0"
    
    root@mhoracle1 /> clmgr -v -a name,state,raw_state query node
    NAME="mhoracle1"
    STATE="NORMAL"
    RAW_STATE="ST_STABLE"
    
    NAME="mhoracle2"
    STATE="NORMAL"
    RAW_STATE="ST_STABLE"
    
    root@mhoracle1 /> lssrc -ls clstrmgrES | grep state
    Current state: ST_STABLE
    
    root@mhoracle1 /> clshowsrv -v
    Status of the RSCT subsystems used by HACMP:
    Subsystem        Group            PID          Status
    cthags           cthags           5243090      active
    ctrmc            rsct             5439656      active
    
    Status of the HACMP subsystems:
    Subsystem        Group            PID          Status
    clstrmgrES       cluster          5505208      active
    clcomd           caa              7405578      active
    
    Status of the optional HACMP subsystems:
    Subsystem         Group            PID          Status
    clinfoES         cluster                       inoperative
    • 显示集群配置:
    • cltopinfo
    • clmgr(查看基本报告)
    • cllsif (群集拓扑视图)
    • clshowres (资源组配置视图)
    样本输出:
    root@mhoracle1 /> cltopinfo
    Cluster Name: sapdemo71_cluster
    Cluster Connection Authentication Mode: Standard
    Cluster Message Authentication Mode: None
    Cluster Message Encryption: None
    Use Persistent Labels for Communication: No
    Repository Disk: hdisk9
    Cluster IP Address: 228.19.51.211
    There are 2 node(s) and 1 network(s) defined
    NODE mhoracle1:
         Network net_ether_01
              sharesvc1       9.19.51.239
              mhoracle1       9.19.51.211
    NODE mhoracle2:
         Network net_ether_01
              sharesvc1       9.19.51.239
              mhoracle2       9.19.51.212
    
    Resource Group SAP_rg
         Startup Policy   Online On Home Node Only
         Fallover Policy  Fallover To Next Priority Node In The List
          Fallback Policy  Never Fallback
         Participating Nodes      mhoracle1 mhoracle2
          Service IP Label                 sharesvc1
    
    
    root@mhoracle1 /> clmgr view report basic
    Cluster Name: sapdemo71_cluster
    Cluster Connection Authentication Mode: Standard
    Cluster Message Authentication Mode: None
    Cluster Message Encryption: None
    Use Persistent Labels for Communication: No
    Repository Disk: hdisk9
    Cluster IP Address: 228.19.51.211
    There are 2 node(s) and 1 network(s) defined
    NODE mhoracle1:
         Network net_ether_01
              sharesvc1       9.19.51.239
              mhoracle1       9.19.51.211
    NODE mhoracle2:
         Network net_ether_01
              sharesvc1       9.19.51.239
              mhoracle2       9.19.51.212
    
    Resource Group SAP_rg
         Startup Policy   Online On Home Node Only
         Fallover Policy  Fallover To Next Priority Node In The List
          Fallback Policy  Never Fallback
         Participating Nodes      mhoracle1 mhoracle2
          Service IP Label         sharesvc1
    
    root@mhoracle1 /> cllsif
    Adapter              Type       Network    Net Type   Attribute  Node       
    IP Address       Hardware Address Interface Name   Global Name      
    Netmask          Alias for HB Prefix Length
    mhoracle1        boot       net_ether_01 ether      public     
    mhoracle1  9.19.51.211      en0   255.255.255.0              24
    sharesvc1        service    net_ether_01 ether      public     
    mhoracle1  9.19.51.239             255.255.255.0             24
    mhoracle2        boot       net_ether_01 ether      public     
    mhoracle2  9.19.51.212      en0    255.255.255.0             24
    sharesvc1        service    net_ether_01 ether      public     
    mhoracle2  9.19.51.239             255.255.255.0               24
    
    
    root@mhoracle1 /> clshowres
    Resource Group Name                                 		SAP_rg
    Participating Node Name(s) 		mhoracle1 mhoracle2
    Startup Policy                       Online On Home Node Only
    Fallover Policy    			Fallover To Next Priority Node In The List
    Fallback Policy    			Never Fallback
    Site Relationship              	ignore
    Node Priority
    Service IP Label    			sharesvc1
    Filesystems   				ALL
    Filesystems Consistency Check         fsck
    Filesystems Recovery Method           parallel
    Filesystems/Directories to be exported (NFSv3)	/asap /sapmnt/TST /usr/sap/trans
    Filesystems/Directories to be exported (NFSv4)
    Filesystems to be NFS mounted
    Network For NFS Mount
    Filesystem/Directory for NFSv4 Stable Storage
    Volume Groups                         sapvg oravg sapersvg sapsgfvg
    Concurrent Volume Groups
    Use forced varyon for volume groups, if necessary false
    Disks
    Raw Disks
    Disk Error Management?                         no
    GMVG Replicated Resources
    GMD Replicated Resources
    PPRC Replicated Resources
    SVC PPRC Replicated Resources
    EMC SRDF® Replicated Resources
    Hitachi TrueCopy® Replicated Resources
    Generic XD Replicated Resources
    AIX Connections Services
    AIX Fast Connect Services
    Shared Tape Resources
    Application Servers                          sap
    Highly Available Communication Links
    Primary Workload Manager Class
    Secondary Workload Manager Class
    Delayed Fallback Timer
    Miscellaneous Data
    Automatically Import Volume Groups           false
    Inactive Takeover
    SSA Disk Fencing         		       false
    Filesystems mounted before IP configured     true
    WPAR Name
    
    Run Time Parameters:
    
    Node Name                                     mhoracle1
    Debug Level                                   high
    Format for hacmp.out                          Standard
    
    Node Name                                     mhoracle2
    Debug Level  		                       high
    Format for hacmp.out                          Standard
    • 资源位置:
      • clRGinfo –p
    样本输出:
    root@mhoracle1 /> clRGinfo -p
    
    Cluster Name: sapdemo71_cluster
    Resource Group Name: SAP_rg
    Node                         Group State
    ---------------------------- ---------------
    mhoracle1                    ONLINE
    mhoracle2                    OFFLINE
    • CAA命令:
      • lscluster –c (集群配置,多播地址)
      • lscluster –i (集群接口的状态)
      • lscluster –d (集群存储接口)
      • lcluster –m (集群节点配置信息)
    样本输出:
    root@mhoracle1 /> lscluster -c
    Cluster Name: sapdemo71_cluster
    Cluster UUID: 1de50be8-6ab0-11e2-ace9-46a6ba546402
    Number of nodes in cluster = 2
            Cluster ID for node mhoracle1.dfw.ibm.com: 1
            Primary IP address for node mhoracle1.dfw.ibm.com: 9.19.51.211
            Cluster ID for node mhoracle2.dfw.ibm.com: 2
            Primary IP address for node mhoracle2.dfw.ibm.com: 9.19.51.212
    Number of disks in cluster = 1
            Disk = hdisk9 UUID = d3ce4fd5-3003-ac21-9789-6d9a590242fd 
    cluster_major = 0 cluster_minor = 1
    Multicast for site LOCAL: IPv4 228.19.51.211 IPv6 ff05::e413:33d3
    
    
    root@mhoracle1 /> lscluster -i
    Network/Storage Interface Query
    
    Cluster Name: sapdemo71_cluster
    Cluster UUID: 1de50be8-6ab0-11e2-ace9-46a6ba546402
    Number of nodes reporting = 2
    Number of nodes stale = 0
    Number of nodes expected = 2
    
    Node mhoracle1.dfw.ibm.com
    Node UUID = 1dfc2d5a-6ab0-11e2-ace9-46a6ba546402
    Number of interfaces discovered = 3
            Interface number 1, en0
                    IFNET type = 6 (IFT_ETHER)
                    NDD type = 7 (NDD_ISO88023)
                    MAC address length = 6
                    MAC address = 46:A6:BA:54:64:02
                    Smoothed RTT across interface = 7
                    Mean deviation in network RTT across interface = 3
                    Probe interval for interface = 100 ms
                    IFNET flags for interface = 0x1E080863
                    NDD flags for interface = 0x0021081B
                    Interface state = UP
                    Number of regular addresses configured on interface = 2
                    IPv4 ADDRESS: 9.19.51.211 broadcast 9.19.51.255 netmask 255.255.255.0
                    IPv4 ADDRESS: 9.19.51.239 broadcast 9.19.51.255 netmask 255.255.255.0
                    Number of cluster multicast addresses configured on interface = 1
                    IPv4 MULTICAST ADDRESS: 228.19.51.211
            Interface number 2, sfwcom
                    IFNET type = 0 (none)
                    NDD type = 304 (NDD_SANCOMM)
                    Smoothed RTT across interface = 7
                    Mean deviation in network RTT across interface = 3
                    Probe interval for interface = 100 ms
                    IFNET flags for interface = 0x00000000
                    NDD flags for interface = 0x00000009
                    Interface state = UP
            Interface number 3, dpcom
                    IFNET type = 0 (none)
                    NDD type = 305 (NDD_PINGCOMM)
                    Smoothed RTT across interface = 750
                    Mean deviation in network RTT across interface = 1500
                    Probe interval for interface = 22500 ms
                    IFNET flags for interface = 0x00000000
                    NDD flags for interface = 0x00000009
                    Interface state = UP RESTRICTED AIX_CONTROLLED
    
    Node mhoracle2.dfw.ibm.com
    Node UUID = 1e1476a8-6ab0-11e2-ace9-46a6ba546402
    Number of interfaces discovered = 3
            Interface number 1, en0
                    IFNET type = 6 (IFT_ETHER)
                    NDD type = 7 (NDD_ISO88023)
                    MAC address length = 6
                    MAC address = 32:43:2B:33:8A:02
                    Smoothed RTT across interface = 7
                    Mean deviation in network RTT across interface = 3
                    Probe interval for interface = 100 ms
                    IFNET flags for interface = 0x1E080863
                    NDD flags for interface = 0x0021081B
                    Interface state = UP
                    Number of regular addresses configured on interface = 1
                    IPv4 ADDRESS: 9.19.51.212 broadcast 9.19.51.255 netmask 255.255.255.0
                    Number of cluster multicast addresses configured on interface = 1
                    IPv4 MULTICAST ADDRESS: 228.19.51.211
            Interface number 2, sfwcom
                    IFNET type = 0 (none)
                    NDD type = 304 (NDD_SANCOMM)
                    Smoothed RTT across interface = 7
                    Mean deviation in network RTT across interface = 3
                    Probe interval for interface = 100 ms
                    IFNET flags for interface = 0x00000000
                    NDD flags for interface = 0x00000009
                    Interface state = UP
            Interface number 3, dpcom
                    IFNET type = 0 (none)
                    NDD type = 305 (NDD_PINGCOMM)
                    Smoothed RTT across interface = 750
                    Mean deviation in network RTT across interface = 1500
                    Probe interval for interface = 22500 ms
                    IFNET flags for interface = 0x00000000
                    NDD flags for interface = 0x00000009
                    Interface state = UP RESTRICTED AIX_CONTROLLED
    
    		root@mhoracle1 /> lscluster -d
    		Storage Interface Query
    
    		Cluster Name: sapdemo71_cluster
    		Cluster UUID: 1de50be8-6ab0-11e2-ace9-46a6ba546402
    		Number of nodes reporting = 2
    		Number of nodes expected = 2
    
    		Node mhoracle1.dfw.ibm.com
    		Node UUID = 1dfc2d5a-6ab0-11e2-ace9-46a6ba546402
    		Number of disks discovered = 1
    				hdisk9:
    						State : UP
    						 uDid : 
    3E213600A0B80001132D0000020024D3850960F1815      FAStT03IBMfcp
    						 uUid : d3ce4fd5-3003-
    ac21-9789-6d9a590242fd
    				Site uUid : 51735173-5173-5173-5173-
    517351735173
    						 Type : REPDISK
    
    		Node mhoracle2.dfw.ibm.com
    		Node UUID = 1e1476a8-6ab0-11e2-ace9-46a6ba546402
    		Number of disks discovered = 1
    				hdisk9:
    						State : UP
    						 uDid : 
    3E213600A0B80001132D0000020024D3850960F1815      FAStT03IBMfcp
    						 uUid : d3ce4fd5-3003-
    ac21-9789-6d9a590242fd
    				Site uUid : 51735173-5173-5173-5173-
    517351735173
    					   Type : REPDISK
    
    root@mhoracle1 /> lscluster -m
    		Calling node query for all nodes...
    		Node query number of nodes examined: 2
    
    			Node name: mhoracle1.dfw.ibm.com
    			Cluster shorthand id for node: 1
    			UUID for node: 1dfc2d5a-6ab0-11e2-ace9-46a6ba546402
    			State of node: UP  NODE_LOCAL
    			Smoothed rtt to node: 0
    			Mean Deviation in network rtt to node: 0
    			Number of clusters node is a member in: 1
    			CLUSTER NAME       SHID         UUID
    			sapdemo71_cluster  0            1de50be8-6ab0-
    11e2-ace9-46a6ba546402
    			SITE NAME          SHID         UUID
    			LOCAL              1            51735173-5173-5173-5173-
    517351735173
    
    			Points of contact for node: 0
    
    ----------------------------------------------------------------------------
    
    			Node name: mhoracle2.dfw.ibm.com
    			Cluster shorthand id for node: 2
    			UUID for node: 1e1476a8-6ab0-11e2-ace9-46a6ba546402
    			State of node: UP
    			Smoothed rtt to node: 7
    			Mean Deviation in network rtt to node: 3
    			Number of clusters node is a member in: 1
    			CLUSTER NAME       SHID         UUID
    			sapdemo71_cluster  0            1de50be8-6ab0-
    11e2-ace9-46a6ba546402
    			SITE NAME          SHID         UUID
    			LOCAL              1            51735173-5173-
    5173-5173-517351735173
    
    			Points of contact for node: 3
    			------------------------------------------
    			Interface     State  Protocol  Status
                           ------------------------------------------
    			dpcom       DOWN none      RESTRICTED
    			en0           UP     	IPv4       none
    			sfwcom     UP     	none      none
    仅当在lscluster -m输出中可见sfwcom时,SANCOMM才起作用:
    Interface State Protocol Status
    		
    dpcom DOWN none RESTRICTED
    en0 UP IPv4 none
    sfwcom UP none none
    lscluster –s群集统计信息
    You can also check the sent and received storage packet counts in
    
    lscluster -s:
    storage pkts sent: 168493709 storage pkts recv: 82575360
    		
    # clras sancomm_status
    NAME                        UUID                          STATUS
    nodeA.dfw.ibm.com | e9b4d6a4-5e71-11-e2-af42-00145ee726e1 | UP |
    lscluster –完整的样本输出
    root@mhoracle1 /> lscluster -s
    Cluster Network Statistics:
    
    pkts seen: 15627136                   		passed: 3335048
    IP pkts: 12873577                     		UDP pkts: 12344880
    gossip pkts sent: 2470583             		gossip pkts recv: 4932115
    cluster address pkts: 0               		CP pkts: 12292272
    bad transmits: 0                      		bad posts: 33
    Bad transmit (overflow): 0
    Bad transmit (host unreachable): 0
    Bad transmit (net unreachable): 0
    Bad transmit (network down): 0
    Bad transmit (no connection): 0
    short pkts: 0                         		multicast pkts: 11664024
    cluster wide errors: 0                		bad pkts: 0
    dup pkts: 398159                      		pkt fragments: 10964
    fragments queued: 0                   		fragments freed: 0
    pkts pulled: 0                        		no memory: 0
    rxmit requests recv: 619              		requests found: 511
    requests missed: 157                  		ooo pkts: 76
    requests reset sent: 157              		reset recv: 90
    remote tcpsock send: 0                		tcpsock recv: 0
    rxmit requests sent: 696
    alive pkts sent: 0                    		alive pkts recv: 0
    ahafs pkts sent: 14                   		ahafs pkts recv: 4
    nodedown pkts sent: 0                 		nodedown pkts recv: 0
    socket pkts sent: 24859               		socket pkts recv: 24910
    cwide pkts sent: 990856               		cwide pkts recv: 992280
    socket pkts no space: 0               		pkts recv notforhere: 0
    Pseudo socket pkts sent: 0            	       Pseudo socket pkts recv: 0
    Pseudo socket pkts dropped: 0
    arp pkts sent: 3                      		arp pkts recv: 1
    stale pkts recv: 0                    		other cluster pkts: 2
    storage pkts sent: 6022728            	       storage pkts recv: 5825646
    disk pkts sent: 7023                  		disk pkts recv: 7508
    unicast pkts sent: 435987             		unicast pkts recv: 680571
    out-of-range pkts recv: 0
    IPv6 pkts sent: 0                     		IPv6 pkts recv: 0
    IPv6 frags sent: 0                    		IPv6 frags recv: 0
    Unhandled large pkts: 0

    样本配置文件

    / etc /集群/主机
    9.10.10.1
    9.10.10.2
    / etc / hosts
    127.0.0.1 loopback
    # PowerHA SystemMirror Cluster IP Addresses
    9.10.10.1 nodea.dfw.ibm.com nodeA # node A base address
    9.10.10.2 nodeb.dfw.ibm.com nodeB # node B base address
    9.10.10.10 shared_ip.dfw.ibm.com shared_ip # Shared SVC IP address
    /etc/netsvc.conf
    hosts=local,bind
    /etc/resolv.conf
    nameserver	9.0.1.1
    domain		dfw.ibm.com
    /usr/es/sbin/cluster/netmon.cf
    9.10.10.6
    !REQD owner target
    !IBQPORT owner
    !IBQPORTONLY owner
    			
    
    			 Reference /usr/sbin/rsct/samples/hats/netmon.cf
    
    			 Documentation APARs: IZ01332 IZ01332

    应用程序控制器脚本

    /usr/local/hascripts/appA_start.sh(基本的SAP示例)
    #!/bin/ksh
    su – orastst –c "lsnrctl start"
    su – tstadm –c "startsap"
    exit 0
    /usr/local/hascripts/appA_stop.sh(基本的SAP示例)
    #!/bin/ksh
    su – tstadm –c "stopsap"
    su – oratst –c "lsnrctl stop"
    exit 0
    /usr/local/hascripts/appA_monitor.sh
    #/bin/ksh
    …user provided logic ….
    exit 0

    有用的集群日志文件

    /var/hacmp/log/hacmp.out(详细的事件处理)
    Aug 14 16:34:49 EVENT START: node_up nodea
    :node_up [165] [[ high==high ]]
    :node_up [165] version=1.10.11.32
    :node_up [167] node_up_vg_fence_init
    ……
    ......
    /var/hacmp/adm/cluster.log(高级集群事件)
    Aug 14 16:34:49 nodea user:notice PowerHA SystemMirror for AIX: EVENT START: node_up nodea
    Aug 14 16:34:51 nodea user:notice PowerHA SystemMirror for AIX: EVENT COMPLETED:
    node_up nodea
    …...
    …..
    /var/hacmp/log/clutils.log(由集群实用程序生成)
    CLMGR STARTED 	(9153:10254698:5177392) : Thu Aug 14 16:34:49 CET 2013
    CLMGR USER 	(9153:10254698:5177392) : ::root:system
    CLMGR COMMAND 	(9153:10254698:5177392) : clmgr online node nodea
    CLMGR ACTUAL 	(9153:10254698:5177392) : start_node nodea
    /var/adm/ras/syslog.caa(CAA日志记录和故障排除)
    Aug 14 16:34:28 nodea caa:info syslog: caa_query.c cl_get_capability 2594
    There are 2 more capabilities defined at level 131072
    
    Aug 14 16:34:49 nodea caa:info syslog: caa_query.c cl_get_capability 2594
    There are 2 more capabilities defined at level 131072
    • 检查也很有用:
      • /var/hacmp/clverify/clverify.log(有关详细的验证检查输出)
      • /var/hacmp/clcomd/clcomd.log(用于解决通信问题)
      • /var/hacmp/log/cspoc.log.long(有关CSPOC的详细信息
      • /var/hacmp/log/clstrmgr.debug(由clstrmgr守护程序生成)
      • /var/hacmp/log/autoverify.log(通过每晚验证生成)

    有用的参考


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

    更多相关内容
  • IBM Power750安装配置AIX7.1&PowerHA7;.1(oracle) 主备方案,文档很详细。 AIX 7.1.0.4 PowerHA 7.1.3.4 Oracle11.2.0.4.8
  • ibm powerha安装

    2018-06-20 15:19:28
    ibm POWRHA7.1 安装文档,ibm powerha手把手安装指南。
  • PowerHA7.1配置文档

    2018-08-13 17:33:46
    IBM PowerHA SystemMirror 7.1配置文档,适合新手使用
  • IBM PowerHA for AIX有助于保护重要业务应用避免计划内和计划外中断。十多年来,通过开发IBM磁盘存储解决方案套件,为核心数据业务弹性奠定基础,PowerHA for AIX解决方案始终提供可靠的监控、故障检测和业务应用...
  • POWERHA常用心跳网络特点和配置.二、常用心跳网络配置 1、 RS232串口心跳配置 硬件配置建议配置专门用作心跳网络的异步卡。异步卡及串口线的选择配置可以参考: PowerHA中异步卡和串口线的选择。 配置方法:添加tty...
  • PowerHA7.1

    2016-04-01 15:37:29
  • 官方的hacmp7.1管理文档,适用于后期维护管理,原厂文档
  • 官方的hacmp7的概念解释,比以前版本配置更加简单,但功能强大
  • 数据中心和服务的可用性是IT基础架构最重要的主题之一,并且每天都引起更多关注。 站点之间的数据复制是最大程度地减少业务中断的好方法,因为备份还原操作可能需要很长时间才能满足业务... PowerHA SystemMirror 7....

    数据中心和服务的可用性是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配置示例
    PowerHA SystemMirror HyperSwap配置示例

    AIX对HyperSwap的支持

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

    图2:HyperSwap的AIX组件
    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支持
      图3:PowerHA集群HyperSwap支持
    • 对应用程序透明
      图4:HyperSwap磁盘表示
      图4:HyperSwap磁盘表示
    • 支持跨IBM SystemStorage®DS8000®系统的一致性组管理
    • 为关键系统磁盘提供HyperSwap支持,包括:
      • 根vg
      • 分页设备
      • 转储设备
      • 储存库磁盘
    • 提供磁盘分组支持
    • 提供对AIX逻辑卷管理器(LVM)和原始磁盘的支持
      • 磁盘或VG复制
      • 磁盘错误处理
      • Oracle可以与LVM或地址空间管理器(ASM)磁盘一起部署
    • 为多站点部署提供支持
      • 计算节点中断
        • 主动-主动工作负载提供持续可用性
      • 仓储中断
        • HyperSwap提供持续可用性
      • 主动被动站点
        • 站点内的双活工作负载
        • 跨站点主动-被动
        • 站点存储中断的连续可用性
    图5:主动-被动HyperSwap
    主动-被动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的交换超时在0180秒之间。 要确定计划外的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相关的配置设置

    名称 零件 描述
    丁克 协议驱动程序(fscsi) 已启用 如果更改了设备的N_port ID,则提供透明的I / O恢复
    (例如,由于光纤通道从一个交换机端口移动
    到另一个)。 在主机总线适配器(HBA)级别处理此选项。
    fc_err_recov 协议驱动程序(fscsi) fast_fail 使您能够检测到交换机和交换机之间的光纤通道问题。
    储存设备。
    hcheck_interval 磁盘驱动程序(hdisk) 60 健康检查请求发送到存储设备的时间间隔。
    默认设置为60秒。
    rw_timeout 磁盘驱动程序(hdisk) 30(DS8000) DS8000读/写超时值设置为30秒
    timeout_policy 磁盘驱动程序(hdisk) fail_path(DS8000) DS8000的默认值

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

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

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

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

    表2:交换时间指标

    交换类型 交换时间 对应用透明
    计划的用户镜像组 4秒 是的,如果没有读取并且进行了合理数量的写入操作,则几乎是透明的
    计划系统镜像组 少于1秒
    计划的存储库镜像组 少于1秒
    纯写应用程序的计划外交换 30秒(可调) 是的,如果写操作不是太高
    计划外交换纯读取应用程序 30秒(可调) 不,应用程序在交换的整个过程中都挂起。

    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_systemsmitty sysmirror > 群集应用程序和资源 > 资源 > 配置DS8800 Metro Mirror(带内)资源 > 配置存储系统 > 添加存储系统 。 也对辅助站点存储重复此步骤。
    8. 为HyperSwap磁盘设置以下镜像组。
      • 用户镜像组
      • Cluster_repository镜像组
      • SystemMirror组

      使用路径smitty cm_cfg_mirror_grpssmitty 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_VMMCAP_PROPAGATE

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

    展开全文
  • 在本文中,我将分享一些在虚拟I / O(VIO)环境中构建PowerHA™集群的技巧。 我将简要描述一个简单的两节点PowerHA集群的LPAR和VIO服务器(VIOS)设计和布局。 但是,我将不涉及特定的PowerHA配置,因为该主题太大而...

    在本文中,我将分享一些在虚拟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集群概述
    该图显示了两个595服务器以及vios,RAM和LPAR信息。

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

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

    虚拟网络

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

    图2. VIOS网络概述
    该图显示了595-1 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),依此类推。 服务地址是没有附加admhostname

    清单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 ...

    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。
        image003
        图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

    展开全文
  • 我意识到此新功能是PowerHA SystemMirror 7.1的一个重大更改,但似乎仅在PowerHA SystemMirror 7.1公告信和IBMRedbooks®中提到过。 所以,我想在这里分享我的研究。 比较卷组被动模式和存储框架磁盘防护 在PowerHA...
  • IBM PowerHA System Mirror for AIX是集群软件,当系统发生故障时,它可以将资源或资源组(应用程序)自动或手动移动到另一个IBMAIX®系统。 心跳和故障检测是在群集可用的所有接口上执行的。 这可能是网络接口,...
  • PowerHA SystemMirror 6.1 Planning, Implementation and Administration(Course code AN41) Instructor Guide
  • IBM PowerHA SystemMirror 7.2版引入了一项称为自动存储库磁盘替换(ARR)的新功能。 配置此功能后,当活动集群存储库磁盘发生故障或无法访问时,可以防止集群进入受限模式 。 当检测到存储库磁盘故障,集群感知...
  • 单个缓存分区可用于缓存一个或多个目标设备 主节点 :PowerHA集群节点(r7r3m206),它将在集群启动时启动应用程序 辅助节点 :一个PowerHA集群节点(r73m207),可以在发生故障时重新启动应用程序 硬件设定 图1...
  • IBM PowerHA 6 DARE 的功能介绍
  • IBM POWER是RISC处理器架构的一种,由IBM设计,全称为“Performance Optimization With Enhanced RISC”,POWER系列微处理器用于IBM的服务器、微电脑、工作站、超级电脑的主处理器。提到Power,大家都觉得“高大上”...
  • PowerHA完全手册范本.doc
  • 浅析PowerHA HyperSwap双活方案.docx
  • IBM PowerHA小型机中的战斗机.docx
  • 基于Nmon的PowerHA宕机故障分析.docx
  • PowerHA7.1_配置规范[归纳].pdf
  • PowerHA 系统构架在生产系统中的运用.pdf
  • PowerHA 系统构架在生产系统中的运用.zip
  • Power Enterprise Pool结合PowerHA的高可用技术实践.docx
  • IBM PowerHA新功能介绍

    2011-03-24 11:52:52
    IBM PowerHA for AIX(原名为High Availability Cluster Multiprocessing-HACMP)有助于保护重要业务应用避免计划内和计划外中断。十多年来,通过开发IBM磁盘存储解决方案套件,为核心数据业务弹性奠定基础,PowerHA ...

空空如也

空空如也

1 2 3 4 5 ... 19
收藏数 368
精华内容 147
关键字:

powerha