ラックマウント支援ツール PATCHBOX Setup.exe を試す

目次

PATCHBOX Setup.exe

PATCHBOX Setup.exe はサーバーラックなどにネットワーク機器を搭載する際に使用するサポートツールです。
通常、ネットワーク機器を設置する際には1人は機器を支えもう1人がネジで固定するといったように、2人で対応することが理想的です。
(もちろん、無理をすれば1人で行うことも出来ますが、機器を落下させるなどのリスクがあります)

このツールは、設置するネットワーク機器を固定するまでの間機器を支える役割を果たし、1人でも安全に作業を行えるようにします。

外観

本体は2つ折りの構造となっており、1kg程度と軽量なノートPCと同等の重量です。

両端にワンタッチでサーバーラックのマウントフレームに固定できるプル式の固定具がついています。
また、本体上部にはクッション性のある素材がついており、支える機器に擦り傷などがつきにくい配慮がされています。

また、本体にはケージナットを付けておくための穴が開いています。
(正直これについてはいまいち使い勝手がいいのかどうか分かりません)

使ってみる

実際にサーバーラックに取り付けてみるとこのようになります。
ノブをプルするだけで固定を解除できるため、取り付けも非常に簡単に行えます。

試しに Cisco の ASA5515-X を置いてみましたがしっかりと支えてくれており、固定するまでの間であれば十分安心して使用することができます。

また、サーバーラックから突き出すように取り付けることで、その上にノートPCなどを置いて作業場を確保することも可能で、機器に設定を行う際に便利に活用出来ます。

まとめ

これまでの自宅クラウド運用では機器の取り付けをすべて1人で行っており、重量のあるネットワーク機器をかなり苦労しながら取り付けていました。
そこそこいい価格のするツールではありますが、機器を落下させるリスクを低減させ苦労せずに設置できる他、作業中のPC置き場にもなることを考えると便利なツールであるといえます。

SSDを高速なキャッシュとして使えるbcacheをセットアップする (Ubuntu)

目次

概要

今回は、HDDなどの比較的低速なブロックデバイスに対して、SSDなどの比較的高速なブロックデバイスをキャッシュとして使える bcache をセットアップ方法と各種設定などについて紹介します。

bcacheとは

bcacheは、ブロックデバイスをキャッシュとして使うための仕組みを提供するソフトウェアです。

bcacheでは、キャッシュとして使用するブロックデバイスを キャッシュデバイス と呼び、データを保存する為のブロックデバイスを バッキングデバイス と呼びます。

似たような仕組みを提供するソフトウェアとしてLVM cacheやdm-cacheなどがありますが、bcacheの方がセットアップが容易だったり性能が高いという特徴があります。

キャッシュがあることのメリット

通常、高速なIO性能を必要とするシステムにおいてはHDDではなく高速なSSDをストレージとして利用します。
しかし、SSDはHDDに比べると容量単価が高く、大容量のストレージが必要な場合にはコストが大きな問題となります。

そこで登場するのがキャッシュです。
例えば、データへのアクセスの性質が「書き込んだばかりのデータを読み取ることが多い」場合や「同じデータに頻繁にアクセスすることが多い」場合、全てのデータ領域において高速にアクセスできる必要性はなく、アクセス頻度の高いデータのみ高速にアクセス出来ればほとんど問題ないといえます。
つまり、アクセス頻度の高いデータのみ高速なブロックデバイス上にキャッシュしておけばいいわけです。

高価なRAIDコントローラなどではより高速にアクセス可能な揮発性メモリを使用したキャッシュが搭載されており、書き込みなどをキャッシュすることで高速なストレージアクセスを実現しています。

キャッシュの種類

キャッシュにはいくつかのモードがあります。

  • writeback
    • 書き込まれたデータはまずキャッシュデバイスに書き込まれ、その次にバッキングデバイスへ書き込まれます。しかし、書き込みが完了したとみなされるのはキャッシュデバイスに書き込まれた後であり、その後非同期的にバッキングデバイスへ書き込まれます。
  • writethrough
    • 書き込まれたデータはキャッシュデバイス及びバッキングデバイスへ同時に書き込まれ、バッキングデバイスへの書き込みが完了した時点でIOが完了したとみなされます。そのため、writebackより安全性が高いですがパフォーマンス面では劣ります。
  • writearound
    • 読み取り専用のキャッシュモードです。書き込まれたデータは直接バッキングデバイスへ書き込まれます。キャッシュデバイスへは書き込まれないため、書き込み操作ではキャッシュデバイスの恩恵を受けることはできません。また、データが読み取られるとき、初回はバッキングデバイスから読み取りキャッシュします。このモードのメリットは書き込みをキャッシュしないためキャッシュデバイスの寿命を向上させることができる点です。
  • none (bcache)
    • bcacheは何もしません。

通常はwritebackを使用すれば問題ないはずです。
安全性を重視する場合はwritethroughを、Read intensive(読み取りメイン)な場合はwritearoundを使用すれば良いでしょう。

bcacheをセットアップする

今回は、Ubuntu 22.04 環境下でセットアップを行います。
本例では /dev/sdb をバッキングデバイスとして使用し、キャッシュデバイスは /dev/nvme0n1 を使用しています。

なお、キャッシュデバイス及びバッキングデバイスともにパーティションを含めた既存のデータはすべてロストします。

念のため、使用するブロックデバイスを初期化しておきます。下記のいずれかのコマンドを実行すれば十分でしょう。
必要に応じてブロックデバイスのパスは変更してください。

# dd if=/dev/zero of=/dev/sdb bs=1M count=1000
# sgdisk -Z /dev/sdb

bcacheを使用するために必要な bcache-tools をインストールします。

# apt update
# apt install bcache-tools

続いて、bcacheデバイスを作成します。
-B オプションの後に指定したブロックデバイスはバッキングデバイスとして使用され、 -C オプションの後に指定したブロックデバイスはキャッシュデバイスとして使用されます。

# make-bcache -B /dev/sdb -C /dev/nvme0n1

make-bcache コマンドの実行後、 bcache0 デバイスがシステムに認識されているはずです。

#  ll /sys/block/ | grep bcache
lrwxrwxrwx  1 root root 0 Feb  7 14:47 bcache0 -> ../devices/virtual/block/bcache0/

あとは通常のブロックデバイスと変わらずに使用することができます。
ここでは一般的な mkfs などでファイルシステムを作成しマウントする方法を紹介しておきます。

# mkfs.ext4 /dev/bcache0 
# mkdir /mnt/bcache-device
# mount /dev/bcache0 /mnt/bcache-device

なお、必要に応じて /etc/fstab にマウント設定を追記しておくと良いでしょう。

設定を変える

  • キャッシュデバイスの状態を確認する
# bcache-super-show /dev/nvme0n1
sb.magic                ok
sb.first_sector         8 [match]
sb.csum                 E200784837EB4188 [match]
sb.version              3 [cache device]

dev.label               (empty)
dev.uuid                d7be4216-fac7-4bb5-8090-3d85d06374c1
dev.sectors_per_block   1
dev.sectors_per_bucket  1024
dev.cache.first_sector  1024
dev.cache.cache_sectors 1953523712
dev.cache.total_sectors 1953524736
dev.cache.ordered       yes
dev.cache.discard       no
dev.cache.pos           0
dev.cache.replacement   0 [lru]

cset.uuid               090c7c50-5680-46f2-97b0-fc075eaea7c2
  • バッキングデバイスの状態を確認する
