Redis Advanced Learning 高可用性 Sentinel (概要共有)

この記事では、関数アーキテクチャ、デプロイ、構成に関する問題など、Redis の高可用性センチネルに関する関連知識を提供します。皆様のお役に立てれば幸いです。

推奨学習: Redis ビデオ チュートリアル

1. 関数と構造

1. 関数

Sentinel を紹介する前に、まず Redis の高可用性に関連するテクノロジーをマクロの観点から確認してみましょう。それらには、永続性、レプリケーション、センチネル、クラスターが含まれます。それらの主な機能と解決される問題は次のとおりです:

• 永続性: 永続性は最も単純な高可用性の方法です (高可用性を実現する手段として分類されていない場合もあります) 、その主な機能はデータのバックアップ、つまりプロセスの終了によってデータが失われないようにデータをハードディスクに保存することです。
• レプリケーション: レプリケーションは高可用性 Redis の基盤であり、Sentinel とクラスターはどちらもレプリケーションに基づいて高可用性を実現します。レプリケーションは主に、データのマルチマシン バックアップと、読み取り操作の負荷分散と単純な障害回復を実装します。欠点: 障害回復は自動化できません。書き込み操作の負荷分散はできません。ストレージ容量は 1 台のマシンによって制限されます。
• Sentinel: Sentinel はレプリケーションに基づいて、自動障害回復を実装します。欠点: 書き込み操作は負荷分散できず、ストレージ容量は 1 台のマシンによって制限されます。
• クラスター: Redis はクラスター化を通じて、書き込み操作の負荷分散ができず、ストレージ容量が単一マシンによって制限されるという問題を解決し、比較的完全な高可用性ソリューションを実装します。

見張りについて話しましょう。

Redis Sentinel、Redis Sentinel は、Redis バージョン 2.8 で導入されました。 Sentinel の中核機能は、マスター ノードの自動フェイルオーバーです。 以下は Redis 公式ドキュメントの Sentinel 機能の説明です:

• 監視: Sentinel はマスター ノードとスレーブ ノードが正常に動作しているかどうかを継続的にチェックします。
• 自動フェイルオーバー: マスター ノードが正常に動作しない場合、Sentinel は自動フェイルオーバー操作を開始します。障害が発生したマスター ノードのスレーブ ノードの 1 つを新しいマスター ノードにアップグレードし、もう 1 つのスレーブ ノードを新しいマスター ノードにアップグレードします。スレーブ ノードは、新しいマスター ノードを複製するように変更されます。
• 構成プロバイダー: 初期化中に、クライアントはセンチネルに接続することにより、現在の Redis サービスのマスター ノード アドレスを取得します。
• 通知: Sentinel はフェイルオーバー結果をクライアントに送信できます。

このうち、監視機能と自動フェイルオーバー機能により、Sentinel はマスター ノードの障害を適時に検出して転送を完了できますが、構成プロバイダーと通知機能はクライアントとの対話に反映する必要があります。

記事内での「クライアント」という言葉の使用方法について説明します。 前の記事では、API を介して Redis サーバーにアクセスする限り、redis サーバーも含めてクライアントと呼ばれます。 cli と Java クライアント。Jedis など。区別と説明を容易にするために、この記事のクライアントには redis-cli は含まれていませんが、redis-cli よりも複雑です。redis-cli は、redis によって提供される基盤となるインターフェイスを使用します。一方、クライアントは、Sentinel の構成プロバイダーと通知機能を最大限に活用するために、カプセル化されたこれらのインターフェイスと関数を使用します。

2. アーキテクチャ

典型的なセンチネル アーキテクチャ図は次のとおりです:

これは、センチネル ノードとデータ ノード :

• センチネル ノード: センチネル システムは 1 つ以上のセンチネル ノードで構成されます。センチネル ノードは、データを保存しない特別な Redis ノードです。
• データ ノード: マスター ノードとスレーブ ノードは両方ともデータ ノードです。

