インストールおよびセットアップクイックスタート #
このマニュアルでは、crmシェルで提供されているブートストラップスクリプトを使用して、非常に基本的な2ノードクラスタをセットアップする手順を説明します。仮想IPアドレスをクラスタリソースとして設定する手順や、共有ストレージ上でSBDをノードフェンシングメカニズムとして使用する手順も記載されています。
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 SP4
Server Applications Module 15 SP4
SUSE Linux Enterprise High Availability Extension 15 SP4
2.3 その他の要件と推奨事項 #
- 時刻同期
クラスタノードはクラスタ外のNTPサーバに同期する必要があります。SUSE Linux Enterprise High Availability Extension 15以降、Chronyは、NTPでデフォルトで実装されるようになりました。詳細については、SUSE Linux Enterprise Server 15 SP4の『管理ガイド』を参照してください。
ノードが同期されていない場合、クラスタが正常に動作しないことがあります。また、同期が行われていないと、ログファイルとクラスタレポートの分析が非常に困難になります。ブートストラップスクリプトを使用するときにNTPがまだ設定されていない場合、警告が表示されます。
- ホスト名およびIPアドレス
静的IPアドレスを使用します。
/etc/hosts
ファイルにあるすべてのクラスタノードを、完全修飾ホスト名およびショートホスト名で一覧表示します。クラスタのメンバーが名前で互いを見つけられることが重要です。名前を使用できない場合、内部クラスタ通信は失敗します。
- SSH
すべてのクラスタノードはSSHによって互いにアクセスできる必要があります。
crm report
(トラブルシューティング用)などのツールおよびHawk2の は、ノード間でパスワード不要のSSHアクセスを必要とします。それがない場合、現在のノードからしかデータを収集できません。クラスタのセットアップにブートストラップスクリプトを使用した場合、SSHキーは自動的に作成されてコピーされます。
3 ブートストラップスクリプトの概要 #
次のコマンドは、最低限の時間と手動介入しか必要のないブートストラップスクリプトを実行します。
crm cluster init
を使用して、クラスタ通信に必要な基本パラメータを定義します。これによって1ノードクラスタの実行が可能になります。crm cluster join
を使用して、クラスタにノードを追加します。crm cluster remove
を使用して、クラスタからノードを削除します。
すべてのブートストラップスクリプトは/var/log/crmsh/crmsh.log
にログを記録します。ブートストラッププロセスの詳細については、このファイルを確認してください。ブートストラッププロセス中に設定されたオプションは、YaSTクラスタモジュールで後で変更できます。詳細については第4章 「YaSTクラスタモジュールの使用」を参照してください。
ブートストラップスクリプトcrm 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 SP4の『導入ガイド』を参照してください。
High Availability
パターンのインストール #このパターンがまだインストールされていない場合は、次の手順に従います。
次のように、Zypperを使用してコマンドラインでインストールします。
root #
zypper
install -t pattern ha_slesクラスタの一部になるすべてのマシンにHigh Availabilityパターンをインストールします。
注記: すべてのパーティへのソフトウェアパッケージのインストールSUSE Linux Enterprise Server 15 SP4およびSUSE Linux Enterprise High Availability Extension 15 SP4を自動インストールする場合は、AutoYaSTを使用して既存のノードのクローンを作成します。AutoYaSTを使用して既存のノードをクローンします。詳細については、3.2項 「AutoYaSTによる大量インストールと展開」を参照してください。
SUSEカスタマセンターにマシンを登録します。詳細については、SUSE Linux Enterprise Server 15 SP4の『アップグレードガイド』を参照してください。
5 フェンシングメカニズムとしてのSBDの使用 #
SAN (ストレージエリアネットワーク)などの共有ストレージが存在する場合、それらのストレージを使用してスプリットブレインシナリオを回避できます。そのためには、SBDをノードのフェンシングメカニズムとして設定します。SBDは、ウォッチドッグサポートとexternal/sbd
STONITHリソースエージェントを使用します。
5.1 SBDの要件 #
crm cluster init
で最初のノードをセットアップする際に、SBDを使用するかどうかを決定できます。使用する場合、共有ストレージデバイスのパスを入力する必要があります。デフォルトで、crm cluster init
は、SBDに使用するデバイス上に自動的に小容量のパーティションを作成します。
SBDを使用するには、次の要件を満たしている必要があります。
共有ストレージデバイスのパスが永続的で、クラスタ内のすべてのノードで一致している必要があります。
/dev/disk/by-id/dm-uuid-part1-mpath-abcedf12345
などの固定デバイス名を使用してください。SBDデバイスでホストベースのRAIDやLVM2を使用したり、SBDデバイスをDRBD*インスタンス上に存在させることは「できません」。
共有ストレージの設定方法の詳細については、SUSE Linux Enterprise Server 15 SP4の『Storage Administration Guide』を参照してください。
5.2 SBDのsoftdogウォッチドッグの有効化 #
SUSE Linux Enterprise Serverでは、カーネル内のウォッチドッグサポートはデフォルトで有効化されています。これは、ハードウェア固有のウォッチドッグドライバを提供する、さまざまなカーネルモジュールを標準装備しています。High Availability Extensionはウォッチドッグに「フィード」するソフトウェアコンポーネントとしてSBDデーモンを使用します。
次の手順では、softdog
ウォッチドッグを使用します。
softdogドライバはCPUが最低1つは動作中であることを前提とします。すべてのCPUが固まっている場合、システムを再起動させるsoftdogドライバのコードは実行されません。これに対して、ハードウェアウォッチドッグはすべてのCPUが固まっていても動作し続けます。
運用環境でクラスタを使用する前に、softdog
モジュールを、ご使用のハードウェアに最適なハードウェアモジュールに置き換えることを強くお勧めします。
ただし、ハードウェアに適合するウォッチドッグがない場合、カーネルウォッチドッグモジュールとしてsoftdog
を使用することができます。
5.1項 「SBDの要件」の説明に従って、永続的な共有ストレージを作成します。
softdogウォッチドッグを有効にします。
root #
echo
softdog > /etc/modules-load.d/watchdog.confroot #
systemctl
restart systemd-modules-loadsoftdogモジュールが正しくロードされているかどうかをテストします。
root #
lsmod
| grep dog softdog 16384 1
スプリットシナリオを避けるために、SBDフェンシングメカニズムが正常に機能しているかどうかをテストすることを強くお勧めします。このテストを実行するには、Corosyncクラスタ通信をブロックします。
6 最初のノードの設定 #
crm cluster init
スクリプトで最初のノードを設定します。ここでは最小限の時間と手動介入しか必要ありません。
crm cluster init
を使用して最初のノード(alice
)を設定する #クラスタノードとして使用する物理または仮想マシンに
root
としてログインします。実行によって、ブートストラップスクリプトを開始します。
root #
crm cluster init
--name CLUSTERNAMECLUSTERNAMEプレースホルダを、クラスタの地理的な場所のような、意味のある名前で置き換えます(たとえば、
amsterdam
)。これによってサイトを識別しやすくなるため、後でGeoクラスタを作成する場合に特に役立ちます。クラスタ通信にユニキャスト(デフォルト)の代わりにマルチキャストが必要な場合は、オプション
--multicast
(または-U
)を使用します。このスクリプトは、NTP設定とハードウェアウォッチドッグサービスを確認します。また、SSHアクセスとCsync2の同期に使用される公開および秘密SSHキーが生成され、それぞれのサービスが起動されます。
クラスタ通信層(Corosync)を設定します。
バインドするネットワークアドレスを入力します。デフォルトでは、スクリプトは
eth0
のネットワークアドレスを提案します。または、たとえばbond0
のアドレスなど、別のネットワークアドレスを入力します。提案されたポート(
5405
)を受け入れるか、別のポートを入力します。
SBDをノードフェンシングメカニズムとして設定します。
<
y
>キーを押して、SBDを使用することを確認します。SBDに使用するブロックデバイスのパーティションの永続的なパスを入力します。5項 「フェンシングメカニズムとしてのSBDの使用」を参照してください。パスはクラスタ内のすべてのノード全体で一致している必要があります。
Hawk2でクラスタを管理するための仮想IPアドレスを設定します(この仮想IPリソースは、後でフェールオーバーが正常に実行されるかどうかをテストするために使用します)。
<
y
>キーを押して、仮想IPアドレスを設定することを確認します。Hawk2の管理IPとして使用する、未使用のIPアドレス(
192.168.2.1
)を入力します。Hawk2で個々のクラスタノードにログインする代わりに、その仮想IPアドレスに接続できるようになります。
最後に、スクリプトはPacemakerサービスを開始し、クラスタをオンラインにして、Hawk2を有効にします。Hawk2に使用するURLが画面に表示されます。
1ノードクラスタが実行するようになります。状態を表示するには、次の手順に従います。
任意のコンピュータで、Webブラウザを起動し、JavaScriptとクッキーが有効なことを確認します。
URLとして、Hawk Webサービスを実行するクラスタノードのIPアドレスまたはホスト名を入力します。または、手順2「
crm cluster init
を使用して最初のノード(alice
)を設定する」のステップ 5で設定した仮想IPアドレスのアドレスを入力します。https://HAWKSERVER:7630/
注記: 証明書の警告初めてURLにアクセスしようとするときに証明書の警告が表示される場合は、自己署名証明書が使用されています。自己署名証明書は、デフォルトでは信頼されません。
証明書を検証するための詳細情報については、クラスタのオペレータに問い合わせてください。
続行するには、ブラウザに例外を追加して警告をバイパスします。
Hawk2のログイン画面で、ブートストラップ手順で作成されたユーザの
と を入力します(ユーザhacluster
、パスワードlinux
)。重要: セキュリティ保護されたパスワードデフォルトのパスワードはできるだけ早くセキュリティ保護されたパスワードに変更します。
root #
passwd
hacluster- 図 1: Hawk2の1ノードクラスタの状態 #
7 2つ目のノードの追加 #
1ノードクラスタが正常に稼働している場合、手順 4に従って、crm cluster join
ブートストラップスクリプトを使用して2つ目のクラスタノードを追加します。スクリプトは既存のクラスタノードへのアクセスのみが必要で、ご使用のマシンで自動的に基本セットアップを完了します。詳細については、crm cluster join
のマニュアルページを参照してください。
ブートストラップスクリプトは、SBDやCorosyncなど、2ノードクラスタに固有な設定を変更します。ブートストラップスクリプトは、SBDやCorosyncなど、2ノードクラスタに固有な設定を変更するために使用します。
crm cluster join
を使用して2つ目のノード(bob
)を追加する #クラスタを参加させることになる物理または仮想マシンに
root
としてログインします。実行によって、ブートストラップスクリプトを開始します。
root #
crm cluster join
NTPがブート時に開始するよう設定されていない場合、メッセージが表示されます。このスクリプトは、ハードウェアウォッチドッグデバイスも確認します(SBDを設定する場合は重要です)。デバイスがないときは警告が表示されます。
それでも継続を選択する場合、既存のノードのIPアドレスが求められます。最初のノードのIPアドレスを入力します(
alice
、192.168.1.1
)。両方のマシン間にパスワードなしのSSHアクセスを設定していない場合、既存のノードの
root
パスワードが求められます。指定されたノードにログインした後、スクリプトはCorosync設定をコピーし、SSH、Csync2を設定して、新しいクラスタノードとしてご使用のマシンをオンラインにします。それとは別に、Hawk2に必要なサービスを開始します。
Hawk2でクラスタの状態を確認します。図2「2ノードクラスタの状態」を参照してください)。
› に、2つのノードが緑色の状態で表示されます(8 クラスタのテスト #
8.1項 「リソースフェールオーバーのテスト」は、現在リソースを実行しているノードをstandby
に設定した場合に、クラスタによって仮想IPアドレスが他方のノードに移動されるかどうかを確認する簡単なテストです。
ただし、現実的なテストでは、スプリットブレイン状況を回避するフェンシングメカニズムのテストなど、特定のユースケースとシナリオが含まれます。フェンシングメカニズムを正しく設定していない場合、クラスタは正常に動作しません。
運用環境でクラスタを使用する前に、ユースケースに応じて、またはha-cluster-preflight-check
スクリプトを使用して、クラスタを十分にテストしてください。
8.1 リソースフェールオーバーのテスト #
簡単なテストとして、次の手順でリソースフェールオーバーを確認します。
ターミナルを開き、使用している仮想IPアドレス
192.168.2.1
に対してpingを実行します。root #
ping
192.168.2.1手順3「Hawk2 Webインタフェースへのログイン」の説明に従って、クラスタにログインします。
Hawk2の
› で、仮想IPアドレス(リソースadmin_addr
)がどのノードで実行されているかを確認します。ここでは、リソースがalice
で実行されていることを想定しています。alice
を モードにします(図3「スタンバイモードのノードalice
」を参照してください)。図 3: スタンバイモードのノードalice
#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 aliceroot #
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– 2024 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、その関係者、著者、翻訳者のいずれも誤りまたはその結果に対して一切責任を負いかねます。