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

レプリケーションとは、1 つから別のもう 1 つ、または複数の Directory Server にディレクトリの内容を自動的にコピーするメカニズムです。エントリの追加、変更、削除など、あらゆる書き込み処理はコピー先の Directory Server に自動的にミラー化されます。レプリケーションの概念、レプリケーションの導入例、ディレクトリ導入時にレプリケーションを計画する方法についての詳細は、『Directory Server 配備計画ガイド』の第 6 章「レプリケーションについての理解」を参照してください。

Directory Server 5.2 には、次のようなレプリケーションの新機能が用意されています。

広域ネットワーク (WAN) 上のマルチマスターレプリケーション (MMR) では、地理的に離れたマスターとの間でレプリケーションアグリーメントを確立し、データをより効率的に配信できます。

MMR は、完全に接続されたマスターを同時に 4 つサポートできるようになりました。これにより、一層のフェイルオーバ保護を提供できます。

バイナリコピーにより、大容量レプリカの初期化がより高速になりました。

部分レプリケーションにより、レプリケートする属性セットを指定できるので、データをより効率的に配信できます。

レプリケーションアクティビティの監視には、新しいコマンド行ツールも利用できます。

この章では、レプリケーションのさまざまな導入例の設定作業について説明します。説明する内容は次のとおりです。

はじめに

レプリケーションの設定は複雑な作業です。設定を始める前に、シングルマスターとマルチマスターのどちらを導入するのか、またはハブを利用したカスケード型レプリケーションを導入するのかなど、組織に導入するレプリケーションの種類を明確にしておく必要があります。レプリケーションの単位はサフィックスまたはサブサフィックスです。1 つのサフィックスに含まれるすべてのエントリは、まとめてレプリケートされます。導入を意図したように行うには、各サフィックスをマスター、ハブ、または含まれるデータの専用コンシューマとして識別する必要があります。

サーバーにレプリケートされるサフィックスをレプリカと呼びます。マスターは、クライアントからの読み取り処理と書き込み処理の両方を受け付けるレプリカです。ハブと専用コンシューマは、レプリケーションメカニズムを使用して行われる更新だけを受け付ける、読み取り専用のレプリカです。ハブは、マスターまたは別のハブからの更新を受信し、それを別のハブまたは専用コンシューマに転送します。専用コンシューマは、マスターまたはハブから更新を受信するだけです。

次の 3 つの図は、レプリケーションの一般的な導入例でのレプリカ間の関係を示しています。

このマニュアルでは、サプライヤとコンシューマという用語も使います。これは、レプリケーションアグリーメントに関与する 2 種類のサーバーの役割を意味します。サプライヤはレプリケーション更新を送信するサーバーで、コンシューマはそれを受信するサーバーです。上の図は、次の関係を示しています。

シングルマスターはサプライヤであり、コンシューマではない

マルチマスターレプリケーションのマスターには、サプライヤとしての役割だけでなく、他のマスターのコンシューマとしての役割もある

ハブには常にサプライヤとコンシューマの役割がある

専用コンシューマは常にコンシューマである

レプリカの種類に関係なく、アグリーメントにはサプライヤとコンシューマの役割として、数多くのレプリケーション設定がレプリカに適用されます。

レプリケーションの設定手順のまとめ

次の手順は、シングルサフィックスのレプリケーションを前提としています。複数のサフィックスをレプリケートする場合は、各サーバーでそれぞれを並行して設定する必要があります。つまり、複数サフィックスのレプリケーションを設定するには、各手順を繰り返す必要があります。

レプリケーションのトポロジを設定する手順は、次のとおりです。

シングルマスターを除くすべてのサーバーでレプリケーションマネージャのエントリを定義します (または、すべてのサーバーでデフォルトのレプリケーションマネージャを使用する)。

専用コンシューマのレプリカが作成されるすべてのサーバーでは、次の処理を行います。

コンシューマレプリカ用の空のサフィックスを作成します。

レプリケーションウィザードを使用して、サフィックスに含まれるコンシューマレプリカを有効にします。

必要に応じて、詳細なレプリカ設定を行います。

ハブを利用する場合は、ハブのレプリカが作成されるすべてのサーバーで次の処理を行います。

ハブレプリカ用の空のサフィックスを作成します。

レプリケーションウィザードを使用して、サフィックスに含まれるハブレプリカを有効にします。

必要に応じて、詳細なレプリカ設定を行います。

マスターレプリカが作成されるすべてのサーバーでは、次の処理を行います。

マスターレプリカとなるマスターで、サフィックスを 1 つ選択するか、作成します。

レプリケーションウィザードを使用して、サフィックスに含まれるマスターレプリカを有効にします。

必要に応じて、詳細なレプリカ設定を行います。

すべてのサプライヤレプリカで、次の順序でレプリケーションアグリーメントを設定します。

マルチマスターセットのマスター間

マスターと専用コンシューマの間

マスターとハブレプリカの間

必要に応じて、この時点で部分レプリケーションを設定することができます。

ハブレプリカとそのコンシューマとの間のレプリケーションアグリーメントを設定します。

マルチマスターレプリケーションでは、データのオリジナルコピーを含むマスターレプリカから順にすべてのマスターを初期化します。ハブとコンシューマレプリカを初期化します。



注	レプリケーションアグリーメントを作成する前に、すべてのレプリカを有効にすることが重要です。こうすることで、レプリケーションアグリーメントの作成後、ただちにコンシューマレプリカを初期化できます。コンシューマの初期化は、常にレプリケーションの設定の最後の段階で実行します。

レプリケーションマネージャの選択

レプリケーションの設定で重要なのは、レプリケーションマネージャというエントリを選択することです。レプリケーションマネージャは、サプライヤがレプリケーションの更新を送信するときに、コンシューマサーバーとのバインドに使われます。更新を受け取るサフィックスを持つすべてのサーバーでは、少なくとも 1 つのレプリケーションマネージャエントリが必要です。

Directory Server には、すべてのサーバーで利用できるデフォルトのレプリケーションマネージャエントリが用意されています。このエントリの DN は cn=Replication Manager,cn=replication,cn=config です。

単純なレプリケーションの導入例では、デフォルトのレプリケーションマネージャを利用することをお勧めします。レプリケーションウィザードは、このエントリを使用してコンシューマレプリカを自動的に設定するので、レプリカを簡単に導入できます。

デフォルトレプリケーションマネージャのパスワードが定義されていない場合、レプリケーションウィザードはパスワードの入力を要求します。パスワードをあとから変更する手順は、次のとおりです。

Directory Server コンソールの最上位の「設定」タブで「データ」ノードを選び、右側のパネルで「レプリケーション」タブを選びます。

「レプリケーションマネージャ」という見出しの下にある 2 つのテキストフィールドに新しいパスワードを入力します。

パスワードの確認への入力が完了したら、「保存」をクリックします。パスワードが確認のために入力したパスワードと一致しない場合、「保存」ボタンは有効になりません。

デフォルトのレプリケーションマネージャを使用しない場合、レプリケーションマネージャとして機能するエントリを新たに作成することができます。たとえば、レプリケートされるすべてのサフィックスで、複数のレプリケーションマネージャエントリに異なるパスワードを持たせることができます。また、たとえば SSL 経由の証明書など、異なる認証モデルをレプリケーションに適用するには、独自のレプリケーションマネージャを作成する必要があります。

レプリケーションマネージャエントリには、レプリケーションアグリーメントを定義するときに、選択した認証方法に適した属性が含まれている必要があります。たとえば、デフォルトのレプリケーションマネージャのオブジェクトクラスは person です。このクラスは、userPassword 属性を使った簡単な認証に対応しています。証明書を使用してレプリケーションマネージャをバインドする方法の詳細は、「SSL を経由するレプリケーション」を参照してください。

レプリケーションマネージャのエントリは、コンシューマサーバーのレプリケートされたサフィックスの中に保存しておくことはできません。レプリケーションマネージャの定義場所としてふさわしいのは、cn=replication,cn=config です。

新しいレプリケーションマネージャをコマンド行から手動で作成する場合は、レプリカ設定エントリの nsDS5ReplicaBindDN 属性を変更することで、コンシューマ上のバインド DN を指定する必要があります。

各コンシューマのレプリケーションマネージャを選択したら、次の処理を行います。


警告	レプリケーションマネージャエントリの DN とパスワードを使用して、バインドを実行したり、サーバー上で処理を行うことはできません。レプリケーションマネージャはレプリケーションメカニズムだけが使用するものであり、その他の使用ではレプリカの再初期化が必要です。 Directory Manager をレプリケーションマネージャとして使用することはできません。

選択または作成したレプリケーションマネージャの DN を書き留めるか、覚えておきます。この DN とそのパスワードは、あとからこのコンシューマのサプライヤとの間でレプリケーションアグリーメントを作成するときに必要です。

パスワードに有効期限ポリシーを定義したときは、レプリケーションマネージャを除外しておく必要があります。除外しない場合、パスワードの有効期限が切れるとレプリケーションが行われなくなります。レプリケーションマネージャエントリでパスワードの有効期限を無効にするには、パスワードの有効期限が切れないパスワードポリシーを作成し、それをレプリケーションマネージャエントリに割り当てます。詳細は、「個別パスワードポリシーの管理」を参照してください。

専用コンシューマの設定

専用コンシューマは、レプリケートされたサフィックスの読み取り専用コピーです。これは、レプリケーションマネージャとしてバインドされたサーバーから更新を受け取り、変更を行います。コンシューマサーバーを設定するには、レプリカを保持する空のサフィックスを準備し、レプリケーションウィザードを使用してそのサフィックスのレプリケーションを有効にします。必要に応じて、異なるレプリケーションマネージャの選択、リフェラルの設定、パージ遅延の設定など、詳細な設定を行うこともできます。

次に、1 つの専用コンシューマレプリカをそのレプリカのサーバーに設定する手順について説明します。特定のサフィックスの専用コンシューマレプリカを含むすべてのサーバーで、同じ手順を繰り返してください。

コンシューマレプリカのサフィックスの作成

サフィックスをまだ作成していない場合は、レプリケーションの対象となるマスターレプリカと同じ DN を使用してコンシューマに空のサフィックスを作成します。手順については、「サフィックスの作成」を参照してください。

すでにサフィックスが存在し、それが空でない場合は、マスターからレプリカが初期化されたときにそのサフィックスの内容は失われます。

コンシューマレプリカの有効化

レプリケーションウィザードを使うことで、専用コンシューマのレプリカを簡単に有効にできます。

Directory Server コンソールの最上位の「設定」タブで、「データ」ノードを展開し、コンシューマレプリカとして設定するサフィックスのノードを展開し、サフィックスの下の「レプリケーション」ノードを選択します。

右側のパネルにレプリカのステータス情報が表示されます。

「レプリケーションを有効に」ボタンをクリックすると、レプリケーションウィザードが起動されます。

デフォルトでは、「コンシューマレプリカ」ラジオボタンが選択されています。「次へ」をクリックして処理を続けます。

デフォルトのレプリケーションマネージャのパスワードが定義されていない場合、パスワードの入力と確認のための再入力が求められます。各フィールドに同じパスワードを入力し、「次へ」をクリックします。

デフォルトレプリケーションマネージャにすでにパスワードが定義されている場合、この手順は省略されます。

レプリケーションウィザードはレプリケーションの設定更新を開始します。ウィザードには、ステータスメッセージが表示されます。処理が完了したら、「閉じる」をクリックします。

レプリケーションのステータスは、レプリカが更新の受信準備が整っていることを示し、それに対応して左側のペインのアイコンも変更されます。

コンシューマの詳細設定

デフォルトでは、ウィザードはデフォルトのレプリケーションマネージャを使うようにレプリカを設定します。別のレプリケーションマネージャエントリを使用する場合には、詳細な設定が必要です。また、このダイアログを使用して変更とパージ遅延のリフェラルも設定できます。

Directory Server コンソールの最上位の「設定」タブで、「データ」ノードを展開し、設定するサフィックスのノードを展開し、サフィックスの下の「レプリケーション」ノードを選択します。

右側のパネルで「詳細」ボタンをクリックし、「詳細レプリカ設定」ダイアログを開きます。

「バインド DN」タブで、「追加」ボタンと「削除」ボタンを使用して有効なレプリケーションマネージャの DN リストを作成します。このリストは、サプライヤとこのレプリカとの間のアグリーメントに含まれるため、サプライヤはリスト内のいずれの DN も利用できるようになります。新しい DN を追加するときは、DN 名を入力するか、ディレクトリを参照して選択します。

SSL 経由の証明書を使うようにレプリケーションを設定するときは、レプリケーションマネージャの 1 つのエントリとして証明書の DN を指定します。

処理が完了したら、「了解」をクリックします。「オプション」タブを選んで、さらに詳細な設定を行うこともできます。

「詳細レプリカ設定」ダイアログの「オプション」タブには、このコンシューマに送信される変更要求の追加リフェラルを指定する LDAP URL のリストが表示されます。LDAP URL のリストを作成するには、「追加」ボタンと「削除」ボタンを使います。

レプリケーションのメカニズムでは、レプリケーショントポロジに含まれるすべての既知のマスターのリフェラルを返すようにコンシューマを自動的に設定します。これらのデフォルトリフェラルは、クライアントが標準的な接続で簡単な認証を使うことを前提としています。安全な接続のために SSL を使用してマスターにバインドするオプションをクライアントに提供するには、ldaps://servername:port という形式でリフェラルを追加します。port にはセキュリティ保護された接続に使うポート番号を指定します。(マスターがセキュリティ保護された接続のみに設定されていれば、URL はデフォルトでセキュリティ保護されたポートを指定する)

リフェラルとして 1 つまたは複数の LDAP URL を追加したときは、リストの下に表示されるチェックボックスを選択して、コンシューマがマスターレプリカのリフェラルではなく、これらの LDAP URL のリフェラルを送信するようにします。たとえば、クライアントがデフォルトのポートではなく、常にマスターサーバーのセキュリティ保護されたポートにアクセスするように設定するには、これらのセキュリティ保護されたポートの LDAP URL リストを作成し、このチェックボックスを選択します。すべての更新を処理する特定のマスターまたは Directory Server プロキシを指定する場合も、排他的なリフェラルを用意する必要があります。