# bcache-super-show /dev/sdb
sb.magic                ok
sb.first_sector         8 [match]
sb.csum                 C01EF4DC00D547BF [match]
sb.version              1 [backing device]

dev.label               (empty)
dev.uuid                cc268d3d-6044-4a37-be79-2d8fea765093
dev.sectors_per_block   1
dev.sectors_per_bucket  1024
dev.data.first_sector   16
dev.data.cache_mode     0 [writethrough]
dev.data.cache_state    1 [clean]

cset.uuid               090c7c50-5680-46f2-97b0-fc075eaea7c2
  • キャッシュモードを確認する
# cat /sys/block/bcache0/bcache/cache_mode
[writethrough] writeback writearound none
  • キャッシュモードを変更する
# echo writethrough | sudo tee  /sys/block/bcache0/bcache/cache_mode

補足

fioなどのストレージベンチマークツールでは、bcacheのキャッシュ効果を正しく確認できない場合があります。
理由としては、fioのテストデータは単一ファイルとして生成されるため、シーケンシャルな書き込みとみなされキャッシュされないためです。
これは、シーケンシャルなアクセスを全てキャッシュデバイスに書き込んでいると、キャッシュデバイスの寿命を大幅に縮めることになるからです。

bcache上では特定のサイズ以上のIOをキャッシュしないように設定されており、デフォルトでは4.0MBになっています。
この設定は変更することができ、0に設定することで全てのIOをキャッシュすることができるようになります。

  • キャッシュデバイスへの書き込みをやめるサイズを確認・変更する
# cat /sys/block/bcache0/bcache/sequential_cutoff
4.0M
# echo 0 | sudo tee /sys/block/bcache0/bcache/sequential_cutoff

まとめ

今回は、SSDを高速なキャッシュデバイスとして使用できる仕組みであるbcacheのセットアップ方法を紹介しました。
手順が非常に簡単でありセットアップしやすい点に加えて、類似したソフトウェアであるLVM cacheなどと比較してパフォーマンスが良いという利点があります。
詳細なパフォーマンステスト結果は、気が向けば書き起こしたいと思います。

既存のストレージ環境に導入することはできませんが、新たにストレージを用意する場合などで導入を検討してみると良いかもしれません。

Nginxでリバースプロキシの設定をしたらハマった

目次

概要

今回は、Nginxでリバースプロキシの設定をした際にハマった点があったので簡単に紹介します。

事象

ミラーサーバーの提供にはロードバランサとしてNginxのリバースプロキシを設定して利用しています。
サポートするディストリビューションを追加するため、既存のリバースプロキシの設定を複製する形で設定を追記しました。
しかし、既存の設定は機能するにもかかわらず、追記した設定は機能しない問題が発生しました。

追記した設定は以下です。

location /ubuntu {
    proxy_pass http://192.168.x.y:80;
}

location /almalinux {
    proxy_pass http://192.168.x.z:80;
}

/ubuntu パスについては正しくリバースプロキシ先のHTTPサーバーの情報を返してくれますが、/almalinux パスは404となりアクセスができませんでした。
もちろんリバースプロキシ先のHTTPサーバが起動していないなどはなく、直接アクセスし正しく機能していることが確認できます。

# curl -s -o /dev/null -w '%{http_code}\n' http://192.168.x.x/ubuntu
200

# curl -s -o /dev/null -w '%{http_code}\n' http://192.168.x.x/almalinux
404

# curl -s -o /dev/null -w '%{http_code}\n' http://192.168.x.z/
200

正しい設定

Nginxでリバースプロキシを設定する際は、 locationとproxy_passに設定するパスの末尾を必ず / で終了させる必要があります。

上記設定を正しいものに直すと次のようになります。

location /ubuntu/ {
    proxy_pass http://192.168.x.y:80/;
}

location /almalinux/ {
    proxy_pass http://192.168.x.z:80/;
}

なぜ一部設定は機能していたのか

Ubuntuのアーカイブリポジトリには/ubuntuへのシンボリックリンクが入っています。
このため、元の設定では http://192.168.x.x/ubuntu へアクセスすると http://192.168.x.y/ubuntu へリバースプロキシされ、シンボリックリンクを参照したことでリポジトリのルートディレクトリを参照できている状況だったようです。

実際、AlmaLinuxのリポジトリを参照すると、 /almalinux へのシンボリックリンクはないことが確認できます。
このため、 http://192.168.x.x/almalinux へアクセスすると http://192.168.x.z/almalinux へリバースプロキシされ、このファイルは存在しないため404が返ってきます。

あとがき

こういったまれにしかしないことが多い設定は、設定するたびに毎回調べている気がしますね…
そしてたいてい同じところでハマってることが多い気がします。

速い!?エンタープライズHDD EXOS X14 10TBを試す!

目次

概要

今回は、Seagate製のエンタープライズHDDである EXOS X14 の 10TB モデルを入手したので簡単に紹介します。

スペック

公式のデータシートから抜粋になりますが、スペックは次のようになっています。

Seagate EXOS X14 10TB
MTBF (hours) 250 万時間
AFR 0.35 %
Spindle Speed (RPM) 7200 RPM
Interface SATA 6Gbps
Cache (MB) 256 MB
Sequential Read (MB/S) 245 MB/s
Sequential Write (MB/s) 233 MB/s
Random Read 4KB QD16 (IOPS) 170 IOPS
Random Write 4KB QD16 (IOPS) 418 IOPS
Idle Power Consumption (W) 5 W

HDD の故障率は母数が少ないと運に左右されますが、コンシューマ向け HDD との違いは MTBF や AFR が公表されている点でしょうか。
コンシューマ向け HDD では評判があまりよくない Seagate ですが、筆者の中ではエンタープライズ HDD では他社製のモノと比べて遜色ない成績を残しているイメージがあります。
また、近年の大容量 HDD で良く採用されているヘリウムを充填したモデルです。

外観

今回入手したものはリファービッシュ品です。
そのため新品とはラベルなどが異なる可能性があります。

こちらは表面です。
各種情報が記載されたラベルが貼られています。
HGST(WD) などの HDD は角ばっているので丸みを帯びたデザインは個人的には見慣れないものです。

こちらは裏面です。
他社の HDD と比較すると PCB の面積が少ないように感じます。
インタフェースは SATA です。

SMART

smartctl コマンドを使用して SMART 情報を確認してみます。
Ubuntu では次のコマンドでインストールできます。

# apt install smartmontools

諸事情でRAIDコントローラーをHBAモードにして接続しているため、SATA AHCI での接続に比べて見えている情報に差異があるかもしれません。

# smartctl -a -d cciss,0 /dev/sda
smartctl 7.2 2020-12-30 r5155 [x86_64-linux-5.15.0-60-generic] (local build)
Copyright (C) 2002-20, Bruce Allen, Christian Franke, www.smartmontools.org

=== START OF INFORMATION SECTION ===
Model Family:     Seagate Exos X14
Device Model:     ST10000NM0478-2H7100
Serial Number:    XXXXXXXX
LU WWN Device Id: 5 000c50 07443394e
Firmware Version: SN04
User Capacity:    10,000,831,348,736 bytes [10.0 TB]
Sector Sizes:     512 bytes logical, 4096 bytes physical
Rotation Rate:    7200 rpm
Form Factor:      3.5 inches
Device is:        In smartctl database [for details use: -P show]
ATA Version is:   ACS-4 (minor revision not indicated)
SATA Version is:  SATA 3.3, 6.0 Gb/s (current: 6.0 Gb/s)
Local Time is:    Tue Feb 14 11:25:49 2023 UTC
SMART support is: Available - device has SMART capability.
SMART support is: Enabled

