ストレージ
この記事では、物理ストレージハードウェアが仮想マシン (VM) にどのようにマッピングされるか、およびXenServer®がストレージ関連タスクを実行するために使用するソフトウェアオブジェクトについて説明します。また、環境で使用するストレージハードウェアを適切に選択できるように、利用可能なストレージの種類に関する情報も提供します。
ストレージの概念
次の図は、このセクションで説明するストレージオブジェクトがどのように関連しているかを示しています。
ストレージリポジトリ (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タイプによって異なります。各SRには、SM APIと呼ばれる個別のストレージプラグインインターフェイスがあり、データを管理します。
物理ブロックデバイス (PBD)
物理ブロックデバイスは、物理サーバーと接続されたSR間のインターフェースを表します。PBDは、特定のSRをホストにマッピングできるようにするコネクタオブジェクトです。PBDは、特定のストレージターゲットに接続して対話するために使用されるデバイス構成フィールドを格納します。たとえば、NFSデバイス構成には、NFSサーバーのIPアドレスと、XenServerホストがマウントする関連パスが含まれます。PBDオブジェクトは、特定のSRを特定のXenServerホストにランタイムでアタッチすることを管理します。PBDに関連するCLI操作については、PBDコマンドで説明されています。
仮想ブロックデバイス (VBD)
仮想ブロックデバイスは、VDIとVM間のマッピングを可能にするコネクタオブジェクト（上記のPBDと同様）です。VBDは、VDIをVMにアタッチするメカニズムを提供するだけでなく、特定の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のみ)、ファイバーチャネル。
注記:
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/9/hosts-pools#recommended-pool-size) | 32/64 | 32 | 16 |
| サポートされる機能 | |||
| ストレージ移行](/ja-jp/xenserver/9/vms/migrate) | はい | はい | いいえ |
| インテリキャッシュ](/ja-jp/xenserver/9/storage/intellicache) | はい | はい | いいえ |
| 読み取りキャッシュ](/ja-jp/xenserver/9/storage/read-cache) | はい | いいえ | はい |
| シンプロビジョニング (注を参照) | はい | いいえ | はい |
| 災害復旧 | いいえ | はい | いいえ |
注:
ブロックベースのLVMストレージの場合、基盤となるSANでシンプロビジョニングを実装できます。ただし、これはGFS2 SRでは推奨されません。
仮想ディスクデータ形式
一般的に、物理ストレージからVDIへのマッピングには以下の種類があります。
-
LUN上の論理ボリュームベースVHD: デフォルトのXenServerブロックベースストレージは、ディスク上に論理ボリュームマネージャーを挿入します。このディスクは、ローカルに接続されたデバイス (LVM) であるか、またはファイバーチャネル、iSCSI、またはSASを介したSAN接続LUNのいずれかです。VDIはボリュームマネージャー内のボリュームとして表現され、スナップショットとクローンでの参照ノードのシンプロビジョニングを可能にするためにVHD形式で保存されます。
-
ファイルベースのQCOW2 (LUN上): 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またはHBA/LUNごとのVDI SR上にraw VDIを作成すると、所有するVMが、以前に削除されたVDI (任意の形式) の一部であったデータにアクセスできるようになる可能性があります。このオプションを使用する前に、セキュリティ要件を考慮することをお勧めします。
NFS、EXT、またはSMB SR上のraw VDIは、以前に削除された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 <!--NeedCopy--> -
新しい仮想ディスクをVMに接続します。VM内のディスクツールを使用してパーティション分割とフォーマットを行うか、新しいディスクを使用します。
vbd-createコマンドを使用してVBDを作成し、仮想ディスクをVMにマッピングできます。
VDI形式間の変換
raw形式とVHD形式の間で直接変換を行うことはできません。代わりに、VDI (上記のようにrawまたはVHD) を作成し、既存のボリュームからデータをコピーできます。xe CLIを使用して、新しいVDIの仮想サイズがコピー元のVDIと少なくとも同じ大きさであることを確認します。これは、たとえば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を「コピー」するか、vm-copyコマンドを使用してチェーン長を0に戻してください。
統合に関する注意事項
SRに対してアクティブな統合プロセスは常に1つだけです。このプロセススレッドはSRプールコーディネーター上で実行されます。統合プロセスがアクティブな間、デルタツリーのあるレベルから別のレベルにマージされるデータを収容するために、SRに追加のスペースが必要になる場合があります。このプロセスが完了すると、冗長なレベルが削除され、スペースが解放されます。
プールコーディネーター上で重要なVMを実行している場合、時折発生するI/Oの遅延を軽減するために、次の手順を実行できます。
-
VMをSRプールコーディネーター以外のホストに移行する
-
ディスクI/O優先度をより高いレベルに設定し、スケジューラーを調整します。詳細については、「仮想ディスクI/O要求の優先順位付け」を参照してください。