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

マルチリージョン3ノードHAクラスターをAmazon Elastic File Systemを使用して構築してみました(Linux)

CLUSTERPRO オフィシャルブログ ~クラブロ~

はじめに

Amazon Web Services(以降、AWS)において、マルチリージョンかつマルチAZ環境で3ノードHAクラスターの構築を試してみました。
マルチリージョンでのHAクラスター構築については、過去にも何度か記事を紹介しましたが、いずれも各リージョン内はシングルAZ環境でした。
今回は、DRの実現のためにマルチリージョンかつマルチAZ環境でHAクラスターを構築することを考えてみます。平常時は東京リージョンのマルチAZ環境に配置した現用系/待機系のサーバーでサービスを稼働させ、AZ障害に備えます。災害などの理由で東京リージョンが使用できなくなった時にはじめて大阪リージョンのサーバーでサービスを稼働させます。
システム要件や共有するデータによっていくつかの方法がありますが、本記事ではAmazon Elastic File System(以降、Amazon EFS)を使用した構築手順について紹介します。

なお、シングルリージョン時のAmazon EFSを使用したHAクラスターの構築については以下の記事を参考にしてください。

この記事の内容

1. Amazon EFSレプリケーションについて

Amazon EFSは同じリージョン内でNFS共有が可能なほか、クロスリージョンレプリケーションを利用することによって異なるリージョンにファイルシステムのレプリカを作成することが可能です。ただし、このレプリケーションを利用するにあたって注意が必要な点が1つあります。

ファイルシステムのレプリカは読み取り専用となるため、レプリケーション先で読み書き可能にするためにはまずレプリケーション設定を削除する必要があります。レプリケーション設定の削除が完了した後、ファイルシステムのレプリカが通常のファイルシステムになり書き込み可能となります。ただし、一度レプリケーション設定を削除すると、元のレプリケーション設定に戻すことはできなくなります。レプリケーションを再開する時は、新規にレプリケーション設定を追加し、新たなファイルシステムとファイルシステムIDを作成することになります。

従って、リージョンを跨いだフェールオーバーが発生するたびにファイルシステムIDが変わります。本記事では、ファイルシステム名(Nameタグ)からファイルシステムIDを特定することで、レプリケーション設定の削除処理を可能にしています。

なお、リージョンを跨がないフェールオーバーの場合は同じファイルシステムを使用するため、レプリケーション設定の削除を行う必要はありません。

2. HAクラスター構成

今回は、アクセス先の切り替えにDNS名を利用したHAクラスターを構築します。東京リージョンのVPCには異なるAZにserver1とserver2を、大阪リージョンのVPCには単一のAZにserver3を配置し、各VPCは他のVPCとVPCピアリング接続で接続します。データの共有はAmazon EFSを使用します。HAクラスター対象のアプリケーションにはオブジェクトストレージサービスのMinIOを使用します。MinIO以外のアプリケーションのHAクラスターを構築する場合は、MinIOに関する設定や手順を適宜読み替えてください。

CLUSTERPROのサーバーグループとして、「Main」と「Sub」を登録し、東京リージョンのserver1、server2は「Main」へ追加、大阪リージョンのserver3は「Sub」へ追加します。このようにすることで、基本的には「Main」サーバグループに登録したサーバー間でのHAクラスター運用とします。リージョン障害等で、東京リージョンがダウンした時には大阪リージョンへフェールオーバーし、「Sub」サーバグループに登録したserver3で業務継続します。

Amazon EFSは現用系でNFSマウントする形で行います。各ノードでOS起動時にあらかじめNFSマウントを行わないのは、「1. Amazon EFSレプリケーションについて」で述べた通り、フェールオーバー時にファイルシステムIDが変わる場合があるためです。

また、アプリケーションやCluster WebUIへの接続を行うための動作確認用クライアントとして、本記事ではシンガポールリージョン上にclientを用意します。

なお、現用系/待機系の切り替えはDNS名制御方式でなくVIP制御方式でも可能ですが、VPC外からのVIPによるアクセスを可能にするためにVPCピアリング接続の代わりにAWS Transit Gatewayが必要となります。AWS Transit Gatewayを使用したVIP制御方式によるHAクラスターは以下の記事を参照してください。
本記事ではAmazon EFSおよびレプリケーションの機能に焦点をあてたため、ネットワークパーティション解決については割愛しています。そのため実際の運用時には以下の記事も参照ください。

3. HAクラスター構築手順

3.1 事前準備

3.1.1 VPCの設定

