documentation.suse.com / 基本的な3ノード高可用性クラスタのインストール
SUSE Linux Enterprise High Availability 16.0

基本的な3ノード高可用性クラスタのインストール

発行日: 03/11/2025
概要

ディスクレスSBDとソフトウェアウォッチドッグを使用した基本的な3ノード高可用性クラスタの設定方法。

目的

このクラスタは、テスト目的で使用することも、後で拡張可能な最小クラスタ設定として使用することもできます。

所要時間

基本的な高可用性クラスタの設定には、ネットワーク接続の速度にもよりますが、15分ほどを要します。

目標

SUSE Linux Enterprise High Availabilityをすばやく簡単に使い始めます。

1 使用シナリオ

 

このガイドでは、以下の特性を持つ最小限の高可用性クラスタのセットアップについて説明します。

  • 相互にパスワード不要のSSHアクセスが可能な3つのクラスタノード。ディスクレスSBDがQDeviceの助けを借りずにスプリットブレインシナリオを処理できるように、このセットアップには3つのノードが必要です。

  • サービスがどのノードで実行されていても、クライアントからのグラフィカル管理ツールHawkへの接続を可能にする浮動仮想IPアドレス。

  • スプリットブレインシナリオを回避するためのノードフェンシングメカニズムとして使用されるディスクレスSBD (STONITHブロックデバイス)とソフトウェアウォッチドッグ。

  • アクティブなホストが停止した場合における、あるノードから別のノードへのリソースのフェールオーバー(アクティブ/パッシブセットアップ)。

これは、外部要件を最小限に抑えたシンプルなクラスタセットアップです。このクラスタは、テスト目的で使用することも、後で運用環境向けに拡張可能な基本的なクラスタ設定として使用することもできます。

2 インストールの概要

 

1項 「使用シナリオ」で説明する高可用性クラスタをインストールするには、以下のタスクを実行する必要があります。

  1. 3項 「システム要件」を確認し、必要なものがすべて揃っていることを確認します。

  2. 4項 「High Availability Extensionの有効化」 に従って、クラスタノードにSUSE Linux Enterprise High Availabilityをインストールします。

  3. 5項 「最初のノードの設定」に従って、最初のノードでクラスタを初期化します。

  4. 6項 「2つ目と3つ目のノードの追加」に従って、他のノードをクラスタに追加します。

  5. 7項 「Hawkへのログイン」に従って、Hawk Webインタフェースにログインして、クラスタを監視します。

  6. 8項 「クラスタのテスト」に従って 、クラスタが期待どおりに動作することを確認するための基本的なテストを実行します。

  7. 運用環境用にクラスタを拡張する際のアドバイスについては、9項 「次のステップ」を参照します。

3 システム要件

 

このセクションでは、SUSE Linux Enterprise High Availabilityの最小セットアップのシステム要件について説明します。

3.1 ハードウェア要件

 
サーバ

クラスタノードとして動作する3台のサーバ。

サーバはベアメタルでも仮想マシンでも構いません。各サーバが同一のハードウェア設定(メモリ、ディスクスペースなど)になっている必要はありませんが、アーキテクチャは同じである必要があります。クロスプラットフォームのクラスタはサポートされていません。

サーバハードウェアの詳細については、https://www.suse.com/download/sle-ha/の「System Requirements」セクションを参照してください。

ネットワークインタフェースカード(NIC)

クラスタノードあたり少なくとも2つのNIC。これにより、以下のいずれかの方法を使用して、クラスタに2つ以上の通信チャネルを設定できます。

  • NICをネットワークボンドに結合する(推奨)。この場合、クラスタを初期化する前に各ノードでボンドデバイスを設定する必要があります。

  • Corosync内に2つ目の通信チャネルを作成する。これはクラスタセットアップスクリプトで設定できます。この場合、2つのNICは異なるサブネット上に存在する必要があります。

STONITH (ノードフェンシング)

サポートされるには、すべてのSUSE Linux Enterprise High Availabilityクラスタに、スプリットブレインシナリオを回避するための少なくとも1つのノードフェンシング(STONITH)デバイスが必要です。これは、物理デバイス(電源スイッチ)でも、ウォッチドッグと組み合わせたSBD (STONITHブロックデバイス)でも構いません。SBDは、共有ストレージまたはディスクレスモードのいずれかで使用できます。

このガイドで説明する最小セットアップでは、ソフトウェアウォッチドッグとディスクレスSBDを使用するため、追加のハードウェアは必要ありません。運用環境でこのクラスタを使用する前に、ソフトウェアウォッチドッグをハードウェアウォッチドッグに置き換えてください。

