| Oracle® Fusion Middleware Oracle Directory Server Enterprise Editionアップグレードおよび移行ガイド 11gリリース1 (11.1.1.7.0) B72438-01 |
|
 前 |
 次 |
| Oracle® Fusion Middleware Oracle Directory Server Enterprise Editionアップグレードおよび移行ガイド 11gリリース1 (11.1.1.7.0) B72438-01 |
|
前 |
次 |
Directory Server Enterprise Edition 11gリリース1 (11.1.1.7.0)では、レプリケーション・トポロジ全体を自動的に移行できません。レプリケーション・トポロジを移行する場合、各サーバーを個々に移行する必要があります。ただし、通常はサービスをまったく中断せずにトポロジ全体を移行できます。
この章では、レプリケート対象のサーバーの移行における問題を次の内容で説明します。
Directory Server 11g 11gリリース1 (11.1.1.7.0)のマルチマスター・トポロジでは、マスターが数に制限なくサポートされます。このため、また他の変更などのために、移行を新しいサーバーを含む同一のトポロジに行うのではなく、トポロジを再設計した方がよい場合があります。続行する前に、『Oracle Directory Server Enterprise Editionデプロイメント・プランニング・ガイド』の第III部の論理的な設計に関する説明を参照してください。
レプリケートされた古いサーバー・インスタンスを移行する場合、通常はまずコンシューマから開始し、続いてハブを行い、マスターで終了します。このボトムアップのアプローチでは、1度に1つのサーバーのみが中断され、レプリケーション・トポロジのサーバーのブランチ全体を中断する必要がありません。このアプローチは、マスターおよびコンシューマ間で発生する可能性があるカスタム・スキーマの同期に関係する問題を回避するためにも役立ちます。
|
注意: バージョン5.2では、マスター数は最大4つまでに制限されているため、5.2サーバーを含むマルチマスター・レプリケーション構成では(任意のバージョンの)マスターは最大4つまでサポートされます。したがって、トポロジに5.2サーバーが含まれている場合、マスターはトポロジに4つまでしか含めることができません。 |
レプリケーション・トポロジおよび移行戦略によっては、レプリケート対象のサーバーを移行する際に特定の問題が発生する可能性があります。これらの問題は、次の項で説明します。
マルチマスターのレプリケーション・トポロジの移行で、11gリリース1 (11.1.1.7.0)のマスターが古いサーバーにレプリケートする場合が発生します。このような状況で11gリリース1 (11.1.1.7.0)サーバーのパスワード・ポリシー属性を変更し、古いサーバーにレプリケートを行うとオブジェクト・クラス違反が発生します。パスワード・ポリシー属性は、内部でサーバーによって管理されますが、バインド、ユーザーのパスワード変更または、userpassword属性を使用したエントリが追加されると、それらが更新されることがあります。
オブジェクト・クラス違反を回避するには、11gリリース1 (11.1.1.7.0)のマスターからレプリケートされるバージョン5.2のすべてのサーバーに、11gリリース1 (11.1.1.7.0)のパスワード・ポリシー・スキーマ・ファイル(00ds6pwp.ldif)を必ずコピーする必要があります。パスワード・ポリシー・スキーマ・ファイルがコピーされたら、バージョン5.2サーバーを再起動します。
可能であれば、レプリケート対象のサーバーは同じホスト名およびポート番号に移行する必要があります。レプリケート対象のサーバーのホスト名またはポート番号を変更する必要がある場合、そのサーバーをポイントするすべてのレプリケーション承諾は新しいサーバーをポイントするよう手動で更新する必要があります。たとえば、コンシューマ・サーバーをred.example.com:1389からblue.example.com:1389に移行した場合、red.example.com:1389をポイントするすべてのマスター上のレプリケーション承諾はblue.example.com:1389をポイントするよう手動で更新する必要があります。
トポロジ内の移行したマスターからコンシューマへのレプリケーション承諾は、dsmig移行ツールで管理されます。トポロジで自動移行がサポートされない場合、これらのレプリケーション承諾も手動で更新する必要があります。
マスター・レプリカを新しいホストまたはポートに移行した場合、リフェラルも影響を受けます。トポロジ内の各マスターの詳細は、トポロジ内の他のすべてのサーバーのReplica Update Vector (RUV)にあります。各サーバーのRUVは、リフェラルを決定するために使用されます。移行中にマスター・サーバーのホスト名またはポート番号を変更した場合、トポロジ内の他のサーバーからのそのマスターに対するリフェラルはすべて無効になります。これを修正する最も簡単な方法は、移行時に次の手順を順番を守って実行することです。
マスター・サーバーを移行する前に、レプリケート対象の保留中の変更がないことを確認します。これを行うには、insyncツールを使用します。
『Oracle Directory Server Enterprise Edition管理者ガイド』のレプリカの昇格または降格に関する説明に従って、マスター・サーバーをハブに降格させます。
dsmigを使用するか、手動でハブ・サーバーを移行します。
『Oracle Directory Server Enterprise Edition管理者ガイド』のレプリカの昇格または降格に関する説明に従って、ハブ・サーバーをマスターに昇格させます。ハブを昇格させた場合、移行した新しいマスターにreplicaIDを割り当てる必要があります。この新しいreplicaIDは、移行されている古いサーバーのreplicaIDとは別で、レプリケートされるトポロジ内で一意である必要があります。
dsmigでは、デフォルトのレプリケーション・マネージャの(cn=replication manager,cn=replication,cn=config)のパスワード・エントリは移行しません。かわりに、レプリケーション・マネージャのパスワードを削除します。したがって、移行を手動または自動で行うかにかかわらず、レプリケーション・マネージャのパスワードを手動でリセットする必要があります。
レプリケーション・マネージャのパスワードをリセットするには、次のコマンドを使用します。
$ dsconf set-server-prop -h host -p port def-repl-manager-pwd-file:filename $ dsconf set-repl-agmt-prop -p port_master1 replicated_suffix \ master2:port_master2 auth-pwd-file:filename
|
注意:
|
また、dsmigではデフォルトではないレプリケーション・マネージャのエントリも移行しません。古いバージョンのレプリカでデフォルトのレプリケーション・マネージャ以外のエントリを使用しており、このエントリがcn=configの下にある場合、デフォルトのレプリケーション・マネージャを手動で追加する必要があります。デフォルトではないレプリケーション・マネージャのエントリを手動で追加する方法の詳細は、マニュアルを参照してください。デフォルトではないレプリケーション・マネージャを追加する方法の詳細は、『Oracle Directory Server Enterprise Edition管理者ガイド』のデフォルトではないレプリケーション・マネージャの使用に関する説明を参照してください。
Directory Server 11gリリース1 (11.1.1.7.0)のマルチマスター・トポロジでは、マスター数に対する制限がありません。多くの場合、ハブまたはコンシューマが存在しないフルメッシュのマルチマスター・トポロジが推奨されます。
すべてがマスターのトポロジの利点は次のとおりです。
可用性。サーバーの1つがダウンしても書込みトラフィックは中断されません。
簡潔性。すべてがマスターのトポロジで、読み書きを別のサーバーにルートするリフェラルの設定が不要です。
デプロイメントによっては、すべてがマスターのトポロジが使用できない場合があります。たとえば、部分レプリケーションはマスターからコンシューマのみでサポートされているため、すべてがマスターのトポロジでは部分レプリケーションは使用できません。
この項では、様々なレプリケーション・トポロジの移行シナリオの例を示します。
レプリケート対象のサーバーの移行を開始する前に、トポロジのアーキテクチャを変更した場合、デプロイメントでサービスがうまく提供されないことがあるか判断します。この項では、既存のトポロジを保持する場合の移行方法について説明します。レプリケーション・トポロジを同一のトポロジに移行するには、コンシューマを移行し、次いでハブ、次いでマスターを移行します。次の項では、単純なマルチマスター・トポロジを移行する例を示します。
レプリケーション・トポロジ内の各コンシューマに対し、次を実行します。
トポロジ内の別のコンシューマにクライアントをルートしなおします。
移行するコンシューマに対するレプリケーション承諾をすべて無効にします。
コンシューマを停止します。
第5章「Directory Serverの移行プロセスの概要」の説明に従って、コンシューマを移行します。
コンシューマを起動します。
ハブからそのコンシューマに対するレプリケーション承諾を有効にします。
データを移行した場合、そのレプリケーションの同期が保たれていることを確認します。
データを移行していない場合は、コンシューマを再度初期化します。
クライアントをコンシューマにルート変更しなおします。
次の一連の図では、前述のコンシューマの移行を示します。最初の図は、移行前のバージョン5.2のトポロジを示します。
最初の手順では、クライアントをルート変更し、レプリケーション承諾を無効化し、実質的にトポロジからのコンシューマを分離します。
次の手順ではコンシューマを移行します。
次の手順では、新しいコンシューマに対してレプリケーション承諾を有効にし、必要に応じてコンシューマを初期化し、クライアント・アプリケーションを新しいコンシューマにルート変更します。
レプリケーション・トポロジの各ハブに対し、次を実行します。
移行するマスターからハブへのレプリケーション承諾を無効にします。
コンシューマに移行するハブからのレプリケーション承諾を無効にします。
ハブを停止します。
第5章「Directory Serverの移行プロセスの概要」の説明に従って、ハブを移行します。
ハブを起動します。
マスターからそのハブに対するレプリケーション承諾を有効にします。
ハブからそのコンシューマに対するレプリケーション承諾を有効にします。
データを移行した場合、そのレプリケーションの同期が保たれていることを確認します。
データを移行していない場合は、ハブを再度初期化します。
次の一連の図では、前述のとおりハブを移行します。最初の図は、ハブの移行前のトポロジを示します。
最初の移行手順では、レプリケーション承諾を無効にし、実質的にトポロジからハブを分離します。
次の手順ではレガシー・ハブを移行します。
次の手順では、新しいハブでレプリケーション承諾を有効にし、必要に応じてコンシューマを初期化します。
別のハブを移行する前に、コンシューマのレプリケーションが残りのトポロジと同期が保たれていることを確認します。移行したばかりのサーバーには変更ログがなく、したがって同期が保たれていないコンシューマ・サーバーは更新できません。次のサプライヤ・サーバーを移行する前に、トポロジを安定させ、すべてのサーバーの同期が取られるようにします。
レプリケーション・トポロジの各マスターに対し、次を実行します。
移行するマスターに書込みを行うクライアント・アプリケーションがある場合、トポロジ内の別のマスターに書き込むよう、これらのアプリケーションをルート変更します。
そのマスターが書込みリクエストを受信しなくなったことを確認します。これには、マスターで読取り専用モードを有効にします。
マスターとそのコンシューマ間のレプリケーションの同期が取られていることを確認します。
手動で移行を行う場合、変更ログの移行はサポートされていないので、この場合は前の2つの手順は必須です。自動での移行では、変更ログは移行されますが、変更を失うリスクを回避するために上記の手順は行ってください。
移行するマスターに対するレプリケーション承諾をすべて無効にします。
マスターを停止します。
第5章「Directory Serverの移行プロセスの概要」の説明に従ってマスターを移行します。
マスターを起動します。
トポロジ内のマスターからハブおよび他のマスターへのレプリケーション承諾を有効にします。
データを移行した場合、そのレプリケーションの同期が保たれていることを確認します。
データを移行していない場合、トポロジ内の別のマスターからマスターを初期化します。
クライアント・アプリケーションをルート変更した場合(手順2)、ここで移行したマスターに書き込むようアプリケーションをルーティングします。
次の一連の図では、前述のマスターの移行を行います。最初の図は、マスターの移行前のトポロジを示します。
マスターを移行する場合、まずレプリケーション承諾を無効にし、実質的にマスターをトポロジから分離します。
次の手順ではマスターを移行します。
次の手順では、新しいマスターからまたは新しいマスターに対するレプリケーション承諾を有効にし、必要に応じてマスターを初期化します。
別のマスターを移行する前に、すべてのハブおよびコンシューマのレプリケーションの同期が残りのトポロジと保たれていることを確認します。移行したばかりのサーバーには変更ログがなく、したがって同期が保たれていないサーバーは更新できません。次のサプライヤ・サーバーを移行する前に、トポロジを安定させ、すべてのサーバーの同期が取られるようにします。
レプリケート対象のサーバーの移行を開始する前に、トポロジのアーキテクチャを変更した場合、デプロイメントでサービスがうまく提供されないことがあるか判断します。この項では、基本のレガシー・トポロジをすべてがマスターのトポロジに移行する方法について説明します。すべてがマスターのトポロジに移行するには、コンシューマ、ハブおよびマスターを移行し、次いでハブをマスターに、その後コンシューマをハブからマスターに昇格させます。次の項では、単純なマルチマスター・トポロジをすべてがマスターの新しいトポロジに移行する例を示します。
次の図は、レガシー・トポロジを示します。
まず、「同一トポロジへのレプリケーション・トポロジの移行」の説明に従って、すべてのサーバーを個々に移行します。結果のトポロジは次の図のとおりです。
次の手順では、ハブをマスターに昇格させ、マスター間でフルメッシュ型トポロジを作成します。ハブを昇格させるには、『Oracle Directory Server Enterprise Edition管理者ガイド』のレプリカの昇格または降格に関する説明に従います。
次の図は、ハブを昇格後のトポロジを示します。
次の手順では、コンシューマをハブ、次いでマスターに昇格させ、マスター間でフルメッシュ型トポロジを作成します。コンシューマを昇格させるには、『Oracle Directory Server Enterprise Edition管理者ガイド』のレプリカの昇格または降格に関する説明を参照してください。
次の図は、コンシューマを昇格後のトポロジを示します。
複数のデータ・センターを介してサーバーを移行する場合、各データ・センターの各サーバーを個々に移行する必要があります。レプリケート対象のサーバーの移行を開始する前に、トポロジのアーキテクチャを変更した場合、デプロイメントでサービスがうまく提供されないことがあるか判断します。既存のトポロジを維持する場合、各データ・センターで「同一トポロジへのレプリケーション・トポロジの移行」の例に従います。新しいトポロジを移行する場合、各データ・センターで「新しいトポロジへのレプリケーション・トポロジの移行」の例に従います。
