第15章 レプリケーションの管理

レプリケーション は、ディレクトリーデータが 1 つの Red Hat Directory Server インスタンスから相互に自動的に同期されるメカニズムで、単一のサーバー設定以外にディレクトリーサービスを拡張する上で重要なメカニズムです。本章では、単一サプライヤーレプリケーション、マルチサプライヤーレプリケーション、およびカスケードレプリケーションを設定するサプライヤーサーバーおよびコンシューマーサーバーで実行するタスクについて説明します。

15.1. レプリケーションの概要

レプリケーションとは、Directory Server 間でディレクトリーデータを自動的に同期させる仕組みです。あらゆる種類 (エントリーの追加、変更、削除、または名前変更) の更新は、レプリケーションを使用して他の Directory Server に自動的にミラーリングされます。

15.1.1. 複製されるディレクトリーユニット

レプリケートできるディレクトリーの最小単位はデータベースです。つまり、データベース全体を複製できますが、データベース内のサブツリーは複製できません。したがって、ディレクトリーツリーを作成する際に、情報を配信する方法を決定する際に、レプリケーションプランを検討してください。
レプリケーションでは、1 つのデータベースが 1 つの接尾辞に対応する必要もあります。つまり、カスタム分散ロジックを使用して 2 つ以上のデータベースに分散される接尾辞 (または名前空間) は複製できません。このトピックの詳細については、「データベースの作成および維持」を参照してください。

15.1.2. 読み取り/書き込みレプリカおよび読み取り専用レプリカ

レプリケーションに参加するデータベースは レプリカ と呼ばれます。レプリカには、読み書き可能なものと、読み取り専用の 2 種類があります。読み取り/書き込みレプリカ には、ディレクトリー情報のサプライヤーコピーが含まれ、更新できます。読み取り専用のレプリカ サービスは読み取り、検索、および比較要求ですが、読み取り/書き込みレプリカに対する更新操作をすべて参照します。サーバーは、任意の数の読み取り専用または読み書きレプリカを保持できます。

15.1.3. サプライヤーとコンシューマー

別のサーバーのレプリカに送信されるレプリカを保持するサーバーは、そのレプリカの サプライヤー と呼ばれます。別のサーバーから受信したレプリカを保持するサーバーは、そのレプリカの コンシューマー と呼ばれます。通常、サプライヤーサーバーのレプリカは読み取り/書き込みレプリカで、コンシューマーサーバーのレプリカは 2 つの例外を持つ読み取り専用レプリカになります。
  • レプリケーションをカスケードするとき、ハブサーバーは、コンシューマーに提供する読み取り専用レプリカを保持します。「カスケードレプリケーション」に詳細情報があります。
  • マルチサプライヤーレプリケーションの場合、サプライヤー は同じ情報についてサプライヤーとコンシューマーの両方を設定します。詳細は、「マルチサプライヤーのレプリケーション」 を参照してください。
レプリケーションは、常にサプライヤー・サーバーによって開始され、コンシューマーによって開始されることはありません (サプライヤーが開始するレプリケーション)。サプライヤーが開始するレプリケーションでは、サプライヤーサーバーを設定して、データを複数のコンシューマーサーバーに送信できます。

15.1.4. Changelog

すべてのサプライヤーサーバーは、changelog と、サプライヤーまたはハブがそのコンシューマーに送信する必要がある変更の記録です。changelog は、レプリカで発生した変更を保持する特別な種類のデータベースです。次に、サプライヤーサーバーは、マルチサプライヤーレプリケーションの場合には、コンシューマーサーバーに保存されているレプリカまたは他のサプライヤーにこの変更を再生します。
エントリーが変更されると、実行された LDAP 操作を記述する変更レコードが changelog に記録されます。
changelog は、メインデータベースと同じデータベース環境を使用します。メインのデータベースの一部として changelog を実装すると、データベースおよび changelog が常に同期され、必要なデータベースキャッシュサイズが減少し、バックアップと復元操作が簡素化されます。
重要
changelog は、サーバーがシャットダウンするときに changelog RUV エントリーをデータベースにのみ書き込み、それ以外は RUV がメモリー内で管理されます。サプライヤーのデータベースをバックアップする場合は、dsctl db2bak コマンドまたは Web コンソールを使用します。いずれの方法でも、バックアップを開始する前に RUV がデータベースに書き込まれます。
Directory Server では、changelog はサーバーによる内部使用のみを目的としています。

15.1.5. レプリケーション ID

