クラスタサービスの監視

データベースやE コマースのweb サイトなど、重要かつミッションクリティカルなサービスをデプロイする場合、そのサービスを実行しているホストが、長期間、安定して、問題なく稼働し続けることを期待することはまずありません。 むしろ、1 台のホストが故障する可能性を考慮し、故障（またはフェイルオーバー）が発生した場合に、他のホストがすぐにサービスを引継ぎ、 外部にその故障がまったく気付かれないようにする必要があります。

同じタスクを実行するために連携して動作するネットワークに接続されたホストのグループは、コンピュータネットワーク、コンピュータクラスタ、またはより簡単にクラスタと呼ばれます。 クラスタは、外部からは単一のシステムとして動作および表示され、内部ではホストを組織して連携して共通のタスクを実行します。

クラスタはさまざまなタスクを実行できます。たとえば、HPC クラスタは、高性能コンピューティングを実行できます。 これは、1 台のコンピュータでは利用可能なメモリでは不十分な計算を行う場合などに使用されます。 クラスタに高可用性を提供するというタスクがある場合、そのクラスタは HA クラスタとも呼ばれます。 この記事では、HA クラスタについて取り上げます。したがって、以下で「クラスタ」という用語を使用する場合は、常にHA クラスタを意味します。

クラスタは、外部に対して 1 つ以上のサービス、つまりクラスタサービス（クラスタ化されたサービスとも呼ばれる）を提供します。 クラスタを構成するホストは、ノードと呼ばれます。 各サービスは、いつでも 1 つのノードによってのみ提供されます。 クラスタ内のいずれかのノードに障害が発生した場合、クラスタのミッションに不可欠なすべてのサービスは、他のノードの 1 つに移されます。

フェイルオーバーを透過的に行うために、一部のクラスタは独自のクラスタ IP アドレス（仮想 IP アドレスとも呼ばれる）を提供しています。 クラスタ IP アドレスは、常にアクティブなノードを指し、クラスタ全体を表します。 フェイルオーバーが発生すると、IP アドレスは、以前はパッシブだった別のノードに転送され、そのノードがアクティブなノードになります。 クラスタと通信するクライアントは、内部フェイルオーバーを認識しません。 クライアントは、変更されていない同じ IP アドレスを使用し、スイッチングを行う必要はありません。

他のクラスタには、クラスタ IP アドレスはありません。 多くのバリエーションがある Oracle データベースクラスタは、その顕著な例です。 クラスタ IP アドレスがない場合、クライアントは、サービスを提供できるすべてのノードの IP アドレスのリストを維持する必要があります。 アクティブノードに障害が発生した場合、クライアントはこれを検出し、現在サービスを提供しているノードにスイッチする必要があります。

Checkmk は、クラスタと通信するクライアントの 1 つです。 Checkmk では、クラスタ内のすべてのノードを設定して監視することができます。クラスタソフトウェアが、個々のノードのステータスを内部でどのようにチェックし、必要に応じてフェイルオーバーを実行するかは関係ありません。

Checkmk がクラスタの個々のノードに対して実行するチェックのほとんどは、ノードの物理的特性に関するものです。 これは、ホストがクラスタに属しているかどうかとは無関係です。 例としては、CPU およびメモリの使用状況、ローカルディスク、物理ネットワークインターフェイスなどが挙げられます。 ただし、Checkmk でノードのクラスタ機能をマッピングするには、クラスタのタスクを定義するサービス、つまり別のノードへの転送が必要になる可能性のあるサービス（クラスタサービス）を特定する必要があります。

Checkmk は、クラスタサービスの監視を支援します。必要な操作は次のとおりです。

手順は次の章で、以下のサンプル構成を使用して説明します：

Checkmk では、Windows フェイルオーバークラスタを、Microsoft SQL (MS SQL) サーバーがインストールされた 2 つのノードで構成される HA クラスタとして設定します。 これは、いわゆるアクティブ/パッシブクラスタであり、アクティブノードのみデータベースインスタンスを実行します。 もう一方のノードはパッシブであり、フェイルオーバーイベントが発生した場合にのみアクティブになり、データベースインスタンスを起動して、障害が発生したノードを置き換えます。 データベースインスタンスのデータは、ノード自体には保存されず、 たとえば、両方のノードが接続されているストレージエリアネットワーク (SAN) などの共有ストレージメディアに保存されます。 サンプル構成は、以下のコンポーネントで構成されています。

この例とは対照的に、同じノードを複数のクラスタに含めることも可能です。 最後の章では、変更したサンプル構成を使用して、このような重複するクラスタを構成する方法について説明します。

