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

Suite de l’épisode précédent.

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 :

• Règles d’installation de base (épisode 1) (David Baffaleuf) [SQL ServerVintage]
• Modes de récupération et journal de transactions, épisode 1 (David Baffaleuf) [SQL ServerVintage]
• Les Managed Service Account (MSA et gMSA) : se simplifier la vie pour gérer ses comptes de service SQL Server (Capdata team) [Operating SystemSQL Server]
• Planification dans Adaptive Server (David Baffaleuf) [SybaseVintage]
• Production SQL Server : banalisation des instances (Benjamin VESAN) [SQL Server]