セクタサイズですが、論理セクタサイズは 512Byte、物理セクタサイズ 4096Byte のようです。
また、Seagate によると SeaChest と呼ばれるツールを利用することで論理セクタサイズを 4096Byte に変更し、4Kn な HDD として使用することができるようです。
論理セクタサイズを 4K(4096)Byte にするとデータ転送の効率が向上するため、性能向上が期待されています。

しかし、4K セクタをサポートしていない RAID コントローラはまだまだ存在します。
一例をあげると、HPE のサーバーの Gen9 世代に搭載されている RAID コントローラは、RAID モードでは 4Kn HDD をサポートしておらず RAID の構成が出来ません。
ただ、HBA モードであれば使用できるようです。

論理セクタサイズを 4096Byte に設定するかどうかに限らず、RAID 構成で使用する HDD を選ぶ場合はこのあたりも注意して選定する必要があります。

ベンチマーク

CrystalDiskMark を使用して簡単なベンチマークを実施しました。

シーケンシャルでは Read 248.6MB/s、Write 235.7MB/s と、ともに公称値以上の値を出しています。

また、ランダムアクセス性能を見ても HDD としてはかなりいい結果を出していると言えるのではないでしょうか。
(データシート上の 4K ランダムアクセスでの数値はQD16のモノなので今回は比較はしません)

感覚値

本製品はすでに本番環境に投入しています。
性能限界に近いI/Oを3日以上かけ続けていますが、安定して動作しており動作音も非常に静かです。

また、電力値を以前購入したPDUを使用して計測していますが、以前まで使用していた HGST の 4TB HDD に比べるとディスクが使用する電力が 1/3 以下になりました。

さいごに

今回は、Seagate 製のエンタープライズ HDD である EXOS X14 10TB を入手したので簡単に紹介しました。

以前は Western Digital の RED シリーズを使用して今いたが、CMR から SMR にサイレント変更した経緯などがあり、近年では安価で信頼性の高い HDD を入手するのが難しくなっている印象を受けます。
本製品はリファービッシュ品などを ebay などで比較的安価に入手することができ、場合によっては十分選択肢となりうる製品ではないでしょうか。

Proxmox VEで無償版リポジトリを設定する

目次

概要

今回は無償のハイパーバイザーである Proxmox VE にて無償版リポジトリを設定する方法について紹介します。
Proxmox VE では初期設定でエンタプライズ契約向けのリポジトリが設定されており、そのままではアップデートを実施することができません。
この設定は簡単に変更できるほか、以前のバージョンでは CLI からの操作が必要でしたが、最近のアップデートで WebUI から設定が可能となりよりセットアップしやすくなりました。

なお、Proxmox VE 自体の構築手順などは過去に記事化していますのでそちらをご覧ください。

WebUIから設定を変更する

Proxmox VE の WebUI にアクセスし設定を変更してきます。
該当する設定は Datacenter > hostname(画像だとPVE) > Updates > Repositories にあります。

続いて、 https://enterprise.proxmox.com/debian/pve と書かれたものをクリックして選択し、 Disable を押して無効化します。

続いて、先ほどの Disable ボタンの左横の Add ボタンを押し表示されたダイアログ上で No-Subscription を選択して Add を押します。

これで設定変更は完了です。

以前までは CLI からの設定が必須だったのでかなり便利になりました。

アップデートを実施する

設定変更が完了したので早速アップデートを実施してみます。
こちらもWebUIから実施が可能になっています。
(もちろん中身は Debian ですので CLI からも実施可能です。)

アップデートは先ほど Repositories 開く際に使用したペインの1つ上の階層にある Updates を開きます。
上部にある Refresh を押すことで内部で apt-get update コマンドが実行されアップデート確認を実施できます。
また、 Upgrade を押すことで apt-get dist-upgrade が実行されアップデートが実施されます。

Raritan PDUでPrometheus+Grafanaでメトリクスを取る PX3-5138JR

目次

概要

今回はRaritanのインテリジェントPDU PX3-5138JR のメトリクスをPrometheusとGrafanaを用いて可視化してみます。
この記事は3部構成です。

PDUのメトリクスをPrometheusで読む

まずは、PDUのメトリクスをPrometheusで読めるようにする必要があります。
これまでRaritanのPDUでPrometheusを使用するには別途Exporterをサーバーなどで実行してメトリクスを取得する必要がありました。
しかし、PDUのファームウェアのv4系へのアップデートでPDUが直接Exporterの役割を果たすようになり、別途Prometheus Exporterを用意する必要がなくなりました。
また、設定不要で利用することができます。(マニュアル)

curlでアクセスしてみる

まずはマニュアルに従ってcurlコマンドを使用してアクセスしてみます。

$ curl -k https://<USER>:<PASS>@<IP>/cgi-bin/dump_prometheus.cgi
#HELP raritan_pdu_activeenergy_watthour_total Total activeenergy consumed in watthour
#TYPE raritan_pdu_activeenergy_watthour_total counter
raritan_pdu_activeenergy_watthour_total{pduid="1", inletid="I1"} 158.46
raritan_pdu_activeenergy_watthour_total{pduid="1", outletid="1"} 137.26
raritan_pdu_activeenergy_watthour_total{pduid="1", outletid="2"} 11.70
raritan_pdu_activeenergy_watthour_total{pduid="1", outletid="3"} 9.50
~~~~~

また、末尾にパラメーターとして include_names=1 を付加することで名前の情報を取得することができます。

取得できるデータ

  • raritan_pdu_activeenergy_watthour_total Total activeenergy consumed in watthour
    • トータル電力量
  • raritan_pdu_activepower_watt The current value of the activepower in watt
    • 現在の電力量
  • raritan_pdu_apparentpower_voltampere The current value of the apparentpower in voltampere
    • 現在のVA
  • raritan_pdu_current_ampere The current value of the current in ampere
    • 現在のA
  • raritan_pdu_inletrating The maximum ampere rating of the inlet
    • 入力の最大A
  • raritan_pdu_linefrequency_hertz The current value of the linefrequency in hertz
    • 現在の周波数
  • raritan_pdu_outletrating The maximum ampere rating of the outlet
    • 出力の最大A
  • raritan_pdu_powerfactor The current value of the powerfactor
    • 現在の力率
  • raritan_pdu_voltage_volt The current value of the voltage in volt
    • 現在の電圧

Prometheusの設定

/etc/prometheus/prometheus などに下記設定を追記することでPrometheusからデータを取得することができます。

  - job_name: PDU
    scrape_interval: 1m
    scrape_timeout: 1m
    scheme: https
    tls_config:
      insecure_skip_verify: true
    metrics_path: "/cgi-bin/dump_prometheus.cgi"
    params:
      include_names: ["1"]
    static_configs:
      - targets: ['<PDU_IP>:443']
    basic_auth:
      username: "<USERNAME>"
      password: "<PASSWORD>"

Grafanaで表示

サクッとGrafanaでグラフを表示してみます。

現在はPDUにPDUを接続している状況なので、PDU自体の負荷がおよそ3W程度であることが読めています。
分解能もかなり高そうです。

最後に

こういった製品のメトリクスを取得して可視化しようとすると、たいていSNMPを使用することになり毎回苦労することになるのですが、この製品はPDU自体がPrometheus形式のデータを吐いてくれるおかげでかなり楽にメトリクスを取得することが出来ました。

Raritan PDUでカスケード接続してみる PX3-5138JR

目次

概要

