ディザスターリカバリー - 特別なテクノロジーのための特別な考慮事項

特殊な計画を必要とする技術テクノロジー

IBM iの歴史の中で最も嬉しかった時の一つとして、このWebの2008年4月度の記事"System i 戦略"「災害時の復旧対策の準備は十分ですか？」を読んだ時というのが挙げられるでしょう。その思いを今日まで間大切にしてきたかと思いますが、かといってその記事を家族の写真の横に並べるのは、ちょっと抵抗があるでしょう。この抵抗感の理由は、独立補助記憶域プール(iSAP: independent Auxiliary Storage Pools)、クラスタリング、ハイ･アベイラビリティー(HA)ソリューション、暗号化、メディア管理ソリューションといった、心に親しみを覚えさせる重要なものがなかったからかもしれません。さて本稿では、これらについて簡単に説明し、これらのテクノロジーをシステム環境に適用する際に、ディザスターリカバリー(DR)計画に特別に考慮しなければいけない事項を理解していただければと思います。

独立補助記憶域プール

iASPは別名を独立ディスク・プールと言います。IBMのインフォメーションセンターには以下のように記述されています。

独立補助記憶域プール(iASP)はディスク装置の集合体で、システム上の他の記憶域から独立して、オンラインにしたりオフラインにしたりすることができます。iASPには以下が含まれます。

• 1つ以上のユーザー定義ファイル・システム
• 1つ以上の外部ライブラリ

各iASPには、格納されているデータに関連するすべてのシステム情報が含まれています。したがって、システムがアクティブになっているときにiASPをオフラインにしたり、オンラインにしたり、システム間で切り替えたりすることができます。

現在のシステムにiASPが組み込まれているか否かを確認するには、Work with Disk Status (WRKDSKSTS)コマンドを実行し、Enterキーを押した後F11キーを押します。ASPフィールドに33以上の数字が表示されていたらiASPが組み込まれていることになります。iASPが組み込まれている場合、ディザスターリカバリーを実行するにはリカバリー・ガイド(IBM Systems - iSeries Backup and Recovery Version 5 Revision 4, SC41-5304-08)の88頁から始まる、「iASPを含むシステム全体の喪失後にシステム全体を復旧する-チェックリスト21」に記載されている手順に従う必要があります。システムと基本的なユーザーASPデータを復旧する時は、RSTAUTコマンドに*SYSBAS を指定するのを忘れないでください。オペレーティング・システムとその他のデータを回復すると、iASPを作成することができます。リカバリー・ガイドでは、これらの手順を実行する際にIBM Navigator for i を使用することを勧めています。

1. [ナビゲーター]で[マイ・コネクション] (またはアクティブな環境)を開きます
2. IBM iサーバーを開きます
3. [構成とサービス]を開きます
4. [ハードウェア]を開きます
5. [ディスク・ユニット]を開きます
6. [ディスク・プール]を右クリックし、[新規のディスク・プール]を選択します
7. ウィザードの説明に従って、新しいディスク・プールにディスク・ユニットを追加します

iASPが作成できたら、それを使用する前に利用可能に(オンに構成変更)しておかなければなりません。

1. [ナビゲーター]で[マイ・コネクション] (またはアクティブな環境)を開きます
2. IBM iサーバーを開きます
3. [構成とサービス]を開きます
4. [ハードウェア]を開きます
5. [ディスク・ユニット]を開きます
6. [サービス・ツールへのサインオン]ダイアログ・ボックスが表示されたらサービス・ツールにサインオンします
7. [ディスク・プール]を開きます
8. 利用可能になっていないディスク・プールを右クリックし、[利用可能にする]を選択します。複数のディスク・プールを同時に選択して利用可能にすることができます
9. ダイアログ・ボックスが表示されたら[利用可能にする]をクリックしてディスク・プールを利用可能にします

iASPが利用可能な状態になったら、そのiASPにデータを回復させることができます。RSTAUTを*SYSBASに変更したので、データを回復する前にRSTUSRPRFコマンドを実行する必要はありません。ライブラリの回復には、単にRSTLIBコマンドを使用すれば良いのです。RSTLIBコマンドの回復ASP数(RSTASP)のデフォルト値は*SAVASPですから、ライブラリは保存時と同じiASPに回復されます。IFSオブジェクトを回復している場合は、そのオブジェクトがUser Defined File System (UDFS)がマウントされている状況で保存されたのか、マウントされていない状況で保存されたのかを把握しておく必要があります。iSAPがマウントされていた場合は以下のステップで回復させます。

6.1.0以降の場合

1. RST OBJ(('/マウント先のディレクトリ ')) RBDMFS(*UDFS)

5.4.5以前の場合

1. Create User-Defined File System (CRTUDFS)コマンドを使用して、復旧する前と全く同じUDFSを作成します。権限とオブジェクトの監査を忘れずに含めてください。
2. Create Directory (CRTDIR)コマンドを使用して、保存時に各UDFSがマウントされていたディレクトリを作成します。
3. Add Mounted File System (MOUNT)コマンドを使用して、UDFSを上記で作成したディレクトリにマウントします。
4. 次のコマンドを使用してUDFSを回復します。
   RST OBJ(('/マウント先のディレクトリ '))

