Japan

サイト内の現在位置を表示しています。

クラスタ構成情報ファイル生成コマンドでHAクラスターをAWSに移行してみました(Linux)

CLUSTERPRO オフィシャルブログ ～クラブロ～
  • Share

はじめに

サーバーやネットワークなどのインフラ環境を構築する方法にInfrastructure as Code(以降、IaC)というインフラの構成や設定をコード化して管理し、環境構築の自動化を行う手法があります。

CLUSTERPROでは、IaCによるインフラ構築を実現するためのコマンドラインツールを用意しています。今回は、オンプレミス環境(Linux)で構築したクラスタ構成情報ファイルをAmazon Web Services(以降、AWS)環境で利用できるように変更する方法についてご紹介します。

クラスタ構成情報ファイル生成コマンドの解説や基本的な利用方法について、Windows環境における構築手順は以下をご参照ください。

この記事の内容

1. クラスタ構成情報ファイル生成コマンドについて

本記事では、オンプレミス環境で作成したHAクラスターのクラスタ構成情報ファイル(以降、clp.conf)から、AWS環境で動作するHAクラスターのclp.confを作成する手順を紹介します。
クラスタ構成情報ファイル生成コマンド(以降、clpcfadm.py)の詳細に関しては以下をご参照ください。

【参考】
  • CLUSTERPRO X 5.2 > Linux > クラスタ構築コマンドリファレンスガイド
    →第 2 章 コマンドリファレンス
      →2.1 clpcfadm.py コマンド

2. HAクラスター構成と構成情報の変更点

変更元となるオンプレミス環境と変更先となるAWS環境のHAクラスター構成は以下のとおりです。AWS環境ではフローティングIPリソースは利用できないため、AWS仮想IPリソースを利用したHAクラスター構成に変更します。AWS環境でのHAクラスターの構築に関しては、以下のガイドもご参照ください。

【参考】
  • Linux > クラウド > Amazon Web Services > CLUSTERPRO X 5.2 向け HAクラスタ 構築ガイド

クラスタ構成図zoom拡大表示

環境の主な変更点は以下のとおりです。変更点以外のパラメータや利用しているOSは原則としてオンプレミス環境とAWS環境で共通とします。

  • AWS環境では10.0.0.0/16のIPアドレス範囲からクラスターにアクセスするため、インタコネクトおよびMDCのIPアドレスを修正し、不要になったIPを削除
  • フローティングIPリソースはAWS上では利用できないため削除
  • フローティングIPリソースの削除にあわせてフローティングIPモニタリソースを削除
  • フローティングIPリソースの代わりにAWS仮想IPリソースを新規追加
  • AWS仮想IPリソースを監視するためにAWS仮想IPモニタリソースを新規追加
  • オンプレミス環境からAWS環境に移行することでディスクのデバイスファイル名が変更されるため、ミラーディスクリソースのデバイスファイル名を変更

オンプレミス環境のclp.confから変更する項目の一覧は以下のとおりです。なお、オンプレミス環境で構築したHAクラスターのclp.conf(ZIP形式)は、オンプレミス環境のCluster WebUIに設定モードでアクセスし、「設定のエクスポート」を実行することで入手可能です。

 項目名  リソース名  変更内容
 クラスター  cluster1  変更なし
 サーバー  server01,server02  変更なし
 インタコネクト  lan0  IPアドレスを変更
 lan1  削除
 ミラーディスクコネクト(MDC)  mdc0  IPアドレスを変更
 mdc1  削除
 LANハートビート  lankhb0  変更なし
 lankhb1  削除
 フェールオーバーグループ  failover1  変更なし
 フローティングIPリソース  fip1  削除
 AWS仮想IPリソース  awsvip1  新規追加
 ミラーディスクリソース  md1  ミラーディスクのデバイスファイル名を変更
 EXECリソース  exec1  変更なし
 フローティングIPモニタリソース  fipw1  削除
 AWS仮想IPモニタリソース  awsvipw1  新規追加
 ミラーディスクモニタリソース  mdw1  変更なし
 ミラーディスクコネクトモニタリソース  mdnw1  変更なし
 カスタムモニタリソース  genw1  変更なし
 ユーザ空間モニタリソース  userw1  変更なし

