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