Snapshots em LVM Compartilhado no Proxmox VE 9: O Fim do Dilema da SAN

Snapshots em LVM Compartilhado no Proxmox VE 9: O Fim do Dilema da SAN

Se você gerencia infraestrutura virtualizada há tempo suficiente, conhece a dor visceral de configurar uma SAN robusta — seja iSCSI, Fibre Channel ou NVMe-oF —, apresentar o LUN ao cluster e, no momento de criar uma estratégia de proteção rápida, encontrar o botão "Snapshot" desabilitado na interface.

Durante anos, arquitetos de armazenamento no ecossistema KVM/Proxmox viveram sob uma dicotomia cruel: escolher entre a mobilidade e alta disponibilidade do armazenamento compartilhado (Shared LVM) ou a flexibilidade operacional dos snapshots (qcow2/ZFS local). O Proxmox VE 9 traz uma mudança arquitetural na camada de abstração de armazenamento que promete encerrar esse debate.

Vamos dissecar o que mudou na pilha de I/O, como as "Volume Chains" funcionam no backend e o impacto real na latência dos seus discos.

Resumo em 30 segundos

• O Fim do Bloqueio: O Proxmox VE 9 permite snapshots em LVM compartilhado (iSCSI/FC) sem a necessidade de sistemas de arquivos em cluster complexos como GFS2.
• Volume Chains: A mágica ocorre via QEMU gerenciando cadeias de volumes lógicos distintos, desacoplando o estado ativo do disco base, similar aos "delta files" do VMFS.
• Custo de I/O: Embora resolva a operação, cada nível de snapshot adiciona uma penalidade de leitura (read penalty) que exige armazenamento subjacente de baixa latência (All-Flash/NVMe).

O bloqueio histórico do botão de snapshot em iSCSI

Para entender a solução, precisamos respeitar o problema. Em um ambiente de armazenamento compartilhado tradicional, o LVM (Logical Volume Manager) atua como um gerenciador de mapas de blocos. Quando você usa iSCSI ou Fibre Channel, o array de armazenamento entrega um "block device" bruto. O LVM corta esse bolo em fatias (Logical Volumes) para as VMs.

O problema reside na coordenação de metadados. Um snapshot tradicional de LVM (cow) exige a atualização dos metadados do volume em tempo real. Em um cluster, se o Nó A tentar criar um snapshot enquanto o Nó B está escrevendo no volume, sem um mecanismo de travamento (locking) extremamente sofisticado, você corrompe o mapa de alocação. O resultado é perda de dados.

Por que o lvmlockd não permitia COW seguro em cluster

O lvmlockd (e seu antecessor clvm) foi projetado para gerenciar a ativação e desativação de volumes, garantindo que dois nós não montem o mesmo volume de forma conflitante. No entanto, ele não foi desenhado para gerenciar a granularidade de I/O necessária para snapshots LVM nativos em alta performance.

Os snapshots nativos do LVM sofrem de penalidades severas de desempenho porque cada escrita no volume original exige uma leitura do bloco antigo e uma escrita desse bloco na área de snapshot (Copy-On-Write clássico). Em um ambiente clusterizado, coordenar esse "pausa-copia-escreve" através da rede SAN introduz uma latência inaceitável, frequentemente causando timeouts no sistema operacional convidado (Guest OS).

⚠️ Perigo: Tentar forçar snapshots LVM legados em ambientes compartilhados via CLI (lvcreate -s) sem o suporte da plataforma quase sempre resulta em degradação de performance do cluster inteiro, pois o locking manager satura a rede de gerenciamento.

A falácia do GFS2 como solução mágica para datastores

Muitos administradores tentaram contornar a limitação do LVM formatando o LUN compartilhado com GFS2 (Global File System 2) ou OCFS2. A lógica era: "Se eu tiver um sistema de arquivos, posso usar arquivos .qcow2 e ter snapshots".

Embora tecnicamente verdade, essa abordagem transforma seu storage em um pesadelo de gerenciamento de Distributed Lock Manager (DLM). O GFS2 é excelente para servidores de arquivos ativos-ativos, mas péssimo para hospedar imagens de disco virtual.

Cada operação de metadados (alocar um novo bloco no disco virtual, criar um snapshot) exige que o cluster entre em acordo. Se um nó falhar ou a rede de corosync engasgar, o mecanismo de fencing entra em ação, muitas vezes reiniciando nós saudáveis para proteger a integridade do disco. Para armazenamento de VMs, a complexidade do GFS2 raramente compensa o benefício, adicionando camadas de latência desnecessárias.

Arquitetura de volume chains no Proxmox VE 9

O Proxmox VE 9 resolve isso movendo a lógica do snapshot para cima na pilha, saindo da camada de bloco do LVM e indo para a camada do hipervisor (QEMU/KVM), mas persistindo em volumes de bloco brutos.

Ao invés de pedir ao storage array ou ao LVM para criar um snapshot, o PVE 9 implementa Volume Chains (Cadeias de Volumes).

Fig. 1: A nova arquitetura de Volume Chains desacopla o estado ativo do volume base.

Fig. 1: A nova arquitetura de Volume Chains desacopla o estado ativo do volume base.

Como funciona o I/O path

Quando você clica em "Snapshot" em um Datastore LVM Compartilhado no PVE 9:

1. Congelamento (Quiesce): O QEMU pausa as escritas via agente convidado (QEMU Guest Agent) para garantir consistência do sistema de arquivos.

2. Criação do Delta: O PVE solicita ao LVM a criação de um novo Volume Lógico (LV) vazio, do mesmo tamanho ou thin-provisioned.