3. HAクラスター移行手順

3.1 事前準備

オンプレミス環境からAWS環境への移行時にCLUSTERPROのバージョンアップも行う場合は、clpcfadm.pyを実行する前にclp.confを変換する必要があります。CLUSTERPRO X 5.x向けのclp.confの変換にはクラスタ構成情報変換コマンドを実行します。コマンドの利用方法については以下をご参照ください。

【参考】
  • CLUSTERPRO X 5.2 > Linux > スタートアップガイド
    →第 7 章 アップグレード手順
      →7.1.1 X 3.3/4.x から X 5.2 へのアップグレード

オンプレミス環境のclp.confから変更する項目であるAWS仮想IPリソースで利用するVPC IDとENI ID、ミラーディスクリソースで利用するデバイスファイル名を事前に確認します。

AWS環境では以前公開したpopupクラウド環境でLinuxのミラーディスク型クラスターを構築する際の注意ポイントの記事にあるように、運用中にデバイスファイル名が変更される可能性があるため、今回はハードウェアのシリアル番号に基づいて一意な名前が作成されるby-idを利用します。

VPC IDやENI ID、by-idなどの確認方法は以下のとおりです。

  • 1.
    AWSマネジメントコンソールにアクセスし、サービスからVPCを選択します。
  • 2.
    左メニューからお使いのVPCを選択し、表示されるVPCの中から利用するVPC IDを確認します。
  • 3.
    AWSマネジメントコンソールのサービスからEC2を選択します。
  • 4.
    左メニューからネットワークインターフェースを選択し、表示されるネットワークインターフェースの中から利用するネットワークインターフェース ID(ENI ID)を確認します。
  • 5.
    server01、server02にそれぞれログインします。
  • 6.
    以下のコマンドを入力して、クラスタパーティション、データパーティションを作成したデバイス名を確認します。コマンドの実行例は該当箇所のみを抜粋しています。

# lsblk
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
NMP1 218:1 0 4G 0 disk
nvme1n1 259:1 0 5G 0 disk
├─nvme1n1p1 259:4 0 1G 0 part  ★クラスタパーティション
└─nvme1n1p2 259:5 0 4G 0 part  ★データパーティション

  • 7.
    以下のコマンドを入力してクラスタパーティション、データパーティションを作成したデバイス名に対応するby-idを確認します。コマンドの実行例は該当箇所のみを抜粋しています。

# ls -l /dev/disk/by-id
total 0
lrwxrwxrwx 1 root root 13 Jul 25 02:10 nvme-Amazon_Elastic_Block_Store_vol1234567890abcdefg-> ../../nvme1n1
lrwxrwxrwx 1 root root 15 Jul 25 05:06 nvme-Amazon_Elastic_Block_Store_vol1234567890abcdefg-part1 -> ../../nvme1n1p1 ★クラスタパーティション
lrwxrwxrwx 1 root root 15 Jul 25 04:42 nvme-Amazon_Elastic_Block_Store_vol1234567890abcdefg-part2 -> ../../nvme1n1p2 ★データパーティション

3.2 clpcfadm.pyによるclp.confの変更

clpcfadm.pyでclp.confを変更する手順は以下のとおりです。

  • 1.
    server01にログインします。
  • 2.
    オンプレミス環境で作成したclp.confをAWS環境にコピーします。今回は「/tmp/clusterpro/」にclp.confを格納します。
  • 3.
    clpcfadm.pyを実行するため、clp.confを格納したフォルダーに移動します。

# cd /tmp/clusterpro/

  • 4.
    clpcfadm.pyコマンドのmodオプションを実行し、オンプレミス環境で作成したclp.confがAWS環境でも読み書き可能か確認します。clp.confを正しく読み込めていれば、clp.conf内の設定値が一覧で表示されます。
    (以降の各コマンドについては、root権限を持つユーザーで実行します。)

