クラウド環境での災害復旧

クラウド・プロバイダーからのサービスが完全に途絶えた場合に備える

ごく小規模な組織であっても、災害発生時に事業を継続させるための対策をしておかなければなりません。クラウド・プロバイダーからのサービスが完全に途絶える可能性は極めて低いものの、その事態に備えておかないとしたら、それは無責任なことです。災害復旧の作業は複雑になりかねませんが、クラウド・コンピューティング環境では大幅に単純化されます。この記事では、著者の組織で最近行った災害復旧の演習で実行したステップについて説明します。このプロセスを、皆さんが独自の災害復旧作業を行う際の雛形として、どのように活用できるかを学んでください。

Bill Robbins, System Engineer, The Educopia Institute

Bill RobbinsBill Robbins は、Amazon EC2 クラウドでベースのインフラストラクチャーを運用している非営利団体、Educopia Institute のシステム管理者です。Georgia Institute of Technology で電気工学の理学修士号と学士号を取得しました。2008年に Educopia に参加する前は、BellSouth および Emory University で IT およびネットワーク管理に携わり、フロリダ州とジョージア州の電気通信会社では設計技師として働いていました。グラフィカル端末が誕生する前から、さまざまな UNIX システムを扱っていました。



2011年 2月 07日

企業のインフラストラクチャーをクラウド・コンピューティング環境に移すことによってもたらされる単純さを利用している中小企業は数多くあります。しかし、それらの企業の多くは、クラウドでのインフラストラクチャーに対する災害復旧計画を立てておかなければならないことを認識していません。クラウドでの災害復旧に必要な作業は、サーバー・クライアント・インフラストラクチャーやネットワーク・インフラストラクチャーの場合に必要な作業とは違います。これらの違い、そしてクラウドでの災害復旧において実行しなければならないステップが、この記事のトピックです。

私が所属している Educopia Institute という小さな組織では、学術コミュニケーションのための共有サイバーインフラストラクチャー・プロジェクトを計画し、実装しています。最近、この組織で完全な災害復旧の演習を実行したところ、災害復旧のプロセスは、クラウド・コンピューティング環境では極めて単純化されることがわかりました。この記事では、演習の際に実行したステップを説明します。

よく使われる頭文字語

  • DNS: Domain Name System
  • SSL: Secure Sockets Layer

注: 自ら用意した本番環境を使用しているとしても、開発環境をクラウドで運用しているとしたら、この記事で提供する情報を適用することができます。

当然利用している仮想環境

クラウドで実行するということは、当然、仮想サーバーを使用していることになります。すぐに実行できる仮想サーバーのコピーを作成するのは、物理サーバーを用意するときよりも遥かに簡単で、費用も少なく済みます。災害復旧用のクラウド・ベンダーにイメージを保管する必要はあるものの、サーバーの災害復旧インスタンス用に追加ハードウェアを用意する必要はありません。仮想サーバーを一からロードして実行するまでの時間は、物理サーバーを一から再構築するよりも、ずっと短時間で済みます。このすぐに実行に移せる仮想サーバーのコピーが、災害復旧計画の中心となります。

災害復旧計画に取り掛かるには、サーバー・イメージを実行できる、物理的な第 2 の場所を用意する必要があります。この場所は、プライマリー・サーバーのある場所から少なくとも数百マイルは離れたところにしてください。要員はすでにインターネットを介してサーバーに接続しているので、災害復旧チームを現場に派遣する必要はありません。

Amazon EC2 内でのマイグレーション

ダウンロード」セクションには、私の組織のインフラストラクチャーを Amazon EC2 内でマイグレーションしたときに使用した、ec2-migrate-manifest コマンドのサンプル (このコマンドの説明 (Description)、構文 (Syntax)、オプション (Options) を参照) が用意されています。

私の組織では、Amazon EC2 (Amazon Elastic Compute Cloud) を使用しています。ある Amazon データ・センターから別の Amazon データ・センターには、比較的簡単に移ることができます。Amazon クラウド内でのマイグレーションに必要となるこの魔法のコマンドは、ec2-migrate-manifest です。一方、異なるベンダーのデータ・センター間で移動するとしたら、同じベンダーのデータ・センター間で移動する場合よりも複雑になってきます。クラウド・コンピューティング環境を提供しているベンダーは数多くあるので、災害復旧用に最適な代替ベンダーを判断しなければなりません。Amazon EC2 を使用するか、別のベンダーを使用するかに関わらず、災害復旧の本格的な演習に取り掛かる前にはまず、小規模な概念実証を作成する必要があります。


概念実証を作成する

