CERNが加速器を動かすコンピューターで、OSの選び方を変えようとしている。2026年末までに2,200台を超えるフロントエンドコンピューターをDebian 13へ移す計画で、8月30日の講演時点では数十台がすでに稼働していた。これはDebianの公式ニュースと8月30日の説明資料が示した目標である。ただし、ここで替えるのはCERNの全IT環境ではない。電子機器のそばで信号を読み、基板を介して加速器を制御する下位層だ。
移行を強く後押ししたのは、既存ハードウェアとの互換性だ。新しいOSの最低CPU命令要件に合わせるため、まだ使える制御機の基板まで設計し直すことを避ける。そのために、OSの保守期限と現場の機器寿命を切り分ける。加速器の停止、再配線、試運転を伴う設備では、CPUを替えれば済む話にならないからである。
2023年の時点でCERNは、上位の操作端末と高可用サーバーにはRHEL 9を使い、組み込みに近い下位の制御機にはDebianを選ぶ方針を公表していた。当時の論文で決めた設計を、いま実装へ移している。
制御機を更新しなくて済むOSを選ぶ
加速器制御は一枚岩ではない。CERNの資料では、人が操作するコンソール、高可用性を求める中間サーバー、電子基板につながるフロントエンドコンピューターの三層に分かれる。末端の制御機はリアルタイムで状態を監視し、装置に指示を渡す。そこにあるPCは一般的な事務用端末と違い、基板と配線、それらを動かすドライバーまで設備の一部になっている。
CentOS 7への移行も、CERNは2014年に始め、検証に2年をかけて2016年に運用へ入れた。論文によれば、その環境は7年間安定して動いた。しかし、CentOS Streamの5年という寿命は、加速器の運転日程に合わせにくい。OSが保守期限を迎える時点と、設備を安全に止められる時点が重なるとは限らないからだ。
そこでCERNは、上位層と下位層を同じOSにそろえる前提を外した。上位はRHEL 9を使い続け、下位はDebianへ寄せる。構成管理はAnsible、サービス管理はLUMENSとsystemdを使い、特定のディストリビューションに縛られないよう整えてきた。こうした共通の管理手段を整えることが、複数のOSを並行して運用する準備になる。
対象範囲も明確だ。CERNのLinuxサービスは、Debianを加速器フロントエンドシステムに限って支援すると案内している。デスクトップ、ノートPC、データセンターの標準OSをDebianへ変える計画ではない。支援範囲の説明は、今回の判断を研究所全体のOS移行と読まないための線引きにもなる。
CPUの最低要件が、使える機械を変える
CERNが2023年に公表した論文では、RHELのCPU要件変更によって、正常に動く制御用ハードウェアと関連するPCIカードまで交換が必要になると指摘している。OSの更新が、設備の更新を引き起こす。この連鎖を止めるために、制御機だけ別のディストリビューションを選んだ。
CPU命令は、ソフトウェアがCPUに実行させる基本的な操作である。Red HatはRHEL 9でx86-64-v2を最低水準に置いた。SSE4.2などを含む水準であり、より古いCPUでは新しい命令を使うプログラムが動かない場合がある。RHEL 10ではAMD／Intelの64ビット版の最低要件がx86-64-v3へ進み、AVX2などが加わる。RHEL 9の説明とRHEL 10のリリースノートで確認できる。動作周波数が足りるかではなく、配布されたプログラムが使う命令を実行できるかが問題なのだ。
| ディストリビューション | AMD／Intel 64ビット版の最低CPU命令水準 |
|---|---|
| RHEL 9 | x86-64-v2 |
| RHEL 10 | x86-64-v3 |
| Debian 13 amd64 | x86-64-v1 |
最低限必要なCPU命令の違いであり、機器全体の互換性を保証する比較ではない。
Debianのパッケージ情報では、Debian 13のamd64用ベースラインをx86-64 psABI v1としている。実際に制御機へ導入する際は、現場の電子機器とソフトウェアを組み合わせた試験が必要になる。
8月30日のスライドにある2023年第2四半期の試算では、RHELに残るための更新に540万スイスフランを見込む。約11の基板を再設計し、人員の採用や再配線、試運転も必要になるという。あくまでRHELを継続した場合の更新予算の見積もりであり、Debian移行による節約の実績ではない。説明資料は、CPUの命令要件をOSの話だけに閉じない理由を端的に示している。
Red Hat側にも、最低要件を上げる技術的な理由がある。同社の説明では、従来の最適化は特定のライブラリーや関数に適用され、残るコードでは新しいCPU機能を十分に使えていなかった。配布するソフトウェア全体の前提を引き上げれば、新命令を広く使える。CERNの選択は、その方針を一律に否定するものではない。設備ごとに専用の電子機器を持つ現場では、新しいCPU機能を使う利点より、既存機器を検証済みの状態で使い続ける利点が大きいという判断だ。
DebianとLinuxは、何が違うのか
DebianとRHELは、ともにLinuxディストリビューションである。ただしLinuxはOSの中核であるカーネルを指し、DebianはそこへGNUの基本ツール、アプリケーション、パッケージ管理のAPTなどを組み合わせ、利用と保守の単位として配る仕組みをいう。Debianの紹介が説明するこの違いは、CERNの選択を読むうえで実務的である。カーネルがどちらもLinux系でも、どのCPU命令を前提にするか、どの期間を保守するか、パッケージをどう更新するかは配布元ごとに違う。
DebianはIan Murdockが1993年8月に始めたプロジェクトで、名称はDebraとIanの名に由来する。公開された協働作業でソフトウェアを構成、保守する方法を選び、利用者が継続して使える配布OSとして育ってきた。Debianがいう「free」は価格ではなく、ソフトウェアを利用、改変、配布できる自由を指す。今回のCERNには、既存ハードウェアを支える配布OSがあり、設備に合わせて必要な部分を組み立てられることが効いている。
一方で、Debianなら古い装置をすべて残せるわけではない。Debian 13では、i386はamd64上で32ビットソフトを動かすための補助アーキテクチャに限られる。古い64ビットCPUを使えることを、32ビット専用機まで一律に保守できることと取り違えてはいけない。Debian 13のリリース情報が示すのは、互換性にも保守にも境界があることだ。
OSを替える前に、配布と保守の仕組みを作る
制御機はディスクレスで動き、ネットワークから起動する。CERNの説明資料によれば、Linuxカーネルをディストリビューションから分離し、リアルタイムパッチと必要なドライバーを組み込む構成を取る。Debianを入れれば終わるのではなく、加速器用に必要なカーネルと周辺ソフトを、配布OSの更新から切り離して保守する設計である。
その作業はパッケージの流れにも及ぶ。CERNはKojiとRPMCIを使い、DebianパッケージをRPMと並行してビルドできるようにしている。開発チームはDebian用のパッケージ定義とビルド設定を追加し、従来のRPM向けの流れと並行してソフトウェアを用意できる。Kojiの案内は、フロントエンドコンピューター向けの例外を除けば、Debianは積極的な支援対象ではないとも記す。標準サービスを広く置き換えず、対象を限定したからこそ、例外の保守を引き受ける必要がある。
CERNが担う保守には、こうした配布作業に加え、自作ドライバーとネットワーク起動環境の維持もある。一般向けの更新パッケージを受け取るだけでは、設備固有の部分を保守しきれない。機器交換を抑えられても、運用の工数まで消えるわけではない。
加速器の運転日程に、OSの寿命を合わせる
CERNが今回避けようとしているのは、配布OSの寿命が先に尽き、設備の改修時期を前倒しさせる事態である。CentOS 7の通常保守はすでに終了している。2023年論文は、OSの保守終了が物理実験の運転期間の途中に来る問題を指摘していた。ハードウェアの互換性に加え、保守日程も合わせなければならない。
2025年8月9日に公開されたDebian 13は、通常サポートが2028年8月9日まで、その後の長期サポート（LTS）が2030年6月30日まで続く。ただしLTS期間は対応アーキテクチャが絞られる。年末に移行すれば、それだけで設備の残りの寿命をすべてカバーできるわけではない。
CERNの基本計画はDebian 13を2030年まで使い、同年にDebian 15へ移るものだ。延長保守のELTSで2033年まで運用する代替案もあり、Freexianへの支援を始めたとしている。将来版の仕様まで確定した約束ではなく、更新する道と延長保守を使う道を用意した計画である。
年末までに2,200台超を移す目標は、この計画が現場で通用するかを測る大きな節目になる。その先には、稼働する設備を支えながら、2030年のOS更新に向けた検証を進める仕事がある。複数の配布OSを選べる運用を維持できれば、CERNは加速器の改修日程を、特定の配布元の方針に左右されにくくできる。
