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

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

   スクリプトは、オプションを指定しなくても起動できます。この場合、特定の設定については入力を求められ、他の設定についてはcrmshのデフォルト値が使用されます。

   • rootとしてログインした場合は、追加のパラメータなしで次のコマンドを実行できます。

     # crm cluster init

   • SSHエージェント転送を使用せずにsudoユーザとしてログインした場合は、sudoを使用して次のコマンドを実行します。

     > sudo crm cluster init

   • SSHエージェント転送が有効になっている状態でsudoユーザとしてログインした場合は、環境変数SSH_AUTH_SOCKを保持し、ノードでキーを生成するのではなくローカルSSHキーを使用するようにスクリプトに指示する必要があります。

     > sudo --preserve-env=SSH_AUTH_SOCK crm cluster init --use-ssh-agent

   または、追加のオプションを初期化コマンドの一部として指定することもできます。同じコマンドに複数のオプションを含めることができます。いくつかの例を以下に示します。その他のオプションについては、crm cluster init --helpを実行してください。

   クラスタ名

   デフォルトのクラスタ名はhaclusterです。別の名前を選択するには、オプション--name (または-n)を使用します。次に例を示します。

   # crm cluster init --name CLUSTERNAME

   クラスタの地理的な場所など、わかりやすい名前を選択します。これによってサイトを識別しやすくなるため、後でGeoクラスタを作成する場合に特に役立ちます。

   マルチキャスト

   ユニキャストは、クラスタ通信のデフォルトのトランスポートタイプです。代わりにマルチキャストを使用するには、オプション--multicast (または-U)を使用します。次に例を示します。

   # crm cluster init --multicast

   SBDディスク

   後の手順で、スクリプトにより、SBDを設定するかどうかを尋ねられ、使用するディスクを指定するように求められます。複数のSBDディスクを使用してクラスタを設定するには、オプション--sbd-device (または-s) を複数回使用します。次に例を示します。

   # crm cluster init -s /dev/disk/by-id/ID1 -s /dev/disk/by-id/ID2

   このオプションは、タブ補完を使用してデバイスIDを入力できるという点でも便利です。タブ補完は、スクリプトによってパスの入力を求められたときには使用できません。

   冗長通信チャンネル

   サポートされるクラスタには、通信チャンネルが2つ必要です。推奨される方法は、ネットワークデバイスボンディングを使用することです。ボンディングを使用できない場合は、Corosyncで冗長通信チャンネル(第2リングまたはハートビート回線とも呼ばれます)を設定できます。デフォルトでは、1つのリングのネットワークアドレスの入力を求められます。クラスタを2つのリングで設定するには、オプション--interface (または-i)を2回使用します。次に例を示します。

   # crm cluster init -i eth0 -i eth1

   スクリプトを開始すると、次の情報の入力を求められます。initコマンドに追加のオプションを含めた場合、以下の手順の一部は多少異なる場合があります。

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

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

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

   3. 冗長通信チャンネルを設定するオプションを指定してスクリプトを開始した場合は、「y」と入力して2番目のハートビートラインを受け入れてから、提案されたネットワークアドレスとポートを受け入れるか、別のアドレスとポートを入力します。

4. SBDをノードフェンシングメカニズムとして設定するかどうかを選択します。別のフェンシングメカニズムを使用している場合、または後でSBDを設定する場合は、「n」と入力して、この手順をスキップします。

   yを選択した場合は、使用するSBDのタイプを選択します。

   • ディスクレスSBDを使用するには、「none」と入力します。

   • ディスクベースのSBDを使用するには、使用するブロックデバイスのパーティションの永続的なパスを入力します。パスはクラスタ内のすべてのノード全体で一致している必要があります。例: /dev/disk/by-id/ID。

5. Hawk2でのクラスタ管理用の仮想IPアドレスを設定するかどうかを選択します。Hawk2で個々のクラスタノードにログインする代わりに、その仮想IPアドレスに接続できるようになります。

   yを選択した場合、Hawk2に使用する未使用のIPアドレスを入力します。

