O desempenho de E / S do MSSQL foi degradado após a consolidação da SAN?

Question

Recentemente, consolidei todas as nossas SANs Dell Equallogic no mesmo grupo; anteriormente cada SAN estava em seu próprio grupo. Eles são todos preenchidos com drives SAS de 15k RPM no RAID 6, então não me preocupei em escalonar o armazenamento do novo grupo consolidado, já que eles são praticamente todos iguais.

No processo de fazer isso, alterei todas as nossas VMs para usar o armazenamento VMDK em vez do iSCSI, porque acredito que o desempenho seja melhor.

Estou sendo avisado agora que o desempenho de E / S do disco do nosso servidor MS SQL 2005 (nossa caixa principal do SQL, por enquanto) tem sido consistentemente pior do que antes da execução dessas operações, mas não consigo ver como poderia ser ... seus discos (C - OS, D - MDFs, E - LDFs) agora estão distribuídos em mais cabeças de leitura do que eram anteriormente, e meu entendimento é que o armazenamento VMDK tem mais desempenho que o iSCSI.

Então, o que dá? Aqui está um gráfico do "tempo total de espera de E / S" do Solarwinds Database Performance Analyzer:

    

Answer 1

A primeira coisa a ter em mente ao combinar esses arrays EQL em um único pool é que a carga de trabalho em cada volume tem o potencial de afetar o desempenho em outros volumes. É possível que seu banco de dados SQL - embora resida em mais eixos físicos agora - tenha mais contenção de recursos devido a outras cargas de trabalho que compartilham os mesmos eixos.

O segundo fator principal que vem à mente é a rede de armazenamento. Com membros em pools ou grupos separados, quase todo o seu tráfego de rede iSCSI é de E / S para / dos hosts. No entanto, com membros em um único grupo e pool, você deve contabilizar o tráfego dentro do grupo, principalmente o movimento da página. O movimento da página mantém a capacidade em uso, mesmo entre os membros, e também equilibra os dados "quentes" aos membros com cargas de trabalho relativamente baixas. Confira o white paper sobre Equallogic Load Balancers para obter informações mais detalhadas .

Esse aumento no tráfego pode facilmente exceder o que seus switches são capazes, se eles não atenderem aos padrões descritos no Matriz de compatibilidade de armazenamento Dell (consulte a página 19)

Você também pode ler o whitepaper melhores práticas para VMware e Equallogic para garantir que sua configuração não seja a causa do problema.

Algumas perguntas:

1. Você tem uma garantia ativa em algum dos arrays? Nesse caso, isso é realmente algo que você deve obter como contribuição de inúmeros recursos disponíveis para ajudar no desempenho.

   I don't have active warranty on any of the arrays unfortunately.

2. Você tem a sede da SAN instalada e monitorando o grupo? Se não ... consiga instalá-lo e configurá-lo (desde que você tenha uma garantia e possa obtê-lo). Ele fornece algumas informações importantes sobre muitas das métricas de desempenho de armazenamento necessárias para entender possíveis causas raiz.

   I do have SAN HQ, though... can you elaborate on what I should be looking at within it to help pin this down?

O local mais fácil de verificar é em "análise experimental", que fornece um gráfico da sua carga de trabalho em comparação com um "IOPS máximo estimado". Você pode visualizar isso para todo o grupo e para membros individuais. Você também pode ver a IOPS do fuso individual e a profundidade da fila na seção de hardware, embora possa ser difícil dizer apenas por esses números se os fusos estão sendo sobrecarregados.

3. Quantos membros / matrizes você tem no mesmo pool agora?

   There are 5 arrays in the same pool now

Eu recomendo strongmente que você considere dividi-los em dois pools, com no máximo 3 membros em um pool. Um volume é distribuído apenas entre três membros quando não está no meio do reequilíbrio da capacidade para um membro diferente (o que acontecerá com frequência em volumes com instantâneos que mudam constantemente de espaço em uso). Cortar as coisas em até 3 membros no máximo irá parar uma grande quantidade de "churn" de fatias de volume inteiras sendo reequilibradas entre os membros em uma perseguição sem fim depois de obter a capacidade de uso o mais igual possível entre os membros.

Fora de toda essa informação ... se você não consegue chegar ao fundo das coisas sozinho, você pode considerar apenas pagar por um tíquete de suporte com a Dell para que alguém passe por tudo no ambiente com você para isolar a causa.

    

Answer 2

A diferença de desempenho entre o VMDK e o iSCSI em nível de bloco depende do tipo de carga de trabalho e pode variar muito de um aplicativo para outro. Eu recomendo que você faça um teste como executar alguns dos seus aplicativos nos dois tipos de protocolo de acesso ao armazenamento e ver como ele se comporta. Como o VMDK é uma camada adicional entre o aplicativo e o armazenamento, pode ser mais lento se o host que controla a unidade virtual estiver muito carregado.

    

Answer 3

Você provavelmente reduziu seu "tempo de cache" quando compartilhou os discos

Imagine que você tem dois aplicativos "A" e "B":