各リージョンにVPCおよびネットワークを作成します。VPCピアリング接続もこの時に作成しておきます。VPCの構成は以下の通りです。
各VPCの「DNS解決」と「DNSホスト名」の設定は、どちらも有効にしてください。設定が無効の場合、次に作成するAmazon EFSへのDNS名による接続や、Amazon Route 53を利用した名前解決に失敗しますので注意してください。

■ シンガポールリージョン(ap-southeast-1)

VPC-A (VPC ID:vpc-aaaa1234)
  -CIDR:10.50.0.0/16
  -Subnets
    ・Subnet-A1 (サブネットID:subnet-aaaa111a):10.50.110.0/24
  -RouteTables
    ・Main (ルートテーブルID:rtb-aaaa0001)
        10.50.0.0/16 → local
        0.0.0.0/0    → igw-aaaa1234 (Internet Gateway)
        10.60.0.0/16 → pcx-aaaabbbb (東京シンガポール間のVPC Peering接続)
        10.70.0.0/16 → pcx-aaaacccc (大阪シンガポール間のVPC Peering接続)


■ 東京リージョン(ap-northeast-1)

VPC-B (VPC ID:vpc-bbbb1234)
  -CIDR:10.60.0.0/16
  -Subnets
    ・Subnet-A1 (サブネットID:subnet-bbbb111a):10.60.10.0/24
    ・Subnet-A2 (サブネットID:subnet-bbbb222a):10.60.110.0/24
    ・Subnet-C1 (サブネットID:subnet-bbbb111c):10.60.20.0/24
    ・Subnet-C2 (サブネットID:subnet-bbbb222c):10.60.120.0/24
  -RouteTables
    ・Main (ルートテーブルID:rtb-bbbb0001)
        10.60.0.0/16 → local
        0.0.0.0/0    → igw-bbbb1234 (Internet Gateway)
    ・Route-A (ルートテーブルID:rtb-bbbb000a)
        10.60.0.0/16 → local
        0.0.0.0/0    → nat-bbbb0001 (NAT Gateway 1)
        10.50.0.0/16 → pcx-aaaabbbb (東京シンガポール間のVPC Peering接続)
        10.70.0.0/16 → pcx-bbbbcccc (東京大阪間のVPC Peering接続)
    ・Route-C (ルートテーブルID:rtb-bbbb000c)
        10.60.0.0/16 → local
        0.0.0.0/0    → nat-bbbb0002 (NAT Gateway 2)
        10.50.0.0/16 → pcx-aaaabbbb (東京シンガポール間のVPC Peering接続)
        10.70.0.0/16 → pcx-bbbbcccc (東京大阪間のVPC Peering接続)


■ 大阪リージョン(ap-northeast-3)

VPC-C (VPC ID:vpc-cccc1234)
  -CIDR:10.70.0.0/16
  -Subnets
    ・Subnet-A1 (サブネットID:subnet-cccc111a):10.70.10.0/24
    ・Subnet-A2 (サブネットID:subnet-cccc222a):10.70.110.0/24
  -RouteTables
    ・Main (ルートテーブルID:rtb-cccc0001)
        10.70.0.0/16 → local
        0.0.0.0/0    → igw-cccc1234 (Internet Gateway)
    ・Route-A (ルートテーブルID:rtb-cccc000a)
        10.70.0.0/16 → local
        0.0.0.0/0    → nat-cccc0001 (NAT Gateway 3)
        10.50.0.0/16 → pcx-aaaacccc (大阪-シンガポール間のVPC Peering接続)
        10.60.0.0/16 → pcx-bbbbcccc (東京大阪間のVPC Peering接続)

3.1.2 セキュリティグループ

各サーバーや動作確認用クライアントがお互いに通信可能にするために、各リージョンにセキュリティグループを必要に応じて作成します。
セキュリティグループは、システムのポリシーに応じて適切に設定してください。

また、東京リージョンと大阪リージョンのそれぞれに、Amazon EFSが自リージョンのサーバーからのNFSマウントを許可するためのセキュリティグループも作成します。

タイプ:NFS
ポート範囲:2049
プロトコル:TCP
ソース:自リージョンのサーバー

3.1.3 Amazon EFSの作成

東京リージョンに、ファイルシステムを1つ作成します。
Amazon EFSのファイルシステム作成画面で、最初に「カスタマイズ」ボタンをクリックし、詳細設定画面に進みます。

ファイルシステムの作成

