ストレージ
この記事では、物理ストレージハードウェアが仮想マシン (VM) にどのようにマッピングされるか、およびXenServer®がストレージ関連タスクを実行するために使用するソフトウェアオブジェクトについて説明します。また、環境で使用するストレージハードウェアを適切に選択できるように、利用可能なストレージの種類に関する情報も提供します。
ストレージの概念
次の図は、このセクションで説明するストレージオブジェクトがどのように関連しているかを示しています。
ストレージリポジトリと関連オブジェクトのグラフィカルな概要 ](/en-us/xenserver/8/media/sr-diagram.png)
ストレージリポジトリ (SR)
ストレージリポジトリ (SR) は、仮想マシン (VM) の仮想ディスクイメージ (VDI) が格納される特定のストレージターゲットです。VDIは、仮想ハードディスクドライブ (HDD) を表すストレージ抽象化です。XenServerでサポートされているSRの種類については、「ストレージリポジトリの種類」を参照してください。
SRとVDIの抽象化により、それらをサポートするストレージターゲットで高度なストレージ機能が公開されます。たとえば、シンプロビジョニング、VDIスナップショット、高速クローンなどの高度な機能です。高度な操作を直接サポートしないストレージサブシステムの場合、これらの機能を実装するソフトウェアスタックが提供されます。
ストレージリポジトリは、永続的なディスク上のデータ構造です。基になるブロックデバイスを使用するSRタイプの場合、SRの作成プロセスには、指定されたストレージターゲット上の既存のデータをすべて消去することが含まれます。NFSなどの他のストレージタイプは、既存のSRと並行してストレージアレイ上にコンテナを作成します。
各XenServerホストは、複数のSRと異なるSRタイプを同時に使用できます。これらのSRは、ホスト間で共有することも、特定のホスト専用にすることもできます。共有ストレージは、定義されたリソースプール内の複数のホスト間でプールされます。共有SRは、プール内の各ホストからネットワーク経由でアクセスできる必要があります。共有ストレージは、複数のプール間で共有することはできません。
SRコマンドは、含まれる個々のVDIの作成、破棄、サイズ変更、クローン作成、接続、および検出の操作を提供します。ストレージリポジトリを管理するためのCLI操作については、「SRコマンド」で説明されています。
仮想ディスクイメージ (VDI)
仮想ディスクイメージ (VDI) は、仮想ハードディスクドライブ (HDD) を表すストレージ抽象化です。VDIは、XenServerにおける仮想化ストレージの基本単位です。VDIは、XenServerホストとは独立して存在する永続的なディスク上のオブジェクトです。XenServerで仮想ディスクにサポートされているデータ形式の詳細については、「仮想ディスクデータ形式」を参照してください。
VDIを管理するためのCLI操作については、「VDIコマンド」で説明されています。データのディスク上の表現はSRタイプによって異なります。SM APIと呼ばれる各SR用の個別のストレージプラグインインターフェイスがデータを管理します。
物理ブロックデバイス (PBD)
物理ブロックデバイスは、物理サーバーと接続されたSR間のインターフェースを表します。PBDは、特定のSRをホストにマッピングできるようにするコネクタオブジェクトです。PBDは、特定のストレージターゲットに接続して操作するために使用されるデバイス構成フィールドを格納します。例えば、NFSデバイス構成には、NFSサーバーのIPアドレスと、XenServerホストがマウントする関連パスが含まれます。PBDオブジェクトは、特定のSRを特定のXenServerホストに実行時にアタッチすることを管理します。PBDに関連するCLI操作については、PBDコマンドで説明されています。
仮想ブロックデバイス (VBD)
仮想ブロックデバイスは、VDIとVM間のマッピングを可能にするコネクタオブジェクトです（上記のPBDと同様）。VDIをVMにアタッチするメカニズムを提供するだけでなく、VBDは、特定のVDIのディスクI/O優先度と統計、およびそのVDIが起動可能かどうかに関するパラメータの微調整を可能にします。VBDに関連するCLI操作については、VBDコマンドで説明されています。
ストレージリポジトリの種類
XenServerは、ローカルおよびリモート接続されたSRの両方に対応した、さまざまなストレージタイプをサポートしています。
警告:
XenServerは、いずれのSRタイプでも、LUNの外部SANレベルでのスナップショットをサポートしていません。
ローカルSR
ローカルストレージリポジトリ（SR）は単一のホストに接続され、プール内のすべてのホスト間で共有されません。ローカルの物理ストレージハードウェアは、ハードディスクドライブ（HDD）またはソリッドステートドライブ（SSD）にすることができます。以下のいずれかの方法でホストに接続できます: SATA、SCSI、SAS、NVMe。
XenServerホストは、以下の種類のローカルストレージをサポートしています。
リモートSR
XenServerは、iSCSI、NFS、SAS、SMB（バージョン3のみ）、Fibre Channelなどのドライブを使用してリモート接続ストレージをサポートしています。
注記:
NVMe over Fibre Channel および NVMe over TCP はサポートされていません。
XenServer プール用の共有 SR を作成するには、以下のリモート接続ストレージタイプを使用できます。
ISO ライブラリ:
ファイルベースのストレージ:
ブロックベースのストレージ:
共有ストレージタイプの比較
以下の表は、共有SRでサポートされているさまざまなストレージタイプの機能を比較しています。ストレージソリューションを選択する際には、これらの機能を考慮してください。
| ファイルベース (SMB/NFS) | ブロックベース (iSCSI/HBA) LVM | ブロックベース (iSCSI/HBA) GFS2 | |
|---|---|---|---|
| 仮想ディスクの種類 | VHD | VHD | QCOW2 |
| SRあたりの最大仮想ディスク数 | 20000 | 1000 | 20000 |
| 最大仮想ディスクサイズ | 2,040 GiB | 2,040 GiB | 16 TiB |
| 最大プールサイズ(/ja-jp/xenserver/8/hosts-pools.html#recommended-pool-size) | 32/64 | 32/64 | 16 |
| サポートされる機能 | |||
| ストレージ移行(/ja-jp/xenserver/8/vms/migrate.html) | はい | はい | いいえ |
| インテリキャッシュ | はい | はい | いいえ |
| 読み取りキャッシュ(/ja-jp/xenserver/8/storage/read-cache.html) | はい | いいえ | はい |
| シンプロビジョニング（注を参照） | はい | いいえ | はい |
| ディザスタリカバリ | いいえ | はい | いいえ |
注:
ブロックベースのLVMストレージの場合、基盤となるSANでシンプロビジョニングを実装できます。ただし、これはGFS2 SRでは推奨されません。
仮想ディスクデータ形式
一般的に、物理ストレージからVDIへのマッピングには次の種類があります。
-
LUN上の論理ボリュームベースVHD: デフォルトのXenServerブロックベースストレージは、ディスクに論理ボリュームマネージャーを挿入します。このディスクは、ローカル接続デバイス (LVM) または、Fibre Channel、iSCSI、SAS のいずれかを介してSANに接続されたLUNです。VDIはボリュームマネージャー内のボリュームとして表現され、スナップショットとクローンでの参照ノードのシンプロビジョニングを可能にするためにVHD形式で保存されます。
-
LUN上のファイルベースQCOW2: VMイメージは、iSCSIソフトウェアイニシエーターまたはハードウェアHBAのいずれかを介して接続されたLUN上のGFS2共有ディスクファイルシステムに、シンプロビジョニングされたQCOW2形式ファイルとして保存されます。
-
ファイルシステム上のファイルベースVHD: VMイメージは、ローカルの非共有ファイルシステム (EXT3/EXT4タイプSR)、共有NFSターゲット (NFSタイプSR)、またはリモートSMBターゲット (SMBタイプSR) のいずれかに、シンプロビジョニングされたVHD形式ファイルとして保存されます。
-
ファイルシステム上のファイルベースQCOW2: VMイメージは、ローカルの非共有XFSファイルシステムに、シンプロビジョニングされたQCOW2形式ファイルとして保存されます。
VDIの種類
GFS2およびXFS SRの場合、QCOW2 VDIが作成されます。
他のSRタイプの場合、VHD形式のVDIが作成されます。VDIの作成時にrawを使用することを選択できます。このオプションは、xe CLIを使用してのみ指定できます。
注:
LVMベースのSR上にraw VDIを作成すると、所有するVMが、以前に削除されたVDI (任意の形式) の一部であった、任意のVMに属するデータにアクセスできるようになる可能性があります。このオプションを使用する前に、セキュリティ要件を考慮することをお勧めします。
NFS、EXT、またはSMB SR上のraw VDIは、以前に削除された、任意のVMに属するVDIのデータへのアクセスを許可しません。
VDIが
type=rawで作成されたかどうかを確認するには、そのsm-configマップを確認します。この目的には、sr-param-listおよびvdi-param-list xeコマンドをそれぞれ使用できます。
xe CLIを使用してraw仮想ディスクを作成する
-
仮想ディスクを配置するSRのUUIDを指定して、VDIを作成するには、次のコマンドを実行します。
xe vdi-create sr-uuid=sr-uuid type=user virtual-size=virtual-size \
name-label=VDI name sm-config:type=raw -
新しい仮想ディスクをVMに接続します。VM内のディスクツールを使用して、パーティション分割とフォーマットを行うか、新しいディスクを使用します。
vbd-createコマンドを使用してVBDを作成し、仮想ディスクをVMにマップできます。
VDI形式間の変換
raw形式とVHD形式の間で直接変換を行うことはできません。代わりに、VDI（上記で説明したraw形式またはVHD形式のいずれか）を作成し、既存のボリュームからデータをコピーできます。新しいVDIの仮想サイズが、コピー元のVDIと少なくとも同じ大きさであることを確認するには、xe CLIを使用します。これは、
vdi-param-listコマンドを使用して、そのvirtual-sizeフィールドを確認することで実行できます。その後、この新しいVDIをVMにアタッチし、VM内で好みのツールを使用してデータの直接ブロックコピーを実行できます。例えば、Windowsの標準ディスク管理ツールやLinuxのddコマンドなどです。新しいボリュームがVHDボリュームの場合は、空のセクターをディスクに書き込まないツールを使用してください。この操作により、基盤となるストレージリポジトリでスペースが最適に利用されるようになります。ファイルベースのコピーアプローチの方が適している場合があります。
VHDベースおよびQCOW2ベースのVDI
VHDおよびQCOW2イメージはチェーン化でき、2つのVDIが共通データを共有できます。VHDまたはQCOW2をバックエンドとするVMがクローンされる場合、結果として生成されるVMは、クローン作成時に共通のディスク上データを共有します。各VMは、VDIの分離されたコピーオンライトバージョンで独自の変更を行います。この機能により、このようなVMをテンプレートから迅速にクローンでき、新しいVMの非常に高速なプロビジョニングとデプロイが可能になります。
VMとその関連VDIが時間の経過とともにクローンされると、チェーン化されたVDIのツリーが作成されます。チェーン内のVDIの1つが削除されると、XenServerはチェーン内の他のVDIを合理化して不要なVDIを削除します。この統合プロセスは非同期で実行されます。回収されるディスクスペースの量とプロセスの実行にかかる時間は、VDIのサイズと共有データの量によって異なります。詳細については、「統合に関する注意事項」を参照してください。
VHD形式とQCOW2形式の両方が、シンプロビジョニングをサポートしています。VMがディスクにデータを書き込むと、イメージファイルはきめ細かいチャンクで自動的に拡張されます。ファイルベースのVHDおよびGFS2ベースのQCOW2の場合、このアプローチには、VMイメージファイルが物理ストレージ上で必要なだけのスペースしか占有しないという大きな利点があります。LVMベースのVHDの場合、基盤となる論理ボリュームコンテナはVDIの仮想サイズに合わせる必要があります。ただし、スナップショットまたはクローンが発生すると、基盤となるコピーオンライトインスタンスディスク上の未使用スペースは再利用されます。2つの動作の違いは、次のように説明できます。
-
LVMベースのVHDイメージの場合、チェーン内の差分ディスクノードは、ディスクに書き込まれたデータ量のみを消費します。ただし、リーフノード（VDIクローン）は、ディスクの仮想サイズまで完全に拡張されたままです。スナップショットリーフノード（VDIスナップショット）は、使用されていないときはデフレートされたままであり、デフレートされた割り当てを保持するために読み取り専用でアタッチできます。読み書きモードでアタッチされたスナップショットノードは、アタッチ時に完全に拡張され、デタッチ時にデフレートされます。
-
ファイルベースのVHDおよびGFS2ベースのQCOW2イメージの場合、すべてのノードは書き込まれたデータ量のみを消費します。リーフノードファイルは、データがアクティブに書き込まれるにつれて、データを収容するために拡張されます。VMに100 GBのVDIが割り当てられ、OSがインストールされている場合、VDIファイルは物理的にはディスク上のOSデータのサイズに、わずかなメタデータオーバーヘッドを加えたものになります。
単一のVHDまたはQCOW2テンプレートに基づいてVMをクローンする場合、各子VMは新しい変更が新しいVMに書き込まれるチェーンを形成します。古いブロックは親テンプレートから直接読み取られます。新しいVMがさらにテンプレートに変換され、より多くのVMがクローンされた場合、結果として生じるチェーンはパフォーマンスの低下につながります。XenServerは最大30のチェーン長をサポートしています。正当な理由なしにこの制限に近づかないでください。疑問がある場合は、XenCenterを使用してVMを「コピー」するか、チェーン長を0にリセットする
vm-copyコマンドを使用してください。
統合に関する注意事項
SRに対してアクティブな統合プロセスは常に1つだけです。このプロセススレッドはSRプールコーディネーター上で実行されます。統合プロセスがアクティブな間は、デルタツリーのあるレベルから別のレベルにマージされるデータを収容するために、SRに追加のスペースが必要になる場合があります。このプロセスが完了すると、冗長なレベルが削除され、スペースが解放されます。
プールコーディネーター上で重要なVMを実行している場合、時折発生するI/Oの遅延を軽減するために、以下の手順を実行できます。
-
VMをSRプールコーディネーター以外のホストに移行する
-
ディスクI/O優先度をより高いレベルに設定し、スケジューラを調整します。詳細については、「仮想ディスクI/O要求の優先順位付け」を参照してください。