この概念実証では、プライマリー・データ・センターから災害復旧用データ・センターに、仮想サーバー全体のイメージをコピー、またはマイグレーションする必要があります。この始めの段階では、本番サーバーの完全な最新イメージでなくても構いません。ここでは、あるクラウドのサーバーを別のクラウドのロケーションに再現できることを証明しようとしているだけだからです。概念実証では、実際のデータを実行する必要も、本当の Web アドレスを使用する必要もありません。

また、概念実証には大々的な環境を構築する必要がないので、ある程度のストレージ・スペースをセットアップし、小さなサーバーをすべてのクラウド・コンピューティング環境のベンダーで実行すれば費用を抑えられます。可能であれば、現在使用している災害復旧用のクラウド・コンピューティング環境を使用してください。そうすることで、実際の状態に近くなるからです。概念実証の実行に成功すれば、計画を進めることができます。

念頭に置いておくべき点として、おそらくこのベンダーまたはサイトを使用することは当分ありません。ただ、事業が継続できなくなることを事前に把握できるだけの注意を十分に払ってください。この災害復旧用ベンダーには、定期的にイメージを配布します。これが、何かが機能しなくなったことを知る方法となります。


災害復旧サイトで何を実行する必要があるかを判断する

当然のことながら、クラウド内で実際に何を実行していて、何をセットアップしているかを把握し、ドキュメントにしておく必要があります。そのためには、データを集めなければなりません。

この作業が完了したら、災害復旧サイトに移すべき項目を慎重に判断します。これは、「とりあえず何もかも移す」というような単純なことではありません。機能や関数のなかには、テストのために用意されているものもあれば、不可欠ではないため、後で復元できるものもあります。

実際にクラウド内で使用しているすべてのものを調べるには、どうすればよいのでしょうか?それには、クラウド内で使用している項目をドキュメントにし、その内容が最新の状態になっていることを確認するという方法があります。実行中の本番サーバーでシェルにログインし、本番サーバーが正常に稼働していることを確かめてから、以下のステップに従ってファイルを作成してください。これらのファイルが、サーバー上で実行されている項目を記録するのに役立ちます (以下に記載するコマンドは、どのバージョンの Red Hat Linux® でも機能するはずです)。

  1. 実行中のプロセスを記録します。
    ps –ef  > /tmp/procs.txt
  2. サーバー上でアクティブになっている接続を判別します。
    netstat -an > /tmp/connects.txt
  3. サーバー上のファイルシステムを判別します。
    df -ah > /tmp/mounts.txt
  4. 実行中の cron ジョブを記録します。
    cd /var/spool/cron
    
    more * > /tmp/crons.txt

サーバーを一から再構築するのではなく、ここでは仮想サーバーを移そうとしているので、システム上に存在するすべてのソフトウェア・パッケージ、すべてのモジュール (Apache または Perl モジュールなど)、Ruby GEM などを明らかにする必要はありません。というのも、ここでは仮想イメージをコピーするつもりなので、これらの要素はすべて災害復旧サイトに存在することになるからです。

接続のリストは、災害復旧サイトで必要なセキュリティーおよびファイアウォールの設定を判別するのに役立ちます。もう 1 つ重要な点として、このリストから、皆さんがアクセスを許可している他のサーバー、そして皆さんからのアクセスを許可している他のサーバーのすべてが明らかになります。

プロセスのリストは、行ごとに災害復旧サイトで稼働中のサーバーと対応しているはずです (システムを実行しているハードウェアに関連するプロセスについては、その限りでありません)。これを見れば、すべての起動スクリプトがどれだけ上手く構成されているかがわかります。

正しく開始されないプロセスに関しては、プライマリー環境の起動スクリプトでその問題に対処しなければならない場合があります。特に以下の点は、cron ジョブのそれぞれについて個別に評価する必要があります。

  • ジョブが実行される時間に本当に意味があるのか
  • サーバーが別のタイムゾーンで稼働することから、それに応じた変更が必要かどうか
  • 呼び出されるスクリプトのなかに、プライマリー・クラウド・コンピューティング環境で提供されている設備を利用するスクリプトがあるかどうか。そのようなスクリプトがある場合、その設備を災害復旧用環境で使用できるようにする必要があるかどうか

ファイルシステムで第一に調べる必要があるのは、サイズの問題です。災害復旧サイトで突然ファイルシステムがフルになるようなことは避けなければなりません。

これらのリストをひと通り調べ、災害復旧サイトで再現しなければならない項目を決定してください。項目のリストを絞り込むことができれば、そうするのが賢明です。このリストが用意できたら、次のステップに進むことができます。