「ファイルシステムの設定」画面では次のように入力します。それ以外の項目は任意です。

  -名前:DRTest-EFS1
  -ストレージクラス:標準


「次へ」ボタンをクリックします。
「ネットワークアクセス」画面では次のように入力します(マウントターゲットを、サーバー用インスタンスのあるVPCのプライベートサブネットに作成するようにします)。

  -VPC:VPC-B (VPC ID:vpc-bbbb1234)
  -マウントターゲット:
    ■マウントターゲット1
    ・アベイラビリティーゾーン:ap-northeast-1a
    ・サブネットID:subnet-bbbb222a(Subnet-A2)
    ・IPアドレス:自動
    ・セキュリティグループ:「3.1.2 セキュリティグループ」で作成したセキュリティグループ
    ■マウントターゲット2
    ・アベイラビリティーゾーン:ap-northeast-1c
    ・サブネットID:subnet-bbbb222c(Subnet-C2)
    ・IPアドレス:自動
    ・セキュリティグループ:「3.1.2 セキュリティグループ」で作成したセキュリティグループ


「次へ」ボタンをクリックします。
「ファイルシステムポリシー」画面では、特に何も変更せずに「次へ」ボタンをクリックします。
「確認して作成する」画面で内容を確認し、「作成」ボタンをクリックします。

3.1.4 Amazon EFSレプリケーションの作成

Amazon EFSのファイルシステム一覧画面で、作成したファイルシステム(DRTest-EFS1)を選択し、[詳細の表示]ボタンをクリックします。

ファイルシステムの詳細画面の下部にある「レプリケーション」タブをクリックします。
「レプリケーションを作成」ボタンをクリックします。

「レプリケーションを作成」画面において、次のように入力します。それ以外の項目は任意です。

レプリケーション設定
  -送信先のAWSリージョン:アジアパシフィック(大阪) ap-northeast-3
送信先ファイルシステム設定
  -ストレージクラス:1ゾーン
  -アベイラビリティゾーン:ap-northeast-3a


「レプリケーションを作成」ボタンをクリックすると、DRTest-EFS1のファイルシステム詳細画面に戻ります。
「レプリケーション」タブ画面下部の「レプリケーションの状態」が「有効化」になっていることを確認し、「送信先ファイルシステム」に表示されているファイルシステムID(fs-xxxxxxxxxxxxxxxxx)のリンクをクリックします。

大阪リージョンに切り替わり、送信先ファイルシステム(ファイルシステムのレプリカ)の詳細画面が表示されますので、画面下部の「タグ」タブをクリックします。
次の通り、東京リージョンで作成したファイルシステム名と同じ名前のNameタグを追加します。

タグ
  タグキー:Name
  タグ値:DRTest-EFS1


次に「ネットワーク」タブをクリックします。
「マウントターゲットを作成」ボタンをクリックします。

「マウントターゲットを作成」画面では次の項目を入力します(マウントターゲットを、サーバー用インスタンスのあるVPCのプライベートサブネットに作成するようにします)。

VPC:VPC-C (VPC ID:vpc-cccc1234)
マウントターゲット:
    ・アベイラビリティーゾーン:ap-northeast-3a
    ・サブネットID:subnet-cccc222a(Subnet-A2)
    ・IPアドレス:自動
    ・セキュリティグループ:「3.1.2 セキュリティグループ」で作成したセキュリティグループ


「保存」ボタンをクリックします。

なお、「1. Amazon EFSレプリケーションについて」でも触れたとおり、この項で作成したレプリケーション設定はリージョンを跨いだフェールオーバー時に削除されます。
そのためフェールバック(大阪リージョンから東京リージョンにフェールオーバー)を実行する前にレプリケーション設定を再度行う必要があります。この時の設定は入力値が少し異なるため、「4.3 フェールバックの準備」の手順を参照してください。

3.1.5 Amazon EFSマウントヘルパーのインストール

Amazon EFSをEC2インスタンスにマウントして使用する際は、Amazon EFSマウントヘルパーの使用が推奨されています。Amazon EFSマウントヘルパーを使用することで転送時のデータ暗号化がサポートされ、Amazon EFS推奨のマウントオプションが使用されるようになります。Amazon EFSマウントヘルパーの利用方法については以下を参照ください。
Amazon EFSマウントヘルパーを使用しない場合は、以下を参照ください。
Amazon EFSのマウント先を/mnt/efsとするため、HAクラスターを構成する各サーバーでディレクトリ/mnt/efsを作成します。

# mkdir /mnt/efs


