第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 は、サーバーのシャットダウン時に RUV エントリーをデータベースにのみ書き込み、それ以外は RUV がメモリー内で管理されます。マスターのデータベースをバックアップする場合は、db
2bak.pl ユーティリティーまたは Directory Server Console を使用します。いずれの方法でも、バックアップを開始する前に RUV がデータベースに書き込まれます。
Directory Server では、changelog はサーバーによる内部使用のみを目的としています。
15.1.5. レプリケーション ID
2 つのサーバー間でレプリケーションが発生すると、レプリケーションプロセスは、レプリケーションマネージャー エントリーと呼ばれる特別なエントリーを使用して、レプリケーションプロトコルの交換を特定し、ディレクトリーデータへのアクセスを制御します。レプリケーションマネージャーエントリーまたはレプリケーション中に使用されるエントリーは、以下の基準を満たしている必要があります。
- これは、サプライヤーサーバー ではなく、コンシューマーサーバーに作成されます。
- 別のサーバーから更新を受け取る すべて のサーバー (つまり、すべてのハブまたは専用のコンシューマー) でこのエントリーを作成します。
- レプリカがコンシューマーまたはハブとして設定されている場合は、このエントリーを、レプリケーションの更新を実行する権限のあるものとして指定する必要があります。
- レプリカ合意はサプライヤーサーバーで作成され、このエントリーの DN をレプリカ合意に指定する必要があります。
- このエントリーは、特別なユーザープロファイルで、そのレプリカ合意に関係するデータベースのコンシューマーサーバーで定義されるアクセス制御ルールをすべて回避します。
注記
Directory Server コンソールでは、このレプリケーションマネージャーエントリーは サプライヤーバインド DN と呼ばれます。これは、エントリーが実際にサプライヤーサーバーに存在しないため、誤解を招く可能性があります。これは、サプライヤーがコンシューマーにバインドするために使用するエントリーであるため、サプライヤー DN と呼ばれます。このエントリーは実際には、コンシューマーに存在します。
レプリケーションマネージャーエントリーの作成方法は、「サプライヤーバインド DN エントリーの作成」 を参照してください。
15.1.6. レプリカ合意
Directory Server はレプリカ合意を使用してレプリケーション設定を定義します。レプリカ合意は、1 つ のサプライヤーと 1 つ のコンシューマーとの間のレプリケーションのみを説明します。この合意はサプライヤーサーバーに設定し、必要なレプリケーション情報をすべて指定する必要があります。
- 複製されるデータベース。
- データがプッシュされるコンシューマーサーバー
- レプリケーションが実行する曜日および時間帯
- サプライヤーサーバーがバインドに使用する必要のある DN および認証情報 (レプリケーションマネージャーエントリーまたはサプライヤーバインド DN)
- 接続をセキュアにする方法 (TLS、クライアント認証)。
- 複製されない属性 (一部レプリケーション)
15.1.7. 一部レプリケーションを使用した属性のサブセットの複製
一部レプリケーションは、サプライヤーからコンシューマー (または別のサプライヤー) に送信されない特定の属性のサブセットを設定します。したがって、管理者は、含まれるすべての情報を複製したり、全エントリーのすべての情報を複製せずに、データベースを複製できます。
一部レプリケーションは、エントリーごとではなく、レプリカ合意ごとに有効になり、設定されます。レプリケーションから属性を除外すると、レプリカ合意の範囲内のすべてのエントリーと同等に適用されます。
コンシューマーサーバーに関する限り、除外された属性には常に値がありません。そのため、コンシューマーサーバーに対する検索を実行するクライアントは、除外された属性は表示されません。同様に、フィルターでそれらの属性を指定する検索を実行しても、一致するエントリーはありません。
スキーマで任意 (MAY キーワード) として定義された属性については、増分更新と全体更新で複製する属性を別々に設定することができます。増分更新リスト (
nsDS5ReplicatedAttributeList) は、一部レプリケーションを有効にするために常に設定される必要があります。唯一の属性が設定されている場合は、増分更新と合計更新の両方に適用されます。任意の nsDS5ReplicatedAttributeListTotal 属性は、更新の合計に追加の一部レプリケーション一覧を設定します。これは、「合計更新および増分更新での異なる一部レプリケーション属性の設定」で説明されています。
注記
除外された属性への更新が依然として変更イベントをトリガーし、空のレプリケーション更新を生成します。
nsds5ReplicaStripAttrs 属性は、空のレプリケーションイベントでは送信できず、更新シーケンスから削除される属性の一覧を追加します。これには、modifiersName のような運用上の利便性が含まれます。
レプリケーションイベントが 空でない 場合は、ストライピングされた属性 が 複製されます。これらの属性は、イベントが空である場合にのみ更新から削除されます。
15.1.7.1. レプリケーションのキープアライブエントリー
マスターの属性を更新すると、マスターに対する変更シーケンス番号(CSN)が増えます。レプリケーショントポロジーでは、このサーバーは最初のコンシューマーに接続し、ローカル CSN をコンシューマーの CSN と比較できるようになりました。ローカル CSN の方が低い場合は、ローカルの changelog から更新内容を取得し、コンシューマーに複製します。一部レプリケーションを有効にしたレプリケーショントポロジーでは、これが問題になることがあります。たとえば、レプリケーションから除外された属性のみがマスター上で更新された場合、複製するための更新が見つからないため、コンシューマー上で CSN が更新されません。特定のシナリオでは、レプリケーションから除外されたマスターで属性のみが更新されると、サプライヤーの更新に不要な検索を行うと、他のサーバーが、必要に応じて後にデータを受け取る可能性があります。この問題を回避するために、Directory Server ではキープアライブエントリーを使用します。
マスター上の更新された属性がすべてレプリケーションから除外され、スキップされた更新の数が 100 を超えると、サプライヤーで
keepalivetimestamp 属性が更新され、コンシューマーに複製されます。keepalivetimestamp 属性はレプリケーションから除外されないため、キープアライブエントリーの更新は複製され、コンシューマー上の CSN が更新され、サプライヤー上のものと等しくなります。次回サプライヤーをコンシューマーに接続する際には、コンシューマーの CSN より新しい更新のみが検索されます。これにより、サプライヤーが送信する新規更新の検索に費やされた時間が短縮されます。
レプリケーションキープアライブエントリーはマスター上でオンデマンドで作成され、識別名(DN)にマスターのレプリカ ID が含まれます。キープアライブエントリーはそれぞれ特定のマスターに固有のものです。以下に例を示します。
dn: cn=repl keep alive 14,dc=example,dc=com objectclass: top objectclass: ldapsubentry objectclass: extensibleObject cn: repl keep alive 14 keepalivetimestamp: 20170227190346Z
キープアライブエントリーは、以下の状況で更新されます (更新前に存在しない場合には最初に作成されます)。
- 一部レプリカ合意が 100 を超える更新を省略し、レプリケーションセッションの終了前に更新を送信しません。
- マスターがコンシューマーを初期化すると、最初に独自のキープアライブエントリーを作成します。マスターでもあるコンシューマーは、別のコンシューマーも初期化しない限り、独自のキープアライブエントリーを作成しません。
