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

この記事は、CyberAgent 22 新卒 Advent Calendar 2021の19日目の記事です。さいごに概要本記事では、自宅でサーバーやネットワーク機器を運用する筆者が、普段の運用をどのように行っているかを紹介します。また、後半では運用していく中で発生したトラブル経験などを紹介します。サーバーとはサーバーと言われてどのようなものを想像するでしょうか。一般的に、自宅サーバーなどと言われると自宅に中古のデスクトップPCなどを用意してサーバーとして運用するような形を想像する方が多いと思います。しかし、コンピューターにはサーバー用に設計されたものが存在します。これらはデータセンターなどで運用され、サイズ等が規格化されておりラックサーバーなどと呼ばれています。また、これを搭載するための専用のラックが存在しており、ユニット数(U)でいくつかの種類があります。このラックを使用することで、上方向へ積み上げてサーバーを設置することが可能になります。ラックサーバー自体は当然、一般家庭に設置することを想定したデバイスではありませんから、静音性より冷却性能の方が重要です。そのため、基本的に静音性とは無縁です。（サーバーラックに搭載されたラックサーバーの例）自宅サーバーを運用するメリットでは、デスクトップPCなどを使用する場合を含め自宅でサーバーを運用するメリットは何でしょうか。まず一つ目は、学習機会を得られるということです。AWSやGCPといったパブリッククラウドを利用するのと違い、自宅でサーバーを運用するには、物理レイヤーからすべて自分で設計や構築を行う必要があります。パブリッククラウドが普及した近年では、手間が掛かる事から嫌厭されがちですが、学習することに重点を置けば、より多くの学習機会が得られるというメリットがあると言えます。その中では、ネットワークに関する知識のほか、ハードウェアに関する知識も必要となります。そして、こういったレイヤーの知識は経験も重要です。この経験は、実際に運用していく中で原因切り分けなどを実施することで身に付く部分が多い分野でもあります。もう一つは、シビアにコストを気にする必要が無くなるということです。パブリッククラウドでは、インスタンスの起動時間や通信量による課金でコストが掛かります。例えば、パッケージを再インストールしたい場合などに、追加でコスト

さて、自宅インフラの論理構成がおおよそ固まってきたので、少し紹介したいと思います。(物理と合わせて書くとグチャグチャになるので今回はあんまり触れません。)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を用いた仮想化環境をメインにしておりましたが、先日まで検

性能及び冷却性能テスト編前回、AMD EPYC Processor で2U本格水冷サーバを組んでみた。という記事を書きました。今回はその性能テスト編になります。およそ1か月近くたち、その間 Rosetta@Home 稼働のために、フル負荷で連続1か月ほど稼働させておりましたので、その評価と合わせてお届けします。(Linux環境で運用したので、Windows系のベンチマークを取るのがめんどくさくて、本記事の投稿が遅れました。)その前にタスクマネージャーの図でも。どうやら、Windows10のタスクマネージャーはそうスレッド数が64以上になると、いくらウインドウを大きくしたところでチャートは表示されないようですね。48スレッド環境では全スレッドチャートが表示されていたので。Cinebench R20CPUベンチの定番といえばこれではないでしょうか。Temperatureベンチ中の温度は40度以下でした。EPYCにはプロセッサダイが4つありますので、4ノードの温度が表示されています。なお、温度取得にはHWMonitorを利用しております。Rosetta@Homeこちらは明確なスコア等は無いので、評価のしようがないところですが、安定して1か月ほど動作しておりました。評価水冷での冷却性能や、静音性について。本サーバ機を2Uサイズながら水冷としたのには、主に2つの目的がありました。1つは、静音化です。通常、2Uサイズのサーバ機では、CPUやその他コンポーネントを十分に冷却する必要があるためにファンが高速回転し、かなりの騒音となります。しかしながら、寝室にサーバラックがありますので、出来る限り静音化しなければ安眠の妨げとなります。もう1つは、冷却性能の向上です。2Uサイズという非常に薄い空間において冷却性能を担保するには、クーラントによって熱源を移動させ、より大きなヒートシンク（今回はラジエータ）で冷却することです。まず、静音化について。本サーバ機においては、性能や発熱量に対して非常に騒音を小さくすることに成功しています。それなりに音はしますが、扇風機の強運転よりは少し静かなぐらいです。もう1つ、冷却性能について、先ほど示したように最大負荷時でもCPU温度は40度程度でした。室温は25度程度、アイドル時26度ですので、冷却性能は非常に高いといえるでしょう。なにせCPUはTDP15