2. デプロイメント

このパートでは、1 つのマスター ノード、2 つのスレーブ ノード、3 つのセンチネル ノードを含む単純なセンチネル システムをデプロイします。便宜上、これらすべてのノードは 1 台のマシン (LAN IP: 192.168.92.128) に展開され、ポート番号で区別され、ノードの構成は可能な限り簡素化されています。

1. マスター/スレーブ ノードの展開

Sentinel システムのマスター/スレーブ ノードは、通常のマスター/スレーブ ノードと同じように構成されており、追加の構成は必要ありません。以下にマスターノード (ポート=6379) と 2 つのスレーブノード (ポート=6380/6381) の設定ファイルを示しますが、構成は比較的単純なので詳細な説明は省略します。

#redis-6379.conf
port 6379
daemonize yes
logfile "6379.log"
dbfilename "dump-6379.rdb"
#redis-6380.conf
port 6380
daemonize yes
logfile "6380.log"
dbfilename "dump-6380.rdb"
slaveof 192.168.92.128 6379
#redis-6381.conf
port 6381
daemonize yes
logfile "6381.log"
dbfilename "dump-6381.rdb"
slaveof 192.168.92.128 6379

redis-server redis-6379.conf
redis-server redis-6380.conf
redis-server redis-6381.conf

ノード起動後、マスターノードに接続し、マスター/スレーブの状態が正常か確認してください。構成が完了したら、マスター ノードとスレーブ ノードを順番に起動します:

2. センチネル ノードのデプロイ

センチネル ノードは本質的に特別な Redis ノードです。

3 つのセンチネル ノードの構成はほぼ同じです。主な違いはポート番号 (26379/26380/26381) です。以下では、26379 ノードを例として構成と起動方法を紹介します。ノードの構成部分は可能な限り簡略化されており、詳細な構成は後で紹介します。

#sentinel-26379.conf
port 26379
daemonize yes
logfile "26379.log"
sentinel monitor mymaster 192.168.92.128 6379 2

哨兵节点的启动有两种方式，二者作用是完全相同的：其中，sentinel monitor mymaster 192.168.92.128 6379 2 配置的含义是：该哨兵节点监控192.168.92.128:6379这个主节点，该主节点的名称是mymaster，最后的2的含义与主节点的故障判定有关：至少需要2个哨兵节点同意，才能判定主节点故障并进行故障转移。

redis-sentinel sentinel-26379.conf
redis-server sentinel-26379.conf --sentinel

3. 总结

按照上述方式配置和启动之后，整个哨兵系统就启动完毕了。可以通过redis-cli连接哨兵节点进行验证

哨兵系统的搭建过程，有几点需要注意：

（1）哨兵系统中的主从节点，与普通的主从节点并没有什么区别，故障发现和转移是由哨兵来控制和完成的。

（2）哨兵节点本质上是redis节点。

（3）每个哨兵节点，只需要配置监控主节点，便可以自动发现其他的哨兵节点和从节点。

（4）在哨兵节点启动和故障转移阶段，各个节点的配置文件会被重写(config rewrite)。

三、客户端访问哨兵系统

上一小节演示了哨兵的两大作用：监控和自动故障转移，本小节则结合客户端演示哨兵的另外两个作用：配置提供者和通知。

1. 代码示例

在介绍客户端的原理之前，先以Java客户端Jedis为例，演示一下使用方法：下面代码可以连接我们刚刚搭建的哨兵系统，并进行各种读写操作（代码中只演示如何连接哨兵，异常处理、资源关闭等未考虑）。

public static void testSentinel() throws Exception {
         String masterName = "mymaster";
         Set<String> sentinels = new HashSet<>();
         sentinels.add("192.168.92.128:26379");
         sentinels.add("192.168.92.128:26380");
         sentinels.add("192.168.92.128:26381");
         JedisSentinelPool pool = new JedisSentinelPool(masterName, sentinels); //初始化过程做了很多工作
         Jedis jedis = pool.getResource();
         jedis.set("key1", "value1");
         pool.close();
}

