Direct Connect環境のLifeKeeperでサイボウズガルーンを冗長化してみた

まいど、大阪の市田です。

前回ご紹介したサイボウズガルーン(以下、ガルーンと表記)の「サーバ分離構成」では、DBサーバがSPOFになってしまいます。DBサーバを冗長化する方法はいくつかありそうですが、今回はLifeKeeperを使った冗長化についてご紹介します。

サイボウズ ガルーンをAWSに構築してみた

なお、前回の記事との相違点としては、ガルーンを利用する環境になります。

前回の記事では、クライアントはインターネット経由でガルーンを利用する構成でしたが、今回は「オンプレ環境からDirect Connect経由でガルーンを利用するセキュアな構成」を前提としました。
背景として、最近ビジネスアプリケーションがどんどんAWS上に乗ってくるのに伴い、 今後は専用線接続のケースがますます増えることが想定されるためです。

目次

長いエントリーですので目次を作成しました。なかなかボリュームのある内容ですね(汗)

• 構成
  • 構成図
  • 構成の説明
  • 追加ENIの補足
• LifeKeeper/DataKeeperとは
  • ライセンスの入手
• やってみた
  • AWS環境の作成
  • ルートテーブルの作成
  • Security Groupの設定
  • Route53のプライベートホストゾーンの作成
  • NAT Gatewayの作成
  • ELB(Application Load Balancer)の作成
  • Simple ADの作成
  • 踏み台サーバ(Windows Server)の構築
  • Xmingのインストールと設定 -DBサーバの構築(クラスターノードの設定)
  • プライマリENI(eth0)のSource/Dest. Checkの無効化
  • OS上でのNIC設定
  • X11他の導入、OS設定
  • LifeKeeperとガルーンに必要なパッケージのインストール
  • LifeKeeperのインストール
  • LifeKeeperの設定(起動とログイン)
  • LifeKeeperの設定(Communication Pathの作成)
  • LifeKeeperの設定(IPリソースの作成)
  • EC2 API Toolsのインストールと設定
  • LifeKeeperの設定(EC2リソースの作成)
  • 追加EBSのパーティション設定
  • DataKeeperの設定
  • プライマリDBサーバにガルーンをインストール
  • バックアップDBサーバにガルーンをインストール
  • マスター側DBサーバのアクティブ化
  • ガルーン用Generic ARKスクリプトのインストール
  • Cybozu Database Engineサービスのリソース作成
  • Cybozu Scheduling Serviceサービスのリソース作成
  • LifeKeeperのリソース階層の修正 -Appサーバの構築
  • ガルーンに必要なパッケージのインストール
  • SELinuxとfirewalldの無効化
  • ガルーンのインストール
  • ガルーンの設定変更
  • NFSの設定
• 動作確認
  • テスト内容
• 参考ドキュメント
  • サイボウズガルーンのドキュメント
  • LifeKeeperのドキュメント
• 最後に

構成

構成図

可用性を考慮に入れつつ、Direct Connect経由でガルーンを利用することを想定した構成です。

構成の説明

それぞれについて簡単に説明します。

• ガルーンへのアクセス
  • Direct Connect経由でのアクセスを想定の為、各インスタンにはプライベートIPのみ付与
  • Direct Connectからプライベート用のURLに対して、ELB経由でガルーンにアクセス
  • Internal ELBのDNS名に対して、Route53のALIASレコードでelb.garoon-internal.localを指定
  • Direct Connectからの名前解決は、Route53のプライベートホストゾーンと「Simple AD」を利用
• Appサーバ
  • AutoScaling等、複数台存在することを想定
  • 今回は各アベイラビリティゾーンに1台ずつ手動で配置
  • 仮想IP(10.1.0.10)に対してガルーンのデータへアクセス
    • 仮想IPはActiveなDBサーバのENI(eth0)にrouteが向いています。
• DBサーバ
  • サーバ上のガルーンデータをLifeKeeper/DataKeeperを用いてHA化
  • ガルーンデータ用の追加EBSを持ち、AppサーバからNFSマウント
  • 死活チェックの追加ENI(Elastic Network Interface)をeth1として追加
• 各インスタンスでyumを実行するためNAT Gatewayを配置
• 各インスタンスへは踏み台サーバ(Bastion)からアクセス

追加ENIの補足

LifeKeeperではプライマリ、バックアップの各インスタンスで互いの死活状況をチェックしていますが、この確認用のパス(コミュニケーションパス)を2つ持つことが推奨されています。

パスが１つだけでも利用することが可能ですが、LifeKeeper上では警告が表示されるので上記のような構成にしています。

LifeKeeper/DataKeeperとは

今回利用したLifeKeeper/DataKeeperについてですが、公式サイトでは下記のように説明されています。

LifeKeeperは、システムの障害を監視し、稼動系に障害が生じた場合に待機系に自動的に切り替えを行うことで、システムダウンタイムの時間を短縮 し、ビジネス損失を最小限にするHAクラスターソフトウェアです。

DataKeeperは、稼動中のサーバーのデータを待機系サーバーへリアルタイムにレプリケーション（複製）するソフトウェアです。データ圧縮機能や同期・非同期モードにより遠隔地へのレプリケーションにも適用可能です。

LifeKeeper/DataKeeper | サイオステクノロジー株式会社

つまり、Active/Standby構成となるシステムに対して、データ同期を含めてHAクラスターを組むことができるソフトウェアということになります。さらに、Elastic IPの自動付け替えや、VPCのRoute Tableの自動切替といったAWSへの対応も可能です。

ライセンスの入手

LifeKeeperを利用するにはライセンスが必要で、評価ライセンスを下記Webページから入手可能です。

評価版ダウンロード│LifeKeeper/DataKeeper｜サイオステクノロジー株式会社

尚、ガルーンをLifeKeeperで保護する場合は、専用のスクリプト(ガルーン用 Generic ARKスクリプト)が必要なので、今回はサイオステクノロジー様から頂いた評価ライセンスを利用しています。

やってみた

では、早速環境の作成を行っていきたい思います。参考にしたドキュメント等については、本記事の最後でまとめてご紹介していますので、そちらも是非ご参照ください。

AWS環境の作成

VPCのサブネット構成は構成図の通りなので、割愛させて頂きます。

ルートテーブルの作成

今回は6つのルートテーブルを作成しています。NAT Gateway経由でインターネットに出る経路と、Direct Connectからの経路があるので少し多めです。

Internal ELB用のルートテーブル

• Direct Connect側へのルーティングのみ追加しています。

NAT Gateway用のルートテーブル

• インターネットゲートウェイをデフォルトゲートウェイとして指定します。

Appサーバ用のルートテーブル(ap-northeast-1a用)

• 同じアベイラビリティゾーン(ap-northeast-1a)のNAT Gatewayをデフォルトゲートウェイにしています。
• 仮想IPである「10.1.0.10/32」をアクティブなDBサーバのeth0に向けています。
• フェイルオーバー発生時に、LifeKeeperによりバックアップ側のDBサーバ向けに更新されます。

Appサーバ用のルートテーブル(ap-northeast-1c用)

• yumを利用するので、同じアベイラビリティゾーン(ap-northeast-1c)のNAT Gatewayをデフォルトゲートウェイにしています。
• 仮想IPである「10.1.0.10/32」をアクティブなDBサーバのeth0に向けています。
• フェイルオーバー発生時に、LifeKeeperによりバックアップ側のDBサーバ向けに更新されます。
• Direct Connect側へのルート(198.10.0.0/24)は、作業中に直接Appサーバのウェブ表示を確認したかったので設定したものです。無くても構いません。

DBサーバ用のルートテーブル(ap-northeast-1a用)

• yumを利用するので、同じアベイラビリティゾーン(ap-northeast-1a)のNAT Gatewayデフォルトゲートウェイにしています。

