【Check Point R80.40】ClusterXL の概要【冗長化】

ClusterXL とは

ClusterXL は、Security Gateway の冗長性と負荷分散のための Check Point ソフトウェアベースのクラスターソリューションです。 ClusterXL Security Clusterには、同一の Check Point Security Gatewayが含まれています。

High Availability モードでは、障害が発生した場合にバックアップ Security Gateway に透過的なフェイルオーバーを提供することにより、Security Gateway と VPN 接続の冗長性を確保します
Load Sharing モード では、すべてのメンバーがアクティブであるため、信頼性を提供し、パフォーマンスも向上させます

ClusterXL は、状態同期を使用してアクティブな接続を維持し、クラスターメンバーに障害が発生した場合のデータ損失を防ぎます
状態同期を使用すると、各クラスターメンバーは、他のクラスターメンバーを経由する接続について「認識」します
ClusterXL は、クラスター自体に仮想 IP アドレスを使用し、クラスターメンバーに一意の物理 IP アドレスと MAC アドレスを使用します
仮想 IP アドレスは物理インターフェースに属していません

Cluster Control Protocol (CCP)

Cluster Control Protocol（CCP）パケットは、セキュリティクラスターのメンバーを関連付ける “接着剤” です
CCP トラフィックは、通常のネットワークトラフィックとは異なり、任意のネットワークスニファを使用して表示できます
CCP は、クラスターメンバー間の UDP ポート 8116 で動作し、次の役割を果たします
- クラスターメンバーは、CCP によってキープアライブパケットを送信することにより、自分の状態を報告し、他のメンバーの状態について知ることができます
  - これは ClusterXL クラスターにのみ適用されます
- 状態同期（Delta Sync）
Check Point CCP は、すべての ClusterXL モードで使用されます

CCP パケットを受け入れるセキュリティポリシールールベースに明示的なルールを追加する必要はありません。

構成要件

次のいずれかの構成で Check Point アプライアンスに ClusterXL を適用できます。

分散構成: クラスターメンバーとセキュリティ管理サーバーは異なるデバイスにインストールされます
完全高可用性構成: クラスターメンバーとセキュリティ管理サーバーが同じデバイスにインストールされます（各デバイスはスタンドアロン構成を実行します）

分散構成の場合のみ、Open Servers に ClusterXL を適用できます。

サポートメンバー数

High Availability モードでは、最大 5 のクラスターメンバーをサポートします
Load Sharing モードでは、最大 5 のクラスターメンバーをサポートします

4 を超えるメンバーを構成すると、Delta Sync の量が増えるため、クラスターのパフォーマンスが大幅に低下します。

Virtual System Load Sharing（VSLS）モードは、最大 13 のクラスターメンバーをサポートします

もう一つの冗長手段である VRRP クラスターは、2 のクラスターメンバーのみをサポートします（sk105170を参照）。

ハードウェア要件

ClusterXL の動作は、ハードウェアクロックティックに基づく内部タイマーと内部タイムアウトの計算に完全に依存しています。したがって、予期しない動作を回避するために、ClusterXL は同じ CPU 特性を持つマシン間でのみサポートされます。

ベストプラクティス

クラスターインターフェース上の CCP パケットの問題による予期しないフェイルオーバーを回避するために、スイッチを介してクラスターメンバーを接続する場合でも、クラスターインターフェースと同一の物理インターフェースのみをペアリングすることが強く推奨されています。

例：

Member_A の Intel 82598EB と Member_B の Intel 82598EB
Member_A の Broadcom NeXtreme と Member_B の Broadcom NeXtreme

同期インターフェースのスループットがトラフィックインターフェースのスループットと同じであるか、それよりも大きい必要はありません。ただし、ボトルネックの可能性を防ぐために、同期インターフェースのスループットのグッドプラクティスは、少なくともトラフィックインターフェースのスループットと同じである必要があります。

ソフトウェア要件

ClusterXL は、同一の Check Point ソフトウェアバージョン間でのみサポートされます。すべてのクラスターメンバーは、OS ビルドとホットフィックスを含む同一の Check Point ソフトウェアである必要があります
すべての Check Point ソフトウェアコンポーネントは、すべてのクラスターメンバーで同じである必要があります。つまり、すべてのクラスターメンバーで同じソフトウェアブレードと機能を有効にする必要があります
- すべてのクラスターメンバーの SecureXL ステータスは同じである必要があります（有効または無効）
- すべてのクラスターメンバーの CoreXL FW インスタンスの数は同じである必要があります
- すべてのクラスターメンバーの高度な動的ルーティングのステータスと構成は同じである必要があります

