ロール スワップの際の「地雷」を回避する
ディザスター リカバリー（DR）計画を策定しておくことは、IBM i を稼働している多くの企業にとって極めて重要です。これらのシステムに置かれているデータは、企業にとってミッション クリティカルなデータであることが多いと言えます。ディザスター リカバリー戦略を実装することは大変なことです。ディザスター リカバリー戦略を計画して実際に実行することはさらに大変です。
優れた計画が策定されている場合でも、指定されたディザスター リカバリー マシンへのロール スワップ テストが、本番サイトへ急遽ロール スワップを戻さざるを得ない不測の事態により、何度も失敗してしまうことがあります。この記事では、近い将来に起こるかもしれないロール スワップが確実にうまく行われるように、注意しておくべきいくつかの「地雷」についてまとめてみました。
対策その1：緊急時にライセンス キー入手のためにベンダーに連絡を取る最善の方法を決めておく。
ロール スワップは、企業の最も静かな時間帯に起こることがよくあります。そのような時間帯は、重要なアプリケーションのサポートを提供するベンダーで電話に出る人がいない時間帯でもあるかもしれません。ロール スワップ後に、ライセンス キーの入力が必要になるかもしれませんし、あるいは、有効だと思っていたライセンス キーが、実際は有効なキーではなかったことに気付かされる場合もあるかもしれません。必要なときに誰かに連絡してライセンス キーを入手することができない場合、ライセンス キーのような非常に単純なものが、企業全体を窮地に陥れる可能性があります。
ロール スワップの計画を策定する際に、製品のライセンス キーを提供するすべてのサードパーティ ベンダーのリストを作成するようにします。それぞれのベンダーに問い合わせて、サポート対応時間を控えておきます。スワップに最適な時間帯にサポートが利用できない場合は、万が一必要になった場合に備えて、有償のオンコール サポートを提供できるかどうかを確認しておきます。サポートの手配が必要な場合に、電話の向こうで誰かが答えてくれることが分かっていれば、大きな安心感が得られます。
対策その2：DRサイトのパブリックIPが、他の会社への転送のためにホワイトリスト登録されるようにする。
多くのショップで必要なことは、IBM i から他の会社へデータを転送できるということです。この転送がDRロケーション（パブリックIPが異なる可能性が非常に高い）から開始される場合、その転送を受け取る側の企業は、そのアドレスを知らないアドレスとみなして、その接続を拒否する可能性があります。計画段階で行うべき重要なステップは、転送を行う先のすべての企業に連絡を取り、DRロケーションのパブリックIPアドレスを伝えておくことです。そのようにすることで、必要に応じて、彼らはそのIPアドレスをホワイトリスト登録して、確実に彼らのシステムがデータを受け取れるようにすることができます。
対策その3：DRロケーションが異なるサブネットを使用している場合は、IPアドレスを更新する。
ネットワーク アーキテクトは、2つのサイトにまたがるようにネットワークを拡張するか、その都度、別個のネットワークを使用するようにするか決める必要があります。どちらのネットワーク構成にも、それぞれメリットとデメリットがあります。別個のネットワークのデメリットは、特にフル システム複製セットアップでは、DRシステムでいくつかの「地雷」に遭遇する可能性があることです。そこでは、サービスのIPは依然として、DRサイトではなく本番サイトからネットワークを使用するよう求められているためです。別個のネットワークがある場合に、DRシステムで更新される必要がある共通の項目がいくつかあります。
- ホスト テーブル項目 - CFGTCP（「TCP/IPの構成」コマンド）のオプション10 。
本番サイトのIPに解決されるすべての項目が、DRサイトのIPに解決されるように更新される必要があります。これは、奇妙なことに、「Rename（名前の変更）」オプションを使用して、その項目のIPアドレスを変更することによって行われます。 - Webサービス - HTTP Web Administration for i 。
特定のIPアドレスにバインドされているWebサービスがあるかどうかを確認します。サービスのプロパティへ移動して、それらをDRサイトのIPに更新します。 - SMTP IPバインド - Navigator for i 。
SMTPクライアントおよびサーバーは、システム上の特定のIPにバインドされていることがあります。DRサイトでは、そのシステム上に存在し、アクティブであるIPにバインドする必要があります。最も簡単にこの変更を行う方法は、Navigator for iで、SMTPサービスを探して、プロパティに移動し、サーバーおよびクライアント バインドのIPを更新することです。次いで、SMTPサービスを再起動します。
対策その4：ディレクトリー項目が複製されていることを確認する。
フル システム複製を行わないセットアップでは、ディレクトリー項目が複製されていることを確認する必要が生じることがよくあります。これらは、一部のシステムではメールを送信するのに必要であり、他のシステムでは文書ライブラリー オブジェクト（DLOおよび/QDLSファイル システムとしてよく知られています）にアクセスするのに必要です。システム配布ディレクトリーには、これらの項目の「シャドーイング」を可能にして、それらを別のシステムに複製できるようにする機能があります。余分なソフトウェアは必要ありません。この機能を有効化するための手順については、 こちらのページを参照してください。
対策その5：Webサービスは複製されていますか。
クリティカルなデータを複製することは重要なことです。しかし、そうしたクリティカルなデータにアクセスするために稼働している必要があることが多いWebサービスを複製することも重要です。DRサイト システムでテストを実施して、Webサービスの複製コピーが起動でき、アクセス可能であることを確認します。また、これらのWebサービスをセキュアにする証明書が、確実にDRサイトでも保存されるようにすることも重要です。証明書が利用可能ではなく、セキュアな接続ができない場合、どのようにしてDRシステムへ証明書を届けたらよいか慌てて対応を考えることになります。
ご覧の通り、計画と準備は、ロール スワップの成功の鍵です。これらの落し穴について把握しておくことで、DRテストをはるかに円滑に進行させることができます。今後のロール スワップがうまく行われることをお祈りします。願わくば、テストなしの行き当たりばったりではなく、きちんとした計画の下で行われますように。
