Firepower 4100/9300 シャーシでのクラスタリングについて
クラスタは、単一の論理ユニットとして機能する複数のデバイスから構成されます。Firepower 4100/9300 シャーシ にクラスタを導入すると、以下の処理が実行されます。
-
ユニット間通信用のクラスタ制御リンク(デフォルトのポート チャネル 48)を作成します。シャーシ内クラスタリングでは(Firepower 9300のみ)、このリンクは、クラスタ通信に Firepower 9300 バックプレーンを使用します。シャーシ間クラスタリングでは、シャーシ間通信のために、この EtherChannel に物理インターフェイスを手動で割り当てる必要があります。
-
アプリケーション内のクラスタ ブートストラップ コンフィギュレーションを作成します。
クラスタを展開すると、クラスタ名、クラスタ制御リンク インターフェイス、およびその他のクラスタ設定を含む各ユニットに対して、最小限のブートストラップ構成が Firepower 4100/9300 シャーシ スーパーバイザからプッシュされます。クラスタリング環境をカスタマイズする場合、ブートストラップ コンフィギュレーションの一部は、アプリケーション内でユーザが設定できます。
-
スパンド インターフェイスとして、クラスタにデータ インターフェイスを割り当てます。
シャーシ内クラスタリングでは、スパンド インターフェイスは、シャーシ間クラスタリングのように EtherChannel に制限されません。Firepower 9300 スーパーバイザは共有インターフェイスの複数のモジュールにトラフィックをロードバランシングするために内部で EtherChannel テクノロジーを使用するため、スパンド モードではあらゆるタイプのデータ インターフェイスが機能します。シャーシ間クラスタリングでは、すべてのデータ インターフェイスでスパンド EtherChannel を使用します。
(注)
管理インターフェイス以外の個々のインターフェイスはサポートされていません。
-
管理インターフェイスをクラスタ内のすべてのユニットに指定します。
ここでは、クラスタリングの概念と実装について詳しく説明します。
パフォーマンス スケーリング係数
複数のユニットをクラスタに結合した場合、期待できる合計クラスタ パフォーマンスの概算値は次のようになります。
-
TCP または CPS の合計スループットの 80 %
-
UDP の合計スループットの 90 %
-
トラフィックの混在に応じて、イーサネット MIX(EMIX)の合計スループットの 60 %。
たとえば、TCP スループットについては、3 つのモジュールを備えた Firepower 9300 は、単独で動作している場合、約 135 Gbps の実際のファイアウォール トラフィックを処理できます。2 シャーシの場合、最大スループットの合計は 270 Gbps(2 シャーシ X 135 Gbps)の約 80 %、つまり 216 Gbps です。
Bootstrap Configuration
クラスタを展開すると、クラスタ名、クラスタ制御リンク インターフェイス、およびその他のクラスタ設定を含む各ユニットに対して、最小限のブートストラップ構成が Firepower 4100/9300 シャーシ スーパーバイザからプッシュされます。クラスタリング環境をカスタマイズする場合、ブートストラップ コンフィギュレーションの一部はユーザが設定できます。
クラスタ メンバー
クラスタ メンバは連携して動作し、セキュリティ ポリシーおよびトラフィック フローの共有を実現します。ここでは、各メンバのロールの特長について説明します。
マスターおよびスレーブ ユニットの役割
クラスタ内のメンバの 1 つがマスター ユニットです。マスター ユニットは自動的に決定されます。他のすべてのメンバはスレーブ ユニットです。
すべてのコンフィギュレーション作業はマスター ユニット上でのみ実行する必要があります。コンフィギュレーションはその後、スレーブ ユニットに複製されます。
機能によっては、クラスタ内でスケーリングしないものがあり、そのような機能についてはマスター ユニットがすべてのトラフィックを処理します。クラスタリングの中央集中型機能 を参照してください。。
マスター ユニット選定
クラスタのメンバは、クラスタ制御リンクを介して通信してマスター ユニットを選定します。方法は次のとおりです。
-
クラスタを展開すると、各ユニットは選定要求を 3 秒ごとにブロードキャストします。
-
プライオリティの高い他のユニットがこの選定要求に応答します。プライオリティはクラスタの展開時に設定され、設定の変更はできません。
-
45 秒経過しても、プライオリティの高い他のユニットからの応答を受信していない場合は、そのユニットがマスターになります。
-
後からクラスタに参加したユニットのプライオリティの方が高い場合でも、そのユニットが自動的にマスター ユニットになることはありません。既存のマスター ユニットは常にマスターのままです。ただし、マスター ユニットが応答を停止すると、その時点で新しいマスター ユニットが選定されます。
![]() (注) |
特定のユニットを手動で強制的にマスターにすることができます。中央集中型機能については、マスター ユニット変更を強制するとすべての接続がドロップされるので、新しいマスター ユニット上で接続を再確立する必要があります。 |
クラスタ インターフェイス
シャーシ内クラスタリングでは、物理インターフェイス、EtherChannel (ポートチャネルとも呼ばれる)の両方を割り当てることができます。クラスタに割り当てられたインターフェイスはクラスタ内のすべてのメンバーのトラフィックのロード バランシングを行うスパンド インターフェイスです。
シャーシ間クラスタリングでは、データ EtherChannel のみをクラスタに割り当てできます。これらのスパンド EtherChannel は、各シャーシの同じメンバー インターフェイスを含みます。アップストリーム スイッチでは、これらのインターフェイスはすべて単一の EtherChannel に含まれ、スイッチは複数のデバイスに接続されていることを察知しません。
管理インターフェイス以外の個々のインターフェイスはサポートされていません。
VSS または vPC への接続
インターフェイスに冗長性を確保するため、EtherChannel を VSS または vPC に接続することを推奨します。
クラスタ制御リンク
クラスタ制御リンクはユニット間通信用の EtherChannel(ポート チャネル 48)です。シャーシ内クラスタリングでは、このリンクは、クラスタ通信に Firepower 9300 バックプレーンを使用します。シャーシ間クラスタリングでは、シャーシ間通信のために、Firepower 4100/9300 シャーシのこの EtherChannel に物理インターフェイスを手動で割り当てる必要があります。
2 シャーシのシャーシ間クラスタの場合、シャーシと他のシャーシの間をクラスタ制御リンクで直接接続しないでください。インターフェイスを直接接続した場合、一方のユニットで障害が発生すると、クラスタ制御リンクが機能せず、他の正常なユニットも動作しなくなります。スイッチを介してクラスタ制御リンクを接続した場合は、正常なユニットについてはクラスタ制御リンクは動作を維持します。
クラスタ制御リンク トラフィックには、制御とデータの両方のトラフィックが含まれます。
制御トラフィックには次のものが含まれます。
-
マスター選定。
-
コンフィギュレーションの複製
-
ヘルス モニタリング。
データ トラフィックには次のものが含まれます。
-
ステート複製。
-
接続所有権クエリーおよびデータ パケット転送。
クラスタ制御リンク ネットワーク
Firepower 4100/9300 シャーシは、シャーシ ID およびスロット ID(127.2.chassis_id.slot_id)に基づいて、各ユニットのクラスタ制御リンク インターフェイス IP アドレスを自動生成します。この IP アドレスは、FXOS でもアプリケーション内でも手動で設定できません。クラスタ制御リンク ネットワークには、ユニット間のルータを含めることはできません。レイヤ 2 スイッチングのみが許可されます。サイト間トラフィックには、オーバーレイ トランスポート仮想化(OTV)を使用することをお勧めします。
クラスタ内のハイ アベイラビリティ
クラスタリングは、シャーシ、ユニットとインターフェイスの正常性を監視し、ユニット間で接続状態を複製することにより、ハイ アベイラビリティを提供します。
シャーシアプリケーションのモニタリング
シャーシアプリケーションのヘルス モニタリングは常に有効になっています。Firepower 4100/9300 シャーシスーパーバイザはASAアプリケーションを定期的に確認します(毎秒)。ASAが作動中で、Firepower 4100/9300 シャーシスーパーバイザと 3 秒間通信できなければASAは syslog メッセージを生成して、クラスタを離れます。
Firepower 4100/9300 シャーシスーパーバイザが 45 秒後にアプリケーションと通信できなければ、ASAをリロードします。ASAがスーパーバイザと通信できなければ、自身をクラスタから削除します。
ユニットのヘルス モニタリング
マスター ユニットは、各スレーブ ユニットをモニタするために、クラスタ制御リンクを介してハートビート メッセージを定期的に送信します(間隔は設定可能です)。各スレーブ ユニットは、同じメカニズムを使用してマスター ユニットをモニタします。ユニットの健全性チェックが失敗すると、ユニットはクラスタから削除されます。
インターフェイス モニタリング
各ユニットは、使用中のすべてのハードウェア インターフェイスのリンク ステータスをモニタし、ステータス変更をマスター ユニットに報告します。シャーシ間クラスタリングでは、スパンド EtherChannel はクラスタ Link Aggregation Control Protocol(cLACP)を使用します。 各シャーシはリンク ステータスと cLACP プロトコル メッセージをモニタして EtherChannel でポートがアクティブであるかどうかを判別し、インターフェイスがダウンしている場合には ASA アプリケーションに通知します。ヘルス モニタリングを有効にすると、デフォルトではすべての物理インターフェイスがモニタされます(EtherChannel インターフェイスのメイン EtherChannel を含む)。アップ状態の指名されたインターフェイスのみモニタできます。たとえば、名前付き EtherChannel がクラスタから削除される前に、EtherChannel のすべてのメンバー ポートがエラーとなる必要があります(最小ポート バンドル設定に基づく)。オプションで、インターフェイスごとにモニタリングを無効にできます。
あるモニタ対象のインターフェイスが、特定のユニット上では障害が発生したが、別のユニットではアクティブの場合は、そのユニットはクラスタから削除されます。ASA がメンバーをクラスタから削除するまでの時間は、そのユニットが確立済みメンバーであるか、またはクラスタに参加しようとしているかによって異なります。ASA は、ユニットがクラスタに参加する最初の 90 秒間はインターフェイスを監視ししません。この間にインターフェイスのステータスが変化しても、ASA はクラスタから削除されません。設定済みのメンバーの場合は、500 ミリ秒後にユニットが削除されます
シャーシ間クラスタリングでは、クラスタから EtherChannel を追加または削除した場合、各シャーシに変更を加えられるように、インターフェイス ヘルス モニタリングは 95 秒間中断されます。
デコレータ アプリケーションのモニタリング
インターフェイスに Radware DefensePro アプリケーションなどのデコレータ アプリケーションをインストールした場合、ユニットがクラスタ内にとどまるには ASA、デコレータ アプリケーションの両方が動作している必要があります。両方のアプリケーションが動作状態になるまで、ユニットはクラスタに参加しません。一旦クラスタに参加すると、ユニットはデコレータ アプリケーションが正しく動作しているか 3 秒ごとにモニタします。デコレータ アプリケーションがダウンすると、ユニットはクラスタから削除されます。
障害後のステータス
クラスタ内のユニットで障害が発生したときに、そのユニットでホスティングされている接続は他のユニットにシームレスに移管されます。トラフィック フローのステート情報は、クラスタ制御リンクを介して共有されます。
マスター ユニットで障害が発生した場合は、そのクラスタの他のメンバーのうち、プライオリティが最高(番号が最小)のものがマスター ユニットになります。
障害イベントに応じて、ASA は自動的にクラスタへの再参加を試みます。
![]() (注) |
ASA が非アクティブになり、クラスタへの自動再参加に失敗すると、すべてのデータ インターフェイスがシャットダウンされます。管理専用インターフェイスのみがトラフィックを送受信できます。管理インターフェイスは、そのユニットがクラスタ IP プールから受け取った IP アドレスを使用して引き続き稼働状態となります。ただし、リロードする場合、クラスタでユニットがまだ非アクティブになっていると、管理インターフェイスはディセーブルになります。それ以降のコンフィギュレーション作業には、コンソール ポートを使用する必要があります。 |
クラスタへの再参加
クラスタ メンバがクラスタから削除された後、クラスタに再参加できる方法は、削除された理由によって異なります。
-
クラスタ制御リンクの障害:(最初の参加時)クラスタ制御リンクの問題を解決した後、、手動でクラスタに再参加する必要があります。
-
クラスタに参加した後に障害が発生したクラスタ制御リンク:ASA は、無限に 5 分ごとに自動的に再参加を試みます。この動作は設定可能です。
-
データ インターフェイスの障害:ASA は自動的に最初は 5 分後、次に 10 分後、最終的に 20 分後に再参加を試みます。20 分後に参加できない場合、ASA はクラスタリングをディセーブルにします。データ インターフェイスの問題を解決した後、手動でクラスタリングをイネーブルにする必要があります。この動作は設定可能です。
-
ユニットの障害:ユニットがヘルス チェック失敗のためクラスタから削除された場合、クラスタへの再参加は失敗の原因によって異なります。たとえば、一時的な電源障害の場合は、クラスタ制御リンクが稼働している限り、ユニットは再起動するとクラスタに再参加します。ユニットは 5 秒ごとにクラスタへの再参加を試みます。
-
シャーシ アプリケーション通信の障害:ASA がシャーシ アプリケーションの状態が回復したことを検出すると、ASA は自動的にクラスタの再参加を試みます。
-
デコレータ アプリケーションの障害:ASA はデコレータ アプリケーションが復帰したことを確認すると、クラスタへ再参加します。
-
内部エラー:内部の障害には、アプリケーション同期のタイムアウト、矛盾したアプリケーション ステータスなどがあります。ユニットは 5 分、10 分、および 20 分の間隔でクラスタに自動的に再参加を試行します。この動作は設定可能です。
データ パス接続状態の複製
どの接続にも、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 セッションは、マスター ユニットで障害が発生すると切断されます。 |
分散型 VPN(サイト間) |
Yes |
バックアップ セッションがアクティブ セッションになると、新しいバックアップ セッションが作成されます。 |
設定の複製
クラスタ内のすべてのユニットは、単一のコンフィギュレーションを共有します。コンフィギュレーション変更を加えることができるのはマスター ユニット上だけであり、変更は自動的にクラスタ内の他のすべてのユニットに同期されます。
ASAクラスタの管理
ASA クラスタリングを使用することの利点の 1 つは、管理のしやすさです。ここでは、クラスタを管理する方法について説明します。
管理インターフェイス
管理タイプのインターフェイスをクラスタに割り当てる必要があります。このインターフェイスはスパンド インターフェイスではなく、特別な個別インターフェイスです。管理インターフェイスによって各ユニットに直接接続できます。
メイン クラスタ IP アドレスは、そのクラスタのための固定アドレスであり、常に現在のマスター ユニットに属します。アドレス範囲も設定して、現在のマスターを含む各ユニットがその範囲内のローカル アドレスを使用できるようにします。このメイン クラスタ IP アドレスによって、管理アクセスのアドレスが一本化されます。マスター ユニットが変更されると、メイン クラスタ IP アドレスは新しいマスター ユニットに移動するので、クラスタの管理をシームレスに続行できます。
たとえば、クラスタを管理するにはメイン クラスタ IP アドレスに接続します。このアドレスは常に、現在のマスター ユニットに関連付けられています。個々のメンバを管理するには、ローカル IP アドレスに接続します。
TFTP や syslog などの発信管理トラフィックの場合、マスター ユニットを含む各ユニットは、ローカル IP アドレスを使用してサーバに接続します。
マスター ユニット管理とスレーブ ユニット管理
すべての管理とモニタリングはマスター ユニットで実行できます。マスター ユニットから、すべてのユニットの実行時統計情報やリソース使用状況などのモニタリング情報を調べることができます。また、クラスタ内のすべてのユニットに対してコマンドを発行することや、コンソール メッセージをスレーブ ユニットからマスター ユニットに複製することもできます。
必要に応じて、スレーブ ユニットを直接モニタできます。マスター ユニットからでもできますが、ファイル管理をスレーブ ユニット上で実行できます(コンフィギュレーションのバックアップや、イメージの更新など)。次の機能は、マスター ユニットからは使用できません。
-
ユニットごとのクラスタ固有統計情報のモニタリング。
-
ユニットごとの 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 インスペクションを使用したフロー モビリティの有効化、データセンターのサイト間クラスタリングのパフォーマンス向上とラウンドトリップ時間の遅延短縮のためのディレクタ ローカリゼーションの有効化、およびトラフィック フローのバックアップ オーナーが常にオーナーとは異なるサイトに存在する接続に対するサイト冗長性の有効化のためにも使用されます。
サイト間クラスタリングの詳細については、以下の項を参照してください。
-
クラスタ フロー モビリティの設定:クラスタ フロー モビリティの設定
-
ディレクタ ローカリゼーションの有効化: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 の詳細については、ファイアウォールの設定ガイドを参照してください。
新しい接続の所有権
新しい接続がロード バランシング経由でクラスタのメンバに送信される場合は、そのユニットがその接続の両方向のオーナーとなります。接続のパケットが別のユニットに到着した場合は、そのパケットはクラスタ制御リンクを介してオーナー ユニットに転送されます。逆方向のフローが別のユニットに到着した場合は、元のユニットにリダイレクトされます。
サンプル データ フロー
次の例は、新しい接続の確立を示します。
![](/c/dam/en/us/td/i/300001-400000/330001-340000/333001-334000/333480.eps/_jcr_content/renditions/333480.jpg)
-
SYN パケットがクライアントから発信され、ASA の 1 つ(ロード バランシング方法に基づく)に配信されます。これがオーナーとなります。オーナーはフローを作成し、オーナー情報をエンコードして SYN Cookie を生成し、パケットをサーバに転送します。
-
SYN-ACK パケットがサーバから発信され、別の ASA(ロード バランシング方法に基づく)に配信されます。この ASA はフォワーダです。
-
フォワーダはこの接続を所有してはいないので、オーナー情報を SYN Cookie からデコードし、オーナーへの転送フローを作成し、SYN-ACK をオーナーに転送します。
-
オーナーはディレクタに状態アップデートを送信し、SYN-ACK をクライアントに転送します。
-
ディレクタは状態アップデートをオーナーから受信し、オーナーへのフローを作成し、オーナーと同様に TCP ステート情報を記録します。ディレクタは、この接続のバックアップ オーナーとしての役割を持ちます。
-
これ以降、フォワーダに配信されたパケットはすべて、オーナーに転送されます。
-
パケットがその他のユニットに配信された場合は、そのユニットはディレクタに問い合わせてオーナーを特定し、フローを確立します。
-
フローの状態が変化した場合は、状態アップデートがオーナーからディレクタに送信されます。
ASA の各機能とクラスタリング
ASA の一部の機能は ASA クラスタリングではサポートされず、一部はマスター ユニットだけでサポートされます。その他の機能については適切な使用に関する警告がある場合があります。
クラスタリングでサポートされない機能
これらの機能は、クラスタリングがイネーブルのときは設定できず、コマンドは拒否されます。
-
TLS プロキシを使用するユニファイド コミュニケーション機能
-
リモート アクセス VPN(SSL VPN および IPSec VPN)
-
IS-IS ルーティング
-
次のアプリケーション インスペクション:
-
CTIQBE
-
H323、H225、および RAS
-
IPsec パススルー
-
MGCP
-
MMP
-
RTSP
-
SCCP(Skinny)
-
WAAS
-
WCCP
-
-
Botnet Traffic Filter
-
Auto Update Server
-
DHCP クライアント、サーバ、およびプロキシDHCP リレーがサポートされている。
-
VPN ロード バランシング
-
フェールオーバー
-
Integrated Routing and Bridging(IRB)
クラスタリングの中央集中型機能
次の機能は、マスター ユニット上だけでサポートされます。クラスタの場合もスケーリングされません。
![]() (注) |
中央集中型機能のトラフィックは、クラスタ制御リンク経由でメンバ ユニットからマスター ユニットに転送されます。 再分散機能を使用する場合は、中央集中型機能のトラフィックが中央集中型機能として分類される前に再分散が行われて、マスター以外のユニットに転送されることがあります。この場合は、トラフィックがマスター ユニットに送り返されます。 中央集中型機能については、マスター ユニットで障害が発生するとすべての接続がドロップされるので、新しいマスター ユニット上で接続を再確立する必要があります。 |
-
次のアプリケーション インスペクション:
-
DCERPC
-
NetBIOS
-
PPTP
-
RADIUS
-
RSH
-
SUNRPC
-
TFTP
-
XDMCP
-
-
ダイナミック ルーティング
-
スタティック ルート モニタリング
-
IGMP マルチキャスト コントロール プレーン プロトコル処理(データ プレーン フォワーディングはクラスタ全体に分散されます)
-
PIM マルチキャスト コントロール プレーン プロトコル処理(データ プレーン フォワーディングはクラスタ全体に分散されます)
-
ネットワーク アクセスの認証および許可。アカウンティングは非集中型です。
-
フィルタリング サービス
-
サイト間 IKEv1/IKEv2 VPN
集中モードでは、VPN 接続はクラスタのマスターとのみ確立されます。これは、VPN クラスタリングのデフォルト モードです。サイト間 VPN は、S2S IKEv2 VPN 接続がメンバー間で分散される分散型 VPN モードでも展開できます。
個々のユニットに適用される機能
これらの機能は、クラスタ全体またはマスター ユニットではなく、各 ASA ユニットに適用されます。
-
QoS:QoS ポリシーは、コンフィギュレーション複製の一部としてクラスタ全体で同期されます。ただし、ポリシーは、各ユニットに対して個別に適用されます。たとえば、出力に対してポリシングを設定する場合は、適合レートおよび適合バースト値は、特定の ASA から出て行くトラフィックに適用されます。3 ユニットから成るクラスタがあり、トラフィックが均等に分散している場合は、適合レートは実際にクラスタのレートの 3 倍になります。
-
脅威検出:脅威検出は、各ユニットに対して個別に機能します。たとえば、上位統計情報は、ユニット別です。たとえば、ポート スキャン検出が機能しないのは、スキャン トラフィックが全ユニット間で分散されるので、1 つのユニットがすべてのトラフィックを読み取ることはないからです。
-
リソース管理:マルチ コンテキスト モードでのリソース管理は、ローカル使用状況に基づいて各ユニットに個別に適用されます。
-
LISP トラフィック:UDP ポート 4342 上の LISP トラフィックは、各受信ユニットによって検査されますが、ディレクタは割り当てられません。各ユニットは、クラスタ間で共有される EID テーブルに追加されますが、LISP トラフィック自体はクラスタ状態の共有に参加しません。
ネットワーク アクセス用の AAA とクラスタリング
ネットワーク アクセス用の AAA は、認証、許可、アカウンティングの 3 つのコンポーネントで構成されます。認証および許可は、クラスタリング マスター上で中央集中型機能として実装されており、データ構造がクラスタ スレーブに複製されます。マスターが選定されたときは、確立済みの認証済みユーザおよびユーザに関連付けられた許可を引き続き中断なく運用するのに必要なすべての情報を、新しいマスターが保有します。ユーザ認証のアイドルおよび絶対タイムアウトは、マスター ユニット変更が発生したときも維持されます。
アカウンティングは、クラスタ内の分散型機能として実装されています。アカウンティングはフロー単位で実行されるので、フローを所有するクラスタ ユニットがアカウンティング開始と停止のメッセージを AAA サーバに送信します(フローに対するアカウンティングが設定されているとき)。
FTP とクラスタリング
-
FTP データ チャネルとコントロール チャネルのフローがそれぞれ別のクラスタ メンバーよって所有されている場合は、データ チャネルのオーナーは定期的にアイドル タイムアウト アップデートをコントロール チャネルのオーナーに送信し、アイドル タイムアウト値を更新します。ただし、コントロール フローのオーナーがリロードされて、コントロール フローが再ホスティングされた場合は、親子フロー関係は維持されなくなります。したがって、コントロール フローのアイドル タイムアウトは更新されません。
-
FTP アクセスに AAA を使用している場合、制御チャネルのフローはマスター ユニットに集中化されます。
アイデンティティ ファイアウォールとクラスタリング
マスター ユニットのみが AD から user-group を取得し、AD エージェントから user-ip マッピングを取得します。マスター ユニットからユーザ情報がスレーブに渡されるので、スレーブは、セキュリティ ポリシーに基づいてユーザ ID の一致の決定を行うことができます。
マルチキャスト ルーティングとクラスタリング
ファースト パス転送が確立されるまでの間、マスター ユニットがすべてのマルチキャスト ルーティング パケットとデータ パケットを処理します。接続が確立された後は、各スレーブがマルチキャスト データ パケットを転送できます。
NAT とクラスタリング
NAT は、クラスタの全体的なスループットに影響を与えることがあります。着信および発信の NAT パケットが、クラスタ内のそれぞれ別の ASA に送信されることがあります。ロード バランシング アルゴリズムは IP アドレスとポートに依存していますが、NAT が使用されるときは、着信と発信とで、パケットの IP アドレスやポートが異なるからです。接続のオーナーではない ASA に到着したパケットは、クラスタ制御リンクを介してオーナーに転送されるので、大量のトラフィックがクラスタ制御リンク上で発生します。
それでもクラスタリングで NAT を使用する場合は、次のガイドラインを考慮してください。
-
ポート ブロック割り当てによる 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
-
ダイナミック ルーティングおよびクラスタリング
ルーティング プロセスはマスター ユニット上だけで実行されます。ルートはマスター ユニットを介して学習され、セカンダリに複製されます。ルーティング パケットがスレーブに到着した場合は、マスター ユニットにリダイレクトされます。
![](/c/dam/en/us/td/i/400001-500000/400001-410000/404001-405000/404212.eps/_jcr_content/renditions/404212.jpg)
スレーブ メンバがマスター ユニットからルートを学習した後は、各ユニットが個別に転送に関する判断を行います。
OSPF LSA データベースは、マスター ユニットからスレーブ ユニットに同期されません。マスター ユニットのスイッチオーバーが発生した場合は、隣接ルータが再起動を検出します。スイッチオーバーは透過的ではありません。OSPF プロセスが IP アドレスの 1 つをルータ ID として選択します必須ではありませんが、スタティック ルータ ID を割り当てることができます。これで、同じルータ ID がクラスタ全体で使用されるようになります。割り込みを解決するには、OSPF ノンストップ フォワーディング機能を参照してください。
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 の一致の決定を行うことができます。
FXOS シャーシ上の VPN とクラスタリング
ASA FXOS クラスタは、S2S VPN に対する相互排他的な 2 つのモード(集中型または分散型)のいずれかをサポートしています。
-
集中型 VPN モード。デフォルト モードです。集中モードでは、VPN 接続はクラスタのマスターとのみ確立されます。
VPN 機能を使用できるのはマスター ユニットだけであり、クラスタのハイ アベイラビリティ能力は活用されません。マスター ユニットで障害が発生した場合は、すべての既存の VPN 接続が失われ、VPN 接続されたユーザにとってはサービスの中断となります。新しいマスターが選定されたときに、VPN 接続を再確立する必要があります。
VPN トンネルをスパンド インターフェイスのアドレスに接続すると、接続が自動的にマスター ユニットに転送されます。VPN 関連のキーと証明書は、すべてのユニットに複製されます。
-
分散型 VPN モード。このモードでは、S2S IPsec IKEv2 VPN 接続が ASA クラスタのメンバー全体に分散され、拡張性が提供されます。クラスタのメンバー全体に VPN 接続を分散することで、クラスタの容量とスループットの両方を最大限に活用できるため、集中型 VPN の機能を超えて大幅に VPN サポートを拡張できます。
![]() (注) |
集中型 VPN クラスタリング モードは、S2S IKEv1 と S2S IKEv2 をサポートしています。 分散型 VPN クラスタリング モードは、S2S IKEv2 のみをサポートしています。 分散型 VPN クラスタリング モードは、Firepower 9300 でのみサポートされています。 リモート アクセス VPN は、集中型または分散型の VPN クラスタリング モードではサポートされていません。 |