4.2. レプリカのデプロイメントに関する考慮事項
4.2.1. トポロジーでのサーバーサービスの分散
IdM サーバーは、認証局 (CA) や DNS など、多数のサービスを実行できます。レプリカは、作成したサーバーと同じサービスを実行できますが、必須ではありません。
たとえば、最初のサーバーが DNS を実行する場合でも、DNS サービスなしでレプリカをインストールできます。同様に、DNS を使用せずに最初のサーバーがインストールされた場合でも、レプリカを DNS サーバーとして設定できます。
図4.2 サービスが異なるレプリカ
レプリカ上の CA サービス
CA なしでレプリカを設定すると、証明書操作の全要求が、トポロジー内の CA サーバーに転送されます。
警告
Red Hat は、複数のサーバーに CA サービスをインストールすることを強く推奨します。CA サービスを含む初期サーバーのレプリカのインストールは、「CA のあるレプリカのインストール」 を参照してください。
CA を 1 台のサーバーにのみインストールすると、CA サーバーが失敗した場合に CA 設定を復元できる機会なしに CA 設定が失われるリスクがあります。詳細は「失われた CA サーバーの復旧」を参照してください。
レプリカに CA を設定する場合は、その設定が最初のサーバーの CA 設定を反映する必要があります。
- たとえば、サーバーに統合された IdM CA がルート CA として含まれている場合は、レプリカも統合 CA をルート CA としてインストールする必要があります。
- サポートされている CA 設定オプションは、「使用する CA 設定の決定」 を参照してください。
4.2.2. レプリカトポロジーの推奨事項
Red Hat では、以下のガイドラインに従うことを推奨します。
- 1 つの IdM ドメインに 60 を超えるレプリカを設定する
- Red Hat は、レプリカが 60 台以下の環境をサポートすることを保証します。
- レプリカごとに 少なくても 2 つ、多くても 4 つ のレプリカ合意を設定する
- 追加のレプリカ合意を設定すると、初期レプリカとマスターサーバーとの間だけでなく、他のレプリカ間でも情報が複製されます。
- サーバー A からレプリカ B を作成し、サーバー A からレプリカ C を作成する場合に、レプリカ B と C は直接連結されていないので、レプリカ B からのデータが先にサーバー A に複製されてから、レプリカ C に伝播する必要があります。
図4.3 レプリカ B および C はレプリカ合意には参加しない
レプリカ B とレプリカ C の間に追加のレプリカ合意を設定すると、データは直接複製され、データの可用性、一貫性、フェイルオーバーの耐性、およびパフォーマンスが改善されます。図4.4 レプリカ B および C はレプリカ合意に参加している
レプリカ合意の管理に関する詳細は、6章レプリケーショントポロジーの管理 を参照してください。
レプリカごとに 4 つ以上のレプリカ合意を設定する必要はありません。サーバーごとに多数のレプリカ合意を行っても、1 つのマスターでは、一度に 1 つのコンシューマーサーバーしか更新できないので、その他の合意はアイドル状態で、待機していることになります。また、レプリカ合意を設定しすぎると、全体的なパフォーマンスに影響を及ぼす可能性があります。注記ipa topologysuffix-verify コマンドは、トポロジーが最も重要な推奨事項を満たしているかどうかを確認します。詳細は、ipa topologysuffix-verify --help を実行します。このコマンドには、トポロジーの接尾辞を指定する必要があります。詳細は「レプリカ合意、トポロジー接尾辞、およびトポロジーセグメントの説明」を参照してください。
図4.5 トポロジーの例
4.2.2.1. 密接なセルトポロジー
最も回復性の高いトポロジーの 1 つとして、セル内にサーバーが少数あるサーバーとレプリカのセル設定を作成します。
- 各セルは 密接なセル です。密接なセルでは、すべてのサーバーにはレプリカ合意があります。
- 各サーバーには、セル 外の 別のサーバーとレプリカ合意があります。これにより、すべてのセルがドメイン内の他のすべてのセルに疎結合されるようになります。
密接なセルトポロジーを実現するには、以下を行います。
- 各メインオフィス、データセンター、地域に、少なくとも 1 つの IdM サーバーを用意します。可能であれは、2 台の IdM サーバーを用意します。
- 各データセンターに用意するサーバーは 4 台までとします。
- 小規模なオフィスでは、レプリカを使用する代わりに、SSSD を使用して認証情報をキャッシュし、オフサイトの IdM サーバーをデータバックエンドとしてキャッシュします。
