目次にジャンプページナビゲーションにジャンプ: 前のページ[アクセスキーp]/次のページ[アクセスキーn]
documentation.suse.com / SUSE Linux Enterprise High Availability Extensionのドキュメント / Quick Start Guides / インストールおよびセットアップクイックスタート
SUSE Linux Enterprise High Availability Extension 15 SP3

インストールおよびセットアップクイックスタート

 

SUSE Linux Enterprise High Availability Extension 15 SP3

発行日: December 11, 2023

このマニュアルでは、ha-cluster-bootstrapパッケージで提供されているブートストラップスクリプトを使用して、非常に基本的な2ノードクラスタをセットアップする手順を説明します。仮想IPアドレスをクラスタリソースとして設定する手順や、共有ストレージ上でSBDをノードフェンシングメカニズムとして使用する手順も記載されています。

著者: Tanja Roth、Thomas Schraitle

1 使用シナリオ

 

このマニュアルに記載されている手順に従うと、次のプロパティを持つ2ノードクラスタの最小セットアップになります。

  • ネットワーク経由で相互に接続された2つのノード: alice (IP: 192.168.1.1)およびbob (IP: 192.168.1.2)。

  • 実行している物理ノードがどれであれ、クライアントからの該当サービスへの接続を可能にする浮動仮想IPアドレス(192.168.2.1)。

  • SBDフェンシングメカニズムとして使用される共有ストレージデバイス。これにより、スプリットブレインシナリオを回避します。

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

ブートストラップスクリプトを使用してクラスタを設定したら、グラフィカルインタフェースであるHawk2を使用してクラスタを監視します。これは、SUSE® Linux Enterprise High Availability Extensionに搭載されているクラスタ管理ツールの1つです。リソースのフェールオーバーが機能するかどうかの基本的なテストとして、一方のノードをスタンバイモードにし、仮想IPアドレスが2つ目のノードに移行されるかどうかを確認します。

この2ノードクラスタは、テスト目的で使用することも、後で拡張可能な最小クラスタ設定として使用することもできます。運用環境でクラスタを使用する前に、ご自分の要件に従ってクラスタを変更してください。

2 システム要件

 

この項では、1項で説明されているシナリオの重要なシステム要件について説明します。運用環境で使用するためにクラスタを調整する方法については、第2章 「システム要件と推奨事項」の一覧を参照してください。

2.1 ハードウェア要件

 
サーバ

2.2項 「ソフトウェアの必要条件」で指定されているソフトウェアがインストールされた2台のサーバ。

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

通信チャネル

クラスタノードあたり、少なくとも2つのTCP/IP通信メディア。ネットワーク機器は、クラスタ通信に使用する通信手段(マルチキャストまたはユニキャスト)をサポートする必要があります。通信メディアは100Mbit/s以上のデータレートをサポートする必要があります。サポートされるクラスタセットアップでは、2つ以上の冗長通信パスが必要です。これは次のように実行できます。

  • ネットワークデバイスボンディング(推奨)。

  • Corosync内の2つ目の通信チャネル。

ノードフェンシング/STONITH

「スプリットブレイン」シナリオを回避するため、クラスタにはノードフェンシングメカニズムが必要です。スプリットブレインシナリオでは、クラスタノードは、お互いを認識していない2つ以上のグループに分割されます(ハードウェアまたはソフトウェアの障害か、ネットワーク接続の切断による)。フェンシングメカニズムにより、問題のあるノードを分離します(通常はノードをリセットするか、ノードの電源をオフにすることによって分離します)。これをSTONITH (「Shoot the other node in the head」)と呼びます。ノードフェンシングメカニズムは、物理デバイス(電源スイッチ)でも、SBD (ディスクによるSTONITH)のようなメカニズムとウォッチドッグを組み合わせたものでも構いません。SBDを使用するには共有ストレージが必要です。

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

 

