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

【2022年版】AWSで両系活性を防止する方法(Windows/Linux)

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

  • 2024/09/13 以下を追記。
  • サービス起動遅延時間の調整について記述を追加しました。

はじめに

Amazon Web Services(以降、AWS)において、HAクラスターの両系活性を防止するために、CLUSTERPROの機能の一つである強制停止リソースを利用したHAクラスターの構築を試してみました。

本記事は、popup以前の記事の改訂版(2022年版)です。CLUSTERPRO X 5.0において強制停止機能や強制停止スクリプトが強制停止リソースとして刷新されたため、設定方法の説明を改訂しています。
CLUSTERPRO X 4.3以前を使用している場合は、以前の記事を参照してください。

CLUSTERPROでは、両系活性を防止する方法としてネットワークパーティション解決(以降、NP解決)が設定可能です。AWSにおける推奨構成ではHTTP NP解決を設定します。(NP解決の詳細はpopupこちらの記事を参照)

しかし、NP解決を設定したとしてもOSストールやAZ間の通信断などの障害が起きた場合は、両系活性が発生する可能性があります。そのような場合にも両系活性を発生させない方法として、強制停止リソースという機能があります。今回は、AWS環境用の強制停止リソースをHAクラスターに設定します。

この記事の内容

1. 両系活性と強制停止リソース

両系活性
両系活性とは、ネットワークパーティション(スプリットブレイン)の状態に陥ったクラスターにおいて、複数のサーバーがフェールオーバーグループを起動している事象のことです。両系活性が発生すると、各サーバーで動作している業務アプリケーションはそれぞれ独立して業務データの読み書きを行うため、サーバー間のデータ不整合など重大な問題に繋がります。そのため、両系活性の防止策が大切となります。

強制停止リソース
強制停止リソースとは、サーバーのダウンを認識したときに残りのサーバー(正常なサーバー)で動作する機能で、ダウンしたサーバーを外部から強制的に停止させることができます。これにより、ネットワークパーティション(スプリットブレイン)の状態となった場合でも、NP解決リソースによる対応に加えて強制停止リソースを利用してサーバーを停止させることで、両系活性の防止をより確実なものにすることができます。

強制停止リソースを実行する契機は、ハートビートタイムアウトによりサーバーのダウンを検出し、ダウンしたサーバーで起動していたフェールオーバーグループを他のサーバーで起動する場合となります。Cluster WebUIなどからサーバーを正常に停止した場合や、ダウンしたサーバー上でフェールオーバーグループが起動しておらずフェールオーバーが発生しない、といった場合は強制停止リソースを実行しないため、不必要なタイミングでサーバーを強制停止することはありません。

強制停止リソースは環境に応じた様々なタイプが用意されています。例えば、IPMIの機能を利用して物理環境のサーバーを停止するBMC強制停止リソースや、VMware vCenter Serverの機能を利用して仮想マシンを停止するvCenter強制停止リソースなどがあります。

強制停止リソースの詳細については、リファレンスガイドをご参照ください。

【参考】
● CLUSTERPRO X 5.0 > Windows > リファレンスガイド
→第 7 章 強制停止リソースの詳細

● CLUSTERPRO X 5.0 > Linux > リファレンスガイド
→第 7 章 強制停止リソースの詳細

2. 構築するHAクラスター構成

「VIP制御によるHAクラスター」を構築します。AWS構築ガイドの構成から少し変更します。

AWS構築ガイドではHTTP NP解決のターゲットとしてVPC外(インターネット上)のWebサーバーを指定していますが、セキュリティポリシーなどによりHAクラスターの構成サーバーからインターネットへアクセスさせたくない場合は利用できません。
本記事ではインターネットへアクセスしないHAクラスター構成として、「VPCエンドポイント」と組み合わせたパターンで「VIP制御によるHAクラスター」を構築します。

構築するHAクラスターの構成図は以下の通りです。