6. QDeviceおよびQNetdを設定するかどうかを選択します。QDeviceを使用する必要がない場合、またはQNetdサーバをまだ設定していない場合は、「n」と入力して、この手順をスキップします。QDeviceおよびQNetdは後で必要に応じて設定できます。

   yを選択した場合、次の情報を入力します。

   1. QNetdサーバのホスト名またはIPアドレスを入力します。設定を完了するには、クラスタノードがこのサーバにSSHでアクセスできる必要があります。

      残りのフィールドについては、デフォルト値を受け入れるか、必要に応じて変更できます。

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

   3. 投票の割り当て方法を決定するアルゴリズムを選択します。

   4. タイブレーカが必要な場合に使用する方法を選択します。

   5. TLSを有効にするかどうかを選択します。

   6. 投票の決定方法に影響を与えるヒューリスティックスコマンドを入力します。この手順をスキップするには、フィールドを空白のままにします。

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

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

   スクリプトの開始方法は、最初のノードの設定方法によって異なります。次のオプションを確認し、最初のノードの設定に一致するコマンドを使用します。必要に応じて、同じコマンドに複数のオプションを含めることができます。

   • 最初のノードをrootとして、1つのネットワークインタフェース(またはボンドデバイス)のだけで設定した場合、追加のパラメータなしで次のコマンドを実行できます。

     # crm cluster join

   • 最初のノードを2つのネットワークインタフェースで設定した場合は、オプション--interface (または-i)を2回使用して、このノードに同じインタフェースを指定する必要があります。

     # crm cluster join -i eth0 -i eth1

   • 必要に応じて、--cluster-node (または-c)を使用して最初のノードを指定できます。

     # crm cluster join -c [USER]@NODE1

     最初のノードをrootとして設定した場合は、ユーザを指定する必要はありません。

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

     > sudo crm cluster join -c USER@NODE1

   • 最初のノードをSSHエージェント転送を使用してsudoユーザとして設定した場合は、ノードでキーを生成するのではなくローカルSSHキーを使用するようにスクリプトに指示する必要があります。

     > sudo --preserve-env=SSH_AUTH_SOCK \
     crm cluster join --use-ssh-agent -c USER@NODE1

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

3. まだ-cオプションを使用して最初のクラスタノードを指定していない場合は、そのIPアドレスの入力を求められます。

4. クラスタノード間にパスワード不要のSSHアクセスをまだ設定していない場合、最初のノードのパスワードの入力を求められます。

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

マルチキャストを使用する場合、すべてのクラスタノードに同じbindnetaddr、mcastaddr、およびmcastportが使用されます。クラスタ内のすべてのノードは同じマルチキャストアドレスを使用することで互いを認識します。別のクラスタは、別のマルチキャストアドレスを使用します。

1. 既存のクラスタを変更する場合は、通信チャンネルカテゴリに切り替えます。

   初期セットアップウィザードに従っている場合は、カテゴリを手動で切り替える必要はありません。

2. トランスポートプロトコルをMulticastに設定します。

3. バインドネットワークアドレスを定義します。クラスタマルチキャストに使用するサブネットに値を設定します。

4. マルチキャストアドレスを定義します。

5. ポートを定義します。

6. クラスタノードごとに一意のIDを自動的に生成するには、ノードIDの自動生成を有効にしたままにします。

7. クラスタ名を定義します。

8. 期待する得票数の数を入力します。これは、パーティションされたクラスタでCorosyncがクォーラムを計算する場合に重要です。デフォルトでは、各ノードには1票が割り当てられています。期待する得票数の数は、クラスタ内のノード数と一致する必要があります。

9. Corosyncで冗長な通信チャンネルを定義する必要がある場合は、手順7.3「冗長通信チャネルの定義」に進みます。

   それ以外の場合は、次へ(セットアップウィザード)または完了(既存のクラスタ)をクリックして変更を確認します。

1. 既存のクラスタを変更する場合は、通信チャンネルカテゴリに切り替えます。

   初期セットアップウィザードに従っている場合は、カテゴリを手動で切り替える必要はありません。

2. トランスポートプロトコルをUnicastに設定します。

3. ポートを定義します。

4. ユニキャスト通信では、Corosyncはクラスタ内のすべてのノードのIPアドレスを認識する必要があります。各ノードで、追加を選択し、次の詳細情報を入力します。

   • IP Address

   • 冗長IPアドレス(Corosyncで2つ目の通信チャンネルを使用する場合にのみ必要)

   • ノードID (ノードIDの自動生成オプションが無効になっている場合にのみ必要)

   クラスタメンバーのアドレスを変更または削除するには、編集または削除ボタンを使用します。