クラスタの一部になるすべてのノードには、少なくとも次のモジュールと拡張機能が含まれている必要があります。

  • Basesystem Module 15 SP3

  • Server Applications Module 15 SP3

  • SUSE Linux Enterprise High Availability Extension 15 SP3

2.3 その他の要件と推奨事項

 
時刻同期

クラスタノードはクラスタ外のNTPサーバに同期する必要があります。SUSE Linux Enterprise High Availability Extension 15以降、Chronyは、NTPでデフォルトで実装されるようになりました。詳細については、SUSE Linux Enterprise Server 15 SP3の『管理ガイド』を参照してください。

ノードが同期されていない場合、クラスタが正常に動作しないことがあります。また、同期が行われていないと、ログファイルとクラスタレポートの分析が非常に困難になります。ブートストラップスクリプトを使用するときにNTPがまだ設定されていない場合、警告が表示されます。

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

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

  • /etc/hostsファイルにあるすべてのクラスタノードを、完全修飾ホスト名およびショートホスト名で一覧表示します。クラスタのメンバーが名前で互いを見つけられることが重要です。名前を使用できない場合、内部クラスタ通信は失敗します。

SSH

すべてのクラスタノードはSSHによって互いにアクセスできる必要があります。crm report (トラブルシューティング用)などのツールおよびHawk2の履歴エクスプローラは、ノード間でパスワード不要のSSHアクセスを必要とします。それがない場合、現在のノードからしかデータを収集できません。

クラスタのセットアップにブートストラップスクリプトを使用した場合、SSHキーは自動的に作成されてコピーされます。

3 ブートストラップスクリプトの概要

 

パッケージ ha-cluster-bootstrap のすべてのコマンドは、最低限の時間と手動介入しか必要のないブートストラップスクリプトを実行します。

  • ha-cluster-initを使用して、クラスタ通信に必要な基本パラメータを定義します。これによって1ノードクラスタの実行が可能になります。

  • ha-cluster-joinで、他のノードをクラスタに追加します。

  • ha-cluster-removeで、クラスタからノードを削除します。

すべてのブートストラップスクリプトは/var/log/ha-cluster-bootstrap.logにログを記録します。ブートストラッププロセスの詳細については、このファイルを確認してください。ブートストラッププロセス中に設定されたオプションは、YaSTクラスタモジュールで後で変更できます。詳細については第4章 「YaSTクラスタモジュールの使用」を参照してください。

各スクリプトには、さまざまな機能、スクリプトのオプション、およびスクリプトで作成、変更できるファイルの概要を説明したマニュアルページが付属します。

ブートストラップスクリプトha-cluster-initが確認および設定するコンポーネントは、次のとおりです。

NTP

NTPがブート時に開始するよう設定されていない場合、メッセージが表示されます。SUSE Linux Enterprise High Availability Extension 15以降、Chronyは、NTPでデフォルトで実装されるようになりました。

SSH

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

Csync2

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

Corosync

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

SBD/ウォッチドッグ

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

仮想浮動IP

Hawk2でのクラスタ管理用の仮想IPアドレスを設定するかどうか確認メッセージを表示します。

ファイアウォール

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

クラスタ名

クラスタの名前を定義します。デフォルトではhaclusterです。これはオプションで、主にGeoクラスタで役立ちます。通常、クラスタ名は場所を反映し、Geoクラスタ内のサイトを識別しやすくします。

QDevice/QNetd

このセットアップについてはここでは説明しません。QNetdサーバを使用する場合は、第12章 「QDeviceとQNetd」の説明に従って、ブートストラップスクリプトを使用してセットアップできます。

4 SUSE Linux Enterprise High Availability Extensionのインストール

 

High Availability Extensionでクラスタの設定と管理を行うためのパッケージは、High Availabilityインストールパターン(コマンドラインではsles_haで指定)に含まれています。このパターンは、SUSE Linux Enterprise High Availability ExtensionがSUSE® Linux Enterprise Serverの拡張としてインストールされている場合にのみ使用できます。

