Disk IO lento no ESXi, ainda mais lento em uma VM (freeNAS + iSCSI)

5

Eu tenho um servidor com ESXi 5 e armazenamento de rede conectado por iSCSI. O servidor de armazenamento possui discos SATA II de 4x1Tb no Raid-Z no freenas 8.0.4. Essas duas máquinas são conectadas umas às outras com Gigabit ethernet, isoladas de todo o resto. Não há alternância entre eles. A caixa SAN em si é um servidor supermicro de 1U com um Intel Pentium D a 3 GHz e 2 Gigs de memória. Os discos estão conectados a um controlador integrado (algo da Intel?).

O volume raid-z é dividido em três partes: dois zvols, compartilhados com iscsi e um diretamente sobre zfs, compartilhados com nfs e similares.

Eu ssh'd na caixa freeNAS, e fiz alguns testes nos discos. Eu usei dd para testar a terceira parte dos discos (diretamente em cima do ZFS). Eu copiei um bloco de 4GB (2x a quantidade de RAM) de / dev / zero para o disco, e a velocidade era de 80MB / s.

Outro dos zvols compartilhados do iSCSI é um datastore para o ESXi. Eu fiz teste similar com time dd .. lá. Como o dd não deu a velocidade, dividi a quantidade de dados transferidos pelo tempo mostrado por time . O resultado foi cerca de 30-40 MB / s. Isso é cerca de metade da velocidade do host freeNAS!

Depois, testei o IO em uma VM em execução no mesmo host ESXi. A VM era uma máquina leve do CentOS 6.0, que na verdade não estava fazendo mais nada. Não havia outras VMs em execução no servidor no momento e as outras duas "partes" da matriz de disco não foram usadas. Um teste semelhante de dd me deu um resultado de cerca de 15-20 MB / s. Isso é novamente cerca de metade do resultado em um nível inferior!

É claro que há alguma sobrecarga no raid-z - > zfs - > zvolume - > iSCSI - > VMFS - > VM, mas não espero que seja tão grande. Eu acredito que deve haver algo errado no meu sistema.

Eu ouvi falar sobre o mau desempenho do iSCSI do freeNAS, é isso? Eu não consegui obter qualquer outro SAN grande "grande" para executar na caixa (NexentaSTOR, openfiler).

Você pode ver algum problema óbvio com minha configuração?

    
por Esa Varemo 11.06.2012 / 00:12

5 respostas

5

Para acelerar isso, você precisará de mais RAM. Eu começaria com essas melhorias incrementais.

Primeiramente, acelere o sistema de arquivos: 1) O ZFS precisa de muito mais RAM do que o uso do cache do ARC. Quanto mais melhor. Se você pode aumentá-lo pelo menos 8GB ou mais, então você deve ver uma grande melhoria. Nós temos 64GB neles.

2) Em seguida, eu adicionaria um disco ZIL Log, ou seja, uma pequena unidade SSD de cerca de 20 GB. Use um tipo SLC em vez de MLC. A recomendação é usar 2 discos ZIL para redundância. Isso irá acelerar gravações tremendamente.

3) Adicione um disco L2ARC. Isto pode consistir num SSD de bom tamanho, e. um drive MLC de 250GB seria adequado. Tecnicamente falando, um L2ARC não é necessário. No entanto, geralmente é mais barato adicionar uma grande quantidade de armazenamento SSD rápido do que a RAM principal. Mas, comece com o máximo de memória RAM que você puder armazenar / pagar primeiro.

Existem vários sites em torno dessa afirmação para ajudar no ajuste do zfs em geral, e esses parâmetros / variáveis podem ser definidos através da GUI. Vale a pena investigar / tentar.

Além disso, consulte os fóruns do freenas. Você pode receber um suporte melhor do que aqui.

Em segundo lugar: você pode acelerar a rede. Se acontecer de você ter várias interfaces NIC no seu servidor supermicro. Você pode canalizá-los para dar a você quase o dobro da taxa de transferência de rede e alguma redundância. link

    
por 11.06.2012 / 02:39
2

Algumas sugestões.

  • Os espelhos RAID 1 + 0 ou ZFS normalmente apresentam desempenho melhor que o RAIDZ.
  • Você não menciona as especificações reais do seu servidor de armazenamento, mas qual é o seu tipo / velocidade de CPU, quantidade de RAM e controlador de armazenamento?
  • Existe um comutador de rede envolvido? O armazenamento em sua própria rede, isolado do tráfego da VM?

Eu diria que 80 megabytes / segundo é lento para um teste direto no sistema FreeNAS. Você pode ter um problema no disco. Você está usando "Advanced Format" ou discos do setor 4K? Em caso afirmativo, pode haver problemas de alinhamento de partição que afetarão seu desempenho.

    
por 11.06.2012 / 00:41
2

O que você provavelmente está vendo não é uma sobrecarga de tradução, mas um impacto no desempenho devido a um padrão de acesso diferente. As gravações sequenciais em um volume do ZFS simplesmente criariam um fluxo de dados quase sequencial para ser gravado em seus discos físicos subjacentes. As gravações sequenciais em um datastore VMFS sobre um volume ZFS criariam um fluxo de dados que é "perfurado" por atualizações de metadados da estrutura do sistema de arquivos VMFS e solicitações freqüentes de liberação de sincronização / cache para esses mesmos metadados. As gravações seqüenciais em um disco virtual de dentro de um cliente novamente adicionariam mais "perfurações" de seu fluxo sequencial devido aos metadados do sistema de arquivos do convidado.