# clpcfadm.py mod -t
all
cluster
group@failover1
heartbeat
messages
monitor
networkpartition [None]
pm
resource
rm
server@server01
server@server02
servergroup
webalert
webmgr

コマンドの実行結果に「Invalid config file」と表示された場合は、clp.confを正しく読み取れていません。

# clpcfadm.py mod -t
Invalid config file. Use the 'create' option.

「Invalid config file」メッセージが表示された場合は以下の項目の確認、または、Cluster WebUIの「設定のエクスポート」を実行して再度clp.confを入手してください。

  • clp.confの設定値が文字化けしていないかどうか
  • clp.confの設定値にマルチバイト文字が含まれていないかどうか
  • clp.confの設定値の入力ミス、XMLタグの閉じ忘れなど記載に誤りがないかどうか
  • 5.
    以下のコマンドを実行してclp.confを変更します。変数を定義する部分のVPCID、ENIID、CLUSTERPARTITION、DATAPARTITIONに関しては事前準備で確認した値を設定してください。

# 変数を定義
FAILOVERNAME="failover1"
SERVER1NAME="server01"
SERVER2NAME="server02"
SERVER1IPADDRESS1="10.0.110.100"
SERVER2IPADDRESS1="10.0.120.100"
AWSVIP="172.16.0.1"
VPCID="vpc-1234567890abcdefg"
SERVER1ENIID="eni-1234567890abcdefg"
SERVER2ENIID="eni-abcdefg1234567890"
MOUNTPOINT="/mnt/mirror"
SERVER1CLUSTERPARTITION="/dev/disk/by-id/nvme-Amazon_Elastic_Block_Store_vol1234567890abcdefg-part1"
SERVER1DATAPARTITION="/dev/disk/by-id/nvme-Amazon_Elastic_Block_Store_vol1234567890abcdefg-part2"
SERVER2CLUSTERPARTITION="/dev/disk/by-id/nvme-Amazon_Elastic_Block_Store_volabcdefg1234567890-part1"
SERVER2DATAPARTITION="/dev/disk/by-id/nvme-Amazon_Elastic_Block_Store_volabcdefg1234567890-part2"

# インタコネクト(lan0)の修正
clpcfadm.py mod -t server@$SERVER1NAME/device@0/info --set $SERVER1IPADDRESS1
clpcfadm.py mod -t server@$SERVER2NAME/device@0/info --set $SERVER2IPADDRESS1

# インタコネクト(lan1)の削除
clpcfadm.py del device $SERVER1NAME 1
clpcfadm.py del device $SERVER2NAME 1

# MDC(mdc0)の修正
clpcfadm.py mod -t server@$SERVER1NAME/device@400/info --set $SERVER1IPADDRESS1
clpcfadm.py mod -t server@$SERVER2NAME/device@400/info --set $SERVER2IPADDRESS1
clpcfadm.py mod -t server@$SERVER1NAME/device@400/mdc/info --set $SERVER1IPADDRESS1
clpcfadm.py mod -t server@$SERVER2NAME/device@400/mdc/info --set $SERVER2IPADDRESS1

# MDC(mdc1)の削除
clpcfadm.py del device $SERVER1NAME 401
clpcfadm.py del device $SERVER2NAME 401
clpcfadm.py mod -t resource/md@md1/parameters/netdev@1/device --delete
clpcfadm.py mod -t resource/md@md1/parameters/netdev@1/mdcname --delete
clpcfadm.py mod -t resource/md@md1/parameters/netdev@1/priority --delete

# LANハートビート(lankhb1)の削除
clpcfadm.py del hb lankhb 1

# フローティングIPリソースの削除
clpcfadm.py del rsc $FAILOVERNAME fip fip1

# AWS仮想IPリソースの追加
clpcfadm.py add rsc $FAILOVERNAME awsvip awsvip1

# AWS仮想IPリソースに仮想IPアドレスを追加
clpcfadm.py mod -t resource/awsvip@awsvip1/parameters/ip --set $AWSVIP

