Résoudre les problèmes liés aux disques NVMe

Ce document répertorie les erreurs que vous pouvez rencontrer lors de l'utilisation de disques avec l'interface NVMe (nonvolatile memory express).

Vous pouvez utiliser l'interface NVMe pour les disques SSD locaux et les disques persistants (Persistent Disk ou Google Cloud Hyperdisk). Seules les séries de machines les plus récentes, telles que Tau T2A, M3, C3, C3D et H3, utilisent l'interface NVMe pour les disques Persistent Disk. Confidential VMs utilisent également le NVMe pour les disques Persistent Disk. Toutes les autres séries de machines Compute Engine utilisent l'interface disque SCSI pour les disques persistants.

Erreur d'expiration de délai d'une opération d'E/S

Si vous rencontrez des erreurs d'expiration de délai d'E/S, il est possible que la latence dépasse le paramètre de délai avant expiration par défaut pour les opérations d'E/S envoyées à des appareils NVMe.

Message d'erreur :

[1369407.045521] nvme nvme0: I/O 252 QID 2 timeout, aborting
[1369407.050941] nvme nvme0: I/O 253 QID 2 timeout, aborting
[1369407.056354] nvme nvme0: I/O 254 QID 2 timeout, aborting
[1369407.061766] nvme nvme0: I/O 255 QID 2 timeout, aborting
[1369407.067168] nvme nvme0: I/O 256 QID 2 timeout, aborting
[1369407.072583] nvme nvme0: I/O 257 QID 2 timeout, aborting
[1369407.077987] nvme nvme0: I/O 258 QID 2 timeout, aborting
[1369407.083395] nvme nvme0: I/O 259 QID 2 timeout, aborting
[1369407.088802] nvme nvme0: I/O 260 QID 2 timeout, aborting
...

Solution :

Pour résoudre ce problème, augmentez la valeur du paramètre de délai avant expiration.

Affichez la valeur actuelle du paramètre de délai avant expiration.
1. Déterminez le contrôleur NVMe qui est utilisé par le disque persistant ou le volume SSD local.
```
ls -l /dev/disk/by-id
```
2. Affichez le paramètre io_timeout, spécifié en secondes, pour le disque.
```
cat /sys/class/nvme/CONTROLLER_ID/NAMESPACE/queue/io_timeout
```
  Remplacez les éléments suivants :
  - CONTROLLER_ID : ID du contrôleur de disque NVMe, par exemple nvme1
  - NAMESPACE : espace de noms du disque NVMe, par exemple nvme1n1
  Si vous ne disposez que d'un seul disque utilisant NVMe, utilisez la commande suivante :
```
cat /sys/class/nvme/nvme0/nvme0n1/queue/io_timeout
```
Pour augmenter le paramètre de délai avant expiration pour les opérations d'E/S envoyées à des appareils NVMe, ajoutez la ligne suivante au fichier /lib/udev/rules.d/65-gce-disk-naming.rules, puis redémarrez la VM :
```
KERNEL=="nvme*n*", ENV{DEVTYPE}=="disk", ATTRS{model}=="nvme_card-pd", ATTR{queue/io_timeout}="4294967295"
```

Les disques dissociés apparaissent toujours dans le système d'exploitation d'une instance de calcul

Sur les VM qui utilisent le noyau Linux version 6.0 à 6.2, les opérations impliquant la méthode d'API Compute Engine instances.detachDisk ou la commande gcloud compute instances detach-disk peuvent ne pas fonctionner comme prévu. La console Google Cloud indique que l'appareil a été supprimé, les métadonnées de l'instance de calcul (commande compute disks describe) indiquent que l'appareil a été supprimé, mais le point de montage de l'appareil et tous les liens symboliques créés par les règles udev sont toujours visibles dans le système d'exploitation invité.

Message d'erreur :

Toute tentative de lecture à partir du disque dissocié sur la VM entraîne des erreurs d'E/S :

sudo head /dev/nvme0n3

head: error reading '/dev/nvme0n3': Input/output error

Problème :

Les images du système d'exploitation qui utilisent un noyau Linux 6.0-6.2, mais qui n'incluent pas de rétroportage d'une correction NVMe ne parviennent pas à détecter quand un disque NVMe est dissocié.

Solution :

Redémarrez la VM pour terminer le processus de suppression du disque.

