ストレージスタックでのVDO /仮想ディスクオプティマイザーの制限

Question

まあ、RHEL 7.5は重要なアドオンVDOでリリースされました。これは基本的にシンプロビジョニングされた圧縮ボリュームと重複排除ボリュームを追加します。これは素晴らしいことです。テクノロジーはPermabitから取得され、オープンソース。

公式ドキュメント（ https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/7/html/storage_administration_guide/vdo-qs-requirements ）によると、いくつかの考慮事項があります（ "PlacementドキュメントのVDOの「ストレージスタック」セクション）：

generalルールとして、VDOの下に特定のストレージレイヤーを配置し、他のストレージレイヤーをVDOの上に配置する必要があります。

VDOの下：DM-Multipath、DM-Crypt、およびソフトウェアRAID（LVMまたはmdraid）。

VDOの上に：LVMキャッシュ、LVM論理ボリューム、LVMスナップショット、LVMシンプロビジョニング。

まあ、それは「一般的な」ルールだからです-私はそれに問題がないと思います、そしてすべては大丈夫です。次に、以下が表示されます。

次の構成はサポートされていません。

VDOボリューム上のVDO：ストレージ→VDO→LVM→VDO

LVMスナップショットの上にあるVDO

LVMキャッシュ上のVDO

ループバックデバイス上のVDO

LVMシンプロビジョニング上のVDO

VDO上の暗号化ボリューム：ストレージ→VDO→DM-Crypt

VDOボリューム上のパーティション：fdisk、parted、および同様のパーティション

VDOボリューム上でのRAID（LVM、MD、またはその他のタイプ）

これはちょっと「怖い」ので、次のようなものは「サポートされない」ように見えるので、慎重に設計する必要があります。

storage -> LVM PV -> LVM VG -> LVM Thin -> LVM LV -> Storage (in VM) -> VDO (in VM) -> EXT4 (in VM)

VDO/EXT4の最終結果はVMにあり、LVM LVはVMに直接接続されており、次のようになります。

storage -> LVM PV -> LVM VG -> LVM Thin -> LVM LV -> VDO -> Storage (in VM) -> EXT4 (in VM)

これは本当に問題があるのか、危険なのか、サポートされていませんか？
どうして？

基盤となるデバイスですべてを作成することは必ずしも良い選択肢ではありませんが、なぜこれらの制限があるのか明確な説明はありません。

これらのVDOボリュームがホストとゲストの両方に公開されるためでしょうか？

Strepsils · Answer

Thin LVMの上にVDOを作成するポイントは何ですか？ VDOはすでにシンプロビジョニングされており、4kbブロックで動作しています。

VDOボリュームの上にあるVDO：ストレージ→VDO→LVM→VDO-重複排除されたデータの重複排除は行わない
LVMスナップショットの上のVDO-重複排除されたデータのスナップショットには意味がありません
LVMキャッシュの上にあるVDO-本当に重複排除キャッシュが必要ですか？
LVMシンプロビジョニング上のVDO-前述のとおり、VDOはすでにシンデバイスです。さらに、VDO自体は、基礎となるストレージに空き容量がない場合にのみ読み取り状態に変更しますが、VDOをLVMシンの上に配置すると、VDOは容量が終了したことを認識しないため、可能になります。データ破損
VDOの上の暗号化ボリューム：ストレージ→VDO→DM-Crypt-設計により、暗号化データの重複排除は不可能です（明らかに、暗号化データ/デバイスは完全にプロビジョニングされたサイズを必要とするため）RAID（LVM、MD、またはその他のタイプ）VDOボリュームの上-重複排除されたオブジェクト用にRAIDグループを作成する必要があるのはなぜですか？

シナリオに関しては、次のようにしてください（LVMは物理レベルで冗長でなければなりません）。
ストレージ→LVM PV→LVM VG→LVM LV→VDO→ストレージ（VM内）→EXT4（VM内）

私はいくつかのテストVMを同様のシナリオに置き、すべてがうまく機能しました。