GCE での SQL Server Failover Cluster Instance (FCI)の構築における共有ディスクの評価

Posted at 2024-11-21

はじめに

この記事では Compute Engine 上に SQL Serverをデプロイし、共有ディスクを使用したFCI(Failover Cluster Instance)の構築検証の内容を共有します。

FCIの構成によって、WSFCのクラスタノード間で、アクティブな単体のノードを常時起動し、Failover時には別のノードに自動切り替えを行うことで可用性を高めることができます。

FCIはWSFCノード間でアクセス可能な共有ストレージを必要とします。
共有ストレージには以下の３つのパターンがあります。

共有ディスク: 複数のノードにアタッチされた物理ディスクに対してそれぞれのノードから直接アクセス可能にする方式。Compute Engine では、Persistent Disk を使用することで、複数の VM インスタンスからアクセスできる共有ディスクを構成できる。
SAN (Storage Area Network)：専用のネットワークを介して、複数のサーバーがストレージにアクセスするためのネットワーク。
SANless: トラディショナルな SAN を使用せずに、通常のファイルシステムを介してノード間でデータを複製する構成。同期複製と非有同期複製のオプションがあり、同期複製の場合はデータロスがない。SANlessは SCIOS DataKeeper, StarWind などの3rd party製品の導入によって構築できる。

上記２つは公式ドキュメントに記載があります。

マルチライターモードで永続ディスクを使用する SQL Server FCIの構成

(S2D)記憶域スペースダイレクトを使用するSQL Server FCIの構成

SANlessは SIOS Webinar – SQL Server High Availability on the Google Cloud Platform が参考になりました。

公式手順通りにやっていけば良いのですが、今回はいくつか気になる制限があったマルチライター方式にフォーカスします。

Multi-writer mode ディスクの制約

前提として理解しておきたいのが、マルチライターモードの制約です。

以下のドキュメントからいくつか要点をピックアップします。
https://cloud.google.com/compute/docs/disks/sharing-disks-between-vms

FCIを構成するのに使えると明記されてあります。

With multi-writer mode, multiple VMs can read and write to the same disk. This is useful for highly-available (HA) shared file systems and databases like SQL Server Failover Cluster Infrastructure (FCI).

しかし、WSFCのノードは単一ゾーンに縛られるということです。

You can share a zonal disk only between VMs in the same zone. Regional disks can be shared only with VMs in the same zones as the disk's replicas.

最大2台までのアタッチとあるので、単一Standbyの構成に限定される可能性がありますが、3つのVMからSSD永続化ディスクへのアタッチを試したところ一応成功しました....

You can attach an SSD Persistent Disk volume in multi-writer mode to up to two N2 virtual machine (VM) instances simultaneously so that both VMs can read and write to the disk.

そして、マルチライターモードでは、SSD永続化ディスクより Hyperdisk Balanced volumes が推奨とのことです。Hyperdiskについては後で確認します。

Caution: Google recommends that you use Hyperdisk Balanced volumes in multi-writer mode instead of SSD Persistent Disk volumes.

VMアタッチのゾーンは以下に限られると公式に書いてあったが、実際試したところ東京のゾーンでも可能でした。しかし、大阪ではできませんでした。

You can create a Persistent Disk volume in multi-writer mode in any zone, but you can only attach that disk to VMs in the following locations:
australia-southeast1
europe-west1
us-central1 (us-central1-a and us-central1-c zones only)
us-east1 (us-east1-d zone only)
us-west1 (us-west1-b and us-west1-c zones only)

いくつか公式ドキュメントの記載で解消できない疑問点はありますが、Google Cloudで共有ディスクを設定する上では重要なページです。

公式に沿った構築 - Multi-writer mode SSD Persistent Diskを共有ディスク化

前述で確認したドキュメントによると SSD永続化ディスクよりHyperdiskの方が推奨されているそうですが、公式の共有ディスクによるFCI構築手順はSSDでしたのでまずはSSDの検証結果を記述します。

詳細の構築手順はマルチライターモードで永続ディスクを使用する SQL Server FCIの構成を参照。

やることをまとめると以下です。

ドメインコントローラーの準備 : Google Cloud ConsoleでManaged Service for Microsoft Active Directoryへ移動し、AD Domainを作成。
- VPC, region, 利用可能なIP CIDR range をセット
- FQDNをセット：Privateのものなので好きな値をセット。例：ad.instiny.internal
Firewallの作成
- WSFCノード間の双方向通信許可
- SQL-> WSFCノード間の通信許可
- Internal LB -> WSFCノードの許可
VMの作成
- Spread-placement policy を設定して、同じゾーン内のVMでホストを分散させる
- ノード上で必要なWindowsFeature（Failover-Clustering等）と FirewallのPowershellを準備
- enable-wsfc=true でVM作成 (2 nodes & 1 witness)
作成した3つのVMをADに参加させる
- それぞれのVMのユーザーネーム・パスワードをGoogle ConsoleのVMページから設定
- RDPで接続し、管理者権限でPowershellを起動し、Add-Computer -Domain ad.instiny.internal -Restart を実行
- この時、ユーザー・パスワードを求められるが、Managed Service for Microsoft Active DirectoryのAdmin user/pass を入力。setupadmin　というユーザー名。
共有ディスクの作成
- ディスクを　multi-writer　の pd-ssd を3つ作成
- 各ノードに３つのディスクをアタッチ
IPのリザーブ
- WSFC cluster IP
- Internal load balancer IP
Witness file share の作成
- file share witness informationを格納するフォルダの作成
- Cluster nodes が file share への読み取り、書き込みする権限を付与
- SMB (Server Message Block) ShareによるSQL File Share Witnessの作成
クラスタのデプロイ
- Node1 にドメインユーザーでRDP接続し Cluster IPをセットしてクラスタを作成
- Witness に接続し、Clusterに file share のアクセス付与（SmbShareAccess）
- Node1に戻り、witnessのfile shareをcluster quorum として設定
- ADGroupmember に作成したクラスタを追加
FCI の Storage pool の作成
DefaultでインストールされているSQL Serverのアンインストール
SQL Server Failover Clustering Instanceのインストール
- Failover Clusterの新規作成
- Failover Clusterのノードの追加
Internal LB (Passthrough)の作成
- UMIGを作成し、クラスタノードを umigにインスタンス追加
- healthcheck の作成
- helthcheckと umig の backend service を作成
- internal lb の設定

