Discussion :

[mikaeru]

Bonjour,
Pour une grosse DB de plusieurs centaines de GB.
Je pensais mettre mes fichiers dans des LUN différents selon la structure suivante :

C: system
E: Tempdb
F: Data
G: Data archive (partitionnement horizontal)
H: Index
I: Log.

Ma question serait, quelle RAID devrais je appliquer pour chacun de ces disques.

Merci.

[dbaffaleuf]

Ça dépend du nombre de disques disponibles par axe.

[mikaeru]

Bonjour,
Dans un monde idéal? Que me conseillerez-vous?

Je compte m'efforcer de m'y rapprocher .

Thanksssssss

[mikaeru]

Est ce qu'il y aurait un expert à l'ame charitable?

Voici comment je le ferai à l'heure actuel.
Log => Raid 10
Tempdb => Raid 10
Data (mdf) => Raid 5 ?
Indexes => Raid 5?
File stream => Raid 5 ?


Merci pour votre future aide

[mikedavem]

Bonjour,

Quel stockage derrière tout ca ?
Cartes RAID, SAN etc ...

++

[mikaeru]

Bonjour,

San => EMC

[dbaffaleuf]

Est ce qu'il y aurait un expert à l'ame charitable?

Voici comment je le ferai à l'heure actuel.
Log => Raid 10
Tempdb => Raid 10
Data (mdf) => Raid 5 ?
Indexes => Raid 5?
File stream => Raid 5 ?


Merci pour votre future aide

Il vaut mieux éviter le RAID5 si possible. Un RAID à parité impose que les écritures soient alignées et exactement de la taille du stripe or SQL Server utilise des tailles différentes en fonction du type d'action effectuée. Même si les contrôleurs modernes disposent d'algoritmes pour minimiser les problèmes de read-modify-write, si vous avez la possibilité de mettre un raid 10 à la place c'est mieux.

Et puis je ne suis pas sûr qu'un groupe de disques dédiés pour les indexes change grand chose. Je miserais plutôt sur plus de disques pour DATA+INDEXES plutôt que de séparer les deux.

[mikedavem]

Si vous pouvez éviter le RAID 5 cela est conseillé. Cependant il est vrai que les stockages de type SAN permettent d'absorder en partie les problèmes de performances liés au calcul de parité de ce type de raid en proposant des caches en écriture plutôt conséquents. En terme de lectures et en fonction du nombre de disques prévus vous pourrez avoir des performances quasi similaires en lecture.

Même chose que David concernant l'axe reservé aux indexes. Je fusionnerais les disques qui leur sont réservés pour les ajouter à la partition des datas et en faire un RAID 10 par exemple.

++

[SQLpro]

A lire : http://blog.developpez.com/sqlpro/p8...t-le-stocakge/

A +

[mikaeru]

Bonjour,
Merci pour vos info,
Je suis occupé à lire l'article et ce passage m'intrigue ::

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
 
Si maintenant je créé deux storages avec chacun un fichier et que dans l'un je place les tables et dans l'autre les index des mêmes tables, alors je favoriserait les écritures, mais aussi bien des lectures. En effet, une requête faisant souvent appel à de multiples tables, je peut aller chercher un index sur un storage pendant que le lit des lignes de table sur l'autre storage.

Juste à titre de confirmation , qu'est ce qui serait mieux.

• 2 disques RAID 5 (un data + un index)
• 2 disques RAID 5 (DATA et index sur chaque disque)
• 1 disque RAID 10

Bien entendu chacun sur un axe different en SAN EMC.

Merci pour vos lumière.

[Waldar]

Vous avez raté la conclusion :

la virtualisation des serveurs, comme l'utilisation du RAID 5 ou 6 agissent totalement en contraposition à l'ensemble des éléments que je viens de vous donner.

Pas de Raid 5 pour une base de données - et c'est vrai pour tous les SGBD !

[SQLpro]

Bonjour,
Merci pour vos info,
Je suis occupé à lire l'article et ce passage m'intrigue ::

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
 
Si maintenant je créé deux storages avec chacun un fichier et que dans l'un je place les tables et dans l'autre les index des mêmes tables, alors je favoriserait les écritures, mais aussi bien des lectures. En effet, une requête faisant souvent appel à de multiples tables, je peut aller chercher un index sur un storage pendant que le lit des lignes de table sur l'autre storage.

Une requête peut être multithreadé, c'est à dire avoir plusieurs process qui la traite simultanément. Mais pendant que je lit une table ou un index un process peut lire une autre table ou un autre index.
Si vos tables et index sont dans le même storage, alors en RAM c'est OK, mais les disques n'ayant qu'un seul bras de lecture... vous êtes coincé ! => accès séquentiel !
Si en revanche vous avez mis vos index d'un côté et vos table de l'autre (dans des disques PHYSIQUEMENT différents) alors vous êtes sauvé !

A +

[mikaeru]

Bonjour,
Ce serveur de production n'existe pas encore, donc je suis libre pour la gestion des disques mais étant donné le cout du raid 10.

Donc en gros je reviens sur ma question, en sachant que chaque disque sera sur un axe différent, est ce intéressent d'avoir un data file sur un disque différent pour les non clustered indexes?

Si pas de Raid 5, quel alternative ? (la DB ferait +- 400GB).