# AWS仮想IPリソースに共通のVPCとENIの値を追加
clpcfadm.py mod -t resource/awsvip@awsvip1/parameters/vpcid --set $VPCID
clpcfadm.py mod -t resource/awsvip@awsvip1/parameters/eniid --set $SERVER1ENIID

# AWS仮想IPリソースにserver01およびserver02のVPCとENIの値を追加
clpcfadm.py mod -t resource/awsvip@awsvip1/server@$SERVER1NAME/parameters/vpcid --set $VPCID --nocheck
clpcfadm.py mod -t resource/awsvip@awsvip1/server@$SERVER1NAME/parameters/eniid --set $SERVER1ENIID --nocheck
clpcfadm.py mod -t resource/awsvip@awsvip1/server@$SERVER2NAME/parameters/vpcid --set $VPCID --nocheck
clpcfadm.py mod -t resource/awsvip@awsvip1/server@$SERVER2NAME/parameters/eniid --set $SERVER2ENIID --nocheck

# クラスターパーティション、データパーティションのデバイス名を変更
clpcfadm.py mod -t resource/md@md1/parameters/diskdev/cppath --set $CLUSTERPARTITION --nocheck
clpcfadm.py mod -t resource/md@md1/parameters/diskdev/dppath --set $DATAPARTITION --nocheck

# server01およびserver02にマウントポイントとクラスターパーティション、データパーティションのデバイス名を追加
clpcfadm.py mod -t resource/md@md1/server@$SERVER1NAME/parameters/mount/point --set $MOUNTPOINT --nocheck
clpcfadm.py mod -t resource/md@md1/server@$SERVER1NAME/parameters/diskdev/cppath --set $SERVER1CLUSTERPARTITION --nocheck
clpcfadm.py mod -t resource/md@md1/server@$SERVER1NAME/parameters/diskdev/dppath --set $SERVER1DATAPARTITION --nocheck
clpcfadm.py mod -t resource/md@md1/server@$SERVER2NAME/parameters/mount/point --set $MOUNTPOINT --nocheck
clpcfadm.py mod -t resource/md@md1/server@$SERVER2NAME/parameters/diskdev/cppath --set $SERVER2CLUSTERPARTITION --nocheck
clpcfadm.py mod -t resource/md@md1/server@$SERVER2NAME/parameters/diskdev/dppath --set $SERVER2DATAPARTITION --nocheck

# フローティングIPモニタリソース(fipw1)の削除
clpcfadm.py del mon fipw fipw1

# AWS仮想IPモニタリソース(awsvipw1)の追加
clpcfadm.py add mon awsvipw awsvipw1
clpcfadm.py mod -t monitor/awsvipw@awsvipw1/target --set awsvip1
clpcfadm.py mod -t monitor/awsvipw@awsvipw1/relation/type --set rsc --nocheck
clpcfadm.py mod -t monitor/awsvipw@awsvipw1/relation/name --set awsvip1 --nocheck

上記コマンドの実行が完了したら、clp.confの変更は完了です。

なお、コマンドのサンプルは以下のリンクよりダウンロード可能です。また、サンプルは動作を保証するものではありません。

ZIPスクリプトファイル

3.3 clp.confの反映

生成したclp.confをサーバーに反映する手順は以下のとおりです。
(以降の各コマンドについては、root権限を持つユーザーで実行します。)

  • 1.
    server01にログインします。
  • 2.
    以下のコマンドでHAクラスターの状態を確認します。

# clpstat -s

HAクラスターを未構築の場合は、以下のメッセージが表示されます。HAクラスターを構築済みの場合でserver01、server02がOnlineの場合はHAクラスターを停止してください。

The cluster is not created.

  • 3.
    状態を確認後、以下のコマンドで構成情報を反映します。

# clpcfctrl --push -x /tmp/clusterpro/

以下のように「succeeded」と表示されたら反映は成功です。

