Discussion :

[Jinroh77]

Bonjour à tous,
Je précise que ces question se posent dans le cadre de base décisionnel, cela ne devrait pas changer énormément les réponses..

La question se porte sur les disques durs à utiliser pour une instance SQL, dans le cadre où (comme souvent) les budgets ne sont pas extensibles à l'infini et on évite le mode avec 10 disques dur dans un serveur...

Je dois donc installer des serveurs, en x64, avec une certaine quantité de ram, de core etc. Mais la question des disques dur reste...
Je dois avoir

• 1 instance SQL Server (BDD de data, system, ReportServer et TmpReportServer)
• 1 instance SSAS (BDD de cube OLAP, sous forme de multiples fichiers)
• 1 instance SSRS (dont les BDD sont précisées juste au dessus)

La première idée des clients est de mettre un SAN pour placer les bases SQL. Personnellement je suis contre. utilise 1 LUN SAN seul pour mettre dessus les data, log, system, temp etc. est a mon sens du grand n'importe quoi.
Première question, comment leurs expliquer et justifier ???

Ensuite, que proposer de fiable ?
Un SAN particulièrement paramétré (couteux ?) ? ou des disques particulièrement bien organisé sans en compter 10 non plus...) ?
Comment expliquer les différences de performance, avantages/inconvénients etc.

Les questions sont un peu, beaucoup ouvertes, mais le débat est large il me semble. Bien que beaucoup de réponse se trouvent un peu partout, les avis divergent.

[SQLpro]

Dans le cas d'un décisionnel le disque dur n'est pas l'élément prépondérant. L'élément le plus important étant dans ce cas la RAM et mieux vaut qu'il y en ais beaucoup !

Lisez les articles que j'ai écrit à ce sujet :
1) les disques : http://blog.developpez.com/sqlpro/p8...t-le-stocakge/
2) la RAM (paragraphe 1) :
http://sqlpro.developpez.com/optimisation/2/

En tout cas,
a) évitez les RAID 5, 6
b) alignez les partitions
c) alignez les LUN sur des disques physiques
d) séparez le journal des transactions des datas si vous êtes en ROLAP

A +

[mikedavem]

En sus car beaucoup de choses ont déjà été dit,

il faut dédier tempdb sur une LUN rapide. La base de données temporaire est sollicitée pour toutes les opérations de type DISTINCT, GROUP BY , ORDER BY .... à avoir avec la charge évidemment ..

Et puis le SAN a un autre avantage sur les disques locaux, par rapport à un infocentre qui aurait tendance à enfler: on peut rajouter des disques

On peut également faire du provisionning qui est fort intéressant avec les SAN actuels

Il faut juste pouvoir imposer son point de vue, je sais que ce n'est pas facile et qu'on se heurte à beaucoup de préjugés ("on va pas mettre 146 Gb pour stocker des journaux de transaction de 6Gb", "nous on partitionne tout en RAID5", et le pire de tous: "de toutes façons il y a un cache sur la baie, c'est invisible pour la base de données")

Je vois qu'on est tous confronté aux mêmes problèmes ...

++

[Jinroh77]

Merci pour ces premiers retour.
Si l'on arrive à faire avancer ce topic pour en faire un synthèse, ce sera avec plaisir.

Pour ce qui est de la ram dans un environnement décisionnel, en général, on arrive à en faire prendre beaucoup, ça ne coûte plus grand chose.
Le nombre de cœur est aussi important pour les lourds traitement SSIS, surtout si les différentes instances se retrouvent sur le même serveur.
Cela dépend beaucoup des données, mais 16Go et un octo-cœur n'est pas une exception.

Concernant les disques, pour un SAN, je ne connais pas vraiment le sujet mais à utiliser comme vous semblez le définir nécessite bien de paramètrer celui-ci de manière particulière, prévoir plusieurs LUN correctement préparés et associés comme il faut aux disque physique derrière.

La répartition s'envisage comme sur des disques physique différents, sauf que là on est sur des LUN ?


Le coût d'un tel paramétrage, matériel explose donc rapidement ?
Si cela n'est pas envisageable, autant donc utiliser des disques "classiques" en 15KRPM correctement réparti sur les RAID adéquats ?
On aura potentiellement plus de performances/fiabilité sur quelques disques classiques plutôt que sur 1 LUN unique ?

Considérer 1 LUN pour placer uniquement les Data SQL et des disques classique pour le reste (OS, autres instances, tempDB ) peut se révéler intéressant ?

[mikedavem]

Concernant les disques, pour un SAN, je ne connais pas vraiment le sujet mais à utiliser comme vous semblez le définir nécessite bien de paramètrer celui-ci de manière particulière, prévoir plusieurs LUN correctement préparés et associés comme il faut aux disque physique derrière.

Tout à fait ... car chaque LUN doit être préparé en fonction de la nature des IO pour faire rapide.

La répartition s'envisage comme sur des disques physique différents, sauf que là on est sur des LUN ?

Oui mais sur le SAN il n'y a pas que les disques à paramétrer pour vraiment faire de l'optimisation. Il y a les cartes HBA, les fabriques, les chemins, les cartes controleurs et l'architecture des disques ....

