BOOK Preview インサイドMicrosoft Windows 第4版 下 第10章 ストレージ管理 10.3.5 ボリュームI/O処理 書籍情報のページ 2005/11/29 |
|
10.3.5 ボリュームI/O処理
ファイルシステムドライバは、ボリューム内に格納されているデータを管理しますが、ボリュームが置かれる複数ディスクとの間のデータI/Oでは、ボリュームマネージャ経由でストレージドライバ機能を活用しています。ファイルシステムドライバは、マウント処理を通してボリュームマネージャのボリュームオブジェクトへの参照を取得し、ボリュームオブジェクト経由でボリュームマネージャに要求を送ります。ボリューム内のデータを直接操作する必要のあるアプリケーションは、ファイルシステムドライバを経由することなく、ボリュームマネージャに要求を送ることができます。ファイル削除を伴わないプログラムは、このようなアプリケーションの例です。たとえば、Windowsリソースキットに付属するDiskProbeユーティリティなどがあります。
ファイルシステムドライバやアプリケーションがI/O要求をボリュームを表現するデバイスオブジェクトに送るときには、WindowsI/Oマネージャはその要求(つまり、自己完結したパッケージであるIRP)を、目的のデバイスオブジェクトを作成したボリュームマネージャに中継するようになっています。このため、アプリケーションがシステム内の第2ボリュームのブートセクタを読み出した場合には、デバイスオブジェクト\Device\HarddiskVolume2をオープンし、デバイス上のオフセット0から始まる512バイトを読み取る要求をデバイスに送ります。I/Oマネージャは、アプリケーションからの要求をIRPとして整理し、デバイスオブジェクトを所有するボリュームマネージャに送り、IRP要求がHarddiskVolume2デバイス向けであることを通知します。
Windowsは論理的な存在者であるボリュームを活かしながら、1個以上の物理ディスク上に連続的な領域を表現しています。この上位概念は便利なことは間違いないのですが、ボリュームマネージャはボリューム内で相対的なオフセット値を、ディスク先頭からのオフセット値に変換する必要があります。ボリューム2が4096個のディスクセクタを持つパーティションで構成されている場合、ボリュームマネージャはIRPのパラメータを調整し、要求をディスククラスドライバに送信する前に、目的のオフセットを算出する必要があります。ディスククラスドライバは、ミニポートドライバを使って物理ディスク上でI/O処理を行い、要求されたデータをIRP内に指定されたアプリケーションバッファに読み込みます。
ボリュームマネージャは、複数のパーティションボリューム向けの要求も処理します。この処理は複雑ですから、具体的な例を用いながら説明しましょう。パーティション1と2という2つのパーティション構成のストライプボリュームがあるとしましょう。このボリュームは、図10-16のように、\Device\HarddiskVolumes\PhysicalDmVolumes\BlockVolume3というデバイスオブジェクトとして表現されているとします。また、管理者はこのストライプボリュームにドライブ文字Dを割り当て、I/Oマネージャは\Device\HarddiskDmVolumes\ComputerNameDg0\Volume3を参照するために、\Global??\D:というシンボルリンクを定義しているものとします。既に説明したように、このシンボルリンクはPhysicalDmVolumesディレクトリ内の対応するボリュームデバイスオブジェクトを指しています(この場合、BlockVolume3)。DMIOデバイスオブジェクトは\Device\HarddiskVolumes\PhysicalDmVolumes\BlockVolume3向けのファイルシステムディスクI/Oを横取りし、DMIOドライバはディスククラスドライバに送る前に要求を調整します。この調整では、パーティション1か2のいずれかの、送信先ストライプの正確なオフセットを参照するように、I/O要求を構成します。I/O要求が2つのパーティションにまたがっている場合には、DMIOはそれぞれのディスク向けに2種類の補助I/O要求を発行する必要があります。
図10-16 DMIOI/O処理 |
ミラーボリュームにデータを書き込む場合には、DMIOは要求を分割し、ミラーのそれぞれの半分がデータを受信するようにします。読み込みの場合には、DMIOはミラーの半分からのみデータを読み込み、失敗した場合には、残り半分から読み込みます。
10.3.6 仮想ディスクサービス(VDS)
RAIDアダプタ、ハードディスク、あるいはストレージアレイなどのストレージ関連製品を製造販売する会社は、デバイスをインストールし、それを管理するためのアプリケーションを独自に実装する必要があります。異なるストレージデバイス用に異なる管理アプリケーションを使用することは、システム管理者の立場に立つと、決して好ましいことではありません。多くの操作インターフェイスを学ぶ必要が出てきます。また、いつものように標準のWindowsストレージ管理ツールを起動し、サードパーティ製のストレージデバイスを管理することもできません。
Windows Server 2003は、仮想ディスクサービス(通常VDSと略称され、\Windows\System32\Vds.exeに実装されています)を導入しました。このサービスは、「ハイレベルかつ統一的な」ストレージインターフェイスを提供し、システム管理を効率化してくれます。つまり、システム管理者は、異なるベンダーから出荷されているストレージデバイスを同一のユーザーインターフェイス経由で管理できるわけです。VDSは、図10-17のようなコンポーネント構成となっています。VDSは、COMベースのAPIを公開していますから、アプリケーションやスクリプトはCOMインターフェイスを呼び出し、ディスクの作成やフォーマット、あるいはハードウェアRAIDアダプタを調査管理します。たとえば、ユーティリティはVDSAPIを呼び出し、RAID論理ユニット(LUN)にマッピングされている物理ディスクのリストを問い合わせることができます。ディスク管理MMCスナップインやWindows Server 2003 SDKに付属するDiskpartとDiskraidなどのコマンドラインツールをはじめとするWindowsディスク管理ユーティリティは、VDSAPIベースのプログラムです。
図10-17 VDSサービスアーキテクチャ |
VDSは、ソフトウェアプロバイダとハードウェアプロバイダという2種類のインターフェイスを公開しています。
-
ソフトウェアプロバイダは、ディスク、ディスクパーティション、およびボリュームなどのストレージ抽象化層へのインターフェイスを実装しています。これらのインターフェイスがサポートする機能例には、ボリュームの作成、拡張、そして削除機能があります。また、ミラーの追加と解消、ドライブのフォーマットとドライブ文字の割り当てなども、このインターフェイスが提供しています。VDSは、HKLM\SYSTEM\CurrentControlSet\Services
\Vds\SoftwareProvidersレジストリ内の登録済みソフトウェアプロバイダを探します。WindowsServer2003には、ダイナミックディスクへのインターフェイスを提供するVDSダイナミックディスクプロパイダ(\Windows\System32\Vdsdyndr.dll)と基本ディスクへのインターフェイスを提供するVDS基本プロパイダ(\Windows\System32\Vdsbas.dll)が登録されています。 -
ハードウェアベンダーは、VDSハードウェアプロバイダをDLLとして実装します。DLLは、HKLM\SYSTEM\CurrentControlSet\Services
\Vds\HardwareProvidersレジストリ内に登録され、デバイスに依存しないVDSコマンドをハードウェア固有のコマンドに変換します。ハードウェアプロバイダは、ハードウェアRAIDアレイやアダプタカードなどのストレージサブシステムの管理機能も提供しています。たとえば、LUNの作成、拡張、削除、マスク、あるいはマスク切り替えなどがサポートされています。アプリケーションがVDSAPIへの接続を開始し、そのとき、VDSサービスが動作を開始していない場合、RPCサービスをホストしているSvchostプロセスがVDSローダープロセス(\Windows\System32\Vdsldr.exe)を起動します。このローダープロセスは、VDSサービスを起動し、動作を終了します。VDSAPIへの最後の接続が閉じられると、VDSサービスプロセスも動作を終了します。
10.3.7 ボリュームシャドウコピーサービス
多くのバックアップユーティリティは、オープンファイルのバックアップに仕様上の限界を持っています。アプリケーションがオープンファイルに排他アクセスを行っている場合、バックアップユーティリティはそのファイルの内容にアクセスできません。バックアップユーティリティがオープンファイルにアクセスできたとしても、バックアップ内容に一貫性を持たせることは至難の業です。たとえば、あるアプリケーションがあり、ファイルの先頭と終了部分を更新しているとしましょう。そのファイルの内容を保存するバックアップユーティリティは、更新前のファイルの先頭部分と更新後のファイルの終了部分を持つファイルイメージからバックアップファイルを作成する可能性があります。このバックアップファイルを後で復元した場合、アプリケーションはファイルの終了部分ではなく、先頭部分が更新されていることを前提に動作する仕様を持っていれば、ファイル全体が破壊されているとみなしてしまうはずです。
Windows XPは、ボリュームシャドウコピーサービス(\Windows\System32\Vssvc.exe)を導入しました。このサービスは、内蔵バックアップユーティリティがオープンファイルを含むすべてのファイルの内容を正常に記録するための機能を提供しています。ボリュームシャドウコピーサービスは、ISVが「ライタ」と「プロバイダ」を追加挿入できる仕組みを持っています。つまり、このサービスは、拡張性に富むバックアップコアの指令センターのようなものなのです。ライタというのは、シャドウコピー対応アプリケーションがフリーズを受信し、それを通知する機能を持つソフトウェアコンポーネントです。このコンポーネントを組み入れれば、データファイルのバックアップコピーは内部的な一貫性を保持できます。一方、プロバイダというのは、ISV固有のストレージスキームとシャドウコピーサービスを統合する役割を持っています。たとえば、ミラーストレージデバイスを販売するISVがシャドウコピーをミラーボリュームの半分をフリーズとして定義しているとしましょう。図10-18は、シャドウコピーサービス、ライタ、およびプロバイダ間の関係を示しています。
図10-18 シャドウコピー、ライタ、およびプロバイダの位置付け |
Microsoftシャドウコピープロバイダ(\Windows\System32\Drivers\Volsnap.sys)は、Windowsに付属するプロバイダです。このプロバイダは、ボリュームのスナップショットをとる機能を実装しています。Microsoftシャドウコピープロバイダは、ファイルシステムドライバとボリュームドライバ(論理ドライブを表現するディスクセクタのビューを提供するドライバ)の中間層に位置する、いわゆる、ストレージフィルタドライバです。存在位置から判断できるように、ボリューム宛のI/O要求を監視できます。バックアップユーティリティがバックアップ動作を開始するとき、ユーティリティはMicrosoftシャドウコピープロバイダドライバに指示を出し、記録の対象となるファイルやディレクトリを持っているボリュームのボリュームシャドウコピーを作成してもらいます。指示を受けたドライバは、ボリュームへのI/O処理をフリーズ(凍結)し、シャドウボリュームを作成します。たとえば、オブジェクトマネージャ名前空間内のボリューム名が\Device\HarddiskVolume0である場合、シャドウボリューム名は\Device\HarddiskVolumeShadowCopyNなどとなります(Nの部分には固有なID)。
|
バックアップユーティリティは、バックアップするファイルをオリジナルボリューム上に開くのではなく、シャドウボリューム上で開きます。シャドウボリュームは、ある時点でのボリュームのビューを表現しています。このため、ボリュームシャドウコピードライバがオリジナルボリューム宛の書き込み動作を検出すると、その都度、上書きされるセクタのコピーを取り、それをページングファイルベースのバックアップメモリセクション(このセクションは、対応するシャドウボリュームと関連付けられています)に読み込みます。ボリュームシャドウコピードライバは、修正済みセクタのシャドウボリューム宛の読み取り動作が発生すると、このメモリセクションを利用します。無修正領域への読み取り動作が発生したときには、オリジナルボリュームをアクセスします。バックアップユーティリティは、ページングファイルや、すべてのボリュームに置かれているシステム管理の\SystemVolumeInformationディレクトリの内容を保存しませんから、スナップショットドライバは非断片化APIを使用し、これらのファイルとディレクトリの位置を確定し、変更内容は記録しません。Windows XPとWindows Server 2003用のバックアップユーティリティは、シャドウコピー機能を活用することにより、オープンファイル関連問題を克服しています。
図10-19は、ボリュームにアクセスするアプリケーションと、そのボリュームのシャドウボリュームにアクセスするバックアップアプリケーションの動作を図解しています。スナップショットが取られた後にアプリケーションがセクタに書き込みを行い、VolsnapドライバはボリュームC:のセクタa、b、cなどのバックアップコピーを取ります。その後、アプリケーションがセクタcからデータを読み取ろうとすると、Volsnapドライバはその要求をボリュームC:に送ります。しかし、バックアップアプリケーションが同じようにセクタcから読み出し動作を行うと、Volsnapはスナップショットからセクタ内容を読み込みます。無修正のセクタへの読み込み要求が発生した場合には、Volsnapはその要求をオリジナルボリュームに配送します。
図10-19 Volsnapの動作 |
ファイルシステムドライバは、2つのシャドウコピー関連I/O要求(IOCTL)を処理し、整合性のあるスナップショットを作成する必要があります。2つの要求とは、IOCTL_VOLSNAP_FLUSH_AND_HOLD_WRITESとIOCTL_VOLSNAP_RELEASE_WRITESです。それぞれの要求の意味は、要求名称から推測可能です。シャドウコピーAPIは、スナップショットがとられる論理ドライブにIOCTLを送り、スナップショット以前に開始されたすべての修正作業を完了させる必要があります。これにより、シャドウコピー内のファイルデータは、その時点での一貫性を持つことになります。
|
まとめ
本章では、オンディスク構成、Windowsディスクストレージ管理のコンポーネントと動作を詳しく説明しました。第11章では、キャッシュマネージャを取り上げます。キャッシュマネージャは、本章で紹介したボリュームタイプをマウントするファイルシステムドライバの動作を支えるエグゼキュティブコンポーネントの1つです。
INDEX | ||
インサイドMicrosoft Windows 第4版 下 | ||
第10章 ストレージ管理 | ||
10.1 ストレージ関連用語/10.2 ディスクドライバ/10.2.1 Ntldr | ||
10.2.2 ディスククラス、ポート、およびミニポートドライバ/10.2.3 ディスクデバイスオブジェクト/10.2.4 パーティションマネージャ | ||
10.3 ボリューム管理/10.3.1 基本ディスク | ||
10.3.2 ダイナミックディスク | ||
10.3.3 マルチパーティションボリューム管理 | ||
10.3.4 ボリューム名前空間NEW! | ||
10.3.5 ボリュームI/O処理/10.3.6 仮想ディスクサービス(VDS)/10.3.7 ボリュームシャドウコピーサービス/まとめNEW! | ||
「BOOK Preview」 |
- Azure Web Appsの中を「コンソール」や「シェル」でのぞいてみる (2017/7/27)
AzureのWeb Appsはどのような仕組みで動いているのか、オンプレミスのWindows OSと何が違うのか、などをちょっと探訪してみよう - Azure Storage ExplorerでStorageを手軽に操作する (2017/7/24)
エクスプローラのような感覚でAzure Storageにアクセスできる無償ツール「Azure Storage Explorer」。いざというときに使えるよう、事前にセットアップしておこう - Win 10でキーボード配列が誤認識された場合の対処 (2017/7/21)
キーボード配列が異なる言語に誤認識された場合の対処方法を紹介。英語キーボードが日本語配列として認識された場合などは、正しいキー配列に設定し直そう - Azure Web AppsでWordPressをインストールしてみる (2017/7/20)
これまでのIaaSに続き、Azureの大きな特徴といえるPaaSサービス、Azure App Serviceを試してみた! まずはWordPressをインストールしてみる
|
|