「オプション」タブでは、パージ遅延も変更できます。

コンシューマサーバーは、レプリカの内容に加えられる変更に関する内部情報を格納し、パージ遅延はこの情報を保持する期間を決定します。この値は、サプライヤサーバーの更新履歴ログの MaxAge パラメータと関連づけられています。これらの 2 つのパラメータのうち、短いほうの設定が、2 つのサーバー間のレプリケーションが無効になった、またはダウンした場合でも正常な状態に復元できる最長期間を決定します。ほとんどの場合には、デフォルトの 7 日間が適当です。

「了解」をクリックして、このレプリカの詳細設定を保存します。

ハブの設定

ハブレプリカは、コンシューマとしてだけではなく、マスターとしても機能し、レプリケートされたデータをより多くのコンシューマに配信します。このため、レプリケーションの更新をそれぞれのサプライヤから受信して、レプリケーションの更新をそれぞれのコンシューマに送信します。ハブレプリカは変更を受け付けませんが、マスターにリフェラルを返します。

ハブサーバーを設定するには、レプリカを保持する空のサフィックスを準備し、レプリケーションウィザードを使用してそのサフィックスのレプリケーションを有効にします。必要に応じて、異なるレプリケーションマネージャの選択、リフェラルの設定、パージ遅延の設定、ログパラメータの設定と変更など、詳細な設定も行うことができます。

次に、1 つのハブサーバーを設定する手順について説明します。特定のサフィックスのハブレプリカを含むすべてのサーバーで、同じ手順を繰り返してください。

ハブレプリカのサフィックスの作成

サフィックスをまだ作成していない場合は、レプリケーションの対象となるマスターレプリカと同じ DN を使用してハブサーバーに空のサフィックスを作成します。手順については、「サフィックスの作成」を参照してください。

すでにサフィックスが存在し、それが空でない場合は、マスターからレプリカが初期化されたときにそのサフィックスの内容は失われます。

ハブレプリカの有効化

レプリケーションウィザードを使うことで、ハブレプリカを簡単に有効にできます。

Directory Server コンソールの最上位の「設定」タブで、「データ」ノードを展開し、ハブレプリカとして設定するサフィックスのノードを展開し、サフィックスの下の「レプリケーション」ノードを選択します。

右側のパネルにレプリカのステータス情報が表示されます。

「レプリケーションを有効に」ボタンをクリックすると、レプリケーションウィザードが起動されます。

「ハブレプリカ」ラジオボタンを選択し、「次へ」をクリックします。

更新履歴ログファイルを選択していない場合は、ログファイルの選択が求められます。テキストフィールドには、デフォルトの更新履歴ログファイルが表示されます。デフォルトの更新履歴ログファイルを使わないときは、ファイル名を入力するか、「参照」をクリックしてファイルを選択します。

更新履歴ログファイルがすでに指定されている場合、この手順は省略されます。

「次へ」をクリックします。デフォルトのレプリケーションマネージャのパスワードが定義されていない場合、パスワードの入力と確認のための再入力が求められます。各フィールドに同じパスワードを入力し、「次へ」をクリックします。

デフォルトレプリケーションマネージャにすでにパスワードが定義されている場合、この手順は省略されます。

レプリケーションのステータスは、レプリカが更新の受信準備が整っていることを示し、それに対応して左側のペインのアイコンも変更されます。

ハブの詳細設定

ハブはサプライヤとして更新履歴ログファイルを必要とします。ウィザードを使った場合、デフォルトの更新履歴ログの設定を使用してハブレプリカが設定されます。この設定を変更する手順は、次のとおりです。

Directory Server コンソールの最上位の「設定」タブで「データ」ノードを選び、右側のパネルで「レプリケーション」タブを選びます。

このタブの内容の更新が必要な場合には、「更新履歴ログを有効に」チェックボックスを選択して「リセット」ボタンをクリックします。これにより、レプリケーションウィザードで選択した更新履歴ログファイルが表示されます。

更新履歴ログファイルの名前を変更したり、ログパラメータを変更したりできます。

「更新履歴ログの最大レコード数」 - コンシューマに更新を送信するために格納しておく変更の最大数を決定します。デフォルトでは、無制限です。レプリカが数多くの大容量の変更を受信するときは、レコード数を少なめに設定して、ディスク容量を節約できます。

「更新履歴ログの最長保存期間」 - コンシューマに送信する必要のある更新をどれだけの期間ハブが保持しているかを決定します。デフォルトでは、無制限です。更新履歴ログのサイズを制限するときは、最長保存期間パラメータを利用することをお勧めします。

レプリケーションウィザードは、デフォルトのレプリケーションマネージャを使用します。レプリケーションマネージャエントリを独自に作成した場合、それを使うには詳細な設定が必要です。また、このダイアログを使用して変更とパージ遅延のリフェラルも設定できます。

右側のパネルで「詳細」ボタンをクリックし、「詳細レプリカ設定」ダイアログを開きます。

SSL 経由の証明書を使うようにレプリケーションを設定するときは、レプリケーションマネージャの 1 つのエントリとして証明書の DN を指定します。

処理が完了したら、「了解」をクリックします。「オプション」タブを選んで、さらに詳細な設定を行うこともできます。

「詳細レプリカ設定」ダイアログの「オプション」タブには、このハブに送信される変更要求の追加リフェラルを指定する LDAP URL のリストが表示されます。LDAP URL のリストを作成するには、「追加」ボタンと「削除」ボタンを使います。

レプリケーションのメカニズムでは、レプリケーショントポロジに含まれるすべての既知のマスターのリフェラルを返すようにハブを自動的に設定します。これらのデフォルトリフェラルは、クライアントが標準的な接続で簡単な認証を使うことを前提としています。安全な接続のために SSL を使用してマスターにバインドするオプションをクライアントに提供するには、ldaps://servername:port という形式でリフェラルを追加します。port にはセキュリティ保護された接続に使うポート番号を指定します。

リフェラルとして 1 つまたは複数の LDAP URL を追加したときは、リストの下に表示されるチェックボックスを選択して、サーバーがマスターレプリカのリフェラルではなく、これらの LDAP URL のリフェラルを送信するようにします。たとえば、クライアントがデフォルトのポートではなく、常にマスターサーバーのセキュリティ保護されたポートにアクセスするように設定するには、これらのセキュリティ保護されたポートの LDAP URL リストを作成し、このチェックボックスを選択します。すべての更新を処理する特定のマスターまたは Directory Server プロキシを指定する場合も、排他的なリフェラルを用意する必要があります。

「オプション」タブでは、パージ遅延も変更できます。

ハブサーバーは、レプリカの内容に加えられる変更に関する内部情報を格納し、パージ遅延はこの情報を保持する期間を決定します。この値は、更新を提供するサーバーの更新履歴ログ (このサーバー自体の更新履歴ログではない) の MaxAge パラメータと関連づけられています。これらの 2 つのパラメータのうち、短いほうの設定が、2 つのサーバー間のレプリケーションが無効になった、またはダウンした場合でも正常な状態に復元できる最長期間を決定します。ほとんどの場合には、デフォルトの 7 日間が適当です。

「了解」をクリックして、このレプリカの詳細設定を保存します。

マスターレプリカの設定

マスターレプリカにはデータのマスターコピーが含まれ、更新を他のすべてのレプリカに配信する前に、すべての変更を集中的に管理します。マスターはすべての変更を記録し、関連する各コンシューマの状態を確認して、必要に応じて更新を送信します。マルチマスターレプリケーションでは、マスターレプリカが他のマスターから更新を受け取ることもあります。

マスターサーバーを設定するときは、マスターレプリカを含むサフィックスを決定し、レプリケーションウィザードを使用してマスターレプリカを有効にします。また、必要に応じてレプリケーションの詳細設定を行います。

次に、1 つのマスターサーバーを設定する手順について説明します。特定のサフィックスのマスターレプリカを含むすべてのサーバーで、同じ手順を繰り返してください。

マスターレプリカのサフィックスの定義

レプリケートするエントリを保存するマスターサーバー上でサフィックスを選択、または作成します。手順については、「サフィックスの作成」を参照してください。

サフィックスには、レプリケーションアグリーメントを作成する前にすべての初期データを含めておく必要があります。こうすることで、このデータからただちにコンシューマレプリカを初期化できます。マルチマスター設定と初期化を正しく確実に行うために、すべての初期データを 1 つのマスターだけに含め、他のマスターのサフィックスは空にしておきます。

マスターレプリカの有効化

レプリケーションウィザードを使うことで、マスターレプリカを簡単に有効にできます。

Directory Server コンソールの最上位の「設定」タブで、「データ」ノードを展開し、マスターレプリカとして設定するサフィックスのノードを展開し、サフィックスの下の「レプリケーション」ノードを選択します。

右側のパネルにレプリカのステータス情報が表示されます。

「レプリケーションを有効に」ボタンをクリックすると、レプリケーションウィザードが起動されます。

「マスターレプリカ」ラジオボタンを選択し、「次へ」をクリックします。

レプリカ ID を入力します。指定できる値は、1 ～ 65534 までの間で他の ID と重複しない整数です。

あるサフィックスのすべてのマスターレプリカでは、それぞれのレプリカ ID が一意である必要があります。同一サーバー上であってもサフィックスが異なる場合は、マスターレプリカのレプリカ ID は同じでも問題ありません。

「次へ」をクリックします。更新履歴ログファイルを選択していない場合は、ログファイルの選択が求められます。テキストフィールドには、デフォルトの更新履歴ログファイルが表示されます。デフォルトの更新履歴ログファイルを使わないときは、ファイル名を入力するか、「参照」をクリックしてファイルを選択します。

更新履歴ログファイルがすでに指定されている場合、この手順は省略されます。

「次へ」をクリックします。デフォルトのレプリケーションマネージャのパスワードが定義されていない場合、パスワードの入力と確認のための再入力が求められます。シングルマスターレプリケーションではレプリケーションマネージャは使われませんが、設定を続けるにはパスワードを入力する必要があります。各フィールドに同じパスワードを入力し、「次へ」をクリックします。

デフォルトレプリケーションマネージャにすでにパスワードが定義されている場合、この手順は省略されます。

レプリケーションのステータスにはこのマスターのレプリカ ID が表示され、左側のペインにはこのサフィックスのレプリケーションが有効であることを示すアイコンが表示されます。

マルチマスターの詳細設定

デフォルトでは、ウィザードはデフォルトの更新履歴ログを使うようにマスターレプリカを設定します。更新履歴ログの設定を変更する手順は、次のとおりです。

Directory Server コンソールの最上位の「設定」タブで「データ」ノードを選び、右側のパネルで「レプリケーション」タブを選びます。

更新履歴ログファイルの名前を変更したり、ログパラメータを変更したりできます。

「更新履歴ログの最長保存期間」 - コンシューマに送信する必要のある更新をどれだけの期間マスターが保持しているかを決定します。デフォルトでは、無制限です。更新履歴ログのサイズを制限するときは、最長保存期間パラメータを利用することをお勧めします。

レプリケーションウィザードは、デフォルトのレプリケーションマネージャを使用します。レプリケーションマネージャエントリを独自に作成した場合、それを使うには詳細な設定が必要です。また、このダイアログを使用して変更とパージ遅延のリフェラルも設定できます。シングルマスターの設定では、この手順を省略します。

右側のパネルで「詳細」ボタンをクリックし、「詳細レプリカ設定」ダイアログを開きます。

SSL 経由の証明書を使うようにレプリケーションを設定するときは、レプリケーションマネージャの 1 つのエントリとして証明書の DN を指定します。

処理が完了したら、「了解」をクリックします。「オプション」タブを選んで、さらに詳細な設定を行うこともできます。

「詳細レプリカ設定」ダイアログの「オプション」タブには、このマスターに送信される変更要求の追加リフェラルを指定する LDAP URL のリストが表示されます。「マルチマスター初期化後のマスター間の一致」で説明するように、初期化が完了すると、マスターはただちに自動的にリフェラルを返します。LDAP URL のリストを作成するには、「追加」ボタンと「削除」ボタンを使います。

「オプション」タブでは、パージ遅延も変更できます。

マスターサーバーは、レプリカの内容に加えられる変更に関する内部情報を格納する必要があり、パージ遅延はこの情報を保持する期間を決定します。この値は、更新を提供するマスターサーバーの更新履歴ログ (このサーバー自体の更新履歴ログではない) の MaxAge パラメータと関連づけられています。これらの 2 つのパラメータのうち、短いほうの設定が、2 つのサーバー間のレプリケーションが無効になった、またはダウンした場合でも正常な状態に復元できる最長期間を決定します。ほとんどの場合には、デフォルトの 7 日間が適当です。

「了解」をクリックして、このレプリカの詳細設定を保存します。

レプリケーションアグリーメントの作成

レプリケーションアグリーメントはサプライヤ側に設定されるパラメータセットで、更新をどのようにコンシューマに送信するかを制御します。コンシューマに更新を送信するサプライヤレプリカには、レプリケーションアグリーメントを作成する必要があります。レプリケーションアグリーメントは、レプリケーションメカニズムを使用して更新するすべてのコンシューマに 1 つずつ作成する必要があります。

レプリケーションアグリーメントを作成する順序は、次のとおりです。

マルチマスターセットのマスターの間 (レプリケートするサフィックスのオリジナルコピーを含むマスターを最初に作成)

マスターと、レプリケーションにハブを使わない専用コンシューマの間

マスターとハブレプリカの間

ハブレプリカと、ハブを使うコンシューマの間

たとえば図 8-3 は、2 つのマスターと 3 つの専用コンシューマのレプリケーショントポロジを持つマルチマスターレプリケーションを示しています。この場合、次の順序で 8 つのレプリケーションアグリーメントを作成します。

