みなさん、こんにちは。西下です。
寒い日が続きますね。私は朝方の生活を初めて長いのですが、今の季節は朝に通勤で家を出発する時はまだ夜で真っ暗です。空いた電車に座って通勤し、オフィスに一番乗りしてから日の出を拝むのが日課です。当社のプラチナタワーオフィスは日の出のグラデーションが望めてとてもきれいですよ！
さて、当社のLifeKeeperの強みの1つに「クラウド対応」のノウハウがあります。当社はいち早くHAクラスターのクラウド対応に取り組んでまいりました。クラウドの中でも特にAWSはお客様が多くいらっしゃるので、SIer様の構築のご負担を減らすために、当社では標準機能でAWS向けのクラスターの制御する機能を提供しております。
皆様こんにちは。サイオステクノロジーの西下です。今回は、金融系などのセキュリティ要件が厳しいシステムでLifeKeeperをインターネットに出られない環境で運用する必要がある場合、LifeKeeperからプロキシ経由でRoute53にアクセスする方法を紹介します。
LifeKeeperはLinux版とWindows版のいずれもAWS（Amazon EC2）をサポートしています。サポートされる構成については以下をご参照下さい。
→[Q：LifeKeeperおよびDataKeeperは、Amazon EC2上でどんな構成をサポートしていますか？]
上記で紹介されていますが、クライアントがVPCの外から閉域網でLifeKeeperにアクセスする構成で、Route53のAレコードをLifeKeeperからRecovery Kit for Route53を使って書き換える方式は、Transit Gatewayとルートテーブルシナリオの組み合わせが一般的になった最近では使用頻度が減ってきています。しかしTransit Gatewayがお客様の環境では使えないケースも少なからずあり、そういったケースではRoute53のAレコードの書き換えによる制御が使われます。
Route53はAWSではポピュラーなサービスですが、VPCエンドポイント経由では利用できない（インターネットを経由する必要がある）ので、プライベートな環境のLifeKeeperからアクセスする時は注意が必要です。特に金融系などのセキュリティ要件が厳しいシステムでは、LifeKeeperから直接インターネットに出られないケースはよくあると思います。
こういったケースでは、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を使う」要件で当ブログがお役に立てば幸いです。ぜひご活用下さい。
みなさんこんにちは、サイオステクノロジーの西下です。今回は、Windows版のJP1/AJS3 – ManagerおよびAgentが、AWSのRoute53によるルーティング方式のサポートを開始したことをご案内致します。
当社のHAクラスター製品「LifeKeeper」は、統合システム運用管理ツールのJP1のジョブ管理製品のJP1/AJS3向けに、専用のリカバリキットのラインナップをご用意しております。これらを使うことで、制御スクリプトの開発無しでGUI操作だけでHAクラスターを構築いただけます。
みなさんこんにちは、サイオステクノロジーの西下容史です。今回は、Linux版のJP1/AJS3 – ManagerおよびAgentが、AWSのRoute53によるルーティング方式のサポートを開始したことをご案内致します。
こんにちは、オイカワです。
先日、HPE様と開催した共催ウェビナーの内容を記事にまとめました。5分くらいで読めますので、概要やポイントを確認頂き、気になるところがありましたら、ぜひ動画をご確認ください。
※動画は公開後、一定期間が経過しましたら非公開にいたします。
皆さんはアマゾン ウェブ サービス（AWS）のSLAをご存じですか？
AWSでは200近くある各サービスごとにSLAが決められています。※2021年8月現在
「サービスごとのSLAが知りたい」
「SLAのパーセントからダウンタイムを知りたい」
「システムがダウンしたらどうしよう」
こういった疑問をお持ちの方のために、AWSの主要サービスのSLAとダウンタイムの計算方法をご紹介。最後に、万が一障害が起きた場合に備えたおすすめの対策についても解説いたします。
皆さんこんにちは、西下です。本年もよろしくお願いいたします。
今回は2019年のクラウドをめぐる出来事を受けて浮かび上がった課題についてお話したいと思います。
みなさん、こんにちは。東日本のプリセールスの西下です。とても暑い日が続いていますが、体調に気をつけて元気を出していきましょう。
さて、本日はLifeKeeper for Linux v9.2.2からサポートされている「AWSのリージョン間VPCピアリング（Inter region VPC peering）」対応についてご紹介いたします。
LifeKeeper for Linuxは元々AWSのリージョンを跨いだHAクラスター構成を「Cross Region」構成としてサポートしてきました。これは案件において、DR（ディザスターリカバリ）の要件が増加傾向にあり、その対策としてAZ（アベイラビリティゾーン）を跨ぐだけではなく、リージョンを跨ぐHAクラスター構成を取ることで、障害対策における可用性をより固める方式が求められてきた背景があります。
>>Amazon EC2 Cross Region クイックスタートガイド（v9.2.1）※v9.2.2からは廃止
皆さんこんにちは、西下です。
当ブログ記事では、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は対応しています。
よろしければユースケースページと関連ブログもご覧ください。
皆さんこんにちは、西下です。
昨今の自然災害の増加などの背景から、Amazon Web ServicesやMicrosoft Azureといったパブリッククラウド環境で、リージョンを跨いだHAクラスター構成（DR要件）のご要望が増えています。
LifeKeeperは、Amazon EC2環境では既にリージョンを跨いだHAクラスター構成に対応しています。
詳しくは下記のマニュアルをご参照下さい。
上記は、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ノードへ到達します。
※当構成の条件は下記のとおりです。
当機能は「Generic ARK for AWS Transit Gateway」として提供されます。
制御スクリプトと管理ガイドはこちらでご入手頂けます。
→[Linux][Windows]AWSのクロスリージョン環境において仮想IPで通信できる構成をサポート
リージョンを跨いだHAクラスター構成に仮想IPで接続するご要件をお持ちの方は、ぜひお試し下さい。
■参考情報
AWSのユースケースページ（LifeKeeper製品サイト）
■脚注
*2：Recovery Kit for Route53は、クラスターの切り替え時にLifeKeeperからAWS CLIを介してRoute53のAレコードをStandby側の実IPアドレスに書き換える標準機能です。クライアントはホスト名の名前解決をRoute53で行うことで、実IPに向けて通信することでActiveノードへ到達できます。
こんにちは、サイオステクノロジー LifeKeeper 担当の宇野です。
本日は、Amazon EC２のインスタンス上にLifeKeeper for Linux にて構成したHAクラスター環境（クラスターノード）をAWS Elastic Disaster Recoveryを使用してリージョン間レプリケーション、およびリストアを行った手順について紹介させていただきます。
※この記事は翻訳されたものです。本記事の原文はこちら
AWSで可用性の高いSAP HANA環境を構築することは、多くの企業にとって重要です。この記事では、AWSでSIOS LifeKeeperを使用して3ノードのHANAシステムレプリケーション（HSR）クラスターをセットアップし、データベースの回復性と高可用性を確保するための詳細な手順について説明します。
最近では、大規模災害に備え、AZだけではなくリージョンを跨いだ「クロスリージョン構成」のお問い合わせをいただく機会が増えています。当社のHAクラスターソフトウェア「LifeKeeper for Windows /DataKeeper for Windows Cluster Edition」でもAWSリージョン間クラスター構成について、v8.9.1よりサポートを開始しました。LifeKeeper for Linuxではバージョン9.2.2からVPC Peeringによるクロスリージョンをサポートしておりますので、このたびLinuxとWindowsのどちらのモデルでもサポートとなりました。
本記事では、AWSのクロスリージョン構成とシングルリージョン構成（マルチAZ構成）、どちらの構成がどういう場合に適しているのか、LifeKeeper/DataKeeperで実現する場合のメリット・デメリットを交えて比較をしています。AWS上でHAクラスターを導入する場合、どのような構成にするのが最適なのか、ぜひご参考にしていただければと思います。
※この記事は翻訳されたものです。本記事の原文はこちら
Oracleの高可用性（HA）インスタンスを必要とするビジネスクリティカルなアプリケーションのPOC作成を担当する開発者として、私はAWS EC2にOracle EC2 HAクラスターをセットアップする必要があります。何から始めればいいでしょうか？もしあなたが多くの人たちと同じなら、次のタスクをネットで検索したり、記事、インストールガイド、ドキュメント、スタックオーバーフローに関する質問を読んだりして、延々と時間を費やすことになると思います。正解に近い答えはたくさん見つかりますが、それが自分のバージョンや環境にぴったり当てはまることはありません。最悪の場合は、沼にはまってうまくいかない環境を構築し、何日も無駄にすることになってしまいます。
この記事では、DataKeeper、LifeKeeper、SIOS Protection SuiteなどのさまざまなSIOSのHAソリューションを使用して概念実証を開発するためのHA環境のセットアップについて説明します。以下にタスクのリストを示しますので、これらのタスクの実行方法をすでに理解している場合は、そのまま実行してください。各タスクを実行するためのステップバイステップのガイドです。
～LifeKeeperで利用可能なクライアント接続方式とTransit Gatewayにより用いられるルートテーブル方式について～
AWS にシステムの一部を移行して、オンプレミスの既存システムからアクセスして利用したいという要望は大変よく頂きます。AWSにありながら社内システムの一部として利用することは、当社で提供するHAクラスターであるLifeKeeperを導入いただくお客様でも頻繁に利用されている構成です。
そのため、本ブログでは2回にわたりシステムの一部をAWSへのクラウドリフトする方法について解説いたします。今回はAWSクラウド環境で実現すべきクライアント接続方式について解説いたします。
