自宅サーバが燃えた件

突然ですが

サーバが燃えました。

中央付近、メモリのVRM回路と思われる部分が焼損していることがおわかりいただけると思います。

状況

とある日の夜22時ごろ、突然室内の音が変わった気がして、サーバを確認すると、うち1台が停止しており、FaultのLEDが点灯しておりました。
HPのサーバでしたので、iLO4からログを確認すると、電源系のエラーが出ておりました。(スクショ忘れた)
PSU以上かと思った主は、PSU#1が接続された状態でPSU#2を接続してからPSU#1を交換するという方法を取り、サーバの電源を喪失することなくPSUの交換を行いました。
しかしながら、電源ボタンを押しても電源が入ることはなく、電源ケーブルを接続し直すことにしました。
電源ケーブルの再接続を終え、電源ボタンを押すと…

燃えた

はい、燃えました。

といっても目視で確認できていないですが、花火に火をつけたような音やスパークの飛ぶ音が1.5秒ほど続き、一瞬にして室内には半導体の燃える匂いでいっぱいに。
ヒートシンクがマザーボードを外さずに撤去することができなかったので直視できていませんが、半導体チップが溶けてぐちゃぐちゃになっていました。
チップ、半田ゴテとか当てても溶けませんから、相当の温度になっていたのでしょう。

原因は?

完全な原因究明には至っておりません。
考えられることとしては、前日に行ったUPSのマウント作業の際、レールのかみ合わせが悪く、スライドさせるたびにカンナで削ったような金属片が散乱してしまっていましたので、それを運悪くサーバが吸い込んでショートした、ということぐらいでしょうか。

そして、ショートを検知して電源が落ちたものの、主が一度電源を喪失させたためにエラーのステートが消え、エラーをディテクトする前にサーバの電源が入ってしまって燃えた、というところでしょうか。
だとすると、勝手に燃えることは無いはずです。
おそらく、燃える前に止まるでしょうから。

被害?

まず、このサーバ、コアサーバだったのですが当然死亡しました。(というか燃えてから電源入れてない)
稼働1ヶ月ほどでしたので、かなりダメージが大きいものです。
あと、燃えたVRM回路から電源供給を受けていたと思われるメモリが死亡しておりました。
これは廃棄。

まとめ?

5万ちょっとぐらいの被害は出ましたが、家が燃えなくてよかったです。
自宅でサーバ類を運用している方、突然にこのようなことも起こるようなので、お気をつけください。

Interop Tokyo 2019に行ってきました。

 

Interop Tokyo 2019 に行ってきましたので、軽くレポートとしてまとめます。
技術的な内容は一切無いのであしからず。

Interop Tokyoとは

Interop Tokyo(インターロプ・とうきょう)とは、首都圏における、ネットワーク・インフラストラクチャー技術、製品、またそれらを用いたソリューションサービスについての展示会である。
wikiより

まぁあれです。
最新のネットワーク機器等が展示される展示会です。
実際に機器を間近で見ることができます。

後は、ShowNetなどで行われている相互接続テストの様子や、ラックに入れられた機器が見どころの一つではあると思います。

行くことになったきっかけ

今回のInterop Tokyo 2019 への参加は、普段からお世話になっている教員からの提案によるものです。
技術系の展示会などはどうしても関東圏での開催が多く、関西圏の学生が参加することはどうしても難しいのが実情でした。
そんな中、サイオステクノロジー株式会社さんは、特に地方の技術系大学生に対して都市圏でのイベント参加を支援するプロジェクトを始めておられ、教員からの推薦もあって今回、交通費と宿泊費を支援していただけることになりました。

気になる人は支援プログラムのページをご覧ください。

1日目

昔、東京に住んでおりましたので、多少の土地勘はある状態で東京へ向かいました。
あまりInterop自体に関係のないことも書いておりますが、久々の東京でしたので地方学生の戯言だと思って見ていただけると幸いです。

東海道新幹線・京都駅構内で見つけたYAMAHAさんの広告です。

YAMAHAさんの広告は初めてみましたので、思わず撮ってしまいました。

せっかくですので、品川駅にて下車しサイオスさんの中の人に食事へ連れて行ってもらいました。
その中で、今自身が取り組んでいることについてや、最近の学生の動向、後は雑談で、1時間ほどお話をさせていただきました。
もちろん、就活とかは全く関係ありませんので、気軽にお話をさせていただくことができました。

その後は、知り合いと会ったり、プチ東京観光を満喫しました。

幕張へ