• O aplicativo "A" tem um banco de dados pequeno com apenas 40GiB, carrega 1GiB / dia e a maioria das consultas usa os dados dos últimos dias da semana. Em um servidor com 20GiB de RAM dedicado ao cache de disco, provavelmente no máximo 20 dias de dados estarão no cache de disco e a maioria das leituras não moverá a cabeça do disco.

• A aplicação "B", no outro lado, é um arquivo médio com 2000GiB, carrega 20GiB de dados todos os dias e a maioria das consultas lê sequencialmente a coisa toda. É um arquivo e na maioria das vezes faz consultas textuais que são difíceis de indexar e a leitura sequencial acontece dentro de um dia de qualquer forma o que é suficiente para os usuários da aplicação. Como muitos arquivos, ele é usado apenas por auditorias que não precisam de respostas mais rápidas.

• Se você unir os discos desses dois servidores no mesmo armazenamento usando o mesmo cache de 64GiB, o aplicativo "A" e "B" moverão dados de 21GiB por dia. Em seguida, o cache armazenará no máximo três dias de dados. Antes da mesclagem, o aplicativo "A" fazia a maioria de suas consultas na RAM, agora, a maioria deles precisa de uma leitura do disco phisicall. Antes da mesclagem, o aplicativo "B" tinha pouca concorrência do aplicativo "A" nos acessos ao disco, agora tem muita concorrência.

Tem a ideia?

Segmentar os caches de disco é muito importante para o desempenho porque a velocidade da RAM é entre 4k e 4 milhões de vezes mais rápida que os discos de 15k para acesso aleatório. Discos tem que mover a cabeça para obter os dados, a RAM não. Discos de 15k RPM são um desperdício de dinheiro. Eles são cerca de 2 vezes a velocidade das unidades SATA normais para acesso aleatório e custam muito mais do que 2 vezes o preço das unidades SATA.

Sobre o VMDK

Meus servidores são muito grandes e tivemos problemas no passado com VMs grandes (700GiB de RAM, por exemplo) no VMWare. Também tivemos sérios problemas de desempenho e falhas inexplicáveis. Por essa razão, nos mudamos para o KVM. Eu não era o gerente do servidor de virtualização na época, então não posso dizer o que estava errado com o nosso VMWare. Mas desde que nos mudamos para o KVM e nos tornamos o gerente do servidor de virtualização, não temos mais problemas.

Eu tenho algumas imagens vm em dispositivos físicos (encaminhamento SCSI) e algumas imagens como arquivos de imagem .img (semelhante ao VMDK com tamanho fixo). As pessoas na internet disseram que o encaminhamento de SCSI é muito mais rápido, mas, para meus padrões de uso, o desempenho é o mesmo. Se houver uma diferença é pequena o suficiente para eu não ver. A única coisa é que ao criar uma nova máquina virtual, temos que instruir o KVM a não armazenar em cache o acesso ao disco no sistema operacional do host. Eu não sei se o VMWare tem uma opção semelhante.

Minhas sugestões para você

1. Alterar estratégia de armazenamento

Troque os armazenamentos por discos internos. 24 discos SATA internos permitem um grande ataque 10 que será mais barato e mais rápido do que a maioria dos armazenamentos. E tenha um benefício colateral, por um custo menor, você terá um excedente de espaço em disco nesses servidores que podem ser usados em tarefas de backup e manutenção cruzadas.

Mas não expõe esse espaço excedente a seus usuários. Guarde para si mesmo. Caso contrário, será um inferno fazer backups.

Use armazenamentos para os locais para os quais foram projetados:

• Backup centralizado;
• Banco de dados / arquivos que são grandes demais para caber nos discos internos;
• Banco de dados / arquivos que os padrões de uso não são acelerados por caches de disco e o número de cabeçotes de disco necessários para o desempenho não cabe em discos internos ou armazenamento dedicado.

E ... não se incomoda em comprar armazenamentos com muito cache de disco. Em vez disso, coloque o dinheiro no aumento da RAM dos servidores que usam os armazenamentos.

2. Mova a RAM do cache de armazenamento para os servidores reais, se possível

Supondo que você tenha a mesma quantidade de RAM de cache no armazenamento após a unificação, talvez você tenha RAM suficiente. Tente mover a RAM do cache de armazenamento para os servidores reais na proporção que você tem antes. Isso se os chips de RAM forem compatíveis. Isso pode fazer o truque.

3. Nenhum RAID 6 para bancos de dados de missão crítica

A invasão 5 e 6 é a pior para o desempenho do banco de dados. Move to Raid 10. Raid 10 dobra a velocidade de leitura porque você tem duas cópias independentes de cada setor que podem ser lidas independentemente.

4. Mova o log do banco de dados para uma unidade interna dedicada

Eu uso o postgres, e mover o write-ahead-log para um disco dedicado faz muita diferença. O problema é que os servidores de banco de dados mais modernos gravam as informações no log antes de gravar as informações na própria área de dados do banco de dados. O log geralmente é um buffer circular e as gravações são todas sequenciais. Se você tiver um disco físico dedicado, a cabeça estará sempre no lugar para a gravação, quase sem tempo de busca, mesmo que seja uma unidade de baixa rotação. Enquanto leio na internet, o Mysql usa o mesmo design.