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

Content

1. ユニキャスト通信サポート
   PowerHA V7.1.0～7.1.2においては、障害判別等の為のハートビートにマルチキャスト通信を使用します。
   この為、ネットワークがマルチキャスト・パケットを透過する必要があり、環境によってはネットワークの設定が必要でした。
   PowerHA V7.1.3では、デフォルトでハートビートにユニキャスト通信(TCP)を 使用します。ネットワークがマルチキャストをサポートするように構成されている場合は、マルチキャスト通信も選択可能です。
   プロトコルが変わるだけで、通信される内容、レートなどは変わりません。
   2ノードクラスターであれば、ネットワークに関してマルチキャストの考慮が不要である、デフォルトのユニキャスト通信によるハートビート構成をお勧めします。
   ノード数が多いクラスターなどの場合には、通信の効率を考慮して、マルチキャスト通信によるハートビート構成をお勧めします。
   新規クラスター構築時
   デフォルトでハートビートにユニキャスト通信が設定されます。
   SMITからの設定の場合、リポジトリー・ディスクを選択する画面において設定可能です。デフォルトでユニキャスト通信が選択されています。
   smit sysmirror -> Cluster Nodes and Networks -> Standard Cluster Deployment -> Define Repository Disk and Cluster IP Address -> * Heartbeat Mechanism に対して Unicast|Multicast を指定
   その後検証同期
   もしくは clmgr コマンドによる構成の場合、HEARTBEAT_TYPE により設定が可能です。未指定の場合には unicast となります。
   clmgr add cluster ... HEARTBEAT_TYPE={unicast|multicast} ...
   clmgr sync cluster
   マイグレーション時
   PowerHA 6.1からのマイグレーションの場合には、マイグレーションの過程におけるclmigcheckコマンドにおいてユニキャストの利用を指定することが可能です。
   PowerHA V7.1.0～2からのマイグレーションの場合、マルチキャスト通信構成のままマイグレーションされます。その後、必要に応じて、動的もしくは静的にユニキャスト通信に変更してください。
   ハートビート構成の変更
   ハートビートの方式は動的にも静的にも変更可能です。
   SMITによる設定変更
   # smit sysmirror -> Custom Cluster Configuration -> Cluster Nodes and Networks -> Initial Cluster Setup (Custom) -> Define Repository Disk and Cluster IP Address -> * Heartbeat Mechanism に対して Unicast|Multicast を指定
   その後検証同期
   もしくはclmgrコマンドによる設定変更が可能です。
   clmgr modify cluster HEARTBEAT_TYPE={unicast|multicast}
   clmgr sync cluster
   KA対象からの除外 (Oracle のノード間通信ネットワーク)
   ユニキャスト通信構成においてネットワークをKA対象から除外するには、マルチキャスト通信構成と同様に、PowerHAのネットワーク設定をプライベート属性に設定します。反映には、クラスター・サービスを停止して、検証同期を行なう必要があります。
   プライベート属性のネットワークではIPアドレスの引継ぎはサポートされません。
   この構成は、Oracle におけるノード間通信のネットワークを目的としています。
    
