SQL Server et architecture disques serveur, le point ?

**Jinroh77** · 27/03/2010, 10h46

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** · 27/03/2010, 16h57

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 +

**dbaffaleuf** · 27/03/2010, 17h01

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.

**mikedavem** · 27/03/2010, 17h09

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 ...

++

**SQLpro** · 29/03/2010, 15h49

Envoyé par dbaffaleuf

- 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 +

**Jinroh77** · 29/03/2010, 16h49

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** · 29/03/2010, 17h07

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** · 29/03/2010, 23h11

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.

**mikedavem** · 30/03/2010, 09h05

Qu'est ce qu'un PRA ?

Plan de reprise d'activité , plus connu sous sa dénomination anglaise en général Disaster Recovery Plan (DRP)

++

**Jinroh77** · 02/04/2010, 11h55

Je suis en train de préparer un petit récapitulatif, générique, et ordonné en fonction de la partie financière qui finalement peut jouer un rôle important.

Pour ce qui est des instances SSAS (en réalité sous forme de fichier, amis rapidement monté en RAM), si l'on considère
- des bases AS en MOLAP, alimentées 1 fois par nuit
- sans accès nécessaires aux bases SQL en journée : SSRS uniquement sur les cubes,
il est possible d'envisager l'instance AS sur le même LUN que les Data SQL ?
Ce n'est pas très safe mais peut être plus économique.

A partir du moment ou l'accès aux données se fait en parallèle aux cube et aux bases SQL (SSRS), il vaut mieux contraindre à la création d'un nouveau LUN pour les bases AS ?

**SQLpro** · 02/04/2010, 15h59

Si vous êtes économiquement juste, alors prévoyez un serveur plus faible au niveau du proc et mieux dimensionné en RAM. La RAM est prépondérante. Quand aux disque ce n'est qu'à l'alimentation et au processing du cube que cela sera sensible. Peu aux requêtes si la RAM est bien dimensionnée.

A +

**Jinroh77** · 02/04/2010, 17h33

Un bon SAN bien configuré (comme précisé précédemment), sinon des disques simple en 15krpm avec les bon RAID . Mais surtout beaucoup de RAM (pour la disponibilité des données) et de cœur de calcul (pour l'intégration).

**Jinroh77** · 09/04/2010, 12h10

Récapitulatif de la répartition des besoins disques et mémoire pour SQL Server et la suite décisionnelle.

Considérations générales

Minimum 8 cœurs et 16Go
- Facteurs de croissance
- - Taille des cubes
  - Complexité cubes
  - Nombres de bases SSAS
  - Nombre d’utilisateurs simultanés
SAN avec Data / Logs / backup / Data SSAS séparés
Taille du cube = 25% des tables de faits
Préférer du int pour les liaisons
Double d’espace du cube à prévoir au minimum sur le disque pendant le traitement.
Un disque de données SQL doit disposer de 33% d’espace libre.
La base doit être estimée à sa taille critique.
Les fichiers de journaux de transactions peuvent représenter plus de 40% de la taille de la base de données SQL.

Besoin et estimations communes aux différentes hypothèses

Windows Server 2008 Entreprise 64 bits.
Le 64 bits est indispensable pour traiter de forte volumétrie de données. En 32bits, les traitements sont limités à 2Go de mémoire.
Les pilotes vers les bases se feront de la manière suivante :
- SQL Server
  - Ensemble des connections disponibles nativement.
- Oracle
  - Drivers gratuit OLE_DB suffisamment fonctionnels en extraction de données.
- Progress
  - Seul des drivers gratuits existent en ODBC, une surcouche via un DSN est possible. Les possibilités sont relativement limitées (difficulté à utiliser des procédures stockées, variables etc.). Préférer des extractions simples depuis des tables ou vues.
  - Des drivers payant peuvent exister, cela sera à analyser en fonction des besoins d’extraction de ces bases.
En fonction de la volumétrie et du nombre de connections clientes (<300, > 300)
- Minimum 16Go, voire 32Go de RAM. C’est l’élément prépondérant de la config serveur.
- 8 ou 16 cœurs.
Il est difficile d’estimer la taille de la base de données mais on peut envisager plus de
- 300Go de données SQL.
- 100-150Go de journaux de transactions.
- 100Go de bases SSAS.

Version 1
Hypothèses

1 serveur unique.
Cube ROLAP traités plusieurs fois par jour.
Reporting utilisant les cubes et les données en base SQL.
Budget et connaissance paramétrage LUN disponible.

Besoins matériels et avantages

5 LUN de SAN pour disposer séparément :
- données SQL
- les journaux de transaction SQL
- la TempDB SQL
  - celle-ci étant particulièrement utiliser pendant les extractions via Reporting Services en SQL ou les temps d’alimentation des cubes.
- données SSAS
- les backups SQL / SSAS
Il est possible de ne pas utiliser de LUN pour les backups mais plutôt un disque simple, à condition que celui-ci soit sécurisé et/ou redondé.

L’avantage est la flexibilité de la solution. Il est alors aisément possible augmenter la taille des disques. La fiabilité est également accrue.

Version2
Hypothèses

1 serveur unique.
Cube ROLAP traités plusieurs fois par jour.
Reporting utilisant les cubes et les données en base SQL.
Budget et connaissance paramétrage LUN plus restreint.

Besoins matériels et avantages

Utiliser des disques en 15KRPM en distinguant de la même manière Data / Log / backup / Data SSAS. Ajouter des disques supplémentaires pour la TempDB si possible, celle-ci étant particulièrement utiliser pendant les extractions via Reporting Services en SQL.
Monter les disques en RAID 10 pour les données, RAID 1 pour les journaux. Eviter le RAID 5.

**zinzineti** · 09/04/2010, 12h41

Envoyé par Jinroh77

Oracle
Ensemble des connections disponibles nativement.
Drivers gratuit OLE_DB suffisamment fonctionnels en extraction de données.

Seul des drivers gratuits existent en ODBC, une surcouche via un DSN est possible. Les possibilités sont relativement limitées (difficulté à utiliser des procédures stockées, variables etc.). Préférer des extractions simples depuis des tables ou vues.
Des drivers payant peuvent exister, cela sera à analyser en fonction des besoins d’extraction de ces bases.

Merci pour ce retour intéressant.
Juste une petite précision sur le driver OLE_DB pour ORACLE.
Microsoft propose d'utiliser le driver ATTUNITY pour les connections à la base ORACLE (Microsoft Connectors for Oracle and Teradata by Attunity). Il est gratuit. Il n'y a pas longtemps Microsoft à acheter la société Teradata.
Et ce driver est disponible gratuitement ici

A+
Etienne ZINZINDOHOUE