サーバーを再起動すると、IISはどうなりますか？
私の仕事では、現在IISに関する懸念に取り組んでいます。いくつかのIISサーバーでF5ロードバランサーを使用しているため、プールから取り出されたサーバーを少し処理できますが、WindowsUpdateの再起動がサーバーに与える影響が懸念されます。進行中のIISトランザクション。
私たちのIISアプリケーションは、1日中いつでも大量のトランザクションを処理するようなものです。現在、サーバーのパッチ適用を自動化しているため、メンテナンスウィンドウ内で再起動が発生する可能性があります。
マシンを（安全に、クラッシュではなく）再起動すると、IISを介して処理されている現在のトランザクションは失われますか？またはWindowsはIISサービスに十分な時間を与えますか？シャットダウンする前にそれらを完了し、他の負荷分散サーバーがトラフィックを取得できるようにしますか？
IISのリセットについてかなりの数の質問を見つけましたが、それらがマシンの再起動に適用されるかどうかはわかりません。
IISは、スケジュールのシャットダウン中に接続を「正常に」閉じません。ユーザーセッションはリセットされ、BIG-IPを管理していない場合でも、BIG-IP仮想サーバーモニターがダウンとしてマークしてトラフィックを他のノードに再配布するまで、セッションはダウンしたサーバーノードに送信されます。ほとんどのIISモニター/サービスモニターはすぐに気付くでしょうが、ユーザー定義なので、私はそれを呼び出すと思います。
この問題を軽減または軽減するには、GUI内で手動で、または（ iControlREST ）のようなBIG-IPのAPI呼び出しを介して、ノードをオフラインとしてマークします。これにより、新しい接続がメンテナンス中のサーバーにルーティングされるのを防ぎ、既存のセッションをドレインして、必要に応じて再配布できるようになります。
例外は、長く確立されたセッションが必要以上に長く続く可能性があることです。このような場合、BIG-IPでノードを「強制オフライン」としてマークして、接続を強制オフラインにする必要がある場合があります。これにより、既存の接続がリセットされ、新しい接続が他のノードに配布されます。これは望ましくありませんが、IISをリセットし、ノードをダウンとしてマークする前にBIG-IPモニターがX回失敗する間に接続のリセットを許可するよりも優れています。
だからここにあなたの操作の順序があります：
- ノードを無効としてマークします。
- X時間を許可して、アクティブなセッションを他のIISノードに排出します。
- セッションが長時間アクティブのままである場合は、ノードを強制オフラインとしてマークします（アプリケーションの予想される使用状況によって異なります）
- IISに必要なことは何でもします
- BIG-IPでプールメンバー（ノード）をオンラインとしてマークする前に、IISをバックアップし、実行を検証します。
また、これは、オンボックススクリプトまたは安全な管理システムからのAPI呼び出しを使用して、BIG-IPで自動化できます。
BIG-IP（仮想サーバー統計内）または優先管理ソフトウェアを介して、ノードへのトラフィックを監視できます。これにより、ノードごとに既存の接続を判別できます。
探しているものを実現するためのGUIおよびCLIコマンドのハウツーガイドは次のとおりです。