まず、SentinelはRedisのロードバランサーまたはプロキシではありません。
第二に、すべての失敗がホストの死であるわけではありません。サーバーが一時的にハングしたり、ネットワークケーブルが外れたりすることがあります。このため、Redisインスタンスと同じホストでSentinelを実行することはお勧めできません。 Sentinelを使用してフェイルオーバーを管理している場合、Redisマスターとスレーブ以外のノードで実行されている3つ未満のセンチネルが問題を求めています。
Sentinelは、クォーラムメカニズムを使用して、フェイルオーバーとスレーブに投票します。センチネルが2つ未満の場合、2つ以上のRedisサーバーがマスターであると見なすスプリットブレインのリスクがあります。
2台のサーバーを実行し、それぞれでセンチネルを実行するシナリオを想像してみてください。 1つを失うと、信頼できるフェイルオーバー機能が失われます。
クライアントは、現在のマスター接続情報を学習するためにのみSentinelに接続します。クライアントが接続を失うたびに、このプロセスを繰り返します。 SentinelはRedisのプロキシではありません-Redisのコマンドは直接Redisに送られます。
Sentinelを3つ未満のセンチネルで実行する唯一の信頼できる理由は、サービスディスカバリのためです。つまり、フェイルオーバー管理にSentinelを使用しないことを意味します。
2つのホストシナリオを考えてみましょう：
Host A: redis master + sentinel 1 (Quorum 1)
Host B: redis slave + sentinel 2 (Quorum 1)
このシナリオでホストBがホストAへのネットワーク接続を一時的に失った場合、ホストBは自身をマスターに昇格させます。今、あなたは持っています：
Host A: redis master + sentinel 1 (Quorum 1)
Host B: redis master + sentinel 2 (Quorum 1)
Sentinel 2に接続するすべてのクライアントには、ホストBがマスターであると通知されますが、Sentinel 1に接続するクライアントには、ホストAにマスターが通知されます（ロードバランサーの背後にSentinelがある場合、クライアントの半分を意味します）。
したがって、許容できる最小限の信頼できるフェイルオーバー管理を取得するために実行する必要があるのは、次のとおりです。
Host A: Redis master
Host B: Redis Slave
Host C: Sentinel 1
Host D: Sentinel 2
Host E: Sentinel 2
クライアントはセンチネルに接続し、Redisインスタンスの現在のマスターを（名前で）取得してから、それに接続します。マスターが停止した場合、クライアントは接続を切断する必要があります。その後、クライアントはSentinelに再度接続し、新しい情報を取得する必要があります。
各クライアントライブラリがこれをどの程度うまく処理できるかは、ライブラリによって異なります。
理想的には、ホストC、D、およびEは、Redisに接続するのと同じホスト（つまり、クライアントホスト）上にあります。または良いサンプリングを表すと、それらが得られます。ここでの主な目的は、Redisに接続する必要がある場所からチェックしていることを確認することです。それが失敗すると、クライアントと同じDC/ラック/リージョンに配置されます。
クライアントにロードバランサーと通信させたい場合は、可能であれば、それらのLBノードにセンチネルを配置してみてください。必要に応じて非LBホストを追加して、2を超える奇数のセンチネルを取得します。クライアントホストは、それらの数に一貫性がないという点で動的です（たとえば、トラフィックの場合はスケールアップし、低速の場合はスケールダウンします）。このシナリオでは、ほとんどの場合、Sentinelを非クライアントおよび非redis-serverホストで実行する必要があります。
これを行う場合は、マスタースイッチイベントのSentinel PUBSUBチャネルを監視してLBを更新するデーモンを作成する必要があることに注意してください。これは、現在のマスターとのみ通信するように構成する必要があります（両方と通信しようとしないでください）。それを行うにはもっと手間がかかりますが、クライアントに対して透過的なSentinelを利用します。クライアントはLBIP/ポートとの通信のみを知っています。