Configuration de lecteur optimale pour SQL Server 2008R2

19

J'ai un serveur de base de données assez occupé exécutant SQL Server 2008 R2 qui a la configuration suivante:

SATA RAID 1 (2 disques) - OS / Programmes
SAS RAID 10 (4 disques) - Fichiers de base de données SQL (données et journaux)
SAS RAID 1 (2 disques) - TempDB (données et journaux)

En supposant que je ne peux pas ajouter de lecteurs supplémentaires à ce serveur, ai-je fait le meilleur usage de la configuration dont je dispose? Ou devrais-je envisager un autre schéma ici où les journaux sont isolés des fichiers de données, par exemple?

Mise à jour:

Pour ceux qui ont demandé plus de détails sur le matériel:

Les disques SATA (utilisés pour la partition OS / Program) sont: WD 7200 RPM 3 Gb / s 3,5 pouces SATA
Les disques SAS utilisés dans les autres baies sont: Seagate 15K RPM 6 Gb / s 3,5 pouces SAS
Le contrôleur RAID utilisé est: un port LSI 9260-8i SAS / SATA 6 Gb 8

Mise à jour 2:

Sur la base des commentaires que j'ai reçus, il semble que j'ai les options viables parmi lesquelles choisir - je vais attribuer la prime à quelqu'un qui peut me dire ce qui est probablement le meilleur dans l'environnement que j'ai décrit:

Laisse tout tel quel - je ne ferai probablement pas beaucoup mieux
Déplacer mes 2 disques SAS RAID 1 dans ma matrice RAID 10 existante pour qu'elle soit composée de 6 disques au total
Déplacer mes fichiers journaux sur le SAS RAID 1 et / ou réinstaller TempDB (données ou journaux) sur le RAID 10

sql-server hardware

— DanP
source

Votre 2e mise à jour pose exactement les mêmes questions que votre question d'origine, donc la réponse d'origine s'applique. "... qui est probablement le meilleur dans l'environnement que j'ai décrit" ... vous ne nous avez montré aucune analyse de la charge de travail, juste qu'elle est "assez occupée", donc encore la même réponse s'applique .

— Mark Storey-Smith

Avec NVMe hautes performances et d'autres disques SSD sur le marché, le RAID n'est plus très important du point de vue des meilleures pratiques de configuration de disque du serveur SQL . Les pools de disques (espaces de stockage) sont la voie à suivre. Cependant, vous devez séparer logiquement les volumes afin de mieux résoudre les problèmes de performances liés au disque.

— Faces Of IT

14

Des variantes de cette question apparaissent semi-régulièrement:

Il y a aussi des combats occasionnels de petits pains sur la "meilleure pratique" de séparation des données / journaux.

Sans une analyse plus détaillée de ce que fait ce serveur, le même conseil s'applique que celui donné précédemment.

RAID 1 pour OS
RAID 10 (6 disques) pour les données / journaux / tempdb

Il y a rarement un point dans une scission avec si peu de broches disponibles. Une baie unique avec une plus grande capacité d'E / S absorbera généralement les blocs et les bosses de votre charge de travail mieux que 2 baies plus petites.

Une variante qui mérite d'être testée est de mettre tempdb sur le lecteur du système d'exploitation. Ne le faites que si vous disposez d'une charge de travail représentative que vous pouvez relire à plusieurs reprises, afin de garantir une comparaison équitable de la configuration. Si vous optez pour cet arrangement en production, assurez-vous que la croissance de tempdb est limitée afin de ne pas consommer par inadvertance tout l'espace libre sur le lecteur du système d'exploitation.

Étant donné que vos lecteurs OS sont des sous-verres à 7200 tr / min, je serais surpris si la configuration de tempdb sur le lecteur OS offrait un quelconque avantage.

— Mark Storey-Smith
source

7

Tout dépend de votre charge de travail, mais avec seulement 6 disques, cela limite vos options. Si votre charge de travail ne dépend pas fortement de tempdb pour des choses telles que les tris, les tables de hachage et l'isolement de cliché, alors vous feriez mieux d'utiliser les 6 disques SAS ensemble en RAID 10. Cependant, si vous connaissez ou avez les mesures pour prouver que tempdb est fortement utilisé, alors vous devriez le garder séparé comme vous l'avez fait.

