こんにちは。
サイオステクノロジーの高田です。LifeKeeperのトレーニングを担当しています。
本年8月1日にLifeKeeper for Linux v9.1がリリースされました。
今回は4回に分け、この最新バージョンのLifeKeeper for Linux(以後LifeKeeper)を使って、障害発生時に、オンプレミスで稼働しているシステムをパブリッククラウドのディザスタリカバリ環境へ切り替える方法を検証します。他のバージョンでも同様の構成が可能ですが、これまで検証していない構成のため、新しいバージョンのリリースに合わせて検証してみます。
まずは全体の構成から説明します。
今回 ディザスタリカバリ環境として利用するのは、Amazon Web Service (以後AWS)です。
まず、オンプレミスおよびAWSのPublicのサブネットには、Webサーバーやアプリケーションサーバーを配置します。今回はWordPressを利用したWebサーバーを配置しますが、そこではクラスターソフトウェア(LifeKeeper)を利用しません。
通常運用はオンプレミスのWebサーバーでサービスを提供します。AWS側にはWebサーバーを置かず、それをイメージ化したAmazon マシンイメージ(以後AMI)が存在する状態とします。障害が発生した際には、AMIからサーバーを起動します。
オンプレミスおよびAWSのPrivateのサブネットには、データベースサーバーを配置します。今回はMySQLで、LifeKeeperを利用したクラスター構成とします。クラスター構成で利用する共有の領域は、DataKeeper for Linux (以後DataKeeper)でミラーリングします。
オンプレミスとAWSのprivateサブネット上に配置しているデータベースサーバー間の通信は、IPsecVPNで、オンプレミス側のルーターとしてYamahaのRTX1200を利用します。AWSでは専用線接続(AWS Direct Connect)も利用できますが、今回は既存のルーターを使用して検証してみます。
各サブネットのCIDRやサーバーのIPアドレスは、以下のようにしています。
作業開始時点では、オンプレミス側のサーバーが2台配置されているのみです。始めにAWSでのVPCおよび仮想プライベートゲートウェイの設定を行います。こちらの設定については、次回記事でご紹介します。
>> [Linux] DynamicDR（オンプレto AWS ディザスタリカバリ環境）の実現（第2回）～VPN構築とサーバーの配置 を読む