CoreXL ファイアウォールインスタンスの数が多いクラスターメンバーはその状態を DOWN に変更します
クラスターメンバーからより多くの CoreXL ファイアウォールインスタンスを持つピアクラスターメンバーへのフェイルオーバーは、すべての接続を維持します
クラスターメンバーから、より小さなクラスターメンバーのピアへのフェイルオーバー
CoreXL ファイアウォールインスタンスの数が一部の接続を中断します。中断される接続は、ピアクラスターメンバーに存在しない CoreXL ファイアウォールインスタンスを通過する接続です

VMAC モード

フェイルオーバーが発生した後、新しいアクティブメンバー（またはピボットメンバー）は、一連の Gratuitous ARP リクエスト（GARP）をブロードキャストします
GARP は、クラスターの仮想 IP アドレスを新しいアクティブメンバー（または新しいピボット）の物理 MAC アドレスに関連付けます
フェイルオーバー中に発生する可能性のあるトラフィックの停止を最小限に抑えるには、仮想MAC アドレス（VMAC）を使用するようにクラスターを設定します
High Availability モードまたは Load Sharing Unicast モードで仮想 MAC を有効にすることにより、すべてのクラスターメンバーは、同じ仮想 MAC アドレスをすべてのクラスター仮想インターフェースおよび仮想 IP アドレスに関連付けます
仮想 MAC モードでは、クラスターメンバーによって（GARP 要求を介して）アドバタイズされる VMAC は、各メンバーの実際の MAC アドレスを保持し、その上に仮想 MAC アドレスを追加します
ローカル接続と同期接続の場合、各クラスターメンバーの実際の物理 MAC アドレスは引き続き実 IP アドレスに関連付けられます
VMAC モードが有効になっているクラスターでのフェイルオーバー時間は、物理 MAC アドレスを使用するクラスターでのフェイルオーバーよりも短くなります

クラスターメンバーの時刻同期

ClusterXL を使用する場合は、必ずすべてのクラスターメンバーのクロックを同期させてください。手動で、または NTP などのプロトコルを使用してクロックを同期できます。 VPN などの機能は、すべてのクラスターメンバーのクロックが同期されている場合にのみ正しく機能します。

クラスターの制限

クラスタメンバーを同期する場合、次の制限が適用されます。

同期の冗長性のために複数の専用物理インターフェースを使用することはサポートされていません。同期インターフェースの冗長性にはボンディングを使用できます
- 参考: 同期インターフェースの冗長性は、VRRP クラスターではサポートされていません
すべてのクラスターメンバーは、同じように構成されたハードウェアプラットフォームで実行する必要があります
クラスターメンバーがダウンすると、そのメンバーを介したユーザー認証接続は失われます。他のクラスターメンバーは接続を復元できません。クライアント認証またはセッション認証の接続が維持されます
- これらの制限の理由は、ユーザー認証状態が Security Gateway 上のプロセスによって維持されるためです。カーネルデータが同期されるのと同じ方法でクラスターメンバー上で同期することはできません。ただし、セッション認証とクライアント認証の状態はカーネルテーブルに保存され、同期することができます
ユーザー認証された接続を同期できないのと同じ理由で、システムリソースを使用する connection statutes を同期することはできません
接続のアカウンティング情報は、各クラスターメンバーに蓄積され、管理サーバーに送信され、集約されます。クラスタフェイルオーバーが発生した場合、管理サーバーにまだ送信されていないアカウンティング情報は失われます。このリスクを最小限に抑えるために、アカウンティング情報が送信される時間間隔を減らすことができます。これを行うには [クラスターオブジェクト > Logs > Additional Logging ペイン] で、Update Account Log every] 属性に低い値を設定します

ClusterXL モード

各モード概要

ClusterXL は、冗長セキュリティゲートウェイのクラスター間でネットワークトラフィックを分散するソフトウェアベースの高可用性および負荷分散ソリューションです。

ClusterXL には、次の高可用性機能があります。