2. クラスター・ノードのホスト名動的変更
   PowerHA V7.1.2以前はクラスター・ノードのホスト名について以下の制限がありました。
   ホスト名を変更する場合は、サービスを停止し、CAAクラスターの再構成を行なう必要がありました。
   サービス・アドレスに関連付けられるラベルはホスト名に使用できませんでした。
   PowerHA V7.1.3から、クラスター・ノードのホスト名をサービスを停止することなく、動的に変更することが可能になりました。ホスト名変更には、AIX再起動後にホスト名変更が戻る一時的ホスト名変更とAIX再起動後もホスト名の変更が保持される永続ホスト名の二種類があります。
   一時的ホスト名変更
   一時的ホスト名変更では、AIXカーネル内のホスト名を変更し、AIX ODM内のホスト名は変更しません。
   ホスト名を変更するにはhostnameコマンドを使用します。
   PowerHA SystemMirror および Cluster Aware AIX (CAA) は、ホスト名情報を内部ディスクに保管します。この方式を使用する場合、ホスト名は永続的ではなく、AIXを再始動すると元のホスト名に戻ります。
   以下の設定を行なうと、hostnameコマンドにより、ホスト名変更の動的なCAAへの反映、およびPowerHA定義(ノードへの通信パス)の修正が行なわれる様になります。PowerHA定義の修正は、変更を行なったノードから同期により反映される必要があります。デフォルトは disallow であり、この場合、CAAへの反映やPowerHA定義への反映は行なわれません。
   clmgr modify cluster TEMP_HOSTNAME=allow
   clmgr sync cluster
   一時的ホスト名変更におけるTEMP_HOSTNAME={disallow|allow}の補足
   デフォルト(TEMP_HOSTNAME=disallow)設定状態においてhostnameコマンドによりhostnameを変更した場合、
   PowerHAの設定内容は変更されず、PowerHA定義情報の同期なども必要となりません。
   なお、CAAにはhostnameの変更は反映されず、ユーザーによるclcmdコマンドを用いたリモート・ノードでのコマンド実行には問題が生じることになります。この場合、cl_nodecmd 等のPowerHAが提供するコマンドによる代替をご検討ください。
   TEMP_HOSTNAME=allow設定状態においてhostnameコマンドによりhostnameを変更した場合、
   PowerHAの設定内容(通信パス)が変更されPowerHA定義情報の同期が必要となります。
   CAAにhostnameの変更が反映され、clcmdコマンドによるコマンド実行が可能となります。clcmd -m nodename にてノードを明示指定してコマンドを実行するには、変更されたhostnameを指定する必要があります。
   永続ホスト名変更
   永続ホスト名方式は、AIXカーネルおよび AIX ODM 内でホスト名を変更します。AIX ホスト名は永続的で、システムを再始動しても変更されません。
   ホスト名変更はsmit hostname を使用します。
   ホスト名変更後に、変更を行なったノードからPowerHAの同期を実施する必要があります。
   クラスタ内の複数のホスト名を変更する場合は、1ノードのホスト名変更ならびにPowerHAの同期が完了した後に別のノードのホスト名変更を行って下さい。
   考慮点
   hostnameコマンドにて指定するラベルは、そのノード上に構成されているアドレスに解決できる必要があります。そのノード上に無いアドレスに解決されるラベルを指定しないで下さい。例えば、ホスト名にサービス・アドレスに関連付けられた名前を使用する場合、サービス・アドレス解放時にはホスト名を元に戻す必要があります。
   サービス・アドレスに関連付けられた名前をホスト名とする場合、一時的ホスト名変更方式としてください。
   CAAが提供するclcmd コマンドにおいてノードを指定する場合、(変更された)hostnameを指定する必要があります。
   ただし、一時的ホスト名変更状態、かつTEMP_HOSTNAME=disallowの場合には、clcmdが使用できない状況が確認されていますのでご注意ください。
   cl_nodecmd 等のPowerHAが提供するコマンドにおいてノードを指定する場合、PowerHA定義上のノード名を指定する必要があります。
   Enterprise Edition
   PowerHA SystemMirror Enterprise Edition V7は、PowerHA V7.1 TL2(PowerHA V7.1.2)より提供されています。
   Enterprise Edition は、Standard Edition の全機能に加えて、サイト間のデータ・レプリケーションの制御機能を提供します。
   PowerHA V7.1.3では、PowerHA V7.1.2で提供されていたHyperSwap機能が拡張されました。

