2

いくつかのマシンをエラスティック クラスターに投入し、その中で何らかのコンセンサス アルゴリズムを実行したいとします (Paxos など)。彼らがネットワークの初期サイズ、たとえば 8 台のマシンを知っているとします。

したがって、彼らはコンセンサス アルゴリズムを実行し、定足数は 5 です。

ここで、次のケースを検討してください。

  1. CPU が少なすぎることがわかり、クラスター サイズを半分の 4 台のマシンに減らしました。
  2. パーティション分割があり、各分割には 4 台のマシンが割り当てられます。

クォーラムを取得するために現在のクラスター サイズを使用すると、パーティションが分割される可能性があります。基礎となるクラスターの場合、状況 (1) と (2) はまったく同じに見えます。ただし、固定数を使用すると、クラスターをスケールダウンできません (スケールアップすると、パーティションによる不整合が発生します)。

スケーリング時にすべてのマシンにクラスターのサイズを通知する 3 つ目の方法がありますが、たとえば、スケールアップの直前にパーティションが発生し、そのパーティションが新しいサイズを受け取らず、十分なクォーラムを持っていない可能性があります。古いサイズを使用したコンセンサス。

Paxos (およびその他の安全なコンセンサス アルゴリズム) は、柔軟な環境では使用できませんか?

4

2 に答える 2

2

Paxos とその仲間は、弾力的な方法で (ある程度) スケーリングできます。ただし、クォーラム サイズを変更する代わりに、 Learners を追加するだけです。学習者は、コンセンサスに参加しないノードですが、すべての決定を下します。アクセプターと同様に、学習者は読み取りを受け入れ、リーダーへの書き込みを転送します。

学習者には 2 つのスタイルがあります。1 つ目は、アクセプターからのすべてのイベントをリッスンします。2番目に、リーダーはコミットされたすべての遷移を学習者に転送します

于 2015-12-23T23:05:56.290 に答える
2

定足数ベースのコンセンサス プロトコルは、動作するために基本的に定足数を必要とします。Multi-Paxos と Raft はどちらも、クラスターとクォーラムのサイズが動的に変化する環境で使用できますが、一貫したクォーラムを常に維持する制御された方法で行う必要があります。たとえば、現在 8 のクラスター サイズを使用していて、そのクラスターのサイズを 4 に縮小したい場合は、そうすることができます。ただし、クラスタ サイズを 4 に減らすという決定は、元の 8 人が同意した合意に基づく決定でなければなりません。

あなたの質問は少し不明確ですが、ある種のネットワーク パーティションによって元の 8 のクラスターが動作不能になった場合の回復メカニズムとして、クラスター サイズを安全に 4 に減らすことができるかどうかを尋ねているように聞こえました。そうするという決定は合意に基づくものではなく、合意アルゴリズムの裏に行こうとする試みは矛盾をもたらすことが事実上保証されているため、それに対する答えは事実上ノーです。新しい 4 つのセットはどのように定義されますか? すべてのピアが同じ結論に達したことをどのように保証しますか? 全員が同時に同じ決定を下せるようにするにはどうすればよいでしょうか?

もちろん、これらすべての決定を手動で行い、各システムでコンセンサス サービスをシャットダウンし、クォーラム定義を手動で再構成することにより、システムを強制的に回復させることもできます。失敗しないと仮定すると (これは、実際の展開では圧倒的に大きな仮定です)、これは安全です。ただし、より良いアプローチは、1 つまたは 2 つのネットワーク パーティションがシステムを停止させないようにシステムを設計するか (多くのサイト)、または偶発的なネットワーク パーティションを適切に処理する結果整合性モデルを使用することです。CAP 制限を回避する特効薬はありません。

于 2015-12-23T16:53:02.880 に答える