Redisセンチネルとクラスタリング

私は、redisセンチネルが複数のredisインスタンス間でHA（高可用性）を構成する方法であることを理解しています。私が見るように、1つのredisインスタンスが常にクライアントのリクエストにアクティブに対応しています。さらに2つのサーバーがスタンバイ状態になっています（障害が発生するのを待っているため、そのうちの1つが再び動作可能になります）。

• 資源の無駄ですか？
• 利用可能なリソースを最大限に活用するより良い方法はありますか？
• RedisのクラスタリングはRedisの歩哨の代替手段ですか？

センチネルとクラスタリングの redisドキュメントをすでに調べましたが、誰か経験のある人が説明してもらえますか？

更新

OK。私の実際の展開シナリオでは、redis専用の2台のサーバーがあります。Jbossサーバーが実行している別のサーバーがあります。Jbossで実行されているアプリケーションは、redisマスターサーバー（M）に接続するように構成されています。

フェイルオーバーのシナリオ

理想的には、マスターキャッシュサーバーに障害が発生した場合（Redisプロセスがダウンするかマシン障害が発生した場合）、Jbossのアプリケーションはスレーブキャッシュサーバーに接続する必要があります。これを実現するためにredisサーバーをどのように構成しますか？

+--------+          +--------+
| Master  |---------| Slave  |
|         |         |        |
+--------+          +--------+

Configuration: quorum = 1

まず、歩哨について話しましょう。

Sentinelはフェイルオーバーを管理し、HA用のRedisを設定しません。それは重要な違いです。第二に、投稿した図は実際には不適切な設定です。Sentinelを管理しているRedisノードと同じノードで実行したくない場合です。そのホストを失うと、両方を失います。

「資源の無駄ですか？」について ユースケースによって異なります。そのセットアップでは3つのRedisノードは必要ありません。必要なのは2つだけです。3つは冗長性を高めますが、必須ではありません。追加の冗長性が必要な場合、それはリソースの無駄ではありません。冗長性が必要ない場合は、単一のRedisインスタンスを実行し、それを適切と呼びます。これ以上実行すると「無駄」になります。

2つのスレーブを実行するもう1つの理由は、読み取りを分割することです。繰り返しますが、それが必要な場合、それは無駄ではありません。

「利用可能なリソースを最大限に活用するより良い方法はありますか？」について 特定のシナリオやコードに大きく依存しているため、お答えできません。とはいえ、保存するデータの量が「少なく」、コマンドレートがそれほど高くない場合は、ホストをRedis専用にする必要がないことに注意してください。

では、「RedisのクラスタリングはRedisの歩哨の代替手段ですか？」について説明します。それは本当にあなたのユースケースに完全に依存します。RedisクラスターはHAソリューションではありません-複数のライター/ RAMより大きいソリューションです。目標がHAだけの場合は、おそらく適切ではありません。Redisクラスターには、特にマルチキー操作に関する制限があり、必ずしも単純な「クラスターを使用する」操作であるとは限りません。

Redisを実行している3つのホスト（および3つの実行中のセンチネル）が無駄であると考える場合、より多くのリソースを必要とするため、クラスターをさらに高くする可能性があります。

あなたが尋ねた質問はおそらく広範であり、書面どおりに生き残るには意見に基づくものです。解決しようとしている特定のケース/問題がある場合は、それで更新してください。特定の支援と情報を提供できます。

詳細の更新：

シナリオで適切なフェイルオーバー管理を行うには、JBossサーバーで実行されている3つのセンチネルを使用します。JBossノードが3つある場合は、それぞれ1つにします。別のノードにRedisポッド（マスター+スレーブ）を配置し、センチネルにフェイルオーバーを管理させます。

そこから、情報と接続管理にSentinelを使用するためにJBoss / Jedisを接続する必要があります。私はそれらを使用しないので、Jedisがサポートしていることがクイック検索で判明します。それを正しく設定するだけです。私が見つけたいくつかの例は、Sentinelを使用したJedisの例の検索とhttps://github.com/xetorthio/jedis/issues/725にあります。JedisSentinelPool、プールを使用するためのルートであることを使用したます。

