Windows Server 2008「フェイルオーバークラスタリング」の効果的な利用法

Windows Server 2008のフェイルオーバークラスタリングを既存の環境に追加するメリットをどう考えるかで悩んでいる人は少なくない。

公開 2008年10月22日 08時01分

更新 2012年09月04日 18時35分

著者

Greg Shields

[TechTarget]

印刷する

　Windows Server 2008のフェイルオーバークラスタリングを既存の環境に追加するメリットをどう考えるか？　このことで悩んでいる人は少なくない。現在、IT担当者の間では、いつどのような場合にサービスの信頼性を高めるソリューションとしてクラスタリングが適しているのかをめぐって大きな混乱がある。サーバクラスタは常にIT部門によって実装されるが、時には不適切な目的で導入されるケースもある。

　まず念頭に置かなければならないのは、クラスタリングを既存サービスに追加すると、コストが格段に高くなることだ。これは、次のような要因を考えれば明らかだ。つまり、クラスタリングでは共有ストレージが必要になり、ケーブル配線やネットワークが追加され、Windowsの高価なエディションが使われることになる。中でも、クラスタリングの導入に伴って、既存サービスの管理の一環として管理すべき機器が増加することから、IT環境はより複雑になってしまう。

　しかし、クラスタリングが可用性の向上に役立つ場合は確かにある。クラスタリングに関する意思決定を行う際には、可用性を向上させるクラスタリングの機能を利用する目的は何かを考え、それが適切かどうかを検討すべきだ。適切な目的で利用すれば、クラスタリングの導入による複雑さの増加を補って余りあるメリットが得られる可能性がある。

目的その1：ハードウェアの停止の影響を軽減する

　サーバのマザーボードが故障すると、通常そのサーバはたちまちダウンする。そうしたハードウェア障害は多くの場合、運用されていたサービスの長時間の停止につながる。交換部品を調達して取り付けるのに時間がかかるからだ。老舗のサーバ機器ベンダーと保守契約を結んでいる場合、ダウンタイムは半日か丸1日だろう。契約を結んでいない場合は、ダウンタイムはずっと長引くかもしれない。重要な基幹サービスでは、復旧がそこまで遅れることは許されない。

　フェイルオーバークラスタリングは、障害が発生したときにサービスが自動的に引き継がれる場を提供する。このため、交換部品の調達と取り付けを緊急に行う必要性が軽減される。クラスタ化されたサービスは障害発生時でも、停止時間は数時間または数日ではなく、ほんの数秒または数分にとどまる。

　それでも、この目的のためだけにクラスタリングを実装する場合は要注意だ。最近のサーバのハードウェアでは、複数のレベルで冗長性が確保されている。HDDのRAID化やネットワークカードのチーミングが行われ、一部のサーバでは内部コンポーネントも冗長化されている。これらにより、コンポーネントの障害でシステム全体が停止するという深刻な事態に陥る可能性は減少している。つまり、必要な冗長性をサーバのハードウェアが既に備えている可能性がある。

目的その2：ソフトウェアトラブルへの対処を容易にする

　Windowsを使ってサービスを運用する環境では、サービスの稼働に直接必要な処理が行われるだけではない。Windows内部で関連するもろもろの作業が行われるほか、ほとんどの環境ではバックアップやシステム管理・監視、リモート管理などのソフトウェアがサーバに追加されている。これらのソフトウェアパッケージがある時点で衝突し、そのせいでサーバが基幹サービスの稼働を停止させてしまうことがあり得る。

　クラスタリングを導入していれば、そうした場合、サービスは問題が起きていない別のノードに移動される。これによって管理者は、基幹サービスの停止という重大な問題を未然に回避し、じっくりとソフトウェアの衝突の解決を図れる。その結果、より的確な解決が可能になり、一時しのぎの応急処置が取られるケースは少なくなる。

　しかし、この目的が実現するのは、「ほかの」ソフトウェアが問題を引き起こしている場合に限られる。基幹サービスそのものに問題が発生している場合には、クラスタリングのために追加された機器のせいで、トラブルシューティングと解決がより困難になることがある。

目的その3：OSのパッチ適用を円滑に行えるようにする

　Microsoftは製品のパッチを毎月必ず公開している。この月例パッチは、重要度が低いものから極めて重大なものまで多岐にわたるが、業務上可能な限り早急にホストマシンにインストールしなければならない。だが問題は、パッチの多くはインストールを完了するためにシステムを再起動しなければならないことだ。こうした再起動は、運用されているサービスのアップタイムに影響する。

　クラスタリングを利用すれば、パッチの適用前にサービスを別のクラスタノードに移動し、サービスに影響を与えずにパッチのインストールとその後の再起動を行える。これらが最初のノードで完了したら、サービスを移動して元に戻し、サービスに支障をきたすことなくパッチ適用を続行できる。

　しかし、こうしたパッチ適用の円滑化も、クラスタリングの導入目的としては弱いかもしれない。Windows Server 2008の強化点の1つは、パッチ自体の構成が変更され、インストールの完了に再起動が必要なものが少なくなったことだ。また時には、運用されているサービス自体にパッチの適用が必要になることもある。多くの場合、こうしたサービスにパッチを適用するには再起動が必要であり、それではダウンタイムが発生してしまう。これはクラスタリングでは回避できない。

目的その4：ディザスタリカバリ対策の一環

　従来のフェイルオーバークラスタリングを利用する場合、クラスタノードは何らかの共有ストレージに直接接続しなければならない。このストレージは、クォーラム情報と、クラスタの各ノードで処理されるデータの保存に使われる。そのため、各クラスタノードの物理的な位置は、ノードとストレージを結ぶケーブルの長さに制約される。

　従来のクラスタでは、すべてのクラスタホストがこのように中央の共有ストレージと直接接続されている必要があった。このため、1つのノードに影響する災害は、ほかのノードにも影響する可能性が高い。そこでWindows Server 2008では、地理的に分散したクラスタ（ストレッチクラスタやジオクラスタとも呼ばれる）のサポートが強化されている。

　こうした特別なクラスタでは、クラスタノードを遠距離に配置できる。しかしその場合には、ネットワーク接続コストが余計に掛かり、ストレージが増え、サードパーティー製のサイト間データレプリケーションソリューションも必要になる。しかも、既存サービスも大幅に複雑化する。このため、この特別なクラスタは最も基幹的なサービスの運用にのみ利用するのが得策だ。

　以上を要約すると、既存のWindowsサービスにフェイルオーバークラスタリングを追加することにはメリットとデメリットがあり、追加するかどうかを検討する際は、それらを考慮しなければならない。フェイルオーバークラスタリングはしばしば、多様な原因によるシステム停止を防ぐ“特効薬”と期待されるが、実のところごく限られた状況でのみ効果的に利用できる設計となっている。

本稿筆者のグレッグ・シールズ氏は、フリーランスのライター兼コンサルタント。MCSE資格者で、ITアーキテクチャとエンタープライズ管理について長年の経験を持つ。Microsoft製品の管理、システム管理および監視、仮想化といったトピックに関するITトレーナーや講師も務める。近著として「Windows Server 2008: What's New/What's Changed」（SAPIEN Press刊）がある。

印刷する