背景前回はお借りした機材を利用して100GbEをテストしました。今回は、手元に Mellanox ConnectX-4 があったので、こちらを再度簡単にテストしてみることにします。検証機材今回は、NICとケーブルを前回と異なるものでテストします。（ちなみに前回はお借りした機材でしたが今回はすべて私物です。）詳細MachineFujitsu Primergy CX2550 M2CPUIntel Xeon E5-2690v4 x2MemoryDDR4 ECC RDIMM 128GBNICMellanox ConnectX-4 100Gb(Ethernet) MCX415A-CCATCableIntel QSFP28 100G-CWDM4 module (SPTSBP2CLCKS)OSUbuntu Server 20.04.4 LTSMellanox ConnectX-4 MCX415A-CCATIntel QSFP28 100G-CWDM4 module準備初めに、ドライバをインストールします。手順は前回と同様です。Mellanoxのドライバは公式サイトからダウンロードできます。IPアドレスについて、前回と同様に 10.0.0.1/24 と 10.0.0.2/24 を使用し、以下のように直結することにします。10.0.0.1/24 ---------- 10.0.0.2/24設定はnetplanを用いて行いました。2つのNIC間は100G-CWDM4モジュールとシングルモードファイバー(duplex)を用いて接続しました。リンクアップを確認ethtool コマンドを用いて、100Gbpsでリンクアップしているか確認します。$ ethtool ens11np0Settings for ens11np0: Supported ports: [ FIBRE ] Supported link modes: 1000baseKX/Full 10000baseKR/Full 40000baseKR4/Full 40000baseCR4/Full

準備今回は、Ubuntu 20.04.1 を使用しました。Ubuntuに最初から入っているドライバは使用せず、Mellanox公式から取得したドライバを使用することにします。今回は、MLNX_OFED_LINUX-5.1-0.6.6.0-ubuntu20.04-x86_64.tgzを使用しました。取得したファイルを解凍します。$ tar zxvf MLNX_OFED_LINUX-5.1-0.6.6.0-ubuntu20.04-x86_64.tgz$ cd MLNX_OFED_LINUX-5.1-0.6.6.0-ubuntu20.04-x86_64/解凍されたディレクトリの中にある、mlnxofedinstallを実行します。$ lscommon_installers.pl DEBS LICENSE RPM-GPG-KEY-Mellanoxcommon.pl distro mlnx_add_kernel_support.sh srccreate_mlnx_ofed_installers.pl docs mlnxofedinstall uninstall.sh$ ./mlnxofedinstall実行後、新しいドライバを使用するにはopenibdの再起動が必要な旨のメッセージが表示されますので、指示に従います。Installation passed successfullyTo load the new driver, run:/etc/init.d/openibd restart$ sudo /etc/init.d/openibd restartIPアドレスについて、今回は10.0.0.1/24と10.0.0.2/24を使用し、以下のように直結することにします。10.0.0.1/24 ---------- 10.0.0.2/24OSインストール時にIPアドレスの設定はしていませんので、 Interface は Down な状態になっています。そこで Interface を Up にしますが、設定を保存しておく必要はないので今回はipコマンドを使用しました。$ sudo ip link set enp65s0 upIntef

さて、自宅インフラの論理構成がおおよそ固まってきたので、少し紹介したいと思います。(物理と合わせて書くとグチャグチャになるので今回はあんまり触れません。)1年ほど前の構成はこちら最近書いた物理構成はこちら指針これまでの自宅環境では、Hypervisor である Proxmox を利用した仮想化環境を主として構成していました。しかしながら、複数のWebサイトをホストしたりする都合上、仮想マシン(VM)ではスケールに手間がかかります。そこで、学習・検証を兼ねて、kubernetes を用いたコンテナ環境を採用することにしました。また、都合上、仮想マシンも同時に扱える必要がありますので、ハイパーバイザー上の仮想マシンでコンテナ環境を実現するという少し変な構成になっています。(電気代を気にしないならばマシンごとに分ければよいのですが、そうもいかないので)Server Hardware本構成では、物理サーバを3台使用しています。うち2台はHPE製の2Uサーバ、DL380 Gen10を使用し、ストレージには Western Digital 製の Ultrastar DC SS200 (SAS 12Gbps) を使用しています。Hypervisor for VirtualizationHypervisor には引き続き proxmox を利用します。VMWare ESXi を用いない理由としては、無償版においてCPU数の制限があること(8C)、ネットワークインタフェースでのLAG等が出来ないことが挙げられます。Infrastructure with kubernetes物理サーバを2台使用し、それぞれの VM 上にワーカーを乗せています。また、図にはありませんが、コントロールプレーンは物理サーバごとに1つ以上配置しています。これらの物理サーバは 10GbE 2本で接続されています。さらに、 Horizontal Pod Autoscaler による水平方向のオートスケーリングを設定しています。HTTPトラフィックは、 Ingress によるL7ロードバランサーを利用し各Podへの分散を行っています。Registry for ContainerDocker Container 用のレジストリには SUSE がオープンソースで公開している Portus を用いています。また、これらの

