クラウド・ベースの高可用性のための実用的な手法

アプリケーションの種類によらず、高可用性 (HA) は複雑なアクティビティーですが、クラウドやクラウドによる仮想プラットフォームを使用することで、実際に、高可用性の目標がよりシンプルで単純なものになります。物理プラットフォームからの抽象化を行う仮想化は、高可用性に新しい可能性をもたらします。この記事では、ステートレスなフェイルオーバーや、それよりも有用なステートフルなフェイルオーバーなど、クラウド・ベースの高可用性を実現するための実用的な手法をいくつか説明します。さらに、高可用性システムに役立つオープンソースの各種ソフトウェア・コンポーネントについても紹介します。

M. Tim Jones (mtj@mtjones.com), Independent Author, .

M. Tim JonesTim は組み込みファームウェア・アーキテクトであり、著書には『Artificial Intelligence: A Systems Approach』(現在は第 2 版)、『GNU/Linux Application Programming』(第 2 版)、『AI Application Programming』(第 2 版)、『BSD Sockets Programming from a Multilanguage Perspective』があります。彼の技術的な経歴は、静止軌道衛星用のカーネル開発から、組み込みシステム・アーキテクチャーやネットワーク・プロトコル開発まで多岐にわたっています。彼はコロラド州 Longmont 在住のソフトウェア・アーキテクトであり、著作者でもあります。


developerWorks 貢献著者レベル

2011年 11月 11日

私が初めて高可用性を扱ったのは、商用の静止通信衛星に関する仕事をしていた 1980年代です。衛星経由で信頼性の高い信号を送受信できるようにするために、そのプラットフォームの第一の目標はポインティングにありました。ポインティングというのは、衛星 (または衛星上の機器) を地上の何らかの対象物の方向に向けることを指します。衛星がポインティングの能力を失うと、その衛星経由のデータ・パスも失われる可能性があり、結果として商用衛星による収益が失われることになりかねません。

衛星は通常、高可用性を実現するために、部品の放射線耐性の向上からシステムやバスの冗長化に至るまで、さまざまな方法を用いています。しかしこのプラットフォームでは、さらに奥深くまでフォルト・トレランスが考慮され、プロセッサー自体の内部にまで及んでいました。メイン・プロセッサーは avionics クラスの 16 ビットのプロセッサーであり、ロック・ステップで命令を実行する 2 つの内部 CPU が組み込まれていました。この 2 つの内部 CPU の出力は比較され、違いが検出された場合 (通常はアルファ粒子によるアップセット・イベントが原因ですが) には、そのプロセッサーは一時的に信頼できないとみなされ、冗長プロセッサーへのホット・スワップが行われます。冗長プロセッサー (つまりホット・スペア) は、(マスターとスレーブとの間で共有される) 単純な共有メモリーを通じて、演算に関するすべてが最新の状態に維持されているため、即座に衛星の制御を引き継ぐことができ、ポインティングが失われることはありません。

これらの概念は 1980年代で既に新しいものではありませんでしたが、現在でもシステム設計のあらゆる側面にこれらの概念を適用して高可用性の実現に役立てられています。こうした冗長性に基づく設計の目標は、単一障害点を (ある程度まで) なくすことです。この記事では、仮想環境に適用される冗長性とフェイルオーバーの概念について詳しく説明するとともに、ソフトウェアの高可用性のためのオープンソース・プロジェクトについても紹介します。

クラウドの高可用性

ここで説明する手法は、ごく一般的なハードウェアで実施することができます。これはつまり、対象とする障害のレベルはごく一般的なハードウェアで起こりがちなものであることを意味しますが、これらの手法では実際にそうした障害の影響を軽減することができます。IBM メインフレームを見れば明らかなように、真のエンタープライズ・レベルのフォルト・トレランスはハードウェアとソフトウェアの組み合わせによる複雑で綿密な科学です。この記事では純粋にソフトウェアで実装可能な手法のみについて説明します。


フェイルオーバーによる高可用性

