web-dev-qa-db-ja.com

スプリットブレインシナリオを防ぐCorosyncHA

私は、負荷分散と高可用性について自己学習するためのテストシステムをセットアップしています。Corosyncの構成設定について知りたいと思っています。その経験をお持ちの皆さんに教えてください。

私が現在調査および学習しているのは、Corosyncの投票クォーラムと、落ちたノードの処理方法です。小さな研究セッション中に、両方のノードが唯一の生存者であると想定し、マスターであると考え、マスターを維持しようとするSTONITHとスプリットブレインシナリオについての話を見つけました。これはもちろん望ましくないシナリオです。

Corosync構成では、特定の構成を確認しました。

quorum {
        ...
        auto_tie_breaker: 1
        auto_tie_breaker_node: lowest
}

auto_tie_breakerはそのようなスプリットブレインシナリオを防ぐことができますか、それとも私は間違っていますか？

ドキュメンテーションの権利を理解し、それを最下位に設定すると、ノードIDが最下位のノードが担当ノードになります。

nodelist {
          node {
          ring0_addr: primary_private_ip
          name: primary
          nodeid: 1
          }

          node {
          ring0_addr: secondary_private_ip
          name: secondary
          nodeid: 2
          }
}

もちろん、現時点では2ノードのクラスターでのみテストを行っていますが、プロセスがどのように機能するかを理解することを目的としているため、将来、より信頼性の高いインフラストラクチャを正常にセットアップできます。

入力とガイダンスをありがとう、そして素晴らしい一日を！ :)

clusterhigh-availabilitycorosync
2
StianM

auto_tie_breakerはノード構成（1/1、1/1/1/1など）でもノードに接続を維持することを強制することでノード障害を解決しようとするという想定では正しいです。正しいノードのセット（または2つのノードクラスター内の単一ノード）。

投票クォーラムの一般的な動作では、各ノードに1票があると仮定すると、最大50％-1ノードの同時ノード障害が発生します。

ATBが有効になっている場合、クラスターは、決定論的な方法で、ノードの最大50％が同時に障害を起こす可能性があります。デフォルトでは、クラスターパーティション、またはノードIDが最小のノードとまだ接続しているノードのセットは定足数のままになります。他のノードはinquorateになります。この動作は、指定することによっても変更できます

クラスターのクォーラム投票は通常、n + 1ノードのシナリオで使用するか、two_nodeパラメーターを使用して使用する必要があり、expected_votesを2に設定して、ハードウェアフェンシング/ [〜＃ 〜] stonith [〜＃〜] 有効にする必要がありました。

auto_tie_breaker_node: lowest|highest|<list of node IDs>

'lowest'がデフォルトで、 'highest'は、現在のノードのセットに最大のnodeidが含まれている場合、定足数のままになるという点で類似しています。あるいは、クォーラムを維持するために必要となる特定のノードIDまたはノードIDのリストを指定することもできます。 （スペースで区切られた）リストが指定されている場合、ノードは順番に評価されるため、最初のノードが存在する場合、そのノードがどちらの半分にも存在しない（つまり、分割前のクラスター）、2番目のノードIDがチェックされる、というように続きます。 ATBは定足数デバイスと互換性がありません-auto_tie_breakerがcorosync.confで指定されている場合、定足数デバイスは無効になります。

注意：これは [〜＃〜] stonith [〜＃〜] デバイスではなく、two_nodeディレクティブと一緒に使用することはできません。

two_node: 1

2ノードクラスター操作を有効にします（デフォルト：0）。

「2ノードクラスター」は、特別な考慮が必要なユースケースです。標準の2ノードクラスターでは、各ノードに単一の投票があり、クラスターには2つの投票があります。単純な多数決（投票の50％+ 1）を使用してクォーラムを計算すると、クォーラムは2になります。これは、クラスターがクォーレートされて動作するためには、両方のノードが常に稼働している必要があることを意味します。

Two_nodeを有効にする：1、クォーラムは人工的に1に設定されます

したがって、ハードウェアフェンシングまたはSTONITHを使用しないノードクラスタの新しい推奨方法はauto_tie_breakerです。

N + 1クラスターでは、クォーラム投票は依然として非常に信頼できますが、注目度の高いLinux HAの場合、ハードウェアフェンシング/ STONITHが引き続き重要です。

いつものように、ネットワークの停止、ハードウェア障害、電源喪失、同時リソースエラー、DRBDエラー（使用されている場合）など、考えられるすべてのシナリオを必ずテストし、「新規」で このドキュメント を読んでください。 corosyncの機能。

2
Lenniey