Sentinelがフェイルオーバーを実行すると、クライアントは切断され、Jedisは現在のマスターが誰であるかをSentinelsに尋ねることによって再接続を処理します（すべきですか？）。

どこでも、2または2の倍数を使用せずに、奇数のインスタンスから始めることをお勧めします。それは修正されましたが、他のいくつかの点を修正しましょう。

まず、SentinelがHAなしでフェイルオーバーを提供すると言うのは誤りです。フェイルオーバーがある場合、HAがあり、アプリケーションの状態が複製されるという追加の利点があります。違いは、レプリケーションなしでシステムにHAを設定できることです（HAですが、フォールトトレラントではありません）。

次に、ターゲットのredisインスタンスと同じマシンで番兵を実行することは「悪い設定」ではありません。番兵、redisインスタンス、またはマシン全体を失うと、結果は同じになります。そのため、このような構成のすべての例で、両方が同じマシンで実行されていることがわかります。

これは質問への直接の回答ではありませんが、私のようにRedisの初心者には役立つ情報だと思います。また、この質問は、「Redisクラスターvsセンチネル」を検索すると、Googleの最初のリンクとして表示されます。

Redis SentinelはRedis高可用性ソリューションの名前です...これはRedis Clusterとは関係なく、Redis Clusterを必要としない人々が使用することを目的としていますが、マスターが自動フェイルオーバーを実行する方法にすぎませんインスタンスが正しく機能していません。

Redis Sentinelデザインドラフト1.3からの引用

Redisに慣れておらず、フェイルオーバーソリューションを実装している場合でも、問題はありません。センチネルとクラスタリングに関する公式ドキュメントは互いに比較できないため、大量のドキュメントを読まなければ、正しい方法を選択することは困難です。

これは、ドキュメント全体で頭を叩いた後の私の理解です。

Sentinelは一種のホットスタンバイソリューションであり、スレーブは常に複製されており、いつでも昇格する準備ができています。ただし、マルチノードの書き込みはサポートされません。スレーブは読み取り操作用に構成できます。SentinelがHAを提供しないことは真実ではありません、それは典型的なアクティブ-パッシブクラスタのすべての機能を持っています（ただし、ここで使用するのに適切な用語ではありません）。

Redisクラスターは分散ソリューションであり、シャードの上で動作します。データの各チャンクは、マスターノードとスレーブノードに分散されます。最小の複製係数2により、マスターとスレーブ間で2つのアクティブなシャードを使用できるようになります。MongoまたはElasticsearchでのシャーディングを知っている場合は、簡単に追いつくことができます。

Redisは、パーティション化されたクラスター（これらのマスターの多くのマスターとスレーブがある）または単一インスタンスモード（レプリカスレーブを持つ単一のマスター）で動作できます。ここ
のリンクは言う：

単一のRedisサーバーがパーティション分割されていないデータベース全体を管理するシングルインスタンスモードでRedisを使用する場合、Redis Sentinelを使用してその可用性を管理します

それはまた言います：

データが複数のプライマリインスタンス間で分割されるRedisクラスターは、それ自体で可用性を管理し、追加のコンポーネントを必要としません。

したがって、前述の2つのシナリオでHAを確保できます。これで疑問が解消されることを願っています。Redisクラスターと歩哨は互いに代替できません。これらは、パーティション化されたマスターまたはパーティション化されていないマスターのさまざまなケースでHAを確保するために使用されます。

Redis Sentinelは、マスターがダウンしていることを確認すると、レプリカを昇格させるフェイルオーバーを実行します。通常、奇数の番兵ノードが必要です。1つのマスターと1つのレプリカの例では、3つのセンチネルを使用して、決定についてコンセンサスを得ることができます。理想的には、3番目の番兵が3番目のサーバー上にあるため、（障害に応じて）決定が歪められることはありません。Sentinelは、昇格と同期が正しい順序で行われるようにノードのマスター/レプリカ構成設定を変更し、古いデータが含まれている古い障害のあるマスターを持ち込んでデータを上書きしないようにします。

