Japan
サイト内の現在位置を表示しています。
Azureで両系活性を防止する方法(Windows/Linux)
CLUSTERPRO オフィシャルブログ ~クラブロ~はじめに
Microsoft Azure(以降、Azure)において、HAクラスターの両系活性防止を考慮したHAクラスターの構築を試してみました。
CLUSTERPROでは、両系活性を防止する方法としてネットワークパーティション解決(以降、NP解決)が設定可能です。しかし、NP解決を設定したとしてもOSストールやHAクラスターを構築するサーバー間の通信断などの障害が起きた場合は両系活性が発生する可能性があります。そのような場合にも両系活性を発生させないようにするために強制停止リソースという機能も用意されており、Azure用の強制停止リソースはCLUSTERPRO X 5.1から利用可能となっています。
今回は、AzureでHAクラスターを構築し、両系活性防止用にNP解決リソースおよび強制停止リソースを設定する手順を紹介します。
この記事の内容
1. 両系活性防止の必要性
両系活性
両系活性とは、ネットワークパーティション(スプリットブレイン)の状態に陥ったHAクラスターにおいて、複数のサーバーが同じフェールオーバーグループを起動している事象のことです。事象のイメージについては「HAクラスター入門 ~用語解説3~」を参照してください。両系活性が発生すると各サーバーで動作している業務アプリケーションはそれぞれ独立して業務データの読み書きを行うため、両系でのサービス稼働を想定していない場合はサーバー間のデータ不整合など重大な問題に繋がります。そのため、両系活性の防止策が大切となります。
NP解決リソース
NP解決リソースは、相手サーバーとのハートビートの途絶を検出すると、相手サーバーがダウンしたのか、自分自身がネットワークパーティションの状態に陥ったのか、どちらであるかを判別する処理を行います。その際にあらかじめ指定した対象(ネットワーク装置、共有ディスク、サーバー)に各サーバーからアクセスを試みて、その結果からネットワークパーティションであるかを判別します。
その結果、指定した対象と疎通可能なサーバーは自分が業務継続するべきサーバー=現用系になるべきと判断して自サーバー上でフェールオーバーグループを起動します。一方で疎通不可なサーバーは自分がネットワーク的に分断されたと判断して自分自身をシャットダウンします。これによって共有データの破壊を防止します。
強制停止リソース
強制停止リソースは、現用系サーバーのダウンを認識したときに待機系サーバーで動作する機能で、現用系サーバーを外部から強制的に停止させることができます。これによりネットワークパーティション(スプリットブレイン)の状態となった場合でも、NP解決リソースによる対応に加えて強制停止リソースを利用してサーバーを停止させることで両系活性の防止をより確実なものにすることができます。
強制停止リソースを実行する契機は、ハートビートタイムアウトにより現用系サーバーのダウンを検出し、現用系サーバーで起動していたフェールオーバーグループを待機系サーバーで起動する場合となります。Cluster WebUIなどからサーバーを正常に停止した場合や、ダウンしたサーバー上でフェールオーバーグループが起動しておらずフェールオーバーが発生しない、といった場合は強制停止リソースを実行しないため、不必要なタイミングでサーバーを強制停止することはありません。
本記事ではAzure CLIを利用してサーバーを停止するAzure強制停止リソースを使用します。NP解決リソース、および、強制停止リソースの詳細については、リファレンスガイドをご参照ください。
- CLUSTERPRO X 5.2 > Windows > リファレンスガイド
→ 第 6 章 ネットワークパーティション解決リソースの詳細
→ 第 7 章 強制停止リソースの詳細
- CLUSTERPRO X 5.2 > Linux > リファレンスガイド
→ 第 6 章 ネットワークパーティション解決リソースの詳細
→ 第 7 章 強制停止リソースの詳細
2. 構築するHAクラスター構成
東日本リージョンの環境にHAクラスターを構築します。構築するHAクラスターの構成図は以下の通りです。

