皆さんこんにちは、西下です。
当社では現在、AWS Outposts ラック上でのLifeKeeperによる冗長化構成のサポートを順次進めています。背景としては、オンプレミスの基幹系システムをいきなりリージョンのAWS環境に移行するのではなく、レイテンシの低いオンプレミス環境で構築できるAWS環境（＝AWS Outposts ラック）に移行するニーズは今後高まることが予想されるためです。詳しくはAWS Outposts ラックの連携ソリューションページをご覧ください。
皆さま、こんにちは。7月26日（金）にオンサイトでセミナーを開催しました。本セミナーではオンプレミス環境とクラウドをスムーズに統合したい企業の皆様にとって、必見のイベントとなりました。
本記事ではそのセミナーのポイントをご紹介します。
前回述べたように、金融のリアルタイム処理や鉄道の運行管理システム、リアルタイム配電管理システム、スマートロジスティクスなど大規模でネットワークの低遅延などが求められるシステムがAWS Outposts上で稼働しています。
こうした金融系や社会インフラ系のシステム障害がもたらす影響は甚大なものとなります。
そこで、オンプレミス同等の可用性を求める企業が多く、1つの手法としてHAクラスター構成が採用されます。
皆さんこんにちは、西下です。
この度AWS JAPAN APN ブログに、AWS OutpostsラックとLifeKeeperとの連携記事が掲載されたのでお知らせ致します。
皆さんこんにちは、西下です。
当ブログ記事では、LifeKeeperが対応しているAmazon EC2上でのHAクラスター構成をご紹介します。
2025年に追加された構成もあるので、ぜひご覧ください。
Amazon EC2環境では下記の構成が基本となります。
LifeKeeperは標準機能でAmazon EC2上で要件となるHAクラスター構成をほぼ網羅しています。
その中で代表的な構成をご紹介します。
クライアント（クラスターノードと通信するマシン）は仮想IPに向けて通信することでActiveノードに到達できます。AWS環境でAZを跨ぐとサブネットも跨いでしまうので、オンプレミスのように仮想IPだけではクライアントは正しくActiveノードへ到達できません。
そこで、VPCのCIDR外の仮想IPをルートテーブルに登録し、転送先のActive/StandbyノードのENIをクラスターの切り替え時にLifeKeeperからAWS CLIを介して書き換えることで、クライアントは常にActiveノードに到達できます。
Transit Gatewayを使うことで、AWSの外部（オンプレミス）からDirect Connectなどの閉域網を経由しても、仮想IPに向けた通信が可能となります。
◇Linux版
◇Windows版
Transit Gatewayが使えないなどの要因で上記の方式が使えない場合、Route53の名前解決による通信制御が可能です。クライアントはRoute53により名前解決された実IPに向けて通信することで、Activeノードへ到達できます。
Route53のAレコードをクラスターの切り替え時にLifeKeeperからAWS CLIを介して書き換えることで、クライアントは常にActiveノードに到達できます。
◇Linux版
◇Windows版
NLB（Network Load Balancer）のヘルスチェックに応答するノードに通信する方式にも対応しています。セキュリティ要件によりAWS CLIによる構成変更が実施できない場合にはこの方式をご検討下さい。
◇Linux版
◇Windows版
近年の災害対策ニーズの高まりから、リージョンを跨いだ構成にも対応しています。
LifeKeeper for Linux v9.9.0およびLifeKeeper for Windows v8.10.2の追加サポートとしてリリースされた機能です。
当機能が想定している構成です。
HAクラスターはリージョンAとリージョンBを跨いで構成されています。クライアントはリージョンA、B、Cのいずれかにあることを想定しています。
各クライアントからPrimaryノードへの通信は、下図のイメージとなります。各VPCのルートテーブルと各Transit Gatewayのルートテーブルは、送信先が仮想IPのエントリーの転送先をLifeKeeperから制御します。これにより、各クライアントから仮想IPに向けて通信することでPrimaryノードへ到達します。
クラスターの切り替わり時には、LifeKeeperのクラスターリソース情報にセットされた仮想IPアドレスをキーに必要情報を芋づる式に取得し、ルートテーブルに仮想IPのエントリーが存在すれば、転送先を適宜変更して通信制御が行われます。
クラスターが切り替わると、各クライアントからBackupノードへの通信は、下図のイメージとなります。各クライアントから仮想IPに向けて通信することでBackupノードへ到達します。
→[Linux][Windows] AWSのクロスリージョン環境において仮想IPで通信できる構成をサポート
VPCピア接続を条件にRoute53のAレコードの書き換えによる制御に対応しています。
◇Linux版
◇Windows版
LifeKeeperは標準機能でAmazon EC2の様々な構成に対応しています。
また、この記事で紹介されていない構成については、お気軽に下記までお問い合わせ下さい。
クラスターノード間のデータ共有方法については、今回はDataKeeperのみをご紹介しました。
関連情報として下記の記事もご参照下さい。
ご参考までに、オンプレミス環境で運用できるAWS Outpost ラックにLifeKeeperは対応しています。
よろしければユースケースページと関連ブログもご覧ください。
AWSへの7つの移行戦略に基づくアプローチや、それぞれの選択肢におけるメリットや注意点を学ぶことができるセミナーのご紹介です。
最後に実際のセミナーを視聴するためのリンクがありますので是非ご覧ください。
アマゾン ウェブ サービス ジャパン合同会社 シニアパートナーソリューションアーキテクト 豊田 真行氏
AWS へワークロードを移行するにあたって、システムの特性や要件に適した移行手法を選択する事が重要です。本セッションでは、AWS の移行戦略（7R）について詳しく説明し、各移行手法を技術的観点から、そのメリットや注意点を含めて解説いただきました。
主な内容
サイオステクノロジー 株式会社 ソリューションアーキテクト 西下 容史
AWSへの移行パスの中でユーザーが考慮しなければならない可用性について解説し、AWS上での具体的な対策方法をシステムの構成例とともにご紹介しています。
主な内容
・AWSへの移行における多様な選択肢の理解を深めたい方
・移行時のリスク評価と対策について学びたい方
・クラウド移行における効率的で安全なアプローチのヒントが知りたい方
その他
形式：オンデマンド
時間：約60分
