仮想化でプリセールスしてるSEの一日

VMware から Azure まで、インフラや仮想化の最新情報をベンダー色をできるだけ抑えて綴っていきます

Windows Server 2012 ODX の技術詳細

f:id:ogawad:20190203195637p:plain:right

(1) (2) (3) (4) (deep dive)

Windows Server 2012 ODX について、ストレージエンジニアや開発者向けの情報をまとめました。
難しい表現にならないように心掛けながら綴ってみます。


ODX をアプリケーションから利用する

エクスプローラーや COPY コマンド、PowerShell などを利用する場合には意識しなくて良いですが、アプリが ODX を使えるか使えないは、利用する Filesystem API 次第です。

以下に ODX をサポートする API とサポートしない API を記載します。

○  CopyFile,  CopyFileEx,  MoveFile,  MoveFileEx,  CopyFile2
×  CopyFileTransacted,  MoveFileTransacted


なお、LUN を認識しているホストがネットワーク越しの場合、転送プロトコルが SMB 3.0 であればそこにラップされるのであまり気にしなくても大丈夫です。

以下は開発者向け情報

もっとローレベルで処理したい場合は
FSCTL で FSCTL_Offload_Read / FSCTL_Offload_Write を呼び出してください。
また、実は LUN をマウント(ロック)していなくても大丈夫だそうです。
その場合は FSCTL ではなく DSM IOCTL、つまり IOCTL_STORAGE_MANAGE_DATA_SET_ATTRIBUTES の DeviceDsmAction_OffloadRead / DeviceDsmAction_OffloadWrite になります。


ODX を利用できるのは「コピー」と「ゼロ埋め」

ODX を利用できる操作は、XCOPY の名のとおり、ファイルの「コピー」です。
また「移動」も対象となります。
これは、ファイルシステムにおける移動処理の実体が "copy and delete" であるためです。但し、同一ボリューム内のファイル移動については ODX は掛かりません。これは普段の操作で気づかれている方も多いと思いますが、メタデータを少し書き換えるだけで、実際のブロックは何も動かないためです。


Hyper-V に関して言えば、Storage Live Migration や仮想マシンの Import/Export 操作などで効果を確認できました。また、容量固定の VHD や VHDX 作成時もなぜか ODX が掛かるようです

Hyper-V の容量固定 VHD は、VMware でいう EZT (Eager Zero Thick) とほぼ同じ、ゼロ埋めによって最大容量まで事前アロケートされたファイルのことです。
VMware の場合は SBC-2 の WRITE SAME という別の SCSI コマンドを使ってオフロード可能ですが、ODX は WRITE SAME を使っている様子はありません。
推測ですが、Hyper-V の容量固定ディスクの作成ウィザードは、
一旦どこかにゼロ埋めした小さなファイルを作成し、それを ODX (=XCOPY) でひたすらコンカチしているのかもしれません*1


2013.6.13 修正
ODX が利用する SBC-3 XCOPY (EXTENDED COPY) コマンドには、ゼロ埋め機能も追加されているらしく、Hyper-V はそのまま XCOPY でゼロ埋めするそうです。

オフロード処理 VMware vSphere 5.1 Windows Server 2012 Hyper-V
ファイルコピー SBC-3 XCOPY SBC-3 XCOPY
ゼロ埋め SBC-2 WRITE SAME SBC-3 XCOPY
排他ロック SBC-2 XOR (不要)

ODX のブロックサイズ


ストレージアレイは転送ファイルが LUN 上のどのアドレスに位置しているか把握していません。
また、OS は命令するだけで実際のコピーを行っていないにもかかわらず、右図のように「進捗率」が表示されます。
ここから類推できるとおり、
ストレージはコピー状況を定期的に OS に報告しています。


ODX でファイルをコピーする際のブロックサイズ、
つまり 転送長 は 0 〜 256MB の範囲でストレージ側から指定可能です。
ストレージ側で指定がない場合には 既定値 64 MB が利用されます。
そして、ストレージアレイはこのサイズのデータを読み取り(ディスク→コントローラ)・書き込み(コントローラ→ディスク)するごとに、512 Bytes の転送結果 "Token" を OS に返します。つまり、Token とは 戻り値 のようなものです。
なお、各ブロックの書き込みは T10 の規定で 4 秒以内に終えなければなりません。したがって、転送長が 64 MB の場合、最低 16MB/s を出さないとエラーハンドリングが行われ、一定のリトライなどで救えない場合は ODX の利用は中断されます。


ODX はストレージのどこに負荷が掛かる?

ODX 概論の際、ODX は通常より何倍も速く転送しなければならず、コントローラに負荷が掛かるため次のような対処方法を持つものを選択すべき、と注意喚起させていただきました。

  • ODX 命令に対して QoS を掛けられる
  • RAID 計算をコントローラーの CPU で兼用せず、専用のチップで処理する


では、ODX でアレイベースコピーをする際、
ストレージアレイのどこが使われる(負荷が掛かる)のでしょう??


下図は、一般的な SAN ストレージの内部アーキテクチャです。

(@IT さんの記事から転載させていただきました)


昨今は FC や iSCSI などのブロックだけでなく、NFS や CIFS などのファイルアクセスも可能な「ユニファイド・ストレージ」もありますが、それは単にフロントエンド(ホストポート, 図中の "FE")層のプロトコルなだけです。
HDD へはコントローラー上の OS が CPU 処理でブロックに変換し、FC, SAS, SATA のいずれかのプロトコルで I/O しています。


ODX はアレイベースではありますが、前述のとおりデータ転送をディスクエンクロージャ(シェルフ)内で完結することはできません。ホストポートまでは流れませんが、コントローラーは通常必ず経由します。


したがって、ストレージ内の各コンポーネントのうち、下記に負荷が掛かります。

  • 実際にデータを読み書きする HDD / SSDバイス
  • ディスクシェルフ内のパス(FC-AL などの loop 系は特に注意)
  • コントローラーとその 処理プロセッサ、ライトバックキャッシュ


なお、クラスタ型のスケールアウトストレージの場合、ノードをまたいで ODX を利用できる機種もありますが、ノード間のパスがボトルネックになる可能性がありますので「ノード間通信のアーキテクチャが Bus なのか Point-to-Point なのか、また帯域は十分か」などをご確認ください。


少し敷居を上げてしましたが、
冒頭のとおり、色々と目を配らなくてはいけないのはストレージの選定者と、実際に運用する「ストレージエンジニア」です。逆にいえば、ストレージエンジニアを立てない規模であれば、それほど神経質にならなくても大丈夫だと思います。


より詳しく知りたい方へのリンク集

#次の WS2012 フォローアップネタは NIC Team あたりにしようと思ってます

*1:どなたかご存じな方いたら教えてください