冗長性を持たせる方法はシステムの可用性を高めるための一般的な方法です。この手法は、ネットワーク接続の冗長性 (接続が失われた場合や一般的な配線ミスへの対処) から、電源の冗長性 (電源喪失の可能性の最小化)、そしてストレージの冗長性 (ミラーリングなどによるレプリケーションや、独立した複数ディスクによる冗長アレー ([RAID]-5) の排他的論理和 [XOR] などによるエラー・コードを使用する方法など) に至るまで、システムのあらゆるレベルで有効です。

またこの方法は上位レベルでも有効であり、複数のサーバー全体を冗長化することでダウンタイムを最小限にすることができます。冗長サーバーを使用する場合、障害の発生したサーバーから予備サーバーへの切り換えプロセスはフェイルオーバーと呼ばれます。障害時の切り換え先となるサーバーはスペアと呼ばれます。そのサーバーがアクティブな場合にはホット・スペアと呼ばれる一方、サーバーが電源オフでフェイルオーバー・プロセスの実行前に電源投入と初期化が必要な場合にはコールド・スペアと呼ばれます。ホット・スペアではフェイルオーバーに必要な時間は最小限で済みますが、常に電力を消費していることから、コールド・スペアほど電力効率が良いわけではありません。

では、フェイルオーバーのための 2 つの方法 (ステートレスな方法とステートフルな方法) について、またそれぞれの方法でサポートされるモデルについて調べてみましょう。

ステートレスなフェイルオーバー

ステートレスなフェイルオーバーは最も単純な方法ですが、障害の発生したサーバーとバックアップ・サーバーとの間で状態がまったく維持されないことを考えると、最も有用性の低い方法でもあります。

最も単純な場合、1 台のサーバーはフェイルオーバー先となる 1 台のバックアップ・サーバーとペアになります。アクティブなサーバー (またはそのサーバーのアプリケーション) に障害が発生したことが何らかの仕組みによって (ハートビートなどによって) 検出されると、バックアップ・サーバーが制御を開始します。Web サーバーの場合には、ロード・バランサーが障害の発生したサーバーを除外し、Web リクエストのターゲットをバックアップ・サーバーに切り換えます。このプロセスを示したものが図 1 です。

図 1. 単純なステートレス・フェイルオーバーの例
単純なステートレス・フェイルオーバーの例

このタイプのソリューションは Linux-HA プロジェクトで実装されています。Linux-HA プロジェクトの傘下には、HA クラスター・システムを開発するためのオープンソースによる一連の高可用性ビルディング・ブロックがあります。Linux-HA を構成する要素は、メッセージング・レイヤー、(クラスター・リソースに対する標準インターフェースとして機能する) 一連のリソース・エージェント、(新規リソースまたは障害の発生したリソースの登録と通知を許可する) ハートビート・デーモン、(サービス・オーケストレーションのための) クラスター・リソース・マネージャーです。

この場合のリソースとは、Apache Web サーバーのインスタンスや、デバイス上にマウントされたファイルシステムのインスタンスなどのさまざまなエンティティーを指します。リソース・エージェントは通常シェル・スクリプトとして実装され、そのシェル・スクリプトによってリソースに対する一連の操作 (起動、停止、監視など) が公開されます。これらの操作はリソース・マネージャーに対する標準インターフェースとして機能します。Linux-HA プロジェクトでは、さまざまな種類のリソース・エージェントを格納したリポジトリーを提供しています (詳細は「参考文献」を参照)。図 2 は HA クラスターのソフトウェア・スタックを示しています。

図 2. HA クラスターのソフトウェア・スタック
HA クラスターのソフトウェア・スタックを示した図

参考文献」セクションには、さまざまなクラスター・スタック・レイヤー (メッセージング、管理、リソースなど) に使用できるオープンソース・パッケージの一覧も挙げてあります。また、その他の有用なオープンソース・パッケージ (ポリシー・エンジンやその他のリソース管理デーモンなど) へのリンクも挙げてあります。

ステートフルなフェイルオーバー

