XNUMX つのノードのクラスター – 悪魔は細部に宿る

おい、ハブル！ 記事の翻訳をご紹介します 「二つのノード - 悪魔は細部に宿る」 アンドリュー・ビーコフ著。

多くの人が 33 ノード クラスターを好むのは、概念的にシンプルで、XNUMX ノードのクラスターよりも XNUMX% 安価であるためです。 XNUMX つのノードからなる適切なクラスターを構築することは十分に可能ですが、ほとんどの場合、考慮されていないシナリオにより、そのような構成では多くの明らかでない問題が発生します。

高可用性システムを構築するための最初のステップは、個々の障害点 (しばしば「障害点」と略されます) を見つけて排除しようとすることです。 SPoF (単一障害点)。

どのようなシステムにおいても、ダウンタイムの考えられるリスクをすべて排除することは不可能であることに留意する必要があります。これは、リスクに対する一般的な防御策がある程度の冗長性を導入することであり、それがシステムの複雑性の増大と新たな障害点の出現につながるという事実に由来しています。したがって、最初は妥協して、関連する、したがって可能性がますます低くなっているイベントの連鎖ではなく、個々の障害点に関連するイベントに焦点を当てます。

トレードオフを考慮すると、SPoF を探すだけでなく、リスクと結果のバランスも考慮します。その結果、何が重要で何が重要ではないかの結論は展開ごとに異なる場合があります。

誰もが独立した送電線を備えた代替電力供給者を必要とするわけではありません。しかし、少なくとも 1 人の顧客の監視が変圧器の故障を検出したとき、被害妄想は報われました。顧客は、故障した変圧器が爆発するまで、電力会社に警告するために電話をかけ続けました。

自然な開始点は、システム内に複数のノードがあることです。ただし、障害発生後にシステムがサービスを存続ノードに移動する前に、通常、移動されるサービスが他の場所でアクティブになっていないことを確認する必要があります。

障害が発生して両方のノードが同じ静的 Web サイトを提供することになった場合でも、2 ノード クラスターにマイナス面はありません。ただし、その結果、双方が独立して共有ジョブ キューを管理したり、レプリケート データベースや共有ファイル システムへの非調整の書き込みアクセスを提供したりする場合は、状況が変わります。

したがって、単一ノードの障害によるデータ破損を防ぐために、と呼ばれるものに依存します。 "解離" （フェンシング）。

解離の原理

解離の原理の中心となるのは、競合するノードがデータ破損を引き起こす可能性があるかどうかという疑問です。データ破損の可能性が高いシナリオの場合、受信リクエストと永続ストレージの両方からノードを隔離することが良い解決策となります。関連付けを解除する最も一般的なアプローチは、障害のあるノードを切断することです。

解離方法には 2 つのカテゴリがあります。 ストレート и 間接的、しかし、それらは同様に呼び出すことができます 活発な и 受動的。直接的な方法には、IPMI (インテリジェント プラットフォーム管理インターフェイス) または iLO (サーバーへの物理的なアクセスがない場合にサーバーを管理するメカニズム) デバイスとの対話など、生き残ったピア側のアクションが含まれますが、間接的な方法は障害が発生したピアに依存します。ノードが異常な状態にあること（または少なくとも他のメンバーの回復を妨げていること）を何らかの方法で認識し、信号を送る ハードウェアウォッチドッグ 障害が発生したノードを切断する必要性について。

クォーラムは、直接的方法と間接的方法の両方を使用する場合に役立ちます。

直接解離

直接的な解離の場合、クォーラムを使用して、ネットワーク障害が発生した場合の解離の競合を防ぐことができます。

クォーラムの概念により、システム内には (ピアに接続していなくても) ノードが分離や回復を開始する必要があるかどうかを自動的に認識するのに十分な情報が存在します。

クォーラムがないと、ネットワークの分断の両側は、相手方が死んでいると当然想定し、相手方の関連付けを解除しようとします。最悪の場合、双方がクラスタ全体をシャットダウンすることに成功します。別のシナリオは、デスマッチです。これは、ノードが生成され、ピアが表示されず、再起動され、ピアが同じロジックに従っている場合にのみ再起動するまで回復を開始するという無限ループです。

関連付けの解除の問題は、回復の対象としたい同じ障害イベントが原因で、最も一般的に使用されているデバイスが使用できなくなることです。ほとんどの IPMI カードと iLO カードは、制御するホストにインストールされており、デフォルトで同じネットワークを使用するため、ターゲット ホストは他のホストがオフラインであると認識します。

