Melhores opções de sistema de arquivos para o NFS armazenando imagens de disco VMware

Question

Atualmente, usamos uma SAN iSCSI como armazenamento para vários servidores VMware ESXi. Estou investigando o uso de um destino do NFS em um servidor Linux para máquinas virtuais adicionais. Também estou aberto à idéia de usar um sistema operacional alternativo (como o OpenSolaris) se ele fornecer vantagens significativas.

Qual sistema de arquivos baseado em Linux favorece arquivos contíguos muito grandes (como imagens de disco do VMware)? Como alternativa, como as pessoas encontraram o ZFS no OpenSolaris para esse tipo de carga de trabalho?

(Esta questão foi originalmente perguntada no SuperUser ; sinta-se à vontade para migrar as respostas aqui, se você souber como).

    

Answer 1

Eu realmente recomendo que você dê uma olhada no ZFS, mas para obter um desempenho decente, você precisará escolher um dispositivo dedicado como um ZBI Intent Log (ZIL). Basicamente, este é um dispositivo pequeno (alguns GB) que pode gravar extremamente rápido (20-100 K IOPS) que permite que o ZFS confirme imediatamente que as gravações foram sincronizadas com o armazenamento, mas espere até 30 s para realmente confirmar as gravações nos discos rígidos. sua piscina. Em caso de falha / interrupção, qualquer transação não confirmada no ZIL será repetida durante a montagem. Como resultado, além de um no-break, você pode querer um inversor com uma fonte de alimentação interna / supercondensador para que qualquer pedido pendente possa ser armazenado permanentemente em caso de perda de energia. Se você optar por um dispositivo ZIL dedicado, as gravações podem ter alta latência, levando a todos os tipos de problemas. Assumindo que você não está interessado no SSD "Logzilla" de 18 GB da Sun, a ~ $ 8200, existem algumas alternativas mais baratas:

• DDRDrive X1 - Flash SLC de 4 GB DDR2 + 4 GB em uma placa PCIe x1 projetada explicitamente para uso com o ZIL. Escreve para a RAM; no caso de perda de energia, sincroniza RAM para NAND em < 60seg, alimentado por um supercapacitor. (50k-300k IOPS; $ 2000 Direct, $ 1500 para .edu)
• SSD Intel X25-E 32GB de 2,5 polegadas (SLC, mas sem super cap, 3300 write IOPS); [$ 390 @ Amazon] [11]
• OCZ Vertex 2 Pro 40 GB SSD de 2,5 polegadas (supercap, mas MLC, 20k-50k para gravação de IOPS); $ 435 @ Amazon .

Uma vez que você tenha a configuração OpenSolaris / Nexenta + ZFS, existem algumas maneiras de mover blocos entre o OpenSolaris e o ESX boxen; o que é certo para você depende muito da sua infraestrutura existente (switches L3, cartões de fibra) e suas prioridades (redundância, latência, velocidade, custo). Mas, como você não precisa de licenças especializadas para desbloquear a funcionalidade iSCSI / FC / NFS, é possível avaliar qualquer coisa para a qual você possui hardware e escolher o seu favorito:

• Alvos iSCSI (sobrecarga de CPU; sem suporte a TOE no OpenSolaris)
• Alvos de canal de fibra (cartões de fibra não são baratos)
• NFS (VMWare + NFS pode ser complicado, limitado a 32 montagens)

Se você não puder gastar US $ 500,00 para avaliação, teste com e sem ZIL desativado para ver se o ZIL é um gargalo. (Provavelmente é). Não faça isso em produção . Não mexa com a desduplicação do ZFS, a menos que você também tenha muita memória RAM e um SSD para o L2ARC. É definitivamente legal quando você o instala, mas você definitivamente tenta fazer um NFS Tuning antes de jogar com a dedup. Uma vez que você consiga saturar links de 1-2 Gb, há oportunidades de crescimento em 8gb FC, 10gigE e infiniband, mas cada um requer um investimento significativo, mesmo para avaliação.

    

Answer 2

Sou um grande fã de datastores do NFS para VMware, a NetApp tem uma excelente implementação.

O

TR-3808 compara a escala dos datastores compartilhados conectados ao NetApp FC, iSCSI e NFS, que é uma excelente leitura.

    

Answer 3

Eu não faria exatamente isso. Na minha experiência, o Linux (especificamente o CentOS 3/4/5) é geralmente uma má escolha para um servidor NFS. Eu tive vários e achei que sob carga, latência e throughput tendem a cair por razões que nunca conseguimos entender.

Em nossos casos, comparamos o desempenho do Linux back-to-back com o Solaris (no Ultra-SPARC) e com o NetApp; ambos retornaram resultados em termos de desempenho de comparação e em termos nebulosos de "engenheiros não reclamando tanto da latência quando o servidor estava sob carga". Houve várias tentativas de ajustar o servidor Linux NFS; os sistemas NetApps e Solaris foram executados como estão fora da caixa. E como os sistemas Solaris e NetApp envolvidos eram mais antigos, os servidores Linux poderiam ter tido todas as vantagens e ainda não conseguiram ser convincentes.

Se você tiver tempo, seria um experimento valioso configurar o mesmo hardware com o OpenSolaris (agora que o Solaris é muito caro para usar), o Linux e talvez uma variante BSD ou dois, e executá-los. Se você puder criar algumas métricas de desempenho (contagens de E / S de disco em uma VM hospedada fora da loja, por exemplo), isso poderá resultar em um white paper ou artigo da Internet interessante. (Se você tiver tempo.)

Em relação ao NFS em geral, o pessoal da NetApp me disse várias vezes que seus benchmarks mostravam que o NFS só tinha um custo de 5 a 10% no desempenho para VMs - e se seu aplicativo era sensível o suficiente para que isso fosse um problema, você não deveria t virtualizar isso em primeiro lugar.

Mas devo confessar que, depois de todo esse tempo e lágrimas, nossas lojas de VM de produção não local são todas alimentadas pelo iSCSI, principalmente da NetApp.

    

Answer 4

Estamos usando o OpenSolaris 2009/06 com uma configuração RAID 10 ZFS para fornecer o NFS ao nosso servidor VMWare ESXi. Funciona muito bem para as nossas necessidades até agora. Estamos usando unidades do tipo SATA Raid (unidades Seagate ES.2 1TB). Ainda temos alguns ajustes para fazer no entanto.

    

Answer 5

Você pode querer considerar o bug de 3+ anos com o ZFS ARC que ainda persiste antes de se aprofundar muito no ZFS ...

link

(Este é desagradável, pois também vai sair dos limites da VM de um hipervisor!)