ハードウェア中級 #6 RAID 運用の実際 — リビルド・スクラブ・バックアップ

インフラ ハードウェア
読了 6分

第5回 がディスク 1 枚の性能だったなら、今回は複数枚の運用です。基礎 #5 で RAID レベルの概念 (0/1/5/6/10) をつかんだので、ここでは運用者が実際に出会う場面へ進みます。RAID の本当の試験はディスクが無事なときではなく、1 枚が死んだあと に始まるからです。

デグレード — 1 枚が死んだまま走る #

ディスクが 1 枚死ぬと、アレイはデグレード (degraded、冗長性を失ったまま動く状態) に入ります。サービスは動き続けますが、2 つのことが変わります。

  • 性能が落ちる — パリティ方式 (RAID5/6) では、死んだディスクのデータを読み取りのたびに残りのディスクのパリティから計算して復元する必要があります。
  • 余裕が消える — RAID5 なら、もう 1 枚死んだ時点でアレイ全体が終わります。

だからデグレードは「まだ大丈夫な状態」ではなく、カウントダウンが始まった状態 です。モニタリングがアレイの状態を人に知らせるところまでつながっているかが、RAID 運用で最初に点検すべき項目です。

リビルド — もっとも危険な時間 #

死んだディスクを交換するとリビルド (rebuild、残ったディスクからデータを再計算して新しいディスクを埋める作業) が始まります。逆説的ですが、この復旧時間こそアレイの一生でもっとも危険な時間です。

  • 長くかかる — リビルドは新しいディスクを最初から最後まで埋める作業なので、数十 TB のディスクでは 1 日を越えることもあります。サービス I/O と競合すればさらに長くなります。
  • 残りのディスクが酷使される — リビルドは残ったすべてのディスクを最後まで読みます。同じ時期に買って同じ寿命を走ってきたディスクに最大負荷がかかるので、2 枚目の故障がよりによってこのタイミングで起きる確率が普段より高くなります。
  • URE に出会うことがある — URE (Unrecoverable Read Error、ディスクが最後まで読み出せないセクタエラー) は、カタログに「10^14 ビットあたり 1 回」のような確率で書かれています。普段は冗長性が隠してくれますが、RAID5 のリビルド中には隠してくれる冗長性がありません。数十 TB をすべて読む間に一度でも出会えば、その地点のデータは失われます。

最後の項目が「大容量ディスクの時代に RAID5 は危険だ」という格言の根拠です。ディスクが大きいほどリビルドで読む量が増えて URE に出会う確率が上がるため、大きいディスクではパリティが 2 枚の RAID6、あるいはリビルドが速い RAID10 が保守的な選択になります。

ホットスペアとスクラブ — 事故を減らす 2 つの習慣 #

運用でリスクを減らす標準的な仕掛けが 2 つあります。

  • ホットスペア (hot spare) — アレイにあらかじめ挿しておく待機ディスクです。故障が起きると人を待たずに即座にリビルドが始まり、デグレードのまま過ごす時間を減らします。深夜の故障と出勤の間の数時間を埋める保険です。
  • スクラブ (scrub) — アレイ全体を定期的に読んで、潜んでいる不良セクタを先に見つけて直す点検です。普段読まない領域の URE は、スクラブがなければリビルドの日まで隠れていて、最悪の瞬間に現れます。mdadm でも ZFS でもハードウェア RAID コントローラでも同じ概念があり、ふつう週単位や月単位のスケジュールで回します。

要するに、ホットスペアは事故後の時間を、スクラブは事故そのものの確率を減らします。どちらも設定 1 行程度のコストです。

書き込みキャッシュとバッテリー — 性能と安全のトレード #

ハードウェア RAID コントローラの書き込み性能は、かなりの部分がコントローラ上の書き込みキャッシュから来ています。書き込みをキャッシュに受け取って即座に完了と応答するライトバック (write-back) モードです。第3回 のダーティページと同じ構造のトレードなので、同じ弱点があります。ディスクに降りる前に電源が落ちるとその書き込みは消え、ファイルシステムや DB が「完了した」と信じたデータなので被害が大きくなります。

だからコントローラにはバッテリーやフラッシュバックアップ (BBU/CacheVault) が付きます。停電時にキャッシュの内容を守り、起動後に書き切る装置です。運用のポイントは 1 つです。バッテリーが死ぬと、コントローラはふつう ライトスルー (write-through) に降格され、書き込み性能が急落します。「ある日突然 DB の書き込みが遅くなった」の答えがバッテリーの寿命切れだった事例はよくあります。バッテリーの状態もモニタリング項目です。

RAID はバックアップではありません — 運用版 #

基礎 #5 でも触れましたが、運用の言葉で整理し直す価値があります。RAID が防いでくれるのは ディスクハードウェアの故障、その 1 つだけです。

  • 誤って消したファイルは、すべてのディスクから律儀に同時に消えます。
  • ランサムウェアの暗号化も、バグが書いた間違ったデータも、同じく忠実に複製されます。
  • コントローラの故障や火災は、アレイ全体を一度に持っていきます。

だから RAID は可用性 (ディスクが死んでもサービスが続く) の装置であり、バックアップは復旧 (間違う前の過去に戻る) の装置です。両者は代替関係ではなく、両方必要な関係です。ZFS のようなチェックサムベースのファイルシステムはここに完全性 (静かなデータ破損の検知と自己修復) を加えてくれますが、それもバックアップの代わりにはなりません。

よく出会う落とし穴 #

  • デグレードの通知が人に届かない — デグレードのまま数週間走り続け、2 枚目の故障で終わる事故の原因は、技術ではなく通知経路です。アレイ状態のモニタリングから点検します。
  • リビルド完了までを復旧と見なす — リビルド中こそ最大リスクの区間です。その時間だけでもバックアップの周期を早めたり変更作業を先送りしたりする運用判断が必要です。
  • スクラブなしで大容量 RAID5 を回す — 潜伏した URE とリビルドの組み合わせが最悪のシナリオです。スクラブを有効にし、新しいアレイなら RAID6/10 を検討します。

まとめ #

今回つかんだ絵です。

  • デグレードはカウントダウン状態であり、リビルドは時間・酷使・URE の 3 つの理由でもっとも危険な区間です。
  • ディスクが大きいほど RAID5 のリビルドリスクが大きくなります。ホットスペアとスクラブが基本の装備です。
  • ライトバックキャッシュの性能はバッテリーが担保します。バッテリーの状態までモニタリングに入れます。
  • RAID は可用性、バックアップは復旧です。互いを代替しません。

次回 — ストレージネットワーク #

ここまではサーバーの中のディスクでした。次回の「ハードウェア中級 #7 ストレージネットワーク — iSCSI・FC・NVMe-oF・マルチパス」では、ディスクがサーバーの外へ出ます。基礎 #5 で概念だけ見た SAN を実際につなぐ iSCSI と FC、その上で切れない経路を作るマルチパス、そして NVMe 時代の NVMe-oF まで扱います。

X