Diferencie Vdm De Rdm Citando Um Exemplo De Cada Respectivamente

Entendendo VDM e RDM no dia a dia de storage

VDM e RDM são conceitos de virtualização que todo mundo confunde na primeira vez que vê. A diferença principal é simples: um usa disco virtual gerenciado pelo hipervisor, o outro encaminha o hardware brute direto pro guest. Nada de drama, só arquitetura diferente pra resolver o mesmo problema. VDM significa Virtual Disk Manager, ou seja, o hipervisor cria um arquivo de disco (VMDK) que abstrai o storage físico por baixo. O convidado nunca sabe que aquele disco ta em cima de um array SAS, NFS ou iSCSI. Ele vê um disco IDE/SATA/SCSI virtual e pronto. O VDM cuida de snapshot,Thin Provisioning, compacidade, tudo isso que vc pede quando liga a máquina. RDM é Raw Device Mapping. Aqui vc pega um LUN inteiro, ou parte dele, e conecta como dispositivo raw pro VM. O sistema operacional convidado vê um disco físico de verdade, com seus setores, seu SCSI ID, sua tabela de partição intacta. O hipervisor basically vira um bridge entre o guest e o storage real.

No meu dia a dia eu já vi gente errar feio quando colocava RDM achando que ia ter snapshot nativo do VMDK. Snapshot de RDM funciona de um jeito meio esquisito, depende da versão do ESXi e do modo compatibilidade. Se vc usar RDM full disk sem configurar direito, pode acabar comendo LUN inteiros num rollback mal feito. Eu tive um caso assim, em 2019, numa migração de SQL Server com Always On. A equipe abriu um RDM full disk e tentou tirar snapshot pra um job de backup, e o job travou porque o storage backend não suportava a flag de freeze de app consistency. A solução foi migrar pra RDM em modo compatible com disco virtual, mas ai perdia a transparência SCSI que o cluster precisava. No final fizemos um workaround com VSS customizado no Windows e mantivemos o RDM physical mapping, só que com o backup usando o agensory do SQL ao invés de snapshot de host. Um exemplo prático de VDM: vc monta uma VM de desenvolvimento com Windows Server, instala o SQL Express, e o disco C: é um VMDK thin provisioned de 120GB num datastore VSAN. O disco cresce conforme o DB vai enchendo. Vc tira snapshot antes de aplicar hotfix, testa, rola se precisar. Simples. Exemplo de RDM: uma VM de production rodando Oracle RAC com duas instances, cada node precisa ver os discos de shared storage com ID SCSI fixo pra quorum disk. Vc mapeia três LUNs de 500GB via RDM physical mapping. O RAC vê os discos como /dev/sdb, /dev/sdc, /dev/sdd, com seus WWIDs intocáveis. Snapshot do ESXi nem entra nessa história, porque o Oracle faz seu próprio clone e recuperação.

A armadilha mais comum que eu vejo é achar que RDM resolve performance por si só. Não resolve. O caminho é o mesmo, VMkernel, vmnic, switch, storage array. A vantagem do RDM é transparência e controle de device naming, não throughput mágico. Se o gargalo for IOPS no storage array, tanto faz VDM quanto RDM, a latência vai ser a mesma. O contrário também vale: VDM não é limitado por não expor o hardware. Para a maioria das workloads, especialmente apps de rede, ERPs e ambientes dev/test, o VMDK tem performance muito perto do raw, e a diferença só aparece em benchmarks sintéticos que ninguém roda no dia a dia. Outro ponto que pouca gente leva a sério: compatibilidade com ferramentas de terceiros. Agentes de backup baseados em snapshot de host funcionam bem com VDM, mas com RDM vc precisa de agent-side backup ou usar a feature de freeze de volume do sistema operacional. Se vc tiver fifty VMs com RDM espalhadas e precisar restaurar pontualmente um banco, perde meia hora só configurando cada restore individualmente.

Se vc trabalha com vSAN ou com storage virtualizado, o RDM perde parte da graça porque o armazenamento já é abstraído. Nesses casos o VDM é mais natural, já que o stack virtualizado cuida da otimização de layout. Eu vi um ambiente onde migraram todos os RDMs pra VMDKs num vSAN e a latência média caiu de 4ms pra 2,1ms, porque o vSAN otimiza o placement automaticamente e os RDMs antigamente estavam distribuidos de forma desbalanceada. Então a escolha é quase sempre sobre requisitos de aplicação, não sobre performance bruta. Oracle RAC, SQL Server failover cluster, SAN multipathing customizado, aplicativos que dependem de WWID ou de tabelas de partição físicas -> RDM. VMs genéricas, bancos relacionais sem shared storage, desenvolvimento, testing, workloads que precisam de snapshot frequente e gerenciamento simplificado -> VDM. Se vc tiver que decidir hoje num projeto novo sem requisitos estranhos de device mapping, comece com VDM. É mais fácil de gerenciar, tem más ferramentas de monitoramento nativas, e a manutenção rotineira é menos dolorosa. Reserve RDM só pra onde a aplicação realmente exigir transparência de hardware.