電源ブチ切り 総括

呼び方はいろいろです。シャットダウンフリー、電源ブチ切り対応、ROM化、リードオンリー化、電源断保護、延命化、・・・

本ブログで整理した電源ブチ切り対応の手段は、あくまでも趣味の範囲で、わかる人には十分というレベルで記載しています。業務に関わるレベル(≒Linuxに不慣れな方々のオペレーションレベルまで対応するという意味)での記載は別のクローズなSNSに記載しています。Linuxコミュニティに恩返しする意味でもオープンにしていきたいとは思っています。

なお、最近のSSDをはじめとするFlashバイスは耐久性が上がっており、そのためのOS側の実装も充実しております(TRIM、ウェアレベリング、・・・)。採用するメディアのTBW(Tera Byte Written)と実運用を見て、まずは電源ブチ切り対応の必要性を確認すべきかと思います。あと、ノートPCやスマホ等、バッテリーを搭載しシャットダウンシーケンスをとれる機器は対象外です(バッテリー切れを想定するなら対象ですが)。

1. 目的

電源ブチ切り対応の目的を下記に再整理します。

  • 電源ブチ切りが発生しても確実に再起動するLinuxサーバを構築したい。
    書込中の電源断からの復旧を100%保証できるファイルシステムは無いので。
  • SSDを延命したい。
    Flashメモリの書込回数には上限があるので。
  • Linux PCやラズパイを貸し出すことになったが、中身はいじられたくない。
  • 運用情報を残したくない。
  • [特殊な例]マルウエアに感染しても、すぐに元に戻せるようにしたい。

2. 方式

電源ブチ切り対応の実現方式を大きく分けると、下記の2つです。

① tmpfs方式

RWが必要なディレクトリやファイルをあらかじめtmpfs領域にコピーしてからOSを本核起動します。

② overlayroot方式

RWが必要なディレクトリをあらかじめ定義します。そのディレクトリにライトアクセスがあった場合は差分だけがtmpfsに保存されます。Debian系ならパッケージが用意されています。

①②どちらがいいか

手離れして1年以上電源を切らないなら①、手に届く範囲や1ヶ月以内に電源をオフするような運用なら②です。理由はこの記事の本文にありますが、要は、overlayfsの不具合リスクが顕在化する前に電源を確実に切るなら②でOK、たいていは準備の楽な②で良いとは思います。

3. よくある失敗

①のケースでは、とにかく最初が肝心! インストーラ任せでポチポチ進めてパーティション作ったケースにまつわるトラブルが多いです。最低限、諸悪の根源となるLVM(ボリュームマッパー)は外すこと、不必要にパーティションを分けないこと、SWAPの扱いを理解すること(普通は不要だが適用によっては必要な場合もありケースバイケースであること)等が重要です。他にも/etc/rwtabの不整備やメモリ容量不足トラブルはありますが、そちらは事後でも救いやすいものです(後日追記します)。

②のケースでは、設定が手軽な反面、配慮不足/評価不足による不具合が長期運用で顕在化するので、とにかく長期間電源入れっぱなしの運用には不向きです。

4. その他

開発者から手離れするLinuxプラットホームでは、多くのカーネルパラメータをケアしなければなりません。それらは、カーネルバージョン、CPU種別、チップセットディストリビューション、それらの各世代によって、多くのバリエーションがあります。例えば細かい所を言えば、Intel CPUでは、C-Stateの制限や無効化が場合によっては必要です。LANでの高スループットが必要ならネットワークパラメータのマニュアル設定が必須です。複数LANポートを持つケースではトラップがあります。

根気よく調べれば必ず正解にたどり着きますが、調べるきっかけを得られない「知らなかった」が最も恐れるべきところとなります。これを防ぐには、コミュニティ活動に何かしら関わっていくのが良いとは思います。日本人にはなかなか難しいですが、今は、リモートでも匿名でも関わりやすくなっているとは思います。