Azure環境でのフェールオーバークラスタリング構築に伴うトラブル事例と解決策

クラウドサービス部の山﨑です。

近年、オンプレミス環境（以下、オンプレ）からクラウドサービスに移行が進む中、オンプレを前提にしたサービスやミドルウェア、アプリケーションをクラウド環境にどのように適応させるかが現場での課題になっています。この課題に直面する企業が増える中、今回はその一例として、Windows Serverの「フェールオーバークラスタリング」をAzure環境で導入し、実際に現場で発生したトラブルと解決策について紹介します。

フェールオーバークラスタリングとは

Windows Server フェールオーバークラスタリング（以下、WSFC）とはMicrosoft社が提供するサーバ向けOS、Windows Serverの機能で、複数のサーバを1つのクラスタとして束ね、高可用性を実現します。

クラスタリングとは、同じ構成の複数のコンピュータを相互接続し、外部から見たときにあたかも1台のコンピュータのようにふるまう構成を指します。WSFCは、クラスタ内のサーバに障害が発生した場合は即座にフェールオーバーを実行することで、サーバ機能を正常に維持し続けます。特別なソフトを導入せずに、Windows Server標準の機能で高可用性を実現できるため、コスト面でも優れたソリューションです。

サーバのクラウド化（Azure）による影響

WSFCはOSの機能として搭載されていることから、オンプレ環境でクラスタリングを実装するために多くのシチュエーションで活躍してきました。しかし、システムのクラウド化に伴い、オンプレ環境では当たり前のように実装できていた機能を、そのままクラウドで実装できないケースも多くあります。今回紹介するWSFCもその一例です。

オンプレ環境ではWSFC用に仮想IPアドレスを設定することで、外部に対して1つのコンピュータのようにふるまっていました。しかし、Azure環境では、Azure仮想ネットワークから割り当てられたIPアドレスのみが使用可能という制約上、WSFCの仮想IPアドレスやVM内で設定したIPアドレスは、Azure仮想ネットワークで正しく機能せず通信ができません。

このような状況でオンプレ環境をクラウド化する際は、設計を見直し、WSFCを使わず別のソリューションでクラスタリングを実現することも考慮に入れるべきでしょう。しかし、WSFCを利用したMWが搭載されている、可能な限り現行の構成を踏襲するなどといった制約がある場合、クラウド環境に移行した後もWSFCを使う必要があるケースも存在します。

Azure環境でWSFCを構築するためには

Azure環境でWSFC用の仮想IPアドレスを使用し、Azure仮想ネットワーク上で他のコンピュータ（クライアント）から認識させるためには、Azure Load Balancer（以下、LB）を構成することで解決できます。その際、フロントエンドIPをWSFCのアプリケーションで使用する仮想IPアドレスと同一に設定する必要があります。

また、クラスタリソースにアクセスする場合には、各ノードのIPではなく、クライアントアクセスポイントの仮想IPでアクセスする必要があるため、LBの設定には"フローティングIPを有効にする"の設定を有効にすることで、クライアントアクセスポイントの仮想IPにプローブポートの設定を行います。下記の図のように、クラスタ構成のVMと接続元のクライアントとの間にLBが存在する形になります。

※ Azure 環境におけるフェールオーバー クラスター環境の構築について | Microsoft Japan Windows Technology Support Blog

Azure上でWSFCを構築する際のポイント

ここでは、実際にAzure上でWSFCを構築していく上での流れと、オンプレ環境構築との主な違いを解説します。今回構築する構成は、2台のVMを使用し、1つの共有ディスクと1つのクォーラムディスクを組み合わせた最小構成のWSFCです。

WSFC構築事前準備

NIC・ストレージの準備

WSFCの構築にはNICと共有ストレージが必須ですが、Azureはオンプレ機器と異なり、すべてAzure Portalから作成しVMに追加します。下記にAzure上でWSFCを構築する上でのポイントをまとめましたので、参考にしてください。

• NIC（ネットワークインターフェイス）について
  VM構築後に「ネットワークインターフェイスの作成」からクラスタ系間LANセグメントを用意し、VMにアタッチ、OSに認識させる。

  

