Je recherche des conseils sur la meilleure façon de configurer mes disques / partitions pour SQL Server. Voici quelques-unes de mes principales préoccupations:
Comment séparer les fichiers SQL (fichiers de données, journaux, temp)?
Est-il préférable de mettre en RAID beaucoup de disques durs et de partitionner l'espace ou de créer plusieurs RAID avec moins de disques pour chaque RAID?
Les données et les fichiers journaux doivent-ils être sur un type de RAID différent?
Les bases de données par défaut (master, msdb, etc ...) doivent-elles être situées sur le C: ou doivent-elles être au même endroit que les autres fichiers de données / journaux?
sql-server
raid
partition
Sean Howat
la source
la source
C'est une grande question «ça dépend».
Je ne peux pas répondre à la question de savoir comment créer les tableaux RAID individuels pour vous, car je ne suis pas un expert en stockage, mais je peux vous aider avec le reste.
La première chose à considérer est la charge de travail sur les différentes bases de données - OLTP (lecture / écriture) ou DSS / DW (lecture-principalement). Pour les charges de travail en lecture / écriture, vous devriez envisager RAID 1 ou RAID 10 (RAID 1 + 0), car ils offrent une redondance et de grandes performances de lecture / écriture. Pour les charges de travail principalement en lecture, vous pouvez utiliser RAID 5. La raison pour laquelle RAID 5 ne doit pas être utilisé pour les charges de travail en lecture / écriture est que vous payez une pénalité de performances sur les écritures.
Les journaux de transactions, de par leur nature même, sont en lecture / écriture (ou surtout en écriture, selon que vous utilisez le journal de transactions pour quelque chose - par exemple, des sauvegardes de journaux ou une réplication) et ne doivent donc jamais être placés sur RAID 5.
Cela signifie que pour certaines bases de données et charges de travail, vous pouvez avoir des fichiers de données sur RAID 5 et des fichiers journaux sur RAID 1/10, et pour d'autres bases de données, vous pouvez avoir tout sur RAID 1/10. Pour aller plus loin, si vous avez une base de données partitionnée, elle peut contenir des données en lecture et en lecture / écriture, peut-être même dans la même table. Cela peut être divisé en groupes de fichiers séparés, puis chaque groupe de fichiers est placé sur un niveau RAID approprié.
La séparation des bases de données réelles dépend à nouveau de la charge de travail et des capacités du sous-système d'E / S sous-jacent - un degré de séparation plus élevé peut être requis pour stocker des éléments sur des matrices RAID individuelles que sur un SAN, par exemple.
Tempdb est un cas particulier à lui tout seul, car il s'agit généralement d'une base de données lourdement chargée et doit être stocké séparément des autres bases de données. Les bases de données système ne doivent pas être fortement utilisées et peuvent être placées n'importe où tant qu'il y a redondance.
Voici un lien vers un livre blanc que j'ai aidé à rédiger et qui devrait vous aider: Physical Database Storage Design . Assurez-vous également que votre sous-système d'E / S peut gérer la charge de travail prévue - consultez ce livre blanc: Meilleures pratiques d'E / S avant le déploiement . Enfin, assurez-vous que vous utilisez la taille de bande RAID correcte (généralement 64 Ko ou plus sur les systèmes plus récents), la taille d'unité d'allocation NTFS correcte (généralement 64 Ko) et que sur les systèmes antérieurs à Windows Server 2008, vous définissez correctement le décalage de la partition de disque . Pour plus d'informations sur ces derniers, et des pointeurs vers plus d'informations à leur sujet et pourquoi vous devez les configurer de cette façon, consultez cet article de blog: Vos décalages de partition de disque, les tailles de bande RAID et les unités d'allocation NTFS sont-ils correctement définis? .
Ligne Bototm: connaissez votre charge de travail et vos capacités de sous-système d'E / S, puis implémentez-les en conséquence.
J'espère que cela vous aide.
PS En ce qui concerne tempdb, c'est une grosse boîte de vers sur la façon dont vous devez le configurer et il y a toutes sortes d'informations contradictoires. J'ai écrit un article de blog complet sur la configuration des fichiers de données tempdb à Misconceptions autour de TF 1118 .
la source
La réponse courte pour les serveurs que j'ai configurés a toujours été
Journaux sur des disques physiques distincts, raid 1 ou 10 (agrégat par bandes + mise en miroir)
Base de données sur ses propres disques, en fonction des besoins de performances, généralement RAID5
Beaucoup de cache sur les contrôleurs de raid
De préférence, collez à nouveau votre système d'exploitation et votre fichier d'échange Windows sur un tableau séparé, généralement juste un miroir (Raid 1). Cela garde toutes les opérations d'écriture séparées afin que les performances élevées ne traînent pas tout.
Ce que j'ai expérimenté dans le passé, c'est qu'avoir des écritures de base de données + des écritures de journal + des écritures de fichier d'échange va enliser un tableau Raid5 et les performances iront à l'encontre d'un panier à main. Le problème est que vos performances seront bonnes en test, en développement, etc.
la source
Il y a beaucoup mieux de gars MSSQL ici que moi, mais en termes généraux, je suggère ce qui suit;
Système d'exploitation et code sur C: - il doit s'agir des disques locaux, d'une paire de baies RAID1 - nous utilisons pour cela 2 disques SAS 146 Go 10 krpm de 2,5 pouces, mais vous pouvez utiliser 2 disques SATA 7.2. Les données doivent être sur une matrice RAID 1/10, 5/50/6/60 assez rapide (10krpm ou mieux) de la taille dont vous avez besoin - nous détenons les nôtres sur des FC SAN LUN, généralement sur un groupe de disques de 'niveau 2' / 10krpm . Les journaux doivent se trouver sur une paire de baies RAID 1 TRÈS RAPIDE (15krpm) petite (10 Go ou moins?) - nous détenons les nôtres sur des FC SAN LUN, généralement sur un très petit groupe de disques 'tier1' / 15krpm ou sur un 'tier0' / groupe ssd.
Quoi qu'il en soit, vous voulez que chaque morceau de ceux-ci sur des broches / baies distinctes pour les performances - bien sûr, tout cela fonctionnera sur un seul disque, mais je suppose que vous recherchez un équilibre entre performances et coût.
Nous stockons notre master / tempdb avec nos bases de données régulières, mais vous pouvez le diviser en un LUN de tableau de données distinct.
J'espère que cela t'aides.
la source