手順通り構築して、Faiolverの検証が成功しました。次は同じ手順で Hyperdisk に置き換えて構築を試みます。

HyperdiskはFCIをサポートしていない

基本的に手順は同じなのですが、もちろんディスク作成の時はコマンドを入れ替えます。


PD_SIZE=50

gcloud beta compute disks create datadisk-1 \
  --size $PD_SIZE \
  --type hyperdisk-balanced \
  --access-mode READ_WRITE_MANY \
  --zone asia-northeast1-b
gcloud beta compute disks create datadisk-2 \
  --size $PD_SIZE \
  --type hyperdisk-balanced \
  --access-mode READ_WRITE_MANY \
  --zone asia-northeast1-b
gcloud beta compute disks create datadisk-3 \
  --size $PD_SIZE \
  --type hyperdisk-balanced \
  --access-mode READ_WRITE_MANY \
  --zone asia-northeast1-b

VMアタッチも問題なくできました。

gcloud compute instances attach-disk node-1 --disk datadisk-1
gcloud compute instances attach-disk node-1 --disk datadisk-2
gcloud compute instances attach-disk node-1 --disk datadisk-3

gcloud compute instances attach-disk node-2 --disk datadisk-1
gcloud compute instances attach-disk node-2 --disk datadisk-2
gcloud compute instances attach-disk node-2 --disk datadisk-3

その後、順調に進んでいたのですが、Storage pool の作成で問題が起きました。

PS C:\Windows\system32> $Pool = New-StoragePool `
>>   -StorageSubsystemFriendlyName 'Clustered*' `
>>   -FriendlyName FciPool `
>>   -PhysicalDisks $ClusterDisks `
>>   -ResiliencySettingNameDefault Simple `
>>   -Verbose
New-StoragePool : One or more physical disks are not supported by this operation.

Extended information:
One or more physical disks are not in the specified storage subsystem.

Physical Disks:
{41d974ce-8f84-11ef-8d15-806e6f6e6963}:PD:{55305a4b-865a-74da-f8bb-905ec3bb3cbd}
{41d974ce-8f84-11ef-8d15-806e6f6e6963}:PD:{f0bbaa7d-1e12-be87-795c-2820fd0e767b}
{41d974ce-8f84-11ef-8d15-806e6f6e6963}:PD:{f9b7c846-4db1-f6df-b7a6-ef6a513c2882}

Activity ID: {dae39d76-d0ba-4b18-b3a7-7e47f9722f60}
At line:1 char:9
+ $Pool = New-StoragePool `
+         ~~~~~~~~~~~~~~~~~
    + CategoryInfo          : NotSpecified: (StorageWMI:ROOT/Microsoft/...torageSubSystem) [New-StoragePool], CimExcep
   tion
    + FullyQualifiedErrorId : StorageWMI 51000,New-StoragePool

単純にサポートされていないのでしょうか。

$ClusterDisks = Get-PhysicalDisk -CanPool $True |
  Where-Object { ($_ |
    Get-PhysicalDiskStorageNodeView |
    Select-Object -Property StorageNodeObjectId) -like ('*' + $NodeName + '*') }

Storage pool作成時の Get-PhysicalDisk -CanPool $True や Get-PhysicalDiskStorageNodeView の出力結果を比較しても特に違いは見られませんでした。

どうやら、Hyperdiskを使用したFCIはGoogle Cloud サポートの範囲外であるようです。

Hyperdiskボリュームをストレージプールに適したディスクとして認識しておらず、Hyperdiskが従来のSSD永続ディスクとは異なる形式でOSに認識されるためと考えられます。

以下のマルチライターではHyperdiskを推奨する記述があったので、公式手順のSSD永続ディスクではなくHyperdiskを使うことで、より高いIOPSの構成を組めるんじゃないかという仮説からこの検証を行いました。

Caution: Google recommends that you use Hyperdisk Balanced volumes in multi-writer mode instead of SSD Persistent Disk volumes.

ちなみにS2Dでも同様で、Hyperdiskは現時点では公式サポート対象外となりSSD永続ディスクが最適なストレージとなります。

結論

今回の検証では、Google Cloudのマルチライターモードを利用して、Compute Engine上でSQL ServerのFailover Cluster Instance（FCI）を構築しました。公式ドキュメントに沿って進めた結果、SSD永続ディスクを使用したFCI構築は問題なく完了し、フェイルオーバー動作も正常に機能しました。

一方、Hyperdisk を用いた構築では、ストレージプール作成時にエラーが発生し、公式ではマルチライターモードを選択する際はHyperdiskが推奨されているものの、現時点ではFCIの構成に対応していない事が分かりました。

また、共有ディスク方式だとクラスタVMが同一ゾーンに限定される制約があり、これは多くの可用性要件を満たさないと考えられます。

その場合、S2DやSANlessの方が有力な選択肢と考えられます。

You get articles that match your needs
You can efficiently read back useful information
You can use dark theme

What you can do with signing up