クラスターセットのデプロイ

[アーティクル]
10/06/2023
適用対象:

✅ Windows Server 2025, ✅ Windows Server 2022, ✅ Windows Server 2019, ✅ Windows Server 2016, ✅ Azure Stack HCI, versions 23H2 and 22H2

適用対象:Windows Server 2019

この記事では、PowerShell を使って、Windows Server フェールオーバークラスターのクラスターセットを展開する方法について説明します。クラスターセットとは、一緒にクラスター化されている複数のフェールオーバークラスターから成るグループのことです。クラスターセットを使用することにより、単一の Software Defined Data Center (SDDC) クラウド内のサーバーノード数を桁違いに増やすことができます。

クラスターセットは、最大で合計 64 クラスターノードまでテストされ、サポートされています。ただし、クラスターセットははるかに大きい制限までスケーリングでき、制限はハードコーディングされていません。

メリット

クラスターセットには、次の利点があります。

複数の小規模なクラスターを 1 つの大きなファブリックに結合することにより、ソフトウェアの障害の境界を単一のクラスターに維持しながら、高可用性仮想マシン (VM) を実行するためにサポートされる SDDC クラウドスケールを大幅に増やすことができます。クラスターセット全体で VM を簡単に移行できます。
回復性の向上。 1 つのクラスターセットに 4 ノードのクラスターを 4 つ含める方が、16 ノードのクラスターを 1 つ使用するより優れた回復性を得られます。これは、複数の計算ノードがダウンしても、稼働はそのまま維持されるためです。
テナント VM の可用性に影響を与えずに、フェールオーバークラスターのライフサイクルの管理を行えます (クラスターのオンボードと削除を含む)。
個々のクラスター間での VM の柔軟性と、統合ストレージ名前空間。
ハイパーコンバージド環境でコンピューティングとストレージのワークロード比率を簡単に変更できます。
初期 VM の配置とその後の移行で、個々のクラスターをまたいで Azure 風の障害ドメインと可用性セットのメリットが得られます。
クラスターノードの間でコンピューティングとストレージのハードウェアが一致しない場合でも使用できます。
クラスター間での VM のライブマイグレーション。
複数のクラスターにまたがる Azure 風の可用性セットと障害ドメイン。
クラスター間での SQL Server VM の移動。

要件と制限事項

クラスターセットの使用には、次に挙げるいくつかの要件と制限事項があります。

クラスターセット内のすべてのメンバークラスターは、同じ Active Directory (AD) フォレストに存在する必要があります。
セット内のメンバーサーバーは、同じバージョンのオペレーティングシステムを実行する必要があります。異なるオペレーティングシステムの間で仮想マシンのライブマイグレーションを行うことはできません。次のオプションのいずれかで構成されるクラスターセットを使用できますが、複数選択することはできません。
- Windows Server 2019 フェールオーバークラスターと Windows Server 2019 フェールオーバークラスター
- Windows Server 2019 フェールオーバークラスターと Windows Server 2019 記憶域スペースダイレクト
- Windows Server 2019 記憶域スペースダイレクトと Windows Server 2019 記憶域スペースダイレクト
メンバークラスター間でライブマイグレーションを実行するには、すべてのメンバーサーバーで同一のプロセッサハードウェアが必要です。そうでない場合は、仮想マシンの設定で CPU プロセッサの互換性を選択する必要があります。
クラスターセット VM のクラスター間のライブマイグレーションは、手動で行う必要があります。これらを自動フェールオーバーすることはできません。
クラスター障害に対するストレージの回復性を実現するため、メンバークラスター間で記憶域レプリカを使用する必要があります。記憶域レプリカを使う場合、名前空間のストレージ UNC パスは、レプリカターゲットクラスターへの記憶域レプリカフェールオーバー時に自動的に変更されないことに注意してください。
記憶域スペースダイレクトは、クラスターセット内のメンバークラスター間では機能しません。記憶域スペースダイレクトは、単一のクラスターに適用され、各クラスターに独自の記憶域プールが存在します。

アーキテクチャ

次の図にクラスターセットの概要を示します。

以下に、表示されている各要素の概要を説明します。

管理クラスター