Azure Virtual Machines(以降、VM)をHAクラスター化するにあたって、現用系/待機系の制御用にAzureの内部ロードバランサーを利用します。この内部ロードバランサーのバックエンドサーバーの切り替えのためにAzureプローブポートリソースを使用します。
VM間のデータ共有のためにミラーディスクリソースを使用します。両系活性防止のためにPing NP解決リソースを追加し、ターゲットには構成情報に登録したインタコネクトLAN経由でPing応答を返却可能な、クラスターサーバー以外の常時稼動している装置を指定します。今回はPing応答装置としてクライアント用VMを指定します。実際にNP解決リソースを設定する場合のNP解決方法およびターゲットはHAクラスターを構築する環境に合わせて適切なものを使用してください。
Azure強制停止リソースもあわせて設定します。Azure強制停止リソースは内部でAzure CLIを実行しますが、VMが内部ロードバランサー内にあるためそのままではAzure CLIがインターネット上のAzureエンドポイントと通信できません。そこで外部ロードバランサーを追加し、送信規則を設定することでAzureエンドポイントとの通信を可能にします。NATゲートウェイでも同様のことは可能ですが、ゾーン冗長性を持たせるためにはゾーンごとに配置する必要があること、外部ロードバランサーよりもコストがかかることから本記事では外部ロードバランサーを採用しています。
3. HAクラスター構築手順
Azureにおける「内部ロードバランサーを使用したミラーディスク型のHAクラスター」の構築手順をご紹介します。構築手順の詳細については、Azure構築ガイドをご参照ください。
- Windows > クラウド > Microsoft Azure
→ CLUSTERPRO X 5.2 向け HAクラスタ 構築ガイド
→ 第6章 構築手順 (内部ロードバランサーを使用したHA クラスタの場合)
- Linux > クラウド > Microsoft Azure
→ CLUSTERPRO X 5.2 向け HAクラスタ 構築ガイド
→ 第6章 構築手順 (内部ロードバランサーを使用したHA クラスタの場合)
今回の構成ではAzure構築ガイドの構成に加えてAzure強制停止リソース、および外部ロードバランサーを追加しています。また、可用性セットではなく可用性ゾーンを指定しています。
3.1 リソース グループおよびネットワークの作成
Azure portalから、東日本リージョンに以下のリソース グループおよびネットワークを作成します。
名前: TestGroup1
リージョン: (Asia Pacific) Japan East
仮想ネットワーク
名前: Vnet1
リージョン: (Asia Pacific) Japan East
アドレス空間: 10.5.0.0/16
サブネット1
名前: Vnet1-1
アドレス範囲: 10.5.0.0/24
内部ロードバランサー
名前: TestLoadBalancer
リージョン: (Asia Pacific) Japan East
SKU: Standard
種類: 内部
レベル: 地域
フロントエンドIP構成
名前: TestFrontend
IPバージョン: IPv4
仮想ネットワーク: Vnet1
サブネット: Vnet1-1
割り当て: 静的
IPアドレス: 10.5.0.200
可用性ゾーン: ゾーン冗長
バックエンドプール
名前: TestBackendPool
仮想ネットワーク:Vnet1
バックエンドプールの構成: NIC
IP構成: 10.5.0.5、10.5.0.6
インバウンド規則
負荷分散規則
名前: TestLoadBalancingRule
プロトコル: TCP
ポート: 80
バックエンドポート: 8080
正常性プローブ:
名前: TestHealthProbe
プロトコル: TCP
ポート: 12345
サイクル間隔(秒): 5
外部ロードバランサー(SNAT用)
名前: TestExternalLoadBalancer
リージョン: (Asia Pacific) Japan East
SKU: Standard
種類: パブリック
レベル: 地域
フロントエンドIP構成
名前: TestExternalFrontend
IPバージョン: IPv4
IPの種類: IPアドレス
パブリックIPアドレス: (任意のパブリックアドレス)
Gateway Load Balancer: なし
バックエンドプール
名前: TestExternalBackendPool
仮想ネットワーク:Vnet1
バックエンドプールの構成: NIC
IP構成: 10.5.0.5、10.5.0.6
送信規則
名前: TestExternalOutboundRule
IPバージョン: IPv4
フロントエンドIPアドレス: TestExternalFrontend
プロトコル: All
アイドルタイムアウト(分): 4
TCPリセット: 有効
バックエンドプール:TestExternalBackendPool
ポートの割り当て:送信ポートの数を手動で選択する
送信ポート 選択基準:インスタンスごとのポート
インスタンスごとのポート:0
3.2 VMの作成
Azure portalから、東日本リージョンにクライアントおよびHAクラスター用のVMを作成します。IPアドレスは初期設定では動的割り当てとなっているため、静的割り当てに変更します。
クライアント:
ホスト名: client
リージョン: (Asia Pacific) Japan East
可用性ゾーン:なし
IPアドレス1: 10.5.0.4 (サブネット1)
サーバー#1:
ホスト名: server1
リージョン: (Asia Pacific) Japan East
可用性ゾーン:1
IPアドレス1: 10.5.0.5 (サブネット1)
サーバー#2:
ホスト名: server2
リージョン: (Asia Pacific) Japan East
可用性ゾーン:2
IPアドレス1: 10.5.0.6 (サブネット1)
サーバー#1、#2には、CLUSTERPRO XおよびAzure CLIをインストールします。本記事ではWindows、LinuxそれぞれのHAクラスターに対してCLUSTERPRO X 5.2、およびAzure CLI version 2.66.0をインストールし、動作確認しました。
各VMについて、Firewallのポート開放やディスク構築などOS上で必要な設定も忘れずに行っておきます。
3.3 マネージドIDの設定
Azure CLIを実行する際の認証に、システム割り当てマネージドID(以降、マネージドID)を使用します。マネージドIDを使用することで、コード内に資格情報を格納せずに、Azureリソースをクラウドサービスに対して認証させることができます。
Azure portalでAzure カスタム ロールを作成し、Azure強制停止リソースを利用するためにVMに付与する必要がある権限を個別に追加します。マネージドIDに作成したAzure カスタム ロールを割り当てることで、HAクラスターを構築するVMに、VMなどのAzureリソースに対する操作権限を追加します。
マネージドIDの設定手順は次の通りです。
- 1)HAクラスターを構築する各VMでシステム割り当てマネージドIDを有効化
- 2)Azure カスタム ロールを作成し、必要なアクセス許可を追加
- 3)マネージドIDに作成したAzure カスタム ロールを割り当て
以下に、各手順の詳細を記載します。
3.3.1 マネージドIDの有効化
HAクラスターを構築する各VMのシステム割り当てマネージドIDを有効にします。
各VMに対して、下記操作を実行します。
- 1.Azure portalから、HAクラスターを構築するVM(server1、または、server2)を選択します。
- 2.左側のパネルの[セキュリティ]-[ID]をクリックします。
- 3.[システム割り当て済み]タブの[状態]を「オン」に設定して保存します。
3.3.2 カスタム ロールの作成
Azure カスタム ロールを作成し、必要なアクセス許可を追加します。
下記操作を実行します。
- 1.Azure portalから、HAクラスターを構築するVM用に作成したリソース グループ(TestGroup1)を選択します。
- 2.左側のパネルの[アクセス制御(IAM)]をクリックします。
- 3.[カスタムロールを作成する]から[追加]をクリックします。
- 4.[基本]タブでカスタム ロール名「CustomRoleForceStop」を入力します。
- 5.[アクセス許可]タブで次のアクセス許可を追加します。
- Microsoft.Compute/virtualMachines/deallocate/action
- Microsoft.Compute/virtualMachines/powerOff/action
- Microsoft.Compute/virtualMachines/restart/action
- Microsoft.Compute/virtualMachines/write
- Microsoft.Compute/virtualMachines/read
- Microsoft.Compute/disks/write
- Microsoft.Network/networkInterfaces/join/action - 6.[確認と作成]タブから[作成]をクリックします。
3.3.3 マネージドIDへのカスタムロールの割り当て
マネージドIDに作成したAzure カスタム ロールを割り当てます。
下記操作を実行します。
- 1.Azure portalから、HAクラスターを構築するVM用に作成したリソース グループ(TestGroup1)を選択します。
- 2.左側のパネルの[アクセス制御(IAM)]をクリックします。
- 3.[このリソースへのアクセス権の付与]から[ロールの割り当ての追加]をクリックします。
- 4.[ロール]タブでカスタム ロール(CustomRoleForceStop)を選択します。
- 5.[メンバー]タブで[アクセスの割り当て先]に[マネージドID]を選択します。続けて[+メンバーを選択する]をクリックします。
- 6.右側に[マネージドIDの選択]パネルが表示されます。[マネージドID]に[仮想マシン]を選択し、HAクラスターを構築するVM(server1とserver2)を選択して[選択]をクリックします。
- 7.[レビューと割り当て]タブから[レビューと割り当て]をクリックします。
3.4 サービスプリンシパルの作成
Azureサービスに安全にアクセスするためのサービスプリンシパルおよび証明書を作成します。これはCLUSTERPROのAzure DNSリソースやAzure強制停止リソースなどが内部でAzure CLIを実行する際に必要となります。
以降はWindows環境でのコマンド実行、設定手順となりますが、Linux環境でもほとんど同様の手順で実施可能です。
任意のVM上で、Microsoft組織アカウントでログインします。
> az login -u <アカウント名>
サービスプリンシパルを作成し、登録します。Cluster WebUIのAzure強制停止リソース設定時に入力が必要なため、出力された内容は必ずメモ帳などにコピーしてください。また、"fileWithCertAndPrivateKey"が示すパスに証明書ファイルが保存されるため、HAクラスターを構築する各VMにコピーして配置します。
以下の例では、C:\Users\testlogin\examplecert.pemに証明書ファイルが作成されます。
> az ad sp create-for-rbac --display-name azure-test --create-cert --years 10 --role Contributor --scopes <サービスプリンシパ ルのロールの割り当てが適用されるスコープ>
{
"appId": "11111111-2222-3333-4444-555555555555",
"displayName": "azure-test",
"fileWithCertAndPrivateKey": "C:\\Users\\testlogin\\examplecert.pem",
"password": null,
"tenant": "aaaaaaaa-bbbb-cccc-dddd-eeeeeeeeeeee"
}
ログアウトします。
> az logout
3.5 HAクラスターの構築
Cluster WebUIを使用してHAクラスターを構築します。
CLUSTERPROの構成は次の通りです。また、サービスを提供する場合は適宜必要なグループリソースなどを追加してください。
クラスター名: Cluster1
サーバー名: server1、server2
フェールオーバーグループ:
名前: failover1
グループリソース:
azurepp1 (Azureプローブポートリソース)
md1 (ミラーディスクリソース)
監視リソース:
azurelbw1 (Azureロードバランス監視リソース)
azureppw1 (Azureプローブポート監視リソース)
mdw1 (ミラーディスク監視リソース)
クラスター名: Cluster1
サーバー名: server1、server2
フェールオーバーグループ:
名前: failover1
グループリソース:
azurepp1 (Azureプローブポートリソース)
md1 (ミラーディスクリソース)
モニタリソース:
azurelbw1 (Azureロードバランスモニタリソース)
azureppw1 (Azureプローブポートモニタリソース)
mdnw1 (ミラーディスクコネクトモニタリソース)
mdw1 (ミラーディスクモニタリソース)
3.6 NP解決リソースの設定
Ping NP解決リソースは、以下のように設定します。
- 1.Cluster WebUIに接続後、設定モードから「クラスタのプロパティ」を開き、「フェンシング」タブをクリックします。
- 2.「NP解決一覧」にPing NP解決リソースを追加します。ターゲットにはクライアント用VMのIPアドレスである10.5.0.4を指定します。
3.7 強制停止リソースの設定
強制停止リソースは、以下のように設定します。
- 1.Ping NP解決リソースを設定した「フェンシング」の画面にて、強制停止のタイプとして「Azure」を選択し、「プロパティ」をクリックします。
- 2.「利用可能なサーバ」から「server1」を選択し、「追加」をクリックします。
- 3.「仮想マシン名」にserver1を入力し、「OK」をクリックします。