1 つのマスターともう一方のマスターの間

もう一方のマスターと最初のマスターの間

1 つのマスターと 3 つの専用コンシューマの間

もう一方のマスターと 3 つの専用コンシューマの間

レプリケーションアグリーメントを作成する手順は、次のとおりです。

Directory Server コンソールの最上位の「設定」タブで、「データ」ノードを展開し、サプライヤサフィックスのノードを展開し、サフィックスの下の「レプリケーション」ノードを選択します。

右側のパネルにレプリカのステータス情報が表示されます。

定義されているレプリケーションアグリーメントの隣の「新規」ボタンをクリックします。

「レプリケーションアグリーメント」ダイアログが表示されるので、コンシューマレプリカを含む既存のサーバーをメニューから選択するか、「その他」ボタンをクリックして新たに定義します。

「その他」ボタンをクリックしたときは、コンシューマサーバーの完全修飾名と LDAP ポート番号を入力します。そのポートで SSL を使用しているときは、セキュリティ保護されたポートのチェックボックスを選択し、安全な接続によるレプリケーションの更新を有効にします。

コンシューマサーバー上のレプリケーションマネージャエントリの DN とパスワードを入力します。デフォルトでは、デフォルトレプリケーションマネージャの DN が指定されます。

セキュリティ保護されたポートを持つコンシューマを選択したときは、「オプション」ボタンをクリックして、「DN」フィールドの内容が示す意味を指定できます。パスワードを使った接続では、サプライヤは簡単な認証と、暗号化された SSL 接続を経由する通信を利用します。証明書を使った接続では、「DN」フィールドの内容は証明書を含むエントリの DN を意味し、パスワードは必要ありません。

必要に応じて、このアグリーメントの説明文を入力します。コンシューマサーバーの名前とポート番号、説明文は、このマスターレプリカのレプリケーションアグリーメントリストに表示されます。

設定が完了したら「了解」をクリックします。設定した接続パラメータをテストするかどうかを確認するダイアログが表示されます。

指定したレプリケーションマネージャとパスワードを使用して指定のサーバーとポート番号への接続をテストするときは、「はい」をクリックします。接続に失敗した場合でも、そのアグリーメントを使う設定を維持できます。これは、たとえばパラメータに問題はないが、サーバーがオフラインである場合などに有効です。

設定が完了すると、このマスターレプリカのレプリケーションアグリーメントリストにアグリーメントが表示されるようになります。

レプリケーションアグリーメントを編集して、コンシューマサーバー上のレプリケーションマネージャの DN とパスワードをあとから変更できます。

リストからレプリケーションアグリーメントを選択し、「編集」ボタンをクリックします。

「レプリケーションアグリーメント」ダイアログで、「接続」タブを選びます。

コンシューマサーバー上のレプリケーションマネージャの DN またはパスワードを編集します。

必要に応じて、このアグリーメントの説明文を編集します。

「了解」をクリックして新しい設定を保存し、このコンシューマに更新を送信すると、ただちにそのアグリーメントが使用されます。

その他のタブの設定パラメータについては、「部分レプリケーションの有効化」と「WAN を経由するレプリケーション」を参照してください。

必要なレプリケーションアグリーメントを作成したら、このサフィックスの部分レプリケーションを設定し、レプリカをただちに初期化することもできます。詳細は、「レプリカの初期化」を参照してください。

部分レプリケーションの設定

デフォルトでは、レプリケートされるサフィックスに含まれるすべてのエントリがコンシューマレプリカにコピーされます。部分レプリケーション機能を使うことで、レプリケーション時にコピーの対象に含める、またはコピーの対象から除外する属性のサブセットを指定できます。部分レプリケーションはレプリケーションアグリーメントに設定されるので、マスターのコンシューマレプリカごとに属性セットを定義できます。これにより、配信するデータを制御し、レプリケーションの帯域幅とコンシューマリソースをより効率的に利用できます。

たとえば、photo、jpegPhoto、audio のように一般に値が大きい属性のレプリケーションを除外することで、レプリケーションの帯域幅を節約できます。この場合、コンシューマではこれらの属性を利用できなくなります。また、認証に必要な uid 属性と userpassword 属性だけをコンシューマサーバーにレプリケートすることもできます。

部分レプリケーションに関する注意点

属性の部分的なセットを有効化または変更するには、コンシューマレプリカを初期化し直す必要があります。このため、配備前に部分レプリケーションの必要性を検討し、レプリケーションを初期化する前に属性セットを設定しておく必要があります。

ACI、ロール、CoS などの複雑な機能が特定の属性に依存する小規模な属性セットをレプリケートするときは、慎重な対応が必要です。ACI、ロール、CoS の各メカニズムの指定子やフィルタで参照されるその他の属性がレプリケートされない場合、データのセキュリティが損なわれたり、検索時に異なる属性セットが返されることがあります。レプリケーションの対象に含める属性のリストを管理するよりも、除外する属性のリストを管理する方法が安全であり、人的なミスも少なくなります。

レプリケートするすべてのエントリがスキーマに準拠しない属性セットをレプリケートするときは、コンシューマサーバーのスキーマチェックを無効にする必要があります。スキーマに準拠しないエントリをレプリケートしても、レプリケーションメカニズムはコンシューマ上でのスキーマチェックを行わないため、エラーは発生しません。しかし、スキーマに準拠しないエントリがコンシューマに含まれるようになるので、クライアントにとって一貫した状態にする必要があるためスキーマチェックを無効にする必要があります。

部分レプリケーションは、ハブと専用コンシューマに関連するマスターレプリカのレプリケーションアグリーメントに設定します。マルチマスターレプリケーション環境の 2 つのマスターレプリカ間での部分レプリケーションは設定できません。また、複数のマスターが同じレプリカとの間でレプリケーションアグリーメントを持つ場合、同じ属性セットをレプリケートするようにすべてのアグリーメントを設定する必要があります。

Directory Server 5.2 の部分レプリケーション機能は、Directory Server の従来のバージョンとの逆互換性を持ちません。部分レプリケーションアグリーメントを設定するときは、マスターレプリカとコンシューマレプリカの両方が Directory Server バージョン 5.2 のインスタンス上に存在する必要があります。

属性セットの定義

属性セットは、部分レプリケーションがレプリカで有効になった場合にレプリケートされる属性のリストで、リストに含まれない属性はレプリケートされません。マスターサーバーには任意の数の属性セットを設定することができ、その属性セットのどれかをレプリケーションアグリーメントに関連づけます。

Directory Server コンソールの最上位の「設定」タブで「データ」ノードを選び、右側のパネルで「レプリケーション」タブを選びます。

「レプリケーション」タブの下部にある「レプリケートされた属性のセットを管理」ボタンをクリックします。このボタンを表示するには、スクロールが必要なこともあります。

「追加」をクリックして新しい属性セットを定義するか、リストから既存の属性セットを選び、「編集」をクリックして内容を変更します。「属性セット」ダイアログが表示されるので、レプリケートする列のチェックボックスを使用して属性をセットに加えたり、セットから除外したりします。名前の隣にチェックマークが表示された属性がレプリケートされます。

デフォルトでは、すべての属性が選択されています。レプリケートを避ける具体的な理由のある属性だけの選択を解除することをお勧めします。最初から設定し直すときは、「すべてをチェック」ボタンをクリックすると、すべての属性が選択されます。多数の属性の選択を解除した場合、Directory Server は選択が解除された属性以外のすべての属性をレプリケートします。あとから新しい属性をスキーマに定義し、レプリケートされたエントリでそれを使用する場合、属性セットを編集して選択を解除するまで、これらの新しい属性はレプリケートされます。

「チェックしない」ボタンをクリックすると、すべての属性の選択が解除されるので、セットに含める属性 (レプリケートする属性) だけを選択できます。「チェックしない」ボタンをクリックしてから属性セットを定義した場合、選択した属性だけがレプリケートされます。あとから新しい属性をスキーマに定義し、レプリケートされたエントリでそれを使用する場合、属性セットを編集してその属性を選択するまで、これらの新しい属性はレプリケートされません。



注	objectClass、nsUniqueId、nsDS50ruv の各属性と RDN ネーミング属性は、属性セットの定義に関係なくレプリケートされます。これは、objectClass 属性とネーミング属性は LDAP の修正に必要であり、nsUniqueId 属性と nsDS50ruv 属性はレプリケーションを正常に行うために必要なためです。 ACI 属性をレプリケーションの対象から除外すると、コンシューマレプリカでのアクセス制御に影響が生じます。userPassword 属性を除外した場合、コンシューマレプリカにアクセスするすべてのユーザーを認証できなくなります。

必要に応じて、属性セットの説明文を入力または変更します。この文章は、このセットを使用するレプリケーションアグリーメントの編集時に、定義されているセットとともにリスト表示されます。説明文を入力しない場合、含まれるか、除外される属性に基づいてサーバーが説明を自動的に生成します。

処理が終了したら、「保存」をクリックします。

部分レプリケーションの有効化

部分レプリケーションは、既存のレプリケーションアグリーメントだけで有効にできます。

「レプリケーションアグリーメントの作成」の説明に従ってレプリケーションアグリーメントを作成するか、すでに定義されているアグリーメントを選択して変更します。

「レプリケーションアグリーメントの無効化」の説明に従って、レプリケーションアグリーメントを無効にします。部分レプリケーションの設定を変更するときは、アグリーメントを無効にする必要があります。

無効にしたアグリーメントを選び、「編集」をクリックします。「レプリケーションアグリーメント」ダイアログが表示されるので、「レプリケートされた属性」タブを選びます。

「属性のセットのみレプリケート」チェックボックスを選びます。

ドロップダウンリストから既存の属性セットを選ぶか、「新規」をクリックし、「属性セットの定義」の説明に従って新しい属性セットを定義します。「レプリケートされた属性のセットを管理」をクリックして既存のセットの定義を表示し、それを編集することもできます。

部分レプリケーションでは、レプリケーションアグリーメントに関連づけることができる属性セットは 1 つだけです。このセットには、レプリケートする属性だけで構成されたリストを含める必要があります。

属性セットを選んだら、「了解」をクリックします。部分レプリケーションの設定を変更したため、コンシューマレプリカを初期化し直す必要があることを示すメッセージが表示されます。「了解」をクリックすると、メッセージは消えます。

「有効」をクリックして、レプリケーションアグリーメントを有効な状態に戻します。

レプリケートする属性によっては、コンシューマサーバーで実行されるスキーマチェックを無効にする必要があります。

他のマスターがこのレプリカとの間にレプリケーションアグリーメントを持つ場合、そのすべてにおいて同じ手順を繰り返し、同じ属性セットによる部分レプリケーションを有効にする必要があります。

次に、コンシューマレプリカを初期化するか、すでにレプリケートされていた場合は再初期化します。次の「レプリカの初期化」を参照してください。

レプリカの初期化

レプリケーションアグリーメントを作成したら、レプリケーションを実際に開始する前にコンシューマレプリカを初期化する必要があります。初期化時は、サプライヤレプリカからコンシューマレプリカにデータが物理的にコピーされます。

特定のエラーが発生した場合、または設定を変更した場合は、レプリカを初期化し直す必要があります。初期化し直したときは、コンシューマ側のレプリケートされたサフィックスは削除され、マスター側のサフィックスの内容に置き換えられます。これにより、レプリカの同期が確保され、レプリケーションの更新が再開されます。また、ここで説明するどの方法で初期化を行なっても、コンシューマレプリカのインデックスは自動的にふたたび作成されるため、クライアントからの読み取り要求にもただちに正しく対応できます。

初期化のタイミング

レプリカの初期化は、関連する両方のレプリカの設定が完了したあとで、レプリケーションを開始する前に行う必要があります。サフィックスに含まれるデータ全体がコンシューマにコピーされると、サプライヤはコンシューマに対する更新処理を開始します。

通常の運用では、コンシューマを初期化し直す必要はありません。しかし、何らかの理由で 1 つのマスターレプリカをバックアップから復元した場合、そのレプリカが更新するすべてのレプリカを初期化し直す必要があります。マルチマスターレプリケーションでは、他のマスターによって更新されたコンシューマであれば、初期化し直す必要がない場合もあります。

コンソールを使用してレプリカをオンラインで初期化するか、コマンド行を使用して手動で初期化できます。コンソールを使ったオンライン初期化は、少数のコンシューマを初期化する場合に便利です。レプリケーションアグリーメントからレプリカを直接オンラインで初期化できます。ただし、この方法ではレプリカは 1 つずつ初期化されるため、多数のレプリカを処理する場合には適していません。コマンド行を使った手動による初期化は、1 つの LDIF ファイルから多数のコンシューマを同時に初期化できるので、多数のコンシューマを初期化する場合に効果的です。

最後に、経験が豊富な管理者であれば、バイナリコピー機能を利用することで、マスターレプリカまたはコンシューマレプリカのクローンを作成できます。この機能にはある種の制限が適用されるため、処理時間の短縮を見込めるのは、たとえば百万件単位のエントリを含むレプリカなど、大容量のデータベースファイルを持つレプリカだけです。

マルチマスターレプリケーションにおけるレプリカの初期化

マルチマスターレプリケーションの場合、次の順序でレプリカを初期化する必要があります。

1 つのマスターが、レプリケーション対象の完全なデータセットを保持していることを確認します。その他の各マスターのレプリカを初期化するには、このマスターを使います。

それぞれのマスターから (「オンラインでのレプリカ初期化の実行」を参照)、またはいずれかのマスターの LDIF ファイルから (「LDIF ファイルへのレプリカのエクスポート」を参照) コンシューマレプリカを初期化します。

カスケード型レプリケーションでのレプリカの初期化

カスケード型レプリケーションの場合、常に次の順序でレプリカを初期化する必要があります。

マルチマスターレプリケーションとの組み合わせでは、1 つのマスターが、レプリケーション対象の完全なデータセットを保持していることを確認します。その他の各マスターのレプリカを初期化するには、このマスターを使います。

それぞれのマスターレプリカから、最初の階層のハブレプリカに属するレプリカを初期化します。

