7.2.2. マルチマスターレプリケーション

マルチマスターのレプリケーション 環境では、同じ情報のマスターコピーが複数のサーバーに存在することがあります。つまり、異なる場所で同時にデータを更新できることを意味します。各サーバーで発生した変更は、他のサーバーに複製されます。つまり、各サーバーはサプライヤーとコンシューマーの両方として機能します。

同じデータが複数のサーバーで変更された場合、どの変更が保持されるかを決定するための競合解決手順があります。Directory Server は、有効な変更を最新の変更とみなします。

複数のサーバーが同じデータのコピーを保持することはできますが、1 つのレプリケーションアグリーメントの範囲内に存在するのは、1 つのマスターサーバーと 1 つのコンシューマーのみです。したがって、同じデータに対して責任を共有する 2 つのサプライヤーサーバー間にマルチマスター環境を作成するには、複数のレプリケーションアグリーメントを作成します。

図7.2「簡素化されたマルチマスターレプリケーション設定」 では、業者 A および supplier B はそれぞれ、同じデータの読み書きレプリカを保持します。

図7.3「簡素なマルチマスター環境でのレプリケーショントラフィック」 は、2 つのサプライヤー（図で読み書きレプリカ）と 2 つのコンシューマー（図で読み取り専用レプリカ）を使用したレプリケーショントラフィックを示しています。コンシューマーは、両方のサプライヤーによって更新できます。サプライヤーサーバーは、変更が競合しないようにします。

Directory Server でのレプリケーションは、最大 20 のマスターをサポートできます。これらのサプライヤーはすべて、同じデータに対する責任を共有します。このような多くのサプライヤーを使用するには、さまざまなレプリケーションアグリーメントを作成する必要があります。（マルチマスターレプリケーションでは、各サプライヤーは異なるトポロジーで設定できます）。つまり、ディレクトリーツリーとスキーマの相違点は 20 つあります。トポロジーの選択に直接的な影響を与える変数が多数あります。

マルチマスターのレプリケーションでは、サプライヤーは他のすべてのサプライヤーに更新を送信することや、他のサプライヤーのサブセットに更新を送信することができます。他のすべてのサプライヤーへの更新を送信すると、変更がより迅速に伝播され、全体的なシナリオは障害耐性が大幅に向上します。ただし、サプライヤーの設定が複雑になり、ネットワークの需要とサーバーの需要が高くなります。サプライヤーのサブセットへの更新の送信は、設定がはるかに簡単になり、ネットワークとサーバーの負荷が軽減されますが、複数のサーバーに障害が発生した場合、データが失われるリスクがあります。

図7.4「マルチマスターレプリケーション設定 A」 は、4 つのサプライヤーサーバーが、他の 3 つのサプライヤーサーバー（コンシューマーとしても機能する）にデータをフィードする、完全に接続されたメッシュトポロジーを示しています。4 つのサプライヤーサーバー間には、合計 12 のレプリケーションアグリーメントが存在します。

図7.5「マルチマスターレプリケーション設定 B」 は、各サプライヤーサーバーが他の 2 つのサプライヤーサーバー（コンシューマーとしても機能する）にデータをフィードするトポロジーを示しています。図7.4「マルチマスターレプリケーション設定 A」 のトポロジーでは、twelve 合意と比較して、4 つのサプライヤーサーバーの間には 8 つのレプリカ合意が存在します。このトポロジーは、2 つ以上のサーバーに同時に障害が発生する可能性を無視できる場合に役立ちます。

これら 2 つの例は、簡素化したマルチマスターのシナリオです。Red Hat Directory Server では、1 つのマルチマスター環境で 20 ものマスターと無制限のハブサプライヤーを持つことができるため、レプリケーションのトポロジーはより複雑になります。たとえば、図7.4「マルチマスターレプリケーション設定 A」 には 12 レプリカ合意があります（それぞれの契約が 3 つの合意を採用します）。マスター数が 20 の場合、レプリカ合意は 380 になります (20 台のサーバーにそれぞれ 19 の合意があります)。

マルチマスターレプリケーションを計画する際には、以下を考慮してください。