管理クラスターでは、高可用性管理プレーンと、クラスターセットの名前空間参照スケールアウトファイルサーバー (SOFS) がホストされます。管理クラスターは、VM ワークロードが実行される個々のメンバークラスターから論理的に切り離されています。これにより、クラスターセット管理プレーンは、メンバークラスターの停電など、局所的なクラスター全体の障害に対して回復性を持つことができます。

クラスターセットの名前空間参照 SOFS

クラスターセットの名前空間は、管理クラスターで実行される SOFS サーバーロールを使用して提供されます。これは、分散ファイルシステム名前空間 (DFSN) に似ています。ただし、DFSN とは異なり、クラスターセットの名前空間参照メタデータは、すべてのクラスターノードで自動設定され、介入は一切必要ありません。そのため、ストレージアクセスパスでのパフォーマンスのオーバーヘッドはほとんどありません。この軽量の参照メカニズムは、I/O パスには関与しません。

クラスターセットの名前空間参照 SOFS の各サーバーメッセージブロック (SMB) 参照共有は、SimpleReferral という種類です。この参照により、SMB クライアントは、メンバークラスター SOFS でホストされているターゲット SMB 共有にアクセスできます。参照は各クライアントノードに永続的にキャッシュされ、そのクラスターセットの名前空間は、必要に応じてその参照を動的に自動更新します。参照情報は、各クラスターセットノードに永続的に (再起動をまたいでも) キャッシュされます。

クラスターセットマスター

メンバークラスター間の通信は、クラスターセットマスター (CS-Master) リソースによって疎結合されて、調整されます。他のクラスターセットリソースと同様、CS-Master は個々のメンバークラスターの障害や管理クラスターノードの障害に対して高可用性と回復性があります。 CS-Master によって、クラスターセット WMI プロバイダーを介して、すべてのクラスターセット管理アクションの管理エンドポイントが提供されます。

メンバークラスター

メンバークラスターでは、VM と記憶域スペースダイレクトのワークロードが実行されます。複数のメンバークラスターが 1 つのクラスターセットのデプロイに参加し、より大規模な SDDC クラウドファブリックを形成します。メンバークラスターは、次の 2 つの主要な側面で管理クラスターとは異なります。メンバークラスターは障害ドメインと可用性セットの構成に参加します。メンバークラスターのサイズは、VM と記憶域スペースダイレクトのワークロードをホストするように設定されます。このため、メンバークラスター間を移動する VM は、管理クラスターでホストされません。

クラスターセットワーカー

CS-Master は、クラスターセットワーカー (CS-Worker) と呼ばれるメンバークラスター上のクラスターリソースと対話します。 CS-Worker は、VM の配置やリソースのインベントリ作成など、CS-Master による要求に応答します。メンバークラスターごとに 1 つの CS-Worker インスタンスがあります。

障害ドメイン

障害ドメインは、一緒に障害が発生するおそれがあるハードウェアとソフトウェアのグループです。 1 つ以上のクラスターを障害ドメインとしてまとめて指定することもできますが、各ノードは可用性セット内の障害ドメインに参加できます。障害ドメインの境界は、データセンタートポロジ、ネットワークアーキテクチャ、その他の考慮事項に基づいています。

可用性セット

可用性セットは、ワークロードをグループ化してデプロイすることにより、障害ドメインをまたいでクラスター化されたワークロードの必要な冗長性を構成するために使用されます。 2 層アプリケーションの場合は、各層の可用性セットに少なくとも 2 つの VM を構成する必要があります。これにより、1 つの可用性セット内の 1 つの障害ドメインがダウンした場合でも、アプリケーションには各層に少なくとも 1 つの VM が別の障害ドメインでホストされている状態を確保できます。

クラスターセットを作成する

次のサンプルワークフロー内で PowerShell を使用して、2 つのクラスターを使用したクラスターセットを作成します。このクラスターセットの名前は CSMASTER です。

クラスター名	インフラストラクチャの SOFS 名
SET-CLUSTER	SOFS-CLUSTERSET
CLUSTER1	SOFS-CLUSTER1
CLUSTER2	SOFS-CLUSTER2