5. すべてのクラスタノードに対して一意のIDを自動的に生成するには、ノードIDの自動生成を有効にしたままにします。

6. クラスタ名を定義します。

7. 期待する得票数の数を入力します。これは、パーティションされたクラスタでCorosyncがクォーラムを計算する場合に重要です。デフォルトでは、各ノードには1票が割り当てられています。期待する得票数の数は、クラスタ内のノード数と一致する必要があります。

8. Corosyncで冗長な通信チャンネルを定義する必要がある場合は、手順7.3「冗長通信チャネルの定義」に進みます。

   それ以外の場合は、次へ(セットアップウィザード)または完了(既存のクラスタ)をクリックして変更を確認します。

ネットワークデバイスボンディングが何らかの理由で使用できない場合、第2の選択は、Corosyncに冗長通信チャネル(2つ目のリング)を定義することです。この方法では、2つの物理的に分かれたネットワークが通信に使用できます。1つのネットワークが失敗しても、クラスタノードは、もう一方のネットワークを介して通信できます。

Corosync内の追加の通信チャネルは2つ目のトークンパスリングを形成します。設定した最初のチャンネルはプライマリリングで、リング番号0を取得します。2つ目のリング(冗長チャネル)はリング番号1を取得します。

重要: 冗長リングおよび/etc/hosts

Corosync内で複数のリングが設定されている場合、各ノードが複数のIPアドレスを持つことができます。これはすべてのノードの/etc/hostsに反映する必要があります。

1. 最初のチャンネルを手順7.1「最初の通信チャネルの定義(マルチキャスト)」または手順7.2「最初の通信チャネルの定義(ユニキャスト)」の説明に従って設定します。

2. 冗長チャンネルを有効にします。冗長チャネルは、定義した最初の通信チャネルと同じプロトコルを使用する必要があります。

3. マルチキャストを使用する場合は冗長チャンネル用に次のパラメータを入力します: 使用するバインドネットワークアドレス、マルチキャストアドレス、およびポート。

   ユニキャストを使用する場合は次のパラメータを定義します: 使用するバインドネットワークアドレス、およびポート。メンバーアドレスの下で、各エントリを 編集して 、クラスタの一部となる各ノードの冗長IPを追加します。

4. Corosyncに、異なるチャンネルを使用する方法とタイミングを伝えるには、使用するrrp_modeを選択します。

   • 通信チャンネルが1つだけ定義されている場合、rrp-modeは自動的に無効化されます(値none)。

   • activeに設定した場合、Corosyncは両方のインタフェースをアクティブに使用します。ただし、このモードは非推奨の機能です。

   • passiveに設定した場合、Corosyncは代わりに使用可能なネットワークを介してメッセージを送信します。

   RRPの使用時に、SUSE Linux Enterprise High Availabilityは現在のリングの状態を監視し、障害発生後に冗長リングを自動的に再度有効化します。

   または、corosync-cfgtoolを使用してリングの状態を手動で確認します。使用可能なオプションは-hで参照できます。

5. 次へ(セットアップウィザード)または完了(既存のクラスタ)をクリックして変更を確認します。

1. 既存のクラスタを変更する場合は、Corosync QDeviceカテゴリに切り替えます。

   初期セットアップウィザードに従っている場合は、カテゴリを手動で切り替える必要はありません。

2. Corosync QDeviceの有効化をアクティブにします。

3. QNetdサーバホストフィールドに、QNetdサーバのIPアドレスまたはホスト名を入力します。

4. TLSのモードを選択します。

   • TLSが必須ではなく、試行する必要がない場合は、オフを使用します。

   • オンを使用すると、TLSでの接続を試みますが、TLSが利用できない場合はTLSなしで接続します。

   • TLSを必須にするには、必須を使用します。TLSが利用できない場合、QDeviceはエラーで終了します。

5. アルゴリズムとタイブレーカでは、デフォルト値を受け入れます。これらの値を変更する必要がある場合は、クラスタの設定が完了した後に、コマンドcrm cluster init qdeviceを使用して変更できます。