file delivery to server 10.0.110.100 success.
file delivery to server 10.0.120.100 success.
The upload is completed successfully.
To apply the changes you made, restart the Node Manager service.
To apply the changes you made, restart the Alert Sync service.
To apply the changes you made, restart the WebManager service.
To apply the changes you made, restart the Information Base service.
To apply the changes you made, restart the API service.

Command succeeded.

  • 4.
    反映コマンド実行後に表示された各サービスを以下のコマンドで再起動します。

# clpcl -r -a --nm
# clpcl -r -a --alert
# clpcl -r -a --web
# clpcl -r -a --ib
# clpcl -r -a --api

それぞれ「Command succeeded」と表示されることを確認します。

Start server01 : Command succeeded.
Start server02 : Command succeeded.

  • 5.
    ミラーエージェントを以下のコマンドで起動します。

# clpcl -s -a --md

「Command succeeded」と表示されることを確認します。

Start server01 : Command succeeded.
Start server02 : Command succeeded.

  • 6.
    以下のコマンドでCLUSTERPROサービスを起動します。

# clpcl -s -a

「Command succeeded」と表示されることを確認します。

Start server01 : Command succeeded.
Start server02 : Command succeeded.

  • 7.
    以下のコマンドでHAクラスターの状態を確認します。

# clpstat -s

server01、server02のステータスが「Online」になっており、配下のリソースのステータスが「Normal」となっていることを確認します。「Online」になっていない場合は時間をおいてから再度コマンド実行を試します。ステータスが「Error」や「Caution」の場合は、clp.confの設定値に誤りがないか確認します。

 ========================  CLUSTER STATUS  ===========================
  Cluster : cluster1
  <server>
   *server01 ........: Online
      lankhb1        : Normal           Kernel Mode LAN Heartbeat
    server02 ........: Online
      lankhb1        : Normal           Kernel Mode LAN Heartbeat
  <group>
    failover1 .......: Online
      current        : server01
      awsvip1        : Online
      exec1          : Online
      md1            : Online
  <monitor>
    awsvipw1         : Normal
    genw1            : Normal
    mdw1             : Normal
    mdnw1           : Normal
    userw1           : Normal
 =====================================================================

4. 動作確認

以下の手順でHAクラスターが正常に構築できているかを確認します。

  • 1.
    操作用Client上でWebブラウザを起動し、以下のURLにアクセスしてCluster WebUIを表示します。

http://<AWS仮想IPリソースで設定したIPアドレス>:29003

  • 2.
    Cluster WebUIのステータス画面から、server01でフェールオーバーグループ(failover1)が起動していること、[サーバ]、[グループ]、[モニタ]が正常に起動していることを確認します。
  • 3.
    Cluster WebUIから、フェールオーバーグループ(failover1)をserver01からserver02に手動で移動します。
  • 4.
    フェールオーバーグループ(failover1)がserver02側に移動していること、[サーバ]、[グループ]、[モニタ]が正常に起動していることをCluster WebUIで確認します。
フェールオーバーが正常にできることを確認することで、既存システムのオンプレミス環境からAWS環境への移行完了を確認できました。

まとめ

今回はclpcfadm.pyコマンドを利用して、オンプレミス環境で構築したクラスタ構成情報ファイルをAWS環境で利用できるように変更してみました。本記事で紹介したコマンドを応用することで、AnsibleやTerraformなどの構成管理ツールでクラスター構築を自動化し、IaCの促進につなげることができます。

参考

CLUSTERPRO導入支援サービスではコンフィグコード化支援も行っております。クラスタ構成情報ファイルの自動生成に関するご要望がありましたら、popup関連サービスの導入支援サービスの窓口までお問い合わせください。

お問い合わせ

本記事に関するお問い合わせは、popupお問い合わせ窓口までお問い合わせください。
  • ※本記事で紹介しているスクリプトの内容についてのお問い合わせ、および、お客様環境に合わせたカスタマイズにつきましてはCLUSTERPRO導入支援サービスにて承っておりますので、上記窓口の"ご購入前のお問い合わせ"フォームまでお問い合わせください。

  • Share