Azure Stack HCI および Windows Server クラスター上でボリュームを作成する
適用対象: Azure Stack HCI バージョン 22H2 および 21H2、Windows Server 2022、Windows Server 2019、Windows Server 2016
この記事では、Windows Admin Center と Windows PowerShell を使用してクラスター上にボリュームを作成する方法、ボリューム上でファイルを操作する方法、ボリューム上で重複除去と圧縮、整合性チェックサム、BitLocker 暗号化を有効にする方法について説明します。 ストレッチ クラスター用のボリュームを作成し、レプリケーションを設定する方法を学習するには、拡張ボリュームの作成に関する記事を参照してください。
ヒント
まだ確認していない場合は、まずボリュームの計画に関するページをご覧ください。
単一ノード クラスター上にボリュームを作成する場合は、PowerShell を使う必要があります。 PowerShell を使ったボリュームの作成に関する記事を参照してください。
2 方向または 3 方向ミラー ボリュームを作成する
Windows Admin Center を使用して 2 方向または 3 方向ミラー ボリュームを作成するには:
Windows Admin Center で、クラスターに接続し、 [ツール] ウィンドウで [ボリューム] を選択します。
[ボリューム] ページで [インベントリ] タブを選択し、 [作成] を選択します。
[ボリュームの作成] ペインで、ボリュームの名前を入力します。
[回復性] で、クラスター内のサーバーの数に応じて、 [Two-way mirror](2 方向ミラー) または [Three-way mirror](3 方向ミラー) を選択します。
[Size on HDD](HDD 上のサイズ) で、ボリュームのサイズを指定します。 たとえば、5 TB (テラバイト) のように指定します。
[その他のオプション] の下のチェックボックスを使用して、重複除去と圧縮、整合性チェックサム、または BitLocker 暗号化を有効にすることができます。
［作成］ を選択します
サイズによっては、ボリュームの作成に数分かかることがあります。 右上の通知により、ボリュームが作成されたことを知ることができます。 すると、新しいボリュームがインベントリの一覧に表示されます。
ミラー高速パリティ ボリュームの作成
ミラー高速パリティ (MAP) によって、HDD 上のボリュームのフットプリントが減少します。 たとえば、3 方向ミラー ボリュームでは、10 テラバイトのサイズごとに、フットプリントとして 30 テラバイトが必要になることを意味します。 フットプリントのオーバーヘッドを削減するには、ミラー高速パリティを使用してボリュームを作成します。 これにより、最もアクティブな 20 % のデータをミラー化し、よりスペース効率の高いパリティを使用して残りを保管することで、4 台のサーバーのみでも、フットプリントを 30 テラバイトから 22 テラバイトまで削減できます。 このパリティとミラーの比率を調整して、ワークロードに適したパフォーマンスと容量のトレードオフを実現できます。 たとえば、90 % のパリティと 10 % のミラーでは、パフォーマンスが低下しますが、フットプリントはさらに合理化されます。
注意
ミラー高速パリティ ボリュームには、Resilient File System (ReFS) が必要です。
Windows Admin Center でミラー高速パリティを使用するボリュームを作成するには、次のようにします。
- Windows Admin Center で、クラスターに接続し、 [ツール] ウィンドウで [ボリューム] を選択します。
- [ボリューム] ページで [インベントリ] タブを選択し、 [作成] を選択します。
- [ボリュームの作成] ペインで、ボリュームの名前を入力します。
- [回復性] で、 [Mirror-accelerated parity](ミラー高速パリティ) を選択します。
- [Parity percentage](パリティの割合) で、パリティの割合を選択します。
- [その他のオプション] の下のチェックボックスを使用して、重複除去と圧縮、整合性チェックサム、または BitLocker 暗号化を有効にすることができます。
- ［作成］ を選択します
ボリュームを開いてファイルを追加する
Windows Admin Center でボリュームを開き、ボリュームにファイルを追加するには、次のようにします。
Windows Admin Center で、クラスターに接続し、 [ツール] ウィンドウで [ボリューム] を選択します。
[ボリューム] ページで、 [インベントリ] タブを選択します。
ボリュームの一覧で、開くボリュームの名前を選択します。
ボリュームの詳細ページで、ボリュームのパスを確認できます。
ページの最上部で [開く] を選択します。 これにより、Windows dmin Center のファイル ツールが起動します。
ボリュームのパスに移動します。 ここで、ボリューム内のファイルを参照できます。
[アップロード] を選択し、アップロードするファイルを選択します。
ブラウザーの [戻る] ボタンを使用して、Windows Admin Center の [ツール] ペインに戻ります。
重複除去と圧縮を有効にする
重複除去と圧縮はボリュームごとに管理されます。 重複除去と圧縮では後処理モデルが使用されるため、実行されるまで節約は確認されません。 実行されると、以前から存在するファイルであっても、すべてのファイルが処理されます。
詳細については、「ボリュームの暗号化、重複除去、圧縮を有効にする」をご覧ください。
Windows PowerShell を使用してボリュームを作成する
最初に、Windows の [スタート] メニューから Windows PowerShell を起動します。 New-Volume コマンドレットを使用して、Azure Stack HCI のボリュームを作成することをお勧めします。 これは、高速で操作が非常に分かりやすいです。 このコマンドレット 1 つだけで、仮想ディスクが作成されて、パーティション化およびフォーマットされ、一致する名前を持つボリュームが作成されて、クラスター共有ボリュームに追加されます。すべて 1 つの簡単な手順で行うことができます。
New-Volume コマンドレットには、次の 4 つのパラメーターを常に指定する必要があります。
FriendlyName: 任意の文字列 (たとえば "Volume1")
FileSystem:CSVFS_ReFS (すべてのボリュームに推奨されます。ミラー高速パリティ ボリュームの場合は必須です) または CSVFS_NTFS のいずれか
StoragePoolFriendlyName: 記憶域プールの名前 (たとえば "S2D on ClusterName" )
Size: ボリュームのサイズ (たとえば "10 TB" )
注意
PowerShell を含む Windows では、バイナリ (基数 2) の数値を使用してカウントされますが、ドライブには 10 進数 (基数 10) の数値でラベルが付けれていることがよくあります。 これが理由で、1 兆バイトとして定義された "1 テラバイト" のドライブは Windows で約 "909 GB" として表示されます。 これは予期されることです。 New-Volume を使用してボリュームを作成する場合は、Size パラメーターをバイナリ (基数 2) の数値で指定する必要があります。 たとえば、"909 GB" または "0.909495 TB" を指定すると、約 1 兆バイトのボリュームが作成されます。
例: サーバーが 1 台から 3 台の場合
設定を簡単にするために、デプロイにサーバーが 1 台または 2 台しかない場合は、回復性を確保するために、記憶域スペース ダイレクトによって双方向のミラーリングが自動的に使用されます。 デプロイにサーバーが 3 台しかない場合は、自動的に 3 方向のミラーリングが使用されます。
New-Volume -FriendlyName "Volume1" -FileSystem CSVFS_ReFS -StoragePoolFriendlyName S2D* -Size 1TB
例:4 台以上のサーバー
4 台以上のサーバーがある場合は、オプションの ResiliencySettingName パラメーターを使用して、回復性の種類を選択できます。
- ResiliencySettingName:Mirror または Parity のいずれか。
次の例では "Volume2" で 3 方向ミラーリングを使用し、 "Volume3" でデュアル パリティを使用しています ("イレージャー コーディング" とよく呼ばれます)。
New-Volume -FriendlyName "Volume2" -FileSystem CSVFS_ReFS -StoragePoolFriendlyName S2D* -Size 1TB -ResiliencySettingName Mirror
New-Volume -FriendlyName "Volume3" -FileSystem CSVFS_ReFS -StoragePoolFriendlyName S2D* -Size 1TB -ResiliencySettingName Parity
ストレージ層の使用
3 種類のドライブを使用したデプロイでは、1 つのボリュームが SSD および HDD 階層にまたがり、それぞれに部分的に存在することができます。 同様に、4 台以上のサーバーを使用したデプロイでは、1 つのボリュームにミラーリングとデュアル パリティを混在させ、両方に部分的に配置できます。
このようなボリュームの作成を支援するために、Azure Stack HCI には、MirrorOnMediaType および NestedMirrorOnMediaType (パフォーマンス用) と、ParityOnMediaType および NestedParityOnMediaType (容量用) (この MediaType は HDD または SSD です) という既定の階層テンプレートが用意されています。 テンプレートは、メディアの種類に基づいてストレージ層を表し、高速な容量のドライブの 3 方向ミラーリング (該当する場合)、および低速な容量のドライブのデュアル パリティ (該当する場合) の定義をカプセル化したものです。
注意
単一サーバー構成では、ストレージ バス レイヤー (SBL) キャッシュはサポートされていません。 単一サーバーでサポートされるストレージの種類は、すべてフラットな単一ストレージの構成 (たとえば、すべて NVMe またはすべて SSD) のみです。
注意
Windows Server 2016 の以前のバージョンで実行されていた記憶域スペース ダイレクト クラスター上では、既定の層テンプレートは単にパフォーマンスおよび容量と呼ばれていました。
ストレージ層を確認するには、クラスター内の任意のサーバーで Get-StorageTier コマンドレットを実行します。
Get-StorageTier | Select FriendlyName, ResiliencySettingName, PhysicalDiskRedundancy
たとえば、HDD のみを搭載した 2 ノード クラスターがある場合、出力は次のようになります。
FriendlyName ResiliencySettingName PhysicalDiskRedundancy
------------ --------------------- ----------------------
NestedParityOnHDD Parity 1
Capacity Mirror 1
NestedMirrorOnHDD Mirror 3
MirrorOnHDD Mirror 1
階層化ボリュームを作成するには、New-Volume コマンドレットの StorageTierFriendlyNames と StorageTierSizes パラメーターを使用して、これらの層テンプレートを参照します。 たとえば、次のコマンドレットは、3 方向のミラーリングとデュアル パリティを30:70 の比率で混合するボリュームを 1 つ作成します。
New-Volume -FriendlyName "Volume1" -FileSystem CSVFS_ReFS -StoragePoolFriendlyName S2D* -StorageTierFriendlyNames MirrorOnHDD, Capacity -StorageTierSizes 300GB, 700GB
必要なだけ繰り返して、複数のボリュームを作成します。
ストレージ層の概要テーブル
次の表は、Azure Stack HCI または Windows Server 内で作成される、または作成できるストレージ層をまとめたものです。
NumberOfNodes: 1
| FriendlyName | MediaType | ResiliencySettingName | NumberOfDataCopies | PhysicalDiskRedundancy | NumberOfGroups | FaultDomainAwareness | ColumnIsolation | Note |
|---|---|---|---|---|---|---|---|---|
| MirrorOnHDD | HDD | ミラー | 2 | 1 | 1 | 物理ディスク | 物理ディスク | 自動作成 |
| MirrorOnSSD | SSD | ミラー | 2 | 1 | 1 | 物理ディスク | 物理ディスク | 自動作成 |
| MirrorOnSCM | SCM | ミラー | 2 | 1 | 1 | 物理ディスク | 物理ディスク | 自動作成 |
| ParityOnHDD | HDD | パリティ | 1 | 1 | 1 | 物理ディスク | 物理ディスク | 自動作成 |
| ParityOnSSD | SSD | パリティ | 1 | 1 | 1 | 物理ディスク | 物理ディスク | 自動作成 |
| ParityOnSCM | SCM | パリティ | 1 | 1 | 1 | 物理ディスク | 物理ディスク | 自動作成 |
NumberOfNodes: 2
| FriendlyName | MediaType | ResiliencySettingName | NumberOfDataCopies | PhysicalDiskRedundancy | NumberOfGroups | FaultDomainAwareness | ColumnIsolation | Note |
|---|---|---|---|---|---|---|---|---|
| MirrorOnHDD | HDD | ミラー | 2 | 1 | 1 | StorageScaleUnit | 物理ディスク | 自動作成 |
| MirrorOnSSD | SSD | ミラー | 2 | 1 | 1 | StorageScaleUnit | 物理ディスク | 自動作成 |
| MirrorOnSCM | SCM | ミラー | 2 | 1 | 1 | StorageScaleUnit | 物理ディスク | 自動作成 |
| NestedMirrorOnHDD | HDD | ミラー | 4 | 3 | 1 | StorageScaleUnit | 物理ディスク | manual |
| NestedMirrorOnSSD | SSD | ミラー | 4 | 3 | 1 | StorageScaleUnit | 物理ディスク | manual |
| NestedMirrorOnSCM | SCM | ミラー | 4 | 3 | 1 | StorageScaleUnit | 物理ディスク | manual |
| NestedParityOnHDD | HDD | パリティ | 2 | 1 | 1 | StorageScaleUnit | 物理ディスク | manual |
| NestedParityOnSSD | SSD | パリティ | 2 | 1 | 1 | StorageScaleUnit | 物理ディスク | manual |
| NestedParityOnSCM | SCM | パリティ | 2 | 1 | 1 | StorageScaleUnit | 物理ディスク | manual |
NumberOfNodes: 3
| FriendlyName | MediaType | ResiliencySettingName | NumberOfDataCopies | PhysicalDiskRedundancy | NumberOfGroups | FaultDomainAwareness | ColumnIsolation | Note |
|---|---|---|---|---|---|---|---|---|
| MirrorOnHDD | HDD | ミラー | 3 | 2 | 1 | StorageScaleUnit | 物理ディスク | 自動作成 |
| MirrorOnSSD | SSD | ミラー | 3 | 2 | 1 | StorageScaleUnit | 物理ディスク | 自動作成 |
| MirrorOnSCM | SCM | ミラー | 3 | 2 | 1 | StorageScaleUnit | 物理ディスク | 自動作成 |
NumberOfNodes: 4+
| FriendlyName | MediaType | ResiliencySettingName | NumberOfDataCopies | PhysicalDiskRedundancy | NumberOfGroups | FaultDomainAwareness | ColumnIsolation | Note |
|---|---|---|---|---|---|---|---|---|
| MirrorOnHDD | HDD | ミラー | 3 | 2 | 1 | StorageScaleUnit | 物理ディスク | 自動作成 |
| MirrorOnSSD | SSD | ミラー | 3 | 2 | 1 | StorageScaleUnit | 物理ディスク | 自動作成 |
| MirrorOnSCM | SCM | ミラー | 3 | 2 | 1 | StorageScaleUnit | 物理ディスク | 自動作成 |
| ParityOnHDD | HDD | パリティ | 1 | 2 | 自動 | StorageScaleUnit | StorageScaleUnit | 自動作成 |
| ParityOnSSD | SSD | パリティ | 1 | 2 | 自動 | StorageScaleUnit | StorageScaleUnit | 自動作成 |
| ParityOnSCM | SCM | パリティ | 1 | 2 | 自動 | StorageScaleUnit | StorageScaleUnit | 自動作成 |
入れ子の回復性ボリューム
入れ子の回復性は、Azure Stack HCI、Windows Server 2022 または Windows Server 2019 が実行されている 2 サーバー クラスターにのみ適用されます。お使いのクラスターに 3 台以上のサーバーがある場合、または、そのクラスターによって実行されているのが Windows Server 2016 の場合、入れ子の回復性を使用することはできません。 入れ子の回復性により、2 サーバー クラスターは、ストレージの可用性を失うことなく同時に複数のハードウェア障害に耐えられます。また、ユーザー、アプリ、および仮想マシンを中断することなく継続して実行することができます。 詳細については、「記憶域スペース ダイレクトに向けた入れ子の回復性」および「ボリュームの計画: 回復性の種類の選択」を参照してください。
以下のセクションで説明するように、PowerShell で使い慣れた記憶域コマンドレットを使用して、入れ子の回復性を備えたボリュームを作成できます。
手順 1: ストレージ層テンプレートを作成する (Windows Server 2019 のみ)
WindowsServer 2019 では、ボリュームを作成する前に、New-StorageTier コマンドレットを使用して新しいストレージ層テンプレートを作成する必要があります。 これは一度だけ行う必要があります。その後は、作成するすべての新しいボリュームでこれらのテンプレートを参照できます。
注意
Server 2022、Windows Azure Stack HCI 21H2、または Azure Stack HCI 20H2 を実行している場合は、この手順をスキップできます。
容量ドライブの -MediaType を指定し、必要に応じて任意の -FriendlyName を指定します。 他のパラメーターは変更しないでください。
たとえば、容量ドライブがハード ディスク ドライブ (HDD) の場合は、管理者として PowerShell を起動し、次のコマンドレットを実行します。
NestedMirror 層を作成するには:
New-StorageTier -StoragePoolFriendlyName S2D* -FriendlyName NestedMirrorOnHDD -ResiliencySettingName Mirror -MediaType HDD -NumberOfDataCopies 4
NestedParity 層を作成するには:
New-StorageTier -StoragePoolFriendlyName S2D* -FriendlyName NestedParityOnHDD -ResiliencySettingName Parity -MediaType HDD -NumberOfDataCopies 2 -PhysicalDiskRedundancy 1 -NumberOfGroups 1 -FaultDomainAwareness StorageScaleUnit -ColumnIsolation PhysicalDisk
容量ドライブがソリッド ステート ドライブ (SSD) の場合は、代わりに -MediaType を SSD に設定し、-FriendlyName を *OnSSD に変更します。 他のパラメーターは変更しないでください。
ヒント
Get-StorageTier によって層が正常に作成されたことを確認します。
手順 2: 入れ子になったボリュームを作成する
New-Volume コマンドレットを使用して新しいボリュームを作成します。
入れ子の双方向ミラー
入れ子の双方向ミラーを使用するには、
NestedMirror層テンプレートを参照し、サイズを指定します。 例:New-Volume -StoragePoolFriendlyName S2D* -FriendlyName Volume01 -StorageTierFriendlyNames NestedMirrorOnHDD -StorageTierSizes 500GB容量ドライブがソリッド ステート ドライブ (SSD) の場合は、
-StorageTierFriendlyNamesを*OnSSDに変更します。入れ子になったミラー加速パリティ
入れ子のミラーリングによって高速化されたパリティを使用するには、
NestedMirrorとNestedParityの両方の層テンプレートを参照し、ボリュームの部分ごとに 1 つのサイズを指定します (最初がミラー、2 番目がパリティの 2 つ)。 たとえば、入れ子になった双方向のミラーが 20% で入れ子になったパリティが 80% の 500 GB ボリュームを 1 つ作成するには、次を実行します。New-Volume -StoragePoolFriendlyName S2D* -FriendlyName Volume02 -StorageTierFriendlyNames NestedMirrorOnHDD, NestedParityOnHDD -StorageTierSizes 100GB, 400GB容量ドライブがソリッド ステート ドライブ (SSD) の場合は、
-StorageTierFriendlyNamesを*OnSSDに変更します。
手順 3: Windows Admin Center で続行する
入れ子になった回復性を使用するボリュームは、次のスクリーンショットのように、明確なラベル付けを使用してWindows Admin Centerに表示されます。 作成されたら、記憶域スペース ダイレクトの他のすべてのボリュームと同様に、Windows Admin Center を使用してそれらを管理し、監視することができます。
省略可能: キャッシュ ドライブまで拡張する
入れ子の回復性を使用すると、既定の設定で、複数の容量ドライブが同時に失われたり、1 台のサーバーと 1 つの容量のドライブが同時に失われたりする状況から保護されます。 この保護を キャッシュ ドライブに拡張するには、もう 1 つの考慮事項があります。キャッシュ ドライブは、多くの場合、複数の容量ドライブに対して読み取りと書き込みのキャッシュを提供するため、他のサーバーがダウンしたときにキャッシュ ドライブの損失を許容できる唯一の方法は、キャッシュの書き込みではなく、パフォーマンスに影響します。
このシナリオに対処するため、記憶域スペース ダイレクトには、2 台構成のサーバー クラスターで 1 台のサーバーがダウンしたら自動的に書き込みキャッシュを無効にして、サーバーが復帰したら書き込みキャッシュを再度有効にするオプションが用意されています。 パフォーマンスに影響を与えずにルーチンを再開できるように、書き込みキャッシュはサーバーが 30 分間停止されるまで無効にされません。 書き込みキャッシュが無効にされると、書き込みキャッシュの内容は容量デバイスに書き込まれます。 この後のサーバーでは、オンライン サーバーに障害が発生したキャッシュ デバイスがあっても問題ありません。ただし、キャッシュ デバイスで障害が発生した場合、キャッシュからの読み取りが遅れたり失敗したりする可能性があります。
注意
すべてのキャッシュ (単一メディア タイプ) 物理システムの場合、2 サーバー クラスター内の 1 つのサーバーがダウンしている場合に、書き込みキャッシュの自動無効化を検討する必要はありません。 これは、HDD を使用している場合にのみ必要なストレージ バス レイヤー (SBL) キャッシュでのみ考慮する必要があります。
(省略可能) 2 サーバー クラスター内の 1 つのサーバーがダウンしたときに書き込みキャッシュを自動的に無効にするには、管理者として PowerShell を起動し、次を実行します。
Get-StorageSubSystem Cluster* | Set-StorageHealthSetting -Name "System.Storage.NestedResiliency.DisableWriteCacheOnNodeDown.Enabled" -Value "True"
True に設定すると、キャッシュの動作は次のようになります。
| 状況 | キャッシュの動作 | キャッシュ ドライブの損失に耐えられるか |
|---|---|---|
| 両方のサーバーが稼働 | 読み取りと書き込みをキャッシュする、完全なパフォーマンス | はい |
| サーバーがダウン、最初の 30 分間 | 読み取りと書き込みをキャッシュする、完全なパフォーマンス | いいえ (一時的) |
| 最初の 30 分間の後 | 読み取りのみキャッシュする、パフォーマンスが影響を受ける | はい (キャッシュが容量ドライブに書き込まれた後) |
次のステップ
関連トピックおよびその他のストレージ管理タスクについては、次のトピックも参照してください。
フィードバック
以下は間もなく提供いたします。2024 年を通じて、コンテンツのフィードバック メカニズムとして GitHub の issue を段階的に廃止し、新しいフィードバック システムに置き換えます。 詳細については、「https://aka.ms/ContentUserFeedback」を参照してください。
フィードバックの送信と表示