• 共有ディスク
  VM構築後に「新しいディスクを作成し接続する」から各用途のストレージディスクを作成し、VMにアタッチ。
  その後、作成した共有ディスクはWSFC構築完了するまではOS（1号機）でのみディスクのセットアップを実施する。

  

Azure Load Balancerの準備

Azure上でのWSFC構築は、LB（ロードバランサ）を構築する必要があります。対象サーバ2台でWSFCを構築後、別途Azure Portal上でLBを構築し、下記の設定値に沿ってパラメータを追加していきます。フロントエンドIPやバックエンドプールは、Azure PortalのLBのメニューから簡単に設定できます。

Azure Load Balancerは下記の設定で作成します。

種類	内部
フロントエンドIP	クライアントアクセスポイントに設定した仮想IPと同じIPを設定 ※ クライアントアクセスポイントの仮想IPは、静的IPアドレスで設定すること
バックエンドプール	クラスタのノードのIP or NIC（ノードが2台の場合は2台を設定）
正常性プローブのポート	後述で設定するクラスタのIPリソースのプローブポートと同じポート番号を設定（今回は59999） ※ ここで設定したポートに応答したノードへだけLBは通信を流す動きとなる
負荷分散規則の "フローティングIPを有効にする"	オンに設定 ※ この設定により、各ノードのIPへの変換はせず、フロントエンドIPのまま、つまりクライアントアクセスポイントの仮想IPとして通信が可能

Azure Load Balancer設定後の通信設定

最後に、LB構築後の作業を紹介します。LBに各種設定値の追加後、ADサーバおよびDNSサーバにLBとそのフロントエンドIPアドレスを設定します。また、サーバ側からもLBを有効化する必要があるため、プローブポートの設定を追記します。この設定を行うことで、IPアドレスリソースの所有者となっているノードが、このプローブポートで通信をリッスンするようになり、LBへ応答を返せるようになります。

下記に、実際に設定に使用したコマンドと実行例を記載しましたので、設定作業の参考にしていただければと思います。

PS C:¥> $ClusterNetworkName="クラスタ ネットワーク 4"
PS C:¥> $IPResourceName = "IP アドレス 10.4.0.101"
PS C:¥> $ILBIP = "10.4.0.101"
PS C:¥> [int]$ProbePort = 59999
PS C:¥> Get-ClusterResource $IPResourceName | Get-ClusterParameter
 
Object                 Name                  Value                     Type
------                 ----                  -----                     ----
IP アドレス 10.4.0.101 Network               クラスタ ネットワーク 4 String
IP アドレス 10.4.0.101 ADdress               10.4.0.101                String
IP アドレス 10.4.0.101 SubnetMask            255.255.255.0             String
～省略～
IP アドレス 10.4.0.101 ProbePort             0                         UInt32
～省略～
 
PS C:¥> Get-ClusterResource $IPResourceName | Set-ClusterParameter -Multiple @{"ADdress"="$ILBIP";"ProbePort"=$ProbePort;"SubnetMask"="255.255.255.255";"Network"="$ClusterNetworkName";"EnableDhcp"=0}
 
警告: プロパティは保存されましたが、IP アドレス 10.4.0.101
がオフラインになり、再度オンラインになるまで、一部の変更が有効になりません。
 
PS C:¥> Get-ClusterResource $IPResourceName | Get-ClusterParameter
 
Object                 Name                  Value                     Type
------                 ----                  -----                     ----
IP アドレス 10.4.0.101 Network               クラスタ ネットワーク 4 String
IP アドレス 10.4.0.101 ADdress               10.4.0.101                String
IP アドレス 10.4.0.101 SubnetMask            255.255.255.255           String
～省略～
IP アドレス 10.4.0.101 ProbePort             59999                     UInt32
～省略～
PS C:¥>

ADサーバ、DNSサーバ、そしてWSFCを構築したサーバ全ての設定が完了し、疎通完了すればAzure上でのWSFCの構築は完了です。

Azure環境におけるWSFC構築に関するトラブル

ここでは、実際にAzure上でWSFCを構築した際に発生したトラブルを紹介します。

構築中に発生したADサーバ変更にともなう影響

経緯と対応