ハブの構成が複数の階層に分かれている場合、各階層を上から順に初期化していきます。

最後の階層のハブレプリカから専用コンシューマのレプリカを初期化します。

マルチマスター初期化後のマスター間の一致

マルチマスターレプリケーションでは、あるマスターの初期化中に他のマスターが変更を処理することもあります。このため、初期化が完了した時点で、新しいマスターは初期化データに含まれていなかった新しい更新を受け取る必要があります。初期化には時間がかかるため、その間に発生する未適用の更新の数も問題となります。

これらの未適用更新が適用されるように、新たに初期化されたマスターは、初期化後、クライアント側からの操作に対して自動的に読み取り専用モードに設定されます。(これは、コマンド行から LDIF ファイルを使用して初期化した場合か、バックアップを使用してバイナリコピーを実行した場合のみに当てはまる) これは、Directory Server 5.2 の新機能です。

したがって、マルチマスター設定の初期化後のマスターは、レプリケーションの更新を処理し、クライアントからの読み取り操作を受け付けますが、すべての書き込み操作に対してはリフェラルを返します。リフェラルは、「マルチマスターの詳細設定」で説明されている手順に従って定義できます。マスターのモードは、次の場合に読み書きモードに変わります。

ds5BeginReplicaAcceptUpdates 設定属性を start に設定し、更新の受け付けを明示的に可能にします。更新の受け付けを有効にする前に、新しいマスターレプリカの内容が他のマスターと一致していることを確認する必要があります。確認には、Directory Server コンソールのレプリケーション設定パネル、またはコマンド行 (後述する手順を参照) を使います。

事前に ds5referralDelayAfterInit 属性が設定されている場合、所定の時間が経過したあとにマスターレプリカは自動的に読み書きモードに切り替わります。この属性は、サーバー情報のマスターレプリカごとに設定できます。

この属性を設定するときは、初期化後に新しいマスターレプリカが内容を他のマスターと一致するために必要な時間を考慮する必要があります。この処理に要する時間は、予定される初期化の規模と所要時間、およびその他のマスターで並行して行われる更新の頻度によって異なります。初期化後、マスターが更新をレプリケートしている最中に新たな更新を受け付けた場合、予期せぬエラーが発生することがあります。レプリケーションエラーが発生したときは、『Directory Server Administration Reference』の第 8 章にある「Error Log Message Reference」を参照してください。



注	この新しい対応方法によってマスターレプリカがリフェラルを送信する場合、書き込み処理を待機しているクライアントのホップ回数が、制限回数に達してしまうことも考えられます。利用可能なマスターにアクセスできるように、クライアントのホップ制限の設定を変更する必要があるかもしれません。すべてのマスターレプリカを初期化または再初期化するときは、どのレプリカもクライアントからの更新を受け付けられないため、すべての書き込み処理が失敗します。サーバーの応答を最大化するには、いかなる場合も初期化したマスターを注意深く監視し、リフェラルの属性を適切に設定する必要があります。

コンソールによる更新の受け付け開始

マルチマスターレプリカの初期化後に、更新の受け付けを明示的に開始する手順は、次のとおりです。

Directory Server コンソールの最上位の「設定」タブで、「データ」ノードを展開し、レプリケートされたサフィックスのノードを展開し、サフィックスの下の「レプリケーション」ノードを選択します。

レプリカが初期化され、現時点では更新処理に対してリフェラルを返していることを示すメッセージが右側のパネルに表示されます。自動的なリフェラル遅延が有効であることを示すメッセージが表示される場合でも、この手順を使用して自動遅延の代わりに受け付けの開始を明示的に指定できます。

insync ツールを使用して、レプリカの状態が他のすべてのマスターと一致していることを確認します。すべてのサーバーで変更の遅れがゼロである場合、またはそのレプリカに適用する更新がなかった場合 (遅れが -1 となる場合) は、すべてのレプリカが同期しています。詳細については、『Directory Server Administration Reference』の第 1 章にある「insync」を参照してください。

メッセージの右にあるボタンをクリックして、ただちに更新の受け付けを開始します。

コマンド行による更新の受け付け開始

マルチマスターレプリカの初期化プロセスを自動化するスクリプトで、次のコマンドを実行することができます。このコマンドは、マスターレプリカ間の一致を確認し、更新の受け付けを明示的に有効にします。

次のコマンドを使用して ds5BeginReplicaAcceptUpdates 設定属性を変更します。

ldapmodify -h host -p port -D "cn=Directory Manager" -w password
dn: cn=replica, cn=suffixName, cn=mapping tree, cn=config
changetype:modify
add:ds5BeginReplicaAcceptUpdates
ds5BeginReplicaAcceptUpdates:start
^D

レプリカの初期化が完了すると ds5BeginReplicaAcceptUpdates は自動的に削除されるので、次回の初期化後は更新処理の受け付けは拒否されます。

自動リフェラル遅延の設定

ds5ReferralDelayAfterInit 設定属性は、初期化後に何秒間レプリカがリフェラルを返すかを決定します。この時間が経過すると、レプリカは自動的にクライアントからの更新処理を受け付けるようになります。この属性は各レプリカに固有の設定です。「マルチマスター初期化後のマスター間の一致」で説明されている条件に基づいて値を設定してください。

この属性の値の変更は、初期化され、まだ更新を受け付けていないレプリカにダイナミックに適用されます。この値を変更することで、遅延時間を延長または縮小できます。遅延時間が経過し、レプリカが更新処理の受け付けを開始したあとに属性の設定を変更しても、レプリカは影響を受けません。

この属性のデフォルト値は -1 で、レプリカは無期限に更新処理を拒否します。この場合、遅延時間を設定することで、初期化からこの時間が経過した時点で自動的に更新処理を許可できます。すでに経過している時間を遅延時間に設定すると、レプリカは更新をただちに受け付けます。

ds5ReferralDelayAfterInit 属性に次のコマンドを設定します。

ldapmodify -h host -p port -D "cn=Directory Manager" -w password
dn: cn=replica, cn=suffixName, cn=mapping tree, cn=config
changetype:modify
replace: ds5ReferralDelayAfterInit
ds5ReferralDelayAfterInit: seconds
^D

コンソールによるレプリカの初期化

コンソールを使ったオンラインでのレプリカの初期化は、コンシューマの初期化と再初期化でもっとも簡単な方法です。ただし、多数のエントリ (100 ～ 200 万) を初期化する場合、処理に時間がかかるため、コマンド行を使用した手動によるコンシューマの初期化の方が効果的なこともあります。詳細は、「コマンド行によるレプリカの初期化」を参照してください。

コンソールを使用してコンシューマレプリカを初期化している最中は、レプリカに対するすべての処理 (検索を含む) は初期化のプロセスが完了するまでマスターサーバーを参照します。

Directory Server コンソールを使った場合、部分レプリケーションが設定されたレプリカの初期化は透過的に行われます。初期化時に、選択されている属性だけがコンシューマに送られます。

オンラインでのレプリカ初期化の実行

コンソールを使用してレプリカを初期化または再初期化する手順は、次のとおりです。

Directory Server コンソールの最上位の「設定」タブで、「データ」ノードを展開し、マスターレプリカサフィックスのノードを展開し、サフィックスの下の「レプリケーション」ノードを選択します。

右側のパネルにレプリカのステータス情報が表示されます。

定義されているレプリケーションアグリーメントのリストから、初期化するコンシューマに対応するアグリーメントを選び、「アクション」>「リモートレプリカを初期化」の順にクリックします。

コンシューマ上のレプリカに格納されている情報がすべて削除されるという確認メッセージが表示されます。

確認ボックスで「はい」をクリックします。

オンラインコンシューマの初期化がただちに開始されます。レプリケーションアグリーメントのアイコンが赤いギアとなり、初期化プロセスの状態を示します。

「再表示」>「ただちに再表示」の順にクリックするか、「再表示」>「継続して再表示」の順にクリックして、コンシューマ初期化の状態を監視します。

強調表示されているアグリーメントに関するメッセージが、リストの下のテキストボックスに表示されます。

コマンド行によるレプリカの初期化

コマンド行を使用して手動でレプリカを初期化する方法は、多数のエントリのレプリケーションが必要な導入で、コンシューマを初期化するにはもっとも速い方法です。パフォーマンス上の制約からオンラインプロセスが適切でないと判断する場合は、手動プロセスを使用してください。ただし、手動によるコンシューマの初期化は、オンラインでのコンシューマ初期化と比べてプロセスが複雑です。

レプリカを手動で初期化または再初期化するには、まず、オリジナルのサフィックスデータのコピーを LDIF ファイルにエクスポートします。部分レプリカを初期化するときは、ファイルをフィルタリングして、レプリケートされる属性だけを確保する必要があります。次に、そのファイルをすべてのコンシューマサーバーに転送し、それをインポートします。マルチマスターレプリケーションの導入では、オリジナルマスターからエクスポートした LDIF ファイルを使用して他のマスターとコンシューマの両方を初期化できます。カスケード型のレプリケーションでは、同じファイルを使用してハブレプリカとそのコンシューマを初期化できます。

どの場合にも、設定が完了しているマスターレプリカからエクスポートした LDIF ファイルから開始する必要があります。これ以外の任意の LDIF ファイルにはレプリケーションデータが含まれないため、これを使用してすべてのレプリカを初期化することはできません。最初に LDIF ファイルをマスターレプリカにインポートし、次の手順でそれをエクスポートする必要があります。

LDIF ファイルへのレプリカのエクスポート

レプリカの内容を LDIF ファイルに格納するには、db2ldif -r コマンドまたは db2ldif-task -r コマンドを使います。詳細は、「コマンド行からの LDIF へのエクスポート」を参照してください。これらのコマンドを使用してレプリカをエクスポートするときは、-r オプションを指定する必要があります。

次の例は、dc=example,dc=com レプリカ全体を example_master.ldif というファイルにエクスポートします。

次に、必要に応じて LDIF ファイルをフィルタリングし、それをコンシューマホストに転送して、コンシューマレプリカを初期化します。

部分レプリケーションのための LDIF ファイルのフィルタリング

	# /usr/sbin/directoryserver -s example stop # /usr/sbin/directoryserver db2ldif -r -s "dc=example,dc=com" ¥ -a /var/ds5/slapd-serverID/ldif/example_master.ldif # /usr/sbin/directoryserver -s example start

部分レプリケーションを設定したときは、エクスポートした LDIF ファイルをコンシューマサーバーにコピーする前に、不要な属性をフィルタリングする必要があります。この処理を行うために、Directory Server には fildif というツールが用意されています。このツールは、指定した LDIF ファイルをフィルタリングし、レプリケーションアグリーメントに定義されている属性セットが許可する属性だけを残します。

このツールはサーバーの設定を読み取り、属性セットの定義を決定します。設定ファイルの読み取りが必要になるため、fildif ツールをルートとして実行するか、プロセスおよびファイルを所有するユーザーとして実行する必要があります (nsslapd-localuser 属性によって指定)。たとえば、次のコマンドは、前の例で dc=example,dc=com サフィックスからエクスポートされたファイルをフィルタリングします。

# CAMUS=/var/opt/mps/serverroot/slapd-camus
# /var/opt/mps/serverroot/shared/bin/fildif ¥
-i $CAMUS/ldif/example_master.ldif ¥
-o $CAMUS/ldif/filtered.ldif -c $CAMUS/config/dse.ldif ¥
-b "cn=rousseau.example.com:389, cn=replica, ¥
cn=¥"dc=example,dc=com¥", cn=mapping tree, cn=config"

-i オプションと -o オプションは、それぞれ入力ファイルと出力ファイルです。-c オプションは、レプリケーションアグリーメントと属性セットの定義を含む設定ファイルです。サーバーは、cn=config エントリの内容を dse.ldif ファイルに格納します。レプリケーションアグリーメントと属性セットもこれに含まれます。

-b オプションは、部分レプリケーションが定義されているレプリケーションアグリーメントの DN です。このエントリを見つけるには、Directory Server コンソールで Directory Manager として cn=config サフィックスを参照します。サフィックスの cn=replica エントリの下のエントリを選び、メニューから「編集」>「DN のコピー」の順に選んで、この DN をクリップボードにコピーします。コマンドを入力するときは、この情報を使います。

fildif ツールの完全なコマンド行構文は、『Directory Server Administration Reference』の第 1 章にある「fildif」を参照してください。

fildif ツールを使用して作成した filtered.ldif ファイルを使用して、このレプリケーションアグリーメントの対象となるコンシューマを初期化できます。ファイルをコンシューマサーバーに転送し、次に説明する手順に従ってインポートします。

コンシューマレプリカへの LDIF ファイルのインポート

マスターレプリカの内容が含まれている LDIF ファイルをコンシューマレプリカにインポートするには、Directory Server コンソールのインポート機能を使用するか、directoryserver ldif2db コマンドまたは directoryserver ldif2db-task コマンドを使用します。その他すべてのインポート処理と同様に、インポートを行うには、Directory Manager のバインド DN とパスワードをコマンドに指定する必要があります。これらのインポート方法については、「コマンド行からの LDIF のインポート」を参照してください。

次の例は、LDIF ファイルをインポートして、dc=example,dc=com コンシューマレプリカを初期化する方法を示しています。

	# /usr/sbin/directoryserver -s example stop # /usr/sbin/directoryserver ldif2db -s "dc=example,dc=com" ¥ -i example_master.ldif # /usr/sbin/directoryserver -s example start

ldif2db-task コマンドを使う場合、事前にサーバーを停止する必要はありません。詳細については、『Directory Server Administration Reference』の第 1 章にある「ldif2db-task」を参照してください。

バイナリコピーによるレプリカの初期化

バイナリコピー機能は、1 つのサーバーのバイナリバックアップファイルを使用して、別のサーバー上の同じディレクトリの内容を復元することで、サーバー全体のクローンを作成します。この高度な機能では、Directory Server 上のデータベースファイルとの間で情報をやり取りします。この機能は、経験が豊富な管理者以外は使用しないでください。

