AMD EPYC Processor で2U本格水冷サーバを組んでみた。

事の発端

巷で話題になっていた Rosetta@Home の方を自宅ラック内の設備の一部を使用して動かしておりましたが、当然CPUを使い切るわけですから、それなりに電力を消費することになります。
Haswell世代のXeon E5 プロセッサを始めとして、100スレッド超えの計算能力を突っ込んでいました。
(一時期、Rosetta@Homeにおいて国内2位の計算能力を提供していました。)
しかしながら、それだけ電力使用量も増えるもので、Haswell世代のXeon E5 プロセッサを2基(計24コア48スレッド)積んだマシンを動かすと、それだけで400W近い電力を消費していました。
それ以外にも多くのマシンを動かしていましたから、1.5KWh近い電力を消費していたように思います。
(流石にここまで来ると、部屋が暑くなります。まだ4月でしたので、窓を開けてちょうどいい感じでした。)
自宅ラック勢の中では、比較的新しいマシンが多い弊宅(当社調べ)ですが、それでも計算能力に対して電力効率が、決していいとは言えないことが気になってきます。
ここまで来ると、より良いものが欲しくなるのが人の性。
AMD EPYC プロセッサ、中でもZen2アーキテクチャを採用したRomeに目をつけました。

構成を考える

まず、筐体(ケース)ですが、弊宅の36Uサイズの19インチサーバーラックへインストールするため、2Uサイズのラックケースを選択しました。
そうすると、高さが80mm程度を低いため、市販品のCPUクーラーは入らなくなります。
当然、サーバー向けプロセッサですから、2Uサイズの空冷CPUクーラーも存在します。
しかしながら、TDPが150Wを超えるようなプロセッサを2Uサイズに収まるような小さな空冷CPUクーラーで冷却したところで、冷却能力を高めるためにファンが高速回転しうるさくなるか、ファンの回転数を落としたために冷却不足になるなど、冷却や音の問題が出てきます。
弊宅はワンルームですから寝室を兼ねていますし、極力音は小さくしたいものです。
そこで、思い切って水冷にしてみることにしました。
クーラントによって熱を移動させ、2Uサイズの空冷クーラーよりは大きな断面積を確保したラジエータによって冷却するのです。
本格水冷自体始めてで、どの程度冷却できるか、静音性等は未知数でしたが、チャレンジしてみることとしました。

懸念事項

水冷にするということは、当然液体を用いますから、空冷CPUクーラーに比べて、より頻度の高い定期的なメンテナンスが必要となります。
今回は、そのリスクを頭の片隅に置いた上で、本格水冷を採用することとしました。

パーツ

詳細
CPU AMD EPYC 7452 32Core Processor
M/B Supermicro H11SSL-i (要Rev2.0)
Memory DDR4 ECC Registered 16GB x8 計128GB
PSU 80PLUS GOLD 定格500W ATX電源
Radiator Alphacool NexXxoS XT45 Full Copper 80mm (240mm length)
WaterBlock TR40用ブロック

M/B(マザーボード)については、Supermicro製のものを選択しました。
しかしながら、Rome世代のEPYC 7002シリーズには、rev2.0以降のものでないと対応しないとのことだったので、rev2.0以降のものを入手しています。
(どうもフラッシュチップの容量の関係みたいです)
Memoryについては、別マシンで使用予定で入手したものの使わなくなったものがあったので、それを利用することとしました。
ラジエータについても、2Uサイズに収まるものを選択しています。
また、EPYC プロセッサのソケットはSP3ですが、形状はTR4と同様です。(ピン互換性はありません)

組んでみた

まずはCPU、やはり大きいですね。

そして、組み込んだ図。

クーラントの色は、なんとなく赤にしてあります。
(リークテストの際に、漏れた場合ティッシュが着色されてわかりやすいかなぁと)

全体像は以下のようになりました。

下の方に転がっているWDのSSDはテスト用の物です。
また、ファンなども仮設置のものが多くて、全体的に散らかっていますがご容赦を。
特に漏れることもなく、組むことができています。

また、動作にも問題ありませんでした。

パフォーマンスは?水冷の効果は?