作成したファイルシステムおよびファイルシステムのレプリカがマウント可能であることを各サーバーで確認しておきます。

EFSマウントヘルパーを使用する場合("fs-abcd1234"には実際のファイルシステムIDを指定)
# mount -t efs -o tls fs-abcd1234:/ /mnt/efs

EFSマウントヘルパーを使用しない場合("fs-abcd1234"、"ap-xxxxyyyy-z"には実際のファイルシステムIDおよびリージョンを指定)
# mount -t nfs4 -o nfsvers=4.1,rsize=1048576,wsize=1048576,hard,timeo=60,retrans=2,noresvport,_netdev fsabcd1234.efs.ap-xxxxyyyy-z.amazonaws.com:/ /mnt/efs


正常にマウントできたことを確認後、後の「3.2.4 モニタリソースの登録」で追加するディスクモニタリソース(diskw)の監視対象ファイル用のディレクトリをこのタイミングで作成しておきます。

# mkdir /mnt/efs/mon


マウントしたファイルシステムを、忘れずにアンマウントします。

# umount /mnt/efs

3.1.6 Amazon Route 53の設定

DNS名制御方式のために、Amazon Route 53でホストゾーンを作成します。
本記事では各VPCで名前解決を可能にするため、プライベートホストゾーンとして作成します。

ホストゾーン
  -ドメイン名:example.com
  -タイプ:プライベートホストゾーン
ホストゾーンに関連付けるVPC
  ・VPC-A (VPC ID:vpc-aaaa1234)
  ・VPC-B (VPC ID:vpc-bbbb1234)
  ・VPC-C (VPC ID:vpc-cccc1234)


ホストゾーン作成後、動作確認用クライアントからdrtest.example.comでアクセスするためのレコードも作成します。

レコード
  -レコード名:drtest
  -レコードタイプ:A
  -エイリアス:オフ
  -値:server1のIPアドレス
  -TTL(秒):300

3.1.7 MinIOの設定

次に、HAクラスターを構成するサーバーにMinIOをインストールします。インストール手順については以下を参照してください。MinIOのインストール先は任意の場所を指定してください。今回はルートディレクトリの配下に作成した「/work」にインストールします。

3.1.8 AWS CLIの設定

本記事の構成では、EXECリソースとAWS DNSリソースで利用するために、PythonとAWS CLIのインストールが必要となります。PythonおよびAWS CLIの動作環境、インストール方法については以下を参照ください。

【参考】
    popupCLUSTERPRO X システム構築ガイド
      ● CLUSTERPRO X 5.1 > Linux > スタートアップガイド
        → 第4章 CLUSTERPRO の動作環境
            → 4.2 ソフトウェア
                → 4.2.8 AWS DNS リソース、AWS DNS モニタリソースの動作環境
        → 第6章 注意制限事項
            → 6.3 OS インストール後、CLUSTERPRO インストール前
                → 6.3.20 AWS 環境における IAM の設定について

また、スクリプトからのAmazon EFSの操作を許可するために、IAMポリシーには上記構築ガイドに記載のアクションに加えて以下のアクションの許可が必要となります。

elasticfilesystem:DescribeFileSystems
elasticfilesystem:DescribeReplicationConfigurations
elasticfilesystem:DeleteReplicationConfiguration

3.2 DNS名制御によるHAクラスターの構築

今回の検証では、CLUSTERPRO X 5.1(内部Ver. Linux:5.1.0-1)を利用しています。
サーバグループを東京リージョン、大阪リージョンで別となるように作成し、Amazon EFSのファイルシステムは現用系でマウントします。

本記事でのCLUSTERPROの構成(グループリソース、モニタリソース)の概要は次の通りです。

■フェールオーバーグループ(failover)のグループリソース
  -AWS DNSリソース(awsdns)
  -EXECリソース(exec-EFS)
  -EXECリソース(exec-MinIO)

■モニタリソース
  -AWS DNSモニタリソース(awsdnsw)
  -カスタムモニタリソース(genw-EFS)
  -ディスクモニタリソース(diskw)
  -PIDモニタリソース(pidw-MinIO)

3.2.1 サーバグループの作成

「サーバ共通のプロパティ」において、次の通りサーバグループを定義します。
Mainグループに東京リージョンのサーバー(server1、server2)、Subグループに大阪リージョンのサーバー(server3)を登録します。

「サーバグループ」タブ
  Main:server1、server2
  Sub:server3

サーバ共通のプロパティ

3.2.2 フェールオーバーグループの作成