ステートレスなフェイルオーバーは多くの使用モデルで機能しますが、ステートフル性が必要な場合には決して理想的とは言えません。例えば、フェイルオーバー・サーバーにとって重要な情報 (例えばアプリケーションの状態や、ネットワーク接続などオペレーティング・システム・レベルの情報) をオペレーティング・システムやアプリケーションが維持している場合には、もっと複雑な方法が必要です。ステートフルなフェイルオーバー手法では、新しいサーバーへと移行していることがオペレーティング・システムやアプリケーションにはわからないように、適切なタイミングで透過的に移行が行われます。

そうした方法の 1 つを実装したものが、Remus と呼ばれる研究プロジェクトの成果を取り入れた Xen ハイパーバイザーと、Kemari の成果を取り入れた KVM (Kernel-based Virtual Machine) です。Remus と Kemari はステートフルに VM をマイグレート (移植) する手法を定義しており、この手法では障害の発生したサーバーから新しいサーバーへと透過的に VM をマイグレートしますが、それを連続的な形で行います。どちらの手法も (Xen も KVM も)、次に説明する既存のライブ・マイグレーション機能を利用しています。VM をステートフルにフェイルオーバーする方法については、ライブ・マイグレーションの後に説明します。

ライブ・マイグレーション

ライブ (またはオンライン) マイグレーションは、ほとんどのハイパーバイザーで実装されている機能です。この機能により、現在 VM を実行している物理サーバーから別の物理サーバーへと、サーバーを停止せずに VM を移し替えることができます。VM から見ると、マイグレーションは透過的に行われるため、唯一認識される副作用は、外部との通信がわずかに遅延することぐらいです。ライブ・マイグレーションが (ハイパーバイザーによる) プラットフォーム仮想化に限定された機能ではないことに注意してください。OpenVZ などのオープンソース製品によってオペレーティング・システムの仮想化を行っているような場合にも、ライブ・マイグレーションが利用されています。オペレーティング・システムの仮想化では既存のサスペンド機能とリストア機能を利用しています。

マイグレーションのプロセスでは、サスペンドされた状態の VM (メモリーで表現されます) をパッケージ化し、それらのページを新しいホストに移動した後、VM をリストアして実行します。VM をサスペンドして新しいホストにマイグレートするプロセスは「停止後コピー (stop and copy)」と呼ばれることもあります。これは VM を停止してマイグレートするからです (ただしプレコピーも発生するかもしれません)。このプロセスによって、古いホストから新しいホストにマイグレートするページ (ダーティー・ワーキング・セット) の数が増えるにつれ、顕著な遅延が発生する結果となります。

連続ライブ・マイグレーション

(ブリティッシュ・コロンビア大学による) Remus プロジェクトは、ライブ・マイグレーションの概念に少し変更を加えることで、VM のための高可用性を実現しています。この手法では、別のサーバーへのマイグレーションを連続的なプロセスとして行います。バックアップ・サーバーまたはシャドウ・サーバーは、アクティブ・サーバーの連続する 1 つのチェックポイントであり、従来のライブ・マイグレーションのプロセスに主要な 2 つの変更を加えることで実現されています。

第 1 の変更は、ホスト間のメモリー・ページのマイグレーションに関する変更です。ライブ・マイグレーションの動作を思い出してください。ライブ・マイグレーションでは、「プレコピー」と呼ばれる動作により、VM が実行を継続している間にページがマイグレートされ、ダーティー・ページのしきい値に達すると「停止後コピー」フェーズに入り、VM は一時的にサスペンドされ、すべてのダーティー・ページが移動されます。連続ライブ・マイグレーションでは、アクティブなホストは (さまざまな情報を保存しておくための領域である) チェックポイントを利用して (「停止後コピー」フェーズで) 連続的にプレコピーを行います。要するに、アクティブなハイパーバイザーは (「停止後コピー」によって) ライブ・マイグレーションを行いますが、現在アクティブなホスト上で VM の実行を継続させます。「停止後コピー」フェーズの結果がチェックポイントそのものになります。障害が発生すると、(独立した物理サーバー上にある) バックアップ・ハイパーバイザーは最新のチェックポイントを使用してイメージを再起動します (図 3 を参照)。

図 3. 連続ライブ・マイグレーションにより VM の高可用性を実現する
連続ライブ・マイグレーションのプロセスによって VM の高可用性を実現する様子を示した図

