私は Redis Sentinel の使用方法についていくつか読んでおり、2 つ以上の Sentinel を使用して、クライアント側から呼び出すときにそれらの間で負荷を分散できることを知っています。
マスター + スレーブと同じサーバーにこれら 2 つのセンチネルを配置するのは良い方法ですか? つまり、マスターと同じ物理サーバーに 1 つのセンチネルを持ち、スレーブと同じ物理サーバーに別のセンチネルを持っていますか?
マスターサーバーが停止した場合、スレーブのセンチネルは単にスレーブをマスターに昇格させるように思えます。スレーブサーバーが停止しても、マスターがまだ稼働しているため問題ありません。
何か不足していますか？欠点は何ですか？
むしろ、待機時間を短縮するために、センチネルをマスター/スレーブと同じ物理サーバーに配置します。
まず、Sentinel は Redis のロード バランサーまたはプロキシではありません。
第二に、すべての障害がホストの死であるとは限りません。サーバーが短時間ハングしたり、ネットワーク ケーブルが抜かれたりすることがあります。このため、Redis インスタンスと同じホストで Sentinel を実行することはお勧めできません。Sentinel を使用してフェイルオーバーを管理している場合、Redis マスターとスレーブ以外のノードで実行されている Sentinel が 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/Rack/Region に配置されます。
クライアントにロード バランサーと通信させたい場合は、可能であればこれらの LB ノードに Sentinel を配置し、必要に応じて非 LB ホストを追加して奇数の Sentinel > 2 を取得します。これに対する例外は、クライアント ホストは、その数が一貫していないという点で動的です (たとえば、トラフィックに応じてスケールアップし、遅い期間にダウンします)。このシナリオでは、Sentinel を非クライアントおよび非 redis サーバー ホストで実行する必要があります。
これを行う場合、マスター切り替えイベントの Sentinel PUBSUB チャネルを監視して LB を更新するデーモンを作成する必要があることに注意してください。これは、現在のマスターとのみ通信するように構成する必要があります (決して両方と通信しようとしないでください)。それを行うにはより多くの作業が必要ですが、Sentinel をクライアントに対して透過的に使用します。これは、LB IP/ポートと通信することしか認識していません。
それはすべて、実現したいディザスタ リカバリのレベルによって異なります。ホストされている場所に関係なく、次のコンポーネントがあると仮定します。
1 マスター 1+ スレーブ
1 つのホストのシナリオ
ホストの障害: すべてが失われ、ほとんどのユース ケースで不適切なレプリケーション シナリオが発生します。
2 つのホストのシナリオ
ホスト 1:
ホスト 2:
このシナリオでは、ホストに一度に 1 つずつ障害が発生し、ある程度のセキュリティが得られることは事実です。異なるサーバーが物理的に異なるホストを意味するかどうかを理解してください。これらが同じホスト上の単なる VM である場合、同じレベルの DR (ディザスター リカバリー) は得られません。
あなたの質問について：
むしろ、待機時間を短縮するために、センチネルをマスター/スレーブと同じサーバーに配置します。
Sentinel は現在のマスターとスレーブを追跡しますが、Redis クライアントは Sentinel を介してマスターに接続せず、Sentinel を介して現在のマスターがどこにあるかを取得するだけであることに注意してください。かなりの*レイテンシの増加を調べます。
構成プロバイダー。Sentinel は、クライアント サービス検出の権限のソースとして機能します。クライアントは、特定のサービスを担当する現在の Redis マスターのアドレスを要求するために、Sentinel に接続します。フェイルオーバーが発生すると、Sentinels は新しいアドレスを報告します。
(参照: http://redis.io/topics/sentinel )
私が見る限り、遅延に関して得られる唯一の利点は、マスターとスレーブからセンチネルに送信されるハートビートです。サーバーを全世界に広げていない限り、問題ありません。
それはすべてユースケースに依存しますが、他のすべての条件 (コスト、クライアントまでの距離など) が等しい場合は、可能な限り別々に保つことが最善の方法のようです。
それは確かに推奨されるアプローチではありません。
Redis Sentinel のドキュメントでは、トレードオフについてよく説明されています。お役に立てれば。 https://redis.io/topics/sentinel#example-sentinel-deployments