DBサーバ用のルートテーブル(ap-northeast-1c用)

• yumを利用するので、同じアベイラビリティゾーン(ap-northeast-1c)のNAT Gatewayデフォルトゲートウェイにしています。

Security Groupの設定

Appサーバ用グループ

• Appサーバに下記の内容で設定します。

DBサーバ用グループ

• DBサーバに下記の内容で設定します。
• eth0、eth1両方のENIに適用します。
• DBサーバへのアクセスについては、MySQLやNFS、LifeKeeperの死活監視等の通信があります。
  • 今回は簡単にする為に関連サブネットからのアクセスは全て許可しました。
• 必要に応じてカスタマイズして下さい。

ELB用グループ

踏み台サーバ

• アクセスする拠点IPを許可して下さい。
• 今回はLinuxとWindows Serverの2種類の踏み台サーバを使ったので、SSHとRDPのポートを許可しました。

Simple AD用グループ

• Simple AD作成時に作られるセキュリティグループを下記のように修正します。

Route53のプライベートホストゾーンの作成

下記のように設定してみました。

具体的な作成方法は下記をご参照下さい。

Route 53のPrivate DNS対応を試してみた

NAT Gatewayの作成

具体的な作成方法は下記をご参照下さい。

【新機能】ついに登場！Amazon VPC NAT GatewayでNATがAWSマネージドに

ELB(Application Load Balancer)の作成

今回はInternal ELBとして作成します。具体的な作成方法は下記をご参照下さい。

【新機能】新しいロードバランサー Application Load Balancer（ALB）が発表されました

Simple ADの作成

具体的な作成方法は下記をご参照下さい。

AWS Directory Service(Simple AD)を利用したオンプレミスからのPrivate Hosted Zone名前解決

踏み台サーバ(Windows Server)の構築

LifeKeeperの設定はGUIで行いますが、X Window Systemを使用しているため、クライアント側にもXサーバーが必要となります。

その為、GUI操作用にWindows Serverの踏み台サーバを用意します。今回は「Windows Server 2012R2」を利用し「NAT Gateway」と同じサブネットに作成します。

作成できたらRDPでログオンして、「Teraterm」とWindows用のXサーバとして「Xming」をインストールします。 (Teratermのインストールは割愛させて頂きます。)

Xmingのインストールと設定

Xmingのインストールもインストーラの指示通りに行っていくものですが、初めてでしたので紹介します。
まず、下記サイトからインストーラをダウンロードして実行します。

Xming X Server for Windows 日本語情報トップページ - OSDN

ひたすら「Next」をクリックします。

Xmingが起動するとタスクトレイにアイコンが表示されます。

これでXmingのインストールは完了です。もし出力が文字化けする場合は「「Xming-fonts」もインストールしてみて下さい。

次に、自動的にLifeKeeperのGUIにアクセスできるように「X11 Forwarding」の設定を行います。
Teratermを起動して「SSH転送」をクリックします。

「リモートの（X）アプリケーションをローカルのXサーバーに表示する」にチェックを入れます。

設定を保存します。

DBサーバの構築(クラスターノードの設定)

ここからは各サーバの構築を行っていきます。踏み台を除くインスタンスは全て同じAMIを利用します。

特にクラスターノードを構成するDBサーバについては必ず同じAMIにして下さい。Appサーバは別のAMIでもいいかと思いますが、ガルーンのインストール等も統一したかったので全て同じAMIにしています。また、EBSのガルーン用のボリュームは検証の為、最小の8GBを指定しています。

下記の構成で、MarketplaceのRHELのAMIから作成して下さい。AMIは「ami-0dd8f963」を利用しました。タイミングによって異なるAMIで公開されているかもしれませんので、適宜選択して下さい。
セキュリティグループは前述の「DBサーバ用グループ」の内容のグループを適用して下さい。

今回は全てRHEL7.2のAMIからインスタンスを作成しています。

ENIについては、インスタンス作成時に下記のようにeth0を追加します。

EBSはガルーン用ボリュームを下記のように追加します。

プライマリENI(eth0)のSource/Dest. Checkの無効化

DBインスタンスが作成できたら、各DBサーバの「eth0」のENIに対して「Source/Dest. Check」を「Disabled」に変更します。これはeth0に対して、仮想IP(10.1.0.10)宛の通信がある為です。

次の画面で「Change Source/Dest. Check」をクリックします。

「Disabled」にチェックを入れて保存します。

OS上でのNIC設定

DBサーバはENIが2つアタッチされていますが、2つ目のENI(eth1)がOS上で認識されていないので、手動で設定を追加します。

まず、eth1用の設定ファイルをifcfg-eth0からifcfg-eth1としてコピーします。

# cd /etc/sysconfig/network-scripts/
# sed 's/eth0/eth1/g' ifcfg-eth0>ifcfg-eth1

eth0をデフォルトルートに設定します。

# echo DEFROUTE=YES>>ifcfg-eth0
# echo DEFROUTE=NO>>ifcfg-eth1

設定を反映させます。

# systemctl restart network

ルーティングテーブルが下記のようになっていることを確認します。

# route -n
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
0.0.0.0         10.0.3.1        0.0.0.0         UG    100    0        0 eth0
10.0.3.0        0.0.0.0         255.255.255.0   U     100    0        0 eth0
10.0.12.0       0.0.0.0         255.255.255.0   U     100    0        0 eth1
10.0.14.0       10.0.12.1       255.255.255.0   UG    100    0        0 eth1

次にプライマリのDBサーバ(db-01)でeth1用のゲートウェイ設定を追加設定します。下記の内容で/etc/sysconfig/network-scripts/route-eth1を作成して下さい。

10.0.14.0/24 via 10.0.12.1

設定を反映させます。

# systemctl restart network

同様にバックアップのDBサーバ(db-02)でもroute-eth1を作成します。

10.0.12.0/24 via 10.0.14.1

設定を反映させます。

# systemctl restart network

ルーティングテーブルが下記のようになっていることを確認します。

# route -n
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
0.0.0.0         10.0.6.1        0.0.0.0         UG    100    0        0 eth0
10.0.6.0        0.0.0.0         255.255.255.0   U     100    0        0 eth0
10.0.12.0       10.0.14.1       255.255.255.0   UG    100    0        0 eth1
10.0.14.0       0.0.0.0         255.255.255.0   U     100    0        0 eth1

DBサーバ間で10.0.12.4、10.0.14.4に対してPingで疎通できることを確認します。
db-01からdb-02へ確認します。

# ping -c 4 10.0.14.4
PING 10.0.14.4 (10.0.14.4) 56(84) bytes of data.
64 bytes from 10.0.14.4: icmp_seq=1 ttl=64 time=3.87 ms
64 bytes from 10.0.14.4: icmp_seq=2 ttl=64 time=2.70 ms
64 bytes from 10.0.14.4: icmp_seq=3 ttl=64 time=2.63 ms
64 bytes from 10.0.14.4: icmp_seq=4 ttl=64 time=2.59 ms

--- 10.0.14.4 ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3005ms
rtt min/avg/max/mdev = 2.599/2.953/3.875/0.534 ms

db-02からdb-01へ確認します。

# ping -c 4 10.0.12.4
PING 10.0.12.4 (10.0.12.4) 56(84) bytes of data.
64 bytes from 10.0.12.4: icmp_seq=1 ttl=64 time=2.69 ms
64 bytes from 10.0.12.4: icmp_seq=2 ttl=64 time=2.82 ms
64 bytes from 10.0.12.4: icmp_seq=3 ttl=64 time=2.66 ms
64 bytes from 10.0.12.4: icmp_seq=4 ttl=64 time=2.62 ms

--- 10.0.12.4 ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3005ms
rtt min/avg/max/mdev = 2.621/2.699/2.821/0.075 ms