Jedis客户端对哨兵提供了很好的支持。如上述代码所示，我们只需要向Jedis提供哨兵节点集合和masterName，构造JedisSentinelPool对象；然后便可以像使用普通redis连接池一样来使用了：通过pool.getResource()获取连接，执行具体的命令。2. 客户端原理

在整个过程中，我们的代码不需要显式的指定主节点的地址，就可以连接到主节点；代码中对故障转移没有任何体现，就可以在哨兵完成故障转移后自动的切换主节点。之所以可以做到这一点，是因为在JedisSentinelPool的构造器中，进行了相关的工作；主要包括以下两点：

（1）遍历哨兵节点，获取主节点信息：遍历哨兵节点，通过其中一个哨兵节点+masterName获得主节点的信息；该功能是通过调用哨兵节点的sentinel get-master-addr-by-name命令实现，该命令示例如下：

一旦获得主节点信息，停止遍历（因此一般来说遍历到第一个哨兵节点，循环就停止了）。

（2）增加对哨兵的监听：这样当发生故障转移时，客户端便可以收到哨兵的通知，从而完成主节点的切换。具体做法是：利用redis提供的发布订阅功能，为每一个哨兵节点开启一个单独的线程，订阅哨兵节点的+switch-master频道，当收到消息时，重新初始化连接池。

3. 总结

通过客户端原理的介绍，可以加深对哨兵功能的理解：

（1）配置提供者：客户端可以通过哨兵节点+masterName获取主节点信息，在这里哨兵起到的作用就是配置提供者。

需要注意的是，哨兵只是配置提供者，而不是代理。二者的区别在于：如果是配置提供者，客户端在通过哨兵获得主节点信息后，会直接建立到主节点的连接，后续的请求(如set/get)会直接发向主节点；如果是代理，客户端的每一次请求都会发向哨兵，哨兵再通过主节点处理请求。

举一个例子可以很好的理解哨兵的作用是配置提供者，而不是代理。在前面部署的哨兵系统中，将哨兵节点的配置文件进行如下修改：

sentinel monitor mymaster 192.168.92.128 6379 2
改为
sentinel monitor mymaster 127.0.0.1 6379 2

（2）通知：哨兵节点在故障转移完成后，会将新的主节点信息发送给客户端，以便客户端及时切换主节点。然后，将前述客户端代码在局域网的另外一台机器上运行，会发现客户端无法连接主节点；这是因为哨兵作为配置提供者，客户端通过它查询到主节点的地址为127.0.0.1:6379，客户端会向127.0.0.1:6379建立redis连接，自然无法连接。如果哨兵是代理，这个问题就不会出现了。

四、基本原理

前面介绍了哨兵部署、使用的基本方法，本部分介绍哨兵实现的基本原理。

1. Sentinel ノードがサポートするコマンド

Sentinel ノードは特別なモードで実行される Redis ノードとして、通常の Redis ノードとは異なるコマンドをサポートします。運用と保守では、これらのコマンドを使用して Sentinel システムのクエリや変更を行うことができますが、より重要なのは、Sentinel システムが障害検出やフェイルオーバーなどのさまざまな機能を実装するために、Sentinel ノード間の通信と切り離せないことです。通信は非常に複雑です。そのほとんどは、センチネル ノードによってサポートされるコマンドを通じて実現されます。以下にセンチネルノードがサポートする主なコマンドを紹介します。

(1) 基本クエリ: これらのコマンドを通じて、Sentinel システムのトポロジ、ノード情報、構成情報などをクエリできます。

