クラスターセットをデプロイする

2025-05-03
適用対象: ✅ Windows Server 2025, ✅ Windows Server 2022, ✅ Windows Server 2019, ✅ Windows Server 2016, ✅ Azure Local 2311.2 and later

適用対象: Windows Server 2019

この記事では、PowerShell を使用して Windows Server フェールオーバークラスターのクラスターセットをデプロイする方法について説明します。クラスターセットは、一緒にクラスター化された複数のフェールオーバークラスターのグループです。クラスターセットを使用すると、1 つのソフトウェア定義データセンター (SDDC) クラウド内のサーバーノードの数を桁違いに増やすことができます。

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

メリット

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

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

要件と制限

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

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

アーキテクチャ

次の図は、高次元でのクラスターセットを示しています。

次に示す各要素の概要を示します。

管理クラスター

管理クラスターは、高可用性管理プレーンと、クラスターセットの名前空間紹介スケールアウトファイルサーバー (SOFS) をホストします。管理クラスターは、VM ワークロードを実行する個々のメンバークラスターから論理的に分離されます。これにより、クラスターセット管理プレーンは、メンバークラスターの電源が失われるなど、クラスター全体のローカライズされた障害に対して回復性が高くなります。

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

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

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

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

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

メンバークラスター

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

クラスターセット worker

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

障害ドメイン

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

可用性セット

可用性セットは、ワークロードをグループ化してデプロイすることで、障害ドメイン間でクラスター化されたワークロードの必要な冗長性を構成するために使用されます。 2 層アプリケーションの場合は、各層の可用性セットに少なくとも 2 つの VM を構成する必要があります。これにより、可用性セット内の障害ドメインがダウンしたときに、アプリケーションは各層に少なくとも 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 つの仮想プロセッサ
使用可能な CPU 最小使用率 10%

# 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

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

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

VM が作成されると、指定された特定のノードの Hyper-V マネージャーに表示されます。クラスターセット 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 パスは 1 つのメンバークラスターに対してローカルに設計されているため、メンバークラスター間でライブマイグレーションされると VM からアクセスできないため、ストレージの移行が必要です。

この例では、スケールアウトファイルサーバー SOFS-CLUSTER3 で Add-ClusterSetMember を使用して、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 クラスターロールがあります。インフラストラクチャ SOFS ロールは、-Infrastructure コマンドレットに Add-ClusterScaleOutFileServerRole スイッチパラメーターを指定することによって作成されます。例えば次が挙げられます。

Add-ClusterScaleoutFileServerRole -Name "my_infra_sofs_name" -Infrastructure

作成された各 CSV ボリュームは、CSV ボリューム名に基づいて自動生成された名前を持つ SMB 共有の作成を自動的にトリガーします。 CSV ボリュームの作成および変更操作を使用する以外に、SOFS ロールで SMB 共有を直接作成または変更することはできません。

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

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

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

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

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

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

次の例では、クラスターセットに 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"

それらが正常に作成されたことを確認するために、FD1 の出力を表示して Get-ClusterSetFaultDomain を実行できます。

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 バックアップを使用すると、必要に応じてノードのクラスターデータベースのみを復元したり、権限のある復元を実行してクラスターデータベース全体をすべてのノードにロールバックしたりできます。クラスターセットの場合は、最初にメンバークラスターに対して権限のある復元を行い、次に管理クラスターに対して権限のある復元を行うことをお勧めします。システム状態のバックアップの詳細については、「システム状態とベアメタルのバックアップ」を参照してください。

次のステップ

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

次の方法で共有

クラスター セットをデプロイする

メリット

要件と制限

アーキテクチャ

管理クラスター

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

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

メンバー クラスター

クラスター セット worker