この手順はシステムのリカバリー手順が失敗した場合、あるいは、ボリューム上に保管されているデータが必要ではない場合にのみ、システム構成を復元するために使用します。
始める前に
この構成の復元手順は、ボリューム、ローカル・メトロ・ミラー情報、ローカル・グローバル・ミラー情報、ストレージ・プール、およびノードなどの、構成に関する情報を復元することを目的としています。 ボリュームに書き込んだデータは復元されません。ボリューム上のデータを復元するには、クラスター化システム上のボリュームをストレージとして使用するすべてのアプリケーションから個別にアプリケーション・データを復元する必要があります。 そのため、構成のリカバリー・プロセスを実行する前に、このデータのバックアップを用意する必要があります。
システムのバックアップ時にシステム上で USB 暗号化が有効であった場合、構成のリストアを機能させるためには、ノード・キャニスターの USB ポートに少なくとも 3 つの USB フラッシュ・ドライブが存在する必要があります。3 つの USB フラッシュ・ドライブは、構成の復元・コマンドを実行する単一のノードに挿入されている必要があります。他の (システムの一部になる可能性がある) ノードにある USB フラッシュ・ドライブは、すべて無視されます。クラウド・バックアップ構成のリカバリーを行わない場合は、USB フラッシュ・ドライブに鍵が含まれている必要はありません。それらは、復元・プロセスの一環として新しい鍵を生成するために使用されます。クラウド・バックアップ構成のリカバリーを行う場合は、暗号化された現行データのロックを解除して新しい鍵で再暗号化できるよう、USB フラッシュ・ドライブに以前の一連の鍵が含まれている必要があります。
T4 リカバリー中に、新しいシステムが新しい証明書を使用して作成されます。システムに鍵サーバー暗号化がある場合は、T4 リカバリーを実行する前に、chsystemcert -export コマンドを使用して新しい証明書をエクスポートし、正しい装置グループ内のすべての鍵サーバーにインストールする必要があります。使用される装置グループは、以前のシステムが定義された装置グループです。また、新しいシステムの証明書に署名が必要な場合もあります。T4 リカバリーで、アクティブな鍵が暗号漏えいと見なされることを鍵サーバー管理者に通知してください。
このタスクについて
データ損失を避けるには、
構成データおよびアプリケーション・データを定期的にバックアップする必要があります。
重大な障害が発生してシステムが失われると、システムの構成とアプリケーションの両方のデータが失われます。システムを正確に障害発生前の状態に復元してから、
アプリケーション・データをリカバリーする必要があります。
復元処理中、ノードとストレージ・エンクロージャーがシステムに復元されてから、MDisk とアレイが再作成され、構成されます。関与するストレージ・エンクロージャーが複数ある場合、アレイおよび MDisk はエンクロージャー ID に基づいて適切なエンクロージャーで復元されます。
重要: - 復元処理の際には、
準備と実行の 2 つのフェーズがあります。
この 2 つのフェーズの間では、ファブリックまたはシステムへの変更を行ってはなりません。
- iSCSI によって仮想化された外部コントローラーに接続されるノードを含む システムでは、ご使用のデータをリストアする前に、すべてのノードをシステム内に追加する必要があります。さらに、ご使用のデータをリストアする前に、システムの cfgportip 設定および iSCSI ストレージ・ポートを手動で再適用する必要もあります。ステップ 10 を参照してください。
- VMware vSphere 仮想ボリューム (VVol と呼ばれることもある) 環境では、T4 回復の後、仮想ボリューム 構成ステップの一部は既に完了しています。つまり、metadatavdisk が作成され、ユーザーグループとユーザーが作成され、adminlun ホストが作成されています。
ただし、ユーザーはその後最後の 2 つの構成ステップを手動で実行する必要があります。それらのステップは、IBM®
Spectrum Control Base Edition 上でのストレージ・コンテナーの作成と、VMware vCenter 上での仮想計算機の作成です。「仮想ボリュームの構成」を参照。
- システムが USB 暗号化されている場合は、システム内の、暗号鍵が入っている USB フラッシュ・ドライブを挿入した任意のノードからリカバリーを実行します。
- システムに鍵サーバー暗号化がある場合、鍵サーバーに接続されているノード上でリカバリーを実行します。鍵は、鍵サーバーからリモートでフェッチされます。
- システムが USB 暗号化と鍵サーバー暗号化の両方を使用する場合、USB フラッシュ・ドライブ または鍵サーバーとの接続のどちらかを提供する (必要なのは 1 つだけですが、両方でも機能します) と、システムのロックが解除されます。
- クラウド・バックアップ構成を持つシステムの場合、T4 リカバリー時に、元のシステムからのシステム・マスター鍵が入っていた USB 鍵を新規システムの構成ノードに挿入する必要があります。あるいは、鍵サーバーを使用している場合は、鍵サーバーに元のシステムからのシステム・マスター鍵が入っている必要があります。元のシステム・マスター鍵が使用可能でなく、システム・データがクラウド・プロバイダーで暗号化されている場合は、クラウド内のデータにアクセスできません。
- システムに、USB と鍵サーバーの両方の暗号化を使用して構成されている暗号化されたクラウド・アカウントが含まれている場合、T4 リカバリーの時点で両方のマスター鍵が使用可能になっている必要があります。
- USB フラッシュ・ドライブを使用して暗号鍵を管理する場合、T4 リカバリーを行うと、USB フラッシュ・ドライブがシステムに挿入されていない場合に、クラウド・サービス・プロバイダーへの接続がオフラインになります。この問題を修正するには、現行鍵が入っている USB フラッシュ・ドライブをシステムに挿入します。
- 鍵サーバーを使用して暗号鍵を管理する場合、T4 リカバリーを行うと、鍵サーバーがオフラインである場合に、クラウド・サービス・プロバイダーへの接続がオフラインになります。
この問題を修正するには、T4 リカバリー時に、鍵サーバーがオンラインで、かつ使用可能であることを確認します。
- 鍵サーバーと USB フラッシュ・ドライブの両方を使用して暗号鍵を管理する場合、T4 リカバリーを行うと、鍵サーバーがオフラインである場合に、クラウド・サービス・プロバイダーへの接続がオフラインになります。
この問題を修正するには、T4 リカバリー時に、鍵サーバーがオンラインで、かつ USB フラッシュ・ドライブがシステムに挿入されていることを確認します。
- USB 暗号化を使用する暗号化されたクラウド・アカウントがシステムに含まれている場合、そのクラウド・アカウントがオンライン状態に移行するには、事前にシステム・マスター鍵を持つ USB フラッシュ・ドライブが構成ノード内に存在する必要があります。
この要件は、システムが電源遮断された後で再始動される場合に必要です。
- T4 回復後は、クラウド・アカウントがオフライン状態になります。アカウントをオンラインに戻すには、認証情報を再入力する必要があります。
- T4 回復前に使用可能にされていたクラウド・スナップショットを持つボリュームでは、回復後にクラウド・スナップショットを手動で再び使用可能にする必要があります。
CLI コマンドを実行するための説明を理解できない場合、コマンド・ライン・インターフェースの参照情報を参照してください。
構成データを復元するには、以下のステップを実行します。
手順
- このリカバリー手順を実行する前に、すべてのノードが候補ノードとして使用可能であることを確認します。ノードを候補状態にするには、エラー 550 またはエラー 578 を除去する必要があります。
- システムを作成する。可能であれば、本来入出力グループ 0 にあったノードを使用します。
- サポートされるブラウザーで、システムの初期化に使用した IP アドレスと、デフォルトのスーパーユーザー・パスワード (passw0rd) を入力します。
- 以下の CLI コマンドを発行して、構成ノードのみがオンラインであることを確認します。
svcinfo lsnode
以下の出力は、表示内容の例です。
id name status IO_group_id IO_group_name config_node
1 nodel online 0 io_grp0 yes
- コマンド・ライン・インターフェースを使用し、次のコマンドを発行してシステムにログオンします。
plink -i ssh_private_key_file superuser@cluster_ip
ここで、ssh_private_key_file は superuser の SSH 秘密鍵の名前、cluster_ip は構成を復元するシステムの IP アドレスまたは DNS 名です。
注: RSA ホスト鍵が変更されているため、SSH を使用してシステムに接続する際に、警告メッセージが表示される場合があります。
- 復元元の構成バックアップ・ファイルを特定します。
このファイルは、構成のバックアップ時に保存した構成バックアップ XML ファイルのローカル・コピーでも、いずれかのノード上の最新のファイルでも、どちらでもかまいません。
構成データは、毎日、システム時刻 01:00 に構成ノードに自動的にバックアップされます。
以前にシステム内にあったすべてのノードで構成バックアップ・ファイルをダウンロードして確認し、最新の完全バックアップが含まれる構成バックアップ・ファイルを識別します。
- 管理 GUI から、をクリックします。
- 「手動アップロード手順 (Manual Upload Instructions)」を展開し、「サポート・パッケージのダウンロード」を選択します。
- 「新規サポート・パッケージまたはログ・ファイルのダウンロード」ページで、「既存のパッケージのダウンロード」を選択します。
- システム内の各ノード (キャニスター) に対して、以下のステップを実行します。
- 表の上部にある選択ボックスから、操作するノードを選択します。
- パターン svc.config.*.xml* に一致する名前のファイルをすべて見つけます。
- それらのファイルを選択して「ダウンロード」をクリックし、ご使用のコンピューターにファイルをダウンロードします。
XML ファイルには日時が入っており、これによって最新のバックアップを識別することができます。
システムの復元時に使用するバックアップの XML ファイルを識別した後、ファイルを svc.config.backup.xml に名前変更します。
- リストアしたい XML バックアップ・ファイルをシステムにコピーします。
pscp full_path_to_identified_svc.config.file
superuser@cluster_ip:/tmp/svc.config.backup.xml
- 10 GB インターフェース・アダプターまたは 2 つ目のファイバー・チャネル・インターフェース・アダプターが取り付けられたノードがシステムに含まれており、以前に localfcportmask および partnerfcportmask がデフォルト以外の設定で構成されている場合、データを復元する前にこれらの設定を手動で再構成します。
- システムが、2 つのサイトにノードが配置された拡張トポロジーまたは HyperSwap® トポロジーを使用する場合、あるいはシステムに内蔵フラッシュ・ドライブを備えたノード (拡張エンクロージャーに接続されたノードを含む) が含まれる場合、これらのノードはこの時点で追加する必要があります。 これらのノードを追加するには、該当するノードすべてのパネル名、ノード名、および入出力グループを構成バックアップ・ファイルから判別してください。ノードをシステムに追加するには、次のコマンドを実行します。
svctask addnode -panelname panel_name -iogrp iogrp_name_or_id -name node_name
ここで、panel_name はパネルに表示される名前、iogrp_name_or_id はこのノードを追加する先の入出力グループの名前または ID、node_name はノードの名前です。
- システムに iSCSI ストレージ・コントローラーが含まれている場合、それらのコントローラーをここで手動で検出する必要があります。データを復元するためには、その前に、それらのコントローラーに接続されているノード、iSCSI ポート IP アドレス、および iSCSI ストレージ・ポートをシステムに追加しておく必要があります。
- これらのノードを追加するには、該当するノードすべてのパネル名、ノード名、および入出力グループを構成バックアップ・ファイルから判別してください。ノードをシステムに追加するには、次のコマンドを実行します。
svctask addnode -panelname panel_name -iogrp iogrp_name_or_id -name node_name
ここで、panel_name はパネルに表示される名前、iogrp_name_or_id はこのノードを追加する先の入出力グループの名前または ID、node_name はノードの名前です。
- iSCSI ポート IP アドレスを復元するには、cfgportip コマンドを使用します。
- IPv4 アドレスを復元するには、構成バックアップ・ファイルから id (port_id)、 node_id、 node_name、 IP_address、 mask、 gateway、 host (0/1 は no/yes を表す)、 remote_copy (0/1 は no/yes を表す)、および storage (0/1 は no/yes を表す) を判別して、以下のコマンドを実行します。
svctask cfgportip -node node_name_or_id -ip ipv4_address -gw ipv4_gw
-host yes | no -remotecopy remote_copy_port_group_id -storage yes | no port_id
ここで、node_name_or_id はノードの名前または ID、ipv4_address はポートの IP v4 バージョン・プロトコル・アドレス、ipv4_gw はポートの IPv4 ゲートウェイ・アドレスです。
- IPv6 アドレスを復元するには、構成バックアップ・ファイルから id (port_id)、 node_id、 node_name、 IP_address_6、 mask、 gateway_6、 prefix_6、 host_6 (0/1 は no/yes を表す)、 remote_copy_6 (0/1 は no/yes を表す)、 storage_6 (0/1 は no/yes を表す) を判別して、以下のコマンドを実行します。
svctask cfgportip -node node_name_or_id -ip_6 ipv6_address -gw_6 ipv6_gw
-prefix_6 prefix -host_6 yes | no -remotecopy_6 remote_copy_port_group_id -storage_6 yes | no port_id
ここで、node_name_or_id はノードの名前または ID、ipv6_address はポートの IP v6 バージョン・プロトコル・アドレス、ipv6_gw はポートの IPv6 ゲートウェイ・アドレス、prefix は IPv6 接頭部です。
ステップ b.i および b.ii を、バックアップ構成ファイルの node_ethernet_portip_ip セクションのすべての (以前に構成済みの) IP ポートに対して実行してください。
- 次に、detectiscsistorageportcandidate コマンドとaddiscsistorageport コマンドを使用して、iSCSI ストレージ・ポートの候補を検出して追加します。必ず、これらの iSCSI ストレージ・ポートを検出し、構成バックアップ・ファイルに示されるのと同じ順序でそれらを追加してください。正しい順序に従わないと、T4 障害が発生する場合があります。ステップ c.i に続き、ステップの c.ii および c.iii を実行する必要があります。バックアップ構成ファイルにリストされているすべての iSCSI セッションに対して、これらのステップをまったく同じ順序で繰り返す必要があります。
- iSCSI ストレージ・ポートを検出するために、構成バックアップ・ファイルから src_port_id、IO_group_id (オプション。値が 255 の場合は不要)、target_ipv4/target_ipv6 (ブランクでないターゲット IP は必須)、iscsi_user_name (ブランクの場合は不要)、iscsi_chap_secret (ブランクの場合は不要)、および site (ブランクの場合は不要) を判別して、以下のコマンドを実行します。
svctask detectiscsistorageportcandidate -srcportid src_port_id -iogrp IO_group_id
-targetip/targetip6 target_ipv4/target_ipv6 -username iscsi_user_name -chapsecret iscsi_chap_secret -site site_id_or_name
ここで、src_port_id は構成ポートのソース・イーサネット・ポート ID、IO_group_id は検出される入出力グループの ID または名前、target_ipv4/target_ipv6 は IPv4/IPv6 ターゲット iSCSI コントローラー IPv4/IPv6 アドレス、iscsi_user_name は検出されるターゲット・コントローラー・ユーザー名、iscsi_chap_secret は検出されるターゲット・コントローラー CHAP シークレット、site_id_or_name は検出されるサイトの指定された ID または名前です。
- lsiscsistorageportcandidate コマンドを実行して、検出された target_iscsiname をバックアップ構成ファイル内のこの特定のセッションの target_iscsiname と突き合わせ、一致する索引を使用してステップ c.iii で iSCSI ポートを追加します。
svcinfo lsiscsistorageportcandidate コマンドを実行し、構成バックアップ・ファイルから、target_iscsiname が target_iscsiname に一致する行の ID フィールドを判別します。これが、ステップ c.iii でお客様が使用する candidate_id です。
- iSCSI ストレージ・ポートを追加するために、構成バックアップ・ファイルから、IO_group_id (オプション。値が 255 の場合は不要)、site (ブランクの場合は不要)、iscsi_user_name (バックアップ・ファイルでブランクの場合は不要)、iscsi_chap_secret (ブランクの場合は不要) を判別し、ステップ c.ii で一致した target_iscsiname_index を提供してから、以下のコマンドを実行します。
addiscsistorageport -iogrp iogrp_id -username iscsi_user_name -chapsecret iscsi_chap_secret -site site_id_or_name candidate_id
ここで、iogrp_id は追加される入出力グループの ID または名前、iscsi_user_name は追加されるターゲット・コントローラー・ユーザー名、iscsi_chap_secret は追加されるターゲット・コントローラー CHAP シークレット、site_id_or_name は追加されるサイトの指定された ID または名前です。
- 構成がHyperSwapまたは拡張 システムの場合、コントローラー名およびサイトを復元する必要があります。コントローラー名およびサイトを復元するには、inter_WWPN フィールドを新規追加された iSCSI コントローラーと突き合わせることによって、バックアップ xml ファイルから ccontroller_name およびコントローラーの site_id/name を判別してから、以下のコマンドを実行します。
chcontroller -name controller_name -site site_id/name controller_id/name
ここで、controller_name はバックアップ xml ファイルからのコントローラーの名前、site_id/name はバックアップ xml ファイルからの iSCSI コントローラーの サイトの ID または名前、controller_id/name はコントローラーの IDまたは現行名です。
- 次の CLI コマンドを発行して、現行構成とバックアップ構成データ・ファイルを比較します。
svcconfig restore -prepare
この CLI コマンドで、
構成ノードの /tmp ディレクトリーにログ・ファイルが作成されます。
ログ・ファイルの名前は svc.config.restore.prepare.log です。
注: 各 256-MDisk バッチをディスカバーするには、最大 1 分かかる場合があります。このコマンドの入力後に MDisk に関するエラー・メッセージ CMMVC6200W を受け取った場合は、まだすべての管理対象ディスク (MDisk) がディスカバーされていない可能性があります。適当な時間が経過するのを待ってから、svcconfig restore -prepare コマンドを再試行してください。
- 次のコマンドを発行して、ログ・ファイルをシステムにアクセス可能な別のサーバーにコピーします。
pscp superuser@cluster_ip:/tmp/svc.config.restore.prepare.log
full_path_for_where_to_copy_log_files
- 現在コピーが保管されているサーバーからログ・ファイルを開きます。
- ログ・ファイルのエラーを検査します。
- エラーが検出された場合は、エラーの原因となっている状態を修正して、コマンドを再発行します。
ステップ 15 に進むには、
すべてエラーを訂正しておく必要があります。
- 支援が必要な場合は、サポート・センターにご連絡ください。
- 次の CLI コマンドを発行して、構成を復元します。
svcconfig restore -execute
この CLI コマンドで、
構成ノードの /tmp ディレクトリーにログ・ファイルが作成されます。
ログ・ファイルの名前は svc.config.restore.execute.log です。
- 次のコマンドを発行して、ログ・ファイルをシステムにアクセス可能な別のサーバーにコピーします。
pscp superuser@cluster_ip:/tmp/svc.config.restore.execute.log
full_path_for_where_to_copy_log_files
- 現在コピーが保管されているサーバーからログ・ファイルを開きます。
- このログ・ファイルを調べて、エラーまたは警告が発生していないことを確認します。
注: ライセンス機能が使用不可であることを知らせる警告を受け取ることがあります。
つまり、このメッセージは、リカバリー処理後に現行ライセンス設定値が
前のライセンス設定値と一致していないことを意味します。通常、リカバリー処理は続行され、正しいライセンス設定値を後で 管理 GUIに入力できます。
SSH を使用して CLI に再ログインすると、以下のような出力が表示されます。
IBM_2145:your_cluster_name:superuser>
次のタスク
次の CLI コマンドを発行して、不必要なバックアップと復元構成ファイルを構成ノードの
/tmp ディレクトリーから除去することができます。
svcconfig clear -all