災害復旧サイトを最新の状態に維持する

もうすぐ、イメージを作成して災害復旧サイトに送れるようになりますが、全体のプロセスは、クラウド・プロバイダーによって変わってきます。

また、このプロセスを実行する頻度、そして災害復旧サイトを最新の状態に保つ方法についても検討しなければなりません。失っても差し支えない時間とデータの量と、何も失われないことを確実にするための代価とを比較して、慎重に検討してください。どの作業も、どのデータも失いたくないのは当然ですが、それには代償が伴うのは確かです。

私の組織を例に挙げると、私たちは 1 週間分のデータがなくても致命的ではないと判断し、完全な仮想イメージは毎月一回の頻度で作成しています。このイメージは、災害復旧サイトにも送られます。私たちは 1 週間に一度、フル・バックアップを行い、増分バックアップを毎日行っています。毎週のフル・バックアップについても、災害復旧サイトに送ることにしました。これらのバックアップについては、プライマリー・サイトで冗長化する必要はなく、わずかな追加料金を支払ってインターネット経由で送信しているだけです。


完全な演習を行うためのステップ

チェックリストを検討して代わりのクラウド・サーバーを稼働させる場所がわかったら、次はベータ・テストを実行する必要があります。

本番サーバーの完全なイメージは、代替クラウドにコピーするのでも、マイグレーションするのでも構いません。災害時に代わりに使用するサーバーを都合のよいときに実行して、プロセスのこの部分が正常に機能することを確認します。プロセスが円滑に進むことを確認した後、完全な災害復旧の演習を開始するまでには、まだいくつかのステップが残っています。

新規ネットワーク ID

最大の変更は、災害復旧サーバーのネットワーク ID です。簡単に言うと、災害復旧サーバーには別の IP アドレスを使用しなければなりません。ドメイン名はすべてそのまま維持することができますが、それぞれの IP アドレスについては変更の必要があります。この変更によって生じる問題はいくつかありますが、なかでも大きな問題は、ドメイン名に対応する IP アドレスを変更することです (これを DNS A レコードと呼びます)。A レコードを変更する必要があるのは、災害復旧の演習を実行するとき、そして実際の災害発生時です。

A レコードを更新する方法はさまざまにありますが、一般には、DNS プロバイダーでのアカウントの ID とパスワードを調べ、レコードを変更する方法を調べるという作業が必要になります。災害復旧サイトで IP アドレスを恒久的に確保し、その IP アドレスを DNS エントリーとして入力してください。この DNS エントリーに名前を付けることで、IP アドレスを検索すると有効なレコードが結果として返されることが確実になります。

一例として、www.agreatsite.com という Web サイトの場合、災害復旧サーバーには alt-www.agreatesite.com、あるいは drwww.agreatesite.com のような恒久的な DNS レコードを指定します。災害復旧の演習を実行するときには (そして実際の災害発生時にも)、DNS プロバイダーのサイトにアクセスし、www.agreatsite.com の IP アドレスを災害復旧サイトの IP アドレスに切り替えればよいのです。alt-www.agreatsite.com のエントリーを変更または削除する理由は何もありません。DNS レコードを維持しておけば、この災害復旧サーバーの情報を他のサイトやサーバーがそのセキュリティー設定に入力しなければならないときに役立ちます。

新規 ID のセキュリティー設定

次に、災害復旧 IP アドレスを他のすべての従業員、部署、ベンダー、パートナーと共有します。つまり、災害復旧 IP アドレスを、現在、プライマリー IP アドレスをセキュリティー設定で使用しているすべてのエンティティーと共有します。これは、十分な考慮と調査が必要となる項目の 1 つです。セキュリティー設定は、サーバーが別のシステムとの接続を開始するときに必要になります。

ファイアウォールに、これらの接続に対する既存のルールが設定されている場合もあれば、設定されていない場合もあります (おそらく、設定されていない可能性のほうが高いと思います)。一般に、ファイアウォールの内側にあるサーバーが接続を開始する場合には、何の制約もありません。同様に、netstat コマンドを実行したときに、アクティブな接続が確認できる場合も、確認できない場合もあります。おそらく、この接続は必要なときにだけ実行され、cron によるスケジューリングはされていません。例えば、ある種の更新は、必要なときにだけ、セキュアな転送によって手動で送信することになる可能性もあります。

災害復旧サイトでの変更

