ZFS e a Nova Matemática do Datacenter: Por Que Trocar RAID em Hardware + ESXi por Barebone + Proxmox Vai Além da Economia

Todo projeto de infraestrutura crítica esbarra na mesma pergunta em algum momento: vale a pena manter a arquitetura tradicional de virtualização — controladora RAID dedicada, hypervisor proprietário, licenciamento por núcleo — ou migrar para um modelo baseado em hardware simplificado e armazenamento definido por software?

Com a reestruturação de licenciamento da VMware sob a Broadcom, essa pergunta deixou de ser teórica. Mas reduzir essa decisão só à planilha de custo é subestimar o que realmente muda quando você troca RAID em hardware por ZFS. A diferença mais profunda não é o preço da controladora — é o que acontece no dia em que algo queima, e é o quanto essa arquitetura te deixa mais competitivo quando você revende infraestrutura para o cliente final.

Neste artigo, vamos além do óbvio: hardware, licenciamento, performance e segurança — e entramos em quatro pontos que raramente aparecem nessa comparação e que, na prática, pesam tanto ou mais que a economia direta: portabilidade do pool em caso de desastre, fim do lock-in com fabricante de controladora, capacidade real de crescer um pool já em produção, e o impacto direto na margem de quem revende virtualização como serviço.

O ponto de partida: duas arquiteturas, duas filosofias

Arquitetura tradicional (RAID em hardware + ESXi):
Uma controladora RAID dedicada (geralmente um chip Broadcom/LSI com processador próprio e cache com bateria ou supercapacitor) monta o array em nível de hardware. O hypervisor enxerga um único volume lógico e não tem visibilidade sobre os discos individuais. Os metadados do array são gravados em formato proprietário, legível apenas por controladoras compatíveis do mesmo fabricante — e, frequentemente, da mesma família de firmware.

Arquitetura ZFS (HBA + Proxmox):
Os discos são apresentados "crus" ao sistema operacional através de um HBA em modo IT (sem RAID embarcado), e o ZFS assume toda a responsabilidade de redundância, cache, compressão e verificação de integridade em nível de software, usando a CPU e a RAM do próprio servidor. Os metadados do pool ficam gravados nos próprios discos, em formato aberto, legível por qualquer sistema operacional com suporte a ZFS.

É exatamente essa última frase — metadados gravados nos discos, em formato aberto — que muda tudo o que vem a seguir.

1. Escalabilidade e recuperação de desastre: o pool é portátil, o servidor não é

Esse é, na minha experiência prática, o ponto mais subestimado da comparação — e o mais decisivo quando as coisas dão errado de verdade.

Num array RAID em hardware, o volume lógico só existe enquanto a controladora que o criou (ou uma compatível) estiver funcionando. Se a placa-mãe morre, se a controladora queima, ou se todo o servidor fica inutilizável por qualquer motivo físico (incêndio, surto elétrico, enchente, roubo), os dados ficam reféns de duas condições: encontrar uma controladora compatível e recriar exatamente a mesma configuração de array.

Com ZFS, o pool é uma unidade lógica autocontida. Se um servidor sai de operação, o procedimento de recuperação é literalmente:

1. Pegar os discos (ou os discos remanescentes, se o array tinha redundância);

2. Instalar em qualquer outro hardware com Proxmox, TrueNAS ou qualquer Linux/BSD com suporte a ZFS;

3. Rodar zpool import;

4. O pool volta a ficar online, com todos os datasets, snapshots e permissões intactos.

Não importa o fabricante, o modelo da placa-mãe ou a geração do processador do novo servidor. Isso transforma recuperação de desastre de "esperar logística de hardware específico" para "questão de minutos, com o hardware que você já tem disponível" — inclusive um servidor mais simples ou até uma workstation, temporariamente, até a operação normalizar.

