自作ルーターを作っていくのにR86S U1を買ったのもあり、遂にフレッツ光クロス、10Gbps対応に関する覚書で構想した10GbE LAN環境の構築を実行してみた。有線部分のみの対応で無線部分は放置している。
フレッツ光クロスとフレッツ光ネクスト隼のコスト比較をしてみた結果、クロスの導入コストが高すぎたのでLAN内だけ10GbE対応としている。そもそも出先から10GbE接続できるとは思えないのもあり、WANまで10GbE対応にする意味はNAS目的では薄そうだ。
恐らく現状で10G対応WANが活躍するシーンは、BitTorrentみたいに異なる相手から複数ストリームを並列でやり取りするみたいな用途くらいな気はする。
| 分類 | 機器 | 詳細 | 参考価格 |
|---|---|---|---|
| スイッチ | MikroTik CRS305-1G-4S+IN | 10GBASE, SFP+ 4口, 1000BASE-T 1口 | 27,349円 |
| DACケーブル | 10Gtek CAB-10GSFP-P0.5M-30 | 10GBASE, CAT8, 0.5m Twinaxケーブル | 1,999円 |
| DACケーブル | 10Gtek CAB-10GSFP-P1M-30 | 10GBASE, CAT8, 1.0m Twinaxケーブル | 2,199円 |
| DACケーブル | 10Gtek CAB-10GSFP-P2M-30 | 10GBASE, CAT8, 2.0m Twinaxケーブル | 2,419円 |
| Windows用NIC | Mellanox ConnectX-4 Lx | PCIe3.0 x8, SFP28ポート * 2 | 3,359円 |
| Ubuntu用NIC | 同上 | 同上 | 同上 |
スイッチを除くと1GbE用の設備と比べてもそこまで高くない印象で、案外負担にならない印象だ。
特にMellanox ConnectX-4 Lxは中古が安く流通しているので、かなり助かる。このNICはQSFP対応の25GbE対応とオーバースペックだが、SFP28とSFP+には互換性があるため問題ない。
むしろSFP+対応で10GbEのX-3は最新のUbuntuに対応させるのに手間が掛かったり、Windows 11が起動しなくなるなどの問題があると聞くため、これが無難な選択肢だろう。しかし軽く見た感じボードメーカーの記載がなく、どこが作ったものなのかは不明だ。
価格的にも2ポートの方が1ポートより安いなど、SFP+対応NICはジャストスペックを狙うより、オーバースペックの方がコストを抑えられ、将来の拡張性も得られて嬉しいかもしれない。
なお、Windows側はx8に空きがなかったため、PCIe 4.0 x4に挿して使っており、Ubuntu側はCPUの制限によりPCIe 5.0 x16がPCIe 4.0 x4にダウングレードされたスロットを使っている。
リンク速度はWindowsはHWiNFOで確認した限り「バージョン: 3.0」「現在のリンク幅: x4」「現在のリンク速度: 8.0GT/s」で、Ubuntuはsudo lspci -vvで確認した限りSpeed 8GT/s, Width x4だった。これだけを見ると10Gbps出ない気もするが、実際のところはどうなのか、この後計測してゆく。
iperf3でWindowsとUbuntu間を計測した結果。
NICやルーターは2.5GbEに対応しているが、1GbEスイッチを挟んでいる関係で1Gbpsが上限となる。接続はすべてCAT6のLANケーブル。
[ ID] Interval Transfer Bitrate
[ 5] 0.00-1.01 sec 119 MBytes 981 Mbits/sec
[ 5] 1.01-2.01 sec 112 MBytes 949 Mbits/sec
[ 5] 2.01-3.00 sec 113 MBytes 950 Mbits/sec
[ 5] 3.00-4.00 sec 113 MBytes 949 Mbits/sec
[ 5] 4.00-5.01 sec 115 MBytes 950 Mbits/sec
[ 5] 5.01-6.01 sec 112 MBytes 949 Mbits/sec
[ 5] 6.01-7.00 sec 113 MBytes 949 Mbits/sec
[ 5] 7.00-8.02 sec 114 MBytes 950 Mbits/sec
[ 5] 8.02-9.01 sec 113 MBytes 949 Mbits/sec
[ 5] 9.01-10.01 sec 113 MBytes 950 Mbits/sec
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval Transfer Bitrate
[ 5] 0.00-10.01 sec 1.11 GBytes 953 Mbits/sec sender
[ 5] 0.00-10.03 sec 1.11 GBytes 949 Mbits/sec receiver
[ ID] Interval Transfer Bitrate Retr Cwnd
[ 5] 0.00-1.00 sec 115 MBytes 962 Mbits/sec 0 471 KBytes
[ 5] 1.00-2.00 sec 112 MBytes 938 Mbits/sec 0 494 KBytes
[ 5] 2.00-3.00 sec 112 MBytes 942 Mbits/sec 0 520 KBytes
[ 5] 3.00-4.00 sec 113 MBytes 946 Mbits/sec 0 549 KBytes
[ 5] 4.00-5.00 sec 112 MBytes 942 Mbits/sec 0 577 KBytes
[ 5] 5.00-6.00 sec 112 MBytes 938 Mbits/sec 0 577 KBytes
[ 5] 6.00-7.00 sec 113 MBytes 946 Mbits/sec 0 577 KBytes
[ 5] 7.00-8.00 sec 112 MBytes 939 Mbits/sec 0 577 KBytes
[ 5] 8.00-9.00 sec 113 MBytes 946 Mbits/sec 0 617 KBytes
[ 5] 9.00-10.00 sec 112 MBytes 942 Mbits/sec 0 646 KBytes
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval Transfer Bitrate Retr
[ 5] 0.00-10.00 sec 1.10 GBytes 944 Mbits/sec 0 sender
[ 5] 0.00-10.00 sec 1.10 GBytes 941 Mbits/sec receiver
Windows側はPCIe 4.0 x4、Ubuntu側は
1GbE環境とルーターが同じだが、これはR86Sが10GbEと2.5GbEの二種類のポートを持っているためだ。
R86SはSFP+ポートが10GbE、RJ45ポートが2.5GbE対応になっている。
[ ID] Interval Transfer Bitrate
[ 5] 0.00-1.01 sec 1.08 GBytes 9.22 Gbits/sec
[ 5] 1.01-2.01 sec 1.10 GBytes 9.36 Gbits/sec
[ 5] 2.01-3.00 sec 1.08 GBytes 9.36 Gbits/sec
[ 5] 3.00-4.01 sec 1.09 GBytes 9.36 Gbits/sec
[ 5] 4.01-5.00 sec 1.08 GBytes 9.36 Gbits/sec
[ 5] 5.00-6.01 sec 1.10 GBytes 9.36 Gbits/sec
[ 5] 6.01-7.01 sec 1.10 GBytes 9.36 Gbits/sec
[ 5] 7.01-8.01 sec 1.08 GBytes 9.36 Gbits/sec
[ 5] 8.01-9.01 sec 1.10 GBytes 9.36 Gbits/sec
[ 5] 9.01-10.02 sec 1.09 GBytes 9.36 Gbits/sec
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval Transfer Bitrate
[ 5] 0.00-10.02 sec 10.9 GBytes 9.35 Gbits/sec sender
[ 5] 0.00-10.02 sec 10.9 GBytes 9.34 Gbits/sec receiver
[ ID] Interval Transfer Bitrate Retr Cwnd
[ 5] 0.00-1.00 sec 256 KBytes 2.09 Mbits/sec 2 1.41 KBytes
[ 5] 1.00-2.00 sec 0.00 Bytes 0.00 bits/sec 1 1.41 KBytes
[ 5] 2.00-3.00 sec 0.00 Bytes 0.00 bits/sec 0 1.41 KBytes
[ 5] 3.00-4.00 sec 0.00 Bytes 0.00 bits/sec 1 1.41 KBytes
[ 5] 4.00-5.00 sec 0.00 Bytes 0.00 bits/sec 0 1.41 KBytes
[ 5] 5.00-6.00 sec 0.00 Bytes 0.00 bits/sec 0 1.41 KBytes
[ 5] 6.00-7.00 sec 0.00 Bytes 0.00 bits/sec 1 1.41 KBytes
[ 5] 7.00-8.00 sec 0.00 Bytes 0.00 bits/sec 0 1.41 KBytes
[ 5] 8.00-9.00 sec 0.00 Bytes 0.00 bits/sec 0 1.41 KBytes
[ 5] 9.00-10.00 sec 0.00 Bytes 0.00 bits/sec 0 1.41 KBytes
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval Transfer Bitrate Retr
[ 5] 0.00-10.00 sec 256 KBytes 210 Kbits/sec 5 sender
[ 5] 0.00-10.00 sec 0.00 Bytes 0.00 bits/sec receiver
[ ID] Interval Transfer Bitrate
[ 5] 0.00-1.01 sec 1.11 GBytes 9.51 Gbits/sec
[ 5] 1.01-2.01 sec 1.11 GBytes 9.50 Gbits/sec
[ 5] 2.01-3.01 sec 1.10 GBytes 9.49 Gbits/sec
[ 5] 3.01-4.00 sec 1.10 GBytes 9.49 Gbits/sec
[ 5] 4.00-5.01 sec 1.11 GBytes 9.50 Gbits/sec
[ 5] 5.01-6.01 sec 1.11 GBytes 9.50 Gbits/sec
[ 5] 6.01-7.01 sec 1.11 GBytes 9.49 Gbits/sec
[ 5] 7.01-8.01 sec 1.10 GBytes 9.49 Gbits/sec
[ 5] 8.01-9.00 sec 1.10 GBytes 9.49 Gbits/sec
[ 5] 9.00-10.01 sec 1.11 GBytes 9.49 Gbits/sec
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval Transfer Bitrate
[ 5] 0.00-10.01 sec 11.1 GBytes 9.49 Gbits/sec sender
[ 5] 0.00-10.01 sec 11.1 GBytes 9.49 Gbits/sec receiver
[ ID] Interval Transfer Bitrate Retr Cwnd
[ 5] 0.00-1.00 sec 1.10 GBytes 9.43 Gbits/sec 0 1.33 MBytes
[ 5] 1.00-2.00 sec 1.10 GBytes 9.42 Gbits/sec 0 1.33 MBytes
[ 5] 2.00-3.00 sec 1.10 GBytes 9.42 Gbits/sec 0 1.33 MBytes
[ 5] 3.00-4.00 sec 1.09 GBytes 9.41 Gbits/sec 0 1.33 MBytes
[ 5] 4.00-5.00 sec 1.10 GBytes 9.42 Gbits/sec 0 1.54 MBytes
[ 5] 5.00-6.00 sec 1.10 GBytes 9.42 Gbits/sec 0 1.54 MBytes
[ 5] 6.00-7.00 sec 1.09 GBytes 9.41 Gbits/sec 0 1.54 MBytes
[ 5] 7.00-8.00 sec 1.10 GBytes 9.42 Gbits/sec 0 1.54 MBytes
[ 5] 8.00-9.00 sec 1.10 GBytes 9.41 Gbits/sec 0 1.54 MBytes
[ 5] 9.00-10.00 sec 1.10 GBytes 9.42 Gbits/sec 0 1.54 MBytes
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval Transfer Bitrate Retr
[ 5] 0.00-10.00 sec 11.0 GBytes 9.42 Gbits/sec 0 sender
[ 5] 0.00-10.00 sec 11.0 GBytes 9.41 Gbits/sec receiver
| 回線状況 | Windows→Ubuntu(上り) | Windows→Ubuntu(下り) | Ubuntu→Windows(上り) | Ubuntu→Windows(下り) |
|---|---|---|---|---|
| 1GbE | 953 Mbps | 949 Mbps | 944 Mbps | 941 Mbps |
| 10GbE(Windowsドライバなし) | 9.35 Gbps | 9.34 Gbps | 210 Kbps | 0 bps |
| 10GbE(Windowsドライバあり) | 9.49 Gbps | 9.49 Gbps | 9.42 Gbps | 9.41 Gbps |
Windowsにドライバがない状況だとiperf3では何故かまともに疎通できない状態だった。何故かは不明。SFTPを使ったファイル転送は出来たのでiperf3との相性が悪かった可能性もあるが、ドライバを入れて改善したところから、ドライバレスでは何かしら不都合がある可能性がある。
またWindowsよりUbuntuの方が若干速度が落ちる傾向があることも分かった。
デフォルトではIB（InfiniBand）だからETH（Ethernet）にモード変更が必要というのをネットで見ていたが、私の場合そんなことはなかった。ひょっとしたら中古なので設定が書き換えられたままだったのかもしれない。
Ubuntu 24.04.3 LTSではNICを挿すだけで動いたので特に何もしていない。デフォルトでETH動作だった。
こちらもデフォルトでETH動作で、挿すだけでも動いた。
しかしConnectX-4用のドライバを入れることで性能が改善した。具体的にはiperf3で受信速度が0bpsだったのが9.5Gbpsくらいになった。
メーカー不詳のMellanox ConnectX-4 Lxボードだ。PCIe3.0 x8でSFP28ポートが二つ付いている。
Windows用とUbuntu用で二つ買っている。2ポートあるのは2ポートの方が安かったから。
ヒートシンクが付いてたり、SFP+用の長いソケットがついていたり、放熱用なのか穴が開いていたり、中々厳つい。
SFP+対応NICはショートブラケットが多く、ロングブラケットがないという話も聞くが、安心のロングブラケット入りを買ったので、ロングブラケットがちゃんと付いていた。
中身を取り出したところ。
ショートブラケットとロングブラケットでネジが異なるのだが、ロングの用のネジもちゃんと付いていて嬉しかった。というのも、このボードは中古なので不必要なパーツは紛失していても不思議がないからだ。
このNICをあてがう為だけに存在するようなPCIeレーンを解き放つ時が来た。見た目はx16だが、CPUが貧弱なのでx4しか出せない。
差し込んでみると中々いい感じだ。
いつも思うのだが、PCIeカードの窪みはケーブルを通すためにあるのだろうか？私はよくケーブルを通すのに使っていて、この写真でもケーブルを通している。
SFP+ジャックがいい感じに光る見た目になった。
MikroTik CRS305-1G-4S+INという、Amazonで売られている10GbE対応SFP+ジャック付きのイーサネットスイッチだ。Cloud Switch seriesとあるので、データセンター向け製品なのかもしれない。そもそもSFP+端子そのものがコンシューマー向けではないというのもある気はするが…ｗ
こちらは新品で、中には簡単なマニュアルと本体、ACアダプタが入っていた。
外観はこんな感じ。ファンレスでパンチホールが沢山空いている。特に発熱のあるSFP+周りに穴が多い。PoE給電にも対応しているようだが、我が家には対応設備がなかった。
背中にはアースとAC入力が二つあった。どうやら電源を多重化し、片方が死んでも死なないようにするための仕組みらしい。RTX830にはなかった気がするので、こちらの方がよりハイグレードな設計といえるだろう。
裏面には壁にぶら下げる穴みたいなのもあった。
側面にはインジゲーターがあり、疎通状況などが確認できる仕組みになっていた。いかにも熱くなりそうなマークも目を引くポイントだ。10GbEは発熱が凄いと聞くので、恐らくその関係だろう。
なお今のところそんなに熱くなってはいない。
起動するとめっちゃ青く光る。
10GtekのDACケーブル。両端がSFP+端子になっているものをTwinaxケーブルというらしい。
こんな感じの袋に入っている。
中身はこんな感じ。端子がごつく、中の基板がむき出しで見えるのが面白い。
因みにこれは30cmのケーブルで、ケーブル延長が30cmだと思ったら、端子部分まで含めて30cmだったので使い物にならなかったやつだ。短すぎるケーブルを買う場合は注意した方がいいだろう。
マシンに差し込んだところ。金属端子がカッコいい感じだ。
まずは元々使っていた玄人志向 GBE2.5-PCIE（Realtek RTL8125BG）を抜く。これはマザボ側のインターフェースが不安定なので使っていたカードだ。WindowsとIntelのネットワークインターフェースはここ数年相性が最悪レベルなのが困りものだ。
次に今回買ったNICを挿す。買う前から解ってはいたが、見事にスロットからはみ出ている。
こちらは抜き取ったRJ45端子のNIC(2.5GbE)。
大まかな外観はこんな感じになった。逸般の誤家庭には程遠いが、それっぽさはあり、個人的には満足している。
しかしR86Sのファンはお世辞にも長生きしそうにない上に、凄い勢いでファンに埃が詰まっていっているのもあり、このまま使っていくのならば、ちゃんとしたクーラーを用意した方がいい気配がしている。
配線状況を図にするとこんな感じ。WiFi APを2.5GbEや10GbEに対応させることも考えたが、SFP+に対応したものは巨大すぎるので置き場所に困るし、SFP+とRJ45の変換は端子が90度に達するとも聞くので、運用できる気がしない。2.5GbEに絞ってみても高い端末や、やけにでかい端末しか見つからなかったので諦めた。
特に関係ないが、おまけで物理ネットワーク全体と言う事で、現在のデスク風景も残しておく。
機材コストはそこそこしたものの、思ったよりトラブルなく移行できたのは良かった。
PCIeのリンク速度が8GT/sだったため、10Gbps出るかどうか懐疑的だったが、実効速度としては9.5Gbps出ており、1Gbps時代も950Mbpsだったことを考えればフルで出ていると考えて支障ない数値だ。8GT/sとは一体何なのかという感じだが、深く考えないでおこう。
ファイル転送速度も爆発的に上がり、LAN内でNASを運用する場合にも支障がだいぶ減った。とはいえ、流石にローカルのNVMeと比較すると全然物足りない速度ではある。
| 1GbE時代のファイル転送速度 | 10GbEになった後のファイル転送速度 |
|---|---|
 |
 |