6. ヒューリスティックスモードを選択します。

   • ヒューリスティックスを無効にするには、オフを使用します。

   • ヒューリスティックスをヒューリスティックス間隔で設定した間隔で定期的に実行するには、オンを使用します。

   • 起動時、クラスタメンバーシップの変更時、およびQNetdへの接続時にのみヒューリスティックスを実行するには、同期を使用します。

7. ヒューリスティックスモードをオンまたは同期に設定する場合は、ヒューリスティックコマンドをヒューリスティックス実行リストに追加します。

   1. 追加を選択します。新しいウィンドウが開きます。

   2. コマンドの実行名を入力します。

   3. 実行スクリプトフィールドにコマンドを入力します。単一のコマンドまたはスクリプトへのパスを入力でき、Shell、Python、Rubyなどの任意の言語で記述できます。

   4. OKを選択して、ウィンドウを閉じます。

8. 次へ(セットアップウィザード)または完了(既存のクラスタ)をクリックして変更を確認します。

1. 既存のクラスタを変更する場合は、セキュリティカテゴリに切り替えます。

   初期セットアップウィザードに従っている場合は、カテゴリを手動で切り替える必要はありません。

2. セキュリティ認証を有効にするをアクティブ化します。

3. 新しく作成したクラスタの場合は、認証鍵ファイルの生成を選択します。認証キーが作成され、/etc/corosync/authkeyに書き込まれます。

   ご使用のマシンを既存のクラスタに参加させたい場合、新しいキーファイルは生成しないでください。代わりに、いずれかのノードから/etc/corosync/authkeyを(手動またはCsync2によって)ご使用のマシンにコピーします。

4. 次へ(セットアップウィザード)または完了(既存のクラスタ)をクリックして変更を確認します。YaSTが設定を/etc/corosync/corosync.confに書き込みます。

1. 既存のクラスタを変更する場合は、Csync2の設定カテゴリに切り替えます。

   初期セットアップウィザードに従っている場合は、カテゴリを手動で切り替える必要はありません。

2. 同期グループを指定するには、同期ホストグループで追加を選択し、クラスタ内のすべてのノードのローカルホスト名を入力します。ノードごとに、hostnameコマンドから返された文字列を正確に使用する必要があります。

   

   ヒント: ホスト名解決

   ホスト名解決がネットワークで正しく機能しない場合は、各クラスタノードのホスト名とIPアドレスの組み合わせを指定することもできます。この指定には、HOSTNAME@IP文字列(たとえば、alice@192.168.2.100)を使用します。Csync2は、接続時にIPアドレスを使用します。

3. 事前共有鍵の生成を選択して、同期グループのキーファイルを生成します。キーファイルは、/etc/csync2/key_hagroupに書き込まれます。

4. すべてのノード間で、通常、同期される必要のあるファイルを同期ファイルリストに入れるには、推奨されるファイルの追加を選択します。

5. 同期するファイルのリストからファイルを編集、追加、または削除するには、該当する各ボタンを使用します。ファイルごとに絶対パス名を入力する必要があります。

6. Csync2を有効にするを選択して、Csync2をアクティブ化します。これにより、ブート時にCsync2 が自動的に起動するようになります。

7. 次へ(セットアップウィザード)または完了(既存のクラスタ)をクリックして変更を確認します。YaSTがCsync2の設定内容を/etc/csync2/csync2.cfgに書き込みます。

YaSTクラスタモジュールを使用して、ユーザスペースconntrackdを設定します(図7.6「YaSTクラスタ - conntrackd」を参照してください)。これには、その他の通信チャネルに使用されていない専用のネットワークインタフェースが必要です。デーモンは後でリソースエージェントによって起動できます。

1. 既存のクラスタを変更する場合は、conntrackdの設定カテゴリに切り替えます。

   初期セットアップウィザードに従っている場合は、カテゴリを手動で切り替える必要はありません。

2. 専用インターフェイスを選択して、接続ステータスを同期します。選択したインタフェースのIPv4アドレスが自動的に検出され、YaSTに表示されます。これはすでに設定済みで、マルチキャストをサポートしている必要があります。

3. 接続ステータスの同期に使用するマルチキャストアドレスを定義します。

4. グループ番号で、接続ステータスを同期させるグループのID番号を定義します。

5. /etc/conntrackd/conntrackd.confの生成を選択して、conntrackdの環境設定ファイルを作成します。

