Não preste atenção à SAN atrás da cortina

Era uma vez, eu construí meus próprios servidores SQL e tinha controle sobre a configuração da unidade, níveis de RAID etc. O conselho tradicional de separação de dados, logs, tempdb, backups (dependendo do orçamento!) Sempre foi uma parte muito importante do processo de design do servidor SQL.

Agora, com uma SAN de nível empresarial, apenas solicito uma quantidade específica de espaço em disco para um novo servidor SQL, dividido em unidades lógicas para dados, backups e compartilhamento de arquivos. Certamente facilita meu trabalho, mas há uma parte de mim que não se sente completamente à vontade que eu realmente não posso espiar "por trás da cortina" para ver o que realmente está acontecendo lá atrás.

Meu entendimento é que a equipe da SAN não configura diferentes "tipos" de unidades de maneira diferente (otimizando as unidades de dados para acesso aleatório versus as unidades de log para gravação em fluxo contínuo). Parte disso pode depender do próprio produto da SAN (temos um HP XP12000 e um HP XP24000), mas tenho certeza de que o software HP faz todos os tipos de configuração de desempenho dinâmico (observando pontos de acesso de IO e reconfigurando rapidamente para otimizar esses LUNs), para que as equipes de aplicativos e os DBAs não precisem se preocupar com nada disso. Algo sobre "espalhar a carga de todos os servidores por um grande número de eixos" ou algo assim.

Minhas perguntas / discussão:

1. Sem criar inimigos na equipe da SAN, como posso garantir a mim e aos desenvolvedores de aplicativos que nossos servidores SQL não estão sofrendo de armazenamento mal configurado? Basta usar estatísticas perfmon? Outros benchmarks como o sqlio?

2. Se eu carregar o teste nessas unidades SAN, isso realmente me dará uma medida confiável e repetível do que verei quando formos ao ar? (supondo que o software SAN possa "configurar dinamicamente" de maneira diferente em diferentes momentos).

3. As E / S pesadas em uma parte da SAN (por exemplo, o servidor Exchange) afetam meus servidores SQL? (supondo que eles não estejam dando discos dedicados a cada servidor, o que me disseram que eles não estão)

4. Solicitar a separação de unidades lógicas para diferentes funções unidades lógicas (dados x log x tempdb) ajudaria aqui? A SAN veria as diferentes atividades de E / S nelas e as configuraria de maneira ideal?

5. Estamos em uma crise no espaço agora. As equipes de aplicativos são instruídas a cortar os arquivos de dados etc. A preocupação com o espaço levaria a equipe da SAN a tomar decisões diferentes sobre como configurar o armazenamento interno (níveis de RAID etc.) que poderiam afetar o desempenho do meu servidor?

Obrigado por seus pensamentos (tópico semelhante discutido brevemente nesta pergunta sobre o SF )

Sem criar inimigos na equipe da SAN, como posso garantir a mim e aos desenvolvedores de aplicativos que nossos servidores SQL não estão sofrendo de armazenamento mal configurado? Basta usar estatísticas perfmon? Outros benchmarks como o sqlio?

Em suma, provavelmente não há uma maneira de ter certeza absoluta. O que eu diria (eu sou um administrador da SAN) é que, se seus aplicativos estiverem atendendo às suas expectativas, não se preocupe. Se você começar a ver problemas de desempenho que acredita estar relacionados ao desempenho do SAN / Disk IO, é aconselhável investigar. Eu não uso muito armazenamento HP como você, mas no mundo IBM / NetApp, posso dizer por experiência que não existem muitas opções que permitam configurá-lo "mal". Atualmente, a maior parte do armazenamento corporativo retira muitas suposições da criação de matrizes de ataque, e realmente não permite que você faça errado. A menos que eles misturem velocidades e capacidades da unidade nos mesmos grupos de invasões, você pode ter certeza na maioria dos casos de que seu disco está funcionando bem.

Se eu carregar o teste nessas unidades SAN, isso realmente me dará uma medida confiável e repetível do que verei quando formos ao ar? (supondo que o software SAN possa "configurar dinamicamente" de maneira diferente em diferentes momentos).

O teste de carga deve ser bastante confiável. Lembre-se de que, quando você está testando uma caixa, sendo uma Matriz de Disco / SAN compartilhada, seu desempenho pode (e será) afetado por outros sistemas usando o mesmo armazenamento.

As E / S pesadas em uma parte da SAN (por exemplo, o servidor Exchange) afetam meus servidores SQL? (supondo que eles não estejam dando discos dedicados a cada servidor, o que me disseram que eles não estão)

