Cato サイトタイプのための復旧メカニズム

Prev Next

概要

Catoは、サイトとPoPの間に接続の問題が発生しても、トラフィックの継続性を維持するように設計されています。 サイトはPoPに接続し、トラフィックはその後、Cato Cloud経由でWANに出力されるか、SaaSおよびインターネットアプリケーションへのアクセスのためにインターネットに出力されます。 レジリエンシーは、接続の問題がある場合でも、エンドユーザーへの影響を最小限に抑えてトラフィックフローを継続的に維持することを保証します。

この記事では、異なるサイトタイプに対してCatoがどのようにレジリエンシーを実現し、PoP接続の問題時にトラフィックがどのように動作するかを説明します。

Cato PoP アーキテクチャ

Cato PoP は、複数の処理サーバーで構成されたクラウドロケーションです。 各PoPは、顧客トンネルを処理し、セキュリティサービスを適用し、単一の処理ノードに依存せずにトラフィックを転送するように設計されています。

各PoPノード:

  • 顧客トンネル(DTLSまたはIPsec)の終端処理を実施

  • ネットワークトラフィックの処理と転送

  • Cato ソフトウェアスタック全体を実行し、ルーティング、最適化、WANやインターネットファイアウォール、IPS、TLSインスペクションなどのセキュリティサービスを含む

このPoPノードベースのアーキテクチャにより、問題がインフラストラクチャに関連する場合でも、Cato Cloudはトラフィック処理とセキュリティ適用を維持し、影響を最小限に抑えます。

WANとインターネットのためのソケットおよびvSocketトラフィックレジリエンシー

ソケットおよびvSocketサイトは、Cato Cloud上のサイト間のWAN接続を維持し、トラフィックをSaaSアプリケーションに向けるためのインターネット接続を提供する最もレジリエントなモデルです。 この展開モデルは、データセンターや主要支社など、トラフィックの継続性と予測可能な復旧動作が運用上重要なサイトに設計されており、PoPへの接続の問題が発生した場合にエンドユーザーが最小限の影響を受けるべきです。

PoP接続の問題に対するレジリエンシー

サイトがPoPへの接続に問題を抱えている場合、ソケットは自動でトラフィックフローを最小限の中断で維持し、管理者の介入なしで作動します。 復旧は中断を最小限に抑え、不必要なトポロジの変更を避けるために漸進的に処理されます。

機能には以下が含まれます:

  1. ノードレベルの問題が検出された場合の異なるPoPノードへの自動再接続

  2. PoPレベルの接続問題が続く場合、異なるPoPへの自動フェイルオーバー

これらの動作は、瞬間的なPoP接続の問題の影響を軽減し、エンドユーザーに対するトラフィック継続性の維持に役立ちます。 詳細については、サイトの合意すべきSLAと不合意なSLAの理解をご参照ください。

ラストマイルおよびISPのレジリエンシー

ソケットおよびvSocketサイトは、Cato Cloudへの安定したトンネルを維持するためのラストマイル接続を積極的に監視します。 トラフィック操作の決定は、静的な好みよりもむしろリアルタイムのリンク条件に基づいて行われます。

機能には以下が含まれます:

  1. 各WANリンク上での品質と接続性メトリックの連続モニタリング

  2. ISPの冗長性を提供するために、ソケットごとに最大4つのWANインターフェースをサポート

  3. 複数のWANリンクの積極的な利用により、可用性と耐久性を向上

このモデルは、単一のISPへの依存を減らし、最終マイル障害時の復旧結果を改善します。

トラフィック固有の復旧動作

ソケットは、PoP接続の問題がある場合、WANトラフィックとインターネットに向かうトラフィックに別々の回復ロジックを適用します。 この区別により、PoP接続が失われたことが原因でサイト間通信やインターネットアクセスが不要に影響を受けないことが保証されます。