今回はRaritanのインテリジェントPDU PX3-5138JR でカスケード接続を試してみます。
この記事は3部構成です。

カスケード接続

インテリジェントPDUはイーサネット接続を利用して様々な操作や情報の取得を行えるようになっています。
しかし、通常PDUは大量に設置されるものであり、それぞれ個別にネットワークスイッチに接続していてはスイッチ側でかなりのポートを消費してしまいます。
これを回避するため、こういったPDU製品の多くはカスケード接続をサポートしています。
これは、PDUからPDUにデイジーチェーンのように接続することで、ネットワークスイッチのポート消費を最小限に抑えるものです。

カスケード接続のタイプ

Raritan PDUでは2つのカスケード接続方式をサポートしています。

  • ブリッジ
    • それぞれのPDUは異なるIPアドレスを用いてアクセスできるようになります。
  • ポートフォワーディング
    • 全てのPDUは同じIPアドレスを使用してアクセスできますがポート番号がPDUごとに異なります。IP消費が1つで済みます。

今回は、オーソドックスなブリッジでのカスケード接続を試してみます。
また、今回のRaritan PDUではPDU間での接続にイーサネットを使用することができず、USB A to Bのケーブルを使用する必要があります。
(この点は少し残念です)

詳細はオンラインマニュアルを確認してください。

カスケード接続の設定

以後の設定はカスケード接続するすべてのデバイスで行っておく必要があります。
詳細な手順はオンラインマニュアルに記載があります。

まずはネットワーク設定から カスケードモードブリッジング に設定します。

次にIP設定を確認します。
BRIDGE の項目にIP設定が移動しています。
設定前に ETHERNET で設定していたStatic IPの設定などは引き継がれないようなので注意が必要です。

設定は以上です。
続いて、USBケーブルの接続を行います。
配線は次のようなイメージで行います。

これで全てのPDUにアクセスできるようになります。
次回はPrometheus+Grafanaを用いてPDUの情報の可視化を行います。

インテリジェントPDUを買ってみた セットアップ編 PX3-5138JR

目次

概要

今回はRaritanのインテリジェントPDU PX3-5138JR を購入したので、軽く紹介していきます。
この記事は3部構成です。

外観

Raritan PX3-5138JRは1UタイプのPDUです。
フロント側にNEMA 5-15Rが8口のほかLCDやシリアルポートが配置されています。
入力側のC-20はリア側に配置されており、専用のロック機構がついたケーブルが付属していました。
イーサネット接続用のポートもリア側に配置されています。

ラックマウント金具は取付位置を変更できるようになっています。
しかし、フロント側を面一にすることができないのが個人的には少し残念です。
また、後ろ向きに設置することも可能です。

本体に搭載されているLCDでは様々な情報を確認することができます。
デフォルトで次の2つの画面が交互に表示されています。

メニュー画面

Outlet側の情報はポート単位でも確認することができます。

WebUIにアクセス

背面の ETHERNET ポートを利用してネットワーク接続することで、WebUIにアクセスすることができます。
ネットワークの設定はデフォルトでDHCPになっており、ネットワーク接続後にLCDからIP情報を確認することができます。
このため、DHCPサーバーがあればシリアルポートを使用せずにセットアップできます。

デバイス情報も確認することができます。

入手したものではファームウェアのバージョンが 3.3.10.5-43736 が入っていました。
細かい設定をする前に最新バージョンのファームウェアに更新します。

ファームウェアアップデート

Raritanのサイトを確認すると、最新バージョンは 4.0.20.5-49038 でした。
アップデート手順を確認すると、 3.3.10.5-43736 から直接最新バージョンにすることはできず、一度 3.5.0.5-45371 を経由する必要があるようです。
指示に従ってファームウェアのアップデートを実施します。
公式サイトからダウンロードしたzipファイルを解凍し、中にあるbinファイルをWebUIの Update Firmware からアップロードすることで簡単にファームウェアアップデートを実施できます。

4.0.20.5-49038 にアップデートするとWebUIが日本語化されました。

また、LCD画面も変更されたようです。

基本的な設定

ファームウェアのアップデートが完了したので、基本的な設定をしていきます。
設定といってもPDUですので大した設定はありません。
今回はネットワークとNTPの設定を確認します。

先ほども紹介したように、ネットワーク設定はデフォルトでDHCPに設定されています。
Static IPを設定した場合はここから設定することができます。

また、初期設定はNTPの設定が入っておらず時刻が狂っています。
NTPサーバーを利用して時刻同期を行う設定を行いますが、まずはDNSサーバーの設定を行います。
DNSリゾルバ設定IPv4アドレス にして 1番目のDNSサーバー にDNSサーバのアドレスを入力します。

続いてNTPの設定を行います。
タイムゾーン をUTC+9に設定し、 1番目のNTPサーバー を設定します。
(ちなみに 1番目のNTPサーバー なのに 2番目のタイムサーバー になっていることが気になって夜しか眠れません。)

これで左下に表示される デバイス時間 が正しい時間を示すようになります。

WebUI

WebUIから各ポートの情報を確認することができます。
Inlet

Outletでは口単位で個別にON/OFFを設定することができるようになっており、機器を強制的に放電したい場合などもリモートで実施できるようになります。

ここまで、RaritanのインテリジェントPDUを軽く紹介しました。
次回はカスケード接続の設定をしてみます。

ElastiFlowとKibanaを組み合わせてNetFlowのデータを分析してみる

目次

概要

今回は、ElastiFlow 環境を構築してネットワークのフロー情報の収集と可視化を行う環境を構築してみます。
OS は Ubuntu22.04 LTS です。

ElastiFlowとは

ElastiFlow とは、ネットワークのフロー情報を解析するためのツールの1つです。
OSS として提供されており、データの蓄積と解析を行う ElasticSearch 、データを可視化する WebUI を提供する Kibana を合わせて使用することでフロー情報の取得から解析・可視化を行うことができます。
この ElasticSearch に対して収集したデータを入れるツールとして以前は logstash が用いられていたようですが、今は ElastiFlow に内包された ElastiFlow Unified Flow Collector によってデータの収集と ElasticSearch 用データ形式への正規化が行われています。

準備

最初に、構築にあたって動作に必要なスペックを確認しておく必要があります。
フロー情報の分析などにそこそこの計算資源を消費しますので、公式サイトを参考にマシンスペックを決定します。

また、必要になる基本的なツールをインストールしておきます。

sudo apt install apt-transport-https unzip

Linux Kernelのチューニング

ElasticSearch はデフォルトで mmapfs ディレクトリを使用してデータを保存しますが、Linux のデフォルトの制限値が低すぎるためこの制限を 262114 に引き上げておく必要があります。

echo "vm.max_map_count=262144" | sudo tee /etc/sysctl.d/70-elasticsearch.conf > /dev/null

また、ネットワーク関係のパラメーターについても変更を行います。
デフォルトでは大量の UDP パケットの受信に最適化されておらずパケットがドロップされる可能性があるため、チューニングを行っておく必要があります。

echo -e "net.core.netdev_max_backlog=4096\nnet.core.rmem_default=262144\nnet.core.rmem_max=67108864\nnet.ipv4.udp_rmem_min=131072\nnet.ipv4.udp_mem=2097152 4194304 8388608" | sudo tee /etc/sysctl.d/60-net.conf > /dev/null

これらの設定を適用するためにOSを再起動します。

