Azure Stack HCI クラスターの検証
適用対象: Azure Stack HCI、バージョン 22H2 および 21H2。Windows Server 2022、Windows Server 2019。
警告
この記事で説明するデプロイ手順は、古いバージョンの Azure Stack HCI バージョン 22H2 に適用されます。 新しいデプロイでは、一般公開されている最新バージョンの Azure Stack HCI バージョン 23H2 を使用することをお勧めします。 デプロイ手順については、「 Azure Stack HCI バージョン 23H2 デプロイについて」を参照してください。
DCB が、Azure Stack HCI でホスト ネットワーク構成を設定またはテストするための推奨ツールではなくなりました。 ネットワーク ATC を使用して、Azure Stack HCI のホスト ネットワーク セットアップを構成することをお勧めします。 ネットワーク ATC は常に Azure Stack HCI 上の DCB の検証よりも優先されます。
Windows Admin Center でクラスターの作成ウィザードを実行すると、選択したハードウェアで動作するクラスターを作成するための特定の検証が行われますが、クラスターの検証では、クラスターが運用環境で動作することを確認するための追加のチェックが実行されます。 このハウツー記事では、クラスターの検証が重要である理由と、どのようなときに Azure Stack HCI クラスターに対してそれを実行するかについて説明します。
主に次のようなシナリオで、クラスターの検証を実行することをお勧めします。
- サーバー クラスターをデプロイした後、Validate-DCB ツールを実行してネットワークをテストします。
- サーバー クラスターを更新した後、シナリオによっては、両方の検証オプションを実行して、クラスターの問題のトラブルシューティングを行います。
- 記憶域レプリカを使用してレプリケーションを設定した後、いくつかの具体的なイベントを調べて、コマンドをいくつか実行することにより、レプリケーションが正常に進行していることを確認します。
- サーバー クラスターを作成したら、運用環境に配置する前に Validate-DCB ツールを実行します。
クラスターの検証とは
クラスターの検証の目的は、クラスターの運用を始める前に、ハードウェアまたは構成の問題を検出することです。 クラスターの検証を行うと、デプロイしようとしている Azure Stack HCI ソリューションが本当に信頼できることを確認するのに役立ちます。 また、構成済みのフェールオーバー クラスターで診断ツールとしてクラスターの検証を使用することもできます。
具体的な検証シナリオ
ここでは、検証が必要または便利なシナリオについて説明します。
クラスターを構成する前の検証:
フェールオーバー クラスターにする準備ができているサーバーのセット: これは、最も簡単な検証シナリオです。 ハードウェア コンポーネント (システム、ネットワーク、ストレージ) は接続されていますが、システムはまだクラスターとして機能していません。 この状況でテストを実行しても、可用性には影響しません。
サーバー VM: クラスター内の仮想化されたサーバーの場合、他の新しいクラスターの場合と同様に、クラスターの検証を実行します。 この機能を実行するための要件は、次のどちらの場合でも同じです。
- 2 台の物理コンピューターの間でフェールオーバーが行われる "ホスト クラスター"。
- 同じ物理コンピューター上のゲスト オペレーティング システムの間でフェールオーバーが行われる "ゲスト クラスター"。
クラスターが構成されて使用された後の検証:
クラスターにサーバーを追加する前: クラスターにサーバーを追加するときは、クラスターを検証することを強くお勧めします。 クラスターの検証を実行するときに、既存のクラスター メンバーと新しいサーバーの両方を指定します。
ドライブを追加するとき: 新しいドライブをクラスターに追加するときは、障害が発生したドライブの交換や、既存のドライブに依存する仮想ディスクやボリュームの作成とは異なり、クラスターの検証を実行して、新しいストレージが正しく機能することを確認します。
ファームウェアまたはドライバーに影響する変更を行うとき: クラスターでファームウェアまたはドライバーに影響するアップグレードまたは変更を行う場合は、クラスターの検証を実行して、ハードウェア、ファームウェア、ドライバー、ソフトウェアの新しい組み合わせで、フェールオーバー クラスターの機能がサポートされることを確認する必要があります。
バックアップからシステムを復元した後: バックアップからシステムを復元した後は、クラスターの検証を実行し、システムがクラスターの一部として正しく機能していることを確認します。
ネットワークを検証する
Microsoft の Validate-DCB ツールは、クラスターでのデータ センター ブリッジング (DCB) の構成を検証するように設計されています。 これを行うには、ツールに入力として期待される構成を渡すと、クラスター内の各サーバーのテストが行われます。 このセクションでは、Validate-DCB ツールをインストールして実行する方法、結果を確認する方法、およびツールによって識別されたネットワーク エラーを解決する方法について説明します。
Note
Microsoft では、Network ATC を使用して構成をデプロイおよび管理することをお勧めします。これにより、Validate-DCB ツールで検査される構成の課題のほとんどが解消されます。 ネットワーク デプロイをホストするためのインテント ベースのアプローチを提供する Network ATC の詳細については、「Network ATC を使用してホスト ネットワークを単純化する」を参照してください。
ネットワークで RDMA (リモート ダイレクト メモリ アクセス) over Converged Ethernet (RoCE) を使用すると、ネットワーク ファブリックを無損失にするために DCB テクノロジが必要です。 iWARP の場合、DCB は省略可能です。 ただし、DCB の構成は複雑な場合があり、以下のすべてで正確に構成する必要があります。
- クラスター内の各サーバー
- ファブリック上の RDMA トラフィックが通過する各ネットワーク ポート
前提条件
- 次のような、検証するサーバー クラスターのネットワーク セットアップ情報。
- ホストまたはサーバー クラスターの名前
- 仮想スイッチの名前
- ネットワーク アダプターの名前
- 優先順位フロー制御 (PFC) と Enhanced Transmission Selection (ETS) の設定
- Microsoft から Windows PowerShell のツール モジュールをダウンロードするためのインターネット接続。
Validate-DCB ツールをインストールして実行する
Validate-DCB ツールをインストールして実行するには:
管理 PC で、管理者として Windows PowerShell セッションを開き、次のコマンドを使用してツールをインストールします。
Install-Module Validate-DCB
NuGet プロバイダーの使用に関する要求を受け入れ、リポジトリにアクセスしてツールをインストールします。
PowerShell により Microsoft ネットワークに接続してツールがダウンロードされた後、「
Validate-DCB
」と入力して Enter キーを押し、ツール ウィザードを開始します。Note
Validate-DCB ツールのスクリプトを実行できない場合は、PowerShell の実行ポリシーの調整が必要になることがあります。 現在のスクリプト実行ポリシーの設定を表示するには、Get-ExecutionPolicy コマンドレットを使用します。 PowerShell での実行ポリシーの設定の詳細については、「実行ポリシーについて」を参照してください。
[Welcome to the Validate-DCB](Validate-DCB へようこそ) 構成ウィザード ページで、 [次へ] を選択します。
[Clusters and Nodes](クラスターとノード) ページで、検証するサーバー クラスターの名前を入力し、 [解決] を選択してページにその一覧を表示した後、 [次へ] を選択します。
[Adapters](アダプター) ページで、次のようにします。
- [vSwitch attached](接続されている vSwitch) チェック ボックスをオンにして、vSwitch の名前を入力します。
- [Adapter Name](アダプター名) に各物理 NIC の名前を入力し、 [Host vNIC Name](ホスト vNIC 名) に各仮想 NIC (vNIC) の名前を入力し、 [VLAN] に各アダプターで使用されている VLAN ID を入力します。
- [RDMA Type](RDMA の種類) ドロップダウンの一覧を展開して、適切なプロトコルを選択します: [RoCE] または [iWARP] 。 また、 [Jumbo Frames](ジャンボ フレーム) をネットワークに対する適切な値に設定し、 [次へ] を選択します。
Note
- SR-IOV によるネットワーク パフォーマンスの向上の詳細については、「シングル ルート I/O 仮想化 (SR-IOV) の概要」を参照してください。
[Data Center Bridging](データ センター ブリッジング) ページで、 [Priority](優先順位) 、 [Policy Name](ポリシー名) 、 [Bandwidth Reservation](帯域幅予約) の値を組織の設定と一致するように変更して、 [次へ] を選択します。
Note
前のウィザード ページで RDMA over RoCE を選択した場合は、すべての NIC とスイッチポートでネットワークの信頼性のために DCB が必要です。
[保存して展開] ページの [ 構成ファイルパス ] ボックスで、 .ps1 拡張子を使用して構成ファイルを後で必要に応じて再び使用できる場所に保存し、[ エクスポート ] を選択して Validate-DCB ツールの実行を開始します。
- 必要に応じて、ページの [Deploy Configuration to Nodes](ノードに構成をデプロイする) セクションを設定することで、構成ファイルをデプロイできます。これには、Azure Automation アカウントを使用して構成をデプロイしてから検証する機能が含まれます。 Azure Automation の使用を開始するには、「Azure Automation アカウントを作成する」を参照してください。
結果を確認してエラーを修正する
Validate-DCB ツールにより、2 つのユニットで結果が生成されます。
- [Global Unit] の結果には、モーダル テストを実行するための前提条件と要件の一覧が表示されます。
- [Modal Unit] の結果では、各クラスター ホストの構成とベスト プラクティスについてのフィードバックが提供されます。
この例では、失敗カウントが 0 なので、すべての前提条件とモーダルのユニットのテストで、単一サーバーのスキャン結果が成功であったことが示されています。
次の手順では、vNIC SMB02 からのジャンボ パケット エラーを識別して修正する方法を示します。
Validate-DCB ツール スキャンの結果では、失敗カウントで 1 つのエラーが示されています。
結果を上にスクロールするとエラーが赤で表示され、ホスト S046036 の vNIC SMB02 に対するジャンボ パケットが既定のサイズ 1514 に設定されてますが、9014 に設定する必要があることが示されています。
ホスト S046036 の vNIC SMB02 の [詳細設定] プロパティを確認すると、ジャンボ パケットが既定の [無効] に設定されていることがわかります。
エラーを修正するには、ジャンボ パケット機能を有効にして、サイズを 9014 バイトに変更する必要があります。 ホスト S046036 でもう一度スキャンを実行すると、失敗カウントが 0 に戻っていることで、この変更が確認されます。
Validate-DCB ツールで明らかになったエラーの解決方法の詳細については、次のビデオをご覧ください。
ツールをオフラインでインストールすることもできます。 切断されたシステムの場合は、Save-Module -Name Validate-DCB -Path c:\temp\Validate-DCB
を使用し、c:\temp\Validate-DCB 内のモジュールを切断されたシステムに移動します。 詳細については、次のビデオをご覧ください。
クラスターを検証する
Windows Admin Center で既存のクラスターのサーバーを検証するには、次の手順を使用します。
Windows Admin Center の [すべての接続] で検証する Azure Stack HCI クラスターを選択し、 [接続] を選択します。
クラスター マネージャー ダッシュボードに、クラスターに関する概要情報が表示されます。
クラスター マネージャー ダッシュボードの [ツール] で、 [サーバー] を選択します。
[インベントリ] ページで、クラスター内のサーバーを選択し、 [その他] サブメニューを展開して、 [クラスターの検証] を選択します。
[クラスターの検証] ポップアップ ウィンドウで、 [はい] を選択します。
[Credential Security Service Provider (CredSSP)] ポップアップ ウィンドウで、 [はい] を選択します。
資格情報を入力して CredSSP を有効にした後、 [続行] を選択します。
クラスターの検証がバックグラウンドで実行され、完了すると通知が表示されます。その時点で、次のセクションで説明するように、検証レポートを表示できます。
Note
クラスター サーバーの検証が済んだら、セキュリティのため CredSSP を無効にする必要があります。
CredSSP を無効にする
サーバー クラスターが正常に検証されたら、セキュリティのため、各サーバーで資格情報セキュリティ サポート プロバイダー (CredSSP) プロトコルを無効にします。 詳細については、CVE-2018-0886 を参照してください。
Windows Admin Center の [すべての接続] で、クラスター内の最初のサーバーを選択し、 [接続] を選択します。
[概要] ページで [Disable CredSSP](CredSSP を無効にする) を選択し、次に [Disable CredSSP](CredSSP を無効にする) ポップアップ ウィンドウで [はい] を選択します。
ステップ 2 を実行すると、サーバーの [概要] ページの上部にある赤い [CredSSP ENABLED](CredSSP が有効になっています) というバナーが表示されなくなり、他のサーバーの CredSSP が無効になります。
検証レポートを表示する
これで、クラスター検証レポートを表示する準備ができました。
検証レポートにアクセスするには、2 つの方法があります。
[インベントリ] ページで [その他] サブメニューを展開し、 [View validation reports](検証レポートの表示) を選択します。
Windows Admin Center の右上にある [通知] ベル アイコンを選択して、 [通知] ウィンドウを表示します。 [Successfully validated cluster](正常に検証されたクラスター) 通知を選択し、 [Go to Failover Cluster validation report](フェールオーバー クラスター検証レポートに移動する) を選択します。
Note
サーバー クラスター検証プロセスが完了するまでに時間がかかることがあります。 プロセスの実行中は、Windows Admin Center の別のツールに切り替えないでください。 [通知] ウィンドウで、 [クラスターの検証] 通知の下にあるステータス バーには、プロセスがいつ完了したかが示されます。
PowerShell を使用してクラスターを検証する
Windows PowerShell を使用して、サーバー クラスターに対する検証テストを実行し、結果を表示することもできます。 テストは、クラスターのセットアップの前と後の両方で実行できます。
サーバー クラスターの検証テストを実行するには、管理 PC から Get-Cluster および Test-Cluster<サーバー クラスター名> PowerShell コマンドレットを実行するか、クラスターで直接 Test-Cluster コマンドレットのみを実行します。
$Cluster = Get-Cluster -Name 'server-cluster1'
Test-Cluster -InputObject $Cluster -Verbose
その他の例と使用方法に関する情報については、「Test-Cluster」のリファレンス ドキュメントを参照してください。
Test-NetStack は、GitHub から入手できる PowerShell ベースのテスト ツールです。これは、ネットワークの ICMP、TCP、RDMA のトラフィック テストを実行したり、潜在的なネットワーク ファブリックとホストの不備や動作の不安定性を特定したりするために使用できます。 Test-NetStack を使用して、ネイティブ、合成、ハードウェア オフロード (RDMA) のネットワーク データ パスをテストし、接続性、パケットの断片化、低スループット、輻輳に関する問題を確認します。
記憶域レプリカのレプリケーションを検証する
記憶域レプリカを使用してストレッチ クラスターまたはクラスター間でボリュームをレプリケートする場合、レプリケーションの状態を取得するために使用できるイベントとコマンドレットがいくつかあります。
次のシナリオでは、2 つのサイトにレプリケーション グループ (RG) を作成することにより記憶域レプリカを構成した後、Site1 のソース サーバー ノード (Server1、Server2) と Site2 のターゲット (レプリケート先) サーバー ノード (Server3、Server4) の両方に対して、データ ボリュームとログ ボリュームを指定しました。
Site1 の Server1 でのレプリケーションの進行状況を確認するには、Get-WinEvent コマンドを実行し、イベント 5015、5002、5004、1237、5001、2200 を調べます。
Get-WinEvent -ComputerName Server1 -ProviderName Microsoft-Windows-StorageReplica -max 20
Site2 の Server3 の場合は、次の Get-WinEvent
コマンドを実行して、パートナーシップの作成を示す記憶域レプリカ イベントを確認します。 このイベントでは、コピーされたバイト数と所要時間が示されます。 次に例を示します。
Get-WinEvent -ComputerName Server3 -ProviderName Microsoft-Windows-StorageReplica | Where-Object {$_.ID -eq "1215"} | FL
Site2 の Server3 の場合、Get-WinEvent
コマンドを実行し、イベント 5009、1237、5001、5015、5005、2200 を調べて、処理の進行状況を把握します。 このシーケンスでは、エラーの警告は発生しないはずです。 多数の 1237 イベントが発生します。これらは進行状況を示します。
Get-WinEvent -ComputerName Server3 -ProviderName Microsoft-Windows-StorageReplica | FL
または、レプリカのターゲット サーバー グループでは、常にコピーの残りバイト数が示され、PowerShell でGet-SRGroup
を使用してクエリを実行できます。 次に例を示します。
(Get-SRGroup).Replicas | Select-Object numofbytesremaining
Site2 のノード Server3 の場合は、次のコマンドを実行し、イベント 5009、1237、5001、5015、5005、2200 を調べて、レプリケーションの進行状況を把握します。 エラーの警告は表示されないはずです。 ただし、多くの "1237" イベントが存在します。これは単に進行状況を示します。
Get-WinEvent -ComputerName Server3 -ProviderName Microsoft-Windows-StorageReplica | FL
終了しない進行状況スクリプトとして:
while($true) {
$v = (Get-SRGroup -Name "Replication2").replicas | Select-Object numofbytesremaining
[System.Console]::Write("Number of bytes remaining: {0}`r", $v.numofbytesremaining)
Start-Sleep -s 5
}
ストレッチ クラスター内でレプリケーションの状態を取得するには、Get-SRGroup
と Get-SRPartnership
を使用します。
Get-SRGroup -Cluster ClusterS1
Get-SRPartnership -Cluster ClusterS1
(Get-SRGroup).replicas -Cluster ClusterS1
サイト間でデータが正常にレプリケートされたことを確認したら、VM と他のワークロードを作成できます。
関連項目
- 新しく作成された記憶域スペースでの合成ワークロードに対する、DiskSpd.exe を使用したパフォーマンス テスト。 詳細については、「Windows Server で合成ワークロードを使用して記憶域スペースのパフォーマンスをテストする」を参照してください。
- Windows Server Assessment は、インストールの確認を希望するお客様が利用できる Premier サービスです。 詳細については、Microsoft Premier サポートにお問い合わせください。 詳細については、「Windows Server のオンデマンド評価 (サーバー、セキュリティ、Hyper-V、フェールオーバー クラスター、IIS) の概要」を参照してください。