可用性は高めたい。でもHAクラスター投資は見合わない　Single Server Protectionという現実解

こんにちは。ＳＣＳＫ　池田です。

近年、多くの企業でシステム基盤のクラウド化や仮想化が進んでいます。

VMware環境ではvSphere HA、クラウド環境ではAWSやAzureが提供する可用性機能などを活用し、サーバー障害に備えることが一般的になりました。これらの機能によって、物理サーバー障害や仮想マシン障害への耐性は以前と比較して大幅に向上しています。

そのため、
「もう可用性対策は十分ではないか」
と考える方もいるかもしれません。

しかし、実際の現場では依然としてシステム停止が発生しています。
なぜでしょうか。

それは、多くの可用性機能が監視しているのは”サーバー”であり、”アプリケーション”ではないからです。

サーバーは生きている。でも業務は止まっている

例えば、以下のような障害を経験したことはないでしょうか。

このような障害では、

という状態になっていることが珍しくありません。
インフラから見ると正常です。

しかし利用者から見ると、
「システムが使えない」
状態です。

つまり、
サーバーの可用性と業務システムの可用性は同じではない
のです。

クラウド時代だからこそ重要になるアプリケーション監視

オンプレミス時代は、物理サーバー故障が可用性対策の中心課題でした。
しかし現在は、

などの普及によって、インフラ障害の発生頻度は低下しています。

その一方で、

など、OS内部で発生する障害による停止が相対的に目立つようになっています。

可用性対策の対象も、
「サーバーを守る」から「業務サービスを守る」へ変化しているのです。

監視だけでは業務停止時間は短くならない

こうした課題に対して、多くの企業では監視ツールを導入しています。
確かに、

などを利用すれば障害を迅速に検知できます。
しかし障害を検知するだけでは、業務は復旧しません。

結局のところ、

という運用が残ります。

つまり、「検知の自動化」はできても、「復旧の自動化」ができていない
ケースが多いのです。

本格的なHAクラスターの導入はハードルが高い

このような課題に対して、サーバーを複数台用意して本格的なHAクラスターを構成することで冗長性を高めるという選択肢もあります。

しかし、すべてのシステムに待機系サーバーや追加ライセンスを含めた高可用性構成を適用できるとは限りません。

特に、

というシステムも少なくありません。

そこでご紹介したいのが、LifeKeeperの姉妹製品であるSingle Server Protectionです。

Single Server Protectionは、1台のサーバーに導入し、サーバー上で動作するアプリケーションやミドルウェアを監視して、障害発生時の自動復旧を支援する製品です。

「最初から最高レベルの可用性を目指すのではなく、限られた予算の中で、今より一段上の可用性を手に入れる」

そのための、現実的で始めやすい選択肢です。

Single Server Protectionとは

Single Server Protectionは、その名前のとおり、単一のサーバーを保護するためのソフトウェアです。

HAクラスター製品であるLifeKeeperは、複数台のサーバーを使用し、障害発生時に別のサーバーへサービスを切り替えることで、高い可用性を実現します。

一方、Single Server Protectionでは待機系サーバーが必要ありません。1台のサーバー上でアプリケーションやミドルウェアを監視し、障害が発生した際にアプリケーションの再起動やOSの再起動などを行い、復旧を試みます。

サイオステクノロジーの製品情報でも、SingleServer製品は単体サーバー上の可用性向上を目的とした製品であり、1ライセンスから購入できる製品として整理されています。

一般的な動作のイメージは、次のとおりです。

人が障害に気付いてからサーバーへログインし、状況を調査して、サービスを再起動するという一連の初動を自動化できる点が大きなメリットです。

つまり、Single Server Protectionはサーバーを二重化する製品ではありませんが、
単一サーバー構成のまま、アプリケーション障害からの復旧時間を短縮できる製品
なのです。

1台構成だから、導入のハードルを抑えられる

Single Server Protectionの最大の特長は、待機系サーバーを必要としないことです。