フェールオーバーグループにはAWS仮想IPリソース、ミラーディスクリソースのみを設定します。
また、HTTP NP解決のターゲットには、Amazon S3上に作成したウェブサイトを指定します。Amazon S3へはゲートウェイエンドポイントを介してアクセスを行い、セキュリティの観点から、HAクラスターを構築するVPCからのみ接続可能となるように設定します。
さらに、強制停止リソースを設定して、ダウンしたサーバーをシャットダウンします。

  • NP解決リソースはHAクラスター環境に合わせて適宜設定してください。
    たとえば、オンプレミスにあるクライアントがAWS Direct Connectを使用してAWS上のHAクラスター環境にアクセスする場合、Ping NP解決リソースを使用して、Pingターゲットにオンプレミス側のゲートウェイを設定することでNP解決を実現することも可能です。

ゲートウェイエンドポイントの詳細や作成手順、Amazon S3上でウェブサイトをホスティングする手順については以下を参照ください。

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

HAクラスターの構築手順をご紹介します。
構築手順は、WindowsとLinuxで異なりますのでご注意ください。

3.1 HAクラスター構築の事前準備

AWS環境における事前準備の詳細はAWS構築ガイドをご参照ください。
今回の構成では、AWS CLIのコマンド実行時のHAクラスター構成サーバーからエンドポイントに対する通信にVPCエンドポイントを利用するため、NATインスタンスの作成は不要です。
VPCエンドポイントの設定手順は、popup以前の記事をご参照ください。

【参考】
● Windows > クラウド > Amazon Web Services
→CLUSTERPRO X 5.0 向け HAクラスタ 構築ガイド
→第 5 章 VIP 制御によるHA クラスタの設定
→5.1 VPC 環境の設定
→5.2 インスタンスの設定

● Linux > クラウド > Amazon Web Services
→CLUSTERPRO X 5.0 向け HAクラスタ 構築ガイド
→第 5 章 VIP 制御によるHA クラスタの設定
→5.1 VPC 環境の設定
→5.2 インスタンスの設定

また、今回は強制停止リソースでEC2インスタンスを停止するため、強制停止リソースからAWS CLIのstop-instanceコマンドを実行します。そのため、サーバーに割り当てるIAMロールのポリシーにec2:StopInstancesのアクションを追加します。AWS仮想IPリソースの制御に必要なアクションと合わせ、IAMロールのポリシーでは以下のアクションを許可します。

"ec2:Describe*"
"ec2:StopInstances"
"ec2:ReplaceRoute"

VPCの構成は以下の通りです。
Amazon S3(VPCエンドポイント)への経路は、ゲートウェイエンドポイント作成時に選択したルートテーブルへ自動的に追加されます。

  • VPC(VPC ID:vpc-1234abcd)
  • CIDR:10.0.0.0/16
  • Subnets
  • Subnet-A1 (サブネット ID:sub-1111aaaa):10.0.10.0/24
  • Subnet-A2 (サブネット ID:sub-2222aaaa):10.0.110.0/24
  • Subnet-C1 (サブネット ID:sub-1111cccc):10.0.20.0/24
  • Subnet-C2 (サブネット ID:sub-2222cccc):10.0.120.0/24
  •  
  • RouteTables
  • Main (ルートテーブル ID:rtb-00000001)
  • >10.0.0.0/16 → local
  • >0.0.0.0/0 → igw-1234abcd (Internet Gateway)
  • >20.0.0.200/32 → eni-1234abcd (ENI ID)
  • Route-A (ルートテーブル ID:rtb-0000000a)
  • >10.0.0.0/16 → local
  • >20.0.0.200/32 → eni-1234abcd (ENI ID)
  • >pl-xxxxxxxx → vpce-5678cdef (Endpoint ID)
  •  ※Amazon S3(VPCエンドポイント)への経路
  • Route-C (ルートテーブル ID:rtb-0000000c)
  • >10.0.0.0/16 → local
  • >20.0.0.200/32 → eni-1234abcd (ENI ID)
  • >pl-xxxxxxxx → vpce-5678cdef (Endpoint ID)
  •  ※Amazon S3(VPCエンドポイント)への経路

VPC

3.2 HAクラスターの構築

「VIP制御によるHAクラスター」の構築手順の詳細については、AWS構築ガイドをご参照ください。

【参考】
● Windows > クラウド > Amazon Web Services
→CLUSTERPRO X 5.0 向け HAクラスタ 構築ガイド
→第 5 章 VIP 制御によるHA クラスタの設定
→5.3 CLUSTERPRO の設定

● Linux > クラウド > Amazon Web Services
→CLUSTERPRO X 5.0 向け HAクラスタ 構築ガイド
→第 5 章 VIP 制御によるHA クラスタの設定
→5.3 CLUSTERPRO の設定