Para operações que atendem clientes hospitalares e industriais, onde o SLA de disponibilidade é inegociável, essa capacidade de reimportar o pool em qualquer lugar não é um "bônus" — é redução direta de tempo de indisponibilidade em cenário de catástrofe, o que se traduz em menos multa contratual e menos risco reputacional.

2. Fim do lock-in de controladora: o custo escondido do RMA

Esse ponto conversa diretamente com o anterior, mas merece destaque próprio porque é um custo que raramente entra na planilha inicial — só aparece quando a controladora falha.

Quando uma controladora RAID em hardware queima, a reposição não é trivial:

• Normalmente é preciso o mesmo modelo, ou um compatível na mesma família de firmware, para que o array seja reconhecido corretamente;

• Fabricantes como Broadcom/LSI não têm estoque local amplo no Brasil — o lead time de importação ou de um revendedor autorizado pode levar dias, às vezes semanas;

• Enquanto isso, o servidor fica parado, ou você precisa correr atrás de uma solução de contorno (restaurar de backup em outro hardware, se houver, com todo o tempo que isso consome);

• Se a controladora específica saiu de linha, o problema piora — você pode ficar refém de mercado de reposição usada.

Com HBA + ZFS, esse risco praticamente desaparece. Um HBA em modo IT é uma peça muito mais commodity — qualquer HBA compatível (mesmo de outro fabricante) reconhece os discos e o zpool import faz o resto. Você pode inclusive manter um HBA reserva em estoque próprio a um custo muito menor do que manter uma controladora RAID sobressalente, e isso já é suficiente para eliminar o gargalo de logística do fabricante.

Na prática: você troca uma dependência de fornecedor específico, com lead time incerto, por uma peça padronizada de baixo custo que qualquer distribuidor de TI tem disponível — ou que você já tem na prateleira.

3. Crescimento do pool: expansão que o RAID tradicional não entrega de verdade

Esse ponto costuma passar despercebido até o dia em que o cliente pede mais espaço — e é uma das diferenças mais práticas no dia a dia de operação.

Em controladoras RAID de hardware, algumas linhas mais robustas até oferecem OCE (Online Capacity Expansion), mas na prática é um recurso limitado: normalmente exige adicionar discos em lote (não um disco isolado), o processo pode levar horas ou dias em arrays grandes, o array roda com resiliência reduzida durante toda a expansão, o nível de RAID fica travado, e nem toda controladora — ou firmware — suporta a operação de forma confiável. Por isso, na prática, a maioria das operações trata "expandir array" como sinônimo de "destruir e recriar do zero com os discos novos", restaurando tudo do backup.

Com ZFS, existem hoje dois caminhos de crescimento, e nenhum deles exige destruir o pool:

• Adicionar um novo vdev ao pool (zpool add): sempre foi possível — você soma um novo grupo de discos (outro RAIDZ, outro mirror) ao pool existente, expandindo a capacidade total instantaneamente, sem tocar nos dados já gravados. É o método mais usado e mais seguro em produção.

• Expandir um vdev RAIDZ existente disco a disco (zpool attach): desde o OpenZFS 2.3 — já presente nas versões atuais do Proxmox — é possível anexar um único disco novo a um vdev RAIDZ já existente e expandir sua capacidade sem precisar de um conjunto completo de discos novos. Vale o alerta técnico: os dados já gravados antes da expansão continuam usando a proporção antiga de paridade até serem reescritos, então o ganho de espaço pleno aparece de forma gradual — mas a operação em si acontece com o pool online e sem destruir nada.

Também é possível crescer trocando disco por disco por unidades maiores (zpool replace + autoexpand=on), deixando o pool assumir a capacidade adicional automaticamente assim que todos os discos de um vdev forem substituídos — uma estratégia de upgrade incremental que RAID em hardware simplesmente não oferece com a mesma flexibilidade.

Na prática operacional, isso significa que o crescimento de um ambiente ZFS acompanha o crescimento do cliente sem forçar uma parada extensa nem uma reconstrução completa do storage — algo que, no modelo tradicional, normalmente vira projeto de migração à parte.

