IBM Support

PowerHA SystemMirror for AIX V7.2 新機能/機能拡張の技術的ハイライト

News


Abstract

2015年10月に発表されたPowerHA SystemMirror for AIX V7.2 (以下、PowerHA 7.2) の新機能および機能拡張につき、技術的観点から説明します。読者として、PowerHAの基礎的知識をお持ちで、その提案・設計・構築・運用に携わる方を対象にしています。
当テクニカル・フラッシュは、提案・設計にあたっての前提条件や考慮点等をすべて列挙したものではありません。提案・設計にあたっては、必ず製品発表レター、PowerHAマニュアル等をあらかじめ参照してください。
このテクニカルフラッシュは2016年1月7日に公開されたもので、情報はas-isとなっています。

Content

概要
PowerHA 7.2 の主な新機能/機能拡張や変更点は以下のとおりです。
  • アプリケーションの停止時間の最小化を可能にする AIX 7.2 暫定フィックス(i-Fix)適用、及び PowerHA コードの更新
  • Live Partition Mobility (LPM) との連携
  • Power Enterprise Pools との組み合わせによる柔軟な PowerHA クラスター構成
  • リポジトリー・ディスクの自動交換
  • スプリットブレイン防止機能の強化
  • クラスター検証項目の追加
前提
PowerHA SystemMirror for AIX V7.2 の前提
  • サポートされるハードウェア
    POWER6 以降のプロセッサーを搭載したサーバー
    (POWER5 以前のサーバーは非サポート)
  • 前提 OS (※)
    AIX 6.1 TL09 以降
    AIX 7.1 TL03 以降
    AIX 7.2 以降
    ※ PowerHA 7.2 で提供される全ての機能を使用するためには AIX 7.1 TL04 または AIX 7.2 の導入が必要です。
新機能および機能拡張
  • PowerHA 7.1.3 から PowerHA 7.2 以降への無停止アップグレード (Non-Disruptive Upgrade : NDU)

    PowerHA の前提となる AIX のバージョン・アップや TL/SP 更新に伴うリブートを必要としない環境であれば、NDU 機能により、PowerHA クラスターの引継ぎ対象アプリケーションの停止を行わずに、PowerHA 7.1.3 から PowerHA 7.2 以降へのバージョン・アップを行うことができます。
<NDU が可能な AIX バージョン>
  • AIX 6.1 TL9 以降
  • AIX 7.1 TL3 以降
  • AIX 7.2 以降
<NDU の考慮事項>
  • 当テクニカル・フラッシュ発行時点 (2015/12/24) では、AIX の TL レベルの更新やバージョン・アップの際は、AIX のリブートが必要です。
  • PowerHA EE 環境で DS8000 の HyperSwap 機能を使用しており、NDU による PowerHA のアップグレードを行う場合は、PowerHA 7.1.3 SP4 以降がインストールされている必要があります。
  • PowerHA EE 環境で GLVM/RPV を構成しており、NDU による PowerHA のアップグレードを行う場合は、予め RPV のクライアント/サーバー構成を解除しておく必要があります。
  • PowerHA 7.2 で提供される全ての機能を使用するためには、AIX 7.1 TL04 または AIX 7.2 の導入が必要です(例：自動リポジトリー・ディスク・リプレース機能)。
  • NDU 実行中はリソース・グループが Unmanaged 状態になるため、アップグレードが完了するまで PowerHA による障害検知、及びそれに紐付くアクションが取られません。
  • アプリケーション・モニターが設定されていない場合、Unmanaged 状態からの PowerHA クラスター復帰後、アプリケーション・コントローラー始動スクリプトが実行され、アプリケーションが二重起動される可能性があります。
※ 具体的な手順については「インストールおよびマイグレーション」のセクションを参照してください。
AIX Live Kernel Update (LKU) サポート

AIX 7.2 で新しく提供された LKU 機能 (AIX のリブートを行わずに i-fix の適用を可能にする機能) を、PowerHA 7.2 クラスター環境でサポートします。
LKU 機能を利用可能にするための設定が PowerHA に追加されました。この設定により、LKU 中に PowerHA クラスターで必要な処理が自動的に行われるようになります(LKU 実行中の リソース・グループの Unmanaged 停止等)。デフォルトで有効です。
<PowerHA の LKU サポートの考慮事項>
  • LKU のブラックアウト期間はアプリケーションが一時的に停止します (LKU 自体の制約)。
  • PowerHA EE 環境では、LKU 実行中でも HyperSwap 機能、及び GLVM 同期モードはサポートされます。GLVM 非同期モードは同期モードに変更する必要があります。
  • LKU 実行中はリソース・グループが Unmanaged 状態になるため、LKU が完了するまで PowerHA による障害検知、及びそれに紐付くアクションが取られません。
  • アプリケーション・モニターが設定されていない場合、Unmanaged 状態からの PowerHA クラスター復帰後、アプリケーション・コントローラー始動スクリプトが実行され、アプリケーションが二重起動される可能性があります。