HAクラスターを構築する場合、原則として稼働系と待機系の2台分の環境を準備する必要があります。クラウド環境であっても、待機系の仮想マシンやストレージ、OS、ミドルウェアなどのコストを考慮しなければなりません。

Single Server Protectionであれば、現在利用している1台のサーバーへ導入するところから始められます。

待機系サーバーを追加しないため、次のようなコストや作業を抑えやすくなります。

Single Server Protectionは、単一ノードで利用できるため、待機ノードのコンピューターリソースを用意せずに可用性を向上させられる点が特長です。

もちろん、HAクラスターとSingle Server Protectionは同じものではありません。

サーバー自体が完全に停止した場合や、物理基盤、クラウド基盤、ストレージなどに重大な障害が発生した場合、同一サーバー上での再起動だけでは復旧できない可能性があります。

それでも、実際の運用ではサービスの異常終了、プロセスの停止、アプリケーションのハングアップなど、再起動によって復旧できる障害も存在します。

こうした障害に対して、担当者の手作業を待たずに自動復旧を行えるだけでも、システム停止時間の短縮が期待できます。

「予算がないから何もしない」というゼロの状態から、「少なくともアプリケーション障害は自動で復旧させる」という状態へ進めることに、Single Server Protectionを導入する価値があります。

アプリケーションを監視することの重要性

サーバーを仮想環境やクラウド環境で動かしているから、可用性対策は十分だと考えていないでしょうか。

仮想基盤やクラウド基盤には、仮想マシンの異常や物理ホストの障害を検知し、仮想マシンを再起動する仕組みが用意されていることがあります。

しかし、ここで注意したいのは、仮想マシンが動いていることと、業務アプリケーションが正常に動いていることは同じではないという点です。

例えば、OSは正常に稼働していても、業務に必要なサービスだけが停止していることがあります。また、プロセス自体は存在していても、アプリケーションとしては正常に応答できていない場合もあります。

このような状態では、仮想基盤から見ると仮想マシンは正常です。そのため、仮想マシンの再起動が実行されず、業務だけが止まり続ける可能性があります。

Single Server Protectionは、OS上のアプリケーションやミドルウェアを監視し、異常を検知した場合に復旧処理を行います。仮想基盤側の可用性機能と組み合わせることで、仮想基盤は仮想マシンを、Single Server Protectionは仮想マシン内部のアプリケーションを監視するという、役割分担が可能になります。

特にVMware vSphere HAとの連携では、アプリケーションの再起動を試み、復旧できなかった場合に仮想マシンを再起動するといった、段階的な復旧方法を選択できます。

いきなり仮想マシン全体を再起動するのではなく、まずは障害が発生したサービスだけを再起動することで、正常に稼働しているほかのサービスへの影響を抑えられる可能性があります。

障害対応を「人の頑張り」だけに任せない

Single Server Protectionが解決する課題は、システム障害だけではありません。

もう一つの大きな課題が、運用の属人化です。

小規模なシステムでは、障害発生時の対応が次のようになっていることがあります。

担当者がすぐにアラートへ気付けばよいのですが、障害は必ずしも勤務時間中に発生するとは限りません。深夜や休日に発生した場合、気付くまでに時間がかかることもあります。

また、障害対応が特定の担当者に依存していると、その担当者が不在の際に復旧が遅れる可能性があります。手順書があったとしても、作業に慣れていない担当者が対応すると、操作ミスが発生するかもしれません。

Single Server Protectionを導入し、障害検知から再起動までを自動化すれば、一次対応をシステムに任せられます。

運用担当者は「異常を発見して再起動する人」から、「自動復旧の結果を確認し、根本原因を調査する人」へ役割を変えられます。

これは単なる時間短縮ではありません。夜間や休日の呼び出しを減らし、担当者の心理的な負担を軽減することにもつながります。

可用性の向上と運用負荷の軽減を、同時に目指せるのです。

導入や設定もライトに始められる

可用性製品に対して、「構築が難しそう」「専用の監視スクリプトを作らなければならないのでは」と感じる方もいるでしょう。

