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 com armazenamento mal configurado? Apenas use estatísticas de perfmon? Outros benchmarks como o sqlio?
Em suma, provavelmente não há como ter certeza absoluta. O que eu diria (sou administrador de SAN) é que, se os aplicativos estiverem funcionando de acordo com as suas expectativas, não se preocupe. Se você começar a ver problemas de desempenho que acredita estarem relacionados ao desempenho do SAN / Disk IO, convém consultar. Eu não uso muito armazenamento da HP como você, mas no mundo da IBM / NetApp eu posso dizer por experiência que não há muitas opções que permitam configurá-lo "mal". A maior parte do armazenamento corporativo nos dias de hoje exige muito do trabalho de adivinhação da construção de arrays de raid, e realmente não permite que você faça errado. A menos que eles estejam misturando velocidades e capacidades de unidade nos mesmos grupos de raids, você pode ficar tranqüilo na maioria dos casos em 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 veremos 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 a carga de uma caixa, que está em uma SAN / Disk Array compartilhada, seu desempenho pode (e será) afetado por outros sistemas que usam o mesmo armazenamento.
O IO pesado em uma parte da SAN (digamos, o servidor Exchange) afeta meus servidores SQL? (assumindo que eles não estão dando discos dedicados para cada servidor, o que me foi dito que não são)
Pode. Não é tudo sobre os discos, ou quais discos, os servidores estão ligados. Todos os dados estão sendo servidos por meio de um controlador de disco e, em seguida, por um comutador SAN. O desempenho que você verá dependerá muito de como o controlador de disco está conectado às prateleiras de disco correspondentes e à SAN correspondente. Se o array inteiro se conectar ao backbone SAN em um único fio de fibra de 4 Gbps, então, claramente, o desempenho será afetado. Se a matriz estiver conectada através de duas SANs redundantes com carga balanceada, usando links troncalizados, então seria impossível para a troca absorver muita largura de banda. Outra coisa que precisa ser considerada é a quantidade de I / o da matriz que a matriz é capaz. Contanto que o array e o SAN ao qual ele está conectado sejam dimensionados corretamente, o IO pesado em outras partes do ambiente SAN não deve afetar seu desempenho do SQL.
Solicitar a separação de unidades lógicas para diferentes unidades lógicas de funções (dados vs log vs tempdb) ajuda aqui? A SAN veria as diferentes atividades de IO sobre elas e as configuraria de maneira ideal de maneira diferente?
Isso é provavelmente uma questão de preferência e também depende muito de como seus administradores de armazenamento a configuram. Eles podem fornecer três LUNs no mesmo array ou volume, e nesse caso, é tudo igual. Se eles lhe deram LUNs individuais em matrizes diferentes, em volumes diferentes (discos fisicamente diferentes), talvez valha a pena separá-los.
Estamos com um pouco de falta de espaço agora. As equipes de aplicativos foram instruídas a cortar arquivos de dados, etc. As preocupações com espaço levariam a equipe de 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 seu administrador de armazenamento altere o nível de invasão para liberar espaço. Se ele quisesse, então ele 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 forma impactante no desempenho. Eles podem se tornar um pouco mais restritos sobre quanto espaço eles te dão. Eles podem ativar recursos como deduplicação de dados (se a matriz suportar), o que pode prejudicar o desempenho da matriz enquanto o processo é executado, mas não o tempo todo.