web-dev-qa-db-ja.com

50台のSuperMicroマシンでのBSOD0x09c

プロジェクトの場合、50台のサーバーすべてに(通常は)同じハードウェアが装備されています。ここで発生する問題は非常に深刻で、すべてのマシンで発生します。多くの努力と製造業者とソフトウェア開発者への連絡にもかかわらず、誰もがお互いを指摘し、何が起こっているのかについての手がかりを私に与えることさえ拒否します。

まず、セットアップについて説明します。これは「サーバーグレード」のハードウェアです。私の最初の経験では、servergradeは私の人生で最大の失望です。

  • SuperMicro X10SDV-8C + -LN2F
  • Intel Xeon D-1540(マザーボードに組み込まれています)
  • カスタムデザインの1UケースまたはSuperMicroオリジナルケース
  • 480ワットのサーバーPSUまたは200ワットのSuperMicroオリジナルPSU
  • サムスンエボ850500GB SSD
  • 32 GB DDR4-2133 ECCまたはNON-ECC(ただし、同じサーバーに混在していない)
  • Asus GT730 4GB DDR3 GPU
  • GPUにはPCIeライザーカード(リボンではない)が搭載されており、中国やSuperMicroオリジナルの名前はありません

システム上で実行中-WindowsServer 2012 R2 Enterprise-VMWare Workstation 12-VMがGPUを集中的に実行するタスク-このシステムは在庫があり、オーバークロック/アンダークロックはまったくありません

症状-ランダムBSOD0x09c(別名Machine_Check_Exception):システムが問題なく1週間実行されることもあれば、わずか10分後にクラッシュすることもありますが、ほとんどの場合、数時間実行されます。

すでに試行/チェック済み:

  • BIOSが最新バージョンに更新されました(これにより、システムが安定するまでの時間が改善されたと思いますが、それはランダムであった可能性があります)。
  • Windowsが最新バージョンに更新されました。
  • VMWareが最新バージョンに更新されました。
  • すべてのコンポーネントを交換し、デスクトップATX PSUおよびM.2SSDを試した場合でも、すべての異なるオプションを試しました。
  • Ubuntuですべてのシステムを最初からインストールしました。私はLinuxに精通しておらず、Linux BSODを見たことがありません。サーバーシステムがヘッドレスであるため、まだ見ていません。DCでこれを試しました。結果:システムがハングし、再起動後にLinuxがXORGクラッシュ(GPU関連)を報告しました。
  • BIOSのGPU設定を「Above4G」に変更しました。残りのBIOSは工場出荷時のデフォルトです。

また有益:

  • システムはデータセンターにあります。温度、空気、電力、ネットワークが最適です。
  • 温度は工場の最高気温をはるかに下回っています
  • まったく同じソフトウェアセットアップがデスクトップコンピューター(デスクトップハードウェアを使用)で実行されています。これらのシステムは、毎月100台のPCのうち1台がクラッシュしても正常に動作します。
  • VMWareに連絡しましたが、これはハードウェアの問題だと言っています
  • 私はSuperMicroに連絡しました、彼らはいくつかのことを除いて実際には何も言わず、すでに試みました、そしてまたこれはまだソフトウェアの問題である可能性があります。

私たちはここで必死です。幸運にも実行しているアプリケーションは、一種の冗長です。サーバーとそのVMがドロップした場合、それはそのような問題ではありません。他のサーバーが5分以内に負荷を引き継ぎますが、このレートでは、サーバーを再起動するために1日中オンラインである必要があります。

私はハードウェアに関する幅広い知識を持っていますが、これはそれを超えています。私はこれを1か月以上にわたって一日中検索し、さまざまなことを試してきました。これらのマザーボードがホスティングプロバイダーで大規模に使用されているという事実は、ボード自体に問題がないことを私に疑わせます。 50枚のボードすべてに同じ症状があるため、これはRMAの特定のハードウェアの問題ではありません。私たちと違うのはGPUだけです。これをLinuxの実験と組み合わせると、これは間違いなくPCIeレーンにあるものだと思います。 GPU自体はデスクトップmoboで安定しています。大きなメモリ容量にもかかわらず、これはあまり電力を消費しない小さなGPUです。中国のライザーカードが疑われますが、SuperMicro認定のライザーも使用しており、まったく改善が見られません。

私はここで解決策を見つけることを非常に切望しています。これは、正確な原因を特定することから始まります。私たちは、いくつかのダンプを分析し、より多くの詳細(またはさらに良いことに、解決策)を提供できる専門家に素晴らしい報奨金を喜んで支払います。

敬具、

サイモン

8
user349749

さて、これは非常に遅いです、私は問題がこの時点で解決されていると思いますか?いずれにせよ、0x9Cは通常MCEハードウェア障害を意味します。GPUシステムはLinuxをホストOSとして実行し、Windowsよりも少し詳細にこれらのエラーを報告します。

とにかく、これらはしばらく前にHPによって作られた同様のハードウェア上でランダムにポップアップしていました、それはGPUへの不十分な電力供給で終わった。具体的には、PCIeポート自体によって供給されることになっている75W。

PCIeブレークアウトボード上のマルチメータで確認しました。 GPUと10Gbeネットワークカードの両方が同時に激しく打たれたときに電圧が低下しました。マザーボードはx16スロットに75Wを供給できましたが、他のカードがすべて電力を消費しているとき、電力供給セクションは少し苦労しました。

ここではライザーが疑われ、高電流負荷で電圧が低下している可能性があります。

2
TriadicTech

お返事をありがとうございます。 3年後の今です。 Supermicroはあらゆる方法で私たちを助けることを拒否しました。私たちは複数のマシンを送りました(私たちが作ったものとまったく同じです)。彼らによると、彼らは数週間ストレステストを行い、墜落することはありませんでした。

ライザーに関しては、スロットに直接あるGPUでも同じエラーが発生します。

SupermicroはVMWareに責任を負わせ続けています。これは、同じボードの新しいリリースを手に入れるまで、私が信じていたものです。 Supermicroからのコメントなしで、XeonD-1540を搭載したボードは数か月後にXeonD-1541でアップデートされました。新しいボードは、基本的に新しいCPUと同じです(クロック速度もわずかに高くなります)。更新されたボードには、追加のファンヘッダーも備わっています。

これらのボードはクラッシュしなくなりました。まったく同じ負荷で、問題なく数か月間実行されます。私はここでマシンのクローンを作成しました。それらはクラッシュしたマシンとまったく同じハードウェアとソフトウェアを実行します。

この種の私の疑いを確認します。 Supermicroはボードに問題があることを知っていますが、クラッシュのためにこれらのボードのほぼ100が役に立たなくなったので、理由を教えたくありません。彼らは決してRMAでなかったか、それに対するBIOSアップデートさえ修正しなかったので、それはボード上の何かであったに違いありません。

言うまでもなく、Supermicroを使ったのはこれが初めてで最後でした。これはもちろんどのブランドにも起こり得ますが、サポートはゼロ以下でした。

0
Simon Allais