メンバーに障害が発生した場合の透過的なフェイルオーバー
ミッションクリティカルな環境でのダウンタイムゼロ（状態同期を使用する場合）
スループットの向上（Load Sharing モード）
透過的なアップグレード

クラスター内のすべてのメンバーは、他の各メンバーを通過する接続を認識しています。クラスターメンバーは、安全な同期ネットワークを介して接続とステータス情報を同期します。

ClusterXL クラスターのメンバーを結ぶ “接着剤” は、Cluster Control Protocol（CCP）であり、クラスターメンバー間で同期やその他の情報を渡すために使用されます。

High Availability

クラスター内で 1 つのメンバーのみがアクティブです（アクティブ/スタンバイ）
アクティブなクラスターメンバーが使用できなくなった場合、すべての接続は中断することなく指定されたスタンバイにリダイレクトされます
各メンバーに priority が割り当てられます
最も priority の高いメンバーはアクティブクラスターメンバーとして機能します
同期されたクラスターでは、スタンバイクラスターメンバーはアクティブクラスターメンバーの接続の状態で更新されます
アクティブクラスターメンバーに障害が発生した場合、制御は次に priority の高いメンバーに渡されます
- さらにそのメンバーにも障害が発生すると、制御はさらにその次のメンバーに渡されます
メンバーが復旧した場合の動作として、現在のアクティブメンバー（Active Up）を維持するか、または最も優先度の高いメンバー（Primary Up）に切り替えることができます
IPv4 と IPv6 の両方をサポートしています

Load Sharing

クラスター内でトラフィックを分散するため、クラスター全体での合計スループットが向上します
クラスター内で機能しているすべてのメンバーがアクティブであり、ネットワークトラフィックを処理します（アクティブ/アクティブ）
クラスタ内のいずれかのメンバーが到達不能になると、クラスタ内の残りの運用メンバーに対して透過的なフェールオーバーが発生し、高可用性が提供されます
- すべての接続は、中断することなく残りのセキュリティゲートウェイ間で共有されます
IPv6 はサポートしていません

すべての ClusterXL モード

ClusterXL のモードは次の 4 つがあります。

High Availability モード
Load Sharing Multicast モード
Load Sharing Unicast モード
Active-Active モード

Load Sharing モード

Load Sharing を使用すると、クラスターメンバー間でネットワークトラフィックを分散できます
常に単一のメンバーのみがアクティブである High Availability とは対照的に、Load Sharing ソリューションのすべてのクラスターメンバーがアクティブです
クラスタメンバーはどのクラスタメンバーがどのパケットを処理するかを決定しますが、これは cluster decision function によって決定されます
ClusterXL Load Sharing は、完全な高可用性ソリューションも提供することを理解することが重要です
- すべてのクラスターメンバーがアクティブな場合、トラフィックはクラスターメンバー間で均等に分散されます
- クラスターメンバーの 1 つに問題が発生したためにフェイルオーバーイベントが発生した場合、障害のあるメンバーによって処理されたすべての接続の処理は、他のクラスターメンバーによって即座に引き継がれます
ClusterXL は、マルチキャストとユニキャストの 2 つの Load Sharing ソリューションを提供します。これらの 2 つのモードでは、クラスターメンバーがクラスターに送信されたパケットを受信する方法が異なります

Load Sharing Multicast モード

イーサネットネットワーク層によって提供されるマルチキャストメカニズムにより、複数のインターフェースを単一の物理（MAC）アドレスに関連付けることができます
同じサブネット内のすべてのインターフェースを単一の MAC アドレスにバインドするブロードキャストとは異なり、マルチキャストではネットワーク内でのグループ化が可能です
これは、特定の MAC アドレスに送信されたパケットを受信する単一のサブネット内のインターフェースを選択できることを意味します
ClusterXL は、マルチキャストメカニズムを使用して、クラスターの仮想 IP アドレスをマルチキャスト MAC アドレスに関連付けます
これにより、ネットワーク上のデフォルトゲートウェイとして機能する、クラスターに送信されたすべてのパケットがすべてのクラスターメンバーに確実に到達します
次に、各クラスターメンバーは、パケットを処理するかどうかを決定します。この決定は、ロードシェアリングメカニズムの中核です
少なくとも 1 つのクラスターメンバーが各パケットを処理し（トラフィックがブロックされないように）、そして 2 つのクラスターメンバーが同じパケットを処理しないようにする必要があります（トラフィックの複製の防止）
cluster decision function の追加要件は、クラスターメンバーを介して各接続をルーティングし、単一の接続に属するパケットが同じクラスターメンバーによって処理されるようにすることです
残念ながら、この要件は常に適用できるとは限らず、場合によっては、同じ接続のパケットが異なるクラスターメンバーによって処理されます
ClusterXL は、すべてのクラスターメンバーの接続をミラーリングする状態同期メカニズムを使用してこれらの状況を処理します