• info Sentinel: すべての監視対象マスター ノードの基本情報を取得します。
• sentinel masters: すべての監視対象マスター ノードの詳細情報を取得します。
• sentinel master mymaster: 詳細情報を取得します。監視対象のマスターノードの mymaster
• sentinel SLAVES mymaster: 監視対象のマスターノードの詳細情報の取得 mymaster のスレーブノード
• sentinel Sentinels mymaster: 監視対象のマスターノードの取得 mymaster の Sentinel ノードの詳細情報
• sentinel get-master-addr-by-name mymaster: 以前紹介した監視対象のマスターノード mymaster のアドレス情報を取得します
• sentinel is-master-down-by-addr : Sentinel ノードこのコマンドを使用して、マスターノードがオフラインかどうかを尋ね、客観的にオフラインかどうかを判断できます。

(2) マスターノードの監視の追加/削除

センチネル監視mymaster2 192.168.92.128 16379 2: この機能は、センチネル ノードをデプロイする際の設定ファイル内のセンチネル モニター機能とまったく同じであるため、詳細な説明は省略します。

sentinel Remove mymaster2: 監視をキャンセルします。現在のセンチネル ノードによるマスター ノード mymaster2

(3) 強制フェイルオーバー

センチネル フェイルオーバー mymaster: このコマンドは、mymaster# でフェイルオーバーを強制的に実行できます。 ##, 現在のマスターノードが正常に稼働している場合でも、たとえば、現在のマスターノードが配置されているマシンが廃棄されそうになっている場合、failover コマンドを使用して事前にフェイルオーバーを実行できます。 2. 基本原則

セントリーの原則に関して重要なのは、次の概念を理解することです。

(1) スケジュールされたタスク: 各センチネル ノードは 3 つのスケジュールされたタスクを維持します。スケジュールされたタスクの機能は、マスタースレーブノードにinfoコマンドを送信して最新のマスタースレーブ構造を取得、パブリッシュ＆サブスクライブ機能により他のセンチネルノードの情報を取得、pingを送信してハートビート検出を実行します。他のノードにコマンドを送信して、それらがオフラインかどうかを判断します。

(2) 主観的オフライン: ハートビート検出のスケジュールされたタスクにおいて、他のノードが一定時間応答しない場合、センチネル ノードはそれらを主観的にオフラインにします。名前が示すように、主観的オフラインとはセンチネル ノードが「主観的に」オフラインを判断することを意味し、主観的オフラインに相当するのは客観的オフラインです。

(3) オフラインの目的: センチネル ノードがマスター ノードから主観的にログオフした後、センチネル is-master-down-by-addr コマンドを通じて他のセンチネル ノードにマスター ノードのステータスを問い合わせます。マスターノード上でオフラインになったセンチネルの数が一定の値に達すると、マスターノードは客観的にオフラインになります。

目標オフラインはマスター ノードにのみ存在する概念であることに注意してください。スレーブ ノードとセンチネル ノードに障害が発生した場合、センチネルによって主観的にオフラインになった後は、その後の目標オフラインは存在しません。 . ラインとフェイルオーバー操作。

(4) リーダー センチネル ノードの選出: マスター ノードが客観的にオフラインであると判断されると、各センチネル ノードはリーダー センチネル ノードを選出するためにネゴシエートし、リーダー ノードはフェイルオーバー操作を実行します。

マスター ノードを監視しているすべてのセンチネルがリーダーとして選出される可能性があります。選出に使用されるアルゴリズムは Raft アルゴリズムです。Raft アルゴリズムの基本的な考え方は、早い者勝ちです。選挙の 1 ラウンド、センチネル A リーダーになる申請書を B に送信します。B が他のセンチネルに同意していない場合は、A がリーダーになることに同意します。選挙の具体的なプロセスについてはここでは詳しく説明しませんが、一般的に言えば、センチネルの選出プロセスは非常に速く、オフラインで最初に目標を達成した人が通常リーダーになります。

(5) フェイルオーバー: 選出されたリーダー センチネルはフェイルオーバー操作を開始します。これは大きく 3 つのステップに分けることができます:

