Choix de l'organisation des disques [Résolu]

[Jinroh77]

Bonjour,
Je suis en train de proposer une configuration server pour héberger une BDD de 10go interrogée via Ssrs en Sql pour sortir des rapports relativement volumineux.

Le serveur est limité à 4 disques.

Comment les organiser au mieux selon vous ?

Au début j'avais pensé à ne pas faire de raid, et repartir de la manière suivante :
- os
- mdf utilisateur
- LDf utilisateur
- tempdb

Avec un bon plan de maintenance derrière.
Est ce mieux de faire autrement en considérant du raid pour couvrir un risque de défaillance sur les DD des db et si oui comment l'organiser ?

A l'écoute de vos conseils avisés.

[dbaffaleuf]

Je dirais deux RAID1 au minimum.
- Un RAID1 : OS + DATA+tempdb
- Un RAID1: Log + backups

C'est le minimum syndical et encore c'est discutable.

[Jinroh77]

Envoyé par dbaffaleuf

Je dirais deux RAID1 au minimum.
- Un RAID1 : OS + DATA+tempdb
- Un RAID1: Log + backups

C'est le minimum syndical et encore c'est discutable.

J'aimerai bien faire un peu plus sur les disques mais le serveur est limité à 4 disques.
Il est vraiment lus interessant de mettre du RAID 1 comme cela plutôt que mieux répartis en terme de puissant mais avec par contre un bon plan de maintenance derrière ?

[dbaffaleuf]

C'est à toi de voir. Si un des disques lâche, il n'est pas redondé, donc potentiellement corruption. Pire si c'est le disque sur lequel se trouvent les journaux, tu perds des transactions, donc perte de données irrécupérable (sauf à rejouer manuellement). C'est pour ça que je ne peux pas suggérer autre chose qu'un système à tolérance de panne quel qu'il soit.

[Jinroh77]

Ok pour cette configuration de tolérance de panne, par contre du coup au niveau de l'organisation des différents fichiers,
Lorsque ti dis TempDB sur le premier axe, il s'agit du .mdf et .ldf de la tempDB ou le .ldf de la tempDB se retrouve avec les autres Log ?
Ne serais-ce d'ailleurs pas préférable de mettre le .mdf de la TempDB sur le 2° axe, séparé des données desquelles sont extraites les données qu'elle doit traiter ?

Ce qui donnerai :
Axe 1 : RAID 1 de 2 disques avec : OS + .MDF
Axe 2 : RAID 1 de 2 disques avec : Log + tempDB (MDF+LDF) + backups

ou même :
Axe 1 : RAID 1 de 2 disques avec : OS + .MDF + tempDB.ldf
Axe 2 : RAID 1 de 2 disques avec : Log + tempDB.mdf + backups


Merci.

[dbaffaleuf]

Non je garderais les journaux physiquement séparés de tout fichier de données, l'intérêt est de séparer les accès aléatoires sur les fichiers de données des accès séquentiels sur les fichiers de journaux, pour minimiser le seek elevation sur le commit et le recovery. Cette problématique de localité de la donnée sur les disques est écrasée en général par les SANs et les caches, mais dans ton cas tu accèdes directement à des disques en write-through donc la mécanique va être pas mal sollicitée.

[dbaffaleuf]

+ autre avantage du RAID1, certains contrôleurs peuvent faire du load balancing sur les lectures, donc potentiellement un RAID1 est capable de tirer 2x le débit d'un seul disque sur la paire.

[Jinroh77]

Autre question alors, qui est de la répartition entre le mdf et le ldf de la tempDB ?
On les positionne de la même manière que les mdf et ldf des autres bases ?

Axe 1 : RAID 1 de 2 disques avec : OS + .MDF + tempDB.mdf
Axe 2 : RAID 1 de 2 disques avec : Log + tempDB.ldf + backups

[dbaffaleuf]

ouaip

[Jinroh77]

Parfait.
Merci beaucoup pour toutes ces précisions.

Je laisse ouvert le topic quelques jours histoire d'avoir peut-être un avis complémentaire.

Encore merci.

[mikedavem]

Personnellement je ferais la même chose que David.

2 RAID 1 augmentent diminuent vos chances de panne (tolérance plus forte). De plus il est préférable d'isoler les activités IO qui sont différentes entre les datas et les logs (RANDOM / asynchrones d'un côté et SEQUENTIAL / synchrone de l'autre)

++

[SQLpro]

Envoyé par dbaffaleuf

Non je garderais les journaux physiquement séparés de tout fichier de données, l'intérêt est de séparer les accès aléatoires sur les fichiers de données des accès séquentiels sur les fichiers de journaux, pour minimiser le seek elevation sur le commit et le recovery. Cette problématique de localité de la donnée sur les disques est écrasée en général par les SANs et les caches, mais dans ton cas tu accèdes directement à des disques en write-through donc la mécanique va être pas mal sollicitée.

