ネイティブHA CRR

Native HA Cross-Region Replication（CRR）構成では、キューマネージャの実行を別の場所にある別のNative HA構成に切り替えることができます。

ディザスタリカバリ・ソリューションを提供するために、ネイティブHA CRR構成を使用することができます。本番サイトで何らかの災害が発生した場合、フェイルオーバーを実行し、復旧サイトでキュー・マネージャの実行を継続することができます。この状況では、フェイルオーバーが発生したときにリカバリログが同期されていることを保証できないため、データの損失が発生する可能性があります。同様に、障害が発生したサイトがリストアされた場合、キュー・マネージャの2つのライブ・インスタンスが存在するため、パーティショニングされた（分割された）データが発生する可能性があります。

ネイティブ HA CRR 構成を使用することで、保守やテストを行っている間でも継続性を提供することができます。このような状況では、データの損失が発生しないように切り替えが制御される。同じように、復帰する際も、パーティション分けされたデータを解決する必要はない。

Linux でネイティブ HA CRR ソリューションを構成するには、同じアーキテクチャーを使用する 2 番目の 3 ノードセットが復旧グループとして機能する必要がある。これらのノードのリソースは、役割を変更する必要がある場合に、ライブまたはリカバリーのどちらの役割でも実行できるように、十分かつ均一に割り当てられなければならない。

TLS 2つのネイティブHAグループ間でログデータを複製する際には、暗号化が必須です。オプションですが、推奨される設定として、各グループのメンバー間でデータを複製するために TLS も設定してください。

ネイティブHA CRRの構成例を示す

求められる役割と効果的な役割

リクエストされた役割とは、 qm.ini の NativeHALocalInstance スタンザで指定された、ネイティブHAインスタンスの GroupRole 構成設定のことである。インスタンスがグループ内の他のインスタンスと協力して役割を果たすことを要求する設定。大多数のインスタンスが同じRequestedロールを共有すると、グループのリーダーを選ぶために選挙を行うことができる。当選すると、リクエストされたロールは、インスタンスが有効ロールを導き出すために使用した最後のロールと比較される。 qm.ini ファイルの NativeHAInstance スタンザおよび qm.ini ファイルの NativeHALocalInstance スタンザを参照のこと。

ライブ・ロール

Liveグループは、3つのインスタンスで構成される通常のNative HAキューマネージャである。 1つのインスタンスがアクティブなインスタンスとして選出され、このインスタンスがアプリケーションから新しい仕事を受け入れる。既存のNative HAキューマネージャをNative HA CRR構成に移行することができる。

Requested役割が qm.ini で明示的に指定されていない場合、デフォルトはLiveとみなされる。このインスタンスは、新しいメッセージング作業を実行し、キュー・マネージャ・オブジェクトを管理するために、アプリケーションとツーリング接続を受け入れることができます。

回復の役割

リカバリーグループも3つのインスタンスで構成され、そのうちの1つがリーダーに選出される。リーダーはプロキシとしてのみ機能し、ペアになっているLiveグループから送られてくる仕事を引き受ける。キューマネージャインスタンスの終了などの操作を完了できるように、いくつかの制御コマンドは許可されていますが、回復グループへのアプリケーション接続は許可されていません。

Liveグループの qm.ini 構成ファイルの NativeHARecoveryGroup スタンザは、Recoveryグループのネットワークアドレスを特定する。

保留中の役割移行

現在のライブグループが新しいリカバリーグループになる（そして現在のリカバリーグループが新しいライブグループになる）計画的な切り替えを行う場合、グループ間の調整が必要である。この調整により、ログの同一性が保証され、RPO（復旧時点目標）ゼロが達成される。

2つのグループがリカバリーとライブの切り替えを調整している場合、効果的なペンディングの役割が一時的に両方のグループによって採用される。

リカバリ・ロールからライブ・ロールへ（ライブ待ち）

ライブ・ロールに変更する予定のリカバリ・ロールで以前運用されていたグループは、他のグループが構成されているかどうかに基づいて、いつロールを使用するかを決定する。

他に設定されたグループがない場合は、直ちにライブ・ロールに移行する。

別のグループが構成され有効になっている場合、もう一方のグループがリカバリまたは保留中のリカバリの役割を採用するまで、そして両方のグループが同期するまで、ライブの役割への移行はブロックされる。

ライブ・ロールからリカバリ・ロールへ（リカバリ待ち）

以前はLiveロールで運用されていたグループが、Recoveryロールに変更しようとする場合、Recoveryロールをいつ使用するかは、別のグループが構成されているかどうかに基づいて決定される。

別のグループが構成され有効になっている場合、もう一方のグループがライブまたはライブ待ちの役割を採用するまで、そして両方のグループが同期するまで、リカバリの役割への移行はブロックされる。

レプリケーションとリベース

ネイティブHA CRR構成の2つのグループが接続されている間、ログの更新は復旧グループのリーダーに渡され、他の復旧インスタンスに渡されます。これを複製といいます。

2つのグループ間のネットワーク接続が失われた場合、復旧グループがレプリケートされたログを使用してもキャッチアップできない可能性がある（たとえば、ライブグループがキャッチアップに必要なログエクステントを再利用しているため）。この場合、リカバリーリーダーはリベースを実行する。リベースとは、受信したログデータを破棄し、ライブグループから送信されたログデータ一式からキューマネージャを再構築するプロセスである。リカバリーリーダーがリベースを完了すると、ログはリカバリーインスタンスにレプリケートされる。

リベース操作中に問題が発生した場合、キュー・マネージャがリカバリ・グループのメンバー上で起動できなくなる可能性があります。この可能性を避けるため、リベース操作の開始前にログのバックアップが取られる。リベースに失敗した場合は、バックアップログデータを使用してキューマネージャを再起動することができます。バックアップ・ログは、リベースが成功すると削除される。

バックアップログが必要なため、ネイティブHA CRR構成は、ネイティブHA構成の少なくとも2倍のストレージ容量を必要とする。

インスタンスとグループの命名

ネイティブHA CRRを構成する場合、3つのインスタンスの各セットにはグループ名も必要である。グループ名は（ dspmq の出力やメッセージで）識別のために使用されるため、例えば「london」や「rome」のように、地理的な名前を使用してグループを識別したい場合がある。

例えば「live」と「recovery」、「primary」と「backup」など、グループの役割を暗示するようなグループ名の使用は避けてください。このような名前は、グループ間で「通常の」役割が入れ替わった場合、 dspmq の出力やメッセージで混乱を招く可能性があります。

グループの命名規則は、インスタンスの命名規則と同じです。