Windows Server 2022 または Windows Server 2019 を実行している管理クライアントコンピューターを使います。
管理クラスターサーバーにフェールオーバークラスターツールをインストールします。
2 つのクラスターメンバーを作成し、各クラスターに少なくとも 2 つのクラスターの共有ボリューム (CSV) があるようにします。
メンバークラスターをまたぐ管理クラスター (物理またはゲスト) を作成します。これにより、メンバークラスターの障害が発生しても、そのクラスターセット管理プレーンは引き続き使用できるようになります。
クラスターセットを作成するには、次のようにします。
```
New-ClusterSet -Name CSMASTER -NamespaceRoot SOFS-CLUSTERSET -CimSession SET-CLUSTER
```
注意

静的 IP アドレスを使用している場合は、New-ClusterSet コマンドに -StaticAddress x.x.x.x を含める必要があります。

そのクラスターセットにクラスターメンバーを追加するには、次のようにします。

Add-ClusterSetMember -ClusterName CLUSTER1 -CimSession CSMASTER -InfraSOFSName SOFS-CLUSTER1
Add-ClusterSetMember -ClusterName CLUSTER2 -CimSession CSMASTER -InfraSOFSName SOFS-CLUSTER2

そのクラスターセット内のすべてのメンバークラスターを列挙するには、次のようにします。
```
Get-ClusterSetMember -CimSession CSMASTER
```
クラスターセット内のすべてのメンバークラスターを、管理クラスターノードも含めて列挙するには、次のようにします。
```
Get-ClusterSet -CimSession CSMASTER | Get-Cluster | Get-ClusterNode
```
すべてのメンバークラスターのすべてのサーバーノードを一覧表示するには、次のようにします。
```
Get-ClusterSetNode -CimSession CSMASTER
```
そのクラスターセット全体のすべてのリソースグループを一覧表示するには、次のようにします。
```
Get-ClusterSet -CimSession CSMASTER | Get-Cluster | Get-ClusterGroup
```
そのクラスターセットに、クラスターメンバー CSV ボリュームごとにインフラストラクチャ SOFS 上に 1 つの SMB 共有 (ScopeName はそのインフラストラクチャファイルサーバーの名前) が含まれていることを確認するには、次のようにします。
```
Get-SmbShare -CimSession CSMASTER
```
クラスターセット、管理クラスター、各クラスターメンバーのクラスターセットデバッグログファイルを確認します。
```
Get-ClusterSetLog -ClusterSetCimSession CSMASTER -IncludeClusterLog -IncludeManagementClusterLog -DestinationFolderPath <path>
```
すべてのクラスターセットメンバー間に、制約付き委任を使用して Kerberos を構成します。
クラスターセット内の各ノードで、クラスター間 VM ライブマイグレーション認証の種類を Kerberos に構成します。
```
foreach($h in $hosts){ Set-VMHost -VirtualMachineMigrationAuthenticationType Kerberos -ComputerName $h }
```
その管理クラスターを、クラスターセット内の各クラスターメンバーサーバーノードのローカル管理者グループに追加します。
```
foreach($h in $hosts){ Invoke-Command -ComputerName $h -ScriptBlock {Net localgroup administrators /add <management_cluster_name>$} }
```

クラスターセット VM を作成する

クラスターセットを作成したら、次の手順として VM を作成します。その前に、次の確認事項を実行する必要があります。

各クラスターサーバーノードで使用可能なメモリを確認する
各クラスターサーバーノードで使用可能なディスク領域を確認する
速度とパフォーマンスの観点で特定の VM ストレージ要件すべてを確認する

Get-ClusterSetOptimalNodeForVM コマンドは、クラスターセット内の最適なクラスターとノードを識別し、その上に VM をデプロイします。次の例では、新しい VM は次のように作成されています。

4 GB 利用可能
1 つの仮想プロセッサ
10% の最小 CPU 使用率

# Identify the optimal node to create a new virtual machine
$memoryinMB=4096
$vpcount = 1
$targetnode = Get-ClusterSetOptimalNodeForVM -CimSession CSMASTER -VMMemory $memoryinMB -VMVirtualCoreCount $vpcount -VMCpuReservation 10
$secure_string_pwd = convertto-securestring "<password>" -asplaintext -force
$cred = new-object -typename System.Management.Automation.PSCredential ("<domain\account>",$secure_string_pwd)