- 4.前述の 2.および 3.と同様の手順で、server2の仮想マシンを追加します。
- 5.「強制停止」のタブをクリックし、「停止失敗時にグループのフェイルオーバを抑制する」にチェックを入れます。こちらの設定を有効化することで、強制停止の実行が失敗した場合はフェールオーバーが抑制されるため、より確実に両系活性を防止することが可能です。
- ※「強制停止アクション」の値はCLUSTERPRO X 5.1までは「stop」、5.2以降では「stop and deallocate」を選択します。これはVMの停止+リソース割り当て解除のアクションとなります。
- ※リソース割り当てを解除せずに即時停止させたい場合は「stop only」を選択します(CLUSTERPRO X 5.2以降で選択可能)。
- 6.「Azure」タブをクリックし、Azureのサービスプリンシパルの情報を入力します。「3.4 サービスプリンシパルの作成」で控えておいた内容をもとに、「ユーザURI」には"appId"の値、「テナントID」には"tenant"、「サービスプリンシパルのファイルパス」には"fileWithCertAndPrivateKey"の値を入力します。「リソースグループ名」にはVMの属するリソース グループ名を指定します。
3.8 CLUSTERPROサービス起動遅延時間の設定
CLUSTERPROサービス起動時の遅延時間を設定します。これにより、強制停止リソース実行中に対向サーバーでOS再起動などが実行された場合に、両系活性が発生することや、クラスター起動処理中に強制停止が実行されることを防止します。サービス起動遅延時間を以下となるように設定します。
サービス起動遅延時間は、「クラスタのプロパティ」の「タイムアウト」タブにある[サービス起動遅延時間]で設定できます。
CLUSTERPROサービス起動時の遅延時間を設定する代わりに、OS起動時間を調整することでも対応が可能です。
OSの起動時間を以下となるように設定します。
OS起動時間の調整手順の詳細については、インストール&設定ガイドをご参照ください。
- CLUSTERPRO X 5.2 > Windows > インストール&設定ガイド
→ 第 2 章 システム構成を決定する
→ 2.6 ハードウェア構成後の設定
→ 2.6.3 CLUSTERPRO のサービス起動時間を調整する (必須)
- CLUSTERPRO X 5.2 > Linux > インストール&設定ガイド
→ 第 2 章 システム構成を決定する
→ 2.8 ハードウェア構成後の設定
→ 2.8.5 CLUSTERPRO のサービス起動時間を調整する (必須)
また、DISK方式によるNP解決を行う場合や共有ディスクを利用する場合はサービス起動遅延時間、もしくはOS起動時間の計算について、別の観点での考慮が必要です。詳細については、【2024年版】サービス起動遅延時間設定機能の紹介も併せて参照ください。
4 NP解決時の動作確認
強制停止リソースを実行する構成、また、実行しない構成で、ネットワークパーティション状態を起こして、HAクラスターの動作を確認します。
今回は、Windows環境における動作確認の例を記載します。
ネットワークパーティション状態を起こすため、server1、server2の間の通信を遮断します。本記事では、Windows Defender ファイアウォールにおいて、お互いに相手サーバーとの送受信をブロックするように受信規則、送信規則を追加します。これにより、サーバー間のハートビートが途絶えますが、Ping応答装置代わりのclientへのPing通信は可能であるため、それぞれのサーバーが「相手サーバーで問題が発生した」と判断してフェールオーバーグループを起動しようとします。