iASPがマウントされていなかった場合は以下のステップで回復させます。

1. iASP中のすべてのQDEFAULTユーザー定義ファイル・システムをアンマウントします。
2. 以下のように入力して、UDFSをすべてiASPに回復します。
   RST OBJ(('/DEV/iasp名'))
   ここでiasp名はiASPの名前です。複数のiASPを保存した順番で回復させたい場合は、RST OBJ(('/DEV/*'))を指定して、各iASPに対するすべてのユーザー定義ファイル・システムを回復させることもできます。
3. 上記ステップ1でアンマウントしたQDEFAULTユーザー定義ファイル・システムを、すべてマウントします。

iASPの詳細については、IBM iインフォメーションセンターのサイトを参照ください。

クラスター環境とHAソリューション

運用しているシステムが、クラスター環境の一部であるとわかる場合がほとんどでしょうが、わからない場合は、Display Cluster Information (DSPCLUINF)コマンドを使用して、クラスター環境下にあるのか否かを調べることができます。運用しているシステムがクラスターの一部ではなければ、DSPCLUINFコマンドを実行したときに、一番上にクラスターとして*NONEが表示されます。運用しているシステムがクラスターの一部である場合は、クラスター・ノード情報とクラスター資源グループ情報を印刷しておいた方がよいでしょう。

クラスター情報を表示させるコマンド
DSPCLUINF DETAIL(*FULL) OUTPUT(*PRINT)