フェールオーバーグループの作成時に、「サーバグループ設定を使用する」にチェックを入れます。

「次へ」ボタンをクリックします。
「起動可能なサーバグループ」にMain、Subを追加します。

「次へ」ボタンをクリックします。
「フェイルオーバ属性」では、「自動フェイルオーバ」配下の「サーバグループ内のフェイルオーバポリシーを優先する」を選択し、「サーバグループ間では手動フェイルオーバのみを有効とする」にチェックを入れます。

「次へ」ボタンをクリックしてグループリソースの登録に進みます。

3.2.3 グループリソースの登録

フェールオーバーグループに以下のグループリソースを登録します。

■AWS DNSリソース(awsdns)

-依存関係
    既存の依存関係に従う
-詳細
    ホストゾーンID:ZZZZZZZZZZZZZZZZZZZZ
    リソースレコードセット名:drtest.example.com.
    IPアドレス:
        server1:10.60.110.10
        server2:10.60.120.10
        server3:10.70.110.10

AWS DNSリソースは、Amazon Route 53に登録したdrtest.example.comのAレコードの値を現用系サーバーのIPアドレスに更新することにより、接続先の切り替えを実現します。詳細な設定手順については以下を参照ください。

【参考】
    popupCLUSTERPRO X ソフトウェア構築ガイド
      ● Linux > クラウド > Amazon Web Services
         > CLUSTERPRO X 5.1 向け HAクラスタ 構築ガイド
            → 第7章 DNS 名制御によるHA クラスタの設定
                → 7.3 CLUSTERPRO の設定
                    → 2. グループリソースの追加
                        → AWS DNS リソース

■EXECリソース(exec-EFS)

-依存関係
    既存の依存関係に従う
-詳細
  ・Start Script:<開始スクリプト>
  ・Stop Script:<終了スクリプト>


EXECリソース(exec-EFS)は、Amazon EFSのファイルシステムのマウント・アンマウントを行います。リージョンを跨いだフェールオーバーの場合(それまでレプリカだったファイルシステムをマウントする場合)には、マウント前にレプリケーション削除も行います。
具体的には開始スクリプト(start.sh)で以下の動作を行います。

  • 1.
    ファイルシステム名(Nameタグの値)からファイルシステムIDを取得する。
  • 2.
    ファイルシステムIDからレプリケーション設定情報を取得する。
  • 3.
    レプリケーション設定情報の中からソースファイルシステムIDを抽出する。
  • 4.
    1.のファイルシステムIDとソースファイルシステムIDが異なる場合はリージョン跨ぎが発生したとみなし、レプリケーション設定の削除を行う。
  • 5.
    レプリケーション設定の削除が完了するまで待ち合わせる(約10~15分)。
  • 6.
    ファイルシステムIDを指定してマウントポイントにマウントする。

exec-EFSの開始スクリプト(start.sh)は次の通りです。
冒頭にある変数の値は環境にあわせて変更してください。
変数USE_EFS_MOUNT_HELPERは、「3.1.5 Amazon EFSマウントヘルパーのインストール」においてヘルパーをインストールした場合に"yes"、ヘルパーを使用しない場合は"no"を指定します。
変数EFS_NAMEは、「3.1.3 Amazon EFSの作成」で指定したファイルシステム名(ここではDRTest-EFS1)を指定します。変数MOUNT_POINTにはファイルシステムのマウントポイントを指定します。
変数LOOP_COUNTとSLEEP_SECはレプリケーション設定削除の待ち合わせ用ループカウンタとウェイト秒数を指定します。
変数AWS_CLIは「3.1.8 AWS CLIの設定」でインストールしたAWS CLIの、awsコマンドへの絶対パスを指定します。

#!/bin/bash
#***************************************
#               start.sh
#***************************************

USE_EFS_MOUNT_HELPER=yes
EFS_NAME=DRTest-EFS1
MOUNT_POINT=/mnt/efs
LOOP_COUNT=120
SLEEP_SEC=10
AWS_CLI="/usr/local/bin/aws"

# get replication configuration information
get_replication_configuration()
{
  local fsid=$1
  result=$( \
    ${AWS_CLI} efs describe-replication-configurations \
      --output text \
      --file-system-id "${fsid}" \
      --query 'Replications[].{A:SourceFileSystemId, B:Destinations[0].Status}' 2> /dev/null ) \
      || return $?
  echo "${result}"
}

# --- Main ---