Merci encore pour vos points de vues

[mikedavem]

Oui cela peut être intéressant dans certains cas. Par exemple une requête qui implique l'usage des index non clusters et des données. L'opération peut être parallélisé.

En réalité il est dur de prévoir ce genre de comportement. C'est la raison pour laquelle il est préférable "d'optimiser" le stockage qui hébergera les datas et index.

Si pas de RAID 5 (et RAID 10) vous pouvez vous orienter au pire sur le RAID1. Les écritures seront plus rapides mais la lecture des données sera beaucoup moins performante.

++

[SQLpro]

Si pas de RAID 5 (et RAID 10) vous pouvez vous orienter au pire sur le RAID1. Les écritures seront plus rapides mais la lecture des données sera beaucoup moins performante.
++

Non c'est bénéfique aussi au lecture car il peut choisir l'un ou l'autre disque pour lire et donc les deux en //, à condition que le contrôleur en soit capable... Donc pas un serveur acheté à monoprix, mais du HP par exemple ! (en évitant le Dell et ses fameuses cartes PERC !!!)

A +

[mikedavem]

La lecture parallèle n'est pas vraiment parallèle en réalité comme on en discutait avec dbafalleuf. Le contrôleur va simplement choisir la tête la plus proche de la donnée ce qui va réduire le temps globale de recherche de la donnée.

Avec du RAID 1 on sera toujours limité à 2 disques alors que le raid 5 est beaucoup plus évolutif. On pourra améliorer le débit en lecture en augmentant le nombre de disques par exemple.

++

[Waldar]

Avec du RAID 1 on sera toujours limité à 2 disques

Non, le RAID 1 commence à partir de 2 disques, les limites hautes sont définies par le besoin, la qualité du contrôleur et bien entendu par le budget !

Le RAID 5 c'est le mal !

[mikedavem]

Tu as raison je rectifie on peut mettre plus de 2 disques dans une configuration miroir. Il y aura quand même au final 2 ensembles en miroir. On n'augmentera pas les performances en lecture vu qu'on ira chercher sur une grappe puis sur l'autre.

Le raid 5 a l'avantage de pouvoir utiliser tous les disques pour retrouver l'information.

Je ne dis pas que le RAID 5 est la meilleure solution mais dire que le raid 5 c'est le mal incarné est à mon sens exagéré. En fonction de la charge et du type d'activité cela peut s'avérer un choix raisonnable. Je prends pour exemple une base de données qui est sollicitée la plupart du temps en lecture : dans ce cas le RAID1 n'aidera pas aux performances contrairemen au RAID5

++

[dbaffaleuf]

+1

En fait avoir un filegroup pour les tables et indexes cluster d'un côté et un autre pour les indexes NC n'a d'intérêt que si les indexes NC sont non couvrants (ie SQL est obligé de faire des bookmark lookups) , non ? Et encore, je ne suis même pas sûr que SQL sache exécuter deux opérations en // (N workers sur un index NC Seek, N autres sur les RID LOOKUP / Clustered Index Seek Lookup en même temps).

[Waldar]

Je ne dis pas que le RAID 5 est la meilleure solution mais dire que le raid 5 c'est le mal incarné est à mon sens exagéré. En fonction de la charge et du type d'activité cela peut s'avérer un choix raisonnable. Je prends pour exemple une base de données qui est sollicitée la plupart du temps en lecture : dans ce cas le RAID1 n'aidera pas aux performances contrairemen au RAID5

Le RAID 5 c'est malheureusement le mal absolu.
Je cite wikipedia :

On a souvent tendance à croire qu'un système RAID 5 est totalement fiable. Il est en effet généralement admis que la probabilité de défaillance simultanée de plusieurs disques est extrêmement faible — on parle évidemment d'une défaillance entraînant la perte de données définitive sur plusieurs disques et non d'une simple indisponibilité de plusieurs disques. Cela est vrai pour une défaillance générale d'une unité de disque. Cependant, cela est faux si l'on considère comme "défaillance" un seul secteur devenu illisible.

En effet, dans la pratique, il est très rare que toutes les données d'un volume soient lues régulièrement. Et quand bien même ce serait le cas, la cohérence de la parité n'est que très rarement vérifiée pour des raisons de performances. Il est donc probable que des défauts tels que des secteurs de parité illisibles ne soient pas détectés pendant une très longue période. Lorsque l'un des disques devient réellement défectueux, la reconstruction nécessite de parcourir l'intégralité des disques restants. On peut alors découvrir des défauts qui étaient restés invisibles jusque-là.

Tout ceci pourrait ne pas être bien grave et occasionner la perte d'une quantité de données minime (un secteur de disque), cependant, l'extrême majorité des contrôleurs RAID est incapable de gérer les défaillances partielles : ils considèrent généralement qu'un disque contenant un secteur illisible est totalement défaillant. À ce moment-là, 2 disques sont considérés défaillants simultanément et le volume RAID 5 devient inutilisable. Il devient extrêmement difficile de récupérer les données, et extrêmement coûteux.

Évidemment tant qu'on n'a pas de problème de secteur, le RAID 5 paraît magique. Mais dès que les données deviennent inutilisables et non-reconstructibles, c'est une autre paire de manche.

Sur ce lien microsoft :

Raid5, Recommandated Use : Very good for Read only data.