2020年6月3日のアップデートでDirect Connectのフェイルオーバーテストが可能になりました。
AWSとオンプレミスの接続をする時にはDirect Connectが用いられますが、障害対策として、2本の接続を利用することもよくあります。
1本で障害が起きても、もう1本あるから大丈夫。。。大丈夫なはず。。。テストしたい。。。
それが実現できるようになりました。
やってみた
たまたま手元にDirect Connectの冗長構成があったので、やってみました。
準備
効果測定のためにEC2インスタンスから、Direct Connect経由のサーバに対し、pingを打ち続けます。
ubuntu@ip-10-0-0-10:~$ ping -s 1472 172.16.0.10 PING 172.16.0.10 (172.16.0.10) 1472(1500) bytes of data. 1480 bytes from 172.16.0.10: icmp_seq=1 ttl=58 time=78.3 ms 1480 bytes from 172.16.0.10: icmp_seq=2 ttl=58 time=78.2 ms 1480 bytes from 172.16.0.10: icmp_seq=3 ttl=58 time=78.2 ms
そして、CloudWatchメトリクスでVIFのトラフィックを確認します。
2つのVIFのそれぞれにEgressとIngressがありますが、実際にトラフィックが流れているのは1つのVIFだけであることが確認できます。
フェイルオーバーテストの実行
VIF1つ目をDownさせてみる
VIFを一つ選択し、アクション > フェイルオーバーテスト > BGPを停止させる をクリックします。
テストでダウンさせる時間を１分〜１８０分の間で指定します。
今回は１０分にしてみました。
確認するをクリックするとテストが開始されます。
VIFの状態がtestingになります。
テスト開始後もしばらくはBGPステータスがupになります。
しばらくすると、BGPステータスがdownになり、VIFのステータスもdownになります。
CloudWatchを見ると、トラフィックが流れるVIFが変わったことが確認できます。
なお、Ingressしかフェイルオーバーしなかったのですが、非対称ルートになっていたのが原因のようです。
指定した１０分を経過すると復旧してきます。
VIF2つ目をDownさせてみる
2つのVIFのどちらで障害が起きてもトラフィックに問題ないかを確認したかったので、もう一つのVIFもDownさせてみます。
今回はテスト時間を２０分にしてみました。
20分経過後にフェイルバック（経路の切り戻し）が自動的に行われました。
今回はきちんと調べてないですが、対向ルータの設定やBGPパラメータ等が原因なのだろうと思います。
ping結果
1480 bytes from 172.16.0.10: icmp_seq=7384 ttl=58 time=79.3 ms 1480 bytes from 172.16.0.10: icmp_seq=7385 ttl=58 time=78.2 ms 1480 bytes from 172.16.0.10: icmp_seq=7386 ttl=58 time=78.2 ms 1480 bytes from 172.16.0.10: icmp_seq=7387 ttl=58 time=78.2 ms ^C --- 172.16.0.10 ping statistics --- 7387 packets transmitted, 7377 received, 0% packet loss, time 7396236ms rtt min/avg/max/mdev = 61.058/79.008/101.443/1.734 ms
パケットロスは7387の中で10パケットだけロスしてますね。
（1%未満なので0% packet lossと表示）
明確にどのタイミングでロスが発生したかは確認しませんでしたが、本記事に書いたのも含め、フェイルオーバーテストを合計4回しているので、それでこれなら優秀なのではないでしょうか。
なんにしても、障害時の挙動を概ね把握でき、だいぶ安心できるようになりました。
テスト履歴
VIFの画面でフェイルオーバーテストの履歴が見れるようになっていました。
まとめ
Direct Connectの冗長構成で、片方のVIFのBGP停止させるテストが可能になりました。
それによって、片系障害時にどのようなトラフィックになるのかを確認できるようになりました。
また、障害復旧時にフェイルバックが起きるかどうかも確認ができました。
いろいろとテストができるようになったので、今後はDirect Connectの冗長化に関するテスト計画も作成すると良さそうと感じました。