次の方法で共有


システム サーバーのテストのトラブルシューティング

Windows Hardware Lab Kit (Windows HLK) System.Server テストで発生する問題をトラブルシューティングするには、この記事で説明されている手順に従います。

この記事の内容:

一般的なシステム サーバーのトラブルシューティング

  1. サーバー テストのヘルプについては、以下のトピックを参照してください。

  2. サーバーのデバイスとドライバーのテストでは、テスト対象のシステム (SUT: System Under Test) が次のように構成されていることを確認します。

    • 正しいバージョンの Windows がインストールされている。

    • Server Core オプションがインストールされている。

    • SUT に少なくとも 4 つのコアまたは論理プロセッサがある。

    • SUT に少なくとも 6 GB の RAM がインストールされている。

    • ストレージ デバイスのテストでは、ストレージ デバイスがブート デバイスである場合、ストレージ ドライブがある 2 つのデバイス インスタンスが必要になる場合があります。

  3. Windows HLK Studio でターゲットをプロジェクトに追加できなかったというエラーが発生した場合は、ターゲットを再選択し、Windows HLK Studio を終了してから、Windows HLK Studio を再起動してください。 このエラーは、データが更新されていないことを意味しています。

  4. Sysparse プロセスは、Gatherer DLL を直接実行します。 2 つ目のプロセスである Asset Configuration Manager Engine (ACME) は、ハードウェアの変更を監視し、1 つ以上のハードウェア変更が発生した場合にシステムに警告します。 ACME は、タイムアウトが発生するか、頻繁なハードウェア変更レポートが停止するまで待機してから、登録された Gatherer を開始します。

    一部のテストでは、テストの実行中にハードウェアの変更が行われます。 これにより、Sysparse が定期的に実行されます。 Sysparse は大量のメモリを消費する可能性があります。これは、Gatherer が実行され、データを収集しているためです。 ほとんどの場合、テストではパフォーマンスが検証されないため、Sysparse はテストに影響しないはずです。

  5. Windows HLK Controller がインストールされているシステムに、テストの要求を満たすために十分なハードウェア機能があることを確認します。 これらのハードウェア要件の説明については、「Windows HLK の前提条件」を参照してください。 テストするデバイスとシステムの数が増えるのに応じて、プロセッサ、メモリ、またはストレージを追加する必要がある場合があります。

失敗したシステム サーバー テストのトラブルシューティング

テストが失敗した場合は、これらの手順に従います。

  1. テストの開始から数分以内にエラーが発生した場合は、通常、何かが正しく構成されていないことを意味します。 テスト環境の設定を再確認してください。

  2. テストが実行された場合は、Windows HLK Controller 内に Srvlog.xml というログ ファイルがあるはずです。 次の手順のようにします。

    1. Windows HLK Studio で、ジョブ モニターを開きます。

    2. スケジュールされたテストのマシン プールを参照します。

    3. [ジョブ実行状態] ペインで、[Loadgen サーバー ストレス - サーバー用のテスト開始] を選択します。

    4. [Task Execution Status] (タスク実行状態) ペインで [RunJob -Launch Server Logo Kit] (RunJob - サーバー ロゴ キットの起動) を右クリックし、[Child Job Result] (子ジョブの結果) を選択します。

    5. [ジョブ実行状態] ペインに戻って、[Launch Server Logo Kit] (サーバー ロゴ キットの起動) を選択します。

    6. [Task Execution Status] (タスク実行状態) ペインで [Start LogGen task] (LogGen タスクの開始) を右クリックし、[View Task Log] (タスク ログの表示) を選択します。 ログは元の Loadgen ログから解析され、エラーとパスだけが含まれます。

    7. 元の Loadgen テキスト ログを取得するには、手順 1. から 5. を繰り返してから、[Launch Server Logo Kit] (サーバー ロゴ キットの起動) を右クリックし、[Browse Job Logs] (ジョブ ログの参照) を選択します。 これで、Windows HLK Controller 上のログ共有が開かれます。Loadgen ログ ファイルの srv.log は、この共有にあります。

    8. srv.log ファイルをメモ帳にドラッグ アンド ドロップします。

    9. メモ帳で、ファイルの一番下までスクロールします。

    10. 下から上に向かって、文字列 "Error -" を検索します。 同じ行のテキストに、エラーが記述されています。 エラーの原因を見つけるには、数回検索しなければならない場合があります。 ログ ファイル内の情報では、何が失敗したかについての高レベルの指標のみが提供されます。

Loadgen がより多くのクライアントを要求する

既存のクライアントが SUT に対して十分なストレスを生成できない場合、Loadgen によってより多くのストレス クライアント (SC) が求められます。 この機能は、大規模なサーバーに対応し、一部の SC が実行の途中で失敗する可能性に対処するためのものです。 一般に、8 個の SC から始めるのが適しています。 ストレス レベルは、テストの最初の 3 時間から 4 時間で安定するはずです。 さらに多くのクライアントが必要な場合は、通常、その時間枠内にマスター コントローラー (MC) にポップアップが表示されます。 新しいクライアントを追加できるのは、60 分以内です。追加できなかった場合、テストが終了して失敗します。

Note