拡張をインストールする方法の詳細については、SUSE Linux Enterprise Server 15 SP3の『導入ガイド』を参照してください。

手順 1: High Availabilityパターンのインストール
 

このパターンがまだインストールされていない場合は、次の手順に従います。

  1. 次のように、Zypperを使用してコマンドラインでインストールします。

    root # zypper install -t pattern ha_sles

  2. クラスタの一部になるすべてのマシンにHigh Availabilityパターンをインストールします。

    注記
    注記: すべてのパーティへのソフトウェアパッケージのインストール

    SUSE Linux Enterprise Server 15 SP3およびSUSE Linux Enterprise High Availability Extension 15 SP3を自動インストールする場合は、AutoYaSTを使用して既存のノードをクローンします。詳細については、3.2項 「AutoYaSTによる大量インストールと展開」を参照してください。

  3. SUSEカスタマセンターにマシンを登録します。詳細については、SUSE Linux Enterprise Server 15 SP3の『アップグレードガイド』を参照してください。

5 フェンシングメカニズムとしてのSBDの使用

 

SAN (ストレージエリアネットワーク)などの共有ストレージが存在する場合、それらのストレージを使用してスプリットブレインシナリオを回避できます。そのためには、SBDをノードのフェンシングメカニズムとして設定します。SBDは、ウォッチドッグサポートとexternal/sbd STONITHリソースエージェントを使用します。

5.1 SBDの要件

 

ha-cluster-initで最初のノードをセットアップする際に、SBDを使用するかどうかを決定できます。使用する場合、共有ストレージデバイスのパスを入力する必要があります。デフォルトで、ha-cluster-initは、SBDに使用するデバイス上に自動的に小容量のパーティションを作成します。

SBDを使用するには、次の要件を満たしている必要があります。

  • 共有ストレージデバイスのパスが永続的で、クラスタ内のすべてのノードで一致している必要があります。/dev/disk/by-id/dm-uuid-part1-mpath-abcedf12345などの固定デバイス名を使用してください。

  • SBDデバイスでホストベースのRAIDやLVM2を使用したり、SBDデバイスをDRBD*インスタンス上に存在させることは「できません」。

共有ストレージの設定方法の詳細については、SUSE Linux Enterprise Server 15 SP3の『Storage Administration Guide』を参照してください。

5.2 SBDのsoftdogウォッチドッグの有効化

 

SUSE Linux Enterprise Serverでは、カーネル内のウォッチドッグサポートはデフォルトで有効化されています。これは、ハードウェア固有のウォッチドッグドライバを提供する、さまざまなカーネルモジュールを標準装備しています。High Availability Extensionはウォッチドッグに「フィード」するソフトウェアコンポーネントとしてSBDデーモンを使用します。

次の手順では、softdogウォッチドッグを使用します。

重要
重要: Softdogの制限

softdogドライバはCPUが最低1つは動作中であることを前提とします。すべてのCPUが固まっている場合、システムを再起動させるsoftdogドライバのコードは実行されません。これに対して、ハードウェアウォッチドッグはすべてのCPUが固まっていても動作し続けます。

運用環境でクラスタを使用する前に、softdogモジュールを、ご使用のハードウェアに最適なハードウェアモジュールに置き換えることを強くお勧めします。

ただし、ウォッチドッグがご使用のハードウェアに一致しない場合は、softdogはカーネルウォッチドッグモジュールとして使用できます。

  1. 5.1項 「SBDの要件」の説明に従って、永続的な共有ストレージを作成します。

  2. softdogウォッチドッグを有効にします。 

    root # echo softdog > /etc/modules-load.d/watchdog.conf
root # systemctl restart systemd-modules-load

  3. softdogモジュールが正しくロードされているかどうかをテストします。 

    root # lsmod | grep dog
softdog                16384  1

スプリットシナリオを避けるために、SBDフェンシングメカニズムが正常に機能しているかどうかをテストすることを強くお勧めします。このテストを実行するには、Corosyncクラスタ通信をブロックします。

6 最初のノードの設定

 

