Réglage de ZFS lors de l'utilisation de stockage flash

Les informations suivantes s'appliquent aux SSD flash, à la carte accélératrice PCIe F20, à la carte accélératrice PCIe F40 et à la baie de stockage flash F5100.

Consultez les commentaires généraux suivants lorsque vous utilisez ZFS avec un stockage flash :

Si vous en disposez, envisagez d'utiliser des LUN ou des disques à faible latence gérés par un contrôleur à mémoire persistante pour le journal d'intention ZFS (ZIL). Cette option peut s'avérer beaucoup plus rentable que l'utilisation de flash pour des validations de latence faible. Les périphériques de journalisation doivent avoir une taille suffisante pour contenir 10 secondes du débit d'écriture maximal. C'est le cas par exemple d'un LUN basé sur une baie de stockage ou un disque connecté à un HBA avec un cache d'écriture avec batterie protégée.

Si aucun périphérique de ce type n'est disponible, segmentez un pool de périphériques flash distinct à utiliser comme périphériques de journalisation dans un pool de stockage ZFS.
Les cartes accélératrices flash F20 et F40 contiennent et exportent 4 modules flash indépendants vers le système d'exploitation. La baie F5100 contient jusqu'à 80 modules flash indépendants. Chaque module flash apparaît au système d'exploitation sous la forme d'un périphérique unique. Les SSD sont visualisés sous la forme d'un périphérique unique par le système d'exploitation. Il est possible d'utiliser des périphériques flash en tant que périphériques de journalisation ZFS pour réduire la latence de validation, en particulier sur un serveur NFS. Par exemple, l'utilisation en tant que périphérique de journalisation ZFS d'un seul module flash d'un périphérique flash peut diviser par 10 la latence d'opérations individuelles à thread léger. Il est possible d'entrelacer des périphériques flash supplémentaires pour atteindre un débit plus élevé pour de grandes quantités d'opérations synchrones.
Il est recommandé de mettre les périphériques de journalisation en miroir pour plus de fiabilité. Pour garantir une protection maximale, vous devez créer les miroirs sur des périphériques flash distincts. Dans le cas des cartes accélératrices PCIe F20 et F40, une protection maximale est assurée en plaçant les miroirs sur des cartes PCIe physiques différentes. Pour une protection maximale avec la baie de stockage F5100, les miroirs doivent être placés sur des périphériques F5100 distincts.
Il est possible d'utiliser en tant que périphériques de cache de deuxième niveau des périphériques flash qui ne font pas office de périphériques de journalisation. Ceci permet de décharger le stockage sur disque principal d'opérations d'E/S par seconde (IOPS) et d'améliorer la latence de lecture des données couramment utilisées.

Ajout de périphériques flash en tant que périphériques de journalisation ZFS ou de périphériques de cache

Consultez les recommandations suivantes lorsque vous ajoutez des périphériques flash en tant que périphériques de journalisation ZFS ou de cache.

Vous pouvez ajouter un périphérique de journalisation ZFS ou de cache à un pool de stockage ZFS existant à l'aide de la commande zpool add. Faites très attention lorsque vous utilisez les commandes zpool add. Si, par erreur, vous ajoutez un périphérique de journalisation en tant que périphérique de pool normal, ce pool devra être détruit, puis restauré de toutes pièces. Il est possible de supprimer d'un pool des périphériques de journalisation individuels.
Familiarisez-vous avec la commande zpool add avant de tenter cette opération sur un stockage actif. Vous pouvez utiliser l'option zpool add -n pour prévisualiser la configuration sans la créer. Par exemple, la syntaxe de prévisualisation zpool add incorrecte suivante tente d'ajouter un périphérique en tant que périphérique de journalisation :
```
# zpool add -n tank c4t1d0
vdev verification failed: use -f to override the following errors:
mismatched replication level: pool uses mirror and new vdev is disk
Unable to build pool from specified devices: invalid vdev configuration
```
Voici la syntaxe de prévisualisation zpool add correcte pour l'ajout d'un périphérique de journalisation à un pool existant :
```
# zpool add -n tank log c4t1d0
would update 'tank' to the following configuration:
        tank
          mirror
            c4t0d0
            c5t0d0
        logs
          c4t1d0
```
Si plusieurs périphériques sont spécifiés, ils sont entrelacés. Pour plus d'informations, reportez-vous aux exemples ci-dessous ou à zpool(1M).

