IBM Support

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

News


Abstract

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

Content

概要
PowerHA SystemMirror Standard Edition V7.1.1 は、PowerHA SystemMirror V7.1 の新しいテクノロジー・レベル (TL1) の製品です。主な新機能/機能拡張や変更点は以下のとおりです。
  • リリース戦略の改良
  • リポジトリー・レジリエンス、JFS2マウント・ガード、デッドマン・スイッチ（DMS)といった、さらに堅牢性を高めるための機能
  • プライベート・ネットワーク、ミラー･プールとLVMサイト間ミラーリング、フォアグラウンドでのアプリケーション起動といったより柔軟なクラスター構成のための機能
  • Smart Assist対象アプリケーションの追加による、使いやすさ向上のための機能
前提
PowerHA 7.1.1 (SP00)の前提
AIX 7.1 TL1 SP02
AIX 6.1 TL7 SP02
PowerHA 7.1.1 SP01の前提 (リポジトリー・レジリエンス機能はPowerHA 7.1.1 SP01からのサポートになります。)
AIX 7.1 TL1 SP03
AIX 6.1 TL7 SP03
PowerHA 7.1.0においても、AIX 7.1 TL1もしくはAIX 6.1 TL7以降のCAAが使用可能です。
PowerHA 7.1.0 (参考)
PowerHA 7.1.1 SP00
PowerHA 7.1.1 SP01
AIX 7.1 TL0もしくはAIX 6.1 TL6
Yes
NO
NO
AIX 7.1 TL1もしくはAIX 6.1 TL7
Yes
Yes
AIX 7.1 TL1 SP02以降
AIX 6.1 TL7 SP02以降
Yes
AIX 7.1 TL1 SP03以降
AIX 6.1 TL7 SP03以降
リリース戦略/サポート期間
PowerHA SystemMirror は、従来はAIX とは異なるリリース戦略をとっていました。しかしこのリリースから、PowerHA SystemMirror のリリース戦略は、AIX リリース戦略と密接に連携するように変更されました。PowerHA SystemMirror のリリースは、今後以下のようになります。
  • 3年以上の間隔での主要なアップデートもしくはバージョン・アップ
    - PowerHA V7.1 は、最初のメジャー・バージョン
  • リリースごとに5年の標準サポートを提供
    - たとえばPowerHA SystemMirror 7.1 製品は、少なくとも 2010 年から 2015 年までサポートされます
  • 1年に1度のテクノロジー・レベル・アップデート
    - 今回発表のV7.1.1は、PowerHA V7.1のTL1
  • 各テクノロジー・レベルは3年間サポート
  • 旧テクノロジー・レベルのメディアはライフ期間はPRPQで入手可能
