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

インストールとセットアップクイックスタート

 
発行日: 2024 年 9 月 29 日

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

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

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

SUSEの商標については、https://www.suse.com/company/legal/を参照してください。サードパーティ各社とその製品の商標は、所有者であるそれぞれの会社に所属します。商標記号(®、™など)は、SUSEおよびその関連会社の商標を示します。アスタリスク(*)は、第三者の商標を示します。

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

1 使用シナリオ

 

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

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

  • 実行しているノードがどれであれ、クライアントからの該当サービスへの接続を可能にする浮動仮想IPアドレス(192.168.1.10)。このIPアドレスは、グラフィカル管理ツールHawk2への接続に使用します。

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

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

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

2 システム要件

 

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

2.1 ハードウェア要件

 
サーバ

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

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

通信チャネル

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

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

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

ノードフェンシング/STONITH

スプリットブレインシナリオを回避するためのノードフェンシング(STONITH)デバイス。これは、物理デバイス(電源スイッチ)でも、SBD (ディスクによるSTONITH)のようなメカニズムとウォッチドッグを組み合わせたものでも構いません。SBDは、共有ストレージまたはディスクレスモードのいずれかで使用できます。このドキュメントでは、SBDを共有ストレージで使用する方法について説明します。次の要件を満たす必要があります。

  • 共有ストレージデバイス。共有ストレージの設定については、Storage Administration Guide for SUSE Linux Enterprise Serverを参照してください。テスト目的で基本的な共有ストレージのみが必要な場合は、付録A SBDの基本的なiSCSIストレージを参照してください。

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

  • SBDデバイスが、ホストベースのRAID、LVM、またはDRBD*を使用してはいけません。

STONITHの詳細については、第12章 「フェンシングとSTONITH」を参照してください。SBDの詳細については、第13章 「ストレージ保護とSBD」を参照してください。

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

 

すべてのノードは、少なくとも次のモジュールおよび拡張機能が必要です。

  • Basesystem Module 15 SP6

  • Server Applications Module 15 SP6

  • SUSE Linux Enterprise High Availability 15 SP6

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

 
時刻同期

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

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

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

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

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

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

SSH

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

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

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

 

次のコマンドは、最低限の時間と手動操作しか必要のないブートストラップスクリプトを実行します。

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

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

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

ブートストラップスクリプトによって設定されるオプションは、Pacemakerのデフォルト設定と同じではない場合があります。ブートストラップスクリプトが変更した設定は/var/log/crmsh/crmsh.logで確認できます。ブートストラッププロセス中に設定されたオプションは、YaSTクラスタモジュールで後で変更できます。詳細については第4章 「YaSTクラスタモジュールの使用」を参照してください。

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

NTP

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

SSH

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

Csync2

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

Corosync

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

SBD/ウォッチドッグ

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

仮想浮動IP

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

ファイアウォール

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

クラスタ名

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

QDevice/QNetd

QDevice/QNetdを設定してクォーラムの決定に参加するかどうか確認メッセージを表示します。ノード数が偶数であるクラスタ、特に2ノードクラスタについては、QDeviceおよびQNetdの使用をお勧めします。

この設定についてはここでは説明しませんが、第14章 「QDeviceおよびQNetd」で説明されているように後で設定できます。

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

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

4 High Availabilityパッケージのインストール

 

クラスタを設定および管理するためのパッケージは、High Availabilityインストールパターンに含まれています。このパターンは、SUSE Linux Enterprise High Availabilityのインストール後にのみ使用できます。

SUSE Customer Centerに登録して、SUSE Linux Enterprise Serverのインストール中またはインストール後にSUSE Linux Enterprise High Availabilityをインストールできます。SUSE Linux Enterprise Serverの詳細については、Deployment Guideを参照してください。

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

  1. コマンドラインからHigh Availabilityパターンをインストールします。

    # zypper install -t pattern ha_sles

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

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

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

5 ノードフェンシングにSBDを使用する

 

ブートストラップスクリプトでSBDを設定する前に、各ノードでウォッチドッグを有効にする必要があります。SUSE Linux Enterprise Serverには、ハードウェア固有のウォッチドッグドライバを提供する、いくつかのカーネルモジュールが付属しています。SUSE Linux Enterprise High Availabilityはウォッチドッグに「フィード」するソフトウェアコンポーネントとしてSBDデーモンを使用します。

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

重要
重要: softdogの制限

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

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

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

手順 2: SBDのsoftdogウォッチドッグの有効化
 

  1. 各ノードで、softdogウォッチドッグを有効にします。 

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

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

    # lsmod | grep dog
softdog           16384  1

6 最初のノードの設定

 

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