# Deploy the virtual machine on the optimal node
Invoke-Command -ComputerName $targetnode.name -scriptblock { param([String]$storagepath); New-VM CSVM1 -MemoryStartupBytes 3072MB -path $storagepath -NewVHDPath CSVM.vhdx -NewVHDSizeBytes 4194304 } -ArgumentList @("\\SOFS-CLUSTER1\VOLUME1") -Credential $cred | Out-Null

Start-VM CSVM1 -ComputerName $targetnode.name | Out-Null
Get-VM CSVM1 -ComputerName $targetnode.name | fl State, ComputerName

完了すると、どのクラスターノードに VM がデプロイされたかが表示されます。上記の例では、次のように表示されます。

State         : Running
ComputerName  : 1-S2D2

使用できるメモリ、CPU 容量、またはディスク領域が、VM を追加するのに十分ではない場合は、次のエラーが表示されます。

Get-ClusterSetOptimalNodeForVM : A cluster node isn't available for this operation.

VM が作成されると、指定された特定のノードの Hyper-V マネージャーにその VM が表示されます。これをクラスターセット VM として追加し、クラスターに追加するには、次のコマンドを使用します。

Register-ClusterSetVM -CimSession CSMASTER -MemberName $targetnode.Member -VMName CSVM1

完了すると、出力は次のようになります。

Id  VMName  State  MemberName  PSComputerName
--  ------  -----  ----------  --------------
 1  CSVM1     On   CLUSTER1    CSMASTER

既存の VM を使用してクラスターを作成した場合は、その VM をクラスターセットに登録する必要があります。すべての VM を一度に登録するには、以下を使用します。

Get-ClusterSetMember -Name CLUSTER3 -CimSession CSMASTER | Register-ClusterSetVM -RegisterAll -CimSession CSMASTER

次に、VM パスをクラスターセットの名前空間に追加します。

例として、ローカルクラスターの共有ボリューム (CSV) に存在する事前構成済みの VM を持つ既存のクラスターが、クラスターセットに追加されているとします。 VHDX のパスは、C:\ClusterStorage\Volume1\MYVM\Virtual Hard Disks\MYVM.vhdx1 のようになります。

CSV パスは意図的に単一のメンバークラスターに対してローカルにされており、メンバークラスター間でライブマイグレーションを実行すると VM にアクセスできなくなるため、ストレージを移行する必要があります。

この例では、Add-ClusterSetMember を使用してスケールアウトファイルサーバー SOFS-CLUSTER3 を指定して、CLUSTER3 がクラスターセットに追加されています。 VM 構成とストレージを移動するため、次のコマンドを実行します。

Move-VMStorage -DestinationStoragePath \\SOFS-CLUSTER3\Volume1 -Name MyVM

完了すると、次の警告が表示される場合があります。

WARNING: There were issues updating the virtual machine configuration that may prevent the virtual machine from running. For more information view the report file below.
WARNING: Report file location: C:\Windows\Cluster\Reports\Update-ClusterVirtualMachineConfiguration '' on date at time.htm.

仮想マシンロールのストレージ構成に物理的な変更は加えられていないので、この警告は無視してもかまいません。実際の物理的な場所は変わらず、構成パスのみが変わります。

Move-VMStorage の詳細については、「Move-VMStorage」を参照してください。

クラスターセット内の VM のライブマイグレーションには、次が含まれます。

Set-VMHost -UseAnyNetworkForMigration $true

次に、一例として、クラスターセット VM を CLUSTER1 から CLUSTER3 の NODE2-CL3 に移動するとしたら、コマンドは次のようになるはずです。

Move-ClusterSetVM -CimSession CSMASTER -VMName CSVM1 -Node NODE2-CL3

このコマンドで VM ストレージや構成ファイルは移動しません。VM へのパスは \\SOFS-CLUSTER1\VOLUME1 のままのため、必要ありません。 VM がインフラストラクチャファイルサーバー共有パスに登録されれば、ドライブと VM が VM と同じノードに存在する必要はなくなります。

インフラストラクチャスケールアウトファイルサーバーを作成する

