 |
This is a machine translation based on the English version of the article. It might or might not have already been subject to text preparation. If you find errors, please file a GitHub issue that states the paragraph that has to be improved. |
1. 基本
2 台の Checkmk アプライアンスを接続して、フェイルオーバークラスタを形成することができます。 そうすることで、2 台のアプライアンス間で、すべての設定およびデータが同期されます。 クラスタとして接続されたアプライアンスは、ノードとも呼ばれます。 クラスタ内のノードのうち 1 つがアクティブな役割、つまりクラスタのタスクを実行します。 両方のノードは、そのステータスに関する情報を常に交換しています。 アクティブノードが、例えば障害のためにタスクを実行できなくなったことを非アクティブノードが認識すると 非アクティブノードはアクティブノードのタスクを引き継ぎ、新しいアクティブノードになります。
フェイルオーバークラスタは、デバイスまたは個々のコンポーネントのハードウェア障害から保護することで、監視インストールの可用性を高める役割を果たします。 ただし、クラスタリングはデータのバックアップに代わるものではなく、論理エラーは検出しません。
次のような状況では、クラスタは、非アクティブなノードがそのリソースを引き継ぐことでダウンタイムを短縮します。
Checkmk ラック内の RAID にアクセスできなくなった場合。
以前にアクティブだったデバイスがアクセスできなくなった（故障した）場合。
以前にアクティブだったデバイスが「外部」ネットワークにアクセスできなくなったが、非アクティブなノードはアクセスできる場合。
ノードでファームウェアのアップデートを実行した場合。
もちろん、クラスタは、ノードが別々のスイッチおよび電源で動作している場合にのみ、緊急時に機能します。
2. 前提条件
クラスタを設定するには、まず 2 台の互換性のある Checkmk アプライアンスが必要です。 以下のモデルをクラスタに組み合わせることができます。
2 x Checkmk rack1
2 台の Checkmk rack5
2 x Checkmk virt1 (技術的には可能ですが、サポートおよび実運用は推奨されません。詳細については、以下をご覧ください。)
1 台の Checkmk rack1/rack5 および 1 台の Checkmk virt1
さらに、2 つのアプライアンスは互換性のあるファームウェアを使用している必要があります。 virt1 アプライアンスと物理ラックを組み合わせる場合、仮想マシンは物理サーバーと同じ仕様である必要があります。そうしないと、ラックからの負荷を引き継いだときにクラッシュする可能性があります。
ユニットは、少なくとも 2 つの独立したネットワーク接続で配線する必要があります。 これらの接続のうち 1 つは通常のネットワーク接続に使用され、もう 1 つはクラスタノード間の同期に使用されます。 同期接続は、可能であればユニット間で直接実行しますが、最低でも別のネットワーク経由で実行してください。
ネットワーク接続の可用性を高めるには、ボンディング設定を作成する必要があります。 このボンディング設定の具体的な内容は、主に (ネットワーク) 環境によって異なります。 必要に応じて、データセンターまたはネットワーク部門の担当者に相談してください。
仮想アプライアンスのクラスタリング
2 つの virt1 インスタンスをクラスタリングすることは、技術的には確かに可能です。 ただし、クラスタ機能はハードウェアの障害を補うために設計されているため、実稼働環境ではお勧めできません。 高可用性を実現するには、VMware vSphere などの仮想化プラットフォームが独自の機能を提供しています。 ただし、2 台の仮想マシンを使用して、クラスタの動作と構成を非常に簡単にテストすることができます。 VirtualBox や VMware Workstation Player などの「デスクトップ仮想化ソフトウェア」も、この目的に適しています。 これらのソリューションでは、ボンディングの設定は不要です。 以下に示すようにボンディングを設定する代わりに、使用していない 2 番目のネットワークインターフェイスを使用してください。 実際のクラスタリングでは、ボンディングインターフェイスではなく、2 つの個別のインターフェイスを選択してください。
3. クラスタの構成
この説明では、web ブラウザで web インターフェイスを開くことができるように、両方のデバイスがすでに事前設定されていることを前提としています。
クラスタを実際に設定する前に、まず両方のデバイスを準備する必要があります。 その際、主に、上記の要件を満たすようにネットワーク設定を変更する必要があります。 必要に応じて、クラスタリングに使用するポートをメモしておいてください。
以下では、次の図に示す 2 つのボンディングインターフェースを備えたクラスタの参考構成について説明します。
図で使用されているインターフェースの名称「LAN1 」、「LAN2 」などは、デバイス上の物理インターフェースを表しています。 実際の名称は、それぞれのハードウェアによって異なります。
使用する IP アドレスは、もちろん任意です。 ただし、内部クラスタネットワーク（図のbond1 ）は、「外部」ネットワーク（図のbond0 ）とは異なる IP ネットワークを使用するようにしてください。
3.1. ネットワーク設定
最初のノードの web インターフェイスを開き、デバイス設定を選択し、上部にある「Network Settings 」を選択します。Network Settings には 2 つのモードがあります。
デフォルトでは、デバイスの標準インターフェースのみを設定できる「Simple Mode, 」が有効になっています。 (このモードは、アプライアンスの初期設定時にテキストコンソールを使用して行った設定に対応しています)。
クラスタリングには、詳細モードが必要です。 このモードを有効にするには、上部の [Advanced Mode ] ボタンをクリックし、確認ダイアログで承認します。
次のページには、ユニットで使用可能なすべてのネットワークインターフェイスが表示されます。 現在、標準インターフェイス（このスクリーンショットではens32）のみに設定があります。 これは、シンプルモードから引き継がれています。
次に、Create Bonding をクリックして、最初のボンディングインターフェースbond0 を作成します。 次のダイアログで、次のスクリーンショットに示すとおりにすべてのデータを入力し、ダイアログをSave.
次に、直接同期接続に適した設定で、2 番目のボンディングインターフェースbond1 を作成します。
2 つのボンディングインターフェイスを作成すると、ネットワークインターフェイス用のネットワーク設定ダイアログで、行ったすべての設定が再び表示されます。
…および作成したボンディングの設定が表示されます：
すべての設定手順が正常に完了したら、[Activate Changes ] をクリックして設定を有効にします。 新しいネットワーク設定が読み込まれます。 数秒後、ネットワーク設定のステータスは、実際のネットワークインターフェイスで「OK」になり、ボンディングでも「OK」になります。
…およびボンディングでも表示されます:
次に、2 台目のデバイスで、適切な設定を使用してネットワーク設定の構成を繰り返します。
3.2. ホスト名
クラスタに接続するデバイスには、それぞれ異なるホスト名を設定する必要があります。
ホスト名は、デバイス設定で定義できます。
この例では、アプライアンスに「cma1 」および「cma2 」という名前が付けられています。
3.3. クラスタの接続
準備が完了しましたので、クラスタの設定に進みます。
これを行うには、最初のデバイス（ここではcma1 ）のメインメニューにある web インターフェイスでClustering モジュールを開き、[Create Cluster.
クラスタを作成するためのダイアログで、対応する設定を入力し、Save でダイアログを確認します。 後でクラスタにアクセスするために使用するCluster IP address, は、ここで特に重要です。 このダイアログに関する詳細情報が必要な場合は、Checkmk ロゴの横にあるアイコンからインラインヘルプを呼び出してください。
次のページで、2 つのデバイスをクラスタに接続できます。 そのためには、2 番目のデバイスの web インターフェイスのパスワードを入力する必要があります。 このパスワードは、2 つのユニット間の接続を確立するために 1 回だけ使用されます。 表示されているターゲットデバイスのデータを上書きしてもよろしい場合は、確認ダイアログを承認してください。
この接続が正常に確立されると、クラスタのデバイスの同期が開始されます。 このプロセスの現在のステータスは、クラスタページで確認できます。 同期中、既存の監視サイトを含むすべてのリソースは、最初のノードで起動されます。
これ以降、クラスタの IP アドレス (ここでは10.3.3.30) を使用して、現在リソースを保持しているノードに関係なく、クラスタのリソース (監視サイトなど) にアクセスできるようになります。
4. クラスタのステータス
最初の同期が完了すると、クラスタは完全に動作可能になります。 クラスタのステータスは、クラスタページでいつでも確認できます。
コンソールのステータスビューを使用すると、Cluster ボックスにクラスタの現在の状態が要約されたフォームで表示されます。 各ノードの役割は、現在のステータスの後に括弧で表示されます。アクティブノードの場合は「M 」（メイン）、パッシブノードの場合は「S 」（サブ）と表示されます。
5. クラスタの特別な機能
5.1. リソースへのアクセス
web インターフェイスへのアクセスなどの監視サイトへのすべての要求、および SNMP トラップや syslog メッセージなどのイベントコンソールへの着信メッセージ、ライブステータス要求は、通常、クラスタの IP アドレスを経由する必要があります。
個々のノードに直接アクセスする必要があるのは、エラー診断や特定のノードの更新など、例外的な状況の場合のみです。
5.2. デバイスオプション
これまで個々のユニットで個別に設定していた、時刻同期や名前解決などの設定は、クラスタ内の 2 つのノード間で同期されます。
ただし、これらの設定は、それぞれのアクティブノードでのみ編集できます。 非アクティブノードでは、設定はロックされています。
Checkmk rack1 管理インターフェースの設定など、一部のデバイス固有の設定は、個々のデバイスでいつでも編集できます。
5.3. ノードの IP アドレスまたはホスト名
個々のノードの IP 設定を編集するには、まずノード間のリンクを切断する必要があります。 これを行うには、クラスタページで [Disconnect Cluster ] をクリックします。 その後、個々のノードの web インターフェイスで必要に応じて設定を変更できます。
変更が完了したら、クラスタページで「Reconnect Cluster 」を選択してください。 ノードが正常に再接続されると、クラスタは数分後に動作を再開します。 ステータスはクラスタページで確認できます。
5.4. Checkmk バージョンおよび監視サイトの管理
監視サイトと Checkmk バージョンも 2 つのノード間で同期されます。 これらは、アクティブなノードの web インターフェイス（独自の IP アドレスおよびクラスタ IP アドレスの両方）でのみ変更できます。
6. クラスタ運用における管理作業
6.1. ファームウェアの更新（メジャーバージョン）
以下で説明する互換バージョン内のファームウェア更新（例：1.6.1 から 1.6.2）とは異なり、メジャーバージョン（例：1.6.x から 1.7.y）を更新する場合は、若干異なる手順が必要です。 その理由は、メジャーバージョンでは通常、基盤となるオペレーティングシステムのバージョンが更新されたり、基本コンセプトが変更されたりするためです。 つまり、クラスタを短時間完全にオフラインにする必要があり、ダウンタイムが発生します。 マイナーアップデートでは、クラスタの個々のノードをメンテナンス状態にしてアップデートを実行するだけで十分です。 メジャーアップデートを実行するには、次のようにします。
準備として、まず Checkmk のマイナーバージョンを最新バージョンにアップデートし、次にアプライアンスファームウェアのマイナーバージョンを最新バージョンにアップデートしてください。
Clustering > Disconnect Cluster を使用して、ノードをクラスタから切断します。
すべてのノードの更新が完了したら、Clustering > Reconnect Cluster を使用してクラスタにノードを再接続します。
サイトで使用している Checkmk のバージョンが互換性があるかどうかを確認します (ほとんどの場合、互換性はありません)。必要に応じて、アプライアンスのメイン記事の説明に従って、各サイトのアプライアンスファームウェアと一致する Checkmk パッケージをインストールします。
6.2. ファームウェア更新（マイナーバージョン）
デバイスのファームウェアバージョンは、クラスタ運用中でも同期されません。 そのため、ファームウェアの更新は各ノードで個別に実行します。 ただし、この方法には、一方のノードが更新されている間も、もう一方のノードは監視を継続できるという利点があります。
互換性のあるファームウェアバージョンに更新する際は、必ず以下の手順に従ってください：
まず、更新するノードの web インターフェイスで「Clustering 」モジュールを開きます。
次に、このノードの列にある「ハート」アイコンをクリックし、表示される確認ダイアログで「はい」をクリックします。 これにより、ノードがメンテナンス状態になります。
メンテナンス状態のノードは、そのノードで現在アクティブなすべてのリソースを解放し、他のノードがそれらを引き継ぎます。
ノードがメンテナンス状態にある間、クラスタはフェイルセーフではありません。 アクティブなノードのスイッチがオフになると、メンテナンス状態にある非アクティブなノードはリソースを引き継ぎません。 この時点で 2 番目のノードもメンテナンス状態にすると、すべてのリソースがシャットダウンされます。 これらのリソースは、ノードがメンテナンス状態から解除されるまで再起動されません。 メンテナンス状態は、必ず手動で解除してください。
クラスタページに以下が表示されている場合、そのノードはメンテナンス状態にあることがわかります。
これで、クラスタ化されていないアプライアンスと同じ方法で、このノードのファームウェアの更新を実行できます。
ファームウェアのアップデートが正常に完了したら、クラスタページを再度開きます。 アップデートしたデバイスのメンテナンスステータスを解除します。 これにより、デバイスが自動的にクラスタに再挿入され、クラスタが完全に機能するようになります。
両方のノードで同じファームウェアバージョンを実行することをお勧めします。 したがって、クラスタが完全に回復したら、もう一方のノードについても同じ手順を繰り返してください。
6.3. クラスタの解散
クラスタからノードを切り離して、個別に動作を継続することができます。 そうすることで、両方のデバイスで同期された構成を引き続き使用したり、たとえば、一方のデバイスを工場出荷時の状態にリセットして再構成したりすることができます。
動作中に、1 つまたは両方のノードをクラスタから削除することができます。 現在のデータで両方のノードを引き続き使用したい場合は、まずデータの同期が正しく機能していることを確認する必要があります。 これは、クラスタページで確認できます。
クラスタを解散するには、web インターフェイスのクラスタページで [Disband Cluster ] をクリックします。 次の確認ダイアログのテキストに注意してください。 これは、接続が切断された後に、それぞれのデバイスがどのような状態になるかを、考えられるすべての状況について示しています。
アプライアンスの分離は、今後両方のアプライアンスを個別に操作できるように、両方のノードで個別に実行する必要があります。
今後、いずれかのデバイスだけを使用する場合は、引き続き使用するデバイスのクラスタを切断し、もう一方のデバイスを工場出荷時の状態に戻してください。
ノードをクラスタから切断した後、監視サイトは自動的に再起動しません。 必要に応じて、後で手動で再起動してください。
6.4. アプライアンスの交換
古いアプライアンスのハードドライブが正常に動作している場合は、古いアプライアンスからハードドライブを取り外し、新しいアプライアンスにインストールして、古いアプライアンスとまったく同じように配線し、電源をオンにしてください。 起動後、新しいユニットは古いユニットと同じようにクラスタに自動的に再挿入されます。
7. 故障診断
7.1. ログ記録
クラスタ管理は、大部分が自動的に行われます。 ノード上の自動プロセスが、各デバイスで起動および停止するリソースを決定します。 この動作は、ログエントリのフォームで詳細に記録されます。 これらのエントリには、クラスタページから「Cluster Log 」ボタンでアクセスできます。
これらのエントリは、他のシステムメッセージと同様、ユニットが再起動されると失われますのでご注意ください。 それ以降もメッセージを受信したい場合は、ブラウザから現在のログファイルをダウンロードするか、ログメッセージを syslog サーバーに転送する設定を永続的に設定してください。