12 QDeviceとQNetd #
QDeviceとQNetdはクォーラムの決定に参加します。アービトレータcorosync-qnetdからの支援により、corosync-qdeviceは設定可能な投票数を提供するため、クラスタは標準のクォーラムルールで許可されているよりも多くのノード障害に耐えることができます。2ノードクラスタにはcorosync-qnetdとcorosync-qdeviceを展開することを強くお勧めしますが、ノード数が偶数のクラスタには一般的にQNetdとQDeviceを使用することもお勧めします。
12.1 概念の概要 #
クラスタノード間のクォーラを計算するのと比較して、QDevice-and-QNetdアプローチには次の利点があります。
ノード障害が発生した場合の持続可能性が向上します。
投票に影響する独自のヒューリスティックススクリプトを作成できます。これは、SAPアプリケーションなどの複雑なセットアップに特に役立ちます。
複数のクラスタに投票を提供するようにQNetdサーバを設定できます。
2ノードクラスタでディスクレスSBDを使用できます。
スプリットブレイン状況下で偶数のノードを持つクラスタ、特に2ノードクラスタのクォーラムの決定に役立ちます。
QDevice/QNetdを使用したセットアップは、次のコンポーネントとメカニズムで構成されます。
- QNetd (
corosync-qnetd) クラスタの一部ではないsystemdサービス(デーモン、「QNetdサーバ」)。systemdサービスは、
corosync-qdeviceデーモンに投票を提供します。セキュリティを向上させるため、
corosync-qnetdは、クライアント証明書の確認にTLSと連携することができます。- QDevice (
corosync-qdevice) Corosyncとともに実行されている各クラスタノード上のsystemdサービス(デーモン)。これは
corosync-qnetdのクライアントです。その主な用途は、クラスタが標準のクォーラムルールが許可するよりも多くのノード障害に耐えることができるようにすることです。QDeviceはさまざまなアービトレータと連携するように設計されています。ただし、現在では、QNetdのみがサポートされています。
- アルゴリズム
QDeviceは投票の割り当て方法の動作を決定する、さまざまなアルゴリズムをサポートしています。現在は、以下が存在します。
FFSplit (「fifty-fifty split」)がデフォルトです。これは、ノード数が偶数のクラスタに使用されます。クラスタが2つの同じパーティションに分割される場合、このアルゴリズムによりヒューリスティックスの確認と他の要因に基づいて、パーティションのいずれかに1票が提供されます。クラスタが2つの同様のパーティションに分割される場合、このアルゴリズムによりヒューリスティックスの確認と他の要因に基づいて、パーティションのいずれかに1票が提供されます。
LMS (「last man standing」)では、QNetdサーバを確認できる残っている唯一のノードに1票が与えられます。QNetdサーバを確認できる残っている唯一のノードである場合に、1票が返されます。したがって、このアルゴリズムは、アクティブな1つのノードのみを持つクラスタがクォーラムに達した状態を維持する必要がある場合に役立ちます。
- ヒューリスティックス
QDeviceは一連のコマンド(「heuristics」)をサポートしています。コマンドは、クラスタサービスの起動、クラスタメンバーシップの変更、
corosync-qnetdへの接続の成功時にローカルで実行されるか、オプションで定期的に実行されます。ヒューリスティックスは、quorum.device.heuristicsキー(corosync.confファイル内)または--qdevice-heuristics-modeオプションを使用して設定できます。両方がoff(デフォルト)、sync、およびonの値を認識しています。syncとonの違いは、先に示したコマンドを定期的に補足的に実行できるということです。すべてのコマンドが正常に実行された場合にのみ、ヒューリスティックスは合格したとみなされ、そうでない場合は、失敗したとみなされます。ヒューリスティックスの結果は、
corosync-qnetdに送信され、そこでクォーラムに達するパーティションを決定するための計算に使用されます。- Tiebreaker
これは同じヒューリスティックスの結果の場合でも、クラスタパーティションが完全に等しい場合のフォールバックとして使用されます。最小、最大、または特定のノードIDに設定できます。
12.2 要件と前提条件 #
QDeviceとQNetdを設定する前に、次のように環境を準備しておく必要があります。
クラスタノードのほかに、QNetdサーバになる別のマシンが必要です。12.3項 「QNetdサーバのセットアップ」を参照してください。
Corosyncが使用するものとは異なる物理ネットワーク。QDeviceがQNetdサーバに到達することをお勧めします。理想としては、QNetdサーバはメインクラスタとは別のラックに配置するか、少なくとも別のPSUに配置し、Corosyncリングと同じネットワークセグメントには配置しないでください。
12.3 QNetdサーバのセットアップ #
QNetdサーバはクラスタスタックの一部ではなく、クラスタの実際のメンバーでもありません。そのため、このサーバにリソースを移動することはできません。
QNetdサーバはほとんど「ステートフリー」です。通常、設定ファイル/etc/sysconfig/corosync-qnetd内を変更する必要はありません。デフォルトでは、corosync-qnetdサービスはグループcoroqnetd内のユーザcoroqnetdとしてデーモンを実行します。これにより、rootとしてデーモンを実行する必要がなくなります。
QNetdサーバを作成するには、次の手順に従います。
QNetdサーバになるマシン上に、SUSE Linux Enterprise Server 15 SP4をインストールします。
QNetdサーバにログインして、次のパッケージをインストールします。
root #zypperinstall corosync-qnetdcorosync-qnetdサービスを手動で開始する必要はありません。ブートストラップスクリプトは、qdeviceステージ中の起動プロセスを処理します。
QNetdサーバはQDeviceクライアントcorosync-qdeviceからの接続を受け入れる準備ができています。さらに設定する必要はありません。
12.4 QDeviceクライアントをQNetdサーバに接続する #
QNetdサーバを設定した後で、クライアントを設定して実行することができます。クラスタのインストール中にQNetdサーバにクライアントを接続するか、後で追加することができます。次の手順では、後者の方法を使用します。2つのクラスタノード(aliceとbob)およびQNetdサーバ(charlie)を持つクラスタを想定しています。
すべてのノードで、パッケージ corosync-qdevice:
root #zypperinstall corosync-qdevicealiceで、クラスタを初期化します。
root #crmcluster init -ybobで、クラスタに参加します。
root #crmcluster join -c alice -yaliceとbobで、
qdeviceステージをブートストラップします。ほとんどの場合、デフォルト設定で問題ありません。少なくとも--qnetd-hostnameとQNetdサーバのホスト名またはIP アドレス(この場合はCharlie)を指定します。root #crmcluster init qdevice --qnetd-hostname=charlieデフォルトの設定を変更する場合は、コマンド
crm cluster init qdevice --helpを使用してすべての可能なオプションのリストを取得します。QDeviceに関連するすべてのオプションは、--qdevice-NAMEで開始されます。
デフォルト設定を使用している場合、先に示したコマンドはTLSが有効で、FFSplitアルゴリズムを使用するQDeviceを作成します。
12.5 ヒューリスティックスを使用したQDeviceの設定 #
投票の決定方法をさらに制御する必要がある場合は、ヒューリスティックスを使用します。ヒューリスティックスは、並行して実行される一連のコマンドです。
この目的のため、コマンドcrm cluster init qdeviceはオプション--qdevice-heuristicsを提供します。絶対パスを使用して1つ以上のコマンド(セミコロンで区切る)を渡すことができます。
たとえば、ヒューリスティックチェック用の独自のコマンドが/usr/sbin/my-script.shにある場合は、次のようにクラスタノードのいずれかで実行できます。
root #crmcluster init qdevice --qdevice-hostname=charlie \ --qdevice-heuristics=/usr/sbin/my-script.sh \ --qdevice-heuristics-mode=on
コマンドは、Shell、Python、またはRubyなどの任意の言語で記述することができます。成功した場合は、0 (ゼロ)を返し、失敗した場合はエラーコードを返します。
一連のコマンドを渡すこともできます。すべてのコマンドが正常に終了した場合のみ(戻りコードが0)、ヒューリスティックスが渡されます。
--qdevice-heuristics-mode=onオプションを使用すると、ヒューリスティックスコマンドを定期的に実行できます。
12.6 クォーラムステータスの確認と表示 #
例12.1「QDeviceのステータス」に示すように、クラスタノードのいずれかでクォーラムステータスを問い合わせることができます。QDeviceノードのステータスが表示されます。
root #corosync-quorumtool1 Quorum information ------------------ Date: ... Quorum provider: corosync_votequorum Nodes: 2 2 Node ID: 3232235777 3 Ring ID: 3232235777/8 Quorate: Yes 4 Votequorum information ---------------------- Expected votes: 3 Highest expected: 3 Total votes: 3 Quorum: 2 Flags: Quorate Qdevice Membership information ---------------------- Nodeid Votes Qdevice Name 3232235777 1 A,V,NMW 192.168.1.1 (local) 5 3232235778 1 A,V,NMW 192.168.1.2 5 0 1 Qdevice
同一の結果の代替として、 | |
予想されるノード数。この例では、2ノードクラスタです。 | |
| |
クォーラムステータス。この場合、クラスタにはクォーラムがあります。 | |
各クラスタノードのステータスは以下を意味します。
|
QNetdサーバのステータスを問い合わせると、例12.2「QNetdサーバのステータス」に示すのと同様の出力が得られます。
root #corosync-qnetd-tool -lv1 Cluster "hacluster": 2 Algorithm: Fifty-Fifty split 3 Tie-breaker: Node with lowest node ID Node ID 3232235777: 4 Client address: ::ffff:192.168.1.1:54732 HB interval: 8000ms Configured node list: 3232235777, 3232235778 Ring ID: aa10ab0.8 Membership node list: 3232235777, 3232235778 Heuristics: Undefined (membership: Undefined, regular: Undefined) TLS active: Yes (client certificate verified) Vote: ACK (ACK) Node ID 3232235778: Client address: ::ffff:192.168.1.2:43016 HB interval: 8000ms Configured node list: 3232235777, 3232235778 Ring ID: aa10ab0.8 Membership node list: 3232235777, 3232235778 Heuristics: Undefined (membership: Undefined, regular: Undefined) TLS active: Yes (client certificate verified) Vote: No change (ACK)
12.7 詳細の参照先 #
QDeviceとQNetdに関する追加情報については、corosync-qdevice(8)とcorosync-qnetd(8)のマニュアルページを参照してください。