最後に必要な作業は、災害復旧サイトでプライマリー・サイトと異なる点をすべて把握することです。必ず以下の項目について検討し、必要となる変更をリストアップしてください。

  • タイムゾーン
  • バックアップおよびアーカイブ用のストレージ
  • 模倣する必要のあるクラウド・コンピューティング環境の設備
  • このような施設を参照するスクリプトまたはコードに対する変更
  • ホスト名ではなく IP アドレスを使用するスクリプトまたはコードに対する変更

可能であれば災害復旧の演習の前に、必要な変更を行ってください。災害復旧の演習の際にしか実行できない変更であれば、そのための準備をしておいてください。


災害復旧の演習を実行する

ここからは、完全な災害復旧の演習を実際に実行することに焦点を当てます。データを記録して、災害復旧の演習の実行に関して「真剣に考える」だけでは足りません。災害復旧の演習で順に実行するステップを適切に決めてから、演習をスケジューリングしてください。演習の日時についてはチームのメンバーの同意が必要で、サイトを短期間停止しても、その影響がほとんど、あるいはまったくない日時にする必要があります。演習の日時が決まったら、関係者に事前に知らせ、スケジューリングされた演習の時刻に混乱が起きないようにしてください。

ここで強調しておきたいのは、この演習のとき以外は災害の発生を事前に確実に知ることはできないということです。

演習の開始

演習では何よりも先に、DNS 設定を変更します。これは、DNS 設定の変更が伝播するまでには時間がかかるためです。DNS 設定を変更した後、プライマリー・サーバーを停止できますが、災害復旧サイトを開始する前に、プライマリー・サイトの停止による被害を軽減するために早急に行える措置がないかどうかを検討してください。

Nagios などを使って、監視やアラートを構成しているとしたら、警報をオフにして構いません。また、他にもプライマリー・サーバーに依存しているシステムがあるかもしれませんが、それについてはどのような措置を取れるかを考えてください。災害復旧サイトを準備している間、素早く実行できる措置や、誰かに処理を頼めることがあったら、そのようにするべきです。

災害復旧クラウドへの移行

次に、災害復旧サイトでサーバーを起動します。前に作成したチェックリストに従って順に実行してください。災害復旧サイトでイメージをどのように保持することにしたかによっては、バックアップもリストアしなければならない場合があります。

サーバーがブートした後に、サーバーで最後の仕上げが必要になる場合もあります。例えば、災害復旧サイトのストレージ設備を使用するように、サーバーで実行されるスクリプトを変更するなどです。もちろん、定期的に災害復旧用イメージを作成するというタスクは中断するか、変更しなければなりません。また、cron ジョブの実行回数も変更しなければならない可能性があります。

機能テストの実行

DNS の変更が伝播するまでしばらく待った後 (私たちの経験では、2 時間から 4 時間でした)、諸々のテストを開始することができます。ここで、テストを開始するにあたって当然実行しなければならないパスを実行し、多少のリバース・エンジニアリングを行います。最初にチェックするのは、例えば Web サイトが稼働しているかどうかなど、最も明らかなことです。それには、クラウド内で実行しているサイトを一覧にした RSS フィードをあらかじめ用意しておかなければなりません。まだ用意していない場合には、この時点でフィードを作成してください。このフィードには、公開されているサイトだけでなく、サーバーを管理するために使用しているサイト (phpMyAdmin など) と Drupal ユーザー・ログインも含めます。同じように、プロセス監視についてもチェックが必要です。一時的に導入されたプロセスで、今となっては実行される可能性のないプロセスがないかどうかをチェックしてください。また、別のサイトでは停止しておかなければならなかったプロセスも、今度は実行できるかもしれません。

ここで、最初に取った記録に戻り、項目のそれぞれを詳しく調べて、すべてのプロセスとネットワーク接続が有効かつ正常であることを検証します。ここからは、組織がそれぞれに異なるテスト一式を実行して、復旧が成功したことを検証することになります。すべてが上手く行けば、後はすべての cron タスクが確実に実行されるようにし、その後の数日間でこれらのタスクがどのように実行されるかを確かめればよいのです。

詳細のドキュメント化

すべてが上手く行ったとしても、この極めて重要なテストでは完全とは言えないかもしれません。この時点で、演習の実行中に見逃していた可能性のある措置も含め、すべてのステップをまとめてドキュメントにする必要があります。ドキュメントを作成したら、ようやく演習をひと通り振り返って万事が完璧に行われることを確認できるようになります。


プライマリー環境に復帰し、すべてを再び繰り返す

「プライマリー環境への復帰」の演習は、翌週末に行うようにスケジューリングします。この演習は、実際の完全な災害復旧の演習を実行する上で大きな部分を占めます。この演習を 2 回実行して、あらゆる誤りから学び、実際の災害が発生した場合に備えて万全を期してください。

