前回述べたように、金融のリアルタイム処理や鉄道の運行管理システム、リアルタイム配電管理システム、スマートロジスティクスなど大規模でネットワークの低遅延などが求められるシステムがAWS Outposts上で稼働しています。
こうした金融系や社会インフラ系のシステム障害がもたらす影響は甚大なものとなります。
そこで、オンプレミス同等の可用性を求める企業が多く、1つの手法としてHAクラスター構成が採用されます。
Contents
HAクラスター製品「LifeKeeper」の概要と特徴
HAクラスター製品の「LifeKeeper」はサーバーや仮想マシン、そのうえで動いているアプリケーションを監視しシステム障害発生時に自動で待機系に切り替えてサービスを継続するためのソフトウェアです。AWS Outposts環境においても可用性を高める手法として既に金融系のお客様を中心とした導入実績があります。
LifeKeeperはAWS Outposts利用時のAWSのベストプラクティスへの準拠、そして市場におけるユーザーの成功事例を含む技術的な検証を通過したことを証明として「AWS Outpostsサービスレディ」認定を国内で初めて取得した製品ですので安心してご利用いただけます。
自動フェイルオーバー
LifeKeeperは、システム障害が発生した際に自動的にスタンバイサーバーに切り替える機能を提供します。サーバーや仮想マシン、そのうえで動いているアプリケーションも監視しシステム障害発生時に自動で待機系に切り替え、システムダウンタイムを最小限に抑え、業務の継続性を確保します。
DataKeeperについて
DataKeeperはデータレプリケーションツールです。LifeKeeperと合わせて利用することで、クラウド上に共有ディスクがあるかのように論理的な共有ディスクを作成することができます。
DataKeeperが無ければLifeKeeperによるフェイルオーバーが発生した場合スタンバイノードにデータが引き継がれないということになってしまいます。スライドのように各EC2インスタンスにアタッチされたEBSをレプリケーションすることにより、フェイルオーバー発生時にデータを切り替え先のノードでも利用することができます。
多様な環境での対応
LifeKeeperはオンプレミスおよびクラウド環境で動作し、AWS EC2上でも動作します。さまざまなインフラ環境において一貫した高可用性を提供します。グローバルで8万ライセンス、クラウドで国内約900件の導入実績がある製品です。
直感的な管理インターフェース
GUIベースの管理ツールを提供しており、ユーザーは直感的にクラスターの設定や管理を行うことができます。また、JP1やHULFT、Oracle Databaseなどの主要アプリケーションのサポートも充実しており、迅速なシステム設定が可能です。
LifeKeeperの監視と切り替えの仕組み
LifeKeeperはノードとソフトウェアの監視を行っています。
ノードの監視はパケットをクラスターノード間でやり取りするハートビートで監視を行います。ハートビートが全断した場合にノード障害を起因としたフェイルオーバーが発生します。
ソフトウェア（クラスターリソース）の監視はActiveノードで、JP1やHULFTなど弊社が用意したスクリプトやお客様が作成されたスクリプトで監視することができます。デフォルトでは2分間隔で監視を行っています。リソース監視時に障害を検知した場合に、リソース障害を起因としたフェイルオーバーが発生します。
切り替えはGUI上で予め指定した順序で各クラスターのリソースを自動停止して起動します。これによって安全に停止し、GUI上で予め指定した順序でリソースを起動することができます。
リージョンのAmazon EC2上でのサポート構成
LifeKeeperは多様な環境に対応していますが、我々が普段利用しているリージョンのAmazon EC2上でもさまざまなクライアントの接続方式に対応しています。
お客様の環境によってクライアントからの接続はさまざまですが、スライドにあるようにほぼ全てのパターンにLifeKeeperの標準機能で対応しています。
リージョンのAmazon EC2上でのHAクラスター構成でよくある構成
ここで、リージョンのAmazon EC2上でのHAクラスター構成でよくある具体的な例を紹介します。ここでの内容はクラウドリージョンでの説明になります。
AWS Outposts環境については後述します。
LifeKeeperではAvailability Zone（以下AZ）を跨いだ構成を基本としています。
リージョンのAmazon EC2環境においてAZを跨ぐとサブネットもまたぐことになるため、オンプレミスのように仮想IPアドレスを稼働系ノードと待機系ノードの間で切り替えるだけでは適切なルーティングができません。
そこで、「ルートテーブルシナリオ」を使用します。このシナリオでは、VPCのCIDR外の仮想IPアドレス（例: 10.1.0.10）を用意し、クライアントはこの仮想IPアドレスにアクセスします。クライアントからの通信はルートテーブルによって制御され、予め仮想IPアドレスのターゲットとして登録されている稼働系ノードのENI（Elastic Network Interface）にルーティングされます。これにより、クライアントからの通信は正確に稼働系ノードに到達します。
フェイルオーバー時には、LifeKeeperがAWS CLIを使ってルートテーブルの仮想IPアドレスのターゲットを自動的に待機系ノードのENIに切り替えます。これにより、クライアントはフェイルオーバー後も待機系ノードへ通信が可能となります。
なお、この構成（仮想IPアドレスとルートテーブルによるルーティング制御）は、AWSの仕様上、クライアントがクラスターノードと同じVPC内にあることが必要です。クライアントがVPC外にある場合は、Transit Gatewayを利用することでこの制約を回避することができます。
ユースケース
主なユースケースとして2つ紹介しました。
- すぐにリージョンのAWSへの移行が難しいオンプレミスのシステムに対してクラウドマイグレーションを行うケース
- 特定の場所にデータを保存する要件があるケース
どちらも、AWS様のセッションでもあがっていた課題にも出てきました。
このようなケースでAWS Outposts Rackが選択されます。スライドの上半分はクラウドリージョン、下半分がAWS Outpostsです。
クラウドリージョンのVPCがAWS Outpostsに伸びてきています。
LifeKeeperは、現時点でニーズの多い「シングルラック構成（＝シングルAZ構成）」に対応しています。
ここからは具体例を挙げてもう少し詳しい説明になります。
この例は大手金融機関で採用いただいた構成で、現在も別の金融機関のお客様で同じ構成で構築が進んでいます。
まずVPCは外のクライアントにあります。クライアントからクラスターノードに通信ができるようにすることがポイントになります。
こちらの例は、仮想IPを使いつつ、セカンダリIPの付け替えで通信しています。
ポイントとしてはダイレクトVPCルーティングモードを利用しています。このモードでは、オンプレミスのクライアントからAWS Outposts内のプライベートなIPアドレスに向けて通信が可能となります。
仮想IPアドレスと同じセカンダリIPを用意してクライアントから通信を行います。フェイルオーバーが発生した際はセカンダリIPをActive側からStandby側に付け替えて切り替え先に通信が到達できるように制御します。
費用例
次のスライドはあくまで一例となります。保護するアプリケーションによっても異なりますので費用についてはお問い合わせください。
ざっくりこれぐらいの費用感、というとらえ方をしていただければと思います。
【Q&A】
質疑応答も活発に行われ、ハードウェアの故障時や法定点検でビルが全館停電になる場合についてなど、運用に関してかなり具体的な質問が出ていました。
みなさまも、この記事をご覧になり、ご質問やご興味がございましたら是非お問い合わせください。
まとめ
今回のセミナーでは、エンタープライズ企業が直面するクラウドマイグレーションの課題と、それに対する具体的な解決策が詳しく紹介されました。AWS Outpostsは、クラウドとオンプレミスのハイブリッド環境を構築するための強力なサービスであり、特にレガシーシステムの移行やデータレジデンシーに対応するための柔軟なソリューションを提供します。
また、サイオステクノロジーは、AWSのクラウドリージョン及びAWS Outposts上で稼働するシステムの高可用性構成について、実現方法を具体例を挙げながら解説しました。
このセミナーを通じて、クラウドとオンプレミスの統合に向けた具体的な戦略を学び、ITインフラのモダナイゼーションに向けた道筋が見えたのではないでしょうか。今後も弊社はAWS様と共に、企業のクラウド移行を支援するため、さらなるソリューションとサポートを提供していく予定です。
それぞれのサービスの詳細は是非お問い合わせください。
AWS上のLifeKeeperによるHAクラスター構成については製品サイトをご覧ください。