6. 既存のクラスタでオプションを変更した場合、変更を確認して、クラスタモジュールを終了します。

7. 次へ(セットアップウィザード)または完了(既存のクラスタ)をクリックして変更を確認します。

1. 既存のクラスタを変更する場合は、サービスカテゴリに切り替えます。このセクションのオプションを使用して、このノード上のクラスタサービスを開始および停止できます。

   初期セットアップウィザードに従っている場合は、カテゴリを手動で切り替える必要はありません。クラスタサービスは後で開始するので、ステップ 5までスキップしても構いません。

2. このクラスタノードがブートするたびにクラスタサービスを開始するには、クラスタの有効化を選択します。クラスタの無効化を選択する場合は、このノードがブートするたびに手動でクラスタサービスを開始する必要があります。

3. クラスタサービスを直ちに開始または停止するには、今すぐ開始するまたは今すぐ停止するを選択します。

4. QDeviceを直ちに開始または停止するには、今すぐ開始するまたは今すぐ停止するを選択します。

5. クラスタ通信に必要なポートをファイアウォールで開くには、ファイアウォールでポートを開くをアクティブにします。

6. 次へ(セットアップウィザード)または完了(既存のクラスタ)をクリックして変更を確認します。

   初期セットアップウィザードに従っている場合は、これで初期設定が完了し、YaSTが終了します。7.9項 「すべてのノードへの設定の転送」に進みます。

1. ノード間にパスワード不要のSSHが設定されていることを確認します。これはクラスタ通信に必要です。

2. ファイル/etc/csync2/csync2.cfgをクラスタ内のすべてのノードに手動でコピーします。

3. ファイル/etc/csync2/key_hagroupをクラスタ内のすべてのノードに手動でコピーします。このファイルは、Csync2による認証で必要になります。ただし、すべてのノードで同じファイルでなければならないので、他のノードではファイルを再生成しないでください。

4. すべてのノード上で次のコマンドを実行して、サービスを今すぐ有効にして開始します。

   # systemctl enable --now csync2.socket

1. すべてのファイルを一度同期させるには、設定のコピー元であるマシン上で次のコマンドを実行します。

   # csync2 -xv

   これによって、すべてのファイルをその他のノードにプッシュすることで、一度に同期を行います。すべてのファイルが正常に同期されると、Csync2がエラーなしで終了します。

   同期対象の1つ以上のファイルが(現在のノードだけでなく)他のノード上で変更されている場合は、Csync2から、以下のものと同様の出力との衝突が報告されます。

   While syncing file /etc/corosync/corosync.conf:
   ERROR from peer hex-14: File is also marked dirty here!
   Finished with 1 errors.

2. 現在のノードのファイルバージョンが「最良」だと確信する場合は、そのファイルを強制して再同期を行い、競合を解決できます。

   # csync2 -f /etc/corosync/corosync.conf
   # csync2 -xv

1. 既存のノードにログインします。

2. すべてのクラスタノード上でクラスタサービスを開始します。

   # crm cluster start --all

   このコマンドにはノード間のパスワード不要のSSHアクセスが必要です。crm cluster startを使用して個々のノードを起動することもできます。

3. クラスタのステータスをcrm statusコマンドで確認します。すべてのノードがオンラインの場合、出力は次のようになります。

   # crm status
   Cluster Summary:
     * Stack: corosync
     * Current DC: alice (version ...) - partition with quorum
     * Last updated: ...
     * Last change:  ... by hacluster via crmd on bob
     * 2 nodes configured
     * 1 resource instance configured
   
   Node List:
     * Online: [ alice bob ]
   ...

   この出力は、クラスタリソースマネージャが起動し、リソースを管理できる状態にあることを示しています。

1. 負荷の下でリソースが開始および停止するためにかかる時間を確認します。

2. 必要な場合、パラメータop_defaultsを追加し、それに応じて(デフォルトの)タイムアウト値を設定します。

   1. たとえば、op_defaultsを60秒に設定します。

      crm(live)configure# op_defaults timeout=60

   2. さらに長い時間を必要とするリソースについては、個別の値を定義します。

3. あるリソースに対して操作を設定する場合には、個別のstart操作およびstop操作を追加します。Hawk2を使用して設定する場合、これらの操作に適したタイムアウト値候補が表示されます。