フェイルオーバーを実行するようにセンチネルノードを設定したら、正しいインスタンスをポイントしていることを確認する必要があります。このためのHAProxy構成の例を参照してください。HAProxyはヘルスチェックを実行し、障害が発生した場合に新しいマスターをポイントします。

クラスタリングにより、水平方向のスケーリングが可能になり、高負荷の処理に役立ちます。事前の設定と構成には少し手間がかかります。

Redisのオープンソースフォークである「KeyDB」により、アクティブレプリカオプションを備えたセンチネルノードの必要がなくなりました。これにより、レプリカノードは読み取りと書き込みを受け入れることができます。フェイルオーバーが発生すると、HAProxyは障害が発生したノードでの読み取り/書き込みを停止し、すでに同期されている残りのアクティブノードを使用します。タイムスタンプにより、障害が発生したノードが自動的に再結合し、オンラインに戻ったときにデータを失うことなく再同期できます。設定は簡単で、トラフィックが多い場合は、レプリカノードへの読み取りとマスターへの読み取り/書き込みを行うための特別な事前設定は必要ありません。ここでアクティブなレプリケーションの例を参照してください。KeyDBもマルチスレッド化されており、一部のアプリケーションではクラスタリングの代替となる場合がありますが、実際にはニーズによって異なります。

手動で、およびcreate-clusterツールを使用してクラスタリングを設定する例もあります。Redisを使用している場合の手順は同じです（「keydb」を「redis」に置き換えてください）

上記の回答への追加情報

Redisクラスター

• Redisクラスターの主な目的の1つは、シャーディングによってデータの負荷を均等または均等に分散することです

• Redisクラスターは一貫したハッシュを使用しませんが、すべてのキーが概念的にハッシュスロットと呼ばれるものの一部である、異なる形式のシャーディングを使用します

• Redisクラスターには16384のハッシュスロットがあり、Redisクラスターのすべてのノードがハッシュスロットのサブセットを担当します。たとえば、3つのノードを持つクラスターがあるとします。

  ノードAには0〜5500のハッシュスロットが含まれ、ノードBには5501〜11000のハッシュスロットが含まれ、ノードCには11001〜16383のハッシュスロットが含まれます

これにより、クラスター内のノードを簡単に追加および削除できます。たとえば、新しいノードDを追加する場合、ノードA、B、CからDにハッシュスロットを移動する必要があります

• Redisクラスターはマスター/スレーブ構造をサポートしています。クラスターの作成時にマスターA、B、CとともにスレーブA1、B1、C2を作成できるため、マスターBがダウンするとスレーブB1がマスターとして昇格します。

Redisクラスターを使用する場合、追加のフェイルオーバー処理は必要ありません。また、Sentinelインスタンスをクラスターノードのいずれかに向けないでください。

では、実用的には、Redis Clusterで何が得られますか？

1.複数のノード間でデータセットを自動的に分割する機能。

2.ノードのサブセットで障害が発生した場合、またはクラスターの残りの部分と通信できない場合に操作を続行する機能。

Redis Sentinel

• Redisは、マスターノードからデータを複製する複数のスレーブをサポートしています。
• これにより、マスターノードのデータのバックアップが提供されます。
• Redis Sentinelは、マスターとスレーブを管理するために設計されたシステムです。別のプログラムとして実行されます。理想的なシステムで必要な最小センチネル数は3です。これらのセンチネルは相互に通信し、マスターが生きていることを確認します。生きていない場合は、スレーブの1つをマスターとして昇格させるため、後でデッドノードがスピンアップしたときに新しいマスターのスレーブとして機能する
• クォーラムは構成可能です。基本的には、マスターがダウンしているときに同意する必要があるセンチネルの数です。N / 2 +1は同意する必要があります。Nはポッド内のノードの数です（この設定はポッドと呼ばれ、クラスターではないことに注意してください）

それでは、実際的には、Redis Sentinelで何が得られますか？

マスターが常に利用可能であることを確認します（マスターがダウンした場合、スレーブはマスターとして昇格されます）

参照 ：

https://fnordig.de/2015/06/01/redis-sentinel-and-redis-cluster/

https://redis.io/topics/cluster-tutorial