設定方法：
(SMIT での設定)
# smitty sysmirror
> Cluster Nodes and Networks
> Manage Nodes
> Change/Show a Node
"Enable AIX Live Update operation" を 設定
(コマンドラインでの設定)
# clmgr modify node [ ENABLE_LIVE_UPDATE={true | false} ]
Live Partition Mobility (LPM) サポートの拡張
LPM を安定して行うための PowerHA パラメーターの追加、LPM 操作に対する PowerHA クラスターの自動対応等、PowerHA 環境での LPM サポート内容が拡張されました。
LPM 中の SAN ベース通信経路の使用
PowerHA のホスト間通信ネットワークとして SAN ベース通信経路(※)を使用している場合、以前のバージョンでは LPM 実行前に構成を解除し、LPM 完了後に再構成する必要がありました。
PowerHA 7.2 では、SAN ベース通信経路が設定された PowerHA クラスター・ノードでも LPM を実行することが可能になりました。ただし、 SAN ベース通信は LPM 宛先システムに自動的に移行されないため、LPM 実行前に予め宛先システム上で SAN ベース通信を構成しておく必要があります。
※ SAN ベース通信経路は、PowerHA 6.1 までの非 IP ベース・ネットワークとしてのディスク・ハートビートや、PowerHA 7.1 以降の構成で必須のリポジトリー・ディスクとは異なります。第3の通信経路としてオプションで設定可能な、SAN スイッチを経由したディスク・アダプター間の通信のことを指します。
LPM ノード・ポリシー と LPM 中のノード障害検知タイムアウト値
LPM 実行中にリソース・グループを Unmanaged 状態にするかどうかを指定することが可能です (LPM_POLICY)。デフォルトでは Manage です (PowerHA による障害検知が可能な状態)。

また、LPM 実行中、PowerHA のノード障害検知タイムアウト値 (HEARTBEAT_FREQUENCY) を LPM のフリーズ期間よりも長い時間に設定することができます (HEARTBEAT_FREQUENCY_DURING_LPM)。これにより、LPM 実行中の不要なクラスター・イベントの発生を防ぐことができます。HEARTBEAT_FREQUENCY_DURING_LPM が設定されていない場合は、LPM 実行中も HEARTBEAT_FREQUENCY がノード障害検知タイムアウト値として使用されます。
これらの LPM 変数の提供により、以前のバージョンでは LPM 実行前に必要だった PowerHA の誤動作を防ぐための手動操作が不要になります。
設定方法：
(SMIT での設定)
# smit sysmirror
> Custom Cluster Configuration
> Cluster Nodes and Networks
> Manage the Cluster
> Cluster heartbeat settings
"LPM Node Policy" 及び "Node Failure Detection Timeout during LPM"を設定
(コマンド・ラインでの設定)
# clmgr modify cluster [ HEARTBEAT_FREQUENCY_DURING_LPM=<node_timeout> ] [ LPM_POLICY=<manage | unmanage> ]
※ LPM 変数を変更した際は、クラスターの検証と同期化が必要です。
参考：
Live Partition Mobility に関する公開情報のお知らせ
http://www-01.ibm.com/support/docview.wss?uid=jpn1J1011942（リンク切れ）
自動リポジトリー・ディスク・リプレース機能
PowerHA 7.1 以降、クラスター当たり 1 つのリポジトリー・ディスクという共有ディスクの構成が必須となりました。
PowerHA 7.1.1 では、リポジトリー・ディスクの障害時にサービスが停止せず､その後､ユーザーが新規リポジトリー・ディスクを指定し、動的に交換することができる機能が追加されました。
PowerHA 7.2 では、リポジトリー・ディスクの障害時に、予め登録しておいた代替リポジトリー・ディスクに、自動的に交換することができるようになりました。
設定手順：
1. プライマリー・リポジトリー・ディスクとバックアップ・リポジトリー・ディスクを全てのクラスター・ノードで共有できる構成にする
2. # smitty sysmirror
> Cluster Nodes and Networks
> Manage Repository Disks
> Add a Repository Disk
バックアップ・リポジトリー・ディスクを追加(最大 6 つ) (この際､PVがPVIDを持たない場合､各ノードでPVIDが割り振られます｡)
3. クラスター構成の検証と同期化
<自動リポジトリー・ディスク・リプレース機能の考慮事項>
  • AIX 7.1 TL04 または AIX 7.2 以降である必要があります｡
  • リポジトリー・ディスクがバックアップに切り替えられると errpt に通知が書き出されます (エラー・ラベル : 92EE81A5 CL_ARU_PASSED)。
  • 自動リプレースが実行されるタイミングは環境に依存します。
