BIG-IP管理サポートおよびトラブルシューティングドキュメントからの包括的かつ詳細な説明：負荷分散が期待通りに機能せず、接続が物理ハードウェア間で偏っているように見える場合、管理者は「メンバー」レベルと「ノード」レベルの負荷分散を区別する必要があります。
「メンバー」は特定のIPアドレスとポート番号の組み合わせ（例：10.1.1.1:80）を指しますが、「ノード」はポート番号に関係なく、基盤となるIPアドレス（10.1.1.1）を指します25。1台のサーバーが異なるプールにまたがって複数のサービス（Web、FTP、API）をホストしている場合、「最小接続数（メンバー）」を使用すると、各プール内の接続のみが分散されます26。これにより、1台のサーバーが接続を独占し、過負荷状態になるシナリオが発生する可能性があります。
「最少接続数」は3つの異なるプールで同時にカウントされます。「最少接続数（ノード）」を選択すると、BIG-IPは物理IPアドレスへの同時接続数を、それが属するすべてのプール27全体で追跡します。これにより、管理者はハードウェア全体に均等に作業を分散させることができ、複数のアプリケーションサービスをホストするバックエンドサーバーのパフォーマンス低下を防ぐことができます。

このシナリオは、「メガプロキシ」問題として知られる典型的なネットワークパフォーマンスの問題を説明しています。組織が従業員のトラフィックをすべて単一のプロキシサーバー経由でルーティングする場合、BIG-IPは数千人のユニークユーザーが全く同じ送信元IPアドレスを持つと認識します。管理者が「送信元アドレスアフィニティ」パーシステンスを設定している場合、BIG-IPはルールに正しく従いますが、すべてのユーザーを同じ単一のバックエンドプールメンバーに誤ってルーティングします。これにより、1つのサーバーが過負荷になり、他のサーバーがアイドル状態になるという深刻な負荷不均衡が生じ、アプリケーションの応答時間が低下します。この問題を解決するには、管理者はパーシステンスプロファイルを「HTTP Cookie」に変更する必要があります。Cookieベースのパーシステンスにより、BIG-IPは各ユーザーのブラウザに一意の識別子を配置できるため、同じ送信元IPを共有する場合でも、システムは個々のセッションを区別できます。この修正により、トラフィックがプールメンバー間で均等に分散され、期待される負荷分散機能が回復し、企業プロキシの背後にいるユーザーから報告されたパフォーマンスの低下が解消されます。

BIG-IPデバイスグループが「変更保留中」ステータスを示している場合、グループ内の1つ以上のデバイスに、他のメンバーにまだ同期されていない設定変更があることを示します。どのデバイスが最新の（権限のある）設定を持っているかを特定するには、管理者はデバイスグループレベルで詳細な同期ステータスを確認する必要があります。
正しい場所は「デバイス管理」>「デバイスグループ」（オプションD）です。このメニューでは、BIG-IP構成ユーティリティが各デバイスグループとその同期ステータスを表示し、変更が保留中のデバイスに関する詳細情報を提供します。このビューから、管理者は変更が保留中としてマークされているデバイスを明確に把握し、そのデバイスをグループへの同期操作を開始するためのソースデバイスとして指定できます。
その他のオプションでは、必要なレベルの詳細が提供されません。
デバイス管理 > 概要 (オプション A) には、一般的な HA ステータスが表示されますが、構成の所有権は表示されません。
デバイス管理 > デバイス (オプション B) ではデバイスが一覧表示されますが、どのデバイスに同期されていない変更が含まれているかは明確に識別されません。
システム > 高可用性 (オプション C) は、構成の同期状態ではなく、フェールオーバーとトラフィック グループに重点を置いています。
このワークフローは、構成同期に関する BIG-IP のベスト プラクティスに準拠しており、新しい構成を上書きせずに変更が正しく伝播されることを保証します。

BIG-IPシステムを新しいTMOSバージョンにアップグレードする前に、不安定性やリグレッションの発生を防ぐため、既知の問題を確認することが重要です。F5 Bug Tracker（オプションB）は、このための主要なリソースです。管理者は、TMOSバージョン、モジュール、症状、またはバグIDで、文書化されたソフトウェアの不具合を検索できます。Bug Trackerを使用することで、管理者は未解決の問題、修正されたバグ、そしてトラフィック処理、高可用性、モジュール固有の機能など、特定の導入に影響を与える可能性のある動作の変更を特定できます。これは、プロアクティブなトラブルシューティングと情報に基づいたアップグレード計画を直接的にサポートします。
F5 iHealth（オプションD）は、アップグレード準備時に使用するもう一つの重要なツールです。iHealthは、アップロードされたUCSまたはQKViewファイルを分析し、デバイス構成とソフトウェアバージョンをF5の既知の問題データベースと関連付けます。重大な不具合、アップグレードのリスク、相互運用性に関する懸念事項、推奨されるターゲットバージョンなど、実用的なレポートを提供します。iHealthは、デバイス上で実際に実行されている構成に基づいて既知の問題を文脈化できるため、特に有用です。
その他のオプションは、既知のソフトウェアの問題の検証には適していません。F5 End User Diagnostics（オプションA）はクライアント側のトラブルシューティングツールであり、F5 University（オプションC）はトレーニングプラットフォームです。F5 Downloads（オプションE）は、既知の欠陥を詳細に分析するためではなく、主にソフトウェアイメージとリリースノートを取得するために使用されます。

SSL接続のリセットに関するトラブルシューティングでは、ライセンス制限と実際のリソース使用率を検証することがしばしば必要になります。F5デバイスは、「1秒あたりのトランザクション数」（TPS）ライセンスを使用して、デバイスが処理できるSSL処理量を制御します。ログエントリのSSLトランザクション（TPS）レート制限への到達は、トラフィック量がライセンス容量を超えたことを明確に示しています。必要なライセンスレベルを決定する際には、F5が主に「クライアント側」SSL TPS、つまりユーザーと仮想サーバー間の暗号化された接続に対してライセンスと制限を適用していることを理解することが重要です。この特定のシナリオでは、ピーク需要が1秒あたり1200件のクライアント側トランザクションに達しました。800件のサーバー側トランザクション（BIG-IPからプールへの再暗号化）もありましたが、これらは通常、プライマリTPSライセンス制限に同様にカウントされません。したがって、ピーク負荷時に仮想サーバーが期待どおりに動作することを保証するには、管理者はライセンスを少なくとも1200 TPSにアップグレードする必要があります。このトラブルシューティングプロセスは、システムログエラーとライセンスによって課されるリソース制約を結び付けます。