2 つのサーバー間でレプリケーションが発生すると、レプリケーションプロセスは、レプリケーションマネージャー エントリーと呼ばれる特別なエントリーを使用して、レプリケーションプロトコルの交換を特定し、ディレクトリーデータへのアクセスを制御します。レプリケーションマネージャーエントリーまたはレプリケーション中に使用されるエントリーは、以下の基準を満たしている必要があります。
  • これは、cn=config エントリーのコンシューマーサーバーに作成されます。
  • 別のサーバーから更新を受け取る すべて のサーバー (つまり、すべてのハブまたは専用のコンシューマー) でこのエントリーを作成します。
  • レプリカがコンシューマーまたはハブとして設定されている場合は、このエントリーを、レプリケーションの更新を実行する権限のあるものとして指定する必要があります。
  • レプリカ合意はサプライヤーサーバーで作成され、このエントリーの DN をレプリカ合意に指定する必要があります。
  • レプリケーションコンテキストでは、このエントリーは、その特別なユーザープロファイルを使用して、そのレプリケーションアグリーメントに含まれるデータベースのコンシューマーサーバーで定義されたアクセス制御規則をバイパスします。レプリケーションコンテキストの外では、レプリケーションマネージャーは通常の操作を実行するときに ACI の影響を受けることに注意してください。

15.1.6. レプリカ合意

Directory Server はレプリカ合意を使用してレプリケーション設定を定義します。レプリカ合意は、1 つ のサプライヤーと 1 つ のコンシューマーとの間のレプリケーションのみを説明します。この合意はサプライヤーサーバーに設定し、必要なレプリケーション情報をすべて指定する必要があります。
  • 複製されるデータベース。
  • データがプッシュされるコンシューマーサーバー
  • レプリケーションが実行する曜日および時間帯
  • サプライヤーサーバーがバインドに使用する必要のある DN および認証情報 (レプリケーションマネージャーエントリーまたはサプライヤーバインド DN)
  • 接続をセキュアにする方法 (TLS、クライアント認証)。
  • 複製されない属性 (一部レプリケーション)

15.1.7. 一部レプリケーションを使用した属性のサブセットの複製

一部レプリケーションは、サプライヤーからコンシューマー (または別のサプライヤー) に送信されない特定の属性のサブセットを設定します。したがって、管理者は、含まれるすべての情報を複製したり、全エントリーのすべての情報を複製せずに、データベースを複製できます。
一部レプリケーションは、エントリーごとではなく、レプリカ合意ごとに有効になり、設定されます。レプリケーションから属性を除外すると、レプリカ合意の範囲内のすべてのエントリーと同等に適用されます。
スキーマで任意 (MAY キーワード) として定義された属性については、増分更新と全体更新で複製する属性を別々に設定することができます。増分更新リスト (nsDS5ReplicatedAttributeList) は、一部レプリケーションを有効にするために常に設定される必要があります。唯一の属性が設定されている場合は、増分更新と合計更新の両方に適用されます。オプションの nsDS5ReplicatedAttributeListTotal 属性は、更新の合計に追加の一部レプリケーション一覧を設定します。これは、「合計更新および増分更新での異なる一部レプリケーション属性の設定」で説明されています。
注記
除外された属性への更新が依然として変更イベントをトリガーし、空のレプリケーション更新を生成します。nsds5ReplicaStripAttrs 属性は、空のレプリケーションイベントでは送信できず、更新シーケンスから削除される属性の一覧を追加します。これには、modifiersName のような運用上の利便性が含まれます。
レプリケーションイベントが 空でない 場合は、ストライピングされた属性 が 複製されます。これらの属性は、イベントが空である場合にのみ更新から削除されます。

15.1.8. TLS 上のレプリケーション

セキュリティー上の理由から、TLS 接続を介してデータのみを複製するように、レプリケーションに関連する Directory Server インスタンスを設定します。属性の暗号化を有効にすると、セキュアな接続がレプリケーションに常に必要になります。

前提条件

TLS でレプリケーションを設定する前に、以下の前提条件を満たす必要があります。
  • サプライヤーサーバーとコンシューマーサーバーの両方が TLS を使用するように設定します。「Directory Server での TLS の有効化」を参照してください。
  • コンシューマーサーバーが、サプライヤーサーバーの証明書を サプライヤー DN として認識するように設定します。これは、簡易認証ではなく TLS クライアント認証のみを使用します。「証明書ベースのクライアント認証の使用」を参照してください。
    重要
    TLS ハンドシェイク中に、サプライヤーの証明書がサーバー証明書としてのみ動作し、同時にクライアントとしては動作しない場合は、証明書ベースの認証を用いて TLS 上で設定されたレプリケーションが失敗するという問題がありました。証明書ベースの認証でのレプリケーションでは、リモートサーバーへの認証に Directory Server のサーバー証明書を使用します。
    certutil を使用して証明書署名要求 (CSR) を生成する場合は、--nsCertType=sslClient,sslServer オプションをコマンドに渡し、必要な証明書を設定します。

TLS でのレプリケーションの設定

レプリケーションの設定に関する詳細は、以下を参照してください。