Azure共有ディスクを利用したWSFC（LBなし / 分散ネットワーク名）

# Windows Server Failover Cluster (WSFC)　を作る
検証のために Azure 上で Windows Server Failover Cluster (WSFC)　を構築したのですが、
　・ロードバランサーがいるんだっけ…いらないんだっけ…
　・クラスター作成のオプションってなんだったっけ…
等々を忘れていて手間取りましたので、備忘を兼ねて整理しておきます。


クラスタは以下のような形で、構築します。
　- 仮想マシン(b2ms) x2
　- OS は Windows Server 2019 以降
　- 分散ネットワーク名(DNN)で構築
　- 共有ディスクを利用する
　- スケールアウトファイルサーバーも構成する

構築時に使用した、ドメイン参加～スケールアウトファイルサーバーの設定を行う Powershell も残してみました。

# Azure 上で WSFC を構成する際の LB 要否

Windows Server Failover Cluster (WSFC) の構成パターンとして、仮想ネットワーク名(VNN)を用いる構成と、分散ネットワーク名 (DNN)を用いる構成があります。

Azure 上での構成を前提に、少しまとめてみました。

|| 従来<br>仮想ネットワーク名 (VNN) + Azure Load Balancer | Windows Server 2019 以降<br> 分散ネットワーク名 (DNN) |
|:-:|:-:|:-:|
| 構成イメージ | ![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1461633/01c2b279-f41e-4050-d201-6138dd770975.png)  | ![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1461633/8d1df516-1e0a-91c9-f9c3-c0649626bdfa.png) |
| クラスタ構築時<br>既定のうごき | オンプレミス/他クラウド等で構築した場合はこちらが既定 | Azure 上で構成した場合にはこちらが既定 |
| LB要否を指定したい場合 <br> New-Cluster の オプション  | New-Cluster -ManagementPointNetworkType `Singleton`  | New-Cluster -ManagementPointNetworkType `Distributed`  |


従来、仮想ネットワーク名(VNN)と仮想 IP アクセスポイントを設定していました。
しかし、Azure 環境では仮想 IP を利用することはできないという制約があり、Azure 内部ロードバランサー を別途構成する形で、WSFC を実現をする必要がありました。

例えば、 wsfc というクラスター名を作成し IP 10.0.0.100 を設定したい場合、別途 10.0.0.100 の フロントIPアドレスを持たせた ロードバランサーを構成し、そのバックエンドにクラスターノードを配置する構成です。
クライアントからの wsfc 宛の通信は、10.0.0.100 にいったん名前解決されてロードバランサーへ到達し、ロードバランサーはバックエンドであるクラスターノードに対して通信を届ける形です。

しかし、Windows Server 2019 以降であれば、クラスターの作成中に、サーバーは自分自身が Azure 上 で稼働しているかどうかを判断し、自動的に 分散ネットワーク名 (DNN) リソースを使用する構成でクラスターが作成される動作となっています。
こちらは、ロード バランサーを使用しない構成となります。
分散ネットワーク名の場合、クライアントからの wsfc 宛の通信は、直接、クラスターノードのIPアドレスに名前解決され、直接クラスターノードに対して通信されます。

なお、Azure 上 で稼働しているかどうかは以下のように確認できます。

```Powershell : クラスターがAzure上にあるかを判定する方法
Get-Cluster | fl DetectedCloudPlatform

# 実行結果
# DetectedCloudPlatform            : Azure
```

ちなみに、Windows Server 2019 以降では、Azure 上にクラスターを構成しようとしていることが感知されると、DNN 以外にも有効になる機能があります。

