Storage externo no Proxmox: NFS, iSCSI e Fibre Channel sem surpresa

Nem todo mundo que vai para o Proxmox quer montar storage definido por software. Uma parcela grande já tem um storage array em operação, dentro do ciclo de depreciação, com suporte vigente — e a pergunta certa não é "devo trocar por Ceph?", é "como conecto o que eu já tenho, sem perder recursos importantes no caminho?".

O Proxmox conecta bem nos três protocolos clássicos. O que muda entre eles não é só desempenho: muda o que você consegue fazer com snapshot, com thin provisioning e com backup, e essa é a parte que pega gente desprevenida depois da migração.

A distinção que explica tudo: bloco ou arquivo

Antes dos protocolos, um conceito. Storage entregue ao Proxmox vem de duas formas:

• Nível de arquivo (NFS, CIFS): o storage entrega um sistema de arquivos. O Proxmox grava arquivos de disco de VM dentro dele, normalmente no formato qcow2.
• Nível de bloco (iSCSI, Fibre Channel): o storage entrega um dispositivo bruto. O Proxmox precisa colocar alguma estrutura por cima para dividir esse bloco entre várias VMs — e essa estrutura, normalmente, é o LVM.

Essa diferença é a origem da maior surpresa pós-migração, e ela merece uma seção própria.

A surpresa do snapshot

Quem vem do VMware está acostumado a snapshot de VM em qualquer datastore. No Proxmox com storage de bloco, isso muda.

Leia a linha do meio com atenção, porque é a combinação mais comum em quem migra de storage array: iSCSI ou Fibre Channel com LVM compartilhado não suporta snapshot de VM. O disco é raw sobre volume lógico, e não há camada que guarde o estado anterior.

O LVM-thin resolve snapshot e thin provisioning, mas não é compartilhável entre nós — o que significa que você perde a migração ao vivo simples e o failover de HA sobre aquele storage. Não é um meio-termo utilizável em cluster.

Isso não é defeito do Proxmox; é característica do modelo. Mas precisa ser descoberto no planejamento, não no dia em que alguém vai tirar um snapshot antes de uma atualização crítica e o botão está indisponível.

As saídas, quando você precisa de snapshot com storage de bloco:

• Usar NFS em vez de iSCSI, se o array oferece os dois. É a solução mais simples e a que mais recomendamos nesse cenário.
• Usar o snapshot do próprio array, no nível do LUN, orquestrado fora do Proxmox. Funciona, mas não é por VM e não aparece no painel.
• Aceitar não ter snapshot de VM e compensar com backup frequente no PBS, que continua funcionando normalmente e cobre o caso de uso real (reverter uma mudança) com alguns minutos a mais.

NFS: o mais simples, e quase sempre suficiente

Configuração de poucos minutos: endereço do servidor, caminho exportado, pronto. É compartilhado entre todos os nós, suporta snapshot com qcow2, suporta thin provisioning e permite migração ao vivo sem esforço.

Onde exige cuidado:

• Versão do protocolo. Use NFS versão 4.1 ou superior quando o array suportar; o tratamento de travas e recuperação de sessão é melhor.
• Rede dedicada. Tráfego de storage não divide interface com tráfego de VM. 10 Gbps é o piso realista.
• Opções de montagem. Os parâmetros de tempo limite e de comportamento em indisponibilidade decidem o que acontece quando o array trava: VM congelada esperando indefinidamente, ou erro de I/O. Nenhuma das duas é agradável, e a escolha precisa ser consciente.
• Ponto único de falha. Servidor NFS sem redundância é o SPOF da sua virtualização inteira. Se o array não tem controladora dupla e caminho redundante, você moveu o problema em vez de resolvê-lo.

Para a maioria dos ambientes de porte pequeno e médio com array existente, NFS é a resposta certa. Simplicidade tem valor operacional real.

iSCSI: bloco sobre a rede que você já tem

Entrega LUN pela rede Ethernet. Vantagem sobre Fibre Channel: não exige switch nem placa especializada.

O que precisa estar certo:

• Rede exclusiva para o tráfego iSCSI, em VLAN separada, idealmente em switches próprios.
• Jumbo frames, configurados de ponta a ponta — placa, switch e array. Configurar em parte do caminho é pior que não configurar, porque gera fragmentação e desempenho errático de diagnóstico difícil.
• Multipath, com no mínimo dois caminhos por switches diferentes. É o que dá redundância de verdade; sem ele, iSCSI tem ponto único de falha na rede.
• Desabilitar controle de fluxo ou configurá-lo de forma coerente entre os equipamentos — é fonte clássica de lentidão intermitente.
• LVM por cima, com a consequência de snapshot já discutida.