4. Hardware: quanto custa a mudança em si

Em clusters com múltiplos nós — como ambientes multirregião com nós distribuídos entre diferentes datacenters — essa economia se multiplica linearmente, e ainda reduz o número de peças proprietárias que precisam ser mantidas em estoque de reposição.

5. Licenciamento: onde está o maior impacto financeiro recorrente

A migração de clientes para Proxmox em 2025 e 2026 tem sido impulsionada quase inteiramente pela reestruturação de licenciamento da VMware promovida pela Broadcom: fim das licenças perpétuas, pacotes de assinatura obrigatórios e contagem mínima de núcleos por CPU, que multiplicaram os custos de muitas operações de médio porte em uma faixa de 3 a 10 vezes.

Do outro lado, o modelo do Proxmox é radicalmente mais simples. O software em si é gratuito e sem limitação de núcleos, VMs ou nós de cluster. A assinatura é opcional e cobrada por soquete físico de CPU ocupado, não por núcleo:

O detalhe mais relevante para quem está migrando servidores com processadores modernos de alta densidade: uma CPU com 32, 64 ou até 128 núcleos continua sendo licenciada como um único soquete. É o oposto exato do modelo por núcleo que encareceu o licenciamento tradicional — e na prática favorece justamente os servidores mais robustos, que são os que mais interessam para consolidação de workloads hospitalares e industriais.

Estimativa prática: dependendo do tier de suporte contratado no Proxmox e da configuração de núcleos que o cliente tinha licenciada anteriormente, a economia em licenciamento anual costuma ficar entre 60% e 85% frente a um contrato vSphere equivalente pós-reestruturação.

6. O ângulo que mais importa para quem revende infraestrutura: margem

Se você olha isso puramente como cliente final, a conta já fecha. Mas se você constrói infraestrutura para revender — IaaS, VPS, colocation com serviço gerenciado — o efeito é multiplicado, porque cada real economizado em CAPEX e em licenciamento vira margem disponível para competir em preço sem sacrificar rentabilidade.

O mercado de nuvem no Brasil está cada vez mais competitivo, com provedores internacionais pressionando preço agressivamente. Nesse cenário, o custo-base da sua infraestrutura é o que determina até onde você consegue descer o preço final sem operar no vermelho. Uma stack baseada em barebone + Proxmox + ZFS, comparada a uma stack tradicional com RAID em hardware + hypervisor licenciado por núcleo, tipicamente resulta em:

• CAPEX por nó menor (economia de hardware detalhada acima), o que reduz o payback de cada servidor novo colocado em produção;

• OPEX de licenciamento drasticamente menor, o que é especialmente relevante quando você está precificando um contrato recorrente de longo prazo para o cliente final;

• Menor exposição a risco operacional (recuperação mais rápida, sem lock-in de fornecedor), o que reduz custo de SLA e de contingência que normalmente precisa ser embutido no preço;

• Backup nativo gratuito via Proxmox Backup Server, reduzindo mais uma linha de custo recorrente que normalmente seria repassada ao cliente ou absorvida na margem.

Na prática, isso significa que a mesma qualidade de serviço — ou até superior, dado o ganho de integridade de dados do ZFS — pode ser oferecida com um preço mais competitivo, sem comprimir a margem da operação. É a diferença entre competir por preço "queimando margem" e competir por preço porque a base de custo realmente é menor.

7. Performance: não é uma vitória unilateral

Seria desonesto apresentar o ZFS como estritamente mais rápido — a realidade depende de dimensionamento correto.

Vantagens do ZFS:

• ARC (Adaptive Replacement Cache): usa a RAM do host como cache de leitura de forma muito mais agressiva e inteligente do que o cache limitado de uma controladora RAID.

• Compressão inline (lz4): quase sempre compensa o custo de CPU, reduzindo o volume real de I/O em disco.

