レック・テクノロジー・コンサルティング株式会社TECH BLOG

【CLUSTERPRO X】AWS EC2×強制停止について

Re:Q Tech Blogをご覧いただきありがとうございます。
インフラ技術部のIです。

前回の記事「【CLUSTERPRO X】AWS EC2×ネットワークパーティション解決の注意点」に続いて、今回は強制停止について簡潔に説明します。

CLUSTERPROのHAクラスタを利用するにあたり、両系活性は避けるべき重要なシチュエーションの一つです。
本記事では、AWS環境でCLUSTERPROを使用する際に両系活性を防ぐための機能である強制停止リソースについて、
具体的な実装例とその仕組みを解説します。

1.両系活性とは

両系活性とは、HAクラスター内で複数のサーバーが同時にアクティブ状態になることを指します。
この状態になると、同じデータに対して異なる操作が行われる可能性があり、データ破損の原因となってしまいます。
force0.png

これは、ネットワークパーティションなどが発生した際に、スタンバイ側のサーバーがアクティブ側がダウンしたと
認識して、自身をアクティブサーバーへ昇格させた場合に起きる現象となります。
この状態を防ぐためには、強制停止機能を活用して、確実にアクティブサーバーを1台にすることが重要です。


2.強制停止とは

強制停止は、クラスターグループ内のサーバー間においてハートビートの途絶によりサーバのダウンを認識した時に、
残りのサーバー(正常なサーバー)からダウンしたサーバーを強制的に停止させる機能となります。

(例)ハートビート通信不可となるケース
・OSクラッシュ
・OSストール
・ネットワークパーティション...等


force1.png

この機能を利用することで、ネットワークパーティションが発生した場合に、
両系活性をより確実に防ぎ、データの整合性を保つことが可能です。

3.ネットワークパーティション解決だけで両系活性を防ぐのは難しいのか

CLUSTERPROには、「ネットワークパーティション解決」という機能があります。
この機能は、PING方式やHTTP方式などを利用してネットワークパーティション対策を可能にします。

しかし、次のようなケースでは両系活性状態が発生する可能性があります。

ケース:クラスター間(ハートビート)通信のみ障害が発生
 両方(アクティブ/スタンバイ)のEC2は正常なステータス
 両方(アクティブ/スタンバイ)のEC2はネットワークパーティション解決先への通信が可能
 ハートビート間の通信のみが異常
 ※ハートビートのタイムアウト値はLinux90秒、Windows30秒となります。(CLUSTERPRO X 5.3)
force2.png

スタンバイ側から見ると、アクティブ側とのハートビート通信が取れない一方で、
ネットワークパーティション解決先とは通信ができるため、アクティブ側に異常が発生したと認識して、スタンバイ側でフェイルオーバーグループが起動します。
これにより両系活性状態が発生し、データ破損などのリスクが生じます。
force3.png

4.AWS EC2に強制停止を設定するためには

AWS環境で強制停止を利用するには、以下を設定する必要があります。

4-1.AWSおよびEC2(OS)の設定

1.IAMロールの作成
以下のIAMポリシーをIAMロールに追加します。
強制停止のアクションで再起動を使用する場合は再起動用のポリシーを適用してください。
EC2停止: aws ec2 stop-instances --instance-ids <instance-ids> --force

2.EC2へのIAMロール割り当て
1.で作成したIAMロールをクラスターグループに所属するEC2インスタンスに割り当てます。

3.EC2へのAWS CLIインストール
クラスターグループのEC2インスタンスにAWS CLIをインストールします。

4-2.CLUSTERPROの設定

1.CLUSTERPRO Web UIへログイン
CLUSTERPROをインストールしているOS上でWebブラウザを起動してWeb UIへログインします。

2.[クラスタのプロパティ]→[フェンシング]→[強制停止]から、タイプを[AWS]へ設定
[設定モード]へ遷移が必要となります。

3.[強制停止]→[プロパティ]→[利用可能なサーバ]から、強制停止を利用するサーバを選択して、[追加]をクリック
2台以上の追加が必要となります。

4.サーバごとに[インスタンスID]を入力して[OK]をクリック インスタンスIDは、AWSマネジメントコンソールなどから確認を行ってください。

AWS環境で強制停止を使用する場合の注意点
バージョンや設定の組み合わせによって、強制停止を使用できないケースもございますので、
強制停止を利用される場合はドキュメントの確認をした上で設計および設定をお願いいたします。
CLUSTERPRO® X 5.3 for Windows リファレンスガイド - 7.4.4. AWS 強制停止リソースの注意事項
CLUSTERPRO® X 5.3 for Linux リファレンスガイド - 7.4.4. AWS 強制停止リソースの注意事項

5.強制停止の仕組み

次のケースを元に、簡単な強制停止の流れについて説明します。

ケース:クラスター間(ハートビート)通信のみ障害が発生
 両方(アクティブ/スタンバイ)のEC2インスタンスは正常なステータスです。
 両方(アクティブ/スタンバイ)のEC2インスタンスはネットワークパーティション解決先への通信が可能です。
 ハートビート間の通信にのみ異常があります。
 ※ハートビートのタイムアウト値はLinux90秒、Windows30秒となります。(CLUSTERPRO X 5.3)
 ネットワークパーティション解決、強制停止リソース設定済み

この状況では、スタンバイ側のサーバーがフェイルオーバーグループを自身のサーバー上で起動しようとします。
force2.png

ネットワークパーティション解決に加えて、強制停止リソースも設定されているため、
スタンバイ側のCLUSTERPROは、両系活性を確実に防ぐためにAWS CLIを利用してアクティブ側のサーバーを停止します。
force4.png


アクティブ側のサーバーが停止された後、スタンバイ側でフェイルオーバーグループが起動され、アクティブへ昇格します。
※スタンバイ側でフェイルオーバーグループ(Application)のフェイルオーバーを実行(起動)する前に
 AWS CLIを使用した強制停止リソースが動作するため、両系活性を防ぐことが可能となります。
force5.png

このように強制停止を活用することで、両系活性の防止を確実に行うことが可能となります。

尚、フェイルオーバーグループやOSを正常に停止した場合には、強制停止リソースは使用されることはございません。

6.最後に

本記事では、AWS環境でのCLUSTERPROを用いた強制停止の仕組みとその重要性について説明させていただきました。

ネットワークパーティションが発生する状況において、両系活性を防ぐためのこの機能は、
システムの信頼性とデータの整合性を確保する上で不可欠ですので、活用することを推奨いたします。

この記事をシェアする

  • Facebook
  • X
  • Pocket
  • Line
  • Hatena
  • Linkedin

資料請求・お問い合わせはこちら

ページトップへ戻る