※　PowerHA V6.1以前のバージョン・リリースにはこのポリシーは適用されません。
ミドルウェアサポート
PowerHA Smart Assistを利用することで、アプリケーションを容易にPowerHAに構成することができます。PowerHA V7.1.1では、以下のSmart Assistが追加されました。
Smart Assist for Tivoli Directory Server
Smart Assist for Tivoli Directory Server を使用することにより、Tivoli Directory Server が既に構築されている環境の PowerHA SystemMirror 構成を容易にセットアップできます。
Smart Assist for WebSphere MQSeries
Smart Assist for WebSphere MQSeries を使用することにより、WebSphere MQ が既に構築されている環境の PowerHA SystemMirror 構成を容易にセットアップできます。
Smart Assist for SAP liveCache Hot Standby
SAP liveCache Hot StandbyとIBM DS8000やSANボリューム・コントローラー(SVC)を組み合わせた環境におけるPowerHA構成をサポートし、高速フェールオーバーを可能にします。PowerHAとSAP liveCacheを組み合わせた構成については、以下の資料が参考になりますのでご参照ください。
IBM Techdocs White Paper: Invincible Supply Chain - SAP APO Hot Standby liveCache on IBM Power Systems:
Smart Assistを利用する場合、サポートしている構成や前提条件があります。詳しくは、マニュアルやPowerHAインストール時に導入される /usr/es/sbin/cluster/release_notes_assist.htm ファイルを参照ください。
Smart Assists for PowerHA SystemMirror:
使い易さ
可用性
リポジトリー・レジリエンス
従来のPowerHA 7.1環境では、リポジトリー・ディスクへのアクセスが出来なくなるような障害の場合にはそのまま稼働できましたが、リポジトリー・ディスクが論理障害となる様な場合にはノードが停止される可能性が有りました。
AIX 7.1 TL1 SP3もしくはAIX 6.1 TL7 SP3レベル、およびPowerHA 7.1.1 SP01は、リポジトリー・レジリエンス機能を提供します。
この機能により、論理障害を含むリポジトリー・ディスク障害時に、ノードはローカルキャッシュを使用して稼働し続けます。
更に、リポジトリー・ディスク障害時を含むPowerHAクラスター・サービス稼働中に、新しいディスクを使用して、リポジトリー・ディスクを再構成することが可能となります。
リポジトリー・ディスクが失われている間は、クラスターの変更は出来ません。
リポジトリー・ディスク障害メッセージ出力
リポジトリー・ディスク物理障害/接続障害時メッセージ出力例 (リポジトリー・ディスク論理障害時を除く)
エラーログに以下の様なエントリーが出力されます。
エラーログ出力例
---------------------------------------------------------------------------
ラベル: OPMSG
ID: AA8AB241
日付/時刻: Sat Aug 18 07:35:00 JST 2012
順序番号: 9393
マシン ID: 00006D9AD400
ノード ID: ivmc26
クラス: O
タイプ: TEMP
WPAR: Global
リソース名: clevmgrd
説明
オペレーター通知
ユーザー側の原因
errlogger コマンド
推奨される処置
詳細データを検討してください
詳細データ
errlogger コマンドからのメッセージ
Error: Node 0x81366CD66A7611E196EBAA4757F3F305 has lost access to repository disk hdisk1. +++
---------------------------------------------------------------------------
hacmp.outとコンソールにメッセージが出力されつづけます。メッセージ出力間隔は、30秒間隔を初期値とし、1時間を上限として5回出力される度に2倍となります。
hacmp.out メッセージ例
ERROR: rep_disk_notify : Sat Aug 18 07:35:00 JST 2012 : Node "ivmc26"(0x81366CD66A7611E196EBAA4757F3F305) on Cluster ivmc1626_cluster has lost access to repository disk hdisk1.
Please recover from this error or replace the repository disk using smitty.
ERROR: rep_disk_notify : Sat Aug 18 07:35:31 JST 2012 : Node "ivmc26"(0x81366CD66A7611E196EBAA4757F3F305) on Cluster ivmc1626_cluster has lost access to repository disk hdisk1.
Please recover from this error or replace the repository disk using smitty.
リポジトリー・ディスク回復時には上のエラー・メッセージは停止し、以下の様な回復メッセージが出力されます。
hacmp.out メッセージ例
rep_disk_notify: Sat Aug 18 07:35:48 JST 2012 : Access to repository disk has been restored on Node "ivmc26"
もしリポジトリー・ディスク障害メッセージが停止しない場合には、/usr/es/sbin/cluster/README7.1.1.UPDATEを参照の上、回復させてください。
リポジトリー・ディスク論理障害時メッセージ出力例
/var/adm/ras/syslog.caa に10分間隔でメッセージが出力されつづけます。
syslog.caa メッセージ例
syslog.caa メッセージ例
Aug 15 17:57:25 node1 caa:info cluster[10223624]: clconfd.c clconfd 216 START
Aug 15 17:57:25 node1 caa:info cluster[10223624]: cluster_utils.c cl_run_log_method 2161 START '/usr/sbin/lsvg caavg_private'
Aug 15 17:57:25 node1 caa:info cluster[10223624]: cluster_utils.c cl_run_log_method 2190 FINISH return = 1
Aug 15 17:57:25 node1 caa:info cluster[10223624]: cluster_utils.c cl_run_log_method 2161 START '/usr/sbin/varyonvg -b -u caavg_private'
Aug 15 17:57:25 node1 caa:info cluster[10223624]: cluster_utils.c cl_run_log_method 2190 FINISH return = 1
Aug 15 17:57:25 node1 caa:err|error cluster[10223624]: clconfd.c clconfd 242 Not able to varyon CAAVG on hdisk3
Aug 15 17:57:25 node1 caa:info cluster[10223624]: clconfd.c clconfd 448 FINISH clconfd
Aug 15 18:07:25 node1 caa:info cluster[10223624]: clconfd.c clconfd 216 START
Aug 15 18:07:25 node1 caa:info cluster[10223624]: cluster_utils.c cl_run_log_method 2161 START '/usr/sbin/lsvg caavg_private'
Aug 15 18:07:25 node1 caa:info cluster[10223624]: cluster_utils.c cl_run_log_method 2190 FINISH return = 1
Aug 15 18:07:25 node1 caa:info cluster[10223624]: cluster_utils.c cl_run_log_method 2161 START '/usr/sbin/varyonvg -b -u caavg_private'
Aug 15 18:07:25 node1 caa:info cluster[10223624]: cluster_utils.c cl_run_log_method 2190 FINISH return = 1
Aug 15 18:07:25 node1 caa:err|error cluster[10223624]: clconfd.c clconfd 242 Not able to varyon CAAVG on hdisk3
Aug 15 18:07:25 node1 caa:info cluster[10223624]: clconfd.c clconfd 448 FINISH clconfd
なお、syslog.caa はローテートされる設定となっている為、常にopenして監視するような監視方法の場合にはローテート時に監視が外れてしまう可能性があります。その様な場合、必要に応じて、別途 caa.err を対象とするローテートしないログファイルを 用意し、そちらを監視する等の対応をご検討ください。
リポジトリー・ディスク障害状態の影響
CAAの構成変更は拒絶されます。CAAの構成変更を伴わない限りは、PowerHAクラスター・サービスの起動、停止、引き継ぎ、PowerHAレベルでの動的再構成(DARE)や同期などもサポートされます。
ただし、ノードをリブートしてしまうと、ノードはCAAクラスターに参加できず、結果としてPowerHAクラスター・サービスも起動できなくなります。
PowerHA 7.1から提供されるrootvg監視機能は、使用できません。
ユーザーはリポジトリー・ディスク障害を認識し、新しいディスクを割り当てる必要があります。
新しいリポジトリー・ディスクの選択
以下のSMITメニューより、新しいリポジトリー・ディスクを指定してCAAクラスターを再構成することが可能です。
リポジトリーディスク障害前から稼働しつづけているノードが必要です。このノードがローカルにキャッシュしている情報を用いて新しいリポジトリー・ディスクを再構成します。
新しく指定するディスクは、リポジトリー・ディスクの要件を満たし、各ノードからPVID付きで認識されている必要があります。
この交換は、PowerHAクラスター・サービス稼働中に、動的に行う事も可能ですし、PowerHAクラスター・サービス停止状態で行う事も可能です。
以下のSMITメニューを実行すると、確認サブメニューの後、即座に各ノード上のPowerHA設定への反映および実際のリポジトリー・ディスクの交換が行われます。反映の為に別途検証同期を行う必要はありません。
# smit sysmirror
問題判別ツール
新規クラスター・リポジトリー・ディスクの選択
--------------------------------------------------------------------------------
新規クラスター・リポジトリー・ディスクの選択
フィールドの値を入力または選択してください。
変更を完了したら ENTER キーを押してください。
[入力フィールド]
* クラスター名 cluster01
* リポジトリー・ディスク [hdisk2] +
--------------------------------------------------------------------------------
リポジトリー・ディスクの変更はPowerHA定義情報の変更を伴うため、全てのノードのAIXが稼働している状況で実施することをお勧めします。
一部のノードが停止している状況での変更が必要な場合、そのノードの回復後に、情報を反映させる必要があります。
手順の詳細はREADMEフィルをご参照ください。
/usr/es/sbin/cluster/README7.1.1.UPDATE
JFS2マウントガード
ファイルシステムを、複数ノードから同時にmountすると、ファイルシステムの整合性が失われる可能性が有ります。
その状況が発生するリスクを防ぐために、AIXはJFS2に対して、新たに mount guard 機能を提供しました。
PowerHAは、拡張コンカレントVGのアクティブ/パッシブ モードvaryonや、ディスクフェンス機能により、その状況からファイル・システムを保護していますが、仮にこれらが正しく動作できなくとも、JFS2 mount guard 機能を使用し、mount中のファイルシステムを、ユーザーが誤って他のノードからmountしてしまうことが無いようにガードする様になりました。
PowerHAはJFS2 Mount GuardをサポートするAIXレベルの場合、共用JFS2ファイルシステムに関して、Mount Guardを使用する様にJFS2の属性を変更します。
その結果、リモート・ノードでmount中のJFS2ファイルシステムに対する、ユーザーによる mount が抑止されます。
但し、mount時に -o noguard オプション を使用すると、マウントガードを無視してmountが出来てしまい、ファイルシステムの整合性が失われる可能性が有ります。
また、logredo, fsck, chfsなどの実行が抑止がされる訳ではありません。リモート・ノードでmount中のJFS2ファイルシステムに対してこれらを実行すると、ファイルシステムの整合性が失われる可能性が有ります。なお、これらを実行した後には、マウントガードも外れ、 -o noguard オプションが無くともmountが可能となります。
PowerHAによるJFS2資源取得時には、必ずlogredo処理が行われる為、JFS2 Mount Guardにより資源取得が妨げられることはありません。
以下を満たすレベルにおいて、PowerHAクラスター環境における共用JFS2ファイルシステムに関して、JFS2 Mount Guard機能が使用されるようになります。
AIX 7.1 TL1以降
AIX 6.1 TL7以降
かつ
PowerHA 7.1.1 SP00
PowerHA 7.1 SP05 IV12910 mount guard support (http://www-01.ibm.com/support/docview.wss?uid=isg1IV12910)（リンク切れ）
PowerHA 6.1 SP07 IV06544 mount guard support (http://www-01.ibm.com/support/docview.wss?uid=isg1IV06544)（リンク切れ）
PowerHA 5.5 SP10 IV10903 mount guard support (http://www-01.ibm.com/support/docview.wss?uid=isg1IV10903)（リンク切れ）
JFSファイルシステムに対しては提供されません。
デッドマン・スイッチ（DMS）
PowerHA 6.1までは、システムが非常に高負荷な状況に陥るなどの状況によりノードの生存を外部に知らせる事が出来なくなった場合、ノードを強制停止するデッドマン・スイッチ（DMS）機能が提供されていました。
AIX 7100-00, 6100-06のCAAでは、負荷状況に従って障害検出を自動的にチューニングすることにより、高負荷状況に陥ったとしても、誤ったノード引き継ぎは抑止される様になりました。
AIX 7100-01, 6100-07のCAAは、加えて、DMS機能を再び提供するようになりました。
マルチ・ノード環境において、CAAはノードの孤立を検出します。
システムが非常に高負荷な状況に陥るなどの状況により、LAN経由、SANベースの通信経路経由、repositoryディスク経由で、ノードの生存を外部に知らせる事が出来ない状態となった場合、DMS機能によりノードは強制停止(デフォルト動作)されます。
発生までの時間はチューニングできません。
DMSによりノードを強制停止させるかどうかは、clctrlコマンドにより設定、および状況の確認が可能です。
強制停止(デフォルト)
# clctrl -tune -o deadman_mode=a
1 tunable updated on cluster lpar54_cluster.
なお、強制停止後、ノードはリブートされます。
停止させない
# clctrl -tune -o deadman_mode=e
1 tunable updated on cluster lpar54_cluster.
現在の値の確認
# clctrl -tune -L deadman_mode
NAME DEF MIN MAX UNIT SCOPE
ENTITY_NAME(UUID) CUR
--------------------------------------------------------------------------------
deadman_mode a c n
lpar54_cluster(6887d730-69a2-11e1-a668-96d8a811750b) a
--------------------------------------------------------------------------------
エラーログの例
---------------------------------------------------------------------------
ラベル: KERNEL_PANIC
ID: 225E3B63
日付/時刻: Sat Mar 10 15:42:22 JST 2012
順序番号: 7417
マシン ID: 00006ABAD400
ノード ID: ivmc16
クラス: S
タイプ: TEMP
WPAR: Global
リソース名: PANIC
説明
ソフトウェア・プログラムが異常終了
推奨される処置
問題判別手順を実行してください
詳細データ
代入文字列
パニック文字列
Deadman timer triggered.
---------------------------------------------------------------------------
機能拡張
プライベート・ネットワーク
オラクルは、他のハートビートやプロトコルで使用されないネットワークを必要とします。
PowerHA 6.1およびそれ以前はこの要件をサポートしていましたが、7.1 TL0ではサポートされませんでした。
PowerHA 7.1 TL1では、ネットワークの属性として再び 専用(private) を提供し、この要件を満たすことが再び可能となりました。
PowerHA 7.1 TL1は、クラスター・サービス起動時に、プライベート・ネットワークのローカル・ノードにおけるインターフェースを/etc/cluster/ifrestrictテキストファイルに反映します。
CAAはifrestrictの内容変更を動的にキャッチアップし、そのインターフェースからのマルチキャストアドレス宛のハートビート送信を抑止します。
Private属性とするネットワークでは、IPアドレス・テークオーバーはサポートされません。
Private属性とするネットワークには、ホスト名が関連づけられているインターフェースが含まれていてはいけません。
この属性変更の同期には、クラスター・サービスの停止が必要です。動的な属性変更の反映はサポートされません。
なお、publicからprivateへの変更も、privateからpublicへの変更も可能です。
ミラー・プールとLVMサイト間ミラーリング
クロスサイトLVMミラーリング構成とは、
PowerHA 6.1まででサポートされていた、SANで接続された2サイトにノード及びサイト間でLVMミラーを行うストレージを配置する、比較的近距離間での災害対策ソリューションです。
PowerHA 7.1はサイトの概念をサポートしない為、クロスサイトLVMミラーリング構成もサポートしませんでした。
PowerHA 7.1 TL1は、ミラープール機能、およびリポジトリー・レジリエンス機能により、同等の構成、管理をサポートします。
SANで接続されたサイト間でのLVMミラー構成
2PVからなる共用VG構成でのサイト間LVMミラー構成
SANで接続された各サイトにそれぞれ1PV、合わせて2PVからなるVG(複数可)であれば、LVの「各論理区画のコピーを別の物理ボリュームに割り当てる」属性を、「はい」(デフォルト)などとすることで、データをサイト間でミラーリングする事が指定可能です。
ミラープールを使用するサイト間LVMミラー構成 (主に2PVを超える共用VGの構成)
SANで接続された各サイト間で、2PVを超えるVGを用いたLVMミラーを行う構成の場合、対象VGに含まれる各サイト上のPVをミラープールとしてまとめることで、同様の配置の指定、操作が可能となります。
ミラープールとは
  • ミラープールとは、LVMミラーcopy1,copy2,copy3の配置先として指定できるスケーラブルVG内のディスクによる相互に排他的な集合です。
  • VGにミラープールを3つまで構成可能です。
  • VGにSuper Strictミラー・プール属性を設定することにより、各ミラー・プールに、各論理ボリュームの完全なミラー・コピーを含める様に指定できます。(chvg -M s VGNAME)
  • reorgvgコマンドにより、論理ボリュームの各コピーを、意図したミラープールに再配置させることが可能です。
  • PowerHAのC-SPOCメニューから、共用VGにおけるミラープールの操作がサポートされます。（後述)
ミラープールを使用するサイト間LVMミラー構成とするには、以下の様に構成します。
  • スケーラブルVG構成とし、かつSuper Strictミラー・プール属性を設定
  • 各サイトのPVをそれぞれ別のミラープールに構成
各PVは、各ミラー・プールに手動で割り当てられなければなりません。
VGの各サイト上のPVが正しく同じミラープールで纏められていること、ディスクがどのミラープール間でのミラーであるのかは、ユーザーが責任を持つ必要があります。
PowerHAによるLVMミラーを用いたサイト障害ソリューション
ストレージ、PowerHAは以下の様に構成する必要があります。
  • 共用ディスクは、SANで接続されたサイト間でのLVMミラー構成とする。
  • 各サイトのノード間でPowerHAクラスターを構成
  • 各サイトのノードは、両サイトのストレージにSANで接続
  • リポジトリー・ディスクはどちらかのサイト上に構成 (ミラーリングや複数PVの使用がサポートされないため)
  • リポジトリー・レジリエンス機能によりリポジトリー・ディスクを代替できる様に、リポジトリー・ディスクを置かないサイトにも、予備のディスクを用意しておくことが望まれます。
AIX, PowerHAは以下の様に設定する必要があります。
  • 共用VGの、Quorum保護を無効に設定
  • リソース・グループ定義において、強制varyonを使用する 属性を「はい」と設定
なお、このオプションが使用されるのは、クラスター停止状態から、一方のサイトのみでサービスを起動する場合等になります。
正常稼働状態からノード障害が発生して引き継ぎが行われる場合には、スタンバイ･ノードにおいてパッシブモードではあるが既にvaryonしている為、引き継ぎに強制varyonオプションは使用されません。
サイト障害時動作は以下の様になります。
  1. ノード及びミラーリングの一方のストレージが障害となる
  2. 他方のノードが、LVMミラーの残ったcopyを用いて資源を引き継ぎ、サービスを再開
  3. リポジトリー・ディスクが障害サイト上に有った場合、リポジトリー・レジリエンス機能により、手動で、残ったサイト上のディスクを用いてリポジトリー・ディスクを再構成
サイト回復時の運用
  • ディスクの活動化、syncvgなどはユーザーオペレーションが必要となります。
PowerHA C-SPOCによるミラー・プールのサポート
以下のSMITメニューが提供されます。
# smit sysmirror
システム管理 (C-SPOC)
ストレージ
ボリューム・グループ
ボリューム・グループのミラー・プールの管理
--------------------------------------------------------------------------------
ボリューム・グループのミラー・プールの管理
カーソルを選択したい項目に移動して、ENTER キーを押してください。
すべてのミラー・プールの表示
ボリューム・グループのミラー・プールの表示
ミラー・プールの特性の変更/表示
ディスクをミラー・プールに追加
ディスクをミラー・プールから除去
ミラー・プールの名前変更
ミラー・プールの除去
--------------------------------------------------------------------------------
これにより、PowerHA環境でのミラープールの操作が容易になります。
ミラープールは、GLVMなど、クロスサイトLVMミラーの代替用途に限らない為、PowerHA 6.1に対してもC-SPOCでの操作がサポートされます。
既にLVが構成されミラーされているSuper Strictミラー・プール属性VGに対して、「ディスクをミラー・プールに追加」を行うと、自動的に、LVのcopy1から順にそのミラープールが指定されます。
既にミラープールが設定されているSuper Strictミラー・プール属性VGにLVを追加する際などには、mklv -c2 -p copy1=MP1 -p copy2=MP2 vg00 10の様に、ミラーコピー名の指定が必要となることがあります。
フォアグラウンドのアプリケーション起動
アプリケーション･コントロール・スクリプトの始動スクリプト(以降アプリケーション･コントロール・スタート・スクリプト)は、バックグラウンドで実行されていました。これは、ユーザーの作成したスクリプトの不備により、クラスターがハングアップしてしまうリスクを削減するためです。
リソース・グループが親子依存関係を持つ構成など、あるアプリケーションの起動完了を待って次の処理を進める必要がある場合には、PowerHAではアプリケーション・モニターの始動モニターが使用可能でした。
PowerHA 7.1 TL1は、始動モニターに加えて、アプリケーション･コントロール・スタート・スクリプトをバックグラウンドで実行するかフォアグラウンドで実行するかを指定するアプリケーション始動モード オプションを提供します。(デフォルトはバックグラウンド)
--------------------------------------------------------------------------------
アプリケーション・コントローラー・スクリプトの追加
フィールドの値を入力または選択してください。
変更を完了したら ENTER キーを押してください。
[入力フィールド]
* アプリケーション・コントローラー名 []
* 始動スクリプト []
* 停止スクリプト []
アプリケーション・モニター名 +
アプリケーション始動モード [フォアグラウンド] +
--------------------------------------------------------------------------------
これにより、アプリケーションの起動完了を待つ必要があり、かつアプリケーション･コントロール・スタート・スクリプトが、アプリケーション起動完了を待って制御を戻す実装の場合には、PowerHAの構成をシンプルにすることが可能となります。
注意
正しく設計されなかったアプリケーション･コントロール・スタート・スクリプトは、config_too_longにより警告されるクラスター・処理のハングアップ状態を引き起こす可能性が有ります。
PowerHA 7.1 TL1 SP1現在、アプリケーション始動モードをフォアグラウンド指定としても、その戻り値は確認されません。
その為、現在は、アプリケーションが正常に稼働したことを確認の上で後続の処理を行わせるには、従来通り始動時モニターが必要です。
この制約は将来解消される予定です。
引き継ぎ開始時間の調整
PowerHA 7.1 TL1は、ノード障害検出までの時間、および検出してから引き継ぎを開始するまでの時間をチューニングするためのパラメーターを設定できるようになりました。
ネットワーク毎に異なる値を設定することは出来ません。
Failure Cycle もしくは Node Failure Detection Timeout (CAAではnode_timeoutに相当), Grace Period もしくはFailure Indication Grace Time (CAAではnode_down_delayに相当)を設定することが可能です。
Failure Cycle もしくは Node Failure Detection Timeout は、ノードが障害であると認識するまでの時間を指定します。
設定可能値は10,000m秒～600,000m秒、デフォルト20,000m秒 (単位はm秒もしくは秒)
Grace Period もしくはFailure Indication Grace Time は、ノード障害検出から引き継ぎ処理開始までの時間を指定します。
設定可能値は5,000m秒～600,000m秒、デフォルトは10,000m秒 (単位はm秒もしくは秒)
これらは、パケットの間隔や回数を指定する物ではありません。
# smit sysmirror
Custom Cluster Configuration
Cluster Nodes and Networks
Manage the Cluster
Cluster Heartbeat Settings
--------------------------------------------------------------------------------
Cluster heartbeat settings
Type or select values in entry fields.
Press Enter AFTER making all desired changes.
[Entry Fields]
* Grace Period [0] #
* Failure Cycle [0] #
--------------------------------------------------------------------------------
0,0 は、デフォルトを意味します。
もしくはSPレベルによっては以下の表示となります。
--------------------------------------------------------------------------------
Cluster heartbeat settings
Type or select values in entry fields.
Press Enter AFTER making all desired changes.
[Entry Fields]
* Node Failure Detection Timeout [20] #
* Failure Indication Grace Time [10] #
--------------------------------------------------------------------------------
設定値は同期により有効となります。
Cluster Aware AIX(CAA) AIX 7100-01, 6100-07
CAA概要
AIX 7.1 TL1もしくはAIX 6.1 TL7以降のCAAではSolid DBを使用しなくなりました。
Solid DBはAIXにインストールされていますが使用されません。
solid, solidhacサブシステムはCAAでは使用されません。
cldサブシステムは存在しなくなりました。
クラスター・リポジトリー・ディスク
クラスター・リポジトリー・ディスク容量ガイドライン
PowerHAのクラスター・リポジトリー・ディスク容量の要件は512MB以上460GB以下に変更されました。
クラスター・リポジトリー・ディスクの必要容量は共有ディスク、クラスターのノード数、クラスターのアダプター数などに依存します。
CAAとしてのクラスター・リポジトリー・ディスク容量の推奨は以前と変わらず10GBです。
クラスター・リポジトリー・ディスクに使用可能なマルチパス構成の追加
以下のデバイス・ドライバを使用するディスクをクラスター・リポジトリー・ディスクとして構成可能になりました。
EMC PowerPath
Hitachi Dynamic Link Manager (HDLM)
クラスター・リポジトリー・ディスクのデバイス名
AIX 7.1 TL1もしくはAIX 6.1 TL7以降のCAAではクラスター・リポジトリー・ディスクのデバイス名を変更しなくなりました。
Solid DBが使用していたクラスター・リポジトリー・ディスク上のファイルシステム/clrepos_private1, /clrepos_private2などは構成されません。
CAA (AIX 7100-00, 6100-06)
# lspv | grep caavg_private
caa_private0 00f62fc6d7f58462 caavg_private active
# lsvg -l caavg_private
caavg_private:
LV NAME TYPE LPs PPs PVs LV STATE MOUNT POINT
caalv_private1 boot 1 1 1 closed/syncd N/A
caalv_private2 boot 1 1 1 closed/syncd N/A
caalv_private3 boot 4 4 1 open/syncd N/A
fslv00 jfs2 4 4 1 open/syncd /clrepos_private1
fslv01 jfs2 4 4 1 closed/syncd /clrepos_private2
powerha_crlv boot 1 1 1 closed/syncd N/A
CAA (AIX 7100-01, 6100-07)
# lspv | grep caavg_private
hdisk3 0004d2a2e1f0959e caavg_private active
# lsvg -l caavg_private
caavg_private:
LV NAME TYPE LPs PPs PVs LV STATE MOUNT POINT
caalv_private1 boot 1 1 1 closed/syncd N/A
caalv_private2 boot 1 1 1 closed/syncd N/A
caalv_private3 boot 4 4 1 open/syncd N/A
CAAの運用
AIX 7.1 TL1もしくはAIX 6.1 TL7以降のCAAではコマンドでの強制クリーンアップ･オプションがサポートされなくなりました。
以下のコマンドのオプションはサポートされません。
chcluster -f
clusterconf -f, -s, -u
rmcluster -f
クラスター・リポジトリー・ディスクの変更や、クラスター・マルチキャスト IP アドレスの変更には、CAAクラスターの削除が必要ですが、2012/03/13現在、rmclusterコマンドによるCAAクラスターの削除は失敗します。
回避策として、クラスター・リポジトリー・ディスクの変更や、クラスター・マルチキャスト IP アドレスの変更には、PowerHAクラスターのスナップショット作成、PowerHAクラスター構成解除、スナップショット適用が必要です。
【参考】
PowerHA V7.1.1と合わせて発表されたPowerHA for AIX Enterprise Edition V6.1 Service Pack 7 (PoweHA EE V6.1 SP7)の機能拡
張
PowerHA EE V6.1 SP7より、サポートするレプリケーションの対象にXIV Remote Mirrorレプリケーション(Metro Mirror, Global Mirror)が加わりました。詳細については、以下を参照ください。
IBM Techdocs Flash: PowerHA EE now supports XIV replication:
なお、PowerHA EEがサポートするレプリケーション機能の一覧については以下を参照ください。
IBM Techdocs Technote: PowerHA Enterprise Edition Support Cross Reference:
PowerHA V7.1.1 SP1でのREADMEファイル等
添付ファイルを参照してください。
Tips
shutdown -r時のリソース・グループ動作
従来は、shutdownに-Fもしくは-rオプションが含まれていた場合、そのノードのPowerHAクラスター・サービスは「リソース・グループの非管理」オプションで停止され、リソース・グループは引き継がれませんでした。
PowerHA 7.1 TL1 SP1より、これは-Fオプションが含まれていた場合という条件に変更されました。
即ち、PowerHA 7.1 TL1 SP1以降の場合、shutdown時に-rが含まれていても-Fが含まれていなければ、リソース・グループは引き継がれる様になります。
詳細については、以下を参照ください。
IV14953: SHUTDOWN -R SHOULD BRING THE RESOURCE GROUPS GRACEFULLY DOWN.（リンク切れ）
https://www-304.ibm.com/support/docview.wss?uid=isg1IV14953
タグVLANサポート
PowerHAはAIX上で作成されるVLANアダプター(smit addvlanより構成)をサポートしていませんでしたが、PowerHA 7.1 TL1およびAIX 7100-01-03もしくは6100-07-03以降よりサポートされるようになりました。
ここでのVLANアダプターとは、AIX上で構成する論理的なデバイスであり、このインタフェースを通してVLANタグの付加されたイーサネット・フレームの送受信がAIXで可能となります。
/usr/es/sbin/cluster/README7.1.1.UPDATE
o VLAN'ed networks (IEEE 802.1Q) are now supported for CAA communications.
With the SP3 version of AIX and CAA, there are no longer any restrictions
when using VLAN (layer 2 routing) networks.
なお、ノード間の通信の過程ではタグ付のフレームが使用される様な構成であっても、AIXがタグ無しのフレームを送受信する構成でさえあれば、従来よりサポートされていました。
例えば、外部のイーサネット・スイッチ上などネットワークの経路上でVLANタグを追加・除去している構成や、VIOCのVE(仮想Ethernet Adapter)がPVID(Port VLAN ID)のみを持つ構成などが該当します。
netmon.cf (RSCT IV14422適用以降)
PowerHA V7.1ではnetmon.cfが廃止され、サービスノードを含むPOWER筐体におけるVIOSの全NIC障害時等によるネットワーク分断時に、PowerHAによる引継ぎを行わせることがネイティブな機能としてはできなくなっていました。
ただし、筐体外のアドレスへのpingを監視するアプリケーション・モニターを構成すれば、容易に実装可能です。
お客様からの問題報告を受け、以下のAPARにより再びnetmon.cfによるネットワーク分断対応がPowerHAのネイティブ機能として再び利用可能になりました。
IV14422: VIOS CABLE PULL DOES NOT LEAD TO EVENTS RUN BY POWERHA（リンク切れ）
http://www-01.ibm.com/support/docview.wss?uid=isg1IV14422
適用する際には、IV14422を含むIV21222: MISC SERVICE UPDATES以降の適用をお薦めします。
IV21222: MISC SERVICE UPDATES（リンク切れ）
http://www-01.ibm.com/support/docview.wss?rs=0&dc=DB550&q1=%2b5765F07AP&uid=isg1IV21222
このAPARを適用し、!REQD書式を用いて/usr/es/sbin/cluster/netmon.cfファイルを作成することで、ネットワークが分断された際にサービス・アドレスを持つリソース・グループを移動させることが可能となります。
!REQD書式の詳細に関しては、テクニカル・フラッシュ System p-08-013 PowerHA (HACMP) 機能拡張:単一サブネットでIPエイリアスによるIPアドレス引継ぎ構成が可能 をご参照ください。
  PowerHA (HACMP) 機能拡張:単一サブネットでIPエイリアスによるIPアドレス引継ぎ構成が可能 (System p-08-013)（リンク切れ）
http://www-01.ibm.com/support/docview.wss?uid=jpn1J1005991
PowerHA 6.1までとの主な相違点は以下の通りです。
  • 対象
    PowerHA 6.1まで シングル・アダプター・ネットワーク構成の場合には強く推奨
    PowerHA 7.1[.1]+IV14422以降 ネットワークが分断された際に引継ぎを必要とする場合にのみ必要 (!REQD書式)
    アダプターがAIXから使用可能かどうかはCAAが監視するため、netmon.cfは、ネットワーク分断ケース以外への対応の為には必要ではありません。
  • 反映タイミング
    PowerHA 6.1まで PowerHAクラスター・サービス起動時のみ
    PowerHA 7.1[.1]+IV14422以降 netmon.cfの編集は数秒毎に確認され、反映される
  • 使用するデーモン
    PowerHA 6.1まで topsvcs(トポロジー・サービス・デーモン)
    PowerHA 7.1[.1]+IV14422以降 cthagsd(グループ・サービス・デーモン)
  • ログファイル
    PowerHA 6.1まで /var/ha/log/nmDiag.nim.topsvcs.enX.CLUSTERNAME[.00X]
    PowerHA 7.1[.1]+IV14422以降 /var/ct/CLUSTERNAME/log/cthags/trace.nmDiag
    trace.nmDiagはバイナリーファイルで有り、内容を確認するには、rpttrコマンドが使用可能です。
    rpttr -o dtic /var/ct/CLUSTERNAME/log/cthags/trace.nmDiag
参考
IV14422: VIOS CABLE PULL DOES NOT LEAD TO EVENTS RUN BY POWERHA（リンク切れ）
http://www-01.ibm.com/support/docview.wss?uid=isg1IV14422
IV20256: DOC: POWERHA MANUALS NEED TO EXPLAIN NETMON.CF FILE（リンク切れ）
http://www-01.ibm.com/support/docview.wss?uid=isg1IV20256

[{"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:
13 February 2023

UID

ibm16852159

Page Feedback