Une fois le matériel commandé, livré, déballé, racké, etc…, il va falloir installer Windows et SQL Server. Là encore il va falloir regarder certains détails de près :

Paramétrage de Windows Server:

Préparation des disques:

On l’a dit dans l’épisode 1, le disque c’est le nerf de la guerre. Je vais donc apporter un soin particulier à la configuration de mes axes.

Pour placer sur disque une base de données transactionnelle, on essaie de considérer deux règles de base:

• Toujours séparer physiquement le fichier de données du journal de transactions: pour deux raisons. La première pour la sécurité des données: si je perds mon disque de données, j’ai besoin d’avoir accès au journal pour récupérer les dernières transactions validées mais pas encore prises par le backup log. La seconde pour des raisons de performances: le critère qui pèse le plus dans le temps de service d’un disque, c’est le déplacement de la tête au dessus de la bonne piste (seek time). Les accès aux données sont de nature aléatoire et donc augmentent cette latence de recherche. En revanche, les accès sur le journal sont séquentiels, donc limitent le seek time car une fois la tête positionnée sur la bonne piste / bon secteur, elle glisse tranquillement pour lire (recovery) ou écrire (commit / checkpoints) sur les secteurs adjacents. Mélanger les deux, ça plombe les accès au journal, et sur une instance OLTP, on sait que l’accès en écriture sur le journal est critique car il conditionne le temps de réponse du commit.

• Toujours séparer physiquement les données des sauvegardes: pour une raison évidente de sécurité des données, mais il faut y penser avant d’avoir un problème. Et par défaut jusqu’en SQL Server 2005, tout allait dans ~MSSQL\Data et ~MSSQL\Backup.

Séparer physiquement, ça veut dire PAS sur les mêmes disques. Ce n’est pas parce que j’ai trois lecteurs E:\, F:\ et G:\ que j’ai trois disques, il faudra le vérifier avec la console de gestion des volumes (diskmgmt.msc) et avec votre ami l’administrateur système en charge du stockage pour vérifier s’il ne vous a pas refilé 3 LUNs découpées dans le même diskgroup. Si je reprends mon Proliant DL 580 G5  avec ses 16 slots:

Je me paye même le luxe d’avoir un RAID10 pour placer mes filegroups d’indexes, comme sur Oracle. Cela dit, la bagarre va être rude parce que tout le monde pense que l’espace disque est gâché, surtout pour ce qui concerne les journaux de transactions, où on va utiliser peut être 20% de l’espace alloué. Mais il faut le voir comme un investissement. Vous aurez des temps de service garantis de moins de 4 ms en écriture sur le commit, et le nombre de transactions par seconde va en bénéficier. C’est une réalité, on voit des exemples de ce type régulièrement chez nos clients. 

Une fois les axes définis et montrés à la machine, la première chose va être de partitionner le disque en alignant sur le 128ième secteur (=64K), sous diskpart:

diskpart> create partition primary align=64

Globalement, il faut savoir que jusqu’en version 2003 incluse, Windows continue de préréserver les 63 premiers secteurs d’un disque pour y stocker son MBR (master boot record). Lorsque l’on va formater ensuite le file system en 64K, le premier offset va commencer réellement sur le 63ième secteur et décaler les clusters NTFS de 512 octets (1 secteur). il faut que les écritures de SQL Server (64K) soient alignées avec le début de la partition. Pour davantage d’infos, voir l’article de David BARBARIN sur le sujet.

En deux étapes:

• Partitionner le disque en alignant sur le 128ième secteur.
• Puis créer un FS en NTFS avec un cluster size de 64K pour les disques de données et de journaux.

Il faudra aussi aller vérifier que la politique d’écriture est bien en write-through au niveau du cache du contrôleur disque. Cet exemple sous OpenManage:

Paramètres noyau de Windows pour SQL Server:

Pas grand chose à faire dans 99% des cas. Il faut valider que le bail (quantum en anglais) par thread est bien de type ‘long’ dans les performances avancées de la machine (Poste de Travail -> Properties -> Advanced -> Performance -> Advanced):

Background services => chaque thread a le droit de s’exécuter pendant 12 ticks d’horloge avant d’être interrompu par le Dispatcher.  Par défaut sur la gamme Server, le radiobutton doit être sur background services (quantum = 12 ticks d’horloge) et sur la gamme workstation, sur Programs (quantum = 2 ticks d’horloge). En général pour tous les SGBD, le quantum doit être plus long pour limiter le nombre de changements de contexte opérés par le système d’exploitation. Pour plus de détails, voir cet article.

Il faudra aussi aller vérifier que les ressources allouées seront en priorité sur les programmes générant beaucoup d’IOs comme SQL Server (Connexions réseau, clic-droit sur l’interface réseau -> Properties-> File and Printer Sharing (et oui !) -> Properties):

Maximize throughput for network applications: sous entendu on n’est pas là pour faire du partage de fichiers.

Et éviter l’utilisation des antivirus autant que possible.

Compte de service pour SQL Server et l’agent:

Le compte de service est le compte déclaré au niveau de la machine ou du domaine pour supporter l’exécution de SQL Server et l’ensemble de ses interactions avec le système: poster des IOs, atteindre des machines sur le réseau, écrire dans un fichier de sauvegarde, etc… Toutes ces actions seront donc exécutées sous le contexte de droits du compte de service.  Dans la plupart des cas, les SQL  Server sont démarrés sous le contrôle des comptes systèmes locaux (LOCAL SYSTEM) avec lesquels sont lancés la plupart des modules de windows exécutés en mode user (smss.exe, crss.exe, lsass.exe, winlogon.exe, etc…). Et négligence du  DBA, on trouve aussi des SQL Server démarrés sous le compte Administrateur local voire de domaine, ce qui du point de vue sécurité  n’est pas vraiment l’idéal.

