Redis センチネル

本番環境に Redis インスタンスが 1 つしかなく、何らかの理由である時点で失敗するシナリオを想定します。あなたのアプリケーションはデータを Redis データ ストアにキャッシュしており、唯一のデータ ソースが死んでいます。このようなシナリオを制御する 1 つの方法は、マスター ノードが戻ってくるまでスレーブがマスター ノードを複製できるマスター/スレーブ アーキテクチャを維持することです。 Redis クラスターは、マスター/レプリカ アプローチにより、ある程度の高可用性をサポートします。 Redis Sentinel は、Redis インスタンスの高可用性を維持するためのより信頼性の高い方法を提供する別のアプローチです。 Redis マスター ノードの障害を監視し、既存のスレーブ ノードを新しいマスターに昇格させるフェイルオーバー プロセスを直ちにトリガーします。

さらに、Redis センチネルは、クライアントが接続して最新のマスター ノード IP アドレスを要求する仲介者として機能します。そのため、接続されたセンチネルはすぐにマスター ノード アドレスを提供します。

さらに、複数のセンチネルが特定のマスターに到達できない、または使用できないことに同意した場合、マスター ノードの障害が確認されます。これで障害検出フェーズが終了し、フェイルオーバー プロセスがすぐに開始されます。したがって、Redis センチネルは、特定のプロパティを持つ分散システムと見なすことができます。

センチネルの合意は、次のセクションで説明するクォーラム値に基づいています。

誰の価値

Quorum 値は、マスター ノードがダウンしたときに合意する必要があるセンチネルの最大数です。この値は、マスター ノードの障害を識別するためにのみ使用されます。フェイルオーバー プロセスは、使用可能な複数のセンチネル ノードの承認から始まり、選択されたセンチネルをリーダーとして続行します。

Redis Sentinel の機能

センチネルは、Redis データ ストアに高可用性メカニズムを提供することで知られています。それとは別に、他のいくつかの機能をリストできます。

• Sentinel は、Redis システムのマスター ノードとスレーブ ノードのステータスを継続的に監視します。
• Redis インスタンスに障害や問題が発生した場合、センチネルは管理者または接続されたアプリケーションにセンチネル API を使用して通知できます。
• フェイルオーバー フェーズは、レプリカを新しいマスターとして昇格させることにより、センチネルによって指示されます。新しいマスターを使用するように構成された残りのレプリカ。最後に、対応するクライアントに新しいマスター ノード アドレスが通知されます。
• また、Redis センチネルは接続されたクライアントの構成プロバイダーであり、クライアントは現在利用可能なマスター インスタンスのアドレスを要求できます。突然の崩壊が発生した場合、センチネルは新しいマスター ノード アドレスをすぐにプッシュするようにコミットされます。

次のセクションでは、Redis センチネルをマスター/レプリカ インスタンスで構成し、センチネル API を使用してノードを監視します。

センチネル構成

まず、ポート 7000 と 7001 に 2 つの Redis インスタンスを作成します。ポート 7000 はマスター ノードになり、もう 1 つはマスターをレプリケートします。両方のインスタンスは、それぞれ次の構成ファイルを使用します。

マスター ノードの構成

スレーブ ノードの構成

両方のインスタンスは、それぞれに関連付けられた構成ファイルを提供することによって開始されます。次のコマンドを使用して、Redis インスタンスを個別に開始できます。

次のように、ポート 7001 で開始された Redis インスタンスに接続してみましょう。

これで、このインスタンスをポート 7000 で実行されているマスターのレプリカにすることができます。REPLICAOF コマンドは次のように使用できます。

予想どおり、ポート 7001 で実行されているインスタンスは、ポート 7000 で実行されているマスターのレプリカ ノードになりました。

これで、上記のマスター インスタンスを監視する 3 つの Redis センチネルを構成する準備が整いました。以下に示すように、ポート 5000、5001、および 5002 で 3 つのセンチネル インスタンスを作成するには、3 つの構成ファイルが必要です。

各 センチネル.conf ポート番号が変更されることを除いて、ファイルは次のようになります。

では、3 つのセンチネルを実行します。へのパスとともに redis-sentinel 実行可能ファイルを使用できます。 センチネル.conf Sentinel インスタンスを作成するための構成ファイル。それ以外の場合は、パスを指定して redis-server 実行可能ファイルを呼び出すことができます センチネル.conf そして旗 –センチネル .

次のコマンドを使用して、各センチネルを開始しましょう。

最初のセンチネルはポート 5000 で開始されました。同様に、他の 2 つのインスタンスも開始できます。

これで、次の図に示すように、Redis センチネルのセットアップが実行されます。

