Sa pratique standard consiste à séparer les fichiers journaux et de données pour séparer les disques du système d'exploitation (tempdb, sauvegardes et fichier d'échange également). -ils ne sont qu'une partie du nombre x de disques sur le SAN et le LUN est juste une allocation d'espace
Réponses:
Les journaux et les lecteurs de données ont des modèles d'accès aux données différents qui sont en conflit les uns avec les autres (au moins en théorie) lorsqu'ils partagent un lecteur.
Écritures de journal
L'accès aux journaux consiste en un très grand nombre de petites écritures séquentielles. De façon un peu simpliste, les journaux de base de données sont des tampons en anneau contenant une liste d'instructions pour écrire des éléments de données vers des emplacements particuliers sur le disque. Le modèle d'accès consiste en un grand nombre de petites écritures séquentielles qui doivent être garanties pour être terminées - elles sont donc écrites sur le disque.
Idéalement, les journaux devraient être sur un volume RAID-1 ou RAID-10 silencieux (c'est-à-dire non partagé avec autre chose). Logiquement, vous pouvez afficher le processus comme le SGBD principal écrivant les entrées de journal et un ou plusieurs threads de lecteur de journal qui consomment les journaux et écrivent les modifications sur les disques de données (en pratique, le processus est optimisé pour que les écritures de données soient écrites immédiatement si possible). S'il y a un autre trafic sur les disques de journal, les têtes sont déplacées par ces autres accès et les écritures de journal séquentielles deviennent des écritures de journal aléatoires. Celles-ci sont beaucoup plus lentes, donc les disques de journal occupés peuvent créer un hotspot qui agit comme un goulot d'étranglement sur l'ensemble du système.
Écritures de données
(mis à jour) Les écritures de journal doivent être validées sur le disque (appelées supports stables) pour qu'une transaction soit valide et éligible à la validation. On peut logiquement voir cela comme des entrées de journal en cours d'écriture, puis utilisées comme instructions pour écrire des pages de données sur le disque par un processus asynchrone. Dans la pratique, les écritures de page de disque sont réellement préparées et mises en mémoire tampon au moment de l'entrée du journal, mais elles n'ont pas besoin d'être écrites immédiatement pour que la transaction soit validée. Les tampons de disque sont écrits sur un support stable (disque) par le processus Lazy Writer (Merci à Paul Randal de l'avoir signalé) que cet article de Technet décrit un peu plus en détail.
Il s'agit d'un modèle d'accès très aléatoire, donc le partage des mêmes disques physiques avec des journaux peut créer un goulot d'étranglement artificiel sur les performances du système. Les entrées de journal doivent être écrites pour que la transaction soit validée, donc avoir des recherches aléatoires ralentissant ce processus (les E / S aléatoires sont beaucoup plus lentes que les E / S de journal séquentielles) transformeront le journal d'un séquenital en un périphérique d'accès aléatoire. Cela crée un sérieux goulot d'étranglement des performances sur un système occupé et doit être évité. Il en va de même lors du partage de zones temporaires avec des volumes de journaux.
Le rôle de la mise en cache
Les contrôleurs SAN ont généralement de grands caches RAM, qui peuvent absorber le trafic d'accès aléatoire dans une certaine mesure. Cependant, pour l'intégrité transactionnelle, il est souhaitable que les écritures sur disque à partir d'un SGBD soient garanties. Lorsqu'un contrôleur est configuré pour utiliser la mise en cache en écriture différée, les blocs sales sont mis en cache et l'appel d'E / S est signalé comme terminé à l'hôte.
Cela peut atténuer de nombreux problèmes de contention, car le cache peut absorber une grande partie des E / S qui, autrement, iraient sur le disque physique. Il peut également optimiser les lectures et écritures de parité pour RAID-5, ce qui diminue l'effet sur les performances des volumes RAID-5.
Ce sont les caractéristiques qui animent l'école de pensée «Laissez le SAN s'en occuper», bien que cette vision ait certaines limites:
La mise en cache en écriture différée a toujours des modes de défaillance qui peuvent perdre des données, et le contrôleur s'est infiltré dans le SGBD, disant que les blocs ont été écrits sur le disque alors qu'ils ne l'ont pas fait. Pour cette raison, vous ne souhaiterez peut-être pas utiliser la mise en cache en écriture différée pour une application transactionnelle, en particulier quelque chose contenant des données stratégiques ou financières où les problèmes d'intégrité des données pourraient avoir de graves conséquences pour l'entreprise.
SQL Server (en particulier) utilise les E / S dans un mode où un indicateur (appelé FUA ou Forced Update Access) force les écritures physiques sur le disque avant le retour de l'appel. Microsoft a un programme de certification et de nombreux fournisseurs de SAN produisent du matériel qui respecte cette sémantique (exigences résumées ici ). Dans ce cas, aucune quantité de cache n'optimisera les écritures sur disque, ce qui signifie que le trafic de journaux se bloquera s'il se trouve sur un volume partagé occupé.
Si l'application génère beaucoup de trafic disque, son jeu de travail peut dépasser le cache, ce qui entraînera également des problèmes de contention d'écriture.
Si le SAN est partagé avec d'autres applications (en particulier sur le même volume de disque), le trafic provenant d'autres applications peut générer des goulots d'étranglement de journal.
Certaines applications (par exemple les entrepôts de données) génèrent de grandes pointes de charge transitoires qui les rendent assez antisociaux sur les SAN.
Même sur un grand SAN, des volumes de journaux distincts sont toujours recommandés. Vous pouvez vous en tirer sans vous soucier de la mise en page d'une application peu utilisée. Sur les très grandes applications, vous pouvez même bénéficier de plusieurs contrôleurs SAN. Oracle publie une série d'études de cas de mise en page d'entrepôt de données dans lesquelles certaines des configurations les plus importantes impliquent plusieurs contrôleurs.
Mettez la responsabilité de la performance à sa place
Sur quelque chose avec de gros volumes ou lorsque les performances peuvent être un problème, responsabilisez l'équipe SAN pour les performances de l'application. S'ils vont ignorer vos recommandations de configuration, assurez-vous que la direction en est consciente et que la responsabilité des performances du système est au bon endroit. En particulier, établissez des directives acceptables pour les statistiques de performances de base de données clés comme les attentes d'E / S ou les attentes de verrouillage de page ou les SLA d'E / S d'application acceptables.
Notez que la responsabilité de la performance répartie entre plusieurs équipes crée une incitation à pointer du doigt et à renvoyer la balle à l'autre équipe. Il s'agit d'un anti-modèle de gestion connu et d'une formule pour les problèmes qui traînent pendant des mois ou des années sans jamais être résolus. Idéalement, il devrait y avoir un seul architecte habilité à spécifier les modifications de configuration de l'application, de la base de données et du SAN.
Évaluez également le système sous charge. Si vous pouvez l'arranger, les serveurs d'occasion et les tableaux à connexion directe peuvent être achetés à bon marché sur Ebay. Si vous configurez une boîte comme celle-ci avec une ou deux baies de disques, vous pouvez bricoler avec la configuration du disque physique et mesurer l'effet sur les performances.
À titre d'exemple, j'ai fait une comparaison entre une application s'exécutant sur un grand SAN (un IBM Shark) et une boîte à deux sockets avec une matrice U320 à connexion directe. Dans ce cas, 3 000 £ de matériel acheté hors d'eBay ont surpassé un SAN haut de gamme de 1 M £ par un facteur de deux - sur un hôte avec une configuration de processeur et de mémoire à peu près équivalente.
À partir de cet incident particulier, on pourrait affirmer qu'avoir quelque chose comme ça traîner est un très bon moyen de garder les administrateurs SAN honnêtes.
Je suppose que la balise Equallogic et le contenu de la demande signifient que vous envisagez un SAN Equallogic. Ce qui suit concerne spécifiquement Equallogic et ne s'applique pas aux autres types de SAN.
Avec les baies Equallogic, les disques spécifiques utilisés pour les volumes ne peuvent pas être spécifiés aussi précisément qu'ils le peuvent avec, disons, les baies EMC Clariion, donc l'approche doit être un peu différente.
L'architecture Equallogic est très automatisée et dynamique. Son bloc de construction de base est l'unité de baie et non les packs / groupes RAID dans une baie comme on le voit dans d'autres SAN. Chaque baie est entièrement configurée pour RAID 5, 6, 10 ou 50, bien que cela n'implique pas qu'il n'y ait qu'un seul groupe RAID par baie, vous ne pouvez jamais décider ou interagir avec eux à ce niveau. Vous mettez des tableaux dans des pools de stockage et vos pools appartiennent alors à un groupe de stockage. Le groupe de stockage possède une adresse IP de cluster \ virtuelle que vous utilisez comme cible de découverte iSCSI pour tous les volumes de ce groupe - le logiciel de gestion du groupe EQL et la pile MPIO hôte gèrent la redirection de niveau IP nécessaire pour réellement acheminer vers le port le plus approprié sur les tableaux individuels lors de la demande de blocs de données, mais c'est quelque chose que vous avez peu ou pas de contrôle.
Les volumes de stockage sont attribués à partir de l'espace libre total dans chaque pool. Tous les volumes d'un pool sont répartis sur toutes les baies de ce pool (jusqu'à un maximum de 4 baies distinctes) afin de distribuer les E / S réseau sur le nombre total d'interfaces réseau (2 à 4 par baie Eql selon le modèle) et les E / S sur autant de contrôleurs que possible. Le logiciel de gestion Equallogic surveille les performances du volume \ de la baie au fil du temps et optimise dynamiquement la distribution des blocs entre les baies membres. En général, à moins que vous ne sachiez ce que vous faites, vous devez mettre toutes les baies dans un seul pool et le laisser faire son travail, n'oubliez pas de vous assurer de configurer vos disques haute vitesse (SAS 10k \ 15k) avec RAID 10, vitesse moyenne avec RAID 50 ou 5 afin de garantir que le processus d'optimisation choisit réellement les vrais disques haute performance.
Pour une approximation approximative, vous aurez quelque part entre 2500-5000 IOP par baie PS en fonction du type de lecteur et du type RAID. Si vous fournissez suffisamment d'IOP au total, le processus de gestion automatisé devrait finalement vous donner de bonnes performances même si vous regroupez simplement tous les volumes dans un seul pool.
Cependant, si vous voulez garantir que vos journaux, bases de données, magasins temporaires, lecteurs de système d'exploitation, etc. sont réellement isolés les uns des autres, vous pouvez faire quelques choses. Tout d'abord, vous pouvez définir une préférence RAID pour un volume qui garantira que le volume spécifique est toujours stocké uniquement sur des matrices de ce type RAID (si elles sont présentes dans le pool auquel le volume appartient). Deuxièmement, vous pouvez définir des pools de stockage hiérarchisé qui ne contiennent que des baies qui fournissent les différents niveaux de performances dont vous avez besoin pour ce niveau particulier, puis répartir vos volumes dans les pools appropriés. L'avertissement de santé qui accompagne cette approche est que vous aurez généralement besoin de beaucoup de baies pour que cela fournisse réellement de meilleures performances globales - ce qui peut être moins important pour vous que de garantir les performances sur vos volumes critiques, même si c'est souvent le meilleur choix. L'architecture de référence de Dell pour Oracle DB utilise un pool avec 2 baies RAID 10 pour les données, le disque de vote et l'OCR, et un pool séparé avec une seule baie RAID 5 pour la zone de récupération flash.
À tout moment avec Equallogic, vous devez vous demander si les décisions que vous prenez concernant le partitionnement forcé vont fournir de meilleures performances globales pour vos volumes en termes d'interfaces réseau disponibles, de broches de disque et de contrôleurs. Si vous ne pouvez pas répondre à cela, optez pour le nombre minimum de piscines et laissez-le gérer les détails ou demandez à un spécialiste Equallogic de faire une vraie conception. Si vous n'avez qu'un seul tableau, vous ne pouvez rien faire pour séparer les volumes.
Nous stockons nos bases de données sur des boîtiers SAN uniques, mais avec des données distinctes, des LUN de journal et de sauvegarde, chacun sur des groupes de disques différents, hiérarchisés en fonction de la vitesse - avec nos journaux sur des LUN RAID 10 à 15 000 tr / min, des données sur des LUN RAID 1 à 10/15 000 tr / min et une sauvegarde sur RAID 5 LUN à 7,2 km / min. Nous présentons également des journaux et des données via différents contrôleurs sur le même SAN.
Grande question!
Jetez d'abord un œil au débat de Brent Ozar sur "Steel Cage BlogMatch" sur cette question.
Dans notre entreprise, pour la plupart des serveurs, nous mettons les données et les journaux sur le même lecteur SAN et nous laissons le soin à l'équipe SAN de s'assurer que tout fonctionne correctement.
Je commence à penser que ce n'est pas la meilleure stratégie, en particulier pour les serveurs à volume élevé. Le problème sous-jacent est que je n'ai vraiment aucun moyen de vérifier que l'équipe SAN fait vraiment autre chose que de regrouper suffisamment de disques pour l'espace dont nous avons besoin. Nous n'exécutons pas de benchmarks IO contre les disques SAN de notre côté ou quoi que ce soit, nous supposons simplement qu'ils "font leur travail" (en ajustant les performances ainsi que l'espace), ce qui est probablement un peu naïf.
Mon autre pensée est que le type d'accès dont les données et les journaux ont besoin est différent. Je vais essayer de trouver l'article que j'ai lu récemment qui parlait de la façon dont les deux types de lecteurs différents devraient vraiment être optimisés de manière très différente (je pense que l'un avait besoin d'une optimisation pour les écritures séquentielles, l'autre d'une optimisation pour les lectures aléatoires, quelque chose comme ça .)
En bref, oui, vous devez créer des volumes distincts pour les fichiers de données SQL Server, les fichiers journaux et les données et fichiers journaux TempDB.
Puisque vous avez étiqueté votre question avec Equallogic, veuillez lire le Guide d'architecture de référence Dell gratuit: Déploiement de Microsoft® SQL Server® avec les matrices de stockage Dell ™ EqualLogic ™ série PS5000 (inscription requise) avant de concevoir votre solution. Vous constaterez souvent que les conseils sur des configurations spécifiques peuvent différer considérablement des conseils génériques .
Je serais d'accord avec BradC (+1) en termes de performances. En général, un bon SAN aurait plus d'E / S brutes que vous ne pourriez en attendre.
C'est toujours une bonne idée de séparer vos SAUVEGARDES de votre système en direct (Évidemment, je sais, mais si j'avais un £ 1 pour chaque fois que je vois cela ...)
Il est également recommandé de garder tempdb éloigné des fichiers journaux. La tente du gars du SAN pour lever les yeux sur vous lorsque vous commencez à vouloir "différents compartiments" (terme technique) pour les journaux, les données et la température, mais si vous leur dites que c'est pour que vous puissiez évaluer la quantité différente d'E / S de données allant dans chaque zone et Demandez-leur de vous montrer leurs graphiques de performances fantaisistes!
Il suffit de vérifier deux fois / deux que le gars du SAN l'a bien configuré pour vous. Si vous voulez du RAID 10, insistez dessus (je l'ai fait) même s'ils ont continué à dire que leur RAID 5 n'avait aucune pénalité en termes de performances.
(Pour les opérations "basées sur des fichiers", RAID 5 est très bien. Pour les écritures intensives, dès que vous remplissez le tampon d'écriture, votre vissé!)
Soyez conscient de tous les mélanges de termes ici aussi.
Généralement et très basique:
Vous pouvez avoir plusieurs volumes sur le même tableau, ce qui est quelque chose à retenir lorsque vous effectuez des optimisations de haut niveau abordées dans ce fil.
La clé est ce que plusieurs autres ont mentionné (ne l'oubliez pas), séparer les données / journaux / sauvegardes sur différentes broches de lecteur, pas seulement des volumes séparés.
Edit: et Helvick ci-dessus vous a donné une bonne réponse sur les SAN Equallogic!