今回の構成ではAWS構築ガイドの構成からHTTP NP解決リソースのターゲットホストを変更、また、強制停止リソースを追加で設定します。
HTTP NP解決のターゲットホストにAmazon S3上に作成したウェブサイトを指定します。

3.2.1 HTTP NP解決リソースの設定

HTTP NP解決リソースは、以下のように設定します。
今回は、Amazon S3上に作成したウェブサイトに対して、HTTP NP解決リソースの設定を行います。

HTTP NP解決リソースのプロパティは以下の通りです。

HTTPNP設定02

3.2.2 強制停止リソースの設定

強制停止リソースは、以下のように設定します。

  • 1.HTTP NP解決リソースを設定した「フェンシング」の画面にて、強制停止のタイプとして「AWS」を選択し、「プロパティ」をクリックします。

  • 2.利用可能なサーバから「server01」を選択し、「追加」をクリックします。

  • 3.server01のEC2インスタンスのIDを入力し、「OK」をクリックします。

インスタンスID

  • 4.前述の 2. および 3. と同様の手順で、server02のEC2インスタンスのIDを追加します。

  • 5.「強制停止」のタブをクリックし、[停止失敗時にグループのフェイルオーバを抑制する]にチェックを入れます。
    こちらの設定を有効化することで、強制停止の実行が失敗した場合はフェールオーバーが抑制されるため、より確実に両系活性を防止することが可能です。

3.2.3 CLUSTERPROサービス起動遅延時間の設定

CLUSTERPROサービス起動時の遅延時間を設定します。
これにより、強制停止リソース実行中に対向サーバーでOS再起動などが実行された場合に、両系活性が発生することや、クラスター起動処理中に強制停止が実行されることを防止します。
サービス起動遅延時間を以下となるように設定します。

サービス起動遅延時間 >= 強制停止リソースの強制停止タイムアウト + 強制停止リソースの停止完了待ち時間 + ハートビートタイムアウト + ハートビートインターバル

サービス起動遅延時間は、「クラスタのプロパティ」の「タイムアウト」タブにある[サービス起動遅延時間]で設定できます。

CLUSTERPROサービス起動時の遅延時間を設定する代わりに、OS起動時間を調整することでも対応が可能です。
OSの起動時間を以下となるように設定します。

OSの起動時間 >= 強制停止リソースの強制停止タイムアウト + 強制停止リソースの停止完了待ち時間 + ハートビートタイムアウト + ハートビートインターバル

OS起動時間の調整手順の詳細については、インストール&設定ガイドをご参照ください。

【参考】
● CLUSTERPRO X 5.0 > Windows > インストール&設定ガイド
→第 2 章 システム構成を決定する
→2.6 ハードウェア構成後の設定
→2.6.3 OS 起動時間を調整する (必須)

● CLUSTERPRO X 5.0 > Linux > インストール&設定ガイド
→第 2 章 システム構成を決定する
→2.8 ハードウェア構成後の設定
→2.8.5 OS 起動時間を調整する (必須)
また、DISK方式によるNP解決を行う場合や共有ディスクを利用する場合はサービス起動遅延時間、もしくはOS起動時間の計算について、別の観点での考慮が必要です。
詳細については、popup【2024年版】サービス起動遅延時間設定機能の紹介も併せて参照ください。

4. NP解決時の動作確認

強制停止リソースを実行する構成、また、実行しない構成で、ネットワークパーティション状態を起こして、HAクラスターの動作を確認します。
今回は、Windows環境における動作確認の例を記載します。

ネットワークパーティション状態を起こすため、ネットワークACLの設定によりHAクラスターを構成するサーバーのAZ間をまたぐ通信を全て遮断するようにしました。これにより、サーバー間のハートビートが途絶えますが、Amazon S3上に作成したウェブサイトへのhttp通信は可能であるため、それぞれのサーバーが「相手サーバーで問題が発生した」と判断してフェールオーバーグループを起動しようとします。

4.1 強制停止リソースを実行しない場合

強制停止リソースを実行しない場合、それぞれのサーバーがフェールオーバーグループを起動するため、両系活性状態となってしまいます。

