Comment dois-je configurer la matrice RAID de disques SSD sur mon serveur SQL?

14

Je construis un serveur SQL avec 48 Go de RAM, 1 processeur et 8 disques SSD SATA III (6 Go / s) (128 Go Crucial m4) et un contrôleur LSI MegaRAID (SAS 9265-8i). Je m'attends à ce que la charge de travail typique soit principalement lue. Il y aura des périodes d'activité d'écriture plus intense (synchronisation des données toutes les heures avec des fournisseurs de données tiers - sauvegardes nocturnes), mais je pense que le rapport de lecture / écriture typique est d'environ 90% de lectures / 10% d'écritures.

Option 1:
Disque logique C: - RAID 1 (2 disques physiques) - Disque
logique du système d'exploitation D: - RAID 10 (6 disques physiques) - Fichiers DB / journaux / tempdb / sauvegardes?

OU

Option 2:
Disque logique C: - RAID 1 (2 disques physiques) - Disque
logique OS D: - RAID 1 (2 disques physiques) - Fichiers Db Disque
logique E: - RAID 1 (2 disques physiques) - fichiers journaux / sauvegardes?
Disque logique F: - RAID 1 (2 disques physiques) - tempdb

OU

Option 3:
Autres suggestions?

Je pense que l'option 1 me donnerait de meilleures performances, car toute l'activité de la base de données serait répartie sur 3 disques (et reflétée sur les 3 autres de la matrice), bien que l'option 2 semble imiter la sagesse conventionnelle (qui semble s'appliquer davantage aux mécaniques lecteurs que SSD). Il semble que Stack Overflow soit parti avec l' option 1 .

Je suppose qu'avec les disques SSD, il est OK de tout mettre sur un seul lecteur logique car votre serveur est probablement plus contraint par le processeur que par les E / S à ce stade?

Une autre question que j'ai est de savoir où dois-je placer les sauvegardes nocturnes? Nous ne voulons pas que les sauvegardes ralentissent le reste du serveur SQL, et je suppose que l'écriture des sauvegardes au même emplacement que les journaux est une bonne pratique car le comportement de lecture / écriture dans ces deux cas est une écriture séquentielle.

sql-server configuration

— Robbie
source

J'ai cru une fois qu'il y avait des avantages à la distribution logique, mais après quelques recherches assez approfondies (Michael peut en avoir encore), nous sommes arrivés à la conclusion que la distribution logique au niveau cible n'a pas amélioré les performances. Donc, si nous parlions d'un disque physique (en rotation) et que vous vouliez 8 fichiers de données afin de tirer parti de l'affinité de base, peu importait qu'ils soient 8 fichiers sur un seul volume logique (sur le même disque physique) ou si vous coupez 8 partitions logiques pour ces 8 fichiers (sur le même disque physique). Je pense que vous le trouverez similaire coupant logiquement votre SSD

— Eric Higgins

9

La sagesse conventionnelle sur le RAID ne s'applique pas bien aux SSD. Ils n'ont pas vraiment besoin de striping (RAID0). Ils sont sujets aux pannes de par leur conception, mais RAID-1 n'est généralement pas la bonne réponse pour les SSD pour deux raisons: a) est un gaspillage, réduit de moitié la capacité de la matrice SSD (et ils sont coûteux) et 2) les caractéristiques des pannes des SSD conduisent vers les deux disques dans le miroir pour échouer à des intervalles très proches (c.-à-d. défaillances corrélées) et ainsi rendre l'ensemble de la baie inutilisable. Voir RAID différentiel: repenser le RAID pour la fiabilité des SSD pour une discussion plus longue. Certains ont recommandé d'utiliser Raid-6 pour les SSD.

En outre, la sagesse conventionnelle de la disposition des fichiers SQL Server ne s'applique pas aux SSD. Je vous recommande de regarder SQL sur les SSD: Hot and Crazy Love et de parcourir les liens de référence dans cette réponse .

— Remus Rusanu
source

Bon point, avec RAID 10, je suis probablement plus vulnérable aux pannes corrélées. Merci pour le lien RAID différentiel.