バイナリコピーの制限

バイナリコピー機能は、あるマシンから別のマシンにデータベースファイルを移動するため、次の制限が厳密に適用されます。

両方のマシンが同じハードウェア、同じオペレーティングシステム (サービスパックやパッチも含まれる) を使用している必要がある

両方のマシンに同じバージョンの Directory Server (バイナリ形式 (32 ビットまたは 64 ビット)、サービスパック、パッチも含まれる) がインストールされている必要がある

両方のサーバーは、同じサフィックスに分岐する同じディレクトリツリーを持つ必要がある。すべてのサフィックスのデータベースファイルを一度にコピーすることが必要で、サフィックスを個別にコピーすることはできない

両方のサーバーの各サフィックスには同じインデックス (VLV (仮想リスト表示) インデックスも含まれる) が設定されている必要がある。サフィックスのデータベースの名前は同じである必要がある

コピーする Directory Server には o=NetscapeRoot サフィックスを含めることはできない。つまり、Directory Server を管理サーバーの設定ディレクトリにすることはできない

各サーバーでは、同じサフィックスがレプリカとして設定されている必要があり、両方のサーバーでレプリカに同じ役割 (マスター、ハブ、コンシューマ) が設定されている必要がある。部分レプリケーションが設定されている場合は、すべてのサーバーが同じように設定されている必要がある

どちらのサーバーでも、属性の暗号化を使用していてはならない

属性値の一意性プラグインが有効な場合は、両方のサーバーで設定を共通させる。また、次に説明する手順で、新しいコピーを設定し直す必要がある

上の条件を満たす環境では、別のマスターサーバーのバイナリコピーからマスターを初期化または再初期化したり、別のコンシューマサーバーのバイナリコピーからコンシューマを初期化または再初期化したりできます。次の 2 つの手順は、バイナリコピーの実行方法を示しています。一つはサーバーを停止せずに行う方法で、もう一つはディスクスペースの消費を最小限に抑える方法です。

サーバーの停止を必要としないバイナリコピー

次の手順は、通常のバックアップ機能を使用してサーバーのデータベースファイルのコピーを作成するので、バイナリコピーを実行するときは、この方法をお勧めします。通常のバックアップを実行することで、サーバーを停止しなくても、すべてのデータベースファイルを一定の状態に維持できます。

ただし、この手順には注意を要する制限があります。バックアップと復元の処理によって、同じマシンにデータベースファイルのコピーが作成されるため、各マシンでこれらのファイルが占有するディスクスペースの容量が 2 倍になります。また、これらのファイルに対する実際のコピー処理は、ディレクトリに G バイト単位のデータが含まれる場合、時間がかかります。ディスクスペースが限られていたり、データベースファイルのサイズが極端に大きい場合の対応については、「ディスクスペースの消費量を最小限に抑えるバイナリコピー」を参照してください。

新しいレプリカのターゲットマシンに Directory Server をインストールし、必要に応じてサーバーの新しいインスタンスを作成します。次に、「バイナリコピーの制限」に従ってインスタンスを設定します。

このレプリカに関連するレプリケーショントポロジにすべてのレプリケーションアグリーメントを作成します。これには、サプライヤからこのレプリカへのアグリーメントも含まれ、専用コンシューマ以外では、このレプリカから各コンシューマへのアグリーメントも含まれます。

初期化するレプリカと同じ種類 (マスター、ハブ、コンシューマのどれか) の、完全に設定され、初期化されたレプリカを選択し、「コンソールを使用したサーバーのバックアップ」の手順に従って通常のバックアップ処理を行います。

バックアップディレクトリからターゲットマシンのディレクトリにファイルをコピーまたは転送します。この操作には、ftp コマンドなどを使います。

「バックアップからのデータの復元」の手順に従って、ファイルをターゲットサーバーにロードします。

マルチマスターレプリケーションの新しいマスターを初期化したときは、「マルチマスター初期化後のマスター間の一致」の手順に従って、新しいレプリカがクライアントからの更新処理を受け付けるように設定します。

ディスクスペースの消費量を最小限に抑えるバイナリコピー

次の手順では、データベースファイルのバックアップコピーを作成しないため、ディスクスペースの消費が少なく、処理に要する時間も少なくなります。ただし、データベースファイルを一貫した状態に保つため、クローン作成の対象となるサーバーを停止する必要があります。


警告	マルチマスターレプリケーションにすでに組み込まれているマスターの再初期化に、この手順を使うことはできません。この手順を利用できるのは、コンシューマサーバーの再初期化、または新しいマスターサーバーの初期化だけです。既存のマスターレプリカを再初期化するときは、オンラインによる初期化を行い、LDIF ファイルをインポートするか、「サーバーの停止を必要としないバイナリコピー」の手順を実行します。

「Directory Server の起動と停止」の説明に従って、初期化または再初期化するサーバーを停止します。

初期化するレプリカと同じ種類 (マスター、ハブ、コンシューマのどれか) の、完全に設定され、初期化されたレプリカを選択し、このサーバーも停止します。マルチマスター設定に組み込まれているマスターレプリカのクローンを作成するときは、それを停止する前に、その他のマスターから最新のすべての変更が完全に反映されていることを確認する必要があります。

トランザクションログ、更新履歴ログ、地域ファイル (__db.xxx ファイル) など、すべてのデータベースファイルをターゲットサーバーから削除します。ファイルの位置を変更していない限り、データベースファイルとトランザクションログは ServerRoot/slapd-serverID/db ディレクトリに保存されています。

トランザクションログを含むすべてのデータベースファイルをソースレプリカマシンからターゲットマシンにコピーまたは転送します。この処理には、ftp コマンドなどを使います。ファイルの位置を変更していない限り、データベースファイルとトランザクションログは ServerRoot/slapd-serverID/db ディレクトリに保存されています。

マスターレプリカまたはハブレプリカを初期化するときは、更新履歴ログに記録されているすべてのファイルもコピーする必要があります。更新履歴ログは、デフォルトでは ServerRoot/slapd-serverID/changelog ディレクトリにあります。

ソースサーバーとターゲットサーバーの両方を再起動します。

参照整合性プラグインの有効化

参照整合性プラグインを使用している場合、すべてのマスターサーバーでそれを有効にする必要があります。ハブサーバーまたはコンシューマサーバー上のプラグインを有効にする必要はありません。詳細は、「レプリケーションにおける参照整合性の使用」を参照してください。

SSL を経由するレプリケーション

すべてのレプリケーション操作が SSL 接続を経由するように、レプリケーションに関連する Directory Server を設定できます。この設定を行う手順は、次のとおりです。

サプライヤサーバーとコンシューマサーバーの両方を、SSL を使用するように設定します。

詳細は、第 11 章「認証と暗号化の管理」を参照してください。



注	サプライヤサーバー証明書が、SSL ハンドシェイク時にクライアントとして機能できない SSL サーバー専用証明書である場合、SSL を経由するレプリケーションは失敗します。 SSL を経由するレプリケーションは、現在のところ自己署名の証明書をサポートしていません。

コンシューマサーバー上のサフィックスにレプリケーションが設定されていない場合、「コンシューマレプリカの有効化」の説明に従って、そのサフィックスを有効にします。

「コンシューマの詳細設定」の手順に従って、コンシューマの証明書エントリの DN を別のレプリケーションマネージャとして定義します。

サプライヤサーバー上のサフィックスにレプリケーションが設定されていない場合、「ハブレプリカの有効化」または「マスターレプリカの有効化」の説明に従って、そのサフィックスを有効にします。

サプライヤサーバーで新しいレプリケーションアグリーメントを作成し、セキュリティ保護された SSL ポート上のコンシューマに更新を送信します。詳細な方法については、「レプリケーションアグリーメントの作成」を参照してください。セキュリティ保護されたポートをコンシューマサーバーに設定し、パスワードまたは証明書のどちらを使うかについて、SSL オプションを選択します。選択した SSL オプションの DN (レプリケーションマネージャまたは証明書) を入力します。

レプリケーションアグリーメントの設定が完了すると、サプライヤはすべてのレプリケーション更新メッセージを SSL 経由でコンシューマに送信します。証明書を使用するオプションを選んだ場合は、証明書が利用されます。SSL のアグリーメント設定を使用してコンソールからカスタマーの初期化を行う場合も、セキュリティ保護された接続が使われます。

WAN を経由するレプリケーション

Directory Server 5.2 では、広域ネットワーク (WAN) に接続されたマシン間のマルチマスターレプリケーション (MMR) を含め、あらゆる種類のレプリケーションを行えます。レプリケーションメカニズムを内部的に見直したことで、応答時間が遅く、帯域幅の狭いネットワークでも、妥当な遅延でサプライヤサーバーがコンシューマを初期化、更新できるようになりました。



注	レプリケーションデータの転送率は、使用可能な物理媒体が帯域幅に関して許可している転送率を常に下回ります。レプリカ間の更新量を使用可能な帯域幅と物理的に適合させることができない場合、更新負荷が大きくなったときにレプリカ間に差異が生じることを、チューニングによって回避できなくなります。レプリケーションの遅延と更新パフォーマンスは、修正頻度、エントリのサイズ、サーバーハードウェア、平均応答時間、平均帯域幅など、多くの要因に左右されます。利用環境でのレプリケーションについて疑問がある場合は、Sun Professional Service の担当者に連絡してください。

デフォルトでは、レプリケーションメカニズムの内部パラメータは WAN に合わせて最適化されています。ただし、前述の要因などが原因でレプリケーションが遅くなるときは、ウィンドウサイズとグループサイズのパラメータを調節してみてください。また、ネットワークのピーク時を避けてレプリケーションをスケジュールすることで、ネットワークの全体的な利用率を高めることができます。最後に、Directory Server は、帯域幅の使用を最適化するためにレプリケーションデータの圧縮に対応しています。

ネットワークパラメータの設定

ネットワーク経由でエントリをより効率的に送信するために、レプリケーションメカニズムがエントリをグループ化する方法は、次の 2 つのパラメータによって決定されます。これらのパラメータは、サプライヤとコンシューマがレプリケーション更新メッセージと、その確認応答を交換する方法に影響します。

ウィンドウサイズ (デフォルト値は 10): コンシューマからの即時の確認応答なしに送信できる更新メッセージの最大数を表します。

各コンシューマからの確認応答を待機するよりも、短時間に連続して多数のメッセージを送信する方が効果的です。適切なウィンドウサイズを使用することで、レプリケーション更新や確認応答の到着を待機するためにレプリカが費やす時間を排除できます。

コンシューマレプリカがサプライヤよりも遅れている場合、詳細な調整を行う前に、ウィンドウサイズをデフォルトよりも大きい数字 (100 など) に設定して、レプリケーションのパフォーマンスをもう一度確認してみます。レプリケーションの更新頻度が高く、更新間隔が短い場合、LAN 接続されたレプリカでもウィンドウサイズを大きくすることでパフォーマンスが向上する可能性があります。

グループサイズ (デフォルト値は 1): 1 つの更新メッセージに入れることのできるデータ修正の最大数を表します。

ネットワーク接続がレプリケーションのボトルネックとなっているように思われる場合、グループサイズをデフォルトよりも大きい数字 (10 など) に設定して、レプリケーションのパフォーマンスをもう一度確認してみます。グループサイズを大きくする場合には、次の点に注意します。

ウィンドウサイズがグループサイズよりも大幅に大きい数字に設定されていること

ウィンドウサイズ / グループサイズの値が、コンシューマの nsslapd-maxThreadsPerConn under cn=config の値よりも大幅に上回っていること (通常は 2 倍)

グループサイズが 1 よりも大きい数に設定されている場合、サプライヤはグループが満たされるのを待たずに、サプライヤに更新を送信します。ただし、送信する更新リストがグループサイズよりも大きい場合、コンシューマが並行で処理できるように個別変更のグループを送信する目的で、サプライヤが機能別にグループ分けします。

この 2 つのネットワークパラメータは、すべてのレプリケーションアグリーメントで設定できます。これにより、各コンシューマのネットワーク状態に応じてレプリケーションパフォーマンスを調節できます。

ウィンドウとグループのサイズパラメータを変更するときに、レプリケーションを中断する必要はありません。

Directory Server コンソールで「設定」タブを選び、「データ」ノードを展開し、レプリケートするサフィックスのノードを展開します。

サフィックスの下の「レプリケーション」ノードを選び、右側のペインで設定するレプリケーションアグリーメントを選んで、「編集」をクリックします。

「レプリケーションアグリーメント」ダイアログの「ネットワーク」タブを選び、ウィンドウサイズの新しい値 (1 ～ 1000) とグループサイズの新しい値 (1 ～ 100) を入力します。グループサイズは、ウィンドウサイズ以下に設定する必要があります。

「了解」をクリックして新しい値を保存し、「レプリケーションアグリーメント」ダイアログを閉じます。

新しいパラメータ値はただちに有効となり、対応するコンシューマに次にレプリケーション更新を送信するときに適用されます。

レプリケーションアクティビティのスケジュール

レプリカ間の即時同期が重要でない場合は、ネットワーク利用率が低い時間帯に更新をスケジュールして、WAN 経由のデータレプリケーションを実行できます。より多くのネットワーク資源を利用できれば、更新はより高速で処理され、ネットワークの利用率がすでに高い場合は、レプリケーションメッセージによってネットワークにそれ以上の負荷がかかることはありません。

レプリケーションアグリーメントを設定することで、コンシューマごとに日次または週次の更新をスケジュールできます。

Directory Server コンソールで最上位の「設定」タブを選び、「データ」ノードを展開し、レプリケートするサフィックスのノードを展開します。

「レプリケーションアグリーメント」ダイアログの「スケジュール」タブを選び、週次スケジュールの隣のラジオボタンを選びます。

スケジュールを定義します。

週次更新では、レプリケーションを行う曜日 (複数を指定できる) の隣のチェックボックスを選択します。各曜日のレプリケーションをさらに細かく指定するときは、時間帯を 24 時間表記で指定します。