第 2 の変更はアクティブな VM の I/O に関する変更です。メモリーの管理は非常に容易ですが、それに比べると I/O の同期は複雑な問題です。ネットワーク・パケットはチェックポイント (上述のチェックポイントとは異なり、バッファーから書き込むタイミングを示すチェックポイント) が発生するまで保存されます。チェックポイントが完了したことをバックアップ・ホストが示すと、ネットワーク・パケットは解放され、外部から見たホストの状態をネットワークキング動作のために維持できるようになります。ストレージの処理は複雑な問題であり、これまでバックアップ・ホストでの単純なミラーリングによって解決されてきました。アクティブなディスクに 1 つのブロックが書き込まれると、そのブロックのコピーもバックアップ・ホストに書き込まれます。チェックポイントが発生すると、ディスク・バッファーは解放されます。

チェックポイントの頻度は構成可能ですが、ドキュメントによれば 25 ミリ秒ごとに発生します。このように高い頻度でチェックポイントが発生するため、転送が必要なダーティー・ページの数も最小限になり、ネットワーク・フレームやストレージ・フレームのバッファリング処理も最小限になります。

連続ライブ・マイグレーションは現在、オープンソースのハイパーバイザーで実現されています。Remus プロジェクトで用いられたこれらの概念を最初に実装する対象となったのは Xen でしたが、KVM もこの機能を Kemari プロジェクトで実装しています。どちらの手法も、変更されていないオペレーティング・システム上で実施されます。これらについての詳細は「参考文献」セクションを参照してください。


その他の手法

ここまでに説明した手法は主要なオープンソースのハイパーバイザーに採用されていますが、この分野では他にも数多くの取り組みが行われています。

1995年には、Thomas Bressoud 氏と Fred Schneider 氏により、ハイパーバイザー環境でレプリケーション・プロトコルを使用したフォルト・トレランスの実装についての研究が行われました。Remus プロジェクトの以前には、Remus の基礎となった SecondSite というプロジェクトがありました。SecondSite は Remus の中核をなす概念を提供していますが、それ以外にも SecondSite では、ダーティー・ページを圧縮することによって VM の 1 つの複製に対して 80% も帯域幅を改善できることを明らかにしました。

しかし最も興味深い手法の 1 つは、プロセッサーの一時的な障害を仮想化によって処理する ExtraVirt と呼ばれるプロジェクトの手法です。ExtraVirt では、マルチコア・プロセッサー上で実行されるハイパーバイザーを定義し、そのハイパーバイザーが各コアで別々に VM の複製を実行させます。VM レベルの複製は、ハイパーバイザーによって管理され、VM の出力を監視して (出力が表示される前に) プロセッサー内部の障害を検出し、その障害から回復させます。VM は VM をログに記録して再生することで一貫性が維持されます。ExtraVirt は Xen ハイパーバイザーの拡張機能として実装されます。

ExtraVirt は仮想化によってフォルト・トレランスを実現するソリューションですが、他にも ExtraVirt と同じようにプロセッサー・レベルでフォルト・トレランスを実現する仕組みがあります。興味深い手法として、SWIFT (Software Implemented Fault Tolerance) や EDDI (Error Detection by Duplicated Instructions) などがあります。EDDI は命令ストリームを複製し、複製された命令ストリームの実行結果を調べます。この実行結果と複製元の命令ストリームの実行結果が一致する場合には、障害は発生していません。それ以外の場合、つまり複製元と複製されたストリームの実行結果が一致しない場合には、障害が検出され、その障害に応じた処理が行われます。コンパイラーは、命令ストリームの複製を生成し、それらの複数の命令ストリームを適切につなぎ合わせます。つまりこの方法はソフトウェアのみによるソリューションです。SWIFT プロジェクトも似た方法を採用していますが、複製された命令に命令レベルの未使用リソースを再利用することで、より効率的な仕組みを実現しています。


さらに詳しく調べてください