ROHA (Resource Optimized High Availability)
PowerHA はアプリケーション・コントローラーに設定された最小 CPU 数/メモリー量、及び必要 CPU数/メモリー量に応じ、アプリケーション起動/停止時に自動的に CPU/メモリーの DLPAR や CoD 操作を行う機能を提供しています。
CoD リソースとして Power Enterprise Pools を使用することにより、サービス・ノードとスタンバイ・ノードでプール内の CPU/メモリーを無駄なく配分することができ、企業全体として CPU/メモリーのアクティベーション費用やソフトウェアのライセンス費用を削減することができます。
PowerHA 7.1.x でも PowerHA 環境での Power Enterprise Pools の利用は可能でしたが、PowerHA との連携は行われず、ノード引継ぎ時のクラスター・ノードに対する CoD リソースの割り当て変更は HMC の手動操作、またはユーザー・スクリプトの作り込みが必要でした。
PowerHA 7.2 では、サービス・ノードでのリソース・グループ解放時にプールへ CPU/メモリーを戻し、スタンバイ・ノードでのリソース・グループ取得時にプールから CPU/メモリーを割り当てるという一連の操作を、PowerHA の設定のみで自動化できます。
各 PowerHA バージョンにおける CoD オファリングのサポート状況は、下表をご参照ください。
CoD Offering
Type
PowerHA 6.1/7.1
PowerHA 7.2
CUoD
CPU, メモリー
 ○ ○
Elastic (On/Off) CoD
 CPU
○
 ○
Elastic (On/Off) CoD メモリー
×
○
Utility CoD
CPU
○*1
 ○*1
Trial CoD
CPU, メモリー
○
 ○
Enterprise Pools
CPU, メモリー
×
○
*1 Hypervisor レベルで処理されるため、PowerHA 側での対応は特になし
<Power Enterprise Pools と PowerHA を組み合わせた場合のクラスター・ノードへの CPU 割り当て例>
Power Enterprise Pools を使用しない場合
Power Enterprise Poolsを使用する場合
引継ぎ前
引継ぎ後
引継ぎ前
引継ぎ後
サービス
スタンバイ
サービス
スタンバイ
サービス
スタンバイ
サービス
スタンバイ
CPU数
5
1
5
5(4コア追加)
5
1
1(4コア返却)
5(4コア追加)
必要コア数合計
10
6
参考：
IBM Power System Pools（リンク切れ）
http://www-06.ibm.com/systems/jp/power/hardware/systempools/
Power エンタープライズ・プール
Power Enterprise Pools on IBM Power Systems
PowerHA SystemMirror におけるリソース最適化高可用性
クラスター検証の拡張
PowerHA は、適切なクラスター操作と確実な障害対応が可能な環境であることをチェックするための仕組みを提供しています。
PowerHA 7.2 では、クラスターの検証項目に詳細チェック・オプションが追加されました。詳細チェック・オプションを有効にした際の検証項目には以下のものがあります。
  • クラスター・ノード間の LVM 整合性をチェック (PVID、ファイルシステム、パラメーター)
  • LVM, NFS に対して AIX Runtime Expert のチェック機能を利用
  • ネットワーク・エラーをチェックし、しきい値を超えた場合に警告 (受信+送信パケット・カウントの 5%)
  • GLVM バッファー・サイズのチェック
  • セキュリティ構成のチェック (パスワード・ルール)
  • カーネル・パラメーターのチェック (ネットワーク関連, VMM, J2)
  • ディスク予約ポリシーのチェック (single_path でないこと)
<クラスター検証詳細チェックオプションの考慮事項>
  • 詳細チェック・オプションが有効になっている場合、環境によってはクラスター検証に通常よりも多くの時間がかかります。
  • 詳細チェック・オプションは、全てのノード上でクラスター・サービスが停止している場合にのみ選択可能です。
  • デフォルトでは無効です。
Quarantine ポリシー
PowerHA 7.1 以降の PowerHA では、ノード間通信経路として IP ベース・ネットワークとリポジトリー・ディスクを必須構成として持ちます。また、オプションとして SAN ベース通信経路を設定可能です。PowerHA は全てのノード間通信経路が断絶した場合にノード・ダウンとみなし、対応する処理を行いますが、いずれかの経路が使用可能な場合は部分的な障害(ネットワーク障害)として処理します。
しかしながら多重障害等の何らかの理由により、ノード自体には障害が発生していないにも関わらず全てのノード間通信が不通となった場合、クラスター分割(スプリット・ブレイン状態)が発生する可能性がありました。
PowerHA 7.2 では、クラスター分割による共有ディスク上のアプリケーション・データの破壊を防止するために、クリティカル・リソース・グループに対し Quarantine ポリシーを構成できます。Quarantine ポリシーを設定すると、クリティカル・リソース・グループが引継ぎ先ノードでアクティブになる前に、元アクティブ・ノードをクラスターから切り離します。
Quarantine ポリシーとして指定可能なオプションは、以下の 2 つです。
  • アクティブ・ノード停止ポリシー
    クラスター分割発生時、クリティカル・リソース・グループを引継ぎ先ノードでアクティブにする前に、無応答のノードを HMC から強制的に shutdown します。
  • ディスク・フェンシング
    クラスター分割発生時、クリティカル・リソース・グループに含まれる共有ディスクが、SCSI-3 PR (永続予約)により元アクティブ・ノードから隔離されます。
