これが役立つかどうかはわかりませんが、私たちの設定では、クライアントが通信するロード バランサーがあります。この LB は、どのインスタンスがライブで、どのインスタンスがダークであるかを認識し、それに応じてトラフィックを転送します。リクエストに「特別な」ヘッダーがある場合、LB はトラフィックをダーク プールに送信します。アプリケーションごとにこのセットアップがあります(投稿した図のようにこれを明確にするだけで、プラットフォーム全体がブルーグリーンであると考える人もいるかもしれません)
したがって、緑のクラスターがライブで青が暗い(<3アスキーアート)という図になります
[Client] <- I assume this is internal, otherwise add a FW :).
|
\|/
[Application Load Balancer] <- internal, per app
|
|\--------------\--------------\--------------\
\|/ \|/ \|/ \|/
[Node 1 G/L] [Node 2 G/L] [Node 3 B/D] [Node 4 B/D]
G = Green B = Blue
L = Live D = Dark
Application Load Balancerは、多数のテクノロジーである場合があります。ゲートウェイ アプリ (Netflix Zuul など) または負荷分散 Web サーバー (HAProxy を使用する AirBnB Smartstack など) である可能性があります。
ライブ クラスターが炎上した場合、ダーク クラスターをライブに自動的に昇格させないことに言及する価値があります。 . これはあなたの懸念ですか?(ここでVIPを使用していてキープアライブしているため)
編集
質問への回答に感謝します。残念ながら、あなたの制約では青緑を成功させることはできないと思います。
大きな環境を 1 つだけ用意して、カナリア リリースとブルーグリーンのハイブリッドを考えたことはありますか? このアプローチでは、最初に 5 つのサーバーがライブ トラフィックを処理し、1 つのサーバーがダーク トラフィックを処理します (合計 6 つのボックスがあると仮定します)。ライブ ノードは、3 つのノードがライブ トラフィックを取得し、2 つのノードがバッチ処理を行うように構成できます。
ダーク プールのコードに満足したら、すべてのサーバーがライブ トラフィックをライブ プールで処理するようになるまで、サーバーを 1 つずつアップグレードします。その時点で、2 つのバッチ処理サーバーをライト プールに移動する必要があるかもしれません。
念のために言っておきますが、これはあなたを苦しめる可能性があるためです (そして、私は仲間の開発者が苦しんでいるのが好きではありません)。バッチ処理がプラットフォームの基本的な部分である場合、真の HA 環境はありません。元の回答で概説した理由により、ライブ クラスターが何らかの理由 (DB の破損?) で失敗した場合、そうではありません。残りのハードウェアで実行できます。