je suis pas d'accord avec ton approche. Je croiserais les fichier data/JT entre les bases. En effet les IO sont continu sur les JT => //
Les IO sont sessionnés au même moment pour toutes les données, pour les datas. Donc //

A +

[mikedavem]

Oui mais si on croise les JT avec les DATA dans ce cas et si des accès sont requis en écriture à la fois sur tempdb et la base de données utilisateur cela risque de poser problème.

Les écritures sur les données d'une base (fichier de données) qui sont aléatoires risquent d'interférer avec celles qui doivent être faites sur les journaux de l'autre qui sont séquentielles.

Tête de lecture qui va d'un fichier de journal à un fichier de données et vis vers ca.. ce qui risque de ralentir le tout ... avec des modes d'écritures qui ne sont pas les mêmes ..

Je vois cependant un scénario où le fait d'avoir un fichier journal et un fichier de données ne poserait pas de problème : lorsque la base de données n'est pratiquement sollicité qu'en lecture .. je ne sais pas si c'est le cas de Jinroh77

++

[Jinroh77]

Envoyé par mikedavem

Je vois cependant un scénario où le fait d'avoir un fichier journal et un fichier de données ne poserait pas de problème : lorsque la base de données n'est pratiquement sollicité qu'en lecture .. je ne sais pas si c'est le cas de Jinroh77
++

C'est exactement cela.
La base de données est alimentée de nuit uniquement, ensuite, en journée, c'est uniquement de la lecture via Reporting Services. Il faut d'ailleurs que je place aussi les bases system et temp de SSRS.

En bref, il y a donc, sur la base utilisateur, de l'écriture de nuit et uniquement de la lecture en journée.
Le lecture se faisant pour du reporting, avec des jointures, du tri etc.

Je reprends quelque chose plutôt comme cela :
Axe 1 : RAID 1 de 2 disques avec : OS + tempDB.mdf + backups
Axe 2 : RAID 1 de 2 disques avec : .mdf + .ldf + tempdb.ldf

[Zabriskir]

Bonjour,

Moi je serais tenté de mettre les 4 disques en RAID 10.

@+

[zinzineti]

Envoyé par Zabriskir

Bonjour,

Moi je serais tenté de mettre les 4 disques en RAID 10.

@+

Tu peux argumenter un peu ?

Quel est le raisonnement qui peut conduire à ce choix ?

A+

[Jinroh77]

@Zabriskir : Pas plus de précision ?

Quelqu'un pour me répondre à la dernière précision ?
Sachant que la lecture et l'écriture de la base se font de manière totalement décalée, on peut considérer cela :
Axe 1 : RAID 1 de 2 disques avec : OS + tempDB.mdf + backups
Axe 2 : RAID 1 de 2 disques avec : .mdf + .ldf + tempdb.ldf

[dbaffaleuf]

dsl je persiste sur la séparation data / log. On pourrait effectivement comme dit Frédéric entrelacer les données et journaux des différentes bases, mais s'il n'y a qu'une seule base et sans mesure des temps de service dans les différentes configurations (via sqlio par ex), je partirai sur la logique de séparation quand même.

[Zabriskir]

@Zabriskir : Pas plus de précision ?

1. Pas une grosse base,
2. RAID 10 = bonnes performances en lecture/écriture. Peut-être qu'un seul axe physique performant vaut mieux que deux RAID 1.
Comme l'a dit dbaffaleuf, avec le RAID 1, on est même pas sûr de gagner en lecture.
3. Pas de risque de manque d'espace sur l'une ou l'autre des grappes car plus qu'une seule,
4. Pas de solution idéale dans notre cas.

@+

[mikedavem]

Aux données fourni par Jinroh77, je pourrais hésiter à mettre 2 grappes RAID 1 et 1 grappe RAID 10 comme le suggère Zabriskir.

Le RAID 10 est vraiment performant que ce soit en lecture ou écriture et dans le cas de Jinroh77 vu que chaque type d'activité est distinct (import la nuit et lecture le jour) on pourrait penser que l'activité sera ciblé principalement sur un type de fichier et donc en principe un mode de lecture.

Le RAID 10 permettrait également de pouvoir faire du provisionning par la suite sans avoir à tout casser (si bien sûr on reste sur le scénario décrit par Jinroh77).

Cependant on ne pourrait pas bénéficier d'opérations parallélisées (avec un thread dédié pour chaque axe disque par exemple).

Il faudrait pouvoir tester la configuration qui serait la mieux pour le scénario avec SQLIO comme le suggère également David.

Il faudra dans tous les cas penser à sizer la taille de bande du contrôleur RAID pour l'adapter à un fonctionnement optimale du sous système disque.


PS : En parlant des cartes contrôleurs RAID qui permettent de paralléliser les lectures sur du RAID 1, j'ai eu plus de précision. Visiblement celles-ci ne font pas réellement de la lecture parallèle sur les 2 disques mais va prendre le disque qui possède les données qui sont les plus proches de la tête à ce moment, ce qui permet de réduite le temps de latence globale.

++