各ベンチマークや、水冷の効果の考察については、後日投稿する別記事にて記したいと思います。

BIOSでは認識しているがディスクの管理に表示されないSeagete製HDDがあるらしい

知り合いが、増設したHDDを認識しない現象に見舞われ、トラブルシューティングしたのでそのログです。
軽く調査を行ったところ、Seagate製のHDDにおいて稀に発生するようです。
原因調査中、思ったように情報にたどり着けなかったので、記しておきます。

予め申しておきますが、本記事はSeageteさんに対する批判等ではございません。

(解決方法が知りたい人は、この記事の下部へ)

  • 当該HDD
    • Seagete ST2000DM008

Windows10PCにHDDを増設するも認識しない!?

BIOS上には増設したHDDが表示され、Windows10上のデバイスマネージャー上でも、増設したHDDは認識されていました。
しかしながら、増設したHDDを使用するにはMBRないしはGPTのパーティションテーブルを作成する必要があります。
通常、Windows10ではこれらの操作はディスクの管理から行うこととなります。
しかし、肝心のディスクの管理には当該HDDは表示されていませんでした。

ちなみに、CrystalDiskInfoでは認識し、S.M.A.R.T.情報を読み取ることができる状態でした。
これは、接続ケーブルの不良やマザーボードの故障ではないことを意味します。

新品なのにHDD上になんか残っている…?

調べてゆくと、Windows10上で記憶域プールとして認識されたものは、ディスクの管理に表示されないことがわかります。
今回の症状に合致します。(そのような設定を行ったかどうかは別として…)

解決方法…?

そこで、Windows10上から記憶域プールの設定を確認します。
(設定へのたどり着き方は各自調べてください。 設定 から行く方法と、コントロールパネルから行く方法があります。)
本件の場合、他人のPCだったのでスクリーンショットがありませんがディスクの管理に表示されないディスクが、記憶域プールとして使用されていました。
すでに記憶域プールを利用している方は、操作を行うディスクを間違えないように注意しながら、この記憶域プールを削除します。

本件においては、以上の操作を行うことで、ディスクの管理上に表示されるようになりました。

*当該操作等を行ったことによるデータの喪失その他について、当記事の筆者は何ら責任を負いません。

原因は?

本症状は稀に発生することが多いようで、大抵の場合返品交換をしてもらうことで解決しているようです。
また、その殆どがSeagate製のHDDにおいて発生していました。
Seageteさんが製造時あるいは検品等を行う際に何らかの問題が発生することがまれにあるのでしょう。
今回のトラブルは、ある意味不良品であり、返品交換をしてもらうか、自身で操作を行うことによって回避できる問題と言えるでしょう。

ちなみにLinux系だと…

Win10等で認識しない場合、Linux系のOS(ubuntuなど)をUSBメモリからtryでブートして、fdisk等を利用して当該HDDのパーティションテーブルを初期化することでも解決することができるように思います。

CRS326-24S+2Q+RMでの40GbEのスループットをテストしてみた!

さて

およそ半年前、MikroTik社のCRS326-24S+2Q+RMを購入した記事を書きましたが、40GbEのテストは後でやると書きました。

ようやくそのテストを実施する(気になる)ことができたので、その結果を記していきたいと思います。

環境

本当はLinux機でテストしたかったのですが、ぱっと使えるマシンがWindowsしかなかったので、諦めてそちらでテストを行いました。

  • マシン1 (Desktop)
    • Windows10 Pro
    • Mellanox ConnectX-3 Pro EN
    • 6C12T
    • 16GB RAM
  • マシン2 (HPE DL380 Gen9)
    • Windows10 Pro
    • Mellanox ConnectX-3 Pro EN
    • 24C48T
    • 128GB RAM

なお、Desktop機においてはNICが冷却できずに燃えそうだったので、サーキュレータの風をぶち当てて強制冷却することにしました。

PC1 --- CRS326-24S+2Q+RM --- PC2

こんな構成でテストを行いました。
なお、IPアドレスについては別途DHCPサーバからの配布としました。

iperf3 with MTU 1500