Vous pouvez ajouter le périphérique flash c4t1d0 en tant que périphérique de journalisation ZFS :

# zpool add pool log c4t1d0

Si 2 périphériques flash sont disponibles, vous pouvez ajouter des périphériques de journalisation mis en miroir :

# zpool add pool log mirror c4t1d0 c4t2d0

Les périphériques flash disponibles peuvent être ajoutés en tant que périphérique de cache pour les lectures.

# zpool add pool cache c4t3d0

Vous ne pouvez pas mettre en miroir des périphériques de cache, car ils sont entrelacés.

# zpool add pool cache c4t3d0 c4t4d0

Configuration d'un comportement de vidage de cache correct pour les périphériques de stockage flash et NVRAM

ZFS est conçu pour fonctionner avec les périphériques de stockage qui gèrent un cache au niveau d'un disque. ZFS demande en général au périphérique de stockage de s'assurer que les données sont correctement placées sur un stockage stable en envoyant une demande de purge du cache. Pour le stockage JBOD, cela fonctionne comme prévu et sans problèmes. Pour de nombreuses baies de stockage basées sur NVRAM, un problème de performances risque de se produire si la baie traite la demande de purge et exécute une action avec cette dernière au lieu de l'ignorer. Certaines baies de stockage purgent leurs caches volumineux malgré le fait que la protection NVRAM rende ces caches aussi efficaces qu'un stockage stable.

ZFS produit une purge peu fréquente (toutes les 5 secondes environ) après les mises à jour de l'uberblock. La faible fréquence de la purge ne présente ici que peu de conséquences, aucun réglage n'est alors nécessaire. ZFS produit également une purge à chaque demande d'écriture synchrone émise par une application (O_DSYNC, fsync, validation NFS, etc.). L'avancement de ce type de purge est attendu par l'application et a une incidence sur les performances. Et ce, considérablement. D'un point de vue des performances, cela neutralise les avantages découlant de la possession d'un stockage basé sur NVRAM.

Il a récemment été établi que le réglage du vidage du cache contribue à améliorer les performances des périphériques flash utilisés en tant que périphériques de journalisation. Lorsque tous les LUN exposés à ZFS proviennent d'une baie de stockage protégée par NVRAM et que des procédures assurent qu'aucun LUN non protégé ne sera ajouté à l'avenir, vous pouvez régler ZFS pour qu'il n'émette pas de demandes de vidage en définissant zfs_nocacheflush. Si certaines LUN exposées à ZFS ne sont pas protégées par NVRAM, ce réglage peut engendrer des pertes de données, des dommages au niveau des applications ou même un endommagement du pool. Dans certaines baies de stockage protégées par NVRAM, la commande de purge du cache constitue une opération non effective. Par conséquent, un réglage dans cette situation ne fait pas de différences en termes de performances.

Lors d'une récente modification du SE, la sémantique de demande de vidage a été qualifiée de manière à indiquer aux périphériques de stockage d'ignorer les demandes s'ils disposent d'une protection correcte. Cette modification nécessite une correction de nos pilotes de disque pour que le périphérique NVRAM prenne en charge la sémantique mise à jour. Si le périphérique NVRAM ne reconnaît pas cette amélioration, suivez les instructions ci-après pour indiquer au SE Solaris de ne pas envoyer de commandes de synchronisation de cache à la baie de disques. Si vous appliquez ces instructions, assurez-vous que tous les LUN ciblés sont effectivement protégés par NVRAM.