日時更新では、「すべて」をクリックしてすべての曜日を選択し、レプリケーションを行う時間帯を 24 時間表記で指定します。

深夜 0 時をまたがる時間帯は設定できません。

「了解」をクリックして新しい値を保存し、「レプリケーションアグリーメント」ダイアログを閉じます。

新しいスケジュールはただちに有効になり、対応するコンシューマに対する次回のレプリケーション更新は、スケジュールされた次回の更新まで行われなくなります。

データの圧縮

レプリケーションで使われる帯域幅を節約するために、コンシューマの更新時に送信されるデータを圧縮するようにレプリケーションを設定できます。レプリケーションメカニズムは、Zlib 圧縮ライブラリを使用します。圧縮を利用するには、Solaris プラットフォームでサプライヤとコンシューマの両方が稼動している必要があります。

レプリケーションの圧縮の設定は、マスターサーバー側のレプリケーションアグリーメントエントリに含まれる ds5ReplicaTransportCompressionLevel 属性だけを使用して行われます。この属性には、次のいずれかの値を指定できます。

各圧縮レベルを実験的に使用し、レプリケーションの用途に合わせて WAN 環境で最適な結果を得られるオプションを選択します。圧縮と解凍のプロセスによってレプリケーション速度が低下するため、遅延があまり問題とならない LAN (ローカルエリアネットワーク) ではこのパラメータを使用しないでください。

たとえば、east.example.com にあるコンシューマに最速圧縮オプションを使用してレプリケーション更新を送信するには、次の ldapmodify コマンドを実行します。

圧縮レベルの設定については、『Directory Server Administration Reference』の第 2 章にある「ds5ReplicaTransportCompressionLevel」を参照してください。

レプリケーショントポロジの変更

ここでは、レプリケーションアグリーメントの編集と削除、レプリカの昇格と降格、無効化、コンシューマの強制更新、更新履歴ログの管理など、既存のレプリケーショントポロジを管理する手順について説明します。

レプリケーションアグリーメントの管理

マスターサフィックスのレプリケーションパネルでは、レプリケーションアグリーメントの設定を変更して、アグリーメントの認証情報の変更、特定のコンシューマに対するレプリケーションの中断、トポロジからのコンシューマの削除を実行できます。

レプリケーションマネージャの変更

レプリケーションアグリーメントを編集して、コンシューマサーバーへのバインドに使われるレプリケーションマネージャの識別情報を変更できます。レプリケーションが中断されないように、レプリケーションアグリーメントを変更する前に、新しいレプリケーションマネージャエントリまたはコンシューマの証明書エントリを定義する必要があります。ただし、バインドの失敗によってレプリケーションが中断された場合、レプリケーション回復設定の制限内でエラーを修正したときは、レプリケーションメカニズムによって必要なすべての更新が自動的に送信されます (「コンシューマの詳細設定」を参照)。

コンシューマの認証に使うレプリケーションマネージャを変更する手順は、次のとおりです。

右側のパネルで変更するレプリケーションアグリーメントを選び、「編集」をクリックします。

「レプリケーションアグリーメント」ダイアログで、「接続」タブを選びます。

ステータス行には、コンシューマサーバーのホスト名とポート番号が表示されます。

DN とパスワードのフィールドを変更します。別のレプリケーションマネージャエントリの DN とパスワードを入力するか、コンシューマサーバー上の証明書エントリの DN を入力します。

このレプリケーションアグリーメントが、セキュリティ保護されたポートで SSL を使用するときは、「オプション」ボタンをクリックして、セキュリティ保護された認証の種類を選択することもできます。パスワードを使った接続では、サプライヤは簡単な認証と指定の DN、および暗号化された SSL 接続による通信を利用します。証明書を使った接続では、「DN」フィールドの内容は証明書エントリの DN を意味し、パスワードは必要ありません。

既存のレプリケーションアグリーメントでセキュリティ保護ありをセキュリティ保護なしに切り替えたり、その反対に切り替えることはできません。別のセキュリティ設定でレプリケーションを有効にするには、別のレプリケーションアグリーメントを作成する必要があります。

「了解」をクリックして、変更を保存します。

レプリケーションアグリーメントの複製

レプリケーションアグリーメントを複製することで、大規模なレプリケーショントポロジでサプライヤレプリカの多数のコンシューマを簡単に設定できます。

レプリケーションアグリーメントのリストから、複製するアグリーメントを 1 つ選択します。コンシューマとの接続をセキュリティ保護する新しいアグリーメントを作成するときは、セキュリティ保護されたポートを使用する既存のアグリーメントを選択する必要があります。セキュリティ保護されていないアグリーメントを新たに作成する場合は、セキュリティ保護されていないアグリーメントを選択する必要があります。

「編集」をクリックして「レプリケーションアグリーメント」ダイアログのタブを表示し、このアグリーメントの設定を確認します。これらのタブで行う設定については、次の各項で説明しています。

「接続」タブについては、「レプリケーションマネージャの変更」を参照してください。

「スケジュール」タブと「ネットワーク」タブについては、「WAN を経由するレプリケーション」を参照してください。

「レプリケートされた属性」タブについては、「部分レプリケーションの設定」を参照してください。

同じレプリケーションアグリーメントを選択した状態で、「複製」ボタンをクリックします。

新しいコンシューマのホスト名とポート番号をリストから選択するか、「ホストを追加」ボタンをクリックして、別のホストとポートを指定します。リストと「ホストを追加」ダイアログでは、複製するコンシューマアグリーメントと同じ種類のセキュリティ (セキュリティ保護あり、またはなし) が設定されたコンシューマだけを選択できます。

リストのホスト名が選択されていることを確認し、「了解」をクリックして、そのコンシューマサーバーの新しいレプリケーションアグリーメントを作成します。

新しいアグリーメントには、既存のアグリーメントのすべての設定情報が複製されます。つまり、2 つのサーバーにまったく同じレプリケーションマネージャエントリを定義し、同じパスワードを使用する必要があります。レプリケーションマネージャの DN の変更など、新しいアグリーメントの設定を変更するときは、リストからそのアグリーメントを選択し、「編集」をクリックします。

レプリケーションアグリーメントの無効化

レプリケーションアグリーメントを無効にすると、そのアグリーメントに指定されているコンシューマに対してマスターが更新を送信しなくなります。そのサーバーのレプリケーションは停止されますが、アグリーメントに記録されているすべての設定は残されます。あとからまたアグリーメントを有効にすることで、レプリケーションを再開できます。中断後のレプリケーションメカニズムの再開については、次の「レプリケーションアグリーメントの有効化」を参照してください。

レプリケーションアグリーメントを無効にする手順は、次のとおりです。

右側のパネルで、無効にするレプリケーションアグリーメントを選びます。

アグリーメントのリストの下で、「アクション」>「アグリーメントを無効に」の順に選択します。

「はい」をクリックして、レプリケーションアグリーメントが無効になったことを確認します。

リスト上のアグリーメントのアイコンが変化し、無効になったことを示します。

レプリケーションアグリーメントの有効化

レプリケーションアグリーメントを有効にすると、指定のコンシューマのレプリケーションが再開されます。ただし、レプリケーションの回復設定で許容される時間より長くレプリケーションを中断していた場合は、別のサプライヤによるコンシューマの更新が行われないため、コンシューマを初期化し直す必要があります。レプリケーション回復設定は、このサプライヤの更新履歴ログの最大サイズと有効期限、およびコンシューマのパージ遅延です (「コンシューマの詳細設定」を参照)。

中断時間が短く、レプリケーションが回復された場合は、アグリーメントがふたたび有効になったときに、マスターが自動的にそのコンシューマを更新します。

レプリケーションアグリーメントを有効にする手順は、次のとおりです。

右側のパネルで、有効にするレプリケーションアグリーメントを選びます。

アグリーメントのリストの下にある「有効」ボタンをクリックします。

必要に応じて、コンシューマレプリカを初期化し直します。

レプリケーションアグリーメントの削除

レプリケーションアグリーメントを削除すると、対応するコンシューマのレプリケーションは停止され、アグリーメントに関するすべての設定情報が失われます。あとからレプリケーションを再開する必要があるときは、「レプリケーションアグリーメントの無効化」の説明に従って、アグリーメントを削除せずに無効にします。

レプリケーションアグリーメントを削除する手順は、次のとおりです。

右側のパネルで、削除するレプリケーションアグリーメントを選びます。

アグリーメントのリストの右にある「削除」ボタンをクリックします。

「はい」をクリックして、レプリケーションアグリーメントの削除を確認します。

レプリカの昇格と降格

レプリカの昇格と降格は、レプリケーショントポロジで、レプリカの役割を変更することを意味します。専用コンシューマをハブに変更したり、ハブをマスターに変更したりできます。また、マスターをハブに変更したり、ハブを専用コンシューマに変更したりすることもできます。ただし、マスターを直接コンシューマに格下げしたり、コンシューマを直接マスターに格上げすることはできません。

マルチマスターレプリケーションのメカニズムでレプリカの役割を変更できることで、トポロジがとても柔軟になります。コンシューマレプリカが処理を担当していたサイトの負荷が増え、複数のレプリカを持つハブによる処理が必要になることもあります。レプリカの内容に対して多数の変更が含まれるときは、ハブをマスターに昇格させることで、ローカルな変更に迅速に対応し、その変更を他のサイトの他のマスターにレプリケートできます。

右側のパネルで、メニューから「変更」>「レプリカの昇格と降格」の順に選択します。

レプリケーションウィザードでは、設定できる新しい役割だけを選択できます。次に、そのレプリカの新しい役割について、順に設定を行います。このとき、次の点に注意が必要です。

マスターをハブに降格させると、レプリカは読み取り専用となり、残りのマスターに対してはリフェラルを送信するように設定されます。新しいハブは、設定されているすべてのコンシューマをハブまたは専用コンシューマとして維持します。

シングルマスターレプリケーションでマスターをハブに降格させると、マスターレプリカの存在しないトポロジが作成されます。新しいマスターを定義することを前提として、ウィザードでもこのような変更が可能です。ただし、マスターを降格させる前にマルチマスターとして新しいマスターを追加し、初期化できるようにしておくことをお勧めします。

ハブをコンシューマに降格させると、すべてのレプリケーションアグリーメントは削除されます。そのハブのコンシューマが他のハブまたはマスターによって更新されるように設定されていない場合、そのコンシューマは更新されなくなります。これらのコンシューマが更新されるように、残りのハブまたはマスターに新しいアグリーメントを作成する必要があります。

コンシューマをハブに昇格させると、更新履歴ログが有効になり、コンシューマとの間に新しいアグリーメントを定義できるようになります。

ハブをマスターに昇格させると、レプリカは更新要求を受け付けるようになり、他のマスター、ハブ、または専用コンシューマとの間に新しいアグリーメントを定義できるようになります。

レプリカの無効化

レプリカを無効にすると、そのレプリカはレプリケーショントポロジから除外されます。設定されている役割 (マスター、ハブ、またはコンシューマ) に応じて、そのレプリカは更新されなくなり、更新を送信しなくなります。サプライヤを無効にすると、すべてのレプリケーションアグリーメントが削除されます。そのレプリカをふたたび有効にするときは、これらのアグリーメントを作成し直す必要があります。

右側のパネルで、メニューから「変更」>「レプリケーションを無効に」の順に選択します。

確認ダイアログが表示されるので、「はい」をクリックします。

必要に応じて、このサフィックスの書き込み権限とリフェラルをリセットします。これらの設定は、レプリカを無効にした時点の状態で残されます。たとえば、無効になったコンシューマは、無効になる以前のマスターレプリカに対して更新要求を送信します。

書き込み権限とリフェラルを変更するには、「設定」タブでこのサフィックスのノードを選択し、右側のパネルの「設定」タブで変更を加えます。詳細は、「アクセス権とリフェラルの設定」を参照してください。

更新履歴ログの移動

更新履歴ログは、特定のサプライヤレプリカに加えられるすべての変更を記録した内部レコードで、サーバーが他のレプリカに修正を加えるときに使われます。更新履歴ログの内容はサーバーによって自動的に管理され、サーバーを再起動したあとでも、マルチマスター更新によって更新されます。

Directory Server の従来のバージョンでは、LDAP から更新履歴ログにアクセスできました。しかし今回、更新履歴ログの形式が変更され、サーバーによる内部処理専用になりました。使用しているアプリケーションで更新履歴ログを読み取る必要がある場合は、旧バージョン形式の更新履歴ログプラグインを使用して、下位互換性を保つことができます。詳細については、「旧バージョン形式の更新履歴ログプラグインの使用」を参照してください。

管理者が更新履歴ログの内容を変更する必要があるのは、ファイルが記録されるディスクがいっぱいになった場合など、このファイルを別の場所に移動するときだけです。


警告	更新履歴ログは、無効化したり、別の場所に移動したりすると、ふたたび初期化されます。どちらの場合も、このサーバーのレプリカのすべてのコンシューマを初期化し直す必要があります。

更新履歴ログの移動には、Directory Server コンソールを使用する必要があります。オペレーティングシステムの rename コマンドまたは mv コマンドを使用することはできません。

Directory Server コンソールの最上位の「設定」タブで「データ」ノードを選び、右側のパネルで「レプリケーション」タブを選びます。

新しい場所をテキストフィールドに入力します。これは、更新履歴ログを格納する新しいパスとディレクトリ名です。たとえば、更新履歴ログをデフォルト位置の ServerRoot/slapd-serverID/changelogdb から ServerRoot/slapd-serverID/newchangelog に移動できます。

古い場所にある既存の更新履歴ログは削除され、新しい場所に新しいログが作成されます。

「レプリケーション」タブの「保存」をクリックします。

Directory Server を再起動します。

「レプリカの初期化」の説明に従って、コンシューマを初期化し直します。

レプリカの同期の維持