Azure環境でのWSFC構築後、ADサーバを新規に用意し、そのサーバにAD参加するという構成変更が発生しました。WSFCはAD参加していることが前提となるため、古いADサーバから新しいADに変更する必要があります。しかし、そのためには構築済みのWSFCを解体しなければなりません。以下に実際に実施したWSFC解体の流れを示します。

WSFC解体手順

WSFCを安全に解体し、AD離脱をするためには以下の流れに沿って実施します。また、WSFCに依存しているMWが搭載されている場合は、順序性を考慮しないと予期せぬ不具合が発生することもあるので注意が必要です。

• ①関連MWを削除する
• ②クラスタサービス（GUI）を起動し、WSFCに設定されている「役割」を削除する

  

• ③Powershellから以下のコマンドを打鍵し、クラスタを削除する

  PS C:¥> Remove-Cluster
   
  Remove-Cluster
  クラスタ WSFC.TEST を完全に削除しますか？
  [Y] はい(Y)　[N] いいえ(N) [S] 中断(S)　[?] ヘルプ (規定値は "Y"):

• ④上記の作業完了後、AD離脱を行う

①～④を実施することで、VMはAD参加をしていないローカルPCになります。再度WSFCを構築する場合は、AD参加から通常の手順で実施します。

リリース後に発生したAzureFirewall（FW）に関係したトラブル

経緯

WSFC自体には直接関与していませんが、前述のADサーバ変更に関係したトラブルのため紹介します。

AD変更にともなう構成の変化で、WSFCを設定したデータサーバと、そのサーバと通信するアプリケーションサーバが別のV-netになりました。Azureの特徴として、V-netピアリングを使用して別V-net間の通信を実現し、AzureFWでその通信を制御できます。しかし、稼働後にアプリケーションサーバからデータサーバへの通信が到達しないという事象が発生しました。

原因と対応

調査の結果、AzureFWを通過する通信が一定時間（240秒）無通信で、かつAzureFWがオートスケール機能によりインスタンス増減が発生した場合に、AzureFWによってセッションが切られていることが原因と判明しました。この問題を解決するために、KeepAliveパケットを有効化することで240秒以上の無通信状態を解消できました。KeepAliveとは、一定時間ごとにコネクションを確立したサーバ（クライアント）間の通信が保たれているかを確認する仕組みです。今回のようにセッションを常に維持したい場合には有効な解決策となります。

実際の設定

今回のケースでは、AzureFWの制限を避けるため240秒の制限より短い230秒のタイムアウト設定を行いました。設定はレジストリエディターまたはreg addコマンドから追加できます。また、KeepAliveパケットを送信するためにはSO_KEEPALIVEオプションを有効化する必要があります。SO_KEEPALIVEオプションに関しては、通信を確立させたいアプリケーション側で有効にできる場合もあるので、検討時に確認してみてください。

キー	キー	HKEY_LOCAL_MACHINE¥SYSTEM¥CurrentControlSet¥Service¥TCPIP¥Parameters
値の名前	KeepAliveTime	0x38480（230000ミリ秒）
	KeepAliveInterval	0x3e8（1000ミリ秒）（デフォルト）
	TcpMaxDataRetransmissions	0x5（5回）（デフォルト）

※ KeepAliveTime：最後のデータの送受信が行われてから、KeepAliveパケットを送信するまでの時間。デフォルトは2時間
※ KeepAliveInterval：KeepAliveパケットの送信間隔
※ TcpMaxDataRetransmissions：KeepAliveパケットの送信回数

設定後、サーバ間の通信断は発生しておらず、上記の対応により事象が解消されたことが確認されました。

おわりに

今回、WSFCをAzure上で構築するという珍しいケースに直面したため、事例を紹介しました。この経験は、ラックとしても、私個人としても貴重なものとなりました。本記事が皆様の問題解決の一助になれば幸いです。

ラックは、オンプレ環境からAzure、AWSやOCIなどのパブリッククラウドへの移行に関する豊富な知識とノウハウを持っており、総合的な導入支援や活用支援を行っています。クラウドへの環境移行を検討される際は、ぜひラックまでお問い合わせください。

プロフィール