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.
Visualiza el valor actual del parámetro de tiempo de espera.
- Determina qué controlador NVMe usa el disco persistente o la SSD local.
ls -l /dev/disk/by-id
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
- Determina qué controlador NVMe usa el disco persistente o la SSD local.
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.
Symlinks no creados en las VMs C3 y C3D con SSD locales
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.
- 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 reglasudev
diferente. - Ubica el archivo
65-gce-disk-naming.rules
en el directorio de reglas udev. 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"
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 archivo65-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
Ve al directorio
udev
.Ubica el archivo
google_nvme_id
en el directorioudev
.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
Asegúrate de que el archivo
google_nvme_id
sea ejecutable.sudo chmod 755 google_nvme_id
Reinicia la VM.
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, ejecutalsblk
. Los dispositivos NVMe que muestran375G
en tamaño son dispositivos SSD locales.
Próximos pasos
- Obtén información sobre Persistent Disk.
- Obtén más información sobre los SSD locales
- Configurar los discos para cumplir con los requisitos de rendimiento
- Obtén más información sobre los symlinks.