Load Sharing Unicast モード

Load Sharing Unicast モードは、マルチキャストイーサネットが動作できない環境に適合した負荷分散ソリューションを提供します
このモードでは、ピボットと呼ばれる単一のクラスターメンバーがクラスターの仮想 IP アドレスに関連付けられます
このピボットクラスターメンバーは、クラスターに送信されたすべてのパケットを受信する唯一のクラスターメンバーです
次に、ピボットクラスターメンバーは、パケットを他のクラスターメンバーに伝播し、Load Sharing メカニズムを作成します
パケットの配布は、Load Sharing Multicast モードで実行されるのと同じ方法で、各パケットに cluster decision function を適用することによって実行されます
違いは、1 つのクラスターメンバーのみがこの selection を実行することです
- 転送されたパケットを受信する非ピボットメンバーは、cluster decision function を適用せずにそれを処理します
- 非ピボットクラスターメンバーは、トラフィックの共有に対してルーティングおよびファイアウォールタスクを実行するため、引き続きアクティブであることに注意してください（ただし、decision は実行しません）
ピボットクラスターメンバーは decision プロセスを担当しますが、パケットを処理するセキュリティゲートウェイとして機能します
- decision によってはパケットを自身で処理します
ただし、追加のタスクは時間がかかるため、通常、総負荷に占める割合は小さくなります
非ピボットメンバーで障害が発生すると、その処理された接続がアクティブな非ピボットクラスターメンバー間で再分散され、High Availability および Load Sharing Multicast と同じ高可用性機能が提供されます
ピボットクラスターメンバーで問題が発生すると、定期的なフェイルオーバーイベントが発生し、さらに、別のアクティブな非ピボットメンバーが新しいピボットの役割を引き受けます
ピボットメンバーは、常に最も priority の高いアクティブメンバーです
- 元々ピボットだったメンバーが復旧したときに、そのメンバーがピボットに戻ることになります

Active-Active モード

R80.40では、Active-Active と呼ばれる新しい ClusterXL モードが導入されました。

このモードは、クラスターメンバーがさまざまな地理的領域（さまざまなサイト、さまざまなアベイラビリティーゾーン）にあるクラスター向けに設計されています
管理者は各クラスターメンバーに動的ルーティングを構成するため、クラスターメンバーは該当するエリアのルーターまたはサイトの自律システムになります
各クラスターメンバーのインターフェイスの IP アドレスは、異なるネットワーク（同期インターフェイスを含む）にあります
各クラスターメンバーは、ルーティングされたすべてのトラフィックを検査し、記録された接続をピアクラスターメンバーに同期します
トラフィックはメンバー間でバランスが取れていません

クラスターとセキュリティポリシー

■管理者によるポリシー設定

管理者は、個々のクラスターメンバーに個別にではなく、クラスターオブジェクトにセキュリティポリシーをインストールします
ポリシーは、すべてのクラスターメンバーに自動的にインストールされます
ポリシーは、クラスターメンバーオブジェクトの [General Properties] ページで定義された IP アドレスに送信されます

■クラスターメンバーが障害から復旧時の動作

障害が発生したクラスターメンバーが回復すると、最初に、ピアのアクティブクラスターメンバーの1つからポリシーをフェッチしようとします
- 他のクラスターメンバーには、より最新のポリシーがあることが前提です
ピアクラスターメンバーからのポリシーのフェッチが失敗した場合、回復されたクラスターメンバーは、自身のローカルポリシーをその管理サーバー上のポリシーと比較します
- 管理サーバーのポリシーが、回復されたクラスターメンバーのポリシーよりも最新である場合、ポリシーは管理サーバーからフェッチされます
クラスタメンバーにローカルポリシーがない場合は、管理サーバーからローカルポリシーを取得します