• Copy-on-write: elimina o "write hole" clássico do RAID 5/6, onde uma queda de energia no meio de uma escrita pode corromper todo o stripe.

Pontos de atenção:

• ZFS consome CPU (checksum, compressão) e exige RAM dedicada — regra prática de aproximadamente 1 GB de RAM por TB de armazenamento, mais ainda se deduplicação for habilitada (recomendamos evitar dedup em produção na maioria dos casos).

• Um HBA sem cache de escrita própria pode penalizar cargas com muitas escritas síncronas — típico de bancos de dados Oracle — a menos que se adicione um dispositivo SLOG dedicado em NVMe ou Optane.

• Em arrays muito cheios, o resilver (reconstrução) do ZFS pode ser mais lento que um rebuild de RAID em hardware, embora as versões recentes do OpenZFS tenham avançado bastante nesse ponto.

Recomendação de arquitetura: nunca colocar uma controladora RAID em modo hardware por trás do ZFS — isso mascara o acesso direto aos discos que o ZFS precisa para funcionar corretamente. O caminho correto é sempre HBA em modo IT, com SLOG dedicado quando o workload exigir baixa latência de escrita síncrona.

8. Segurança e integridade de dados

Se em performance o resultado é "depende do dimensionamento", em integridade de dados a vantagem do ZFS é inequívoca:

• Checksum de ponta a ponta em cada bloco: RAID em hardware tradicional não detecta corrupção silenciosa de dados (bit rot). O ZFS detecta e, havendo redundância, se autocorrige durante um scrub programado.

• Eliminação do write hole: o design copy-on-write do RAIDZ evita a janela de corrupção presente no RAID 5/6 tradicional em caso de queda de energia durante uma escrita.

• Snapshots nativos: instantâneos, praticamente sem custo de espaço no momento da criação (graças ao COW) — um diferencial enorme para estratégias de backup e recuperação de desastre.

• Sem dependência de hardware proprietário: como já detalhado, a recuperação não depende de controladora compatível — reforçando o mesmo ponto de portabilidade sob outro ângulo, agora o de integridade sob falha.

Para operações que lidam com bases Oracle, sistemas PACS de imagem médica ou qualquer workload onde corrupção silenciosa é inaceitável, esse argumento de integridade tende a pesar tanto quanto — ou mais que — a economia financeira, especialmente em auditorias de compliance.

Conclusão: uma decisão de arquitetura, não só de custo

A migração de RAID em hardware + ESXi para barebone + Proxmox com ZFS não é apenas uma forma de cortar custos — embora a economia combinada em hardware e licenciamento normalmente já justifique o projeto por si só. É uma mudança estrutural em quatro frentes que se reforçam mutuamente:

1. Resiliência operacional real, porque o pool de dados não está preso a um hardware específico e pode ser recuperado em qualquer lugar, em minutos;

2. Independência de fornecedor, porque uma peça de reposição commodity substitui a dependência de um lead time incerto de controladora proprietária;

3. Crescimento sem trauma, porque o pool acompanha a expansão do cliente sem exigir destruição e reconstrução completa do storage;

4. Competitividade de mercado, porque uma base de custo menor se traduz diretamente em margem disponível para quem revende infraestrutura, num mercado de nuvem cada vez mais pressionado por preço.

Como sempre reforçamos nos projetos de migração que conduzimos: a governança da infraestrutura deve vir antes da escolha de tecnologia. O ZFS não é a resposta certa para todo cenário, mas para quem já paga o preço do licenciamento tradicional, quer previsibilidade orçamentária, resiliência real contra desastre e margem para competir — a conta fecha em todas as frentes.

A Nyverra conduz migrações de VMware/ESXi para Proxmox com arquitetura ZFS, incluindo dimensionamento de hardware, planejamento de storage e migração assistida de workloads críticos. Fale com nosso time para uma análise de viabilidade do seu ambiente.