【補足】再起動せずに適用する(一時的な適用)
sudo sysctl -w vm.max_map_count=262144
sudo sysctl -w net.core.netdev_max_backlog=4096
sudo sysctl -w net.core.rmem_default=262144
sudo sysctl -w net.core.rmem_max=67108864
sudo sysctl -w net.ipv4.udp_rmem_min=131072
sudo sysctl -w net.ipv4.udp_mem='2097152 4194304 8388608'

ElasticSearchのインストール

最初に、ElasticSearch の PGP キーを追加します。

wget -qO - https://artifacts.elastic.co/GPG-KEY-elasticsearch | sudo apt-key add -

続いて Elastic のリポジトリを追加します。

echo "deb https://artifacts.elastic.co/packages/7.x/apt stable main" | sudo tee /etc/apt/sources.list.d/elastic-7.x.list > /dev/null

リポジトリの追加が出来たら ElasticSearch をインストールします。

sudo apt update
sudo apt install elasticsearch

ElasticSearchの設定

インストールが完了したら、ElasticSearch の設定を行います。

初めに、JVM のヒープサイズを設定します。
使用中に JVM のヒープサイズが動的に変更された場合にプロセスが一時停止する場合があるためです。
初期ヒープサイズと最大ヒープサイズを同じサイズに設定しておくことで回避することができます。
なお、今回は 12GB を割り当てていますが、システムのメモリ量の 1/3 の量に設定することが望ましいようですので、各自の環境に合わせて変更してください。

echo -e "-Xms12g\n-Xmx12g" | sudo tee /etc/elasticsearch/jvm.options.d/heap.options > /dev/null

続いて、systemd の設定ファイル内でシステム制限の引き上げを行います。

sudo mkdir /etc/systemd/system/elasticsearch.service.d
echo -e "[Service]\nLimitNOFILE=131072\nLimitNPROC=8192\nLimitMEMLOCK=infinity\nLimitFSIZE=infinity\nLimitAS=infinity" | sudo tee /etc/systemd/system/elasticsearch.service.d/elasticsearch.conf > /dev/null

ElasticSearch への接続に使用する証明書の生成を行います。
この処理を簡素にするために elasticsearch-certutil と呼ばれるツールが用意されていますのでこちらを利用します。
最初に CA を生成します。

sudo /usr/share/elasticsearch/bin/elasticsearch-certutil ca --pem

Please enter the desired output file [elastic-stack-ca.zip]: が表示されたらそのまま Enter を押下しデフォルトのまま進みます。
生成されたファイルは /usr/share/elasticsearch に配置されます。

生成されたファイルを解凍して移動します。

sudo mkdir /etc/elasticsearch/certs
sudo unzip /usr/share/elasticsearch/elastic-stack-ca.zip -d /etc/elasticsearch/certs

続いて、証明書を生成するのに必要な情報を記載したファイル /usr/share/elasticsearch/instances.yml 作成します。
このファイルに次の内容を書き込みます。 nameipdns の値は各自の環境に合わせて変更する必要があります。
なお、 dns についてはDNS名が無い場合は項目ごと設定しないでおくことができます。(下から2行分を削除)

instances:
  - name: "hostname" 
    ip: 
      - "192.168.1.2"
    dns: 
      - "hostname.dns.local"

先ほどの生成ツールを利用して証明書を生成します。

sudo /usr/share/elasticsearch/bin/elasticsearch-certutil cert --silent --in instances.yml --out certs.zip --pem --ca-cert /etc/elasticsearch/certs/ca/ca.crt --ca-key /etc/elasticsearch/certs/ca/ca.key

生成された ZIP ファイルを再度解凍しておきます。

sudo unzip /usr/share/elasticsearch/certs.zip -d /etc/elasticsearch/certs

設定ファイルを編集します。
設定ファイルは /etc/elasticsearch/elasticsearch.yml に存在します。
xpack.security.http.ssl.keyxpack.security.http.ssl.certificate にある証明書のパスは必ず各自の環境に合わせて変更しておく必要があります。
その他項目についても設定を変更する必要がある場合は調整してください。

cluster.name: elastiflow

path.data: /var/lib/elasticsearch
path.logs: /var/log/elasticsearch

bootstrap.memory_lock: true

network.host: 0.0.0.0
http.port: 9200

discovery.type: 'single-node'

indices.query.bool.max_clause_count: 8192
search.max_buckets: 250000

action.destructive_requires_name: 'true'

xpack.security.http.ssl.enabled: 'true'
xpack.security.http.ssl.verification_mode: 'none'
xpack.security.http.ssl.certificate_authorities: /etc/elasticsearch/certs/ca/ca.crt
xpack.security.http.ssl.key: /etc/elasticsearch/certs/hostname/myhohostnamest.key
xpack.security.http.ssl.certificate: /etc/elasticsearch/certs/hostname/hostname.crt

xpack.monitoring.enabled: 'true'
xpack.monitoring.collection.enabled: 'true'
xpack.monitoring.collection.interval: 30s

xpack.security.enabled: 'true'
xpack.security.audit.enabled: 'false'

設定ファイルの編集が完了したら ElasticSearch サービスを起動します。
なお、初期状態ではOS起動時に自動的に起動する設定にはなっていないため、合わせて設定しておきます。

sudo systemctl daemon-reload
sudo systemctl enable elasticsearch
sudo systemctl start elasticsearch

ElasticSearch の各種パスワードを設定します。

sudo /usr/share/elasticsearch/bin/elasticsearch-setup-passwords interactive

インタラクティブ形式で設定項目が出てきますので、それぞれ設定します。

ここまで完了したら、curl コマンドを利用して正しく動作しているか確認します。
<PASSWORD> は適宜変更してください。
下記のようなレスポンスが返ってくれば正しく動作しています。
レスポンスエラーになる場合は証明書のパス設定が正しいか、ElasticSearch が起動しているかなどを再度確認してみてください。

$ curl -XGET -k "https://elastic:<PASSWORD>@127.0.0.1:9200"
{
  "name" : "elastiflow",
  "cluster_name" : "elastiflow",
  "cluster_uuid" : "askEKLTJgskl4wNKL",
  "version" : {
    "number" : "7.17.6",
    "build_flavor" : "default",
    "build_type" : "deb",
    "build_hash" : "f65e9d338dc1d07b642e14a27f338990148ee5b6",
    "build_date" : "2022-08-23T11:08:48.893373482Z",
    "build_snapshot" : false,
    "lucene_version" : "8.11.1",
    "minimum_wire_compatibility_version" : "6.8.0",
    "minimum_index_compatibility_version" : "6.0.0-beta1"
  },
  "tagline" : "You Know, for Search"
}

Kibanaのインストール

続いて Kibana をインストールしていきます。

sudo apt update
sudo apt install -y kibana

先ほど作成した ElasticSearch の証明書をコピーします。

sudo cp -r /etc/elasticsearch/certs /etc/kibana

Kibana の設定ファイルを編集します。
設定ファイルは /etc/kibana/kibana.yml に存在します。
環境に合わせて変更する必要があるのは次の箇所です。

  • server.publicBaseUrl
  • server.ssl.key
  • server.ssl.certificate
  • elasticsearch.hosts
    • localhost では証明書エラーで接続できませんので必ずIPで設定します。
  • elasticsearch.password
  • elasticsearch.ssl.key
  • elasticsearch.ssl.certificate
  • xpack.encryptedSavedObjects.encryptionKey
    • 変更しなくても動作しますがランダム文字列に変えておくとよいでしょう。
telemetry.enabled: false
telemetry.optIn: false
newsfeed.enabled: false