ha-cluster-initスクリプトを使用して最初のノードを設定します。ここでは最小限の時間と手動介入しか必要ありません。

手順 2: ha-cluster-initを使用した最初のノード(alice)の設定
 

  1. クラスタノードとして使用する物理または仮想マシンにrootとしてログインします。

  2. 実行によって、ブートストラップスクリプトを開始します。 

    root # ha-cluster-init --name CLUSTERNAME

    CLUSTERNAMEプレースホルダを、クラスタの地理的な場所のような、意味のある名前で置き換えます(たとえば、amsterdam)。これによってサイトを識別しやすくなるため、後でGeoクラスタを作成する場合に特に役立ちます。

    クラスタ通信にマルチキャスト(デフォルト)の代わりにユニキャストが必要な場合は、オプション-uを使用します。インストール後、ファイル/etc/corosync/corosync.confで値udpuを見つけます。ha-cluster-initがAmazon Web Services (AWS)で実行しているノードを検出する場合、スクリプトはクラスタ通信のデフォルトとして自動的にユニキャストを使用します。

    このスクリプトは、NTP設定とハードウェアウォッチドッグサービスを確認します。また、SSHアクセスとCsync2の同期に使用される公開および秘密SSHキーが生成され、それぞれのサービスが起動されます。

  3. クラスタ通信層(Corosync)を設定します。

    1. バインドするネットワークアドレスを入力します。デフォルトでは、スクリプトはeth0のネットワークアドレスを提案します。または、たとえばbond0のアドレスなど、別のネットワークアドレスを入力します。

    2. マルチキャストアドレスを入力します。スクリプトはデフォルトとして使用できるランダムなアドレスを提案します。もちろん、ご使用の特定のネットワークがマルチキャストアドレスをサポートしている必要があります。

    3. マルチキャストポートを入力します。スクリプトはデフォルトとして5405を提案します。

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

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

    2. SBDに使用するブロックデバイスのパーティションの永続的なパスを入力します。5項 「フェンシングメカニズムとしてのSBDの使用」を参照してください。パスはクラスタ内のすべてのノード全体で一致している必要があります。

  5. Hawk2でクラスタを管理するための仮想IPアドレスを設定します(この仮想IPリソースは、後でフェールオーバーが正常に実行されるかどうかをテストするために使用します)。

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

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

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

最後に、スクリプトはPacemakerサービスを開始し、クラスタをオンラインにして、Hawk2を有効にします。Hawk2に使用するURLが画面に表示されます。

1ノードクラスタが実行するようになります。状態を表示するには、次の手順に従います。

手順 3: Hawk2 Webインタフェースへのログイン
 

  1. 任意のコンピュータで、Webブラウザを起動し、JavaScriptとクッキーが有効なことを確認します。

  2. URLとして、Hawk Webサービスを実行するクラスタノードのIPアドレスまたはホスト名を入力します。または、手順2「ha-cluster-initを使用した最初のノード(alice)の設定」のステップ 5で設定した仮想IPアドレスのアドレスを入力します。 

    https://HAWKSERVER:7630/
    注記
    注記: 証明書の警告

    初めてURLにアクセスしようとするときに証明書の警告が表示される場合は、自己署名証明書が使用されています。自己署名証明書は、デフォルトでは信頼されません。

    証明書を検証するための詳細情報については、クラスタのオペレータに問い合わせてください。

    続行するには、ブラウザに例外を追加して警告をバイパスします。

  3. Hawk2のログイン画面で、ブートストラップ手順で作成されたユーザのユーザ名とパスワードを入力します(ユーザhacluster、パスワードlinux)。

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

    デフォルトのパスワードはできるだけ早くセキュリティ保護されたパスワードに変更します。 

    root # passwd hacluster

  4. ログインをクリックします。ログイン後、Hawk2 Webインタフェースに［ステータス］画面がデフォルトで表示され、クラスタの現在の状態の概要が表示されます。

    Hawk2の1ノードクラスタの状態
    図 1: Hawk2の1ノードクラスタの状態
     