$ ./iperf3.exe -c 192.168.5.111
Connecting to host 192.168.5.111, port 5201
[  4] local 192.168.5.110 port 51729 connected to 192.168.5.111 port 5201
[ ID] Interval           Transfer     Bandwidth
[  4]   0.00-1.00   sec  1.01 GBytes  8.71 Gbits/sec
[  4]   1.00-2.00   sec   963 MBytes  8.07 Gbits/sec
[  4]   2.00-3.00   sec   965 MBytes  8.09 Gbits/sec
[  4]   3.00-4.00   sec  1.06 GBytes  9.07 Gbits/sec
[  4]   4.00-5.00   sec  1.14 GBytes  9.76 Gbits/sec
[  4]   5.00-6.00   sec  1.13 GBytes  9.74 Gbits/sec
[  4]   6.00-7.00   sec  1.06 GBytes  9.10 Gbits/sec
[  4]   7.00-8.00   sec  1.10 GBytes  9.41 Gbits/sec
[  4]   8.00-9.00   sec  1018 MBytes  8.54 Gbits/sec
[  4]   9.00-10.00  sec  1.16 GBytes  9.99 Gbits/sec
ーーーーーーーーーーーーーーーーーーーーーーーーーーーーーー
[ ID] Interval           Transfer     Bandwidth
[  4]   0.00-10.00  sec  10.5 GBytes  9.05 Gbits/sec                  sender
[  4]   0.00-10.00  sec  10.5 GBytes  9.05 Gbits/sec                  receiver

iperf Done.

iperf3でテストを行ったのですが、10Gbps程度しか出ていませんね。
PCIe接続帯域を疑ったのですが、確認したところ双方PCIe3.0 x8で正しくリンクしているようです。

なお、調査したところ、iperf3では -P オプションをつけて並列で実行してもさほど効果がないようです。

ということで、iperf2で試してみることにしました。
なお、MTUを9000としました。

iperf2 with MTU 9000

$ ./iperf.exe -c 192.168.5.111
ーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーー
Client connecting to 192.168.5.111, TCP port 5001
TCP window size:  208 KByte (default)
ーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーー
[  3] local 192.168.5.110 port 52802 connected with 192.168.5.111 port 5001
[ ID] Interval       Transfer     Bandwidth
[  3]  0.0-10.0 sec  23.5 GBytes  20.2 Gbits/sec

20Gbpsほど出ていますね。
この差は何なのでしょうか…

iperf2 -P 10 with MTU 9000

$ ./iperf.exe -c 192.168.5.111 -P 10
ーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーー
Client connecting to 192.168.5.111, TCP port 5001
TCP window size:  208 KByte (default)
ーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーー
[ 11] local 192.168.5.110 port 52816 connected with 192.168.5.111 port 5001
[ 12] local 192.168.5.110 port 52817 connected with 192.168.5.111 port 5001
[  5] local 192.168.5.110 port 52810 connected with 192.168.5.111 port 5001
[ 10] local 192.168.5.110 port 52815 connected with 192.168.5.111 port 5001
[  9] local 192.168.5.110 port 52814 connected with 192.168.5.111 port 5001
[  3] local 192.168.5.110 port 52808 connected with 192.168.5.111 port 5001
[  6] local 192.168.5.110 port 52811 connected with 192.168.5.111 port 5001
[  4] local 192.168.5.110 port 52809 connected with 192.168.5.111 port 5001
[  7] local 192.168.5.110 port 52812 connected with 192.168.5.111 port 5001
[  8] local 192.168.5.110 port 52813 connected with 192.168.5.111 port 5001
[ ID] Interval       Transfer     Bandwidth
[ 11]  0.0-10.0 sec  3.97 GBytes  3.41 Gbits/sec
[ 12]  0.0-10.0 sec  2.63 GBytes  2.26 Gbits/sec
[  5]  0.0-10.0 sec  5.29 GBytes  4.55 Gbits/sec
[  9]  0.0-10.0 sec  6.19 GBytes  5.31 Gbits/sec
[  3]  0.0-10.0 sec  3.43 GBytes  2.95 Gbits/sec
[  6]  0.0-10.0 sec  6.10 GBytes  5.24 Gbits/sec
[  4]  0.0-10.0 sec  3.74 GBytes  3.21 Gbits/sec
[  7]  0.0-10.0 sec  5.74 GBytes  4.93 Gbits/sec
[  8]  0.0-10.0 sec  5.33 GBytes  4.58 Gbits/sec
[ 10]  0.0-10.2 sec  2.62 GBytes  2.20 Gbits/sec
[SUM]  0.0-10.2 sec  45.0 GBytes  37.8 Gbits/sec