定期保守のためにレプリケーションに関連する Directory Server の停止後、オンライン状態に復帰させたときは、レプリケーションを介してそれが更新されていることをただちに確認する必要があります。特に、マルチマスター環境のマスターサーバーでは、マルチマスターセットのもう一つのサーバーからディレクトリ情報を更新する必要があります。マルチマスター以外の環境でも、ハブレプリカや専用コンシューマが保守のためにオフラインになった場合、オンラインに復帰したときは、マスターレプリカ側から更新を行う必要があります。

ここでは、レプリケーションの再試行アルゴリズムおよび次の実行まで待たずに、強制的にレプリケーション更新を行う方法について説明します。

レプリケーションの再試行アルゴリズム

サプライヤがコンシューマのレプリケーションに失敗した場合は、時間間隔を大きくしながら定期的にレプリケーションを再試行します。再試行のパターンは、20、40、80、160、300 秒後です。その後、サプライヤは 300 秒 (5 分) おきに再試行を繰り返します。

サプライヤレプリカとコンシューマレプリカの間で、常に同期をとるレプリケーションアグリーメントを設定していても、オフライン状態の時間が 5 分を超えたレプリカをただちに最新の状態に戻すには、この方法では不十分です。

サーバーがオンライン状態に復帰した直後にディレクトリ情報を確実に同期させるには、Directory Server コンソールまたはカスタマイズ可能なスクリプトのどれかを利用できます。

コンソールによるレプリケーションの強制的な更新

コンシューマまたはマルチマスターレプリケーション設定のマスターが一定の時間を経過してオンライン状態に復帰したとき、レプリケーション更新をただちに送信させるためには、最新のディレクトリデータを保持しているサプライヤ上で次の手順を実行します。


注	ここで説明されている手順を利用できるのは、レプリケーションの設定が完了し、さらにコンシューマを初期化した直後だけです。

Directory Server コンソールの最上位の「設定」タブで、「データ」ノードを展開し、マスターレプリカのサフィックスのノードを展開し、サフィックスの下の「レプリケーション」ノードを選択します。

右側のパネルにレプリカのステータス情報が表示されます。

更新するコンシューマに対応するレプリケーションアグリーメントをリストから選択し、「アクション」>「ただちに更新を送信」の順にクリックします。

これにより、更新が必要な情報を保持しているレプリカに対してレプリケーションが開始されます。

コマンド行によるレプリケーションの強制的な更新

更新が必要なコンシューマから、次のスクリプトを実行して、レプリケーションの更新をただちに転送するようサプライヤに要求します。このスクリプト例をコピーして、適切な名前 (replicate_now.sh など) をつけてください。なお、この例のリストに含まれている変数には、実際の値を設定する必要があります。


注	このスクリプトは、サーバーがオフラインからオンラインに復帰したあとすぐに自動的に実行できるように設定できないため、管理者がこのスクリプトを実行する必要があります。

#!/bin/sh
SUP_HOST=supplier_hostname
SUP_PORT=supplier_portnumber
SUP_MGRDN=supplier_directoryManagerDN
SUP_MGRPW=supplier_directoryManagerPassword
MY_HOST=consumer_hostname
MY_PORT=consumer_portnumber

ldapsearch -1 -h ${SUP_HOST} -p ${SUP_PORT} -D "${SUP_MGRDN}" ¥
           -w ${SUP_MGRPW} -b "cn=mapping tree, cn=config" ¥
           "(&(objectclass=nsds5replicationagreement) ¥
              (nsDS5ReplicaHost=${MY_HOST}) ¥
              (nsDS5ReplicaPort=${MY_PORT}))" ¥
           dn nsds5ReplicaUpdateSchedule > /tmp/$$

cat /tmp/$$ |
awk '
BEGIN { s = 0 }
/^dn:/ { print $0;
  print "changetype:modify";
  print "replace:nsds5ReplicaUpdateSchedule";
  print "nsds5ReplicaUpdateSchedule: 0000-2359 0123456";
  print "-";
  print "";
  print $0;
  print "changetype:modify";
  print "replace:nsds5ReplicaUpdateSchedule";
  }
/^nsds5ReplicaUpdateSchedule:/ { s = 1; print $0; }
/^$/ {
  if ( $s == 1 )
    { print "-" ; print ""; }
  else
    { print "nsds5ReplicaUpdateSchedule: 0000-2359 0123456";
      print "-" ; print ""; };
  s = 0; }
' > /tmp/ldif.$$

echo "Ldif is in /tmp/ldif.$$"
echo

ldapmodify -c -h ${SUP_HOST} -p ${SUP_PORT} -D "${SUP_MGRDN}" ¥
           -w ${SUP_MGRPW} -f /tmp/ldif.$$

旧バージョンからのレプリケーション

ここでは、Directory Server の旧バージョンからのレプリケーションを設定する方法について説明します。

Directory Server 5.1 および 5.2 は、次の例外を除いてレプリケーションの設定については完全に互換性があります。

Directory Server 5.2 マスターレプリカと 5.1 コンシューマレプリカの間では、部分レプリケーションは行うことはできないので設定できません。

5.2 サプライヤと 5.1 コンシューマの間のアグリーメントを設定する前に、cn=config で nsslapd-schema-repl-useronly を on に設定する必要があります。この設定を行わないと、5.1 にレプリケートするときに、5.2 のスキーマによって競合が発生します。この設定により、99user.ldif ファイルに格納されているユーザー定義のスキーマ要素だけがレプリケートされます。詳細は、「スキーマ定義のレプリケーション」を参照してください。

Directory Server 5.2 では、RFC 2307 に合わせてスキーマファイル 11rfc2307.ldif が変更されています。「Directory Server 5.1 スキーマの更新」で説明する手順に従って、5.1 サーバーで対応するファイルを更新する必要があります。

ハブに降格された 5.2 マスターは、5.1 コンシューマのリフェラルのリストに残ります。ただし、降格の内部メカニズムにより、降格されたレプリカのポート番号はゼロになります。このリフェラル URL は使用できないため、ほとんどのクライアントは他のマスターへのリフェラルを自動的に試行します。しかし、これらの 5.1 レプリカにアクセスするクライアントのリフェラルでは、ホップ制限を引き上げる必要があります。5.2 コンシューマレプリカは、降格されたマスターを表示しません。また、そのマスターへの有効なリフェラル URL を返しません。

Directory Server 5.2 がリリース 4.x の Directory Server と組み合わせたレプリケーションに関与できるのは、次の場合です。

Directory Server 5.2 がマスターとして設定され、Directory Server 4.x サプライヤのコンシューマとしてだけレプリケートされる場合

コンシューマレプリカは、4.x サプライヤと 5.2 サプライヤの両方のコンシューマとなることはできない。ただし、 5.2 サーバーは異なる種類のレプリカ (旧バージョンの Directory Server から提供されるレプリカと 5.2 Directory Server から提供されレプリカ) を保持できる

4.x サプライヤのコンシューマとして設定された Directory Server 5.2 レプリカは、トポロジのこのサフィックスではハブレプリカとして機能できない

旧バージョンの Directory Server のコンシューマとして Directory Server 5.2 を使用できる利点は、レプリケートされた環境を簡単に移行できることです。レプリケートされた環境を移行するための手順について詳細は、『Directory Server Installation and Migration Guide』の第 4 章にある「Replicated Server Upgrade」を参照してください。

Directory Server 4.x のコンシューマとして Directory Server 5.2 を設定

リリース 4.x の Directory Server のコンシューマとして Directory Server 5.2 を使うときは、次のように設定する必要があります。

「マスターレプリカの有効化」の説明に従って、レプリカをマスターレプリカとして有効にします。レプリカは 4.x サプライヤのコンシューマとなりますが、マスターレプリカとして設定する必要があります。

このレプリカについて、右側のパネルで「変更」>「4.x との互換性を有効に」の順に選択します。または、「オブジェクト」メニューから「4.x との互換性を有効に」を選びます。

「4.x との互換性を有効に」ウィンドウが表示されるので、旧バージョンのサプライヤサーバーがバインドに使用するバインド DN とパスワードを指定します。ここで指定したバインド DN とパスワードは、旧バージョンのレプリケーションでのみ使用します。したがって、既存の DN や、5.x レプリケーションで使用されているデフォルトのレプリケーションマネージャは使用できません。

レプリケーションウィザードを使用して旧バージョンのレプリケーションを設定した場合は、指定したバインド DN とパスワードが旧バージョンのレプリケーションの設定エントリに正しく格納されます。旧バージョンのレプリケーションをコマンド行から手動で設定する場合、nsslapd-legacy-updatedn および nsslapd-legacy-updatepw 属性を使用して、旧バージョンのレプリケーションの設定エントリ内でバインド DN とパスワードを指定する必要があります。

旧バージョンのレプリケーションは簡単な認証のみに対応しており、証明書を使用するセキュリティ保護された認証には対応していません。

「了解」をクリックします。これで、このコンシューマレプリカは旧バージョンのサプライヤから更新を受信できます。

5.2 レプリカサーバーのスキーマが、4.x マスターからレプリケートされる内容が使用するすべての属性とオブジェクトクラスを定義していることを確認してください。

4.x マスターで作成された LDIF レプリカファイルをインポートして、5.2 レプリカを初期化します。このファイルの最初のエントリには、4.x レプリケーションメカニズムが必要とする copiedfrom 属性が含まれます。

サーバーで 4.x との互換性を有効にすると、デフォルトでインストールされている旧バージョンとのレプリケーションのプラグインが設定されます。このプラグインは、旧バージョンのサプライヤからの更新を処理し、レプリケートされるサフィックスの内容を更新します。

旧バージョンのレプリケーションの設定を完了するには、Directory Server 5.2 にレプリケートする旧バージョンのサプライヤを設定する必要があります。4.x Directory Server にレプリケーションアグリーメントを設定する手順については、旧バージョンの Directory Server のマニュアルを参照してください。

Directory Server 5.1 スキーマの更新


注	4.x との互換性を有効にしている限り、このレプリカはクライアントからすべての変更要求に対してリフェラルを返します。Directory Server 5.2 をマスターレプリカとして設定しても、このサフィックスでは変更要求は行われません。その代わりに、4.x サプライヤサーバーへのリフェラルが返されます。

