長期運用される Raspberry Pi のための考慮事項
(dzombak.com)- Raspberry Pi を数週間から数年にわたって無介入の状態で維持するには、障害が発生したときに自動的に復旧する経路をあらかじめ設計しておく必要がある
- このガイドは、既存の SD カードの摩耗を減らす記事を置き換える、より広範な信頼性シリーズであり、問題の種類ごとの対策とモニタリングのヒントをまとめている
- 主なリスクは、WiFi 接続の失敗、サービス停止、ハードウェア・ファームウェア・ドライバーの不安定さによるクラッシュ、SD カードの摩耗または容量超過に分けられる
- SD カードの問題は、適切な microSD の選択、swap の不使用、書き込み削減、読み取り専用ルートファイルシステム、必要に応じた fsck の実行で緩和できる
- journaling の無効化は摩耗を減らせる可能性がある一方で、クラッシュや停電時にファイルシステム破損のリスクを高めるため、長期安定性という目標には合わない
長期運用でまず見るべき障害ポイント
- Raspberry Pi を長期間オンラインに保つには、各障害状況で Pi がどのように復旧するかを検討し、解決策の利点とリスクも併せて比較する必要がある
- 著者は自宅で Raspberry Pi を低出力 FM 送信機や UPS エネルギーモニターなどとして使用している
- Raspberry Pi Reliability シリーズは、実際に遭遇した問題の種類と解決方法を整理し、主に Uptime Kuma を活用したモニタリングのヒントも含んでいる
- このシリーズは、既存の SD カードの摩耗を減らす記事より包括的なガイドを目指しており、リンク先の記事群が更新版の代替として機能する
問題の種類ごとの対策と避けるべき選択
- WiFi 接続の失敗は、長期運用でまず考慮すべき障害の種類である
- ソフトウェアサービスの停止は、別途復旧戦略が必要な領域である
- ハードウェア・ファームウェア・ドライバーの不安定さは、クラッシュにつながる可能性がある
- SD カードは摩耗したり、完全にいっぱいになったりする可能性があり、運用方法に影響する
- 適切な microSD カードの選択から始める
- SD カードを swap に使わない
- SD カードへの書き込みを減らす、特にログ書き込みの削減とルートファイルシステムの読み取り専用化を検討できる
- 読み取り専用ルートファイルシステムを使わない場合は、ファイルシステムを頻繁に検査する必要がある
- 不要なサービスの無効化は、ソフトウェアの安定性と SD カード摩耗の緩和の両方に役立つ
- 侵襲的な介入を適用する前に、まずリスクと利点を比較する必要がある
- 障害が実際に発生したときの原因究明には、リモートロギングが有用である
- Stack Exchange のある投稿は Pi のファイルシステムの journaling 無効化を提案しているが、クラッシュや停電時にファイルシステム破損の可能性を高めるため、避けるべきである
1件のコメント
Hacker News のコメント
代わりに Lenovo mini PC を買い始めたが、18cm x 18cm x 3cm なので今でもかなり小さい
最近はかなり安く手に入り、きちんとしたケースと冷却も備えている: https://psref.lenovo.com/syspool/Sys/PDF/ThinkCentre/ThinkCe...
すぐ横に1台置いて使っているが、i5-8500T、32GB RAM、SSD 2台構成で、
powertopの自動チューニング状態では現在アイドル時の消費電力が5W: https://wiki.archlinux.org/title/powertopマイクロコントローラーにシリアル接続を追加することはできるだろうが、そうすると解決策があまりすっきりしなくなる
最近は NAS（N5105）とサービス用マシン（3215U）も、eBay やフリーマーケットで中古で手に入れた mini PC とロック解除済み Chromebook に移した。安く、消費電力も低く抑えつつ、計算性能は Pi とはまったく別次元だ
オーストラリアではリース終了で放出される機体が何千台も出てくる。8500T や 8700T チップは優秀で、公式に Windows 11 を実行でき、ハードウェアトランスコーディングも内蔵しているので Plex サーバーに向いている
手持ちの1台は 2TB SSD 2台と 64GB RAM にアップグレードしており、問題なく24時間365日動いている
SDカードがおそらく最大の問題原因で、RPi に SSD などを接続する費用まで考えると、もはや費用対効果がよくなかった
最初の助言が、ファイルシステムのジャーナリングモードを有効にしろ、であるべきではない
最初の助言は、ファイルシステムを 読み取り専用 でマウントし、
/varはメモリ上にマウントし、すべてのログを RPi ではなく、まともな UPS と NUT が動いているノードへ送ることにすべきだ。ファイルシステムが読み取り専用か一時領域なら、停電は実質的に無害になるRPi が1台だけならやり過ぎかもしれないが、筆者は家のあちこちで複数台使っていると言っていた
また、A/B システムパーティション を用意し、パーティション全体を書き直す方式でアップグレードしてからアクティブパーティションを切り替えるのもよい。そうすれば新バージョンに致命的なバグがあっても、常に正常なシステムパーティションが1つ残り、復旧しやすい
この方式で、さまざまな用途の複数の小型／シングルボード PC を20年以上うまく使ってきた
https://www.dzombak.com/blog/2021/11/Reducing-SD-Card-Wear-o...
/varだけでなく/tmpのような場所にも tmpfs を使うべきだ。そうすれば SDカードの寿命は大きく延びるはず新しいディスクイメージをどう作るのか、各デバイスにログインしてアップグレードするのか、それとも自動化があるのか知りたい
/varをメモリ上にマウントしたときにデバイスのメモリを超えることがある/var/lib/dockerを補助ストレージに移す必要があるかもしれない2011年に Global Scale Technologies の初期のプラグコンピューター上で動く商用製品を作ったことがある
20台しか売れなかったが、全台が SDカード破損 の問題で返品され、急いでルートファイルシステムを読み取り専用に変更しなければならなかった。それ以来、この方式を気に入っている
その初期の商用製品は、ごく小さなホームオートメーション機能を含む家庭用セキュリティ製品で、2021年に新しい名前でオープンソースとして公開し、今は Jetson 系シングルボードコンピューターで動作する: https://github.com/hcfman/sbts-install
今では高度な YOLO モデルもトリガーとして含まれている。スタンドアロン製品を意図していたため HTTPS をサポートし、証明書まわりの作業全体を包む GUI もあった。この機能はオープンソース版にも残っており、デバイス間の REST 呼び出しに自己署名証明書を使いやすい
また、マルチパーティションのメモリ overlayFS 方式を維持・拡張しており、インストール時にまず
sbts-baseシステムをインストールするようにして、他の人がそれを自分のベースシステムとして使えるようにしている時間が経つと、ディスク書き込みのたびにシステムが1〜2秒ずつ止まり始め、かなりつらかった
こういうことをしようとしている人には、まず ESP32 のような小さなボードで必要な処理をまかなえないか見てみることを勧めたい
消費電力はずっと少なく、価格は数ドル程度で、多くの用途には十分。Python 系を好むなら、多くのボードが MicroPython と CircuitPython の両方をサポートしている
初期購入費用と継続的な電気代を減らせるので、検討する価値はある
マイクロコントローラーで実現したプロジェクトは、Pi ベースのプロジェクトより何十年単位で安定していたし、デフォルトの SSH 設定を変え忘れてボットネットの一部になる心配も少ない。デフォルトは
pi:raspberryではなかったかと思うMicroPython 以外にも、ESP32C3 向けの no_std Rust サポートは毎月よくなっている。趣味で小さなホームオートメーションプロジェクトをする人にとっては、追加の制約がむしろ楽しく、やりがいのあるものにしてくれることもある
ただし Linux にすでに慣れている人には Pi のほうが概してずっと簡単で、私の経験では費用は少なくとも10倍くらい高い。同じレベルの安定性を得るための SSD ブート、ネットワークブート、読み取り専用ルートファイルシステム、ウォッチドッグ設定といった追加構成や、より高い消費電力、特に Pi 5 の電力も意思決定に含めるべき
ESP32 でパスワードマネージャーのサーバーを動かせるか？ できない。Pi-hole は？ 無理。Unifi コントローラーは？ 無理
こういう提案は、人々が Pi をガレージドアのコントローラーみたいな用途に使っていると想像しているようだが、反射的に ESP32 を Pi の代替として提案するのはあまり役に立たない
何かがうまくいかないときに HDMI とキーボードをつないで、一般的なユーティリティがそろったメインライン Linux 環境でその場でデバッグすることはできない
Arduino の代わりに MicroPython を初めて使ってみたが本当に気に入っていて、驚くほど非常に安定している。以前は Wi-Fi の電力状態のせいで長期的にはプロジェクトがよく壊れていたが、今のところ MicroPython 構成では問題がない
「Wi-Fi 接続が大丈夫かを定期的に確認し、そうでなければ Wi-Fi インターフェースや Pi 全体を再起動するスクリプトにほぼ行き着く」というのはハックではなく ベストプラクティス
データセンターの重要なサーバーに IPMI やリモート制御可能な RPDU コンセントのようなアウトオブバンド接続が必要なように、アクセスしにくい遠隔地の重要なサーバーにはウォッチドッグスクリプトが必要
もちろん再起動の影響と、再起動までのダウンタイムを考慮して用途に合わせて調整する必要があり、少なくとも後で調査できるように異常イベントを記録することはできる
リモート RPi を配備したとき、最初にやったのは簡単な Bash のウォッチドッグスクリプトだった。Wi-Fi の問題だけでなく、壊れる可能性があり、再起動で直る可能性のある何十もの状況のためのものだった
init がサービスを管理できると信頼できないなら、システムがサービスを提供するという保証はどこから来るのか疑問
スクリプトで作り直すこともできるだろうが、私たちはすでにその段階を過ぎている。systemd に多く触れているが、ひいきしたいわけではなく代替手段もある
ほとんどのサービスは、自分が存在する環境をきちんと活用していない。Web サーバーが特定のマウントを必要とすると宣言するような、サイト固有のカスタマイズを期待しているように見える
よく見落とされるディレクティブが
PartOf=だ。あるサービスやリソースの再起動を別のものと結び付けられるもっと簡単には、NetworkManager が Wi-Fi/ポータル確認をカスタマイズする方法を提供しているはず。完全に過激な方向に行く必要はないかもしれない
ルーターについては、適切な SSID への接続を試み、ルーターに ping を送って、どちらか一方でも失敗すれば別のルーターに切り替える。同じ設定の同じルーターを2台用意し、電源は SPDT リレーの NO/NC 接点につないで、一方が失敗したらリレーの状態だけを変えてもう一方へ切り替える
ルーターが生きていれば、ウォッチドッグはケーブルモデムのステータスページを取得し、ISP ネットワーク内で CMTS かその近くの機器に見える3つの IP のどれかに ping を送って、HFC 設備が生きているか確認する。再起動で解決できない障害なら、わざわざ再起動したくないからだ
残念ながら、同じ MAC を持つケーブルモデムを2台用意して切り替える方法は見つけられず、ISP も同じアカウントでモデム2台を許可していないので、ケーブルモデムが失敗したら再起動してうまくいくことを願うしかない
これに、停電中でもルーターとモデムを30時間以上動かせるバッテリーラックを付けており、2020年5月に作ってからほぼずっとオンライン状態を保っている。コードはひどいが、実際には非常に堅牢に動作している
完璧なコードと設計でも防げないことは起きるし、ウォッチドッグタイマーは無限ループを断ち切ってリセットしてくれる。宇宙線がビットを反転させることや瞬間的な電圧低下のようなものもあり、Raspberry Pi では SD カード破損も心配しなければならない
Raspberry Pi には内蔵ハードウェアウォッチドッグタイマーがあると認識している。Arduino には確実にある
ほぼ10年にわたり、本番環境で数千台の Piを運用してきて、いまは x86 への移行を始めている
Pi の価格性能比は以前ほどではなくなった。最近 State of Open Con でこの経験について発表した: https://youtu.be/vX-qK9mxKZI
私たちのサービスではまだ使っていないが、ドキュメント上はかなり堅牢そうで、ディスク/SD 上のデータを保護できる
私たちはまだ Pi にかなり満足しており、よりオープンな API である Mesa/DRM/KMS/FFmpeg へ移行したことも、ようやく実用的な状態になってきていて非常に有望に見える
主な用途はいまもデジタルサイネージなので、生の処理性能はそれほど重要ではない。コストの大きな部分である動画デコードは当然アクセラレーションされるし、Pi で可能な後方互換性は素晴らしい。いまでもほぼ10年目の Pi1B+ を動かし続け、私たちが提供する最新 OS リリースを使っている顧客がいる
寿命も見るべきで、そこでも ARM のほうが x86 より長持ちしそうだ。モジュール性の面でも ARM は x86 より優れている。小さなデバイスを複数置くほうが安いからだ
ただし拡張性、つまり現在の経済状況での事業性は x86 のほうが ARM より良い
また、すべてのグラフはワット当たりを基準にすべきだ。2 から 4 へ移って性能が上がったというのは新しい話ではなく、重要なのはワット当たり性能が向上したかどうかだ
そう見ると、Raspberry Pi 5 はワット当たり性能の向上が期待ほど大きくないことが分かる。人類史上、恒久的にピークに達してしまったように思える
最後に、現時点で何らかの進展に対する唯一の希望は、性能ではなくオープン性の面で JH7110 だが、3D 対応が遅れている
そうしたことを何一つしていなくても、いくつかの Pi は新モデルに交換されるまで何年も問題なく動いていた
HomeKit/Zigbee ゲートウェイとデータロガーはいま Pi 4 だ。結局、良い SD カードと安定した電源供給が肝心なのだと思う
pibenchmark は良い情報源だと思う: https://pibenchmarks.com/
購入前に SD カードは必ず比較すべきだ
十分に多くのデバイスを運用すれば、起こり得る問題はすべて起きるし、夢にも思わなかった新しい故障モードも現れる
その後、カード破損の報告が多かった理由はおそらくそれだろう
micro SD カードに Raspbian をインストールし、Cups を設定し、プリンターに USB を接続した以外は何もしていない。別の1台はネットワークプリンターを管理している。その後は放置しているだけだ
今では大半を SSD に替えた。そうしないと、あまりに運任せに感じる
SD カードの話が最初に出てこないことに驚いたし、記事でUSB ブートを提案していないことにはさらに驚いた
Pi を1台、何年もほぼ 24/7 で稼働させているが、問題がなかった理由は、1) ディスクにほとんど触れないよう Alpine を構成したこと、2) 破損する SD カードがないこと、だと思っている。なぜ USB のほうが安定するのかは分からないが、経験的にはそうだった
失敗する唯一の理由は停電時だ。10分だけ持つバッテリーがあれば十分すぎると思う
たとえば https://wiki.alpinelinux.org/wiki/Installation#Diskless_Mode のようなものを言っているのか知りたい
カードを抜いて、そのカードと次の Pi は USB SSD に替えて使っている。少し怖かった。それでも前述のとおり、micro SD で Cups サーバーを何年も問題なく動かしている Pi もある
RPi 2台はいずれも USB からブートして動かしており、何年も順調に稼働している
2017年から同じSDカードで2台のPiをほぼ継続して動かしている。停電は2〜3回ほどあった
1台はDNS/プリントサーバーで、もう1台はKodi、メディアは外部NFS上にある。自分がやったことは全ログをオフにしただけで、一度も問題はなかった
どちらも SanDisk 2GBカード を使っている。「容量が少ない → ビット密度が低い → 信頼性が高い」というふうに素朴に考えていた記憶がうっすらある
log2ram（github/azlux/log2ram）を使ってきており、結果には満足している/varにRAMディスクをマウントし、たまにログをRAMディスクからSDカードへコピーするだけ。おかげでSDカードを激しく叩かなくても、すべてのログを確認できるほとんど電源は入ったままだが、接続しているUSB電源をうっかり切ってしまうことがたまにある。5ポートの小型電源で、これもほぼ同じくらい古く、自分の構成では電源ボタンがあまりに押されやすい
基本的にすべてのログとWebページをtmpfsにマウントしており、DBはSDカード上にあって5分ごとに書き込まれる
いくつかのインストールを経たが、今はバックアップDNSサーバーになっている。ファイルシステムを見ると2018年からPi-holeとして使われており、数回の再起動と引っ越しの時を除けば、実質的に24時間365日動いている
SDには何も書き込まず、すべて
/dev/shmのRAMへ送っている。Pi-holeはまれに落ちてもリストを取り直せばよく、そもそも毎日ダウンロードしている後にはローカルDNSとTailscaleノードとしても使い始めた。数か月再起動しなかったこともあり、最長稼働時間は約11か月だった。非常に堅牢だった。UPSにつないでおくと確実に役に立つ
「Raspberry Piを数週間、数か月、数年間、手を入れずにオンライン状態に保つのは、ある程度は職人芸だ」とあったが、私は 組み込みファイルシステムを含むNetBSDカーネル を起動している
たとえばINSTALLカーネルやカスタムカーネルを使う。起動直後にSDカードは抜いてもよく、必要に応じて接続したストレージへ
chrootするこうすれば数週間、数か月、数年間動く。ブログ筆者が挙げていた問題は経験したことがない
私が見つけた唯一の問題は、ケースを使うときの電源コネクタまわりだ。たとえば交換用ケーブルを使うと接続が弱いことがある。最近のPiでは改善されているかもしれない
だが、たいていのコンピュータでも似たようなことは言える。ケーブルとコネクタはたいてい弱くて安価な部品だ。動いた拍子に電源が切れると、Piは自動的に再起動する