3.2 ソフトウェアの必要条件

 
オペレーティングシステム

すべてのノードにSUSE Linux Enterprise Serverがインストールされ、登録されている必要があります。

High Availability Extension

SUSE Linux Enterprise High Availability Extensionには、追加の登録コードが必要です。

この拡張機能は、SLESのインストール中に有効にするか、実行中のシステムで後で有効にすることができます。このガイドでは、実行中のシステムで拡張機能を有効にして登録する方法を説明します。

3.3 ネットワーク要件

 
時刻同期

すべてのシステムはクラスタ外のNTPサーバに同期する必要があります。SUSE Linux Enterprise ServerはNTPにchronyを使用します。クラスタを初期化する際、chronyが実行されていないと警告が表示されます。

ノードが同期されていても、ノードに設定されたタイムゾーンが異なると、ログファイルやクラスタレポートの分析が困難になることがあります。

ホスト名およびIPアドレス

すべてのクラスタノードは名前で互いを検出できる必要があります。信頼性の高い名前解決を行うには、以下の方法を使用します。

  • 静的IPアドレスを使用します。

  • /etc/hostsファイル内のすべてのノードを、IPアドレス、FQDN、短いホスト名とともに一覧表示します。

各NICのプライマリIPアドレスのみがサポートされます。

SSH

すべてのクラスタノードはSSHによって互いにアクセスできる必要があります。特定のクラスタ操作では、パスワード不要のSSH認証も必要です。クラスタを初期化すると、セットアップスクリプトは、既存のSSHキーがあるかどうかを確認し、ない場合には生成します。

重要
重要: SUSE Linux Enterprise 16におけるroot SSHアクセス

SUSE Linux Enterprise 16では、パスワードによるroot SSHログインはデフォルトで無効になっています。

各ノードで、クラスタを初期化する前に、sudo特権を持つユーザを作成するか、rootユーザにパスワード不要のSSH認証を設定します。

sudoユーザでクラスタを初期化する場合、特定のcrmshコマンドにもパスワード不要のsudo権限が必要です。

4 High Availability Extensionの有効化

 

この手順では、既存のSUSE Linux Enterprise ServerにSUSE Linux Enterprise High Availabilityをインストールする方法を説明します。Agamaを使用したSLESのインストール中にHigh Availability Extensionとパッケージをすでにインストールしている場合は、この手順を省略できます。

要件
 

  • SUSE Linux Enterprise Serverがインストールされ、SUSEカスタマーセンターに登録されている。

  • SUSE Linux Enterprise High Availabilityの追加の登録コードがある。

クラスタノードとして使用するすべてのマシンでこの手順を実行します。

  1. rootユーザまたはsudo特権を持つユーザとしてログインします。

  2. High Availability Extensionがすでに有効になっているかどうかを確認します。 

    > sudo SUSEConnect --list-extensions

  3. High Availabilityパッケージがすでにインストールされているかどうかを確認します。 

    > zypper search ha_sles

  4. SUSE Linux Enterprise High Availability Extensionを有効にします。 

    > sudo SUSEConnect -p sle-ha/16.0/x86_64 -r HA_REGCODE

  5. High Availabilityパッケージをインストールします。

    > sudo zypper install -t pattern ha_sles

5 最初のノードの設定

 

SUSE Linux Enterprise High Availabilityには、クラスタのインストールを簡素化するセットアップスクリプトが含まれています。最初のノードでクラスタを設定するには、crm cluster init スクリプトを使用します。

5.1 crm cluster initスクリプトの概要

 

crm cluster initコマンドは、クラスタ通信に必要な基本パラメータを定義するスクリプトを起動し、その結果、動作する1ノードクラスタが作成されます。

このスクリプトが確認および設定するコンポーネントは、次のとおりです。

NTP

chronyがブート時に開始するように設定されているかどうかをチェックします。設定されていない場合は、メッセージが表示されます。

SSH

クラスタノード間でパスワード不要のログインを行うためのSSHキーを検出または生成します。

ファイアウォール

クラスタ通信に必要なポートをファイアウォールで開きます。

Csync2

クラスタ内のすべてのノードで設定ファイルを複製するようにCsync2を設定します。

Corosync

クラスタ通信システムを設定します。

SBD/ウォッチドッグ

ウォッチドッグが存在するかどうかをチェックし、SBDをノードフェンシングメカニズムとして設定するかどうか確認メッセージを表示します。

Hawkクラスタの管理

Hawkサービスを有効にし、Hawk WebインタフェースのURLを表示します。

仮想浮動IP