X11他の導入、OS設定

LifeKeeperのGUIアプリケーションを利用する為にX11をインストールします。

# yum -y groupinstall "x11"

"Server with GUI"でインストールしてしまうとカーネルバージョンが上がってしまうので、念のためカーネルバージョンが変わっていないことを確認しておきましょう。

# uname -r
3.10.0-327.el7.x86_64

完了したら下記を実行します。

# systemctl set-default graphical.target

次にredhat-lsbをインストールします。

# yum install redhat-lsb

クラスタ同士の名前解決の為に/etc/hostsを設定します。
プライマリ(db-01)側に下記2行を追記します。同じ内容でバックアップ(db-02)側にも追記して下さい。

# cat /etc/hosts
127.0.0.1   localhost localhost.localdomain localhost4 localhost4.localdomain4
::1         localhost localhost.localdomain localhost6 localhost6.localdomain6

10.0.3.4 ip-10-0-3-4.ap-northeast-1.compute.internal
10.0.6.4 ip-10-0-6-4.ap-northeast-1.compute.internal

次にドキュメントにある通りSELinuxを無効化します。

# sed -i -e 's/enforcing/disabled/g' /etc/selinux/config

設定を反映させる為、再起動します。

# reboot

再起動が完了したらSElinuxの状態を確認します。getenforceの結果がDisabledであることを確認します。

$ getenforce
Disabled

次にfirewalldが起動しているのでこれを停止します。

# systemctl status firewalld

自動起動設定も無効化します。

# systemctl disable firewalld

LifeKeeperのインストール時にrootパスワードが必要になるので、設定します。

# passwd

LifeKeeperとガルーンに必要なパッケージのインストール

ガルーンの動作に必要な各種パッケージをインストールします。プライマリ(db-01)、バックアップ(db-02)の両方で実施します。

yum -y install httpd libaio libjpeg-turbo libpng perl perl-Data-Dumper wget unzip

LifeKeeperのインストール

LifeKeeperのイメージファイルspsXXX.imgをDBサーバ上にscp等で保存します。保存できたらイメージファイルをマウントしてインストーラを起動します。イメージファイルの名前はspsXXX.imgになっていると思いますが、入手されたファイル名に合わせて下さい。

# mount spsXXX.img -t iso9660 -o loop /mnt
mount: /dev/loop0 is write-protected, mounting read-only

# cd /mnt
# ./setup

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

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

完了したらEnterキーで先に進みます。

Javaパッケージのインストールです。Enterキーでインストールして下さい。

完了したらEnterキーで先に進みます。

DataKeeper用途のカーネルモジュールのインストールです。Enterキーでインストールして下さい。

完了したらEnterキーで先に進みます。

NFSユーティリティパッケージのインストールです。Enterキーでインストールして下さい。

NFSサービスを再起動します。Enterキーで実行して下さい。

Enterキーで先に進みます。

必須パッケージのインストール。Enterキーでインストールして下さい。

完了したらEnterキーで先に進みます。

SPS coreパッケージのインストールです。Enterキーでインストールして下さい。

完了したらEnterキーで先に進みます。

グループとログインユーザの設定。Enterキーで実行して下さい。

完了したらEnterキーで先に進みます。

ライセンスキーインストールの確認です。ここではインストールしないのでEnterキーを押してください。

オプションの Recovery Kit パッケージのインストールです。スペースキーでlkDRを選択します。選択完了したらEnterキーを押してください。

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

パッケージのインストールが成功すると以下のメッセージが表示されます。Enterキーで先に進みます。

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

次に「EC２専用ARK(Application Recovery Kit)」のインストールを行います。
EC2 関連のRecovery KitのRPMパッケージは、先程のイメージファイルに含まれていて、マウントしたディレクトリ直下の「amazon」ディレクトリ内にあります。

RPMファイル名のバージョン番号は適宜読み替えて下さい。

# cd /mnt/amazon/
# rpm -Uvh steeleye-lkECC-9.1.X-XXXX.noarch.rpm

EC2 ARKのインストールが完了したら、「ライセンスキー」をインストールします。

# /opt/LifeKeeper/bin/lkkeyins <ライセンスファイルのPATH>

ここまで出来たらブロードキャストpingを無効化します。(VPCはブロードキャストは利用不可の為)

# sed -i -e 's/NOBCASTPING=0/NOBCASTPING=1/g' /etc/default/LifeKeeper

インストール作業が完了したら、イメージファイルをアンマウントしておきましょう。

# cd
# umount /mnt

同じ作業がプライマリ(db-01)、バックアップ(db-02)の両方で完了すればLifeKeeperのインストールは完了です。

LifeKeeperの設定(起動とログイン)

LifeKeeperのインストールが完了したので、これからLifeKeeperの設定を行っていきます。

まず、Windows Serverの踏み台サーバにRDPでログオンして、Teratermを起動します。Teratermで各DBサーバにSSHログインします。
最初にec2-userユーザでログインしてからrootにスイッチして下さい。

DBサーバにログインできたら下記のコマンドでLifeKeeperを起動します。(両方のDBサーバで実行します)

# /opt/LifeKeeper/bin/lkstart

次にプライマリ側のDBサーバでLifeKeeper GUIを起動します。

# /opt/LifeKeeper/bin/lkGUIup

起動する時は、ログインしたユーザーの環境変数と認証情報、GUI画面を起動したユーザーの環境変数と認証情報を一致させておく必要があります。次のコマンドの結果が一致していることを確認して下さい。

$ echo $DISPLAY
# echo $DISPLAY
$ xauth list
# xauth list

一致していない場合、以下のコマンドでログインユーザー側の情報と一致させてください。

# export DISPLAY=[ログインユーザーの＄DISPLAYの出力結果]
# xauth add [ログインユーザーのxauth listの出力結果]

永続的に環境変数を設定する場合は、ユーザーの環境変数（.bash_profile等）に適宜設定して下さい。

正常にGUIが起動できたら、rootアカウントのアカウント情報を入力して「OK」をクリックします。

ログインできたら下記の様な表示になっていることを確認します。

クラスターアイコンをクリックしてBackup ノードにログインします。

Server Name にバックアップ側DBの「Private DNS」である「ip-10-0-6-4.ap-northeast-1.compute.internal」、[login]に「root」、Password にrootのパスワードを入力して[OK]をクリックします。

プライマリ、バックアップ両方のDBにログインできると下記のような表示になります。

LifeKeeperの設定(Communication Pathの作成)

次に「Communication Path 」を作成していきます。コミュニケーションパスとは、一般的にハートビートと呼ばれるクラスター間の監視用の通信経路のことです。

それでは「Create Comm Path」のアイコンをクリックしてウィザードを起動します。

「Local Server」に「ip-10-0-3-4.ap-northeast-1.compute.internal」を選択して「Next」をクリックします。

「Remote Server(s)」に「ip-10-0-6-4.ap-northeast-1.compute.internal」を選択して、「Next」をクリックします。

「Device Type」は「TCP」を選択します。

「Local IP Address(es)」はプライマリDBサーバの「10.0.3.4」を選択します。

「Remote IP Address」はバックアップDBサーバの「10.0.6.4」を選択します。

「Priority」は「1」を選択して下さい。

「Next」をクリックして進めます。

「Done」で完了させます。

ここまでの状態ではコミュニケーションパスがプライマリの1つだけなので、サーバのアイコンに警告マークが表示されています。セカンダリとして2つ目のコミュニケーションパスを設定することで正常な表示に変わります。

先程と同様に「Create Comm Path」のアイコンをクリックしてウィザードを起動します。

「Local Server」「Remote Server」「Device Type 」は先程と同じものを選択します。

「Local IP Address」にeth1の「10.0.12.4」を選択して「Next」をクリックします。

