呼び方はいろいろです。シャットダウンフリー、電源ブチ切り対応、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ポートを持つケースではトラップがあります。
根気よく調べれば必ず正解にたどり着きますが、調べるきっかけを得られない「知らなかった」が最も恐れるべきところとなります。これを防ぐには、コミュニティ活動に何かしら関わっていくのが良いとは思います。日本人にはなかなか難しいですが、今は、リモートでも匿名でも関わりやすくなっているとは思います。