みなさんこんにちは。東日本担当のプリセールスの西下（にしした）です。
前回のブログではAmazon EC2向けのLinux版のLifeKeeperによるHAクラスタ構成の1つの「ルートテーブルシナリオ」の仕組みをご紹介しました。今回からは実際の構築手順を3回に分けてご紹介します。できるだけ最小限の手順で構成しました。
・ 実際の構築手順（AWSの設定編） ←今回
・ 実際の構築手順（LifeKeeperの設定編）
・ 実際の構築手順（保護対象のソフトウェアの設定編）
記事の最後に、クラウド環境の要件に合わせた解決策を解説する資料や、AWS EC2環境でのHAクラスタ構築手順書などのダウンロード、LifeKeeper評価版のご案内がありますので是非ご活用ください。
手順はこの通り行わければならないものではありませんので参考としてご覧ください。また、内容を参考にされた結果生じたいかなる損害も当社は責任を負いませんので、事前に十分な動作検証をお願いします。 |
Contents
Amazon EC2の構成
今回は下記の構成を前提に構築します。NATインスタンスなどのAWSの構成要素は前回の記事をご参照下さい。
クラスタノードのNode1およびNode2にはHAクラスタソフトのLinux版のLifeKeeperとDataKeeper、そして今回の保護対象のソフトウェアのPostgreSQLが入ります。
各サブネットおよびインスタンスの設定は各手順で記載します。
AWSでの作業の主な手順
今回は下記の手順で行います。
- VPC の作成
- インターネットゲートウェイ（IGW）の作成と VPC へのアタッチ
- サブネットの作成（複数 AZ の選択）
- ルーティング設定（その1）
- セキュリティグループの作成
- キーペアの作成
- インスタンス作成
- 送信元 送信先の変更チェックの無効化
- ルーティング設定（その2）
- インスタンスへの接続
1. VPC の作成
AWSで環境を構築する際にはAWSクラウドの論理的に分離されたセクションであるVPCの作成から作業を始めます。VPCの作成は簡単です。
まず、AWSのマネージメントコンソールにログインします。
画面右上のリージョンの選択肢で、「アジアパシフィック（東京）」以外になっている場合は「アジアパシフィック（東京）」に変更します。
サービスをクリックし、右側のペインからVPCを選択します。
VPCダッシュボードから[VPC]を選択
[VPCの作成]を選択
名前タグに任意の文言を指定します。今回は「VPC-yattemiyo」とします。
CIDRには今回は「10.0.0.0/16」と入力します。
[はい、作成する]をクリックします。
すぐに下記のようなVPCができます。
以上でVPCの作成は終了です。
2. インターネットゲートウェイ（IGW）の作成と VPC へのアタッチ
VPCを作っただけでは外部からアクセスできません。そこでVPCの外部からVPCにアクセスできるように、インターネットとの相互通信を可能にする「インターネットゲートウェイ（IGW）」を作成して、それをVPCにアタッチします。
画面左のVPCダッシュボードから「インターネットゲートウェイ」を選択し、続けて「インターネットゲートウェイの作成」をクリック。
名前タグに任意の名前をつけます。今回は「IGW-yattemiyo」としました。
今作成したインターネットゲートウェイが選択されていることを確認して、「VPCにアタッチ」をクリック。
[VPCにアタッチ]のポップアップが表示されるので先程作成したVPCが選択されていることを確認して「はい、アタッチする」をクリックします。
作成したインターネットゲートウェイの状態が「attached」になっていることを確認します。
以上で、インターネットゲートウェイ（IGW）の作成と VPC へのアタッチの手順は終了です。
3. サブネットの作成（複数 AZ の選択）
続いて各インスタンスが配置されるサブネットを作成します。
VPCダッシュボードから「サブネット」を選択し、「サブネットの作成」をクリックします。
[名前タグ]に任意の名称（今回は「SUB-yattemiyo-A1」としました）を入力します。
[VPC]のドロップダウンメニューから先程用意したVPC（今回はVPC-yattemiyo）を選択します。
[アベイラビリティーゾーン]は「ap-northeast-1a」を指定します。
[VPC CIDR]には「10.0.1.0/24」を設定します。
[はい、作成する]ボタンをクリックします。
上記の操作を合計4回行います。
設定値は下記をご参考下さい。
名前タグ | サブネット | AZ（アベイラビリティーゾーン） |
SUB-yattemiyo-A1 | 10.0.1.0/24 | ap-northeast-1a |
SUB-yattemiyo-A2 | 10.0.2.0/24 | ap-northeast-1a |
SUB-yattemiyo-C1 | 10.0.3.0/24 | ap-northeast-1c |
SUB-yattemiyo-C2 | 10.0.4.0/24 | ap-northeast-1c |
以上でサブネットの設定は終了です。
4. ルーティング設定およびセキュリティグループの作成 ※重要※
今回の構成ではサブネットを跨いだトラフィックが行われます。これらのトラフィックは、AWSの基本機能のルートテーブルで制御されます。
ここの設定は間違えやすく、間違いにすぐに気づかないことが多いので、注意を払って下さい。
各ルートテーブルの役割は下記のとおりです。（合わせて前回の記事もご参考下さい）
1)10.0.1.0/24 および 10.0.3.0/24 のルートテーブル
名前タグ：RT-yattemiyo-A1C1
接続先 | ターゲット | 注記 |
10.0.0.0/0 | ローカル | デフォルトで定義されている |
0.0.0.0/0 | インターネットゲートウェイ | インターネット接続するためにパブリックなElastic IPを割り当てる。 |
2)10.0.2.0/24のルートテーブル
名前タグ：RT-yattemiyo-A2
接続先 | ターゲット | 注記 |
10.0.0.0/0 | ローカル | デフォルトで定義されている |
10.1.0.10/32 | Node1（10.0.2.4）のENI（eth0）のIDを暫定的に指定 | Recovery Kit for EC2™によりActiveノードのENIへの紐付けに更新される |
0.0.0.0/0 | NAT1（10.0.1.4）のENI（eth0）を指定 | 一旦NATを経由してインターネットへ接続 |
3)10.0.4.0/24のルートテーブル
名前タグ：RT-yattemiyo-C2
接続先 | ターゲット | 注記 |
10.0.0.0/0 | ローカル | デフォルトで定義されている |
10.1.0.10/32 | Node1（10.0.2.4）のENI（eth0）のIDを暫定的に指定 | Recovery Kit for EC2™によりActiveノードのENIへの紐付けに更新される |
0.0.0.0/0 | NAT2（10.0.3.4）のENI（eth0）を指定 | 一旦NATを経由してインターネットへ接続 |
まずサブネットSUB-yattemiyo-A1およびSUB-yattemiyo-A2用のルートテーブルを作成します。
VPCダッシュボードから「ルートテーブル」を選択し、「ルートテーブルの作成」をクリックします。
名前タグには「RT-yattemiyo-A1C1」を指定し、[はい、作成する]をクリックします。
今作成したルートテーブルを選択した状態で、画面下部の[ルート]タブを選択します。
下部ペインには選択されているルートテーブルに関連付いた情報が表示されています。
初期状態では下記の画面になっているのを確認して[編集]をクリックします。
送信先の「10.0.0.0/16」はローカルルートと呼ばれるものです。管轄のサブネット内で10.0.x.xのIPアドレスが指定された場合はVPC内の通信を可能にします。
これにもう1つ送信先として先程作成したインターネットゲートウェイ（0.0.0.0/0）を追加します。
追加するには[別のルートテーブルを追加]をクリックします。
2行目に「0.0.0.0/0」を選択すると、ターゲット欄には入力候補で先程作成したインターネットゲートウェイが表示されるので選択して[保存]をクリックします。※ここで[保存]を押し忘れやすいので注意して下さい。
[サブネットの関連付け]タブをクリックし[編集]をクリックします。
関連付けるサブネット2つを選択して[保存]をクリックします。当ケースでは「SUB-yattemiyo-A1」と「SUB-yattemiyo-C1」を選択します。
保存が無事終了すると下記の画面が表示されます。
残りのルートテーブルは、先にインスタンス（NATインスタンスとクラスタインスタンス）が必要なので、先に各インスタンスを作成してから改めて2)と3)作成します。
サブネットの作成（複数 AZ の選択）は一旦終了です。
5. セキュリティグループの作成
VPC内の各種トラフィックを制御するには「セキュリティグループ」を設定しておく必要があります。各インスタンスからはセキュリティグループを指定することで、セキュリティに関する設定を行います。
VPCダッシュボードから[セキュリティグループ]を選択して[セキュリティグループの作成]をクリックします。
[名前タグ]には今回は「SG-yattemiyo」を設定します。
[説明]は空欄ではエラーが出るので適宜入力します。
[VPC]は先程作成したものを選択します。
[はい、作成する]をクリックします。
作成したセキュリティグループを選択して、下部のペインの[インバウンドルール]タブを選択して[編集]をクリックします。
タイプに「すべてのトラフィック」、ソースに「0.0.0.0/0」を設定して[保存]をクリックします。
続いて[アウトバウンドルール]タブで[編集]をクリックします。
タイプに「すべてのトラフィック」、送信先に「0.0.0.0/0」になっていることを確認して[保存]をクリックします。
セキュリティグループの作成は以上で終了です。
6. キーペアの作成
この後作成するEC2の仮想インスタンスへの接続は公開鍵認証になります。
そこで認証に必要になる「秘密鍵」をこの手順で作成します。
サービスをクリックし、右側のペインからEC2を選択します。
EC2ダッシュボードから[キーペア]を選択し、[キーペアの作成]をクリックします。
[キーペアの作成]ダイアログボックスにキーペア名欄に任意のキーペア名を入力して[作成]をクリックします。この例では「KEYP-yattemiyo」と入力しています。
作成したキーは自動的にダウンロードされます。（*.pemというファイル名になります。）このキーはこれからの手順で何度も使うので、大切に保管して下さい。
キーペアの作成手順は以上で完了です。
7. インスタンス作成
このセクションではいよいよ各インスタンスを作成します。
まず始めに設定内容をまとめて記載します。
インスタンス名 | サブネット | IPアドレス | タグ | 用途 |
NAT1 | SUB-yattemiyo-A1 | 10.0.1.4 | NAT1-yattemiyo | 中継用のNATインスタンス |
NAT2 | SUB-yattemiyo-C1 | 10.0.3.4 | NAT2-yattemiyo | 中継用のNATインスタンス |
Node1 | SUB-yattemiyo-A2 | 10.0.2.4 | Node1-yattemiyo | クラスタノード |
Node2 | SUB-yattemiyo-C2 | 10.0.4.4 | Node2-yattemiyo | クラスタノード |
Client1 | SUB-yattemiyo-A2 | 10.0.2.5 | Client1-yattemiyo | クライアント |
Client2 | SUB-yattemiyo-C2 | 10.0.4.5 | Client2-yattemiyo | クライアント |
Windows | SUB-yattemiyo-C1 | 10.0.1.10 | Win-yattemiyo | GUI操作用の踏み台サーバー |
まずはLifeKeeperおよびPostgreSQLをインストールする先の仮想インスタンスの「Node1」と「Node2」を作成します。
EC2ダッシュボードの[インスタンス]を選択し、[インスタンスの作成]をクリックします。
[1.AMIの選択]画面でRed Hat Enterprise Linux 7.4 (HVM), SSD Volume Typeを選択します。
なお、最新のLifeKeeper for LinuxのOSや保護対象のソフトウェアのバージョン要件については下記をご確認下さい。
→[サポートマトリックス] ※「SIOS Protection Suite for Linux サポートマトリックス」をクリック
[2.インスタンスタイプの選択]画面でインスタンスタイプを選択します。ここでは無料利用枠の「t2.micro」を選択します。
今回は使いませんが、Oracleのように大きなメモリーサイズを必要とする場合は、適切なインスタンスタイプを選択して下さい。
[確認と作成]ではなく、[次の手順：インスタンスの詳細の設定]をクリックします。
[3.インスタンスの設定]画面では、[ネットワーク]には先程設定したVPCを設定します。
[サブネット]には「SUB-yattemiyo-A2」サブネットを選択します。
[自動割当パブリックIP]には「サブネット設定を使用（無効）」が有効になっていることを確認します。この設定が意味する所はクラスタノードは直接インターネットへつながっている必要はないので、パブリックIPを無効とする設定を行います。このような設定でセキュリティを高めています。
画面下部の[ネットワークインターフェイス]には、eth0のデフォルト設定が表示されています。
LifeKeeperをインストールするクラスタノードはIPアドレスを固定にしておく必要があります。
EC2のデフォルトである自動割当は無効にしておき、更に[プライマリIP]を「10.0.2.4」に指定します。
[4.ストレージの追加]画面で[新しいボリュームの追加]をクリックして、DBのインストール先として8GBのボリュームを追加し、[次の手順：Add Tags]をクリックします。
[5.タグの追加]画面で[タグの追加]をクリックして、[キー]に「Name」、[値]にインスタンス名を入力することでEC2インスタンスの一覧画面で表示されるようになります。
今回は「Node1-yattemiyo」とします。
[次の手順：セキュリティグループの設定]をクリックします。
[6.セキュリティグループの設定]画面で先程作成したセキュリティグループを選択し、[セキュリティグループの割当]で「既存のセキュリティグループを選択する」を選択します。
[確認と作成]をクリックします。
[ステップ 7: インスタンス作成の確認]で設定内容を確認し、問題なければ[作成]をクリックします。
[既存のキーペアを選択するか、新しいキーペアを作成します。]のポップアップが表示されるので、[既存のキーペアの選択]と先程作成したキーペアが表示されていることを確認し、チェックボックスへチェックをして[インスタンスの作成]をクリックします。
続いてNode2についても同様に仮想インスタンスを作成します。設定内容についてはこのセクション冒頭の表を参照して下さい。
続いてクライアント（Client1およびClient2）を作成します。
クライアントの設定は、基本的にはNode1およびNode2と同じ設定にしますが、Node1およびNode2との設定との相違点は下記です。
・[3.インスタンスの設定]画面では、[自動割当パブリックIP]を「有効」にします。
・[4.ストレージの追加]画面では追加ストレージは不要。デフォルトのまま。
続いて、NATインスタンス（NAT1およびNAT2）を作成します。
今回はRHEL7.4のAMIではなく、コミュニティAMIからNAT用のAMI「amzn-ami-vpc-nat-hvm-2016.09.0.20161028-x86_64-ebs (ami-863b6391)」を選択して使用します。
[コミュニティAMI]の画面で「amzn-ami-vpc-nat-hvm-2016.09.0.20161028-x86_64-ebs」で検索すると良いでしょう。
作成はNAT1とNAT2の両方に対して行います。
Node1およびNode2との設定との相違点は下記です。
・[3.インスタンスの設定]画面では、[自動割当パブリックIP]を「有効」にします。
・[4.ストレージの追加]画面では追加ストレージは不要。デフォルトのまま。
最後にWindows踏み台サーバーは、「Microsoft Windows Server 2012 R2 Base – ami-7dcb701b」を選択します。
Node1およびNode2との設定との相違点は下記です。
・[3.インスタンスの設定]画面では、[自動割当パブリックIP]を「有効」にします。
・[4.ストレージの追加]画面では追加ストレージは不要。デフォルトのまま。
以上でインスタンスの作成は終了ですが、必ず下記の処理を追加で行って下さい。
8. 送信元 送信先の変更チェックの無効化 ※忘れやすいので重要※
インスタンスの作成が完了したら、全てのインスタンスで送信元/送信先の変更チェックを無効化します。この手順を怠ると NAT インスタンスへのリダイレクト、VIP への疎通が出来ません。
EC2ダッシュボードの[インスタンス]を選択して仮想インスタンスの一覧を表示します。各インスタンスの右クリックメニューで[ネットワーキング]→[送信元/送信先の変更チェック]を選択します。
※この操作は複数のインスタンスをまとめて行うことは出来ません。チェックボックスが全てOFFになっている状態で行って下さい。
すると下記のポップアップ画面が出るので、「はい、無効化する」をクリックします。
これを全ての7つの仮想インスタンスに対して行います。
9. ルーティング設定（その2）
前項の④で中断していたサブネット10.0.2.0/24および10.0.4.0/24のルートテーブルの設定を再開します。前項⑧でインスタンスを作成したことで、ENIのIDの情報を取得できます。
操作は④と同じです。VPCダッシュボードから[ルートテーブル]を選択して必要事項を設定します。
設定値は④の冒頭の表を参考にして下さい。
ルートテーブル設定時は下記の画面になるはずですが、3行目のダミーの仮想IPの「10.10.0.10/32」のターゲットの値は入力補助が働かないので手作業が必要です。
ターゲットの値は、対象となるNode1のEC2のインスンスの詳細画面の中の[ネットワークインターフェース]＞[eth0]を選択して、ポップアップの[インターフェイス ID]の値をコピペするなどして取得して下さい。（どちらのサブネットのルートテーブルの設定も、Node1のインターフェイスIDを指すようにします。）
ルートテーブルの設定は以上で終了です。
10. インスタンスへの接続
Recovery Kit for EC2™のルートテーブルシナリオでは、意図的にクラスタノードおよびクライアントに対してインターネット経由で直接アクセスができない構成にしてあります。そのためこれらのサーバーにアクセスするために一旦VPC内に踏み台のWindowsサーバーを用意してあります。この踏み台のWindowsサーバーはインターネット経由でアクセスできるため、以降の作業はこの踏み台のWindowsサーバー上の作業を中心に行います。
今回はNode1などのLinuxのEC2インスタンスへのアクセスをリモートログオンクライアントの「puTTY」を使っています。その他、踏み台のWindowsサーバーからクラスタノードにファイルを転送するツールとして「WinSCP」を使っています。
まずpuTTYをローカルのWindowsPC(AWSへの接続に使うコンピュータ)にインストールします。インストールの詳細は下記をご参照下さい。インストールは全てデフォルトで構いません。
→[外部サイト：PuTTY を使用した Windows から Linux インスタンスへの接続]
この後の手順で踏み台のWindowsサーバーでpuTTYを使う準備として、前項⑥で作成したキーペア（*.pemファイル）をpuTTYで認識できる形に変換します。変換にはpuTTYの一機能である「puTTYgen」を使います。（puTTYと一緒にインストールされます）
WindowsPC上でpuTTYgenを起動します。
続いて[Type of key to generate] で[SSH-2 RSA]を選択します。
[Load] をクリックします。デフォルトでは、PuTTYgen には拡張子「*.ppk」を持つファイルだけが表示されます。「*.pem」ファイルの場所を特定するには、[すべてのタイプのファイルを表示する]オプションを選択します。
ファイル一覧から作成してあったキーペアファイル（*.pem）を選択します。
次の確認ダイアログボックスで[OK]をクリックします。これでキーペアファイルの読み込みが成功しました。
[Save private key] をクリックして、PuTTY が使用できる形式でキーを保存します。
警告文を確認して[はい]をクリックします。
任意のファイル名（*.ppk）で保存します。
キーペアの変換の手順は以上です。
次は、踏み台のWindowsサーバーにリモートデスクトップで接続します。
対象のインスタンスを選択して[接続]をクリックします。
[インスタンスへの接続]ダイアログが表示されます。最初にパスワード取得をクリックします。
[ファイルを選択]をクリックして、作成済みのキーペア（*.pem）を指定します。
キーペアを指定すると画面中央部に内容が表示されるので[パスワードの復号]をクリックします。
すると下記のようにパスワードが表示されるので、メモなど取っておいて下さい。
続けて[リモートデスクトップファイルのダウンロード]をクリックすると、踏み台のWindowsサーバー用のリモートデスクトップファイルがダウンロードされます。以降はこのファイルを実行すると、踏み台のWindowsサーバーへのリモートアクセスができます。
早速ダウンロードしたリモートデスクトップファイル（*.rdp）のアイコンをダブルクリックして実行します。途中出る認証と確認進めると、踏み台のWindowsサーバーのリモートデスクトップ画面が表示されます。
今後インストールに必要なファイルを踏み台サーバーの適当なフォルダにコピーしておきます。
コピーはローカルのWindowsPCからマウスの右クリック[コピー][ペースト]で行えます。（ドラッグアンドドロップはできません）
・puTTY
・WinSCP
・Xming
・プライベートキーファイル ppk
・LifeKeeper for Linuxのインストールイメージ（ISOファイル）
・LifeKeeper for Linuxの評価ライセンス（txtファイル）
※なお、評価ライセンスの入手方法は末尾をご参照下さい。
先程と同様に踏み台サーバー上でpuTTYをインストールします。（もう既に変換済みのppkファイルはあるのでpuTTYgenは使いません）
PuTTYを起動します。
例えばNode1に接続する場合は、[Session]画面の[Host Name]に下記のように入力します。
ec2-user@10.0.2.4
[Connection]＞[SSH]＞[Auth]の[Authentication parameters]の[Private key file for authentication:]に先程ローカルPCからコピーしたプライベートキーファイル（ppk）を指定します。
[Connection]>[SSH]>[X11]にて、[X11 formwarding]にチェックを入れて有効にします。
ここまで設定した内容は、下記のように[Save]しておくと良いでしょう。
[Open]をクリックすると下記のようにコンソールが表示されます。
続いてWinSCPを踏み台サーバーにインストールします。
https://winscp.net/eng/download.php にアクセスしてWinSCPをダウンロードします。
インストールは全てデフォルトで構いません。
インストール完了直前に下記の確認画面が出てきますが、[No]を選択します。
ログイン画面では、[Host Name]と[User Name]にそれぞれ記載します。
Password欄には何も書きません。
[Advanced]>[Advanced…]を開きます。
[SSH]＞[Authentication]を選択します。
[Authentication Parameters]の[Private Key File]にて、既に保存されている秘密鍵（*.ppkファイル）を選択して[OK]をクリックします。
ログイン画面で[ログイン]をクリックします。
ログインに成功すれば下記のような画面が表示され、WinSCPを使えます。
LifeKeeper for Linuxでは大半の操作をGUI上で行います。そこでX Windowを踏み台サーバーにフォワードして使うために、XサーバーのXmingを踏み台サーバーにストールします。これにより、クラスタノード上でLifeKeeperのGUIアプリを起動すると、そのGUIアプリを踏み台サーバーのデスクトップ上で使えるようになります。
Xmingは下記から入手できます。
https://ja.osdn.net/projects/sfnet_xming/releases/
インストール手順はデフォルトで構いません。
インストールが終わると、Xlaunchを起動します。ここでも設定のウイザードは全てデフォルトで構いません。
以上で接続準備は完了です。
次回からはいよいよLifeKeeperのインストールを行います。お楽しみに。
資料ダウンロード
クラウド環境の要件に合わせた解決策を解説する資料や、AWS EC2環境でのHAクラスタ構築手順書などをご用意しています。一度のフォーム入力で各種ダウンロードしていただけます。
1. クラウド環境で可用性要件が出てきたら読む資料
2. AmazonEC2環境でのHAクラスター構成パターン
3.【Linux】AWS EC2環境でのHAクラスター構築 Step by Step ガイド【ルートテーブルシナリオ編】
4.【Linux】AWS EC2環境でのHAクラスター構築 Step by Step ガイド【AWS Route 53編】
5.【Windows】AWS EC2環境でのHAクラスター構築 Step by Step ガイド【ルートテーブルシナリオ編】
6.【Windows】AWS EC2環境でのHAクラスター構築 Step by Step ガイド【AWS Route 53編】
7.【Windows】AWS EC2上でSQL Serverを冗長化するためのクイックスタートガイド
8.【Linux】AWS EC2環境でのHAクラスター構築ガイド
評価版
ご評価版は下記からお申し込みいただけます。30日間無償でご検証いただけます。
※評価版のご使用にあたっては、十分に規約をご確認の上ご活用願います。
当記事の内容は全て公開日時点での当社独自見解となりますので、製品選定時のご参考に用途を限定し、二次配布や資料の改変はご遠慮願います。 内容を参考にされた結果生じたいかなる損害も当社は責任を負いませんので、事前に十分な動作検証をお願いします。 |
<<前回の記事に戻る
