[SQL Server] Gestion de fichiers de données : stockage

Ce billet traite de l’importance du stockage dans le cadre de la gestion de fichiers de données.

Très souvent, dans les cas où une ou plusieurs bases de données voient leur taille dépasser le(s) disque(s) sur le(s)quel(s) elles sont situées, l’utilisation de dispositifs de stockage externe est souvent envisagée. C’est le cas de baies de stockage telles que le SAN et le NAS.

Le fait de préférer le SAN au NAS repose sur la finalité même du NAS : l’envoi de données à travers le réseau afin que le NAS puisse écrire et/ou lire les données.Un NAS ne garantit aucunement l’intégrité des données dans la mesure où l’instance SQL Server n’a aucun contrôle sur la façon dont les données sont stockées sur un NAS. De plus, le fait que plusieurs serveurs (ou clients) peuvent s’adresser au NAS pour de lecture ou de l’écriture augmente le risque de problèmes de performances en I/O pour les bases de données.

Contrairement au NAS, le SAN propose plus de facilités à SQL Server en lui offrant un espace de stockage multi-disques avec connexion directe entre le serveur et le SAN, permettant ainsi à l’instance SQL Server de garder un contrôle total sur ses fichiers.

Du fait de la volumétrie minimale des données à traiter, il est recommandé d’utiliser des RAIDs avec une taille de stripe (bande) minimale supérieure ou égale à 64 Ko. En effet, rappelons qu’un extent de données vaut 64 Ko, soit 8 pages contigües de 8 Ko, et des tailles de stripe trop petites peuvent provoquer des contentions et/ou des fragmentations disques.

Par ailleurs, les fichiers de données étant généralement soumis aux accès en lecture (là où les fichiers de journal de transactions sont surtout soumis aux écritures), l’utilisation de disques en RAID5 (ou mieux, de disques en RAID10) est un bon compromis.

Notons qu’il est recommandé de placer les fichiers de données dans un ou plusieurs LUNs (Logical Unit Numbers) dédiés afin de mieux isoler les activités I/O, et surtout éviter tout conflit avec les fichiers de journal de transactions, les sauvegardes ou tempDB réputés gourmands en écritures. De plus, si un fichier spécifique s’avère être un aspirateur en ressources I/O et est susceptible d’impacter les performances d’accès aux autres fichiers de données, il est possible d’envisager de lui dédier un LUN séparé.
D’autres éléments de bonnes pratiques ne sont pas à négliger tels que :

  • Sous les versions inférieures à Windows 2008, la nécessité d’aligner les partitions afin de réduire tout risque de fragmentations et de multiplication d’activités I/O superflues (voir ici).
  • La nécessité de configurer une taille de chunk de 64 Ko minimum pour chaque cluster d’allocation de partition.
  • Placer les fichiers de données sur une (ou plusieurs) partition(s) NTFS pour des raisons de performances.
  • Eviter de mettre des fichiers de données dans des disques compressés.
  • Activer, au niveau Windows, l’Instant File Initialization afin d’accélérer des opérations de maintenance de volume telles que la création de nouveaux fichiers de données, leur modification (surtout quand elles sont volumineuses), etc…
  • Exempter tout fichier de données de scans d’antivirus, pour des raisons d’intégrité et de performances.
Publicités

Laisser un commentaire

Entrez vos coordonnées ci-dessous ou cliquez sur une icône pour vous connecter:

Logo WordPress.com

Vous commentez à l'aide de votre compte WordPress.com. Déconnexion / Changer )

Image Twitter

Vous commentez à l'aide de votre compte Twitter. Déconnexion / Changer )

Photo Facebook

Vous commentez à l'aide de votre compte Facebook. Déconnexion / Changer )

Photo Google+

Vous commentez à l'aide de votre compte Google+. Déconnexion / Changer )

Connexion à %s