Azure Stack HCI クラスターを検証する

適用対象: Azure Stack HCI バージョン 22H2 および 21H2;Windows Server 2022、Windows Server 2019。

Important

Azure Stack HCI が Azure Local の一部になりました。 ただし、古いバージョンの Azure Stack HCI (例: 22H2) は HCI Azure Stack参照し続け、名前の変更は反映されません。 詳細はこちらでご確認ください。

警告

この記事で説明するデプロイ手順は、HCI バージョン 22H2 Azure Stack以前のバージョンに適用されます。 新しいデプロイについては、一般公開されている最新バージョンのAzure Localを使用することをお勧めします。「Azure Local展開について」を参照してください。

DCB が、Azure Stack HCI でホスト ネットワーク構成を設定またはテストするための推奨ツールではなくなりました。 ネットワーク ATC を使用して、Azure Stack HCI のホスト ネットワーク セットアップを構成することをお勧めします。 Network ATC は、Azure Stack HCI では常に Validate DCB に優先します。

Windows Admin Centerのクラスターの作成ウィザードでは、選択したハードウェアで動作するクラスターを作成するために特定の検証が実行されますが、クラスターの検証では追加のチェックが実行され、クラスターが運用環境で動作することを確認します。 このハウツー記事では、クラスター検証が重要な理由と、Azure Stack HCI クラスターで実行するタイミングについて説明します。

次の主要なシナリオでは、クラスターの検証を実行することをお勧めします。

• サーバー クラスターをデプロイした後、Validate-DCB ツールを実行してネットワークをテストします。
• サーバー クラスターを更新した後、シナリオに応じて、両方の検証オプションを実行してクラスターの問題をトラブルシューティングします。
• 記憶域レプリカを使用してレプリケーションを設定した後、特定のイベントを確認し、2 つのコマンドを実行して、レプリケーションが正常に進行していることを確認します。
• サーバー クラスターを作成した後、Validate-DCB ツールを実行してから運用環境に配置します。

クラスター検証とは

クラスターの検証は、クラスターが運用環境に移行する前にハードウェアまたは構成の問題をキャッチすることを目的としています。 クラスターの検証は、デプロイしようとしているAzure Stack HCI ソリューションが本当に信頼できることを確認するのに役立ちます。 構成済みのフェールオーバー クラスターでクラスター検証を診断ツールとして使用することもできます。

特定の検証シナリオ

このセクションでは、検証も必要または便利なシナリオについて説明します。

• クラスターが構成される前の検証:

  • フェールオーバー クラスターになる準備ができているサーバーのセット: これは最も簡単な検証シナリオです。 ハードウェア コンポーネント (システム、ネットワーク、ストレージ) は接続されていますが、システムはまだクラスターとして機能していません。 この状況でテストを実行しても、可用性には影響しません。

  • サーバー VM: クラスター内の仮想化されたサーバーの場合は、他の新しいクラスターと同様にクラスター検証を実行します。 この機能を実行する要件は、次のものがあるかどうかに関係なく同じです。

    • 2 台の物理コンピューター間でフェールオーバーが発生する "ホスト クラスター" です。
    • 同じ物理コンピューター上のゲスト オペレーティング システム間でフェールオーバーが発生する "ゲスト クラスター" です。

• クラスターが構成され使用中の後の検証:

  • クラスターにサーバーを追加する前に、次の手順を実行します 。クラスターにサーバーを追加するときは、クラスターを検証することを強くお勧めします。 クラスター検証を実行するときに、既存のクラスター メンバーと新しいサーバーの両方を指定します。

  • ドライブを追加する場合: 障害が発生したドライブの交換や、既存のドライブに依存する仮想ディスクまたはボリュームの作成とは異なるドライブをクラスターに追加する場合は、クラスター検証を実行して、新しいストレージが正しく機能することを確認します。

  • ファームウェアまたはドライバーに影響を与える変更を行う場合: ファームウェアまたはドライバーに影響するクラスターをアップグレードまたは変更する場合は、クラスター検証を実行して、ハードウェア、ファームウェア、ドライバー、ソフトウェアの新しい組み合わせがフェールオーバー クラスター機能をサポートしていることを確認する必要があります。

  • バックアップからシステムを復元した後: バックアップからシステムを復元した後、クラスター検証を実行して、システムがクラスターの一部として正しく機能することを確認します。

