はじめに
みなさんこんにちは。東日本担当のプリセールスの西下（にしした）です。
以前のブログ記事ではAWSをはじめとしたクラウド環境の可用性の現実と対策法として当社のHAクラスターソリューション（LifeKeeperとDataKeeper）をご紹介しました。
今回はLinux版のLifeKeeperとDataKeeperを使ったAmazon EC2上のHAクラスター構成について詳しく解説します。更に次回からは、実際の構築手順を詳しくご紹介致しますのでご期待ください。
LifeKeeperとDataKeeperを使ったAmazon EC2のHAクラスター構成（Linux版）
LifeKeeperには標準機能として「仮想IP」という機能が提供されています。この機能は、常に稼動系のノードに紐付く「仮想IPアドレス」を提供します。クライアントからは仮想IPアドレスを指しておくことで、今どちらのノードが稼動系なのかを意識する必要がなくなる便利な機能です。
仮想IPが行っている具体的な機能については下記をご参照下さい。
→[[Linux] IP Recovery Kit の処理概要]
下図はオンプレ環境の典型的なHAクラスターの概念図です。単一のサブネット内でHAクラスターを構成する場合は、このように製品機能の仮想IPでクライアントからのルーティングを制御できます。
しかし仮想IPアドレスが使えるのは、各ノードが同一のサブネットにある場合に限られます。サブネットを跨いだHAクラスター構成にした場合、ネットワークの仕組み上クライアントは、仮想IPアドレスをそのまま参照しようとしてもクラスターノードにたどり着くことができなくなってしまうため、何らかの対応が必要になります。
このクライアントの制御（ルーティング）は上流工程で十分に考慮する必要があり、また難易度の高い領域です。
当社ではAmazon EC2上のHAクラスター構成の基本は、AZ（Availability Zone）を跨いだ構成（＝マルチAZ構成）を基本としています。これは、各AZは物理的に独立したインフラ上で稼働しているため、マルチAZでHAクラスターを構成することにより、障害に対する可用性をより高められる観点に起因します。
マルチAZのHAクラスター構成は可用性の面ではメリットがありますが、反面構成が複雑になるデメリットがあります。複雑になる要因の１つが「1つのサブネットは複数AZに跨げない」というAWSの仕様です。
→[VPC とサブネット]
このため、マルチAZのHAクラスターを構成する場合は、サブネットを跨いだHAクラスター構成が前提となります。
LifeKeeper for Linuxでは、これらのルーティングの制御を容易に構築していただくために、製品の標準機能として提供しています。下記の４つのシナリオに対応しており、Amazon EC2上にHAクラスターを構築する際に遭遇する要件のパターンをカバーしています。
＜LifeKeeper for Linuxの構成例：Amazon EC2向け＞
※上記概念図は、いずれもマルチAZ構成です。（簡略化のためAZの記載を省略しています。）
上記について簡単に説明致します。
シナリオの種類 | 特徴 |
ルートテーブル | ・クライアントがVPC内部からアクセスしてくるパターンで、よく使われる構成です。 ・クライアントのルーティングにルートテーブルを利用しています。LifeKeeperによるフェイルオーバー（切り替え）時には、LifeKeeperからAWSのAPIをキックしてルートテーブルの指しているターゲットのIPアドレスを稼動系から待機系に書き換えます。 ・クライアントがAPサーバー、クラスターの保護対象がDBサーバーのケースなどに適用されます。 ・製品の標準機能のRecovery Kit for EC2で提供されます。 |
ElasticIP | ・クライアントがVPC外部からインターネットを経由してアクセスしてくるパターンです。 ・クライアントのルーティングに、パブリックなElastic IPとクラスターのActiveノードとのマッピングを利用しています。LifeKeeperによるフェイルオーバー（切り替え）時には、LifeKeeperからAWSのAPIをキックしてElastic IPと紐付いている先を稼動系から待機系に書き換えます。 ・クラスターの保護対象がWebサーバーの場合などに適用されます。 ・製品の標準機能のRecovery Kit for EC2で提供されます。 |
オンプレから接続 | ・クライアントがVPC外のオンプレ環境から専用線などの閉域網を通ってAWS内のシステムと通信するケースが、基幹系システムのAWSへの移行が一般化する中で急増しています。この場合AWSの受け側は「Direct Connect」という専用線接続サービスが使われます。 ・VPC外からのアクセスの場合、前述のルートテーブルを使ったルーティングがAWSの仕様上使えません。このためクライアントは、IPアドレスではなくホスト名でクラスターノードにアクセスし、DNSで名前解決をすることでルーティングさせます。AWSでは「Route53」というDNSのサービスが提供されているので、LifeKeeperによるフェイルオーバー（切り替え）時には、LifeKeeperからAWSのAPIをキックしてRoute53のAレコードが指しているクラスターノードのIPアドレスを書き換えることで、クライアントのルーティングを制御します。 ・クラスターの保護対象が統合運用管理ツールやファイル転送ソフト、ファイルサーバーなどの場合に適用されます。 ・製品の標準機能の「Route53 Recovery Kit」で提供されます。 |
別のVPCから接続 | 仕組み的には上記の「オンプレから接続」と同じです。 |
さて上記の４つのシナリオのうち、実際の案件でよく使われるのは「ルートテーブルシナリオ」になります。HAクラスター構成は「スケールアウト」ではなく「スケールアップ」型なので、スケールアップの代表格のDBサーバーと相性の良いルートテーブルシナリオが多く使われています。
今回の記事でもこのルートテーブルシナリオを対象に進めていきます。
ルートテーブルシナリオの仕組み
それでは次に、ルートテーブルシナリオを前提としたHAクラスターの構成図をご覧ください。
どうでしょうか？これはHAクラスター構成に必要な要素だけに絞り込んでいるのですが、それでもいろいろな要素が含まれていますね。それでは各要素についてご説明致します。
構成要素 | 説明 |
NATインスタンス | PublicなIPアドレス（Elastic IP）を持つPublicなサブネットに配置します。 ルートテーブルシナリオではRecovery Kit for EC2の機能でAWSのAPIを使ってルートテーブルを制御の内容を書き換えます。AWSのAPIを使うにはインターネットにアクセスできることが前提となります。 このままではAWSのAPIを使えないため、クラスターノードは一旦所属するPrivateなサブネットのルートテーブルを参照して本NATインスタンスを経由してインターネットに接続します。 ※AWSの新機能のPrivate Linkを使うことでインターネットに出ずにAPIをたたけるようになりましたが、本記事では従来通りのNATインスタンスを使う方式を前提としています。 |
踏み台のWindowsサーバー | Publicなサブネットに配置します。クラスターの稼動には使いませんが、設定やメンテナンス作業は全て踏み台サーバーで行います。 そこでインターネットから接続可能なWindowsサーバーを「踏み台」としてVPC内に配置し、作業はこのWindowsサーバーにお手元のPCからRDPで接続して行います。踏み台のWindowsサーバーとクラスターノード間はSSHで通信します。 また、LifeKeeperの操作の大半はGUIを使用して行います。EC2にはGUI環境が用意されていないので、クラスターノードのX Window（X11）を踏み台のWindowsサーバーにフォワードしてGUI環境を使います。 |
クライアント | 特段の理由がなければPrivateなサブネットに配置します。 |
クラスターノード | 上記のクライアントから見たサーバーです。 インターネットにアクセスできる必要が無いので、Privateなサブネットに配置します。 |
ダミーの仮想IPアドレス | ルートテーブルシナリオの特徴的な存在です。 意図的にVPC（10.0.0.0/16）外のダミーのIPアドレス（10.1.0.10）をクライアントから参照させることでルートテーブルを参照させて、そのルートテーブルに登録されているターゲットのENIにアクセスさせます。 フェイルオーバーの際には、LifeKeeperからAWSのAPIをキックしてターゲットを稼動系のENI（Elastic Network Interface）から待機系のENIに書き換えます。この制御により、クライアントは常に稼動系のクラスターノードにアクセスできます。 |
*1 LifeKeeperではコミュニケーションパスは2系統以上を推奨しています（サポート要件は「1系統以上」であること）。但しオンプレと異なり、クラウド環境の仮想NICは、実際の物理の構成がブラックボックスな点もあり、仮想NICの冗長化の必要性については議論の余地があります。当資料では極力構成をシンプルにするため、あえて1系統で構成してあります。
ルートテーブルシナリオの動き
それではルートテーブルシナリオの動きについて順を追って見てみましょう。
まずサブネットA2のクライアントからダミーの仮想IPアドレスに対してアクセスを試みます。（赤線）
サブネットA2は10.0.2.0/24なので、10.1.0.10へのトラフィックは、サブネットA2のルートテーブルを参照します。サブネットA2のサブネットは下記のように設定してあります。
＜サブネットA2のルートテーブル＞
接続先 | ターゲット | 補足 |
10.0.0.0/16 | ローカル | デフォルトの値 |
10.1.0.10/32 | 稼動系のクラスターノードのENIのIDなので、今はNode1のENI。 | フェイルオーバーで書き換え |
0.0.0.0/0 | サブネットA1のNATインスタンス（NAT1） | インターネットへのトラフィックはNATインスタンスへルーティングされる。 |
よって、下記のようなルートを通ります。
これはサブネットC2のクライアントから見ても同じです。
＜サブネットC2のルートテーブル＞
接続先 | ターゲット | 補足 |
10.0.0.0/16 | ローカル | デフォルトの値 |
10.1.0.10/32 | 稼動系のクラスターノードのENIのIDなので、今はNode1のENI。 | フェイルオーバーで書き換え |
0.0.0.0/0 | サブネットC1のNATインスタンス（NAT２） | インターネットへのトラフィックはNATインスタンスへルーティングされる。 |
インターネットへの接続先0.0.0.0/0のターゲットがサブネットC1のNAT2になっている以外は同じです。接続先10.1.0.10/32のターゲットがNode2ではなくてNode1であることがポイントです。
なお、LifeKeeperが障害を検知してフェイルオーバーが行われると、各サブネットのルートテーブルは下記のようにLifeKeeperからAWSのAPIをキックして書き換えます。
＜サブネットA2のルートテーブル＞
接続先 | ターゲット | 補足 |
10.0.0.0/16 | ローカル | デフォルトの値 |
10.1.0.10/32 | 稼動系のクラスターノードのENIのIDなので、今はNode2のENI。 | フェイルオーバーで書き換え |
0.0.0.0/0 | サブネットA1のNATインスタンス（NAT1） | インターネットへのトラフィックはNATインスタンスへルーティングされる。 |
＜サブネットC2のルートテーブル＞
接続先 | ターゲット | 補足 |
10.0.0.0/16 | ローカル | デフォルトの値 |
10.1.0.10/32 | 稼動系のクラスターノードのENIのIDなので、今はNode2のENI。 | フェイルオーバーで書き換え |
0.0.0.0/0 | サブネットC1のNATインスタンス（NAT２） | インターネットへのトラフィックはNATインスタンスへルーティングされる。 |
どこが変わったかわかりましたか？接続先10.1.0.10/32のターゲットがNode1からNode2に書き換えられたことがポイントです。あとは変わりません。
これによりサブネットA2のクライアントは、サブネットC2のクラスターノードのNode2のENIをターゲットとして認識します。
ちなみに、サブネットA1およびC1のルートテーブルは、両者ともに下記の内容になります。
＜サブネットA1およびC1のルートテーブル＞
接続先 | ターゲット | 補足 |
10.0.0.0/16 | ローカル | デフォルトの値 |
0.0.0.0/0 | Internet Gateway | インターネットへアクセスするにはPublicなIPアドレス＝Elastic IPが割り当てられる。 |
例えばNode1からインターネットへアクセスしようとした場合、下記のルートを通ります。
いかがでしょうか？ルートテーブルシナリオの動きについてイメージをお持ちいただけたかと思います。
次回からは実際に今回ご紹介した構成の構築手順をご紹介致します。お楽しみに。
＜ご参考情報＞
当ブログ記事でご紹介した構成は、極力シンプルな構成を前提としています。実際の案件ではもっと複雑な構成も考えられます。今回は応用例として、過去にクラスメソッド様およびアマゾンウェブサービス様と三社で行ったブログ記事をご紹介致します。
保護対象はサイボウズガルーンのWebサーバー分離構成で、クラスターノードから見たクライアントは、ELB（Elastic Load Balancing）でスケールアウトされたWebサーバーです。各Webサーバーがダミーの仮想IPアドレスを参照して、稼動系ノードのMySQLと通信する構成となります。※構成にDirect Connectが含まれますが、HAクラスターに関する箇所はルートテーブルシナリオで構成されています。
→[外部サイト：Direct Connect環境のLifeKeeperでサイボウズガルーンを冗長化してみた]
AWS関連情報
LifeKeeperやDataKeeperによるAmazon EC2上でのクラスター構成についてご紹介しています。
お問い合わせ先
「もっと詳しい話を聞いてみたい。」「自分の持っている案件は対応できそうか？」といった場合は、下記までお気軽にお問い合わせください。