-Pオプションを使用して10並列で実行した結果です。
最後の行、各並列での実行結果の合計が示されていますが、 37.8Gbits/sec となっています。
40GbEにおけるほぼ理論値が出ていることが確認できます。
はやい…

そして、NTTtcpというMicrosoftが公開しているツールがあるとのことだったので、そちらでもテストしてみることにしました。

NTTtcp with MTU 9000

送信側

$ ./NTttcp.exe -s -m 24,*,192.168.5.111 -t 30
Copyright Version 5.33
Network activity progressing...


Thread  Time(s) Throughput(KB/s) Avg B / Compl
======  ======= ================ =============
   0  30.016    152017.058   65536.000
   1  30.008    172660.091   65536.000
   2  30.000    195206.400   65536.000
   3  29.881    140094.910   65536.000
   4  29.680    164485.175   65536.000
   5  30.000    187421.867   65536.000
   6  30.000    206696.533   65536.000
   7  30.274    220114.422   65536.000
   8  30.000    143276.800   65536.000
   9  30.063    226766.457   65536.000
  10  30.004    176714.571   65536.000
  11  30.000    186645.333   65536.000
  12  30.008    168695.281   65536.000
  13  30.000    207208.533   65536.000
  14  30.000    211219.200   65536.000
  15  30.002    243292.580   65536.000
  16  29.759    247294.331   65536.000
  17  30.077    151723.643   65536.000
  18  29.992    194283.276   65536.000
  19  30.022    206172.007   65536.000
  20  30.000    127082.667   65536.000
  21  29.975    190990.092   65536.000
  22  29.987    196200.220   65536.000
  23  29.760    181253.763   65536.000


####  Totals:  ####


   Bytes(MEG)    realtime(s) Avg Frame Size Throughput(MB/s)
================ =========== ============== ================
  131681.000000  30.001   8194.436   4389.220


Throughput(Buffers/s) Cycles/Byte       Buffers
===================== =========== =============
     70227.526     2.130   2106896.000


DPCs(count/s) Pkts(num/DPC)   Intr(count/s) Pkts(num/intr)
============= ============= =============== ==============
  100731.942   1.033  179893.237   0.578


Packets Sent Packets Received Retransmits Errors Avg. CPU %
============ ================ =========== ====== ==========
  16850158    3120561     64737   0    24.066

受信側

$ ./NTttcp.exe -r -m 24,*,192.168.5.111 -t 30
Copyright Version 5.33
Network activity progressing...


Thread  Time(s) Throughput(KB/s) Avg B / Compl
======  ======= ================ =============
   0 30.029    152115.281    60831.268
   1 30.013    172750.741    54972.069
   2 30.294    193288.704    57800.761
   3 30.185    138724.267    60691.135
   4 29.717    164140.316    57431.574
   5 30.013    187752.241    57852.899
   6 29.716    208883.323    57616.087
   7 30.263    220325.619    56724.817
   8 30.013    143334.155    56863.175
   9 30.044    226828.918    55499.565
  10 30.013    176832.173    55274.441
  11 30.013    186647.653    58564.156
  12 30.013    168679.824    56173.564
  13 30.013    207253.124    56957.149
  14 30.013    211270.951    58245.179
  15 30.294    240877.798    55655.737
  16 29.779    247252.896    57050.740
  17 29.763    153271.757    57865.536
  18 30.013    194315.796    57041.578
  19 30.013    206154.933    56982.983
  20 30.013    126995.635    57870.181
  21 29.998    191005.726    57402.725
  22 30.013    196121.947    58497.045
  23 29.779    181292.857    57231.037


####  Totals:  ####


   Bytes(MEG)    realtime(s) Avg Frame Size Throughput(MB/s)
