港区にしかリージョンないですけどね。
Introduction
mstdn.maud.io Advent Calendar 2021 17日目です。
買った19インチサーバラックと周辺技術の話をネタに無限に喋り倒す試みになります。
(タイトルが書きたかっただけの可能性がある)
メタルラック時代はこんなでした。
Rack Environment
Rack
- サンワサプライ - 19インチサーバーラック（中型・24U・奥行85cm・パネルレス）
- https://direct.sanwa.co.jp/ItemPage/100-SV00324U
出来上がったものがこちらになります。
24U ではだいぶお買い得かと思います。
パネル付いているほうが見た目的にもよいのではという話はあるかもですが、パネルが付いた途端に重量がエライことになり、最悪床が抜ける可能性があります。
ラックだけで 100kg 超えるとさすがにつらいですからね…
あと使ってて思いましたが、サイドパネルは無いほうがメンテしやすくてよいと思います。
今回買った 100-SV00324U は、ラックのみで重量が 40kg です。
建築基準法施行令によると、一般家屋における床の積載荷重は約 180kg/㎡ であると定められています。
100-SV00324U は専有面積が 600x850mm、高さが 24U であるため、全部詰めたとしても 180kg/㎡ を超えることはそうそう無いでしょう。
(ただし、Backblaze のように 60 台の 3.5” HDD が刺さった死ぬほど重たい 4U サーバを詰め込むとかすると死ぬと思います)
フローリングに直置きすると脚の跡が付く恐れはあります。そのため何かしら敷いておいたほうが安心できます。
僕は？ 僕は貧民なので梱包に使われたダンボールをそのまま敷いています。クッソダサい。
24U を選んだ理由としては、天井がクソだからです。
36U が欲しかったけど無駄に盛り下がった天井にぶつかるかぶつからないかという感じなので、安全を取って 24U にしました。
とはいうものの、たくさんマシンを詰め込めるほど富豪でもないので、個人利用の範囲では 24U でも問題ないかなという感じです。
なによりラックの天板に物が置けます。モニタとキーボードを設置して KVM コンソール的な使い方も出来て丁度よいです。
そのうち中国製の雑な KVM スイッチを用意してもよさそうですね。
ラックマウントできない機材がたくさんあるので、とりあえず対応する棚板を4枚買って 240k くらい吹き飛ばしましたが、棚板の耐荷重である 70kg を超えるようなものはさすがに置かないので、1U ハーフラックトレイでも十分であることは買ってから気付きました。
気になる点としてはバックパネルが邪魔。外してもよいかもしれませんが揺れます。
マウントフレームは前面際々にあるので、マウントする機材によっては前面から飛び出ます。
ラック用電源タップの取り付けにも悩まされることになります。マウントフレームへの取り付けしかできませんし、しかもバックパネルに邪魔されます。
取り付けられないことはなさそうですが、めんどくさいので一旦は元々使っている電源タップを底に転がして耐え凌いでいます。
奥行きが控えめなため、機材によっては背面からも飛び出るみたいなことはありそうですが、メーカー製のサーバをマウントすることはおそらく無いので (増設する際はハーフラックトレイを使って自作するつもりなので) その点については気にしておらず、奥行きはむしろ設置場所にフィットしているので、うちの環境においては正解な気がしています。サンワさんありがとう。
配線が終わってるのはそのうちなんとかします。
よりグッドなラックをお求めの場合はコレとか買うと良さそうですが、値段がアホほど高くなります。
ラックマウント対応表については下記で確認できます。
https://direct.sanwa.co.jp/contents/sp/rac/taiou_svrac.pdf?wand=link_banner_SV00324U
Network
特に凝ったことはしていませんが、DNS サーバを建てるのはだるかったので RTX3500 で名前解決を頑張ってもらっています。
サーバに使用している OS は、すべて Rocky Linux 8.4 です。Debian なんもわからへんので。
サーバとして稼働させているマシンは4台で、うち1台に Puppet やら Cobbler やら監視周りやら全部詰め込んでいます。
詰め込みすぎて死んだ時どうなんのという懸念はありますが、アプリケーションは別のマシンで実行しますし Puppet 打てば環境は一瞬で作れるので、各種データのバックアップさえ取っていれば死んでも影響は軽微かと思います。美しくはないですが…
もう1台は NAS で、残り2台に色々やっていただくという構成です。
台数はそのうち増やします。
Anaconda Kickstart
複数のサーバを管理するためには、構成管理の仕組みがないとやってられません。
そのため、構成管理用のサーバを用意する必要がある訳ですが、こればかりはどうしても手動になってしまいます。
それでも GUI でポチポチなど死んでもやりたくないですから、予め Kickstart ファイルを仕込んだ ISO を使用して自動 Install を行っています。
一度出来上がってしまえば楽ではありますが、sudo mkisofs -o /path/to/custom.iso -b isolinux/isolinux.bin -J -R -l -c isolinux/boot.cat -no-emul-boot -boot-load-size 4 -boot-info-table -eltorito-alt-boot -eltorito-boot images/efiboot.img -no-emul-boot -graft-points -V "Rocky-8-4-x86_64-dvd" . みたいなクソ意味不明な mkisofs コマンドを打つ必要があることに気付くまでに4兆年ほど要したため、ポチポチガチアンチでない場合はおすすめできません。
インストールメディアの作成については下記が参考になるかと思います。
https://access.redhat.com/solutions/60959
インストール後は Puppet の環境作って Manifest 適用で準備完了という感じです。
Puppet
構成管理ツールとして、Puppet 7 を導入しています。
これは使う人によるかもですが、Puppet Module は可能な限り自作することを徹底しています。
メンテできる気がしないからですね。 (メンテできる気がしない例)
バージョン追従もだるいので、パッケージのインストール、各種設定ファイルの編集くらいであればモジュールに頼らなくても自力で書けるという判断です。
ただし、異なる OS が混在する環境の場合はモジュールに頼ったほうが楽です。
1 | case $facts[os][family] { |
こんなん死んでも書きたくないですからね。(そもそも OS は統一したほうがよい)
Validation などもサードパーティモジュールは丁寧にやってくれたりしていますが、自分で書く場合その辺りも考慮する必要があります (僕はやってないです)
あと、Puppet Agent のサービスは止めてます。勝手に apply されると非常に困るからですね。
複数台に Puppet を適用する際は Puppet Bolt でコマンドを撒いて適用すればよいです。
Puppet Bolt
https://github.com/puppetlabs/bolt
Ansible に似せた構成管理ツールです。
Puppet との使い分けとしては、Puppet Manifest に準じた構成を適用させる際 (各種ソフトウェアのインストール, 設定等) に Puppet を使って、複数サーバにコマンドを撒いたり、アプリケーションのデプロイを行う際は Bolt を使うといった具合になっています。
じゃあ Ansible つかえやとなるかもしれませんが、Puppet に慣れている身としては Bolt の方が都合がよいのです。
Cobbler
PXE による自動インストールを行うために Cobbler 3 を使用しています。
よしなに PXE Server を作ってくれるツールとしてはこれくらいしか無い気がします。
注意点としては、接続しているスイッチにて STP が有効になっていると Link Up が遅れるため PXE Boot も遅くなるくらいでしょうか。
PXE 用のネットワークにおいては、STP は無効化しておいたほうがよいかもしれません。
ループにはくれぐれもご注意を。
Sensu Go + InfluxDB + Grafana
監視ツールとして Sensu Go を使用しています。
旧 Sensu では Redis と RabbitMQ を使わされる結構キツめの構成を強いられていましたが、Sensu Go では撤廃され etcd のみを使用するようになっています。
クラスタ構成を組まないのであれば、etcd についても気にする必要はあまり無さそうです。適当です。
Nagios との親和性も高いため個人的にはだいぶ使いやすいと思います。
Sensu Go で実行した Check Result は InfluxDB (1.x系) に格納しており、Grafana で視覚化できるようにしています。
Alert が出た場合は Discord に通知して僕が叩き起こされるようになっています。
で、InfluxDB 2.x 系が出ているにも関わらず何故 1.x 系を使っているかというと、sensu-influxdb-handler がまだ2系に対応できていないからですね。
ぶっちゃけかなり屈辱的なので、有り余る余裕があれば対応したさがあります。
突然監視サーバがぶっ壊れた時を考慮して、Sensu Go の Config もコードとして管理できたほうがよいでしょう。
Sensu Go ドキュメントの Monitoring as code with Sensu にもあるように、Sensu Go の設定情報は YAML/JSON で表すことが出来ます。
が、コード化した設定を適用するのは SensuFlow が作られるくらいにはめんどくさいです。
Nagios くらい楽に管理できたら嬉しいのですが、ここは慣れるしかないでしょうか。
Sensu Go のコード管理については、気が向いたら別記事にて触れるかもしれません。
あと、ルータとかスイッチは Sensu Go Agent を入れられないので SNMP 叩くしかないですね。
Fluentd
Syslog および各種アプリケーションのログは Fluentd を経由して InfluxDB に食わせています。
以上！(ログ集めてるだけなので書くことが無いです)
phpIPAM
ファシリティ管理のために phpIPAM を使用しています。
IPAM を Google Spread Sheet でやる手法もアリっちゃアリですが、微妙なので phpIPAM でよろしくやっています。
MySQL が必要ですが、ホストマシンに MySQL を突っ込むのは (あと phpIPAM の環境自体を作るのも) 嫌なので Docker Compose で建てています。
NetBox という選択もありますが、オーバースペック過ぎる気がします。
4兆個くらい DC 持ってるとかならアリだと思いますが…
Docker, Docker Compose
アプリケーションのデプロイでは、基本的に Docker Compose を使用しています。
ホストマシンに色々ブチ込みたくないのでこれが一番ラクですね。
Docker 使いまくるなら Swarm なり k3s なり使ったほうがよいのですが、それはそれで面倒なのでサボっている状況です。
台数増やしてから考えます。
XigmaNAS
我が家には 4TB x 5台を RAID-Z2 で構築したストレージサーバが鎮座しています。使用可能容量は 10TB です。
OS は XigmaNAS (旧 NAS4Free) を使用しています。
以前は FreeNAS (現 TrueNAS) を使用していましたが、USB Boot が非推奨となってしまったため XigmaNAS へと乗り換えました。
美少女イラストを食わせすぎて残り容量が 3TB を切っており、そろそろ増やしときたいなとは思っています。
次組むとしたら 14TB x 10 の RAID-Z3 でしょうか。(82TB くらい使えると思う)
実はもうガワだけ買ってあります。 (ラックの一番下がそれです)
ここまでくると RAID でもしんどいので、MinIO あるいは OpenIO でオブジェクトストレージを作ってもよいかもしれません。
(そうなると複数台構成を強いられることになるので、ラック2台目が爆誕しそうです。床抜けます。)
Conclusion
以上、道楽でした。
課題は5兆個くらいあるので、引き続きいろいろやります。