なお、Linuxの場合はfirewall-cmdなど、ディストリビューションで用意されたコマンドを使用してください。
4.1 強制停止リソースを設定しない場合
強制停止リソースを設定しない場合、それぞれのサーバーがフェールオーバーグループを起動するため、両系活性状態となってしまいます。
それぞれのサーバーでHAクラスターの起動状態を確認すると以下となります。それぞれのサーバーでフェールオーバーグループが起動していることが確認できます。
[server1のクラスターの起動状態]
server1でフェールオーバーグループが起動しています。
>clpstat
======================== CLUSTER STATUS ===========================
Cluster : Cluster1
<server>
*server1 .........: Online ←server1は起動中
lankhb1 : Normal LAN Heartbeat
pingnp1 : Normal ping resolution
server2 .........: Offline ←server2は停止中
lankhb1 : Unknown LAN Heartbeat
pingnp1 : Unknown ping resolution
<group>
failover1 .......: Online
current : server1 ←server1でフェールオーバーグループが起動中
azurepp1 : Online
md1 : Online
<monitor>
azurelbw1 : Normal
azureppw1 : Normal
mdw1 : Caution
userw : Normal
=====================================================================
[server2のクラスターの起動状態]
server2でフェールオーバーグループが起動しています。
>clpstat
======================== CLUSTER STATUS ===========================
Cluster : Cluster1
<server>
server1 .........: Offline ←server1は停止中
lankhb1 : Unknown LAN Heartbeat
pingnp1 : Unknown ping resolution
*server2 .........: Online ←server2は起動中
lankhb1 : Normal LAN Heartbeat
pingnp1 : Normal ping resolution
<group>
failover1 .......: Online
current : server2 ←server2でフェールオーバーグループが起動中
azurepp1 : Online
md1 : Online
<monitor>
azurelbw1 : Normal
azureppw1 : Normal
mdw1 : Caution
userw : Normal
=====================================================================
4.2 強制停止リソースを設定する場合
強制停止リソースを設定する場合、待機系サーバーではフェールオーバーグループのフェールオーバーを実行する前に強制停止リソースが動作して現用系サーバーを停止させます。そのため、両系活性を防ぐことができます。
待機系サーバーが現用系サーバーのダウンを検出した後のアラートログの出力は以下のようになります。フェールオーバーグループの起動前に強制停止リソースを実行していることが確認できます。
異常 2025/01/07 07:46:44.542 server2 nm 102 サーバserver1が停止しました。
警告 2025/01/07 07:46:48.354 server2 mdadmn 3880 ミラーディスクmd1のミラーディスクコネクトが切断されています。
情報 2025/01/07 07:46:48.996 server2 forcestop 5201 サーバ server1 の強制停止を要求しました。(azure, stop and deallocate)
警告 2025/01/07 07:47:16.410 server2 rm 1504 監視 mdw1 は警告の状態です。 (105 : ミラーディスクmd1のデータの新旧が未確定です。)
情報 2025/01/07 07:47:20.254 server2 forcestop 5202 サーバ server1 の強制停止を完了しました。(azure, stop and deallocate)
情報 2025/01/07 07:47:20.254 server2 rc 1060 グループ failover1 をフェイルオーバしています。
情報 2025/01/07 07:47:20.254 server2 rc 1010 グループ failover1 を起動しています。
情報 2025/01/07 07:47:25.995 server2 rc 1011 グループ failover1 の起動が完了しました。
情報 2025/01/07 07:47:26.010 server2 rc 1061 グループ failover1 のフェイルオーバが完了しました。
フェールオーバー完了後、Azure portalから現用系サーバーのEC2インスタンスの起動状態を確認すると「停止済み(割り当て解除)」となっており、現用系インスタンスが停止していることを確認できます。
まとめ
今回は強制停止リソースを利用したHAクラスターの構築手順をご紹介しました。
Azure上でネットワークパーティション発生時に両系活性をより確実に防止することができますので、強制停止リソースの利用をご検討ください。

お問い合わせ