「Remote IP Address」ではバックアップDBサーバのeth1のIP「10.0.14.4」を選択して下さい。

「Priority」は今回は「10」を指定して下さい。「Create」をクリックして完了です。

これで両方のサーバのアイコンが「緑」になりました。

LifeKeeperの設定(IPリソースの作成)

次に「IPリソース」の作成を行います。

VPCはブロードキャストが利用できないので、ブロードキャストPingを無効にします。/etc/default/LifeKeeperのパラメー タNOBCASTPINGの値を0から１に変更します。(両方のサーバで変更して下さい。)

# sed -i -e 's/NOBCASTPING=0/NOBCASTPING=1/g' /etc/default/LifeKeeper

引き続きプライマリ側のLifeKeeperで設定を行います。「Create Resource Hierarchy」のアイコンをクリックします。

「Recovery Kit」で「IP」を選択して下さい。

「Switchback Type」は「intelligent」を選択します。

「Switchback Type」とは、フェイルオーバー発生後、元のサーバが復旧した場合に切り戻す方法の指定です。「intelligent」は手動、「automatic」は自動です。今回はデフォルトの「intelligent」を選択しています。

「Server」は、プライマリDB(ip-10-0-3-4.ap-northeast-1.compute.internal)を選択します。

「IP Resource」は仮想IP「10.1.0.10」を入力して下さい。

「Netmask」は「255.255.255.0」を指定します。

「Network Interface」は仮想IPが関連付く「eth0」を指定して下さい。

「IP Resource Tag」は自動的に入力されたもので構いません。

「Successful」と表示されれば「Next」をクリックします。

このまま作業が続きます。次は「Pre-Extend Wizard」という画面になっています。

最初から「Target Server」にバックアップ側のDBサーバ(ip-10-0-6-4.ap-northeast-1.compute.internal)が指定されているので、そのまま「Next」をクリックして下さい。
選択されていなければ正しいものを指定します。

「Switchback Type」は「intelligent」を選択します。

「Template Priority」は「1」を指定して下さい。

「Target Priority」は「10」を指定して下さい。

「Pre Extend checks were successful」と表示されれば「Next」をクリックして次に進みます。

次は「Extend comm/ip Resource Hierarchy」ウィンドウに変わります。引き続き作業を行います。

「IP Resouce」は仮想IP「10.1.0.10」を指定して下さい。

「Netmask」は「255.255.255.0」を指定します。

「Network Interface」は「eth0」を指定して下さい。

「IP Resource Tag」は自動的に入力されたもので構いません。

「Hierarchy successful extended」と表示されれば「Finish」をクリックします。

「Done」をクリックして完了です。

ここまでの作業でLifeKeeperの画面は以下のようになっています。

EC2 API Toolsのインストールと設定

次に、LifeKeeperからAWSのリソースを操作する為に「EC2 API Tools」を各DBサーバにインストールします。今後のアップデートでIAM Roleへの対応が期待されますね。

尚、LifeKeeperはroot権限で動作するので、rootになり作業を行います。

まずは「EC2 API Tools」をダウンロードします。

# wget http://s3.amazonaws.com/ec2-downloads/ec2-api-tools.zip

解凍します。

# unzip ec2-api-tools.zip

展開したファイル群を/opt/awsにリネームしてください。

# mv ec2-api-tools-1.7.5.1/ /opt/aws/

Java1.8.0をインストールします。

# yum install java-1.8.0-openjdk

次にAPI Toolsに設定する「AWSアクセスキー」と「AWS秘密鍵」を取得する為に「IAM User」を作成します。IAMのマネジメントコンソールで作成します。

ユーザ名は「lifekeeper」として、「Access type」は「Programmatic access」にチェックを入れます。

「Attach existing policies directly」をクリックして既存のポリシーをアタッチします。

今回は「AmazonEC2FullAccess」を付与しました。

問題なければ「Create user」をクリックします。

次の画面で必ずCSVのcredentialファイルをダウンロードしてください。このファイルの中に「AWSアクセスキー」と「AWS秘密鍵」が記載されています。

最後に、下記の内容をrootユーザの~/.bash_profileに追記します。AWS_ACCESS_KEYとAWS_SECRET_KEYは先程ダウンロードしたcredentialファイル内のものを記載して下さい。JAVA_HOMEは実際にインストールされたバージョンに合わせてください。

# AWS EC2 API Tools
export AWS_ACCESS_KEY="XXXXXXXXXXXXXXXXXXXX"
export AWS_SECRET_KEY="XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX"
export JAVA_HOME=/usr/lib/jvm/java-1.8.0-openjdk-1.8.0.XXX-X.bXX.el7_X.x86_64/jre
export EC2_AMITOOL_HOME=/opt/aws
export EC2_HOME=/opt/aws
export EC2_URL="https://ec2.ap-northeast-1.amazonaws.com"
export EC2_REGION="ap-northeast-1"

追記できたら設定を読み込みます。

# source ~/.bash_profile

適当なコマンドを実行して動作確認しておきましょう。

# /opt/aws/bin/ec2-describe-regions

REGION  ap-south-1  ec2.ap-south-1.amazonaws.com
REGION  eu-west-2   ec2.eu-west-2.amazonaws.com
REGION  eu-west-1   ec2.eu-west-1.amazonaws.com
(以下略)

この作業をプライマリ(db-01)とバックアップ(db-02)の両方のDBサーバで実施して下さい。これでEC2 API Toolsのインストールは完了です。

LifeKeeperの設定(EC2リソースの作成)

再びLifeKeeperの設定に戻ります。

これまでと同じように「Create Resource Hierarchy」のアイコンをクリックしてリソース作成を開始します。

「Recovery Kit」は「Amazon EC2」を選択して下さい。

「Switchback Type」は「intelligent」を選択します。

「Server」はプライマリのDBサーバ(ip-10-0-3-4.ap-northeast-1.compute.internal)を指定します。

「EC2 Home」は「/opt/aws」を指定して下さい。

「EC2 URL」は「ec2.ap-northeast-1.amazonaws.com」を指定して下さい。

「AWS Access key」は先程作成したIAM Userのものを入力します。

「AWS Secret key」も同様に入力します。

「EC2 Resource type」では「Route Table (Backend cluster)」を選択して下さい。これによりフェイルオーバー時に仮想IPへのRoute Tableの情報が変更することが可能になります。

「IP resource」は自動入力されたもので構いません。

「EC2 Resource Tag」も自動入力されたものでOKです。

「End of successful Create of...」と表示されれば「Next」をクリックして先に進みましょう。もう少しです。

次は「Pre-Extend」のウィザードです。「Target Server」はバックアップ側のDB(ip-10-0-6-4.ap-northeast-1.compute.internal)を指定して下さい。

「Switchback Type」は「intelligent」を選択します。

「Template Priority」は「1」を指定して下さい。

「Target Priority」は「10」を指定して下さい。

「Pre Extend checks were successful」と表示されれば「Next」をクリックして下さい。

LifeKeeperの設定の最後として「Extend comm/ec2 Resource Hierarchy」ウィンドウに進みます。
「EC2 Resouce Tag」は自動入力されている「ec2-10.1.0.10」を指定して下さい。

「Hierarchy successful extended」と表示されれば「Finish」をクリックします。

最後に「Done」をクリックして完了させます。

追加EBSのパーティション設定

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

ルートボリュームはxvda2で、追加したEBSはxvdbとして認識されています。

# 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

xvdbはまだマウントされていませんが、LifeKeeperによってマウントされます。

# df -h
Filesystem      Size  Used Avail Use% Mounted on
/dev/xvda2       10G  1.5G  8.6G  15% /
devtmpfs        479M     0  479M   0% /dev
tmpfs           496M     0  496M   0% /dev/shm
tmpfs           496M   13M  483M   3% /run
tmpfs           496M     0  496M   0% /sys/fs/cgroup
tmpfs           100M     0  100M   0% /run/user/1000