ネットワークの検証

Microsoft Validate-DCB ツールは、クラスター上のデータ センター ブリッジング (DCB) 構成を検証するように設計されています。 これを行うには、ツールが入力として期待される構成を受け取り、クラスター内の各サーバーをテストします。 このセクションでは、Validate-DCB ツールをインストールして実行し、結果を確認し、ツールが識別するネットワーク エラーを解決する方法について説明します。

Note

Microsoftでは、Network ATC を使用して構成を展開および管理することをお勧めします。これにより、Validate-DCB ツールで確認される構成の課題のほとんどが排除されます。 ネットワークの展開をホストするための意図ベースのアプローチを提供するネットワーク ATC の詳細については、「 ネットワーク ATC を使用したホスト ネットワークの簡略化」を参照してください。

ネットワーク上では、コンバージド イーサネット (RoCE) 経由のリモート ダイレクト メモリ アクセス (RDMA) では、ネットワーク ファブリックをロスレスにするために DCB テクノロジが必要です。 iWARP では、DCB は省略可能です。 ただし、DCB の構成は複雑になる可能性があります。次の場合は、正確な構成が必要です。

• クラスター内の各サーバー
• RDMA トラフィックがファブリックで通過する各ネットワーク ポート

Prerequisites

• 検証するサーバー クラスターのネットワーク セットアップ情報を次に示します。
  • ホストまたはサーバー クラスター名
  • 仮想スイッチの名前
  • ネットワーク アダプター名
  • 優先度フロー制御 (PFC) と拡張伝送選択 (ETS) の設定
• Microsoftから Windows PowerShell でツール モジュールをダウンロードするためのインターネット接続。

Validate-DCB ツールをインストールして実行する

Validate-DCB ツールをインストールして実行するには:

1. 管理 PC で、管理者として Windows PowerShell セッションを開き、次のコマンドを使用してツールをインストールします。

   Install-Module Validate-DCB
   

2. NuGet プロバイダーを使用する要求を受け入れ、リポジトリにアクセスしてツールをインストールします。

3. PowerShell がMicrosoft ネットワークに接続してツールをダウンロードしたら、「Validate-DCB」と入力し、Enter キーを押してツール ウィザードを開始します。

   Note

   Validate-DCB ツール スクリプトを実行できない場合は、PowerShell 実行ポリシーの調整が必要になることがあります。 Get-ExecutionPolicy コマンドレットを使用して、現在のスクリプト実行ポリシー設定を表示します。 PowerShell での実行ポリシーの設定については、「 実行ポリシーについて」を参照してください。

4. [Validate-DCB 構成ウィザードへようこそ] ページで、[ 次へ] を選択します。

5. [クラスターとノード] ページで、検証するサーバー クラスターの名前を入力し、[ 解決 ] を選択してページに一覧表示し、[ 次へ] を選択します。

   

6. [アダプター] ページで、次の手順を実行します。

   1. vSwitch 添付チェックボックスを選択し、vSwitch の名前を入力します。
   2. [ アダプター名] に、各物理 NIC の名前、 ホスト vNIC 名、各仮想 NIC (vNIC) の名前、および VLAN の下の各アダプターで使用されている VLAN ID を入力します。
   3. [RDMA の種類] ドロップダウン リスト ボックスを展開し、適切なプロトコル (RoCE または iWARP) を選択します。 また、 ジャンボ フレーム をネットワークに適した値に設定し、[ 次へ] を選択します。

   

   Note

   • SR-IOV でネットワーク パフォーマンスを向上させる方法の詳細については、「 単一ルート I/O 仮想化の概要 (SR-IOV)」を参照してください。

