Règles d’installation de base (épisode 1)

C’est par là qu’on commence… à faire des bêtises en général. SQL Server, c’est facile, on clique, suivant, suivant et hop c’est fini.

Hélas, ce n’est pas plus facile qu’un autre SGBD. C’est juste plus facile de se tromper. Voici quelques règles de bases lorsqu’on s’apprête à installer un SQL Server en production. Episode 1: le matériel.

1) La machine: physique ou virtuelle ?
Le gros débat des mois à venir. Même si la plupart des clients vont conserver des machines physiques pour leurs bases critiques, il y aura des bases de prod, uat, dev, qualif moins critiques qui seront virtualisées.
Les constructeurs (Dell, HP,…) sortent de plus en plus des chassis dédiés à la virtualisation, avec ESXi embarqué. La virtualisation est (heureusement ? maheureusement ?) un train en marche, et plutôt que de freiner des quatre fers, posons-nous la question “comment virtualiser”, parce qu’il ne faut pas se voiler la face, on va y venir de toutes façons, ce n’est qu’une question de temps. HYPER-V et ESX sont tous les deux de bons concurrents, et ESX est annoncé compatible avec les produits MS. La combinaison des technos aujourd’hui (full virtualisation + assistance matérielle) fait que l’overhead de performances se réduit de plus en plus (on est quasiment en CPU-direct sur les Intel-VT et les AMD-V). Je penche personnellement pour le raw device mapping, une assistance matérielle CPU et une configuration mémoire appropriée. Dans quelques temps nous aurons un ESX ou deux et nous pourrons tester tout ça.

2) Admettons, machine physique:
LE PRIX ! Franchement les configurations à moins de 8000€ sont assez répandues et fiables. Je pense au HP Proliant DL 580 G5 (2×4 Xeon 3Ghz, 4Gb RAM, 2 cartes 1ge et 16 slots disque pour $7600) ou au très populaire Dell PowerEdge 2950 III (même config mais avec seulement 6 slots disques pour $3600).

DEDIEE/MUTUALISEE: en fonction des moyens. Mais idéalement il faut une machine dédiée. Les petits budgets vont faire tourner IIS et SQL Server sur la même machine, et d’expérience, c’est un mauvais calcul. Il vaut mieux investir un peu plus dans deux machines, et on aura moins de soucis ensuite.

CPU: le plus de cores il a sous le coude, et le mieux il se porte, SQL Server. Il est multithreadé, il sait parralléliser ses traitements. Evidemment il faut partir directement en 64 bits (EM64T, IA64, AMD64). Attention les éditeurs commencent à revoir leur politique de licence par socket, ils perdaient trop d’argent avec les hexacores et certains commencent à limiter à 6 cores par socket. Et attention à ne pas activer l’hyperthreading sur les machines SQL Server.

MEMOIRE: Oublier le 32 bits, la version 2008 de Windows Server sera la dernière à être proposée dans ce mode. En 64 bits, et avec le prix de la DDR2, il ne faut pas lésiner. C’est encore plus important que la CPU. Plus le cache de données est gros, moins SQL Server fera de lectures physiques.

RESEAU: Ca dépend. Je suis intervenu chez un client DRM il y a quelques temps et là le réseau c’était VRAIMENT crucial. Ca va le devenir de plus en plus avec FILESTREAM, la spatialisation, la vidéo HD, le plus de données on stocke, et le plus de données on va faire transiter. Les cartes et les core switches en 10Ge sont là, les Jumbo Frames, donc tout ça suit derrière. Le réseau entre systèmes Production / Secours est aussi crucial (Database mirroring, réplication). Nous avons un client en database mirroring 2005 qui avait installé un lien 100Mb entre ses deux sites, il va passer en fibre car il a de plus en plus de choses à faire passer sur le lien en plus du streaming lié au DB mirroring (sauvegardes, recopies de fichiers, etc…). Autre exemple, un client qui a une réplication transactionnelle entre Frankfort et Londres, le lien est vraiment très lent, et la resynchro de répli (34Gb) se fait en moyenne en 10-12 heures.
Mais si l’application est codée en procédures stockées, que la quantité de données qui transite n’est pas importante et que SQL server est standalone, alors une carte 100Mb/s devrait faire l’affaire.

DISQUES: tout le monde ne peut pas se payer un SAN, je pense aux petites PME du web avec 1 machine serveur, un IIS et une base de données de production, avec des moyens modestes. Donc on va considérer deux configurations: les disques internes pour les petits, et le stockage en réseau pour les riches et la classe moyenne.
– DISQUES INTERNES: choisir du SAS en 15KRPM. Le disque pour la base de données, c’est le nerf de la guerre. Le HP DL580 G5 avec ses 16 slots est parfait, il permet de faire trois RAID10 (data, log, backup) et un RAID1 (système) et de garder deux slots de spare. Il faudra vérifier au niveau de l’interface du contrôleur SAS que celui-ci est bien sur batterie et que celle-ci est valide, et que la politique est en write-through, c’est à dire que le cache du contrôleur n’est pas utilisé en écriture. Les disques SAS 73 Gb 15KRPM sont à 330€ chez Dell en 2’5, ça ne vaut pas le coup de se priver.
– STOCKAGE RESEAU: ne pas utiliser de NAS au sens strict (attachement réseau), pas de CIFS, ce n’est pas supporté de base par SQL Server. Il faut que les disques soient vus comme des disques locaux, donc soit une baie avec un attachement direct, soit un SAN. Pour les riches, le SAN en fibre channel est à privilégier. Pour la classe moyenne, le iSCSI est un bon moyen de faire du SAN à moindre coût, à la condition d’utiliser sur la machine hôte un initiateur matériel et non logiciel, c’est à dire une carte 1Ge qui soit compatible TSO (TCP Segmentation Offload, calcul de la pile TCP déchargée du CPU hôte), et que le réseau soit dédié au stockage. Pour les disques SAN, même politique que les disques internes. Au niveau du choix de la baie, il faut regarder plusieurs choses: Le nombre de storage processors (va déterminer le multiplexage des entrées, il en faut au moins 2), la taille du cache par storage processor et non en globalité, le nombre de slots pour les disques, la capacité globale. Le plus important c’est la taille du cache par SP. Si les caches entre SP sont mirrorés l’un sur l’autre, on perd la moitié de la capacité mémoire, si la baie est mirorrée sur une autre, on perd encore car le soft de miroir utilise des buffers dans le cache de chaque SP. Ensuite, il faut voir comment le cache est partitionné entre les lectures et les écritures. Le plus souvent, c’est fait à la louche pour des systèmes majoritairement en lecture, mais attention à ne pas négliger les écritures en transactionnel. Un cache en écriture plein, et les queues se remplissent au niveau des SP, on observe des outstanding IOs côté SQL Server et c’est rapidement la cata.

Il paraît que je fais des articles trop longs, donc ce sera tout pour aujourd’hui 😉
Prochain épisode, l’installation Windows et les prérequis SQL Server.

A+ [ David B. ]

Continuez votre lecture sur le blog :

• Règles d’installation de base (épisode 2) (David Baffaleuf) [SQL ServerVintage]
• Stocker ses bases de données dans un Azure Blob Storage : l’impossible dilemme ? (Capdata team) [AzureSQL Server]
• Bench avec NetApp / Datacore / ESX (David Baffaleuf) [SQL Server]
• Production SQL Server : banalisation des instances (Benjamin VESAN) [SQL Server]
• Haute disponibilité d’Oracle database sous Windows : et pourquoi pas Fail Safe ? (Capdata team) [Oracle]