XenServer

ストレージ

この記事では、物理ストレージハードウェアが仮想マシン (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と同様)です。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
最大プールサイズ 32/64 32/64 16
サポートされる機能
ストレージ移行 はい はい いいえ
インテリキャッシュ はい はい いいえ
読み取りキャッシュ はい いいえ はい
シンプロビジョニング (注を参照) はい いいえ はい
ディザスタリカバリ いいえ はい いいえ

注:

ブロックベースのLVMストレージの場合、基盤となるSANでシンプロビジョニングを実装できます。ただし、これはGFS2 SRでは推奨されません。

仮想ディスクデータ形式

一般的に、物理ストレージからVDIへのマッピングには次の種類があります。

  1. 論理ボリュームベースのVHD(LUN上): デフォルトのXenServerブロックベースストレージは、ディスクに論理ボリュームマネージャーを挿入します。このディスクは、ローカル接続デバイス(LVM)であるか、Fibre Channel、iSCSI、またはSASを介してSANに接続されたLUNのいずれかです。VDIはボリュームマネージャー内のボリュームとして表現され、スナップショットとクローンで参照ノードのシンプロビジョニングを可能にするためにVHD形式で保存されます。

  2. ファイルベースのQCOW2(LUN上): VMイメージは、iSCSIソフトウェアイニシエーターまたはハードウェアHBAを介して接続されたLUN上のGFS2共有ディスクファイルシステムに、シンプロビジョニングされたQCOW2形式ファイルとして保存されます。

  3. ファイルベースのVHD(ファイルシステム上): VMイメージは、ローカルの非共有ファイルシステム(EXT3/EXT4タイプSR)、共有NFSターゲット(NFSタイプSR)、またはリモートSMBターゲット(SMBタイプSR)のいずれかに、シンプロビジョニングされたVHD形式ファイルとして保存されます。

  4. ファイルベースの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(任意の形式)に属するデータを、どのVMのものであってもアクセスできるようになる可能性があります。このオプションを使用する前に、セキュリティ要件を考慮することをお勧めします。

NFS、EXT、またはSMB SR上のraw VDIは、以前に削除されたVDIに属するデータへのアクセスを許可しません。

VDIがtype=rawで作成されたかどうかを確認するには、そのsm-configマップを確認します。この目的には、sr-param-listおよびvdi-param-list xeコマンドをそれぞれ使用できます。

xe CLIを使用してraw仮想ディスクを作成する

  1. 仮想ディスクを配置する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-->
    
  2. 新しい仮想ディスクをVMに接続します。VM内のディスクツールを使用して、新しいディスクをパーティション分割およびフォーマットするか、その他の方法で使用します。vbd-createコマンドを使用して、仮想ディスクをVMにマッピングするためのVBDを作成できます。

VDI形式間の変換

raw形式とVHD形式の間で直接変換を行うことはできません。代わりに、VDI(上記で説明したraw形式、またはVHD形式のいずれか)を作成し、既存のボリュームからデータをコピーできます。xe CLIを使用して、新しいVDIの仮想サイズがコピー元のVDIと同じかそれ以上であることを確認してください。これは、virtual-sizeフィールドを確認することで実行できます。例えば、vdi-param-listコマンドを使用します。その後、この新しい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要求の優先順位付け」を参照してください。

ストレージ