Configurer la mémoire persistante (PMEM) pour SQL Server sur Linux

  • Article

S’applique à :SQL Server - Linux

Cet article décrit comment configurer la mémoire persistante (PMEM) pour SQL Server 2019 (15.x) et les versions ultérieures sur Linux.

Vue d’ensemble

SQL Server 2019 (15.x) a introduit de nombreuses de fonctionnalités en mémoire qui utilisent la mémoire persistante. Cet article décrit les étapes nécessaires à la configuration de la mémoire persistante pour SQL Server sur Linux.

Notes

Le terme enlightment (« illumination ») a été introduit pour décrire le concept d’utiliser un système de fichiers prenant en charge la mémoire persistante. L’accès direct au système de fichiers à partir d’applications d’espace utilisateur est facilité par l’utilisation du mappage de mémoire (mmap()). Lors de la création d’un mappage de mémoire pour un fichier, l’application peut émettre des instructions de chargement/stockage en contournant totalement la pile d’E/S. Il s’agit d’une méthode d’accès aux fichiers « enlightened » (ou illuminée) du point de vue de l’application d’extension hôte (qui est le code autorisant SQLPAL à interagir avec le système d’exploitation Windows ou Linux).

Créer des espaces de noms pour les appareils PMEM

Configurer les appareils

Dans Linux, utilisez l’utilitaire ndctl.

  • Installez ndctl pour configurer l’appareil PMEM. Vous pouvez le trouver ici.
  • Utilisez ndctl pour créer un espace de noms. Les espaces de noms sont entrelacés sur les NVDIMM PMEM et peuvent fournir différents types d’accès d’espace utilisateur aux régions de la mémoire sur l’appareil. fsdax est le mode par défaut et souhaité pour SQL Server.
ndctl create-namespace -f -e namespace0.0 --mode=fsdax --map=dev

Nous avons choisi le mode fsdax et nous utilisons la mémoire système pour stocker les métadonnées par page. Nous vous recommandons d’utiliser --map=dev. Cette option permet de stocker les métadonnées directement sur l’espace de noms. Le stockage de métadonnées en mémoire avec --map=mem est expérimental pour l’instant.

Utilisez ndctl pour vérifier l’espace de noms.

Un exemple est alors sorti :

# ndctl list -N
{
  "dev":"namespace0.0",
  "mode":"fsdax",
  "map":"dev",
  "size":4294967296,
  "sector_size":512,
  "blockdev":"pmem0",
  "numa_node":0
}

Créez et montez un appareil PMEM

Par exemple, avec XFS

mkfs.xfs -f /dev/pmem0
mount -o dax,noatime /dev/pmem0 /mnt/dax
xfs_io -c "extsize 2m" /mnt/dax

Par exemple, avec EXT4

mkfs.ext4 -b 4096 -E stride=512 -F /dev/pmem0
mount -o dax,noatime /dev/pmem0 /mnt/dax

Considérations techniques

  • Bloquer l’allocation de 2 Mo pour XFS/EXT4, comme décrit précédemment
  • Un mauvais alignement entre l’allocation de bloc et mmap entraîne un basculement silencieux sur 4 Ko
  • Les tailles de fichier doivent être un multiple de 2 Mo (modulo 2 Mo)
  • Ne pas désactiver les pages THP (Transparent huge page) (activées par défaut sur la plupart des distributions)

Une fois l’appareil configuré avec ndctl, créé et monté, vous pouvez y placer des fichiers de base de données ou créer une nouvelle base de données.

Vous pouvez stocker les fichiers de données de SQL Server (MDFS, NDFS) et les fichiers tempdb sur un appareil PMEM quand ils sont configurés avec le mode fsdax à l’aide de la commande suivante. N’utilisez pas cette procédure pour stocker les fichiers de journal SQL Server (LDFS), car le journal des transactions doit se trouver sur le stockage qui fournit des garanties atomiques de secteur :

ndctl create-namespace -f -e namespace0.0 --mode=fsdax --map=dev

Avant de définir l’option de mappage dans la commande précédente, prenez en compte les points suivants :

  • Pour des performances optimales lors de l’accès et de la mise à jour de ces entrées de pages NVDIMM pour cet appareil, il est préférable d’utiliser -map=mem
  • Si la capacité du dispositif NVDIMM est trop grande (supérieure à 512 Go), définissez –map=dev, ce qui influence le débit d’E/S et bloque les performances

Pour les fichiers journaux SQL Server sur des appareils PMEM, approvisionnez le ou les appareils PMEM pour utiliser le secteur/la table de traduction de bloc (BTT). Cela fournit l’atomicité de secteur nécessaire pour les fichiers journaux SQL Server de cette technologie de dispositifs de stockage. Nous vous recommandons également d’effectuer des validations de performances de charge de travail. Vous pouvez comparer les performances des journaux SQL Server pour votre charge de travail entre cette solution et les disques SSD NVMe les plus performants, puis sélectionner la solution qui répond le mieux à vos besoins et offre de meilleures performances.

ndctl create-namespace -f -e namespace0.0 --mode= sector

Désactiver le comportement de vidage forcé

