超包括的な Redis 分散高可用性ソリューション: Sentinel メカニズム

開発作業において、分散キャッシュ高可用性ソリューション（Redis キャッシュ高可用性ソリューションの構築）の場合、Redis マスタースレーブアーキテクチャの高可用性はどのように確保されますか?

Redis Sentinel は、Redis に高可用性ソリューションを提供する分散システムであることがわかっています。では、Redis サービス展開のセンチネル モードの主な原則と、それが解決する問題は何でしょうか。そこで私は関連する問題を整理するために時間を費やしました。この記事を読んだ後、あなたもその技術を他の人と共有できるようになると信じています。 O(∩_∩)O ハハハ〜

0. 問題の準備

センチネル モードについて説明する前に、まずアプリケーションの問題、つまり Redis サービス ホストがクラッシュするケースを見てみましょう。

実際の使用では、マスターがクラッシュする可能性があります (書き込みサービスがなくなり、読み取りサービスのみになります)。サービスの可用性を確保したい場合は、他のスレーブ ノードの 1 つをマスター ノードとして選択し、サービス機能を継続的に提供する必要があります。

主なアクションは次のように抽象化されます。

• ダウンしたマスターをオフラインにする

• 奴隷を主人として見つける

• すべてのスレーブに新しいマスターに接続するように通知します

• 完全または部分的なデータ同期

いくつかの問題があります:

• マスターがダウンしたことを誰が確認するのでしょうか? (ネットワークがしばらく不安定な場合は、シャットダウンされますか?)

• 奴隷に代わる主人をどうやって見つけるか、そして誰が見つけるか?どうやって見つけるのですか?根拠は何ですか?

• 構成を変更した後に元のマスターを復元する場合はどうすればよいですか?

実際、センチネルメカニズムを導入することで、上記の問題を非常にうまく解決できます。

Sentinel - Redis クラスター

1. Sentinel とは何ですか?

Sentinel は Redis の高可用性ソリューションです。1 つ以上の Sentinel インスタンスで構成される Sentinel システムは、任意の数のマスター サービスとこれらのマスター サーバーの下にあるすべてのスレーブ サービスを監視し、監視対象のマスター サービスがオフラインになった (サービス提供が不可能になった) ときに、オフライン マスター サーバーの下にあるスレーブ サーバーを新しいマスター サーバーに自動的にアップグレードできます。

Sentinel の役割を要約すると次のようになります。

• クラスター監視

マスターとスレーブが正常に動作しているかを常時チェック（マスター生存検出、マスターとスレーブの動作状態検出）

• メッセージ通知

監視対象サーバーで問題が発生すると、他のセンチネルとクライアントに通知が送信されます。

• 自動フェイルオーバー

障害が発生したマスターをスレーブから切断し、スレーブを新しいマスターとして選択し、他のスレーブを新しいマスターに接続して、クライアントに新しいサーバー アドレスを通知します。

注: Sentinel も Redis サーバーですが、データ サービスは提供しません。通常、設定されるセンチネルの数は奇数です。

2. Sentinelの仕組み

以下では、主に、フェイルオーバー プロセス中に Sentinel が実行する 3 つの段階について説明します。

2.1.クラスター監視

ステップ1: Sentinel 1がRedisクラスターに接続する

• info コマンドをマスターに送信し、cmd 接続を確立します。

• センチネル側はセンチネルステータス (SentinelStatus) を保存し、すべてのセンチネルステータス、マスターノード、スレーブノードの情報を保存します。マスター側はRedisインスタンス情報（SentinelRedisInstance）を記録します。

• センチネルはマスターから取得した各スレーブの情報に基づいて各スレーブに接続し、同じ info コマンドを送信します。

クラスター監視

ステップ2: Sentinel 2が参加した後

• info コマンドもマスター ノードに送信され、cmd 接続が確立されます。

• マスターには他のセンチネルノードに関する情報が含まれており、センチネル情報は Sentinel 2 に保存されていることがわかります (Sentinel 1 との違いは、Sentinel 1 と Sentinel 2 の 2 つのセンチネルノードの情報を保存することです)。

• 各センチネルの情報の一貫性を確保するために、センチネル間にパブリッシュ/サブスクライブ メカニズムが確立されます。センチネル間の長期的な情報の対称性を維持するために、センチネルは相互に ping コマンドも送信します。

クラスター監視

ステップ3: Sentinel 3が参加した後

• Sentinel 1 と 2 でも同じアクションが実行されます。info コマンドがマスター ノードに送信され、cmd 接続が確立されます。

• Sentinel 1とSentinel 2間の情報が同期されていることを確認するために、パブリッシュサブスクライブキューが確立されます（pingコマンドを相互に送信できます）

クラスター監視

簡単な要約:

• センチネルはマスター、スレーブ、および他のセンチネルからステータスを取得します。

• センチネルは「対応するチャネル」を形成し、情報を公開、サブスクライブ、受信、同期します。

2.2.メッセージ通知

1) センチネルノードは、マスター/スレーブノードによって確立されたcmd接続を通じて動作ステータスを取得します。

