こんにちは、cloudpackの津村です。
今回はCiscoやJuniperの箱ルータではなく、ソフトウェアルータについてエントリをアップします。（ちょっと真面目

AWS上でソフトウェアルータを冗長化する

データセンタのコアルータや、VPNのセンタールータ等では、一般的にCiscoやJuniper、VPN用ではNECやYAMAHAなどのハイエンド機をアサインする事があります。
これは、筐体そのものの信頼性の他、拠点（ブランチ）ルータでは削られてしまう冗長機能が実装されている為です。
一般的にはネットワークを冗長する（BGP, OSPF…）方をイメージしてしまう方もいらっしゃるかもしれませんが、今回は筐体そのものを冗長するクラスタリング(HAクラスタ)を取り上げます。

HAクラスタのクラスタリング構成図

Vyatta（ヴィヤッタ）とは？

Vyattaとは、米ブロケード社が買収した、ソフトウェアルータのベンダー、及びオープンソースのソフトウェアルータです。
Viyatta自身はもっぱら設定や管理をメインとし、それぞれの専門の部分を、それぞれ他のオープンソース・ソフトウェア(iptablesやopenvpn等)で補完しいている事が特徴です。
CLIはJunosライクなCLIがされており、それぞれのコンポーネントを1つのConfigで管理できます。

使い方として、アプライアンスとしてx86サーバに直接インストールする他、VMwareやHyper-V、Xen等のハイパーバイザ上でブリッジと組み合わせて使う場合が多いです。
そして、今回お話するようにVPNのセンタールータやNATサーバに代わる効率的なルータとして、パブリッククラウドでも多々使用されています。
Brocade Vyatta 5400 vRouter

今回の要件

今回は、Vyattaのプライマリ(運用系)・セカンダリ(待機系)を、それぞれ同一VPC・別AZに配置し、HAクラスタを構成するものです。
これにより、VyattaのマルチAZ構成を可能にします。

しかし、従来VPCに起因する問題でVyattaのクラスタリング機能を有効にする事ができませんでした。
これを、Vyattaの標準機能（Configのみ）で、この問題を解決しました。

HAクラスタを阻むVPCとVyattaの組み合わせ

VyattaのHAクラスタは、Linux-HAのHeartbeatが使用されています。
一般的にブロックデバイスを同期するDRBDと併用される事が多いですが、ここでは純粋にフェールオーバの機能としてheatbeatのみ使用しています。
また、STONITH（IPMI等を使い障害機を自動的にシャットダウンする仕組み）も使用しておりませんので、自殺・他殺といった心配もありません。（笑
Linux-HA Japan : LinuxにおけるHAクラスタに関する日本語リソース

しかし、Heartbeat自身はユニキャスト・ブロードキャスト・マルチキャストと対応していますが、Vyattaからはマルチキャストしか構成する事はできません。
ユニキャストの設定を手書きすれば動きますが、リブートした際にConfigが元に戻る為、クラスタに復帰することができません。
スタートアップスクリプトの変更などで対処できる場合もありますが、ブロケード社にサポートされない場合が考えられます。

一方、VPCではマルチキャスト・ブロードキャストのパケットに対応していません。
よくある質問 – Amazon VPC （仮想プライベートクラウド Amazon Virtual Private Cloud ）| アマゾン ウェブ サービス（AWS 日本語）

よって、このままでは、HAクラスタを実装することができません。

設定内容と解説

Vyattaトンネルインタフェースの構成図

今回、Vyattaのトンネルインターフェースの実装として、GREトンネルを使用しました。
挙動としては以下の通りです。

  1. トンネルインターフェースが定義される。
  2. GREによりL2トンネルが張られ、両端のトンネルインターフェースにIPアドレスが付与される。
  3. トンネルインターフェースのアドレスを使用し、Heartbeatが相互監視をはじめる。

GREは暗号化機能を持たない為、一般的にIPSecと併用されますが、今回のような場合はリソースへの負荷もあり、GRE単体で使用しました。
GRE ( Generic Routing Encapsulation ) とは – ネットワークエンジニアとして

set system host-name vyatta-a
set system time-zone Asia/Tokyo

set interfaces tunnel tun00 address '169.254.0.1/24'
set interfaces tunnel tun00 encapsulation 'gre'
set interfaces tunnel tun00 local-ip '《vyatta-aのLocalIP》'
set interfaces tunnel tun00 remote-ip '《vyatta-cのLocalIP》'
set interfaces tunnel tun00 multicast enable

set cluster interface tun00
set cluster pre-shared-secret cloudpack
set cluster group aws
set cluster group aws primary vyatta-a
set cluster group aws secondary vyatta-c

このConfigのポイントとしては３つです。

  • Heartbeatを構成する際に、ホスト名が使用されます。
    よって、clusterで定義するホスト名と、実際のホスト名を一致させます。
  • トンネルインターフェースではリンクローカルアドレスを使用します。
    これは、Vyattaが環境によって、すべてのプライベートIPを使用する可能性がある為、なるべくバッティングを避けるためです。
  • トンネルインターフェースに対して、マルチキャストルーティングを有効にします。
    （set interfaces tunnel tun00 multicast enable）
    マルチキャストルーティングは、VyattaCore 6.6R1で実装されました。

また、先に挙げていたように、このConfigはBrocade社のサポート技術の範囲で作成されています。

結果として、以下のようにスプリットブレイン（意図しない両Act）にならず、正常に障害を検出・フェールオーバーしています。

Vyattaクラスタリングの障害検出フェールオーバーの確認

尚、検証にあたり、以下のAMIを使用しました。
AWS Marketplace: Vyatta Virtual Router/Firewall/VPN by Vyatta, Inc.

バージョン：VSE6.6R (07/17/2014)

Vyattaクラスタリング構成にあたり使用したAMI: VSE6.6R6, released 07/17/2014

おわりに

尚、GREもクラウドサービスによっては使用できないところがあります。
これは、ネットワークインフラをL2 over L3で実装しており、カプセリングに使用しているプロトコルは使用できない場合があります。
今回のマルチキャスト、及びブロードキャストについても、同様の事情から使用できない場合があります。

クラウドベンダーの中にはVLANを使って解決している場合もあり、この場合はほぼ物理サーバと同じようにネットワークを使うことが可能です。
「さくらのクラウド」のアーキテクチャは、意外なほどシンプルだった － Publickey
クラウド 機能・サービス（プライベートLAN） | ニフティクラウド

最後に、解決のヒントをくださったデプロイ王子、ありがとうございました。＼(^o^)／

元記事はこちらです。
「標準機能でできた！商用版VYATTAのマルチAZ化」