みなさん、こんにちは。西下です。
寒い日が続きますね。私は朝方の生活を初めて長いのですが、今の季節は朝に通勤で家を出発する時はまだ夜で真っ暗です。空いた電車に座って通勤し、オフィスに一番乗りしてから日の出を拝むのが日課です。当社のプラチナタワーオフィスは日の出のグラデーションが望めてとてもきれいですよ！
さて、当社のLifeKeeperの強みの1つに「クラウド対応」のノウハウがあります。当社はいち早くHAクラスターのクラウド対応に取り組んでまいりました。クラウドの中でも特にAWSはお客様が多くいらっしゃるので、SIer様の構築のご負担を減らすために、当社では標準機能でAWS向けのクラスターの制御する機能を提供しております。
LifeKeeperは可用性の観点から、AWS EC2環境では、AZ（Availability Zone）を跨いだ構成を標準としています。AZを跨ぐということはサブネットも跨ぐということになるので、クライアントはLifeKeeper標準機能の「仮想IPアドレス」をそのまま使ってActiveノードと通信することはできません。
そこで一般的なクラスターソフトではAWSのAPIを駆使して、クラスターが障害や手動で切り替わるタイミングで様々な制御を作り込む必要があるのですが、LifeKeeperでは案件で出てくる下記の要件を製品の標準機能でカバーしており、SIer様の構築効率の大幅なUPに寄与できます。
＜LifeKeeperの標準機能でカバーされている構成の概念図＞
※スペースの都合上AZの概念は割愛しています。
詳細は「Amazon EC2環境でのHAクラスター構成パターン」をご参照ください。
この中で、一番左側の「ルートテーブルシナリオ」は、クライアントが同一VPC内に存在するというシンプルさとニーズの多さから、既に構築ガイドを公開済みです。当構築ガイドでは、Step By Stepレベルで各手順をスクリーンショット付きで詳しく説明されています。非常に人気の高い資料ですので、ぜひこの機会にご一読ください。
【構築ガイド】SIOS Protection Suite for Linux on AWS Step by Step Guide
このルートテーブルシナリオと同じくらいニーズが高いのが、上記概念図の右側の2つです。
1つはクライアントがデータセンター内のオンプレ環境にあるケースです。この場合は専用線などの閉域網を使い、AWS側の受け口としてDirect Connectを経由してクラスターのActiveノードと通信する必要があります。
AWSの技術仕様上の制約で、外部からはルートテーブルを使ったルーティング制御は行なえません。このため本ケースでは前述のルートテーブルシナリオではなく、DNSサービスのAmazon Route 53のAレコードをLifeKeeperの切り替えのタイミングで書き換えることによる、ホスト名解決によるルーティング機能を製品の標準機能「Recovery Kit for Route 53™」で提供しています。
同様にクライアントが別VPCから通信してくるケースも同様に、Recovery Kit for Route 53™で対応しています。
＜Recovery Kit for Route 53™によるクライアントのルーティング制御の概念図＞
＜オンプレからDirect Connect経由の場合＞
＜VPCピアリングの場合＞
このRecovery Kit for Route53™を使ったStepByStep形式の構築ガイド（Linux版）がついに公開されました。Step By Stepレベルで各手順がスクリーンショット付きで詳しく説明されています。手順だけではなく、構成の説明にもかなり紙面を使っており、現在最もオススメの資料です。ぜひこの機会にご一読ください。
SIOS Protection Suite for Linux Step by Step Guide【AWS Route 53 編】
＜図解を多用して非常にわかりやすい内容の例＞
最近のAWSの案件では、ほぼ毎回Amazon Route 53による制御の要件が出ます。ぜひこの機会にAmazon Route 53による制御をご確認いただき、お客様へのご提案にご活用ください。
案件等がございましたら、お気軽に下記からお問い合わせくださいませ。
関連情報
AWS環境の対応構成や導入事例、検証レポートや構築ガイド等は下記からご参照ください。