WANトラフィックの場合、ソケットはサイト間接続の維持を優先します:

  1. PoPが到達不能な場合、WANトラフィックはクラウド外のDTLSトンネル(WANリカバリ)にリダイレクトされる

  2. 既存のサイト間セッションは、再確立を必要とせずに復旧パス上で継続

インターネットトラフィックの場合、ソケットは別の回復パスを適用します:

  1. インターネットに向かうトラフィックは、PoPではなくローカルISPに直接ルーティングされます(インターネットリカバリ)

  2. トラフィックはPoPのIPアドレスではなく、ソケットのパブリックIPアドレスを使用して出力されます

このトラフィック固有の処理により、WANおよびインターネットトラフィックが障害のタイプに基づいて独立して復旧することを可能にし、障害の範囲を制限します。

ソケットのレジリエンシーのための運用ベストプラクティス

正しいソケットの展開は、復旧の効果に直接影響を与えます。 これらのプラクティスを適用することで、PoP接続問題時には予測可能な動作とユーザーへの影響を最小限に抑えることができます。

一般的な展開ベストプラクティス

ベストプラクティスには以下が含まれます:

  1. 単一プロバイダへの依存を避けるために、アクティブ/アクティブ構成でサイトあたり少なくとも2つのISPを展開

  2. ローカルのハードウェア障害から保護するためにソケット高可用性(HA)を使用

  3. サイトと上流ISPの間の物理パス多様性を確保

  4. 特にデータセンターサイトに対して、WANインターフェースに対する静的パブリックIPアドレスを設定

詳細については、Cato ソケット接続の前提条件と既知の制限をご参照ください

WANリカバリの計画

WANリカバリは、PoPへの接続が失われた際に、クラウド外のDTLSトンネルを経由してWANトラフィックをルーティングすることでサイト間接続を維持します。 迅速な収束と信頼性の高い回復動作を保証するには、安定したWANインターフェース構成が重要です。

ベストプラクティスには以下が含まれます:

  1. クラウド外トンネルの安定性を向上させるために、WANリカバリに参加するWANインターフェースで静的IPアドレスを設定

    これは特にデータセンターおよびハブサイトにとって重要です。

  2. ネットワーク > サイトページを使用して、WANインターフェースまたはルーティングの変更後にWAN復旧トンネルのステータスを確認

詳細については、WANリカバリによるソケットサイトのレジリエンシーをご参照ください。

インターネットリカバリの計画

インターネットリカバリ中、トラフィックはPoPではなくソケットからインターネットに直接出力されます。 この動作は、SaaSアクセスとIPベースのセキュリティポリシーに影響します。

運用上の考慮事項には以下が含まれます:

  1. インターネットトラフィックはリカバリ中にソケットのパブリックIPアドレスから送信されます

  2. インターネットリカバリがアクティブな間、PoPベースのパブリックIPアドレスは使用されません

  3. クリティカルなSaaSアプリケーションのアクセスを維持するために、ソケットのパブリックIPアドレスをホワイトリストに追加

  4. 例えば、アプリケーションがPoP出力も使用する場合は、割り当てられたCato IPアドレスとソケットパブリックIPアドレスの両方をホワイトリストに追加

詳細については、Cato Networks のインターネットリカバリの使用をご参照ください。

IPsecおよびクラウド間接続サイトのレジリエンシー

IPsecおよびクラウド間接続サイトは、PoP接続の問題の際にトラフィックの継続性を維持するためにPoPレベルの冗長性に依存しています。 ソケットベースのサイトとは異なり、これらのサイトタイプはクラウド外復旧メカニズムを使用しません。 レジリエンシーは、Cato Cloudへの冗長接続パスによって達成されます。

IPsec サイトのレジリエンシー

IPsecサイトは、複数のPoPロケーションにトンネルを確立することによってレジリエンシーを維持します。 フェイルオーバー動作は、顧客管理のサードパーティIPsecデバイスの設定と機能によって決定されます。

