ここからはどちらかというと余談になります。いろいろと作業をしていくなかであった発見や「なるほど！」と思った現象について少し書いてみたいと思います。

ZFSの圧縮の効果がこんなところに

とりあえずすべてデータを転送してみたのですが、気になることが一つ。それはmdadmで確保されたRAID領域(ファイルシステム依存の領域)からZFSにコピーしたのですが、使用容量が8%ほど下がりました。おそらくZFSによる圧縮の効果だと思うのですが、アルゴリズムは速度優先でlz4を指定しているためそれほど圧縮されないはずですし、大抵のファイルが一度圧縮を行っているファイルのはずなので、圧縮はあまりかからないはずだったのですが…。圧縮をかけられるデータやファイル名などのメタデータが圧縮を受けるとどれだけ容量が削減できるかがよくわかりました。速度に問題がなければほかの領域でもかけたくなりますね。

QEMUの設定をRedHat系からDebian系に移すのはかなり難しい

こちらは苦労した点。設定ファイルを直接持って行ってどうにかなるのか？というと「基本的にはうまくいかない」が回答のようです。仮想マシンの実行ファイルはRedHat系とDebian系で名前が異なっているため変更が必要、VirtIOがうまく動作せず起動させるとブルースクリーン行きになる、設定ファイルをインポートするとコマンドライン指示の部分(ポート開放処理を記述)は削除される、などがありました。結局一時的に別のUbuntuServer機を用意してそちらにGNOMEとQEMUをインストールして「グラフィカルな環境で設定を行い動作したもの」＋「そのときの設定ファイル」を再度コピーする、という手順でなんとかする羽目になりました。VirtIOはドライバのバージョンが古すぎたのかな…とも考えています。

mdadmによるソフトウェアRAIDは別PCにストレージだけをつけ直しても検知はされる

これは今回チェックできた中でよかったこと。ちゃんとSuperblockに設定が残っているらしく、OSが入れ替わったとしてもちゃんとmdstatに状態が表示され、mountをかけると普通にファイルが見えました。これでmdadmで構築した場合にインタフェースが故障してもある程度大丈夫ということがわかりました。ただし、mdadmからアレイを削除すると普通に見えなくなりますし、検知された段階で詳細をファイルに保存する(mdadm –detail –scan > /etc/mdadm.conf)ことを忘れるとその後見えなくなったときに二度と構築できなかったりとしますので注意は必要ですね。（元の計画では、HDDとインタフェースカードのみ追加して一時的にHDDを付け替えてコピーする、という算段をしていたが、これがうまくできるのかどうかわからなかったので諦めてPCを一台組んだ、という経緯がある）

SELinuxが動いている環境で設定ファイルを/etcにコピーする、というやり方は失敗する可能性がある

再度のFedora環境の移行時に起こった出来事。どうせ同じサービス環境を復元するので移行前の/etcを取り出しておいて移行先で必要なファイルだけ展開してコピーすればいいや、と思って作業をやるとこういう出来事に引っかかるのですよね…。今回引っかかったのはhttpdの秘密鍵と公開鍵の部分。移行前のサーバと同じものを使うためにコピーしてhttpdを起動させるとうまく起動しない。起動しない原因が(日本語に訳すと)「公開鍵ファイルが読み込めないため実行できない」というもの。ファイルのパーミッションは間違いがないのでおかしいな？と思っていたらこのことを思い出して設定を調べてみて判明。特に「/etcに元から存在しないファイルを外からコピーすると/etcのファイルに設定されるべきコンテキストが設定されないため読み込めない」という事態になることが判明。近くにあるファイルのコンテキストをls -dZで確認してchconで設定する、という作業が必要になります。

I219V(e1000e)はLinuxと相性が悪い？

どうもそのようです。e1000eに関するいろいろな記事が出ていますが、移行前および移行先のサーバともNICはI219Vを使用しており、移行後のサーバにネットワーク負荷をかけたところかなりの頻度で通信が切断される、という現象が起こったためいろいろと調べてみた結果の結論です。この症状が出るとログに頻繁に「Detected Hardware Unit Hang」が報告されれ、NICのリセットが行われる、というシーケンスが発生します。なお、私の場合はこれが発生しすぎたためかネットワーク経由でサーバにアクセスすることができず強制的に電源断を行わざるを得なくなりました。

原因としてはTSO(TCP Segmentation Offload)が有効になっているとNICへの負荷が高くなって切断される、というもののようで、セグメント分割の処理をCPU側に戻すとよいようです。方法としてはNICをeth0だとすると

# ethtool -K eth0 rx off tx off tso off gso off

のようにして関連する処理をすべてoffにすればOKです。面倒なのがこれを基本的には「起動時に」行う必要がある点。これについてはFedora32やUbuntu 20.04 LTSでは互換性維持のためrc.localによる記述が有効(ただし、Fedora系は/etc/rc.d/rc.local、Debian系は/etc/rc.local)であることを利用して

#!/bin/sh
ethtool -K eth0 rx off tx off tso off gso off

のような感じのrc.localを用意して実行権限を付与すればOKです。

ちなみに、JumboFrameを有効にするとCPUのC-Stateによる省電力が一部使えなくなるようですが、サーバ用途なので気にしなくても大丈夫だと思います。BIOSの設定でC-stateを無効にしても表示されていたのでどうしようもないかも。

ついでに見つかったのが/etc/resolv.confのシンボリックリンクがなぜかstub-resolv.confを指していて、NICリセット時に一時的に127.0.0.53をDNSサーバと勘違いしていた点。修正しましたが、こちらもなぜこんな設定だったのかは不明。

とりあえず安定状態に持って行くことができた

今回はファイルのコピーにとんでもない時間がかかってしまったのでサーバの設定時間の方がよほどやることがあって進んでいた印象があるのが今回の移行作業でした。また、今回はUSBメモリによるLinuxインストールを何回も行うことになりrufus(USBメモリに起動可能なデータを設定する)が大活躍しました。まあ、これだけOSを切り替えながらやる計画性のないやり方は今回限りにしたいですね。