申請の開始後、マシン プールにマシンを追加することはできません。 8 個未満のクライアントを使用してテストを開始する場合は、テストを開始する前に、マシン プールに追加のクライアントがあることを確認してください。

4 時間のテストの後、Loadgen によってさらに多くのクライアントが要求される場合は、何かが失敗した可能性があります。 1 つ以上の既存のクライアントがドロップアウトしたか、ネットワーク接続の問題が発生したか、または別の問題によって、必要な 40% の使用率の負荷を SUT が検知できません。 これは、NIC ドライバーとネットワーク速度の組み合わせの問題、または Loadgen MC が依存するパフォーマンス モニター カウンターに対するドライバーの実装の問題である可能性があります。

この場合は、次のトラブルシューティング手順を試してください。

  1. NIC での一時的なハードウェア障害を除外するには、同じモデルと製造元である別の NIC を使用します。

  2. 同じ製造元の別のモデルの NIC を使用します。ただし、同じドライバーを使用するモデルにします。

  3. 別の製造元の NIC とドライバーを使用します。

  4. 1 つ以上の NIC がシステム ボードに直接インストールされている場合は、ハードウェア システムの設定にアクセスし、そのレベルの NIC を無効にして、Windows によって検出されないようしてから、テストに別のデバイスとドライバーを使用します。

  5. 複数の NIC がシステム ボードに直接インストールされ、PCI Express スロットに追加のデバイスをインストールできない場合は、ハードウェア システムの設定にアクセスし、1 つを除くすべての NIC を無効にして、Windows によってデバイスが検出されないようにします。

Note

検出された各 NIC は、テスト中にストレスを掛けられる必要があります。 そのためには、各 NIC に個別の物理ネットワーク セグメント上の SC が必要です。

高度な機能が組み込まれているスイッチは、さまざまな方法でテストに干渉する可能性があります。 次に例を示します。

  • スイッチは、1 つのポートでドロップされたパケットまたは他のエラーを検出した場合に、スイッチ内のポートの速度を落とすことができる機能がある場合があります。 SUT 上の 10GigE NIC が、すべてのポートの速度が 1 GigE に低下した結果として発生するトラフィックを受信することを意図している場合、Loadgen テストは、テストに合格するために必要な 40% のネットワーク帯域幅使用率レベルに到達できません。

  • スイッチは、スイッチの内部的なルールやロジック (負荷分散、冗長性、サービス品質 (QoS)、ミラーリング、双方向と 一方向の操作、アダプティブまたはインテリジェントなブリッジング、ポートの優先順位付け、MAC フィルタリングなど) に応じて、トラフィックのルーティングやネットワークのセグメント化を行うことができます。このことは、NIC でのネットワーク帯域幅使用率レベルに影響を与える可能性があります。

Error=0x80004005

Main::RunMain:: Test Check Spsrv が停止し、要求された合格率 (100) に達しなかった (Error=0x80004005) というエラーが表示される場合があります。 この場合は、次の手順を実行します。

  1. Windows HLK Studio を閉じます。

  2. SUT コンピューター名を 15 文字以下に変更します。

  3. SUT を再起動します。

  4. Windows HLK Studio を開き、LoadGen Server Stress - Start Test for Server テストを再実行します。

サーバー ストレス テスト

サーバー ストレス テストを実行する場合は、SUT を SC および MC に接続するネットワーク インフラストラクチャが SUT のネットワーク インターフェイス カード (NIC) のレベルで動作できることを確認します。 SUT に 1 つ以上の 10GigE NIC がある場合、SC とネットワーク インフラストラクチャは、そのレベルのパフォーマンスを実現できる必要があります。

DHCP、DNS、Active Directory、Windows HLK Controller、Windows HLK Studio、SUT、SC、および MC を接続するネットワーク インフラストラクチャが正しく動作していることを確認します。 すべてのシステムが、ホスト名または IP アドレスを使用して相互に通信する必要があります。 これは、単純な ping テストを使用して確認できます。

DHCP、DNS、Active Directory サーバーが正しく機能することを確認します。 古くなった DNS レコードが存在しないようにする必要があります。 DHCP サーバーがネットワーク上で動作することを承認されている必要があります。構成が正しいこと、DHCP スコープが正しいこと、正しくないマルチホーミングがないこと、および DHCP システム イベント ログにエラーがないことが必要です。 Active Directory ドメイン コントローラーからのレポートにエラーがなく、すべてのシステム間でタイム サービスが同期されている必要があります。

テスト環境での仮想マシン (VM) の使用

DHCP、DNS、AD、および VM 内のその他のシステムによる既知の問題はありません。 問題は、SC を VM で実行することによって発生することがあります。 これらの問題は、通常、ネットワーク帯域幅の負荷の生成に関連しています。 問題を回避するには、以下の構成が設定されていることを確認してください。

  • 各 SC VM には、SUT NIC に接続されているネットワークに負荷を掛ける専用の物理 NIC がある必要があります。

  • 少なくとも、SUT NIC の最大帯域幅の 2 倍以上に対応できる SC VM に関連付けられている物理 NIC がなければなりません。

  • SC VM に使用されている物理システムが、高レベルの CPU 使用率によってストレス過剰になっていないことと、すべての VM に十分な物理メモリがあることを確認してください。

システム サーバーのテスト