SD-WANに関する条件付きBackhaulなど高可用性設計
こんにちは、Yos235です。
SD-WANは複数のリンクをいい感じに使うというもの(すごい説明だ)ですが、
実はxxができなかったんですよ、というリリース後に気づいたり、
アーリーアダプタが「仕様かよっ」とハマったりすることはよくありますよね。
その一つがこれ、条件付きバックホールです。
Conditional Backhaul、 条件付きバックホール
それがCWS(正確にはトンネル)が死んでいたとしても、インターネットリンクが
切れていなければ検出できなかったものをトンネルレベルで検知するというもの。
「ユースケース 2:クラウド セキュリティ サービス (CSS) リンクの障害」
VeloCloudの場合は、CSS(Zscaler)とはIPsec(NULL)で接続しますが、
そのIPsecトンネルが途切れた時(インターネットリンクはUp状態でも)に検知して
Backhaulとして(おそらくは既存DC側から)をHUBを通って出ていくことになります。
この辺は動作仕様をきちんと確認したほうがいいかなと思いますが、
以下のようなまとめが記載してあって、このDocsは親切だなぁと思います。
条件付きバックホールの動作特性
- 条件付きバックホールが有効になっている場合、デフォルトでは、ブランチ レベルのすべてのビジネス ポリシー ルールは、CBH 経由でトラフィックをフェイルオーバーする必要があります。選択されたポリシーの特定の要件に基づいて、条件付きバックホールからトラフィックを除外するには、選択されたビジネス ポリシー レベルでこの機能を無効にします。(Yos235記:CBHしたくないものを指定可能)
- 条件付きバックホールは、パブリック リンクが停止した場合、すでにハブにバックホールされている既存のフローには影響しません。既存のフローは、引き続き同じハブを使用してデータを転送します。(Yos235記:全部をCSSに転送してないパターンも大丈夫、)
- ブランチにバックアップ パブリック リンクがある場合、バックアップ パブリック リンクは CBH よりも優先されます。プライマリ リンクとバックアップ リンクがすべて動作不能になった場合にのみ、CBH がトリガされ、プライベート リンクを使用します。(Yos235記:プライマリ>バックアップ>CBHと3段構え)
- プライベート リンクがバックアップとして機能している場合、アクティブなパブリック リンクに障害が発生し、プライベート バックアップ リンクがアクティブになると、トラフィックは CBH 機能を使用してプライベート リンクにフェイルオーバーします。(Yos235記:プライベートリンクが普段は止めてあるパターン)
- この機能を使用するには、ブランチと条件付きバックホール ハブの両方で、プライベート リンクに同じプライベート ネットワーク名を割り当てる必要があります(そうしないと、プライベート トンネルは起動しません)。(Yos235記:プライベートネットワーク名でまとめるみたい)
そうなると気になるのは、L7レベルで監視する「レイヤー 7 健全性チェック」。
これを使うとZIAのロードバランサの裏にあるサービスEdgeに対するHTTPプローブの
応答により、障害を検知することができるようになるのですが、この場合においても
Backhaulへのフェイルオーバーが動作するようです。
こういうパターンって、詳しくない人ほどいい感じにやってくれそうだよね、
と思われるけど、そうでもないことが多々あって。SIer泣かせの事象なのですが。
出来て当たり前のようにみえるが、これすごいですね、ちゃんとしてそうです。
今日は、この辺で。