1. PowerHA HyperSwapの機能拡張
   PowerHA は、Enterprise Edition 7.1 TL2より、PowerHA HyperSwap機能を提供しています。
   PowerHA HyperSwap機能は、DS8800間でPPRCにより同期が取られたLUNを単一のディスクとして認識させ、DS8800障害時に自動的にアクセス先を切替えてアクセスを継続させるソリューションです。
   参照
   『PowerHA SystemMirror for AIX V7.1.2 新機能/機能拡張の技術的ハイライト(System p-13-002)』
   https://www.ibm.com/support/pages/node/6852135
   
   PowerHA HyperSwap
   Enterprise Edition 7.1 TL3では、HyperSwap に関して以下の様な機能拡張が行なわれています。
   
   アクティブ/アクティブの HyperSwap 構成
   HyperSwap 機能を使用する共有ディスクを各サイトにおいて同時に使用する構成がサポートされます。
   このクラスター構成において、アプリケーションは、2 つのクラスター間で共有データへのアクセスのバランスを取ることができます。その一方で、メトロ・ミラー機能および HyperSwap 機能を通じて、アプリケーションのデータ整合性がサイト間で維持されます。
   ストレージ障害やサイト障害が発生した場合は、アプリケーションは、別のサイトを使用してデータにアクセスするための接続を確立することができます。
   この構成は遠距離サイト間でのアクティブ/アクティブ Oracle RAC 構成を想定しています。
   シングル・サーバー HyperSwap
   最小限のハードウェアを使用して、単一ノード構成で HyperSwap 機能を使用することができます。ただし、1 次ストレージ・システムと補助ストレージ・システムが必要です。
   PowerHAはHyperSwapの基盤としてのみ使用され、サイトは構成しません。