次のセクションでは、Sentinel API と、それを利用して Redis マスター ノードに関連する情報を取得する方法について詳しく説明します。

センチネル API

Redis は、関連するマスターとレプリカを監視し、通知をサブスクライブし、センチネル設定を変更するための別個のセンチネル API を提供します。さらに、いくつかの使用法を以下に示します。

• 監視対象の Redis マスターおよびスレーブ インスタンスのステータスを確認する
• 他のセンチネルの詳細
• フェイルオーバーの際にセンチネルからプッシュ形式の通知を受け取る

SENTINEL コマンドを関連するサブコマンドと共に使用して、Redis センチネルと監視対象ノードのクエリ、更新、または設定を行うことができます。

マスター ノードのステータスを確認する

マスター ノードの状態を時々監視またはチェックすることは非常に重要です。次の Sentinel API コマンドを使用して、マスターの詳細を取得できます。

監視対象マスター名: 前の手順で作成したセンチネル構成ファイルで指定されたマスター ノードの名前。

このコマンドを使用して、セットアップのマスター ステータスを問い合わせてみましょう。この場合、マスター ノード名は 「マスターノード」。

いくつかの情報が取得されており、num-slaves、flag、num-other-sentinels などの重要なものがいくつかあります。

の フラグ プロパティはに設定されています 主人 これは、マスターが健康であることを意味します。マスター ノードがダウンすると、 s_down また o_down フラグが表示されます。プロパティ num-other-sentinels は 2 に設定されています。これは、Redis センチネルがマスター ノードの他の 2 つのセンチネルを既に認識していることを意味します。加えて 数奴隷 プロパティには、マスター ノードで使用可能なレプリカが表示されます。この場合、レプリカが 1 つしかないため、1 に設定されます。

接続されたレプリカに関する情報の取得

次の SENTINEL サブコマンドを使用して、マスター ノードに接続されているレプリカを確認できます。

この例では、マスター名は「masternode」です。

予想どおり、Sentinel はポート 7001 で実行されているスレーブ ノードを検出しました。

関連する Sentinel に関する情報を取得する

同様に、次の SENTINEL サブコマンドを使用して、現在のマスター ノードに関連付けられている他のセンチネルに関連する詳細を照会できます。

この場合、「masternode」という名前のマスター ノードに関連する情報をフェッチします。

マスター ノード アドレスを取得する

前のセクションで説明したように、Redis Sentinel は接続されたクライアントの構成プロバイダーです。そのため、現在実行中のマスター ノードの IP アドレスとポートを要求されたクライアントに提供できます。次の Sentinel API サブコマンドを使用して、前述の情報を取得できます。

次のように、シナリオで上記のコマンドを実行しましょう。

いくつかの Sentinel API コマンドについてのみ説明しました。他にも、sentinel-failover、sentinel info-cache、sentinel masters など、いくつかのサブコマンドを使用できます。さらに、多くのコマンドを管理目的で使用することもできます。次のセクションでは、Redis センチネルのフェイルオーバー プロセスに焦点を当てます。

Sentinel フェイルオーバー プロセス

センチネルが構成されているので、フェイルオーバー フェーズをテストできます。マスター ノードを 300 秒間スリープさせて、マスター ノードの障害をシミュレートします。

ポート 7000 で実行されているマスター ノードは、現在到達できないはずです。したがって、関連付けられたセンチネルは、マスターが使用できないことに気づきます。 +ダウン イベント。次に、これはに設定されます +odown ここで、2 つのセンチネルが、クォーラム値に従ってマスター ノードがダウンしていることを確認します。最後に、フェイルオーバー フェーズが開始され、理想的には、レプリカが新しいマスターに昇格する必要があります。

マスターノードのIPアドレスとポートをもう一度確認しましょう。

予想どおり、以前のレプリカは新しいマスターに昇格されました。これは、センチネル フェールオーバー プロセスが成功したことを意味します。これで、単一のマスター/レプリカ ペアに対する 3 つのセンチネル セットアップの展開とテストが完了しました。

結論

Redis Sentinel は、特定の Redis マスター レプリカ インスタンスの高可用性を確保するための最も信頼できるアプローチです。センチネルは、人間の介入なしで自動フェイルオーバーを監視、通知、および開始できます。また、複数のセンチネルは、マスター ノードに到達できないという事実について同意し、クォーラム値は、マスター インスタンスの可用性をチェックするときに合意する必要があるセンチネルの最大数として使用されます。 Redis Sentinel は、マスター ノードと関連するレプリカの状態に関する情報を取得し、管理タスクも実行するための使いやすい API を提供します。