================ =========== ============== ================
 131738.545221   30.017    25233.644    4388.798


Throughput(Buffers/s) Cycles/Byte       Buffers
===================== =========== =============
    70220.766     3.854    2107816.724


DPCs(count/s) Pkts(num/DPC)   Intr(count/s) Pkts(num/intr)
============= ============= =============== ==============
  91530.266    1.993     182212.080    1.001


Packets Sent Packets Received Retransmits Errors Avg. CPU %
============ ================ =========== ====== ==========
  3121124     5474353      0     0    14.800

およそ 4388MB/s となっています。
これはおよそ 40Gbps となりますので、かなりの速度が出ていることがわかります。

まとめ

MiktoTik製のCRS326-24S+2Q+RMの40GbEポートのスループットテストを簡易的に行いました。
これにより、L2レベルでは40GbEにおける理論値に近いスループットが出ることがわかりました。
L2に関して、スループットの低下等を気にする必要はなさそうです。
10GbEについても同様に理論値に近い速度が出ています。

L3以上の処理(VLAN等)を行うとCPU処理となるため、速度が低下すると考えられます。
これについては、気が向いたらテストしたいと思います。

参考

40GbEスイッチ MikroTik CRS326-24S+2Q+RM がやってきた!

2019年を振り返って

さて、もう2019年も終わろうとしている大晦日、今年もあと2時間ちょっとで終わる今2019年の振り返りをして見ようと思います。
読んでもなんの特にもならないので、今すぐブラウザバックしてテレビでも見たほうがいいんじゃないでしょうか。
途中なんかどうでもいいという人は、この記事の一番下にまとめてあります。

1月

自分でも覚えてないんで、自身のツイートを漁って見てたのですが、何してんだこいつってなりましたね。
1月真ん中らへん、VMWare ESXiを触ってみてたみたいですね。

自分の記憶にあるのは、とりあえず1Uサーバーにインストールして触ってみたところまでです。
結局その後Proxmoxを採用しましたので…。

そして、Twitterでたちまち話題となった「例のグラボ」こと、マイニング向けのRX470 8GB。
こいつの映像出力端子を有効化して遊んだりしてました。

1005という規格の1mm x 0.5mmサイズのパーツを付ける作業を手作業でしてみたくて、買った感じですね。
その後このグラボは部品箱へと入ってゆきましたとさ。

そして、人生初の新品サーバー、FujitsuのPrimergy RX1330 M1を購入した月でもありました。
3万ぐらいで買えたのでお得だったなと。

2月

先程紹介したサーバー、やっとここで開封したらしいです。何やってんだ。

そして、ラックに入れてたらしいですね。
このときのラックはまだ24Uでした。(ということは後ほど何かが起こります。)

そして、2月中旬頃から休暇期間に入ったはずなのに、ツイッターばかりしていて進捗が見つかりませんでした。(?)
この時期に、今の構成(iSCSIを用いたストレージシステム)の基礎ができたように思います。

3月

どうやらいい加減ネットワークをちゃんとやろうと思って、ルーティング周りの勉強(と言っても実際に設定して動作させるところまで)をしていたように思います。
そして過去の自分は「OSPFとBGP完全に理解した」とか言っていますね。ホントかな??????

そして、知り合い宅のとの間にVPNを張ってBGPやる作業をした記憶があります。

また、それまで宅内のサーバーはHPのProLiant DL360 G7を3台+αとして運用してましたが、この時期からGen8へのリプレイスを始めました。
Gen8がそれなりにお安く買えるようになってきたタイミングでした。
その結果、ダンボールに閉じ込められたんですけどね?

4月

大学での新学期が始まり、色々とすることがあり、あんまり何もしてなかったみたいですね。
ツッコミどころ満載なラックならデプロイしたらしいです。

そして、ネットワークの勉強会を主催した月でもありました。
ネットワークの基礎の基礎しか扱わなかったのですが、実際に機材を設定してもらうことで体験してもらった勉強会でした。
さらには、とあるイベント会場へのネットワーク提供チームの一員として携わった月でもあります。
設置から運用、撤収まで貴重な経験ができた機会であったと思います。

