NGINX Plus のドキュメントから私が理解しているのは、ロード バランシングはダウンまたは混雑しているサーバーを迂回してルーティングし、セッション パーシスタンスは特定のセッションで同じサーバーを維持しようとするということです。セッションの途中でサーバーがダウンすると、この 2 つが相互に排他的になる可能性があるようです。サーバー障害の兆候はありますでしょうか。つまり、別のサーバーに切り替えることでデータが失われる可能性がある (セッション中の変更には影響しない可能性があります) か、静かに切り替わるのでしょうか。
これは HTTP ではなく、TCP/UDP 通信専用です。
答え1
両者は排他的になるかもしれない
はい。これは nginx に固有の問題ではありません。これまでのところ、最善の解決策はセッション データを複製して高可用性を実現することですが、十分に計画されていない既存のサービスにそれを組み込むのは簡単ではありません。
セッションを実装しているサーバーに障害が発生した場合、nginx に何を実行させますか? 他のサーバーにフェイルオーバーしますか? 特定のサーバーにフェイルオーバーしますか? サーバーはペアになっていますか? 他に何かありますか? セッションを停止します - 不確定な状態にあるため... 非常に多くのオプションがあります。
障害の報告については、2 つの部分があります。1 つは監視です。つまり、何かが壊れている、または修正が必要であることを誰かに伝える必要があります。これは Nginx の仕事ではありません。これは監視スタックが処理するものです。2 つ目の部分は、何かが機能していないことをクライアントに知らせることです。Nginx は、在庫を棚に戻したり、DNS 変更を再適用したりする必要があることを知りません。これは、実行しているプロトコルとアプリケーションの仕事です。タイミングの問題はありますが、ほとんどのネットワーク プロトコルは、短い要求/応答メッセージの交換を使用して、クライアントでサーバーの状態を可視化します。(ほとんどの) データベースの場合、これはクライアントからの明示的な "COMMIT" メッセージで非常に明確に定義されています。しかし、クライアントが "COMMIT" と言っても応答がない場合はどうなるか考えてみてください。
これは HTTP ではなく、TCP/UDP 通信専用です。
@PersionGulf と同様に、nginx 経由の TCP の非 HTTP ロード バランシング / HA には HAProxy を使用することをお勧めします。前回確認したところ、UDP は実行できませんでした。
失敗した場合にどう動作するかは示されていない
テストするのは難しくありません。