server.host: '0.0.0.0'
server.port: 5601
server.maxPayload: 8388608
server.publicBaseUrl: 'https://192.168.2.1:5601'

server.ssl.enabled: true
server.ssl.certificateAuthorities: /etc/kibana/certs/ca/ca.crt
server.ssl.key: /etc/kibana/certs/myhost/myhost.key
server.ssl.certificate: /etc/kibana/certs/myhost/myhost.crt

elasticsearch.hosts: ['https://192.168.2.1:9200']
elasticsearch.username: 'kibana_system'
elasticsearch.password: 'PASSWORD'
elasticsearch.ssl.certificateAuthorities: /etc/kibana/certs/ca/ca.crt
elasticsearch.ssl.key: /etc/kibana/certs/myhost/myhost.key
elasticsearch.ssl.certificate: /etc/kibana/certs/myhost/myhost.crt
elasticsearch.ssl.verificationMode: 'certificate'

elasticsearch.requestTimeout: 132000
elasticsearch.shardTimeout: 120000

kibana.autocompleteTimeout: 2000
kibana.autocompleteTerminateAfter: 500000

monitoring.enabled: true
monitoring.kibana.collection.enabled: true
monitoring.kibana.collection.interval: 30000

monitoring.ui.enabled: true
monitoring.ui.min_interval_seconds: 20

xpack.maps.showMapVisualizationTypes: true

xpack.security.enabled: true
xpack.security.audit.enabled: false

xpack.encryptedSavedObjects.encryptionKey: 'THIS_IS_A_RANDOM_STRINGS'

Kibana を起動します。
こちらも ElasticSearch と同様に初期状態ではOS起動時に自動的に起動する設定にはなっていないので合わせて設定しておきます。

sudo systemctl daemon-reload
sudo systemctl enable kibana
sudo systemctl start kibana

サービスが正常に起動しているか確認します。

sudo systemctl status kibana

正常に起動できていれば、ブラウザで https://<IP>:5601 にアクセスするとログイン画面が表示されます。
証明書エラーが表示されますが、自己証明書を使用しているためです。自己責任で続行することができます。

ElastiFlow Unified Flow Collectorのインストール

続いて、NetFlow のデータを利用するために Elastic Unified Flow Collector をインストールします。

wget https://elastiflow-packages.s3.amazonaws.com/flow-collector/flow-collector_5.6.0_linux_amd64.deb
sudo apt install ./flow-collector_5.6.0_linux_amd64.deb

ElastiFlow Unified Flow Collectorの設定

コレクターの設定をしていきます。

まずは、証明書をコピーして利用できるようにします。

sudo mkdir /etc/elastiflow/ca
sudo cp /etc/elasticsearch/certs/ca/ca.crt /etc/elastiflow/ca

続いて、せっかくなので無償で使用できる Basic ライセンスを取得しておきます。
こちらのページからリクエストすることができます。
ライセンスをリクエストすると30分程度でライセンス情報が記載されたメールが届きます。

ライセンスを取得出来たら、必要な設定をしていきます。
設定ファイルは /etc/systemd/system/flowcoll.service.d/flowcoll.conf に存在しています。
必要な項目をコメントアウトするなどして編集します。

ライセンス関連

EF_FLOW_LICENSED_UNITS はライセンス形態により異なりますが今回は BASIC ライセンスですので 1 を設定します。

Environment="EF_FLOW_ACCOUNT_ID=<メールに記載のあるACCOUNT_ID>"
Environment="EF_FLOW_LICENSE_KEY=<メールに記載のあるLICENSE_KEY>"
Environment="EF_FLOW_LICENSED_UNITS=1"
ネットワーク関連

本来は 0.0.0.0 で良いはずなのですが、私の環境ではその設定では IPv6 でしか Listen してくれなかったので明示的に IPv4 インターフェースのアドレスを指定しておきます。

Environment="EF_FLOW_SERVER_UDP_IP=192.168.1.2"
ElasticSearch関連

下記項目は環境に合わせて変更します。

  • EF_FLOW_OUTPUT_ELASTICSEARCH_ADDRESSES
  • EF_FLOW_OUTPUT_ELASTICSEARCH_PASSWORD
Environment="EF_FLOW_OUTPUT_ELASTICSEARCH_ENABLE=true"
Environment="EF_FLOW_OUTPUT_ELASTICSEARCH_ECS_ENABLE=true"
Environment="EF_FLOW_OUTPUT_ELASTICSEARCH_TIMESTAMP_SOURCE=end"
Environment="EF_FLOW_OUTPUT_ELASTICSEARCH_INDEX_TEMPLATE_SHARDS=1"
Environment="EF_FLOW_OUTPUT_ELASTICSEARCH_INDEX_TEMPLATE_REPLICAS=0"
Environment="EF_FLOW_OUTPUT_ELASTICSEARCH_INDEX_PERIOD=rollover"
Environment="EF_FLOW_OUTPUT_ELASTICSEARCH_ADDRESSES=192.168.1.2:9200"
Environment="EF_FLOW_OUTPUT_ELASTICSEARCH_USERNAME=elastic"
Environment="EF_FLOW_OUTPUT_ELASTICSEARCH_PASSWORD=changeme"

なお、 EF_FLOW_OUTPUT_ELASTICSEARCH_TIMESTAMP_SOURCE の設定について詳細が公式ドキュメントに記載されていますので、必要な場合は変更します。

証明書関連

ElastiFlow に使用する証明書の設定を行います。

Environment="EF_FLOW_OUTPUT_ELASTICSEARCH_TLS_ENABLE=true"
Environment="EF_FLOW_OUTPUT_ELASTICSEARCH_TLS_CA_CERT_FILEPATH=/etc/elastiflow/ca/ca.crt"

設定が完了したら ElastiFlow Unifed Flow Collector を起動します。
こちらも初期状態では OS 起動時に起動する設定にはなっていないので、合わせて設定しておきます。

sudo systemctl daemon-reload
sudo systemctl enable flowcoll
sudo systemctl start flowcoll

サービスが正常に起動しているか確認します。

sudo systemctl status flowcoll

GEOIPとASNのデータベース設定

別途データベースをダウンロードすることで GeoIP の情報と ASN(Autonomous System Number) の情報を利用することができます。
最新のデータベースはこちらから取得することができます。

cd /etc/elastiflow/maxmind
wget https://github.com/P3TERX/GeoLite.mmdb/releases/download/2022.09.16/GeoLite2-ASN.mmdb
wget https://github.com/P3TERX/GeoLite.mmdb/releases/download/2022.09.16/GeoLite2-City.mmdb
wget https://github.com/P3TERX/GeoLite.mmdb/releases/download/2022.09.16/GeoLite2-Country.mmdb

続いて、このデータベースを利用するように ElastiFlow の設定ファイルである /etc/systemd/system/flowcoll.service.d/flowcoll.conf を編集します。

Environment="EF_FLOW_DECODER_ENRICH_MAXMIND_ASN_ENABLE=true"
Environment="EF_FLOW_DECODER_ENRICH_MAXMIND_ASN_PATH=maxmind/GeoLite2-ASN.mmdb"
Environment="EF_FLOW_DECODER_ENRICH_MAXMIND_GEOIP_ENABLE=true"
Environment="EF_FLOW_DECODER_ENRICH_MAXMIND_GEOIP_PATH=maxmind/GeoLite2-City.mmdb"
Environment="EF_FLOW_DECODER_ENRICH_MAXMIND_GEOIP_LANG=en"

設定が完了したら反映のため ElastiFlow サービスを再起動しておきます。
なお、適用には daemon-reload を実施する必要があります。

