可用性を考慮した設計 vs. 障害を考慮した設計

　可用性を考慮した設計における思考プロセスは、障害を考慮した設計の場合とは全く異なる。その違いを理解することが環境構築を成功させる鍵を握る。われわれは可用性を考慮して設計を行うとき、稼働停止を防ぐことを目指して製品や技術を検討する。これに対し、障害を考慮して設計を行うときは、障害発生後の稼働停止に対処する準備をする。この対比は単純に聞こえるが、深く考察されないことが多い。

　簡単な例として従来のラックサーバを見てみよう。従来のラックサーバは通常、ドライブで障害が発生した場合のデータ損失を防ぐため、RAID技術などを用いて冗長ハードウェアとともに構成され、データ保護のためにバックアップされる。これらは、可用性を考慮した設計における定石だ。だが、複数のドライブで障害が発生した場合、システムはどうなるのかという問題がある。

　一方、可用性ではなく障害を考慮した設計を行う場合、予備のハードウェアを用意することになる。障害発生時にベンダーの出張サービスを2～4時間も待つことなく、すぐにリカバリを開始できるようにするためだ。障害が発生したドライブを交換したら、ベアメタルリストアを行えるか、あるいはOS全体とバックアップエージェントを再インストールしてリカバリを始めなければならないかのいずれかだ。

管理専用クラスタのメリット

　このリカバリプロセスは完了までに数時間もかかることがあるが、われわれはシステムの可用性を話題にするときは、そのことを棚上げしていることが多い。仮想環境に関していえば、99.999％の可用性を目指すよりも、障害対策を重視しよう。仮想環境で最も重要な要素の1つは管理ツールであり、米VMware製品を使用する仮想環境では、それは「VMware vCenter Server」（以下、vCenter）を意味する。多くの企業では、vCenterを物理環境で利用することが、管理ツールを管理対象環境の外部に置く1つの方法だった。

　しかしVMwareは、vCenterアプライアンスを堅牢な仮想アプライアンスへと進化させ続けており、このアプライアンスはVMware環境の管理プラットフォームとして好んで選ばれるようになっている。vCenterは理論上はあらゆる仮想クラスタに配置できるが、管理専用のクラスタで使用することで、重要な仮想マシン（VM）の管理など、さまざまな点でメリットがある。

　独立した管理クラスタを置くのは、可用性を考慮した設計ではなく、障害を考慮した設計に基づいている。管理クラスタは2～3台のホストのみで構成されるかもしれないし、共有ストレージではなくローカルディスクを使用する可能性もある。SAN（Storage Area Network）やNFS（Network File System）ストレージを使用しないのは奇妙に聞こえるかもしれないが、管理クラスタの目的は、本番システムとは別の環境を作ることにあることを思い出そう。

　このように機能ごとに環境を分けるのは、一方の環境におけるイベントが他方の環境に悪影響を与えないようにする狙いがある。この隔離により、障害の影響が限定される他、パッチ適用やアップグレードが柔軟に行える。もちろん次のステップは、リンクモードでvCenterを使用し、本番環境のバックアップ管理サーバと組み合わせることで、本番環境や管理環境でハードウェア障害が発生しても、管理ツールへのアクセスを維持できるようにすることだ。

ドキュメント化するかリスク放置か

　仮想環境の重要な要素の1つでありながら、後回しにされたり無視されたりしがちなのがドキュメントの作成だ。今の時代は何事も変化が速く、そのためにドキュメント化はプロジェクトで一番後回しにされることがよくあり、ドキュメントが全く作成されない場合も多い。だが、もし仮に仮想環境の管理ツールへのアクセスを解除した場合、あなたは仮想環境で使われているIPアドレスやホスト名が分かるだろうか。ストレージLUNやネットワークvLANへのマッピングについてはどうか。われわれは環境をインストールしたり拡張したりするとき、設定については既存の設定を見比べて参考にする一方で、ドキュメントは参照しないことがしばしばだ。多くの場合、まだドキュメント作成に至っていないからだ。

　また、例えば、新人のVMware管理者が、近く行われるメンテナンスのために「Distributed Resource Scheduler（DRS）」を無効にする必要があるにもかかわらず、そうしてDRSをメンテナンスモードにするのではなく、主要な本番クラスタ上でDRSを停止したとしよう。

　DRSを無効にした場合は、DRSのアフィニティルールとリソースプールの両方の設定が全て保持される。だが、DRSを停止すると、それらのルールもプールも削除されてしまう。もちろんDRSは、管理者がDRSの停止を選択すると、警告を表示するが、全てのダイアログボックスのメッセージがきちんと読まれるとは限らない。

　これは残念ながら、経験豊富な管理者が転職するのが少し早過ぎると、何が起こり得るかを示す実例だ。リソースプールとDRSのルールが全て削除されると、本番クラスタは問題のある状態になってしまう。

　もちろん、幾つかのルールは記憶から再作成できるが、適切なドキュメントがなければ、それら以外は一から作業をやり直す羽目になる。これではすんなりうまくいく可能性はほとんどない。しかし、最新のドキュメントがあれば、復旧作業に何日も要し、VMのパフォーマンスに影響を与えたこの手のトラブルは、もっとスムーズに解決され、より深刻度の低い「修正可能なミス」と受け止められていただろう。

　この例では、技術や設計上の問題で障害が発生したわけではない。障害の原因は人的ミスだった。だが、障害が一段と悪化したのはドキュメントがなかったからだ。経営陣と管理者は、ドキュメントの重要性については意見が一致しているだろうが、業務のペースの速さや時間不足からドキュメントが作成されないことがよくある。

　幸い、米Neverfailの「IT Continuity Architect」のような製品は、IT部門がこれらの問題の一部を克服するのに役立つ。こうした製品は仮想インフラを分析し、既存環境やさらにはサーバとアプリケーションの依存関係も図示するする。これにより、管理者が作業に多大な時間を費やさなくても、インフラのドキュメントマップが作成され、仮想環境に関する洞察が得られる。

　管理専用クラスタと適切なドキュメントを用意すれば、仮想環境におけるハードウェア障害に2本柱のアプローチで対処できる。また、われわれは通常、可用性を考慮して設計を行うが、仮想環境では、障害を考慮して設計を行うことも認める必要がある。企業はこうしたアプローチや設計により、不測の事態への備えを強化できるだろう。