Ne faites pas attention à ce SAN derrière le rideau

Il était une fois, je construisais mes propres serveurs SQL et j'avais le contrôle de la configuration des disques, des niveaux de RAID, etc. du processus de conception du serveur SQL.

Maintenant, avec un réseau SAN d'entreprise, je demande simplement une quantité d'espace disque spécifique pour un nouveau serveur SQL, divisée en lecteurs logiques pour les données, les sauvegardes et les partages de fichiers. Cela facilite certainement mon travail, mais il y a une partie de moi qui ne se sent pas complètement à l'aise de ne pas pouvoir jeter un coup d'œil "derrière le rideau" pour voir ce qui se passe vraiment là-bas.

D'après ce que j'ai compris, l'équipe de réseau de stockage ne configure pas différemment les "types" de lecteurs (optimisation des lecteurs de données pour un accès aléatoire par rapport aux lecteurs de journaux pour la lecture en continu). Cela dépend en partie du produit SAN lui-même (nous avons un HP XP12000 et un HP XP24000), mais on m'a assuré que le logiciel HP effectue toutes sortes de configurations de performances dynamiques (surveillance des points chauds d'E / S et reconfiguration à la volée pour optimiser ces LUN), de sorte que les équipes de l'application et les administrateurs de base de données n'aient pas à s'inquiéter de ce genre de choses. Quelque chose à propos de "répartir la charge de tous les serveurs sur un grand nombre de piles" ou quelque chose comme ça.

Mes questions / discussion:

1. Sans me faire des ennemis dans l'équipe SAN, comment puis-je me assurer, ainsi que les développeurs d'applications, que nos serveurs SQL ne souffrent pas d'un stockage mal configuré? Il suffit d'utiliser les statistiques de perfmon? Autres repères comme sqlio?

2. Si je charge des tests sur ces disques SAN, est-ce que cela me donne une mesure fiable et reproductible de ce que je verrai quand nous irons en direct? (en supposant que le logiciel SAN puisse "configurer dynamiquement" différemment à différents moments).

3. Des E / S lourdes dans une partie du SAN (par exemple le serveur Exchange) ont-elles un impact sur mes serveurs SQL? (en supposant qu'ils ne donnent pas de disques dédiés à chaque serveur, on m'a dit qu'ils ne le sont pas)

4. Demander la séparation des lecteurs logiques pour différentes fonctions des lecteurs logiques (données vs journaux vs tempdb) serait-il utile ici? Le réseau SAN verrait-il les différentes activités IO sur ceux-ci et les configurerait-il différemment de manière optimale?

5. Nous sommes un peu dans une pénurie d'espace en ce moment. On demande aux équipes d'application de supprimer les archives de données, etc. Les problèmes d'espace obligent-ils l'équipe SAN à prendre des décisions différentes sur la manière de configurer le stockage interne (niveaux RAID, etc.) pouvant avoir une incidence sur les performances de mon serveur?

Merci pour vos pensées (sujet similaire abordé brièvement dans cette question SF )

Sans me faire des ennemis dans l'équipe SAN, comment puis-je me assurer, ainsi que les développeurs d'applications, que nos serveurs SQL ne souffrent pas d'un stockage mal configuré? Il suffit d'utiliser les statistiques de perfmon? Autres repères comme sqlio?

En bref, il n’ya probablement pas moyen d’être vraiment sûr. Ce que je dirais (je suis un administrateur SAN), c'est que si vos applications fonctionnent à la hauteur de vos attentes, ne vous inquiétez pas. Si vous commencez à voir des problèmes de performances qui, selon vous, pourraient être liés aux performances de SAN / Disk IO, il peut être judicieux de vous renseigner. Je n'utilise pas beaucoup de stockage HP comme vous, mais dans le monde IBM / NetApp, je peux affirmer par expérience qu'il n'y a pas beaucoup d'options qui vous permettraient de le configurer "mal". De nos jours, la plupart des systèmes de stockage pour entreprises simplifient considérablement la construction de baies de stockage et ne vous laissent pas réellement vous tromper. À moins de mélanger les vitesses et les capacités de disque dans les mêmes groupes de raids, vous pouvez être assuré dans la plupart des cas que votre disque fonctionne correctement.

Si je charge des tests sur ces disques SAN, est-ce que cela me donne une mesure fiable et reproductible de ce que je verrai quand nous irons en direct? (en supposant que le logiciel SAN puisse "configurer dynamiquement" différemment à différents moments).

Les tests de charge devraient être très fiables. Gardez simplement à l'esprit que lorsque vous testez en charge un seul boîtier, qui se trouve sur une baie de disques SAN / disques partagée, ses performances peuvent (et seront) affectées par d'autres systèmes utilisant le même stockage.

Des E / S lourdes dans une partie du SAN (par exemple le serveur Exchange) ont-elles un impact sur mes serveurs SQL? (en supposant qu'ils ne donnent pas de disques dédiés à chaque serveur, on m'a dit qu'ils ne le sont pas)

Ça peut. Tout ne concerne pas les disques, ni les disques sur lesquels les serveurs sont allumés. Toutes les données sont servies via un contrôleur de disque, puis un commutateur SAN. Les performances que vous verrez dépendent en grande partie de la façon dont le contrôleur de disque est connecté, des étagères de disque correspondantes et du réseau de stockage correspondant. Si toute la matrice se connecte au réseau fédérateur sur un seul brin de fibre 4 Gbps, les performances en seront clairement affectées. Si la matrice est connectée à travers deux réseaux SAN redondants équilibrés en charge, à l'aide de liaisons partagées, il serait alors impossible qu'un simple échange absorbe trop de bande passante. Une autre chose à prendre en compte est le nombre d'E / S par seconde pouvant être utilisé par la matrice. Tant que le module RAID et le réseau de stockage auquel il est connecté sont mis à l’échelle correctement,

Demander la séparation des lecteurs logiques pour différentes fonctions des lecteurs logiques (données vs journaux vs tempdb) serait-il utile ici? Le réseau SAN verrait-il les différentes activités IO sur ceux-ci et les configurerait-il différemment de manière optimale?

C’est probablement une question de préférence et dépend également de la façon dont vos administrateurs de stockage le configurent. Ils peuvent vous donner trois LUN dans le même tableau ou le même volume, auquel cas c'est toujours pareil. S'ils vous ont donné des LUN individuels sur des baies différentes, dans des volumes différents (des disques physiquement différents), il peut être intéressant de les séparer.

Nous sommes un peu dans une pénurie d'espace en ce moment. On demande aux équipes d'application de supprimer les archives de données, etc. Les problèmes d'espace obligent-ils l'équipe SAN à prendre des décisions différentes sur la manière de configurer le stockage interne (niveaux RAID, etc.) pouvant avoir une incidence sur les performances de mon serveur?

Je n'imagine pas que votre administrateur de stockage changerait le niveau de raid afin de libérer de l'espace. S'il le voulait, il devrait probablement être renvoyé. Les problèmes d'espace peuvent amener à configurer les choses différemment, mais pas normalement de manière à nuire aux performances. Ils pourraient juste devenir un peu plus serrés sur combien d'espace ils vous donnent. Ils peuvent activer des fonctionnalités telles que la déduplication des données (si le groupe le prend en charge) qui peuvent nuire aux performances du groupe pendant l'exécution du processus, mais pas à tout moment.

L’équipe SAN devrait disposer d’outils pouvant vous aider à déterminer si votre application est en point chaud. De toute évidence, vous devez également surveiller et mesurer votre objectif.

La plupart de mes expériences concernent EMC, donc YMMV. Toutefois, les éléments suivants devraient s’appliquer à la plupart des équipements SAN.

Il y a seulement tellement de ports entrant dans le tableau. Parfois, il existe un commutateur SAN entre lesquels vous pouvez définir des zones. Ce n’est pas parce que la matrice est une grande réserve de stockage que vous ne devez pas vous inquiéter des performances d’IO.

Donc, si vous sentez que vous avez des problèmes d'E / S, vous devez préciser le goulot d'étranglement. S'il se situe quelque part entre l'adaptateur HBA et le module RAID, vous pouvez alors déterminer si l'adaptateur HBA est saturé ou si le port SAN du côté commutateur / module est sursouscrit. En outre, l'équipe SAN doit surveiller les modèles d'accès de votre application, à partir d'un démarrage à froid et à chaud.

Évidemment, le stockage sous-jacent fait toute la différence, par exemple si vous exécutez un RAID 5 lent et lent ou un RAID 10 rapide, car vous devrez peut-être, à un moment donné, frapper le disque, quels que soient les différents niveaux de cache.

HTH. Vous pouvez me connecter hors ligne si vous rencontrez un problème spécifique, car cela peut prendre un certain temps à résoudre.

Sans me faire des ennemis dans l'équipe SAN, comment puis-je me assurer, ainsi que les développeurs d'applications, que nos serveurs SQL ne souffrent pas d'un stockage mal configuré? Il suffit d'utiliser les statistiques de perfmon? Autres repères comme sqlio?

La première chose que vous devez savoir avant de procéder à tout type d’analyse comparative est de savoir quelle tolérance doit supporter votre propre charge de travail. Par conséquent, analysez vos propres données avant d’examiner le nouveau système. Ainsi, si vous détectez un maximum de 56 Mo / s en période de pointe (sauvegardes?), Sachant que la matrice de disques connectée au SAN pousse «seulement» 110 Mo / s sous des charges de pointe simulées, vous pouvez assuré que la limite ne sera pas le canal I / O.

Lors de la vérification d'une nouvelle matrice de disques, j'ai effectué ce type de test de performances. La nouvelle matrice utilisait des disques SATA au lieu des disques Fibre Channel (SCSI) et je devais m'assurer que cela fonctionnerait dans notre environnement. J'étais profondément dubitative. Mais après la caractérisation, j'ai découvert que le nouveau système avait suffisamment de surcharge d'E / S en période de pointe pour suivre le pic mesuré sur les disques plus fiables. Ça m'a étonné.

Si je charge des tests sur ces disques SAN, est-ce que cela me donne une mesure fiable et reproductible de ce que je verrai quand nous irons en direct? (en supposant que le logiciel SAN puisse "configurer dynamiquement" différemment à différents moments).

En raison de la nature partagée des baies de disques connectées au SAN, les performances varient d'une semaine à l'autre. Si vous savez déjà à quelle heure votre charge d'E / S est maximale, effectuez une série de tests de charge à l'heure de la journée au cours de laquelle votre charge d'E / S est maximale. De cette façon, vous pourrez mieux caractériser le type de surcharge d'E / S disponible pendant les périodes qui vous intéressent le plus. Les tests de charge en dehors des périodes de pointe vous donneront une idée de la rapidité avec laquelle les choses vont se produire, mais les tests de pointe vous donner de véritables limites en vérifiant.

Des E / S lourdes dans une partie du SAN (par exemple le serveur Exchange) ont-elles un impact sur mes serveurs SQL? (en supposant qu'ils ne donnent pas de disques dédiés à chaque serveur, on m'a dit qu'ils ne le sont pas)

Si les LUN Exchange partagent des disques avec vos LUN SQL, ils le feront absolument. Nous utilisons des EVA HP, pas des XP, mais je pense qu’ils utilisent la même terminologie "groupe de disques". Les LUN du même groupe de disques partagent des disques, et par conséquent se disputent les E / S sur ces périphériques physiques. Plus vous placez de disques dans un groupe de disques, plus la baie doit disposer d'une marge de manœuvre suffisante pour gérer les E / S. Les baies (du moins les EVA le font, et je suppose que les XP les plus onéreux en font de même) distribuent les blocs de LUN logiques sur les disques physiques de manière non séquentielle. Cela lui permet de faire ce que vous suggérez, à savoir répartir de manière dynamique des groupes de blocs fréquemment utilisés sur différents périphériques physiques afin d'accroître le parallélisme et de réduire les conflits d'E / S au niveau du disque.

La question à se poser est de savoir quel est le budget d'E / S de ce groupe de disques et si les applications utilisant ces LUN sont sursouscrites pour les E / S. C'est une question que les administrateurs de stockage devront suivre. Il se peut que les E / S de pointe pour Exchange (probablement pendant les sauvegardes) ne coïncident pas avec les charges SQL, et que les deux systèmes puissent coexister de manière heureuse.

Demander la séparation des lecteurs logiques pour différentes fonctions des lecteurs logiques (données vs journaux vs tempdb) serait-il utile ici? Le réseau SAN verrait-il les différentes activités IO sur ceux-ci et les configurerait-il différemment de manière optimale?

Pour les matrices HP, vous devez placer les différents modèles d'E / S dans différents groupes de disques , et non pas de LUN. Les modèles d'E / S de base de données ne doivent pas coexister avec les modèles d'accès de serveur Web, par exemple. Les différents LUN n'améliorent pas votre performance de manière marquée, sauf s'ils se trouvent dans des groupes de disques différents. S'ils font partie du même groupe de disques, le seul avantage réel réside dans le système d'exploitation, qui peut effectuer une planification des E / S dans le noyau pour améliorer le parallélisme du sous-système de disque. Cela dit...

À ma connaissance, les baies HP prennent en compte différents modèles d’accès sur les LUN, mais portent une attention particulière aux blocs logiques réels. Le fait de placer les journaux sur un autre LUN impose une limite aux blocs logiques générant ce type de trafic d'E / S, ce qui facilite la tâche de tri correct des blocs logiques sur les disques physiques.

Nous sommes un peu dans une pénurie d'espace en ce moment. On demande aux équipes d'application de supprimer les archives de données, etc. Les problèmes d'espace obligent-ils l'équipe SAN à prendre des décisions différentes sur la manière de configurer le stockage interne (niveaux RAID, etc.) pouvant avoir une incidence sur les performances de mon serveur?

Absolument. Si l'espace est restreint, vous n'obtiendrez pas de groupes de disques dédiés pour vos E / S (à moins que votre environnement de stockage ne soit suffisamment grand pour justifier de réserver 7 To de disque physique à votre usage exclusif, ce qui pourrait bien être le cas. ). Le débat Raid5 / Raid10 dépend en grande partie de la politique de l'organisation et demander est votre meilleur choix.

Je suggère d'ouvrir un dialogue avec votre équipe SAN et votre fournisseur pour répondre à vos préoccupations. L’un des problèmes que vous allez rencontrer avec vos propres tests de performance est que vos tests n’ont peut-être pas d’incidence sur ce qui se passe en production, en particulier aux pointes de charge. La plupart des réseaux de stockage disposent de tonnes de cache sauvegardé par batterie, ce qui dans de nombreux cas (en particulier lorsque vous exécutez des tests de performances synthétiques) signifie que vous écrivez dans la RAM et obtenez des performances exceptionnelles.

En fonction de votre environnement et de la solution que vous utilisez, il se peut que certains fournisseurs CE aient récemment intégré le réseau SAN et configuré celui-ci selon la norme qu'il préfère. Cela se produit plus que vous ne le pensez. Vous allez devoir éliminer le shell "l'équipe de SAN connaît tout" jusqu'à ce que vous ayez l'assurance que la solution répond à vos besoins.

Bonne chance.

Une fois, j'étais à une conférence Oracle avec un exposé sur ce sujet: un SAN sain pour les bases de données.

Le résumé de la présentation est disponible dans ce fichier PDF ou sur le site de l'auteur ici