— Patrick Keisler
source

Merci pour la réponse, changer la configuration des gammes n'est (malheureusement) pas une option car ce serveur est en production. Je suis curieux de repasser le tempdb sur le RAID 10 et de mettre tous les fichiers journaux sur le RAID 1 - est-ce une option intelligente?

— DanP

2

N'oubliez pas que SQL Server doit écrire physiquement toutes les transactions dans le journal dans le cadre de la validation, vous voulez donc les performances d'écriture les plus rapides possibles dans votre configuration. RAID 10 offre de meilleures performances d'écriture que RAID 1, donc je laisserais les journaux sur le volume le plus rapide.

— Patrick Keisler

2

Cela dépend beaucoup de ce que vous entendez par «très occupé»: différents modèles de charge de travail (écriture lourde ou non, opérations en masse courantes ou non, niveau d'accès simultané, pour ne nommer que trois des nombreuses variables) peuvent avoir un effet drastique sur la performance de tout arrangement de broche donné.

Pour une situation d'écriture lourde, la séparation des journaux des données peut faire une différence significative car chaque écriture implique la mise à jour du journal et des fichiers de données, ce qui implique une bonne quantité de retournement de tête supplémentaire si les deux ensembles de fichiers sont sur le même ensemble de broches .

Sans autre référence à votre charge de travail (et aux spécifications de ces disques et de tout contrôleur qui se trouve entre eux et la machine), je serais enclin à opter pour trois volumes: un pour les programmes OS + et tempdb (données), un pour la base de données principale données et le troisième pour les journaux (à la fois tempdb et DB principaux).

Bien sûr, si vos charges de travail sont toutes très légères sur les opérations d'écriture, vous ne devriez pas passer trop de temps à vous soucier de garder les données et les journaux séparés, car cela fera peu de différence de performances et leur consacrer un volume entier serait assez inutile. espace.

— David Spillett
source

Je décrirais certainement notre environnement comme un environnement "d'écriture lourde" - je mettrai à jour ma question avec des spécifications matérielles plus détaillées lundi.

— DanP

Une idée du nombre de disques que OP a? Je pense plus au Raid 1 qu'il a pour les fichiers journaux. Cela ne semble pas être une excellente option à des fins d'écriture, et les fichiers journaux AFAIK ne sont pas limités en lecture, mais écrivent ..

— Marian

J'ai ajouté des spécifications supplémentaires sur le matériel de la machine.

— DanP

1

Ce malentendu peut être à l'origine de nombreuses diatribes de séparation des données / journaux, donc excuses, mais je vais le rappeler. "... car chaque écriture implique la mise à jour du journal et des fichiers de données" - non, ce n'est pas le cas. Les écritures sur les pages de données se produisent au point de contrôle, pas à chaque modification.

— Mark Storey-Smith

1

@DavidSpillett Certes, il y aura toujours des cas où la division sera bénéfique. La clé est que vous avez testé et validé que la configuration était bénéfique pour cette charge de travail particulière.

— Mark Storey-Smith

2

La réponse réelle dépend de vos besoins, mais en général, "mettre des données et se connecter sur des tableaux différents" est plus important que "mettre tempdb sur son propre tableau".

Compte tenu du nombre de disques dont vous disposez, mon point de départ serait:

Deux disques, RAID 1 - Système d'exploitation, exécutables, fichier d'échange.
Quatre disques, RAID 5 - Tous les fichiers de données (alternativement, RAID 1 + 0)
Deux disques, RAID 1 - Tous les fichiers journaux

Ce que vous devez faire est d'utiliser SQLIO pour tester les performances de différentes configurations de disques.

— Marcheur de Greenstone
source

Cela représente certainement "l'autre côté" des conseils que j'ai lus. Je souhaite qu'il y ait une méthode définitive pour déterminer laquelle des options serait la meilleure sans recourir à "l'essayer" dans un environnement de production.

— DanP

2

@DanP Eh bien, personnellement, j'aurais suivi les conseils de Mark et choisi un RAID10 avec le reste des disques (sauf OS). Les fichiers journaux nécessitent beaucoup d'écriture et nécessitent de meilleures performances que ce que RAID 1 a à offrir, pour autant que j'y pense. Mais je ne suis pas un expert en matériel. Juste mes 2 cents.

— Marian

2

Je dois mentionner que mon opinion ne vient que de l'expérience d'une migration (en quelque sorte) passée vers un meilleur serveur, mais avec de moins bonnes performances. Nous n'avons jamais testé une charge réelle sur ce nouveau serveur, nous n'avons jamais eu de chance, le serveur n'était pas prêt à temps. Il s'avère que le test du serveur AVANT la migration vers la production doit être OBLIGATOIRE. Désolé pour l'accent. Donc, mon mantra pour toutes les migrations / mises à niveau est: TEST, TEST, TEST, ... freaking test autant que possible.

— Marian

1

Je ne sais pas s'il faut commencer par RAID 5 ou SQLIOSIM ... allons-y avec le plus tard car le premier parle de lui-même. SQLIOSIM est un outil de test d'exactitude et de stress , ce n'est pas un outil de test de performance ou de charge. Il n'a absolument aucune place pour comparer les performances de config-X par rapport à config-Y pour workload-Z. Tout ce qui vous dirait est la performance de config-X par rapport à config-Y dans une exécution SQLIOSIM. Si vous souhaitez comparer les performances de workload-Z, testez workload-Z.

— Mark Storey-Smith

1

@GreenstoneWalker "RAID1 est plus rapide à écrire que RAID1 + 0" est absurde. D'où est venue cette idée?

— Mark Storey-Smith

-1

Selon l'utilisation que vous faites de la base de données (OLTP vs entreposage), votre configuration ressemble à une bonne configuration générale. Si vous aviez plus de disques, vous auriez plus d'options.

Vous pourriez obtenir de meilleures performances si vous commutiez le disque de votre TempDB sur RAID 0 (stripe). Cela augmente le risque d'échec, mais comme TempDB ne met en mémoire tampon que les données, vous ne pouvez pas subir de perte de données. La plupart des gens considèrent donc que c'est un compromis raisonnable. Gardez simplement un disque de rechange (ou un disque de secours).

Une chose que vous n'avez pas mentionnée, mais que vous pourriez essayer (si vous ne l'avez pas déjà fait): Microsoft recommande de diviser votre TempDB en plusieurs fichiers (un par CPU). Bien sûr, il est préférable qu'ils soient sur des disques séparés, mais simplement avoir des fichiers séparés aide. http://msdn.microsoft.com/en-us/library/ms175527(v=SQL.105).aspx

