treedown’s Report

システム管理者に巻き起こる様々な事象を読者の貴方へ報告するブログです。会社でも家庭でも"システム"に携わるすべての方の共感を目指しています。

Debian 13 Trixie時代は32ビットOS廃止なので考えていること

今日はちょっと検討中の内容を、頭の中を整理するために書き出してみました。ほぼ自分用です。

32ビットOSのsambaサーバ×2をどうリプレイスするか

現在Debian 12 bookwormをOSとして動作しているsambaサーバが2台あります。

以前<Debian 13 Trixieのリリースノートを調べてみた - treedown’s Report>にて確認したように、Debian 13 Trixieでは32ビットバージョンのサポートが終了となっており、32ビットOSのユーザはbookwormが最後のOSとなります。

次期バージョンにするためには、sambaサーバ本体であるPCハードウェアからリプレイスしないといけない環境なのですが、24時間365日稼働するサーバで、かつUSB接続の外付けHDDで現状運用しているので、OSがインストールされている本体だけをすげ替えるだけでリプレイスはできると考えています。

bookwormのLTS終了までに構成を決定してTrixie環境に移行する必要があると思うのと、昨今Windows側でNTLM廃止や認証の厳格化などの仕様変更も静かに進行していることもあり、あまりbookwormで引っ張るのも難しいのではないかと思っています。

対象のsambaサーバ構成

簡単に構成を解説しておきます。
Debianのsambaサーバで共有フォルダをホスト、samba-Aとsamba-Bの2台を同じ構成にし、2台のsambaサーバ間はrsync(rsyncd)で定期的に同期し、同一のデータを保持しています。

-------------------------------------------------------
  <samba-A> …→ rsync …→ <samba-B>
    ↓
    BunBackup(ファイルバックアップ)
    ↓
   <Backupサーバ>(Windows)
-------------------------------------------------------

samba-Aではrsyncdが動作しており、samba-Bはrsyncコマンドをcronで定期実行しています。

rsyncでそれほど時間差なく(共有フォルダの)同一データを2台で保持しつつ、別のWindowsコンピュータからファイルバックアップを定期的に仕掛けて、バックアップの世代としています。

ざっくりいうと(クラスタではないが)同一筐体のsambaサーバを2台で正系副系と稼働させrsyncで同期しつつ、ファイルベースのバックアップを別途取得している、という環境が現状です。

実際にユーザが参照するのはsamba-Aの共有フォルダ、samba-Bはバックアップ用にrsync同期で同期時点の最新データを保全する副系サーバです。世代を管理するようなバックアップはWindowsベースのBackupサーバで実施しています。

なお、rsyncの「片方向性」(誤削除・ランサムウェア・上書きミスのような正系での破壊も副系に伝播すること)に備えるのはWindowsベースで動作するバックアップの<Backupサーバ>(Windows)です。世代管理もしているので最低限前日のファイル、最大限数営業日前くらいまでの保存をしています。rsyncは数時間おきに実行しているので、あくまで最新状態をスナップショット的に同期しているファイルサーバ副系という立ち位置です。

例えば、このsambaサーバ二台がそれぞれ、PCベースのDebian(正系)とRaspberryPi(副系)でリプレイスするというのも一つのやり方かなと思っています。

どっちがいいかなと思った内容

この環境は、RaspberryPiのRaspberryPi OSでsambaサーバを構成するパターンと、64ビット対応の(Windows11が動作しないので余剰する)PCに素のDebianをインストールしてsambaサーバを構成するパターンのどちらかで考えているのですが、運用を考えるとどっちが優位か迷っています。

2025年のWindows10サポート終了よって、Windows11が動作しないという理由で余剰するPCが複数出てくるので、ハードウェアの故障は(同一型式の)本体交換で対処できるというのはPCに素のDebianをインストールするパターンの強みに思えます。

一方で、RaspberryPiはddバックアップしておけば(本体部分は)そうそう壊れないということもあり、それはそれでメリットあると思います。(SDカードなのでddバックアップの容量が少なく済むというのも利点だと思います。)