7 2つ目のノードの追加

 

1ノードクラスタが正常に稼働している場合、手順 4に従って、ha-cluster-joinブートストラップスクリプトを使用して2つ目のクラスタノードを追加します。スクリプトは既存のクラスタノードへのアクセスのみが必要で、ご使用のマシンで自動的に基本セットアップを完了します。詳細については、ha-cluster-joinマニュアルページを参照してください。

ブートストラップスクリプトは、SBDやCorosyncなど、2ノードクラスタに固有な設定を変更します。

手順 4: ha-cluster-joinを使用した2つ目のノード(bob)の追加
 

  1. クラスタを参加させることになる物理または仮想マシンにrootとしてログインします。

  2. 実行によって、ブートストラップスクリプトを開始します。 

    root # ha-cluster-join

    NTPがブート時に開始するよう設定されていない場合、メッセージが表示されます。このスクリプトは、ハードウェアウォッチドッグデバイスも確認します(SBDを設定する場合は重要です)。デバイスがないときは警告が表示されます。

  3. それでも継続を選択する場合、既存のノードのIPアドレスが求められます。最初のノードのIPアドレス(alice、192.168.1.1)を入力します。

  4. 両方のマシン間にパスワードなしのSSHアクセスを設定していない場合、既存のノードのrootパスワードが求められます。

    指定されたノードにログインした後、スクリプトはCorosync設定をコピーし、SSH、Csync2を設定して、新しいクラスタノードとしてご使用のマシンをオンラインにします。それとは別に、Hawk2に必要なサービスを開始します。

Hawk2でクラスタの状態を確認します。ステータス ›  ノード に、2つのノードが緑色の状態で表示されます(図2「2ノードクラスタの状態」を参照してください)。

2ノードクラスタの状態
図 2: 2ノードクラスタの状態
 

8 クラスタのテスト

 

8.1項 「リソースフェールオーバーのテスト」は、現在リソースを実行しているノードをstandbyに設定した場合に、クラスタによって仮想IPアドレスが他方のノードに移動されるかどうかを確認する簡単なテストです。

ただし、現実的なテストでは、スプリットブレイン状況を回避するフェンシングメカニズムのテストなど、特定のユースケースとシナリオが含まれます。フェンシングメカニズムを正しく設定していない場合、クラスタは正常に動作しません。

運用環境でクラスタを使用する前に、ユースケースに応じて、またはha-cluster-preflight-checkスクリプトを使用して、クラスタを十分にテストしてください。

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

 

簡単なテストとして、次の手順でリソースフェールオーバーを確認します。

手順 5: リソースフェールオーバーのテスト
 

  1. ターミナルを開き、使用している仮想IPアドレス192.168.2.1に対してpingを実行します。 

    root # ping 192.168.2.1

  2. 手順3「Hawk2 Webインタフェースへのログイン」の説明に従って、クラスタにログインします。

  3. Hawk2のステータス ›  リソース で、仮想IPアドレス(リソースadmin_addr)がどのノードで実行されているかを確認します。ここでは、リソースがaliceで実行されていることを想定しています。

  4. aliceをスタンバイモードにします(図3「スタンバイモードのノードalice」を参照してください)。

    スタンバイモードのノードalice
    図 3: スタンバイモードのノードalice
     

  5. ステータス › リソース の順にクリックします。リソースadmin_addrがbobに移行されています。

マイグレーション中は、仮想IPアドレスに対して連続してpingが実行されます。これは、クラスタセットアップと浮動IPが正常に機能していることを示します。Ctrl–Cを押してpingコマンドをキャンセルします。

8.2 ha-cluster-preflight-checkコマンドを使用したテスト

 