3. Redirecionamento: O arquivo de configuração da VM é atualizado. O disco "ativo" passa a ser esse novo LV.

4. Backing File: O novo LV aponta para o LV anterior como "Backing Image" (em termos lógicos do QEMU, mapeado para o block device).

A partir desse momento, todas as novas escritas vão para o novo LV. As leituras verificam o novo LV; se o bloco não existir lá, a leitura é redirecionada para o volume base (ou o snapshot anterior na cadeia).

Isso elimina a necessidade de travar os metadados do LVM para cada operação de escrita, pois o volume base se torna efetivamente "Read-Only" para aquela cadeia específica.

Impacto na latência de escrita e validação de migração

Essa arquitetura é muito similar ao que a VMware faz com os arquivos delta (-000001.vmdk) em VMFS. No entanto, aplicar isso em LVM bruto traz nuances de performance que o administrador de storage deve monitorar.

Latência de leitura (Read Amplification)

A física do disco não muda. Se você tiver uma cadeia de 5 snapshots, uma operação de leitura pode ter que percorrer 5 volumes lógicos diferentes para encontrar o bloco de dados correto.

💡 Dica Pro: Em arrays All-Flash ou NVMe, essa latência adicional é negligenciável para cadeias curtas (2-3 snapshots). Em HDDs rotacionais (Spinning Rust), isso pode destruir a performance de leitura aleatória (IOPS). Mantenha suas cadeias curtas.

Fig. 2: A física do disco não muda: snapshots externos reduzem a amplificação de escrita comparados ao COW tradicional.

Fig. 2: A física do disco não muda: snapshots externos reduzem a amplificação de escrita comparados ao COW tradicional.

O comportamento no vMotion (Live Migration)

A grande vitória do PVE 9 é manter a mobilidade. Como todos os volumes da cadeia (Base + Snaps) residem no Storage Compartilhado (SAN), a migração ao vivo de uma VM com snapshots é transparente.

O nó de destino simplesmente abre os descritores de arquivo para os mesmos LVs que o nó de origem estava usando. Não há cópia de dados de disco, apenas transferência de estado de memória RAM. Testes de validação mostram que o tempo de switchover (o "stun" da VM) permanece consistente, independentemente da profundidade da cadeia de snapshots, pois a complexidade está na resolução do caminho de I/O, não na movimentação de dados.

Consolidação de snapshots e limpeza

O perigo oculto dessa funcionalidade é o esquecimento. Diferente de um snapshot de array (que muitas vezes é baseado em ponteiros de metadados eficientes no controlador do storage), as Volume Chains ocupam espaço real e fragmentam o I/O lógico.

Quando você deleta um snapshot no PVE 9 (operação de "Commit" ou "Consolidate"), o sistema precisa ler os dados do volume delta e fundi-los no volume pai (ou base).

Essa operação é intensiva em I/O. Se feita durante o horário de pico em um storage array que já está saturado, você verá a latência de todas as VMs naquele datastore subir. O processo de block-commit do QEMU é eficiente, mas não é mágico; ele precisa mover bits.

Alerta Operacional

A chegada dos snapshots em LVM compartilhado no Proxmox VE 9 remove uma das últimas grandes barreiras para a adoção de storage block-level puro (iSCSI/FC) em detrimento de soluções mais complexas como Ceph ou NFS para certos workloads.

No entanto, minha recomendação é tratar essa funcionalidade como uma ferramenta de operação, não de retenção. Use snapshots para janelas de manutenção, atualizações de sistema ou testes rápidos. Não os utilize como substituto para backups diários ou retenção de longo prazo. A penalidade de leitura acumulada e o risco de corrupção de cadeia (se um volume intermediário for danificado) aumentam exponencialmente com o tempo.

O dilema da SAN acabou, mas a responsabilidade de gerenciar a física do armazenamento continua sendo sua.

Referências & Leitura Complementar

1. QEMU Disk Image Formats & Backing Chains - Documentação técnica sobre como o QEMU manipula overlays em dispositivos de bloco.

2. LVM2 Logical Volume Manager - Red Hat Enterprise Linux 9 Storage Administration Guide (foco em lvmlockd e ativação seletiva).

3. Virtio-blk Performance Tuning - Análise de latência em dispositivos de bloco virtualizados (OASIS Standard).

Perguntas Frequentes

1. Posso usar essa funcionalidade com iSCSI e Fibre Channel? Sim. Desde que o armazenamento seja apresentado ao Proxmox como um LVM Volume Group compartilhado, a funcionalidade de Volume Chains do PVE 9 é agnóstica ao protocolo de transporte (TCP/IP ou FC).

2. Isso substitui o uso de Ceph (RBD)? Não. O Ceph oferece resiliência distribuída e self-healing que uma SAN tradicional (mesmo com RAID) não replica da mesma forma. O LVM Compartilhado é ideal para quem já possui arrays de armazenamento enterprise (Dell PowerStore, HPE Alletra, Pure Storage) e quer aproveitá-los.

3. O que acontece se eu encher o storage enquanto tenho snapshots abertos? O comportamento é crítico. Se o Volume Group ficar sem espaço para alocar novos extents para o volume delta ativo, a VM pausará (IO Error/Pause) para evitar corrupção. O monitoramento de capacidade do VG é vital.

4. A performance é igual a um volume RAW sem snapshots? Não. Existe um overhead de metadados do QEMU para gerenciar a cadeia. Em testes com NVMe-oF, a degradação é inferior a 3-5% para o primeiro snapshot, mas pode escalar se a cadeia crescer. Para bancos de dados de altíssima performance, recomenda-se manter o disco "flat" (sem snapshots) ou usar snapshots baseados no array de storage (offloaded).