事の発端巷で話題になっていた 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サイズの空冷クーラーよりは大きな断面積を確保したラジエータによって冷却するのです。本格水冷自体始めてで、どの程度冷却できるか、静音性等は未知数でしたが、チャレンジしてみることとしました。

そういえば、自宅環境の紹介をしていなかったなと思い、急遽書きました。サーバラックサーバラックの様子をどん。上からまだラッキングしてないサーバがは横に転がってます。ちなみにLANケーブルは半分ぐらい自作です。 ストレージネットワークは10GbEで構成。ネットワーク構成はこんな感じ。知り合いとVPNを張っていて、その経路交換をBGPで行っています。スペックコアになってるProxmoxサーバのスペックはサービスホストしているものを軽く紹介。監視環境とかサービスの死活監視をZabbixにて行い、リソースの可視化をGrafanaで行っています。個人でそこまでする必要があるのかは分かりませんけどね。まとめ何も知らないところ、サブネットマスクもわからないところから約1年、個人でここまでできたのは我ながら驚いています。やはり、自分が好きに触れる物理環境があれば、何でもまず”試してみる”ことができるので良いですね。その過程で色々なノウハウも得ることができました。

突然ですがサーバが燃えました。中央付近、メモリのVRM回路と思われる部分が焼損していることがおわかりいただけると思います。状況とある日の夜22時ごろ、突然室内の音が変わった気がして、サーバを確認すると、うち１台が停止しており、FaultのLEDが点灯しておりました。HPのサーバでしたので、iLO4からログを確認すると、電源系のエラーが出ておりました。(スクショ忘れた)PSU以上かと思った主は、PSU#1が接続された状態でPSU#2を接続してからPSU#1を交換するという方法を取り、サーバの電源を喪失することなくPSUの交換を行いました。しかしながら、電源ボタンを押しても電源が入ることはなく、電源ケーブルを接続し直すことにしました。電源ケーブルの再接続を終え、電源ボタンを押すと…燃えたはい、燃えました。といっても目視で確認できていないですが、花火に火をつけたような音やスパークの飛ぶ音が1.5秒ほど続き、一瞬にして室内には半導体の燃える匂いでいっぱいに。ヒートシンクがマザーボードを外さずに撤去することができなかったので直視できていませんが、半導体チップが溶けてぐちゃぐちゃになっていました。チップ、半田ゴテとか当てても溶けませんから、相当の温度になっていたのでしょう。原因は？完全な原因究明には至っておりません。考えられることとしては、前日に行ったUPSのマウント作業の際、レールのかみ合わせが悪く、スライドさせるたびにカンナで削ったような金属片が散乱してしまっていましたので、それを運悪くサーバが吸い込んでショートした、ということぐらいでしょうか。 そして、ショートを検知して電源が落ちたものの、主が一度電源を喪失させたためにエラーのステートが消え、エラーをディテクトする前にサーバの電源が入ってしまって燃えた、というところでしょうか。だとすると、勝手に燃えることは無いはずです。おそらく、燃える前に止まるでしょうから。被害？まず、このサーバ、コアサーバだったのですが当然死亡しました。(というか燃えてから電源入れてない)稼働１ヶ月ほどでしたので、かなりダメージが大きいものです。あと、燃えたVRM回路から電源供給を受けていたと思われるメモリが死亡しておりました。これは廃棄。 まとめ？5万ちょっとぐらいの被害は出ましたが、家が燃えなくてよかったです。自宅でサーバ類を運用している方、