Checkmk では、ノードおよびクラスタ自体はホスト（ノードホストおよびクラスタホスト）として作成され、クラスタホストには特別なホストタイプが定義されます。

クラスタホストを設定する前に、以下の点に注意してください。

この例では、2 つのノードホストmssql-node01 およびmssql-node02 がすでに作成され、ホストとして設定されています。 ここまでを行う方法については、Windows サーバーの監視に関する記事、およびWindows 標準エージェントをプラグインで拡張する章（この例ではMS SQL Server プラグイン）をご覧ください。

メニュー「Setup > Hosts > Hosts 」からクラスタの作成を開始し、次にメニュー「Hosts > Add cluster 」からクラスタの作成を開始します。

Host name に「mssql-cluster01 」を入力し、Nodes に 2 つのノードホストを入力します。

Save & view folder で作成を完了し、変更をアクティブにしてください。

Checkmk は、ノード上で実行されているサービスのうち、どれがローカルサービスでどれがクラスタサービスであるかを判別できません。ファイルシステムの中には、ローカルであるものもあれば、アクティブノードにのみマウントされているものもあります。 プロセスについても同様です。たとえば、「Windows Timer」サービスは、おそらくすべてのノードで実行されていますが、特定のデータベースインスタンスはアクティブノードでのみ利用可能です。

Checkmk に推測させる代わりに、ルールを使用してクラスタサービスを選択します。 ルールを設定しないと、クラスタにはサービスが割り当てられません。 この例では、すべての MS SQL Server クラスタサービスの名前がMSSQL で始まり、共有ストレージデバイスのファイルシステムにD: ドライブからアクセスできると仮定します。

Setup > Hosts > Hosts から開始し、クラスタ名をクリックします。Properties of host ページで、メニューからHost > Clustered services を選択します。Clustered services ルールセットページが表示され、新しいルールを作成できます。Add rule: Clustered services ページが表示されます。

ホストがフォルダに整理されているかどうか、またその整理方法に関係なく、 クラスタサービスに関するルールは、サービスが実行されているノードホストに適用されるように作成してください。 このようなルールは、クラスタホストには効果はありません。

「Conditions 」ボックスの「Folder 」で、ノードホストを含むフォルダを選択します。 「Explicit hosts 」を有効にし、アクティブノードホストの「mssql-node01 」とパッシブノードホストの「mssql-node02 」を入力します。 次に、「Services 」を有効にし、そこに 2 つのエントリを作成します。 「MSSQL 」で始まるすべての MS SQL サービスには「MSSQL 」、ドライブには「Filesystem D: 」を入力します。 エントリは正規表現として解釈されます。

クラスタサービスとして定義されていないすべてのサービスは、Checkmk によってローカルサービスとして扱われます。

Save でルールの作成を終了し、変更をアクティブにしてください。

参加しているすべてのホスト (クラスタおよびノードホスト) について、最後に新しいサービスディスカバリーを実行して 、新しく定義したクラスタサービスをまずノードから削除してから、クラスタに追加する必要があります。

Setup > Hosts > Hosts で、まず、関連するすべてのホストを選択し、次にメニューからHosts > On Selected hosts > Run bulk service discovery を選択します。Bulk discovery ページで、最初のオプションAdd unmonitored services and new host labels を選択すると、目的の結果が得られます。

[Start ] をクリックして、複数のホストのサービスディスカバリーを開始します。Bulk discovery successful メッセージが表示されて正常に完了したら、終了して変更をアクティブにします。

クラスタサービスの選択が望ましい結果になったかどうかを確認するには、クラスタに現在割り当てられているすべてのサービスをリストします。Setup > Hosts > Hosts で、クラスタホストエントリのホストリストで、アイコンをクリックしてサービスを編集します。 次のページServices of host で、すべてのクラスタサービスがMonitored services の下にリストされます。

一方、ノードホストでは、クラスタに移動されたサービスは、監視対象サービスのリストから削除されます。 ノードホストでは、Monitored clustered services (located on cluster host) セクションのサービスリストの最後に、これらのサービスが表示されます。

ディスカバリーチェックによってサービスディスカバリーを自動的に実行する場合は、特別な点に注意する必要があります。Discovery Check は、消滅したサービスを自動的に削除することができます。 しかし、クラスタ化されたサービスが 1 つのノードから別のノードに移動した場合、そのサービスは消滅したと誤って認識され、削除される可能性があります。 一方、このオプションを省略すると、実際に消滅したサービスは削除されません。