# get options
if [ -z "${EFS_NAME}" -o -z "${MOUNT_POINT}" ]; then
  echo "Usage: ${0} <efs name> <mount point>" >&2
  exit 1
fi

# get fs info by name
result=$(${AWS_CLI} efs describe-file-systems --output text \
            --query 'FileSystems[].{A:Name, B:FileSystemId, C:FileSystemArn}')
if [ $? -ne 0 ]; then
  echo "Execution cli has failed." >&2
  exit 2
fi

fsinfo=($(echo "${result}" | egrep "^${EFS_NAME}\b"))
fsid=${fsinfo[1]}
if [ -z "$fsid" ]; then
  echo "Not found EFS (${EFS_NAME})" >&2
  exit 3
fi
O_IFS="${IFS}"
IFS=:
tmp=(${fsinfo[2]})
region="${tmp[3]}"
IFS="${O_IFS}"

echo "Found fs ${EFS_NAME}: ${fsid} (${region})"

# get replication configuration info
replinfo=($(get_replication_configuration "${fsid}"))
if [ $? -ne 0 ]; then
  echo "No replication configuration (or execution cli failure)." >&2
  exit 4
fi

# check the source of replication file system
srcfsid="${replinfo[0]}"
echo "  Replication source: ${srcfsid}"
if [ "${fsid}" != "${srcfsid}" ]; then
  # delete replication configuration
  echo -n "Deleting replication configuration "
  ${AWS_CLI} efs delete-replication-configuration \
    --source-file-system-id "${srcfsid}"
  if [ $? -ne 0 ]; then
    echo "Deletion replication configuration has failed." >&2
    exit 5
  fi

  # wait for the deletion to complete
  counter=${LOOP_COUNT}
  while [ $counter -gt 0 ]; do
    echo -n "."
    replinfo=($(get_replication_configuration "${fsid}"))
    [ $? -eq 0 ] || break  # deletion has completed
    sleep ${SLEEP_SEC}
    let counter--
  done 

  # timed out
  if [ $counter -le 0 ]; then
    echo " timed out"
    echo "Waiting for deletion has timed out." >&2
    exit 6
  else
    echo " done."
  fi
fi

# mount file system
if [ "${USE_EFS_MOUNT_HELPER}" == "yes" ]; then
  sudo mount -t efs -o tls "${fsid}:/" "${MOUNT_POINT}"
else
  sudo mount -t nfs4 -o nfsvers=4.1,rsize=1048576,wsize=1048576,hard,timeo=60,retrans=2,noresvport,_netdev"${fsid}.efs.${region}.amazonaws.com:/" "${MOUNT_POINT}"
fi
if [ $? -ne 0 ]; then
  echo "Failed to mount EFS (${fsid})." >&2
  exit 7
fi

echo "Mounting ${EFS_NAME} has completed."

exit 0

exec-EFSの終了スクリプト(stop.sh)は次の通りです。変数MOUNT_POINTにはファイルシステムのマウントポイントを指定します。

#! /bin/sh
#***************************************
#                stop.sh
#***************************************

MOUNT_POINT=/mnt/efs

mountpoint "${MOUNT_POINT}"
if [ $? -eq 0 ]; then
  umount -f "${MOUNT_POINT}"
  exit $?
fi
exit 0

■EXECリソース(exec-MinIO)

-依存関係
    依存するリソース:EXECリソース(exec-EFS)
-詳細
  ・Start Script:<開始スクリプト>
  ・Stop Script:<終了スクリプト>
  調整→パラメータ→開始スクリプト:非同期

EXECリソース(exec-MinIO)は、MinIOの起動・停止を行います。開始スクリプト(start.sh)と終了スクリプト(stop.sh)はそれぞれ次の通りです。

開始スクリプト(start.sh)
変数MOUNT_POINTにはファイルシステムのマウントポイントを指定します。

#!/bin/sh

MOUNT_POINT=/mnt/efs

/work/minio server "${MOUNT_POINT}" --console-address :9090
exit $?

終了スクリプト(stop.sh)

#!/bin/sh

pgrep minio
if [ $? -eq 0 ];
then
     pgrep minio | xargs kill
     exit $?
else
     exit 0
fi


EXECリソース(exec-MinIO)のプロパティの「詳細」タブで「調整」ボタンをクリックし、「開始スクリプト」を「同期」から「非同期」へ変更してください。

EXECリソース調整プロパティ

3.2.4 モニタリソースの登録

以下のモニタリソースを登録します。

■AWS DNSモニタリソース(awsdnsw)