O erro mais comum em iSCSI não é de configuração do Proxmox: é apresentar o mesmo LUN a vários nós sem o LVM compartilhado gerenciando o acesso. Dois nós escrevendo em um sistema de arquivos não-clusterizado no mesmo LUN corrompem o dado rapidamente. O Proxmox faz isso corretamente quando você configura o storage como LVM sobre iSCSI; o problema aparece em improviso manual.

Fibre Channel: quando já existe a malha

Se a empresa já tem malha FC, switches e HBAs, o Proxmox trabalha bem sobre ela. O sistema enxerga os dispositivos e você monta o LVM por cima, exatamente como no iSCSI.

Pontos de atenção:

• Compatibilidade de HBA. Verifique o modelo antes. É o item que mais gera retrabalho.
• Zoneamento e mapeamento corretos no switch e no array, com todos os nós enxergando os mesmos LUNs.
• Multipath, novamente, e aqui com atenção à configuração específica do fabricante do array — cada um tem suas recomendações de política de balanceamento e de detecção de caminho.
• Firmware de HBA e switch atualizados e compatíveis entre si.

FC entrega latência baixa e previsível e isolamento do tráfego Ethernet. Não entrega snapshot de VM, pela mesma razão do iSCSI.

Multipath: o detalhe que separa redundante de aparentemente redundante

Vale insistir, porque é o erro mais caro dessa área.

Ter duas placas e dois switches não dá redundância sozinho. É o multipath que agrupa os caminhos e decide o que fazer quando um cai. Sem ele configurado corretamente, o sistema enxerga o mesmo LUN duas vezes como se fossem dois dispositivos distintos — e isso é pior que ter um caminho só.

O teste que prova o desenho, e que deve ser feito antes de colocar carga real:

1. Com VMs rodando e gerando I/O, desconecte um cabo.
2. Verifique se o I/O continua, e por quanto tempo houve pausa.
3. Reconecte e confirme que o caminho volta ao conjunto ativo.
4. Repita pelo outro caminho.
5. Reinicie uma controladora do array, se ele permite, e observe.

Se alguma dessas etapas interrompe as VMs, a redundância é nominal. Melhor descobrir com carga de teste.

Misturar storages é normal e recomendável

Ambiente maduro raramente tem um storage só. Um desenho que funciona bem:

• Array existente por NFS para as VMs de produção que precisam de snapshot e migração ao vivo.
• ZFS local em cada nó para cargas de alto I/O que não precisam migrar, com replicação entre nós.
• NFS separado ou datastore do PBS para backup, obrigatoriamente em equipamento diferente do storage de produção.
• Diretório local para imagens ISO e templates.

O ponto não negociável é o terceiro: backup nunca no mesmo equipamento que o dado de produção. É a regra que transforma falha de storage em incidente recuperável.

Erros comuns

• Migrar para iSCSI ou FC e descobrir depois que perdeu snapshot de VM.
• Usar LVM-thin em cluster achando que é compartilhável.
• Tráfego de storage na mesma interface do tráfego de VM.
• Jumbo frames configurados em parte do caminho.
• Multipath ausente ou mal configurado, com o mesmo LUN visto duas vezes.
• Nunca testar a queda de um caminho com carga real.
• Apresentar o mesmo LUN a vários nós fora do modelo suportado.
• Servidor NFS único, sem redundância, virando o SPOF do ambiente.
• Opções de montagem NFS no padrão, sem decidir o comportamento em indisponibilidade.
• Backup no mesmo array do dado de produção.
• Não verificar compatibilidade de HBA antes de comprar ou migrar.

Como decidir

Três perguntas resolvem a maior parte dos casos:

1. Preciso de snapshot de VM? Se sim e o array oferece NFS, use NFS.
2. Já existe malha FC madura e em suporte? Se sim, use-a e planeje o backup para cobrir a ausência de snapshot.
3. Vou renovar o hardware em breve? Se sim, vale avaliar Ceph com os próprios nós antes de comprar outro array — o TCO costuma surpreender, e é uma conta que merece ser feita com números reais.

Onde a Solvefy/Cloud entra

Como parceiros oficiais Proxmox, conectamos o storage que você já tem — NFS, iSCSI ou Fibre Channel — com multipath configurado e testado, rede de storage separada, parâmetros de montagem definidos conforme o comportamento que você quer em falha, e o desenho de snapshot e backup ajustado ao que o protocolo escolhido permite. Também fazemos o comparativo com Ceph quando há renovação de hardware à vista, com os números do seu ambiente.

Vai migrar para Proxmox com o storage que já tem? Fazemos um diagnóstico gratuito da infraestrutura, sem compromisso, em solvefy.cloud.

Solvefy/Cloud — Infraestrutura que cresce com você.