機能には以下が含まれます:

  1. 異なるPoPロケーションに対するプライマリおよびセカンダリトンネルのサポート

  2. デバイスサポートに応じたアクティブ/パッシブまたはアクティブ/アクティブトンネル構成

運用上の考慮事項には以下が含まれます:

  1. 99.999%のSLAは、少なくとも2つの異なるPoPロケーションに接続されたIPsecサイトに対してのみ保証されます。このことはCato MSAで定義されています

  2. IPsecサイトでは、インターネットリカバリおよびWANリカバリがサポートされていません。 これは、PoPの障害時にサイト間のWAN接続が利用できないことを意味します

クラウド間接続サイトのレジリエンシー

クラウド間接続サイトは、プロバイダバックの接続を使ってCato Cloudに接続します。 レジリエンシーは、冗長なプロバイダインフラストラクチャとPoP接続を通じて実現されます。

機能には以下が含まれます:

  1. プロバイダバックボーン上での冗長接続

  2. クラウド間接続の設計に基づいたアクティブおよびパッシブなPoP接続

運用上の考慮事項には以下が含まれます:

  1. インターネットリカバリおよびWANリカバリはサポートされていません

  2. トラフィックの可用性は、プロバイダSLAと複数のPoPに接続されているサイトに依存します

BGPを使用したルーティングのレジリエンシー

動的ルーティングは、PoP接続の問題およびネットワークの変更時にトラフィックの継続性を維持するために重要です。 BGPは、サイトが迅速に収束し、パスが変更された時でもトラフィックを転送し続けることを可能にする適応ルーティング動作を提供します。

安定した事前定義されたパスのために静的ルーティングを使用することも可能です。

BGPベースのルーティングのレジリエンシー

BGPは、接続の変化がある際にルートの学習と破棄を管理し、障害が発生した際に到達可能なパスに自動的にトラフィックをシフトすることを可能にします。

機能には以下が含まれます:

  1. リアルタイムの到達可能性に基づく動的なパス選択

  2. リンク、パス、またはPoP接続の変更時の自動ルート収束

  3. 障害検出時間を短縮するための双方向転送検出(BFD)のサポート

運用上の考慮事項には以下が含まれます:

  1. BGPはサイトルーターで設定され、Catoのルーティング設定と連携する必要があります

  2. 動的で耐久性のあるルーティング動作が必要な場合、BFDと共にBGPを使用することを推奨します。

詳細については、BGP隣接へのBFD設定をご参照ください。

サイトタイプ別復旧メカニズムの概要

以下の表は、サイトとPoPの間に接続の問題がある場合に、異なるサイトタイプがトラフィックの継続性をどのように維持するかをまとめたものです。 焦点はトラフィックがどこまで流れ続け、どのようにして復旧が実現されるかであり、機能の設定詳細ではありません。

レジリエンシーの観点

ソケットおよびvSocketサイト

IPsecサイト

クラウド間接続サイト

複数のPoPへの接続

はい

はい

はい

現在のPoPが到達不能な場合の代替PoPへの再接続

はい

はい(サードパーティデバイスの動作によります)

はい

PoP接続問題時のWANトラフィックのレジリエンシー

はい(WANリカバリ)

いいえ

いいえ

PoP接続問題時のインターネットトラフィックのレジリエンシー

はい(インターネットリカバリ)

いいえ

いいえ

PoP接続問題時の代替WANのレジリエンシー(MPLS)

はい(代替WANリカバリ)

いいえ

いいえ

サードパーティデバイスまたはプロバイダ動作への依存

いいえ

はい

はい

復旧中のプラットフォームの動作

トラフィックがリカバリーモードまたはWANリカバリーモード中にPoPをバイパスする場合、特定のプラットフォームサービスは適用されません。

運用上の考慮事項には以下が含まれます:

  1. セキュリティ検査および脅威防止サービスはオフクラウドトラフィックに適用されません

  2. PoPベースのサービスは、PoPへの接続が再確立されると自動的に復元されます