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

Atualmente, usamos uma SAN iSCSI como armazenamento para vários servidores VMware ESXi. Estou investigando o uso de um destino 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 oferecer 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?

(Essa pergunta foi originalmente feita no SuperUser ; sinta-se à vontade para migrar as respostas aqui, se você souber).

Eu realmente recomendo que você dê uma olhada no ZFS, mas para obter um desempenho decente, você precisará escolher um dispositivo dedicado como um ZIL (Zent Intent Log) do ZFS. Basicamente, este é um dispositivo pequeno (alguns GB) que pode gravar extremamente rápido (IOPS de 20 a 100 K), permitindo que o ZFS confirme imediatamente que as gravações foram sincronizadas com o armazenamento, mas aguarde até 30 segundos para confirmar as gravações nos discos rígidos. sua piscina. Em caso de falha / interrupção, qualquer transação não confirmada no ZIL é repetida na montagem. Como resultado, além de um no-break, você pode querer uma unidade com uma fonte de alimentação / super capacitor interno, para que quaisquer E / Ss pendentes cheguem ao armazenamento permanente em caso de perda de energia. Se você optar por um dispositivo ZIL dedicado, as gravações poderão ter alta latência, levando a todos os tipos de problemas. Supondo que você não esteja interessado na Sun '

• DDRDrive X1 - SLC DDR2 + 4GB Flash de 4 GB em uma placa PCIe x1 projetada explicitamente para o uso do ZIL. As gravações vão para a RAM; em caso de perda de energia, sincroniza a RAM com a NAND em <60s, alimentado por um supercapacitor. (50.000 a 300.000 IOPS; US $ 2.000 diretos, US $ 1.500 para .edu)
• SSD Intel X25-E de 32 GB e 2,5 polegadas (SLC, mas sem supercap, 3300 IOPS de gravação); [$ 390 na Amazon] [11]
• SSD OCZ Vertex 2 Pro de 40 GB e 2,5 polegadas (supercap, mas MLC, IOPS de gravação de 20k a 50k); $ 435 @ Amazon .

Depois de configurar o OpenSolaris / Nexenta + ZFS, existem várias maneiras de mover blocos entre o OpenSolaris e o ESX boxen; o que é certo para você depende muito da infraestrutura existente (comutadores L3, placas de fibra) e de 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, você pode avaliar tudo o que possui hardware e escolher o seu favorito:

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

Se você não puder gastar US $ 500 em avaliação, teste com e sem o ZIL desativado para ver se o ZIL é um gargalo. (Provavelmente é). Não faça isso na produção . Não mexa ainda com a desduplicação do ZFS, a menos que você também tenha muita memória RAM e um SSD para L2ARC. Definitivamente, é bom depois de configurá-lo, mas você definitivamente tenta fazer alguns ajustes no NFS antes de jogar com desduplicação. Depois de saturar os links de 1-2 Gb, existem oportunidades de crescimento em 8gb FC, 10gigE e infiniband, mas cada um exige um investimento significativo, mesmo para avaliação.

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

Em nossos casos, estávamos comparando o desempenho do Linux com o Solaris (no Ultra-SPARC) e o NetApp; ambos retornaram resultados em termos de desempenho de maçãs para maçãs e em termos nebulosos de "engenheiros não reclamando quase tanto sobre 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 de fábrica. E como os sistemas Solaris e NetApp envolvidos eram mais antigos, poderia-se argumentar que os servidores Linux tinham todas as vantagens e ainda não conseguiram convencer.

Se você tiver tempo, valerá a pena experimentar um experimento para configurar o mesmo hardware com o OpenSolaris (agora que o Solaris é muito caro de usar), Linux e talvez uma variante do BSD ou dois, e executá-los. Se você conseguir criar algumas métricas de desempenho (contagens de E / S de disco em uma VM hospedada fora da loja, por exemplo), pode ser um artigo interessante ou um artigo da Internet. (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% em desempenho para VMs - e se seu aplicativo era sensível o suficiente para que isso fosse um problema, você não deveria estar virtualizando 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 alimentadas pelo iSCSI, principalmente da NetApp.

Estamos usando o OpenSolaris 2009/06 com uma configuração RAID 10 ZFS para fornecer NFS ao nosso servidor VMWare ESXi. Até agora, funciona bastante bem para as nossas necessidades. Estamos usando unidades do tipo SATA Raid (unidades Seagate ES.2 de 1 TB). Ainda temos alguns ajustes a serem feitos.

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

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

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

http://bugs.opensolaris.org/bugdatabase/view_bug.do?bug_id=6522017

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