- 24台の4TB HGSTドライブで作った71 TiB ZFS NASが10年以上運用され、マザーボードと電源ユニットは交換されたが、ドライブ故障はまだ一度もなかった
- 10年間でドライブの累積稼働時間は約6000時間にとどまり、必要なときだけリモートで電源を入れる方式が電力コストを大きく下げた
- HNでは、24台のドライブが10年間すべて無故障である確率は思ったより高いという意見が出ており、電源を頻繁に切っていたおかげだと断定するのは難しい
- ZFSはOS変更後もプールを問題なく再インポートでき、年に数回実行したzpool scrubでもチェックサムエラーは一度も見つからなかった
- 騒音、ネットワーク、UPS、バックアップ、交換計画はいずれも電力・コスト・リスク許容の間の妥協として運用され、同じ容量は将来6〜8台のドライブによるRAIDZ2でも実現可能
10年以上持ちこたえた71 TiB ZFS NAS
- 24台の4TBドライブで構成した4U 71 TiB ZFS NASが10年以上使われ続けている
- 現在のシステムは2枚目のマザーボードと2台目の電源ユニットを使用中
- ドライブ故障はまだ一度もない
- 4TB HGSTドライブの累積稼働時間は約6000時間で、10年基準で約250日分の稼働時間に相当する
必要なときだけ電源を入れる運用
- NASは基本的に電源オフで、必要なときだけリモートで電源を入れる
- 電源投入の流れは次のとおり
- スクリプトでIoT電源タップをオンにする
- BMC(Baseboard Management Controller)の起動が終わると、IPMIでNAS本体を起動する
- 代替としてWake-on-LANも使えた
- 使用が終わると小さなスクリプトでサーバーを停止し、数秒待ってから壁側の電源を切る
- サーバーだけを停止してマザーボードとBMCの電源を残すと約7Wを消費し続けるため、この方式は避けた
- 他のサービスはRaspberry Pi 4や待機電力がはるかに低いサーバーで実行しているため、大きなNASを常時稼働させる必要はなかった
- 主な動機は電気料金の節約であり、ハードドライブの寿命にも良さそうだと判断した
- ただしHNでは、24台のドライブが10年間無故障である確率は予想より高いという意見が出ており、この結果を電源遮断運用のおかげだと断定するのは難しい
- 以前のNASも20台の1TB Samsung Spinpoint F1ドライブで約5年間運用し、ドライブ故障はなかった
ドライブより先に問題を起こした部品
- ドライブは無事だったが、数年前にマザーボードは交換が必要になった
- 故障症状はBIOSに入れず、時々起動に失敗するというものだった
- CMOSバッテリーの取り外しなど基本的な対処を試したが解決しなかった
- 同じマザーボードがEbayで手頃な価格で販売されていたため、大きな問題なく交換した
- 同じボードが必要だった理由は、サーバーがPCIeスロット4本を使っていたため
- 構成はHBA 3枚と10Gbit NIC 1枚だった
- 電源ユニットは、起動時にすべてのドライブが同時にスピンアップし、数秒間で約600Wを消費する条件にさらされていた
- 電源ユニットは750W定格で、12Vレールも十分な電力を出せたと記憶しているが、起動時に時々遮断された
ZFS運用とscrubの結果
- ZFSは数年間問題なく動作した
- OSを何度も変更したが、新しいOSのインストール後に既存プールを再インポートする際に問題はなかった
- 新しいストレージサーバーを作るなら、またZFSを使うつもり
- zpool scrubは年に数回実行する
- scrub 1回の完了には約20時間かかる
- scrub中は電力使用量が大きいため、変動電気料金プランで電気が安い日に実行する
- これまでscrubでチェックサムエラーは一度も見つかっていない
- すべてのドライブを合わせて1ペタバイトを超えるデータを読み取ったはずだが、ZFSが復旧に介入しなければならない状況はなかった
ドライブエラーとサイレントデータ破損
- ドライブ故障は主に2種類に分かれる
- ドライブがまったく検出されない完全故障
- 読み書きの失敗や不良セクタ
- 3つ目の形であるサイレントデータ破損は非常にまれだと見ている
- ディスクが破損したデータを渡したことに自分で気づかない場合
- SATA接続でチェックサムエラーを検出できない場合
- 低レベルのチェックサム検査が多いため、このリスクは非常に小さいと見ている
- サイレントデータ破損は実際のリスクだが、住宅環境よりもデータセンターのような大規模環境でより気にすべき問題だと見ている
- ZFSはLinuxやFreeBSDに慣れたユーザーなら学ぶ価値があり、学習が非常に難しいわけではない
静かなNASのためのファン制御
- このNASはNASとしては非常に静かな部類
- シャーシには24台のドライブベイを冷却する頑丈な12Vファン3基が入っている
- 標準速度で回ると非常にうるさいが、低RPMではかなり静かで、ほとんどの状況で十分なエアフローを提供する
- 低速だけでは、ドライブの読み書き中に温度が最終的に上がった
- 使用したSupermicroマザーボードは、Linuxからすべてのファンヘッダーを制御できた
- 最も熱いドライブ温度に応じてファン速度を調整するスクリプトを作った
- 数学関連のサブレディットで、静かでありながらドライブを冷やすのに適したアルゴリズムを尋ねたところ、PID制御器を勧められた
- PythonでPID制御コードを書き、サンプルコードを取り入れてパラメータを調整した
- このスクリプトは数年間うまく動作し、ドライブ温度を40°C以下に保った
- 基本エアフローが少ないため、HBAやネットワークカードなどPCIeカード4枚を冷却する追加ファンも必要だった
ネットワーク構成の変化
- 当初はクアッドポートのギガビットネットワークコントローラーとネットワークボンディングを使っていた
- この構成で複数システム間に約450MB/sの転送速度を得た
- UTPケーブルが多すぎたため、その後安価なInfinibandカードに変更した
- Infiniband構成ではシステム間で約700MB/sに達することができた
- UbuntuからDebianに戻すことにしたところ、Infinibandカードが動かなくなり、原因を解決できなかった
- その後、中古の10Gbit Ethernetカードを購入し、今まで問題なく動作している
UPS、バックアップ、リスク許容
- しばらくの間、停電時の正常シャットダウンのために大きなUPSを使っていた
- UPSがサーバーの電力使用量に加えて10W以上を余分に消費することを確認し、取り外した
- 電源問題でシステムを失うリスクは受け入れることにした
- 最も重要なデータは3回バックアップしている
- サーバーに保存された多くのデータは、バックアップするほど重要ではないと見ている
- ドライブ故障によるデータ損失は、交換用ハードウェアとZFSに依存する
- その保護が十分でなければ損失を受け入れる条件で、10年間運用してきた
より小さな構成でも可能な次世代
- 現在、将来のストレージ計画は特にない
- 最初にこのサーバーを作った理由は、保存容量不足でデータを移し続けたくなかったためで、今も容量は十分に残っている
- 予備のマザーボード、CPU、メモリ、HBAカードがあり、故障してもシステムを復活させられる可能性が高い
- ハードドライブ容量が大きく増えたため、いつか24ベイシャーシをより小さなフォームファクターに置き換えるかもしれない
- 同じレベルの冗長ストレージ容量は、6〜8台のハードドライブとRAIDZ2、つまりRAID 6相当の冗長性で作れる
- ストレージは依然として高価だと見ている
- もう一つの可能性は、今後数年以内にシステムが最終的に故障し、交換しないままストレージ趣味が終わること
1件のコメント
Hacker News の意見
ドライブの交換周期があるのか気になる
24台のドライブが同じモデルで同じロットである可能性が高く、摩耗度も似ているはずなので、大半が同じような時期に故障し、残りも再構築中に増えた負荷のせいで一緒に故障する可能性がある
信頼できるストレージは難しい
当然どちらも同時に故障し、徹夜で復旧作業をする羽目になった
本当に運がよかったということだ :D
ただ、ハードウェアの摩耗がそこまで一貫しているとは思えない
ドライブ1台が死に、再構築中に2台目も後を追って死ぬまではうまく持ちこたえていた
もちろん ZFS でもなく、定期的なスクラブもなく、2000年代のドライブ故障率も違っていたかもしれず、使わないときに電源を切ってもいなかった
重要なのは正確な原因よりも相関した故障だ。サンプル数1、インターネット上のランダムな人、というお決まりの但し書きは付く
「この NAS は NAS としては非常に静かだ」という部分は、半径の大きいファンが低 RPM でも多くの空気を動かせて、エネルギー効率もはるかに良いからだ
Oxide Computer が発表で 80mm ファンを使う理由を話していたが、静かで、さらに重要なことに消費電力が低いからだと言っていた
他のサーバーでは電力の最大25%がファン駆動に使われる一方、自分たちでは約1%だと観測した、という内容だった
https://www.youtube.com/shorts/hTJYY_Y1H9Q
https://www.youtube.com/watch?v=4vVXClXVuzE
ほとんど姿を消した Flex ATX 電源の 40mm ファンを除けばそうで、80mm も最近はかなり珍しい。普通は 120mm や 140mm をよく見る
典型的な DC 高 RPM 小型ファンの高周波ノイズは本当に嫌いだ
ファン速度の制御にも何か「賢い」方法を使っていてほしい ;-)
より大きな風量をより低い速度で動かすという考えには完全に納得している
1U や 2U シャーシでは難しい点は理解している
それでも良い。ファンノイズの低減だけでも驚きなのに、こんなに単純に見えることを、なぜ以前は誰も考えなかったのか不思議になる
ドライブは回し続けたほうが電源サイクルによる摩耗を減らせる、という正反対の助言を聞いたことがある
何を信じるべきかは分からないが、ZFS NAS を電源オンのままにして、定期的にスクラブを走らせてデータを確認できる点は気に入っている
ちなみに4ドライブのシステムを10年間動かして、その間にドライブ故障は2回あったが、エンタープライズ向けではなく WD Green だった
1日に1、2回ドライブの電源を入れたり切ったりすることと、15分以下ごとにスピンダウンすることは違う
WD Green ドライブは NAS 用には推奨されない。昔は読み書きヘッドを数秒ごとにパーキングすることがあり、データアクセスがまれなら問題ないが、サーバーでは継続的な摩耗につながり早期故障を招く可能性がある
読み書きヘッドはプラッター上に浮いている間はほとんど摩耗しない。電源を切るとヘッドがランプやプラッターのランディングゾーンに物理的に降り、着陸と離陸がヘッドに最も大きな摩耗を与える
最悪の場合、静止摩擦のために離陸中にヘッドが引きちぎられることもある
ベアリングもより長持ちし、長く止まりすぎると固着することがある。ドライブモーターも同様だ
電源投入時の突入電流も、どれほど小さくても電気的ストレスである
ハードディスクの電源を切る理由は、省電力、騒音低減、運搬くらいだ
すると1日のうちに何度もスピンアップとスピンダウンが発生し得るので、この主張はまったく納得しにくい
ただし、これを裏付ける証拠は持っていない
そうなら、ディスクが数分ごとにオン/オフするのを防ぐために回し続けることが寿命改善に役立つ可能性がある
しかしホームラボなら、ディスクの維持費で節約できる額よりも電気代のほうにはるかに多く払っている可能性が高い
家族のメディア用の大容量ドライブがいくつかあるので、「ドライブが故障していない」以上の確信を持って保護したい
チェックサム対応ファイルシステムの議論はたいてい ZFS と BTRFS を中心に進むが、bcachefsを使ったことがある人がいるのか気になる
Linux カーネルに upstream されており、全体チェックサムをサポートしていると理解している。作者もファイルシステムの責任を真剣に受け止めているように見える
ここで使っている人はいる？
https://bcachefs.org/
RAID 全体がジャーナルの問題でマウントできなくなるまで、およそ1週間だった。構成は HDD 8台、書き込みキャッシュ用 SSD 2台、読み取りキャッシュ用 NVMe 2台だった
作者は Reddit で1日以内に返信し、彼の修正案を適用してみた。Linux カーネルをコンパイルしてそれで起動する必要があったが、問題は解決しなかった
その後は残念ながら返答がなく、数日待ってから消去して普通の mdadm RAID に戻した
重要なものは当然すべてバックアップしていたが、重要でないデータの一部は失い、最先端は不安定だという事実を思い出すことになった
ただ、セットアップ手順と機能は素晴らしかった。ディスクを追加して読み取り/書き込みキャッシュとして指定できるだけでも良かった
さらに数年熟成したら、間違いなくまた試すつもり
[1] https://linuxiac.com/torvalds-expresses-regret-over-merging-...
[2] https://news.ycombinator.com/item?id=41407768
本番データではリスクを取りたくないが、ホームラボならありかもしれない
ただし、何か問題が起きたときにどれだけ時間を費やすつもりがあるのか、自分に問いかける必要がある
ZFS も15年以上使ってきて、悪いハードウェアのせいでいろいろ経験したが、良質なエンタープライズ向けハードウェアでは完璧に動作していた
約2TiBの SSD を約8TiBの大型ハードディスクの前段に置き、SSD をキャッシュとして使う構成を試している
Ubuntu で今ではレガシーになった zsys + ルート ZFS の組み合わせで細かな問題を経験したが、一般的な構成で、何年も広く使われているのでサポートを見つけやすい
bcachefs も同じくらいの採用率とコミュニティサポートが得られるまでは使わないと思う
ドライブが動作する環境が寿命に非常に大きな差を生むと思う
住環境はデータセンターやオフィスよりはるかに変動が大きい。温度や湿度の変動も大きな課題だが、驚いたのは少量のホコリでもかなりはっきり影響するという点だった
かなり前に、地下室にある古い Dell サーバーで 8x500G のアレイを動かしていた。ドライブはすべて新品の Seagate で、7200RPM、“エンタープライズ”版だったかもしれない
5年間、平均して6か月に1台ドライブが故障した。パリティドライブを2台用意し、予備ドライブを保管し、故障するたびに RMA を出していた
引っ越し後にラボ専用の部屋を持てるようになり、同じ構成でその後5年間は故障が1件もなかった。新しい環境のほうが良いだろうとは思っていたが、より清潔で安定した環境がここまで効くとは驚きだった
NAS/ファイルサーバーをホコリの多い住環境に置いたまま使い続けてきたし、今でもふわふわした灰色の Synology ロゴが見えるくらいだが、そんなことは経験したことがない
あの世代にはファームウェア問題があったのだと思う
ここの年間故障率を見るといい: https://www.backblaze.com/blog/best-hard-drive-q4-2014/
最近の密閉されたヘリウム充填ドライブでは、そもそも問題だったとしても、今では大きな問題ではないはず
「電源問題でシステムを失うリスクは受け入れる」という部分に関連して、UPSが防いでくれるもう一つの非常にまれな故障として電気的な不均衡がある
近所の工事中に電気の問題が起きたり、家の近くの電柱に雷が落ちたりすると、上下方向のスパイクが発生することがあり、どちらも破壊的になり得る
最初の職場で約10年前、複数のサーバーがそういう形で壊れた。ただし、その手の問題を聞いたのはその時だけ
自分の理解では、UPSはそうしたスパイクも防いでくれ、サーバーが損傷する前にUPSが先に壊れるはず
実家のテレビアンテナに直接雷が落ち、同軸ケーブルで通信ボックス内のアンプ／分配器までつながっていた
その後どうなったのか、近くのネットワークパッチパネルへ飛び、ネットワークにつながっていた有線イーサネットコントローラをすべて焼いた。スイッチポートやAPに内蔵されていたものも含む
ネットワークスイッチでは電流が接地へ流れようとしたのか、電源ユニットまで破壊された
同軸からCat5へどう飛んだのかはいまだに少し謎。電気工事士がどこかで近接して並行に配線していた区間があったのかもしれない
ネットワーク全体を敷き直す必要があったが、幸い現場に有線接続のコンピュータはなかった。ストレージも耐えられなかったと思う
Office Depotで買う99ドルの850VA APCはそうではない。交流からバッテリーへ非常に素早く切り替えるだけで、実際に電源を浄化するわけではない
良い製品を買えるなら、長期的にはハードウェアの信頼性を本当に高めてくれる。クリーンな電源は良い
壊れた機器、損傷した機器、見た目には無事な機器の分布を見ると、VDSLを載せた銅線が非常に直接的な経路だった。モデムはイーサネットで他のすべての機器につながっていた
まともな解決策は、おそらく光に変換して光ファイバー区間を少し通し、その後また変換することだと思う。電気はガラスより別の経路を選ぶ可能性が高い
ところが製品選びが予想よりずっと面倒で、ネットワーク系の人間ではないので1時間ほど製品の違いを見分けようとして諦めた
そこでVDSLモデムと残りの機器の間にWi-Fiブリッジを入れておいた。次の嵐ではその故障モードが隔離されることを願っている
同じモデムにつながっていたZFSアレイがあったが、生き残ったものの、運が良かったのだと思う
当時サーバーはなかったが、LED電球が数週間おきに故障していら立った。60年代の古い建物で、自宅の電気設備にも怪しい応急修理があった
「秘密」は電源を切ることではなく、単に運
4TBのHGSTドライブを10年以上24/7で回している。正確には24台ではなく8台だが、故障は0台
自分も運が良いだけで、同じドライブで何度もRMAに出した知人もいる
一番気になるのは、ほとんどの時間オフにしておけるのに、71TBも必要なデータとは何なのかという点。バックアップ保存サーバーなのか？
例えばベアリングは冷えていると固着することがある
統計に詳しい人なら、年間故障率を1%程度と見積もって24台がすべて生き残る確率を計算できそう
しかも以前のNASの20台のドライブも故障なしだった。となるとN=44だが、どれほど運が良い必要があるのだろう？
住宅用途で使っていて、データが必要なときはたいてい10Gbitでずっと低消費電力のシステムにコピーし、その後このNASはまたオフにする
電源サイクルが危険だったドライブもあった
なのでモデルには同意するが、これが常にすべての人にとって良い方法だと仮定すべきではない。一部のSSDは定期的に電源を供給する必要がある
NASの使用サイクルなら、おそらくその要件は満たすだろう
たぶん問題なく、電気代は確実に安い。軸に余分なグリースが入っていたドライブは、かつての特殊事例だった
Backblazeがドライブのオン／オフと寿命の統計モデルを持っているのか気になる。あちらは常時オンの問題領域にいる気がする
ただ、自分の場合これらのドライブを頻繁に電源サイクルしてはいない。多くても月に数回
大きなリスクではないと言ったり証明したりはできないが、そうではないと信じて15年以上そのリスクを受け入れてきた
ハードディスクにはアイドル時にスピンダウンするオプションがあることも覚えておくべき。つまりハードディスクは1日に何度ものスピンアップに耐えられる
Synology機器を何台かバックアップするために内蔵3.5インチHDDとUSBドックを使っていたが、ファイル復元や追加バックアップのためにドライブをドックへ挿し直すと、10回に1回くらいは再び電源が入らない感じだった
本番環境で数年前からZFS上の複数TB PostgreSQLデータベースを使っており、これまでビット反転を含め何の問題も経験していない
興味のある人のために、経験をここに文書化してある:
https://lackofimagination.org/2022/04/our-experience-with-po...
起動中の断続的な電源断については、ドライブが起動時に5Vレールから電力を引く点を見るべき
似たようなドライブは通常最大1.2Aを消費する。5Vレールの最大負荷が25Aである点（Seasonic Platinum 860W）を合わせると、staggered spinupを使わない場合、起動中に電源障害が発生する可能性が高い