山手線で東京駅へと向かい、京葉線へ。
東京駅から京葉線ホームへの距離が長くて焦りました。

京葉線へ乗車し、快速で30分程で海浜幕張駅へと。

1日目は、海浜幕張駅付近のホテルへ滞在し、翌13日にInteropへ行くこととしました。

いざ、Interopへ!

ホテルを出て道中、ちょうど通勤時間帯だったためか、同じ方向へ向かう方が非常に多いように感じました。
案内標識を見つつ会場へ。
方向音痴ではないため、迷子になったとかはありませんので期待しないでください笑

展示場付近にInteropとAWS Summitの広告がありました。

今回は、InteropとAWS Summitが同時開催されていたようで、双方の広告がありました。

受付の様子です。
AWS Summitと同時開催だったため、AWS Summitと併設して設置されておりました。

見たところ

このような技術系の展示会に参加するのは初めてでしたので、どんなふうに回っていいか分からず、まずはどんなところが出展しているかを見て回ることにしました。

まず、入ってすぐにあったのがSHOWNET。
(写真の角度が最悪で…)

トポロジー

SHOWNETツアーとして、説明員の方が説明しておりました。

今回のSHOWNETの見どころとしては、やはり400GbEによる相互接続テストだったのではないでしょうか。

 

(記録が雑すぎて400GbEのラックの写真か怪しいです…)

サービスチェイニングとSRv6。

 そして、公開されていたラックの裏側。

世界中の400GbEのモジュールを集めて展示してありました。

Zabbixブース。

Mellanoxブース。

YAMAHAブース。

YAMAHAさんによると、ネットワーク機器を出していることをもっと周知していきたいとの意図があるようで、京都駅で見かけた広告もその広報の一環であったようです。

最後に

このような技術展・展示会に参加するのは初めてでしたので、どういったものが展示されているのか見るのが精一杯ではありましたが、最先端の技術に触れることができ、また、参加しなければ知り得なかった情報、技術などを知ることができました。
また、自身の目標として様々なことを考えさせられるきっかけともなりました。
今回、Interopに参加する機会を与えてくださったサイオステクノロジー株式会社さんに、この場を借りてお礼申し上げます。

FreeNASのNFSをProxmoxで利用したときのパフォーマンス

環境

  • FreeNAS
    • HDD WD RED 2TB x3 RAID-Z
    • NFS
    • sync=disable
  • Proxmox
    • Windows10をインストール済み
  • Network
    • 10GbE

症状

ProxmoxからFreeNASへNFSで接続し、Windowsを入れる。
このとき、Proxmox側のディスクドライブはIDE0
この状態でCrystalDiskMarkをかけた結果が以下

HDDはWD REDだし、RAID-Zとはいえ、Read/Writeともにほぼ同じ速度で頭打ちなのはおかしい。
FreeNAS側でも、CPUやメモリが張り付く様子もなく、他のNFSで同じように測定されている方の結果からも、FreeNAS側の問題ではないと判断。

作業

結論から言うと、Proxmox上のWindowsのディスクを、IDE0からSCSI0にした。
この辺は、VirtIOのドライバを入れたりしないといけないので、別途作業が必要。
これがちょっと面倒である。

結果

Proxmox上のWindowsのディスクをSCSI0にして、再度CrystalDiskMarkで計測した結果が以下である。

めちゃめちゃ早くなった。

Readに関しては、CrystalDiskMarkの性質上、テスト前に書き込んだテスト用データがFreeNASのNFSボリューム上のキャッシュにあり、キャッシュから読み出したものだと思われる。
しかしながら、Writeに関しては、ディスクから直接読み込んでいると思われる数値が出ている。
結果として大幅な速度向上に成功した。

余談

これはあくまでも推察なので、事実と異なるかもしれないが、CrystalDiskMarkがディスクのベンチマークを行う際、以下の順序で実行されているように思う。

  • 1,テスト用データを書き込み(Prepare)
  • 2,テスト用データを読み込む(ReadTest)
  • 3,テスト用データを書き込み(WriteTest)
  • 4,残ったゴミを削除

この手順だと、テストデータを2回書き込む必要があると考えられる。
以下の処理順序にすれば、効率よくベンチマークが行えないだろうか?

  • 1,テスト用データを書き込み(WriteTest)
  • 2,テスト用データを読み込む(ReadTest)
  • 3,残ったゴミを削除

この順序だと、書き込みや読み込み処理が1度で済むと考えられる。
当然、何か理由があって、現状の処理順序になっていると考えられるが、それが自身には分からないので、誰かご教示願いたい。