Azure Stack HCI クラスターの検証

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

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 ツールをインストールして実行するには:

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

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

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

    Note

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

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

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

    Validate-DCB 構成ウィザードの [Clusters and Nodes]\(クラスターとノード\) ページ

  6. [Adapters](アダプター) ページで、次のようにします。

    1. [vSwitch attached](接続されている vSwitch) チェック ボックスをオンにして、vSwitch の名前を入力します。
    2. [Adapter Name](アダプター名) に各物理 NIC の名前を入力し、 [Host vNIC Name](ホスト vNIC 名) に各仮想 NIC (vNIC) の名前を入力し、 [VLAN] に各アダプターで使用されている VLAN ID を入力します。
    3. [RDMA Type](RDMA の種類) ドロップダウンの一覧を展開して、適切なプロトコルを選択します: [RoCE] または [iWARP] 。 また、 [Jumbo Frames](ジャンボ フレーム) をネットワークに対する適切な値に設定し、 [次へ] を選択します。

    Validate-DCB 構成ウィザードの [Adapters]\(アダプター\) ページ

    Note

  7. [Data Center Bridging](データ センター ブリッジング) ページで、 [Priority](優先順位)[Policy Name](ポリシー名)[Bandwidth Reservation](帯域幅予約) の値を組織の設定と一致するように変更して、 [次へ] を選択します。

    Validate-DCB 構成ウィザードの [Data Center Bridging]\(データ センター ブリッジング\) ページ

    Note

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

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

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

    Validate-DCB 構成ウィザードの [Save and Deploy]\(保存とデプロイ\) ページ

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

Validate-DCB ツールにより、2 つのユニットで結果が生成されます。

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

この例では、失敗カウントが 0 なので、すべての前提条件とモーダルのユニットのテストで、単一サーバーのスキャン結果が成功であったことが示されています。

Validate-DCB のグローバル ユニットとモーダル ユニットのテストの結果

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

  1. Validate-DCB ツール スキャンの結果では、失敗カウントで 1 つのエラーが示されています。

    失敗カウントで 1 つのエラーが示されている Validate-DCB ツールのスキャン結果

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

    ジャンボ パケット サイズの設定エラーが示されている Validate-DCB ツールのスキャン結果

  3. ホスト S046036 の vNIC SMB02 の [詳細設定] プロパティを確認すると、ジャンボ パケットが既定の [無効] に設定されていることがわかります。

    サーバー ホストの Hyper-V の [詳細設定] プロパティでのジャンボ パケットの設定

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

    サーバー ホストのジャンボ パケット設定が修正されたことを確認する Validate-DCB スキャンの結果

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. [Credential Security Service Provider (CredSSP)] ポップアップ ウィンドウで、 [はい] を選択します。

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

Note

クラスター サーバーの検証が済んだら、セキュリティのため CredSSP を無効にする必要があります。

CredSSP を無効にする

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

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

  2. [概要] ページで [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-SRGroupGet-SRPartnership を使用します。

Get-SRGroup -Cluster ClusterS1
Get-SRPartnership -Cluster ClusterS1
(Get-SRGroup).replicas -Cluster ClusterS1

サイト間でデータが正常にレプリケートされたことを確認したら、VM と他のワークロードを作成できます。

関連項目