Le coût d'un tel paramétrage, matériel explose donc rapidement ?

Ce n'est pas le même prix mais on y gagne vraiment en robustesse et en évolutivité... à voir si cela en vaut la peine dans ton cas mais je suis persuadé qu'à terme cela peut devenir rentable .. mais vous n'allez pas investir dans un SAN simplement pour SQL Server ?

Si cela n'est pas envisageable, autant donc utiliser des disques "classiques" en 15KRPM correctement réparti sur les RAID adéquats ?
On aura potentiellement plus de performances/fiabilité sur quelques disques classiques plutôt que sur 1 LUN unique ?

Si il n'y a qu'un seul LUN effectivement il y a de grandes chances que les performances ne soient pas au rendez vous ..

Considérer 1 LUN pour placer uniquement les Data SQL et des disques classique pour le reste (OS, autres instances, tempDB ) peut se révéler intéressant ?

Personnellement je trouve que ce n'est pas intéressant dans ce cas. Il faudrait avoir au moins une LUN pour les DATA, une LUN pour les journaux et à ce moment là ca pourrait être intéressant dans le cadre d'un PRA où il y aurait une procédure de remontée rapide d'un serveur préalablement préparé en cas de crash. Ce serveur aurait un accès aux LUN des DATA et journaux. La base tempdb peut être en local, ce n'est pas gênant.

++

[Jinroh77]

Merci pour ces nouvelles réponses, c'est à peu près ce que j'attendais.
Je précise juste que je ne cherche pas une solution pour nous, mias plutôt une réponse propre et structurée à apporter aux différents clients contre qui je ne parviens pas à me battre avec les termes et benchs appropriés.

Pour le stricte minimum de 2 LUN, je note, ça peut être un compromis, toujours à valider en fonction des besoins.
Qu'est ce qu'un PRA ?

Je précise encore une fois que l'on et dans le cadre d'une base décisionnelle, les donnés sont donc importante mais le taux de disponibilité n'est pas autant cruciale qu'une base de production métier permettant la prise de commande etc. Nous sommes dans le cadre du reporting d'informations, de la veille principalement.

[dbaffaleuf]

Hello,

Je sens qu'il va être long ce post.

Partir sur un SAN n'est pas forcément une mauvaise chose. On peut faire plusieurs groupes de disques dans une baie SAN, ça ne pose aucun problème. Il faut juste pouvoir imposer son point de vue, je sais que ce n'est pas facile et qu'on se heurte à beaucoup de préjugés ("on va pas mettre 146 Gb pour stocker des journaux de transaction de 6Gb", "nous on partitionne tout en RAID5", et le pire de tous: "de toutes façons il y a un cache sur la baie, c'est invisible pour la base de données"). Et puis le SAN a un autre avantage sur les disques locaux, par rapport à un infocentre qui aurait tendance à enfler: on peut rajouter des disques.

Le nombre d'axes est impossible à déterminer comme ça en répondant sur un forum. Il y a trop de paramètres en jeu, et le plus important, il faut connaître la charge, les traitements, etc... Mais pour du décisionnel, il peut être intéressant de répartir les données sur plusieurs filegroups: on peut ensuite faire de la sauvegarde de filegroups, de la restauration partielle en ligne, partitionner des tables, etc...

Quelques règles simples:
- Séparer fichiers de données et journaux de transactions sur des axes physiques différents. Argument 1: pour des raisons de sécurité. Si tu as une corruption sur une partie des données, tu as toujours accès au journal et il t'est possible de récupérer les transactions non sauvegardées dans le journal. Deuxièmement pour des raisons de performance, parce que les accès sur les données et les journaux sont de nature différente, mais c'est un critère surtout important en OLTP. Mais même en décisionnel, des temps de service de 7-8ms sur les reads, ça ne fait pas de mal.
- Séparer les backups et les données, évidemment, donc ça nous fait déjà 3 axes.
- Tes traitements utiliseront-ils tempdb ? Si oui, beaucoup, alors prévoir peut être un axe en plus pour tempdb.
- Privilégier le SCSI, FC/SCSI si possible et sinon si iSCSI prévoir des initiateurs matériels ( = une carte HBA qui le supporte) plutôt que logiciels (windows iSCSI Software Initiator).
- Pour les disques privilégier le 15KRPM.
- RAID10 pour les données, RAID1 pour les journaux.

Avant de partir en prod, il est possible de benchmarker le sous-système IO avec des outils tels que sqliosim. (http://support.microsoft.com/kb/231619).

Autre chose, quid de la partie HA ? Si le problème de la redondance de machine se pose, et que soudainement il faudrait partir sur un cluster, avec des disques locaux ça ne va pas trop marcher.

Au suivant,

David B.

[SQLpro]

- RAID10 pour les données, RAID1 pour les journaux.

Et je rajouterai que ce serait l'inverse sur une base de données OLTP, car dans ce dernier cas on doit accélérer le débit transactionnel.

Enfin, mettre la journalisation en mode simple ou au moins BULK LOGGED n'est pas mal !

A +