ASA クラスタリングの概要
ここでは、クラスタリング アーキテクチャとその動作について説明します。
ASA クラスタをネットワークに適合させる方法
クラスタは、1 つのユニットとして機能する複数の ASA から構成されます。ASA をクラスタとして機能させるには、次のインフラストラクチャが必要です。
-
クラスタ内通信用の、隔離された高速バックプレーン ネットワーク。クラスタ制御リンクと呼ばれます。
-
各 ASA への管理アクセス(コンフィギュレーションおよびモニタリングのため)。
クラスタをネットワーク内に配置するときは、クラスタが送受信するデータのロード バランシングを、アップストリームおよびダウンストリームのルータが次のいずれかの方法でできることが必要です。
-
スパンド EtherChannel(推奨):クラスタ内の複数のメンバのインターフェイスをグループ化して 1 つの EtherChannel とします。この EtherChannel がユニット間のロード バランシングを実行します。
-
ポリシーベース ルーティング(ルーテッド ファイアウォール モードのみ):アップストリームとダウンストリームのルータが、ルート マップと ACL を使用してユニット間のロード バランシングを実行します。
-
等コスト マルチパス ルーティング(ルーテッド ファイアウォール モードのみ):アップストリームとダウンストリームのルータが、等コストのスタティックまたはダイナミック ルートを使用してユニット間のロード バランシングを実行します。
パフォーマンス スケーリング係数
複数のユニットを結合して 1 つのクラスタとしたときに、期待できるパフォーマンスの概算値は次のようになります。
-
合計スループットの 70 %
-
最大接続数の 60 %
-
接続数/秒の 50 %
たとえば、スループットについては、ASA 5585-X と SSP-40 が処理できる実際のファイアウォール トラフィックは、単独動作時は約 10 Gbps となります。8 ユニットのクラスタでは、合計スループットの最大値は約 80 Gbps(8 ユニット x 10 Gbps)の 70 %、つまり 56 Gbps となります。
クラスタ メンバー
クラスタ メンバーは連携して動作し、セキュリティ ポリシーおよびトラフィック フローの共有を達成します。ここでは、各メンバーのロールの特長について説明します。
Bootstrap Configuration
各デバイスで、最小限のブートストラップ コンフィギュレーション(クラスタ名、クラスタ制御リンク インターフェイスなどのクラスタ設定)を設定します。クラスタリングを最初にイネーブルにしたユニットが一般的にはマスター ユニットとなります。以降のユニットに対してクラスタリングをイネーブルにすると、そのユニットはスレーブとしてクラスタに参加します。
マスターおよびスレーブ ユニットの役割
クラスタ内のメンバの 1 つがマスター ユニットです。マスター ユニットは、ブートストラップ コンフィギュレーション内のプライオリティ設定によって決まります。プライオリティは 1 ~ 100 の範囲内で設定され、1 が最高のプライオリティです。他のすべてのメンバはスレーブ ユニットです。一般的には、クラスタを作成した後で最初に追加したユニットがマスター ユニットとなります。これは単に、その時点でクラスタに存在する唯一のユニットであるからです。
すべてのコンフィギュレーション作業(ブートストラップ コンフィギュレーションを除く)は、マスター ユニット上のみで実行する必要があります。コンフィギュレーションは、スレーブ ユニットに複製されます。物理的資産(たとえばインターフェイス)の場合は、マスター ユニットのコンフィギュレーションがすべてのスレーブ ユニット上でミラーリングされます。たとえば、GigabitEthernet 0/1 を内部インターフェイスとして、GigabitEthernet 0/0 を外部インターフェイスとして設定した場合は、これらのインターフェイスはスレーブ ユニット上でも、内部および外部のインターフェイスとして使用されます。
機能によっては、クラスタ内でスケーリングしないものがあり、そのような機能についてはマスター ユニットがすべてのトラフィックを処理します。
マスター ユニット選定
クラスタのメンバは、クラスタ制御リンクを介して通信してマスター ユニットを選定します。方法は次のとおりです。
-
ユニットに対してクラスタリングをイネーブルにしたとき(または、クラスタリングがイネーブル済みの状態でそのユニットを初めて起動したとき)に、そのユニットは選定要求を 3 秒間隔でブロードキャストします。
-
プライオリティの高い他のユニットがこの選定要求に応答します。プライオリティは 1 ~ 100 の範囲内で設定され、1 が最高のプライオリティです。
-
45 秒経過しても、プライオリティの高い他のユニットからの応答を受信していない場合は、そのユニットがマスターになります。
(注)
最高のプライオリティを持つユニットが複数ある場合は、クラスタ ユニット名、次にシリアル番号を使用してマスターが決定されます。
-
後からクラスタに参加したユニットのプライオリティの方が高い場合でも、そのユニットが自動的にマスター ユニットになることはありません。既存のマスター ユニットは常にマスターのままです。ただし、マスター ユニットが応答を停止すると、その時点で新しいマスター ユニットが選定されます。
(注) |
特定のユニットを手動で強制的にマスターにすることができます。中央集中型機能については、マスター ユニット変更を強制するとすべての接続がドロップされるので、新しいマスター ユニット上で接続を再確立する必要があります。 |
クラスタ インターフェイス
データ インターフェイスは、スパンド EtherChannel として設定することも、個別インターフェイスとして設定することもできます。1 つのクラスタ内のすべてのデータ インターフェイスのタイプが同一であることが必要です。詳細については、「クラスタ インターフェイスについて」を参照してください。
クラスタ制御リンク
各ユニットの、少なくとも 1 つのハードウェア インターフェイスをクラスタ制御リンク専用とする必要があります。詳細については、「クラスタ制御リンクについて」を参照してください。
ASA クラスタ内のハイ アベイラビリティ
ASA クラスタリングは、ユニットとインターフェイスの正常性を監視し、ユニット間で接続状態を複製することにより、ハイ アベイラビリティを提供します。
ユニットのヘルス モニタリング
マスター ユニットは、各スレーブ ユニットをモニタするために、クラスタ制御リンクを介してハートビート メッセージを定期的に送信します(間隔は設定可能です)。各スレーブ ユニットは、同じメカニズムを使用してマスター ユニットをモニタします。ユニットの健全性チェックが失敗すると、ユニットはクラスタから削除されます。
インターフェイス モニタリング
各ユニットは、使用中のすべての指名されたハードウェア インターフェイスのリンク ステータスをモニタし、ステータス変更をマスター ユニットに報告します。
-
スパンド EtherChannel:クラスタ Link Aggregation Control Protocol(cLACP)を使用します。各ユニットは、リンク ステータスおよび cLACP プロトコル メッセージをモニタして、ポートがまだ EtherChannel でアクティブであるかどうかを判断します。ステータスがマスター ユニットに報告されます。
-
個別インターフェイス(ルーテッド モードのみ):各ユニットが自身のインターフェイスを自己モニタし、インターフェイスのステータスをマスター ユニットに報告します。
ヘルス モニタリングをイネーブルにすると、すべての物理インターフェイス(主要な EtherChannel インターフェイスおよび冗長インターフェイスのタイプを含む)がデフォルトでモニタされるため、オプションでインターフェイスごとのモニタリングをディセーブルにすることができます。指名されたインターフェイスのみモニタできます。たとえば、指名された EtherChannel に障害が発生したと判断される必要がある場合、つまり、EtherChannel のすべてのメンバー ポートはクラスタ削除をトリガーすることに失敗する必要があります(最小ポート バンドリング設定に応じて)。
ユニットのモニタ対象のインターフェイスが失敗した場合、そのユニットはクラスタから削除されます。ASA がメンバーをクラスタから削除するまでの時間は、インターフェイスのタイプと、そのユニットが確立済みメンバーであるか、またはクラスタに参加しようとしているかによって異なります。EtherChannel の場合(スパニングかどうかを問わない)は、確立済みメンバーのインターフェイスがダウン状態のときに、ASA はそのメンバーを 9 秒後に削除します。ASA は、ユニットがクラスタに参加する最初の 90 秒間はインターフェイスを監視ししません。この間にインターフェイスのステータスが変化しても、ASA はクラスタから削除されません。非 EtherChannel の場合は、メンバー状態に関係なく、ユニットは 500 ミリ秒後に削除されます。
障害後のステータス
クラスタ内のユニットで障害が発生したときに、そのユニットでホスティングされている接続は他のユニットにシームレスに移管されます。トラフィック フローのステート情報は、クラスタ制御リンクを介して共有されます。
マスター ユニットで障害が発生した場合は、そのクラスタの他のメンバーのうち、プライオリティが最高(番号が最小)のものがマスター ユニットになります。
障害イベントに応じて、ASA は自動的にクラスタへの再参加を試みます。
(注) |
ASA が非アクティブになり、クラスタへの自動再参加に失敗すると、すべてのデータ インターフェイスがシャットダウンされます。管理専用インターフェイスのみがトラフィックを送受信できます。 管理インターフェイスは、そのユニットがクラスタ IP プールから受け取った IP アドレスを使用して引き続き稼働状態となります。ただし、リロードする場合、クラスタでユニットがまだ非アクティブになっていると、管理インターフェイスはディセーブルになります。それ以降のコンフィギュレーション作業には、コンソール ポートを使用する必要があります。 |
クラスタへの再参加
クラスタ メンバがクラスタから削除された後、クラスタに再参加できる方法は、削除された理由によって異なります。
-
クラスタ制御リンクの障害:(最初の参加時)クラスタ制御リンクの問題を解決した後、。
-
クラスタに参加した後に障害が発生したクラスタ制御リンク:ASA は、無限に 5 分ごとに自動的に再参加を試みます。この動作は設定可能です。
-
データ インターフェイスの障害:ASA は自動的に最初は 5 分後、次に 10 分後、最終的に 20 分後に再参加を試みます。20 分後に参加できない場合、ASA はクラスタリングをディセーブルにします。データ インターフェイスの問題を解決した後、。この動作は設定可能です。
-
ASA 5585-X 上の ASA FirePOWER モジュールの障害:ASA は自動的に 5 分後に再参加を試行します。
-
ASA FirePOWE ソフトウェア モジュールの障害:モジュールの問題を解決した後、手動でクラスタリングをイネーブルにする必要があります。
-
ユニットの障害:ユニットがヘルス チェック失敗のためクラスタから削除された場合、クラスタへの再参加は失敗の原因によって異なります。たとえば、一時的な電源障害の場合は、クラスタ制御リンクが稼働していて、クラスタリングがまだイネーブルになっているなら、ユニットは再起動するとクラスタに再参加することを意味します。ASA は 5 秒ごとにクラスタへの再参加を試みます。
-
内部エラー:内部の障害には、アプリケーション同期のタイムアウト、矛盾したアプリケーション ステータスなどがあります。 問題を解決したら、クラスタリングを再び有効にして、クラスタに手動で再参加する必要があります。
「ASA クラスタの基本パラメータの設定」を参照してください。
データ パス接続状態の複製
どの接続にも、1 つのオーナーおよび少なくとも 1 つのバックアップ オーナーがクラスタ内にあります。バックアップ オーナーは、障害が発生しても接続を引き継ぎません。代わりに、TCP/UDP のステート情報を保存します。これは、障害発生時に接続が新しいオーナーにシームレスに移管されるようにするためです。バックアップ オーナーは通常ディレクタでもあります。
トラフィックの中には、TCP または UDP レイヤよりも上のステート情報を必要とするものがあります。この種類のトラフィックに対するクラスタリングのサポートの可否については、次の表を参照してください。
Traffic |
状態のサポート |
注意 |
---|---|---|
Up time |
Yes |
システム アップ タイムをトラッキングします。 |
ARP Table |
Yes |
— |
MAC アドレス テーブル |
Yes |
— |
ユーザ アイデンティティ |
Yes |
AAA ルール(uauth)とアイデンティティ ファイアウォールが含まれます。 |
IPv6 ネイバー データベース |
Yes |
— |
ダイナミック ルーティング |
Yes |
— |
SNMP エンジン ID |
なし |
— |
集中型 VPN(サイト間) |
なし |
VPN セッションは、マスター ユニットで障害が発生すると切断されます。 |
設定の複製
クラスタ内のすべてのユニットは、単一のコンフィギュレーションを共有します。コンフィギュレーション変更を加えることができるのはマスター ユニット上だけであり、変更は自動的にクラスタ内の他のすべてのユニットに同期されます。
ASA クラスタ管理
ASA クラスタリングを使用することの利点の 1 つは、管理のしやすさです。ここでは、クラスタを管理する方法について説明します。
管理ネットワーク
すべてのユニットを単一の管理ネットワークに接続することを推奨します。このネットワークは、クラスタ制御リンクとは別のものです。
管理インターフェイス
管理インターフェイスについては、専用管理インターフェイスの 1 つを使用することを推奨します。管理インターフェイスは、個別インターフェイスとして設定することも(ルーテッド モードとトランスペアレント モードの両方)、スパンド EtherChannel インターフェイスとして設定することもできます。
管理用には、個別インターフェイスを使用することを推奨します(スパンド EtherChannel をデータ インターフェイスに使用している場合でも)。個別インターフェイスならば、必要に応じて各ユニットに直接接続できますが、スパンド EtherChannel インターフェイスでは、現在のマスター ユニットへのリモート接続しかできません。
(注) |
スパンド EtherChannel インターフェイス モードを使用しているときに、管理インターフェイスを個別インターフェイスとして設定する場合は、管理インターフェイスに対してダイナミック ルーティングをイネーブルにすることはできません。スタティック ルートを使用する必要があります。 |
個別インターフェイスの場合は、メイン クラスタ IP アドレスはそのクラスタの固定アドレスであり、常に現在のマスター ユニットに属します。インターフェイスごとに、管理者はアドレス範囲も設定します。これで、各ユニット(現在のマスターも含まれます)がその範囲内のローカル アドレスを使用できるようになります。このメイン クラスタ IP アドレスによって、管理アクセスのアドレスが一本化されます。マスター ユニットが変更されると、メイン クラスタ IP アドレスは新しいマスター ユニットに移動するので、クラスタの管理をシームレスに続行できます。ローカル IP アドレスは、ルーティングに使用され、トラブルシューティングにも役立ちます。
たとえば、クラスタを管理するにはメイン クラスタ IP アドレスに接続します。このアドレスは常に、現在のマスター ユニットに関連付けられています。個々のメンバを管理するには、ローカル IP アドレスに接続します。
TFTP や syslog などの発信管理トラフィックの場合、マスター ユニットを含む各ユニットは、ローカル IP アドレスを使用してサーバに接続します。
スパンド EtherChannel インターフェイスの場合は、IP アドレスは 1 つだけ設定でき、その IP アドレスは常にマスター ユニットに関連付けられます。EtherChannel インターフェイスを使用してスレーブ ユニットに直接接続することはできません。管理インターフェイスは個別インターフェイスとして設定することを推奨します。各ユニットに接続できるようにするためです。デバイス ローカル EtherChannel を管理に使用できます。
マスター ユニット管理とスレーブ ユニット管理
すべての管理とモニタリングはマスター ユニットで実行できます。マスター ユニットから、すべてのユニットの実行時統計情報やリソース使用状況などのモニタリング情報を調べることができます。また、クラスタ内のすべてのユニットに対してコマンドを発行することや、コンソール メッセージをスレーブ ユニットからマスター ユニットに複製することもできます。
必要に応じて、スレーブ ユニットを直接モニタできます。マスター ユニットからでもできますが、ファイル管理をスレーブ ユニット上で実行できます(コンフィギュレーションのバックアップや、イメージの更新など)。次の機能は、マスター ユニットからは使用できません。
-
ユニットごとのクラスタ固有統計情報のモニタリング。
-
ユニットごとの Syslog モニタリング(コンソール レプリケーションが有効な場合にコンソールに送信される syslog を除く)。
-
SNMP
-
NetFlow
RSA キー複製
マスター ユニット上で RSA キーを作成すると、そのキーはすべてのスレーブ ユニットに複製されます。メイン クラスタ IP アドレスへの SSH セッションがある場合に、マスター ユニットで障害が発生すると接続が切断されます。新しいマスター ユニットは、SSH 接続に対して同じキーを使用するので、新しいマスター ユニットに再接続するときに、キャッシュ済みの SSH ホスト キーを更新する必要はありません。
ASDM 接続証明書 IP アドレス不一致
デフォルトでは、自己署名証明書は、ローカル IP アドレスに基づいて ASDM 接続に使用されます。ASDM を使用してメイン クラスタ IP アドレスに接続する場合は、IP アドレス不一致に関する警告メッセージが表示されます。これは、証明書で使用されているのがローカル IP アドレスであり、メイン クラスタ IP アドレスではないからです。このメッセージは無視して、ASDM 接続を確立できます。ただし、この種の警告を回避するには、新しい証明書を登録し、この中でメイン クラスタ IP アドレスと、IP アドレス プールからのすべてのローカル IP アドレスを指定します。この証明書を各クラスタ メンバに使用します。
サイト間クラスタリング
サイト間インストールの場合、推奨されるガイドラインに従っていれば、ASA クラスタリングを活用できます。
各クラスタ シャーシを個別のサイト ID に属するように設定できます。
サイト ID は、サイト固有の MAC アドレスおよび IP アドレスと連動します。クラスタから送信されたパケットは、サイト固有の MAC アドレスおよび IP アドレスを使用するのに対し、クラスタで受信したパケットは、グローバル MAC アドレスおよび IP アドレスを使用します。この機能により、MAC フラッピングの原因となる 2 つの異なるポートで両方のサイトから同じグローバル MAC アドレスをスイッチが学習するのを防止します。代わりに、スイッチはサイトの MAC アドレスのみを学習します。サイト固有の MAC アドレスおよび IP アドレスは、スパンド EtherChannel のみを使用したルーテッド モードでサポートされます。
サイト ID は、LISP インスペクションを使用したフロー モビリティの有効化、データセンターのサイト間クラスタリングのパフォーマンス向上とラウンドトリップ時間の遅延短縮のためのディレクタ ローカリゼーションの有効化。
サイト間クラスタリングの詳細については、以下の項を参照してください。
-
Data Center Interconnect のサイジング:ASA クラスタリングの要件と前提条件
-
サイト間のガイドライン:ASA クラスタリングのガイドライン
-
クラスタ フロー モビリティの設定:クラスタ フロー モビリティの設定
-
ディレクタ ローカリゼーションの有効化:ASA クラスタの基本パラメータの設定
-
サイト間での例:サイト間クラスタリングの例
ASA クラスタが接続を管理する方法
接続をクラスタの複数のメンバにロードバランスできます。接続のロールにより、通常動作時とハイ アベイラビリティ状況時の接続の処理方法が決まります。
接続のロール
接続ごとに定義された次のロールを参照してください。
-
オーナー:通常、最初に接続を受信するユニット。オーナーは、TCP 状態を保持し、パケットを処理します。1 つの接続に対してオーナーは 1 つだけです。元のオーナーに障害が発生すると、新しいユニットが接続からパケットを受信したときにディレクタがこれらのユニットの新しいオーナーを選択します。
-
バックアップ オーナー:オーナーから受信した TCP/UDP ステート情報を格納するユニット。これにより、障害が発生した場合に新しいオーナーにシームレスに接続を転送できます。バックアップ オーナーは、障害発生時に接続を引き継ぎません。オーナーが使用不可能になった場合は、その接続からパケットを受け取る最初のユニット(ロード バランシングに基づく)がバックアップ オーナーに問い合わせて、関連するステート情報を取得し、これでそのユニットが新しいオーナーになることができます。
ディレクタ(下記参照)がオーナーと同じユニットでない限り、ディレクタはバックアップ オーナーでもあります。オーナーがディレクタとして自分自身を選択すると、別のバックアップ オーナーが選択されます。
1 台のシャーシに最大 3 つのクラスタ ユニットを搭載できる Firepower 9300 のシャーシ間クラスタリングでは、バックアップ オーナーがオーナーと同じシャーシにある場合、シャーシ障害からフローを保護するために、別のシャーシから追加のバックアップ オーナーが選択されます。
サイト間クラスタリングのディレクタ ローカリゼーションを有効にすると、ローカル バックアップとグローバル バックアップの 2 つのバックアップ オーナー権限があります。オーナーは、常に同じサイトのローカル バックアップをオーナー自身として選択します(サイト ID に基づいて)。グローバル バックアップはどのサイトにあってもよく、ローカル バックアップと同一のユニットとすることもできます。オーナーは、両方のバックアップへ接続ステート情報を送信します。
-
ディレクタ:フォワーダからのオーナー ルックアップ要求を処理するユニット。オーナーが新しい接続を受信すると、オーナーは、送信元/宛先 IP アドレスおよび ポートのハッシュに基づいてディレクタを選択し、新しい接続を登録するためにメッセージをそのディレクタに送信します。パケットがオーナー以外のユニットに到着した場合は、そのユニットはどのユニットがオーナーかをディレクタに問い合わせます。これで、パケットを転送できるようになります。1 つの接続に対してディレクタは 1 つだけです。ディレクタが失敗すると、オーナーは新しいディレクタを選択します。
ディレクタがオーナーと同じユニットでない限り、ディレクタはバックアップ オーナーでもあります(上記参照)。オーナーがディレクタとして自分自身を選択すると、別のバックアップ オーナーが選択されます。
サイト間クラスタリングのディレクタ ローカリゼーションを有効にすると、ローカル ディレクタとグローバル ディレクタの 2 つのディレクタ権限が区別されます。オーナーは、同一サイト(Site Id に基づき)のローカル ディレクタとして、常にオーナー自身を選択します。グローバル ディレクタはどのサイトにあってもよく、ローカル ディレクタと同一のユニットとすることもできます。元のオーナーに障害が発生すると、ローカル ディレクタはこのサイトで新しい接続オーナーを選択します。
-
フォワーダ:パケットをオーナーに転送するユニット。フォワーダが接続のパケットを受信したときに、その接続のオーナーが自分ではない場合は、フォワーダはディレクタにオーナーを問い合わせてから、そのオーナーへのフローを確立します。これは、この接続に関してフォワーダが受信するその他のパケット用です。ディレクタは、フォワーダにもなることができます。ディレクタ ローカリゼーションを有効にすると、フォワーダは常にローカル ディレクタに問い合わせを行います。フォワーダがグローバル ディレクタに問い合わせを行うのは、ローカル ディレクタがオーナーを認識していない場合だけです。たとえば、別のサイトで所有されている接続のパケットをクラスタ メンバーが受信する場合などです。フォワーダが SYN-ACK パケットを受信した場合、フォワーダはパケットの SYN クッキーからオーナーを直接取得できるので、ディレクタに問い合わせる必要がないことに注意してください(TCP シーケンスのランダム化をディセーブ ルにした場合は、SYN Cookie は使用されないので、ディレクタへの問い合わせが必要です)。存続期間が短いフロー(たとえば DNS や ICMP)の場合は、フォワーダは問い合わせの代わりにパケットを即座にディレクタに送信し、ディレクタがそのパケットをオーナーに送信します。1 つの接続に対して、複数のフォワーダが存在できます。最も効率的なスループットを実現できるのは、フォワーダが 1 つもなく、接続のすべてのパケットをオーナーが受信するという、優れたロードバランシング方法が使用されている場合です。
接続でポート アドレス変換(PAT)を使用すると、PAT のタイプ(per-session または multi-session)が、クラスタのどのメンバが新しい接続のオーナーになるかに影響します。
-
Per-session PAT:オーナーは、接続の最初のパケットを受信するユニットです。
デフォルトでは、TCP および DNS UDP トラフィックは per-session PAT を使用します。
-
Multi-session PAT:オーナーは常にマスター ユニットです。multi-session PAT 接続がスレーブ ユニットで最初に受信される場合、スレーブ ユニットはその接続をマスター ユニットに転送します。
デフォルトでは、UDP(DNS UDP を除く)および ICMP トラフィックは multi-session PAT を使用するので、これらの接続は常にマスター ユニットによって所有されています。
TCP および UDP の per-session PAT デフォルトを変更できるので、これらのプロトコルの接続は、その設定に応じて per-session または multi-session で処理されます。ICMP の場合は、デフォルトの multi-session PAT から変更することはできません。per-session PAT の詳細については、『ファイアウォールの構成ガイド』を参照してください。
新しい接続の所有権
新しい接続がロード バランシング経由でクラスタのメンバに送信される場合は、そのユニットがその接続の両方向のオーナーとなります。接続のパケットが別のユニットに到着した場合は、そのパケットはクラスタ制御リンクを介してオーナー ユニットに転送されます。最適なパフォーマンスを得るには、適切な外部ロード バランシングが必要です。1 つのフローの両方向が同じユニットに到着するとともに、フローがユニット間に均等に分散されるようにするためです。逆方向のフローが別のユニットに到着した場合は、元のユニットにリダイレクトされます。
サンプル データ フロー
次の例は、新しい接続の確立を示します。
-
SYN パケットがクライアントから発信され、ASA の 1 つ(ロード バランシング方法に基づく)に配信されます。これがオーナーとなります。オーナーはフローを作成し、オーナー情報をエンコードして SYN Cookie を生成し、パケットをサーバに転送します。
-
SYN-ACK パケットがサーバから発信され、別の ASA(ロード バランシング方法に基づく)に配信されます。この ASA はフォワーダです。
-
フォワーダはこの接続を所有してはいないので、オーナー情報を SYN Cookie からデコードし、オーナーへの転送フローを作成し、SYN-ACK をオーナーに転送します。
-
オーナーはディレクタに状態アップデートを送信し、SYN-ACK をクライアントに転送します。
-
ディレクタは状態アップデートをオーナーから受信し、オーナーへのフローを作成し、オーナーと同様に TCP ステート情報を記録します。ディレクタは、この接続のバックアップ オーナーとしての役割を持ちます。
-
これ以降、フォワーダに配信されたパケットはすべて、オーナーに転送されます。
-
パケットがその他のユニットに配信された場合は、そのユニットはディレクタに問い合わせてオーナーを特定し、フローを確立します。
-
フローの状態が変化した場合は、状態アップデートがオーナーからディレクタに送信されます。
新しい TCP 接続のクラスタ全体での再分散
アップストリームまたはダウンストリーム ルータによるロード バランシングの結果として、フロー分散に偏りが生じた場合は、新しい TCP フローを過負荷のユニットから他のユニットにリダイレクトするように設定できます。既存のフローは他のユニットには移動されません。
ASA の各機能とクラスタリング
ASA の一部の機能は ASA クラスタリングではサポートされず、一部はマスター ユニットだけでサポートされます。その他の機能については適切な使用に関する警告がある場合があります。
クラスタリングでサポートされない機能
これらの機能は、クラスタリングがイネーブルのときは設定できず、コマンドは拒否されます。
-
TLS プロキシを使用するユニファイド コミュニケーション機能
-
リモート アクセス VPN(SSL VPN および IPSec VPN)
-
次のアプリケーション インスペクション:
-
CTIQBE
-
H323、H225、および RAS
-
IPsec パススルー
-
MGCP
-
MMP
-
RTSP
-
SCCP(Skinny)
-
WAAS
-
WCCP
-
-
Botnet Traffic Filter
-
Auto Update Server
-
DHCP クライアント、サーバ、およびプロキシDHCP リレーがサポートされている。
-
VPN ロード バランシング
-
フェールオーバー
-
ASA CX モジュール
-
Integrated Routing and Bridging(IRB)
-
デッド接続検出(DCD)
クラスタリングの中央集中型機能
次の機能は、マスター ユニット上だけでサポートされます。クラスタの場合もスケーリングされません。たとえば、8 ユニットから成るクラスタがあるとします(5516-X)。その他の VPN ライセンスでは、1 つの ASA 5516-X に対して最大 300 のサイト間 IPsec トンネルが許可されますが、8 ユニットのクラスタ全体では、300 トンネルのみ使用できます。この機能は拡張されません。
(注) |
中央集中型機能のトラフィックは、クラスタ制御リンク経由でメンバ ユニットからマスター ユニットに転送されます。 再分散機能を使用する場合は、中央集中型機能のトラフィックが中央集中型機能として分類される前に再分散が行われて、マスター以外のユニットに転送されることがあります。この場合は、トラフィックがマスター ユニットに送り返されます。 中央集中型機能については、マスター ユニットで障害が発生するとすべての接続がドロップされるので、新しいマスター ユニット上で接続を再確立する必要があります。 |
-
サイト間 VPN
-
次のアプリケーション インスペクション:
-
DCERPC
-
ESMTP
-
IM
-
NetBIOS
-
PPTP
-
RADIUS
-
RSH
-
SNMP
-
SQLNET
-
SUNRPC
-
TFTP
-
XDMCP
-
-
ダイナミック ルーティング(スパンド EtherChannel モードのみ)
-
マルチキャスト ルーティング(個別インターフェイス モードのみ)
-
スタティック ルート モニタリング
-
IGMP マルチキャスト コントロール プレーン プロトコル処理(データ プレーン フォワーディングはクラスタ全体に分散されます)
-
PIM マルチキャスト コントロール プレーン プロトコル処理(データ プレーン転送はクラスタ全体に分散されます)
-
ネットワーク アクセスの認証および許可。アカウンティングは非集中型です。
-
フィルタリング サービス
個々のユニットに適用される機能
これらの機能は、クラスタ全体またはマスター ユニットではなく、各 ASA ユニットに適用されます。
-
QoS:QoS ポリシーは、コンフィギュレーション複製の一部としてクラスタ全体で同期されます。ただし、ポリシーは、各ユニットに対して個別に適用されます。たとえば、出力に対してポリシングを設定する場合は、適合レートおよび適合バースト値は、特定の ASA から出て行くトラフィックに適用されます。3 ユニットから成るクラスタがあり、トラフィックが均等に分散している場合は、適合レートは実際にクラスタのレートの 3 倍になります。
-
脅威検出:脅威検出は、各ユニットに対して個別に機能します。たとえば、上位統計情報は、ユニット別です。たとえば、ポート スキャン検出が機能しないのは、スキャン トラフィックが全ユニット間で分散されるので、1 つのユニットがすべてのトラフィックを読み取ることはないからです。
-
リソース管理:マルチ コンテキスト モードでのリソース管理は、ローカル使用状況に基づいて各ユニットに個別に適用されます。
-
LISP トラフィック:UDP ポート 4342 上の LISP トラフィックは、各受信ユニットによって検査されますが、ディレクタは割り当てられません。各ユニットは、クラスタ間で共有される EID テーブルに追加されますが、LISP トラフィック自体はクラスタ状態の共有に参加しません。
-
ASA Firepower モジュール:ASA Firepower モジュール間でのコンフィギュレーションの同期や状態の共有は行われません。Firepower Management Center を使用して、クラスタ内の ASA Firepower モジュールで一貫したポリシーを保持する必要があります。クラスタ内のデバイスに異なる ASA インターフェイスベースのゾーン定義を使用しないでください。
-
ASA IPS モジュール:IPS モジュール間でのコンフィギュレーションの同期や状態の共有は行われません。IPS シグニチャによっては、IPS が複数の接続にわたって状態を保持することが必要になります。たとえば、ポート スキャン シグニチャが使用されるのは、同じ人物が同じサーバへの多数の接続を、それぞれ異なるポートを使用して開いていることを IPS モジュールが検出した場合です。クラスタリングでは、これらの接続は複数の ASA デバイス間で分散されます。これらのデバイスそれぞれに専用の IPS モジュールがあります。これらの IPS モジュールはステート情報を共有しないので、結果としてのポート スキャンをクラスタが検出できない場合があります。
ネットワーク アクセス用の AAA とクラスタリング
ネットワーク アクセス用の AAA は、認証、許可、アカウンティングの 3 つのコンポーネントで構成されます。認証および許可は、クラスタリング マスター上で中央集中型機能として実装されており、データ構造がクラスタ スレーブに複製されます。マスターが選定されたときは、確立済みの認証済みユーザおよびユーザに関連付けられた許可を引き続き中断なく運用するのに必要なすべての情報を、新しいマスターが保有します。ユーザ認証のアイドルおよび絶対タイムアウトは、マスター ユニット変更が発生したときも維持されます。
アカウンティングは、クラスタ内の分散型機能として実装されています。アカウンティングはフロー単位で実行されるので、フローを所有するクラスタ ユニットがアカウンティング開始と停止のメッセージを AAA サーバに送信します(フローに対するアカウンティングが設定されているとき)。
FTP とクラスタリング
-
FTP データ チャネルとコントロール チャネルのフローがそれぞれ別のクラスタ メンバよって所有されている場合は、データ チャネルのオーナーは定期的にアイドル タイムアウト アップデートをコントロール チャネルのオーナーに送信し、アイドル タイムアウト値を更新します。ただし、コントロール フローのオーナーがリロードされて、コントロール フローが再ホスティングされた場合は、親子フロー関係は維持されなくなります。したがって、コントロール フローのアイドル タイムアウトは更新されません。
-
FTP アクセスに AAA を使用している場合、制御チャネルのフローはマスター ユニットに集中化されます。
アイデンティティ ファイアウォールとクラスタリング
マスター ユニットのみが AD から user-group を取得し、AD エージェントから user-ip マッピングを取得します。マスター ユニットからユーザ情報がスレーブに渡されるので、スレーブは、セキュリティ ポリシーに基づいてユーザ ID の一致の決定を行うことができます。
マルチキャスト ルーティングとクラスタリング
マルチキャスト ルーティングは、インターフェイス モードによって動作が異なります。
スパンド EtherChannel モードでのマルチキャスト ルーティング
スパンド EtherChannel モードでは、ファースト パス転送が確立されるまでの間、マスター ユニットがすべてのマルチキャスト ルーティング パケットとデータ パケットを処理します。接続が確立された後は、各スレーブがマルチキャスト データ パケットを転送できます。
個別インターフェイス モードでのマルチキャスト ルーティング
個別インターフェイス モードでは、マルチキャストに関してユニットが個別に動作することはありません。データおよびルーティングのパケットはすべてマスター ユニットで処理されて転送されるので、パケット レプリケーションが回避されます。
NAT とクラスタリング
NAT は、クラスタの全体的なスループットに影響を与えることがあります。着信および発信の NAT パケットが、クラスタ内のそれぞれ別の ASA に送信されることがあります。ロード バランシング アルゴリズムは IP アドレスとポートに依存していますが、NAT が使用されるときは、着信と発信とで、パケットの IP アドレスやポートが異なるからです。NAT オーナーではない ASA に到着したパケットは、クラスタ制御リンクを介してオーナーに転送されるので、クラスタ制御リンクに大量のトラフィックが発生します。NAT オーナーはセキュリティおよびポリシー チェックの結果に応じてパケットの接続を作成するため、受信側ユニットは転送フローをオーナーに作成しません。
それでもクラスタリングで NAT を使用する場合は、次のガイドラインを考慮してください。
-
プロキシ ARP なし:個別インターフェイスの場合は、マッピング アドレスについてプロキシ ARP 応答が送信されることはありません。これは、クラスタに存在しなくなった可能性のある ASA と隣接ルータとがピア関係を維持することを防ぐためです。アップストリーム ルータは、メイン クラスタ IP アドレスを指すマッピング アドレスについてはスタティック ルートまたは PBR とオブジェクト トラッキングを使用する必要があります。これは、スパンド EtherChannel の問題ではありません。クラスタ インターフェイスには関連付けられた IP アドレスが 1 つしかないためです。
-
個別インターフェイスのインターフェイス PAT なし:インターフェイス PAT は、個別インターフェイスではサポートされていません。
-
ポート ブロック割り当てによる PAT なし:この機能はクラスタではサポートされていません。
-
ポート ブロック割り当てによる PAT:この機能については、次のガイドラインを参照してください。
-
ホストあたりの最大制限は、クラスタ全体の制限ではなく、各ユニットで個別に適用されます。したがって、ホストあたりの最大制限が 1 に設定されている 3 つのノードを持つクラスタにおいて、ホストからのトラフィックが 3 つすべてのユニットでロード バランシングされる場合、そのクラスタには 3 つのブロック(各ユニットに 1 つずつ)を割り当てることができます。
-
バックアップ プールからバックアップ ユニットに作成されたポート ブロックは、ホストあたりの最大制限の適用時には含まれません。
-
PAT IP アドレスのオーナーがダウンすると、バックアップ ユニットが PAT IP アドレス、対応するポート ブロック、および xlate を所有します。ただし、新しい要求を処理するためにこれらのブロックは使用されません。接続が最終的にタイムアウトすると、ブロックは解放されます。
-
PAT プールが完全に新しい IP アドレスの範囲で変更される On-the-fly PAT ルールの変更では、新しいプールが有効になっていてもいまだ送信中の xlate バックアップ要求に対する xlate バックアップの作成が失敗します。この動作はポートのブロック割り当て機能に固有なものではなく、プールが分散されトラフィックがクラスタ ユニット間でロード バランシングされるクラスタ展開でのみ見られる一時的な PAT プールの問題です。
-
-
ダイナミック PAT 用 NAT プール アドレス分散:マスター ユニットは、アドレスをクラスタ全体に均等に分配します。メンバーが接続を受信したときに、そのメンバーのアドレスが 1 つも残っていない場合は、接続はドロップされます(他のメンバーにはまだ使用可能なアドレスがある場合でも)。最低でも、クラスタ内のユニットと同数の NAT アドレスが含まれていることを確認してください。各ユニットが確実に 1 つのアドレスを受け取るようにするためです。アドレス割り当てを表示するには、show nat pool cluster コマンドを使用します。
-
ラウンドロビンなし:PAT プールのラウンドロビンは、クラスタリングではサポートされません。
-
マスター ユニットによって管理されるダイナミック NAT xlate:マスター ユニットが xlate テーブルを維持し、スレーブ ユニットに複製します。ダイナミック NAT を必要とする接続をスレーブ ユニットが受信したときに、その xlate がテーブル内にない場合は、スレーブはマスター ユニットに xlate を要求します。スレーブ ユニットが接続を所有します。
-
Per-session PAT 機能:クラスタリングに限りませんが、Per-session PAT 機能によって PAT のスケーラビリティが向上します。クラスタリングの場合は、各スレーブ ユニットが独自の PAT 接続を持てるようになります。対照的に、Multi-Session PAT 接続はマスター ユニットに転送する必要があり、マスター ユニットがオーナーとなります。デフォルトでは、すべての TCP トラフィックおよび UDP DNS トラフィックは per-session PAT xlate を使用します。これに対し、ICMP および他のすべての UDP トラフィックは multi-session を使用します。TCP および UDP に対しこれらのデフォルトを変更するように per-session NAT ルールを設定できますが、ICMP に per-session PAT を設定することはできません。H.323、SIP、または Skinny などの multi-session PAT のメリットを活用できるトラフィックでは、関連付けられている TCP ポートに対し per-session PAT を無効にできます(それらの H.323 および SIP の UDP ポートはデフォルトですでに multi-session になっています)。per-session PAT の詳細については、『ファイアウォールの構成ガイド』を参照してください。
-
次のインスペクション用のスタティック PAT はありません。
-
FTP
-
PPTP
-
RSH
-
SQLNET
-
TFTP
-
XDMCP
-
SIP
-
ダイナミック ルーティングおよびクラスタリング
ここでは、クラスタリングでダイナミック ルーティングを使用する方法について説明します。
スパンド EtherChannel モードでのダイナミック ルーティング
(注) |
IS-IS は、スパンド EtherChannel モードではサポートされていません。 |
スパンド EtherChannel モード:ルーティング プロセスはマスター ユニット上だけで実行されます。ルートはマスター ユニットを介して学習され、スレーブに複製されます。ルーティング パケットがスレーブに到着した場合は、マスター ユニットにリダイレクトされます。
スレーブ メンバがマスター ユニットからルートを学習した後は、各ユニットが個別に転送に関する判断を行います。
OSPF LSA データベースは、マスター ユニットからスレーブ ユニットに同期されません。マスター ユニットのスイッチオーバーが発生した場合は、隣接ルータが再起動を検出します。スイッチオーバーは透過的ではありません。OSPF プロセスが IP アドレスの 1 つをルータ ID として選択します必須ではありませんが、スタティック ルータ ID を割り当てることができます。これで、同じルータ ID がクラスタ全体で使用されるようになります。割り込みを解決するには、OSPF ノンストップ フォワーディング機能を参照してください。
個別インターフェイス モードでのダイナミック ルーティング
個別インターフェイス モードでは、各ユニットがスタンドアロン ルータとしてルーティング プロトコルを実行します。ルートの学習は、各ユニットが個別に行います。
上の図では、ルータ A はルータ B への等コスト パスが 4 本あることを学習します。パスはそれぞれ 1 つの ASA を通過します。ECMP を使用して、4 パス間でトラフィックのロード バランシングを行います。各 ASA は、外部ルータと通信するときに、それぞれ異なるルータ ID を選択します。
管理者は、各ユニットが別のルータ ID を使用できるように、ルータ ID のクラスタ プールを設定する必要があります。
EIGRP は、個別のインターフェイス モードのクラスタ ピアとのネイバー関係を形成しません。
(注) |
冗長性の目的で、クラスタに同じルータへの複数の隣接関係がある場合、非対称ルーティングは許容できないトラフィック損失の原因となる可能性があります。非対称ルーティングを避けるためには、同じトラフィックゾーンにこれらすべての ASA インターフェイスをまとめます。トラフィック ゾーンの設定を参照してください。 |
SCTP とクラスタリング
SCTP 関連付けは、任意のユニットで作成できます(ロード バランシングのため)。そのマルチホーミング接続は同じユニットに存在する必要があります。
SIP インスペクションとクラスタリング
制御フローは、任意のユニットで作成できます(ロード バランシングのため)。その子データ フローは同じユニットに存在する必要があります。
TLS プロキシ設定はサポートされていません。
SNMP とクラスタリング
SNMP エージェントは、個々の ASA を、そのローカル IP アドレスによってポーリングします。クラスタの統合データをポーリングすることはできません。
SNMP ポーリングには、メイン クラスタ IP アドレスではなく、常にローカル アドレスを使用してください。SNMP エージェントがメイン クラスタ IP アドレスをポーリングする場合は、新しいマスターが選定されたときに、新しいマスター ユニットのポーリングに失敗します。
STUN とクラスタリング
ピンホールが複製されるとき、STUN インスペクションはフェールオーバー モードとクラスタ モードでサポートされます。ただし、トランザクション ID はユニット間で複製されません。STUN 要求の受信後にユニットに障害が発生し、別のユニットが STUN 応答を受信した場合、STUN 応答はドロップされます。
syslog および NetFlow とクラスタリング
-
Syslog:クラスタの各ユニットは自身の syslog メッセージを生成します。各ユニットの syslog メッセージ ヘッダー フィールドで使用されるデバイス ID を同一にするか、別にするかを設定できます。たとえば、ホスト名コンフィギュレーションはクラスタ内のすべてのユニットに複製されて共有されます。ホスト名をデバイス ID として使用するようにロギングを設定した場合は、どのユニットで生成された syslog メッセージも 1 つのユニットからのように見えます。クラスタ ブートストラップ コンフィギュレーションで割り当てられたローカル ユニット名をデバイス ID として使用するようにロギングを設定した場合は、syslog メッセージはそれぞれ別のユニットからのように見えます。
-
NetFlow:クラスタの各ユニットは自身の NetFlow ストリームを生成します。NetFlow コレクタは、各 ASA を独立した NetFlow エクスポータとしてのみ扱うことができます。
Cisco TrustSec とクラスタリング
マスター ユニットだけがセキュリティ グループ タグ(SGT)情報を学習します。マスター ユニットからこの SGT がスレーブに渡されるので、スレーブは、セキュリティ ポリシーに基づいて SGT の一致決定を下せます。
VPN とクラスタリング
サイトツーサイト VPN は、中央集中型機能です。マスター ユニットだけが VPN 接続をサポートします。分散型サイト間 VPN クラスタリングがサポートされています。詳細については、この pdf のハイ アベイラビリティ オプションを検索してください。
(注) |
リモート アクセス VPN は、クラスタリングではサポートされません。 |
VPN 機能を使用できるのはマスター ユニットだけであり、クラスタのハイ アベイラビリティ能力は活用されません。マスター ユニットで障害が発生した場合は、すべての既存の VPN 接続が失われ、VPN ユーザにとってはサービスの中断となります。新しいマスターが選定されたときに、VPN 接続を再確立する必要があります。
VPN トンネルをスパンド EtherChannel アドレスに接続すると、接続が自動的にマスター ユニットに転送されます。PBR または ECMP を使用するときの個別インターフェイスへの接続については、ローカル アドレスではなく、常にメイン クラスタ IP アドレスに接続する必要があります。
VPN 関連のキーと証明書は、すべてのユニットに複製されます。