|
| Sun ONE Directory Server 管理ガイド |
レプリケーションとは、1 つの Directory Server から別のもう 1 つ、または複数の Directory Server にディレクトリの内容を自動的にコピーするメカニズムです。エントリの追加、変更、削除など、あらゆる書き込み処理はコピー先の Directory Server に自動的にミラー化されます。レプリケーションの概念、レプリケーションの導入例、ディレクトリ導入時にレプリケーションを計画する方法についての詳細 は、『Sun ONE Directory Server Deployment Guide』の第 6 章「Designing the Replication Process」を参照してください。
Sun ONE Directory Server 5.2 には、レプリケーションの新機能が数多く用意されています。
- 広域ネットワーク (WAN) 上のマルチマスターレプリケーション (MMR) では、地理的に離れたマスターとの間でレプリケーションアグリーメントを確立し、データをより効率的に配信できます。
- MMR は、完全に接続されたマスターを同時に 4 つサポートできるようになりました。これにより、一層のフェイルオーバ保護を提供できます。
- バイナリコピーにより、大容量レプリカの初期化がより高速になりました。
- 部分レプリケーションにより、レプリケートする属性セットを指定できるので、データをより効率的に配信できます。
- レプリケーション導入の監視には、新しいコマンド行ツールも利用できます。
この章では、レプリケーションのすべての導入例の設定について、マスター、ハブ、コンシューマサーバーで実行するタスクについて説明します。この章は、次の節で構成されています。
- はじめに
- レプリケーションの設定手順のまとめ
- レプリケーションマネージャの選択
- 専用コンシューマの設定
- ハブの設定
- マスターレプリカの設定
- レプリケーションアグリーメントの作成
- 部分レプリケーションの設定
- レプリカの初期化
- 参照整合性プラグインの有効化
- SSL を経由するレプリケーション
- WAN を経由するレプリケーション
- レプリケーショントポロジの変更
- 旧バージョンからのレプリケーション
- 旧バージョン形式の更新履歴ログプラグインの使用
- レプリケーション状態の監視
- よく発生するレプリケーションの競合の解決
はじめに
レプリケーションの設定は複雑な作業です。設定を始める前に、シングルマスターとマルチマスターのどちらを導入するのか、またはハブを利用したカスケード 型レプリケーションを導入するのかなど、組織に導入するレプリケーションの種類を明確にしておく必要があります。レプリケーションの単位はサフィックスま たはサブサフィックスです。1 つのサフィックスに含まれるすべてのエントリは、まとめてレプリケートされます。導入を意図したように行うには、各サフィックスをマスター、ハブ、または 含まれるデータの専用コンシューマとして識別する必要があります。
サーバーにレプリケートされるサフィックスをレプリカと呼びます。マスターは、クライアントからの読み取り処理と書き込み処理の両方を受け付けるレプリカ です。ハブと専用コンシューマは、レプリケーションメカニズムを使って行われる更新だけを受け付ける、読み取り専用のレプリカです。ハブは、マスターまた は別のハブからの更新を受信し、それを別のハブまたは専用コンシューマに転送します。専用コンシューマは、マスターまたはハブから更新を受信するだけで す。
次の図は、レプリケーションの一般的な導入例でのレプリカ間の関係を示しています。
図 8-1 一般的なレプリケーションの例
このマニュアルでは、サプライヤとコンシューマという用語も使います。これは、レプリケーションアグリーメントに関与する 2 種類のサーバーの役割を意味します。サプライヤはレプリケーション更新を送信するサーバーで、コンシューマはそれを受信するサーバーです。上の図は、次の 関係を示しています。
- シングルマスターはサプライヤであり、コンシューマではない
- マルチマスターレプリケーションのマスターには、サプライヤとしての役割だけでなく、他のマスターのコンシューマとしての役割もある
- ハブには常にサプライヤとコンシューマの役割がある
- 専用コンシューマは常にコンシューマである
レプリカの種類に関係なく、アグリーメントにはサプライヤとコンシューマの役割として、数多くのレプリケーション設定がレプリカに適用されます。
レプリケーションの設定手順のまとめ
次の手順は、シングル サフィックスのレプリケーションを前提としています。複数のサフィックスをレプリケートする場合は、各サーバーでそれぞれを並行して設定する必要がありま す。つまり、複数サフィックスのレプリケーションを設定するには、各手順を繰り返す必要があります。
レプリケーションのトポロジを設定する手順は、次のとおりです。
- シングルマスターを除くすべてのサーバーでレプリケーションマネージャのエントリを定義します。または、すべてのサーバーでデフォルトのレプリケーションマネージャを使用します。
- 専用コンシューマのレプリカが作成されるすべてのサーバーでは、次の処理を行います。
- コンシューマレプリカ用の空のサフィックスを作成します。
- レプリケーションウィザードを使って、サフィックスに含まれるコンシューマレプリカを有効にします。
- 必要に応じて、詳細なレプリカ設定を行います。
- ハブを利用する場合は、ハブのレプリカが作成されるすべてのサーバーで次の処理を行います。
- ハブレプリカ用の空のサフィックスを作成します。
- レプリケーションウィザードを使って、サフィックスに含まれるハブレプリカを有効にします。
- 必要に応じて、詳細なレプリカ設定を行います。
- マスターレプリカが作成されるすべてのサーバーでは、次の処理を行います。
- マスターレプリカとなるマスターで、サフィックスを 1 つ選択するか、作成します。
- レプリケーションウィザードを使って、サフィックスに含まれるマスターレプリカを有効にします。
- 必要に応じて、詳細なレプリカ設定を行います。
- すべてのサプライヤレプリカで、次の順序でレプリケーションアグリーメントを設定します。
- マルチマスターセットのマスター間
- マスターと専用コンシューマの間
- マスターとハブレプリカの間
必要に応じて、部分レプリケーションを設定し、この時点でコンシューマレプリカとハブレプリカを初期化することもできます。マルチマスターレプリケーションでは、データのオリジナルコピーを含むマスターレプリカから順にすべてのマスターを初期化します。
- マスターからデータを直接受け取るすべてのハブレプリカで、レプリケーションアグリーメントを設定します。これは、 ハブレプリカとそのコンシューマとの間のアグリーメントです。必要に応じて、この時点でコンシューマレプリカを初期化します。カスケード型のレプリケー ションでは、ハブのすべての階層でこの手順を繰り返します。
注 以上の手順で重要なことは、レプリケーションアグリーメントを作成する前に、レプリカをすべて作成し、設定しておくことです。こうすることで、レプリケー ションアグリーメントの作成後、ただちにコンシューマレプリカを初期化できます。コンシューマの初期化は、常にレプリケーションの設定の最後の段階で実行 します。
レプリケーションマネージャの選択
レプリケーションの設定で重要なのは、レプリケーションマネージャというエントリを選択することです。レプリケーションマネージャは、サプライヤがレプリ ケーションの更新を送信するときに、コンシューマサーバーとのバインドに使われます。専用コンシューマ、ハブ、マルチマスターレプリケーションに組み込ま れているマスターなど、更新を受け取るサフィックスを持つすべてのサーバーでは、少なくとも 1 つのレプリケーションマネージャエントリが必要です。
Directory Server には、すべてのサーバーで利用できるデフォルトのレプリケーションマネージャエントリが用意されています。このエントリの DN は cn=Replication Manager,cn=replication,cn=config です。
注 単純なレプリケーションでは、すべての導入例でデフォルトのレプリケーションマネージャを利用することをお勧めします。レプリケーションウィザードは、このエントリを使ってコンシューマレプリカを自動的に設定するので、レプリカを簡単に導入できます。
デフォルトレプリケーションマネージャのパスワードが定義されていない場合、レプリケーションウィザードはパスワードの入力を要求します。デフォルトレプリケーションマネージャのパスワードをあとから変更する手順は、次のとおりです。
- Directory Server コンソールの最上位の「設定」タブで「データ」ノードを選び、右側のパネルで「レプリケーション」タブを選びます。
- 「レプリケーションマネージャ」という見出しの下にある 2 つのテキストフィールドに新しいパスワードを入力します。
- パスワードの確認への入力が完了したら、「保存」をクリックします。パスワードが確認のために入力したパスワードと一致しない場合、「保存」ボタンは有効になりません。
レプリケーションマネージャとして機能するエントリを新たに作成することもできます。たとえば、レプリケートされるすべてのサフィックスで、複数のレプリ ケーションマネージャエントリに異なるパスワードを持たせることができます。また、たとえば SSL 経由の証明書など、異なる認証モデルをレプリケーションに適用するには、独自のレプリケーションマネージャを作成する必要があります。
レプリケーションマネージャエントリには、レプリケーションアグリーメントを定義するときに、選択した認証方法に適した属性が含まれている必要があります。たとえば、デフォルトのレプリケーションマネージャのオブジェクトクラスは person です。このクラスは、userPassword 属性を使った簡単な認証に対応しています。証明書を使ってレプリケーションマネージャをバインドする方法の詳細は、「SSL を経由するレプリケーション」を参照してください。
このレプリケーションマネージャのエントリは、コンシューマサーバーのレプリケートされたサフィックスの中に保存しておくことはできません。レプリケーションマネージャの定義場所としてふさわしいのは、cn=replication,cn=config です。
警告
レプリケーションマネージャエントリの DN とパスワードを使って、バインドを実行したり、サーバー上で処理を行うことはできません。レプリケーションマネージャはレプリケーションメカニズムだけが使用するものであり、その他の使用ではレプリカの再初期化が必要です。
各コンシューマのレプリケーションマネージャを選択したら、次の処理を行います。
- 選択または作成したレプリケーションマネージャの 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 にはセキュリティ保護された接続に使うポート番号を指定します。
リフェラルとして 1 つまたは複数の LDAP URL を追加したときは、リストの下に表示されるチェックボックスを選択して、コンシューマがマスターレプリカのリフェラルではなく、これらの LDAP URL のリフェラルを送信するようにします。たとえば、クライアントがデフォルトのポートではなく、常にマスターサーバーのセキュリティ保護されたポートにアク セスするように設定するには、これらのセキュリティ保護されたポートの LDAP URL リストを作成し、このチェックボックスを選択します。すべての更新を処理する特定のマスターまたは Directory Server プロキシを指定する場合も、排他的なリフェラルを用意する必要があります。
- 「オプション」タブでは、パージ遅延も変更できます。
コンシューマサーバーは、レプリカの内容に加えられる変更に関する内部情報を格納する必要があり、パージ遅延はこの情報を保持する期間を決定します。この 値は、サプライヤサーバーの更新履歴ログの MaxAge パラメータと関連づけられています。これらの 2 つのパラメータのうち、短いほうの設定が、2 つのサーバー間のレプリケーションが無効になった、またはダウンした場合でも正常な状態に復元できる最長期間を決定します。ほとんどの場合には、デフォル トの 7 日間が適当です。
- 「了解」をクリックして、このレプリカの詳細設定を保存します。
ハブの設定
ハブレプリカは、コンシューマとしてだけではなく、マスターとしても機能し、レプリケートされたデータをより多くのコンシューマに配信します。このため、 レプリケーションの更新をそれぞれのサプライヤから受信するだけでなく、レプリケーションの更新をそれぞれのコンシューマに送信する必要があります。ハブ レプリカは変更を受け付けませんが、マスターにリフェラルを返します。
ハブサーバーを設定するには、レプリカを保持する空のサフィックスを準備し、レプリケーションウィザードを使ってそのサフィックスのレプリケーションを有 効にします。必要に応じて、異なるレプリケーションマネージャの選択、リフェラルの設定、パージ遅延の設定、ログパラメータの設定と変更など、詳細な設定 も行うことができます。
次に、1 つのハブサーバーを設定する手順について説明します。特定のサフィックスのハブレプリカを含むすべてのサーバーで、同じ手順を繰り返してください。
ハブレプリカのサフィックスの作成
サフィックスをまだ作成していない場合は、レプリケーションの対象となるマスターレプリカと同じ DN を使ってハブサーバーに空のサフィックスを作成します。手順については、「サフィックスの作成」を参照してください。
すでにサフィックスが存在し、それが空でない場合は、マスターからレプリカが初期化されたときにそのサフィックスの内容は失われます。
ハブレプリカの有効化
レプリケーションウィザードを使うことで、ハブレプリカを簡単に有効にできます。
- Directory Server コンソールの最上位の「設定」タブで、「データ」ノードを展開し、ハブレプリカとして設定するサフィックスのノードを展開し、サフィックスの下の「レプリケーション」ノードを選択します。
右側のパネルにレプリカのステータス情報が表示されます。
- 「レプリケーションを有効に」ボタンをクリックすると、レプリケーションウィザードが起動されます。
- 「ハブレプリカ」ラジオボタンを選択し、「次へ」をクリックします。
- 更新履歴ログファイルを選択していない場合は、ログファイルの選択が求められます。テキストフィールドには、デフォ ルトの更新履歴ログファイルが表示されます。デフォルトの更新履歴ログファイルを使わないときは、ファイル名を入力するか、「参照」をクリックしてファイ ルを選択します。
更新履歴ログファイルがすでに指定されている場合、この手順は省略されます。
- 「次へ」をクリックします。デフォルトレプリケーションマネージャのパスワードが定義されていない場合、パスワードの入力と確認のための再入力が求められます。各フィールドに同じパスワードを入力し、「次へ」をクリックします。
デフォルトレプリケーションマネージャにすでにパスワードが定義されている場合、この手順は省略されます。
- レプリケーションウィザードはレプリケーションの設定更新を開始します。ウィザードには、ステータスメッセージが表示されます。処理が完了したら、「閉じる」をクリックします。
レプリケーションのステータスは、レプリカが更新の受信準備が整っていることを示し、それに対応して左側のペインのアイコンも変更されます。
ハブの詳細設定
ハブはサプライヤとして更新履歴ログファイルを必要とします。ウィザードを使った場合、デフォルトの更新履歴ログの設定を使ってハブレプリカが設定されます。この設定を変更する手順は、次のとおりです。
- Directory Server コンソールの最上位の「設定」タブで「データ」ノードを選び、右側のパネルで「レプリケーション」タブを選びます。
- このタブの内容の更新が必要な場合には、「更新履歴ログを有効に」チェックボックスを選択して「リセット」ボタンをクリックします。これにより、レプリケーションウィザードで選択した更新履歴ログファイルが表示されます。
- 更新履歴ログファイルの名前を変更したり、ログパラメータを変更したりできます。
- 「更新履歴ログの最大レコード数」 - コンシューマに更新を送信するために格納しておく変更の最大数を決定します。デフォルトでは、無制限です。レプリカが数多くの大容量の変更を受信するときは、レコード数を少なめに設定して、ディスク容量を節約できます。
- 「更新履歴ログの最長保存期間」 - コンシューマに送信する必要のある更新をどれだけの期間ハブが保持しているかを決定します。デフォルトでは、無制限です。更新履歴ログのサイズを制限するときは、最長保存期間パラメータを利用することをお勧めします。
レプリケーションウィザードは、デフォルトのレプリケーションマネージャを使用します。レプリケーションマネージャエントリを独自に作成した場合、それを使うには詳細な設定が必要です。また、このダイアログを使って変更とパージ遅延のリフェラルも設定できます。
- Directory Server コンソールの最上位の「設定」タブで、「データ」ノードを展開し、設定するサフィックスのノードを展開し、サフィックスの下の「レプリケーション」ノードを選択します。
- 右側のパネルで「詳細」ボタンをクリックし、「詳細レプリカ設定」ダイアログを開きます。
- 「バインド DN」タブで、「追加」ボタンと「削除」ボタンを使って有効なレプリケーションマネージャの DN リストを作成します。このリストは、サプライヤとこのレプリカとの間のアグリーメントに含まれるため、サプライヤはリスト内のいずれの DN も利用できるようになります。新しい DN を追加するときは、DN 名を入力するか、ディレクトリを参照して選択します。
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 コンソールの最上位の「設定」タブで「データ」ノードを選び、右側のパネルで「レプリケーション」タブを選びます。
- このタブの内容の更新が必要な場合には、「更新履歴ログを有効に」チェックボックスを選択して「リセット」ボタンをクリックします。これにより、レプリケーションウィザードで選択した更新履歴ログファイルが表示されます。
- 更新履歴ログファイルの名前を変更したり、ログパラメータを変更したりできます。
- 「更新履歴ログの最大レコード数」 - コンシューマに更新を送信するために格納しておく変更の最大数を決定します。デフォルトでは、無制限です。レプリカが数多くの大容量の変更を受信するときは、レコード数を少なめに設定して、ディスク容量を節約できます。
- 「更新履歴ログの最長保存期間」 - コンシューマに送信する必要のある更新をどれだけの期間ハブが保持しているかを決定します。デフォルトでは、無制限です。更新履歴ログのサイズを制限するときは、最長保存期間パラメータを利用することをお勧めします。
レプリケーションウィザードは、デフォルトのレプリケーションマネージャを使用します。レプリケーションマネージャエントリを独自に作成した場合、それを 使うには詳細な設定が必要です。また、このダイアログを使って変更とパージ遅延のリフェラルも設定できます。シングルマスターの設定では、この手順を省略 します。
- Directory Server コンソールの最上位の「設定」タブで、「データ」ノードを展開し、設定するサフィックスのノードを展開し、サフィックスの下の「レプリケーション」ノードを選択します。
- 右側のパネルで「詳細」ボタンをクリックし、「詳細レプリカ設定」ダイアログを開きます。
- 「バインド DN」タブで、「追加」ボタンと「削除」ボタンを使って有効なレプリケーションマネージャの DN リストを作成します。このリストは、サプライヤとこのレプリカとの間のアグリーメントに含まれるため、サプライヤはリスト内のいずれの DN も利用できるようになります。新しい DN を追加するときは、DN 名を入力するか、ディレクトリを参照して選択します。
SSL 経由の証明書を使うようにレプリケーションを設定するときは、レプリケーションマネージャの 1 つのエントリとして証明書の DN を指定します。
- 処理が完了したら、「了解」をクリックします。「オプション」タブを選んで、さらに詳細な設定を行うこともできます。
- 「詳細レプリカ設定」ダイアログの「オプション」タブには、このマスターに送信される変更要求の追加リフェラルを指定する LDAP URL のリストが表示されます。「マルチマスター初期化後のマスター間の一致」でも説明しますが、初期化が完了すると、マスターはただちにリフェラルを返します。LDAP URL のリストを作成するには、「追加」ボタンと「削除」ボタンを使います。
レプリケーションのメカニズムでは、レプリケーショントポロジに含まれるすべての既知のマスターのリフェラルを返すようにハブを自動的に設定します。これ らのデフォルトリフェラルは、クライアントが標準的な接続で簡単な認証を使うことを前提としています。安全な接続のために SSL を使ってマスターにバインドするオプションをクライアントに提供するには、ldaps://servername:port という形式でリフェラルを追加します。port にはセキュリティ保護された接続に使うポート番号を指定します。
リフェラルとして 1 つまたは複数の LDAP URL を追加したときは、リストの下に表示されるチェックボックスを選択して、サーバーがマスターレプリカのリフェラルではなく、これらの LDAP URL のリフェラルを送信するようにします。たとえば、クライアントがデフォルトのポートではなく、常にマスターサーバーのセキュリティ保護されたポートにアク セスするように設定するには、これらのセキュリティ保護されたポートの LDAP URL リストを作成し、このチェックボックスを選択します。
- 「オプション」タブでは、パージ遅延も変更できます。
マスターサーバーは、レプリカの内容に加えられる変更に関する内部情報を格納する必要があり、パージ遅延はこの情報を保持する期間を決定します。この値 は、更新を提供するマスターサーバーの更新履歴ログ (このサーバー自体の更新履歴ログではない) の MaxAge パラメータと関連づけられています。これらの 2 つのパラメータのうち、短いほうの設定が、2 つのサーバー間のレプリケーションが無効になった、またはダウンした場合でも正常な状態に復元できる最長期間を決定します。ほとんどの場合には、デフォル トの 7 日間が適当です。
- 「了解」をクリックして、このレプリカの詳細設定を保存します。
レプリケーションアグリーメントの作成
レプリケーションアグリーメントはサプライヤ側に設定されるパラメータセットで、更新をどのようにコンシューマに送信するかを制御します。コンシューマに 更新を送信するサプライヤレプリカには、レプリケーションアグリーメントを作成する必要があります。レプリケーションアグリーメントは、レプリケーション メカニズムを使って更新するすべてのコンシューマに 1 つずつ作成する必要があります。
レプリケーションアグリーメントを作成する順序は、次のとおりです。
- マルチマスターセットのマスターの間 (レプリケートするサフィックスのオリジナルコピーを含むマスターを最初に作成)
- マスターと、レプリケーションにハブを使わない専用コンシューマの間
- マスターとハブレプリカの間
- ハブレプリカと、ハブを使うコンシューマの間
たとえば 図 8-1 は、2 つのマスターと 3 つの専用コンシューマのレプリケーショントポロジを持つマルチマスターレプリケーションを示しています。この場合、次の順序で 8 つのレプリケーションアグリーメントを作成します。
- 1 つのマスターともう一方のマスターの間
- もう一方のマスターと最初のマスターの間
- 1 つのマスターと 3 つの専用コンシューマの間
- もう一方のマスターと 3 つの専用コンシューマの間
レプリケーションアグリーメントを作成する手順は、次のとおりです。
- Directory Server コンソールの最上位の「設定」タブで、「データ」ノードを展開し、サプライヤサフィックスのノードを展開し、サフィックスの下の「レプリケーション」ノードを選択します。
右側のパネルにレプリカのステータス情報が表示されます。
- 定義されているレプリケーションアグリーメントの隣の「新規」ボタンをクリックします。
- 「レプリケーションアグリーメント」ダイアログが表示されるので、コンシューマレプリカを含む既存のサーバーをメニューから選択するか、「その他」ボタンをクリックして新たに定義します。
「その他」ボタンをクリックしたときは、コンシューマサーバーの完全修飾名と LDAP ポート番号を入力します。そのポートで SSL を使っているときは、セキュリティ保護されたポートのチェックボックスを選択し、安全な接続によるレプリケーションの更新を有効にします。
- コンシューマサーバー上のレプリケーションマネージャエントリの DN とパスワードを入力します。デフォルトでは、デフォルトレプリケーションマネージャの DN が指定されます。
セキュリティ保護されたポートを持つコンシューマを選択したときは、「オプション」ボタンをクリックして、「DN」フィールドの内容が示す意味を指定でき ます。パスワードを使った接続では、サプライヤは簡単な認証と、暗号化された SSL 接続を経由する通信を利用します。証明書を使った接続では、「DN」フィールドの内容は証明書を含むエントリの DN を意味し、パスワードは必要ありません。
- 必要に応じて、このアグリーメントの説明文を入力します。コンシューマサーバーの名前とポート番号、説明文は、このマスターレプリカのレプリケーションアグリーメントリストに表示されます。
- 設定が完了したら「了解」をクリックします。設定した接続パラメータをテストするかどうかを確認するダイアログが表示されます。
- 指定したレプリケーションマネージャとパスワードを使って指定のサーバーとポート番号への接続をテストするときは、 「はい」をクリックします。接続に失敗した場合でも、そのアグリーメントを使う設定を維持できます。これは、たとえばパラメータに問題はないが、サーバー がオフラインである場合などに有効です。
設定が完了すると、このマスターレプリカのレプリケーションアグリーメントリストにアグリーメントが表示されるようになります。
レプリケーションアグリーメントを編集して、コンシューマサーバー上のレプリケーションマネージャの DN とパスワードをあとから変更できます。
- リストからレプリケーションアグリーメントを選択し、「編集」ボタンをクリックします。
- 「レプリケーションアグリーメント」ダイアログが表示されるので、「接続」タブを選びます。
- コンシューマサーバー上のレプリケーションマネージャの DN またはパスワードを編集します。
- 必要に応じて、このアグリーメントの説明文を編集します。
- 「了解」をクリックして新しい設定を保存し、このコンシューマに更新を送信すると、ただちにそのアグリーメントが使用されます。
その他のタブの設定パラメータについては、「部分レプリケーションの有効化」と「WAN を経由するレプリケーション」を参照してください。
- 必要なレプリケーションアグリーメントを作成したら、このサフィックスの部分レプリケーションを設定し、レプリカをただちに初期化することもできます。詳細は、「レプリカの初期化」を参照してください。
部分レプリケーションの設定
デフォルトでは、レプリケートされるサフィックスに含まれるすべてのエントリがコンシューマレプリカにコピーされます。Sun ONE Directory Server 5.2 に新たに追加された部分レプリケーション機能を使うことで、レプリケーション時にコピーの対象に含める、またはコピーの対象から除外する属性のサブセット を指定できます。部分レプリケーションはレプリケーションアグリーメントに設定されるので、マスターのコンシューマレプリカごとに属性セットを定義できま す。これにより、配信するデータを制御し、レプリケーションの帯域幅とコンシューマリソースをより効率的に利用できます。
たとえば、photo、jpegPhoto、audio のように一般に値が大きい属性のレプリケーションを除外することで、レプリケーションの帯域幅を節約できます。この場合、コンシューマではこれらの属性を利用できなくなります。また、認証に必要な uid 属性と userpassword 属性だけをコンシューマサーバーにレプリケートすることもできます。
部分レプリケーションに関する注意点
属性の部分的なセットを有効化または変更するには、コンシューマレプリカを初期化し直す必要があります。このため、配備前に部分レプリケーションの必要性を検討し、レプリケーションを初期化する前に属性セットを設定しておく必要があります。
ACI、ロール、CoS などの複雑な機能が特定の属性に依存する小規模な属性セットをレプリケートするときは、慎重な対応が必要です。ACI、ロール、CoS の各メカニズムの指定子やフィルタで参照されるその他の属性がレプリケートされない場合、データのセキュリティが損なわれたり、検索時に異なる属性セット が返されることがあります。レプリケーションの対象に含める属性のリストを管理するよりも、除外する属性のリストを管理する方法が安全であり、人的なミス も少なくなります。
レプリケートするすべてのエントリがスキーマに準拠しない属性セットをレプリケートするときは、コンシューマサーバーのスキーマチェックを無効にする必要 があります。スキーマに準拠しないエントリをレプリケートしても、レプリケーションメカニズムはコンシューマ上でのスキーマチェックを行わないため、エ ラーは発生しません。しかし、スキーマに準拠しないエントリがコンシューマに含まれるようになるので、クライアントにとって一貫した状態にする必要がある ためスキーマチェックを無効にする必要があります。
部分レプリケーションは、ハブと専用コンシューマに関連するマスターレプリカのレプリケーションアグリーメントに設定します。マルチマスターレプリケー ション環境の 2 つのマスターレプリカ間での部分レプリケーションは設定できません。また、複数のマスターが同じレプリカとの間でレプリケーションアグリーメントを持つ場 合、同じ属性セットをレプリケートするようにすべてのアグリーメントを設定する必要があります。
Sun ONE Directory Server 5.2 が提供する部分レプリケーション機能は、旧バージョンの Directory Server との間に下位互換性を持ちません。部分レプリケーションアグリーメントを設定するときは、マスターレプリカとコンシューマレプリカの両方が Directory Server 5.2 インスタンス上に存在する必要があります。
属性セットの定義
属性セットは、部分レプリケーションがレプリカで有効になった場合にレプリケートされる属性のリストで、リストに含まれない属性はレプリケートされませ ん。マスターサーバーには任意の数の属性セットを設定することができ、その属性セットのどれかをレプリケーションアグリーメントに関連づけます。
- Directory Server コンソールの最上位の「設定」タブで「データ」ノードを選び、右側のパネルで「レプリケーション」タブを選びます。
- 「レプリケーション」タブの下部にある「レプリケートされた属性のセットを管理」ボタンをクリックします。このボタンを表示するには、スクロールが必要なこともあります。
- 「追加」をクリックして新しい属性セットを定義するか、リストから既存の属性セットを選び、「編集」をクリックして 内容を変更します。「属性セット」ダイアログが表示されるので、レプリケートする列のチェックボックスを使って属性をセットに加えたり、セットから除外し たりします。名前の隣にチェックマークが表示された属性がレプリケートされます。
デフォルトでは、すべての属性が選択されています。レプリケートを避ける具体的な理由のある属性だけの選択を解除することをお勧めします。最初から設定し 直すときは、「すべてをチェック」ボタンをクリックすると、すべての属性が選択されます。多数の属性の選択を解除した場合、Directory Server は選択が解除された属性以外のすべての属性をレプリケートします。あとから新しい属性をスキーマに定義し、レプリケートされたエントリでそれを使用する場 合、属性セットを編集して選択を解除するまで、これらの新しい属性はレプリケートされます。
「チェックしない」ボタンをクリックすると、すべての属性の選択が解除されるので、セットに含める属性 (レプリケートする属性) だけを選択できます。「チェックしない」ボタンをクリックしてから属性セットを定義した場合、選択した属性だけがレプリケートされます。あとから新しい属 性をスキーマに定義し、レプリケートされたエントリでそれを使用する場合、属性セットを編集してその属性を選択するまで、これらの新しい属性はレプリケー トされません。
- 必要に応じて、属性セットの説明文を入力または変更します。この文章は、このセットを使用するレプリケーションアグ リーメントの編集時に、定義されているセットとともにリスト表示されます。説明文を入力しない場合、含まれるか、除外される属性に基づいてサーバーが説明 を自動的に生成します。
- 処理が終了したら、「保存」をクリックします。
部分レプリケーションの有効化
部分レプリケーションは、既存のレプリケーションアグリーメントだけで有効にできます。
- 「レプリケーションアグリーメントの作成」の説明に従ってレプリケーションアグリーメントを作成するか、すでに定義されているアグリーメントを選択して変更します。
- 「レプリケーションアグリーメントの無効化」の説明に従って、レプリケーションアグリーメントを無効にします。部分レプリケーションの設定を変更するときは、アグリーメントを無効にする必要があります。
- 無効にしたアグリーメントを選び、「編集」をクリックします。「レプリケーションアグリーメント」ダイアログが表示されるので、「レプリケートされた属性」タブを選びます。
- 「属性のセットのみレプリケート」チェックボックスを選びます。
- ドロップダウンリストから既存の属性セットを選ぶか、「新規」をクリックし、「属性セットの定義」の説明に従って新しい属性セットを定義します。「レプリケートされた属性のセットを管理」をクリックして既存のセットの定義を表示し、それを編集することもできます。
部分レプリケーションでは、レプリケーションアグリーメントに関連づけることができる属性セットは 1 つだけです。このセットには、レプリケートする属性だけで構成されたリストを含める必要があります。
- 属性セットを選んだら、「了解」をクリックします。部分レプリケーションの設定を変更したため、コンシューマレプリカを初期化し直す必要があることを示すメッセージが表示されます。「了解」をクリックすると、メッセージは消えます。
- 「有効」をクリックして、レプリケーションアグリーメントを有効な状態に戻します。
- レプリケートする属性によっては、コンシューマサーバーで実行されるスキーマチェックを無効にする必要があります。
- 他のマスターがこのレプリカとの間にレプリケーションアグリーメントを持つ場合、そのすべてにおいて同じ手順を繰り返し、同じ属性セットによる部分レプリケーションを有効にする必要があります。
- 次に、コンシューマレプリカを初期化するか、すでにレプリケートされていた場合は再初期化します。次の「レプリカの初期化」を参照してください。
レプリカの初期化
レプリケーションアグリーメントを作成したら、レプリケーションを実際に開始する前にコンシューマレプリカを初期化する必要があります。初期化時は、サプライヤレプリカからコンシューマレプリカにデータが物理的にコピーされます。
特定のエラーが発生した場合、または設定を変更した場合は、レプリカを初期化し直す必要があります。初期化し直したときは、コンシューマ側のレプリケート されたサフィックスは削除され、マスター側のサフィックスの内容に置き換えられます。これにより、レプリカの同期が確保され、レプリケーションの更新が再 開されます。また、ここで説明するどの方法で初期化を行なっても、コンシューマレプリカのインデックスは自動的にふたたび作成されるため、クライアントか らの読み取り要求にもただちに正しく対応できます。
初期化のタイミング
レプリカの初期化は、関連する両方のレプリカの設定が完了したあとで、レプリケーションを開始する前に行う必要があります。サフィックスに含まれるデータ全体がコンシューマにコピーされると、サプライヤはコンシューマに対する更新処理を開始します。
通常の運用では、コンシューマを初期化し直す必要はありません。しかし、何らかの理由で 1 つのマスターレプリカをバックアップから復元した場合、そのレプリカが更新するすべてのレプリカを初期化し直す必要があります。マルチマスターレプリケー ションでは、他のマスターによって更新されたコンシューマであれば、初期化し直す必要がない場合もあります。
コンソールを使ってレプリカをオンラインで初期化するか、コマンド行を使って手動で初期化できます。コンソールを使ったオンライン初期化は、少数のコン シューマを初期化する場合に便利です。レプリケーションアグリーメントからレプリカを直接オンラインで初期化できます。ただし、この方法ではレプリカは 1 つずつ初期化されるため、多数のレプリカを処理する場合には適していません。コマンド行を使った手動による初期化は、1 つの LDIF ファイルから多数のコンシューマを同時に初期化できるので、多数のコンシューマを初期化する場合に効果的です。
最後に、経験が豊富な管理者であれば、Directory Server 5.2 に新たに搭載されたバイナリコピー機能を利用することで、マスターレプリカまたはコンシューマレプリカのクローンを作成できます。この機能にはある種の制 限が適用されるため、処理時間の短縮を見込めるのは、たとえば百万件単位のエントリを含むレプリカなど、大容量のデータベースファイルを持つレプリカだけ です。
マルチマスターレプリケーションにおけるレプリカの初期化
マルチマスターレプリケーションの場合、次の順序でレプリカを初期化する必要があります。
- 1 つのマスターが、レプリケーション対象の完全なデータセットを保持していることを確認します。その他の各マスターのレプリカを初期化するには、このマスターを使います。
- それぞれのマスターから、またはいずれかのマスターの LDIF ファイルからコンシューマレプリカを初期化します。
カスケード型レプリケーションでのレプリカの初期化
カスケード型レプリケーションの場合、常に次の順序でレプリカを初期化する必要があります。
- マルチマスターレプリケーションとの組み合わせでは、1 つのマスターが、レプリケーション対象の完全なデータセットを保持していることを確認します。その他の各マスターのレプリカを初期化するには、このマスターを使います。
- それぞれのマスターレプリカから、最初の階層のハブレプリカに属するレプリカを初期化します。
- ハブの構成が複数の階層に分かれている場合、各階層を上から順に初期化していきます。
- 最後の階層のハブレプリカから専用コンシューマのレプリカを初期化します。
マルチマスター初期化後のマスター間の一致
マルチマスターレプリケーションでは、あるマスターの初期化中に他のマスターが変更を処理することもあります。このため、初期化が完了した時点で、新しい マスターは初期化データに含まれていなかった新しい更新を受け取る必要があります。初期化には時間がかかるため、その間に発生する未適用の更新の数も問題 となります。
これらの未適用更新が適用されるように、新たに初期化されたマスターは、初期化後、クライアント側からの操作に対して自動的に読み取り専用モードに設定さ れます。この設定は、コンソールを使ったオンライン初期化、コマンド行から LDIF ファイルを使った初期化、バイナリコピーを使ったバックアップの実行など、初期化の種類に関係なく行われます。これは、Sun ONE Directory Server 5.2 の新機能です。
したがって、マルチマスター設定の初期化後のマスターは、レプリケーションの更新を処理し、クライアントからの読み取り操作を受け付けますが、すべての書き込み操作に対してはリフェラルを返します。リフェラルは、「マルチマスターの詳細設定」で説明されている手順に従って定義できます。マスターのモードは、次の場合に読み書きモードに変わります。
- ds5BeginReplicaAcceptUpdates 設定属性を start に設定し、更新の受け付けを明示的に可能にします。更新の受け付けを有効にする前に、新しいマスターレプリカの内容が他のマスターと一致していることを確 認する必要があります。確認には、Directory Server コンソールのレプリケーション設定パネル、またはコマンド行 (後述する手順を参照) を使います。
更新の受け付けを有効にする前に、新しいマスターが他のマスターと完全に同期していることを確認できるので、新たに初期化されたマスターの更新を有効にする方法としては、手動による処理をお勧めします。
- 事前に ds5referralDelayAfterInit 属性が設定されている場合、所定の時間が経過したあとにマスターレプリカは自動的に読み書きモードに切り替わります。この属性は、サーバー情報のマスターレプリカごとに設定できます。
この属性を設定するときは、初期化後に新しいマスターレプリカが内容を他のマスターと一致するために必要な時間を考慮する必要があります。この処理に要す る時間は、予定される初期化の規模と所要時間、およびその他のマスターで並行して行われる更新の頻度によって異なります。初期化後、マスターが更新をレプ リケートしている最中に新たな更新を受け付けた場合、予期せぬエラーが発生することがあります。レプリケーションエラーが発生したときは、『Sun ONE Directory Server Reference Manual』の付録 A 「エラーコード」を参照してください。
コンソールによる更新の受け付け開始
マルチマスターレプリカの初期化後に、更新の受け付けを明示的に開始する手順は、次のとおりです。
- Directory Server コンソールの最上位の「設定」タブで、「データ」ノードを展開し、レプリケートされたサフィックスのノードを展開し、サフィックスの下の「レプリケーション」ノードを選択します。
レプリカが初期化され、現時点では更新処理に対してリフェラルを返していることを示すメッセージが右側のパネルに表示されます。自動的なリフェラル遅延が 有効であることを示すメッセージが表示される場合でも、この手順を使って自動遅延の代わりに受け付けの開始を明示的に指定できます。
- insync ツールを使って、レプリカの状態が他のすべてのマスターと一致していることを確認します。すべてのサーバーで変更の遅れがゼロである場合、またはそのレプリカに適用する更新がなかった場合 (遅れが -1 となる場合) は、すべてのレプリカが同期しています。詳細については、『Sun ONE Directory Server Reference Manual』の第 1 章にある「insync」を参照してください。
- メッセージの右にあるボタンをクリックして、ただちに更新の受け付けを開始します。
コマンド行による更新の受け付け開始
マルチマスターレプリカの初期化プロセスを自動化するスクリプトで、次のコマンドを実行することができます。このコマンドは、マスターレプリカ間の一致を確認し、更新の受け付けを明示的に有効にします。
- insync ツールを使って、レプリカの状態が他のすべてのマスターと一致していることを確認します。すべてのサーバーで変更の遅れがゼロである場合、またはそのレプリカに適用する更新がなかった場合 (遅れが -1 となる場合) は、すべてのレプリカが同期しています。詳細については、『Sun ONE Directory Server Reference Manual』の第 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.pl -r コマンドを使います。詳細は、「コマンド行からの LDIF へのエクスポート」を参照してください。これらのコマンドを使ってレプリカをエクスポートするときは、-r オプションを指定する必要があります。
次の例は、dc=example,dc=com レプリカ全体を example_master.ldif というファイルにエクスポートします。
次に、必要に応じて LDIF ファイルをフィルタリングし、それをコンシューマホストに転送して、コンシューマレプリカを初期化します。
部分レプリケーションのための LDIF ファイルのフィルタリング
部分レプリケーションを設定したときは、エクスポートした LDIF ファイルをコンシューマサーバーにコピーする前に、不要な属性をフィルタリングする必要があります。この処理を行うために、Directory Server には fildif というツールが用意されています。このツールは、指定した LDIF ファイルをフィルタリングし、レプリケーションアグリーメントに定義されている属性セットが許可する属性だけを残します。
このツールはサーバーの設定を読み取り、属性セットの定義を決定します。設定ファイルの読み取りが必要になるため、fildif ツールはルートとして実行する必要があります。たとえば、次のコマンドは、前の例で dc=example,dc=com サフィックスからエクスポートされたファイルをフィルタリングします。
# CAMUS=/var/Sun/mps/slapd-camus
# /var/Sun/mps/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\, c=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 ツールの完全なコマンド行構文は、『Sun ONE Directory Server Reference Manual』の第 1 章にある「LDIF Command-Line Utilities」で説明しています。
fildif ツールを使って作成した filtered.ldif ファイルを使って、このレプリケーションアグリーメントの対象となるコンシューマを初期化できます。ファイルをコンシューマサーバーに転送し、次に説明する手順に従ってインポートします。
コンシューマレプリカへの LDIF ファイルのインポート
マスターレプリカの内容が含まれている LDIF ファイルをコンシューマレプリカにインポートするには、Directory Server コンソールのインポート機能を使用するか、ldif2db コマンドまたは ldif2db.pl スクリプト (Solaris パッケージではdirectoryserver ldif2db または directoryserver ldif2db-task) を使用します。その他すべてのインポート処理と同様に、インポートを行うには、Directory Manager のバインド DN とパスワードをスクリプトに指定する必要があります。これらのインポート方法については、「コマンド行からの LDIF のインポート」を参照してください。
次の例は、LDIF ファイルをインポートして、dc=example,dc=com コンシューマレプリカを初期化する方法を示しています。
ldif2db.pl スクリプトを使う場合、事前にサーバーを停止する必要はありません。詳細については、『Sun ONE Directory Server Reference Manual』の第 2 章にある「ldif2db.pl」を参照してください。
バイナリコピーによるレプリカの初期化
Directory Server 5.2 に新たに搭載されたバイナリコピー機能は、1 つのサーバーのバイナリバックアップファイルを使って、別のサーバー上の同じディレクトリの内容を復元することで、サーバー全体のクローンを作成します。 この高度な機能では、Directory Server 上のデータベースファイルとの間で情報をやり取りします。この機能は、経験が豊富な管理者以外は使用しないでください。
バイナリコピーの制限
バイナリコピー機能は、あるマシンから別のマシンにデータベースファイルを移動するため、次の制限が厳密に適用されます。
- どちらのマシンも同じハードウェアと同じオペレーティングシステム (サービスパック、パッチも含む) を使用する
- どちらのマシンにも同じバージョンの Directory Server をインストールする。バイナリ形式 (32 ビットまたは 64 ビット)、サービスパックとパッチのレベルも同一である必要がある
- どちらのサーバーも同じディレクトリツリーを持ち、同じサフィックスに分割されている。すべてのサフィックスのデータベースファイルを一度にコピーすることが必要で、サフィックスを個別にコピーすることはできない
- どちらのサーバーでも各サフィックスに VLV (仮想リスト表示) インデックスも含めて同じインデックスを設定する。サフィックスのデータベースには、同じ名前をつける必要がある
- コピーする Directory Server には o=NetscapeRoot サフィックスを含めることはできない。つまり、Directory Server を Sun ONE 管理サーバーの設定ディレクトリにすることはできない
- 各サーバーには、レプリカとして同じサフィックスが設定され、両方のサーバーで各レプリカは同じ役割 (マスター、ハブ、またはコンシューマ) を持つ必要がある。部分レプリケーションを設定する場合は、すべてのマスターサーバーで同様に設定する必要がある
- どちらのサーバーでも属性の暗号化を使用できない
- 属性値の一意性プラグインが有効な場合は、両方のサーバーで設定を共通させる。また、次に説明する手順で、新しいコピーを設定し直す必要がある
上の条件を満たす環境では、別のマスターサーバーのバイナリコピーからマスターを初期化または再初期化したり、別のコンシューマサーバーのバイナリコピー からコンシューマを初期化または再初期化したりできます。次の 2 つの手順は、バイナリコピーの実行方法を示しています。一つはサーバーを停止せずに行う方法で、もう一つはディスクスペースの消費を最小限に抑える方法で す。
サーバーの停止を必要としないバイナリコピー
次の手順は、通常のバックアップ機能を使ってサーバーのデータベースファイルのコピーを作成するので、バイナリコピーを実行するときは、この方法をお勧め します。通常のバックアップを実行することで、サーバーを停止しなくても、すべてのデータベースファイルを一定の状態に維持できます。
ただし、この手順には注意を要する制限があります。バックアップと復元の処理によって、同じマシンにデータベースファイルのコピーが作成されるため、各マ シンでこれらのファイルが占有するディスクスペースの容量が 2 倍になります。また、これらのファイルに対する実際のコピー処理は、ディレクトリに G バイト単位のデータが含まれる場合、時間がかかります。ディスクスペースが限られていたり、データベースファイルのサイズが極端に大きい場合の対応につい ては、「ディスクスペースの消費量を最小限に抑えるバイナリコピー」を参照してください。
- 新しいレプリカのターゲットマシンに Directory Server をインストールし、必要に応じてサーバーの新しいインスタンスを作成します。次に、「バイナリコピーの制限」に従ってインスタンスを設定します。
- このレプリカに関連するレプリケーショントポロジにすべてのレプリケーションアグリーメントを作成します。これには、サプライヤからこのレプリカへのアグリーメントも含まれ、専用コンシューマ以外では、このレプリカから各コンシューマへのアグリーメントも含まれます。
- 初期化するレプリカと同じ種類 (マスター、ハブ、コンシューマのどれか) の、完全に設定され、初期化されたサフィックスを選択し、「コンソールを使用したサーバーのバックアップ」の手順に従って通常のバックアップ処理を行います。
- バックアップディレクトリからターゲットマシンのディレクトリにファイルをコピーまたは転送します。この操作には、ftp コマンドなどを使います。
- 「バックアップからのデータの復元」の手順に従って、ファイルをターゲットサーバーにロードします。
- マルチマスターレプリケーションの新しいマスターを初期化したときは、「マルチマスター初期化後のマスター間の一致」の手順に従って、新しいレプリカがクライアントからの更新処理を受け付けるように設定します。
ディスクスペースの消費量を最小限に抑えるバイナリコピー
次の手順では、データベースファイルのバックアップコピーを作成しないため、ディスクスペースの消費が少なく、処理に要する時間も少なくなります。ただし、データベースファイルを一貫した状態に保つため、クローン作成の対象となるサーバーを停止する必要があります。
警告
マルチマスターレプリケーションにすでに組み込まれているマスターの再初期化に、この手順を使うことはできません。この手順を利用できるのは、コンシュー マサーバーの再初期化、または新しいマスターサーバーの初期化だけです。既存のマスターレプリカを再初期化するときは、オンラインによる初期化を行い、 LDIF ファイルをインポートするか、「サーバーの停止を必要としないバイナリコピー」の手順を実行します。
- 新しいレプリカのターゲットマシンに Directory Server をインストールし、必要に応じてサーバーの新しいインスタンスを作成します。次に、「バイナリコピーの制限」に従ってインスタンスを設定します。
- このレプリカに関連するレプリケーショントポロジにすべてのレプリケーションアグリーメントを作成します。これには、サプライヤからこのレプリカへのアグリーメントも含まれ、専用コンシューマ以外では、このレプリカから各コンシューマへのアグリーメントも含まれます。
- 「Directory Server の起動と停止」の説明に従って、初期化または再初期化するサーバーを停止します。
- 初期化するレプリカと同じ種類 (マスター、ハブ、コンシューマのどれか) の、完全に設定され、初期化されたレプリカを選択し、このサーバーも停止します。マルチマスター設定に組み込まれているマスターレプリカのクローンを作成 するときは、それを停止する前に、その他のマスターから最新のすべての変更が完全に反映されていることを確認する必要があります。
- トランザクションログを含むすべてのデータベースファイルをソースレプリカマシンからターゲットマシンにコピーまたは転送します。この処理には、ftp コマンドなどを使います。ファイルの位置を変更していない限り、データベースファイルとトランザクションログは ServerRoot/slapd-serverID/db ディレクトリに保存されています。
マスターレプリカまたはハブレプリカを初期化するときは、更新履歴ログに記録されているすべてのファイルもコピーする必要があります。更新履歴ログは、デフォルトでは ServerRoot/slapd-serverID/changelog ディレクトリにあります。
- ソースサーバーとターゲットサーバーの両方を再起動します。
参照整合性プラグインの有効化
参照整合性プラグインを使っている場合、すべてのマスターサーバーでそれを有効にする必要があります。ハブサーバーまたはコンシューマサーバー上のプラグインを有効にする必要はありません。詳細は、「レプリケーションにおける参照整合性の使用」を参照してください。
SSL を経由するレプリケーション
すべてのレプリケーション操作が SSL 接続を経由するように、レプリケーションに関連する Directory Server を設定できます。この設定を行う手順は、次のとおりです。
- サプライヤサーバーとコンシューマサーバーの両方を、SSL を使用するように設定します。
詳細は、第 11 章「セキュリティの実装」を参照してください。
注 次のサプライヤサーバー証明書では、SSL を経由するレプリケーションは失敗します。
- コンシューマサーバー上のサフィックスにレプリケーションが設定されていない場合、「コンシューマレプリカの有効化」の説明に従って、そのサフィックスを有効にします。
- 「コンシューマの詳細設定」の手順に従って、コンシューマの証明書エントリの DN を別のレプリケーションマネージャとして定義します。
- サプライヤサーバー上のサフィックスにレプリケーションが設定されていない場合「ハブレプリカの有効化」または 「マスターレプリカの有効化」の説明に従って、そのサフィックスを有効にします。
- サプライヤサーバーで新しいレプリケーションアグリーメントを作成し、セキュリティ保護された SSL ポート上のコンシューマに更新を送信します。詳細な方法については、「レプリケーションアグリーメントの作成」を参照してください。セキュリティ保護されたポートをコンシューマサーバーに設定し、パスワードまたは証明書のどちらを使うかについて、SSL オプションを選択します。選択した SSL オプションの DN (レプリケーションマネージャまたは証明書) を入力します。
レプリケーションアグリーメントの設定が完了すると、サプライヤはすべてのレプリケーション更新メッセージを SSL 経由でコンシューマに送信します。証明書を使用するオプションを選んだ場合は、証明書が利用されます。SSL のアグリーメント設定を使ってコンソールからカスタマーの初期化を行う場合も、セキュリティ保護された接続が使われます。
WAN を経由するレプリケーション
Sun ONE Directory Server 5.2 では、広域ネットワーク (WAN) に接続されたマシン間のマルチマスターレプリケーション (MMR) を含め、あらゆる種類のレプリケーションを行えます。レプリケーションメカニズムを内部的に見直したことで、応答時間が遅く、帯域幅の狭いネットワークで も、妥当な遅延でサプライヤサーバーがコンシューマを初期化、更新できるようになりました。
注 レプリケーションの実際の遅延と更新パフォーマンスは、修正頻度、エントリのサイズ、サーバーハードウェア、平均応答時間、平均帯域幅など、多くの要因に 左右されます。利用環境でのレプリケーションについて疑問がある場合は、Sun Professional Service の担当者に連絡してください。
デフォルトでは、レプリケーションメカニズムの内部パラメータは WAN に合わせて最適化されています。ただし、前述の要因などが原因でレプリケーションが遅くなるときは、ウィンドウサイズとグループサイズのパラメータを調節 してみてください。また、ネットワークのピーク時を避けてレプリケーションをスケジュールすることで、ネットワークの全体的な利用率を高めることができま す。最後に、Solaris、Linux の各プラットフォームで稼動する Directory Server は、帯域幅の使用を最適化するためにレプリケーションデータの圧縮に対応しています。
ネットワークパラメータの設定
ネットワーク経由でエントリをより効率的に送信するために、レプリケーションメカニズムがエントリをグループ化する方法は、次の 2 つのパラメータによって決定されます。これらのパラメータは、サプライヤとコンシューマがレプリケーション更新メッセージと、その確認応答を交換する方法 に影響します。
- ウィンドウサイズ (デフォルト値は 10) : コンシューマからの即時の確認応答なしに送信できる更新メッセージの最大数を表します。WAN 環境では、メッセージごとに確認応答を待つよりも、多数のメッセージを一度に送信したほうが効率的です。
- グループサイズ (デフォルト値は 1) : 1 つの更新メッセージに入れることのできるデータ修正の最大数を表します。データのサイズとネットワークのプロパティによっては、より大きなメッセージ、つ まりグループサイズがより大きいメッセージを送信するほうが効率的になります。
ほとんどの状況では、デフォルト値の利用が最適です。しかし、ディレクトリエントリの数が極端に多い、または少ない場合、またはレプリケートが必要な修正 の頻度が極端に高い場合は、これらのパラメータを変更して、WAN 経由のレプリケーションパフォーマンスに与える影響をテストできます。
この 2 つのネットワークパラメータは、すべてのレプリケーションアグリーメントで設定できます。これにより、各コンシューマのネットワーク状態に応じてレプリケーションパフォーマンスを調節できます。
ウィンドウとグループのサイズパラメータを変更するときに、レプリケーションを中断する必要はありません。
- Directory Server コンソールで「設定」タブを選び、「データ」ノードを展開し、レプリケートするサフィックスのノードを展開します。
- サフィックスの下の「レプリケーション」ノードを選び、右側のペインで設定するレプリケーションアグリーメントを選んで、「編集」をクリックします。
- 「レプリケーションアグリーメント」ダイアログの「ネットワーク」タブを選び、ウィンドウサイズの新しい値 (1 〜 1000) とグループサイズの新しい値 (1 〜 100) を入力します。グループサイズは、ウィンドウサイズ以下に設定する必要があります。
- 「了解」をクリックして新しい値を保存し、「レプリケーションアグリーメント」ダイアログを閉じます。
新しいパラメータ値はただちに有効となり、対応するコンシューマに次にレプリケーション更新を送信するときに適用されます。
レプリケーションアクティビティのスケジュール
レプリカ間の即時同期が重要でない場合は、ネットワーク利用率が低い時間帯に更新をスケジュールして、WAN 経由のデータレプリケーションを実行できます。より多くのネットワーク資源を利用できれば、更新はより高速で処理され、ネットワークの利用率がすでに高い 場合は、レプリケーション メッセージによってネットワークにそれ以上の負荷がかかることはありません。
レプリケーションアグリーメントを設定することで、コンシューマごとに日次または週次の更新をスケジュールできます。
- Directory Server コンソールで最上位の「設定」タブを選び、「データ」ノードを展開し、レプリケートするサフィックスのノードを展開します。
- サフィックスの下の「レプリケーション」ノードを選び、右側のペインで設定するレプリケーションアグリーメントを選んで、「編集」をクリックします。
- 「レプリケーションアグリーメント」ダイアログの「スケジュール」タブを選び、週次スケジュールの隣のラジオボタンを選びます。
- スケジュールを定義します。
- 週次更新では、レプリケーションを行う曜日 (複数を指定できる) の隣のチェックボックスを選択します。各曜日のレプリケーションをさらに細かく指定するときは、時間帯を 24 時間表記で指定します。
- 日時更新では、「すべて」をクリックしてすべての曜日を選択し、レプリケーションを行う時間帯を 24 時間表記で指定します。
深夜 0 時をまたがる時間帯は設定できません。
- 「了解」をクリックして新しい値を保存し、「レプリケーションアグリーメント」ダイアログを閉じます。
新しいスケジュールはただちに有効になり、対応するコンシューマに対する次回のレプリケーション更新は、スケジュールされた次回の更新まで行われなくなります。
データの圧縮
レプリケーションで使われる帯域幅を節約するために、コンシューマの更新時に送信されるデータを圧縮するようにレプリケーションを設定できます。レプリ ケーションメカニズムは、Zlib 圧縮ライブラリを使用します。これは、対応している Solaris および Linux プラットフォームだけで利用できます。圧縮を利用するには、Solaris または Linux プラットフォームでサプライヤとコンシューマの両方が稼動している必要があります。
レプリケーションの圧縮の設定は、マスターサーバー側のレプリケーションアグリーメントエントリに含まれる ds5ReplicaTransportCompressionLevel 属性だけを使って行われます。この属性には、次のいずれかの値を指定できます。
0 - 圧縮を行いません。これは、ds5ReplicaTransportCompressionLevel 属性が定義されていない場合のデフォルトの設定です。
1 - Zlib ライブラリのデフォルトの圧縮レベルを使用します。
2 - Zlib ライブラリの最適サイズの圧縮レベルを使用します。
3 - Zlib ライブラリの最速の圧縮レベルを使用します。
各圧縮レベルを実験的に使用し、レプリケーションの用途に合わせて WAN 環境で最適な結果を得られるオプションを選択します。圧縮と解凍のプロセスによってレプリケーション速度が低下するため、遅延があまり問題とならない LAN (ローカルエリアネットワーク) ではこのパラメータを使用しないでください。
たとえば、east.example.com にあるコンシューマに最速圧縮オプションを使ってレプリケーション更新を送信するには、次の ldapmodify コマンドを実行します。
ldapmodify -h host -p port -D "cn=Directory Manager" -w password
dn: cn=east.example.com:389,cn=replica,cn="suffixDN",
cn=mapping tree,cn=config
changetype: modify
add: ds5ReplicaTransportCompressionLevel
ds5ReplicaTransportCompressionLevel: 3
^Dレプリケーショントポロジの変更
ここでは、レプリケーションアグリーメントの編集と削除、レプリカの昇格と降格、無効化、コンシューマの強制更新、更新履歴ログの管理など、既存のレプリケーショントポロジを管理する手順について説明します。
レプリケーションアグリーメントの管理
マスターサフィックスのレプリケーションパネルでは、レプリケーションアグリーメントの設定を変更して、アグリーメントの認証情報の変更、特定のコンシューマに対するレプリケーションの中断、トポロジからのコンシューマの削除を実行できます。
レプリケーションマネージャの変更
レプリケーションアグリーメントを編集して、コンシューマサーバーへのバインドに使われるレプリケーションマネージャの識別情報を変更できます。レプリ ケーションが中断されないように、レプリケーションアグリーメントを変更する前に、新しいレプリケーションマネージャエントリまたはコンシューマの証明書 エントリを定義する必要があります。ただし、バインドの失敗によってレプリケーションが中断された場合、レプリケーション回復設定の制限内でエラーを修正 したときは、レプリケーションメカニズムによって必要なすべての更新が自動的に送信されます (「コンシューマの詳細設定」を参照)。
コンシューマの認証に使うレプリケーションマネージャを変更する手順は、次のとおりです。
- Directory Server コンソールの最上位の「設定」タブで、「データ」ノードを展開し、レプリケートされたサフィックスのノードを展開し、サフィックスの下の「レプリケーション」ノードを選択します。
- 右側のパネルで変更するレプリケーションアグリーメントを選び、「編集」をクリックします。
- 「レプリケーションアグリーメント」ダイアログで、「接続」タブを選びます。
ステータス行には、コンシューマサーバーのホスト名とポート番号が表示されます。
- DN とパスワードのフィールドを変更します。別のレプリケーションマネージャエントリの DN とパスワードを入力するか、コンシューマサーバー上の証明書エントリの DN を入力します。
- このレプリケーションアグリーメントが、セキュリティ保護されたポートで SSL を使用するときは、「オプション」ボタンをクリックして、セキュリティ保護された認証の種類を選択することもできます。パスワードを使った接続では、サプ ライヤは簡単な認証と指定の DN、および暗号化された SSL 接続による通信を利用します。証明書を使った接続では、「DN」フィールドの内容は証明書エントリの DN を意味し、パスワードは必要ありません。
既存のレプリケーションアグリーメントでセキュリティ保護ありをセキュリティ保護なしに切り替えたり、その反対に切り替えることはできません。別のセキュリティ設定でレプリケーションを有効にするには、別のレプリケーションアグリーメントを作成する必要があります。
- 「了解」をクリックして、変更を保存します。
レプリケーションアグリーメントの複製
レプリケーションアグリーメントを複製することで、大規模なレプリケーショントポロジでサプライヤレプリカの多数のコンシューマを簡単に設定できます。
- Directory Server コンソールの最上位の「設定」タブで、「データ」ノードを展開し、レプリケートされたサフィックスのノードを展開し、サフィックスの下の「レプリケーション」ノードを選択します。
- レプリケーションアグリーメントのリストから、複製するアグリーメントを 1 つ選択します。コンシューマとの接続をセキュリティ保護する新しいアグリーメントを作成するときは、セキュリティ保護されたポートを使用する既存のアグ リーメントを選択する必要があります。セキュリティ保護されていないアグリーメントを新たに作成する場合は、セキュリティ保護されていないアグリーメント を選択する必要があります。
「編集」をクリックして「レプリケーションアグリーメント」ダイアログのタブを表示し、このアグリーメントの設定を確認します。これらのタブで行う設定については、次の各項で説明しています。
- 「接続」タブについては、「レプリケーションマネージャの変更」を参照してください。
- 「スケジュール」タブと「ネットワーク」タブについては、「WAN を経由するレプリケーション」を参照してください。
- 「レプリケートされた属性」タブについては、「部分レプリケーションの設定」を参照してください。
- 同じレプリケーションアグリーメントを選択した状態で、「複製」ボタンをクリックします。
- 新しいコンシューマのホスト名とポート番号をリストから選択するか、「ホストを追加」ボタンをクリックして、別のホ ストとポートを指定します。リストと「ホストを追加」ダイアログでは、複製するコンシューマアグリーメントと同じ種類のセキュリティ (セキュリティ保護あり、またはなし) が設定されたコンシューマだけを選択できます。
- リストのホスト名が選択されていることを確認し、「了解」をクリックして、そのコンシューマサーバーの新しいレプリケーションアグリーメントを作成します。
- 新しいアグリーメントには、既存のアグリーメントのすべての設定情報が複製されます。つまり、2 つのサーバーにまったく同じレプリケーションマネージャエントリを定義し、同じパスワードを使用する必要があります。レプリケーションマネージャの DN の変更など、新しいアグリーメントの設定を変更するときは、リストからそのアグリーメントを選択し、「編集」をクリックします。
レプリケーションアグリーメントの無効化
レプリケーションアグリーメントを無効にすると、そのアグリーメントに指定されているコンシューマに対してマスターが更新を送信しなくなります。そのサー バーのレプリケーションは停止されますが、アグリーメントに記録されているすべての設定は残されます。あとからまたアグリーメントを有効にすることで、レ プリケーションを再開できます。中断後のレプリケーションメカニズムの再開については、次の「レプリケーションアグリーメントの有効化」を参照してください。
レプリケーションアグリーメントを無効にする手順は、次のとおりです。
- Directory Server コンソールの最上位の「設定」タブで、「データ」ノードを展開し、レプリケートされたサフィックスのノードを展開し、サフィックスの下の「レプリケーション」ノードを選択します。
- 右側のパネルで、無効にするレプリケーションアグリーメントを選びます。
- アグリーメントのリストの下で、「アクション」>「アグリーメントを無効に」の順に選択します。
- 「はい」をクリックして、レプリケーションアグリーメントが無効になったことを確認します。
リスト上のアグリーメントのアイコンが変化し、無効になったことを示します。
レプリケーションアグリーメントの有効化
レプリケーションアグリーメントを有効にすると、指定のコンシューマのレプリケーションが再開されます。ただし、レプリケーションの回復設定で許容される 時間より長くレプリケーションを中断していた場合は、別のサプライヤによるコンシューマの更新が行われないため、コンシューマを初期化し直す必要がありま す。レプリケーション回復設定は、このサプライヤの更新履歴ログの最大サイズと有効期限、およびコンシューマのパージ遅延です (「コンシューマの詳細設定」を参照)。
中断時間が短く、レプリケーションが回復された場合は、アグリーメントがふたたび有効になったときに、マスターが自動的にそのコンシューマを更新します。
レプリケーションアグリーメントを有効にする手順は、次のとおりです。
- Directory Server コンソールの最上位の「設定」タブで、「データ」ノードを展開し、レプリケートされたサフィックスのノードを展開し、サフィックスの下の「レプリケーション」ノードを選択します。
- 右側のパネルで、有効にするレプリケーションアグリーメントを選びます。
- アグリーメントのリストの下にある「有効」ボタンをクリックします。
- 必要に応じて、コンシューマレプリカを初期化し直します。
レプリケーションアグリーメントの削除
レプリケーションアグリーメントを削除すると、対応するコンシューマのレプリケーションは停止され、アグリーメントに関するすべての設定情報が失われます。あとからレプリケーションを再開する必要があるときは、「レプリケーションアグリーメントの無効化」の説明に従って、アグリーメントを削除せずに無効にします。
レプリケーションアグリーメントを削除する手順は、次のとおりです。
- Directory Server コンソールの最上位の「設定」タブで、「データ」ノードを展開し、レプリケートされたサフィックスのノードを展開し、サフィックスの下の「レプリケーション」ノードを選択します。
- 右側のパネルで、削除するレプリケーションアグリーメントを選びます。
- アグリーメントのリストの右にある「削除」ボタンをクリックします。
- 「はい」をクリックして、レプリケーションアグリーメントの削除を確認します。
レプリカの昇格と降格
レプリカの昇格と降格は、レプリケーショントポロジで、レプリカの役割を変更することを意味します。専用コンシューマをハブに変更したり、ハブをマスター に変更したりできます。また、マスターをハブに変更したり、ハブを専用コンシューマに変更したりすることもできます。ただし、マスターを直接コンシューマ に格下げしたり、コンシューマを直接マスターに格上げすることはできません。
マルチマスターレプリケーションのメカニズムでレプリカの役割を変更できることで、トポロジがとても柔軟になります。コンシューマレプリカが処理を担当し ていたサイトの負荷が増え、複数のレプリカを持つハブによる処理が必要になることもあります。レプリカの内容に対して多数の変更が含まれるときは、ハブを マスターに昇格させることで、ローカルな変更に迅速に対応し、その変更を他のサイトの他のマスターにレプリケートできます。
レプリカの役割を変更する手順は、次のとおりです。
- Directory Server コンソールの最上位の「設定」タブで、「データ」ノードを展開し、レプリケートされたサフィックスのノードを展開し、サフィックスの下の「レプリケーション」ノードを選択します。
- 右側のパネルで、メニューから「変更」>「レプリカの昇格と降格」の順に選択します。
- レプリケーションウィザードでは、設定できる新しい役割だけを選択できます。次に、そのレプリカの新しい役割について、順に設定を行います。このとき、次の点に注意が必要です。
- マスターをハブに降格させると、レプリカは読み取り専用となり、残りのマスターに対してはリフェラルを送信するように設定されます。新しいハブは、設定されているすべてのコンシューマをハブまたは専用コンシューマとして維持します。
- シングルマスターレプリケーションでマスターをハブに降格させると、マスターレプリカの存在しないトポロジが作成されます。新しいマス ターを定義することを前提として、ウィザードでもこのような変更が可能です。ただし、マスターを降格させる前にマルチマスターとして新しいマスターを追加 し、初期化できるようにしておくことをお勧めします。
- ハブをコンシューマに降格させると、すべてのレプリケーションアグリーメントは削除されます。そのハブのコンシューマが他のハブまたはマ スターによって更新されるように設定されていない場合、そのコンシューマは更新されなくなります。これらのコンシューマが更新されるように、残りのハブま たはマスターに新しいアグリーメントを作成する必要があります。
- コンシューマをハブに昇格させると、更新履歴ログが有効になり、コンシューマとの間に新しいアグリーメントを定義できるようになります。
- ハブをマスターに昇格させると、レプリカは更新要求を受け付けるようになり、他のマスター、ハブ、または専用コンシューマとの間に新しいアグリーメントを定義できるようになります。
レプリカの無効化
レプリカを無効にすると、そのレプリカはレプリケーショントポロジから除外されます。設定されている役割 (マスター、ハブ、またはコンシューマ) に応じて、そのレプリカは更新されなくなり、更新を送信しなくなります。サプライヤを無効にすると、すべてのレプリケーションアグリーメントが削除されま す。そのレプリカをふたたび有効にするときは、これらのアグリーメントを作成し直す必要があります。
レプリカを無効にする手順は、次のとおりです。
- Directory Server コンソールの最上位の「設定」タブで、「データ」ノードを展開し、レプリケートされたサフィックスのノードを展開し、サフィックスの下の「レプリケーション」ノードを選択します。
- 右側のパネルで、メニューから「変更」>「レプリケーションを無効に」の順に選択します。
- 確認ダイアログが表示されるので、「はい」をクリックします。
- 必要に応じて、このサフィックスの書き込み権限とリフェラルをリセットします。これらの設定は、レプリカを無効にした時点の状態で残されます。たとえば、無効になったコンシューマは、無効になる以前のマスターレプリカに対して更新要求を送信します。
書き込み権限とリフェラルを変更するには、「設定」タブでこのサフィックスのノードを選択し、右側のパネルの「設定」タブで変更を加えます。詳細は、「アクセス権とリフェラルの設定」を参照してください。
更新履歴ログの移動
更新履歴ログは、特定のサプライヤレプリカに加えられるすべての変更を記録した内部レコードで、サーバーが他のレプリカに修正を加えるときに使われます。 更新履歴ログの内容はサーバーによって自動的に管理され、サーバーを再起動したあとでも、マルチマスター更新によって更新されます。
旧バージョンの 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 秒後です。その後、サプライヤは 160 秒おきに再試行を繰り返します。
サプライヤレプリカとコンシューマレプリカの間で、常に同期をとるレプリケーションアグリーメントを設定していても、オフライン状態の時間が 5 分を超えたレプリカをただちに最新の状態に戻すには、この方法では不十分です。
サーバーがオンライン状態に復帰した直後にディレクトリ情報を確実に同期させるには、Directory Server コンソールまたはカスタマイズ可能なスクリプトのどれかを利用できます。
コンソールによるレプリケーションの強制的な更新
コンシューマまたはマルチマスターレプリケーション設定のマスターが一定の時間を経過してオンライン状態に復帰したとき、レプリケーション更新をただちに送信させるためには、最新のディレクトリデータを保持しているサプライヤ上で次の手順を実行します。
- Directory Server コンソールの最上位の「設定」タブで、「データ」ノードを展開し、マスターレプリカのサフィックスのノードを展開し、サフィックスの下の「レプリケーション」ノードを選択します。
右側のパネルにレプリカのステータス情報が表示されます。
- 更新するコンシューマに対応するレプリケーションアグリーメントをリストから選択し、「アクション」>「ただちに更新を送信」の順にクリックします。
これにより、更新が必要な情報を保持しているレプリカに対してレプリケーションが開始されます。
コマンド行によるレプリケーションの強制的な更新
サプライヤに対してレプリケーションの更新がただちに転送されるように要求するスクリプトを、更新が必要なコンシューマから実行することもできます。このスクリプトを、コード例 8-1 に示します。
このスクリプト例をコピーして、適切な名前 (replicate_now.sh など) をつけてください。なお、コード例 8-1 のリストに含まれている変数には、実際の値を設定する必要があります。
注 このスクリプトは、サーバーがオフラインからオンラインに復帰したあとすぐに自動的に実行できるように設定できないため、管理者がこのスクリプトを実行する必要があります。
コード例 8-1 Replicate_Now スクリプトの使用例
#!/bin/sh
SUP_HOST=supplier_hostname
SUP_PORT=supplier_portnumber
SUP_MGRDN=supplier_directoryManager
SUP_MGRPW=supplier_directoryManager_passwd
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.$$
このスクリプトを使用する場合は、スクリプトに含まれている次の変数を、レプリケーション環境の実際の値に置き換える必要があります。
表 8-1 Replicate_Now 変数
SSL 接続を経由して更新処理を実行する場合、スクリプト中の ldapmodify コマンドを適切なパラメータと値で置き換える必要があります。詳細は、「LDAP クライアントでセキュリティを使用するための設定」を参照してください。
旧バージョンからのレプリケーション
ここでは、Sun ONE Directory Server の旧バージョンからのレプリケーションを設定する方法について説明します。
Sun ONE 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 を返しません。
Sun ONE 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 を使用できる利点は、レプリケートされた環境を簡単に移行できることです。レプリケートされた環境を移行するための手順について詳細は、『Sun ONE Directory Server インストールおよびチューニングガイド』の第 2 章にある「旧バージョンからのアップデート」を参照してください。
Directory Server 4.x のコンシューマとしての Directory Server 5.2 の設定
リリース 4.x の Directory Server のコンシューマとして Directory Server 5.2 を使うときは、次のように設定する必要があります。
- 「マスターレプリカの有効化」の説明に従って、レプリカをマスターレプリカとして有効にします。レプリカは 4.x サプライヤのコンシューマとなりますが、マスターレプリカとして設定する必要があります。
- Directory Server コンソールの最上位の「設定」タブで、「データ」ノードを展開し、レプリケートされたサフィックスのノードを展開し、サフィックスの下の「レプリケーション」ノードを選択します。
- このレプリカについて、右側のパネルで「変更」>「4.x との互換性を有効に」の順に選択します。または、「オブジェクト」メニューから「4.x との互換性を有効に」を選びます。
- 「4.x との互換性を有効に」ウィンドウが表示されるので、旧バージョンのサプライヤサーバーがバインドに使用するバインド DN とパスワードを指定します。バインド DN には、デフォルトのレプリケーションマネージャを含め、どのような管理エントリでも使用できます。バインド DN については、「レプリケーションマネージャの選択」を参照してください。
サプライヤがレプリケーション更新にサーバーのセキュリティ保護されたポートを使うときは、セキュリティ保護された認証を行えるように、サーバーの証明書エントリの DN を指定できます。
- 「了解」をクリックします。これで、このコンシューマレプリカは旧バージョンのサプライヤから更新を受信できます。
- 5.2 レプリカサーバーのスキーマが、4.x マスターからレプリケートされる内容が使用するすべての属性とオブジェクト クラスを定義していることを確認してください。
- 4.x マスターで作成された LDIF レプリカファイルをインポートして、5.2 レプリカを初期化します。このファイルの最初のエントリには、4.x レプリケーションメカニズムが必要とする copiedfrom 属性が含まれます。
サーバーで 4.x との互換性を有効にすると、デフォルトでインストールされている旧バージョンとのレプリケーションのプラグインが設定されます。このプラグインは、旧バージョンのサプライヤからの更新を処理し、レプリケートされるサフィックスの内容を更新します。
注 4.x との互換性を有効にしている限り、このレプリカはクライアントからすべての変更要求に対してリフェラルを返します。Directory Server 5.2 をマスターレプリカとして設定しても、このサフィックスでは変更要求は行われません。その代わりに、4.x サプライヤサーバーへのリフェラルが返されます。
旧バージョンのレプリケーションの設定を完了するには、Directory Server 5.2 にレプリケートする旧バージョンのサプライヤを設定する必要があります。4.x Directory Server にレプリケーションアグリーメントを設定する手順については、旧バージョンの Directory Server のマニュアルを参照してください。
Directory Server 5.1 スキーマの更新
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 $ serialNumer が削除されました。
- 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 の形式の更新履歴ログに依存している、Sun ONE Meta Directory などのアプリケーションで必要になる場合があります。これは、アプリケーションが更新履歴ログからデータを読み取るためです。
旧バージョン形式の更新履歴ログプラグインでは、Directory Server 5.2 を 4.x コンシューマレプリカのサプライヤとすることはできません。「旧バージョンからのレプリケーション」で 説明したように、4.x サプライヤの Directory Server 5.2 コンシューマだけがサポートされます。旧バージョン形式の更新履歴ログプラグインは、レプリケーションプロトコルとは無関係に動作し、レプリケーショント ポロジに影響しません。旧バージョン形式の更新履歴ログプラグインは、シングルマスター構成のどのサーバーでも有効にできます。これは、マルチマスター環 境では正しく動作しないので、この環境では有効にしないでください。
旧バージョン形式の更新履歴ログは、サーバーの 5.2 更新履歴ログとは別に維持されます。旧バージョン形式の更新履歴ログは、cn=changelog という特別なサフィックスの下で、独立したデータベースに格納されます。旧バージョン形式の更新履歴ログは、単一レベルの複数のエントリから構成されます。更新履歴ログの各エントリには changeLogEntry というオブジェクトクラスがあり、次の表に一覧表示されている属性を含めることができます。
表 8-2 旧バージョン形式の更新履歴ログエントリの属性
旧バージョン形式の更新履歴ログプラグインの有効化
旧バージョン形式の更新履歴ログプラグインの設定情報は、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
- サーバーを再起動します。サーバーの再起動については、「Directory Server の起動と停止」を参照してください。
旧バージョン形式の更新履歴ログの削除
更新履歴ログのエントリは、指定した一定時間後に自動的に削除されます。更新履歴ログからエントリを自動的に削除する期間を指定するには、cn=Retro Changelog Plugin、cn=plugins、cn=config エントリで nsslapd-changelogmaxage 設定属性を設定する必要があります。この属性を設定するには、次のようにコマンド行だけで設定できます。
ldapmodify -h host -p port -D "cn=Directory Manager" -p password
dn: cn=Retro Changelog Plugin,cn=plugins,cn=config
changetype: modify
replace: nsslapd-changelogmaxage
nsslapd-changelogmaxage: IntegerTimeunitnsslapd-changelogmaxage 属性は、次の形式の単一値属性です。
nsslapd-changelogmaxage: IntegerTimeunit
ここで、Integer は数字を表し、TimeUnit の s は秒、m は分、h は時間、d は日数、およびw は週を表します。次の例のように、Integer 変数と Timeunit 変数の間には空白を挿入しません。
nsslapd-changelogmaxage: 2d
旧バージョン形式の更新履歴ログは、更新記録ログに対する次回の処理時に削除されます。
旧バージョン形式の更新履歴ログへのアクセス
更新履歴ログは検索処理をサポートし、 次の形式のフィルタを含む検索用に最適化されています。
(&(changeNumber>=X)(changeNumber<=Y))
一般的な規則として、更新履歴ログのサイズを小さくするためにエントリを削除するとしても、旧バージョン形式の更新履歴ログでは追加または変更処理は実行 すべきではありません。旧バージョン形式の更新履歴ログで修正処理を実行する必要があるのは、デフォルトのアクセス制御ポリシーを修正する場合だけです。
旧バージョン形式の更新履歴ログが作成されると、次のアクセス制御規則がデフォルトで適用されます。
- 旧バージョン形式の更新履歴ログのトップエントリ cn=changelog に対する読み取り、検索、および比較の権限は、すべての認証ユーザー (userdn=anyone のユーザー。userdn=all で指定された匿名アクセスとは異なる) に付与される
- Directory Manager に対する暗黙の了承を除き、書き込みおよび削除アクセスは付与されない
更新履歴ログのエントリにはパスワードなどの重要な情報が含まれている場合があるので、読み取りアクセス権を匿名ユーザーに付与しないでください。認証さ れたユーザーにも内容の表示が許可されない場合でも、旧バージョン形式の更新履歴ログの内容へのアクセスをさらに制限することが必要なことがあります。
旧バージョン形式の更新履歴ログに対するデフォルトのアクセス制御ポリシーを変更するには、cn=changelog エントリの aci 属性を変更する必要があります。aci 属性の設定については、第 6 章「アクセス制御の管理」を参照してください。
レプリケーション状態の監視
新しいコマンド行ツールと Directory Server コンソールを使って、レプリケーションの状態を監視できます。
コマンド行ツール
レプリケーションの状態の監視には、次の 3 種類の新しいコマンド行ツールを利用できます。
- repldisc : レプリケーションに含まれるすべての既知のサーバーを検出し、テーブルを作成する
- insync : サプライヤレプリカと、1 つまたは複数のコンシューマレプリカの間の同期状態を示す
- entrycmp : 複数のレプリカに含まれる同じエントリを比較する
これらのツールは、次のディレクトリにあります。
ServerRoot/shared/bin
これらのツールの完全なコマンド行構文と使用例については、『Sun ONE Directory Server Reference Manual』の第 1 章にある「Replication Monitoring Tools」を参照してください。
レプリケーション状態タブ
Directory Server コンソールでレプリケーション状態の概要を確認する手順は、次のとおりです。
- Directory Server コンソールの最上位の「状態」タブで、「レプリケーション」ノードを選択します。
このサーバーに設定されている各レプリケーションアグリーメントに関する情報が、右側のパネルに表示されます。
- レプリケーションの状態を監視するには、「継続して再表示」チェックボックスを選択します。たとえば、レプリカの初期化がいつ完了したかを確認できます。
- コンシューマにまだレプリケートされていないマスター側の最後の変更を調べるには、「保留中の変更数」ボタンをク リックします。この処理は時間がかかることがあるため、実行するかどうかを確認するメッセージが表示されます。保留中の変更数を調べるには、コンシューマ 側の更新レコードをダウンロードし、それをマスター側の更新履歴ログと比較する必要があります。これらのログのサイズが大きい場合、多くの時間とサーバー リソースが使われます。
- 列の見出しをクリックしてサイズを変更することで、テーブルのレイアウトを変更できます。また、「表示オプション」ボタンをクリックして、表示する列だけを指定することもできます。次の表 8-3 は、このサーバーの各アグリーメントのテーブルの表示について指定できるレプリケーションパラメータを示しています。
表 8-3 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 つのエントリを作成すると、レプリケーションの競合解決メカニズムによって、2 番目に作成されたエントリの名前が自動的に変更されます。すべてのディレクトリエントリには、nsuniqueid オペレーショナル属性が指定する一意の識別子があり、ネーミングの競合が発生すると、一意でない DN の名前に一意の ID が追加されます。
最初のサーバーが 2 番目のサーバーに変更をレプリケートする前に 2 番目のサーバーでエントリが作成された場合、同じ 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 値と競合マーカー属性を削除します。たとえば、次のようにします。
1 つの値からなるネーミング属性を持つエントリの名前変更
ネーミング属性が 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 値と競合マーカー属性を削除します。たとえば、次のようにします。
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
注 一意の識別子属性 nsuniqueid は削除できないため、RDN の変更は 2 段階で実行されます。
- 新しい競合しない値をネーミング属性に指定して、エントリの名前を変更します。たとえば、次のようにします。
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
^Ddeleteoldrdn 属性の値に 1 を設定すると、一時的な属性と値のペアである o=TempName が削除されます。この属性を保持する場合は、deleteoldrdn 属性の値に 0 を設定します。
親のないエントリの競合の解決
エントリの削除操作がレプリケートされたとき、コンシューマサーバーが削除されるエントリが子エントリを持つことを検出した場合、競合解決処理によって glue エントリが作成され、親のないエントリをディレクトリに持つことを回避します。
同様に、エントリの追加後にレプリケーションが実行され、コンシューマサーバーが追加されたエントリの親エントリを検出できなかった場合も、競合解決処理は親を表す glue エントリを作成し、親のないエントリが追加されることを回避します。
glue エントリは、glue および extensibleObject というオブジェクトクラスを持つ一時的なエントリです。glue エントリは、次のいくつかの方法で作成されます。
- 競合解決処理が、一致する一意の識別子をともなう削除されるエントリを検出した場合、glue エントリは、glue オブジェクトクラスと nsds5ReplConflict 属性を加えて、そのエントリを復元する
この場合は、glue エントリを修正して glue オブジェクトクラスと nsds5ReplConflict 属性を削除し、通常のエントリに戻すか、または glue エントリとその子エントリを削除します。
- サーバーによって、glue および extensibleObject オブジェクトクラスを持つ必要最小限のエントリが作成される
このような場合は、意味のあるエントリになるようにエントリを修正するか、またはエントリとその子エントリをすべて削除します。
潜在的な相互運用性の問題の解決
メールサーバーのように属性の一意性に依存するアプリケーションとの相互運用性の理由から、nsds5ReplConflict 属性を持つエントリへのアクセスを制限する必要がある場合があります。これらのエントリへのアクセスを制限しない場合は、1 つの属性だけを要求するアプリケーションが元のエントリと nsds5ReplConflict を含む競合解決エントリの両方を取得し、処理が失敗します。
アクセスを制限するには、次のコマンドを使用して、匿名の読み取りアクセスを許可するデフォルトの ACI を変更する必要があります。
ldapmodify -h hostname -D "cn=Directory Manager" -w password
dn: dc=example,dc=com
changetype: modify
delete: aci
aci: (target ="ldap:///dc=example,dc=com")
(targetattr !="userPassword"
(version 3.0;acl "Anonymous read-search access";
allow (read, search, compare)(userdn = "ldap:///anyone");)
-
add: aci
aci: (target="ldap:///dc=example,dc=com")
(targetattr!="userPassword")
(targetfilter="(!(nsds5ReplConflict=*))")(version 3.0;acl
"Anonymous read-search access";allow (read, search, compare)
(userdn="ldap:///anyone");)
^D新しい ACI フィルタは、検索結果から nsds5ReplConflict 属性を持つすべてのエントリを除外します。