ちなみに、LifeKeeperでマウントされている状態では下記のようになります。

# lsblk
NAME    MAJ:MIN RM SIZE RO TYPE  MOUNTPOINT
nbd0     43:0    0   8G  0 disk
nbd2     43:2    0   8G  0 disk
nbd3     43:3    0   8G  0 disk
nbd4     43:4    0   8G  0 disk
nbd5     43:5    0   8G  0 disk
nbd6     43:6    0   8G  0 disk
nbd7     43:7    0   8G  0 disk
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
  └─md0   9:0    0   8G  0 raid1 /mnt/DIR1

# df -h
Filesystem      Size  Used Avail Use% Mounted on
/dev/xvda2       10G  2.7G  7.4G  27% /
devtmpfs        479M     0  479M   0% /dev
tmpfs           496M     0  496M   0% /dev/shm
tmpfs           496M   51M  446M  11% /run
tmpfs           496M     0  496M   0% /sys/fs/cgroup
/dev/md0        8.0G  894M  7.2G  11% /mnt/DIR1
tmpfs           100M     0  100M   0% /run/user/1000

それではfdiskでパーティション設定を行います。

# fdisk /dev/xvdb

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キーで進めます。

Last sector, +sectors or +size{K,M,G} (2048-16777215, default 16777215):
そのままEnterキーで進めます。

Command (m for help): w
「w」で書き込みます。

確認します。

# fdisk -l /dev/xvdb

Disk /dev/xvdb: 8589 MB, 8589934592 bytes, 16777216 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk label type: dos
Disk identifier: 0xe577bade

    Device Boot      Start         End      Blocks   Id  System
/dev/xvdb1            2048    16777215     8387584   83  Linux

今回は、ガルーンのデータ保存及びインストールを/mnt/DIR1に行うので、/mnt/DIR1を作成します。

この後、DataKeeperでデータのレプリケーションを行いますが、今回はプライマリ(db-01)、バックアップ(db-02)両サーバの/dev/xvdb1をレプリケーションの対象として、DataKeeperから/mnt/DIR1にマウントさせる形となります。

フェイルオーバーが発生した時は、バックアップ(db-02)のDBサーバ上で、DataKeeperによって/dev/xvdb1が/mnt/DIR1にマウントされます。

# mkdir /mnt/DIR1

XFSでフォーマットします。

# mkfs -t xfs /dev/xvdb1

両方のDBサーバで実行できたら完了です。

DataKeeperの設定

ここからはデータレプリケーションを行う為に、DataKeeperの設定を行っていきます。

改めてここで整理すると、以下のようになります。

• クラスターインスタンス(各DBサーバ)は、/dev/xvdb1を追加EBSとして保持
• DataKeeperが、アクティブなインスタンス上で/dev/xvdb1を/mnt/DIR1にマウント
• /mnt/DIR1上にガルーンをインストール(データ保存先も/mnt/DIR1)
• Appサーバは、DBサーバの/mnt/DIR1をNFSマウント
• DBサーバのフェイルオーバー発生時
  • プライマリ側の/mnt/DIR1のマウントが外れる
  • セカンダリ側の/mnt/DIR1が/dev/xvdb1にマウントされる。(それまではマウントされていない)

それでは設定してみます。

これまでと同じように「Create Resource Hierarchy」のアイコンをクリックしてリソース作成を開始して下さい。

「Ricovery Kit」は「Data Replicatoin」を選択して下さい。

「Switchback Type」は「intelligent」を選択します。

「Server」はプライマリのDBサーバ(ip-10-0-3-4.ap-northeast-1.compute.internal)を指定します。

「Hierarchy Type」は「Replication New Filesystem」を選択して下さい。

「Source Disk」は「/dev/xvdb1 (8.0GB)」を選択して下さい。

そのまま「Continue」で先に進みます。

「New Mount Point」は「/mnt/DIR1」を選択します。

「New Filesystem Type」は「xfs」を選択します。先程フォーマットした種類に合わせてください。

「Data Replication Resouce Tag」は自動入力されている「datarep-DIR1」を指定して下さい。

「File System Resouce Tag」も自動入力されている「/mnt/DIR1」で構いません。

「Bitmap File」も、自動入力されたもの(/opt/LifeKeeper/bitmap__mnt_DIR1)でOKです。

「Enable Asynchronous Replication?」は他のLifeKeeperのドキュメントに合わせて「yes」にしました。適宜選択して下さい。

「Create」を押して作成します。

作成できたら「Next」をクリックして、「Pre-Extend」のウィザードに進みます。

「Target Server」はバックアップ側のDB(ip-10-0-6-4.ap-northeast-1.compute.internal)を指定して下さい。

「Switchback Type」は「intelligent」を選択します。

「Template Priority」は「1」を指定して下さい。

「Target Priority」は「10」を指定して下さい。

作成できたら「Next」をクリックして、「Extend Data Replication Resource Hierarchy」のウィザードに進みます。

「Target Disk」は「/dev/xvdb1 (8.0GB)」を選択します。

[Data Replication Resource Tag]は自動入力されている「datarep-DIR1」のままで構いません。

「Bitmap File」も、自動入力されたもの(/opt/LifeKeeper/bitmap__mnt_DIR1)でOKです。

「Replication Path」は「10.0.12.4/10.0.14.4」を指定して下さい。

「Replication Type」は「asynchronous」を選択しました。適宜選択して下さい。

「Mount point」は「/mnt/DIR1」を選択します。

「Root Tag」は自動入力されたもの(/mnt/DIR1)で構いません。

作成が成功すれば「Finish」をクリックしてください。

[Done]をクリックして完了させます。

ここまでの作業で、LifeKeeperの表示が下記のようになっていることを確認してください。

プライマリDBサーバにガルーンをインストール

LifeKeeperの設定が完了したので、ここでようやくガルーンをインストールします。ガルーンのドキュメントに従い作業は全てrootで行います。

サイボウズ ガルーン バージョン 4.2 インストールガイド

この作業はプライマリ(db-01)で実施します。
バックアップ(db-02)側の作業は別途行いますので、ここではプライマリ側だけの作業であることに注意して下さい。

また、ガルーンは下記の試用版を利用します。ここから「サイボウズ ガルーン 4.2」のLinux(64bit)版をダウンロードします。

試用する（パッケージ版） | サイボウズ ガルーン

今回はサーバから直接インストーラをダウンロードして実行します。インストーラのURLはタイミングによって変わる可能性があるので、上記サイトで確認してから実行して下さい。

# wget http://download.cybozu.co.jp/cbgrn/grn-4.2.0-linux-x64.bin
# sh /tmp/grn-4.2.0-linux-x64.bin

インストーラを実行すると最初に試用許諾契約が表示されます。

スペースキーやEnterキーで一番下までスクロールして全体に目を通します。内容に同意する場合は「yes」を入力します。

インストール識別子を入力します。そのままEnterキーを押してデフォルトの「cbgrn」にします。

使用するMySQLを選択します。「1」はガルーンにバンドルされたMySQLです。こちらが推奨とのことなので「1」を選択して、Enter キーを押します。

ガルーンのプログラムとデータのインストールディレクトリの指定です。DBサーバ上では/mnt/DIR1を指定します。

次に各パスワードの設定です。設定するパスワードは下記の3種類です。
このパスワードはプライマリとバックアップの両方のサーバで同じものを設定して下さい。

• MySQLの管理ユーザのパスワード
• MySQLの接続ユーザのパスワード
• ガルーンの管理者(Administrator)のパスワード

上の2つは「a-z, A-Z, 0-9, _」が使用できます。長さは全て「6文字以上、10文字以内」です。