Pour éviter ce problème, utilisez un système d'exploitation avec une version du noyau Linux qui ne présente pas ce problème :

5.19 et versions ultérieures
6.3 et versions ultérieures

Vous pouvez utiliser la commande uname -r dans l'OS invité pour afficher la version du noyau Linux.

Liens symboliques non créés sur des VM C3 et C3D avec un disque SSD local

Si vous associez des disques SSD locaux à une VM C3 ou C3D, vous devrez peut-être prendre des mesures supplémentaires pour créer les liens symboliques pour les disques SSD locaux. Ces étapes ne sont requises que si vous utilisez l'une des images publiques suivantes proposées par Google Cloud :

SLES 15 SP4 et SP5
SLES 12 SP4

Ces étapes supplémentaires ne s'appliquent qu'aux disques SSD locaux. Vous n'avez rien à faire pour les volumes Persistent Disk.

Les images Linux publiques répertoriées précédemment ne disposent pas de la configuration udev appropriée pour créer des liens symboliques pour les disques SSD locaux associés à des VM C3 et C3D. Les images personnalisées peuvent également ne pas inclure les règles udev requises pour créer des liens symboliques pour les disques SSD locaux associés à des VM C3 et C3D.

Suivez ces instructions pour ajouter des règles udev pour des images SUSE ou personnalisées.

Recherchez le répertoire des règles udev. Il s'agit généralement de /lib/udev/rules.d ou /usr/lib/udev/rules.d. Votre image peut avoir un répertoire de règles udev différent.
Recherchez le fichier 65-gce-disk-naming.rules dans le répertoire des règles udev.
Si le fichier 65-gce-disk-naming.rules contient la ligne suivante, votre image est compatible avec les nouvelles règles et vous pouvez vous arrêter ici :
```
KERNEL=="nvme*n*", ATTRS{model}=="nvme_card[0-9]*",IMPORT{program}="google_nvme_id -d $tempnode"
```
Si la ligne précédente n'est pas présente ou si le fichier 65-gce-disk-naming.rules n'existe pas, remplacez le fichier existant ou créez un fichier avec le contenu de cette URL : https://raw.githubusercontent.com/GoogleCloudPlatform/guest-configs/20230630.00/src/lib/udev/rules.d/65-gce-disk-naming.rules. Ce fichier contient le contenu mis à jour du fichier 65-gce-disk-naming.rules, y compris la ligne de l'étape précédente et d'autres règles requises pour la dénomination des disques Compute Engine. Exemple :
```
sudo curl -o 65-gce-disk-naming.rules https://raw.githubusercontent.com/GoogleCloudPlatform/guest-configs/20230630.00/src/lib/udev/rules.d/65-gce-disk-naming.rules
```
Accédez au répertoire udev :
Recherchez le fichier google_nvme_id dans le répertoire udev.

Remplacez le contenu du fichier google_nvme_id existant ou créez un fichier avec le contenu de cette URL :

sudo curl -o google_nvme_id https://raw.githubusercontent.com/GoogleCloudPlatform/guest-configs/20230630.00/src/lib/udev/google_nvme_id

Assurez-vous que le fichier google_nvme_id est exécutable.
```
sudo chmod 755 google_nvme_id
```
Redémarrez la VM.
Vérifiez que les liens symboliques ont bien été créés.
```
ls -l /dev/disk/by-id/google-local-nvme-ssd*
```
Le résultat doit répertorier le même nombre de liens que les disques SSD locaux associés à l'instance, et chaque lien doit pointer vers un chemin d'accès /dev/nvme différent. Exemple :
```
lrwxrwxrwx 1 root root 13 Jul 19 22:52 /dev/disk/by-id/google-local-nvme-ssd-0 -> ../../nvme0n1
lrwxrwxrwx 1 root root 13 Jul 19 22:52 /dev/disk/by-id/google-local-nvme-ssd-1 -> ../../nvme1n1
```
Pour en savoir plus sur les noms d'appareils, consultez Nommer les appareils.

Vous pouvez vérifier que les chemins d'accès aux appareils /dev/nvme sont des appareils SSD locaux en exécutant lsblk. Les appareils NVMe dont la taille est 375G sont des disques SSD locaux.

Étape suivante

Découvrez Persistent Disk.
Découvrez les SSD locaux.
Configurez les disques pour répondre aux exigences de performances.
Apprenez-en plus sur les liens symboliques.