新しいスレーブ ノードを選択します。 マスター ノード: 選択の原則は次のとおりです。最初に異常なスレーブ ノードをフィルタリングして除外します。次に、最高の優先順位 (slave-priority で指定) を持つスレーブ ノードを選択します。優先順位を区別できない場合は、レプリケーション オフセットが最大のスレーブ ノードを選択します。それでも区別できない場合は、最小の runid を持つスレーブ ノード。

• マスター/スレーブ ステータスの更新: 選択したスレーブ ノードをマスター ノードにするには、slaveof no one コマンドを使用します。また、他のノードをそのスレーブ ノードにするには、slaveof コマンドを使用します。
• オフラインのマスター ノード (つまり 6379) を新しいマスター ノードのスレーブ ノードとして設定します。6379 がオンラインに戻ると、新しいマスター ノードのスレーブ ノードになります。
• 5. 構成と実践的な提案

1. 構成

以下では、Sentinel に関連するいくつかの構成を紹介します。

(1) センチネル モニター {masterName} {masterIp} {masterPort} {quorum}

センチネル モニターはセンチネルのコア構成です。前回のセンチネル ノードのデプロイ時に説明しました。そのうち、masterName はマスター ノード名を指定し、masterIp と masterPort はマスター ノードのアドレスを指定します。クォーラムはマスター ノードのオフラインの目標を決定するセンチネル 数量しきい値: マスター ノードがオフラインであると決定するセンチネルの数がクォーラムに達すると、マスター ノードは客観的にオフラインになります。推奨値は、センチネルの数の半分に 1 を加えた値です。

(2) センチネル ダウンアフター ミリ秒 {マスター名} {時間}

センチネル ダウンアフター ミリ秒は主観的なオフラインの判断に関連しています。センチネルは ping コマンドを使用して実行します。他のノードのハートビート検出。ダウンアフターミリ秒で設定された時間が経過しても他のノードが応答しない場合、Sentinel は主観的にそれらのノードをオフラインにします。この構成は、マスター ノード、スレーブ ノード、センチネル ノードの主観的なオフラインの決定に有効です。

ダウンアフターミリ秒のデフォルト値は 30000、つまり 30 秒です。さまざまなネットワーク環境やアプリケーション要件に応じて調整できます。値が大きいほど、主観的なオフラインの判断が緩くなり、利点が得られます。は判断ミスである可能性は低いですが、障害発見やフェイルオーバーに時間がかかり、クライアントの待ち時間も長くなってしまうデメリットがあります。たとえば、アプリケーションに高可用性要件がある場合は、障害が発生したときにできるだけ早く転送を完了するために値を適切に下げることができます。また、ネットワーク環境が比較的劣悪な場合は、頻繁な誤判断を避けるためにしきい値を適切に増やすことができます。

(3) SentinelParallel-syncs {masterName} {number}

sentinelParallel-syncs は、フェイルオーバー後のスレーブ ノードのレプリケーションに関連しています。これは、レプリケーションが開始されるたびに、次のように指定します。新しいマスター ノード レプリケーション操作のスレーブ ノードの数。たとえば、マスター ノードの切り替えが完了した後、3 つのスレーブ ノードが新しいマスター ノードへのレプリケーションを開始したいとします。Parallel-syncs=1 の場合、スレーブ ノードは 1 つずつレプリケーションを開始します。Parallel-syncs=3 の場合、次に 3 つのスレーブ ノード ノードは一緒に複製を開始します。

Parallel-syncs の値が大きいほど、スレーブ ノードがレプリケーションを完了するまでの時間が速くなりますが、マスター ノードのネットワーク負荷とハードディスク負荷への負荷が大きくなります。それに応じて設定する必要があります。実際の状況に。たとえば、マスター ノードの負荷が低く、スレーブ ノードのサービス可用性要件が高い場合は、Parallel-syncs 値を適切に増やすことができます。並列同期のデフォルト値は 1 です。

(4) Sentinel fadeover-timeout {masterName} {time}