Il arrive que les périphériques flash et NVRAM n'indiquent pas correctement au SE qu'ils ne sont pas des périphériques, et que les caches ne nécessitent pas de vidage. Le vidage de cache est une opération coûteuse. Des vidages inutiles peuvent considérablement diminuer les performances dans certains cas.

Consultez les restrictions de syntaxe zfs_nocacheflush suivantes avant d'appliquer les entrées réglables ci-dessous :

Vous pouvez inclure la syntaxe de réglage ci-dessous dans sd.conf mais il ne doit exister qu'une seule entrée sd-config-list par fournisseur/produit.
Si vous souhaitez saisir plusieurs entrées de périphériques, vous pouvez indiquer plusieurs paires d'ID fournisseur et de chaînes réglables sd sur la même ligne à l'aide de la syntaxe suivante :
```
#              "012345670123456789012345","tuning    ",
sd-config-list="|-VID1-||-----PID1-----|","param1:val1, param2:val2",
               "|-VIDN-||-----PIDN-----|","param1:val1, param3:val3";
```
Assurez-vous que la chaîne de l'ID du fournisseur (VID) est complétée de 8 caractères et que la chaîne de l'ID de produit (PID) est complétée de 16 caractères comme décrit dans l'exemple précédent.

Attention - Toutes les commandes de synchronisation de cache sont ignorées par le périphérique. Leur utilisation est risquée.

Servez-vous de l'utilitaire format pour exécuter la sous-commande inquiry sur un LUN de la baie de stockage. Par exemple :

# format
.
.
.
Specify disk (enter its number): x
format> inquiry
Vendor:   ATA     
Product:  Marvell      
Revision: XXXX
format>

Sélectionnez l'un des éléments suivants en fonction de votre architecture :
- Pour les périphériques flash F40, ajoutez l'entrée suivante à /kernel/drv/sd.conf. Dans l'entrée ci-dessous, assurez-vous que "ATA" est renseigné avec 8 caractères et que "3E128-TS2-550B01" contient 16 caractères. La longueur totale de la chaîne est égale à 24.
```
sd-config-list="ATA     3E128-TS2-550B01","disksort:false, cache-non:true";
```
- Pour les périphériques flash F20 et F5100, sélectionnez l'un des éléments suivants en fonction de votre architecture. Dans les entrées ci-dessous, "ATA" est renseigné avec 8 caractères et "MARVELL SD88SA02" contient 16 caractères. La longueur totale de la chaîne est égale à 24.
- De nombreuses architectures SPARC : ajoutez l'entrée suivante à /kernel/drv/ssd.conf :
```
ssd-config-list = "ATA     MARVELL SD88SA02","throttle-max:32, disksort:false, cache-non:true";
```
- x64 et quelques pilotes SPARC : ajoutez l'entrée suivante à /kernel/drv/sd.conf
```
ssd-config-list="ATA     MARVELL SD88SA02","throttle-max:32, disksort:false, cache-non:true";
```
Ajoutez des espaces avec précaution pour porter la longueur de l'ID fournisseur (VID) à 8 caractères (ici ATA) et celle de l'ID produit à 16 caractères (ici MARVELL) dans l'entrée sd-config-list, comme indiqué.
Réinitialisez le système.

Vous pouvez restaurer la valeur par défaut (0) de zfs_nocacheflush sans effet négatif sur les performances.

Considérations relatives à l'annulation du mappage SCSI pour les périphériques flash

Le SE Solaris 11.1 présente un problème entraînant des appels excessifs vers les routines d'annulation de mappage SCSI. Ce problème spécifique nuit aux performances flash. La solution consiste à désactiver la fonction d'annulation de mappage de la manière suivante :

Incluez l'entrée suivante dans le fichier /etc/system.
```
set zfs:zfs_unmap_ignore_size=0
```
Réinitialisez le système.

Ignorer les liens de navigation
Quitter l'aperu
	Manuel de référence des paramètres réglables Oracle Solaris 11.1 Oracle Solaris 11.1 Information Library (Français)