VyOSをAWSで冗長構成で使う時にやること
まだまだVyOSを使うことの多い市田です。 今回は、VyOSを2台作ってActive-Standby構成を作ってみたいと思います。
想定環境
下図のようなVPN接続を冗長化した構成を考えてみます。 VyOSの後ろにあるELB以下については、今回のようなケースで考えられうる構成として記載したものですので、今回はここの構築は行いません。
できるだけVPCの機能を使うことを前提としているので、前回のVyOSまとめ記事と同様にVyOSをカスタマーゲートウェイとして利用しています。
構成の利点
VyOSをActive-Standby構成にすることで、EC2をホストしているハードウェア環境の影響でActiveのVyOSが利用不可になっても、自動的に待機系のStandby側のVyOSに経路を切り替えて利用することができます。
構成上のポイント
今回の構成でポイントになるのは、以下の3点です。
1.VyOSをカスタマーゲートウェイとして利用(できるだけAWSらしく使うことを前提) 2.VyOSをActive-Standby構成で作成 3.VyOSのフェイルオーバ発生時のVPCルートテーブルの切り替え方法
ポイントの説明
ポイント1 - VyOSはカスタマーゲートウェイ
前回のVyOSまとめ記事にある通りの構成になります。 要件によっては、VPNゲートウェイなどを使わず、構成図の東京リージョン側にもVPNインスタンスを構築してVPNを張るという選択肢もありますが、今回の想定ではありません。
ポイント2 - VyOSによる経路制御
公式ドキュメントによると、VPCにおける最良パス選択のアルゴリズムの順番は以下のようになっています。
- ロンゲストマッチ(例えば、10.0.0.0/24 は 10.0.0.0/16 よりも優先される)
- Staticなルーティング(BGPなどのDynamicなものよりも優先)
- AS PATH(ASパスの短い方を優先)
- ORIGINE(最も低い値を優先)
- ルータID(VPCで生成されるVyOSのコンフィグでは設定されません)
- BGPピアのIPアドレス(最小のピアIPアドレスが優先)
Amazon VPC への複数の VPN 接続の設定 - Amazon Virtual Private Cloud
前回の記事でも記載した通り、Staticな構成はできるだけ採りたくないので、3番目のASパスで優先度の設定を行います。
ポイント3 - VPCルートテーブルの変更
ルータの設定でVyOSの冗長構成は作れますが、ActiveのVyOS-1が何らかの原因で停止してフェイルオーバが発生した時に、シンガポールリージョン側のルートテーブルも変更する必要があります。
具体的には、構成図にあるap-3やap-4のインスタンスから東京側リージョンへの経路を、VyOS-1からVyOS-2経由に変更する作業が発生します。
ActiveのVyOSが復帰した時にも同様の変更が発生します。
ルートテーブルの変更は、AWS CLIで制御するのが簡単なので、シェルスクリプトなどVyOSの仕組みとは異なる手段で、ルートテーブルを変更する必要があります。
また、ルートテーブル切替トリガーのスコープについても、VyOSの死活のみにするのか、対向VPCへの疎通チェックまでにするのか、といった点も検討すべき内容になってきます。
さらにそのチェック間隔なども検討事項になってくると思われます。
手順
前置きが長くなりましたが、手順を説明していきたいと思います。
- 構成図の通りVPCやサブネット、ルーティングテーブルを作成
vyos-1とvyos-2に対するカスタマーゲートウェイを東京リージョンとソウルリージョンで作成 (合計で2つ作ることになります)- 東京リージョンで仮想プライベートゲートウェイを作成
- 東京リージョンでVPN接続を作成
- カスタマーゲートウェイと仮想プライベートゲートウェイの組み合わせで合計2つのVPN接続を作ります。 1. vyosのコンフィグを各VPN接続からダウンロード(種類はvyattaのものを選択)
具体的な手順については、下記のエントリーを参照して頂ければと思います。
- [新サービス] SORACOM Doorを試してみた #scd2016 #soracom ｜ Developers.IO
- VyOSをAWSで使う時によくやることをまとめてみた ｜ Developers.IO
Active-Standbyのコンフィグ
今回の本題です。 先ほど書いたように、今回はASパス設定でActive-Standby構成を作ります。 ASパスプリペンドの設定は下記のとおりです。
この設定は、StandbyにするVyOS-2に対してのみ設定します。
まず、各ピアに適用するルートマップを作成します。 下記では東京リージョン向けのピアに適用するルートマップを「routemap-vyos2tokyo-out」という名前で作成しています。
次に、東京リージョンのVPC向けにアドバタイズする経路に、シンガポールリージョン自身のAS番号(デフォルトから変更していなければ65000)を2つ追加します。
こうすることで東京リージョンのVPCから見るとVyOS-2への経路がVyOS-1よりも遠くなるので、VyOS-1が優先される経路(つまりActive)になります。
# set policy route-map routemap-vyos2tokyo-out rule 10 action permit # set policy route-map routemap-vyos2tokyo-out rule 10 set as-path-prepend "65000 65000 65000" # set protocols bgp 65000 neighbor 169.254.xx.xx route-map export routemap-vyos2tokyo-out # set protocols bgp 65000 neighbor 169.254.yy.yy route-map export routemap-vyos2tokyo-out # clear ip bgp 169.254.xx.xx soft out # clear ip bgp 169.254.yy.yy soft out
送信経路情報の確認
設定した内容で経路情報がアドバタイズされているかは次のコマンドで確認できます。
$ show ip bgp neighbors 169.254.xx.xx advertised-routes
下記のような感じで、AS番号が追加された形で表示されていればOKです。
設定前
$ show ip bgp neighbors 169.254.xx.xx advertised-routes BGP table version is 0, local router ID is 172.31.xx.xx Status codes: s suppressed, d damped, h history, * valid, > best, i - internal, r RIB-failure, S Stale, R Removed Origin codes: i - IGP, e - EGP, ? - incomplete Network Next Hop Metric LocPrf Weight Path *> xx.xx.xx.0/24 169.254.xx xx 1 32768 i Total number of prefixes 1
設定後
$ show ip bgp neighbors 169.254.xx.xx advertised-routes BGP table version is 0, local router ID is 172.31.xx.xx Status codes: s suppressed, d damped, h history, * valid, > best, i - internal, r RIB-failure, S Stale, R Removed Origin codes: i - IGP, e - EGP, ? - incomplete Network Next Hop Metric LocPrf Weight Path *> xxx.xx.x.0/24 169.254.xx.xx 0 65000 65000 65000 10124 i *> xxx.xx.xx.0/24 169.254.xx.xx 1 32768 65000 65000 65000 i Total number of prefixes 2
ここまでの設定の動作と注意点
ここまでの設定で、次のような動作をすることになります。
- ActiveのVyOS-1に障害が発生した時、対向VPCからのトラフィックは自動的にVyOS-2に変わります。
- VyOS-1が復帰すると、自動的にトラフィックがVyOS-1に流れるように戻ります。
注意点
ここまでの設定では、VyOSの切り替わりのみ行えるものになります。
しかし、VyOSが切り替わってもその後ろにあるVPCのルーティングも連動して切り替わらないと、対向VPCへの戻りの経路が、故障したVyOSに向かってしまいます。
そのため、最低限シェルスクリプトなどでVyOS-2からVyOS-1を死活監視しておいて、VyOS-1からの応答がなくなったら、ルートテーブルを切り替えるようにしておきます。
ルートテーブルの切り替え(リプレイス)はAWS CLIで行うのが簡単です。
$ aws ec2 replace-route --route-table-id <ルートテーブルID> ¥ --destination-cidr-block --instance-id <VyOSのインスタンスID> --region <対象リージョン>
今回の構成のように切り替えるべきサブネットが2つある場合は、上記のコマンドも各サブネットに対して実行するようにします。
なお、VyOSへのAWS CLIの導入については、下記で紹介しています。
ここまでのまとめ
ここまでをまとめてみます。
- VyOSインスタンスの冗長構成は、ASパスプリペンドにより実現できる - ルートテーブルの切り替えは各VyOSの監視をトリガーにしてAWS CLIで実現できる - ルートテーブル切り替えのトリガーにするスコープは要件に応じて決める
最後に
スクリプトの作り込みによっては、対向VPCのend pointのIPを監視することで、VPN接続が切れたことをトリガーに経路を切り替えることもできます。 また、別途監視サーバなどを置いて、インスタンスやネットワークの状態を細かくチェックすることで、より柔軟に運用することもできるかと思います。
要件に応じたサービスレベルによる切り替え基準を設けて、実装していくのがベストかと思います。
以上になります。
