SAN com iSCSI-Target Performance Horrendo

Question

Temos a configuração SAN de um homem pobre 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:

2>OutputoftopontheSAN:

    

Answer 1

Isso se parece muito com um caso típico de armazenamento underspeced. Os hipervisores (especialmente o ESXi / vSphere) emitem gravações síncronas significativamente mais frequentemente do que você veria com uma instalação bare-metal de um sistema operacional como o Linux - onde a grande maioria dos pedidos de gravação seria assíncrona (a menos que você tenha estragado as configurações do sistema de arquivos) ). As gravações síncronas novamente precisariam do armazenamento para confirmar que uma operação foi concluída e foi confirmada para um armazenamento permanente. Se tudo o que você tem são 2 discos, será um jogo difícil - você está vendo os resultados.

Suas opções:

1. use um controlador RAID com um cache próprio, com bateria ou flash, para poder informar a conclusão assim que os dados forem gravados no cache
2. minta para o seu hipervisor que os dados foram confirmados para armazenamento permanente, embora na verdade ele não tenha permitido ativar IOMode=wb para sua definição de LUN no ietd.conf

Observe que o último não é recomendado, pois pode levar à corrupção do armazenamento de dados do Hypervisor, dos sistemas de arquivos dos convidados e dos bancos de dados transacionais em caso de queda de energia ou falha do servidor de armazenamento (e o IET pode falhar de fato) mas é bastante adequado como uma verificação rápida se as gravações de sincronização são o que está causando sua carga e números de desempenho péssimos ao compilar.

    

Answer 2

gargalo. poderia estar no lado do iniciador, rede em ambos os lados, software de destino ou subsistema de disco de destino. pela descrição, eu começaria com a rede, certificando-se de que os offloads estão desligados (ethtool -K {tso, gso, lro} off)

    

Answer 3

hdparm é uma ferramenta muito ruim para avaliar o desempenho de IO. Você deve considerar o uso de bonnie++ ou uma das ferramentas mais específicas do aplicativo.

Ao fazer seu processo ./configure; make , você acabará fazendo um intervalo de leituras e gravações, com tamanhos variáveis, mais prováveis do que não se espalhar pelo disco inteiro em vez de em uma área contígua.

Depois de entender melhor o desempenho do seu sistema de I / O, você pode identificar a causa raiz.

O desempenho está correto no destino iSCSI ao gravar diretamente no disco, mas não está OK quando você está falando sobre o iSCSI? Em caso afirmativo, provavelmente relacionado à rede (offloads, mtu, duplex / speed mismatch etc). Se não, provavelmente controlador / disco relacionado (cache de gravação etc)