Single Server Protectionでは、GUIを利用した設定や運用管理が可能です。また、LifeKeeperファミリーには、アプリケーションやミドルウェアを監視・復旧するためのRecovery Kitが用意されています。

対応するRecovery Kitを利用することで、監視や復旧の仕組みをすべて一から開発する必要がなくなり、構築や検証の負担を抑えられます。一般的なOSサービスについては、GUI上で保護対象を設定できるQuick Service Protectionも提供されています。

製品名やライセンス体系については、バージョン10から整理されています。

従来のSingle Server Protectionは、現在の製品体系ではLifeKeeper v10 for SingleServerという基本パッケージ名で提供されています。Windows版とLinux版では、利用できる標準機能や、保護対象に応じて必要となるRecovery Kitが異なるため、導入前に対象OSとアプリケーションを確認することが重要です。

必要な機能だけを選定することで、システムの目的に合ったシンプルな構成にできます。

どのようなシステムに向いているのか

Single Server Protectionは、特に次のようなシステムに適しています。

1．停止すると困るが、HAクラスターの予算を確保できないシステム

部門内で利用する業務システムや、拠点単位で稼働しているサーバーなど、一定の重要性はあるものの、本格的な二重化までは難しいシステムです。

2．現在、障害発生時に手動でサービスを再起動しているシステム

過去の障害対応で「サービスを再起動したら復旧した」というケースが多い場合、その一次対応を自動化できる可能性があります。

3．夜間や休日の障害対応を減らしたいシステム

自動復旧によって、担当者が対応を開始するまでの待ち時間を減らせます。復旧後の確認や原因調査は翌営業日に行うという運用も検討しやすくなります。

4．仮想基盤のHA機能だけでは不安なシステム

仮想マシン単位の監視に加えて、ゲストOS上のアプリケーションも監視したい場合に適しています。

5．将来的に本格的なHAクラスターを検討しているシステム

まずSingle Server Protectionでアプリケーション監視と自動復旧を導入し、システムの重要度や予算の増加に合わせて、将来的にLifeKeeperによる複数サーバー構成を検討するという段階的なアプローチも考えられます。

正しく理解しておきたい限界

Single Server Protectionを検討する際には、「できること」だけでなく、「できないこと」も理解しておく必要があります。

Single Server Protectionは単一サーバー上で動作するため、HAクラスターのように、別サーバーへサービスを引き継ぐことはできません。

例えば、次のような障害では、Single Server Protectionだけでの復旧が難しい場合があります。

こうした障害まで含めて短時間での復旧が求められるシステムには、複数サーバーを使用するLifeKeeperなどのHAクラスターが適しています。

大切なのは、すべてのシステムへ同じ可用性対策を適用することではありません。

システムの重要度、許容停止時間、障害発生時の業務影響、予算を整理し、必要なレベルに合った対策を選ぶことです。

「HAクラスターではないから意味がない」のではなく、現在の手動運用と比較して、停止時間や運用負荷をどこまで改善できるかという観点で評価することがポイントです。

0か100かではなく、現実的な一歩を

システムの可用性対策は、0か100かで考える必要はありません。

本格的なHAクラスターを導入できれば、より高い可用性を実現できます。しかし、予算や体制の制約によって導入できないからといって、何も対策をしなければ、障害発生時の復旧は運用担当者の判断と作業に依存したままです。

Single Server Protectionであれば、既存の1台構成をベースに、アプリケーションの監視と自動復旧を追加できます。

「システムの可用性は高めたい。でも、お金はない」

そのようなお客様にこそ、Single Server Protectionは検討していただきたい製品です。

大きな予算を確保して、いきなり完璧な構成を目指すだけが可用性対策ではありません。

まずは止まりやすいアプリケーションを自動で監視し、障害が起きたら自動で復旧させる。そこから始めるだけでも、システム運用は大きく変わります。

現在の「人が気付いて、人が再起動する」運用から、一歩先へ。

Single Server Protectionで、無理なく、気軽に、現実的な可用性向上を始めてみてはいかがでしょうか。