それぞれのサーバーでHAクラスターの起動状態を確認すると以下となります。それぞれのサーバーでフェールオーバーグループが起動していることが確認できます。

[server01のクラスターの起動状態]
server01でフェールオーバーグループが起動しています。

C:\Users\Administrator>clpstat
 ========================  CLUSTER STATUS  ===========================
  Cluster : cluster
  <server>
   *server01 ........: Online     ←server01は起動中
      lankhb1        : Normal           LAN Heartbeat
      httpnp1        : Normal           http resolution
    server02 ........: Offline    ←server02は停止中
      lankhb1        : Unknown          LAN Heartbeat
      httpnp1        : Unknown          http resolution
  <group>
    failover ........: Online
      current        : server01   ←server01でフェールオーバーグループが起動中
      awsvip         : Online
      md             : Online
  <monitor>
    awsvipw1         : Normal
    mdw1             : Caution
    userw            : Normal
 =====================================================================

[server02のクラスターの起動状態]
server02でフェールオーバーグループが起動しています。

C:\Users\Administrator>clpstat
 ========================  CLUSTER STATUS  ===========================
  Cluster : cluster
  <server>
    server01 ........: Offline    ←server01は停止中
      lankhb1        : Unknown          LAN Heartbeat
      httpnp1        : Unknown          http resolution
   *server02 ........: Online     ←server02は起動中
      lankhb1        : Normal           LAN Heartbeat
      httpnp1        : Normal           http resolution
  <group>
    failover ........: Online
      current        : server02   ←server02でフェールオーバーグループが起動中
      awsvip         : Online
      md             : Online
  <monitor>
    awsvipw1         : Normal
    mdw1             : Caution
    userw            : Normal
 =====================================================================

4.2 強制停止リソースを実行する場合

強制停止リソースを実行する場合、待機系サーバーではフェールオーバーグループのフェールオーバーを実行する前に強制停止リソースが動作して現用系サーバーを停止させます。そのため、両系活性を防ぐことができます。

待機系サーバーが現用系サーバーのダウンを検出した後のアラートログの出力は以下のようになります(ログの受信日時は割愛しています)。フェールオーバーグループの起動前に強制停止リソースを実行していることが確認できます。

情報  2022/10/12 06:42:00.649  server02  nm            2  サーバserver01が停止しました。 ★現用系サーバーのダウンを検出
情報  2022/10/12 06:42:04.743  server02  forcestop  5201  サーバ server01 の強制停止を要求しました。(aws, stop) ★強制停止リソースを実行開始
警告  2022/10/12 06:42:19.368  server02  mdadmn     3880  ミラーディスクmdのミラーディスクコネクトが切断されています。
警告  2022/10/12 06:42:19.603  server02  rm         1504  監視 mdw1 は警告の状態です。 (102 : ミラーディスクmdはミラーリングされていません。)
情報  2022/10/12 06:42:37.180  server02  forcestop  5202  サーバ server01 の強制停止を完了しました。(aws, stop) ★強制停止リソースの実行完了
情報  2022/10/12 06:42:37.180  server02  rc         1060  グループ failover をフェイルオーバしています。 ★フェールオーバーグループの起動開始
情報  2022/10/12 06:42:37.180  server02  rc         1010  グループ failover を起動しています。

フェールオーバー完了後、現用系サーバーのEC2インスタンスの起動状態を確認するとstoppedとなっており、現用系インスタンスが停止していることを確認できます。

C:\Users\Administrator>aws ec2 describe-instances --instance-ids i-11111111111111111 --query "Reservations[0].Instances[0].[InstanceId, State.Name]"
[
    [
        [
            "i-11111111111111111",
            "stopped"
        ]
    ]
]

さいごに

今回は強制停止リソースを利用したHAクラスターの構築手順をご紹介しました。
AWS上でネットワークパーティション発生時に両系活性をより確実に防止することができますので、強制停止リソースの利用をご検討ください。

CLUSTERPROでは、お客様のHAクラスター導入を支援する「CLUSTERPRO導入支援サービス」をご用意しております。お客様環境に合わせた設計支援や構築支援などを承っておりますので、後述の「お問い合わせ窓口」から "ご購入前のお問い合わせ" フォームまでお問い合わせください。

お問い合わせ

本記事に関するお問い合わせは、popupお問い合わせ窓口までお問い合わせください。