　- クラスターノード間 の ハートビート (ネットワーク通信閾値）が自動調整される
　- クラスターノードが Azureホストのメンテナンスを検知した際のイベントが追加され、ログ記録やその他アクションを設定することができる

詳細は [こちらのブログ（英語）](https://techcommunity.microsoft.com/t5/failover-clustering/failover-clustering-in-azure/ba-p/2554341 ) に記載されています。

また、Azure 上でも、これまでのオンプレミス同様構成をしたい場合には、表でも整理した通り、New-Cluster コマンドのオプション　-ManagementPointNetworkType `Singleton　を指定して構築する形です。
詳しくは　[サポートチームのブログ](https://jpwinsup.github.io/blog/2023/11/06/FailoverClustering/ConfigurationAndManagement/ClusterOnAzure/ ) で手順が案内がされています。




# 早速、分散ネットワーク(DNN) で構築してみる

今回構成する環境はこんな感じです。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1461633/0b44f4fb-e073-97c0-cbba-52175c85512b.png)

クラスターの作成自体は DNN で作成できますので、ロードバランサーは不要です。

加えて、クラスター化された役割として スケールアウトファイルサーバー を持たせます。
スケールアウトファイルサーバー は DNN 同様、DNS ラウンドロビンを利用した負荷分散が可能なファイルサーバーであるため、こちらもロードバランサーなしで構成できます。



では早速作っていきます。
なお、仮想ネットワーク と Active Directory の作成は既に済んでいる前提です。


## 1.仮想マシンを作る

仮想マシンは 2台 用意します。
作成が完了した後は、DNS が AD サーバー宛になるようにしておきます。

<details><summary> Azure Portal から 仮想マシン を作成する</summary>

まずは仮想マシンを用意していきます。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1461633/e7b338e1-200a-2b5e-f7ee-06bedaf9c8bf.png)

共有ディスクをここで作成しても良いのですが、今回はまだ設定していません。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1461633/ea7c44e4-1d3a-c824-d003-fcda7ccc1755.png)

このまま次々とデフォルトのまま進み、作成を完了させます。
仮想マシンは 2台 用意しますので、もう一度繰り返します。

作成が完了した後は、DNS を AD サーバー宛にしておきます。
仮想マシンの [設定] - [ネットワーク] を開き、ネットワークインターフェース のリンク から、仮想マシンに紐づいた NIC を開きます。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1461633/0f7db693-5fdc-e903-62bb-99d5985659b7.png)

DNS サーバー の設定を変更し、ADサーバー のプライベートIPアドレスを入力します。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1461633/818beff5-23bb-4973-c1fd-c65b09c5377b.png)

仮想マシン が起動済みの場合には、いったん再起動させ、設定した DNSサーバー へ名前解決するようにしておきます。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1461633/2fba1317-11c8-c69a-cee2-ee2748a570c6.png)


</details>

## 2.マネージドディスクを作成してアタッチする

つづけて、マネージドディスク を 共有ディスク として作成していきます。
作成時に、[共有ディスクを有効にする] にチェックをいれて作成するだけです。


<details><summary> Azure Portal から 共有ディスク を作成してアタッチする</summary>

Azure Portal から [ディスク] と検索し、新規作成に進みます。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1461633/f8bd0081-fd50-f5e2-ea47-31a7e159a666.png)

選んだマネージドディスク SKU により、何台の仮想マシンで共有できるかの最大数が変動します。
以下公開ドキュメントも参考にして、調整します。

https://learn.microsoft.com/ja-jp/azure/virtual-machines/disks-shared#disk-sizes

今回は一旦、既定値のまま進めてみます。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1461633/13c3358b-bf39-94a0-a67d-048b9cc62f58.png)

既定では OFF になっていますが、 [共有ディスクを有効にする] にチェックをいれることで共有ディスクになります。
最大共有数もここで選択します。　他は既定値のまま、作成を完了させます。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1461633/f06fa099-aec4-5d1a-28e8-a6b3b43c4df2.png)

共有ディスクの作成が完了したら、仮想マシンのディスクとして追加しておきます。
作成した 仮想マシン 2台 とも、追加しておく必要があります。

作成した仮想マシンを開き、[設定] - [ディスク] - [既存のディスクをアタッチ] と進むと、作成した共有ディスクがプルダウンの選択肢に現れるはずです。
共有ディスクを選択して、設定を保存します。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1461633/172d6994-5f99-5528-ca5b-5af7316311b6.png)

</details>


## 3.ストレージアカウントを作成して、アクセスキーを確認する

WSFC の クォーラム となる ストレージアカウント も作成しておきます。
作成が完了したら、[セキュリティとネットワーク] - [アクセスキー] の箇所から、ストレージアカウント名 と キー が確認できます。
後ほど WSFC のクォーラムとして構成する際に、こちらの ストレージアカウント名 と キー を利用します。

<details><summary> ストレージアカウントの作成と、ストレージアカウント名 と キー の確認</summary>

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1461633/05a5f29b-ecdc-4648-0df1-7ed482c8d517.png)

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1461633/449b12b2-0a35-eb94-6579-06bf554a3dc4.png)
</details>

## 4.仮想マシンをドメイン参加させる

クラスターノードとなる仮想マシン ２台 とも、Active Directory ドメインに参加させます。
作成した 仮想マシン にログインして GUI から操作を行ってもOKですし、Powershell で行う場合には下記で参加できると思います。
ドメイン名、管理者名、パスワードは、環境にあわせて変更する必要があります。

作成した 仮想マシン 2台 とも、ドメイン参加をさせる必要があります。

```PowerShell
# 手順1 ドメイン参加する
# ドメイン名、ユーザー名、パスワードを指定
$domainName = "contoso.local"
$userName = "domainadmin"
$password = ConvertTo-SecureString "password" -AsPlainText -Force
 
# クレデンシャルオブジェクトを作成
$credential = New-Object System.Management.Automation.PSCredential($userName, $password)
 
# ドメイン参加を実行
Add-Computer -DomainName $domainName -Credential $credential -Verbose
 
# コンピュータを再起動（ドメイン参加後に必要）
Restart-Computer
```

:::note info
ドメイン参加の操作は、Azure Portal 上から、実行コマンドで行うこともできます。
この場合には、ユーザー名の最後にドメイン名を指定する必要があります。
ご注意ください。
:::

<details><summary> Azure Portal 上での実行例</summary>

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1461633/b7977beb-4cd7-3bd6-62a4-e78f59c7d198.png)

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1461633/d406eb0d-ecd4-2b68-9ed4-205fbaaa1de2.png)
</details>


## 5.クラスターを構成する
クラスターを構成していきます。
ここからの手順は、仮想マシンどちらか１台で OK です。

以下 Powershell スクリプトを変数など調整して流せば、構成できると思います。
指定した仮想マシンに、フェールオーバー クラスタ リング機能 と スケールアウトファイルサーバー機能をインストールし、クラスター作成、クオーラムの設定、共有ディスクのフォーマットとファイル共有の作成を行うスクリプトです。
[こちらの公開ドキュメント](https://learn.microsoft.com/ja-jp/windows-server/remote/remote-desktop-services/rds-storage-spaces-direct-deployment ) を参考に作成しました。

:::note info
途中、手順6-7 で、共有ディスクをフォーマットをする箇所があります。
ディスク番号を指定してフォーマットしていますので、誤ったディスク番号を指定しないように注意です。
:::

```Powershell
### 各種パラメーターの調整
# クラスターノード名を指定する。 クラスター名を指定する。 SoFS ロール名を指定する。
$nodes = ("wsfc01", "wsfc02")
$clustername = "wsfc"
$sofsrole = "sofsrole"

# ストレージアカウントのアカウント名とアクセスキーを指定する
$parameters = @{
    CloudWitness = $true
    AccountName  = 'アカウント名'
    AccessKey    = 'アクセスキー'
}

# ディスク番号は手順 6 で確認した番号を指定する。ドライブレターは任意の文字、ディスクラベルは任意の名前を指定する。
$DiskNumber = 2
$DriveLetter = "S"
$DiskLabel = "FileShereDisk"

### 各種パラメーターの調整 - 終わり

### SoFS 構築用スクリプト。手順6-7 のディスクフォーマットを行う箇所注意。
# 手順 2: WSFC Role をインストール
icm $nodes {Install-WindowsFeature Failover-Clustering -IncludeAllSubFeature -IncludeManagementTools}
icm $nodes {Install-WindowsFeature FS-FileServer}

# 手順 3: クラスター構成を検証する
Test-Cluster -Node $nodes

# 手順 4: クラスターを作成する
New-Cluster -Name $clustername -Node $nodes

# 手順 5: クラスターのクオーラムを構成する（クラウド監視）
Set-ClusterQuorum @parameters

# 手順 6: ディスク一覧のうち、ファイルシステム未作成のディスクのみ、テーブル形式で表示する。ディスク番号を確認する。
get-disk | where partitionstyle -eq "RAW" | format-table -AutoSize

# 手順 7: クラスターの共有ボリュームを追加する。
# ディスク番号は手順 6 で確認した番号を指定する。ドライブレターは任意の文字、ディスクラベルは任意の名前を指定する。
# ファイルシステム未作成のディスクを初期化し、GPT パーティションを作成し、ドライブレターを割り当て、ReFS ファイルシステムを作成する。
Get-Disk -Number $DiskNumber | Where-Object PartitionStyle -Eq "RAW" | Initialize-Disk -PartitionStyle GPT -PassThru |  New-Partition -DriveLetter $DriveLetter -UseMaximumSize | Format-Volume  -FileSystem ReFS -NewFileSystemLabel $DiskLabel -Force -Verbose

# 手順 8: クラスター全ノードで利用可能なディスクをクラスターディスクとして追加する。その後、共有ボリュームを追加する。
Get-ClusterAvailableDisk -All | Add-ClusterDisk
Add-ClusterSharedVolume -Name "Cluster Disk 1"

# 手順 9: SoFS ロールを追加する。新しい共有フォルダを作成する。
Add-ClusterScaleOutFileServerRole -Name $sofsrole -Cluster $clustername
New-Item -Path C:\ClusterStorage\Volume1\Share001 -ItemType Directory
New-SmbShare -Name Share001 -Path C:\ClusterStorage\Volume1\Share001
```


各手順ごとに実行した例や、ポイントなど記載しておきます。


<details><summary> 手順 2: WSFC Role をインストール - 実行例</summary>

まずは 仮想マシン2台共に、フェールオーバー クラスタ リング機能をインストールします。
また、スケールアウトファイルサーバー(SoFS)機能のため、ファイル サーバーの機能もインストールします。
今回 wsfc01 、wsfc02 という仮想マシンで構成していますが、必要に応じて $node の箇所を変更してください。

```PowerShell
# 手順 2: WSFC Role をインストール
$nodes = ("wsfc01", "wsfc02")
icm $nodes {Install-WindowsFeature Failover-Clustering -IncludeAllSubFeature -IncludeManagementTools}
icm $nodes {Install-WindowsFeature FS-FileServer}
```

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1461633/c7c6e509-83cd-7b1b-be66-9173104804c5.png)
</details>

<details><summary> 手順 3: クラスター構成を検証する,手順 4: クラスターを作成する - 実行例</summary>

クラスター構成の検証と、クラスターの作成を行います。
クラスターの名前などは適宜変更してください。

```PowerShell
# 手順 3: クラスター構成を検証する
Test-Cluster -Node $nodes

# 手順 4: クラスターを作成する
New-Cluster -Name "wsfc" -Node $nodes
```

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1461633/9805268d-0105-b422-95b4-bb3b172352a2.png)

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1461633/f60f8328-5b09-3373-0b36-7350a76042f9.png)


</details>

<details><summary> 手順 5: クラスターのクオーラムを構成する（クラウド監視）- 実行例</summary>

作成したクラスターのクォーラムを設定します。
クォーラムは、スプリット ブレイン（デュアルマスター）を防ぐための仕組みです。
今回はストレージアカウントを利用したでクラウド監視のパターンで構成しますが、その他のパターン等は [こちら](https://learn.microsoft.com/ja-jp/windows-server/failover-clustering/manage-cluster-quorum#witness-configuration )に紹介があります。

先ほど確認した ストレージアカウント の アカウント名 と アクセスキー を使用します

```PowerShell
# 手順 5: クラスターのクオーラムを構成する（クラウド監視）
$parameters = @{
    CloudWitness = $true
    AccountName  = 'アカウント名'
    AccessKey    = 'アクセスキー'
}
Set-ClusterQuorum @parameters
```

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1461633/52b5d4f4-b36a-8a72-5246-0ed46baab068.png)
</details>

<details><summary> 手順 6: ディスク一覧確認、手順 7: フォーマットとクラスターの共有ボリューム追加 - 実行例</summary>

追加した共有ディスクをフォーマットします。
まずは手順6 で、対象ディスクの番号を確認しておきます。
確認したディスク番号で、手順7 のスクリプトを修正します。
今回の例では、ディスク番号が2 ( $DiskNumber = 2 ) を指定して、フォーマットを行っています。
なお ディスク番号以外にも、必要に応じて、ドライブレター や ディスクラベル を変更します。

```PowerShell
# 手順 6: ディスク一覧のうち、ファイルシステム未作成のディスクのみ、テーブル形式で表示する。ディスク番号を確認する。
get-disk | where partitionstyle -eq "RAW" | format-table -AutoSize

# 手順 7: クラスターの共有ボリュームを追加する。
# ディスク番号は手順 6 で確認した番号を指定する。ドライブレターは任意の文字、ディスクラベルは任意の名前を指定する。
# ファイルシステム未作成のディスクを初期化し、GPT パーティションを作成し、ドライブレターを割り当て、ReFS ファイルシステムを作成する。
$DiskNumber = 2
$DriveLetter = "S"
$DiskLabel = "FileShereDisk"
Get-Disk -Number $DiskNumber | Where-Object PartitionStyle -Eq "RAW" | Initialize-Disk -PartitionStyle GPT -PassThru |  New-Partition -DriveLetter $DriveLetter -UseMaximumSize | Format-Volume  -FileSystem ReFS -NewFileSystemLabel $DiskLabel -Force -Verbose
```


手順6 確認結果：　ディスク番号 2
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1461633/fd572c7c-6497-49e4-a9be-438ed6e25911.png)

手順7 フォーマット
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1461633/09f8e25d-893b-5363-b53c-41f36a942ba6.png)
</details>

<details><summary> 手順 8: クラスターディスク追加と共有ボリューム作成。手順 9: SoFS ロールを追加と共有フォルダ作成 - 実行例</summary>

フォーマットしたディスクをクラスターディスクとして追加し、共有ボリュームにします。
その後、SoFS のロールを作成し、共有フォルダを作成します。
今回だと SoFS のロールを "sofsrole" という名前で作成しています。
また、作成する共有フォルダは "Share001" です。
\\ "SoFS のロール名" \ "共有名" \ でアクセスできますので、\\sofsrole\share001\ でアクセスできます。

```PowerShell
# 手順 8: クラスター全ノードで利用可能なディスクをクラスターディスクとして追加する。その後、共有ボリュームを追加する。
Get-ClusterAvailableDisk -All | Add-ClusterDisk
Add-ClusterSharedVolume -Name "Cluster Disk 1"

# 手順 9: SoFS ロールを追加する。新しい共有フォルダを作成する。
Add-ClusterScaleOutFileServerRole -Name sofsrole -Cluster "wsfc"
New-Item -Path C:\ClusterStorage\Volume1\Share001 -ItemType Directory
New-SmbShare -Name Share001 -Path C:\ClusterStorage\Volume1\Share001
```


手順8 実行結果
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1461633/ae2e4db4-8a42-1f54-f532-7012ead49730.png)

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1461633/e417de5a-5833-abc9-3b82-d34cd71ca77b.png)


手順9 実行結果
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1461633/1f4a3771-4f8d-7004-216b-0f665a9b634f.png)

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1461633/035135d5-a577-7442-5359-7542c91ef581.png)
これで構成が完了しました。

</details>


## 6.動作確認

手順4 の クラスターの構築が、エラー無く完了しました。
手順5以降、クラスターに対しての操作も、特に問題なく成功しています。

また、スケールアウトファイルサーバーとしても、別の仮想マシンから確認してみると、 \\sofsrole\share001\ でアクセスできています。
必要に応じて NTFSアクセス権などは調整する必要がありますが、こちらも問題ないようです。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1461633/8de8eb9c-4ac2-8f24-70ed-c382f19dec49.png)

なお、登録した クラスター名(wsfc) や SoFSロール名(sofs) は、たしかに DNSラウンドロビン で、クラスターノード(wsfc01 と wsfc02)のIPを返す形であることも確認できました。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1461633/3ba3de5b-34d6-a826-afd3-025ac7c603fa.png)


# Tips1  :ファイルサーバー と スケールアウトファイルサーバー(SoFS) の使いわけ

今回作成した WSFC に持たせた役割は、スケールアウトファイルサーバーでしたが、通常のファイルサーバーの役割を追加する場合もあります。

以下公開ドキュメントに、比較表があります。

https://learn.microsoft.com/ja-jp/windows-server/failover-clustering/sofs-overview#when-to-use-scale-out-file-server
> ファイルを開く、ファイルを閉じる、新しいファイルを作成する、既存のファイル名を変更するなどのメタデータ操作がワークロードにより大量に生成される場合には、スケールアウト ファイル サーバーを使用しないでください。 

例えば、ユーザープロファイルを配置するファイルサーバーとして利用する場合を考えてみると、ユーザープロファイルを移動ユーザープロファイルで実現する場合には、メタデータの操作が多くなりますので、この場合には、通常のファイルサーバーの構成の方が推奨となります。一方、FSLogix や UPD のように VHD をマウントする方式で、メタデータ操作頻度がすくない場合においては、スケールアウトファイルサーバーの方が適している形になります。


# Tips2  :　汎用ファイルサーバー の場合の例

汎用ファイルサーバーの場合には、アクティブ/スタンバイ での構成となります。
共有ディスクはどちらのクラスターノードが占有し、DNSによる負荷分散も行わない形になります。
ロードバランサーを配置して構成してみます。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1461633/c6f5e6a1-b89d-6a8f-72f3-a8bf5df06320.png)


<details><summary> 実行例</summary>

ファイルサーバーの役割を追加。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1461633/fc201575-6519-9b3b-5f4e-e385cb7db726.png)

クラスターノードの自身のIPアドレスがいったん設定されるが、使用済みの為、起動できない。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1461633/2d72c4d8-65d8-2192-4219-e8034c45d8a2.png)

静的IPアドレスとして、ロードバランサーのフロントエンドIPアドレスを指定して起動する。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1461633/a0cf70e1-5133-6d91-7c29-839244f3a7ba.png)

構成できました。

</details>

# 参考
https://jpwinsup.github.io/blog/2023/11/06/FailoverClustering/ConfigurationAndManagement/ClusterOnAzure/

https://techcommunity.microsoft.com/t5/failover-clustering/failover-clustering-in-azure/ba-p/2554341

https://learn.microsoft.com/ja-jp/windows-server/remote/remote-desktop-services/rds-storage-spaces-direct-deployment

https://learn.microsoft.com/ja-jp/windows-server/failover-clustering/sofs-overview#when-to-use-scale-out-file-server