皆さんこんにちは。LifeKeeperプリセールスの西下です。
前回のブログではTransitGatewayの基本やHAクラスターと組み合わせたときの構成メリットをご紹介しました。
今回は、実際にTransitGatewayを使ったHAクラスタ構成の実施環境及び検証手順についてご紹介いたします。
ハンズオンのご案内もしておりますので、ぜひご覧ください。
AWS Transit Gatewayを使ってシンプルなHAクラスター構成を試してみた
「transit gateway」の検索結果
AWS Transit Gatewayとは？HAクラスター構成との組み合わせ方も紹介！
皆さんこんにちは。LifeKeeperプリセールスの西下です。
AWSの構築の現場でもTransit Gateway（トランジットゲートウェイ）の採用がよく聞かれるようになってきました。このTransit Gatewayを使うとHAクラスターの構築がシンプルになりとてもメリットがあります。
TransitGatewayとはどういったものなのか、どう使うと、どんなメリットが有るのか、そしてTransit Gatewayを使ったHAクラスター構成の設定例をご説明いたします。
AWSでの障害対策新標準！？ HAクラスタ + AWS Transit Gatewayとは
皆さんこんにちは、西下です。本年もよろしくお願いいたします。
今回は2019年のクラウドをめぐる出来事を受けて浮かび上がった課題についてお話したいと思います。
【AWS HA構成】LifeKeeperを使ったAmazon EC2の冗長化手法と最新対応まとめ
皆さんこんにちは、西下です。
当ブログ記事では、LifeKeeperが対応しているAmazon EC2上でのHAクラスター構成をご紹介します。
2025年に追加された構成もあるので、ぜひご覧ください。
『LifeKeeper』の基本的な構成
Amazon EC2環境では下記の構成が基本となります。
- LifeKeeper：ノード（仮想マシン）監視とリソース監視
- DataKeeper：ローカルディスク（EBS）をブロックレベルのリアルタイム同期
『LifeKeeper』によるAmazon EC2の冗長化構成の例
LifeKeeperは標準機能でAmazon EC2上で要件となるHAクラスター構成をほぼ網羅しています。
その中で代表的な構成をご紹介します。
仮想IPとルートテーブルの書き換えによる制御
クライアント（クラスターノードと通信するマシン）は仮想IPに向けて通信することでActiveノードに到達できます。AWS環境でAZを跨ぐとサブネットも跨いでしまうので、オンプレミスのように仮想IPだけではクライアントは正しくActiveノードへ到達できません。
そこで、VPCのCIDR外の仮想IPをルートテーブルに登録し、転送先のActive/StandbyノードのENIをクラスターの切り替え時にLifeKeeperからAWS CLIを介して書き換えることで、クライアントは常にActiveノードに到達できます。
Transit Gatewayを使うことで、AWSの外部（オンプレミス）からDirect Connectなどの閉域網を経由しても、仮想IPに向けた通信が可能となります。
■関連するマニュアル ※バージョンは2025年２月時点の最新バージョン
◇Linux版
◇Windows版
実IPとRoute53のAレコードの書き換えによる制御
Transit Gatewayが使えないなどの要因で上記の方式が使えない場合、Route53の名前解決による通信制御が可能です。クライアントはRoute53により名前解決された実IPに向けて通信することで、Activeノードへ到達できます。
Route53のAレコードをクラスターの切り替え時にLifeKeeperからAWS CLIを介して書き換えることで、クライアントは常にActiveノードに到達できます。
■関連するマニュアル ※バージョンは2025年２月時点の最新バージョン
◇Linux版
◇Windows版
NLBのヘルスチェックによる制御
NLB（Network Load Balancer）のヘルスチェックに応答するノードに通信する方式にも対応しています。セキュリティ要件によりAWS CLIによる構成変更が実施できない場合にはこの方式をご検討下さい。
■関連するマニュアル ※バージョンは2025年２月時点の最新バージョン
◇Linux版
◇Windows版
リージョンを跨いだ構成
近年の災害対策ニーズの高まりから、リージョンを跨いだ構成にも対応しています。
仮想IPとルートテーブルの書き換えによる制御
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ノードへ到達します。
■関連するマニュアル
- こちらからGeneric ARKの制御スクリプトとドキュメントをダウンロード頂けます。
→[Linux][Windows] AWSのクロスリージョン環境において仮想IPで通信できる構成をサポート
実IPとRoute53のAレコードの書き換えによる制御
VPCピア接続を条件にRoute53のAレコードの書き換えによる制御に対応しています。
■関連するマニュアル ※バージョンは2025年２月時点の最新バージョン
◇Linux版
◇Windows版
LifeKeeperは標準機能でAmazon EC2の様々な構成に対応しています。
また、この記事で紹介されていない構成については、お気軽に下記までお問い合わせ下さい。
クラスターノード間のデータ共有方法については、今回はDataKeeperのみをご紹介しました。
関連情報として下記の記事もご参照下さい。
ご参考までに、オンプレミス環境で運用できるAWS Outpost ラックにLifeKeeperは対応しています。
よろしければユースケースページと関連ブログもご覧ください。
クラウド時代の災害対策 ～ Amazon EC2の仮想IPによるクロスリージョンDR構成のサポート開始 ～
皆さんこんにちは、西下です。
昨今の自然災害の増加などの背景から、Amazon Web ServicesやMicrosoft Azureといったパブリッククラウド環境で、リージョンを跨いだHAクラスター構成（DR要件）のご要望が増えています。
LifeKeeperは、Amazon EC2環境では既にリージョンを跨いだHAクラスター構成に対応しています。
詳しくは下記のマニュアルをご参照下さい。
- Linux版：AWS VPC ピアリング接続を使用した複数 VPC クラスター構成クイックスタートガイド
- Windows版：AWS VPC ピアリング接続を使用した複数 VPC クラスター構成クイックスタートガイド
上記は、Route53でホスト名の名前解決を行い、解決した「実IP」に向けて通信が行われる方式です。クラスターが切り替わる時には、LifeKeeperのRecovery Kit for Route53*2がAWS CLIを使ってRoute53のAレコードを書き換えることで、待機系の実IPに向けて通信が行われます。
最近は、LifeKeeperの保護対象のソフトウェアの事情により、「実IP」ではなく切り替えの前後で同じIPアドレスを使える「仮想IP」を使うご要望が増えてきています。そこでクライアントから仮想IPに向けて通信することで、Activeノードへ到達する新機能が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ノードへ到達します。
※当構成の条件は下記のとおりです。
- EC2インスタンス、VPC、TransitGateway等、上記構成図に含まれるオブジェクトは全て同一AWSアカウントに所属
- クラスタノードからAmazon EC2サービスのエンドポイントにHTTPおよびHTTPSを使用してアクセスできること
当機能は「Generic ARK for AWS Transit Gateway」として提供されます。
制御スクリプトと管理ガイドはこちらでご入手頂けます。
→[Linux][Windows]AWSのクロスリージョン環境において仮想IPで通信できる構成をサポート
リージョンを跨いだHAクラスター構成に仮想IPで接続するご要件をお持ちの方は、ぜひお試し下さい。
■参考情報
AWSのユースケースページ（LifeKeeper製品サイト）
■脚注
- 概要：Azure Global Load Balancer(リージョン間ロードバランサー)シナリオ
- ロードバランサーの設定：Azure – Global Load Balancer(リージョン間ロードバランサー)の作成
*2：Recovery Kit for Route53は、クラスターの切り替え時にLifeKeeperからAWS CLIを介してRoute53のAレコードをStandby側の実IPアドレスに書き換える標準機能です。クライアントはホスト名の名前解決をRoute53で行うことで、実IPに向けて通信することでActiveノードへ到達できます。
【第二部】AWS Outpostsラックの可用性を高めよう ~HAクラスター製品LifeKeeperによる対策~（後編）
前回述べたように、金融のリアルタイム処理や鉄道の運行管理システム、リアルタイム配電管理システム、スマートロジスティクスなど大規模でネットワークの低遅延などが求められるシステムがAWS Outposts上で稼働しています。
こうした金融系や社会インフラ系のシステム障害がもたらす影響は甚大なものとなります。
そこで、オンプレミス同等の可用性を求める企業が多く、1つの手法としてHAクラスター構成が採用されます。
インターネットに出られない環境からプロキシ経由でRoute53にアクセスする方法
皆様こんにちは。サイオステクノロジーの西下です。今回は、金融系などのセキュリティ要件が厳しいシステムでLifeKeeperをインターネットに出られない環境で運用する必要がある場合、LifeKeeperからプロキシ経由でRoute53にアクセスする方法を紹介します。
LifeKeeperはLinux版とWindows版のいずれもAWS（Amazon EC2）をサポートしています。サポートされる構成については以下をご参照下さい。
→[Q：LifeKeeperおよびDataKeeperは、Amazon EC2上でどんな構成をサポートしていますか？]
Transit Gatewayが利用できない環境での課題
上記で紹介されていますが、クライアントがVPCの外から閉域網でLifeKeeperにアクセスする構成で、Route53のAレコードをLifeKeeperからRecovery Kit for Route53を使って書き換える方式は、Transit Gatewayとルートテーブルシナリオの組み合わせが一般的になった最近では使用頻度が減ってきています。しかしTransit Gatewayがお客様の環境では使えないケースも少なからずあり、そういったケースではRoute53のAレコードの書き換えによる制御が使われます。
Route53はAWSではポピュラーなサービスですが、VPCエンドポイント経由では利用できない（インターネットを経由する必要がある）ので、プライベートな環境のLifeKeeperからアクセスする時は注意が必要です。特に金融系などのセキュリティ要件が厳しいシステムでは、LifeKeeperから直接インターネットに出られないケースはよくあると思います。
プロキシ（Proxy）サーバーを経由して解決
こういったケースでは、LifeKeeperからプロキシ（Proxy）サーバーを経由することで、プライベートな環境のLifeKeeperからでもRoute53に対して制御が可能になります。
プロキシを図に描くと下記の構成（例）となります。
※構成図のインスタンス
EC2インスタンス | 稼働系ノード：LKNODE01 | 稼働系/待機系ノードは踏み台サーバーから操作を行い、インターネットへアクセスできない。 |
EC2インスタンス | プロキシサーバー：LKPROXY |
|
図に記載の通り、LifeKeeperは右側のVPC内のPrivate Subnetに配置されています。左側のVPCにはInternet Gatewayが用意されており、VPC内にはプロキシサーバーがあります。LifeKeeperからはプロキシサーバーを経由することでインターネットに出てRoute53にアクセスしてAレコードを制御することが可能になります。
LifeKeeperはAWS CLIを使ってRoute53やルートテーブル等を制御しています。プロキシサーバー経由でAWS CLIを実行するには、AWSが提供している環境変数（HTTP_PROXY、HTTPS_PROXY、NO_PROXY）を使う必要があります。Recovery Kit for Route53はこれらのパラメータに対応しており、LifeKeeperのパラメータファイル上でこれらの値を設定することでプロキシサーバーを経由することが可能になります。
→[マニュアル：Route53 パラメータ一覧（Linux版）]
→[マニュアル：Route53 パラメータ一覧（Windows版）]
検証レポート
今回、プロキシサーバー経由でRoute53を制御する構成を検証しました。当構成の検証レポートをLinux版とWindows版のそれぞれをご用意しております。ご希望の方は、下記フォームからお申し込み下さい。
「インターネットに出られない環境でRoute53を使う」要件で当ブログがお役に立てば幸いです。ぜひご活用下さい。
クラウドリフトの最初の一歩。社内からAWSに配置したHAクラスターシステムへ接続するには？ #1
～LifeKeeperで利用可能なクライアント接続方式とTransit Gatewayにより用いられるルートテーブル方式について～
AWS にシステムの一部を移行して、オンプレミスの既存システムからアクセスして利用したいという要望は大変よく頂きます。AWSにありながら社内システムの一部として利用することは、当社で提供するHAクラスターであるLifeKeeperを導入いただくお客様でも頻繁に利用されている構成です。
そのため、本ブログでは2回にわたりシステムの一部をAWSへのクラウドリフトする方法について解説いたします。今回はAWSクラウド環境で実現すべきクライアント接続方式について解説いたします。
【日立ソリューションズ×サイオステクノロジー】クラウド環境でJP1を安定稼働させるには？―監視環境構築のベストプラクティス―
近年では、運用監視環境をクラウドでクラスタ化することで可用性を高めたいというニーズが高まっています。システムを安定運用するには、それらを下支えする運用監視環境が必要です。
本記事では、ある企業で監視環境の冗長化を実現した方法について、日立ソリューションズ様にインタビューを実施した内容を紹介します。
【セミナーレポート】基幹システムの安心・安全なクラウド化に欠かせない4本の矢
こんにちは、マーケティング担当クニイです。
先日、伊藤忠テクノソリューションズ様・日立製作所様・アマゾンウェブサービス様と共催で、「基幹システムのクラウド化」というテーマのウェビナーを開催しました。
今回は、その内容をダイジェストでご紹介します。
本記事最後では、サイオステクノロジーがウェビナーで使用した資料もダウンロードできますので、ご興味のある方はぜひご覧ください！
Windows版のJP1/AJS3がAWS Route53によるルーティング方式のサポートを開始
みなさんこんにちは、サイオステクノロジーの西下です。今回は、Windows版のJP1/AJS3 – ManagerおよびAgentが、AWSのRoute53によるルーティング方式のサポートを開始したことをご案内致します。
当社のHAクラスター製品「LifeKeeper」は、統合システム運用管理ツールのJP1のジョブ管理製品のJP1/AJS3向けに、専用のリカバリキットのラインナップをご用意しております。これらを使うことで、制御スクリプトの開発無しでGUI操作だけでHAクラスターを構築いただけます。
【検証レポートあり】Google Cloud上でJP1/AJS3をHAクラスタソフトで冗長化！
こんにちは、サイオステクノロジーの高田です。
日立製作所が提供するジョブ管理システム、JP1/AJS3についてのお話です。JP1/AJS3は企業活動を支える重要なシステムとして、クラウド上で運用する場合にも、十分な障害対策が検討されております。その一つとしてクラスタソフトウェアによる冗長構成での対策があります。
３社共催ウェビナー「まとめて解決！JP1、AWS移行のギモン」-イベントレポート-
こんにちは、サイオスの井上です。
2022年6月24日に、株式会社日立製作所様とアマゾンウェブサービス合同会社様とサイオステクノロジー株式会社の３社共催ウェビナーを開催しました。「基幹系システムのジョブ管理を担うJP1/AJS3を、AWSへ移行する際の疑問を解決」というテーマで、90名近い方にお申込み頂きました。その後、2022年7月22日に開催したJP１×LifeKeeper on AWSハンズオンセミナーも満員で終える事が出来ました！
この記事では、 「まとめて解決！JP1、AWS移行のギモン」の大まかな内容をご紹介致します。
Linux版のJP1/AJS3がAWS Route53によるルーティング方式のサポートを開始
みなさんこんにちは、サイオステクノロジーの西下容史です。今回は、Linux版のJP1/AJS3 – ManagerおよびAgentが、AWSのRoute53によるルーティング方式のサポートを開始したことをご案内致します。
AWS上でJP1/AJS3をHAクラクターで冗長化する、ざっくり手順とは
こんにちは、マーケティング担当のオイカワです。
日立製作所が提供するジョブ管理システム、JP1/AJS3についてのお話です。JP1/AJS3は企業活動を支える重要なシステムとして、クラウド上で運用する場合にも、十分な障害対策が検討されております。
今回は、実際に開催しているハンズオンセミナーでの演習内容をもとに、AWS上でJP1/AJS3をHAクラスターを使って冗長化する場合の構築手順を簡単にご紹介いたします。
アプリケーションの障害はもちろん、AWSの単一Availability Zone(以下、AZ)における広域障害発生時でも、ジョブを自動で引き継ぎ、システムの停止時間を最小限に抑えることができます。
是非ご参考ください。
12