7. [データ センター ブリッジ] ページで、 優先度、 ポリシー名、帯域幅 予約に関する組織の設定に合わせて値を変更し、[ 次へ] を選択します。

   

   Note

   前のウィザード ページで RdMA over RoCE を選択するには、すべての NIC とスイッチポートでネットワークの信頼性を確保するために DCB が必要です。

8. [保存して展開] ページの [構成ファイルパス ] ボックスで、 .ps1 拡張子を使用して構成ファイルを後で使用できる場所に保存し、[ エクスポート ] を選択して Validate-DCB ツールの実行を開始します。

   • 必要に応じて、ページの [Deploy Configuration to Nodes]\(構成をノードにデプロイする\) セクションを完了することで、構成ファイルをデプロイできます。これには、Azure Automation アカウントを使用して構成をデプロイし、検証する機能が含まれます。 Azure Automationの使用を開始するには、「Azure Automation アカウントを作成する」を参照してください。

   

結果を確認してエラーを修正する

Validate-DCB ツールでは、次の 2 つの単位で結果が生成されます。

1. [グローバル ユニット] 結果には、モーダル テストを実行するための前提条件と要件が一覧表示されます。
2. [モーダル ユニット] の結果は、各クラスター ホストの構成とベスト プラクティスに関するフィードバックを提供します。

この例では、失敗数が 0 であることを示すことによって、すべての前提条件とモーダル単体テストに対する単一サーバーのスキャン結果が成功したことを示します。

次の手順では、vNIC SMB02 からジャンボ パケット エラーを特定して修正する方法を示します。

1. Validate-DCB ツール スキャンの結果は、失敗したカウント エラー 1 を示します。

   

2. 結果をスクロールすると赤でエラーが表示され、ホスト S046036の vNIC SMB02 のジャンボ パケットは既定のサイズ 1514 に設定されていますが、9014 に設定する必要があります。

   

3. ホスト S046036上の vNIC SMB02 の 高度な プロパティを確認すると、ジャンボ パケットが既定の 無効に設定されていることが示されます。

   

4. エラーを修正するには、ジャンボ パケット機能を有効にし、そのサイズを 9014 バイトに変更する必要があります。 ホスト S046036でスキャンを再度実行すると、失敗したカウント 0 が返され、この変更が確認されます。

   

Validate-DCB ツールで識別されるエラーの解決の詳細については、次のビデオを参照してください。

ツールをオフラインでインストールすることもできます。 切断されたシステムの場合は、 Save-Module -Name Validate-DCB -Path c:\temp\Validate-DCB を使用し、c:\temp\Validate-DCB のモジュールを切断されたシステムに移動します。 詳細については、次のビデオをご覧ください。

クラスターを検証する

次の手順を使用して、Windows Admin Center内の既存のクラスター内のサーバーを検証します。

1. Windows Admin Centerで、[すべての接続] で、検証する Azure Stack HCI クラスターを選択し、[接続] を選択します。

   クラスター マネージャー ダッシュボードには、クラスターに関する概要情報が表示されます。

2. クラスター マネージャー ダッシュボードの [ツール] で、[サーバー] を選択します。

3. [ インベントリ ] ページで、クラスター内のサーバーを選択し、[ その他 ] サブメニューを展開し、[ クラスターの検証] を選択します。

4. [ クラスターの検証 ] ポップアップ ウィンドウで、[ はい] を選択します。

   

5. 資格情報 セキュリティ サービス プロバイダー (CredSSP) ポップアップ ウィンドウで、[ はい] を選択します。

6. 資格情報を入力して CredSSP を有効にし、[ 続行] を選択します。
   クラスターの検証はバックグラウンドで実行され、完了すると通知が表示されます。その時点で、次のセクションで説明するように、検証レポートを表示できます。