<Quarantine ポリシーの考慮事項>
  • Quarantine ポリシーで保護されるリソース・グループはクリティカル・リソース・グループである必要があります。クリティカル・リソース・グループは拡張クラスター (Stretched Cluster) 構成に 1 つ作成できます。
  • アクティブ・ノード停止ポリシーを使用する場合、HMC にパスワードなしで ssh が実行可能である必要があります。
  • ディスク・フェンシングを使用する場合、ストレージ・サブシステムが SCSI-3 PR (永続予約)および PR_SHARED の ODM reserve_policy をサポートしている必要があります。
NFS Backed Tie Breaker ディスク・サポート
Tie Breaker ディスクは、サイト間のネットワークの断絶によりクラスターが分割された際、設定されたクラスター管理ポリシー(分割/マージ)に応じ、クラスター・ノードの動作を決定するために使用されます。
分割ポリシー/マージ・ポリシーで使用される Tie Breaker ディスクとして、以前のバージョンでは SCSI ディスクまたは iSCSI ディスクがサポートされていましたが、これに加え PowerHA 7.2 では NFS ファイル を指定できるようになりました。
PowerHA 7.2 からサポートのなくなった機能
IBM Systems Director の PowerHA プラグインによる GUI 操作は PowerHA 7.2 からサポートされません。
インストールおよびマイグレーション
PowerHA V7.2 へのマイグレーション・パス
PowerHA V7.2 に直接マイグレーション可能な PowerHA のバージョンは、PowerHA V6.1 以降となります。
PowerHA V7.1.3 から V7.2 へのマイグレーションでは、Non-Disruptive Upgradeがサポートされています。詳細は上記『新機能および機能拡張』の項をご参照ください。
To
7.1.1
7.1.2
7.1.3
7.2
6.1
R/S/O
R/S/O
R/S/O
R/S/O
7.1
S/O
S/O
S/O
S/O
From 7.1.1
R/S/O
R/S/O
R/S/O
7.1.2
R/S/O
R/S/O
7.1.3
R/S/O/N
R=Rolling Upgrade, S=Snapshot Upgrade, O=Offline Upgrade, N=Non-disruptive Upgrade
PowerHA V7.2 インストール手順
PowerHA V7.2 を新規インストールする際の手順ですが、V7.1 の手順と大きな変更はありません。
すでに公開している初心者のための手順書『PowerHA V7.1 はじめての構築～PowerHA SystemMirror for AIX V7.1 簡単構築ガイド～』がありますので、詳しくはそちらをご参照ください。
【PowerHA V7.1 はじめての構築】
AIX関連技術情報
　　-> 「導入編」タブをクリック
　　　-> 「PowerHA 7.1 はじめての構築」をクリック
　　　　※ ドキュメントはPDF形式で提供しています。閲覧には Adobe Reader が必要です。
PowerHA V7.2 へのマイグレーション手順
ここでは、マイグレーション手順の例として、PowerHA V7.1.3 から V7.2 への Non-Disruptive Upgrade(NDU) の手順の概要を記述します。
その他の方法による手順については、PowerHA V7.2のマニュアル”PowerHA SystemMirror クラスターのアップグレード”をご参照ください。
※ NDU実行時の考慮事項については「新機能および機能拡張」のセクションを参照してください。
マイグレーション手順：
1. SMIT で「リソース・グループの管理解除」を実行
2. PowerHA V7.2 をインストール
3. SMIT でクラスター・サービスを開始
4. クラスター内の残りのノードで上記 1～3 を繰り返す

[{"Type":"MASTER","Line of Business":{"code":"LOB08","label":"Cognitive Systems"},"Business Unit":{"code":"BU054","label":"Systems w\/TPS"},"Product":{"code":"SSPHQG","label":"PowerHA SystemMirror"},"ARM Category":[{"code":"a8m3p000000hAumAAE","label":"PowerHA System Mirror"}],"Platform":[{"code":"PF025","label":"Platform Independent"}],"Version":"All Versions"}]

Document Information

Modified date:
05 February 2023

UID

ibm16851821

Page Feedback