Et bien depuis la version SQL Server 2005, il n’y a plus d’excuse: on créé simplement des comptes utilisateurs locaux ou de domaine sans privilège *** pour SQL Server et SQL Agent (je ne parle pas de SQL Browser puisque du point de vue sécurité, on ne doit pas l’utiliser **), on les passe ensuite à l’assistant d’installation qui créé des groupes avec les droits appropriés, et y intègre les comptes qui héritent du coup des droits strictement nécessaires.

Éléments à définir avant l’installation de SQL Server :

Avant de lancer le setup,il faut réfléchir à quelques éléments caractéristiques de l’instance que l’on souhaite installer:

Instance locale / instance nommée:

L’instance locale est l’instance que l’on créé par défaut sur une machine. Elle prend par défaut le nom de la machine et le port 1433 attribué par l’IANA. On ne peut donc en créer qu’une seule par machine. Ma chaîne de connexion ressemblera à :

sqlcmd -Udba_exploit -w1000 -S PIXIES 

Où PIXIES est le nom de ma machine, et donc le nom de mon instance locale par la même occasion. Maintenant, lorsqu’on souhaite en installer plus d’une par machine, on pourra utiliser les instances nommées, dont le nom sera constitué d’un préfixe (nom de la machine hôte) et d’un suffixe (nom de l’instance à choisir) séparés par un backslash (‘\’). Dans ce cas, ma chaîne de connexion ressemblera à :

sqlcmd -Udba_exploit -w1000 -S PIXIES\SQL1 

Où SQL1 sera le nom de nom instance nommée. Autre différence majeure, le port de démarrage sera défini dynamiquement. Ce qui signifie qu’il peut changer entre deux redémarrages, donc problème de firewall à l’horizon. Pour l’éviter, il faudra fixer le port de démarrage de l’instance dans les propriétés TCP, et redémarrer SQL Server. **

Collation:

La collation va définir la manière de coder les caractères dans ma base de données. Là aussi le sujet est vaste et largement débattu sur le net. Il faut simplement réfléchir aux types de champs texte que mon application va devoir stocker et choisir le codepage approprié. Il faut essayer de prendre le codepage le plus large possible. Lors de l’installation en SQL Server 2005, deux types de collations sont proposées: les collations windows et les collations SQL Server. En fait la seconde est incluse pour compatibilité vers les versions précédentes, et ne doit donc être utilisée que pour assurer la compatibilité lors d’une migration. Il vaut mieux essayer de partir avec une collation Windows dès le départ, elles sont plus riches et plus précises, notamment lorsqu’on utilise à la fois des colonnes UNICODE et NON-UNICODE, car la collation windows sait convertir du NON-UNICODE à la volée.  Changer la collation à tous niveaux n’est pas une opération de routine: au niveau de l’instance, il faudra la reconstruire, au niveau de la base c’est plus épique encore.

Mode d’authentification:

Deux solutions:

• Le mode intégré: l’authentification se fait par une autorité telle qu’un contrôleur de domaine ou la machine locale. Avantage, SQL Server ne stocke pas de mot de passe, côté sécurité c’est la meilleure option. Inconvénient, lorsqu’on souhaite atteindre depuis son application cliente une instance qui n’est pas dans le même domaine, ou simplement une machine en workgroup, l’authentification intégrée ne fonctionnera pas.
• Le mode mixte: donc on sera obligé de permettre aussi de créer et d’utiliser  des comptes et des mots de passe dans SQL Server. En mode mixte, on se connecte soit avec un compte windows, soit avec un compte SQL Server.

Les bonnes pratiques de sécurité préconisent de rester en mode intégré, mais ce n’est n’est bien souvent pas très pratique, et donc pas appliqué. Il vaut mieux autoriser le mode mixte mais désactiver le compte sa, et faire appliquer la politique de mots de passe de Windows.

Une fois ces étapes validées, l’installation peut commencer. Le travail de préparation est terminé.

A bientôt !

* Dans cet exemple, on choisit de faire les backups sur un partage CIFS
** Je ne parle pas de sécurité dans cet article, le sujet est vaste et fera l’objet d’un prochain post.
*** Penser à cocher le compte n’expire jamais pour les comptes de service.

[ David B. ]

Continuez votre lecture sur le blog :

• Modes de récupération et journal de transactions, épisode 2 (David BAFFALEUF) [SQL Server]
• Scripting et SMO (suite): scripter les objets directement en T-SQL (David BAFFALEUF) [SQL Server]
• Formation Optimisation de requêtes (David BAFFALEUF) [SQL Server]
• Insert et Update en une seule fois avec MERGE (Guillaume DEFENDINI) [SQL Server]
• OPENROWSET, épisode 1 (David BAFFALEUF) [SQL Server]

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 :

• Mythe: TORN PAGE DETECTION est moins coûteux que CHECKSUM (David BAFFALEUF) [SQL Server]
• Point-in-time recovery et fn_dump_dblog() (David BAFFALEUF) [SQL Server]
• Un trigger fait-il parti d’une transaction ? (Cédric PEINTRE) [GénéralMySQLOracleSQL ServerSybase]
• Attention aux requêtes en double avec Windev et MySQL ! (Cédric PEINTRE) [MySQL]
• Mythe: SQL Server associe un thread à chaque connexion (David BAFFALEUF) [SQL Server]