はじめに
Socket | インターネット回線 | 本記事にて解説する構成 |
1台 | 1本 | |
1台 | 2本 | 〇 |
1台 | 3本以上 | |
2台 | 1本 | |
2台 | 2本 | 〇 |
2台 | 3本以上 |
Cato Cloudについての詳細はこちらをご参照ください!
Cato Socketについて
まずはCato Socketについてご紹介です。
今回使用したのはX1500というモデルで、外観はこのような感じです。
このモデルはスループット(上下の通信の合計値)が最大500Mbpsですが、これより広帯域が必要な場合は、X1500より上位のX1600やX1700から選択することができます。
今回の検証では500Mbpsで十分なのでX1500を使用しました。
また、X1500は4ポートのギガビットイーサネットを搭載しており、左からWAN×2ポート、LAN×2ポート、コンソール×1ポートという並びになっています。
その他特徴は以下にまとめました。
▼表2.X1500の仕様
寸法 | W:165mm×D:105.5mm×H:43mm or W:180mm×D:130mm×H:30mm (dual rack mount available) |
CPU | Intel® Atom™ processor |
システムメモリ | 4GB |
ストレージ | 16GB |
Ethernetポート | 4×1GbE |
スループット | 500Mbps |
構成例
続いて、本投稿にて解説する3つの構成についてです。
構成1. Socket1台 インターネット回線2本構成
構成1は、インターネット回線2本を1台の Socket で直接終端する構成です。
インターネット回線はActive/ActiveまたはActive/Passiveにて設定が可能ですが、本投稿ではActive/Passiveとした場合について解説します。
構成2. Socket2台 インターネット回線2本構成
構成2は、Socket2台・インターネット回線2本の構成で、2パターン解説します。
パターンA
パターンAの構成は、Socket1台に対しインターネット回線を2本接続し、Internet回線とSocketを冗長化した構成です。
インターネット回線はActive/ActiveまたはActive/Passiveとすることが可能ですが、本投稿ではActive/Passiveとした場合について解説します。
SocketはActive/Passive のみ可実装可能です。
パターンB
パターンBの構成は、Socket1台に対しインターネット回線を1本接続し、Internet回線とSocketを冗長化した構成です。
インターネット回線はSocke1台に対してインターネット回線1本のためActive設定とします。
またSocketは前述の通り、Active/Passive のみ実装可能です。
障害時の通信フロー
ここで、各構成で障害を発生させた際の通信フローについて解説していきたいと思います。
障害パターンは以下4パターンの想定です。
障害パターン
- Socketの筐体障害
- SocketのLAN側切断
- Socket と Catoクラウド PoP間のVPN切断
- インターネット回線品質低下(SLA閾値を下回る)
構成1
障害パターン1・2発生時
Socketおよびインターネット回線の切り替わりは発生しませんでした。
構成1は、図からもわかる通りSocketが1台のみの構成です。
そのため、Socketの筐体障害およびLAN切断時のSocketの切り替わりが不可となり、通信を継続させることができません。
障害パターン3・4発生時
インターネット回線の切り替わりが発生し、通信を継続させることができました。
Socketがwan1側のVPN切断やActive回線の品質低下を検知すると、wan2インターフェイスのステータスをPassiveからActiveに変更し、wan2経由で通信を継続します。
この時、TCPコネクションは継続され、Socket配下の端末から接続先アプリケーションへの通信は継続することが可能です。
さらに、Socketがwan1側のVPN接続やActive回線の復旧を検知すると、自動的にwan1経由の通信へと切り戻ります。
まとめ
- 筐体障害やLAN切断発生時、通信が全断する可能性があります。
- VPN切断や回線品質低下による、インターネット回線の切り替わりは可能です。
- VPN切断や回線品質低下による、インターネット回線切り替わりの際、TCPコネクションは継続されます。
- VPN接続や回線品質復旧時、通信は自動で元の通信経路に切り戻ります。
各障害発生時の切り替わり可否や切り替わり時間についてまとめると下表のようになります。
▼表3.構成1における各障害発生時の切り替わり可否と切り替わり時間
障害パターン | 障害時の切り替わり | 復旧時の切り戻り | |
1 | 筐体障害 | × | × |
2 | LAN側切断 | × | × |
3 | VPN切断 | 〇:インターネット接続が10秒以上断 | 〇:wan1側が復旧後即時で切り戻り |
4 | 回線品質低下 | 〇:SLA閾値を下回る状態が130秒以上継続 | 〇:10分毎にSLA条件を再評価し問題ない場合切り戻り |
構成2(パターンA)
障害パターン1・2発生時
Socketの切り替わりが発生し、通信を継続させることができました。
Socket(Passive)はSocket(Active)の筐体障害およびLAN切断を検知すると、SocketHAステータスをPassiveからActiveに変更し、Socket(Passive)経由で通信を継続します。
この時、TCPコネクションは継続され、Socket配下の端末から接続先アプリケーションへの通信は継続することが可能です。
さらに、Socket(Passive)がSocket(Active)の筐体およびLANの復旧を検知すると、自動的にSocket(Active)経由の通信へと切り戻ります。
障害パターン3・4発生時
インターネット回線の切り替わりが発生し、通信を継続させることができました。
Socket(Active)は、wan1インターフェイス側のVPN切断およびActive回線の品質低下を検知すると、wan2インターフェイスのステータスをPassiveからActiveに変更し、Socket(Active)のwan2経由で通信を継続します。
この時、TCPコネクションは継続され、Socket配下の端末から接続先アプリケーションへの通信は継続することが可能です。
さらに、Socketがwan1側のVPN接続やActive回線の復旧を検知すると、自動的にSocket(Active)のwan1経由の通信へと切り戻ります。
まとめ
- 全障害パターンで切り替わりが発生し、通信を継続させることができます。
- 切り替わりの際、TCPコネクションは継続されます。
- 復旧時、通信は自動で元の通信経路に切り戻ります。
各障害発生時の切り替わり可否や切り替わり時間についてまとめると下表のようになります。
▼表4.構成2(パターンA)における障害発生時の切り替わり
障害パターン | 切り替わり時間(障害時) | 切り替わり時間(復旧時) | |
1 | 筐体障害 | 〇:VRRPハートビート1秒×3回断 | 〇 |
2 | LAN側切断 | 〇:VRRPハートビート1秒×3回断 | 〇:lan1が復旧後即時で切り戻り |
3 | VPN切断 | 〇:インターネット接続が10秒以上断 | 〇:wan1側が復旧後即時で切り戻り |
4 | 回線品質低下 | 〇:SLA閾値を下回る状態が130秒以上継続 | 〇:10分毎にSLA条件を再評価し問題ない場合切り戻り |
構成2(パターンB)
障害パターン1・2・3発生時
Socketの切り替わりが発生し、通信を継続させることができました。
Socket(Passive)はSocket(Active)の筐体障害およびLAN切断を検知すると、SocketHAステータスをPassiveからActiveに変更し、Socket(Passive)経由で通信を継続します。
また、Socket(Active)のVPN切断時についても同様に、Socket(Passive)はSocket(Active)のwan1インターフェイス側のVPN切断を検知し、SocketHAステータスをPassiveからActiveに変更することで、Socket(Passive)経由で通信を継続します。
この時、TCPコネクションは継続され、Socket配下の端末から接続先アプリケーションへの通信は継続することが可能です。
さらに、Socket(Passive)がSocket(Active)の筐体・LAN復旧およびVPN接続の復旧を検知すると、自動的にSocket(Active)経由の通信へと切り戻ります。
障害パターン4発生時
そのため、Socket(Active)でwanインターフェイスの切り替えができず、Socket(Active)のwan1経由で通信を継続します。
つまり、不安定な通信が継続される可能性があるといえます。
まとめ
- 回線品質低下による切り替わりを考慮しない場合のみ、有効な構成です。
※回線品質劣化による切り替わりを考慮する場合は、構成2(パターンA)が推奨です。 - 筐体障害やVPN切断、LAN切断による、Socketの切り替わりの際、TCPコネクションは継続されます。
- 筐体・LAN復旧およびVPN接続の復旧時、通信は自動で元の通信経路に切り戻ります。
各障害発生時の切り替わり可否や切り替わり時間についてまとめると下表のようになります。
▼表5.構成2(パターンB)における障害発生時の切り替わり
障害パターン | 切り替わり時間(障害時) | 切り替わり時間(復旧時) | |
1 | 筐体障害 | 〇:VRRPハートビート1秒×3回断 | 〇 |
2 | LAN側切断 | 〇:VRRPハートビート1秒×3回断 | 〇:lan1が復旧後即時 |
3 | VPN切断 | 〇:インターネット接続が10秒以上断/VRRPハートビート1秒×3回断(最大13秒) | 〇:wan1側が復旧後即時で切り戻り |
4 | 回線品質低下 | × | × |
構成比較検討
最後に、通信の継続性の観点から3つの構成を比較した結果です。
通信の継続が構成検討時の必須条件である場合、構成2(パターンA)が推奨ですが、
Socketの切り替わりを考慮しない場合は構成1、回線品質低下による切り替わりを考慮しない場合は構成2(パターンB)でも実装が可能です。
▼表6.構成比較表
Socket | インターネット回線 | 構成例 | 継続性 |
1台 | 2本 | 構成1 | △:一部継続不可 |
2台 | 2台 | 構成2(パターンA) | 〇:継続可能 |
2台 | 2台 | 構成2(パターンB) | △:不安定な通信が継続される可能性あり |
まとめ
本投稿では、Catoクラウドの拠点内構成のうち、冗長構成について説明いたしました。
Catoクラウド導入や拠点展開のご検討時にお役に立てば幸いです。
なお、本投稿はCatoのナレッジベースを参考に作成しています。
SocketのHA構成についての詳細はこちらをご参照ください!
なお、弊社の FAQ サイトでは 、よくあるご質問やCato クラウドのアップデート情報を公開しておりますので、是非ご参照ください!