Xen と KVM は進化を続けており、フォルト・トレランスを必要とするような新たな市場に対応する新機能が追加されています。この種の機能はクラウド環境にとって理想的です。なぜなら、ごく一般的なサーバーを使用してエンタープライズ・レベルの機能を実現するためのさらに新たな手段 (つまりサービス・レベル・アグリーメント) を提供できるからです。ライブ・マイグレーションはサーバー・クラスターのロード・バランシングにとって重要な機能でしたが、ライブ・マイグレーションに基づくフェイルオーバー機能を構築することで、高可用性に依存するアプリケーションを新たにクラウド内に実現することができます。

参考文献

学ぶために

  • 分散複製型ブロック・デバイス、DRBD による高可用性」(M. Tim Jones 著、developerworks、2010年8月) は、データのミラーリングのための 1 つの方法を紹介しています。DRBD は 2 つのサーバーと 2 つのストレージ・デバイスの間に分割して RAID-1 型の機能を実現するオープンソースのプロジェクトです。
  • Linux-HA プロジェクトは、1999年以来 Linux その他のプラットフォームに高可用性を実装したプロジェクトを集めたものです。Linux-HA プロジェクトの下には、HA クラスター・システムを構築するための高可用性ビルディング・ブロックがいくつかあります。
  • クラスター・システムのメッセージング・レイヤーは、サービスの存在 (またはサービスが存在しないこと) を理解するために必要なメッセージング機能とメンバーシップ機能を提供します。メッセージング・レイヤーの例として、HeartbeatCorosyncOpenAIS などがあります。また、クラスター・グルー (Cluster Glue) と呼ばれるものもあります。Cluster Glue は基本的に、エラー・レポート、ライブラリー、ユーティリティーなど、さまざまなコンポーネントを集めたものです。
  • リソース・エージェントはクラスター・エコシステムのエンティティーに対する標準インターフェースとして機能します。リソース・エージェントは Apache Web サーバーなどのソフトウェア・サービスの場合もあり、実際の音による警告などの物理的サービスの場合もあります。上記のリンク先には、多種多様なサービスに対する最新のリソース・エージェントの一覧があります。
  • Pacemaker はクラスターの管理アクティビティー (サービスの起動/停止、モニタリングなど) を調整するクラスター・リソース・マネージャーです。Pacemaker は Linux-HA ソリューションの重要部分であり、ここをクリックすると、pengine ポリシー・エンジンやさまざまなリソース・エージェントなど他のコンポーネントの紹介を含め、Pacemaker のアーキテクチャーについて学ぶことができます。また、Pacemaker の CLI とその設計目標、コマンド・リストについても学ぶことができます。
  • Xen と KVM では、VM を連続的に同期化することによる高可用性フェイルオーバーが実装されています。それぞれの実装について、それぞれのプロジェクトの Web サイト (Remus および Kemari) で学ぶことができます。
  • フォルト・トレランスに関する他の作業の成果として、「Hypervisor-based Fault Tolerance」、「SecondSite」(Remus の前身)、「ExtraVirt」(仮想化により過渡的なプロセッサー障害を管理)、「SWIFT」(重複命令ストリームによるソフトウェア専用のフォルト・トレランス) などがあります。
  • developerWorks でクラウド開発者のためのリソースを調べてください。クラウドにデプロイするためにプロジェクトを構築しているアプリケーション開発者やサービス開発者の知識や経験を発見し、共有することができます。
  • Technology bookstore には、この記事や他の技術的な話題に関する本が豊富に取り揃えられています。
  • Twitter で developerWorks をフォローしてください。この記事の著者 M. Tim Jones も Twitter でフォローすることができます。
  • developerWorks On demand demos をご覧ください。初心者のための製品インストール方法やセットアップのデモから、上級開発者のための高度な機能に至るまで、多様な話題が解説されています。

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

  • 皆さんの目的に最適な方法で IBM 製品を評価してください。製品の試用版をダウンロードする方法、オンラインで製品を試す方法、クラウド環境で製品を使う方法、あるいは SOA Sandbox で数時間を費やし、サービス指向アーキテクチャーの効率的な実装方法を学ぶ方法などがあります。

議論するために

  • 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=772588
ArticleTitle=クラウド・ベースの高可用性のための実用的な手法
publish-date=11112011