Hawk Webインタフェースに仮想IPアドレスを設定するかどうか確認メッセージを表示します。

QDevice/QNetd

QDevice/QNetdを設定してクォーラムの決定に参加するかどうか確認メッセージを表示します。これは、ノード数が偶数であるクラスタ、特に2ノードクラスタの場合に推奨されます。

注記
注記: Pacemakerのデフォルト設定

crm cluster initスクリプトによって設定されるオプションは、Pacemakerのデフォルト設定と同じではない場合があります。スクリプトが変更した設定は/var/log/crmsh/crmsh.logで確認できます。ブートストラッププロセス中に設定されたオプションは、crmshで後で変更できます。

注記
注記: さまざまなプラットフォームに対するクラスタ設定

crm cluster initスクリプトは、システム環境(Microsoft Azureなど)を検出し、その環境のプロファイルに基づいて特定のクラスタ設定を調整します。詳細については、ファイル/etc/crm/profiles.ymlを参照してください。

5.2 最初のノードでのクラスタの初期化

 

crm cluster initスクリプトを使用して、最初のノードでクラスタを設定します。スクリプトは、クラスタに関する基本情報の入力を求め、必要な設定とサービスを構成します。詳細については、crm cluster init --helpコマンドを実行してください。

要件
 

  • SUSE Linux Enterprise High Availabilityがインストールされ、最新の状態である。

  • すべてのノードに、2つ以上のネットワークインタフェースまたは1つのネットワークボンドがあり、各ノードのFQDNと短いホスト名とともに静的IPアドレスが/etc/hostsファイルに記載されている。

この手順は1つのノードに対してのみ実行します。

  1. rootユーザまたはsudo特権を持つユーザとして最初のノードにログインします。

  2. crm cluster initスクリプトを起動します。 

    > sudo crm cluster init

    スクリプトは、chronyが実行されているかどうかを確認し、必要なファイアウォールポートを開き、Csync2を設定し、SSHキーを確認します。SSHキーがない場合は、スクリプトによって生成されます。

  3. クラスタ通信用にCorosyncを設定します。

    1. 最初の通信チャネル(ring0)のIPアドレスを入力します。デフォルトでは、スクリプトは最初の利用可能なネットワークインタフェースのアドレスを提案します。これは、個々のインタフェースか、ボンドデバイスのいずれかです。このアドレスを受け入れるか、別のアドレスを入力してください。

    2. スクリプトが複数のネットワークインタフェースを検出した場合、2つ目の通信チャネル(ring1)を設定するかどうか確認メッセージを表示します。最初のチャネルをボンドデバイスで設定した場合、nで拒否できます。2つ目のチャネルを設定する必要がある場合は、yで確定し、別のネットワークインタフェースのIPアドレスを入力します。2つのインタフェースは異なるサブネット上に存在する必要があります。

    スクリプトは、Corosync通信用のデフォルトのファイアウォールポートを設定します。

  4. SBDをノードフェンシングメカニズムとして設定するかどうかを選択します。

    1. <y>キーを押して、SBDを使用することを確認します。

    2. ブロックデバイスへのパスの入力を求められたら、「none」と入力し、ディスクレスSBDを設定します。

    スクリプトは、関連するタイムアウト設定を含む、SBDを設定します。ディスクベースのSBDとは異なり、ディスクレスSBDはSTONITHクラスタリソースを必要としません。

    ハードウェアウォッチドッグが利用できない場合、スクリプトはソフトウェアウォッチドッグsoftdog を設定します。

  5. Hawk Webインタフェースでクラスタを管理するための仮想IPアドレスを設定します。

    1. <y>キーを押して、仮想IPアドレスを設定することを確認します。

    2. Hawkの管理IPとして使用する、未使用のIPアドレスを入力します。

    個々のクラスタノードでHawkにログインする代わりに、その仮想IPアドレスに接続できるようになります。

  6. QDeviceおよびQNetdを設定するかどうかを選択します。

    このドキュメントで説明されている最小限のセットアップについては、nで拒否してください。

スクリプトはクラスタサービスを開始し、クラスタをオンラインにして、Hawkを有効にします。Hawkに使用するURLが画面に表示されます。また、crm statusコマンドでクラスタのステータスを確認することもできます。

重要
重要: haclusterのセキュリティ保護されたパスワード

crm cluster initスクリプトはデフォルトのクラスタユーザとパスワードを作成します。デフォルトのパスワードはできるだけ早くセキュリティ保護されたパスワードに変更します。 

> sudo passwd hacluster

6 2つ目と3つ目のノードの追加

 