コマンドha-cluster-preflight-checkは、クラスタの標準化されたテストを実行します。クラスタ障害をトリガーし、設定を検証して問題を検出します。クラスタを運用環境で使用する前に、このコマンドを使用して、すべてが予期するように動作しているか確認することをお勧めします。

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

  • 環境チェック: -e/--env-check。.  このテストは次をチェックします。

    • ホスト名は解決できますか?

    • タイムサービスは有効になっていて、開始されていますか?

    • 現在のノードにはウォッチドッグが設定されていますか?

    • firewalldサービスが開始されていて、クラスタ関連のポートが開いていますか?

  • クラスタの状態チェック: -c/--cluster-check。.  クラスタのさまざまな状態とサービスをチェックします。このテストは次をチェックします。

    • クラスタサービス(Pacemaker/Corosync)が有効になっていて、実行されていますか?

    • STONITHが有効になっていますか? STONITH関連のリソースが設定されていて、開始されているかどうかもチェックします。SBDを設定している場合、SBDサービスは開始されていますか?

    • クラスタにはクォーラムがありますか? 現在のDCノードと、オンライン、オフライン、およびアンクリーンなノードを表示します。

    • 開始した、停止した、あるいは障害が発生しているリソースがありますか?

  • スプリットブレインチェック: --split-brain-iptables。.  Corosyncポートをブロックすることにより、スプリットブレインシナリオをシミュレートします。1つのノードが予期されるようにフェンシングできるかどうかをチェックします。

  • SBD、Corosync、およびPacemakerのデーモンを強制終了する: -kill-sbd/-kill-corosync/-kill-pacemakerd。.  このようなテストを実行した後で、レポートを/var/lib/ha-cluster-preflight-checkで見つけることができます。このレポートには、テストケースの説明、アクションのログ記録が含まれ、起こり得る結果が説明されています。

  • フェンスノードチェック: --fence-node。. コマンドラインから渡される特定のノードをフェンスします。

たとえば、環境をテストするには、次のコマンドを実行します。 

root # crm_mon -1
Stack: corosync
Current DC: alice (version ...) - partition with quorum
Last updated: Fri Mar 03 14:40:21 2020
Last change: Fri Mar 03 14:35:07 2020 by root via cibadmin on alice

2 nodes configured
1 resource configured

Online: [ alice bob ]
Active resources:

 stonith-sbd    (stonith:external/sbd): Started alice

root # ha-cluster-preflight-check -e
[2020/03/20 14:40:45]INFO: Checking hostname resolvable [Pass]
[2020/03/20 14:40:45]INFO: Checking time service [Fail]
 INFO: chronyd.service is available
 WARNING: chronyd.service is disabled
 WARNING: chronyd.service is not active
[2020/03/20 14:40:45]INFO: Checking watchdog [Pass]
[2020/03/20 14:40:45]INFO: Checking firewall [Fail]
 INFO: firewalld.service is available
 WARNING: firewalld.service is not active

/var/log/ha-cluster-preflight-check.logで結果を検査することができます。

9 詳細の参照先

 

本製品の他のマニュアルは、https://documentation.suse.com/sle-ha/で入手できます。設定および管理タスクの詳細については、包括的な『 管理ガイド』を参照してください。

10 法的規制の通知

 

Copyright © 2006–2023 SUSE LLC and contributors.All rights reserved.

この文書は、GNUフリー文書ライセンスのバージョン1.2または(オプションとして)バージョン1.3の条項に従って、複製、配布、および/または改変が許可されています。ただし、この著作権表示およびライセンスは変更せずに記載すること。ライセンスバージョン1.2のコピーは、「GNUフリー文書ライセンス」セクションに含まれています。

SUSEの商標については、http://www.suse.com/company/legal/を参照してください。その他の第三者のすべての商標は、各社の所有に帰属します。商標記号(®、 ™など)は、SUSEおよび関連会社の商標を示します。アスタリスク(*)は、第三者の商標を示します。

本書のすべての情報は、細心の注意を払って編集されています。しかし、このことは絶対に正確であることを保証するものではありません。SUSE LLC、その関係者、著者、翻訳者のいずれも誤りまたはその結果に対して一切責任を負いかねます。