1 つのクラスターには、インフラストラクチャ SOFS クラスターロールが 1 つあります。インフラストラクチャ SOFS ロールは、-Infrastructure スイッチパラメーターを Add-ClusterScaleOutFileServerRole コマンドレットに指定することによって作成されます。例:

Add-ClusterScaleoutFileServerRole -Name "my_infra_sofs_name" -Infrastructure

自動的に CSV ボリュームが作成されるたびに、SMB 共有の作成がトリガーされます。これには、CSV ボリューム名に基づく自動生成名が付きます。 CSV ボリュームの作成と変更操作を使う以外に、SOFS ロールの下で SMB 共有を直接作成または変更することはできません。

ハイパーコンバージド構成では、インフラストラクチャ SOFS により、SMB クライアント (Hyper-V ホスト) が継続的可用性 (CA) でインフラストラクチャ SOFS SMB サーバーと通信することが許可されます。このハイパーコンバージド SMB ループバック CA は、VM がその仮想ディスク (VHDX) ファイルにアクセスすることによって実現します。その際、所有 VM ID はクライアントとサーバーの間で転送されます。この ID 転送により、以前の標準ハイパーコンバージドクラスター構成の場合と同様に、VHDx ファイルに対して ACL を使用できるようになります。

クラスターセットが作成されると、そのクラスターセットの名前空間は、各メンバークラスターに対するインフラストラクチャ SOFS に加え、管理クラスター内のインフラストラクチャ SOFS に依存します。

メンバークラスターがクラスターセットに追加された時点で、そのクラスターのインフラストラクチャ SOFS の名前を指定できます (既に存在している場合)。インフラストラクチャ SOFS が存在しない場合は、新しいインフラストラクチャ SOFS ロールが新しいメンバークラスターに作成されます。そのメンバークラスターに対するインフラストラクチャ SOFS ロールが既に存在する場合は、Add 操作で、必要に応じて指定した名前に暗黙的に名前が変更されます。既存の SMB サーバーも、そのメンバークラスターのインフラストラクチャ SOFS 以外のロールも、そのクラスターセットでは使用されません。

クラスターセットが作成されると、管理クラスターの名前空間ルートとして既存の AD コンピューターオブジェクトを使用できるようになります。クラスターセットの作成を実行すると、管理クラスターにインフラストラクチャ SOFS クラスターロールが作成されるか、既存のインフラストラクチャ SOFS ロールの名前が変更されます。管理クラスターのインフラストラクチャ SOFS は、クラスターセットの名前空間参照 SOFS として使用されます。

障害ドメインと可用性セットを作成する

Azure 風の障害ドメインと可用性セットをクラスターセットに構成できます。これは、最初の VM 配置とクラスター間の移行に役立ちます。

次の例では、1 つのクラスターセットに 4 つのクラスターがあります。そのセット内に、これらのクラスターのうちの 2 つを使用して 1 つの障害ドメインが作成され、残りの 2 つのクラスターを使用して 2 つ目の障害ドメインが作成されます。これらの 2 つの障害ドメインによって、可用性セットが構成されます。

次の例では、CLUSTER1 と CLUSTER2 が障害ドメイン FD1 に含まれており、CLUSTER3 と CLUSTER4 が障害ドメイン FD2 に含まれています。可用性セットは、CSMASTER-AS です。

障害ドメインを作成するためのコマンドは、次のようになります。

New-ClusterSetFaultDomain -Name FD1 -FdType Logical -CimSession CSMASTER -MemberCluster CLUSTER1,CLUSTER2 -Description "First fault domain"

New-ClusterSetFaultDomain -Name FD2 -FdType Logical -CimSession CSMASTER -MemberCluster CLUSTER3,CLUSTER4 -Description "Second fault domain"

正常に作成されたことを確認するには、Get-ClusterSetFaultDomain を実行します。FD1 の場合の出力は次のようになります。

PS C:\> Get-ClusterSetFaultDomain -CimSession CSMASTER -FdName FD1 | fl *

PSShowComputerName    : True
FaultDomainType       : Logical
ClusterName           : {CLUSTER1, CLUSTER2}
Description           : First fault domain
FDName                : FD1
Id                    : 1
PSComputerName        : CSMASTER