sentinel fadeover-timeout はフェイルオーバーのタイムアウトの判定に関係しますが、このパラメータはフェイルオーバーのタイムアウトの判定には使用されません。フェイルオーバー フェーズ全体、ただしそのサブステージのいくつかでタイムアウトが発生します。たとえば、マスター ノードがスレーブ ノードを昇格させる時間がタイムアウトを超えた場合、またはスレーブ ノードが新しいマスターへのレプリケーション操作を開始する時間を超えた場合などです。ノード (データのコピー時間を除く) がタイムアウトを超えると、フェイルオーバー タイムアウトが発生します。

failover-timeout のデフォルト値は 180000、つまり 180 秒です。タイムアウトすると、次回は元の値の 2 倍になります。

(5) 上記パラメータ以外にも、セキュリティ検証に関するパラメータなど、ここでは紹介しませんがいくつかのパラメータがあります。

2. 実践的な提案

(1) センチネル ノードの数は複数である必要がありますが、一方ではセンチネル ノードの冗長性を高めてセンチネル自体の負荷が高くなるのを防ぎます。 -可用性のボトルネック、一方でセンチネルノードの数が減少する オフラインでの誤った判断。さらに、これらの異なるセンチネル ノードは異なる物理マシンに展開する必要があります。

(2) センチネル ノードの数は、センチネルが投票を通じて「決定」(リーダー選出に関する決定、オフラインでの目標に関する決定など) を行えるようにするために、奇数である必要があります。

(3) 各センチネル ノードの構成は、ハードウェア、パラメータなどを含め、一貫している必要があります。また、正確で一貫した時刻を保証するために、すべてのノードが ntp または同様のサービスを使用する必要があります。

(4) Sentinel の構成プロバイダーと通知クライアント機能には、前述の Jedis などのクライアント サポートを実装する必要があります。開発者が使用するライブラリが対応するサポートを提供していない場合、開発者は自分で実装する必要がある場合があります。

(5) Sentinel システムのノードが Docker (またはポート マッピングを実行する可能性のあるその他のソフトウェア) にデプロイされている場合、ポート マッピングによって Sentinel システムが失敗する可能性があるという事実に特別な注意を払う必要があります。 Sentinel の動作は他のノードとの通信に基づいており、Docker のポート マッピングにより Sentinel が他のノードに接続できなくなる可能性があるため、正常に動作します。たとえば、センチネルによる相互の検出は、センチネルが外部に宣言した IP とポートに依存します。センチネル A がポート マッピングを使用して Docker にデプロイされている場合、他のセンチネルは、A によって宣言されたポートを使用して A に接続できません。

6. 概要

この記事では、まず Sentinel の役割 (監視、フェイルオーバー、構成プロバイダー、通知) を紹介し、次に Sentinel システムの展開方法とクライアント メソッドを介した Sentinel システムへのアクセスについて説明します。次に、センチネル実装の基本原則を簡単に説明し、最後にセンチネルの実践に関するいくつかの提案を示します。

マスター/スレーブ レプリケーションに基づいて、Sentinel はマスター ノードの自動フェイルオーバーを導入し、Redis の高可用性をさらに向上させますが、Sentinel の欠点も明らかです: Sentinel はスレーブ ノードを自動的にフェイルオーバーできません。読み書き分離シナリオでは、スレーブ ノードに障害が発生すると読み取りサービスが利用できなくなるため、スレーブ ノードで追加の監視と切り替え操作を実行する必要があります。

さらに、Sentinel は、書き込み操作の負荷分散ができず、ストレージ容量が 1 台のマシンによって制限されるという問題をまだ解決していません。これらの問題を解決するには、クラスターの使用が必要です。これについては、後で紹介します。後の記事です。ご注目ください。

推奨学習: 「Redis ビデオ チュートリアル 」、「2022 年の最新 Redis 面接の質問と回答 」

以上がRedis Advanced Learning 高可用性 Sentinel (概要共有)の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。