desempenho iSCSI entre SAN e hipervisor terrivelmente lento

Question

Temos uma configuração SAN de homem ruim em um servidor Ubuntu 1U executando iSCSI-Target com duas unidades de 300 GB em RAID-0. Em seguida, estamos usando-o para armazenamento em nível de bloco para máquinas virtuais. O hipervisor é conectado à SAN via gigabit em uma VLAN e interfaces dedicadas.

Temos apenas uma única configuração de máquina virtual e fazemos alguns benchmarks. Se executarmos hdparm -t /dev/sda1 da máquina virtual, obteremos um desempenho "ok" de 75MB / s da máquina virtual para a SAN. Então, basicamente, compilamos um pacote com ./configure e make . As coisas começam ok, mas, de repente, a média de carga na SAN aumenta para 7+ e as coisas ficam mais lentas. Quando nós SSH no SAN e executar top, com certeza a carga é de 7 +, mas o uso da CPU é basicamente nada, também o servidor tem 1,5 GB de memória disponível. Quando matamos a compilação na máquina virtual, lentamente, o LOAD na SAN retorna para valores de sub 1.

O que no mundo está causando isso? Como podemos diagnosticar isso ainda mais?

Aqui estão duas capturas de tela da SAN durante o carregamento alto.

1> Output of iotop on the SAN:

link

2> Output of top on the SAN:

link

    

Answer 1

Você deve ver um aumento significativo de desempenho depois de ativar o cache de gravação no destino (os detalhes dependem da implementação - o que você está usando, tgt?) e de seus discos

hdparm -W 1 /dev/sda
hdparm -W 1 /dev/sdb

No entanto, há um preço: isso colocará em risco a integridade dos dados (especialmente se você executar bancos de dados) no caso de falta de energia ou suspensão do sistema da SAN, como dados que foram gravados permanentemente no disco, residia em DRAM volátil. Para atenuar esse risco, você deve usar um controlador com BBWC (cache de gravação com bateria) em que os dados sobreviveriam a uma queda de energia por um tempo (geralmente de 1 a 2 dias).

O principal "problema" com o ESXi é que ele está constantemente sincronizando os discos. A necessidade de escrever metadados para VMFS (se você tiver) torna ainda pior. Os fóruns da comunidade vmware estão cheios de postagens "meus discos estão lentos" sempre que as pessoas estão usando controladores sem caches de gravação.

    

Answer 2

Execute o iometer na sua máquina virtual.

Com apenas duas unidades de 7,2k rpm, o acesso aleatório vai prejudicar você. Você pode obter apenas tantos iops deles.

Tente executar dois cenários com o iometer:

1) leitura / escrita sequencial - isto deve dar números bons e gordos. 2) acesso aleatório à unidade - aqui você deve estar em uma terra de mágoa.

Configure um arquivo para testes grandes o suficiente para forçá-lo a sair do cache da máquina virtual.

    

Answer 3

Eu recomendaria tentar algumas coisas:

1. Tente fazer alguns testes de taxa de transferência com tráfego não-iSCSI (por exemplo, dd if=/dev/zero bs=1M | nc ... ) e veja se as cargas estão no mesmo nível (compare as duas cargas e a CPU% s). Você provavelmente deve tentar testar com apenas uma conexão, bem como executar cerca de 8 desses testes simultaneamente. E tente enviar e receber dados em ambas as direções.
2. Tente usar um software de destino diferente (por exemplo, o pacote do Ubuntu do tgt)
3. Atualize seu kernel na SAN para uma versão mais recente, caso você tenha encontrado um erro no kernel.
4. Denuncie esta questão na lista de discussão iSCSI-Target ou, se não tiver sorte, talvez o linux-kernel lista de discussão ?
5. Se tudo mais falhar, e se for uma opção para você, tente o NexentaOS ou o NexentaStor e veja se você obtém melhores resultados.

Eu também deparei com algumas diretrizes de ajuste de desempenho do iSCSI recentemente, que você pode achar útil, mesmo que essas recomendações não abordem o problema específico que você está enfrentando.