High Response Private Cloud (HRPC) Xen 6Gf
ストレージ・ディープ・ダイブ
本ドキュメントは、High Response Private Cloud (HRPC) 6Gf 環境での HRPC Xenタイプのストレージ設計方針について、現行の実装から、将来的な構想まで含め、技術的、構造的に深掘り(ディープ・ダイブ)したものです。
想定読者は、HRPCのストレージ内部構造やハイパーバイザ連携が理解できる上級エンジニア、内部構造がどのようになっているか興味が尽きない人です。
HRPCの一般的なシステム利用者(そしてそれを管理する人)には「ほとんど」必要ありません。
現時点での Xen タイプのストレージ設計
参考≫ HRPCのストレージ設計例
IaR（Independent and Replication）型
- 構成：ICSをext4でフォーマットし、仮想マシンのVHD (バーチャルハードディスク)を保存
- レプリケーション：Continuous Replication(スナップショットレプリケーション)を用い、BSF(Backup StorageのNFSなど)や、QuTS Cloud on InfiniCloudに保存。
- 用途：(設計的に)シンプルで安定した構成。ICSの高速性がもっとも生かせるタイプ
3Tier型
- 構成：NFSベースの SR に vhd ファイルを格納。
- 特徴：レプリケーション機構は IaR と同様。ボリューム共有性に優れる。
HCI（現在、InfiniCloudで開発中）
- 構成予定：Ceph RBD を SMAPIv3 経由で直結
- 特徴：Librados ベースのネイティブ SR。将来、Xen Orchestraが対応すれば、snapshot + clone + replication 自動化も視野。
VHD on FS なのか？ LVM on block deviceなのか？
現時点のxcp-ngがもつStorage Management APIはSMAPI v1とv3となります。SMAPI v3はまだ出たばかりの機能なので、これに関しては後述しますが、HRPC Xenタイプでは、事実上、SMAPI v1を利用せざるをえません。
そのため、次の二つの方法でストレージを利用する必要があります。
- vhd on File system：ext4やNFSの上にVHDファイルを保存し、XAPIで管理する方式
- LVM on Block Device：ローカルディスクや、iSCSIボリュームにLVM の論理ボリュームを SR として割当る方式
HRPC Xenタイプでは、標準構成出荷時にはVHD型を利用しています。これがなぜなのか？を含め、このドキュメントは記載します。
一般的なメリット・デメリット
一般的なシステムアドミンが読むような資料には下記の様なことが書かれていると思われます。ここでは復習も含め、記載しておきます。
| 項目 | VHD | LVM |
|---|---|---|
| ファイル単位の柔軟性 | ◎（vhdファイルごと管理） | ✖️（LV単位） |
| スナップショット操作の明示性 | ◎（vhdファイルが明確に分かれる） | △（LV内でメタデータ管理） |
| 差分ファイルの削除・復元 | ◎（vhdファイル削除・コピーで対応） | ✖️（複雑な merge が必要） |
| I/O性能（通常時） | ○（ある程度安定） | ◎（直ブロックアクセス） |
| Thin Provisioning | ○ | ✖️（clvm/Thin Pool なら一部可） |
このリストから考えると、HRPC XenがVHD型をつかうのは、Thin Provisioningの為ではないか？と見えるでしょうが、本当の理由は下記です。
容量臨界時の挙動比較
しかし、実際にHRPC Xenタイプの設計をしたときに、最重要比較したのは下記の通りです。
| 状況 | VHD | LVM |
|---|---|---|
| VMがディスク容量を使い切った | VM内で `ENOSPC`（書き込み不能） ホストの ext ファイルシステムは正常継続 | LVサイズ限界に達するまで動作 snap領域と競合しても警告なし |
| snapshotが肥大しすぎた | vhdチェインが深くなり I/O遅延が発生 mergeが必要で、mergeの時、多くの空き容量が必要になるが「最悪パターンでは別のストレージにコピーして(サービス上は行いません)」ファイルベースで管理可能 | snapshot LV領域が一杯になると 元の LV ごと破壊される（巻き添え） |
| merge処理中に容量不足 | merge失敗、差分 vhd が残る（手動削除により復旧可能） | merge途中で失敗すると元LVが不整合になるリスクが高い |
| ディスク全体が満杯 | vhd書き込みに失敗、ログで検出可能 少なくとも元VMには致命傷にならない | snapshot LVが書き込めず強制破棄→元VMのI/O中にクラッシュの危険 |
| ディスク不整合・FS障害 | ファイル単位でfsckや修復可能 | LVMのメタ情報破損時はVGごと復旧不能リスクあり |
| 1ボリューム内のVM数 | 50ぐらいまで常用可能 | 10〜20で重くなる |
実は、どちらも完璧ではないのですが、VHD型の方が最悪のパターンでの復旧が可能になるケースが多くあります。
運用観点まとめ
| 観点 | VHD | LVM |
|---|---|---|
| 障害時リカバリ性 | ◎ ファイル単位で対応可能 | ✖️ LVMツールで複雑・致命的リスクあり |
| スナップショット削除の安全性 | △(sparse型) | ✖️（merge中クラッシュで全損の可能性） |
| 大容量VMの管理 | △（2TiB 制限あり） | ◎（理論制限ほぼなし、ただしblktapに2TiB制限あり） |
| Xen の互換性・実績 | ◎（最も使われてきた構成） | ○（ただし、現状clvmやthin pool非対応） |
現在のSMAPIv1ベースのシステムでは、いずれにしても2TiB問題があります。
回避できない問題
まずは、現行システムの回避不能な問題について、記載しておきます。
- ロック問題
- ハイパバイザは、仮想マシンの数だけ、しばしばストレージ対してメタ情報操作時にロックを掛けます。これはVMwareなども同じです。IaR型の場合、Independentなのでほぼ問題は起きませんが、共有ストレージを用いた3Tier型、たとえばNFSではファイルロックを掛け、iSCSIでは、SCSI2 LUN Lockを定期的に発行します。
- このロックは1VMあたり、1秒に1度程度、何かしら発生しているため、LVMの場合は広域ロックが発生することになります。この結果、もちろんこれは3Tierストレージレスポンスタイムにもよりますが、1つのLVMで動作できるVMの数がおよそ、10〜20VMsぐらいでロック時間が無視できなくなり、顕著に速度劣化が始まります。
- これが、3TierタイプでNFSを利用する利用ですが、その代わりにNFSの場合、ストレージのリタンダンシー(Fail Over)を、うまくできないという問題が発生します。(NASによって可能なものもありますが、Take Overの成功は容易でも、IO臨界動作時でのFail Overの成功率が今ひとつ低いため、当社では利用していません)。
- VHDのSnapshotが△なのはなぜ？
- XCP-ngで使われている .vhd は、Microsoft VHD (v1) 互換の差分ディスク形式です。snapshotを取ると、元のvhdはread-onlyにし、新しい差分vhd（child）に書き込みが進みます。つまり、snapshotを取得したことで、親子チェイン構造が開始されます。
- VHD差分ファイルは必要なブロックのみ割り当てられるsparse型なので、sparse領域が急速に増えたり、バックエンドFS(ext4, NFSなど)でディスクフルになると、書き込もうとしたブロックが割り当て不能となります。
- その結果、VHDが壊れやすくなり、親とのチェインが崩れやすくなります。
- Snapshotを取り過ぎると、チェイン構造が深くなります。そしてチェイン構造がふえると、I/O遅延が発生します。Xenのblktap/tapdiskは、読み込み要求のたびに親vhd→その親…とツリーをたどるため、coalesce（統合）しないと事実上まともに動かなくなります。
- snapshotを削除すると merge（親への書き戻し）が発生します。この時、主タスクでIOが多く発生中だと、IO競合がおき、更なるIOを発生させてしまいます。HRPC XenタイプのIaRは、スナップショットレプリケーションによってデータを保護するため、「速いうちからNVMeをサポートした」のはそのためです。また、容量不足だと中断せざるを得ません。さらに、不意のリセットや電源断で、途中終了すると親vhdごと破損するリスクもあります。
- さらにsnapshot情報はvhdファイル間の依存関係としてしか存在せず、XenPoolが持つメタ情報(これはプールマスターが持ちますが、メタ情報は大事なので全てのXen Hostで常に共有しています)が破損することでXAPIやblktapが壊れると、もはやだれにも追跡不能になります。snapshotチェインの断裂は、VM全体が起動不能になるので、この回避は「別プールにContinuous Replication」することで回避するしかありません。
このように、VHDの問題を記述しましたが、それでもLVMのLVが破損するリスクの方が高いため、VHD型を採用しています。
データを最大限安全に留める場合は、バックアップ機能(Delta Backup)や、Continuous Replicationで、別プールにバックアップする方が良いでしょう。
よくある疑問
- LVMもLVM Thinは、ジャーナル型になったのでそれを使えば良いのでは？
- たしかにLVM thin pool を用いることでThin Provisioningができるばかりかsnapshotがジャーナル型に変わり、運用安定性が大いに向上します。現在のLVMのSnapshotによるLV破壊問題とも無縁となります。しかし、少なくても現行のXCP-ng/Xen では公式対応外です。
- VHDの問題は解決しないのか？
- VHD型は、VHD後継のVHDXをサポートすることでジャーナル型になり解決する可能性があります。しかし少なくても現行のXCP-ng/Xen では公式対応外です。
- ファイルシステム型は、SMAPI v3でqcow2 への将来的移行が視野に入っており、これがサポートされれば、可搬性のあるストレージ管理が可能になります。
Snapshotの削除、つまりmerge は、どちらの方式でも負荷が高く、容量が潤沢にあり、IOに余裕がある状態を作る事で安定することができます。
まとめ：HRPC Xenタイプの設計
以上のことから、問題点はいくつかあるものの、臨界時挙動が予測可能で、操作単位がファイルベースな VHDを現在は採用し、LVM は merge 時や snapshot 領域枯渇時の挙動が致命的になる可能性があるため、現時点では採用していないというのが直接的な理由です。
将来：SMAPI v3
SMAPIv1では、blktapという仕組みを用いていることで、どのようなディスクにもストレージマイグレーションができ、スナップショットレプリケーションができるという非常に優れたメカニズムを持っています。
しかしながら時が経つにつれ、NVMe SSDなどの超高速ストレージがうまれることにより、blktapの速度律速が目につくようになりました。現在のblktap3は、blktap2よりも高速化されているものの、tapdiskというサービスが事実上ほとんどのところでシングルスレッドで動いており、これがCPU律速となってしまいます。
またSMAPIv1は、たとえストレージやファイルシステムに強力で安全なSnapshot機構があっても、それを利用することはできません。これはtapdiskによって管理されているためです。
そこでSMAPIv3では、ストレージの能力を最大限に活かす方針に変わり、安全で高速、さらに容量が2TiBを越える代わりに、ストレージシステムの直交性が失われています。
SMAPIv3 および将来の設計展望
SMAPIv3 による Ceph SR（HCI）
- 特徴：Ceph RBD を raw デバイスとして認識し、snapshot/clone API に直接対応可能。
- 利点：高性能・高信頼のストレージを完全に統合でき、VMレベルの操作を高速化可能。
- 制約：メタデータ管理が SR 依存となるため、Continuous Replication の仕組みはまだ整備中。
ZFS SR（SMAPIv3 対応版、現在のHRPC 6Gfで利用可能）
- 利点：ZVOL + snapshot + send/recv による高速コピーが理論上可能。
- 課題：現時点では snapshot 間の Continuous Replication 機構が整っていない。
- 用途：インディペンデント構成（手動 snapshot 運用など）には適する。
qcow2 SR（現在はプロト実装）
- 構成：ファイルシステム(例：NFS)上に qcow2 を配置し、SMAPIv3 で管理する SR。
- 利点：ファイル単位での運用が可能で、可搬性が高く、Proxmox VEとのオフライン移行も視野に入る。
- 課題：現時点では snapshot/coalesce/replication の整備は試験的段階。
将来的な対応ストレージ
| 評価項目 | VHD | LVM | ZFS | Ceph RBD | qcow2 |
|---|---|---|---|---|---|
| Thin Provisioning | ○ | ✖️ | ○ | ○ | ○ |
| Snapshot 運用 | △（容量、IOリスク） | △（容量、IOリスク） | ○ | ○ | ○ |
| Continuous Replication | ○ | ○ | ✖️ | ✖️ | ✖️ |
| Merge 処理の安全性 | 中 | 低 | 高 | 高 | 中 |
| 障害時リカバリ容易性 | 高 | 低 | 中 | 中 | 高 |
| 容量限界時の予測性 | 中 | 低 | 高 | 高 | 高 |
補足事項
- SMAPIv3 では ZFSや、qcow2 SR 、Cephの試験実装が進行中です
- qcow2 に移行することで、より柔軟な snapshot 操作・大容量ディスク対応が可能になる見込み
- SMAPIv3の場合、ディスクイメージに「raw イメージ」が入ります。従ってメタ情報さえ保存できれば、理論上、Proxmox VEとxcp-ngでディスクコピー無しにオフラインマイグレーションが可能になりうることになります。
このテクニカルノートは、今後の HCI 戦略や Storage 拡張を進める上での設計方針に基づいて随時更新される予定です。InfiniCloud のマニュアルページにおいて、本記事は高度な構成理解を要する読者を対象とした上級テクニカルノートとして位置付けています。
