|
| Sun ONE Directory Server インストールおよびチューニングガイド |
この章では、Netscape Directory Server 4.x および iPlanet Directory Server 5.x から Sun ONE Directory Server 5.2 へのアップグレードについて説明します。
注 Innosoft Distributed Directory Server 4.5.1 からのアップグレード方法については、この章では取り扱っていません。
この章では、主に古いサーバーから新しいサーバーへのディレクトリデータの移行方法について詳しく説明します。古いサーバーから新しいサーバーに移行する設定属性の詳細については、『Sun ONE Directory Server Reference Manual』を参照してください。
アップグレードの前に
アップグレードを行う前に、Sun ONE Directory Server 5.2 で使用する新しい機能を理解しておいてください。詳細は、このマニュアルの「推奨参考文献」を参照してください。この機会に、既存のディレクトリサービスの実装時に行われた設計上の決定事項を検討してください。
単一サーバーインスタンスをアップグレードする場合
サーバーインスタンスのアップグレードでは、異なる ServerRoot に既存のサーバーとともに新しいサーバーをインストールします。それぞれ異なる serverID、管理サーバー、および Directory Server のポート番号を使用し、古いサーバーを停止してから、設定およびディレクトリデータを移行し、クライアントで新しいサーバーへの要求を行います。
Sun ONE Directory Server 5.2 には、サーバーインスタンスのデータの移行に役立つスクリプトが用意されています。移行スクリプトは、次のタスクを順番に実行します。
- 既存のサーバーを停止して、現在の設定をバックアップする
- スキーマ設定ファイルを確認し、既存のサーバーで使用されているスキーマ設定ファイルと標準スキーマ設定ファイルとの相違をレポートする
(4.x から 5.2 への移行のみ) 既存の 4.x サーバーが、デフォルト (ServerRoot/slapd-serverID/config) 以外の場所にインストールされたカスタムスキーマを使用している場合は、ディレクトリデータを移行する前に手動で設定を調整する必要があります。
- 古いサーバーに格納されているサフィックスのデータベースを作成する
(4.x から 5.2 への移行のみ) 4.x サーバーは、データベースごとに複数のサフィックスをサポートしていました。移行スクリプトは、新しいサーバー上に各サフィックスのデータベースを作成します。
- サーバーとデータベースの設定パラメータを移行する
4.x サーバーは、これらのパラメータを slapd.conf ファイルに格納します。5.x サーバーは、これらのパラメータをエントリとして dse.ldif ファイルに格納します。
注 このスクリプトは、o=NetscapeRoot の下にあるデータを移行しません。
このサフィックスのデータを利用する Sun ONE Messaging Server などのサーバーを導入する場合は、o=NetscapeRoot のデータを手動で移行するか、または対象となるサーバーに付属のツールを使用して移行します。
(4.x から 5.2 への移行のみ) この移行スクリプトは、4.x サーバーのすべてのパラメータを移行しません。場合によっては、手動で 4.x の属性値を移行する必要があります。詳細は、現在のバージョンの『Sun ONE Directory Server Reference Manual』を参照してください。
- ユーザー定義のスキーマオブジェクトを移行する
- インデックスを移行する
- 標準サーバープラグインを移行する
手動でカスタムプラグインを移行する必要があります。少なくとも、すべてのカスタムプラグインを再コンパイルする必要があります。プラグイン API 更新の詳細リストについては、『Sun ONE Directory Server Plug-In API Programming Guide』を参照してください。
- (5.x から 5.2 への移行のみ) レプリケーションアグリーメントを移行する
注 Directory Server 5.2 から 5.1 サーバーにレプリケートする前に、cn=config の nsslapd-schema-repl-useronly を on に設定します。この設定を先に行わない場合、5.2 スキーマが 5.1 サーバーにレプリケートされ、重複オブジェクトが作成されるため、5.1 サーバーが再起動できなくなります。
- 証明書データベースおよび SSL パラメータを移行する
- (5.x から 5.2 への移行のみ) データベースリンクを移行する
- (5.x から 5.2 への移行のみ) レプリケーションエントリを移行する
- SNMP 設定を移行する
移行スクリプトが完了すると、クライアントは新しいサーバーに要求を送信することができます。
複数のレプリケーションサーバーをアップグレードする場合
当然のことながら、複数のサーバーのアップグレードは、各サーバーを個別にアップグレードすることによって行われます。ただし、サーバーをアップグレードする「順序」は、既存のサーバーソフトウェアのバージョンとレプリケーショントポロジによって決まります。
5.x から 5.2 にアップグレードする場合、標準プロセスはボトムアップです。最初にコンシューマを移行します。次にハブをアップグレードします。最後にマスターをアップグレードします。特定のインスタンスでこのプロセスを実行する方法については、「5.x アップグレードの例」を参照してください。
4.x から 5.2 にアップグレードするには、4.x マスターをアップグレードしてから、次にマスターからレプリケートされたコンシューマの各分岐のアップグレードに進みます。この場合、レプリケーションを基準にして最も近いコンシューマからアップグレードを開始します。特定のインスタンスでこのプロセスを実行する方法については、「4.x アップグレードの例」を参照してください。
既存の環境に複数のレプリケーションサーバーが含まれている場合は、アップグレードを続行する前に、この章のすべての関連する項目を入念に読んでください。不必要なダウンタイムを回避するために、アップグレード方法を十分に計画する必要があります。
アップグレードのヘルプについて
Sun プロフェッショナルサービスは、重要なディレクトリサービスのアップグレードを支援します。
問い合わせ先情報については、Web サイト http://jp.sun.com/service/sunps/sunone/ を参照してください。
単一サーバーのアップグレード
この節では、単一の既存のサーバーから単一の 5.2 サーバーへのアップグレードプロセスについて説明します。
注 既存の 4.x サーバーがカスタムスキーマを使用する場合、データを移行する前に移行スクリプトがカスタムスキーマを検出できることを確認します。詳細は、「カスタムスキーマの処理 (4.x から 5.2 にアップグレードする場合)」をお読みください。
移行スクリプトがカスタムスキーマを認識しない場合、スキーマは移行されないので、新しいサーバーにデータを移行した後に標準スキーマファイルを適用します。カスタムスキーマに適合するエントリに標準スキーマを適用すると変更ができなくなり、アップグレードディレクトリは読み取り専用になります。
新しいサーバーのインストール
既存のサーバーと同じホストに新しいサーバーをインストールするには、第 1 章「Sun ONE Directory Server のインストール」で説明する手順に従います。
注 新しいサーバーをインストールする前に、既存のサーバーの現在の内容がバックアップされていることを確認します。
新しいサーバーは、既存のサーバーとは別の ServerRoot ディレクトリに配置する必要があります。また、serverID も別にする必要があります。
元のインストールに適用したほとんどの設定情報を再利用できますが、既存のポート番号は再利用しないでください。既存のデータの移行後、新しいサーバーのポート番号を変更できます。
カスタムスキーマの処理 (4.x から 5.2 にアップグレードする場合)
付属のデータ移行スクリプトは、標準の slapd.user_oc.conf および slapd.user_at.conf ファイルに配置されたカスタムスキーマ、またはほかのファイルに配置され、useroc および userat 指令を使用して slapd.conf に組み込まれたカスタムスキーマだけを認識します。たとえば、カスタムスキーマが slapd.at.conf または slapd.oc.conf ファイルに直接組み込まれている場合、移行スクリプトはこれらのカスタムスキーマを認識しません。
アップグレードを進める前に、次の手順を実行します。
- slapd.at.conf または slapd.oc.conf ファイルを、新しいサーバーの ServerRoot/bin/slapd/install/version4/ の下にある標準ファイルと比較して、カスタムスキーマを slapd.user_oc.conf と slapd.user_at.conf ファイルに転記します。
カスタマイズしたオブジェクトクラスに継承関係がある場合は、スキーマ設定ファイルで、上位オブジェクトクラスがその他のクラスよりも先行していることを確認します。
- slapd.oc.conf の標準オブジェクトクラスにカスタム属性が追加された場合は、slapd.user_oc.conf の属性を含む新しいオブジェクトクラスを作成して、カスタム属性を使用する既存のディレクトリのエントリすべてにこの新しいオブジェクトクラスを追加します。
- useroc と userat 指令を使用して、既存のサーバーの slapd.conf ファイルに slapd.user_oc.conf と slapd.user_at.conf ファイルを組み込み、ほかのファイルの文を組み込むための新しい指令を隣接して配置します。
この時点で、既存のサーバーが使用するすべてのカスタムスキーマが slapd.user_oc.conf または slapd.user_at.conf ファイルに配置され、これらのファイルが useroc と userat指令を使用して、slapd.conf に組み込まれます。
既存のデータの移行
カスタムスキーマを処理したら、次の手順を実行して既存のデータを新しいサーバーに移行します。
- 新しい Directory Server のレプリケーションを、ファイルからオフラインで初期化する場合は、初期化を進める前にファイルを取得します。
Directory Server のデータをエクスポートする手順については、『Sun ONE Directory Server 管理ガイド』を参照してください。
- 新しい Directory Server が動作していることを確認します。
- 新しいサーバーと古いサーバーの両方でデータベースのエクスポートとインポートを起動、停止、および実行するために、それらの権利を持つユーザーとして作業します。
たとえば、スーパーユーザーになるか、または Administrator としてログオンします。
- 表 2-1 に示すように、環境変数を設定します。
表 2-1 移行の環境変数
変数
値
PATH
(UNIX の場合) ServerRoot/bin/slapd/admin/bin:$PATH
(Windows の場合) ServerRoot/bin/slapd/admin/bin;%PATH%
PERL5LIB
ServerRoot/bin/slapd/admin/bin
- 新しいサーバーインスタンスで、次のように移行スクリプトを実行します。
# cd ServerRoot/bin/slapd/admin/bin
# perl migrateInstance5 -p port52 -D "cn=directory manager" -w password -o oldServ -n ¥ newServ
ここで、oldServ は、/usr/iplanet/servers/slapd-ldap または /usr/iplanet/ds5/slapd-ldap など古いサーバーインスタンスへの絶対パスを表し、newServ は、/var/ds/v5.2/slapd-dirserv など新しいサーバーインスタンスへの絶対パスを表します。
スクリプトは実行に伴って出力を生成します。移行完了後のレビューのために、この出力をファイルに転送することができます。
既存のデータを新しいサーバーに移行したら、古いサーバーだけを解除します。
レプリケーションアグリーメントの作成 (4.x から 5.2 にアップグレードする場合)
既存の 4.x サーバーがレプリケーションに含まれている場合、アップグレードによってデータの移行後にレプリケーションアグリーメントが再作成されます。アップグレードプロセスを進める前に、「レプリケーションサーバーのアップグレード (4.x から 5.2 にアップグレードする場合)」をお読みください。
5.2 サーバーのレプリケーションを設定する手順については、『Sun ONE Directory Server 管理ガイド』を参照してください。
既存のポート番号の再利用 (必要に応じて)
古いサーバーから新しいサーバーにデータを移行後、古いサーバーを解除して、新しいサーバーを古いサーバーと同じポートで待機させることができます。古いサーバーと同じポートを使用すると、設定を変更せずにクライアントアプリケーションを続けて使用できます。
サーバーポートを変更する手順については、『Sun ONE Directory Server 管理ガイド』を参照してください。新しいサーバーが古いポートで待機し始める前に、必ず古いサーバーを停止してください。
レプリケーションサーバーのアップグレード (4.x から 5.2 にアップグレードする場合)
4.x レプリケーションサーバーをアップグレードする場合は、新しいマスターにレプリケートしてから、レプリケーショントポロジを介して分岐ごとにアップグレードを進めます。この方法は、サーバー同期トラフィックの量を制限します。
注 レプリケーションの設定と初期化に関する詳細手順については、『Sun ONE Directory Server 管理ガイド』を参照してください。
新しいマスターの準備
アップグレードの間に、5.2 サーバーはマスターとして設定されますが、4.x トポロジの旧バージョンのコンシューマとして機能します。アップグレード完了後、4.x コンシューマ機能が無効になり、新しいサーバーは 5.2 トポロジのマスターとして機能します。
この手順では、手動で新しいマスターサーバーを設定する必要があります。このため、新しいマスターを既存のマスターと別のホストにインストールすることができます。
- 第 1 章「Sun ONE Directory Server のインストール」の手順に従って、新しいサーバーをインストールします。
- 新しいサーバーに、4.x マスターの設定を手動でもう一度作成します。
- 新しいサーバーをマスターにします (5.2 トポロジの場合)。
手順は、『Sun ONE Directory Server 管理ガイド』を参照してください。
- 新しいサーバーを 4.x マスターの旧バージョンのコンシューマとします (4.x トポロジの場合)。
手順は、『Sun ONE Directory Server 管理ガイド』を参照してください。
- 4.x マスターから新しいサーバーへのレプリケーションを初期化します。
このプロセスについては、『Netscape Directory Server 管理者ガイド』の第 12 章「レプリケーションの管理」で説明しています。「Consumer の手動作成」というタイトルの節を参照してください。
これで、コンシューマをアップグレードできるようになりました。
コンシューマのアップグレード
次の手順は、コンシューマのアップグレード方法の概要について説明します。詳細は、後続の手順を参照してください。
- 4.x トポロジのすべての分岐をアップグレードします。
- 必要に応じて、5.2 トポロジにさらにサーバーを追加します。
- 新しいマスターの旧バージョンのコンシューマアグリーメントを無効にして、新しいトポロジと古いトポロジの関係を解除します。
この手順が完了すると、更新プロセスが完了します。
分岐のアップグレード
既存の 4.x レプリケーショントポロジを、ルート要素としてマスターを持つツリーとみなします。ここでは、branch は、レプリケーションフローがルートノードのサプライヤから始まり、ツリー内のコンシューマを経由して、最終的に最下位のノードのコンシューマサーバーに到達する一連のレプリケーションサーバーを示します。
分岐のアップグレードは、トップダウン方式で分岐内のすべての古いサーバーを新しいサーバーに置き換えるプロセスで構成されます。
注 サーバーをアップグレードする間に、レプリケーションフローは分岐内のすべてのダウンストリームサーバーで停止します。アップグレード中にクライアントの要求を別の分岐に転送することを検討してください。
- 「単一サーバーのアップグレード」で説明する手順に従って、分岐の最上位のサーバーをアップグレードします。
これにより、分岐へのレプリケーションフローが切断され、分岐内のダウンストリームサーバーにあるレプリケーションの更新が一時的に中断されます
- 5.2 分岐内の新しいサーバーのレプリケーションアグリーメントを設定して、レプリケーショントポロジの近くにある 5.2 サーバーから新しいマスターへの更新を受信します。
たとえば、新しい分岐の最上位サーバーを設定して、5.2 マスターからの更新を受信します。
- 5.2 サプライヤから新しい 5.2 サーバーへのレプリケーションを初期化します。
ネットワーク容量および更新時と比較したディレクトリデータの量によっては、オフラインによる初期化の方がオンラインによる初期化よりも速くなる場合があります。
- 最下位のすべてのコンシューマに対してこの手順が完了するまで、分岐に沿って 手順 1、手順 2、および 手順 3 を繰り返し実行します。
レプリケーションアグリーメントの設定とレプリケーションの初期化に関する手順については、『Sun ONE Directory Server 管理ガイド』を参照してください。
この時点で、分岐の更新プロセスが完了します。残りの 4.x 分岐に対して、この手順を繰り返します。
さらにサーバーを追加
4.x トポロジから 5.2 トポロジへのアップグレードの完了後、新しいトポロジの必要に応じてさらにマスター、ハブ、およびコンシューマを追加することができます。
各追加サーバーに対して次の手順を実行します。
- 第 1 章「Sun ONE Directory Server のインストール」で説明する手順に従って、新しいサーバーのインストールを実行します。
- 計画したトポロジに適合するように、新しいサーバーのレプリケーションアグリーメントを調整します。
手順は、『Sun ONE Directory Server 管理ガイド』を参照してください。
- 新しいサーバーのレプリケーションを初期化します。
手順は、『Sun ONE Directory Server 管理ガイド』を参照してください。
4.x アップグレードの例
4.x マスターのアップグレードを、1 つは単一のコンシューマ、もう 1 つは 2 つのコンシューマに供給するハブを持つ 2 つの分岐にレプリケートする場合について検討します。この節では、新しいマルチマスタートポロジにアップグレードするための手順を示します。
図 2-1 は、アップグレードする前の 4.x トポロジを示します。
図 2-1 既存の 4.x トポロジの例
図 2-2 は、4.x マスターの旧バージョンのコンシューマとしても機能する 5.2 マスターの追加を示します。
図 2-2 新しいサーバーが追加された 4.x トポロジの例
図 2-3 は、4.x 分岐を置き換える最初の手順を示します。
アップグレードの間、すべての分岐がレプリケーションの更新の受信を停止することに注意してください。この中断は、アップグレードのために、アップストリームの 4.x コンシューマを停止したときに始まり、4.x コンシューマを再起動したときに終了します。
手順で説明されているように、クライアントが利用可能な最新の更新を要求する場合は、クライアントの要求を別の分岐のコンシューマに転送することもできます。
図 2-3 アップグレード中の 4.x 分岐の例 − 手順 1
図 2-4 は、4.x 分岐を置き換える次の手順を示します。
図 2-4 アップグレード中の 4.x 分岐の例 − 手順 2
図 2-5 は、4.x 分岐を置き換える次の手順を示します。
図 2-5 アップグレード中の 4.x 分岐の例 − 手順 3
図 2-6 は、その他の 4.x 分岐の置き換えを示します。
図 2-6 アップグレード中の 4.x 分岐の例 − 次の分岐
図 2-7 は、並行する 2 つのトポロジを示します。
図 2-7 アップグレード中の 4.x および 5.2 トポロジの例
図 2-8 は、新しいトポロジに追加されたマスター、ハブ、およびさらに追加されたレプリケーションアグリーメントを示します。
図 2-8 5.2 トポロジへのサーバーの追加
アップグレードプロセスの完了後、さらにサーバーを追加することもできます。
図 2-9 は、古い 4.x マスターから新しい 5.2 マスターへのレプリケーションアグリーメントの削除を示します。
図 2-9 レプリケーションアグリーメントの削除
クライアントの要求を転送し、レプリケーションアグリーメントを削除した後に、4.x サーバーを無効にすることができます。
図 2-10 は、結果として作成された 5.2 トポロジを示します。
図 2-10 結果として作成された 5.2 トポロジ
ここで、クライアントの要求が 5.2 トポロジに転送されています。
レプリケーションサーバーのアップグレード (5.x から 5.2 にアップグレードする場合)
5.x サーバーをアップグレードする場合、通常はコンシューマから開始し、次にハブを更新し、最後にマスターを更新して終了します。このボトムアップ方法では、一度に中断されるサーバーは 1 台だけです。レプリケーショントポロジの特定の分岐全体が中断されることはありません。また、この方法を使用すると、マスターとコンシューマ間でカスタムスキーマの同期問題が発生する可能性が低下します。
注 ここで説明する手順は、5.x トポロジをアップグレードする標準的な方法を使用します。
ただし、このボトムアップ方法が特定の要件に対応できない場合は、別の方法を計画してください。
5.x サーバーのアップグレード
- 既存のトポロジの各コンシューマの場合、「単一サーバーのアップグレード」で説明する手順に従って、コンシューマのアップグレードを進めます。
- 既存のトポロジのそれぞれのハブについては、同じ手順に従って、ハブを更新します。
- 既存のトポロジのそれぞれのマスターについては、同じ手順に従って、ハブを更新します。
さらにサーバーを追加
5.x トポロジから 5.2 トポロジへのアップグレードの完了後、新しいトポロジの必要に応じてさらにマスター、ハブ、およびコンシューマを追加することができます。
各追加サーバーに対して次の手順を実行します。
- 第 1 章「Sun ONE Directory Server のインストール」の手順に従って、新しいサーバーをインストールします。
- 計画したトポロジに適合するように、新しいサーバーのレプリケーションアグリーメントを調整します。
- 新しいサーバーのレプリケーションを初期化します。
レプリケーションアグリーメントの設定とレプリケーションの初期化に関する手順については、『Sun ONE Directory Server 管理ガイド』を参照してください。
この手順が完了すると、更新プロセスが完了します。クライアントは、アップグレードされたレプリケーショントポロジでサーバーの使用を開始することができます。
5.x アップグレードの例
5.x デュアルマスターのアップグレードを 2 つのコンシューマに供給する 2 つのハブにレプリケートする場合について検討します。この節では、5.2 サーバーを使用するトポロジへアップグレードするための手順を示します。
図 2-11 は、アップグレードする前の 5.x トポロジを示します。
図 2-11 既存の 5.x トポロジの例
最初の手順では、コンシューマのアップグレードが行われます。図 2-12 は、結果として作成されたトポロジを示します。
図 2-12 5.x コンシューマのアップグレード手順の例
次の手順では、ハブのアップグレードが行われます。図 2-13 は、その結果を示します。
図 2-13 5.x ハブのアップグレード手順の例
次の手順では、マスターのアップグレードが行われます。図 2-14 は、その結果を示します。
図 2-14 5.x マスターのアップグレードの例 − 手順 3
図 2-15 は、アップグレード後の 5.2 トポロジを示します。この時点では、古いトポロジのサーバーは解除され、新しいサーバーが 5.2 トポロジに追加されています。
図 2-15 アップグレード後の 5.2 トポロジの例
ここで、クライアントの要求が 5.2 トポロジに転送されています。