5月

Allied Telesisのx510が界隈で流行りだした頃ですね。
東京の某所にて格安で買える10G SFP+ x4を持つL3スイッチだったので、話題となりました。
私も、知り合いに頼んで2台確保してもらったものです。
そして、鉄道輸送。

そして、Stackしてみたやつです。

5月の記憶はこれぐらいでした(え)。

6月

この頃に、このブログ的な何かが設置されましたね。
Markdownから起こすようにしているので、凝ったことはできませんが…。
さて、6月は、Interop Tokyo 2019が開催された月でもあります。
自分は、企業様の支援を得て京都から参加することができました。

その時の記事

そして、Ubiquiti Networks社の製品UniFiシリーズのスイッチを買い足した記憶があります。

小さい上にPoEが扱えるほか、コントローラから一括管理が可能です。
それなりにお値段もしますが…。

そして、4月頃に組んだラックの配線を見直した記録がありました。

そして、このタイミングではすでに10GbEスイッチMikrotik CRS317-1G-16S+RMが導入されていたのですが、購入についての記憶が見つかりませんでした。(?)

7月

サーバーが燃えました。
その時の記事

ちょうど試験期間ということもあり、それ以外は特に何もしてなかったですね。

8月

8月中旬ごろより、とあるスタートアップ企業でのお仕事をはじめまして、触りたい機材を買うためにも、そちらの方を頑張っていました。
フルリモートでしたので、ずっと家に引きこもっていた感じです。

9月

この月は、サイバーエージェントさんが実施されたデータセンター見学会に参加させていただいた月でもあります。
適当にエントリーシート書きなぐったところ、参加させていただける運びとなりました。
NDAもありますので、内容について触れることはできませんが、同時にTwitterのFFでのオフ会になったりもしました。

そして、Mikrotik社の40GbEスイッチ、CRS326-24S+2Q+RMを購入しました。
これについては別記事にまとめてあります。

これにより、宅内40GbEデビューを果たしたはずでした

10月

ラックのケーブルがきれいに整えたぐらいですかね。

11月

今まで使用していた24Uラックは、背面に取り外し不可能なパネルがついていました。
横方向への剛性を確保するために取り付けなければならないもので、取り外すことはできるのですが、横方向への剛性が著しく低下してしまいます。
しかしながら、このパネルが付いているとサーバー背面へのアクセスへの障害となり、管理がしにくいという難点がありました。
また、増えてきたネットワーク機器を収容できるだけの余裕も無かったこともあり、36Uのオープンフレームラックを購入しました。
高さが1800mmと、自身の身長を超えるようなサイズですが、とても使い勝手もよく、気に入っています。
そして、このラックを一人で組み立てしたこともあり、疲れ切ってしまって11月は終わってしまいました。

12月

主に36Uラックへの設備再設置及び再構成で終わった感じです。
機材購入の関係もあり、2週間ほどかかりましたが、12月中旬には本ブログも含めて全サービスを復旧させました。
また、UTPケーブルを自作することで、ケーブルを綺麗にまとめるように努力しましたが、失敗、あんまり綺麗にはなりませんでした。

2019年の総まとめ

自分の中でいろいろとあった年でもありました。
1年前を思い出しても、沢山の人と出会い、そして、たくさんのことを学んだ1年でした。
関わってくれたすべての方へ、感謝しています。
そして、自身の知識としてもとても成長したと感じています。
これからも精進します。

余談

だんだん雑になっていったことに気づいた人もいると思います。
ゆっくり書いてたら年を越してしまいそうでした。

2020年の豊富はまた、別記事にて書きます。

40GbEスイッチ MikroTik CRS326-24S+2Q+RM がやってきた!

40GbE対応スイッチ

MikroTikから発売された、世界最安の40GbE対応スイッチとも言える CRS326-24S+2Q+RMを手に入れたので紹介します。

スペック

  • 10GbE SFP+ Port x24
  • 40GbE QSFP+ Port x2
  • Console Port x1
  • 10/100 Ethernet Port x1
  • USB Type-A x1
  • PSU x2
  • RouterOS L5 License

