2026/06/01(月)自鯖を別OSにマイグレーションするかどうか問題
投稿日：
最近自鯖を別環境に移行するかどうかについて少し考えている。
現在はUbuntuで運用しており、記憶が確かならUbuntu 16.04 LTSから24.04 LTSまで使ってきているが、幾つかの問題を感じている。別にクリティカルでも何でもないので、やる必要性も薄い。
移行方法についてもやや難しく、UbuntuはNVMe SSD上で動いているため、本来なら別にNVMe SSDを買ってきてそこに試験的に移行先を作り、移行が環境した時点でUbuntuのNVMe SSDと物理的にすり替えたいところだが、SSDが高騰している関係でこの手が使えず、やるとしたら空いているSATA SSDに環境を入れて、運用が軌道に乗りそうならUbuntuを消し飛ばすしかなくなる。つまり戻せないか、戻す場合はUbuntuの入っているNVMe SSDをddでどっかにバックアップしてやる必要がある。凄いめんどい。
ひとまず、以下に移行したくなった好ましくない理由と、移行先について書いていく。
Ubuntuの好ましくないところ
ここに書いていることはほとんど運用面では関係ない吝嗇である。端的に言えばCanonicalの姿勢が嫌いなのである。
Ubuntuの商業主義が気に食わない
自鯖はLinuxのDesktop環境の検証も兼ねているのでUbuntu Desktopを導入しているが、何かあるとCanoninalの製品に誘導されたり、過去にはMSアカウントとの連携をお勧めしてくる画面とも出会った記憶がある。こういうところがどうも好きになれない。
私はCanonicalに金を払う気がないし、LinuxをMSアカウントや、その他何かしらのアカウントと連携させたいとも思っていない。スタンドアロンこそが正義だ。
いやまぁ、Edgeのアカウントは連携するけどさ。
Snapが気に食わない
Snapに対する私の理解としてはSnapdというデーモンの上で動くアプリケーションという感じだ。
コンテナ化されたアプリケーションがDocker見たいなやつの上で動いている。なんかリソース食いそうだしキモイ。ネイティブアプリケーションはバイナリでそのまま動いてほしい。
噂ではFirefoxはaptでインストールしてもSnapdの上で動くらしい。これはWikipediaにも載ってるほど有名な話だ。何故snapdを使ってないのにそうなるのか？キモすぎる。
私は仮想化に対しては余り良いイメージがない。何故なら仮想環境分のオーバーヘッドを含み、無駄にストレージやメモリを食うこと、ホスト環境とゲスト環境の差異により問題が発生した時の特定が困難なことがある。
明示的に触れるDockerやVMならまだしもSnapdは一般向けで普通カスタマイズしない気もするし、そもそもカスタマイズが必要になるとしたらバカバカしい。なんでFirefox動かすのにそんな設定しないといけないのか？
動作が不安定
インストール直後にapt upgradeを叩くとリポジトリが死んでることがある。これは非常に嫌だ。
なんで公式でキッティングされてるリポジトリが死んでるのか？本当に営利企業がやってるのか？と思う。
他にもノートPCに入れてると蓋を閉じて開きなおしたときにキーボード入力が効かなくなり、一切何も操作できなくなることもあった。これは大分困る。
基本的にUbuntuのDesktop環境は不安定で、よくフリーズやクラッシュすると思う。それでもUbuntu 8.04 LTS辺りのころよりは安定したとは思うが…。
26でのinit.d切り捨て発表
init.dを捨てろという話なのだが、移行がだるい。
Ubuntuの好ましいところ
一方で、Ubuntuにもいいところはある。
広く普及しておりノウハウが豊富
人気のディストリのため、情報が多いのは強みかもしれない。
パッケージリポジトリも多く、基本的にUbuntu対応は多いと思う。
メジャーアップデートが容易
コマンド一個叩けばアップデートできるのは便利だ。設定の移行も手伝ってくれる。
特に何もしなくても大抵のハードウェアが動く
5種類くらいのデバイスに突っ込んだり、NICを増設したり、色々してきたが、今のところドライバを入れるとか何か対応したことはない。楽である。
現在検討している移行先
取り敢えずそんなこんなで移行先を探すことにした。
Debian
人生で最も最初に触ったディストリ。保守的で質実剛健という話を聞くやつ。
得られそうな利点
- Canonicalの商業主義から解放される
- Ubuntuより安定している可能性がある
- Debianは徹底的なテストを経てリリースされているそうなので
懸念点
通信速度が異常に遅かった
懸念点としては何故か通信速度が異常に遅かった点だ。Live installerでiperf3で計測したところ、なんか異常に遅かった。これでは使い物にならない。原因は調べていないがNICは10000Mbpsでリンクアップしていたので、NICより手前で何かが起きていた可能性がある。
以下はDebian 13.5.0のLive installer上で計測した値だ。
Windows -> Debian
| Interval | Transfer | Bitrate | Retr | Cwnd |
|---|---|---|---|---|
| 0.00-1.00 sec | 39.0 MBytes | 327 Mbits/sec | 1 | 247 KBytes |
| 1.00-2.00 sec | 40.9 MBytes | 343 Mbits/sec | 3 | 214 KBytes |
| 2.00-3.00 sec | 38.2 MBytes | 321 Mbits/sec | 4 | 187 KBytes |
| 3.00-4.00 sec | 41.0 MBytes | 344 Mbits/sec | 3 | 199 KBytes |
| 4.00-5.00 sec | 38.9 MBytes | 326 Mbits/sec | 3 | 160 KBytes |
| 5.00-6.00 sec | 40.1 MBytes | 337 Mbits/sec | 0 | 298 KBytes |
| 6.00-7.00 sec | 39.9 MBytes | 334 Mbits/sec | 0 | 386 KBytes |
| 7.00-8.00 sec | 41.1 MBytes | 345 Mbits/sec | 2 | 358 KBytes |
| 8.00-8.81 sec | 32.0 MBytes | 331 Mbits/sec | 0 | 423 KBytes |
Debian -> Windows
| Interval | Transfer | Bitrate |
|---|---|---|
| 0.00-1.00 sec | 37.8 MBytes | 315 Mbits/sec |
| 1.00-2.01 sec | 41.2 MBytes | 342 Mbits/sec |
| 2.01-3.01 sec | 38.1 MBytes | 321 Mbits/sec |
| 3.01-4.00 sec | 40.6 MBytes | 344 Mbits/sec |
| 4.00-5.01 sec | 39.4 MBytes | 327 Mbits/sec |
| 5.01-6.01 sec | 40.1 MBytes | 339 Mbits/sec |
| 6.01-7.00 sec | 39.2 MBytes | 330 Mbits/sec |
| 7.00-8.01 sec | 41.1 MBytes | 342 Mbits/sec |
| 7.00-8.01 sec | 41.1 MBytes | 342 Mbits/sec |
移行しても旨味があまりなさそう
手間がかかるだけでCanonicalの開放以外のメリットがなさそう。
移行の手間としても全ての手順をマニュアルに書き出すかAnsibleのような構成管理ツールでやる必要があり、非常に面倒そうである。
Proxmox
仮想環境をたくさん作ってその中でアプリケーションを運用するやつ。コンテナ単位でのバックアップも取れるなど便利そうだ。
この環境に移行する場合、移行が楽というのが最大のメリットだ。一度適当な環境に仮構築しモジュールごとに移行し、移行完了したらLXCのバックアップを取り、Ubuntu環境を潰し、Proxmoxに入れ替え、バックアップを復旧して移行すればリスクも手間も最低限で済む。
またDebianで発生したNICの極端な通信速度劣化についてもProxmoxでは確認できなかった。但しUbuntuよりは遅く見えた。
懸念点
スペック的に運用できるか怪しい
例えばコンテナ単位でのリソース管理はその一つだ。例えばコンテナごとにCPUやメモリ、ストレージを割り当てるとすると、特定のコンテナが跳ねたときにリミットにかかって動作が劣化するが、ネイティブで動かしていればCPUやメモリ、ストレージは共有なので、なんかいい感じにしてくれる。限界突破しない限りOOMは起きないし、私のサーバースペックであれば普通起きない。
しかしコンテナ化して1コンテナCPU2コア、メモリ2GBとかしていればしょぼいVPSみたいになって動作が劣化しそうだし、そんな立派なスペックでもなく、現状CPU6コアのメモリ32GBなので、この割り当てだとすぐに枯渇するのは自明である。ブレードサーバーを持ったホームラボ、k8sを使った運用のようにクラスタ化された環境なら、これはうまくいきそうだが、しょっぱいスペックのマシン一台で成り立つかどうかは怪しい。
Opus 4.8は成り立つというが、この分野ではLLMの言うことを真に受けたくはない。そもそもLLMの出力なんか何言ってるかわからないけど動くからいいか！で採用するものでしかないと思っている。
運用がだるそう
例えば10個くらいLXCを上げているとして、コンテナのイメージをアップデートしますとかなると全部上げていかないといけないだろうから、これは面倒そうだ。
他にもLXC1とLXC2, LXC4に対して作業する場合、それぞれのLXCにSSHDと鍵を入れる必要があり、無駄なオーバーヘッドが出る。つまりLXCを増やし、そこの中に入る場合は台数分のSSHDが多重起動し、その数分の鍵が必要だ。まぁこれについては最悪一個にしてもいいが…。切り替えについてもnginxでリバプロしてハブを作れば上手くいくかもしれないが、そもそもそれが出来るかよくわかっていない。軽くググった感じはできるらしいが、そもそもスイッチする時どうなるのか見当もつかない。/lxc1/path/toみたいな形式になるのだろうか？
そう考えるだけで運用がだるそうである。
pct setを使えばうまくいく可能性が示唆されているが、どうやらこの方法は前述のように根本にパスを追加して、そこから分けていく考えのようだ。ユーザーやグループとかどうなるんだこれ…？Proxmox側でID揃えてくれるのかな？
あとホストのアップデートもだるそうな気がしている。
監視がだるそう
動作パフォーマンスを取ろうにもホストとゲストのどっちのCPUやメモリの使用率を取るかは悩みである。ホストには空きがあるが、ゲストには空きがなければ広げた方がいいかもしれないし、この辺りについては考えがまとまっていない。
通信速度の比較
Ubuntu 24.04.4 LTS
Windows -> Ubuntu
| Interval | Transfer | Bitrate |
|---|---|---|
| 0.00-1.00 sec | 1.11 GBytes | 9.50 Gbits/sec |
| 1.00-2.01 sec | 1.11 GBytes | 9.47 Gbits/sec |
| 2.01-3.01 sec | 1.10 GBytes | 9.49 Gbits/sec |
| 3.01-4.01 sec | 1.10 GBytes | 9.49 Gbits/sec |
| 4.01-5.01 sec | 1.11 GBytes | 9.48 Gbits/sec |
| 5.01-6.01 sec | 1.10 GBytes | 9.47 Gbits/sec |
| 6.01-6.57 sec | 628 MBytes | 9.50 Gbits/sec |
Ubuntu -> Windows
| Interval | Transfer | Bitrate |
|---|---|---|
| 0.00-1.01 sec | 1.11 GBytes | 9.40 Gbits/sec |
| 1.01-2.00 sec | 1.09 GBytes | 9.42 Gbits/sec |
| 2.00-3.01 sec | 1.10 GBytes | 9.40 Gbits/sec |
| 3.01-4.01 sec | 1.10 GBytes | 9.39 Gbits/sec |
| 3.01-4.01 sec | 1.10 GBytes | 9.39 Gbits/sec |
Debian 13.5.0のLive installer上での計測
以下の計測値は全てクライアント側で取得したもの。Windows側にCwndが出ているので表が逆かもしれない（Proxmoxではクライアント側にCwndが出ていたため）
Windows -> Debian
| Interval | Transfer | Bitrate | Retr | Cwnd |
|---|---|---|---|---|
| 0.00-1.00 sec | 39.0 MBytes | 327 Mbits/sec | 1 | 247 KBytes |
| 1.00-2.00 sec | 40.9 MBytes | 343 Mbits/sec | 3 | 214 KBytes |
| 2.00-3.00 sec | 38.2 MBytes | 321 Mbits/sec | 4 | 187 KBytes |
| 3.00-4.00 sec | 41.0 MBytes | 344 Mbits/sec | 3 | 199 KBytes |
| 4.00-5.00 sec | 38.9 MBytes | 326 Mbits/sec | 3 | 160 KBytes |
| 5.00-6.00 sec | 40.1 MBytes | 337 Mbits/sec | 0 | 298 KBytes |
| 6.00-7.00 sec | 39.9 MBytes | 334 Mbits/sec | 0 | 386 KBytes |
| 7.00-8.00 sec | 41.1 MBytes | 345 Mbits/sec | 2 | 358 KBytes |
| 8.00-8.81 sec | 32.0 MBytes | 331 Mbits/sec | 0 | 423 KBytes |
Debian -> Windows
| Interval | Transfer | Bitrate |
|---|---|---|
| 0.00-1.00 sec | 37.8 MBytes | 315 Mbits/sec |
| 1.00-2.01 sec | 41.2 MBytes | 342 Mbits/sec |
| 2.01-3.01 sec | 38.1 MBytes | 321 Mbits/sec |
| 3.01-4.00 sec | 40.6 MBytes | 344 Mbits/sec |
| 4.00-5.01 sec | 39.4 MBytes | 327 Mbits/sec |
| 5.01-6.01 sec | 40.1 MBytes | 339 Mbits/sec |
| 6.01-7.00 sec | 39.2 MBytes | 330 Mbits/sec |
| 7.00-8.01 sec | 41.1 MBytes | 342 Mbits/sec |
| 7.00-8.01 sec | 41.1 MBytes | 342 Mbits/sec |
Proxmox VE 9.2-1
以下の計測値は全てWindows上で取得したもので、Proxmox->Windows側はProxmox側のログの値ではない（転記が面倒だったためWindows側の値を取っている）
Windows -> Proxmox
| Interval | Transfer | Bitrate |
|---|---|---|
| 0.00-1.01 sec | 1.07 GBytes | 9.13 Gbits/sec |
| 1.01-2.01 sec | 1.07 GBytes | 9.26 Gbits/sec |
| 2.01-3.01 sec | 1.07 GBytes | 9.25 Gbits/sec |
| 3.01-4.01 sec | 1.09 GBytes | 9.28 Gbits/sec |
| 4.01-5.01 sec | 1.06 GBytes | 9.16 Gbits/sec |
| 5.01-6.00 sec | 1.02 GBytes | 8.78 Gbits/sec |
| 6.00-7.00 sec | 1.07 GBytes | 9.23 Gbits/sec |
| 7.00-7.88 sec | 948 MBytes | 9.03 Gbits/sec |
Proxmox -> Windows
Proxmox側（クライアント）にはCwndが出ていたが、Windows側（サーバー）の値を取っているため、その情報が欠落している。
| Interval | Transfer | Bitrate |
|---|---|---|
| 0.00-1.00 sec | 1.08 GBytes | 9.26 Gbits/sec |
| 1.00-2.01 sec | 1.09 GBytes | 9.27 Gbits/sec |
| 2.01-3.01 sec | 1.08 GBytes | 9.28 Gbits/sec |
| 3.01-4.00 sec | 1.08 GBytes | 9.29 Gbits/sec |
| 4.00-5.00 sec | 1.08 GBytes | 9.29 Gbits/sec |
| 5.00-6.00 sec | 1.08 GBytes | 9.28 Gbits/sec |
| 6.00-7.00 sec | 1.08 GBytes | 9.27 Gbits/sec |
| 7.00-8.01 sec | 1.09 GBytes | 9.29 Gbits/sec |
| 8.01-9.00 sec | 1.07 GBytes | 9.28 Gbits/sec |
| 9.00-10.00 sec | 1.08 GBytes | 9.29 Gbits/sec |
あとがき
Proxmoxで運用の支障がなければ環境分離の観点から移行できるとよさそうだが、メンテナンスのだるさを考えた時にどうかというのでぐるぐるしている。
かといって今のUbuntuを拡張すればするほど移行が手間になってくるので、悩ましい。しかし単一ホストで全部運用するのは間違いなく楽だしなぁ…。
取り敢えずDebianに移行する旨味は余りなさそうだし、これはしなくていいかと思った。
Proxmoxはやってみないとわからない部分もあるのでUbuntu環境のバックアップを入念に取ったうえでやるかもしれないが、問題はUbuntuをバックアップするストレージをどうするか…。
そもそも現時点でやる意義も怪しいので、今はやらない方に倒し、必要が出たときにやるのも一つではある。やりたくなった時にはそれはもう地獄が待っているかもしれないが、それ以前に私はやりたいことが無数にあるのだ。
今回は検証ができたという意味では一つ成果だと思うし、一旦ここで留めておこう。
2025/03/31(月)自作ルーターを作っていくのにR86S U1を買ったのでOSのインストールをした
更新日：
投稿日：
投稿日：
昨年フレッツ光クロス、10Gbps対応に関する覚書を書いてしばらく経つが、いよいよ10GbE対応のための環境を作ろうと思ったので、その記録を残していく。
第一弾はR86S U1を買ったので、その購入録とOSのセットアップまでのログを書いていく。
買ったもの
今回購入したのは中華性の怪しい10GbE自作ルーターマシンとして名高いR86S U1だ。もう話題になって数年経っているので旬は過ぎていると思うが、依然として10GbEルーターとして安価な選択肢だと思う。
買った後で気が付いたが、U2のほうがスペックが上で値段同じなのでU2を買ったほうがいい。
セットアップ時にあるといいもの
- HDMI to Micro HDMI変換アダプタ
- SDカード or USBメモリ
- rufusやbalenaEtcherなどのイメージを焼く手段
- MSYS2
初回起動
私が購入したものはeMMC内にOSが上手く入っていないのかgrubが表示されるだけで、マニュアル操作でも起動イメージが見当たらずｍOSを起動することができなかった。
どの道プリインストールされているOSは中国語で役に立たないという話だったのでOSのセットアップを行うことにした。
試験起動
汎用PCへのインストール手順は公式情報である、[OpenWrt Wiki] OpenWrt on x86 hardware (PC / VM / server)が参考になる。
- リリース一覧を開き最新の安定板を辿り、x86→64に進む
generic-ext4-combined-efi.img.gzをダウンロードするsha256sum openwrt-24.10.0-x86-64-generic-ext4-combined-efi.img.gzでハッシュを確認gunzip openwrt-24.10.0-x86-64-generic-ext4-combined-efi.img.gzで展開する- Explzhだと上手く解凍できなかったのでMSYS2からgunzipを叩いて対処した
- 展開して出てきたimgファイルをSDカードかUSBメモリに焼く
- imgファイルを焼いたメディアをR86Sに差し込む
- R86Sの電源を入れPOST画面が出たらDeleteを叩き、BIOSに入る
- 通電時に勝手に電源が入るため一回落とした方がいい
- 起動順序を差し込んだメディアに変更する
eMMCへのOSインストール
Ubuntuのインストールディスクの中にOpenWrtのイメージをバンドルする方法がわからず、SDカードにimgを焼いてもマウントできなかったのでネットワークを経由してインストールしている。
事前準備
- OpenWrtのイメージファイルを入力しやすい短いファイル名にしてHTTPが疎通するどこかに置いておく
- R86S U1に前述のイメージと疎通可能なLAN線を刺す
インストール手順
- Ubuntu Serverのインストールイメージを落とす
- 日本語版サイトから落とすとEFIイメージでないものが落ちてきたので本家から落としてきたほうがいい
- rufusを使って何かしらのメディアに焼く
- R86S U1を起動し、POST画面でDeleteを叩き、BIOSを開く
- 起動順序をUbuntuを焼いたメディアにする
- USBの場合はUSB Key
- Ubuntuを起動し、GrubでTry or Installを選ぶ
- キーマッピングを日本語にするところまでインストールウィザードを進める
- 右上のヘルプを開き、Enter shellする
- wgetで事前準備で用意した起動イメージを落とす
- eMMCにイメージを焼く
dd if=openwrt-efi.img bs=1M of=/dev/mmcblk0 shutdownコマンドを叩く- 再起動でBIOSに入り起動順序をeMMCに変更
- GrubにOpenWrtが出て起動することを確認
- passwdコマンドでパスワードを設定する
2025年8月4日追記
この続きはR86SとOpenWrt 24.10でOCNバーチャルコネクトに接続したときのメモに書いている。
開梱の儀
梱包状態。安い中華製品にしてはなかなか丁寧だ。
箱もしっかりしている。
横の小さな箱にはMicro HDMI -> HDMIケーブルが付属していた。これは親切だ。
開梱すると本体とACアダプタが見えた。やはり梱包が丁寧だ。
箱の底にはマニュアルと検査証、六角が入っていた。この六角は本体を開けるためのものだが、なめてしまい役に立たなかった。
ネットワークインターフェースはSFP+が2口、2.5GbEイーサーが3口。他に電源用USB-C、USB3.0x2、USB2.0x1、SDカード、Micro HDMIといった感じだ。
表面にはケースファンと冷却用のフィンがついている。デザインも悪くない。
裏面と片側面にはゴム足がついており横置きにも縦置きにも対応している感じだ
分解
付属の六角がなめてしまい役に立たなかったのでちゃんとしたのを買ってきた。対応するのは1.5mmだった。
表のふたを開けるとNVMeSSDスロットが見える。ネジ穴的に一番長い奴しか無理だろう。
本体をパカっと二つに。どうやらマザーボードは三枚くらいに分割されているようだった。
あとがき
EFIイメージかBIOSイメージかは好みで選んでいいという記事を何個か見たが、BIOSイメージだと起動しなかったため、EFIイメージのほうがいいかもしれない。
参考までに手持ちのAMD64マシンにBIOSイメージを刺したところ、そもそも認識すらしなかったためダメなのかもしれない。24.10固有の問題なのかどうかはわからないが、今時はUEFIが推奨される環境であると思われるため、EFIイメージで問題ないと思われる。
ひとまずこれで10GbE環境への一歩を踏み出せたと思う。LANが構築でき、現状の環境でWAN込みで安定稼働させられたら実際に10GbE契約もしていきたいところだ。
しかしイメージを焼いたSDをマウントできないのは想定外だった。FAT32でフォーマットしたはずなのでマウントできそうなものだが…。正直焼いてマウントして取り出すより、アップしてwgetしたほうが楽なので別にいいのだが。