【ストレージ編】NTFSの強化と新ファイルシステムのReFS
前回はラインアップとライセンスについてお伝えしたが、今回は強化された機能について取り上げる。
Windows Server 2012は、NTFSの機能アップ、新しいファイルシステムであるReFS(Resilient File System)の採用など、ストレージに関する機能強化がさまざまな部分で行われているので、その詳細を説明しよう。
■オフラインでのCHKDSK実行回数を削減
Windows Server 2012では、オンラインでの健全性チェックを充実することで、オフラインでのディスクスキャンの回数をほとんどなくした(Building Windowsより) |
現在のWindows OSで採用されているファイルシステムのNTFSは、ファイルの読み書きを行っている時に自己修復できない破損ファイルができた場合には、CHKDSKコマンドによりボリュームをアンマウントして、ボリュームを全スキャンする必要がある。
このため、CHKDSKを行うためには、システムを再起動してWindows OSがすべて起動する前に長時間のディスクスキャンを行うことになる。チェックにかかる時間はいろいろな条件によって変化するが、1TBのデータをチェックするのに3~4時間かかることもある。
サーバーを運用している時に、これだけの長い間、ファイルシステムのチェックだけに時間を食われてシステムを長時間ダウンさせてしまうのでは、ビジネスの障害になる場合もあるだろう。
これを改善するためにWindows Server 2008/Vistaでは、NTFSをオンラインでチェックして破損ファイルを自己修復する機能を搭載し、CHKDSKコマンドを行う回数を減らしてきた。しかし現行のOSであるWindows Server 2008 R2/Windows 7でも、依然として、破損ファイルを自己修復できずにCHKDSKコマンドを実行する必要があった。
そこでWindows Server 2012では、NTFSが持つオンラインでの破損ファイルのスキャンと自己修復機能をより強化した。Windows Server 2008/Vistaで採用されたオンラインスキャン/自己修復機能を、より幅広いパターンに対処できるようにしたため、オフラインでのCHKDSKコマンド実行を必要とすることが、ほとんどなくなったという。
しかし、オンラインでの自己修復機能が拡充したからといって、すべての問題がオンラインで処理できるわけではない。やはりオフラインでしか対処できない問題も存在する。そこでWindows Server 2012では、オフラインでしか対処できない問題がある時にも、できるだけ短時間で処理できるように作られている。
■スポット検証サービスとスポット修復機能
オンラインでの破損ファイルのスキャンと自己修復機能の強化にあたるのが、ファイルシステムドライバーによって呼び出される「スポット検証サービス」という新しいサービスだ。スポット検証サービスでは、バックグラウンドでディスクをスキャンする(ローレベルのスキャンといえる)。これにより、ディスクのファイルに破損が起こっていないのにファイル破損が存在するというアラームが起こる場合は、メモリエラーが考えられると判断できる。
トラブルが検出されると、すぐにファイルシステムのオンラインスキャンを実行する準備を行う。実際のオンラインスキャンはアイドル時間などにバックグラウンドで実行され、発見した問題点をすべてログに記録しておく。
ログに記録された問題点は、ボリュームのオフライン修復を管理者が都合のいい時に行う。このときログを参照しながら、破損している部分だけを修復する(スポット修復機能)。破損している部分だけを修復するため、CHKDSKでの全スキャンが必要ないので、非常に短時間で修復が終了する。
CHKDSKコマンドでボリュームをアンマウントし全スキャンしてから、破損ファイルを見つけて修復するといった手法をとらずにすむため、ファイル数やデータ容量が多くなっても、ファイルを短時間で修復できるようになるわけだ。
このような改良により、ファイルシステムのチェックでシステムが長時間ダウンタイムを起こすことを防いでいる。
また、ファイルシステムの状態を簡単に確認できるように、Windows Server 2012ではアクションセンターのドライブの状態にアラームが表示されたり、エクスプローラーのドライブにもドライブの状態を表示したりするようになった。さらに、サーバーマネージャーにもボリュームの正常性が表示される。このように、さまざまなレベルでボリュームの状態を簡単に確認できるようになっている。
ちなみに、Windows Server 2012/Windows 8に搭載されたNTFSでは、最大256TBのディスクボリュームをサポートしている。さらに、大容量ディスクに対応して4Kセクタ(Advanced Format Technology=AFT)をネイティブでサポートするため、ブートドライブとしても利用可能になった。
オフラインで行うデータ修復は、破損している部分だけを修復するスポット修復により、CHKDSKにかかる時間が大幅に少なくなる。また、修復する個所が多くなっても、ほとんど時間がかからない(Building Windowsより) | Windows Server 2012のNTFSにおける健全性チェックから、修復にいたる流れ(Building Windowsより) |
■データの重複排除機能をファイルシステムレベルでサポート
もう1つ、Windows Server 2012のNTFSでは、データの重複排除(重複除外)機能がファイルシステムレベルで採用されている。これにより、ディスクの使用効率が一気にアップする。データの重複排除機能は、EMCなどの大手ストレージベンダーが自社のストレージの特徴として押し出している機能だ。このような機能がWindows Server OSの標準機能として入るのは、注目すべき点だろう。
新しいNTFSに入ったデータの重複排除機能は、ブロックレベルでの本格的なデータ重複排除機能だ。
この機能は、ファイルを32~128KBの可変サイズの小さなブロック(チャンク)に分割する。ボリューム全体として、同じチャンクは1つだけがチャンクストアに保存され、同一内容のチャンクは重複排除される(つまり2つ目以降の同一内容のチャンクは削除される)。ファイルは、チャンクストアに存在するチャンクの並び順が登録されている仮想的なファイル(実際にデータを持たないインデックスのようなもの)となる。
ブロックレベルの重複排除は、ストレージにとって効率よく容量を圧縮してくれる。ブロックレベルの重複排除は、ファイルシステムの基盤部分を改良する必要があったため導入が遅れたが、ファイルレベルで圧縮する手法に比べると、容量効率も高く、CPU負荷もかからない。
圧縮率としては、ファイルサーバーなどでは50%近い容量の圧縮を行える。さらに、仮想ディスク(VHD)などでは、80%以上の容量圧縮を示すという。
もちろん、データ重複排除機能は、ユーザーの設定でオン/オフすることができるし、特定のファイル(拡張子)を重複排除機能の対象外に設定することも可能だ。また重複排除を適用するファイルは、一定期間(30日間)書き込みがないファイルのみとしている。
■新ファイルシステムReFSの登場
Windows Server 2012では、ReFSという新しいファイルシステムが追加されている。
ReFSは、1ファイルのサイズの拡張、ファイル名の拡張などNTFSに比べると大容量のストレージがサポートされている。
まず、1ファイルの最大サイズは、2の64乗Byte(約18EB:エクサバイト)となる。1つのディレクトリに保存できるファイル数の上限は2の64乗で、ファイル名の長さとパスの長さの両方とも最大32KB(ユニコード)となっている。Storage Spaceの最大容量は4PBである。
さすがにこれだけ大容量化される中でファイルの破損などが起こると、チェックだけで数日かかることになる。そこでReFSでは、信頼性を高くしたり、データ訂正の自動化なども行ったりしている。
例えば、ReFSではデータの書き換え方式がNTFSと異なる。NTFSでは、データの更新を行う場合、データを上書き変更する。このため、データを上書きしている時にトラブルが起こると、データすべてが破損してしまう。
一方ReFSは、データを書き換える場合でも、古いデータを上書きせずに別の場所へ新規データを保存し、その後、古いデータ領域を非利用領域(空きエリア)として、ファイルシステムに登録する。
もしも新しいデータを保存している時にトラブルが起こっても、古いデータが残っているため、ファイルの破損が起こり、ファイルが使えなくなるということもなくなる。ある意味、データベースなどで使っているようなデータ保存方式をファイルシステムにも応用しているといえる。これにより、高い信頼性を実現している(データベースなどのように、アプリケーションがファイルを管理している場合は、この機能をオフにすることも可能)。
また、Windows Server 2012で追加されたNTFSの新機能と同じように、ReFSでもオンラインでの破損ファイルのチェック、修正が可能になっている。さらに、チェックサム(64ビット)がファイルのメタデータに保存されているため、可能な限りチェックサムを使った自動訂正機能が使われる。
ReFSは、ファイル構造を構成するB+Tree(ディレクトリに複数のファイルやディレクトリが存在する入れ子構造を表現する)も改良されている。
ReFSでは、ディレクトリを表現したテーブルにリンクして、File Metadataが置かれている。そしてFile metadataでは、さまざまなファイル属性などをFile Extentsに保存している。このような構造にすることで、非常に大きなファイルやディレクトリが存在しても、パフォーマンスには影響しない(NTFSでは、ファイル数やディレクトリ数が増えるとアクセスに時間がかかる場合がある)。もちろん、B+Treeにもチェックサムが用意されているため、耐障害性が高くなっている。
ReFSは、1ファイル18エクサバイト(EB)も大きなファイルを作成することができる。1つのボリュームの最大容量は302ゼタバイト(ZB)/16KBクラスタ。途方もない容量だ |
■ReFSの利用用途
将来的には、ReFSはNTFSに変わるものになるといわれているが、ファイルシステムの更新には長い期間がかかるため、すぐに一般的になるものではない。
そこで現状では、ReFSからはOSのブートができないようになっている。当面の間は、データボリュームのファイルシステムとして利用することになる。またもう1つの制限として、ReFSはUSBメモリなどのリムーバブルディスクには対応していない。
新しいファイルシステムが導入される時に大きな問題になるのが、ファイルアクセスのAPIが変更されることだ。新しいファイルシステムを使うには、新しいAPIをサポートする必要がなる。アプリケーション側でも、新しいAPIをサポートする必要があるため、新ファイルシステムをサポートするアプリケーションがそろうまで時間がかかる。このため、新しいファイルシステムの普及に時間がかかることになる。また、古いファイルシステムとの互換性なども大きな問題になる。
Microsoftでは、NTFSの代わりに、ReFSをファイルシステムとして利用できるように改良している。これにより、APIレベルではNTFSのAPIがそのまま利用できるため、NTFSと高い互換性を持っている。Windows Server 2012では、NTFSの内部コードを改良して、NTFSの代わりにReFSが利用できるように変更している。
ReFSは、カーネルの部分でNTFSと取り換えがきくように開発されている。このため、上位レイヤーでは、既存のNTFSのAPIがそのまま利用できる | ReFSは多くのWin32APIと互換性を持っている |
ReFSは、既存のディスクでも使用できるが、Windows Server 2012で新しく追加されるStorage Space(記憶域プール、後述)と連携して利用することが考えられている。Storage Spaceを利用すれば、データのコピーを複数のディスクに分散して保存できる。これにより、1つのディスクにトラブルが起きても、ほかのディスクでデータを再構築できるようになっている。また、ファイルの読み込みエラーが起きた時には、別のコピーから読み込むことでトラブルを回避することができる。
このようにReFSでは、複数のディスクをStorage Spaceとして構成して、データをミラーリングして運用することで、非常に高い可用性、耐障害性を得ることができる。
ReFSとStorage Spaceを使えば、高い耐障害性と可用性を持つストレージが構成できる |
Microsoftでは、ReFSのテストを長期間行っている。テストでは、ファイルの書き込み中に電源をオフにして、意図的にデータを破損させたりしている。このような状況でも、ファイルはキチンと復帰できるという。
また、互換性をテストするため、多くのサードパーティ製のアプリケーションをReFS上で動かしている。ReFSはNTFSと高い互換性を持っているので、このテストでもトラブルは非常に少ないそうだ。
ただし、ReFSはNTFSで持っている機能をサポートしていない部分もある。ReFSは、重複排除、DRAMとストレージの間の2次キャッシュ、書き込み可能スナップショットの機能は用意されていない。その代わりスナップショットについては、VSS(Volume Shadow Copy Service)と連動して、Windows環境におけるNTFSと整合性のある形でスナップショット機能を提供する。
なお、このReFSは、クライアントOSのWindows 8には搭載されていないWindows Server 2012だけの機能だ。ReFSは当面、クライアントOSには必要ない機能として省かれたようだ。サーバーから導入して、ある程度こなれてきたらクライアントOSにも導入していこうという考え方だろう。Windows 8の次くらいには、クライアントOSにも導入されていくだろう。
■ストレージを“プール”化するStorage Space
Storage Space機能では、ストレージ(ディスクドライブ)を“プール”として一括管理し、実際にWindows Server 2012上でドライブやボリュームとして利用する時には、プールから一部の容量を割り当てる。
この機能は、Windows Home Serverで採用されていたドライブ拡張機能をより信頼性を高め、可用性を高くしたものだ。NTFSやReFSなどのファイルシステムとより密接に連携するように改良されている。
Storage Spaceでは、ローカルディスク、SANストレージ(iSCSI、FC、Shared SAS)、USBドライブ、マウントされた仮想ディスク(VHD、VHDXファイル)などをStorage Poolに登録しておき、このStorage Poolからスペースを切り出してドライブとして利用する。いわば、ディスクをStorage Spaceで仮想化して、提供するといったイメージだろう(物理ディスクの構造に依存しなくなる)。
Storage Spaceで仮想化している場合には、例えばローカルディスクに1TBのディスクが4台で最大4TBしかなくても、10TBのドライブを構成することができる。ドライブを構成した時点ではほとんどデータは保存されていないため、10TB分のドライブなくても問題はない。これが、実際にデータが保存されて物理的に用意されている4TBに近づくと、容量が足りなくなるとのアラートが発せられるので、この時点でドライブを追加してやればよい。つまり、シンプロビジョニングがStorage Spaceではサポートされているのだ。
耐障害性としては、Storage Poolからドライブを構成する時にミラーリングを設定すれば、自動的にミラー化したドライブを用意する。この場合、RAID1のように物理ドライブを2台使ってミラー化するのではなく、複数の物理ドライブにデータブロック(スラブ)を保存することでミラー化している。さらに、ミラーとして保存するデータは、1つだけではなく複数冗長化することができるため、より耐障害性を高めている。
ミラーリングは、同じデータを別のディスクに複数保存することで、耐障害性をアップしている。しかしこれではディスク容量がもったいないということで、RAID 5にあたるパリティモードも用意されている。
ミラーリングよりも耐障害性は少し落ちるが、トラブルが起こった時にはデータと同時に保存されているパリティ情報を使って、データを再現する。パリティモードを使えば、ミラーリングよりも使用する容量は少なくなる。
モードとしては、冗長性なし、2ウェイ・ミラー(コピーを2つ作成)、3ウェイ・ミラー(コピーを3つ作成)、パリティの4モードが用意されている。
ちなみに、Storage Spaceでは、6台のディスクで構成されている場合、3ウェイ・ミラーでは2台のディスクに障害が起こってもデータの健全性は保たれる。2ウェイ・ミラーとパリティでは、1台のディスク障害なら、データ健全性は保たれる。
なおStorage Spaceは、NTFS、ReFSなどのファイルシステム、ローカルドライブやUBSドライブなどの物理ドライブを仮想化して利用できる。物理ドライブがどのようなインターフェイスで接続されているのかを気にすることもない。
1台のディスクから使用できるが、メリットを生かすには、最低でも3台のディスクで運用する必要がある。また、Storage Poolを構成するディスクの最大数は無制限となっている。実際、Microsoftでは自社のクラウドサービスや社内システムを数千台のディスクをStorage Poolとして運用しているという。
ただしストレージプールに登録したディスクを、OSから直接利用することはできない。Storage Space機能からしか利用できなくなる。
またStorage Spaceでは、SSD、SAS HDD、SATA HDD、USBドライブなど速度・性能の異なるドライブを自動的に組み合わせて、ストレージをパフォーマンス別に構成する機能はない。また、SSDなどの高速なドライブを低速なドライブのキャッシュとして利用するような機能もない。今後のサーバーでの運用を考えれば、こういった機能も必要になってくるかもしれない。ある意味、今後のStorage Spaceの機能アップは楽しみな部分が多いともいえる。
Windows Server 2012では、既存のNTFSなどのファイルシステムとの互換性を壊さずに、ReFSやStorage Spaceといった新しい機能が追加されている。今後は、サーバーにドライブ名がすらりと並ぶこともなくなるのかもしれない。
今回はアーキテクチャを紹介したが、Windows Server 2012の正式版がリリースされたら、設定方法などをステップ・バイ・ステップで紹介していくつもりだ。また、この時に、ベンチマークなどを行ってみたいと考えている。