次に、WebサーバーのCGIディレクトリを指定します。
今、ガルーンをインストールしている対象はDBサーバなのでウェブサーバは使いませんが、最終的にWebサーバからNFSマウントして利用します。ここでは/mnt/DIR1/www/cgi-binを指定します。

Webサーバーのドキュメントルートの指定は、これまでの設定を元に予めセットされるようなので、そのままEnterキーで進めて構いません。

最後に、Webサーバーの実行ユーザー名の指定です。
起動しているプロセスから自動的に判断されたプロセス名がデフォルトになるようです。httpdが起動していなければnobodyと表示されます。今回はインストール時にApacheが起動していたので、そのままapacheとしました。

(DBサーバの場合は、Apacheは不要なので、この後httpdプロセスの停止と自動起動の無効化をしておきましょう)

最後にこれまで設定した内容が表示されます。問題なければ「yes」を入力します。

インストールが完了すると、完了の表示やガルーンのログインURL等が表示されます。
このログインURLはインストーラで一意に表示されているようなので、適宜読み替えて下さい。

ガルーンのインストールが完了したら、MySQLとガルーンのスケジューリングサービスを停止します。

# /etc/init.d/cyss_cbgrn stop
# /etc/init.d/cyde_5_0 stop

また、インストール時に自動起動の設定が有効化されるので、これも無効にしておきます。
ガルーンの関連プロセスの制御はLifeKeeperが行ってくれるので問題ありません。

# chkconfig cyde_5_0 off
# chkconfig cyss_cbgrn off

次にAppサーバからNFSマウントできるようにNFSサーバをセットアップします。

まず下記の内容で/etc/exportsを作成します。

/mnt/DIR1/www/cgi-bin/cbgrn/sessiondata 10.0.2.0/24(rw) 10.0.5.0/24(rw)
/mnt/DIR1/cybozu/mysql-5.0/files 10.0.2.0/24(rw) 10.0.5.0/24(rw)

次にNFSサーバをセットアップします。

# yum -y install nfs-utils
# systemctl enable nfs-server
# systemctl start nfs-server

確認します。

# exportfs -v

/mnt/DIR1/www/cgi-bin/cbgrn/sessiondata
        10.0.2.0/24(rw,sync,wdelay,hide,no_subtree_check,sec=sys,secure,root_squash,no_all_squash)
/mnt/DIR1/www/cgi-bin/cbgrn/sessiondata
        10.0.5.0/24(rw,sync,wdelay,hide,no_subtree_check,sec=sys,secure,root_squash,no_all_squash)
/mnt/DIR1/cybozu/mysql-5.0/files
        10.0.2.0/24(rw,sync,wdelay,hide,no_subtree_check,sec=sys,secure,root_squash,no_all_squash)
/mnt/DIR1/cybozu/mysql-5.0/files
        10.0.5.0/24(rw,sync,wdelay,hide,no_subtree_check,sec=sys,secure,root_squash,no_all_squash)

バックアップDBサーバにガルーンをインストール

次にバックアップ側のDBサーバにガルーンをインストールします。

その為にまずは、LifeKeeper上でバックアップ側がアクティブになるように、手動でフェイルオーバーを実行してリソースを切り替えます。

下記の様にバックアップ側のリソース上で右クリックして「In Service」を選択して下さい。「/mnt/DIR1」と「ip-10.1.0.10」の両方を「In Service」にします。

ちなみに、左側のメニューの「Herarchies」の上位階層のリソースを切り替えると下位のリソースも自動的に切り替わります。今回の場合だと最上位階層に「/mnt/DIR1」と「ip-10.1.0.10」の2つが存在するので、どちらにも切替作業が必要でした。
最上位階層に1つだけしかリソースが無い場合は、そのリソースを切り替えることで全て変更する事ができます。(後で階層構造を整理します。)

切替が完了したら下記のように、Active/Standbyが全て入れ替わります。

それではバックアップ側(db-02)にガルーンをインストールしていきます。

先程の切替時にdb-02で/dev/xvdb1が/mnt/DIR1にマウントされてデータレプリケーションが走ります。その為、db-01側のガルーンのプログラム等のファイルがdb-02に存在するので、これを削除します。

# rm -fr /mnt/DIR1/cybozu /mnt/DIR1/www
# mkdir -p /mnt/DIR1/www/html /mnt/DIR1/www/cgi-bin

ガルーンをインストールします。インストール方法は先程プライマリのDBサーバにインストールした方法と全く同じです。
インストールが完了したらガルーンの関連サービスを停止して、自動起動も無効化します。

# /etc/init.d/cyss_cbgrn stop
# /etc/init.d/cyde_5_0 stop

# chkconfig cyde_5_0 off
# chkconfig cyss_cbgrn off

また、/etc/exportsに下記を設定します。プライマリ側の設定と同じです。

/mnt/DIR1/www/cgi-bin/cbgrn/sessiondata 10.0.2.0/24(rw) 10.0.5.0/24(rw)
/mnt/DIR1/cybozu/mysql-5.0/files 10.0.2.0/24(rw) 10.0.5.0/24(rw)

最後にNFSサーバをセットアップしましょう。これもプライマリ側と全く同じ手順です。

# yum -y install nfs-utils
# systemctl enable nfs-server
# systemctl start nfs-server

確認します。

# exportfs -v

/mnt/DIR1/www/cgi-bin/cbgrn/sessiondata
        10.0.2.0/24(rw,sync,wdelay,hide,no_subtree_check,sec=sys,secure,root_squash,no_all_squash)
/mnt/DIR1/www/cgi-bin/cbgrn/sessiondata
        10.0.5.0/24(rw,sync,wdelay,hide,no_subtree_check,sec=sys,secure,root_squash,no_all_squash)
/mnt/DIR1/cybozu/mysql-5.0/files
        10.0.2.0/24(rw,sync,wdelay,hide,no_subtree_check,sec=sys,secure,root_squash,no_all_squash)
/mnt/DIR1/cybozu/mysql-5.0/files
        10.0.5.0/24(rw,sync,wdelay,hide,no_subtree_check,sec=sys,secure,root_squash,no_all_squash)

マスター側DBサーバのアクティブ化

バックアップ側にガルーンをインストールできたら再度、手動でフェイルオーバーを実行してプライマリ側をActiveに戻します。手順は先程と同じなので割愛します。

ガルーン用Generic ARKスクリプトのインストール

LifeKeeperには、標準で「Apache」や「Oracle」など色々なRecovery Kitが用意されていますが、ガルーン用のRecovery Kitも存在します。ただしこれは標準のパッケージには含まれていないので、今回はサイオステクノロジー様からご提供頂いたものを利用します。

ガルーン用Generic ARKスクリプトには、下記の2種類が存在します。今回は「サーバ分離構成」が該当するので「Garoon_single」をプライマリ側のDBサーバに保存します。

• DB分割構成バージョン(Garoon_dbpart)
• その他の構成バージョン(Garoon_single)
  • 単体構成
  • サーバ分離構成
  • 単体+全文検索サーバ構成

「Garoon_single」のファイル構成は下記のようになっており、mk_scripts.shがインストーラです。インストーラの実行には配下のファイル群が必要なので、頂いたディレクトリをそのままサーバに保存するようにしましょう。

/root/Garoon_single
|--Garoon-HAGuide_single.pdf
|--mk_scripts.sh
|--scripts
|  |--cyde_5_0
|  |  |--quickCheck
|  |  |--recover
|  |  |--remove
|  |  |--restore
|  |--cyss_cbgrn
|  |  |--quickCheck
|  |  |--recover
|  |  |--remove
|  |  |--restore
|--templates
|  |--quickCheck
|  |--recover
|  |--remove
|  |--restore