sudo systemctl daemon-reload
sudo systemctl restart flowcoll

Kibanaの設定

Kibana の設定をしていきます。
まずは ElastiFlow 用の Kibana Object をインポートします。
インポートに必要なオブジェクトはここから取得することができます。
今回、ElasticSearch は Version7.17.6、Schema としてデフォルトの CODEX を使用しているので、 kibana-7.14.x-codex-light.ndjson を使用します。
事前にダウンロードしておきます。

まず、ブラウザで https://<IP>:5601 にアクセスしてログインします。
デフォルトのユーザー名は elastic でパスワードは先ほど設定したものを使用します。

ログイン出来たら左側のメニューから Stack Management から Saved Objects を開きます。
画面右上の import から import を押すとファイル選択画面が出てくるので、先ほどダウンロードしたファイルを選択し Import を押します。

しばらくするとインポートされたオブジェクトが表示されます。

NetFlowでフロー情報を流してみる

ここまで設定できれば ElastiFlow の環境構築は一通り完了です。
ルーターに NetFlow の設定をしてフロー情報を流して動作を確認しましょう。
ElastiFlow Unified Flow Collector のデフォルトの NetFlow ポートは 9995 です。

今回は Ubiquiti Networks 社のルーターである EdgeRouter に設定を入れて動作を確認しました。
各自の環境に合わせて設定方法は調べてください。

EdgeRouter への NetFlow 設定の例

set system flow-accounting disable-memory-table
set system flow-accounting ingress-capture pre-dnat
set system flow-accounting interface eth0
set system flow-accounting netflow enable-egress engine-id 1
set system flow-accounting netflow engine-id 0
set system flow-accounting netflow server 192.168.2.1 port 9995
set system flow-accounting netflow timeout expiry-interval 60
set system flow-accounting netflow timeout flow-generic 60
set system flow-accounting netflow timeout icmp 60
set system flow-accounting netflow timeout max-active-life 60
set system flow-accounting netflow timeout tcp-fin 10
set system flow-accounting netflow timeout tcp-generic 60
set system flow-accounting netflow timeout tcp-rst 10
set system flow-accounting netflow timeout udp 60
set system flow-accounting netflow version 9
set system flow-accounting syslog-facility daemon

Dashboardを見てみる

ここまで正しく設定できていれば、Kibana 上でフロー情報が見えるようになるはずです。
いくつかダッシュボード画面を紹介します。

Overview

フロー情報の概要を確認することができます。

TOP-N

通信量順に送信元・宛先の情報を確認することができます。

Flows

フロー情報を Sankey Diagram 形式で確認することができます。

Geo IP

送信元・宛先の GeoIP 情報を確認することができます。

AS Traffic

送信元・宛先の ASN 情報を確認することができます。

まとめ

今回は、ElastiFlow 環境を構築してネットワークのフロー情報の可視化環境を構築しました。
こういったフロー情報を可視化するツールが OSS で無償で利用できるのはとても便利です。
アクセス元の国や ASN を確認できることで、サーバーの利用状況などを確認することができます。

おうちで始めるNVMe over TCP入門

目次

概要

前回、NVMe over RDMA 環境を構築し、簡単な動作確認を行いました。
今回は、前回の概要でも触れたとおりNVMe over TCP を試してみます。

NVMe over TCP はその名の通り、NVMe プロトコルを TCP プロトコル上に流すことでリモートでの利用を可能にしたものです。
NVMe over RDMA (RoCEv2) と異なり、一般的な TCP プロトコルを使用しているため専用のスイッチなどを必要としないメリットがあります。
しかしながら、メモリ上のデータを直接扱う RDMA の恩恵を受けられないため、プロトコルスタックの処理によるCPU負荷の上昇やIOに対する遅延の増大、スループットの低下などのデメリットも存在します。

今回はそんな NVME over TCP 環境を構築し、動作確認を行ってみます。

環境

今回の検証に使用した環境です。
マシンは2台用意し、それぞれをターゲット(Server)側、Initiator(Client)側としています。

ターゲット側

詳細
Machine HPE ProLiant DL380 Gen10
CPU Intel Xeon Silver 4208 x2
Memory DDR4 ECC RDIMM 128GB (16GB x8 2400MHz)
NIC Mellanox ConnectX-4 100Gb(Ethernet) MCX415A-CCAT
NVMe Intel DC P4600 1.6TB U.2 x2
OS Ubuntu Server 22.04 LTS

Initiator側

詳細
Machine Fujitsu Primergy RX2540 M4
CPU Intel Xeon Gold 6148 x1
Memory DDR4 ECC RDIMM 128GB (32GB x4 2666MHz)
NIC Mellanox ConnectX-4 100Gb(Ethernet) MCX415A-CCAT
OS Ubuntu Server 22.04 LTS

準備

今回も、前回と同様に SPDK を用いて環境構築を行います。
SPDK をビルドし nvmf_tgt が実行可能な状態までは前回と同様の手順です。

ネットワーク設定

この段階でネットワーク設定を行っておきます。
手順については省略します。
なお、今回は次のような構成にしています。
なお、リンクスピードは100Gbps、MTUは9000です。

ターゲット側 10.0.0.1/24 ---------- 10.0.0.2/24 Initiator側

nvme-cliのインストール

ターゲット側とInitiator側の両方に nvme-cli をインストールしておきます。

# apt install nvme-cli

ターゲット側の設定

nvmf_tgt を起動した状態で設定を入れていきます。
前回と異なるのは、 nvmf_create_transportnvmf_subsystem_add_listener 設定において TCP を指定している部分です。

root@target:~/spdk# ./build/bin/nvmf_tgt
root@target:/usr/src/spdk# ./scripts/rpc.py nvmf_create_transport -t TCP -u 16384 -m 8 -c 8192
root@target:/usr/src/spdk# scripts/rpc.py bdev_nvme_attach_controller -b NVMe0 -a 0000:39:00.0 -t pcie
NVMe0n1
root@target:/usr/src/spdk# scripts/rpc.py bdev_nvme_get_controllers
[
  {
    "name": "NVMe0",
    "ctrlrs": [
      {
        "state": "enabled",
        "trid": {
          "trtype": "PCIe",
          "traddr": "0000:39:00.0"
        },
        "cntlid": 0,
        "host": {
          "nqn": "nqn.2014-08.org.nvmexpress:uuid:d4549310-b740-4edc-bed0-95dbcbec1178",
          "addr": "",
          "svcid": ""
        }
      }
    ]
  }
]
root@target:/usr/src/spdk# scripts/rpc.py nvmf_create_subsystem nqn.2016-06.io.spdk:cnode1 -a -s SPDK00000000000001 -d SPDK_Controller1
root@target:/usr/src/spdk# scripts/rpc.py nvmf_subsystem_add_ns nqn.2016-06.io.spdk:cnode1 NVMe0n1
root@target:/usr/src/spdk# scripts/rpc.py nvmf_subsystem_add_listener nqn.2016-06.io.spdk:cnode1 -t tcp -a 10.0.0.1 -s 4420

なお、詳細な設定内容や複数ディスクへの対応方法などは前回の記事で解説しています。

Initiator側の設定

NVMe over TCP を利用するには nvme-tcp モジュールが必要となり、対応したカーネルに更新する必要があります。
今回は、 linux-modules-extra-5.15.0-1004-gke を利用します。

root@initiator:# apt install linux-modules-extra-5.15.0-1004-gke
root@initiator:# reboot
root@initiator:# mobprobe nvme_tcp

