configuração incorreta do SAN em potencial?

1

Sou desenvolvedor e sei muito pouco sobre sistemas de armazenamento. No trabalho, notei um desempenho de consulta lento e grande em um dos SQL Servers. Foi-me dito que o banco de dados está em um canal de fibra SAN MSA1500 (HP?) Com 14 unidades COMPAQ BF3008B26C. Fiz um benchmark rápido de sintonização em HD quando o servidor praticamente não carregava. A média de leitura foi de cerca de 60MB / s. Eu não sei muito sobre SANs, mas a velocidade de leitura parece muito baixa para mim. O benchmark local de leitura em HD é maior. Antes de eu ir para a minha equipe de TI com o que eu acho que é um enorme erro de configuração, eu só queria ter opiniões de vocês.

    
por coderguy123 09.12.2009 / 16:17

5 respostas

1

Os MSA1500s não são tão rápidos para os padrões SAN, mas as SANs mal configuradas geralmente têm desempenho inferior em cargas, como armazéns de dados. É bem provável que seja uma SAN mal configurada (talvez o tamanho da faixa na matriz seja muito pequeno). Também é possível que a SAN seja inerentemente lenta - nem todas as SANs são iguais.

Para uma carga pesada em volume (em vez de pesada) como um data warehouse, você provavelmente obterá um desempenho muito melhor dos arrays de disco de conexão direta. Em uma carga de trabalho de acesso aleatório, como um aplicativo transacional, as limitações do controlador tendem a ser mascaradas pela atividade de busca de disco mecânico. É mais provável que os problemas de desempenho apareçam em uma carga de trabalho de streaming, como uma verificação de tabela em uma grande tabela de fatos.

Um layout ruim do disco, como a colocação de volumes de registro nos mesmos conjuntos de discos, como cargas de trabalho de acesso aleatório ocupado, também pode afetar desproporcionalmente o desempenho do disco em uma SAN.

Para se ter uma ideia de se algo está em diskbound, dê uma olhada nas estatísticas das esperas do IO Latch da página. Se estes são desproporcionalmente altos, então a SAN é provavelmente o gargalo.

    
por 09.12.2009 / 16:27
1

Eu tenho um MSA1500CS e ele é consistentemente de baixo desempenho para mim, com as taxas que você está experimentando. Os discos no meu são drives SATA. Quando eu os tinha em configurações de raid de paridade (RAID5 ou 6), a taxa de transferência estava em torno de 60MB / s. Os controladores lá estão realmente sob energia. Desde então, fui para o RAID10 e a taxa de transferência aumentou bastante, em grande parte porque não estou consumindo quase tantos recursos de CPU do controlador para os cálculos de paridade.

Além disso, esse dispositivo tem um péssimo e desagradável hábito de desativar o cache de gravação ao executar determinadas funções de matriz. Coisas como adicionar uma unidade a uma matriz de disco, alterar o tamanho da faixa em uma LUN ou recuperar de um disco com falha. Quando isso acontece, qualquer paridade RAID LUNs torna-se muito sensível à escrita. Lance muita E / S de gravação e ela começa a diminuir drasticamente a velocidade com que ela confirma gravações nos discos. Unidades mais rápidas podem ajudar, mas é um problema de recursos da CPU do controlador em sua maior parte.

Dito isto, você tem uma unidade SCSI lá não SATA. Isso deve ajudar o desempenho em uma boa quantia, embora novamente o parity RAID possa não melhorar muito. O que melhoraria o desempenho é usar um firmware ativo / ativo e usar o MPIO round-robbin para distribuir a carga de E / S entre os dois controladores. Por último, verifiquei que isso só podia ser feito em ambientes host-SO homogêneos (ou seja, todo o Windows ou todo o Linux).

Este é um dispositivo projetado para que as cargas de trabalho sensíveis à latência (cargas de trabalho "on-line" no jargão da HP) sejam executadas em um conjunto de espelhos e arquivem cargas de trabalho ("nearline") para os RAIDs de paridade. A tentativa de usar um RAID de paridade em uma função online é factível desde que seu aplicativo aceite uma latência potencialmente muito severa. As minhas não eram, e isso causou grandes problemas.

A linha MSA2000 é supostamente muito melhor sobre isso.

    
por 09.12.2009 / 19:07
1

Os infratores comuns:

  • As partições de disco do Windows não estão alinhadas com a SAN. Isso ocorre devido às versões do Windows Server anteriores a 2008 que iniciam as partições no 64º setor.

  • O tamanho da unidade de alocação NTFS deve ser 64k (melhor prática).

  • Tamanho da faixa do SAN abaixo do ideal

Você pode verificar o alinhamento do disco com o comando:

partição wmic get blocksize, startingoffset, name, index

Se o deslocamento inicial for 32256, a partição está desalinhada.

Mais informações:

Práticas recomendadas de alinhamento de partição de disco para o SQL Server

link

    
por 09.12.2009 / 19:54
0

Sua ferramenta de benchmark utilizou a fila do sistema ou executou apenas uma solicitação SCSI por vez?

Pense em transportar carvão de uma mina que fica a 50 metros da sua casa. Você pode usar um caminhão. Com SAN a mina está longe, em outra cidade. Pode estar produzindo muito mais carvão (no seu caso a mina é cerca de 14 vezes maior), mas antes de tudo você precisa colocar muitos caminhões em ação (uma fila).

Seu banco de dados normalmente coloca muitos caminhões em ação, então use uma ferramenta de referência correspondente que também o faça.

Outra coisa, mais importante: operação sequencial vs aleatória. Seu banco de dados com certeza precisa de E / S aleatória (exceto o tempo de backup completo), portanto, posso adivinhar com segurança que ele nunca chegará nem perto de um desempenho de 60 MB / s. Porque com a E / S aleatória, os mineiros trabalham muito devagar, então caminhões e distância não importam muito. Tente avaliar esse tipo de carga de trabalho. Compare com sua unidade local e você pode se surpreender.

Outra resposta que toca nesse assunto Qual é o desempenho típico da SAN? .

    
por 09.12.2009 / 17:52
0

Aqui está um link que discute muitos problemas diferentes no servidor SQL. Vá para a página 19 (Apêndice D) para obter instruções sobre como seus profissionais de TI devem configurar a SAN. Inclui um artigo de Mr. Denny foi muito útil para mim. Nós reconfiguramos os tamanhos de bloco (tamanhos de faixa) e o número de unidades por LUN em nossa SAN após a leitura e observamos uma melhoria de 100 a 120% em nosso ambiente.
Espero que ajude você de alguma forma ...

    
por 09.12.2009 / 19:20