ストレージ面ではSATA IIIの速度が6Gbpsであるため、10Gbpsになったことにより、LAN内でSATAを扱う場合に遅延が無くなったと言える。NVMeSSDは7GByte/sとかなので、全く足りないがSATAを扱う場合は十分な速度といえるだろう。NVMeSSDをネットワーク越しに扱う場合には100GbEクラスが必要になってくると思われるが、ここまで来るとHPC(High Performance Computing)クラスになると思われるので、流石にやりすぎだとは思う。
但し実現自体は不可能ではなさそうで、アリエクでは100GbE対応NICであるMellanox MCX455A-ECAT ConnectX-4 EDR+100GbEが1.3万程度で売られているし、10Gtekも4～5000円で100GBASEのDACを売っているので、その気になれば構築は不可能ではなさそうだ。但しスイッチはMikroTik CRS504-4XQ-INでは13万円ほどし、ルーターは見つけることが出来なかったので、100GBASE対応NICを挿した適当なマシンでルーターPCを組む必要があると思われる。
今回の対応ではルーターまでが10Gbpsとなったため、宅内にボトルネックが仮にあればWANの速度も増えるかと思ったが、そんなことはなく、普通に据え置きで終わった。正直平均以上出てるので、ないとは思っていたが、まぁ、そうだよねという…ｗ
それはさておきとして、一旦機材面では整ってきたと思うので、次はネットワーク機器やサーバーの監視体制を整えていきたいところだ。
Amazonや公式サイトにある情報が本当に正しいとは限らないので実地検分。
# これでCPUの情報が取れる
cat /proc/cpuinfo
# これでメモリの情報が取れる
opkg install dmidecode
dmidecode -t 17
# これでCPU, NICの情報が取れる
opkg install hwinfo
hwinfo
# これでeMMCのベンダ情報が取れる
cat /sys/class/mmc_host/mmc0/mmc0:0001/name
cat /sys/class/mmc_host/mmc0/mmc0:0001/manfid
cat /proc/cpuinfoの結果から取得した情報。
model name : Intel(R) Celeron(R) N5105 @ 2.00GHz
dmidecode -t 17の結果から取得した情報。
MicronのLPDDR4でDDR4-3200相当であるとわかる。
Physical Memory Array
Location: System Board Or Motherboard
Use: System Memory
Error Correction Type: None
Maximum Capacity: 8 GB
Error Information Handle: Not Provided
Number Of Devices: 2Memory Device
Array Handle: 0x003A
Size: 4 GB
Form Factor: Row Of Chips
Locator: Controller0-ChannelA
Type: LPDDR4
Speed: 3200 MT/s
Manufacturer: Micron Technology
hwinfoの結果から取得した情報。
pci 0x125cはI226-VなのでIntel Ethernet controller I226-V
Hardware Class: network
Model: "Intel Ethernet controller"
Vendor: pci 0x8086 "Intel Corporation"
Device: pci 0x125c
SubVendor: pci 0x8086 "Intel Corporation"
SubDevice: pci 0x0000
Revision: 0x04
Driver: "igc"
Driver Modules: "igc"
Device File: eth2
以前分解したときのラベルと、hwinfoの結果から取得した以下の情報と突き合わせるとMellanox ConnectX-3 En10*2 Gigabit Ethernet CX341Aであることが分かる。
Hardware Class: network
Model: "Mellanox MT27500 Family [ConnectX-3]"
Vendor: pci 0x15b3 "Mellanox Technologies"
Device: pci 0x1003 "MT27500 Family [ConnectX-3]"
SubVendor: pci 0x15b3 "Mellanox Technologies"
SubDevice: pci 0x0113
Driver: "mlx4_core"
Driver Modules: "mlx4_core"
Device File: eth3
以下の結果から、name: SCA128, manfid: 0x0000dfであることから、メーカー不詳のSCA128という製品であることが分かる。ググってもメーカー情報は不明だった。
cat /sys/class/mmc_host/mmc0/mmc0:0001/name
cat /sys/class/mmc_host/mmc0/mmc0:0001/manfid
公式サイト？の情報やAmazonの情報と比べると微妙に差異があり、また、書いてない情報も取れたので調べてよかったなと思った。
| 構成 | 製品 | 備考 |
|---|---|---|
| CPU | Intel Celeron N5105 | 6T6C, 2.00GHz, TDP10W |
| MEM | Micron | LPDDR4-3200 4GB * 2 |
| Storage | SCA128 | 128G EMMC |
| NIC | Intel Ethernet controller I226-V | RJ45 2.5GbE * 3 |
| NIC | Mellanox ConnectX-3 En10*2 Gigabit Ethernet CX341A | SPF+ 10GbE * 2 |
前回2024/01/25に更新したサーバー機（サブマシン）だったが、今回サーバーとして運用することになったのと、将来的に10GbEを導入した時の投資としてネットワークスペックを上げるなどを目的とし、更新を実施した。
POST時にメモリエラーが出るので近日中にメモリは交換予定だ。幸い相性保険に入っていたので追加費用は出ない見込み。
| 構成 | 製品 | 更新後 |
|---|---|---|
| OS | Ubuntu 24.04.3 LTS | 変更なし |
| CPU | AMD Ryzen 5 5600G | AMD Ryzen 5 8500G |
| MEM | CFD W4U2666CS-16G | crucial CP2K16G60C36U5W |
| M/B | ASRock A520M-ITX/ac | ASRock B850I Lightning WiFi |
| CPU Cooler | Cooler Master Hyper H412R | Cooler Master Hyper 411 Nano RR-H410-25PK-R1 |
| PSU | SILVERSTONE SST-ST30SF-V2 | 変更なし |
| Primary SSD | Crucial P1 CT500P1SSD8JP | 変更なし |
| Case | Thermaltake Core V1 | 変更なし |
| Front Fan | Thermaltake Pure 20 | 変更なし |
買ったもの。全部神戸市内で購入。というかメインマシン更新時と同じくソフマップで買ってきた。ここにしかITXマザーがなさそうだったのが理由だ。
メモリがやけにゲーミングだが、他が売り切れていたので仕方がなくこれにした。
この時はまだCPUクーラーが適合しないとは夢にも思っていなかった。何故ならAM4とAM5はCPUブラケットに互換性があるとされていたからだ。
箱の中身。WiFiのアンテナや、温度センサ、M2SSDネジ、ケーブルバンド、SATAケーブル辺りがあった。写真には写っていないがASRockのデカいシールも入っていた。
表面。CPUソケットの主張が激しい。
AM5からはLGAに変わっているためマザボ側にトゲが生えている。ピン折れリスクの観点からPGAの方が好きだったので残念だ。
とはいえ、PGAは面積当たりのピン数の制約が強いのでスペックアップのためには仕方ないだろう。面積当たりのピン数はLGAの方が有利だろうし。
裏面。裏面NVMeスロットが復活していた。これはA320M-ITXにはあったけどA520M-ITX/acではなくなっていた要素だ。
恐らくNVMeスロットを2つにする上で仕方がなかったのだろう。確かASUSも裏面に実装していたと思う。
CPUバックプレートを差し込もうとしたところ、なんと入らなかった。寸法は同じだったが穴のサイズが合っていなかった。
更に言うとバックプレートが剥がせなくなっていた。マザーボードに完全に貼り付けてあった。
側面。2.5Gの文字がまぶしい。今回最大の目的はこれである。
右が今回買った方で、左が今まで使ってた方。なんか見た目がかっこよくなっていた。
PGAからLGAに変わった関係で背が低くなっている。ソケットアサイン用の窪みが出来た関係もあると思うが、接点の密度は左程増えていないようにも見える。むしろ減っていても不思議がない。
まさか手持ちのが使えないとは思ってなかったので、組み立て作業はこれが届くまで一時停止する。
こちらは入手困難であったため、Amazonで調達した。17時ごろに見たら翌朝配送と書かれており、私はこの時、映画を見るスケジュールで埋まっていて当日中に手に入れる手立てがなかったからだ。
翌日12時半に到着して、無事パーツを組むことが出来るようになった。エアフローをサイドフロー型向けに最適化しておきたいので、このパーツは外せなかった。なんか微妙な奴ならソフマップにもあったのだが、微妙なのは使いたくなかった。こういうものには納得が必要だ。
付属品はファンとヒートシンクにIntel用のバックパネルとリテンションキット、CPUグリス、マニュアルなどだった。
AMDのバックパネルがないのが気になったが、そのまま挿すことが出来た。これは賢いなぁと思ったが、メーカーごとに自由なバックプレートを作れないのは差別化要素を失わさせる要因にもなるため、Intelの方が多様性に資するなとは思った。
ファンの新旧比較。左が新しい方、右が古い方。新しい方が風量があり、やや五月蠅かった。古い方は風量がやや少ない代わりに静かだった。
ヒートシンクの新旧比較。銀色が古い方、黒色が新しい方。
違いとしては、まず色が違うほか、台座のヒートシンクが小さくなっているのと、台座の高さも減っていた。
また、若干ヒートシンクの角が削れており、これはドライバーでネジを占めるときのクリアランスとして便利だった。以前はヒートシンクが削れていたのでイマイチだった。
グリスはCoolerMasterのコーポレートカラーだったが、なんかキモいので拭き取って忘れることにした。実際にはNoctuaのグリスを塗った。
中身。ヒートシンク付きのごついゲーミングメモリが目立つが、以前と比べ黒くなった。大体CPUクーラーのせい。
外観。ぶっちゃけ変わる要素がないので、ほぼ変わっていない。変化としてはシールが増えているところだ。しかし今回はRADEONのシールがなかったので、Ryzenのシールのみとなり、シールの枚数が奇数になってしまった。
左から右にシールを増やしているが、Athlonのシールがあるマシンもそうそうなさそうなので、結構独特な存在だと思っている。
今回の更新作業は予期せぬトラブルで自宅サーバーが予想外長時間止まってしまった。本来は16時開始17時終了でサーバーを再開する予定が、CPUクーラー手配の関係などで翌日15時まで、ずれ込んでしまった。まぁ、こういうのも、また自宅サーバーの醍醐味だろうという気はするので、特に気にしてはいないし、むしろ停止中にメンテ画面に切り替えるためのDNS変更スクリプトとかは作っておいた方がいいだろうなという気付きを得られたりもした。
ひとまず本質的なスペックとしてはさして上がっていないと思われるが、拡張性で言えばマザボのスペックが最新鋭になり、ストレージスロットがやや増えているのもあり、将来的な拡張には耐えてくれるだろうし、この規模の更新は当面しなくて済むだろう。このベーススペックで5年、あるいはそれ以上持つことを期待したいところだ。
ただ、このマザーボードを使ってCPU(Ryzen 7 9800X3D)が壊れたとか、不具合系の話もまことしやかに聞くのでやや心配だが、そこは見守っていきたい。
OCNバーチャルコネクト環境でIPv6サーバーをポート443で公開した時にやったことを派生させて更にIPv4にも対応させるプラン。
OCNバーチャルコネクトのIPoEでIPv4 over IPv6のMAP-E環境だと、IPv4ではWell-known portsが開けないが、PPPoEを使って取得したIPv4であれば開けるので、これとIPoE側のIPv6の併用でデュアルスタックでWell-known portsの開放を行い、サーバーを運用できるようにするのが目的だ。
| 環境 | 内容 |
|---|---|
| ISP | OCN光 |
| ISP契約 | OCN 光 with フレッツ マンション・スーパーハイスピード 隼・プラン1・西日本 |
| ISP接続方式 | OCNバーチャルコネクト(IPoE, MAP-E) |
| RouterOS | OpenWrt 24.10.0 |
| ServerOS | Ubuntu 24.04.3 LTS |
| HTTPD | nginx 1.26.1 |
| ドメインレジストラ | Value Domain |
ufwではv4にも穴が開いている状態とする
listen 443 ssl;を追記して保存する/etc/iproute2/rt_tablesを開き次のようにpppoeの行を追加、保存
#
# reserved values
#
128 prelocal
255 local
254 main
253 default
300 pppoe
0 unspec
#
# local
#
#1 inr.ruhep
service network restart
10、Override IPv4 routing tableをpppoe (300)にする
1にするwan_pppoeにし、MasqueradingとMSS clampingにチェックを入れ、Covered networksでwanpppを選択し保存する
wan_pppoeを追加し、保存する
wan_pppoeが設定されていることを確認する。設定されていなかったら設定する
lanに、SourceをサーバーのIPにする（例：192.168.1.5/32）
pppoe (300)を設定し、保存する
IPv4 only、Source zoneをwan_pppoe、External portを443、Internal IP addressを転送先のサーバーIP、Internal portを443にして、保存する
curl -4 -v https://example.com
/etc/hotplug.d/ifaceに40-pppoeというファイルを755で作り、以下の内容を記述する。
#!/bin/sh
[ -n "$DEVICE" ] || exit 0
[ "$ACTION" = ifup ] || exit 0
[ "$INTERFACE" = wanppp ] || exit 0
vdpw=ここにDDNS更新用のパスワード
pppoeaddr=$(ip -4 addr show pppoe-wanppp | head -2 | tail -1 | awk '{print $2}')
logger -t "DDNS - PPPoE IP" $pppoeaddr
# hoge.example.comに対して更新リクエストを飛ばす例
logger -t "DDNS - DOMAIN: hoge" $(wget -O - "https://dyn.value-domain.com/cgi-bin/dyn.fcg?d=example.com&p=$vdpw$&h=hoge&i=$pppoeaddr")
# When making requests for multiple domains, wait 60 seconds between each request
このスクリプトはhotplugイベントが発生したときにファイルパス順に呼ばれるスクリプトらしい。
ひとまずデバイスでなく、インターフェイスが起動したときで、かつインターフェース名がwanpppの時に実行されるように組んである。
注意点として、このエンドポイントはレートリミットがシビアで、60秒以内に送ると503を返してくるようなので、複数回投げる場合はsleep 61とかして間隔をあけると良さそうだ。数が増えてきたらバリュードメインAPIのDNS設定APIを利用した方が早いだろう。
ただしこのAPIはTTLの制御に難があり、処理方法によっては3600秒に固定される罠が潜んでいるので注意が必要だ。
/var/log/ufw.logにログがあればufwで穴をあける（まずこれはない）PPPoEインターフェース（wanppp）の設定を開き、Advanced SettingsからUse DNS servers advertised by peerのチェックを外すと直る。
IPv4, v6のデュアルスタックに出来たのはいいが、幾つかの端末で繋いだところIPv4側に流れるケースがあった。メインのv6でなく、オプションのv4に行くという状況はやや残念だ。
構成的にもマルチセッションという微妙な形態で、v4とv6でインターフェースが二系統あり、セキュリティもNATとFWがあり、なかなか複雑な状態になってしまった。
Mastodonにおいてはv4IPのインスタンス（兵庫丼）との疎通はTLレベルでは出来たものの、画像が出なくなるという頭が痛い問題に出会った。
Misskey.ioからは疎通できず、こちらからはユーザープロフィールまではアクセスできるがフォローを押しても音沙汰がない。
結論としてはリッチなアプリケーション通信を伴う用途において、この方式は向かない気がした。恐れくこれはルーターより外側がIPoEとPPPoEで別系統になっている関係で、通信が混乱して上手くいかないパターンがあるのではないかと感じている。
DDNSも制約が厳しいし、Value DomainのAPIはあるだけマシではあるものの、超絶使いづらい問題もあり、この環境においてのデュアルスタックはあきらめようと思った。
まぁいい勉強にはなったので、そのうち何かに活かせるだろう、きっと。
OpenWrtからValue-Domainに複数サブドメインのDDNSを行うツールを作ったのもあり、IPv4が変わったときも自動で切り替えることでダウンタイムを減らす運用ができたので、今のところ不満はない。
ただFediverseで繋がらないところは繋がらないので諦めることにした。
7月31日に立てたMastodon作成ロードマップの最後である、自宅サーバーでMastodonをセルフホスティングするのを達成したので、そのログをここに記す。
Ubuntu実機AMD64環境でDockerを使わず、IPv6シングルスタックで構成している。
自宅サーバーを使ってIPv6シングルスタックで通信を待ち受ける方法はOCNバーチャルコネクト環境でIPv6サーバーをポート443で公開した時にやったことの方に書いている。
Ubuntu実機AMD64環境
| Env | Ver |
|---|---|
| Ubuntu | 24.04.3 LTS |
| nginx | 1.26.1 |
| Mastodon | v4.4.3 |
| Ruby | 3.2.3 |
| ruby-build | 20250811 |
| rbenv | 1.3.2-10-gd1a19a3 |
以下のコマンドを流す
sudo apt update
sudo apt install -y \
imagemagick ffmpeg libvips-tools libpq-dev libxml2-dev libxslt1-dev file git-core \
g++ libprotobuf-dev protobuf-compiler pkg-config gcc autoconf \
bison build-essential libssl-dev libyaml-dev libreadline6-dev \
zlib1g-dev libncurses5-dev libffi-dev libgdbm-dev \
nginx redis-server redis-tools postgresql \
certbot python3-certbot-nginx libidn11-dev libicu-dev libjemalloc-dev \
# 最新版を入れないとうまくいかない
wget https://github.com/rbenv/ruby-build/archive/refs/tags/v20250811.tar.gz
tar -xzf v20250811.tar.gz
sudo PREFIX=/usr/local ./ruby-build-20250811/install.sh
rm v20250811.tar.gz
rm -Rf ruby-build-20250811
# aptではサポート切れの化石が入るのとnvmで入れたのは自分しか使えないので新しいのをグローバルに入れる
curl -fsSL https://deb.nodesource.com/setup_24.x -o nodesource_setup.sh
sudo bash nodesource_setup.sh
apt install -y nodejs
rm nodesource_setup.sh
corepack enable
# メンテナンスでめっちゃ使うのでサービスユーザーにはせず、ログイン可能なユーザーとして作る
adduser --disabled-password mastodon
/etc/redis/redis.confを開きrequirepassのコメントを外し、パスワードを設定
sudo service redis restart
sudo -u postgres psqlでポスグレに入り、ユーザーを作る。ポスグレは不慣れで同時にPW設定する方法が判らなかったので別建てで設定している
CREATE USER mastodon CREATEDB;
ALTER ROLE mastodon WITH PASSWORD 'パスワード';
\q
実際にはかなり行ったり来たりしてるので一部の手順には誤りが含まれている可能性がある。
mastodonユーザーにスイッチしてインストール作業を続行
# Mastodon本体の導入
sudo su - mastodon
git clone https://github.com/mastodon/mastodon.git live
# 超重要、cd忘れててもなんかそれっぽく進むが、以後すべて破綻する
cd live
git checkout $(git tag -l | grep '^v[0-9.]*$' | sort -V | tail -n 1)
git clone https://github.com/rbenv/rbenv.git ~/.rbenv
echo 'export PATH="$HOME/.rbenv/bin:$PATH"' >> ~/.bashrc
echo 'eval "$(rbenv init -)"' >> ~/.bashrc
exec bash
# 動かないやつなのでコメントアウト
# 依存関係のインストールとセットアップでやった内容をこっちでやってもいいかもしれない
# git clone https://github.com/rbenv/ruby-build.git "$(rbenv root)"/plugins/ruby-build
# ここでエラーが出たら何かが間違っているのでやり直し
RUBY_CONFIGURE_OPTS=--with-jemalloc rbenv install
# bundleがないとか、rubyのバージョンが存在しないとかエラーが出たら何かが間違っているのでやり直し
bundle config deployment 'true'
bundle config without 'development test'
bundle install -j$(getconf _NPROCESSORS_ONLN)
yarn install
# 色々尋ねられるので適当に進める
RAILS_ENV=production bin/rails mastodon:setup
デーモン周りの設定をする
# 静的ファイルをnginxに見させるために権限を設定
sudo chmod o+x /home/mastodon
# デーモンの登録と起動
sudo cp /home/mastodon/live/dist/mastodon-*.service /etc/systemd/system/
sudo systemctl daemon-reload
sudo systemctl enable --now mastodon-web mastodon-sidekiq mastodon-streaming
sudo service mastodon-web start
sudo service mastodon-sidekiq start
sudo service mastodon-streaming start
nginxの設定を書く
map $http_upgrade $connection_upgrade {
default upgrade;
'' close;
}
upstream backend {
server [::1]:3000 fail_timeout=0;
}
upstream streaming {
# Instruct nginx to send connections to the server with the least number of connections
# to ensure load is distributed evenly.
least_conn;
server 127.0.0.1:4000 fail_timeout=0;
# Uncomment these lines for load-balancing multiple instances of streaming for scaling,
# this assumes your running the streaming server on ports 4000, 4001, and 4002:
# server 127.0.0.1:4001 fail_timeout=0;
# server 127.0.0.1:4002 fail_timeout=0;
}
proxy_cache_path /var/cache/nginx levels=1:2 keys_zone=CACHE:10m inactive=7d max_size=1g;
server {
listen [::]:443 ssl http2;
server_name <ドメイン>;
ssl_certificate /etc/letsencrypt/live/<証明書のパス>/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/live/<証明書のパス>/privkey.pem;
ssl_protocols TLSv1.2 TLSv1.3;
# You can use https://ssl-config.mozilla.org/ to generate your cipher set.
# We recommend their "Intermediate" level.
ssl_ciphers CDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA84:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA38:DHE-RSA-CHACHA20-POLY1305;
ssl_prefer_server_ciphers on;
ssl_session_cache shared:SSL:10m;
ssl_session_tickets off;
keepalive_timeout 70;
sendfile on;
client_max_body_size 99m;
root /home/mastodon/live/public;
gzip on;
gzip_disable "msie6";
gzip_vary on;
gzip_proxied any;
gzip_comp_level 6;
gzip_buffers 16 8k;
gzip_http_version 1.1;
gzip_types text/plain text/css application/json application/javascript text/xml application/xml application/xmlrss text/javascript image/svg+xml image/x-icon;
gzip_static on;
location / {
try_files $uri @proxy;
}
# If Docker is used for deployment and Rails serves static files,
# then needed must replace line `try_files $uri =404;` with `try_files $uri @proxy;`.
location = /sw.js {
add_header Cache-Control "public, max-age=604800, must-revalidate";
add_header Strict-Transport-Security "max-age=63072000; includeSubDomains";
try_files $uri =404;
}
location ~ ^/assets/ {
add_header Cache-Control "public, max-age=2419200, must-revalidate";
add_header Strict-Transport-Security "max-age=63072000; includeSubDomains";
try_files $uri =404;
}
location ~ ^/avatars/ {
add_header Cache-Control "public, max-age=2419200, must-revalidate";
add_header Strict-Transport-Security "max-age=63072000; includeSubDomains";
try_files $uri =404;
}
location ~ ^/emoji/ {
add_header Cache-Control "public, max-age=2419200, must-revalidate";
add_header Strict-Transport-Security "max-age=63072000; includeSubDomains";
try_files $uri =404;
}
location ~ ^/headers/ {
add_header Cache-Control "public, max-age=2419200, must-revalidate";
add_header Strict-Transport-Security "max-age=63072000; includeSubDomains";
try_files $uri =404;
}
location ~ ^/packs/ {
add_header Cache-Control "public, max-age=2419200, must-revalidate";
add_header Strict-Transport-Security "max-age=63072000; includeSubDomains";
try_files $uri =404;
}
location ~ ^/shortcuts/ {
add_header Cache-Control "public, max-age=2419200, must-revalidate";
add_header Strict-Transport-Security "max-age=63072000; includeSubDomains";
try_files $uri =404;
}
location ~ ^/sounds/ {
add_header Cache-Control "public, max-age=2419200, must-revalidate";
add_header Strict-Transport-Security "max-age=63072000; includeSubDomains";
try_files $uri =404;
}
location ~ ^/system/ {
add_header Cache-Control "public, max-age=2419200, immutable";
add_header Strict-Transport-Security "max-age=63072000; includeSubDomains";
add_header X-Content-Type-Options nosniff;
add_header Content-Security-Policy "default-src 'none'; form-action 'none'";
try_files $uri =404;
}
location ^~ /api/v1/streaming {
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto $scheme;
proxy_set_header Proxy "";
proxy_pass http://streaming;
proxy_buffering off;
proxy_redirect off;
proxy_http_version 1.1;
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection $connection_upgrade;
add_header Strict-Transport-Security "max-age=63072000; includeSubDomains";
tcp_nodelay on;
}
location @proxy {
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto $scheme;
proxy_set_header Proxy "";
proxy_pass_header Server;
proxy_pass http://backend;
proxy_buffering on;
proxy_redirect off;
proxy_http_version 1.1;
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection $connection_upgrade;
proxy_cache CACHE;
proxy_cache_valid 200 7d;
proxy_cache_valid 410 24h;
proxy_cache_use_stale error timeout updating http_500 http_502 http_503 http_504;
add_header X-Cached $upstream_cache_status;
tcp_nodelay on;
}
error_page 404 500 501 502 503 504 /500.html;
}
なんやかんやあり色々苦戦したが、無事立ち上がってくれて何よりだった。
立ち上がった直後。
そして現在。こうやって動いているのを見ると感慨深い。
実は中学生のころから自宅サーバーを立てるという夢を持っており、こうやって実際に公開できたことは感慨深い。実際のところ、実験用の小規模サーバーや、SHOUTcastサーバーだとか、シンクライアント用のSSHサーバーみたいなのは作った経験があり、いずれも外に出していたのでサーバーを作った経験が全くない、というわけではないのだが、監視環境を整えたり、IPv4が実用困難な環境で、IPv6に挑戦してみたりと、ここまで本格的にやったことはなかったのもあり、個人的には結構達成感がある。
3000番はGrafanaをはじめ、様々なNode.js系のポートと干渉するため変えておく。
/etc/systemd/system/mastodon-web.serviceのEnvironment="PORT=3000"を変えることでWeb側のポートが変えられる。Environment="BIND=[::1]"とすることでIPv6で待ち受けられる/etc/systemd/system/mastodon-streaming.serviceのWants=mastodon-streaming@4000.serviceの4000の部分を変えることで、Streaming側のポートも変えられるsudo systemctl daemon-reload
sudo service mastodon-web restart
sudo service mastodon-streaming restart
sudo service nginx restart
基本的にどこかの手順が間違ってるのでしつこくやり直すことで改善する。
以下の内容で修正すると増やせる。
class StatusLengthValidator < ActiveModel::Validator
- MAX_CHARS = 500
+ MAX_CHARS = 50000
正直このファイルは直さなくても動くし、直しても、ほぼ意味がなさそうなので、直す必要はないかもしれない。
- maxChars: state.getIn(['server', 'server', 'configuration', 'statuses', 'max_characters'], 500),
+ maxChars: state.getIn(['server', 'server', 'configuration', 'statuses', 'max_characters'], 50000),
変更直後は投稿画面の初期表示に500と出ていて、数文字打つと50000文字に変化する状態だったが、一日くらい経過すると初期値が50000に変わっていたのでキャッシュか何かが悪さをしていた可能性がある。
IPv6と疎通してないところは仕方がないね。AAAAレコード持ちでcurl -6 -v https://example.comしても疎通する場所でも起きることがあるが原因は不明。
兵庫丼でも偶に遭遇してたので、そういうものだと割り切るしかない。IPv4滅ぶべし、慈悲はない。
APIのレートリミットにかかっているせいっぽい。5分間に300リクエストまでと、かなり渋い。信用するIPを指定することで回避可能らしい。
.env.productionを開き、前述の資料に書かれている信頼できるIPを列挙した後に、自分のIPv6プレフィクス（aaaa:bbbb:cccc:dddd::/64を自分のプレフィクスに置き換え）を追加し、再起動しておいた。これで緩和されると良いのだが、出先では使えないと思うのでどうするか…。
TRUSTED_PROXY_IP=127.0.0.1/8,::1/128,10.0.0.0/8,172.16.0.0/12,192.168.0.0/16,fc00::/7,aaaa:bbbb:cccc:dddd::/64
ドキュメントを読む限り、アカウントIDで縛る処理がどこかにあるようなので、自分のIDを除外できれば出先でも起きなくなり、更に良さそうだが、やり方はよくわからなかった。
調べた限りconfig/initializers/rack_attack.rbの中でやっているようなので、暇なときに見てみたいとは思う。
Mastodonは標準でPrometheusに対応しているので、Exporterの有効化設定を見ながら設定していく。
まず.env.productionを開き、以下の二行を追記し、再起動する。これによってMastodonWebのExporterが有効化され、ローカルホストで動くようになるようだ。Streamingの方は設定せずとも、元から有効になっている模様。
MASTODON_PROMETHEUS_EXPORTER_ENABLED=true
MASTODON_PROMETHEUS_EXPORTER_LOCAL=true
再起動したらcurl http://localhost:{Streamingのポート番号}/metricsとcurl http://localhost:9394/metricsで動いていることを確認。
次にPrometheusのscrape_configsに以下を追記し、Prometheusを再起動する。
- job_name: 'mastodon-web'
static_configs:
- targets: ['localhost:9394']
- job_name: 'mastodon-streaming'
static_configs:
- targets: ['localhost:5001']
Prometheusの管理画面を開き、Target healthに出て動いていればOK。
大まかには、このような感じ。再現したりしなかったりでいい感じの動画が撮れなかった…。
キャッシュ周りで何かの問題が起きている可能性があるが原因はよくわかっていない。3分も待てば改善するので一旦気にしないことにした。
Dockerがあれば一瞬で立ち上がって便利といえば便利なのだが、Ubuntuのネイティブ環境にPrometheusとGrafanaをIPv6スタックで導入した時に、DockerとIPv6の相性が余りにも悪すぎたのが最大の要因。
後はまぁ変なレイヤー隔ててない方が管理楽だし、リソースも抑えられるかなとか。
Mastodon自体に監視の仕組みがあること。Sidekiqという名前自体はよく聞くので知っていたが、今まではなんとなくジョブ管理システムだと思っていた。これはTLで見かけていた管理人の人たちがトラブルが起きた時にジョブを殺したりしているのを見かけたためだ。
とはいえ、公式サイトの説明にはRuby's fastest job systemとあるので、あながち認識としては間違ってなかったようだ。ジョブ管理システムのついでにメトリクスとかも見れる機能があるのかもしれない。
環境変数周りの設定項目が多く、コンソールから設定を操作するイメージが強く、コンソールベースなのかと思っていたが実際にはWebベースのGUI管理コンソールもあり、中々便利だ。管理面の操作や、サーバー本体への影響がない簡単な設定はここで出来るだろう。
アップロードが爆速だったり、画面遷移もかなり早い。家で繋ぐ分にはLAN環境だから早いのかと思っていたが、外から5Gで繋いでも早い。
今のところ大したアクセスや負荷もなく、リソースがしこたま余ってるお陰かもしれない。あとは単純に手前にCDNがないとか、VPSといった共有資源とかと比べた時のスペックの差だろうか？
スペックは結構ある方だと思う。具体的にはCPUはAMD Ryzen 5 5600G、メモリはDDR4 32GB、SSDもCrucial P1 CT500P1SSD8JPでNVMeといった感じで、そんなハチャメチャに高スペックというわけではないが、よくある？安い中古ノートPCを流用したサーバーと比べたら充実している。
主に監視周りの強化をしていきたい。現在のロードマップは以下のような感じだ。
まず、Grafanaをセットアップしたもののnginxのダッシュボードが空っぽなので作っていく必要がある。
次にLokiを入れてログ監視もできた方がいい。個別のログファイルを見るのは割とつらい。
Grafanaで統合管理できると便利なのでMastodonのメトリクスも取れると良いので、これもやっていきたい。
他にも今回のセットアップ中にOpenWrtがOutOfMemoryで落ちるケースがあり、原因不明のネットワーク切断が多発したため、こちらのメトリクス収集も必要だ。ネットワーク自体が死ぬと中身が見れないため、基本的に本体側で、収集して見れるようにしたい。今でも簡単なものは入れているが情報量が少なく、役不足だ。
ストレージ寿命の問題もありeMMCにログを吐くとストレージの寿命がマッハになる恐れがあるため、メモリ管理や追加でストレージを用意するなど、手法についても検討する必要がある。
OpenWrtのメトリクスを鯖側でも取れるようにするのはオプションプランだが、これは別にどうでもいい気はする。平時は統合的に見れて便利かもしれない。
あとは外部環境にステータスページを配置したいと考えている。実用性があるかどうかは謎だが、あるとそれっぽいから。ツールとしてはCachetを採用し、さくらのレンタルサーバー側で運用する予定だ。
簡単な外形監視の導入についても、Cachetで担える可能性がある。
監視面以外ではセルフホスティング方式のWAFであるAnubisに興味があり、これも入れていきたいと考えている。
更に中長期では、現在運用しているlycolia.info配下の全サイトを自宅サーバーへ移行し、メールサーバーやネームサーバーなど、現在あるWebサイトの一切を移行する野望も抱いている。
とにかくやることが沢山あるので、当面は暇になることはなさそうで、充実した生活を送れそうだ。
本来手順になく、私の勘違いで追加して作業してしまっていたOSグローバルのRubyを消しても動くのか試してみた。
# 通常ユーザー作業
ls -la /usr/local/bin | grep ruby
rm /usr/local/bin/ruby-build
sudo rm -Rf /usr/local/bin/ruby-build
ls -la /usr/local/share
sudo rm -Rf /usr/local/share/ruby-build
sudo rm -Rf /usr/local/share/man/man1/ruby-build*
ruby -v
sudo apt remove ruby
sudo su - mastodon
# mastodonユーザー作業
mkdir -p "$(rbenv root)"/plugins/ruby-build
cp ruby-build-20250811/. "$(rbenv root)"/plugins/ruby-build
ls -la "$(rbenv root)"/plugins/ruby-build
cd live
RUBY_CONFIGURE_OPTS=--with-jemalloc rbenv install
ruby -v
exit
# 通常ユーザー作業
sudo service mastodon-web restart
sudo service mastodon-sidekiq restart
sudo service mastodon-streaming restart
一旦ここまでは上手くいったので、上の方にある手順よりこっちでやった方がいいかもしれない。Mastodonのビルドが通るかまでは試してないので、実際に動くかどうかまでは不明だが、まぁ次回考えればよいだろう。