残念ながら、IPMI および iLo デバイスの動作機能は、機器の購入時にほとんど考慮されません。

間接解離

クォーラムは、間接的な関連付けの解除を管理するためにも重要です。正しく実行されれば、クォーラムにより、生存者は失われたノードが一定期間後に安全な状態に移行すると想定することができます。

この構成では、クォーラムが失われない限り、ハードウェア ウォッチドッグ タイマーは N 秒ごとにリセットされます。タイマー (通常は N の数倍) が期限切れになると、デバイスは不正な電源切断 (シャットダウンではなく) を実行します。

このアプローチは非常に効果的ですが、クォーラムがないと、クラスター内にクォーラムを管理するのに十分な情報がありません。ネットワークの停止とピアノードの障害を区別するのは簡単ではありません。これが重要な理由は、2 つのケースを区別する能力がなければ、両方のケースで同じ動作を選択せざるを得なくなるからです。

1 つのモードを選択する場合の問題は、可用性を最大化し、データ損失を防ぐためのアクションが存在しないことです。

• ピアノードがアクティブであるが実際には障害が発生していると想定することを選択した場合、クラスターは、障害が発生したピアノードからのサービスの損失を補うために実行中のサービスを不必要に停止します。
• ノードがダウンしているが、それは単なるネットワーク障害であり、実際にはリモート ノードは機能していると仮定することにした場合、せいぜい、結果として得られるデータ セットの将来の手動調整にサインアップすることになります。

どのようなヒューリスティックを使用するかに関係なく、両側で障害が発生したり、クラスターが生き残っているノードをシャットダウンしたりするような障害が発生することは簡単です。クォーラムを使用しないと、クラスターからその武器庫の中で最も強力なツールの 1 つが実際に奪われてしまいます。

他に選択肢がない場合、最善のアプローチは可用性を犠牲にすることです (ここで著者は CAP 定理に言及しています)。破損したデータの高可用性は誰の役にも立ちませんし、異なるデータセットを手動で調整するのも楽しくありません。

定足数

定足数は素晴らしいですね。

唯一の欠点は、N メンバーを持つクラスター内にこれを配置するには、残りの N/2+1 ノード間で接続する必要があることです。 XNUMX ノードのクラスターでは、XNUMX つのノードに障害が発生した場合、これは不可能です。

これにより、最終的には 2 つのノードに関する根本的な問題が発生します。
クォーラムは 2 ノード クラスターでは意味がありません。クォーラムがなければ、可用性を最大化し、データ損失を防ぐための行動方針を確実に決定することは不可能です。
クロスケーブルで接続された 2 つのノードのシステムであっても、ネットワークの停止と他のノードの障害を明確に区別することは不可能です。一方の端を無効にすると (もちろん、その確率はノード間の距離に比例します)、リンクの健全性がパートナー ノードの健全性と等しいという仮定を無効にするのに十分です。

2 ノードのクラスターを機能させる

場合によっては、クライアントが 3 番目のノードを購入できない、または購入したくない場合があり、代替手段を探す必要があります。

オプション 1 - 重複した解離法

ノードの iLO または IPMI デバイスは障害点を表します。これは、障害が発生した場合、生存者はそれを使用してノードを安全な状態にすることができないためです。 3 つ以上のノードからなるクラスターでは、クォーラムを計算し、ハードウェア ウォッチドッグ (前述したように、間接的な関連付け解除メカニズム) を使用することで、この問題を軽減できます。 XNUMX つのノードの場合は、代わりにネットワーク配電ユニット (PDU) を使用する必要があります。

障害が発生した後、生存者はまずプライマリ関連付け解除デバイス (組み込み iLO または IPMI) への接続を試みます。これが成功すると、通常どおり回復が続行されます。 iLO/IPMI デバイスに障害が発生した場合にのみ PDU がアクセスされ、アクセスが成功した場合は回復を続行できます。

PDU は必ずクラスタ トラフィックとは異なるネットワーク上に配置してください。そうしないと、単一のネットワーク障害によって両方の関連付け解除デバイスへのアクセスがブロックされ、サービスの復元がブロックされます。

ここで、PDU は単一障害点なのでしょうか?と疑問に思うかもしれません。答えは、もちろんそうです。