色々と機材更新やらがありましたが、1年ほど書いていないなと思ったので、書いてみることにしました。前半は機器類の紹介、後半は構成についてです。自宅36Uラック私は一人暮らしをしている学生ですが、自宅に36Uラックを設置しています。その様子を先に。サーバサーバ機器はラック下部にマウントしています。重量のある機器はできるだけラック下部へ設置し、ラック自体の重心を下げるように努めています。自宅のワンルームに設置していますから、地震等でラックが倒壊する可能性をできるだけ抑えるのが目的です。 現在、以下のようなサーバがあります。名称CPURAMHP DL380e Gen8Intel Xeon E5-2420v264GBHP DL380p Gen8Intel Xeon E5-2640v2 x2128GBHPE DL380 Gen10Intel Xeon Silver 4208128GBHPE DL380 Gen10Intel Xeon Bronze 310416GB自作AMD EPYC 7452 32-Core Processor128GBネットワークネットワーク機器は主にラック上部にマウントしています。機器類の管理ネットワークは1GbEで構成し、ストレージ周りは10GbEとしています。使用しているスイッチには40GbEポートがありますから、将来的に40GbEを利用する予定です。(スイッチの紹介、検証等は別途記事にしていますので、アーカイブから御覧ください。)さらに、光ファイバーを2回線引き込んでいます。また、OpenVPNを用いたSite-to-Site VPNによって、VPS及び別のリージョンに設置した機器類について、接続を行っています。各リージョン間の経路情報の交換は、BGPを用いて行っております。 電源夏場のゲリラ豪雨等の一時的な停電・電圧降下に対応するため、1200VAのUPSを1台設置しています。昨年夏の稼働回数は、瞬間的な電圧降下によって15回ほど作動しましたので、重要な役割を担っています。また、15Aのブレーカを搭載したサーバラック用にコンセントバーを背面に設置しております。構成とか現在は、TrueNAS(FreeNAS)を用いたネットワークストレージのみが稼働している状況です。 今まではProxmoxを用いた仮想化環境をメインにしておりましたが、先日まで検

さておよそ半年前、MikroTik社のCRS326-24S+2Q+RMを購入した記事を書きましたが、40GbEのテストは後でやると書きました。ようやくそのテストを実施する(気になる)ことができたので、その結果を記していきたいと思います。環境本当はLinux機でテストしたかったのですが、ぱっと使えるマシンがWindowsしかなかったので、諦めてそちらでテストを行いました。マシン2 (HPE DL380 Gen9)なお、Desktop機においてはNICが冷却できずに燃えそうだったので、サーキュレータの風をぶち当てて強制冷却することにしました。PC1 --- CRS326-24S+2Q+RM --- PC2こんな構成でテストを行いました。なお、IPアドレスについては別途DHCPサーバからの配布としました。iperf3 with MTU 1500$ ./iperf3.exe -c 192.168.5.111Connecting 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.0

40GbE対応スイッチMikroTikから発売された、世界最安の40GbE対応スイッチとも言える CRS326-24S+2Q+RMを手に入れたので紹介します。スペック本製品の目玉は、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が

環境ProxmoxNetwork症状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がディスクのベンチマークを行う際、以下の順序で実行されているように思う。この手順だと、テストデータを2回書き込む必要があると考えられる。以下の処理順序にすれば、効率よくベンチマークが行えないだろうか？ この順序だと、書き込みや読み込み処理が１度で済むと考えられる。当然、何か理由があって、現状の処理順序になっていると考えられるが、それが自身には分からないので、誰かご教示願いたい。