RaspberryPiへの置き換えは性能低下になるか?

気になっているのはこのRaspberryPiに置き換えると、現状のsambaサーバより性能が低下するのかという点です。RaspberryPiのCPUや(世代によりますが)Ethernetの通信速度がフルスペックのPCより多少劣るためです。どれくらいの世代が妥当か、調べてみました。

現状の(32ビットOSでDebianのsambaサーバで稼働する)ハードウェアのスペックが、CPU=Celeron D 420(1.60GHz)、メモリ2GB(おそらく)で動作しています。

結構旧式のPCなので、ちょっと新しいRaspberryPiの性能とはそれほど変わらないつもりでした。

RaspberryPi 3はARM Cortex-A53(4コア)、RaspberryPi 4のARM Cortex-A72(4コア)もシングルコアではやや非力で、Celeron 420(1.60GHz)より処理性能自体は控えめのようです。

CPUで引っ掛かるのが、sambaサーバ自体の動作よりもrsyncでデータを同期するプロセスが動作すると、共有フォルダを参照するユーザ(がフォルダやファイルを開くのが遅くなることがある)への影響が気になります。RaspberryPi 3はメモリも1GBなので、セッション数が増えるとちょっと弱い印象を受けました。

あとRaspberryPi 3だった場合、ギガビットイーサネットではあるものの、システムボード上ではUSB経由でのイーサネット接続なので現状のPCベースのsambaサーバより性能は低下してしまいそうです。RaspberryPi 4はギガビットイーサネットはUSBから独立しているので、RaspberryPiに置き換えるならRaspberryPi4以降の世代なら検討の余地があるように思えました。

RaspberryPi 5なら?

ここで考えたのは、RaspberryPi 4でなくてRaspberryPi 5ならかなり性能が向上しているのでアリなんじゃないかと思いました。RaspberryPi 5はメモリが<1GB、2GB、4GB、8GB、16GB>とラインナップが揃っています。このうち4GBか8GBくらいなら現状のsambaサーバよりメモリ増量となるので現実的なんじゃないかと考えました。ちょっとお値段は張りますが。

RaspberryPi 5はCPUが最新ARM Cortex-A76(4コア)で、RaspberryPi 4の2倍のCPU性能という触れ込みでした。よくよく調べてみると、かなり小規模環境のサーバ機器としては現実的な性能を有しています。あと、サーバとしてリアルタイムクロック(RTC)が標準搭載されているというのも結構プラスに思えてきました。

RaspberryPiでリプレイスしても?

RaspberryPi 5なら性能面では問題ないような感じがしてきたのですが、セルフパワーで外部電源ありのHDDケースを使ったとしてもRaspberryPiで「USBバスパワー不足問題」が発生する、という経験をしていることから、やっぱりユーザが参照する正系のsambaサーバというのはPCベースで素のDebianインストールでサーバ構築したほうがいいかなという感じもしてきました。

blog.treedown.net

この時は、セルフパワーで別電源で給電される外付けHDDをRaspberryPiで接続していても電力不足が発生していました。こういうことがあるので、副系のRaspberryPiは頭にあっても正系で起用するのはどうかと迷う感じです。

ただ、副系なら通常はユーザから参照されることもないし、rsyncで正系の共有フォルダのデータを定期的に複製してくれればいい、という立ち位置なのでRaspberryPiの性能で十分に賄えそうな感じがしてきます。

正系はやっぱり、Windows10世代で余剰したPCに素のDebian 13 Trixieをインストールして64ビット化する、というのがよさそうだなと改めて思いました。

結論は持ち越しですが…

まだ考え中なのですが、考えた途中の内容を記録しておくと、なぜこういう選択(結論)にしたのか、を忘れたころに参照できるため、考えたことを書き出しておく、という作業を実施してみました。

書き出しているうちに、なんとなく頭の中も整理されていくので、しばらく寝かせるといい感じに(頭の中が)まとまっていることもあります。