EXT系ファイルシステムについて
プライベートクラウドはOSイメージをテンプレートから展開して起動するだけではなく、ユーザ自身がisoファイルをアップロードし、仮想マシンを作成し、好きな形でOSをインストールする自由度があります。そのため、OSのインストールは基本、自由ですが、当社ではプライベートクラウド基盤上の仮想マシンにインストールするLinuxで、ext2/3/4を使う事を推奨していません。
現在、多くのLinux OSでは「XFS」が標準で使われており、ブートイメージも、ファイルフォーマットが選択可能なOSでは、XFSやbtrfs、ZFSなど、ext2/3/4以外のファイルシステムを利用することを推奨しています。
ext系ファイルシステムを使うべきではない理由
3-Tier型/HCI型でHigh Response Private Cloudを利用をしたり、あるいはストレージを伴うライブマイグレーションを発生させるとき、仮想OSからみると、ストレージには一定の遅延や短いフリーズが発生します。これは、Private Cloud基盤やStorageの全体の負荷だけでなく、仮想OSからのストレージの書き換え量にも影響し、避け得ないことです。
一般的にはファイルシステムの処理として一定の遅延が発生したとしても、OSはそのまま「待ち」状態に入ります。たとえストレージシステムに遅延が発生したとしても、動作が再び健全になったら動き始めるようにするためです。(ただし上位のアプリケーション層のタイムアウトの最小値までには健全状態に戻る必要はあります)
一方、ext系ファイルシステムは、ストレージ遅延が、一定以上、発生した場合、これを障害と見なし、リードオンリー(書き込みできない)モードでストレージを再マウント(ro-remount)します。ro-remountになった場合。システムはその状態のまましばらく動作し、再起動するまで通常のマウント状態には戻すことはできません(rw,remountは不可能)。
これは、サーバ環境にて多くの問題を発生させます。大きな問題の一つは、システム管理者がro-remountになったことに気がつきにくいことです。Linuxシステムはディスクキャッシュ(ライトバック)の層が厚く、数時間から長いときには数日にわたり、ディスクキャッシュだけで動き続けることがあります。ウェブサーバなどではROのために普通にサービスをしているように見えますが、この状態ではリードオンリーのためにデータもログもディスクには記録されないため、ライトバックキャッシュのメモリが飽和し、サーバーがこれ以上、動作ができなくなった時点でKernel Panicします。大抵は再起動により復帰しますが、リードオンリーになった時点から、データも記録されていないため、ディスク上ではro-remountが起きた点が、最終ログ上の停止点に見えます。
この問題は、extファイルシステムを使う限り、マウントオプションを調整しても、本質的には回避することはできません。
下記は、extをどうしても使わなくてはならなくなった場合の、緩和策と推奨策です。
緩和策
errors=continue
/etc/fstabに記載するマウントオプションにerrors=continueを設定する場合、基本的な要件においては「待ち」続けます。
したがって、いくつかのケースでro-remountの動きが緩和されることとなります。
しかし、クリティカルなジャーナルエラー、深刻なメタデータ欠損、或いはディスクI/Oが連続して失敗する場合には、ro-remountモードとなります。この「待ち」の状態のとき、定期的にI/Oを試みることで、回復したかどうかを判断しています。リトライを発生させても正常に完了しなかった場合、エラーカウントとして記憶され、ディスクI/Oが連続して失敗したと判断されます。この結果、jbd2_journal_commit_transactionなどの関数内でジャーナルのコミットが失敗し、深刻なディスクエラーであると判定され、continueにしても、ro-remountのモードに結果としてなります。
従ってこの設定は、若干の緩和策にしかなりません。
推奨策
errors=panic
マウントオプションにerrors=panicを指定したとき、ファイルシステムにエラーが発生すると、システム全体を停止してカーネルパニックを起こします。
この場合、システムは完全に停止しますが、監視などで異常が検出でき、データを受け取ってバッファリングしてからPanicでリブートすることもありません。
データを受け取りながら書けないよりは、問題にすぐ気がつく方がデータロストを深刻にしないため、問題は明確化します。
ただし、ストレージの応答劣化の深刻度に応じて、意図しないpanicが頻繁に発生する可能性もありますし、ディスクに対するエラーとなるため、クラッシュダンプも取得できません。この様な場合、より高いIOをもつストレージシステムを用意する(ICSをローカルで直接利用する)、あるいはストレージ負荷を分散する必要があるでしょう。