ディスクコントローラとキャッシュ
Proxmoxのディスクコントローラとキャッシュ
本ページは、仮想マシンの設定時のディスク関連の情報について、考え方と注意事項を記載しています。
#contents(): { "base" : 指定されたデザイン名のファイルが存在しません。 }
SCSIコントローラについて
VM新規作成などで選択するSCSIコントローラ、デフォルトのVirtIO Singleにすると、1つのSCSIコントローラに次の節にある仮想ディスクを複数作成した際に、全てがこのコントローラに接続するように見えます。これにより、仮想マシン内のメモリやデバイスが節約されます。
「VirtIO SCSI」を選ぶと、個別のSCSIバスに個別の仮想ディスクが繋がって見えるようになり、個別のドライバ空間とメモリが必要となります。しかし、仮想マシンからのIO速度が分散されることでワークロードによっては速度が向上することがあります。
それ以外の物理SCSIカードのエミュレーションは、通常は利用すべきではありません。
ディスクコントローラについて
IDE(別名ATA)が策定されたのは1988年であるため、ほぼ全てのOSがサポートしています。2003年以前にリリースされたOSではこちらを利用するのがよいでしょう。物理的なIDEは133MB/secが最大速度でしたが、仮想化する場合、IDE自体の実装はとてもシンプルな構造であるため、133MB/secの律速はありません(OS内で敢えて律速している場合は除く)。しかし、IDEはホットスワップの規格がなかったため、仮想マシンの中でデバイスの取り外しができません。
SATAは、2003年以降に登場したOSに向いています。昨今のOSでは互換性が一番高いでしょう。物理的な規格はIDEを継承しシリアル化したものにすぎず、6Gbps(約600MB/sec程度)までの速度でしたが、仮想化する場合はゲストOS内であえて律速しない限り、この律速はありません。
VirtIO SCSI、VirtIO SCSI Singleは、もっとも高速にディスクアクセスが可能になります。ただし、ゲストOS内に準仮想ドライバが含まれている必要があります。IDE/SATAのディスクが一切繋がっていないシステムの場合、OSのインストール時にVirtIO SCSIドライバをインストールしなければ、OSのブートができません。Linuxではおよそ2012年のディストリビューションからこのドライバが提供されており、FreeBSDでは2014年以降、Windows OSの場合は、インストール中にVirtIOドライバを含む追加のISOファイルを提供する必要があります。
ディスクキャッシュについて
ディスクキャッシュの設定は安全性と速度のトレードオフになっています。
- キャッシュ無し
- ゲストのI/Oはホストのキャッシュをバイパスし、ディスクに直接書き込みます(O_DIRECT)。ただし、書き込み要求に対してfsyncは発効されません。これにより、データの整合性が高まりますが、パフォーマンスは他のキャッシュモードと比べて劣る傾向にあります。
- writethrough
- 書き込み操作はホストのキャッシュを通じて行われますが、データは即座にディスクに書き込まれ、fsyncを発効します。これにより、データの整合性が保たれつつ、読み取りパフォーマンスも向上しますが、書き込みパフォーマンスは向上しません。ただし、ローカル接続のNVMe SSDなどではこの限りではありません。
- writeback
- 書き込み操作はホストのキャッシュに保存され、その後ディスクに書き込まれます。これにより、書き込みパフォーマンスが向上しますが、ホストの障害が発生した場合、データが失われるリスクがあります。
- directsync
- ゲストのI/Oはホストのキャッシュをバイパスし、ディスクに直接書き込みます(O_DIRECT)。書き込み要求に対してfsyncを発効します。このモードはデータの整合性が非常に高くなりますが、パフォーマンスは他のキャッシュモードと比べて劣ります。
- unsafe
- キャッシュを最大限利用して、パフォーマンスを高めるモードです。ただし、ホストのクラッシュが発生した場合、データが失われるリスクが非常に高くなります。
下記はこれらをまとめた表となります。
| 特徴 | writethrough | directsync | none | writeback | unsafe |
|---|---|---|---|---|---|
| キャッシュの使用 | ページキャッシュを使用（読み取りに有利） | キャッシュを使用しない | キャッシュを使用しない | ページキャッシュを使用 | ページキャッシュを使用 |
| fsync の発行 | 書き込みごとに発行 | 書き込みごとに発行 | 発行されない | 遅延して発行 | 発行されない |
| 書き込みの流れ | キャッシュに書き込み後、即座にディスクにフラッシュ | ディスクに直接書き込み、すぐにフラッシュ | ディスクに直接書き込み、フラッシュなし | キャッシュに書き込み、遅延フラッシュ | キャッシュに書き込み、フラッシュなし |
| 読み取り性能 | 高い（キャッシュを利用） | 低い（ディスクに依存） | 低い（ディスクに依存） | 高い（キャッシュを利用） | 高い（キャッシュを利用） |
| 書き込み性能 | 中程度（キャッシュ経由） | 低い（キャッシュなし） | 中程度（キャッシュなし） | 高い（キャッシュ利用で遅延） | 非常に高い（キャッシュ利用で遅延） |
| データ整合性 | 高い | 非常に高い | 中程度（ディスク依存） | 低い（書き込みが遅延） | 非常に低い（データ損失のリスク高） |
| 主な用途 | 読み取り中心でデータ整合性が重要なシステム | データ整合性が最優先のシステム | 高速性が重要で、整合性が二次的なシステム | 書き込み性能が重要だが、ある程度の整合性も必要なシステム | 書き込み性能を最優先するが、データ損失リスクが許容されるシステム |
TRIM(discard)
Discardコマンドは、ストレージに対し、削除して不要になった領域を「Discard(破棄)」させます。
もともとはSSDのウェアレベリング処理で、OSが不要になったブロックをデバイス側で認識する必要があり実装されました。このため、OSによってはSSDエミュレーションする必要がある場合があります。
OSがDiscardに対応すると、SSDだけにメリットがあるわけではなく、実機のストレージによっては暗号化したデータを鍵情報を消去するだけでデータの消し込みを行わなくても永久に破棄が可能になります。
プライベートクラウドにおいては、Thin Provisioningに対応したストレージにて、データを再び解放することができます。通常、仮想マシン内で一度でも領域が使われると、仮にデータを削除した場合でもストレージ層ではデータは解放されません。
HRPC KVMタイプにおいては、CephPoolがThin Provisioningに対応し、TRIMにより解放にも対応しています。Enterprise Storageを組み合わせた3-Tier型の場合は、ESF(NFSモード)を選び、qcow2形式でデータを格納することで、Thin Provisioningに対応し、TRIMにより解放にも対応します。
実際の仮想OS内でのTRIMの発効はOSによって異なります。
Linux OSでは、下記のコマンドを利用してポスト処理としてTRIM処理を行うことができます。データの消し込みがおおい処理のあとなど、バッチ的実行をするのがよいでしょう。
fstrim -v マウントポイント
また、マウントオプションにdiscardをつけることで、リアルタイム処理でTRIM処理を行うことができます。/etc/fstabなどのマウントオプションで入れることができますが、下記の様にdiscard付きでmountし直すこともできます。
mount -o discard,remount /
Windows Server OSは、バージョンによって異なり、SSDエミュレーションが必須です。
参考≫ テクニカルノート/Private Cloud環境でのWindows Serverのデフラグ機能について
IO thread
VirtIO SCSIなどを利用する際にディスクIOのIOスレッドを有効にすると、ディスクの書き込みの実際の処理を「親OSの」メインスレッドとは別のスレッドで扱うようになります。
つまり、VirtIOのコマンド発行側(デバイスドライバ側)は仮想OSのスレッドで動作し、受け取る側のデバイス側は別スレッドで動作します。
これによりCPUコア設定に加えて、さらにCPUのスレッドを要求することになりますが、複数の仮想ディスクに渡って書き込みが発生するような場合、読み書きのレイテンシが短縮することになります。