手順 3: aliceを使用して最初のノード(crm cluster init)を設定する
 

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

    重要
    重要: SSHキーアクセス

    クラスタは、ノード間の通信にパスワードなしのSSHアクセスを使用します。crm cluster initスクリプトは、SSHキーがあるかどうかを確認し、ない場合には生成します。

    ほとんどの場合、rootユーザのSSHキーまたはsudoユーザのSSHキーがノードに存在している(または生成されている)必要があります。

    または、sudoユーザのSSHキーがローカルマシンにあり、SSHエージェントの転送によってノードに渡すことができます。このためには、この最小セットアップでは説明していない追加の設定が必要です。詳細については、5.5.1項 「ログイン」を参照してください。

  2. ブートストラップスクリプトを起動します。 

    # crm cluster init --name CLUSTERNAME

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

    クラスタ通信にユニキャスト(デフォルト)の代わりにマルチキャストを使用する必要がある場合は、オプション--multicast (または-U)を使用します。

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

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

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

    2. 提案されたポート(5405)を受け入れるか、別のポートを入力します。

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

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

    2. SBDに使用するブロックデバイスのパーティションの永続的なパスを入力します。パスはクラスタ内のすべてのノード全体で一致している必要があります。

      このスクリプトは、SBDに使用するデバイスに小さなパーティションを作成します。

  5. Hawk2でクラスタを管理するための仮想IPアドレスを設定します。

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

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

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

  6. QDeviceおよびQNetdを設定するかどうかを選択します。このドキュメントで説明されている最小限のセットアップについては、今のところnで拒否してください。第14章 「QDeviceおよびQNetd」で説明しているように、QDeviceおよびQNetdは後で設定できます。

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

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

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

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

  2. URLとして、ブートストラップスクリプトで設定した仮想IPアドレスを入力します。

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

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

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

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

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

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

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

    # passwd hacluster

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

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

7 2つ目のノードの追加

 

crm cluster joinブートストラップスクリプトを使用して、クラスタに2つ目のノードを追加します。スクリプトは既存のクラスタノードへのアクセスのみが必要で、ご使用のマシンで自動的に基本セットアップを完了します。

詳細については、crm cluster join --helpコマンドを参照してください。

手順 5: bobを使用して2つ目のノード(crm cluster join)を追加する
 

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

  2. ブートストラップスクリプトを起動します。

    最初のノードをrootとして設定する場合は、追加のパラメータなしで次のコマンドを実行できます。 

    # crm cluster join

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

    > sudo crm cluster join -c USER@alice

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

  3. -cでまだaliceを指定していない場合は、最初のノードのIPアドレスが求められます。

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

    指定したノードへのログイン後、スクリプトは、Corosync設定をコピーし、SSHおよびCsync2を設定し、現在のマシンを新しいクラスタノードとしてオンラインにし、Hawk2に必要なサービスを起動します。

Hawk2でクラスタの状態を確認します。状態 › ノードに、2つのノードが緑色の状態で表示されます。

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

8 クラスタのテスト

 

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

  • sbd -d DEVICE_NAME listコマンドは、SBDに表示されるすべてのノードを一覧表示します。このドキュメントで説明されているセットアップでは、出力結果は、aliceとbobの両方を示すはずです。

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

  • 8.2項 「crm cluster crash_testコマンドを使用したテスト」は、クラスタの障害をシミュレートし、結果を報告します。

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

 

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

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

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

    # ping 192.168.1.10

  2. Hawk2にログインします。

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

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

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

  5. ステータス › リソース の順にクリックします。リソースadmin_addrはbobにマイグレートされました。

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

8.2 crm cluster crash_testコマンドを使用したテスト

 

crm cluster crash_testコマンドは、クラスタの障害をトリガして問題を見つけます。クラスタを運用環境で使用する前に、このコマンドを使用して、すべてが予期するように動作しているか確認することをお勧めします。

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

--split-brain-iptables

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

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

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

--fence-node NODE

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

詳細については、crm cluster crash_test --helpを参照してください。

例 1: クラスタのテスト: ノードフェンシング
 
# 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

# crm cluster crash_test --fence-node bob

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

!!! 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 60s for node "bob" reboot...
INFO: Node "bob" will be fenced by "alice"!
INFO: Node "bob" was successfully fenced by "alice"

テスト中のbobの変更ステータスを表示するには、Hawk2にログインし、状態 › ノードに移動します。

9 次のステップ

 

ブートストラップスクリプトを使用すると、テスト目的で使用可能な基本的な高可用性クラスタを迅速に設定できます。ただし、このクラスタを、運用環境で使用可能な機能する高可用性クラスタに拡張するには、さらなるステップを実行することをお勧めします。

高可用性クラスタのセットアップを完了するための推奨されるステップ
 
ノードの追加

次のいずれかの方法を使用して、クラスタにノードを追加します。

通常のクラスタには最大32ノードを含めることができます。pacemaker_remoteサービスを使用すると、高可用性クラスタを拡張して、この制限を超えて追加のノードを含めることができます。詳しく詳細については「Pacemaker Remote Quick Start」を参照してください。

QDeviceの設定

クラスタのノード数が偶数の場合、QDeviceおよびQNetdを設定し、クォーラムの決定に参加します。QDeviceは設定可能な投票数を提供するため、クラスタは標準のクォーラムルールで許可されているよりも多くのノード障害に耐えることができます。詳細については、第14章 「QDeviceおよびQNetd」を参照してください。

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

運用環境でクラスタを使用する前に、softdogモジュールを、ご使用のハードウェアに最適なハードウェアモジュールに置き換えてください。詳細については、13.6項 「ウォッチドッグのセットアップ」を参照してください。

10 詳細の参照先

 

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