クラスター資源グループを表示させるコマンド
DSPCRGINF CLUSTER(クラスター名) CRG(*LIST) OUTPUT(*PRINT

実際のクラスター構成はSAVCFGコマンドで保存できます。SAVCFGコマンドはSAVSYSコマンドの一部です。システムを復旧したあと、クラスタリングを復旧したノードからではなく、アクティブなノードから開始してください。こうすることで最新の構成が復旧されたノードに伝搬されます。

クラスタリングとiASPは、IBMやその他のベンダーが提供している多くのHAソリューションの基礎をなすものです。HAソリューションには、ジオグラフィック・ミラーリング、メトロ・ミラーリング、ピアツーピア・リモート・コピー(PPRC)やサード・パーティー製ソリューションがあります。

HAソリューションは、回復あるいはDRの大きな部分を占めるものではありますが、こうした複数のソリューションの概要について少しでも書き始めたら本稿は膨大な頁を占めることになってしまうでしょう。したがって、運用している環境に適した回復ステップや、特定のHA製品については、ソリューション・プロバイダを案内することにとどめておきます。

暗号化

セキュリティが厳しくなるにしたがって、暗号化がより一般的になってきています。使用しているメディアの輸送中や、オフサイトでの保管中での安全性を保つために、テープの暗号化は必要悪といえます。企業によっては、一部のテープ暗号化が法によって義務付けられている場合もあります。テープの暗号化を使用するときは、ディザスターリカバリーにおいて特別に考慮しなければならないことがあります。暗号化機能を使用していることをDRサイトにきちんと伝えてください。特別なハードウェア、ソフトウェア、あるいは別のプラットフォームが必要となる場合があります。

IBM iプラットフォームで利用できる暗号化には、主に4つの種類があります。

テープ・ドライブ暗号化
テープ・ドライブ暗号化は、テープ・ドライブ自体で実行される暗号化です。特定のテープ・ドライブでだけ、ハードウェア・ベースの暗号化機能が利用できます。IBM ナレッジ・ドキュメント KB423991279によれば、TS1120/TS1130は3494、TS3500またはTS3400に装着できますが、LTO4はTS3500、TS3310、TS3200、TS3100またはTS2900に装着できます。LTO4ドライブを使用する場合は、Transparent LME機能が必要です(FC 5900と9900またはTS3310、TS3200、TS3100、TS2900用のFC 5901)。

テープ・ドライブ暗号化は一般的に、鍵の管理に暗号鍵マネージャー(EKM: Encryption Key Manager)またはTivoli鍵ライフタイム・マネージャー(TKLM: Tivoli Key Lifetime Manager)を使用します。DRの目的のためには、通常同じボックス上では鍵を暗号化すべきではありません。鍵を取り出す方法がないからです。したがって、鍵は暗号化せずに別のテープで送付する場合もあります。より安全な方法は、EKMまたはTKLMを、別のシステムや別のプラットフォームに置いておく方法です(こうすると暗号化できます)。テープ・ドライブ暗号化による復旧が実行できるように、DRサイトで正しいテープ･ドライブ・ハードウェアとプラットフォームが利用可能になっているようにしておいてください。

暗号化ハードウェア装置
サード・パーティー・ベンダーから提供されている外付けの装置を使用して、データを暗号化することができます。こうした装置はホストから見えるように設計されており、テープ・ドライブのタイプに依存しません。ハードウェア・ベースの暗号化は一般的に言って、ソフトウェア・ベースの暗号化よりも性能が良いです。DRのためには、使用している暗号化装置のタイプに気を付け、リカバリー・サイトでもそれが利用可能となるように計画してください。

アプリケーション暗号化 アプリケーション暗号化は、ソフトウェア・ベースのものもあればハードウェア・ベースのものもあります。アプリケーション暗号化は、特定のデータベースまたはアプリケーション・データのみを暗号化するように設計されています。3つの主な種類としては、IBM i Cryptographic API (リリース5.3からは、リリースごとにさらにAPIが追加されています)、Java Cryptography Extension (JCE)、Cryptographic Coprocessorカードがあります。
アプリケーション暗号化を使用する場合は、復旧に使用する正しいライセンス製品とハードウェアが揃っていることを確認してください。そしてもちろん、必要となる鍵が揃っていることも確認してください。

ミドルウェア暗号化
多くのベンダーが、ソフトウェア・ベースのソリューションを提供しています。そのほとんどが、鍵管理システムを使用して鍵を保存します。自環境の復旧に特別な考慮が必要か否かについては、ベンダーに問い合わせてください。

メディア管理ソフトウェア

あまりに多くのデータと山のようなバックアップがある場合は、メディア管理ソフトウェアを使用することで、ディザスターリカバリーがずっと効率的になります。特殊なバックアップを実行している場合は、おそらく特殊な復旧を実行することになるでしょう。幸いなことに、これがメディア管理製品のもっとも価値ある部分なのです。すなわち、それぞれの用途に応じてリカバリー・レポートをカスタマイズしてくれるのです。レポートをオフサイトにも送付することを忘れないでください。そうしないと、完全なディザスターリカバリーの最中に利用できなくなってしまう可能性があります。

メディア管理製品をバックアップに使用している場合は、回復時にはリカバリー・レポートに従うようにしてください。IBMのリカバリー・ガイドやネイティブのコマンドを使用したくなるかもしれませんが、リカバリー・レポートに一覧されている通りに従うことが重要です。メディア管理製品のほとんどはIBM iネイティブの保存/回復コマンドを使用していますので、製品を復旧する際に問題が生じた場合でも、ユーザー・データは復旧できます。ただし、製品のコマンドを使用した場合のみにデータを簡単に復旧できるような、特別な保存がある点に注意してください。リリース5.3およびそれ以前のリリースでのスプール・ファイルがその例です。もう一つの例としては、データをメディア・ボリューム間で分離するような、完全な並行バックアップが挙げられます。並行または並列バックアップを実行している場合は、DRサイトに最低でも同じ台数の復旧用装置があることが重要です。そうでないと、ボリュームの切り替えによって復旧に時間がかかったり、面倒なものになったりしてしまいます。

メディア管理ソフトウェアはバックアップおよび復旧ソリューションとして理想的なものです。メディア管理ソフトウェアは、正しいバックアップ・ボリュームの選択、ベースデータとそれに対する変更の回復、ジャーナル変更の適用などといった、必要なステップを自動的に遂行できます。このようなソフトウェアもiASP、HAソリューション、暗号化データなどに対応できるようにアップデートされています。メディア管理ソフトウェアを購入したのに、バックアップや復旧の計画にそれを組み入れていない企業何社かに出会ったことがあります。通常このような手抜かりは、時間がないとか、そのメディア管理製品に対するスキルがないとかいった理由で起こります。こうした障害物があるのは理解できますが、大規模な復旧が必要となった場合、こうした製品に対して割く時間とトレーニングの優先度を、日々のビジネスにおいてなぜ高くしておくべきなのかが、すぐにお分かりになるでしょう。

準備は万端に

ディザスターリカバリーで最も重要なことは、しっかりと準備をすることです。つまり、適切なバックアップを用意し、特別な考慮点も熟知して、DR計画に非の打ちどころがなくなるまでテストを繰り返すことです。もちろん、考慮しなければならない事項や例外、利用可能な製品はまだ他にもあるでしょう。ですから、準備を整え、復旧の計画を繰り返しテストする必要があるのです。さあ、何をじっと待っているのですか。災害に襲われる前にバックアップと復旧の計画を完全なものにしておいてください。

ブライアン・ボーナー氏は、2001年からIBMロチェスター研究所のIBM iサポート・センターでソフトウェア・エンジニアとして勤務しています。同氏はSave/Restore/BRMSチームのシニア・メンバーです。同氏の得意とする専門分野には、アップグレード、バックアップ、リカバリー、PTF、BRMS,仮想メディアなどがあります。さらに同氏は作業管理チームにも属してプリ・アップグレード検証ツールを作成し、バックアップ/リカバリーの性能面においても指導的立場の専門家です。同氏は、IBM Virtual Tape Redbookや、イメージ・カタログを初めて導入したeServer iSeries誌の記事など複数の技術文書を執筆しています。同氏はリモート・テクニカル・サポート、今後のリリース機能/サポート、研究所でのテストを続けており、システムのインストールやディザスターリカバリーを実行するために国内外を飛び回っています。

あわせて読みたい記事