上記の「mk_scripts.sh」を実行してインストールします。

# cd /root/Garoon_single
# ./mk_scripts.sh

Cybozu Garoon Generic Application Scripts are created successfully!
Please use the scripts under 'scripts' directory.

mk_scripts.shを実行すると上記のように「Please use the scripts under 'scripts'directory.」と出力されます。メッセージ通りmk_scripts.shと同じ階層に「scripts」ディレクトリが生成され、その中にガルーン用Generic ARKリソース作成に使用するスクリプトが生成されます。

/root/Garoon_single/scripts
|--cyde_5_0
|  |--quickCheck
|  |--recover
|  |--remove
|  |--restore
|--cyss_cbgrn
|  |--quickCheck
|  |--recover
|  |--remove
|  |--restore

Cybozu Database Engineサービスのリソース作成

再びLifeKeeperでの作業になります。これまでと同じようにリソース作成ウィザードから行います。

「Recovery Kit」は「Generic Application」を選択して下さい。

「Switchback Type」は「intelligent」を選択します。

「Server」はプライマリのDBサーバ(ip-10-0-3-4.ap-northeast-1.compute.internal)を指定します。

「Restore Script」は/root/Garoon_single/scripts/cyde_5_0/restoreを指定します。
これは先程/root/Garoon_single/scriptsに生成したスクリプトの1つです。以後、順次これらのスクリプトを指定していきます。

「Remove Script」は/root/Garoon_single/scripts/cyde_5_0/removeを指定します。

「QuickCheck Script(optional)」は/root/Garoon_single/scripts/cyde_5_0/quickCheckを指定します。

「Local Recovery Script(optional)」は/root/Garoon_single/scripts/cyde_5_0/revoverを指定して下さい。

次の「Application Info(optional)」は空欄で構いません。

「Bring Resource In Service」は「Yes」を選択して下さい。

「Resource Tag」は自動入力の「cyde_5_0」のままで構いません。このまま「Create Instance」をクリックします。

問題なく完了したら「Next」をクリックして「Pre-Extend」ウィザードに進んで下さい。

「Target Server」はバックアップ側のDB(ip-10-0-6-4.ap-northeast-1.compute.internal)を指定して下さい。

「Switchback Type」は「intelligent」を選択します。

「Template Priority」は「1」を指定して下さい。

「Target Priority」は「10」を指定して下さい。

成功したら「Next」をクリックして「Extend gen/app Resource Hierarchy」ウィンドウに進んで下さい。

「Resouce Tag」は自動入力の「cyde_5_0」のままで構いません。

次の「Application Info(optional)」は空欄で構いません。

完了したら「Finish」をクリックします。

「Done」をクリックして終了します。

ここまでで下記のように「cyde_5_0」のリソース表示が増えていることを確認します。

Cybozu Scheduling Serviceサービスのリソース作成

同様にLifeKeeperのウィザードから「Cybozu Scheduling Serviceサービスのリソース」を追加していきます。
後もう少しです。

「Recovery Kit」は「Generic Application」を選択します。

「Switchback Type」は「intelligent」を選択します。

「Server」はプライマリのDBサーバ(ip-10-0-3-4.ap-northeast-1.compute.internal)を指定します。

「Restore Script」はスケジューリングサービス用のスクリプト/root/Garoon_single/scripts/cyss_cbgrn/restoreを指定します。

「Remove Script」は/root/Garoon_single/scripts/cyss_cbgrn/removeです。

「QuickCheck Script(optional)」は/root/Garoon_single/scripts/cyss_cbgrn/quickCheckを指定します。

「Local Recovery Script(optional)」は/root/Garoon_single/scripts/cyss_cbgrn/revoverを指定して下さい。

次の「Application Info(optional)」は空欄で構いません。

「Bring Resource In Service」は「Yes」を選択して下さい。

「Resource Tag」は自動入力の「cyss_cbgrn」のままで構いません。このまま「Create Instance」をクリックします。

問題なく完了したら「Next」をクリックして「Pre-Extend」ウィザードに進んで下さい。

「Target Server」はバックアップ側のDB(ip-10-0-6-4.ap-northeast-1.compute.internal)を指定して下さい。

「Switchback Type」は「intelligent」を選択します。

「Template Priority」は「1」を指定して下さい。

「Target Priority」は「10」を指定して下さい。

成功したら「Next」をクリックして「Extend gen/app Resource Hierarchy」ウィンドウに進んで下さい。

「Resouce Tag」は自動入力の「cyss_cbgrn」のままで構いません。

次の「Application Info(optional)」は空欄で構いません。

完了したら「Finish」をクリックします。

「Done」をクリックして終了します。

LifeKeeper上に「cyss_cgrn」のリソースが表示されていればOKです。

LifeKeeperのリソース階層の修正

最後にLifeKeeperのリソース階層を上から順に下記の様に修正します。

1. IPリソース
2. EC2リソース
3. ガルーンスケジューリングサービス用Generic ARKリソース
4. ガルーンデータベースエンジン用Generic ARKリソース
5. ファイルシステムリソース

ファイルシステムリソースは「/mnt/DIR1リソース」と「datarep-DIR1リソース」を1つのリソースとして扱って下さい。

最終的に下記のような構成にします。

階層の変更方法は簡単です。変更したいリソースを選択して、直下に入れたいリソースを指定するだけです。
下記の例は「cyss_cbgrn」の下に「/mnt/DIR1」のリソースが配置されるように指定しています。

直下に入れたいリソースを選択します。

「Create Depedency」をクリックします。

これを繰り返して、階層を整えて下さい。

Appサーバの構築

次にAppサーバを構築します。全てのAppサーバで共通なので作業後にAMIを作成して展開するとよいでしょう。
内容の半分くらいはDBサーバと同じ作業をすることになります。

ガルーンに必要なパッケージのインストール

ガルーンの動作に必要な各種パッケージをインストールします。

yum -y install httpd libaio libjpeg-turbo libpng perl perl-Data-Dumper wget unzip

ガルーンではApacheの「KeepAlive」設定を無効にする必要がある為、/etc/httpd/conf/httpd.confに下記を追記します。

KeepAlive Off

Apacheの自動起動を設定しておきます。

# systemctl enable httpd.service
Created symlink from /etc/systemd/system/multi-user.target.wants/httpd.service to /usr/lib/systemd/system/httpd.service.

# systemctl is-enabled httpd
enabled

まだApacheは起動しないで下さい。

SELinuxとfirewalldの無効化

ガルーンのドキュメントに従い、SELinuxを無効化します。

# sed -i -e 's/enforcing/disabled/g' /etc/selinux/config

設定を反映させる為、再起動します。

# reboot

再起動が完了したらSElinuxの状態を確認します。getenforceの結果がDisabledであることを確認します。

$ getenforce
Disabled

次にfirewalldが起動しているのでこれを停止します。

# systemctl status firewalld

自動起動設定も無効化します。

# systemctl disable firewalld

ガルーンのインストール

次にガルーンのインストーラをダウンロードしてインストールします。

# wget http://download.cybozu.co.jp/cbgrn/grn-4.2.0-linux-x64.bin
# sh /tmp/grn-4.2.0-linux-x64.bin

全てデフォルトのままで問題ありません。

すべてのAppサーバーで、ガルーンのサービスを停止します。 最初にスケジューリングサービスを停止します。

# /etc/init.d/cyss_cbgrn stop

次にバンドルのMySQLを停止します。

# /etc/init.d/cyde_5_0 stop

Appサーバ上では、ガルーンを利用しないので自動起動も無効化にします。

# systemctl disable cyde_5_0
# systemctl disable cyss_cbgrn

ガルーンの設定変更

