Limitações do VDO / Virtual Disk Optimizer na pilha de armazenamento

Question

Bem, o RHEL 7.5 lançou um importante add-on, o VDO, que basicamente adiciona volumes compactados e duplicados com provisionamento thin, o que é ótimo e obteremos esses benefícios com derivativos e outras distribuições, já que a tecnologia foi adquirida Permabit e é open source.

De acordo com documentos oficiais ( link ) , há algumas considerações (seção "Posicionamento do VDO na pilha de armazenamento" do documento):

As a general rule, you should place certain storage layers under VDO and others on top of VDO: Under VDO:

• DM-Multipath, DM-Crypt, and software RAID (LVM or mdraid).
• On top of VDO: LVM cache, LVM Logical Volumes, LVM snapshots, and LVM Thin Provisioning.

Bem, porque é regra "geral" - não vejo problema com isso e está tudo bem. Em seguida, vemos o seguinte:

The following configurations are not supported:

• VDO on top of VDO volumes: storage → VDO → LVM → VDO
• VDO on top of LVM Snapshots
• VDO on top of LVM Cache
• VDO on top of the loopback device
• VDO on top of LVM Thin Provisioning
• Encrypted volumes on top of VDO: storage → VDO → DM-Crypt
• Partitions on a VDO volume: fdisk, parted, and similar partitions
• RAID (LVM, MD, or any other type) on top of a VDO volume

Isso é um pouco "assustador" e devemos estar cuidadosamente no design, porque parece que o seguinte não será "suportado:"

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

Note que o resultado final VDO / EXT4 está na VM, o LVM LV está diretamente conectado à VM e é semelhante a:

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

1. Isso é realmente problemático ou perigoso e não é suportado?
2. Por quê?

Criar tudo no dispositivo subjacente nem sempre é uma boa opção, mas não vejo uma explicação clara de por que temos essas limitações.

Talvez porque esses volumes VDO estejam expostos ao Host e ao Guest?

    

Answer 1

Qual é o objetivo de criar o VDO no topo do Thin LVM? O VDO já está thin provisioned e está trabalhando em blocos de 4kb.

VDO on top of VDO volumes: storage → VDO → LVM → VDO - does not make sence to deduplicate deduplicated data
VDO on top of LVM Snapshots - does not make sense to snapshot deduplicated data
VDO on top of LVM Cache - do you need to deduplicate caching, really?
VDO on top of LVM Thin Provisioning - as I said above, VDO is already thin device. Moreover, VDO itself will change the state to read only in case if there is no free space on underlying storage, while if you put VDO on top of the LVM thin, VDO will doesn't know that space is ended it will leads to possible data corruption
Encrypted volumes on top of VDO: storage → VDO → DM-Crypt - by design deduplication of encrypted data is not possible (obviously because encrypted data/device is require fully provisioned size)
RAID (LVM, MD, or any other type) on top of a VDO volume - why do you need to create a RAID groups for deduplicated objects?

Em relação ao seu cenário, apenas faça assim (o LVM deve ser redundante no nível físico) - armazenamento - > LVM PV - > LVM VG - > LVM LV - > VDO - > Armazenamento (na VM) - > EXT4 (na VM)

Eu coloco algumas VMs de teste em um cenário semelhante e tudo está funcionando bem.