Solución de problemas de discos NVMe

En este documento, se enumeran los errores que pueden surgir cuando se usan discos con la interfaz de memoria rápida no volátil (NVMe).

Puedes usar la interfaz NVMe para SSD locales y discos persistentes (Persistent Disk o Google Cloud Hyperdisk). Solo la serie de máquina más reciente, como Tau T2A, M3, C3, C3D y H3, usan la interfaz NVMe para Persistent Disk. Las Confidential VMs también usan Persistent Disk NVMe. Todas las demás series de máquinas de Compute Engine usan la interfaz de disco SCSI para los discos persistentes.

Error de tiempo de espera de operación de E/S

Si te encuentras con errores de tiempo de espera de E/S, la latencia podría superar el parámetro de tiempo de espera predeterminado para las operaciones de E/S enviadas a dispositivos NVMe.

Mensaje de error: 

[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
...

Solución:

Para resolver este problema, aumenta el valor del parámetro de tiempo de espera.

  1. Visualiza el valor actual del parámetro de tiempo de espera.

    1. Determina qué controlador NVMe usa el disco persistente o la SSD local.
      ls -l /dev/disk/by-id

    2. Muestra la configuración io_timeout, especificada en segundos, para el disco. 

      cat /sys/class/nvme/CONTROLLER_ID/NAMESPACE/queue/io_timeout
      Reemplaza lo siguiente:

      • CONTROLLER_ID: el ID del controlador de disco NVMe, por ejemplo, nvme1
      • NAMESPACE: el espacio de nombres del disco NVMe, por ejemplo, nvme1n1

      Si solo tienes un único disco que usa NVMe, usa el siguiente comando:

      cat /sys/class/nvme/nvme0/nvme0n1/queue/io_timeout

  2. A fin de aumentar el parámetro de tiempo de espera para las operaciones de E/S enviadas a dispositivos NVMe, agrega las siguientes líneas al archivo /lib/udev/rules.d/65-gce-disk-naming.rules y, luego, reinicia la VM:

    KERNEL=="nvme*n*", ENV{DEVTYPE}=="disk", ATTRS{model}=="nvme_card-pd", ATTR{queue/io_timeout}="4294967295"

Los discos desconectados aún aparecen en el sistema operativo de una instancia de procesamiento

En las VMs que usan la versión 6.0 a 6.2 del kernel de Linux, las operaciones que involucran el método instances.detachDisk de la API de Compute Engine o el comando gcloud compute instances detach-disk pueden no funcionar como se espera. La consola de Google Cloud muestra el dispositivo como quitado, los metadatos de la instancia de procesamiento (comando compute disks describe) muestran el dispositivo como quitado, pero el punto de activación del dispositivo y los symlinks creados por reglas udev aún son visibles en sistema operativo invitado.

Mensaje de error:

Intentar leer desde el disco desconectado en la VM da como resultado errores de E/S:

sudo head /dev/nvme0n3

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

Problema:

Las imágenes del sistema operativo que usan un kernel de Linux 6.0-6.2, pero no incluyen un backport de una corrección NVMe, no reconocen cuando se desconecta un disco NVMe.

Solución:

Reinicia la VM para completar el proceso de eliminación del disco.

Para evitar este problema, usa un sistema operativo con una versión de kernel de Linux que no tenga este problema:

  • 5.19 o una versión posterior
  • 6.3 o una versión posterior

Puedes usar el comando uname -r en el SO invitado para ver la versión de kernel de Linux.

Si conectas discos SSD locales a una VM C3 o C3D, es posible que debas realizar pasos adicionales para crear los symlinks de los discos SSD locales. Estos pasos solo son obligatorios si usas cualquiera de las siguientes imágenes públicas que ofrece Google Cloud:

  • SLES 15 SP4 y SP5
  • SLES 12 SP4

Estos pasos adicionales solo se aplican a los discos SSD locales; no necesitas hacer nada para los volúmenes de Persistent Disk.

Las imágenes públicas de Linux enumeradas antes no tienen la configuración correcta de udev para crear symlinks para dispositivos SSD locales conectados a las VMs C3 y C3D. Es posible que las imágenes personalizadas no incluyan las reglas udev necesarias para crear symlinks para dispositivos SSD locales conectados a las VMs C3 y C3D.

Usa estas instrucciones para agregar reglas udev para SUSE o imágenes personalizadas.

  1. Ubica el directorio de reglas udev. Por lo general, es /lib/udev/rules.d o /usr/lib/udev/rules.d. Es posible que tu imagen tenga un directorio de reglas udev diferente.
  2. Ubica el archivo 65-gce-disk-naming.rules en el directorio de reglas udev.

  3. Si el archivo 65-gce-disk-naming.rules contiene la siguiente línea, la imagen admite las reglas nuevas y puedes detenerte aquí:

    KERNEL=="nvme*n*", ATTRS{model}=="nvme_card[0-9]*",IMPORT{program}="google_nvme_id -d $tempnode"

  4. Si la línea anterior no está presente o si el archivo 65-gce-disk-naming.rules no existe, reemplaza el archivo existente o crea un archivo nuevo, con el contenido del archivo de esta URL: https://raw.githubusercontent.com/GoogleCloudPlatform/guest-configs/20230630.00/src/lib/udev/rules.d/65-gce-disk-naming.rules. Este archivo tiene el contenido actualizado del archivo 65-gce-disk-naming.rules, incluida la línea del paso anterior y otras reglas necesarias para nombrar los discos de Compute Engine. Por ejemplo:

    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

  5. Ve al directorio udev.

  6. Ubica el archivo google_nvme_id en el directorio udev.

  7. Reemplaza el contenido del archivo google_nvme_id existente o crea un archivo nuevo con el contenido de esta URL:

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

  8. Asegúrate de que el archivo google_nvme_id sea ejecutable.

    sudo chmod 755 google_nvme_id

  9. Reinicia la VM.

  10. Verifica que los symlinks se creen correctamente.

    ls -l /dev/disk/by-id/google-local-nvme-ssd*

    El resultado debe mostrar una cantidad de vínculos igual a la cantidad de SSD locales conectados a la instancia, y cada vínculo debe apuntar a una ruta de dispositivo /dev/nvme diferente. Por ejemplo:

    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

    Para obtener más información sobre los nombres de dispositivos, consulta Nombres de dispositivos.

    Para verificar que las rutas de acceso de dispositivo /dev/nvme sean dispositivos SSD locales, ejecuta lsblk. Los dispositivos NVMe que muestran 375G en tamaño son dispositivos SSD locales.

Próximos pasos