Note

クラスター サーバーが検証されたら、セキュリティ上の理由から CredSSP を無効にする必要があります。

CredSSP を無効にする

サーバー クラスターが正常に検証されたら、セキュリティのために各サーバーで資格情報セキュリティ サポート プロバイダー (CredSSP) プロトコルを無効にする必要があります。 詳細については、 CVE-2018-0886 を参照してください。

1. Windows Admin Centerで、[すべての接続] でクラスター内の最初のサーバーを選択し、[接続] を選択します。

2. [ 概要 ] ページで 、[ CredSSP の無効化] を選択し、[ CredSSP の無効化 ] ポップアップ ウィンドウで [ はい] を選択します。

   手順 2 の結果は、サーバーの [概要] ページの上部にある赤い CredSSP ENABLED バナーを削除し、他のサーバーで CredSSP を無効にします。

検証レポートを表示する

これで、クラスター検証レポートを表示する準備ができました。

検証レポートにアクセスするには、次の 2 つの方法があります。

• [ インベントリ ] ページで、[ その他 ] サブメニューを展開し、[ 検証レポートの表示] を選択します。

• Windows Admin Centerの右上にある通知ベル アイコンを選択して、[通知] ウィンドウを表示します。 [ 正常に検証されたクラスターに関 する通知] を選択し、[ フェールオーバー クラスター検証レポートに移動] を選択します。

Note

サーバー クラスターの検証プロセスが完了するまでに時間がかかる場合があります。 プロセスの実行中に、Windows Admin Center内の別のツールに切り替えないでください。 [ 通知 ] ウィンドウの [ クラスターの検証 ] 通知の下にあるステータス バーは、プロセスが完了したタイミングを示します。

PowerShell を使用してクラスターを検証する

Windows PowerShell を使用して、サーバー クラスターで検証テストを実行し、結果を表示することもできます。 テストは、クラスターを設定する前と後の両方で実行できます。

サーバー クラスターで検証テストを実行するには、管理 PC から Get-Cluster および Test-Cluster<server clustername> PowerShell コマンドレットを発行するか、クラスターで 直接 Test-Cluster コマンドレットのみを実行します。

$Cluster = Get-Cluster -Name 'server-cluster1'
Test-Cluster -InputObject $Cluster -Verbose

詳細な例と使用方法については、 Test-Cluster のリファレンス ドキュメントを参照してください。

Test-NetStack は、ネットワークの ICMP、TCP、RDMA トラフィック テストを実行し、ネットワーク ファブリックとホストの構成ミスや運用が不安定になる可能性を特定するために使用できる、GitHubから利用できる PowerShell ベースのテスト ツールです。 Test-NetStack を使用して、ネイティブ、合成、ハードウェア オフロード (RDMA) のネットワーク データ パスをテストして、接続、パケット断片化、低スループット、輻輳に関する問題を検証します。

ストレージ レプリカのレプリケーションを検証する

記憶域レプリカを使用してストレッチ クラスターまたはクラスター間でボリュームをレプリケートする場合、レプリケーションの状態を取得するために使用できるイベントとコマンドレットがいくつかあります。

次のシナリオでは、2 つのサイトのレプリケーション グループ (NSG) を作成して記憶域レプリカを構成し、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

または、レプリカの宛先サーバー グループは、常にコピーする残りのバイト数を示し、 Get-SRGroupを使用して PowerShell を使用してクエリを実行できます。 例えば次が挙げられます。

(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 は、Microsoft に自社のインストール環境のレビューを依頼したいお客様向けに提供される Premier サービスです。 詳細については、Microsoft Premier サポートにお問い合わせください。 詳細については、「Windows Server オンデマンド評価の概要 (サーバー、セキュリティ、Hyper-V、フェールオーバー クラスター、IIS)」を参照してください。