無事に nvme-tcp モジュールを有効化出来たら、nvme discover を実行して検出できるか確認します。

root@initiator:~# nvme discover -t tcp -a 10.0.0.1 -s 4420

Discovery Log Number of Records 1, Generation counter 1
=====Discovery Log Entry 0======
trtype:  tcp
adrfam:  ipv4
subtype: nvme subsystem
treq:    not required
portid:  0
trsvcid: 4420
subnqn:  nqn.2016-06.io.spdk:cnode1
traddr:  10.0.0.1
sectype: none

接続し、認識しているか確認します。

root@initiator:~# nvme connect -t tcp -n "nqn.2016-06.io.spdk:cnode1" -a 10.0.0.1 -s 4420
root@initiator:~# nvme list
Node                  SN                   Model                                    Namespace Usage                      Format           FW Rev
--------------------- -------------------- ---------------------------------------- --------- -------------------------- ---------------- --------
/dev/nvme0n1          SPDK00000000000001   SPDK_Controller1                         1           1.60  TB /   1.60  TB    512   B +  0 B   22.09

問題なく認識していることが確認できたので、 fio で簡単にベンチマークしていきます。

fioを用いてベンチマーク

Initiator 側から NVMe に IO 負荷をかけてベンチマークを実施します。
ベンチマークには fio を用います。

root@initiator:~# apt install fio

シーケンシャルリードでベンチマークをまわしてみます。

root@initiator:~# fio --name=seqread --rw=read --filename=/dev/nvme0n1 --direct=1 --ioengine=libaio --bs=32m --numjobs=2 --size=10G --group_reporting
seqread: (g=0): rw=read, bs=(R) 32.0MiB-32.0MiB, (W) 32.0MiB-32.0MiB, (T) 32.0MiB-32.0MiB, ioengine=libaio, iodepth=1
...
fio-3.28
Starting 2 processes
Jobs: 2 (f=2): [R(2)][100.0%][r=3171MiB/s][r=99 IOPS][eta 00m:00s]
seqread: (groupid=0, jobs=2): err= 0: pid=2327: Fri Jul  1 13:32:00 2022
  read: IOPS=98, BW=3167MiB/s (3321MB/s)(20.0GiB/6466msec)
    slat (usec): min=6780, max=27344, avg=12248.84, stdev=2025.29
    clat (usec): min=5220, max=12290, avg=7910.04, stdev=1526.57
     lat (usec): min=15432, max=35796, avg=20160.18, stdev=1641.21
    clat percentiles (usec):
     |  1.00th=[ 5342],  5.00th=[ 5538], 10.00th=[ 5735], 20.00th=[ 6128],
     | 30.00th=[ 6718], 40.00th=[ 7504], 50.00th=[ 8291], 60.00th=[ 8717],
     | 70.00th=[ 8979], 80.00th=[ 9241], 90.00th=[ 9634], 95.00th=[10028],
     | 99.00th=[10552], 99.50th=[10814], 99.90th=[12256], 99.95th=[12256],
     | 99.99th=[12256]
   bw (  MiB/s): min= 3008, max= 3328, per=100.00%, avg=3173.33, stdev=42.02, samples=24
   iops        : min=   94, max=  104, avg=99.17, stdev= 1.31, samples=24
  lat (msec)   : 10=94.06%, 20=5.94%
  cpu          : usr=0.28%, sys=7.61%, ctx=11290, majf=0, minf=16410
  IO depths    : 1=100.0%, 2=0.0%, 4=0.0%, 8=0.0%, 16=0.0%, 32=0.0%, >=64=0.0%
     submit    : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, >=64=0.0%
     complete  : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, >=64=0.0%
     issued rwts: total=640,0,0,0 short=0,0,0,0 dropped=0,0,0,0
     latency   : target=0, window=0, percentile=100.00%, depth=1

Run status group 0 (all jobs):
   READ: bw=3167MiB/s (3321MB/s), 3167MiB/s-3167MiB/s (3321MB/s-3321MB/s), io=20.0GiB (21.5GB), run=6466-6466msec

Disk stats (read/write):
  nvme0n1: ios=0/0, merge=0/0, ticks=0/0, in_queue=0, util=0.00%

3.3GB/s となっており、これは使用したNVMeの公称値とほぼ同様です。

続いて、シーケンシャルライトを試します。

root@initiator:~# fio --name=seqwrite --rw=write --filename=/dev/nvme0n1 --direct=1 --ioengine=libaio --bs=32m --numjobs=2 --size=10G --group_reporting
seqwrite: (g=0): rw=write, bs=(R) 32.0MiB-32.0MiB, (W) 32.0MiB-32.0MiB, (T) 32.0MiB-32.0MiB, ioengine=libaio, iodepth=1
...
fio-3.28
Starting 2 processes
Jobs: 2 (f=2): [W(2)][100.0%][w=1280MiB/s][w=40 IOPS][eta 00m:00s]
seqwrite: (groupid=0, jobs=2): err= 0: pid=2372: Fri Jul  1 13:32:35 2022
  write: IOPS=38, BW=1248MiB/s (1308MB/s)(20.0GiB/16414msec); 0 zone resets
    slat (usec): min=7971, max=51897, avg=27101.64, stdev=4912.11
    clat (usec): min=10756, max=46502, avg=24141.04, stdev=5077.53
     lat (usec): min=25093, max=79939, avg=51243.83, stdev=6243.81
    clat percentiles (usec):
     |  1.00th=[14484],  5.00th=[16909], 10.00th=[18482], 20.00th=[20055],
     | 30.00th=[21103], 40.00th=[22676], 50.00th=[23725], 60.00th=[24773],
     | 70.00th=[25822], 80.00th=[27395], 90.00th=[31065], 95.00th=[33817],
     | 99.00th=[39584], 99.50th=[40633], 99.90th=[46400], 99.95th=[46400],
     | 99.99th=[46400]
   bw (  MiB/s): min=  960, max= 1408, per=99.86%, avg=1246.00, stdev=60.59, samples=64
   iops        : min=   30, max=   44, avg=38.94, stdev= 1.89, samples=64
  lat (msec)   : 20=19.69%, 50=80.31%
  cpu          : usr=3.62%, sys=4.22%, ctx=11075, majf=0, minf=19
  IO depths    : 1=100.0%, 2=0.0%, 4=0.0%, 8=0.0%, 16=0.0%, 32=0.0%, >=64=0.0%
     submit    : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, >=64=0.0%
     complete  : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, >=64=0.0%
     issued rwts: total=0,640,0,0 short=0,0,0,0 dropped=0,0,0,0
     latency   : target=0, window=0, percentile=100.00%, depth=1

Run status group 0 (all jobs):
  WRITE: bw=1248MiB/s (1308MB/s), 1248MiB/s-1248MiB/s (1308MB/s-1308MB/s), io=20.0GiB (21.5GB), run=16414-16414msec

Disk stats (read/write):
  nvme0n1: ios=0/0, merge=0/0, ticks=0/0, in_queue=0, util=0.00%

こちらも 1.3GB/s となっており公称値と同等です。

まとめ

今回は、前回作成した環境と SPDK を利用して、NVMe over TCP 環境を構築し、簡単なパフォーマンス測定を行いました。
シーケンシャルリード/ライトにおいてはスループット面では特に問題はないようです。
次回、NVMe over RDMA と NVMe over TCP の詳細なパフォーマンス測定を行う予定です。

About

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

お問い合わせはTwitter DMまで

Privacy Policy

About Me

Recommends

Archives