ルートテーブルシナリオの実際の構築手順(LifeKeeperの設定編)

    はじめに

    みなさんこんにちは。東日本担当のプリセールスの西下(にしした)です。

    前回のブログ記事ではAmazon EC2向けのLinux版のLifeKeeperによるHAクラスター構成の1つの「ルートテーブルシナリオ」の準備としてAWS側の設定手順をご紹介し、インスタンスを作成し踏み台のWindowsサーバーの接続の手順まで進めました。

    今回はいよいよLifeKeeperの導入および設定手順をご紹介します。できるだけ最小限の手順で構成しました。

    実際の構築手順(AWSの設定編)

    ・ 実際の構築手順(LifeKeeperの設定編) ←今回

    ・ 実際の構築手順(保護対象のソフトウェアの設定編)

    手順はこの通り行わければならないものではありませんので参考としてご覧ください。また、内容を参考にされた結果生じたいかなる損害も当社は責任を負いませんので、事前に十分な動作検証をお願いします。

    Amazon EC2の構成(再掲)

    今回は下記の構成を前提に構築手順を進めています。NATインスタンスなどのAWSの構成要素は下記の第2回の記事をご参照下さい。

    ※よりシンプルにするために、サブネットC2のクライアントは省略してあります。

    AmazonEC2構成

    LifeKeeperのインストール作業の主な手順

    今回は下記の手順で行います。

    • インストールの準備
    • LifeKeeperのインストール
    • LifeKeeperの設定
      1. GUI管理画面の起動とログイン
      2. コミュニケーションパスの作成
      3. IPリソースの作成
      4. AWS ECCリソース(EC2™リソース)の作成
      5. DataKeeperリソースの作成

    各手順

    以降の手順は断りがない限り踏み台のWindowsサーバーから行います。

    インストールの準備 ※Node1およびNode2の両方で必要

    踏み台のWindowsサーバーにRDPで接続します。具体的な手順は前回記事の「10.インスタンスへの接続」をご参照下さい。

    image3

    WinSCPでクラスターノードのNode1とNode2の両方に下記をコピーしておきます。コピー先はデフォルトだと/home/ec2-userになります。

    ・LifeKeeper for Linuxのインストールイメージ(ISOファイル)

    ・LifeKeeper for Linuxの評価ライセンス(txtファイル)

    image4

    PuTTYでNode1およびNode2に接続します。

    image5

    以降の作業はNode1とNode2の双方に対して行います。

     

    まず先程WinSCPでNode1に転送した2つのファイルが無事存在することを確認します。

    今回ライセンスファイルは「Linux_evalkeys-90day.txt」、インストールイメージは「sps_920.img」としました。

    [ec2-user@ip-10-0-2-4 ~]$ ls
    Linux_evalkeys-90day.txt  sps_920.img

    続いて適当なURL(例ではgoogle)へpingをしてインターネットに疎通できることを確認します。下記のように即応答が返ってくれば成功です。

    [ec2-user@ip-10-0-2-4 ~]$ ping google.com
    PING google.com (216.58.197.238) 56(84) bytes of data.
    64 bytes from nrt13s49-in-f238.1e100.net (216.58.197.238): icmp_seq=1 ttl=48 time=1.93 ms
    64 bytes from nrt13s49-in-f238.1e100.net (216.58.197.238): icmp_seq=2 ttl=48 time=2.07 ms

    しかしながら、下記のように応答が返ってこない場合があります。

    [ec2-user@ip-10-0-2-4 ~]$ ping google.com
    PING google.com (216.58.197.238) 56(84) bytes of data.
    (ここから進まない)

    この場合は恐らく次の2つの内のどちらかに問題があるはずなので確認して下さい。特に後者は私も何度か経験しました。

    ・該当するNATインスタンスが起動していない(Node1の場合はNAT1)。

    ・NATインスタンスまたはクラスターノードのインスタンスにおいて、[送信元/送信先の変更チェック]が「False(無効)」になっていない。(デフォルトは「True(有効)」)→前回記事の「8.送信元 送信先の変更チェックの無効化」をご参照下さい。

    インターネットに無事疎通できることが確認できれば、下記の通りyumを使ってX11をインストールします。EC2上でyumによるオンラインアップデートを行う場合は、インターネットに疎通できることが前提となります。

    [ec2-user@ip-10-0-2-4 ~]$ sudo yum groupinstall “x11”

    X11のインストールが完了したらLinuxの動作モード(ランレベル)を下記のコマンドでGUIにします。

    [ec2-user@ip-10-0-2-4 ~]$ sudo systemctl set-default graphical.target

    RHEL7 でLifeKeeperをインストールする場合、redhat-lsb が必須パッケージになるので、yumでインストールしておきます。

    [ec2-user@ip-10-0-2-4 ~]$ sudo yum install redhat-lsb

    LifeKeeper for Linuxでは各ノードをホスト名で参照します。そのため/etc/hostsファイルに両クラスターノードのIPアドレスとホスト名を登録します(下記の赤字箇所)。編集はvi等を適宜お使い下さい。

    [ec2-user@ip-10-0-2-4 ~]$ cat /etc/hosts
    127.0.0.1 localhost localhost.localdomain localhost4 localhost4.localdomain4
    ::1    localhost localhost.localdomain localhost6 localhost6.localdomain6
    10.0.2.4 ip-10-0-2-4.ap-northeast-1.compute.internal
    10.0.4.4 ip-10-0-4-4.ap-northeast-1.compute.internal

    続いてSELinuxの無効化を行います。LifeKeeper for LinuxはSELinuxをサポートしていないため、導入に際してSELinuxを無効にしていただく必要があります。

    まず状態を確認します。下記の通り有効になっています。

    [ec2-user@ip-10-0-2-4 ~]$ sudo getenforce
    Enforcing

     

    有効になっている設定を無効化します。

    [ec2-user@ip-10-0-2-4 ~]$ sudo setenforce 0

    以降恒久的にSELinuxを無効にするように/etc/selinux/configを編集します。(vi等で編集していただいても構いません)

    [ec2-user@ip-10-0-2-4 ~]$ sudo sed -i -e ‘s/enforcing/disabled/g’ /etc/selinux/config

    続いてファイアウォールの無効化を行います。

    まず下記のコマンドで現在のファイアウォールの有効/無効を確認します。

    [ec2-user@ip-10-0-2-4 ~]$ sudo systemctl status firewalld
    ● firewalld.service – firewalld – dynamic firewall daemon
       Loaded: loaded (/usr/lib/systemd/system/firewalld.service; enabled; vendor preset: enabled)
       Active: inactive (dead)
         Docs: man:firewalld(1)

    上記の通り有効(「Loaded」)になっているのでこれを無効(「Disable」)に設定します。

    [ec2-user@ip-10-0-2-4 ~]$ sudo systemctl disable firewalld.service
    Removed symlink /etc/systemd/system/multi-user.target.wants/firewalld.service.
    Removed symlink /etc/systemd/system/dbus-org.fedoraproject.FirewallD1.service.

    ここまでの作業を行い、一旦仮想インスタンスを再起動します。

    ここからは権限上rootユーザーで行います。

    [ec2-user@ip-10-0-2-4 ~]$ sudo su –

    LifeKeeper のインストールでは rootのパスワードが必要となるため、rootのパスワードを設定します。

    [root@ip-10-0-2-4 ~]# passwd
    Changing password for user root.
    New password:(新しいパスワード)
    Retype new password: (新しいパスワード)
    passwd: all authentication tokens updated successfully.

    LifeKeeperのインストールの準備は以上で完了です。

    ここまでの作業をNode2に対しても行います。

    LifeKeeperのインストール ※Node1およびNode2の両方で必要

    ここからはrootでLifeKeeper for Linuxのインストールを行います。詳細については下記のユーザーサイトで公開されているスタートアップガイドをご参照下さい。

    →[ユーザーサイト:スタートアップガイドの検索結果(該当するバージョンをお選び下さい)]

    まず既に踏み台のWindowsサーバーからコピーしておいたLifeKeeperをインストールするために、

    インストールイメージファイル(下記の例では「sps_920.img」)を/mntにマウントしてsetupを実行します。

    [root@ip-10-0-2-4 ec2-user]# mount sps_920.img -t iso9660 -o loop,ro /mnt
    [root@ip-10-0-2-4 ec2-user]# cd /mnt
    [root@ip-10-0-2-4 mnt]# ./setup

    ここからはウイザードの操作になります。大半の項目はそのまま[Enter]を押して進めます。

    [Enter]でインストールを開始します。

    image6

    LifeKeeper の基本パッケージのインストールです。[Enter]を押してください。

    image7

    [Enter]を押します。

    image8

    Java パッケージのインストール。Enter キーを押してください。

    image9

    [Enter]を押します。

    image10

    DataKeeper 用のカーネルモジュールのインストール。[Enter]キーを押してください。

    image11

    [Enter]を押します。

    image12

    NFS ユーティリティパッケージのインストール。Enter キーを押してください。

    image13

    NFS サービスの再起動。Enter キーを押してください。

    image14

    [Enter]を押します。

    image15

    必須パッケージのインストール。Enter キーを押してください。

    image16

    [Enter]を押します。

    image17

    コア(本体)パッケージのインストール。Enter キーを押してください。

    image18

    [Enter]を押します。

    image19

    グループとログインユーザの設定。Enter キーを押してください。

    image20

    [Enter]を押します。

    image21

    ライセンスキーインストールの確認です。ここではインストールしないので[Enter]を押してください。(この後Recovery Kit for EC2™のインストール時に行います。)

    image22

    インストールするオプション・リカバリキットの選択画面です。今回はlkDR(DataKeeper)とlkPGSQL(PsotgreSQL)を選択します。

    image23

    インストールするパッケージの確認画面が表示されます。[Enter]を押してください。

    image24

    パッケージのインストールに成功すると下記の画面が出るので[Enter]を押して下さい。

    image25

    以上でsetupスクリプトによるインストールが完了しました。[Enter]を押して完了させてください。

    image26

    Recovery Kit for EC2™のインストール

    続いてRecovery Kit for EC2™をインストールします。

    Recovery Kit for EC2™については上記のsetupスクリプトの中ではインストールされないため、下記のようにrpmコマンドで個別にインストールします。Recovery Kit for EC2™は、先程マウントした/mnt配下のamazonディレクトリの中にあります。

    [root@ip-10-0-2-4 mnt]# cd /mnt/amazon/
    [root@ip-10-0-2-4 amazon]# ls
    steeleye-lkECC-9.2.0-6629.noarch.rpm
    steeleye-lkOPENSWAN-9.2.0-6629.noarch.rpm
    steeleye-lkROUTE53-9.2.0-6629.noarch.rpm
    TRANS.TBL

    上記の内「steeleye-lkECC-9.2.0-6629.noarch.rpm」を使います。ファイル名の内「9.2.0-6629」は使用するLifeKeeperのバージョンにより異なるので、適宜読み替えて下さい。

     

    rpmコマンドでインストールします。

    [root@ip-10-0-2-4 amazon]# rpm -Uvh steeleye-lkECC-9.2.0-6629.noarch.rpm
    Preparing…                         
    ################################# [100%]
    Updating / installing…
       1:steeleye-lkECC-9.2.0-6629       
    ################################# [100%]

    lkkeyinsコマンドを使ってライセンスキーのインストールを行います。

    [root@ip-10-0-2-4 amazon]# cd /home/ec2-user/
    [root@ip-10-0-2-4 ec2-user]# ls
    Linux_evalkeys-90day.txt  sps_920.img  yattemiyo.ppk
    [root@ip-10-0-2-4 ec2-user]# /opt/LifeKeeper/bin/lkkeyins Linux_evalkeys-90day.txt
    LifeKeeper license key installation was successful!

    LifeKeeperのIPリソースでは、ブロードキャストpingを使いクラスター外部との疎通確認を行うことで仮想IPアドレスの監視処理を行っています。しかしAmazon EC2上ではAZ(Availability Zone)を跨いだHAクラスター構成となり、サブネットも跨いだ構成となります。このため、ブロードキャストpingでの疎通確認は行えない為この設定を無効化しておきます。

    [root@ip-10-0-2-4 ec2-user]# sed -i -e ‘s/NOBCASTPING=0/NOBCASTPING=1/g’ /etc/default/LifeKeeper

    LifeKeeperのインストール作業は以上で完了です。

    ここまでの作業をNode2に対しても行います。

    LifeKeeperの設定

    以降の手順はLifeKeeperのGUI管理画面を使います。但しEC2はネットワーク経由でしか操作できないため、モニタへ直接アクセスできません。このため、OSに関わらずGUIアクセスするにはリモート接続が必要です。

    LifeKeeperの設定は直感的なGUI(X Window System)で行うため、クライアント(踏み台のWindowsサーバー)側にもXサーバーが必要となります。今回はWindowsの踏み台サーバー上にXサーバーをXmingで用意し、そのXmingに対して仮想インスタンス(Node1または2)からXをフォワードします。

    踏み台のWindowsサーバーには既に下記の2点がここまでの手順で設定されているはずなので、改めて確認して下さい。

    1.puTTYのSSHの設定で[enable X11 forwarding]を有効にしていること

    2.XmingのインストールおよびLaunchしていること

    上記の構成を使うにあたり、まずは下記の2つの環境変数について、「ec2-userでログインした時の内容」を、「rootでログインした時の内容」に対して反映する必要があります。

    1.環境変数$DISPLAYの値

    2.xauthのディスプレイ名

    上記1.の環境変数$DISPLAYの値は下記のコマンドで確認します。

    ※この値は、踏み台のWindowsサーバーからpuTTYでSSH接続する度に変更します。

    [ec2-user@ip-10-0-2-4 ~]$ echo $DISPLAY
    localhost:11.0

    上記2.のxauthのディスプレイ名は下記のコマンドで確認します。(後で使うのでクリップボードに貼り付けておきます)

    [ec2-user@ip-10-0-2-4 ~]$ xauth list
    ip-10-0-2-4.ap-northeast-1.compute.internal/unix:10  MIT-MAGIC-COOKIE-1  923b5f91af52cc467a403febf6417b25
    ip-10-0-2-4.ap-northeast-1.compute.internal/unix:11  MIT-MAGIC-COOKIE-1  193d48c60ec49fc41775afa7479157b0

    一方、ec2-userからrootにスイッチして同じコマンドを試すと、下記のような値になります。

    これらのrootの値をec2-userに合わせる必要があります。

    [ec2-user@ip-10-0-2-4 ~]$ sudo su –
    [root@ip-10-0-2-4 ~]# echo $DISPLAY
    (空白)
    [root@ip-10-0-2-4 ~]# xauth list
    xauth:  file /root/.Xauthority does not exist

    まずDISPLAY変数への反映は、下記のようにexportコマンドで行います。

    [root@ip-10-0-2-4 ~]# export DISPLAY=localhost:11.0
    [root@ip-10-0-2-4 ~]# echo $DISPLAY
    localhost:11.0

    続いてxauthに先程クリップボードに貼り付けたディスプレイ名を追加します。

    [root@ip-10-0-2-4 ~]# xauth add ip-10-0-2-4.ap-northeast-1.compute.internal/unix:11  MIT-MAGIC-COOKIE-1  193d48c60ec49fc41775afa7479157b0
    [root@ip-10-0-2-4 ~]# xauth list
    ip-10-0-2-4.ap-northeast-1.compute.internal/unix:11  MIT-MAGIC-COOKIE-1  193d48c60ec49fc41775afa7479157b0

    上記の手順を忘れると下記のエラーが出て、踏み台のWindowsサーバー上でGUIが表示されません。

    逆に下記のエラーが出た時はこれらの設定を疑ってみて下さい。

    例:環境変数DISPLAYが空白のままの場合

    [root@ip-10-0-2-4 default]# /opt/LifeKeeper/bin/lkGUIapp
    (中略)
    Exception in thread “main” java.awt.HeadlessException:
    No X11 DISPLAY variable was set, but this program performed an operation which requires it.
    (以下略)

    例:環境変数DISPLAYの値がec2-userの値と異なる場合(「localhost:11.0」なのに「localhost:10.0」とした場合)

    [root@ip-10-0-2-4 ~]# /opt/LifeKeeper/bin/lkGUIapp
    (中略)
    PuTTY X11 proxy: unable to connect to forwarded X server: Network error: Connection refused
    Exception in thread “main” java.awt.AWTError: Can’t connect to X11 window server using ‘localhost:10.0’ as the value of the DISPLAY variable.
    (以下略)

    例:DISPLAYの値が正しくてもxauthのディスプレイ名の整合が取れていない場合

    [root@ip-10-0-2-4 ~]# /opt/LifeKeeper/bin/lkGUIapp
    (中略)
    PuTTY X11 proxy: Unsupported authorisation protocol
    Exception in thread “main” java.awt.AWTError: Can’t connect to X11 window server using ‘localhost:11.0’ as the value of the DISPLAY variable.
    (以下略)

    上記の設定ができれば正常にLifeKeeperのGUI管理画面が踏み台のWindowsサーバー上で表示されます。

    LifeKeeperの起動

    続いてLifeKeeperの起動に入ります。

    rootで下記のコマンドを実行し、LifeKeeperを起動します。(Node1とNode2の双方で必要)

    [root@ip-10-0-2-4 default]# /opt/LifeKeeper/bin/lkstart

    Node1(稼動系ノード)側で、以下のコマンドでLifeKeeperのGUI管理画面を起動します。

    [root@ip-10-0-2-4 ~]# /opt/LifeKeeper/bin/lkGUIapp
    java version “1.8.0_51”
    Java(TM) SE Runtime Environment (build 1.8.0_51-b16)
    Java HotSpot(TM) 64-Bit Server VM (build 25.51-b03, mixed mode)
    Setting up secure random number generator
    Random number setup completed

    A)GUI管理画面の起動とログイン

    LifeKeeperの管理画面での認証画面で[Login]に「root」、[Password]に先程手順①の末尾で設定したパスワードを入力します。

    image27

    下記の画面が表示されれば接続成功です。(Node1:10.0.2.4にログイン)

    image28

    まず相手ノードとしてNode2(10.0.4.4)を登録します。

    上記の左端のボタンをクリックすると[Cluster Connect]画面が表示されるので、Server Name に「ip-10-0-4-4.ap-northeast-1.compute.internal」、[login]に「root」、①の手順の末尾でPassword に設定した root パスワードを入力して[OK]をクリックします。

    image29

    接続が成功すれば下記の画面が表示されます。

    image30

    以上でログインとクラスターノード間の接続は完了です。

     

    B)コミュニケーションパスの作成

    相手ノードとコミュニケーションパスを作成します。

    [Create Communication Path]ボタンをクリックしてウイザードを開始します。

    image30-a

    以降は下記の値に従いウイザードを進めて下さい。

    No.

    項目

    入力値/選択値

    備考

    1

    Local Server

    ip-10-0-2-4.ap-northeast1.compute.internal

    稼動系ホスト名

    2

    Remote Server

    ip-10-0-4-4.ap-northeast1.compute.internal

    待機系ホスト名

    3

    Device Type

    TCP

     

    4

    Local IP Address

    10.0.2.4

    稼動系ノードのIPアドレス

    5

    Remote IP Address

    10.0.4.4

    待機系ノードのIPアドレス

    6

    Priority

    1

     

    [Next]をクリック

    image32-a

    [Done]で完了させます。
    image33-a

    なお、LifeKeeperでは通常「2系統以上」のコミュニケーションパスの作成を推奨しています。

    今回は出来る限り「最小限」の構成を目標にしているのと、物理環境と異なりクラウド環境では、仮想NICを冗長化メリットが少ないことから単一の仮想NICで構成されるケースが今後増えると考えられる背景から、今回はあえて単一のコミュニケーションパスで構成しています。

    そのため、管理画面上ではノードの上に「!」マークが表示されたままになります。(2系統以上のコミュニケーションパスを設定すると、本来の緑色の「チェックマーク」です)

    image34-a

     

    以上でコミュニケーションパスの設定は完了です。

     

    C)IPリソースの作成

    続いて「IPリソース」を作成します。

    緑色の「+」マークの「Create Resource Hierarchy」をクリックしてウイザードを開始します。

     image35-a
    image36-a

     

    以降は下記の値に従いウイザードを進めて下さい。

    No.

    項目

    入力値/選択値

    1

    Switchback Type

    Intelligent

    2

    Server

    ip-10-0-2-4.ap-northeast-1.compute.internal

    3

    IP Resource

    10.1.0.10

    4

    Netmask

    255.255.255.0

    5

    Network Interface

    eth0

    6

    IP Resource Tag

    IP-10.1.0.10

    各パラメータの意味については下記をご参考下さい。

    →[オンラインマニュアル:IP リソース階層の作成] ※v9.2当時のものになります。

    IPリソースの処理概要については下記をご参照下さい。

    LifeKeeperユーザーポータル [Linux] IP Recovery Kit の処理概要(v7.4.0-)

     

    なお、上記のウイザードの途中で[IP Resource]の項目設定があります。

    ここでは仮想IPアドレスを設定します。今回は既に前回サブネットA2(10.0.2.0/24)およびサブネットC2(10.0.4.0/24)向けに作成したルートテーブルで定義したダミーの接続先(10.1.0.10)を指定します。
    image37-a

     

    「End of successful Create of…」と表示されれば成功です。[Next]をクリックして次に進みます。
    image38-a

     

    ここからはこれまで設定した値を相手側のNode2(10.0.4.4)に拡張(extend)する手順になります。
    image39-a

     

    以降は下記の値に従いウイザードを進めて下さい。

    No.

    項目

    入力値/選択値

    1

    Target Server

    ip-10-0-4-4.ap-northeast-1.compute.internal

    2

    Switchback Type

    Intelligent

    3

    Template Priority

    1

    4

    Target Priority

    10

    Pre-Extend が開始されます。「Pre Extend checks were successful」と表示されれば成功です。[Next]をクリックして次に進みます。
    image40-a

    続いて「Extend comm/ip Resource Hierarchy」ウィンドウが表示されます。
    image41-a

     

    以降は下記の値に従いウイザードを進めて下さい。

    No.

    項目

    入力値/選択値

    1

    IP Resource

    10.1.0.10

    2

    Netmask

    255.255.255.0

    3

    Network Interface

    eth0

    4

    IP Resource Tag

    IP-10.1.0.10

    [Extend]をクリックするとextendが開始されます。
    image42-a

    Extend が開始されます。「Hierarchy successful extended」と表示されれば成功です。[Finish]をクリックします。
    image43-a

    [Done]で完了させます。
    image44-a

    IPリソースが出来ました。

    image45

    簡単にスイッチバック(手動切替)のテストをしてみましょう。

    右側のスタンバイノードのリソースの上で右クリックメニューの[In Service]をクリックすると、スイッチオーバーします。
    image46-a

    下記のように「Active(稼動系)」「Standby(待機系)」が切り替わります。

    image47

    D)AWS ECCリソース(EC2™リソース)の作成

    続いてAWS ECCリソースの作成を行いますが、その前に必要な準備を説明致します。

     

    まず踏み台のWindowsサーバーからpuTTYでクラスターノードにログインします。この作業はNode1およびNode2の両方で必要です。

    まずec2-userからrootにスイッチします。

    [ec2-user@ip-10-0-2-4 lib]$ sudo su –

    AWS ECCリソースでは、ルートテーブルの書き換えをEC2のAPIツールをkickして行います。

    そこでNode1(10.0.2.4)およびNode2(10.0.4.4)に対してEC2 の API ツールをダウンロードします。

    root@ip-10-0-2-4 ~]# curl -o /root/ec2-api-tools.zip http://s3.amazonaws.com/ec2-downloads/ec2-api-tools.zip
      % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                     Dload  Upload   Total   Spent    Left  Speed
    100 16.7M  100 16.7M    0     0  1147k      0  0:00:14  0:00:14 –:–:– 1321k

    ダウンロードしたAPIツールを解凍します。

    但し環境にはunzipがインストールされていないはずなので、下記のコマンドでunzipをインストールします。

    [root@ip-10-0-2-4 ~]# yum install unzip
    (略)

    続いてec2-api-tools.zipをunzipで解凍します。

    [root@ip-10-0-2-4 ~]# unzip ec2-api-tools.zip

    unzipの展開先は/ ec2-api-tools-1.7.5.1/になっているので、これを/opt/aws/にリネームします。

    [root@ip-10-0-2-4 ~]# mv ec2-api-tools-1.7.5.1/ /opt/aws/

    このパスの情報を/.bash_profileにEC2_HOMEとして追記して反映します。この定義内容は、後のAWS ECCリソースの作成時に使われます。

    [root@ip-10-0-2-4 aws]# echo “export EC2_HOME=”/opt/aws”” >>~/.bash_profile

    続いてJavaをインストールします。(LifeKeeper同梱のものとは別のJavaです。)

    [root@ip-10-0-2-4 aws]# yum install java-1.8.0-openjdk
    (略)

    これらは/usr/lib/jvm/にインストールされます。(jvmディレクトリが作成される)

    jvmディレクトリは下記の構成となります。

    image48

    この後、今はまだ無いJAVA_HOMEにここでインストールしたjreのpathを登録します。

    [root@ip-10-0-2-4 jre]# echo $JAVA_HOME
    (空白)

    JAVA_HOMEにjreのpathを登録します。

    ※「Openjdk-1.8.0」以降のpathの文字列は変わっている可能性があります。

    [root@ip-10-0-2-4 jre]# export JAVA_HOME=”/usr/lib/jvm/jre-1.8.0-openjdk-1.8.0.161-0.b14.el7_4.x86_64″
    [root@ip-10-0-2-4 jvm]# echo $JAVA_HOME
    /usr/lib/jvm/jre-1.8.0-openjdk-1.8.0.161-0.b14.el7_4.x86_64

    ここまでの手順を両クラスターノード(Node1およびNode2)に対して行います。

    なお、AWS ECCリソースの作成ではAWSアクセスキーが必要になります。

    そこでAPI Toolsに設定する「AWSアクセスキー」と「AWS秘密鍵」を取得する為に「IAM User」を作成します。

    下記のようにWebブラウザ上でIAMのマネジメントコンソールで作成します。

    https://console.aws.amazon.com/iam/home?#security_credential

    にアクセス。

    ナビゲーションペインで[ユーザー]を選択し、[ユーザーを追加]をクリック。

    image49-a

    ユーザ名は「lifekeeper」として、[アクセスの種類]は「プログラムによるアクセス」を選択します。

    image50-a

    [既存のポリシーを直接アタッチ]を選択します。

    その既存のポリシーは[AmazonEC2FullAccess]を選択します。

    image51-a

    [ユーザーの作成]ボタンをクリック

    image52-a

    忘れずに[.csvのダウンロード]をクリックしてダウンロードして下さい。このファイルの中に「AWSアクセスキー」と「AWS秘密鍵」が記載されています。次のステップでコピペして使います。
    image53-a

    最後に再びpuTTYのコンソールに戻って、上記で入手したAWSアクセスキーIDとシークレットアクセスキーを下記のように環境変数に設定(先程ダウンロードしたcsvファイルからコピペ)します。

    [root@ip-10-0-2-4 jre]# export AWS_ACCESS_KEY=”(AWSアクセスキーID)”
    [root@ip-10-0-2-4 jre]# export AWS_SECRET_KEY=”(シークレットアクセスキー)”

    ここまでの設定内容を以下のコマンドにて反映します。

    [root@ip-10-0-2-4 jre]# source ~/.bash_profile

    下記のコマンドでリージョンが表示されることを確認します。

    [root@ip-10-0-2-4 ~]# /opt/aws/bin/ec2-describe-regions
    REGION  ap-south-1      ec2.ap-south-1.amazonaws.com
    REGION  eu-west-3       ec2.eu-west-3.amazonaws.com
    REGION  eu-west-2       ec2.eu-west-2.amazonaws.com
    REGION  eu-west-1       ec2.eu-west-1.amazonaws.com
    REGION  ap-northeast-2  ec2.ap-northeast-2.amazonaws.com
    REGION  ap-northeast-1  ec2.ap-northeast-1.amazonaws.com
    REGION  sa-east-1       ec2.sa-east-1.amazonaws.com
    REGION  ca-central-1    ec2.ca-central-1.amazonaws.com
    REGION  ap-southeast-1  ec2.ap-southeast-1.amazonaws.com
    REGION  ap-southeast-2  ec2.ap-southeast-2.amazonaws.com
    REGION  eu-central-1    ec2.eu-central-1.amazonaws.com
    REGION  us-east-1       ec2.us-east-1.amazonaws.com
    REGION  us-east-2       ec2.us-east-2.amazonaws.com
    REGION  us-west-1       ec2.us-west-1.amazonaws.com
    REGION  us-west-2       ec2.us-west-2.amazonaws.com

    ここまでのコマンドラインの手順を両クラスターノード(Node1およびNode2)に対して行います。

     

    いよいよ次はAWS ECCリソースを作成します。

    GUI管理画面で[Create Resource Hierarchy]をクリックしてリソース作成を開始します。

    image54-a

    ウイザードが開始するとプルダウンメニューでRecovery Kitに[Amazon EC2]を選択して[Next]をクリックします。

    image55-a

    以降は下記の値に従いウイザードを進めて下さい。

    No.

    項目

    入力値/選択値

    備考

    1

    Switchback Type

    Intelligent

     

    2

    Server

    ip-10-0-2-4.ap-northeast1.compute.internal

     

    3

    EC2 Home

    /opt/aws

     

    4

    EC2 URL

    ec2.ap-northeast-1.amazonaws.com

    東京リージョン

    5

    AWS Access Key

    アクセスキー

    先程作成したもの

    6

    AWS Security Key

    シークレットアクセスキー

    先程作成したもの

    7

    EC2 Resource type

    Route Table(Backend Cluster)

     

    8

    IP Resource

    IP-10.1.0.10

     

    9

    EC2 Resource Tag

    ec2-10.1.0.10

     

    EC2 Resource Tagまで設定すると最後に[Create]ボタンをクリックするとリソース作成が開始します。
    image56-a

    「End of successful Create of…」と表示されれば成功です。[Next]をクリックして進めてください。
    image57-a

    続いてPre-Extendに進みます。
    image58-a

    以降は下記の値に従いウイザードを進めて下さい。

    No.

    項目

    入力値/選択値

    1

    Target Server

    ip-10-0-4-4.ap-northeast1.compute.internal

    2

    Switchback Type

    Intelligent

    3

    Template Priority

    1

    4

    Target Priority

    10

    「Pre Extend checks were successful」と表示されれば成功です。[Next]をクリックして進めてください。

    image59-a

    「Extend comm/ec2 Resource Hierarchy」ウィンドウが表示されます。

    [ec2 Resource Tag]が「ec2-10.1.0.10」になっていることを確認したら[Next]をクリックします。
    image60-a

    「Hierarchy successful extended」と表示されれば成功です。[Finish]をクリックします。
    image61-a

    [Done]で完了させます。
    image62-a

    リソースツリーが下記のようになっていることを確認します。

    スイッチオーバーも確認してみます。

    image62

    image63

    以上でAWS ECCリソースの設定を完了です。

    E)DataKeeperリソースの作成

    オンプレ環境と異なり、AWS上では共有ストレージが使えません。

    そこでLifeKeeperによるHAクラスター構成では、DataKeeperのレプリケーション領域を共有ストレージとしてLifeKeeperが認識して使うことで、AWS環境でもオンプレ環境と同様のHAクラスター構成を実現しています。

    ここではそのDataKeeperのリソースを作成します。

    その前に、DataKeeperで使用するディスクの設定をコマンドラインで行います。

    インスタンス作成時に追加したDB用のEBSボリュームに対して、パーティション設定を行います。Node1とNode2の両方に実行して下さい。

    踏み台のWindowsサーバーからpuTTYでNode1にrootでログインします。

    [ec2-user@ip-10-0-2-4 dev]$ sudo su –

    DB用のマウントポイントは「u01」としました。

    Node1(10.0.2.4)とNode2(10.0.4.4)の両ノードで/u01ディレクトリを作成します。

    ※両ノードで必要※

    [root@ip-10-0-2-4 ~]# mkdir /u01

    lsblkコマンドで利用可能なブロックデバイスの一覧を表示します。

    インスタンスの作成の際に拡張した8GBのEBSは「xvdb」として認識されています。

    ※両ノードで必要※

    [root@ip-10-0-2-4 ~]# lsblk
    NAME    MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
    xvda    202:0    0  10G  0 disk
    ├─xvda1 202:1    0   1M  0 part
    └─xvda2 202:2    0  10G  0 part /
    xvdb    202:16   0   8G  0 disk

    このEBS「xvdb」に対してfdiskコマンドでパーティションを設定します。

    ※両ノードで必要※

    [root@ip-10-0-2-4 ~]# fdisk /dev/xvdb
    Welcome to fdisk (util-linux 2.23.2).
    (中略)
    Command (m for help): n  ←「n:新しい区画を作成」を入力
    Partition type:
       p   primary (0 primary, 0 extended, 4 free)
       e   extended
    Select (default p): p  ←「p」を入力
    Partition number (1-4, default 1): 1  ←「1」を入力
    First sector (2048-16777215, default 2048):  ←Enter
    Using default value 2048
    Last sector, +sectors or +size{K,M,G} (2048-16777215, default 16777215):  ←Enter
    Using default value 16777215
    Partition 1 of type Linux and of size 8 GiB is set
     
    Command (m for help): w  ←「w:テーブルを書き込んで終了」を入力
    The partition table has been altered!
    (以下略)

    fdiskの結果を確認します。

    [root@ip-10-0-2-4 ~]# fdisk -l /dev/xvdb
    (中略)
        Device Boot      Start         End      Blocks   Id  System
    /dev/xvdb1            2048    16777215     8387584   83  Linux

    上記のxvdb1をフォーマットします。

    ※両ノードで必要※

    [root@ip-10-0-2-4 ~]# mkfs -t xfs /dev/xvdb1
    meta-data=/dev/xvdb1             isize=512    agcount=4, agsize=524224 blks
    (中略)
    realtime =none                   extsz=4096   blocks=0, rtextents=0

    ※Node1のみ※フォーマットした領域を、マウントポイントの/u01にマウントします。

    [root@ip-10-0-2-4 ~]# mount /dev/xvdb1 /u01

    マウント後改めてlsblkコマンドで確認してみると、xvdb1が/u01にマウントされていることが確認できます。

    [root@ip-10-0-2-4 ~]# lsblk
    NAME    MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
    xvda    202:0    0  10G  0 disk
    ├─xvda1 202:1    0   1M  0 part
    └─xvda2 202:2    0  10G  0 part /
    xvdb    202:16   0   8G  0 disk
    └─xvdb1 202:17   0   8G  0 part /u01

    CLIの作業は以上です。

    GUI管理画面で[Create Resource Hierarchy]をクリックしてリソース作成を開始します。
    image64-a

    ウイザードが開始します。プルダウンメニュで Recovery Kit に[Data Replication]を選択して[Next]をクリックします。
    image65-a

    以降は下記の値に従いウイザードを進めて下さい。

    No.

    項目

    入力値/選択値

    備考

    1

    Switchback Type

    Intelligent

     

    2

    Server

    ip-10-0-2-4.ap-northeast1.compute.internal

     

    3

    Hierarchy Type

    Replication Exiting Filesystem

     

    4

    Existing Mount Point

    /u01

     

    5

    DataReplication Resource Tag

    datarep-u01

    デフォルト値

    6

    File System Resource Tag

    /u01

    デフォルト値

    7

    BitmapFile

    /opt/LifeKeeper/bitmap__u01

    デフォルト値

    8

    Enable Asynchronous Replication

    No

     

    デフォルト値

    4.の後に下記の確認画面が出たら[continue]をクリックして進めます。
    image66-a

    「End of successful Create of…」と表示されれば成功です。[Next]をクリックして進めてください。
    image67-a

    続いてPre-Extendの設定を行います。
    image68-a

    以降は下記の値に従いウイザードを進めて下さい。

    No.

    項目

    入力値/選択値

    1

    Target Server

    ip-10-0-4-4.ap-northeast1.compute.internal

    2

    Switchback Type

    Intelligent

    3

    Template Priority

    1

    4

    Target Priority

    10

     

    「Pre Extend checks were successful」と表示されれば成功です。[Next]をクリックして進めてください。
    image69-a

    /dev/xvdb1を選択します。
    image70-a

    以降は下記の値に従いウイザードを進めて下さい。

    No.

    項目

    入力値/選択値

    備考

    1

    Target Disk

    /dev/xvdc1

     

    2

    DataReplication Resource Tag

    datarep-u01

    デフォルト値

    3

    BitmapFile

    /opt/LifeKeeper/bitmap__u01

    デフォルト値

    4

    Replication Path

    10.0.2.4/10.0.4.4

     

    5

    Mount Point

    /u01

     

    6

    Root Tag

    /u01

     

    「Hierarchy successful extended」と表示されれば成功です。[Finish]をクリックします。
    image71-a

    [Done]で完了させます。

    image72

    リソースツリーは下記のようになります。

    image73

    現在はリソースツリーのルートが分かれているので、それぞれ別個にスイッチオーバーすることを確認します。

    image74

    ついでにルートテーブルの内容がLifeKeeper側の切り替えでどのように変わるのかを見てみましょう。

    Recovery Kit for EC2™のルートテーブルシナリオの考え方や動きについては、「ルートテーブルシナリオ」によるEC2のHAクラスター構成の記事をご参照下さい。

    サービスをクリックし、右側のペインからVPCを選択します。

    VPC

    VPCダッシュボードから「ルートテーブル」を選択します。

    image76-a

    表示される作成済みのルートテーブルの一覧からRT-yattemiyo-A2またはRT-yattemiyo-C2を選択します。
    image77-a

    ◇切り替え前=Node1がActive

    サブネットA2と紐付いているルートテーブルRT-yattemiyo-A2の内容

    image78-a

    サブネットC2と紐付いているルートテーブルRT-yattemiyo-C2の内容
    image79-a

    ダミーの仮想IPアドレスである10.1.0.10が指しているENIのIDに着目して下さい。上記のいずれのルートテーブルにおいても、10.1.0.10/32が指している先は同じNode1のENIのID(eni-b8255584)が表示されています。

    それではここでAWS ECCリソースがある方のリソースツリーを手動で切り替えます(=スイッチオーバー)。

    切り替え後=Node2がActive

    サブネットA2と紐付いているルートテーブルRT-yattemiyo-A2の内容
    image80-a

    サブネットC2と紐付いているルートテーブルRT-yattemiyo-C2の内容
    image81-a

    ダミーの仮想IPアドレスである10.1.0.10が指しているENIのIDに着目して下さい。上記のいずれのルートテーブルにおいても、10.1.0.10/32が指している先は同じNode2のENIのID(eni-a6a6a8a9)が表示されています。このことからまさにルートブルシナリオ通りにAWSのルートテーブルがLifeKeeperの切り替えによって制御されていることが確認できます。

    以上でAWS ECCリソースの設定は完了です。

    以上で基本的なHAクラスターの構成の設定は完了です。

    次回は具体的なソフトウェアとして、PostgreSQLを専用のリカバリキットのPotgreSQL ARKを使って保護(監視や切り替え)する手順についてご紹介します。お楽しみに。

    ご案内

    Linux版のLifeKeeperおよびDataKeeperのマニュアルは下記をご参照下さい。

    →[オンラインマニュアル]

    一般公開されている技術情報は下記をご参照下さい。各リカバリキットの処理概要もこちらです。

    →[ユーザーサイト]

    AWS関連情報

    Amazon EC2の可用性向上について

    LifeKeeperやDataKeeperによるAmazon EC2上でのクラスター構成についてご紹介しています。

    AWS向け資料ダウンロードはこちら

    お問い合わせ先

    「もっと詳しい話を聞いてみたい。」「自分の持っている案件は対応できそうか?」といった場合は、下記までお気軽にお問い合わせください。

    ご評価版は下記からお申し込みいただけます。30日間無償でご検証いただけます。
    ※評価版のご使用にあたっては、十分に規約をご確認の上ご活用願います。


    評価中の技術的なお問合わせは評価サポートにて承っております。

    当記事の内容は全て公開日時点での当社独自見解となりますので、製品選定時のご参考に用途を限定し、二次配布や資料の改変はご遠慮願います。

    内容を参考にされた結果生じたいかなる損害も当社は責任を負いませんので、事前に十分な動作検証をお願いします。