Directory Server 5.2 では、RFC 2307 に合わせてスキーマファイル 11rfc2307.ldif が変更されています (http://www.ietf.org/rfc/rfc2307.txt)。5.2 サーバーと 5.1 サーバーの間でレプリケーションを設定または有効化する前に、5.1 サーバー側のスキーマを更新する必要があります。どちらのバージョンのサーバーでも、スキーマファイルは ServerRoot/slapd-serverID/config/schema/ に保存されています。

5.2 サーバーから 5.1 サーバーに 11rfc2307.ldif ファイルをコピーします。

5.1 サーバーの Solaris パッケージインストールを利用しているときは、古くなった 10rfc2307.ldif ファイルを削除します。

その他のプラットフォームで zip ファイルのインストールを利用しているときは、既存の 11rfc2307.ldif ファイルを上書きします。

この変更の影響を受けるスキーマファイルは次のとおりです。これらのファイルを 5.2 サーバーから 5.1 サーバーにコピーして、既存のファイルを上書きする必要があります。

20subscriber.ldif

30ns-common.ldif

50ns-admin.ldif

50ns-certificate.ldif

50ns-directory.ldif

50ns-legacy.ldif

50ns-mail.ldif

50ns-mlm.ldif

50ns-msg.ldif

50ns-netshare.ldif

5.1 サーバーを再起動し、レプリケーションの設定とレプリカの初期化に進みます。他のスキーマ要素との同期によって、サーバー間でレプリケートされるスキーマ属性もありますが、これはレプリケーションメカニズムによる正常な動作です。

古いバージョンのスキーマに依存するアプリケーションでは、更新が必要になる可能性があります。新しい 11rfc2307.ldif ファイルには、次の変更が加えられています。

automount 属性と automountInformation 属性は削除されました。

ipHost オブジェクトクラスの使用可能属性リストから o $ ou $ owner $ seeAlso $ serialNumber が削除されました。

ieee802Device オブジェクトクラスの必須属性リストから cn が削除されました。

ieee802Device オブジェクトクラスの使用可能属性リストから description $ l $ o $ ou $ owner $ seeAlso $ serialNumber が削除されました。

bootableDevice オブジェクトクラスの必須属性リストから cn が削除されました。

bootableDevice オブジェクトクラスの使用可能属性リストから description $ l $ o $ ou $ owner $ seeAlso $ serialNumber が削除されました。

nisMap オブジェクトクラスの OID が 1.3.6.1.1.1.2.9 に変更されました。

旧バージョン形式の更新履歴ログプラグインの使用

旧バージョン形式の更新履歴ログプラグインを使用すると、Directory Server 5.2 マスターレプリカで 4.x スタイルの更新履歴ログを維持できます。このプラグインは、Directory Server 4.x の形式の更新履歴ログに依存している、Meta Directory などのアプリケーションで必要になる場合があります。これは、アプリケーションが更新履歴ログからデータを読み取るためです。

旧バージョン形式の更新履歴ログプラグインでは、Directory Server 5.2 を 4.x コンシューマレプリカのサプライヤとすることはできません。「旧バージョンからのレプリケーション」で説明したように、4.x サプライヤの Directory Server 5.2 コンシューマだけがサポートされます。旧バージョン形式の更新履歴ログプラグインは、レプリケーションプロトコルとは無関係に動作し、レプリケーショントポロジに影響しません。旧バージョン形式の更新履歴ログプラグインは、シングルマスター構成のどのサーバーでも有効にできます。一般に、配備するアプリケーションが旧バージョン形式の更新履歴を必要とする場合は、その配備ではマルチマスターレプリケーショントポロジを採用するべきではありません。

旧バージョン形式の更新履歴ログは、サーバーの 5.2 更新履歴ログとは別に維持されます。旧バージョン形式の更新履歴ログは、cn=changelog という特別なサフィックスの下で、独立したデータベースに格納されます。旧バージョン形式の更新履歴ログは、単一レベルの複数のエントリから構成されます。更新履歴ログの各エントリには changeLogEntry というオブジェクトクラスがあり、次の表に一覧表示されている属性を含めることができます。

表 8-1 旧バージョン形式の更新履歴ログエントリの属性
属性	定義
changeNumber	1 つの値からなる属性で、常に存在する。各変更を識別する一意の整数を含む。この値は、変更の順序を示す。値が大きいほど、変更は新しい
targetDN	この属性には、LDAP 処理の影響を受けるエントリの DN が含まれる。modrdn 処理の場合、targetDN 属性には、変更または移動される前のエントリの DN が含まれる
changeTime	この属性は、変更操作が行われた時刻を特定する
changeType	LDAP 処理の種類を特定する。この属性の値には、add、delete、modify、modrdn のいずれかを指定できる
changes	add または modify 処理の場合、エントリに対する更新が LDIF 形式で記録される
newRDN	modrdn 処理の場合、エントリの新しい RDN が特定される
deleteOldRdn	modrdn 処理の場合、古い RDN が削除されたかどうかを示す
newSuperior	modrdn 処理の場合、エントリの newSuperior 属性を示す

旧バージョン形式の更新履歴ログプラグインの有効化

旧バージョン形式の更新履歴ログプラグインの設定情報は、dse.ldif の cn=Retro Changelog Plugin,cn=plugins,cn=config エントリに保持されます。

Directory Server コンソールから旧バージョン形式の更新履歴ログプラグインを有効にする手順は、次のとおりです。

Directory Server コンソールの最上位の「設定」タブで、「プラグイン」ノードを展開し、下にスクロールして「旧バージョン形式の更新履歴ログプラグイン (Retro Changelog Plugin)」を選択します。

右側のパネルで、「プラグインを有効に」チェックボックスを選択し、「保存」をクリックします。プラグインを無効にするには、このチェックボックスの選択を解除します。

プラグインを有効または無効にしたときは、Directory Server を再起動する必要があります。

コマンド行から旧バージョン形式の更新履歴ログプラグインを有効にする手順は、次のとおりです。

次のコマンドを実行して、旧バージョン形式の更新履歴ログプラグインの設定エントリを変更します。

ldapmodify -h host -p port -D "cn=Directory Manager" -w password
dn:cn=Retro Changelog Plugin,cn=plugins,cn=config
changetype:modify
replace:nsslapd-pluginenabled
nsslapd-pluginenabled:on
^D

サーバーを再起動するサーバーの再起動については、「Directory Server の起動と停止」を参照してください。

旧バージョン形式の更新履歴ログの削除

更新履歴ログのエントリは、指定した一定時間後に自動的に削除されます。更新履歴ログからエントリを自動的に削除する期間を指定するには、cn=Retro Changelog Plugin、cn=plugins、cn=config エントリで nsslapd-changelogmaxage 設定属性を設定する必要があります。この属性を設定するには、次のようにコマンド行だけで設定できます。

ここで、Integer は数字を表し、Timeunit の s は秒、m は分、h は時間、d は日数、およびw は週を表します。次の例のように、Integer 変数と Timeunit 変数の間には空白を挿入しません。

旧バージョン形式の更新履歴ログは、更新記録ログに対する次回の処理時に削除されます。

旧バージョン形式の更新履歴ログへのアクセス

更新履歴ログは検索操作をサポートしています。また、次の形式のフィルタを含む検索用に最適化されています。

一般的な規則として、更新履歴ログのサイズを小さくするためにエントリを削除するとしても、旧バージョン形式の更新履歴ログでは追加または変更処理は実行すべきではありません。旧バージョン形式の更新履歴ログで修正処理を実行する必要があるのは、デフォルトのアクセス制御ポリシーを修正する場合だけです。

旧バージョン形式の更新履歴ログが作成されると、次のアクセス制御規則がデフォルトで適用されます。

旧バージョン形式の更新履歴ログのトップエントリ cn=changelog に対する読み取り、検索、および比較の権限は、すべての認証ユーザー (userdn=anyone のユーザー。userdn=all で指定された匿名アクセスとは異なる) に付与される

Directory Manager に対する暗黙の了承を除き、書き込みおよび削除アクセスは付与されない

更新履歴ログのエントリにはパスワードなどの重要な情報が含まれている場合があるので、読み取りアクセス権を匿名ユーザーに付与しないでください。認証されたユーザーにも内容の表示が許可されない場合でも、旧バージョン形式の更新履歴ログの内容へのアクセスをさらに制限することが必要なことがあります。

旧バージョン形式の更新履歴ログに対するデフォルトのアクセス制御ポリシーを変更するには、cn=changelog エントリの aci 属性を変更する必要があります。aci 属性の設定については、第 6 章「アクセス制御の管理」を参照してください。

レプリケーション状態の監視

新しいコマンド行ツールと Directory Server コンソールを使用して、レプリケーションの状態を監視できます。

コマンド行ツール

レプリケーションの状態の監視には、次の 3 種類の新しいコマンド行ツールを利用できます。

repldisc : レプリケーションに含まれるすべての既知のサーバーを検出し、テーブルを作成する

insync : サプライヤレプリカと、1 つまたは複数のコンシューマレプリカの間の同期状態を示す

entrycmp : 複数のレプリカに含まれる同じエントリを比較する

これらのツールの完全なコマンド行構文と使用例については、『Directory Server Administration Reference』の第 1 章にある「Tools Reference」を参照してください。

レプリケーション状態タブ

Directory Server コンソールでレプリケーション状態の概要を確認する手順は、次のとおりです。

Directory Server コンソールの最上位の「状態」タブで、「レプリケーション」ノードを選択します。

このサーバーに設定されている各レプリケーションアグリーメントに関する情報が、右側のパネルに表示されます。

レプリケーションの状態を監視するには、「継続して再表示」チェックボックスを選択します。たとえば、レプリカの初期化がいつ完了したかを確認できます。

コンシューマにまだレプリケートされていないマスター側の最後の変更を調べるには、「保留中の変更数」ボタンをクリックします。この処理は時間がかかることがあるため、実行するかどうかを確認するメッセージが表示されます。保留中の変更数を調べるには、コンシューマ側の更新レコードをダウンロードし、それをマスター側の更新履歴ログと比較する必要があります。これらのログのサイズが大きい場合、多くの時間とサーバーリソースが使われます。

列の見出しをクリックしてサイズを変更することで、テーブルのレイアウトを変更できます。また、「表示オプション」ボタンをクリックして、表示する列だけを指定することもできます。次の表 8-2 は、このサーバーの各アグリーメントのテーブルの表示について指定できるレプリケーションパラメータを示しています。

表 8-2 Directory Server コンソールの状態タブのレプリケーションパラメータ
テーブルの見出し	内容
サフィックス	レプリケートされるサフィックスまたはサブサフィックスの名前
リモートレプリカ	コンシューマサーバーのホスト名とポート
内容	このレプリケーションアグリーメントに設定されている説明文
状態	アグリーメントが無効になっている、コンシューマを初期化している、通常の増分更新でレプリケーションを行なっている、のどれか
概要	最後のイベント (初期化または更新の開始または終了) と、最後に受信したメッセージ
送信済みの更新	レプリケーションが有効になってから、またはサーバーが再起動されてからコンシューマに更新が送信された合計回数
最終更新開始時間	最後のレプリケーションの更新開始日時
最終更新終了時間	最後のレプリケーションの更新終了日時
最終更新メッセージ	最後のレプリケーション更新の状態
最終初期化メッセージ	最後の初期化後のコンシューマの状態
最終初期化開始時間	最後のコンシューマレプリカの初期化開始日時
最終初期化終了時間	最後のコンシューマレプリカの初期化終了日時

よく発生するレプリケーションの競合の解決

マルチマスターレプリケーションでは、疎整合型レプリケーションモデル (Loose Consistency Replication Model) を使用します。つまり、同一のエントリを別々のサーバーから同時に変更できます。2 つのサーバー間で更新が送信された場合、更新の競合を解決する必要があります。ほとんどの場合、各サーバーの変更に関連するタイムスタンプに基づいて競合は自動的に解決されます。時刻の新しい更新が優先されます。

ただし、更新の競合を解決するためにユーザーの介入が必要となる場合もあります。レプリケーションプロセスで自動的に解決できない更新の競合があるエントリには、競合マーカーとしてのオペレーショナル属性 nsds5ReplConflict が含まれます。

この属性を含むエントリを定期的に検索することで、競合が生じているエントリを探すことができます。たとえば、次の ldapsearch コマンドを使用できます。

% ldapsearch -h host -p port -D "cn=Directory Manager" -w password ¥
-b "dc=example,dc=com" "(nsds5ReplConflict=*)"

nsds5ReplConflict 属性には、デフォルトでインデックスが設定されています。

ネーミングの競合の解決

サーバーがお互いの変更をレプリケートする前にエントリが作成された場合、別々のマスターに同じ DN を持つエントリが作成される可能性があります。レプリケーション時には、競合解決メカニズムによって 2 番目に作成されたエントリの名前が自動的に変更されます。

DN のネーミングが競合しているエントリは、オペレーショナル属性 nsuniqueid によって指定される一意の識別子を DN 内に含めることで名前を変更します。たとえば、2 つのマスターで uid=bjensen,ou=People,dc=example,dc=com というエントリが同時に作成されると、レプリケーション後の 2 つのエントリは、次のようになります。

uid=bjensen,ou=People,dc=example,dc=com

nsuniqueid=66446001-1dd211b2+uid=bjensen,dc=example,dc=com

2 番目のエントリは、DN が有効になるように名前を変更する必要があります。競合しているエントリを削除し、競合しない名前で追加し直すことができます。ただし、作成時に名前を変更する方法が最も確実です。名前変更の手順は、ネーミング属性が 1 つの値を持つか複数の値を持つかによって異なります。各手順は次のとおりです。

複数の値からなるネーミング属性を持つエントリの名前変更

複数の値からなるネーミング属性を持つ競合エントリの名前を変更する手順は、次のとおりです。

古い RDN 値を保持している間にエントリの名前を変更します。たとえば、次のようにします。

ldapmodify -h host -p port -D "cn=Directory Manager" -w password
dn:nsuniqueid=66446001-1dd211b2+uid=bjensen,dc=example,dc=com
changetype:modrdn
newrdn: uid=NewValue
deleteoldrdn: 0
^D

この手順では古い RDN 値を削除することはできません。ここには削除できないオペレーショナル属性 nsuniqueid も含まれているからです。

ネーミング属性の古い RDN 値と競合マーカー属性を削除します。たとえば、次のようにします。

ldapmodify -h host -p port -D "cn=Directory Manager" -w password
dn: uid=NewValue,dc=example,dc=com
changetype:modify
delete:uid
uid:bjensen
-
delete:nsds5ReplConflict
^D

1 つの値からなるネーミング属性を持つエントリの名前変更

dc (ドメインコンポーネント) など、ネーミング属性が 1 つの値の場合は、エントリの名前を単に同じ属性の別の値に変更することはできません。代わりに一時的な名前を付ける必要があります。

別のネーミング属性を使用してエントリの名前を変更し、古い RDN を保持しておきます。たとえば、次のようにします。

ldapmodify -h host -p port -D "cn=Directory Manager" -w password
dn:nsuniqueid=66446001-1dd211b2+dc=HR,dc=example,dc=com
changetype:modrdn
newrdn: o=TempName
deleteoldrdn: 0
^D

この手順では古い RDN 値を削除することはできません。ここには削除できないオペレーショナル属性 nsuniqueid も含まれているからです。

必要なネーミング属性を一意の値に変更し、競合マーカー属性を削除します。たとえば、次のようにします。

ldapmodify -h host -p port -D "cn=Directory Manager" -w password
dn: o=TempName,dc=example,dc=com
changetype:modify
replace:dc
dc: uniqueValue
-
delete:nsds5ReplConflict
^D

エントリの名前を変更し、指定したネーミング属性に戻します。たとえば、次のようにします。

ldapmodify -h host -p port -D "cn=Directory Manager" -w password
dn: o=TempName,dc=example,dc=com
changetype:modrdn
newrdn: dc=uniqueValue
deleteoldrdn: 1
^D

deleteoldrdn 属性の値に 1 を設定すると、一時的な属性と値のペアである o=TempName が削除されます。この属性を保持する場合は、deleteoldrdn 属性の値に 0 を設定します。

親のないエントリの競合の解決

エントリの削除操作がレプリケートされたとき、コンシューマサーバーが削除されるエントリが子エントリを持つことを検出した場合、競合解決処理によって glue エントリが作成され、親のないエントリをディレクトリに持つことを回避します。

同様に、エントリの追加後にレプリケーションが実行され、コンシューマサーバーが追加されたエントリの親エントリを検出できなかった場合も、競合解決処理は親を表す glue エントリを作成し、親のないエントリが追加されることを回避します。

glue エントリは、glue および extensibleObject というオブジェクトクラスを持つ一時的なエントリです。glue エントリは、次のいくつかの方法で作成されます。

競合解決処理が、一致する一意の識別子をともなう削除されるエントリを検出した場合、glue エントリは、glue オブジェクトクラスと nsds5ReplConflict 属性を加えて、そのエントリを復元する

サーバーによって、glue および extensibleObject オブジェクトクラスを持つ必要最小限のエントリが作成される

潜在的な相互運用性の問題の解決

メールサーバーのように属性の一意性に依存するアプリケーションとの相互運用性の理由から、nsds5ReplConflict 属性を持つエントリへのアクセスを制限する必要がある場合があります。これらのエントリへのアクセスを制限しない場合は、1 つの属性だけを要求するアプリケーションが元のエントリと nsds5ReplConflict を含む競合解決エントリの両方を取得し、処理が失敗します。

アクセスを制限するには、次のコマンドを使用して、匿名の読み取りアクセスを許可するデフォルトの ACI を変更する必要があります。

新しい ACI では、検索結果として返されたものの中から nsds5ReplConflict 属性を持つエントリが保持されます。

前へ目次索引次へ
Sun Java™ System Directory Server 5 2004Q2 管理ガイド