A cura geralmente prescrita nessas situações seria a habilitação de um cache de gravação que ignoraria as solicitações de limpeza de cache. Isso aliviaria os problemas de gravação aleatória e sincronização e melhoraria o desempenho dos convidados da sua VM. No entanto, tenha em mente que a integridade de seus dados estaria em risco se o cache não fosse capaz de persistir em interrupções de energia / reinicializações repentinas.

Você pode testar facilmente se estiver atingindo os limites do seu disco emitindo algo como iostat -xd 5 em sua caixa FreeNAS e observando os tamanhos de fila e as estatísticas de utilização de seus dispositivos físicos subjacentes. A execução de esxtop no modo disk device também deve ajudá-lo a obter uma pista sobre o que está acontecendo, mostrando estatísticas de utilização de disco do lado do ESX.

    
por 11.06.2012 / 12:04
2

Atualmente, uso o FreeNas 8 com dois arrays do Raid 5 sSata anexados ao servidor. O servidor tem 8 GB de RAM e dois processadores Intel Xeon de núcleo único.

Meu desempenho foi substancialmente diferente do que os outros experimentaram.

Eu não estou usando o MPIO ou qualquer balanceamento de carga em NICs. Apenas uma única placa de rede do servidor Intel GIGE 10/100/1000.

As duas matrizes têm cinco unidades de 2,0 TB equivalentes a aproximadamente 7,5 TB de espaço RAID5.

Eu utilizo esses dois arrays para duas funções diferentes:

1) A matriz nº 1 está conectada a um servidor Intel HPC executando o Centos 5.8 e PostGres. O sistema de arquivos é ext4. Eu consegui um pico de 800 Mbps / seg para este array.

2) O array # 2 está sendo usado para as VMs do Citrix Xenserver 6 Centos. Essas partições de unidade de 200 GB estão fornecendo excelente desempenho. Cada uma das VMs está executando servidores de sinalização SIP em tempo real que suportam chamadas simultâneas de 5-10 K a 500-1000 CPS. O banco de dados local grava os CDRs nessas partições antes que o servidor de banco de dados principal as copie para suas tabelas. Eu também consegui um pico de 800 Mbps / seg para este array.

Agora, eu não sugeriria usar um array iSCSI FreeNas como minha solução principal para grandes partições de banco de dados. Eu tenho que correr em uma partição SAS Raid 10 10K RPM no servidor de banco de dados.

Mas, não há absolutamente nenhuma razão para que você não possa enviar seu tráfego de dados através de uma simples rede Ethernet comutada para um servidor razoavelmente configurado executando o FreeNAS e enviá-lo no pico teórico do GIGE.

Eu ainda tenho que testar o throughput de leitura, mas o RAID5 é mais lento nas leituras. Então, deve ser tão bom ou melhor.

O FreeNAS dimensiona-se consistentemente bem, à medida que mais demandas de tráfego são feitas. Qualquer servidor do CentOS 5.8 usará seu próprio cache para armazenar em buffer os dados antes de enviá-los aos arrays iSCSI. Portanto, certifique-se de ter uma ampla memória em seus hosts da VM e ficará feliz com seu desempenho.

Nada testa melhor uma tecnologia do que aplicativos de bancos de dados e aplicativos de tráfego em tempo real, na minha opinião.

Eu também acho que adicionar um recurso de cache de gravação de memória do sistema seria benéfico, mas meus números de desempenho mostram que o FreeNAS e o iSCSI estão com desempenho estelar!

Só pode melhorar.

    
por 23.07.2012 / 15:30
0

Primeiro - o desempenho do VMware não é realmente um problema do protocolo iSCSI (no FreeNAS) ou NFS 3 ou CIFS (Windows), é um problema das gravações do sistema de arquivos XFS e do status 'sync'.

O FreeNAS tem uma propriedade chamada "sync" e pode ser ativada ou desativada. "zfs sync = always" é definido por padrão e faz com que todas as gravações sejam liberadas. Isso reduz drasticamente o desempenho, mas garante gravações em disco. Por exemplo, executar o VMware ESXI 5.5 e o FreeNAS em equipamentos modernos (CPU GHZ 3.x, Seagate 7200 HD, rede 1GigE) sem tensão normalmente resulta em um desempenho de 4-5 MB / s em um clone VMware ou robocopy do Windows ou outra operação de 'gravação' . Definindo "zfs sync = disabled" o desempenho de gravação vai facilmente para 40MB e chega a 80Mbs (que é Megabytes por segundo). É 10x-20x mais rápido com a sincronização desativada e é o que você esperaria .... MAS as gravações não são tão seguras.

Então, eu uso sync = disabled 'temporariamente' quando eu quero fazer um monte de clones ou robocopy de significação etc. Então eu reconfixo sync = sempre para a operação de VM 'padrão'.

FreeNAS tem um 'scrub' que irá verificar todos os bytes no disco ... demora cerca de 8hrs para 12TB e eu o executo uma vez por semana para garantir que bytes escritos durante sync = disabled estejam OK. / p>     

por 22.12.2014 / 04:20