Pode. Não é tudo sobre os discos, ou quais discos, os servidores estão ativos. Todos os dados estão sendo veiculados por meio de um controlador de disco e, em seguida, um comutador SAN. O desempenho que você verá depende muito de como o controlador de disco está conectado nas prateleiras correspondentes e na SAN correspondente. Se a matriz inteira se conectar à SAN de backbone em um único fio de fibra de 4 gbps, claramente o desempenho será afetado. Se a matriz estiver conectada através de duas SANs redundantes com balanceamento de carga, usando links troncalizados, seria impossível que o intercâmbio sugasse muita largura de banda. Outra coisa que precisa ser considerada é quantos IO / s a ​​matriz é capaz. Desde que a matriz e a SAN à qual está conectada sejam dimensionadas corretamente,

Solicitar a separação de unidades lógicas para diferentes funções unidades lógicas (dados x log x tempdb) ajudaria aqui? A SAN veria as diferentes atividades de E / S nelas e as configuraria de maneira ideal?

Isso provavelmente é uma questão de preferência e também depende muito de como os administradores de armazenamento o configuram. Eles podem fornecer três LUNs na mesma matriz ou volume; nesse caso, é tudo a mesma coisa. Se eles fornecerem LUNs individuais em matrizes diferentes, em volumes diferentes (discos fisicamente diferentes), poderá valer a pena separá-los.

Estamos em uma crise no espaço agora. As equipes de aplicativos são instruídas a cortar os arquivos de dados etc. A preocupação com o espaço levaria a equipe da SAN a tomar decisões diferentes sobre como configurar o armazenamento interno (níveis de RAID etc.) que poderiam afetar o desempenho do meu servidor?

Não imagino que o administrador do armazenamento altere o nível da invasão para liberar espaço. Se ele quisesse, provavelmente deveria ser demitido. As preocupações com o espaço podem levar as coisas a serem configuradas de maneira diferente, mas normalmente não de maneira impactante no desempenho. Eles podem ficar um pouco mais restritos quanto ao espaço que eles lhe dão. Eles podem ativar recursos como a deduplicação de dados (se a matriz suportar) que podem prejudicar o desempenho da matriz enquanto o processo é executado, mas não o tempo todo.

A equipe da SAN deve ter ferramentas que possam ajudá-lo a revelar se o seu aplicativo está com hotspot. Obviamente, você deve monitorar e medir também.

A maior parte da minha experiência é com a EMC, então YMMV. Mas o seguinte deve se aplicar à maioria dos equipamentos SAN.

Existem tantas portas entrando na matriz. Às vezes, há um comutador SAN entre o qual você pode definir zonas. Só porque a matriz é essencialmente um grande pool de armazenamento, não significa que você não deve se preocupar com o desempenho de E / S.

Portanto, se você sentir que está tendo problemas de IO, precisará diminuir onde está o gargalo. Se estiver em algum lugar entre o HBA e a matriz, você poderá descobrir se o HBA está no máximo ou se a porta SAN no lado do comutador / matriz está com excesso de assinaturas. Além disso, a equipe da SAN monitora os padrões de acesso ao seu aplicativo, desde o início a frio e a quente.

Obviamente, o armazenamento subjacente faz a diferença, digamos, executando RAID5 grande e lento RAID10 veloz, pois em algum momento você precisará atingir o disco, independentemente dos diferentes níveis de cache.

HTH. Você pode fazer o ping off-line se tiver um problema específico, pois isso pode levar um tempo para ser aprofundado.

Sem criar inimigos na equipe da SAN, como posso garantir a mim e aos desenvolvedores de aplicativos que nossos servidores SQL não estão sofrendo de armazenamento mal configurado? Basta usar estatísticas perfmon? Outros benchmarks como o sqlio?

A primeira coisa que você precisa saber antes de fazer qualquer tipo de benchmarking é qual a tolerância que sua própria carga de trabalho precisa executar. Portanto, faça um benchmark de suas próprias coisas antes de verificar o novo sistema. Dessa forma, se você encontrar um máximo de, digamos, 56 MB / s durante os picos de carga (backups?), Descobrindo que a matriz de discos conectados à SAN 'apenas' empurra 110 MB / s sob picos de carga simulados, você pode garantiu que o limite não será o canal de E / S.

Ao verificar uma nova matriz de disco, eu fiz esse tipo de teste de desempenho. A nova matriz usava unidades SATA em vez de unidades de canal de fibra (SCSI), e eu precisava me assegurar de que funcionaria em nosso ambiente. Eu estava profundamente duvidoso. Porém, após a caracterização, descobri que o novo sistema tinha sobrecarga de E / S suficiente no pico para acompanhar o pico medido nos discos mais confiáveis. Isso me surpreendeu.

Se eu carregar o teste nessas unidades SAN, isso realmente me dará uma medida confiável e repetível do que verei quando formos ao ar? (supondo que o software SAN possa "configurar dinamicamente" de maneira diferente em diferentes momentos).