— Robbie

8

L'approche standard consistant à séparer les modèles d'E / S aléatoires pour les données de la séquence des journaux ne s'applique tout simplement pas aux SSD, donc je choisirais votre option 1 avec des mises en garde:

Les sauvegardes DOIVENT être effectuées sur une machine distincte. Il est inutile d'avoir des sauvegardes auxquelles vous ne pouvez pas accéder en cas de fumée du serveur.
Il y a une certaine valeur à séparer les lecteurs de données et de journaux de sorte qu'une défaillance de la matrice de données vous permette d'effectuer une sauvegarde de journal.
N'oubliez pas que vous n'avez pas de disque de rechange.
N'oubliez pas que vous disposez de disques de niveau consommateur. Ne présumez pas qu'ils seront aussi fiables que les équivalents de l'entreprise à des coûts multiples.
Regardez le SQL divertissant et très instructif sur les SSD: Hot and Crazy Love par Brent Ozar.

La question de la séparation des journaux des données lorsque des disques SSD sont utilisés est une question de RPO (objectif de point de récupération) pour le système, plutôt que de performances. Si le RPO est défini en quelques minutes, utilisez une baie partagée et effectuez des sauvegardes de journal toutes les [RPO] minutes. Si le RPO est défini en quelques secondes, utilisez des tableaux séparés.

Pour être honnête, si le RPO était serré, je garderais les SSD pour la matrice de données et j'utiliserais une paire miroir de spinners fiables (d'entreprise) pour le journal.

— Mark Storey-Smith
source

Les sauvegardes sont également copiées sur une machine distincte. Ils sont créés sur la machine locale afin que je puisse utiliser SQL Compare / Data Compare et annuler les modifications en cas de régression / erreur utilisateur.

— Robbie

De plus, le RPO est défini en minutes (je pense que même dans les 10 minutes, ce serait acceptable pour que mon scénario soit complètement honnête). Le post Hot & Crazy Love me fait penser à des échecs corrélés. Dans mon expérience limitée, j'ai eu plus de pannes de la carte mère et de pannes totales du système (alimentation / surtension qui fait tout frire) que des pannes de disque, donc j'essaie toujours de déterminer quel serait le niveau de paranoïa / prévention le plus rentable.

— Robbie

1

Vous devriez choisir l'option 2 comme suit:

Logical Drive - RAID 1 (2 physical drives)
 1 partition C: OS
 2 partition D: backups / log files
Logical Drive E: - RAID 1 (2 physical drives) - DATA files
Logical Drive F: - RAID 1 (2 physical drives) - INDEX files
Logical Drive G: - RAID 1 (2 physical drives) - tempdb

En séparant vos données et vos index dans 2 fichiers de données différents qui sont ensuite stockés dans 2 lecteurs logiques physiques différents, vous gagneriez une énorme augmentation du disque io simplement parce que lorsque vous interrogez, vous auriez un disque en rotation pour vos données de table et un autre tourner pour votre index en même temps.

Laissez également tempdb séparé de vos sauvegardes, car il se passe également beaucoup de choses. Ne mélangez pas vos sauvegardes et votre fichier de données. même si les sauvegardes ne sont pas effectuées quotidiennement, lorsqu'elles se produisent, elles prennent un énorme coup sur votre E / S. en fonction de votre entreprise et de l'utilisation de votre base de données, certaines personnes ou BEAUCOUP de personnes peuvent se plaindre pendant la sauvegarde.

J'espère que cela t'aides

— Nicolas de Fontenay
source

6

Absurdité. Ce sont des SSD, pas des spinners.

— Mark Storey-Smith

pas absurde même avec sdd il y a un certain nombre de performances atteintes de cette façon, mais pas autant.

— Nicolas de Fontenay

2

Même avec des filateurs, la séparation des données des index n'a aucune valeur jusqu'à ce que vous jouiez sur le territoire SQLCAT. Le cas de la séparation de tempdb n'est également jamais clair et s'applique très très rarement avec un si petit nombre de disques.

— Mark Storey-Smith