同じノードおよび異なるノードの依存関係を使用する出版社のモデル

実働用のデータベース (PDB) と実働用のアプリケーション (Papp) はメンテナンスを簡素化するために同一ノード上でホストされています (また、これらのリソース・グループで最も優先順位の高いノードには最も多くのメモリーを搭載しているか、最も高速なプロセッサーが使用されています)。 アプリケーションはデータベースに依存するため、これらのノード間で親/子の関係を設定するのも、有効な手段と言えます。 アプリケーションが動作するためには、データベースはオンライン状態である必要があります。システム・データベース (SDB) とシステム・アプリケーション (Sapp) と QA データベース (QADB) と QA アプリケーション (QAapp) でも同一の条件が成り立ちます。

実働データベースと実働アプリケーションの稼働状態を維持するのが最優先であることから、クラスターを構成することは有効な手段と言えます。つまり、3 つのデータベース・リソース・グループを異なるノードに配置し (異なるノードでオンラインの依存関係セットになる)、PDB リソース・グループの優先順位を 高くします。 SDB の優先順位は 中に、QADB の優先順位は 低になります。

データベースと関連アプリケーションはそれぞれ、同じノードでオンラインになる依存関係セットに属するよう、構成されます。

PowerHA® SystemMirror® は、始動ポリシー、フォールオーバー・ポリシー、およびフォールバック・ポリシーの構成方法に応じて、これらのグループをいくぶん異なる方法で処理します。 参加ノード・リストをデータベースとアプリケーションのセットごとに別に持つことは、優先ノード上にこれらのリソース・グループを固定するという目的では有効であると言えます。

リソース・グループ・ポリシー: Online on first available node (最初に使用可能なノードでオンライン)

以下の使用事例では、6 種類のリソース・グループすべてに以下のポリシーが適用されます。

• 始動ポリシー: Online On First Available Node (最初の使用可能ノードでオンライン)
• フォールオーバー・ポリシー: Fallover to Next Priority Node (次に優先順位が高いノードにフォールオーバー)
• フォールバック・ポリシー: Never Fallback (フォールバックしない)

使用事例 1: 番号順にノードを開始する (ノード 1 が 1 番目)

番号順にノードを開始する方法では、ノード 1 にある実働リソース・グループが最初にオンラインになり、ノード 2 のシステム・リソース・グループが次にオンラインになり、さらにノード 3 にある QA リソース・グループが 3 番目にオンラインになると想定されます。 競合はありません。

リソース・グループである PDB と PApp に対して、ノード 1 が優先順位の最も高いノードになります。 親/子依存関係では、PDB が PApp より先にオンラインになるようにします。 したがって、 PowerHA SystemMirror は rg_move イベントを処理して最初に PDB を獲得し、次に PApp を獲得します。

ノード 1 はその他のグループのノード・リストには 含まれません。 そうであったとしても、「異なるノードでオンライン」依存関係により、優先順位の低いグループがこのノードでオンラインになることは許可されません。

「ノードの開始: 順序 1、2、3」の統合表示

使用事例 2: 順番に関係なくノードを開始 (ノード 3)

ノード 3 は PDB と PApp、および SDB と SApp の両方で、優先順位が最も低くなります。 ノード 3 は QADB と QAApp で最優先になります。 ただし、PDB/PApp のペアは、異なるノードでオンラインの依存関係になるため、最優先になります。 そのため、 PowerHA SystemMirror はノード 3 で PDB を獲得して開始し、その子 PApp を処理します。 規則に基づいて、その他のリソース・グループはエラー状態になります。これらのリソース・グループは、ノード 3 でオンラインになる可能性がありましたが、異なるノードでオンラインの依存関係ポリシーが原因で、獲得 されませんでした。

使用事例 2 (続き): 順番に関係なくノードを開始 (ノード 2)

ノード 2 は SDB および SApp のリソース・グループで優先順位が最も高くなります。 しかし、異なるノードでオンラインの依存関係セットで最も優先順位が高くなるのは、PDB です。 そのため、PDB はこの結合ノードにフォールオーバーし、SDB と SApp はノード 3 で獲得されて開始されます。 これらの 2 つのリソース・グループは「Online on Same Node (同じノードでオンライン)」依存関係セットに属しているため、 PowerHA SystemMirror は PDB を使用して Papp を同じノードに移動します。 QA PDB は SDB より優先順位が低いため、QAapp とともに ERROR 状態のままになります。

ノード 1 が起動すると、PDB と Papp はノード 1 に、SDB と Sapp はノード 2 にそれぞれフォールオーバーし、ノード 3 上では QA リソース・グループが獲得され、始動します。

「順番に関係なくノードを開始: 順序 3、2、1」の統合表示

使用事例 3: ノード障害によるリソース・グループのフォールオーバー

ノード 1 で障害が発生すると、 PowerHA SystemMirror は SApp と SDB、および QADB と QAapp を解放し、最高優先順位のリソース・グループ PDB とその同じノード依存関係パートナーおよび子 PApp をノード 2 に移動し、同様にシステム・グループをノード 3 に移動します。 QA グループには移動先がありません。グループは ERROR 状態になります。

使用事例 4: リソース・グループのフォールオーバー: フォールオーバー中のネットワーク障害

ステップ 5 では、クラスター・マネージャーが現在ダウンしているノード 2 の PApp には、ネットワークが必要であることを認識しているため、PApp は獲得フェーズを実行する代わりに、直接エラー状態になります。 これは獲得の失敗とは対照的です。

ステップ 6 では、イベント・キューはキューに入っている resource_state_change イベントを取得します。このイベントはボートされ、新たな ACQUIRE/RELEASE イベントが待ち行列に挿入されます。

ステップ 7 および 8 では、ネットワーク障害のため、SApp はエラー状態になります。