障害ドメインが作成されたら、次のようにして可用性セットを作成します。

New-ClusterSetAvailabilitySet -Name CSMASTER-AS -FdType Logical -CimSession CSMASTER -ParticipantName FD1,FD2

作成されたことを検証するには、次を使用します。

Get-ClusterSetAvailabilitySet -AvailabilitySetName CSMASTER-AS -CimSession CSMASTER

新しい VM を作成する場合は、-AvailabilitySet パラメーターを使用して、配置に最適なノードを決定します。次に例を示します。

# Identify the optimal node to create a new VM
$memoryinMB=4096
$vpcount = 1
$av = Get-ClusterSetAvailabilitySet -Name CSMASTER-AS -CimSession CSMASTER
$targetnode = Get-ClusterSetOptimalNodeForVM -CimSession CSMASTER -VMMemory $memoryinMB -VMVirtualCoreCount $vpcount -VMCpuReservation 10 -AvailabilitySet $av
$secure_string_pwd = convertto-securestring "<password>" -asplaintext -force
$cred = new-object -typename System.Management.Automation.PSCredential ("<domain\account>",$secure_string_pwd)

クラスターをセットから削除する

クラスターをクラスターセットから削除することが必要になる場合があります。ベストプラクティスとして、すべてのクラスターセット VM を、そのクラスターから事前に移動する必要があります。これは、Move-ClusterSetVM および Move-VMStorage コマンドを使用して実行できます。

最初に VM をクラスターから移動しないと、削除されるクラスターでホストされている残りのすべてのクラスターセット VM は、それらのストレージにアクセスできるのであれば、そのクラスターにバインドされた高可用性 VM になります。クラスターセットにより、そのインベントリの更新も自動的に行われます。これは、削除されるクラスターと、その上で稼働する VM の正常性の追跡をやめることと、削除されるクラスターでホストされていた名前空間と、すべての共有への参照を除去することによって行われます。

たとえば、クラスターセットから CLUSTER1 クラスターを削除するコマンドは次のとおりです。

Remove-ClusterSetMember -ClusterName CLUSTER1 -CimSession CSMASTER

システム状態のバックアップ

システム状態のバックアップでは、クラスターの状態とメタデータがバックアップされます。 Windows Server バックアップを使用すると、必要に応じてノードのクラスターデータベースだけを復元できます。または、Authoritative Restore を実行して、すべてのノードでクラスターデータベース全体をロールバックすることもできます。クラスターセットの場合、Authoritative Restore は、まずメンバークラスターに対して実行してから、管理クラスターに対して実行することをお勧めします。システム状態のバックアップの詳細については、「システム状態およびベアメタルのバックアップ」を参照してください。

次のステップ

記憶域レプリカの詳細を確認する。

次の方法で共有

クラスターセットのデプロイ

メリット

要件と制限事項

アーキテクチャ

管理クラスター

クラスターセットの名前空間参照 SOFS

クラスターセットマスター

メンバークラスター

クラスターセットワーカー

障害ドメイン

可用性セット

クラスターセットを作成する

クラスターセット VM を作成する

インフラストラクチャスケールアウトファイルサーバーを作成する

障害ドメインと可用性セットを作成する

クラスターをセットから削除する

システム状態のバックアップ

次のステップ

フィードバック

その他のリソース

次の方法で共有

クラスター セットのデプロイ

メリット

要件と制限事項

アーキテクチャ

管理クラスター

クラスター セットの名前空間参照 SOFS

クラスター セット マスター

メンバー クラスター

クラスター セット ワーカー

障害ドメイン

可用性セット

クラスター セットを作成する

クラスター セット VM を作成する

インフラストラクチャ スケールアウト ファイル サーバーを作成する

障害ドメインと可用性セットを作成する

クラスターをセットから削除する

システム状態のバックアップ

次のステップ

フィードバック

その他のリソース

クラスターセットのデプロイ

クラスターセットの名前空間参照 SOFS

クラスターセットマスター

メンバークラスター

クラスターセットワーカー

クラスターセットを作成する

クラスターセット VM を作成する

インフラストラクチャスケールアウトファイルサーバーを作成する