Devido à natureza compartilhada das matrizes de disco conectadas à SAN, o desempenho é variável ao longo da semana. Se você já sabe quando o seu pico de carga de E / S é, faça uma série de testes de carga durante o horário do dia em que o pico de carga de E / S é. Dessa forma, você pode caracterizar melhor que tipo de sobrecarga de E / S está disponível durante os períodos nos quais você está mais interessado. Os testes de carga em horários não de pico darão uma ideia de como as coisas serão rápidas, mas os testes de pico dar a você verificação de limites verdadeiros.

As E / S pesadas em uma parte da SAN (por exemplo, o servidor Exchange) afetam meus servidores SQL? (supondo que eles não estejam dando discos dedicados a cada servidor, o que me disseram que eles não estão)

Se os LUNs do Exchange compartilharem discos com seus SQL LUNs, eles absolutamente o farão. Usamos EVAs HP, não XPs, mas acho que eles usam a mesma terminologia de "grupo de discos". LUNs no mesmo grupo de discos compartilham discos e, portanto, disputam E / S nesses dispositivos físicos. Quanto mais discos você colocar em um grupo de discos, mais espaço de manobra a matriz terá para manipular a E / S. As matrizes (pelo menos os EVAs fazem isso, e presumo que os XP mais caros façam o mesmo) distribuem blocos lógicos de LUN pelos discos físicos de maneira não sequencial. Isso permite que você faça o que você sugere, que é distribuir dinamicamente grupos de blocos acessados ​​com frequência em diferentes dispositivos físicos para aumentar o paralelismo e reduzir a contenção de E / S no nível do disco.

A pergunta a ser feita é quanto orçamento de E / S esse grupo de discos possui e se os aplicativos que usam esses LUNs estão com excesso de assinaturas para E / S. Essa é uma pergunta que os administradores de armazenamento terão que acompanhar. Pode ser que o pico de E / S do Exchange (provavelmente durante os backups) possa não coincidir com as cargas do SQL e os dois sistemas possam coexistir com satisfação.

Solicitar a separação de unidades lógicas para diferentes funções unidades lógicas (dados x log x tempdb) ajudaria aqui? A SAN veria as diferentes atividades de E / S nelas e as configuraria de maneira ideal?

Para as matrizes HP, é necessário colocar os diferentes padrões de E / S em diferentes grupos de discos , não LUNs. Os padrões de E / S do banco de dados não devem coexistir com os padrões de acesso de serviço da Web, por exemplo. Diferentes LUNs não melhoram significativamente seu desempenho, a menos que estejam em grupos de discos diferentes. Se eles estiverem no mesmo grupo de discos, a única vantagem real é o sistema operacional, onde ele pode fazer o planejamento de E / S no kernel para melhorar o paralelismo com o subsistema de disco. Dito isto...

As matrizes HP, pelo que entendi, estão cientes dos diferentes padrões de acesso nos LUNs, mas preste muita atenção aos blocos lógicos reais. Colocar os logs em um LUN diferente coloca um limite nos blocos lógicos que receberão esse tipo de tráfego de E / S e facilitarão a tarefa de classificar corretamente os blocos lógicos nos discos físicos.

Estamos em uma crise no espaço agora. As equipes de aplicativos são instruídas a cortar os arquivos de dados etc. A preocupação com o espaço levaria a equipe da SAN a tomar decisões diferentes sobre como configurar o armazenamento interno (níveis de RAID etc.) que poderiam afetar o desempenho do meu servidor?

Definitivamente. Se houver pouco espaço, você não obterá grupos de discos dedicados para sua E / S (a menos que seu ambiente de armazenamento seja grande o suficiente para justificar a dedicação de 7 TB de disco físico para seu uso exclusivo, quando for esse o caso) ) O debate Raid5 / Raid10 depende em grande parte das políticas da organização, e perguntar é a sua melhor aposta.

Sugiro abrir um diálogo com sua equipe e fornecedor da SAN para resolver suas preocupações. Um dos problemas que você terá ao executar seus próprios benchmarks é que seus testes podem não ter influência sobre o que acontece na produção, principalmente em cargas de pico. A maioria das SANs possui toneladas de cache com bateria, o que em muitos casos (principalmente quando você executa benchmarks sintéticos) significa que você está gravando na RAM e obtendo desempenho excelente.

Dependendo do seu ambiente e da solução que você está usando, algum CE do fornecedor pode ter acabado de chegar e configurar a SAN para o padrão que ele preferir. Isso acontece mais do que você pensa. Você precisará remover o shell "a equipe da SAN sabe tudo" até ter certeza de que a solução está atendendo aos seus requisitos.

Boa sorte.

Uma vez, eu estava em uma conferência da oracle com uma palestra sobre este tópico - SAN sã para bancos de dados.

O conteúdo da palestra está disponível neste arquivo PDF ou no site dos autores aqui