テストステ論

高テス協会会長が, テストステロンに関する情報をお届けします.

(writeboost report) いかにしてSSDを交換するか

dm-writeboost v1.0.1をリリースした. これは重大なバグフィックスが入っている. 使う時はこちらを使うように. キャッシュ上メタデータのフォーマットおよびにセマンティクスは変更してないので, 互換性は保たれていると思う.

さて, ライトブーストを運用するに当たっては色々な課題がある. その1つは, SSDの故障にどう備えるかだ.

SSDはいずれ壊れる. ライトブーストはログ構造化キャッシングなため, 仮にSSDが壊れても, 時系列的に巻き戻ってしまうだけであるため, 他のキャッシングソフトウェアに比べればマシと言えるが, データロストには変わりないため避ける必要がある.

ライトブーストを導入するに当たってまず, ライト量はどのくらいか?ということを見積もる必要がある. それによって, SSDがどの程度で壊れるか?ということが大体分かる. あまりぎりぎりまで使うのも危ないので, 半分くらいの期間使って交換するとかいう運用が現実的だろう. 金銭的には負担はない. 理由は, キャッシュSSDを導入している時点でその追加価格があまり大きくないことが保証されているからだ.

寿命の算定に当たって, ライトブーストがシーケンシャルライトのみをするという事実はたぶん役立つ. 細かいコミットを連発するでなく, 512KBごとのライトを出すことは, SSDにとって優しく, 故に寿命が予想外に短くなるリスクを軽減することが出来るだろう. この点も他のキャッシングソフトウェアより優れる.

SSDRAIDすることはあまりオススメしない. ミラーリングの場合, 両方のSSDに同量のライトが書かれてしまうので同時に破綻する可能性があるし, あまりメリットを感じないからだ. ある程度の規模のストレージ・システムに対しては, PCIeのSSD一枚が使われることが多いだろう.

以上より, SSDはいつか交換しなければいけないという前提に立つ. その上で, どのように交換するか, 3通りの方式を示す.

方式1) pvmove方式

LVMのpvmoveは, あるLVを構成するエクステントをミラーリングの要領によりマイグレーションする機能である.

http://www.redhat.com/magazine/007may05/features/storage/figs/pvmove.jpg

これを用いることによって, SSDスワップさせることが出来る. この方式がもっとも確実だと私は思う. システムが完全に無停止なままスワップ出来ることも特長として挙げたい.

方式2) ddでコピー方式

デバイスへのIOを一旦suspendして, キャッシュディスクを一旦引き抜く. そして, 外部でddにより別ディスクにコピーしたあと, 新しいディスクを戻す.

これをやるくらいならpvmoveを使う方が確実だと思う.

方式3) 一旦ライトバックする方式

愚直に考えると, 以下のような手順を踏めばSSDを交換出来る.

  1. SSDのデータを全部ライトバックする.
  2. nr_dirty_cachesが0になった時にsuspendする (t1)
  3. dm tableを差し替えて(dmsetup reload), SSDなしのlinearにする.
  4. resumeする. (t2)
  5. 新しいSSDを差す.
  6. suspendする (t3)
  7. dm tableを差し替えて, ライトブーストを適用する.
  8. resumeする (t4)

停止時間は, (t2-t1) + (t4-t3)である. 前者はほぼゼロと言っても良い. しかし後者はそうはいかない. 理由は, 現状の実装では, 新しいSSDのフォーマットとログのリプレイが起こるからだ.

これら(フォーマットとリプレイ)に対して, 私は以下の実装を行えば, ほぼ無停止を実現出来ると考えている.

  • フォーマット: ユーザランドでフォーマットする. カーネル内と同等のコードをユーザランドにも実装する.
  • リプレイ: 明らかに, フォーマット後のリプレイは不要である. しかし今は愚直に全ログを舐める. これに対して, 「一番先頭のログと一番最後のログのidが0ならば, 全ログがid=0である」という性質に着目して, 定数時間でリプレイ不要を計算するアルゴリズムを実装する.

この2つが実装出来れば方式3が実現出来ると考えるが, 方式1よりは停止時間が長くなると予測する. 一番最初のログと最後のログをチェックするためにSSDに対するリードを行う必要があるからである. 従って方式3の場合は, 10ms程度は停止を覚悟しなければいけない.

方式3のメリットは, SSDを異なるサイズに変更することが出来る点である. 実際に運用してみたところ, SSDがより大きればなお有利であることがわかったとする. SSDをもっと大きなものに交換したいわけであるが, 方式1では移行先のSSDが同サイズを仮定される.

仮に, 大きなサイズのSSDに移行可能とすれば, スモールスタートが可能となり, ライトブーストを適用するチャンスが大きくなる. 従って私としては, 方式1と方式3を公式に認める方針で行こうと思う. 後のリリースでツールも提供していくことだろう.

まずはお試しでライトブーストを使ってみて欲しい.