次にガルーンのDB設定を変更します。デフォルトではローカル上のMySQLを参照するので、これをDBサーバに変更します。
設定ファイルは/var/www/cgi-bin/cbgrn/lwc.iniです。ポイントは仮想IP「10.1.0.10」を指定する点です。

prop:_host = "val:127.0.0.1:3770"
↓
prop:_host = "val:10.1.0.10:3770"

データ保存領域の権限を修正します。

# chmod -R 000 /var/www/cgi-bin/cbgrn/sessiondata
# chmod -R 000 /usr/local/cybozu/mysql-5.0/files

NFSの設定

DBサーバに対して上記をNFSマウントするので、NFSユーティリティをインストールします。

# yum -y install nfs-utils
# systemctl start rpcbind.service
# systemctl start nfs-lock.service

自動起動を有効化しておきましょう。

# systemctl enable rpcbind
# systemctl enable nfs-lock

マウントします。IPは仮想IPを指定します。

mount -o intr,noac 10.1.0.10:/mnt/DIR1/www/cgi-bin/cbgrn/sessiondata /var/www/cgi-bin/cbgrn/sessiondata
mount -o intr 10.1.0.10:/mnt/DIR1/cybozu/mysql-5.0/files /usr/local/cybozu/mysql-5.0/files

確認します。

# mount -l |grep "10.1.0.10"

10.1.0.10:/mnt/DIR1/www/cgi-bin/cbgrn/sessiondata on /var/www/cgi-bin/cbgrn/sessiondata type nfs4 (rw,relatime,sync,vers=4.1,rsize=131072,wsize=131072,namlen=255,acregmin=0,acregmax=0,acdirmin=0,acdirmax=0,hard,noac,proto=tcp,port=0,timeo=600,retrans=2,sec=sys,clientaddr=10.0.2.5,local_lock=none,addr=10.1.0.10)
10.1.0.10:/mnt/DIR1/cybozu/mysql-5.0/files on /usr/local/cybozu/mysql-5.0/files type nfs4 (rw,relatime,vers=4.1,rsize=131072,wsize=131072,namlen=255,hard,proto=tcp,port=0,timeo=600,retrans=2,sec=sys,clientaddr=10.0.2.5,local_lock=none,addr=10.1.0.10)

/etc/fstabに下記を追記しておきましょう。

10.1.0.10:/mnt/DIR1/www/cgi-bin/cbgrn/sessiondata /var/www/cgi-bin/cbgrn/sessiondata nfs intr,noac 0 0
10.1.0.10:/mnt/DIR1/cybozu/mysql-5.0/files /usr/local/cybozu/mysql -5.0/files nfs intr 0 0

Apacheを起動します。

# systemctl start httpd

動作確認

これで環境構築の全ての作業が完了しました。プライマリに異常が発生した際にフェイルオーバーできるかどうか確認してみたいと思います。

テスト内容

テスト内容は以下です。

• ブラウザでガルーンにアクセスして変更を実施
  • テスト用のテキストファイルをメモに添付
• プライマリ側で擬似的な障害を発生
  • プライマリ側のNICを停止
• フェイルオーバー後にブラウザでガルーンにアクセスして確認
  • メモの添付ファイルが見れることを確認

それでは、オンプレ側からガルーンにアクセスします。アクセスするURLはプライベート用ドメインのhttp://elb.garoon-internal.local/cgi-bin/cbgrn/grn.cgiです。

ガルーンインストール時に設定したパスワードでログインします。

メニューにある「Memo」をクリックして「test.txt」というファイル添付します。

ファイルの中身は単なるテキストファイルです。

また、事前にVPCの「Route Table」の内容を確認しておきます。
下記の通り、仮想IP「10.1.0.10/32」宛のトラフィックがプライマリサーバ「db-01」の「eth0」のENIに向いています。これがフェイルオーバーによりセカンダリサーバ「db-02」の「eth0」に向きが変わればOKという訳です。

疑似障害を起こす前に、バックアップ側のLifeKeeperのGUIを起動しておきます。疑似障害を起こすとプライマリ側のLifeKeeperにアクセスできなくなり、GUIが落ちる為です。

手順はプライマリ側のLifeKeeperのGUIにアクセスする方法と同じです。

Windows Serverの踏み台サーバにRDPでログオンして、Teratermでバックアップ側DBサーバ(db-02)にSSHログインします。ec2-userユーザでログイン後にrootにスイッチして下さい。

次に、LifeKeeper GUIを起動します。

# /opt/LifeKeeper/bin/lkGUIup

プライマリ側の時と同じですが、GUIを起動する時は、ログインしたユーザーの環境変数と認証情報、GUI画面を起動したユーザーの環境変数と認証情報を一致させておく必要があります。次のコマンドの結果が一致していることを確認して下さい。

$ echo $DISPLAY
# echo $DISPLAY
$ xauth list
# xauth list

一致していない場合、以下のコマンドでログインユーザー側の情報と一致させてください。

# export DISPLAY=[ログインユーザーの＄DISPLAYの出力結果]
# xauth add [ログインユーザーのxauth listの出力結果]

セカンダリ側のLifeKeeper GUIの表示は以下のように、プライマリサーバとセカンダリサーバの表示が左右逆になっています。

それでは、プライマリのサーバ(db-01)で下記のコマンドを実行してNICを停止します。

# systemctl stop network

プライマリサーバとの疎通が取れなくなったので、画面が下記のように変わります。

VPCの「Route Table」を確認してみます。 下記の通り、仮想IP「10.1.0.10/32」宛のトラフィックがセカンダリサーバ「db-02」の「eth0」のENIに向くように変わっています。これでLifeKeeperによってルーティングが変更されたことが分かります。

次にガルーンを確認してみます。先程と同じURLでガルーンにアクセスしてみます。プライマリ側のNICが止まっていますが、正常に「Memo」の添付ファイルtest.txtを確認することが出来ました。

元に戻す場合は、セカンダリDBサーバを再起動させてから、LifeKeeper上で手動で切替を実行して下さい。

「In Service」をクリックします。

切り替えが開始されます。

徐々に切り替えが進みます。

「Done」をクリックして完了です。

元のActive/Standby状態に戻りました。

参考ドキュメント

今回の環境を構築するにあたり、下記のドキュメントをそれぞれ参考にさせて頂きました。

サイボウズガルーンのドキュメント

ガルーンのインストールや基本的な仕組みについては、下記のドキュメントを参考にしました。

サイボウズ ガルーン バージョン 4.2 インストールガイド

LifeKeeperのドキュメント

LifeKeeperの設定やAWS環境の構成については、「SIOS Protection Suite for Linux Step by Step Guide【AWS編】」というドキュメントを参考にしています。DataKeeperやガルーン冗長化の設定部分は異なりますが、LifeKeeperの設定までは概ね同じ手順になるかと思います。

このドキュメントは下記よりダウンロードが可能です。

サイオステクノロジー株式会社：資料のダウンロード

ガルーン環境でのLifeKeeper利用については、下記ドキュメントのP.23「第4章 サーバ分離構成における構築手順」を参考にしています。こちらの手順は共有ディスクを利用した構成になっているので、その点を考慮する必要があります。

LifeKeeper for Linux サイボウズ ガルーン 冗長化構成ガイド [単体構成 / サーバ分離構成 / 単体〒全文検索サーバ構成] 第3版

最後に

随分と長いエントリになりましたが、いかがだったでしょうか？
今回は触れていませんが、保護対象のプロセスを停止させただけではフェイルオーバーを実行せずに、LifeKeeperによるプロセス再起動で復旧させることも出来ました。

対象のアプリケーションによって、作業する順番などを注意する必要がありますが、設定がGUIでできるのは便利だと思います。

また、AWSにも標準で対応しているので、どうしてもActive/Standby環境をAWS上で用意する必要がある場合、強力な選択肢になるのではないかと思います。

以上です。