crm cluster joinスクリプトを使用して、他のノードをクラスタに追加します。スクリプトは既存のクラスタノードへのアクセスのみが必要で、ご使用のマシンで自動的に基本セットアップを完了します。詳細については、crm cluster join --helpコマンドを実行してください。

要件
 

  • SUSE Linux Enterprise High Availabilityがインストールされ、最新の状態である。

  • 既存のクラスタが、少なくとも1つのノードですでに実行されている。

  • すべてのノードに、2つ以上のネットワークインタフェースまたは1つのネットワークボンドがあり、各ノードのFQDNと短いホスト名とともに静的IPアドレスが/etc/hostsファイルに記載されている。

  • sudoユーザとしてログインする場合:すべてのノードに同じユーザが存在する必要があります。このユーザには、パスワード不要のsudo権限が必要です。

  • rootユーザとしてログインする場合:パスワード不要のSSH認証がすべてのノードで設定されている必要があります。

追加の各ノードで以下の手順を実行します。

  1. 最初のノードの設定に使用したユーザと同じユーザとして、このノードにログインします。

  2. crm cluster joinスクリプトを起動します。

    • 最初のノードをrootとして設定した場合は、追加のパラメータなしでスクリプトを起動できます。 

      # crm cluster join

    • 最初のノードをsudoユーザとして設定する場合は、-cオプションでそのユーザを指定する必要があります。 

      > sudo crm cluster join -c USER@NODE1

    スクリプトは、chronyが実行されているかどうかを確認し、必要なファイアウォールポートを開き、Csync2を設定します。

  3. まだ-cを使用して最初のノードを指定していない場合は、そのIPアドレスまたはホスト名の入力を求められます。

  4. ノード間にパスワード不要のSSH認証をまだ設定していない場合、既存の各ノードのパスワードの入力を求められます。

  5. クラスタ通信用にCorosyncを設定します。

    1. スクリプトはring0用のIPアドレスを提案します。このIPアドレスは、最初のノードでring0に使用したIPアドレスと同じサブネット上に存在する必要があります。そうでない場合は、正しいIPアドレスを入力してください。

    2. クラスタに2つのCorosync通信チャネルが設定されている場合、スクリプトはring1用のIPアドレスの入力を求めます。このIPアドレスは、最初のノードでring1に使用したIPアドレスと同じサブネット上に存在する必要があります。

スクリプトは最初のノードからクラスタ設定をコピーし、新しいノードを考慮するようにタイムアウト設定を調整し、新しいノードをオンラインにします。

crm statusコマンドでクラスタのステータスを確認することができます。

重要
重要: haclusterのセキュリティ保護されたパスワード

crm cluster joinスクリプトはデフォルトのクラスタユーザとパスワードを作成します。各ノードで、デフォルトのパスワードはできるだけ早くセキュリティ保護されたパスワードに変更します。 

> sudo passwd hacluster

7 Hawkへのログイン

 

Hawkを使用すると、グラフィカルなWebブラウザを使用して高可用性クラスタを監視および管理できます。また、実行しているノードがどれであれ、クライアントからのHawkへの接続を可能にする仮想IPアドレスを設定することもできます。

要件
 

  • クライアントマシンはクラスタノードに接続できる必要があります。

  • クライアントマシンには、JavaScriptとクッキーが有効なグラフィカルWebブラウザが必要です。

この手順は、クラスタノードに接続できるマシンであれば、どのマシンでも実行できます。

  1. Webブラウザを起動し、次のURLを入力します。 

    https://HAWKSERVER:7630/

    HAWKSERVERは、クラスタノードのIPアドレスまたはホスト名、またはHawk仮想IPアドレスが設定されている場合はそのアドレスに置き換えてください。

    注記
    注記: 証明書の警告

    初めてURLにアクセスするときに証明書の警告が表示される場合は、自己署名証明書が使用されています。証明書を検証するには、クラスタオペレータに証明書の詳細を求めます。続行するには、ブラウザに例外を追加して警告をバイパスします。

  2. Hawkのログイン画面で、hacluster ユーザのユーザ名とパスワードを入力します。

  3. ログインをクリックします。Hawk Webインタフェースには、デフォルトで状態画面が表示されます。

［状態］画面には、aliceというノードで実行されている仮想IPアドレスadmin-ipである、1 つの設定済みリソースが表示されます。
図 1: Hawkの状態画面
 

8 クラスタのテスト

 

次のテストは、クラスタのセットアップに関する基本的な問題を特定するのに役立ちます。ただし、現実的なテストには、具体的なユースケースやシナリオが含まれます。運用環境でクラスタを使用する前に、ご自分のユースケースに従ってクラスタを十分にテストしてください。