本製品の目玉は、40GbEに対応したことでしょうか。
40GbE対応のQSFP+ポートを2つ搭載しており、ToRのスイッチとしての利用を想定していると言えそうです。

また、MikroTikはこの他に、40GbE QSFP+をアップリンクとした1GbEスイッチを発表するなどしており、今後の40GbE製品の展開に期待が持てそうです。

さらに、MikroTikの製品は、安いものも含めてPSUが冗長化されているのが特徴だと言えます。
本製品も例にもれず、PSUは冗長化されています。

購入

EuroDKより、384ドルで購入しました。
安い…
この記事を書いている時点ではすでに売り切れとなっているようです。

外観

箱はCloud Router Switchのいつもの箱です。

中には簡単なマニュアル。

本体。

MikroTikCloud Router Switch CRS326-24S+2Q+RM

ポート

ポートは左からSFP+ 1から24 QSFP+ 1から2 となっています。
ポートの番付が下から上に1,2となっている点、間違えないように気をつけたほうがいい点ですね。

背面

背面にはPSUが2つ、Fanが3つ付いているようです。

CRS317-1G-16S+RM も所持していますが、背面のヒートシンクがなくなった点、スリムになったように感じます。

Fanはうるさい?

Fanのうるささは結構気にする人が多いと思います。
これについては、最新のRouterOS Stable 6.45.5 にすることで、低温時はFanは回転せず、温度が上がってくるとFanが回るようになります。
個人的にはこれでかなり静かになりました。

動作

40GbEについては、まだ対向が届いていないので、届き次第レビューしたいと思います。

本当に性能がでるの?

MikroTikが公開しているブロックダイアグラムを見る感じ、L2レベルであればしっかりとワイヤースピードが出そうです。
実際に、CRS317-1G-16S+RMではワイヤースピードが出ています。

利用用途

ラック内ではToRのスイッチとして、CRS317-1G-16S+RMが稼働中です。

2つ合わすと10GbE SFP+ Portが40Portと、一般家庭、ましてや私のような一人暮らしワンルームでは到底消費しない数のSFP+ポート数となります。

CRS317-1G-16S+RMCRS326-24S+2Q+RMをどうやって使っていくか、考えものです。

自宅環境紹介

そういえば、自宅環境の紹介をしていなかったなと思い、急遽書きました。

サーバラック

サーバラックの様子をどん。

上から

  • 10G SFP+ スイッチ
  • Router#1(パネル裏)
  • Router#2
  • パッチパネル
  • L2スイッチ#1
  • パッチパネル
  • L2スイッチ#2
  • ストレージサーバ(FreeNAS)
  • 仮想化環境(Proxmox)
  • 仮想化環境(ESXi)
  • 予備サーバ
  • 750VA UPS
  • 1200VA UPS

まだラッキングしてないサーバがは横に転がってます。
ちなみにLANケーブルは半分ぐらい自作です。

ストレージネットワークは10GbEで構成。

ネットワーク構成はこんな感じ。

知り合いとVPNを張っていて、その経路交換をBGPで行っています。

スペック

コアになってるProxmoxサーバのスペックは

  • CPU Xeon 16Core 32Threads
  • Memory ECC Registered 128GB
    とかってところです。

サービス

ホストしているものを軽く紹介。

監視環境とか

サービスの死活監視をZabbixにて行い、リソースの可視化をGrafanaで行っています。
個人でそこまでする必要があるのかは分かりませんけどね。

まとめ

何も知らないところ、サブネットマスクもわからないところから約1年、個人でここまでできたのは我ながら驚いています。
やはり、自分が好きに触れる物理環境があれば、何でもまず”試してみる”ことができるので良いですね。
その過程で色々なノウハウも得ることができました。

自宅サーバが燃えた件

突然ですが

サーバが燃えました。

中央付近、メモリの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度で済むと考えられる。
当然、何か理由があって、現状の処理順序になっていると考えられるが、それが自身には分からないので、誰かご教示願いたい。

About

インフラエンジニア
インフラ系の技術を中心に紹介・解説しています。

お問い合わせはTwitter DMまで

Privacy Policy

About Me

Recommends

Archives