PATCHBOX Setup.exePATCHBOX Setup.exe はサーバーラックなどにネットワーク機器を搭載する際に使用するサポートツールです。通常、ネットワーク機器を設置する際には1人は機器を支えもう1人がネジで固定するといったように、2人で対応することが理想的です。（もちろん、無理をすれば1人で行うことも出来ますが、機器を落下させるなどのリスクがあります）このツールは、設置するネットワーク機器を固定するまでの間機器を支える役割を果たし、1人でも安全に作業を行えるようにします。外観本体は2つ折りの構造となっており、1kg程度と軽量なノートPCと同等の重量です。両端にワンタッチでサーバーラックのマウントフレームに固定できるプル式の固定具がついています。また、本体上部にはクッション性のある素材がついており、支える機器に擦り傷などがつきにくい配慮がされています。また、本体にはケージナットを付けておくための穴が開いています。（正直これについてはいまいち使い勝手がいいのかどうか分かりません）使ってみる実際にサーバーラックに取り付けてみるとこのようになります。ノブをプルするだけで固定を解除できるため、取り付けも非常に簡単に行えます。試しに Cisco の ASA5515-X を置いてみましたがしっかりと支えてくれており、固定するまでの間であれば十分安心して使用することができます。また、サーバーラックから突き出すように取り付けることで、その上にノートPCなどを置いて作業場を確保することも可能で、機器に設定を行う際に便利に活用出来ます。まとめこれまでの自宅クラウド運用では機器の取り付けをすべて1人で行っており、重量のあるネットワーク機器をかなり苦労しながら取り付けていました。そこそこいい価格のするツールではありますが、機器を落下させるリスクを低減させ苦労せずに設置できる他、作業中のPC置き場にもなることを考えると便利なツールであるといえます。

概要今回は、HDDなどの比較的低速なブロックデバイスに対して、SSDなどの比較的高速なブロックデバイスをキャッシュとして使える bcache をセットアップ方法と各種設定などについて紹介します。bcacheとはbcacheは、ブロックデバイスをキャッシュとして使うための仕組みを提供するソフトウェアです。bcacheでは、キャッシュとして使用するブロックデバイスを キャッシュデバイス と呼び、データを保存する為のブロックデバイスを バッキングデバイス と呼びます。似たような仕組みを提供するソフトウェアとしてLVM cacheやdm-cacheなどがありますが、bcacheの方がセットアップが容易だったり性能が高いという特徴があります。キャッシュがあることのメリット通常、高速なIO性能を必要とするシステムにおいてはHDDではなく高速なSSDをストレージとして利用します。しかし、SSDはHDDに比べると容量単価が高く、大容量のストレージが必要な場合にはコストが大きな問題となります。そこで登場するのがキャッシュです。例えば、データへのアクセスの性質が「書き込んだばかりのデータを読み取ることが多い」場合や「同じデータに頻繁にアクセスすることが多い」場合、全てのデータ領域において高速にアクセスできる必要性はなく、アクセス頻度の高いデータのみ高速にアクセス出来ればほとんど問題ないといえます。つまり、アクセス頻度の高いデータのみ高速なブロックデバイス上にキャッシュしておけばいいわけです。高価なRAIDコントローラなどではより高速にアクセス可能な揮発性メモリを使用したキャッシュが搭載されており、書き込みなどをキャッシュすることで高速なストレージアクセスを実現しています。キャッシュの種類キャッシュにはいくつかのモードがあります。writethroughwritearoundnone (bcache)通常はwritebackを使用すれば問題ないはずです。安全性を重視する場合はwritethroughを、Read intensive(読み取りメイン)な場合はwritearoundを使用すれば良いでしょう。bcacheをセットアップする今回は、Ubuntu 22.04 環境下でセットアップを行います。本例では /dev/sdb をバッキングデバイスとして使用し、キャッシュデバイスは /dev

概要今回は、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/ubuntu200# curl -s -o /dev/null -w '%{http_code}\n' http://192.168.x.x/almalinux404# 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/;}なぜ一部設定