8.1 リソースフェールオーバーのテスト

 

現在のノードがstandby に設定されている場合、クラスタがリソースを別のノードに移動するかどうかを確認します。この手順では、aliceとbobというサンプルノードと、admin-ipという仮想IPリソースを、192.168.1.10というサンプルIPアドレスで使用します。

  1. 2つの端末を開きます。

  2. 最初の端末で、仮想IPアドレスにpingを実行します。 

    > ping 192.168.1.10

  3. 2つ目の端末で、クラスタノードの1つにログインします。

  4. 仮想IPアドレスがどのノードで実行されているかを確認します。 

    > sudo crm status
[..]
Node List:
  * Online: [ alice bob ]

Full List of Resources:
  * admin-ip  (ocf:heartbeat:IPaddr2):    Started alice

  5. aliceをスタンバイモードにします。 

    > sudo crm node standby alice

  6. クラスタの状態を再度確認します。リソースadmin-ipはbobに移行しているはずです。 

    > sudo crm status
[...]
Node List:
  * Node alice: standby
  * Online: [ bob ]

Full List of Resources:
  * admin-ip  (ocf:heartbeat:IPaddr2):    Started bob

  7. 最初の端末で、マイグレーション中も、仮想IPアドレスに対して連続してpingが実行されます。これは、クラスタセットアップと浮動IPアドレスが正常に機能していることを示します。

  8. Ctrl–Cを押してpingコマンドをキャンセルします。

  9. 2つ目の端末で、aliceをオンラインに戻します。 

    > sudo crm node online alice

8.2 クラスタ障害のテスト

 

crm cluster crash_testコマンドは、クラスタの障害をシミュレートし、結果を報告します。

このコマンドは以下のチェックをサポートします。

--split-brain-iptables

Corosyncポートをブロックすることでスプリットブレインシナリオをシミュレートし、1つのノードが予期されるようにフェンシングできるかどうかをチェックします。このテストを実行する前に、iptablesをインストールする必要があります。

--kill-sbd/--kill-corosync/ --kill-pacemakerd

SBD、Corosync、またはPacemakerのデーモンを終了します。これらのテストのいずれかを実行すると、/var/lib/crmsh/crash_test/ディレクトリにレポートが表示されます。レポートには、テストケースの説明、アクションのログ、考え得る結果の説明が含まれます。

--fence-node NODE

コマンドラインから渡される特定のノードをフェンスします。

詳細については、crm cluster crash_test --helpコマンドを実行してください。

以下の例では、aliceとbobというノードを使用し、bobのフェンシングをテストします。テスト中のbobの変更状態を表示するには、Hawkにログインし、状態 › ノードに移動します。

例 1: クラスタのテスト: ノードフェンシング
 
> sudo crm status
[...]
Node List:
  * Online: [ alice bob ]

Active Resources:
  * admin-ip     (ocf:heartbeat:IPaddr2):    Started alice

> sudo crm cluster crash_test --fence-node bob

==============================================
Testcase:          Fence node bob
Fence action:      reboot
Fence timeout:     95

!!! WARNING WARNING WARNING !!!
THIS CASE MAY LEAD TO NODE BE FENCED.
TYPE Yes TO CONTINUE, OTHER INPUTS WILL CANCEL THIS CASE [Yes/No](No): Yes
INFO: Trying to fence node "bob"
INFO: Waiting 71s for node "bob" reboot...
INFO: Node "bob" will be fenced by "alice"!
INFO: Node "bob" was successfully fenced by "alice"

9 次のステップ

 

このガイドでは、テスト目的で使用できる基本的な高可用性クラスタについて説明します。運用環境で使用するためにこのクラスタを拡張するには、以下の手順を実行することをお勧めします。

ノードの追加

crm cluster joinスクリプトを使用して、他のノードをクラスタに追加します。

ハードウェアウォッチドッグの有効化

運用環境でクラスタを使用する前に、softdogをハードウェアウォッチドッグに置き換えてください。

STONITHデバイスの追加

クリティカルなワークロードには、物理的なSTONITHデバイスまたはディスクベースのSBDを使用して、2台または3台のSTONITHデバイスを用意することを強くお勧めします。

QDeviceの設定

QDeviceおよびQNetdはクォーラムの決定に参加します。アービトレータであるQNetdの支援により、QDeviceは設定可能な投票数を提供します。これにより、クラスタが標準のクォーラムルールが許可するよりも多くのノード障害に耐えることができます。ノード数が偶数であるクラスタ、特に2ノードクラスタについては、QDeviceおよびQNetdの展開をお勧めします。