2) フィードバックを受け取った後、SentinelはSentinel内で情報を伝達します。

メッセージ通知

2.3.フェイルオーバー

厳密に言えば、フェイルオーバーは障害判定とフェイルオーバーの 2 つのステップに分けられます。

Q1: ノードに障害があるかどうかをどのように判断しますか?

• センチネルは常にマスターノードにpublish sentinel: helloを送信します。

マスターノードが失敗するまで、センチネルは sdown を報告し、同時に、このセンチネルはマスターノードがハングアップしたことを知らせるメッセージを他のセンチネルにも送信します。送信されるコマンドは sentinel is-master-down-by-address-port です。

• 残りのセンチネルがコマンドを受信した後、マスターノードはクラッシュしましたか?ハングしているかどうか確認させてください。送信したメッセージもhelloです。

残りのセンチネルも、受け取った情報を送信し、コマンド sentinel is-master-down-by-address-port を自身のイントラネットに送信して、sentinel is-master-down-by-address-port を送信した最初のセンチネルが、その通りで、この男は確かに死んでいると言っていることを確認します。

• マスターノードがダウンしていると全員が判断すると、そのステータスは odown に変更されます。

1 つのセンチネルがマスター ノードがダウンしていると判断した場合、そのノードは sdown としてマークされ、センチネルの半数がダウンしていると判断した場合、そのノードは odown としてマークされます。

1 つのセンチネルがマスター ノードがダウンしていると判断した場合、それは主観的ダウン (sdown) と呼ばれ、半数以上のセンチネルがマスター ノードがダウンしていると判断した場合、それは客観的ダウン (odown) と呼ばれます。

Q2: フェイルオーバーを実行するにはどうすればいいですか?

1) まず、センチネルはフェイルオーバーを処理するセンチネルリーダーを選出します

今回使用される選出方法は、以前にも導入されたRaftプロトコルです。興味のある学生は、コンセンサスアルゴリズムRaftの簡単な入門をご覧ください。

2) 次に、センチネルリーダーはスレーブノードの1つをマスターノードとして選択します。

主なルール:

• オンラインノードを選択し、オフラインノードを渡します。

• 応答速度が速いノードを選択し、応答速度が遅いノードは通過させます。

• 元のマスターから切断時間が最も短いものを選択し、切断時間が長いものを渡します。

上記の優先事項が一貫している場合は、他の優先事項も考慮されます。

• 大きなオフセット

スレーブ 1 のオフセットが 50 で、スレーブ 2 のオフセットが 55 の場合、センチネルはスレーブ 2 を新しいマスター ノードとして選択します。

• ルニッドは大きすぎる

これは職場の年功序列制度に似ており、つまり、ルニッドの作成時間によって判断すると、作成時間が早い人が最初に昇進します。

3) データ転送

• 新しい主人が就任: センチネルは誰もいない奴隷を新しい主人に送り込む

• 他のスレーブはこれを認識しています: 新しいマスターIPポートのスレーブを他のスレーブに送信します

3. 結論

Redis のマスタースレーブレプリケーション機能には「マスタースレーブレプリケーションは高可用性の礎」という格言があり、高可用性を実現するにはセンチネルとクラスターが不可欠です。

3.1 センチネルの役割

• クラスター監視

マスターとスレーブが正常に動作しているかを常時チェック（マスター生存検出、マスターとスレーブの動作状態検出）

• メッセージ通知

監視対象サーバーで問題が発生すると、他のセンチネルとクライアントに通知が送信されます。

• 自動フェイルオーバー

障害が発生したマスターをスレーブから切断し、スレーブを新しいマスターとして選択し、他のスレーブを新しいマスターに接続して、クライアントに新しいサーバー アドレスを通知します。

3.2 センチネルの仕組み

• 各 Sentinel は、マスター、スレーブ、および認識している他の Sentinel インスタンスに 1 秒ごとに PING コマンドを送信します。

• インスタンスの PING コマンドに対する最後の有効な応答からの時間が down-after-milliseconds オプションで指定された値を超えると、インスタンスは Sentinel によって主観的にオフラインとしてマークされます。

マスターが Sentinel の PING コマンドに対して再度有効な応答を返すと、マスターの主観的なオフライン ステータスは削除されます。

• マスターが主観的にオフラインとしてマークされている場合、このマスターを監視しているすべてのセンチネルは、マスターが実際に主観的にオフライン状態になったことを 1 秒に 1 回確認する必要があります。

• 十分な数のセンチネル (>= 構成ファイルで指定された値) が、指定された時間範囲内でマスターが実際に主観的オフライン状態に入ったことを確認すると、マスターは客観的にオフラインとしてマークされます。

マスターがオフラインであることに同意するセンチネルが十分にいない場合、マスターの客観的なオフライン ステータスは削除されます。

• 通常、各 Sentinel は、10 秒ごとにすべての既知のマスターとスレーブに INFO コマンドを送信します。

• マスターが Sentinel によってオフラインとしてマークされると、オフライン マスターのすべてのスレーブに Sentinel が INFO コマンドを送信する頻度が 10 秒に 1 回から 1 秒に 1 回に変更されます。