-監視(共通)
  ・監視タイミング:活性時
  ・対象リソース:awsdns


AWS DNSモニタリソースは、AWS DNSリソース追加時に自動的に追加されます。特に設定を変更する必要はありません。

■カスタムモニタリソース(genw-EFS)

-監視(共通)
  ・監視タイミング:活性時
  ・対象リソース:exec-EFS
-監視(共通)
  ・ファイル:<監視スクリプト>


カスタムモニタリソース(genw-EFS)は、Amazon EFSのファイルシステムが/mnt/efsにマウントされているかどうかを監視します。監視スクリプト(genw.sh)は次の通りです。
変数MOUNT_POINTにはファイルシステムのマウントポイントを指定します。

#! /bin/sh

MOUNT_POINT=/mnt/efs

mountpoint "${MOUNT_POINT}"
exit $?

■ディスクモニタリソース(diskw)

-監視(共通)
  ・監視タイミング:活性時
  ・対象リソース:exec-EFS
-監視(固有)
  ・監視方法:WRITE(FILE)
  ・監視先:/mnt/efs/mon/monitor.txt
  ・I/Oサイズ:1バイト


ディスクモニタリソースは、Amazon EFSのファイルシステムが書き込み可能かどうかを監視します。監視タイミングにはAmazon EFSのファイルシステムがマウントされているときのみ必要なため「活性時」を選択します。

監視方法は「WRITE(FILE)」を選択します。監視先にはマウントポイント内の任意のファイル(例:/mnt/efs/mon/monitor.txt)を指定し、I/Oサイズには任意の値(例:1バイト)を設定します。

モニタリソースの定義(genw) - 監視(固有)

■PIDモニタリソース(pidw-MinIO)

-監視(共通)
  ・監視タイミング:活性時
  ・対象リソース:exec-MinIO


PIDモニタリソース(pidw-MinIO)により、MinIOのサービスを監視します。対象リソースにはMinIOの制御を行うEXECリソース(例:exec-MinIO)を指定します。

4. 動作確認

