MC/ServiceGuard

MC/ServiceGuardとは、ヒューレットパッカード (HP) のHP-UXかLinuxで高可用性を実現するクラスターパッケージのこと。

現在の最新バージョンは11.19（2009年4月リリース）。先頭の11と言う数字は、HP-UXのバージョン数に合わせ付けられている。

なお、バージョン11.15以降はServiceguardまたはHP Serviceguardが正式名称。旧称はMC/ServiceGuardまたはMulti-Computer/ServiceGuard。

商用UNIX系高可用クラスター構築実績において、IBM社のHACMPと同等の実績を持つ。

2009年4月、HPはServiceGuard for Linux 11.19を最終バージョンとすることを発表した。その後、2012年にProject Odyssayを発表し、Serviceguard for Linuxを再度発売することを決定した。

実装・動作仕様

相互監視

クラスターを構成する各ノードの稼働監視にはLANが使われる。ノード間で相互に接続されたハートビートパケットを送り合い、各ノード間の健常性を確認し合っている。クラスターに参加するノードにおいて、いずれか1台をマスターノードとして、クラスター管理デーモンが動作する。このマスターノードの決定は、各ノードからのVote（投票）によって決定される。2ノードクラスターを構成する場合、スプリットブレインシンドロームを回避するため、共有ディスク上のLVM管理領域をタイブレーカに使用し、サバイバルノードを決定する。

一般にハートビートを通すインターコネクトはネットワークアダプタによる多重設定を推奨しており、TCP/IPにおけるソフトウェア的な単一障害点 (SPOF) を回避するため、インターネットスーパーサーバ (inetd) を介してTCP/IPの自己チェックを行う機能を有する。

タイブレーク機構

2ノードクラスタの場合はどちらかのノードが停止した場合、ノード残存率が50%となるため必ずタイブレーカが必要である。それ以上の台数でクラスタを構成する場合でもタイブレーカの使用が推奨されている。 ServiceGuardではタイブレーカの実装として以下の2つをサポートしている。

1. ロックディスク方式:

   先にディスクにアクセスした方のノードを生存させる方式である。このロックディスク方式は非常に汎用性に富んでおり、SCSIエンクロージャやFCによるストレージ接続、iSCSIなどでの接続の場合でも有効である。ロックディスクとして使用するディスクはLVMで認識されるものであれば何でもよく、必要なディスク容量も最小で構成できる。多くのServiceGuardで構成されたクラスターは、その共有ディスク上に小さな領域（LVMで管理するボリュームグループ）を作成し、それをロックディスクとして使用している。

2. クォーラムサーバ方式:

   サバイバルノードの決定をクォーラムサーバに委ねる方式である。ロックディスク方式と異なり、クォーラムサーバによるタイブレークは物理的なディスク書き込みが発生しないため、、高速にサバイバルノードを決定できる。結果としてクラスタ再構成をより短時間で行うことから、ダウンタイムの短縮が求められるシステムに採用されるケースもある。このための拡張モジュール、『HP Serviceguard Extension for Faster Failover』が配布されている。

サービスの高可用化

ServiceGuardではクラスターで稼動するサービスやアプリケーションを「パッケージ」と呼ばれる機能単位で管理する。パッケージには論理IPアドレス（またはリロケータブルIPアドレス）、共有ディスクが割り当てられるため、クラスタを構成するのLANの外側から見たときに、仮想的な1台のコンピュータに見える。1つのパッケージに複数の論理IPアドレス、共有ディスクを含めることが可能である。ただし、共有ディスクについてはノード間で排他制御がかかり、パッケージで使用している間はそれ以外のノードからアクセスすることはできない。

各種パッケージをシェルスクリプトにてラッピングするだけでクラスターに実装する事が可能なため、既存システムの高可用クラスター化において、比較的容易に対応できる。このため、既存サービスの改修が難しい金融/証券系の基幹システムにおいて圧倒的なシェアを持つ。Unix系のクラスターと言えば、一時期はMC/ServiceGuardで構成するものと語られた時期があった程。アプリケーションのロジックとクラスタのロジックを分離して実装できるため、大規模なアプリケーションの高可用化に適している。

フェイルオーバ判断

フェイルオーバ条件はシステムの保障すべき可用性レベルに応じて厳密に規定される。フェイルオーバは短時間ではあるがサービスの供給が停止するため、その条件は専門のエンジニア・コンサルタントと共に慎重に検討する必要がある。ServiceGuardは様々な標準機能に加え、簡単なシェルスクリプトを記述することによって、きめ細やかなによるフェイルオーバ判断が可能である。

1. サービス停止によるフェイルオーバ:

   ServiceGuardによって起動されるサービスを「サービスを監視するサービス」と規定することにより、特定のサービスが停止した時のフェイルオーバ判断が可能である。シェルスクリプトによるサービス監視が一般的であり、たとえばwhile文の中にプロセスの存在を確認するコードを記述することによって実現される。

2. ネットワーク断絶によるフェイルオーバ:

   サービスを提供するために必要なLANを予め監視することにより、万が一そのLANが断絶した場合にフェイルオーバすることが可能である。ただし、ServiceGuardの一機能である「ローカルスイッチ」によってLANポートが冗長化されている場合は、冗長化されたポートのすべてが断絶した場合にフェイルオーバする。

3. ハートビート断絶によるフェイルオーバ:

   ハートビートが断絶することは、すなわち両方のノードにとって「他方のサーバが停止した」と判断する契機となる。このため、それぞれのノードは独立にタイブレーカへのアクセスを試み、失敗したノードは強制的に再起動することにより、そのノードの確保していたリソースを解放する。サービスを稼働しているノードがクラスタロック獲得競争に負けた場合はフェイルオーバし、ノード自体は停止する。

4. その他のフェイルオーバ:

   EMSといわれるハードウェア資源/ソフトウェア資源の健常性や動作状況をチェックするDiag系フレームワークと連動する事により、他商用高可用パッケージよりも高度な健常性チェックやフェイルオーバ判断が可能となっており、多くのシステムでの実績を上げている。

販売状況

証券及び金融系での人気により、国産ベンダのOEM化が進み、NEC/日立製作所において相当数のライセンスが販売されている。 また、機能拡張の主軸も国産ベンダによる協力強化が進んでおり、ホットスタンバイ機能やノード間切り替えの高速化などのメイン機能に日立やNECのエンジニアによる強化も行われている。

一方、Linux系の高可用クラスターパッケージとしては、低調である。 日本国内で見ると、商用UNIXでのリセラーであるNECが自社のClusterProを担いでいる事や日立もスチールアイテクノロジーのLifeKeeperやClusterProをOEMにて扱い、かつ日立も自社のクラスタソフトであるHAモニタを販売しているため、リセラーによる販売が低い事も一因と思われる。