このリスクがあなたにとって重大である場合、あなたは一人ではありません。両方のノードを 2 つの PDU に接続し、ノードの電源をオンまたはオフにするときに両方を使用するようにクラスタリング ソフトウェアに指示します。 1 つの PDU が故障してもクラスターはアクティブのままになり、もう 1 つの PDU または IPMI デバイスのいずれかに 2 回目の障害が発生すると、回復をブロックする必要があります。

オプション 2 - アービターの追加

一部のシナリオでは、重複の関連付けを解除する方法は技術的には可能ですが、政治的に困難です。多くの企業は、管理者とアプリケーション所有者をある程度分離することを好みますが、セキュリティを重視するネットワーク管理者は、PDU アクセス設定を誰とでも共有することに必ずしも熱心ではありません。

この場合、推奨される代替方法は、クォーラム計算を補うことができる中立的なサードパーティを作成することです。

障害が発生した場合、サービスを復元するために、ノードはピアまたはアービターの電波を認識できなければなりません。アービターには、両方のノードがアービターを認識できても相互を認識できない場合の切断機能も含まれています。

このオプションは、ハードウェア ウォッチドッグ タイマーなどの間接的な関連付け解除方法と組み合わせて使用​​する必要があります。この方法は、ピアおよびアービター ノードへの接続が失われた場合にマシンを強制終了するように構成されています。したがって、生存者は、ハードウェア ウォッチドッグ タイマーが期限切れになった後もピア ノードが安全な状態になると合理的に想定できます。

アービターと 3 番目のノードの実質的な違いは、アービターは動作に必要なリソースがはるかに少なく、潜在的に複数のクラスターにサービスを提供できることです。

オプション 3 - 人的要因

最後のアプローチは、生存者が既に実行していたサービスは実行し続けるが、問題が自然に解決する (ネットワークの復元、ノードの再起動) か、誰かが責任を持って相手側が停止していることを手動で確認するまで、新しいサービスを開始しないことです。

ボーナスオプション

3 番目のノードを追加できると言いましたか?

2つのラック

議論のために、私が 3 番目のノードの利点を理解したとしましょう。次に、ノードの物理的な配置を考慮する必要があります。これらが同じラックに収容されている (そして電源が供給されている) 場合、これも SPoF を構成し、2 番目のラックを追加しても解決できません。

これが驚くべきことである場合は、2 つのノードを備えたラックに障害が発生した場合に何が起こるか、また、生き残ったノードがそれとネットワーク障害をどのように区別するかを考えてください。

簡単に言うと、これは不可能であり、2 つのノードの場合のすべての問題に再び対処することになります。または生存者:

• クォーラムを無視し、ネットワーク停止中に誤って復元を開始しようとします (分離を完了できるかどうかは別の話であり、PDU が関与しているかどうか、および PDU がいずれかのラックと電力を共有しているかどうかによって異なります)、または
• クォーラムを尊重し、ピアノードに障害が発生すると途中で切断します。

いずれの場合も、2 つのラックは 1 つのラックに劣らず、ノードには独立した電源が供給されるか、3 つ (ノード数に応じてそれ以上) のラックに分散される必要があります。

2 つのデータセンター

この時点で、リスクを回避できなくなった読者は、災害復旧を検討したいと思うかもしれません。 3 つのノードが 3 つの異なるラックに分散している同じデータセンターに小惑星が衝突したらどうなるでしょうか?明らかに悪いことですが、ニーズによっては、2 番目のデータセンターを追加するだけでは不十分な場合があります。

正しく行われた場合、2 番目のデータ センターは、サービスとそのデータの最新かつ一貫性のあるコピーを (そして合理的に) 提供します。ただし、2 ノード、2 ラックのシナリオと同様、最大限の可用性を確保し、破損 (またはデータ セットの不一致) を防ぐのに十分な情報がシステム内にありません。 3 つのノード (またはラック) があっても、それらを 2 つのデータセンターにのみ分散すると、双方が通信できない (現在ではその可能性が非常に高くなっている) イベントが発生した場合に、システムは正しい決定を確実に行うことができなくなります。

これは、デュアル データセンター ソリューションが決して適切ではないという意味ではありません。企業は多くの場合、バックアップ データ センターに移行するという特別な措置を講じる前に、従業員に認識してもらいたいと考えています。停止を自動化したい場合は、クォーラムを意味のあるものにするために (直接またはアービターを通じて) 3 番目のデータセンターが必要になるか、データ全体を確実にシャットダウンする方法を見つける必要があることに注意してください。中心。

出所： habr.com