動作確認用クライアント(client)からCluster WebUIおよびMinIOサービス(本記事の場合、http://drtest.example.com:9000/)に接続し、動作確認を行います。

4.1 リージョン内フェールオーバーの確認

東京リージョン内でserver1からserver2にフェールオーバーし、MinIOサービスに問題なくアクセスできることを確認します。

  • 1.
    Cluster WebUIに接続し、フェールオーバーグループがserver1で起動していることを確認します。
  • 2.
    MinIOサービスに接続し、バケット(例:test)を作成します。
  • 3.
    テキストファイル(例:test.txt)をバケットにアップロードします。
  • 4.
    Cluster WebUIからserver2への手動フェールオーバーを実行します。
  • 5.
    フェールオーバーグループがserver2で起動した後、再度MinIOに接続します。フェールオーバー前に作成したテキストファイル(test.txt)が参照できることを確認します。
  • 6.
    AWSマネジメントコンソールから、Amazon EFSファイルシステムのレプリケーション設定が有効であること(削除されていないこと)を確認します。「レプリケーション」タブをクリックし、「レプリケーションの状態」が「有効化」になっていれば正常です。

4.2 リージョン跨ぎフェールオーバーの確認

東京リージョンのserver2から大阪リージョンのserver3にフェールオーバーし、MinIOサービスにアクセスできることを確認します。また、レプリケーション削除が行われることで大阪リージョン側のAmazon EFSのファイルシステムが書き込み可能になり、MinIOサービスのバケットにファイルを保存できることも確認します。

  • 1.
    MinIOサービスに接続し、テキストファイル(例:test2.txt)をバケットにアップロードします。
  • 2.
    Amazon EFSレプリケーションのRPOが15分のため、15分待ちます。
  • 3.
    Cluster WebUIからserver3への手動フェールオーバーを実行します。
  • 4.
    フェールオーバーグループがserver3で起動した後、再度MinIOに接続します。フェールオーバー前に作成したテキストファイル(test2.txt)が参照できることを確認します。
  • 5.
    AWSマネジメントコンソールから、Amazon EFSファイルシステムのレプリケーション設定がないこと(削除されていること)を確認します。「レプリケーション」タブをクリックし、レプリケーション設定が存在しなければ正常です。

  • 6.
    MinIOサービスに接続し、テキストファイル(例:test3.txt)をバケットにアップロードします。アップロードが成功し、ファイルシステムが正常に書き込み可能になっていることを確認します。

4.3 フェールバックの準備

特に準備を行わないまま東京リージョンにフェールバックするとEXECリソース(exec-EFS)の起動に失敗します。これは、レプリケーション設定が削除され、東京リージョンと大阪リージョンのファイルシステムで同期がとれていない状態にあることで、EXECリソースのスクリプト内でマウント処理がガードされるためです。そのためフェールバック処理の前にファイルシステムに対してレプリケーション設定およびファイルシステムのレプリカに対するファイルシステム名の設定とマウントターゲットの追加を行う必要があります。

まず、AWSマネジメントコンソールから、東京リージョンに最初に作成した同名のファイルシステムをリネーム(Nameタグを修正)するか削除しておきます(残したままだと同名のファイルシステムが複数存在することになり誤動作の原因となります)。

次に大阪リージョンに切り替え、ファイルシステム(DRTest-EFS1)を選択し、[詳細の表示]ボタンをクリックします。

ファイルシステムの詳細画面の下部にある「レプリケーション」タブをクリックします。「レプリケーションを作成」ボタンをクリックします。

「レプリケーションを作成」画面において、次のように入力します。それ以外の項目は任意です。

レプリケーション設定
  -送信先のAWSリージョン:アジアパシフィック(東京) ap-northeast-1
送信先ファイルシステム設定
  -ストレージクラス:標準


「レプリケーションを作成」ボタンをクリックします。DRTest-EFS1のファイルシステム詳細画面に戻りますので、画面下部の「レプリケーション」を確認し、送信先ファイルシステムのファイルシステムID(fs-xxxxxxxxxxxxxxxxx)のリンクをクリックします。

東京リージョンに切り替わり、送信先ファイルシステム(レプリケーションされたファイルシステム)の詳細画面が表示されますので、画面下部の「タグ」タブをクリックします。
次の通り、大阪リージョンのファイルシステム名と同じ名前のNameタグを追加します。

タグ
  タグキー:Name
  タグ値:DRTest-EFS1


次に「ネットワーク」タブをクリックします。
「マウントターゲットを作成」ボタンをクリックします。

次の項目を入力します。

VPC:VPC-B (VPC ID:vpc-bbbb1234)
マウントターゲット:
    ■マウントターゲット1
    ・アベイラビリティーゾーン:ap-northeast-1a
    ・サブネットID:subnet-bbbb222a(Subnet-A2)
    ・IPアドレス:自動
    ・セキュリティグループ:「3.1.2 セキュリティグループ」で作成したセキュリティグループ

    ■マウントターゲット2
    ・アベイラビリティーゾーン:ap-northeast-1c
    ・サブネットID:subnet-bbbb222c(Subnet-C2)
    ・IPアドレス:自動
    ・セキュリティグループ:「3.1.2 セキュリティグループ」で作成したセキュリティグループ


「保存」ボタンをクリックします。

4.4 フェールバックの確認

大阪リージョンのserver3から東京リージョンのserver1にフェールバックし、MinIOサービスにアクセスできること、これまでに保存したファイルが存在することを確認します。

  • 1.
    Cluster WebUIからserver1への手動フェールオーバーを実行します。
  • 2.
    フェールオーバーグループがserver1で起動した後、再度MinIOに接続します。テキストファイル(test1.txt、test2.txt、test3.txt)が参照できることを確認します。
なお、リージョンを跨いだフェールバックのため同様にレプリケーション設定が削除されています。そのため以下の手順を実行します。

  • 1.
    大阪リージョンのファイルシステムをリネームするか、削除します。
  • 2.
    「3.1.4 Amazon EFSレプリケーションの作成」の手順を実行し、東京リージョンから大阪リージョンへのレプリケーション設定およびマウントターゲットを再作成します。

まとめ

今回は、CLUSTERPRO X 5.1でAmazon EFSを使用したマルチリージョンかつマルチAZ環境で3ノードHAクラスターの構築を試してみました。Amazon EFSのクロスリージョンレプリケーションを活用することで、リージョン間のデータの共有およびリージョンを跨いだフェールオーバーを実現できることを確認できました。

「4.3 フェールバックの準備」に記述したレプリケーション設定やマウントターゲット作成は、EXECリソースのスクリプトで行わせることも可能ですが、今回はフェールオーバー処理を簡潔にするために手動操作としました。必要があればスクリプト化を検討してみてください。

本記事の構成をご検討の際は、CLUSTERPROのpopup試用版を用いて検証した後、ご提案・構築ください。

お問い合わせ

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