— TimG
source

4

Tempdb est utilisé pour beaucoup de choses, mais ne le traitez pas comme une base de données jetable et ne le placez pas sur un RAID 0. Gardez à l'esprit que si ce volume RAID 0 échoue, SQL Server ne pourra pas démarrer.

— Patrick Keisler

J'ai en effet créé un db temporaire par cœur comme suggéré, mais merci d'avoir soulevé ce point également :)

— DanP

1

Eh bien, ces suggestions ne sont pas très bonnes et ne conviennent pas à tous les environnements. Le premier est mentionné plus tôt par @PatrickKeisler. Le second est un mythe que Paul Randal a démystifié il y a quelque temps. L'article est celui-ci: Un mythe SQL Server DBA par jour: (12/30) tempdb devrait toujours avoir un fichier de données par cœur de processeur . La documentation MS peut donc être erronée, ne la prenez pas par cœur.

— Marian

2

"puisque TempDB ne met en mémoire tampon que les données, vous ne pouvez pas subir de perte de données" ... et je suis sûr que les utilisateurs du système apprécieront que pendant les X heures de temps d'arrêt, ils souffrent pendant que a) les ops creusent dans le sous-sol pour une disque de remplacement ou b) un DBA essaie d'expliquer au helpdesk comment déplacer tempdb depuis son téléphone portable.

— Mark Storey-Smith