1. マイグレーション
   
   PowerHA V7.1.3にマイグレーションする場合の、アップグレードパスは下記表のとおりです。

   	6.1	7.1.1	7.1.2	7.1.3
   5.5	R/S/O/N	R/S/O	R/S/O	NA
   6.1	NA	R/S/O	R/S/O	R/S/O
   7.1.0	NA	S/O	S/O	S/O
   7.1.1	NA	NA	R/S/O	R/S/O
   7.1.2	NA	NA	NA	R/S/O

   
   R=Rolling Upgrade(ローリング・アップグレード/漸次移行）
   S=Snapshot Upgrade（スナップショットを使用したアップグレード）
   O=Offline Upgrade（オフライン・アップグレード）
   N=Non-disruptive Upgrade（無停止でのアップグレード）
    
2. clmgr コマンド
   
   clmgrの機能が拡張され、より使いやすく環境構築や定義情報収集に役立つ機能が拡張されました。
   clmgrによる”オンライン・プランニング・ワークシート”機能と類似したHTML形式のクラスター・レポート機能が提供されました。Systems Directorなどの追加ファイルセットは不要で、ベースのPowerHA機能で実現可能です。クラスター・レポート作成は、cronなどを利用して自動実行することが可能です。
   clmgr view report cluster TYPE=html [ FILE=<PATH_TO_NEW_FILE> ] ...
   同じようなクラスター構成を複数作成する場合に利用できる”クラスター・コピー”機能を提供します。スナップショットを新しいハードウェアにコピーし、そこでノード名やリポジトリー・ディスクを指定することでクラスター定義が構成できます。この機能により、初期構築の時間が短縮され迅速に類似のクラスター環境を提供することができます。ただし、この機能はクローンを作成するのではないため、事前にアプリケーションやメソッド・スクリプト、ボリューム・グループなどを構成しておく必要があり、コピー機能実行後には手動でいくつかの定義修正が必要な場合があります。
   PowerHA V7.1.2以前のヘルプは構文化されていませんでしたが、V7.1.3では引数がわかるように構文化されており、その引数が必須もしくはオプショナルかといったことも明示されたヘルプになりました。
   【サンプル出力：clmgr -h add methodコマンドの実行結果】
   PowerHA V7.1.2の場合
   # clmgr -h add method
   clmgr {[-c|-d <DELIMITER>][-S] | [-x]} [-v] [-f] [-D] \
   [-T <#####>] [-l {error|standard|low|med|high|max}] \
   [-a {<ATTR>,<ATTR#2>,...}] <ACTION> <CLASS> [<NAME>] \
   [-h | <ATTR>=<VALUE> <ATTR#2>=<VALUE#2> ...]
   clmgr {[-c|-d <DELIMITER>][-S] | [-x]} [-v] [-f] [-D] \
   [-T <#####>] [-l {error|standard|low|med|high|max}] \
   [-a {<ATTR>,<ATTR#2>,...}] -M "
   <ACTION> <CLASS> [<NAME>] [<ATTR>=<VALUE> <ATTR#2>=<VALUE#2> ...]
   .
   .
   ."
   ACTION={add|modify|delete|query|online|offline|...}
   CLASS={cluster|site|node|network|resource_group|...}
   clmgr {-h|-?} [-v]
   clmgr [-v] help
   
   PowerHA V7.1.3の場合
   # clmgr -h add method
   clmgr add method <method_label> \
   TYPE=snapshot \
   FILE=<executable_file> \
   [ DESCRIPTION=<description> ]
   clmgr add method <method_label> \
   TYPE=verify \
   FILE=<executable_file> \
   [ SOURCE={script|library} ] \
   [ DESCRIPTION=<description> ]
   clmgr add method <method_label> \
   TYPE=notify \
   DESCRIPTION=<description> \
   FILE=<executable_file> \
   CONTACT=<number_to_dial_or_email_address> \
   EVENTS=<event>[,<event#2>,<event#n>,...] \
   [ NODES=<node>[,<node#2>,<node#n>,...] ] \
   [ RETRY=<retry_count> ] \
   [ TIMEOUT=<timeout> ]
   add => create, make, mk
   method => me
   
   clmgrコマンドのリターン・コードは下記の通り整理され、問題判別がより迅速にできるようになりました。
   
   clmgrコマンドのリターン・コード一覧
   RC_SUCCESS=0
   No errors were detected; the operation appears to have been successful.
   RC_ERROR=1
   A general error has occurred.
   RC_NOT_FOUND=2
   A specified resource does not exist, or could not be found.
   RC_MISSING_INPUT=3
   Some required input was missing
   RC_INCORRECT_INPUT=4
   Some detected input was incorrect in some way
   RC_MISSING_DEPENDENCY=5
   A required dependency does not exist
   RC_SEARCH_FAILED=6
   A specified search failed to match any data
   RC_EXTRANEOUS=7
   A given operation was not really necessary
   RESULT_UNKNOWN=-1
   Intended for internal processing use only.
    
3. IBM Systems Director プラグインの機能拡張（グラフィカル・クラスター・シミュレーター）
   
   PowerHA V7.1.3には、IBM Systems Directorプラグインが無償で組み込まれています。このプラグインを使用して、PowerHAクラスターを構成・管理することが可能ですが、下記のような機能拡張が行われました。
   取得したクラスター・スナップショットを取得したクラスターだけでなく他のクラスター構成のノードにリストアを実施できるようになりました。
   クラスターのsplit/merge操作も可能となりました。
   XMLを使用したオフライン・シミュレーションやプランニングを行うシミュレーション機能が提供され、PowerHA環境のデモが容易に行えるようになり、GUI画面でのプランニングが可能となりました。
   プランニングで作成したXMLファイルを使用してPowerHAクラスター定義をデプロイすることも可能です。
   SAPに対する、柔軟な高可用性管理機能が拡張されました。
   ”オンライン・プランニング・ワークシート”機能をより向上させた、HTML形式でのクラスター構成レポート機能が提供されました。
    
4. ノード名の制約緩和
   
   hostname は、RFC 952 DOD INTERNET HOST TABLE SPECIFICATION により、英数字、マイナス記号"-"、ピリオド"."(FQDN書式用)から構成されることが望まれます。
   一方、PowerHA V7.1.2までのバージョンでは、PowerHAノード名には英数字と下線のみ使用可能 という制約がありました。
   その為、hostname がマイナス記号"-"を含む構成では、PowerHAのノード名をhostname(もしくはそのショートネーム)とは異なった名前で構成する必要があり、構成をシンプルにすることへの障害となっていました。
   PowerHA V7.1.3 より、PowerHAノード名に関して、制約が緩和されました。
   PowerHAノード名にマイナス記号"-"が使用可能になりました。(ノード名の先頭以外)
   これにより、RFC 952 に従ったhostname(もしくはそのショートネーム)はすべてPowerHAのノード名として使用可能になりました。
   PowerHAノード名の先頭に数字を指定することが可能になりました。
   その他の制約については、従来通りとなります。

1. CAA (Cluster Aware AIX)
   
   AIX 7.1 TL1もしくはAIX 6.1 TL7以降のCAAではSolid DBを使用しなくなりました。
   solid, solidhacサブシステムはCAAでは使用されません。
   cldサブシステムは存在しなくなりました。
    
2. リポジトリー・ディスクのデバイス名
   
   AIX 7.1 TL1もしくはAIX 6.1 TL7以降のCAAではクラスター・リポジトリー・ディスクのデバイス名を変更しなくなりました。
   Solid DBが使用していたクラスター・リポジトリー・ディスク上のファイルシステム/clrepos_private1, /clrepos_private2などは構成されません。
    
3. CLUSTER_OVERRIDE 環境変数
   
   AIX 7.1 TL2 SP1 以降のバージョンでは環境変数 CLUSTER_OVERRIDE はサポートされなくなりました。
   CLUSTER_OVERRIDE は、PowerHA クラスター構成に影響を及ぼす可能性のある AIX コマンドの C-SPOC 外からの実行を制御するために提供された環境変数ですが、サポートがなくなったことにより、こうした制御を行うことができなくなりました。
    
4. netmon.cf
   
   PowerHA V7.1ではnetmon.cfが廃止され、サービスノードを含むPOWER筐体におけるVIOSの全NIC障害時等によるネットワーク分断時に、PowerHAによる引継ぎを行わせることがネイティブな機能としてはできなくなっていました。
   ただし、筐体外のアドレスへのpingを監視するアプリケーション・モニターを構成すれば、容易に実装可能です。
   お客様からの問題報告を受け、以下のAPARにより再びnetmon.cfによるネットワーク分断対応がPowerHAのネイティブ機能として再び利用可能になりました。
   適用する際には、IV14422を含むIV21222: MISC SERVICE UPDATES以降の適用をお薦めします。
   これらの APAR はAIX 7.1 TL2, AIX 6.1 TL8 以降に含まれます。
    
5. DMS (Deadman Switch)
   
   PowerHA 6.1 までは、システムが非常に高負荷な状況に陥るなどの状況によりノードの生存を外部に知らせる事が出来なくなった場合、ノードを強制停止するデッドマン・スイッチ（DMS）機能が提供されていました。
   AIX 7.1 TL0, AIX 6.1 TL6 の CAA では、負荷状況に従って障害検出を自動的にチューニングすることにより、高負荷状況に陥ったとしても、誤ったノード引き継ぎは抑止される様になりました。
   AIX 7.1 TL1, AIX 6.1 TL7 の CAA は、加えて、DMS機能を再び提供するようになりました。
   マルチ・ノード環境において、CAA はノードの孤立を検出します。
   システムが非常に高負荷な状況に陥るなどの状況により、LAN経由、SANベースの通信経路経由、repositoryディスク経由で、ノードの生存を外部に知らせる事が出来ない状態となった場合、DMS機能によりノードは強制停止(デフォルト動作)されます。
   発生までの時間はチューニングできません。
    
6. ハートビート・レート/引き継ぎ時間の調整
   
   PowerHA V6.1以前の”Failure Detection Rate(FDR)”に相当するものは無くなり、ユーザーによる調整は出来ません。
   PowerHA V7.1 TL1は、ノード障害検出までの時間、および検出してから引き継ぎを開始するまでの時間をチューニングするためのパラメーターを設定できるようになりました。
   ネットワーク毎に異なる値を設定することは出来ません。
   Failure Cycle もしくは Node Failure Detection Timeout (CAAではnode_timeoutに相当), Grace Period もしくはFailure Indication Grace Time (CAAではnode_down_delayに相当)を設定することが可能です。
    
7. マルチキャスト・アドレス
   
   PowerHA V6.1 まではハートビートにユニキャスト・アドレスが使用されていましたが、PowerHA V7.1 からマルチキャスト・アドレスが使用されるようになりました。
   PowerHA V7.1.2 から V7.1 ベースのものとして初めて Enterprise Edition (EE） がサポートされ、リンク・クラスターにおけるサイト間のハートビートにユニキャスト・アドレスが使用されるようになりました(拡張クラスターではマルチキャスト)。
   PowerHA V7.1.3 から、Standard Edition でもユニキャスト・アドレスがサポートされるようになりました。デフォルトでは新規クラスター作成時にユニキャストが使用されるように構成されます(マルチキャストはオプション)。詳細は当フラッシュの ユニキャスト通信サポート のセクションをご参照ください。
    
8. PowerHA 環境でのソース・アドレス
   
   クラスター・ノードから、ローカル・ネットワーク上、またはリモート・ネットワーク上の機器への接続のソース・アドレス選択ロジックが、V7.1 以降で変更になっています。
   一般的な、単一サブネット上のシングル･アダプター･ネットワーク構成において、サービス・アドレスの配布設定に関して設定を変更していない場合、従来はローカル・ネットワーク、リモート・ネットワークの何れに対してもソース・アドレスとしてブート・アドレスが選択されていました。
   PowerHA 7.1.1以降、ローカル・ネットワークに対して、サービス・アドレスが使用される様になりました。
   加えて、AIX V6.1 TL9, V7.1 TL2+IV48789, V7.1 TL3 以降の場合、リモート・ネットワークに対してもサービス・アドレスが使用される様になります。
   アプリケーションがソース・アドレスに依存する設計になっていたり、PowerHA クラスター・ノードと Firewall を介した通信が行われたりする場合、PowerHA V7.1 以降では V6.1 以前とはソース・アドレスが異なる可能性がある為、ソース・アドレスを意識したアプリケーションの引継ぎを行う場合には、PowerHAの設定を見直す、もしくはアプリケーション･コントロール・スクリプトを修正する必要があります。
    
9. ホスト名の動的変更
   
   PowerHA V7.1 以降 V7.1.2 までのバージョンでは、クラスター・サービス稼働中のホスト名の変更はサポートされません。アプリケーション・コントローラー(従来のアプリケーション始動/停止スクリプト)において、ホスト名を変更する処理(いわゆる「ホスト名の引継ぎ」)がサポートされないことにご注意ください。
   ホスト名を変更するには、クラスター･サービスの停止、CAAクラスターの削除、ホスト名の変更、CAAクラスターの再構成による反映が必要です。(PowerHAクラスター定義の削除/再構成は不要です。)
   PowerHA V7.1.3 からはホスト名の動的変更が可能になりました。詳細は当フラッシュの クラスター・ノードのホスト名動的変更 のセクションをご参照ください。
    
10. 共用ディスクに対するリザーブポリシー設定
    
    PowerHAは拡張コンカレントVGを使用してディスク装置の引継ぎを高速化する、高速ディスク引継ぎ構成をサポートしています。
    PowerHA V6.1までは、MPIO接続やVIOSを経由するディスク装置を共有ディスクとして使用する場合、VGを拡張コンカレント・モードにすることが必須でした(それ以外の構成では、高速ディスク引継ぎは任意)。
    PowerHA V7.1以降は、共有ディスクを拡張コンカレント・モードにすることが必須となっています(全ての構成で高速ディスク引継ぎが行われます)。
    高速ディスク引継ぎ構成では、PowerHAはディスク・デバイスの設定に関わらずディスク装置に対するリザーブを行なわない為、リザーブ・ポリシーの設定変更は必須ではありません。*1
    しかし、運用の誤りなどにより意図しないリザーブの競合が発生すると、サービスに影響が及ぶ可能性があります。この様な状況を抑止するという観点からは、ディスク・デバイスのリザーブ・ポリシーをno_reserveとして構成されることをお勧めします。
    *1 但し、SDDPCMを使用したMPIO接続の場合にはno_reserveの設定が必要です。
     
11.  リソース・グループを制御するイベントの流れの変更
    
    PowerHA 7.1から、リソース・グループを制御するイベントの流れが変更になり、基本的にはrg_move系のイベントが使用されます。(依存関係を持つ従来のクラスター構成と同様。)
    例えば従来のnode_down -> node_down_completeは、node_down -> [rg_move_release ->][ rg_move_acquire -> rg_move_complete ->] node_down_completeとなり、実際の資源の制御はrg_move系が行います。
    その為、イベント・カスタマイズにより、イベントの前処理、後処理などにユーザー処理を追加していた場合には、対応が必要となる可能性が有ります。
    1.  複数のノードのクラスター・サービスを同時に起動、もしくは同時に停止する場合のイベントの流れ
       複数のノードのクラスター・サービスを同時に起動、もしくは同時に停止する場合、タイミングによっては以下の例の様に複数のノードの処理がまとまって行なわれる可能性が有ります。
       イベントカスタマイズなどを行なっている場合には、この状況にも対応できように考慮する、もしくは、同時起動、同時停止を避け、(すなわち、クラスター・サービスの制御をノード毎に行なう、clmgrコマンドを使用したクラスター・サービスを制御する場合にcluster全体を指定しない対応により、)この様なイベントの流れとならないようにしてください。
       node1におけるcluster.mmddyyyyログ
       # 各ノードに対するnode_downイベント。リソースの取得/解放操作は含まれない。
       Apr 13 10:42:24 EVENT START: node_down node2 graceful
       Apr 13 10:42:24 EVENT COMPLETED: node_down node2 graceful 0
       Apr 13 10:42:27 EVENT START: node_down node1 graceful
       Apr 13 10:42:27 EVENT COMPLETED: node_down node1 graceful 0
       # 実際のリソース解放処理
       Apr 13 10:42:30 EVENT START: rg_move_release node1 1
       Apr 13 10:42:30 EVENT START: rg_move node1 1 RELEASE
       Apr 13 10:42:31 EVENT COMPLETED: rg_move node1 1 RELEASE 0
       Apr 13 10:42:31 EVENT COMPLETED: rg_move_release node1 1 0
       Apr 13 10:42:33 EVENT START: rg_move_fence node1 1
       Apr 13 10:42:34 EVENT COMPLETED: rg_move_fence node1 1 0
       # 各ノードに対するnode_down_complete イベント。リソースの取得/解放操作は含まれない。*
       Apr 13 10:42:36 EVENT START: node_down_complete node1 **
       Apr 13 10:42:36 EVENT COMPLETED: node_down_complete node1 0
       * 複数ノードにおけるクラスター・サービス同時停止の場合、ローカル・ノードに対するnode_down_complete 終了時点でローカル・ノードのクラスター・サービスが停止して以降のイベントはログされない為、ローカル・ノード上にて、リモート・ノードに対するnode_downイベントは発生するが、node_down_completeイベントは発生しない可能性が有ります。
       ** node_down イベントにおいてgracefulオプションが付与されていても、node_down_complete イベントにおいては、gracefulオプションは使用されなくなりました。
       なお、オプション無し状態、およびforcedオプション状態は、node_down および node_down_complete の両イベントに作用します。
    2.  イベントの流れが変更された事に伴うclRGinfo -aによるリソース・グループ移動情報への影響
       イベントの流れの変更に伴い、クラスター・マネージャーが資源の解放を行なうフェーズと取得を行なうフェーズが内部的に分離され、資源取得時点のclRGinfo -aにおいて資源解放ノードの情報が入手できなくなり、かつ資源解放時点のclRGinfo -aにおいて資源取得ノードの情報が入手できなくなりました。
       例えば、PowerHA 6.1まででは、アプリケーション起動スクリプト実行時などで、clRGinfo -aコマンドにより、正常起動なのか､引継ぎに伴う起動なのかを判断することが可能でした。
       clRGinfo -a出力において対象となるリソース・グループを解放するノードが存在する場合には引継ぎ起動。
       ただし、RG間の依存関係が構成されていないことが前提。
       しかし、PowerHA 7.1では､clRGinfo -aにて判断することが出来なくなっています。
       これは、資源取得時点のclRGinfo -aにおいて資源解放ノードの情報が入手できなくなった為です。
       その為、clRGinfo -aを使用するスクリプトはテスト、改修が必要となる可能性が有ります。