Comme les appareils PMEM sont sécurisés O_DIRECT (E/S directes), vous pouvez désactiver le comportement de vidage forcé.

Notes

Un système de stockage peut s'assurer que toutes les écritures mises en cache ou échelonnées sont considérées comme sûres et durables, en garantissant que les écritures envoyées à l'appareil sont conservées sur un support qui persistera malgré les défaillances système, les réinitialisations d'interface et les coupures de courant, et que le support lui-même est redondant sur le plan matériel.

  • Les fichiers de base de données (.mdf et .ndf) et de journal des transactions (.ldf) n’utilisent ni writethrough ni alternatewritethrough par défaut dans SQL Server 2017 (14.x) CU 6 et versions ultérieures, car ils utilisent le comportement de vidage forcé. L’indicateur de trace 3979 désactive l’utilisation du comportement de vidage forcé pour les fichiers journaux de base de données et de transactions, et utilise les logiques writethrough et alternatewritethrough.

  • Les autres fichiers ouverts à l’aide de FILE_FLAG_WRITE_THROUGH dans SQL Server, notamment les instantanés de base de données, les instantanés internes pour les vérifications de cohérence de la base de données (DBCC CHECKDB), les fichiers de trace du profileur et les fichiers de suivi d’événements étendus, utilisent les optimisations writethrough et alternatewritethrough.

Pour plus d’informations sur les modifications introduites dans SQL Server 2017 (14.x) CU 6, voir l’article 4131496 de la base de connaissances. Pour plus d’informations sur les éléments internes Forced Unit Access (FUA), consultez Éléments internes FUA.

Fonctionnalité du sous-système d’E/S SQL Server et FUA (Forced Unit Access)

Certaines versions des distributions Linux prises en charge fournissent une prise en charge de la fonctionnalité du sous-système d’E/S FUA, qui permet d’assurer la durabilité des données. SQL Server utilise la fonctionnalité FUA pour fournir des E/S hautement efficaces et fiables pour la charge de travail SQL Server. Pour plus d’informations sur la prise en charge de FUA par la distribution Linux et son effet sur SQL Server, consultez SQL Server sur Linux : éléments internes d’accès d’unité forcé (FUA).

SUSE Linux Enterprise Server 12 SP5, Red Hat Enterprise Linux 8.0 et Ubuntu 18.04 ont introduit la prise en charge de la fonctionnalité FUA dans le sous-système d’E/S. Si vous utilisez SQL Server 2017 (14.x) CU 6 et des versions ultérieures, vous devez utiliser la configuration suivante pour assurer l’implémentation d’E/S efficace et performante avec FUA par SQL Server.

Utilisez cette configuration recommandée si les conditions suivantes sont remplies.

  • SQL Server 2017 (14.x) CU 6 et versions suivantes

  • Distribution et version Linux prenant en charge la fonctionnalité FUA (à partir de Red Hat Enterprise Linux 8.0, SUSE Linux Enterprise Server 12 SP5 ou Ubuntu 18.04)

  • Système de fichiers XFS pour le stockage SQL Server

  • Sous-système de stockage et/ou matériel prenant en charge la fonctionnalité FUA et configurés pour celle-ci

Configuration recommandée :

  1. Activez l’indicateur de trace 3979 en tant que paramètre de démarrage.

  2. Utilisez mssql-conf pour configurer control.writethrough = 1 et control.alternatewritethrough = 0.

Pour presque toutes les autres configurations qui ne respectent pas les conditions précédentes, la configuration recommandée est la suivante :

  1. Activez l’indicateur de trace 3982 comme paramètre de démarrage (par défaut pour SQL Server dans l’écosystème Linux), et veillez à ce que l’indicateur de trace 3979 ne soit pas activé en tant que paramètre de démarrage.

  2. Utilisez mssql-conf pour configurer control.writethrough = 1 et control.alternatewritethrough = 1.

Prise en charge de FUA pour les conteneurs SQL Server déployés dans Kubernetes

  1. SQL Server doit utiliser le stockage permanent à l’état monté, et pas overlayfs.

  2. Le stockage doit utiliser le système de fichiers XFS et doit prendre en charge FUA. Avant d’activer ce paramètre, vous devez vous assurer auprès de votre fournisseur de distribution et de stockage Linux que le système d’exploitation et le sous-système de stockage prennent bien en charge les options FUA. Sur Kubernetes, vous pouvez interroger le type de système de fichiers à l’aide de la commande suivante, où <pvc-name> est votre PersistentVolumeClaim :

    kubectl describe pv <pvc-name>

    Dans la sortie, recherchez le fstype défini sur XFS.

  3. Le nœud de travail hébergeant les pods SQL Server doit utiliser une distribution Linux et une version prenant en charge la fonctionnalité FUA (à partir de Red Hat Enterprise Linux 8.0, SUSE Linux Enterprise Server 12 SP5 ou Ubuntu 18.04).

Si les conditions ci-dessus sont remplies, vous pouvez utiliser les paramètres recommandés FUA suivants.

  1. Activez l’indicateur de trace 3979 en tant que paramètre de démarrage.

  2. Utilisez mssql-conf pour configurer control.writethrough = 1 et control.alternatewritethrough = 0.

Contenu associé