概要今回は、Seagate製のエンタープライズHDDである EXOS X14 の 10TB モデルを入手したので簡単に紹介します。スペック公式のデータシートから抜粋になりますが、スペックは次のようになっています。Seagate EXOS X14 10TBMTBF (hours)250 万時間AFR0.35 %Spindle Speed (RPM)7200 RPMInterfaceSATA 6GbpsCache (MB)256 MBSequential Read (MB/S)245 MB/sSequential Write (MB/s)233 MB/sRandom Read 4KB QD16 (IOPS)170 IOPSRandom Write 4KB QD16 (IOPS)418 IOPSIdle Power Consumption (W)5 WHDD の故障率は母数が少ないと運に左右されますが、コンシューマ向け HDD との違いは MTBF や AFR が公表されている点でしょうか。コンシューマ向け HDD では評判があまりよくない Seagate ですが、筆者の中ではエンタープライズ HDD では他社製のモノと比べて遜色ない成績を残しているイメージがあります。また、近年の大容量 HDD で良く採用されているヘリウムを充填したモデルです。外観今回入手したものはリファービッシュ品です。そのため新品とはラベルなどが異なる可能性があります。こちらは表面です。各種情報が記載されたラベルが貼られています。HGST(WD) などの HDD は角ばっているので丸みを帯びたデザインは個人的には見慣れないものです。こちらは裏面です。他社の HDD と比較すると PCB の面積が少ないように感じます。インタフェースは SATA です。SMARTsmartctl コマンドを使用して SMART 情報を確認してみます。Ubuntu では次のコマンドでインストールできます。# apt install smartmontools諸事情でRAIDコントローラーをHBAモードにして接続しているため、SATA AHCI での接続に比べて見えている情報に差異があるかもしれません。# smartctl -a -d cciss,0 /dev/sdasmartctl

概要今回は無償のハイパーバイザーである 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 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 counterraritan_pdu_activeenergy_watthour_total{pduid="1", inletid="I1"} 158.46raritan_pdu_activeenergy_watthour_total{pduid="1", outletid="1"} 137.26raritan_pdu_activeenergy_watthour_total{pduid="1", outletid="2"} 11.70raritan_pdu_activeenergy_watthour_total{pduid="1", outletid="3&quot

概要今回はRaritanのインテリジェントPDU PX3-5138JR でカスケード接続を試してみます。この記事は3部構成です。カスケード接続インテリジェントPDUはイーサネット接続を利用して様々な操作や情報の取得を行えるようになっています。しかし、通常PDUは大量に設置されるものであり、それぞれ個別にネットワークスイッチに接続していてはスイッチ側でかなりのポートを消費してしまいます。これを回避するため、こういったPDU製品の多くはカスケード接続をサポートしています。これは、PDUからPDUにデイジーチェーンのように接続することで、ネットワークスイッチのポート消費を最小限に抑えるものです。カスケード接続のタイプRaritan PDUでは2つのカスケード接続方式をサポートしています。ポートフォワーディング今回は、オーソドックスなブリッジでのカスケード接続を試してみます。また、今回のRaritan PDUではPDU間での接続にイーサネットを使用することができず、USB A to Bのケーブルを使用する必要があります。（この点は少し残念です）詳細はオンラインマニュアルを確認してください。カスケード接続の設定以後の設定はカスケード接続するすべてのデバイスで行っておく必要があります。詳細な手順はオンラインマニュアルに記載があります。まずはネットワーク設定から カスケードモード を ブリッジング に設定します。次にIP設定を確認します。BRIDGE の項目にIP設定が移動しています。設定前に ETHERNET で設定していたStatic IPの設定などは引き継がれないようなので注意が必要です。設定は以上です。続いて、USBケーブルの接続を行います。配線は次のようなイメージで行います。これで全てのPDUにアクセスできるようになります。次回はPrometheus+Grafanaを用いてPDUの情報の可視化を行います。

概要今回は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画面も変更されたようです。基本的な設定ファーム

概要今回は、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 unzipLinux 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=67

概要前回、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)側としています。ターゲット側詳細MachineHPE ProLiant DL380 Gen10CPUIntel Xeon Silver 4208 x2MemoryDDR4 ECC RDIMM 128GB (16GB x8 2400MHz)NICMellanox ConnectX-4 100Gb(Ethernet) MCX415A-CCATNVMeIntel DC P4600 1.6TB U.2 x2OSUbuntu Server 22.04 LTSInitiator側詳細MachineFujitsu Primergy RX2540 M4CPUIntel Xeon Gold 6148 x1MemoryDDR4 ECC RDIMM 128GB (32GB x4 2666MHz)NICMellanox ConnectX-4 100Gb(Ethernet) MCX415A-CCATOSUbuntu Server 22.04 LTS準備今回も、前回と同様に SPDK を用いて環境構築を行います。SPDK をビルドし nvmf_tgt が実行可能な状態までは前回と同様の手順です。ネットワーク設定この段階でネットワーク設定を行っておきます。手順については省略します。なお、今回は次のような構成にしています。なお、リンクスピードは100Gb