このセクションでは、ハードウェアをアップグレードまたは交換する際に、特定のサーバ上のOpenText eDirectoryを移す、または保護するための情報について説明します。ここでの説明は、「OpenText eDirectoryのバックアップと復元」の情報に基づいています。
Backup OpenText eDirectory Management Toolを使用すれば、次の操作を行うためのOpenText eDirectory情報を準備できます。
記憶デバイスやRAMなどのハードウェアのアップグレードを計画している場合、Backup eMtoolを使用してOpenText eDirectoryのコールドバックアップを行い、ファイルシステムのバックアップも行います。これにより、サーバのOpenText eDirectory識別情報とファイルシステムデータが保護されます。このバックアップには、次の利点があります。
記憶デバイスを交換する場合、バックアップによって古い記憶デバイスから新しい記憶デバイスに情報を移すことができます。
OpenText eDirectoryが格納されたディスクパーティションまたはディスクボリュームを含む記憶デバイスを交換する場合、このバックアップ情報を用いれば、復元プロセスを使用してOpenText eDirectoryデータベースを新しい記憶デバイス上に再構築できます。
OpenText eDirectoryのコールドバックアップを実行し、その後でデータベースをクローズしておけば、バックアップ後のデータベースの変更を心配することなくハードウェアをアップグレードし、データベースを移すことができます。
何か問題が発生した場合、バックアップを使用して復元できます。
OpenText eDirectoryのコールドバックアップを実行する場合、オプションを使用してサーバ上のOpenText eDirectoryをロックし、使用不可にする必要があります。これにより、バックアップ後のデータ変更を防げます。このサーバと通信している他のサーバからは、このサーバは停止しているように見えます。通常サーバに送信されるOpenText eDirectory情報は、そのサーバと再び通信できるようになるまで、ツリー内の別のサーバに保存されます。保存された情報は、サーバがオンライン状態に戻ったときに、サーバを同期するために使用されます。
メモ:OpenText eDirectoryツリー内の他のサーバは、このサーバがすぐにオンライン状態に戻ると期待しているため、アップグレードをすばやく完了させ、できるだけ早くサーバ上のOpenText eDirectoryデータベースをオープンする必要があります。
ハードウェアのアップグレードを計画的に実行するには、次の手順に従います。
アップグレードによりサーバに問題が発生するかもしれないと心配なら、必要に応じて、使用する別のコンピュータを準備するとよいでしょう。
詳細については、1. サーバ交換の準備を参照してください。
OpenText eDirectoryデータベースのコールドバックアップを実行し、その後でデータベースをクローズし、ロックしたままにしておくには、クライアントコマンドを次のように使用します。NICIを使用する場合は、セキュリティファイルもバックアップします。
backup -f backup_filename_and_path -l log_filename_and_path -t -c -o -d
NICIを使用する場合は、NICIファイルをバックアップします。クライアントとスイッチの使用についての詳細は、「DSBKによる手動バックアップ」と「バックアップ/復元のコマンドラインオプション」を参照してください。
これで、OpenText eDirectoryデータベースはロックされました。手順を完了するまでは、サーバ上で新たなデータ変更が実行されないように、データベースをロックしたままにしておく必要があります。
サーバが使用できない時間を最小限に抑えるために、以降の手順をすばやく完了させます。
お好みのバックアップツールを使用して、ファイルシステムをバックアップします。
データベースをバックアップした後で、ファイルシステムのバックアップを行うのは重要です。これにより、OpenText eDirectoryバックアップファイルが、他のファイルシステムと一緒にテープに保存されます。
サーバを停止させ、ハードウェアを交換します。
ハードウェアを交換した後で、ハードウェア変更の種類に応じた以下の手順を実行します。
|
ハードウェア変更の種類… |
実行する手順 |
|---|---|
|
記憶デバイスに変更がない場合 |
サーバを起動し、データベースのロック解除を行います。 |
|
記憶デバイスの交換を行ったが、OpenText eDirectoryが格納されたディスクパーティション/ボリュームに変更はない場合 |
|
|
OpenText eDirectoryが保存された記憶デバイスを交換した場合 |
|
サーバが通常どおりに応答しない場合、次にいずれかの方法によって回復する必要がある場合があります。
変更前のハードウェア環境設定が機能していたことから、これを再作成します。
作成したファイルシステムとOpenText eDirectoryのバックアップを使用して、このサーバの識別情報を別のマシンに移します。詳細については、サーバの計画的な交換を参照してください。
次に示す手順は、サーバのOpenText eDirectory資格情報とファイルシステムデータを別のマシンに移して、実際にサーバを置き換えた場合です。ここでは、古いサーバをサーバAとし、それに置き換わるサーバをサーバBとしています。
Backup eMToolを使用してOpenText eDirectoryのコールドバックアップ(データベースをクローズした状態でのバックアップ)を実行し、さらにお好みのツールを使用してファイルシステムのバックアップをして、サーバの交換に備えます。このバックアップ情報を用いれば、復元プロセスを使用して、新しいコンピュータ上にサーバを再構築できます。
OpenText eDirectoryのコールドバックアップを実行する場合、オプションを使用してサーバA上のOpenText eDirectoryをロックし、使用不可にする必要があります。これにより、バックアップ後のデータ変更を防げます。このサーバと通信している他のサーバからは、このサーバは停止しているように見えます。通常サーバに送信されるOpenText eDirectory情報は、そのサーバと再び通信できるようになるまで、ツリー内の別のサーバに保存されます。保存された情報は、新しいコンピュータであるサーバB上で、サーバがオンライン状態に戻ったときに同期するために使用されます。
メモ:OpenText eDirectoryツリー内の他のサーバは、このサーバがすぐにオンライン状態に戻ると期待しているため、できるだけ早く交換してサーバにOpenText eDirectory情報を復元する必要があります。
サーバを置き換えるための手順の概要を次に示します。
交換する際のサーバAの停止時間を短くするには、「1. サーバ交換の準備」で説明しているようにサーバBにオペレーティングシステムをインストールするなどして、交換前にできるだけサーバBの準備を整えておきます。
2. OpenText eDirectoryのバックアップの作成の説明に従って、サーバAのOpenText eDirectoryおよびファイルシステムのバックアップを行います。
「3. サーバ交換のためのOpenText eDirectory情報の復元」の説明に従って、サーバBに情報を移します。
次に示すサーバAとサーバBのチェックリストを使用して、サーバAを交換する準備ができているかを確認します。開始する前にサーバBの準備をしておけば、あるコンピュータから別のコンピュータへ転送する間のサーバの停止時間を減らすことができます。
サーバAに最新のバージョンのオペレーティングシステムがインストールされていることを確認します。
Treeパーティションのマスタを保持しているサーバでDSRepairを実行し、さらに時刻同期を実行して、サーバAのツリーが正常に機能していることを確認します。
サーバAのデータベースでDSRepairを実行します。サーバAが完全に同期されていることを確認します。
最新バージョンのオペレーティングシステムをインストールします。このオペレーティングシステムは、サーバAのものと同じである必要があります。
サーバBを新しい一時ツリーに配置し、OpenText eDirectoryをインストールします。
(3. サーバ交換のためのOpenText eDirectory情報の復元の過程でOpenText eDirectoryを復元するには、サーバBをサーバAが配置されていた元のツリー内に配置します)。
次のセクション(2. OpenText eDirectoryのバックアップの作成)の手順に進みます。
サーバ交換の前に、OpenText eDirectoryのバックアップを作成する必要があります。1. サーバ交換の準備の手順を完了したら、Clientを使用し、バックアップの後でデータベースを使用不可にしてロックする詳細オプションを設定して、サーバA上のOpenText eDirectoryデータベースのコールドバックアップを実行します。
OpenText eDirectoryのコールドバックアップ(データベースがクローズ中のバックアップ)を作成し、その後でデータベースをクローズのままにしておくには:
1. サーバ交換の準備が完了していることを確認します。
クライアントで、-c、-o、および-dスイッチを指定した次のようなbackupコマンドを用いてサーバA上のOpenText eDirectoryデータベースのコールドバックアップを実行し、完了後もデータベースをクローズしてロックしたままにします。
backup -f backup_filename_and_path -l log_filename_and_path -t -c -o -d
NICIを使用する場合は、NICIファイルをバックアップします。クライアントとスイッチの使用についての詳細は、「DSBKによる手動バックアップ」と「バックアップ/復元のコマンドラインオプション」を参照してください。
サーバAのOpenText eDirectoryデータベースは現在ロックされています。データベースをサーバB上に復元しツリー内に戻すまでは、サーバ上で新たなデータ変更が実行されないように、データベースをロックしたままにしておく必要があります。
サーバアップグレードまたはサーバ交換の残りの手順を迅速に完了させ、サーバが使用できない時間を最小限に抑えます。
サーバAのファイルシステムのフルバックアップを作成します。
データベースをバックアップした後で、ファイルシステムのバックアップを行うのは重要です。これにより、OpenText eDirectoryバックアップファイルが、残りのファイルシステムと一緒にテープに保存されます。
SMSの使用の詳細については、「SMSを使用したデータのバックアップ」を参照してください。
サーバA上のOpenText eDirectoryデータベースをロックし、サーバAをネットワークから外します。
続いて「3. サーバ交換のためのOpenText eDirectory情報の復元」の手順を実行します。
サーバAのOpenText eDirectory識別情報およびファイルシステムをサーバBに移すには:
「1. サーバ交換の準備」および「2. OpenText eDirectoryのバックアップの作成」が完了していることを確認します。
サーバBが起動し、eDirectoryが実行されていることを確認します。
restoreを次のように使用して、サーバAのOpenText eDirectory識別情報とファイルシステムをサーバBに移します。
サーバAのOpenText eDirectoryコールドバックアップファイルをサーバBにコピーします。
サードパーティのファイル圧縮ツールは圧縮性能が良いので、そのようなツールを使用した場合、バックアップファイルはとても小さくなることがあります。これにより、ファイルのコピーを早くできる場合があります。
複製したOpenText eDirectoryのバックアップファイルを使用して、サーバAのOpenText eDirectoryデータベースをサーバB上に復元します。それには、コマンドラインクライアントで、次のようなコマンドを使用します。
restore -r -f backup_filename_and_path -l log_filename_and_path
NICIを使用する場合は、NICIファイルを復元します。インクルードファイルに列挙されたファイルをバックアップしてあった場合は、-uオプションを追加します。クライアントとスイッチの使用についての詳細は、「DSBKによるバックアップファイルの復元作業」と「バックアップ/復元のコマンドラインオプション」を参照してください。
復元にはロールフォワードログを含める必要はありません。なぜなら、コールドバックアップを実行し、その後でデータベースをクローズしてあるからです。データベースではどのようなトランザクションも実行されていません。データベースはクローズされており、バックアップ以降、ロールフォワードログは作成されていません。
バックアップされたサーバAのファイルシステムデータをサーバBに移します。
NICIを使用している場合は、サーバを再起動してNICIを再初期化し、復元されたNICIセキュリティファイルが使用されるようにします。
OpenText eDirectoryデータベースのロックを解除します。
復元が完了した後は、サーバBがサーバAの識別情報を正しく引き継ぎ、通常どおりに応答しているかチェックします。OpenText iMonitorを使用してサーバとその同期をチェックします。
サーバの応答が通常どおりなら、サーバの交換は完了です。これで、サーバAからeDirectoryをアンインストールしてOpenText eDirectory識別情報を削除し、このコンピュータを別の目的に使用できます。サーバAをネットワークに戻すのは、OpenText eDirectoryを削除した後にしてください。そうしないと、OpenText eDirectoryの同期でネットワークが混乱してしまいます。なぜなら、サーバAとサーバBの同じ識別情報により、競合が発生するためです。
(特定条件における処理)このサーバでロールフォワードログを使用していた場合、復元を完了した後で、ロールフォワードログ設定を作成し直します。ロールフォワードログを有効にしてから、改めてフルバックアップも取る必要があります。
復元した後は、設定がデフォルトの状態にリセットされます。つまり、ロールフォワードログがオフになっています。フルバックアップが改めて必要となるのは、スケジュールに従って次に無人でのフルバックアップが取られるまでに、再び障害が起こる可能性があるためです。
サーバBが正常に動作せず、サーバAの識別情報およびファイルシステムを直ちに使用できるようにする必要がある場合は、次を実行します。
サーバBのネットワークケーブルを外すか、サーバBを停止します。
サーバAをネットワークに再接続し、起動してから、OpenText eDirectoryデータベースをオープンします。
DSRepairの実行を要求するシステムメッセージを無視します。
サーバBからOpenText eDirectoryを削除し、再度アップグレードを試みます。
サーバのIPアドレスが変更されることはあまりありません。IPアドレスが変更された場合は、すべてのOpenText eDirectoryインスタンスのnds.confファイルを新しいIPアドレスで更新する必要があります。IPアドレスが頻繁に変更される場合は、nds.confでIPアドレスの代わりにインタフェース名を使用する必要があります。
例: n4u.server.interfaces=eth0@1524
IPアドレスが変更されても、サーバのIPベースのキーマテリアルオブジェクト(KMO)は自動的に更新されません。古いKMO(名前にIPが含まれている)を削除する必要はありませんが、削除すればツリーが見やすくなります。ndsconfig upgradeコマンドを実行して、KMOを再作成し、それらをNCPサーバオブジェクトとLDAPサーバオブジェクトにリンクさせます。
メモ:ndsconfig upgradeを実行すると、OpenText eDirectoryインスタンスが再起動されます。
これで、サーバは新しいアドレスをリスンするようになります。ツリー内に複数のサーバが存在する場合は、DSRepairネットワーク修復オプションを実行します。
ndsrepair -N
修復オプションの実行後に、OpenText eDirectoryサーバを再起動します。
サーバのIPアドレスの変更に関する詳細については、TID# 3201067を参照してください。