BIG-IP の高可用性 (HA) 構成では、自動同期は、同期フェールオーバー デバイス グループ内のアクティブ デバイスからスタンバイ デバイスへの構成の変更を自動的に同期するデバイス信頼機能です。
BIG-IP 管理データ プレーンの概念からの主要な原則:
* アクティブデバイスは常に構成の信頼できるソースです
* 構成の変更はアクティブデバイスでのみ行う必要があります
* 自動同期を有効にすると、アクティブデバイスの構成が変更されるたびに、システムはデバイスグループのすべてのスタンバイメンバーに構成を自動的にプッシュします。
* スタンバイデバイスで直接行われた構成の変更は保存されません。このシナリオでは、
* 管理者がスタンバイデバイス上の仮想サーバーを変更する
* この変更はローカルのみで、デバイスグループの同期構成は変更されません。
* 自動同期が次に実行されると (アクティブ デバイスの変更または内部同期イベントによってトリガー)、アクティブ デバイスの構成がスタンバイ構成を上書きします。その結果、スタンバイ デバイスで行われた構成の変更は元に戻されます。
他の選択肢が間違っている理由:
* A - 変更は別の変更が行われたときにのみ元に戻されるのではなく、次の自動同期操作中に元に戻されます。
* B - スタンバイデバイスで行われた変更はアクティブデバイスに反映されません
* D - 自動同期ではスタンバイの変更が HA ペア構成にマージまたは昇格されません。ベストプラクティスが強化されました。
一貫性があり予測可能な HA 動作を確保するために、自動同期が有効になっている場合は、常にアクティブ BIG-IP デバイスで構成の変更を実行します。

BIG-IP アーキテクチャでは、レイヤー 2 でのリンク アグリゲーションと冗長性は、仮想サーバーやプールではなく、トランクを使用して実装されます。
BIG-IP 管理データ プレーンの概念によると:
* インターフェースはBIG-IPデバイス上の物理ネットワークポートです
* トランクとは、複数のインターフェースを論理的にグループ化したものです
* トランクでは、LACP (Link Aggregation Control Protocol) を使用して次の操作を実行できます。
* リンクの冗長性を提供する
* 総帯域幅を増やす
* リンク障害の自動検出を許可する
* 集約が行われると、VLAN は個々のインターフェイスに直接割り当てられるのではなく、トランクに割り当てられます。シナリオの正しい設計:
LACP を使用して BIG-IP を 2 つのアップストリーム スイッチに接続するには:
* BIG-IPの1つの物理インターフェースがスイッチAに接続されます
* BIG-IPの別の物理インターフェースがスイッチBに接続します
* 両方のインターフェースは同じトランクに配置される
* LACPはトランクとスイッチで有効になっています
この構成により、次のことが可能になります。
* 1つのインターフェースまたはスイッチに障害が発生してもトラフィックの流れが継続されます
* BIG-IPと上流スイッチ間の適切なLACPネゴシエーション
* 責任の明確な分離（レイヤー2はトランキングで処理、レイヤー4～7は仮想サーバーで処理）オプションDが正しい理由：
* 各スイッチに接続されたインターフェースを含むトランクは、まさにBIG-IPがLACPベースのインターフェースバインディングを実装する方法です。
* トランクは、データプレーンでのリンク状態、負荷分散、フェイルオーバーを処理します。他のオプションが間違っている理由:
* AとB - 仮想サーバーはレイヤー4～7で動作し、物理リンクアグリゲーションやLACPとは関係ありません。
* C - VLAN IDとMACアドレスはトランク定義内では設定されません。トランクはインターフェースを集約し、VLANはトランクに適用されます。主要なデータプレーンの概念が強化されました。
BIG-IPシステムでは、LACPは常にトランク上に設定され、物理インターフェースを集約することでレイヤー2の回復力と帯域幅の集約を実現します。仮想サーバーとプールは物理インターフェースのバインディングには関与しません。

Cookie パーシステンスは、HTTP Cookie を利用してユーザー セッションを追跡するレイヤー 7 のパーシステンス メソッドです。
* IPアドレス非依存：「送信元アドレスアフィニティ」（クライアントのIPアドレスに依存する）とは異なり、CookieパーシステンスはBIG-IPシステムが提供する一意のトークンに基づいてセッションを識別します。これは、多くのユーザーが単一のゲートウェイ（NAT）を共有する環境や、クライアントのIPアドレスがセッション中に変更される可能性がある環境では非常に重要です。
* 暗号化と復号化：BIG-IPがCookieを挿入または読み取るには、HTTPヘッダーを認識できる必要があります。トラフィックがエンドツーエンドで暗号化されている場合（SSLパススルー）、BIG-IPはCookieの永続性を使用できません。SSLはBIG-IPで終端する必要があります（オプションBは誤りです）。
* セキュリティ：BIG-IPのCookieはデフォルトでは暗号化されており、平文ではありません。最新バージョンでは、これらのCookieを簡単に暗号化できるため、情報漏洩を防ぐことができます（オプションCは誤りです）。
* メモリ vs. ディスク: デフォルトの動作は「セッションベース」（メモリ内）です。永続プロファイルで有効期限が設定されている場合（オプションDがFalseの場合）、Cookieはクライアントのファイルシステム（ディスク）にのみ書き込まれます。

このシナリオでは、セッションの継続性、複数のプロトコル（HTTPとFTP）、およびHAフェイルオーバーの動作が組み合わされています。
これは、デバイスやサービス全体にわたる永続性の処理に直接関係します。
主要要件の内訳
* セッション全体で同じプールメンバー
* セッションはフェイルオーバー後も存続する必要がある
* セッションは複数のサービス（HTTP および FTP）にまたがる必要があります
サービス間の永続ミラーリングと一致が必要な理由
永続ミラーリング
* アクティブ BIG-IP からスタンバイ BIG-IP への永続レコードが同期されていることを確認します。
* ミラーリングなし:
* フェイルオーバー後、スタンバイデバイスには永続テーブルが存在しない
* クライアントの負荷分散が再び行われる
* セッションが中断され、ユーザーは再起動を余儀なくされる
* 永続ミラーリングは、フェイルオーバー時のセッション継続に不可欠です。サービス間の一致
* 単一の永続レコードを複数の仮想サーバー/プロトコル間で共有できます
* 次の場合に必須:
* HTTPとFTPは同じプールメンバーを使用する必要があります
* 複数のサービスが単一のアプリケーションセッションの一部です
これらの設定を組み合わせることで、次のことが保証されます。
* デバイスのフェイルオーバー後も持続性を維持
* 永続性はHTTPとFTPで尊重されます
他の選択肢が間違っている理由
* A. Cookie の永続性とセッション タイムアウトCookie の永続性は HTTP にのみ適用され、FTP またはフェールオーバー同期には適用されません。
* B. ステートフル フェールオーバーとネットワーク フェールオーバーの検出ステートフル フェールオーバーは、永続性レコードではなく接続状態に適用され、HTTP セッションと FTP セッションをリンクしません。
* D. SYN クッキー挿入しきい値と接続最低水準点これらは、永続性や HA 動作とは関係のない DoS/SYN フラッド保護設定です。