この復帰の演習の際には、上記の演習全体を再度繰り返します。意図的な機能停止を再びスケジューリングして、すべてを通常の状態に戻してください。2 回目の演習では、すべての項目が適切にドキュメント化されることを確信することができます。

必ず、災害復旧の演習を全面的に見直してください。演習はおそらく 6 ヶ月から 2 年に 1 回の頻度で、定期的に実行する必要があります。システムに変更があった場合には、災害復旧計画にも変更を加える必要があるかどうかを必ず評価してください。


まとめ

災害復旧の取り組みは、組織によっても、サイトによっても異なります。この記事では、災害復旧の取り組みを始めるのに適した出発点を紹介し、その際に考慮すべき事項を説明しました。当然、この記事で取り上げた以外にも、調査対象となる項目はあります。例えば、IP アドレスに SSL 証明書を関連付けている場合には、必要となる作業やコストが増えるかもしれません。プライマリー・サイトと災害復旧サイトのそれぞれで実行されるスクリプトを編集する手間を省くとしたら、実行されている場所を検出するためのコードを単純にスクリプトに追加するという方法もあります。次回はこの方法を採ろうと計画していて、役に立つサイト www.whatismyip.com を見つけました。以下のコマンドを実行してください。

wget http://www.whatismyip.com/automation/n09230945.asp -O public_ip.txt

すると、このコマンドによってパブリック IP アドレスが返されます。サイトごとに変更する必要のあるスクリプトの case 文では、その IP アドレスを使用することができます。

災害復旧の演習は、サイト運用に別の利点ももたらします。それは、すぐに実行できる完全かつ最新のテスト環境を用意できることです。本番環境で変更を行う前に、環境を変更するために必要なすべてのステップを明らかにしたいという場合が時々あります (ソフトウェア・パッケージの大幅なアップグレードなど)。そのような場合には、災害復旧用の環境を立ち上げ、変更のステップを完了するために何が必要になるかを調べることができます。さらに、プライマリー環境を変更する前に、その一連のステップをスクリプトにすることさえ可能です。

災害復旧計画にまだ着手していないとしたら、今が実行に移すチャンスです。クラウドと仮想コンピューティングは、かつての災害復旧を大幅に単純化します。皆さんそれぞれの計画が上手く行くことを祈ります!


ダウンロード

内容ファイル名サイズ
Example of using the ec2-migrate-manifest commandec2-ami.zip1KB

参考文献

学ぶために

製品や技術を入手するために

  • ご自分に最適な方法で IBM 製品を評価してください。評価の方法としては、製品の試用版をダウンロードすることも、オンラインで製品を試してみることも、クラウド環境で製品を使用することもできます。また、SOA Sandbox では、数時間で SOA の実装方法を効率的に学ぶことができます。

議論するために

  • My developerWorks コミュニティーに加わってください。ここでは他の developerWorks ユーザーとのつながりを持てる他、開発者が主導するブログ、フォーラム、グループ、ウィキを調べることができます。

コメント

developerWorks: サイン・イン

必須フィールドは(*)で示されます。


IBM ID が必要ですか?
IBM IDをお忘れですか?


パスワードをお忘れですか?
パスワードの変更

「送信する」をクリックすることにより、お客様は developerWorks のご使用条件に同意したことになります。 ご使用条件を読む

 


お客様が developerWorks に初めてサインインすると、お客様のプロフィールが作成されます。会社名を非表示とする選択を行わない限り、プロフィール内の情報(名前、国/地域や会社名)は公開され、投稿するコンテンツと一緒に表示されますが、いつでもこれらの情報を更新できます。

送信されたすべての情報は安全です。

ディスプレイ・ネームを選択してください



developerWorks に初めてサインインするとプロフィールが作成されますので、その際にディスプレイ・ネームを選択する必要があります。ディスプレイ・ネームは、お客様が developerWorks に投稿するコンテンツと一緒に表示されます。

ディスプレイ・ネームは、3文字から31文字の範囲で指定し、かつ developerWorks コミュニティーでユニークである必要があります。また、プライバシー上の理由でお客様の電子メール・アドレスは使用しないでください。

必須フィールドは(*)で示されます。

3文字から31文字の範囲で指定し

「送信する」をクリックすることにより、お客様は developerWorks のご使用条件に同意したことになります。 ご使用条件を読む

 


送信されたすべての情報は安全です。


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=60
Zone=Cloud computing
ArticleID=630710
ArticleTitle=クラウド環境での災害復旧
publish-date=02072011