En esta página, se proporcionan detalles sobre la resiliencia de las aplicaciones de Google Cloud NetApp Volumes.
Consideraciones sobre la resiliencia de la aplicación
Si bien NetApp Volumes tiene una alta disponibilidad, los eventos de mantenimiento planificados, como las actualizaciones de la plataforma, las actualizaciones de servicios, las actualizaciones de software o las fallas no planificadas de componentes en el servicio, pueden provocar pausas breves en las operaciones de entrada y salida (E/S).
Pausas de E/S
El software cliente de Network File System (NFS), Server Message Block (SMB) y iSCSI dentro de tu sistema operativo controla las pausas breves de E/S. El cliente espera y vuelve a intentar las operaciones de E/S sin informar el problema a la aplicación. Estas pausas breves se consideran no disruptivas porque, si bien los usuarios de la aplicación pueden ver tiempos de respuesta más largos, la aplicación no informa errores de E/S.
En el caso de las pausas de E/S más largas, el comportamiento depende del cliente NFS, SMB o iSCSI de tu sistema operativo y de los posibles tiempos de espera configurados en la aplicación. En las siguientes secciones, se analizan los detalles específicos del protocolo para las pausas de E/S.
Pausas de E/S de NFS
Todas las llamadas a un recurso compartido de NFS no disponible y activado de forma permanente se bloquean en el cliente de NFS y esperan indefinidamente hasta que el servidor de NFS vuelva a responder. Mientras espera tu cliente de NFS, aparecen mensajes en los registros del cliente que indican que el servidor de NFS no responde.
Desde la perspectiva de la aplicación, las operaciones de E/S, como la lectura o la escritura, se bloquean y permanecen pendientes hasta que el recurso compartido de NFS se devuelve correctamente. Durante las pausas de E/S, nunca se pierde ninguna operación de E/S y NetApp Volumes garantiza la coherencia de los datos, a menos que detengas por la fuerza las operaciones de E/S pendientes en el cliente.
Usa aplicaciones de software de clústeres para automatizar las conmutaciones por error
Si usas aplicaciones de software de clústeres, como Pacemaker, en las VMs cliente para automatizar la conmutación por error de tu aplicación, configura los tiempos de espera para los recursos compartidos de NFS de modo que resistan los eventos de mantenimiento de NetApp Volumes. Estas conmutaciones por error abortan las operaciones de E/S pendientes en el cliente y pueden provocar la pérdida de transacciones. Te recomendamos que uses los siguientes tiempos de espera:
| Tipo de protocolo | Tiempo de espera recomendado | Notas |
|---|---|---|
| Recursos compartidos de NFSv3 | 60 segundos (para los niveles de servicio Estándar, Premium y Extreme)
120 segundos (para el nivel de servicio Flex) |
Te recomendamos que uses un método de aislamiento, que utiliza la opción de montaje nolock en lugar de depender de los bloqueos de NFS. |
| NFSv4.1 | 105 segundos (para los niveles de servicio Estándar, Premium y Extreme)
165 segundos (para el nivel de servicio Flex) |
El protocolo NFSv4.1 agrega automáticamente un bloqueo confiable sobre NFSv3 (RFC de NFSv4.x, sección 9.6.2), que puedes usar como mecanismo de aislamiento. La recuperación del estado de bloqueo agrega 45 segundos adicionales. |
Se pausan las E/S de los recursos compartidos de SMB
A diferencia de NFS, las sesiones de SMB usan una conexión que puede agotarse. En la mayoría de los casos, NetApp Volumes no supera los tiempos de espera.
Tiempos de espera de las sesiones
El tiempo de espera de la sesión se define en el cliente. El tiempo de espera predeterminado para los clientes de Windows es de 60 segundos. Puedes ejecutar el comando Get-SmbClientConfiguration/Set-SmbClientConfiguration con el parámetro SessionTimeout para leer o cambiar el tiempo de espera de la sesión.
Si se agota el tiempo de espera de una sesión, esta se interrumpe y se informa un error de E/S a la aplicación que realiza la E/S. El Explorador de archivos o las aplicaciones de Microsoft 365 suelen volver a conectarse en cuanto el usuario vuelve a acceder al recurso compartido de SMB. Cuando se producen errores de E/S, algunas aplicaciones intentan volver a conectarse y reintentar la operación de E/S fallida, mientras que otras no lo hacen. Consulta la documentación del proveedor de la aplicación para saber cómo esta controla los tiempos de espera de SMB y puede operar de forma resiliente en los recursos compartidos de SMB.
Los recursos compartidos de disponibilidad continua (CA) son una función de SMB3.x que mejora la resistencia a la conmutación por error para aplicaciones similares a bases de datos. NetApp Volumes admite recursos compartidos disponibles de forma continua para Microsoft SQL Server y FSLogix.
La recuperación ante fallas mejora con cada nueva versión de SMB. NetApp Volumes admite SMB 2.1, 3.0 y 3.1.1. Si es posible, usa la versión más reciente compatible con SMB. Windows 10/Server 2016 y versiones posteriores admiten la versión 3.1.1 más reciente de SMB.
Precauciones basadas en la aplicación para SMB
Algunas aplicaciones basadas en SMB requieren la conmutación por error transparente de SMB. La conmutación por error transparente de SMB permite realizar operaciones de mantenimiento en volúmenes de SMB dentro de NetApp Volumes sin interrumpir la conectividad con las aplicaciones del servidor que almacenan datos y acceden a ellos. NetApp Volumes admite la opción de recursos compartidos de disponibilidad continua de SMB para garantizar que las aplicaciones específicas admitan la conmutación por error transparente de SMB. El uso de recursos compartidos de disponibilidad continua de SMB solo admite las siguientes cargas de trabajo:
Contenedores de perfiles de usuario de FSLogix
Microsoft SQL Server (no Linux SQL Server)
Los recursos compartidos de disponibilidad continua de SMB no admiten aplicaciones personalizadas.
Pausas de E/S de iSCSI
En los entornos de Linux y Windows, los clientes (iniciadores) de iSCSI controlan las pausas de E/S reintentando los comandos hasta que el destino (NetApp Volumes) esté disponible. Durante los eventos de mantenimiento breves, el iniciador iSCSI intenta volver a conectarse y reanudar las operaciones de E/S pendientes, lo que ayuda a mantener la resiliencia de la aplicación.
Tiempos de espera de iSCSI
La configuración adecuada de los tiempos de espera de iSCSI es fundamental para mantener la resiliencia de las aplicaciones durante los eventos de mantenimiento o las interrupciones inesperadas del servicio.
En los sistemas Linux, NetApp Volumes usa la configuración predeterminada del iniciador de iSCSI. Estos parámetros de configuración incluyen los específicos de NetApp dentro de la ruta múltiple predeterminada del asignador de dispositivos de Linux, que administra automáticamente los requisitos de tiempo de espera durante los eventos de mantenimiento de NetApp Volumes.
Sin embargo, para los sistemas Windows, modifica la configuración de MPIO de Windows con el siguiente comando para controlar los eventos de mantenimiento de NetApp Volumes.
Set-MPIOSetting -NewPathVerificationState Enabled ` -NewPDORemovePeriod 130 ` -NewRetryCount 6 ` -CustomPathRecovery Enabled ` -NewPathRecoveryInterval 30 `
Durante las pausas de E/S, el iniciador iSCSI reintenta los comandos y mantiene la E/S pendiente durante el tiempo de espera. Si se supera el tiempo de espera, es posible que el sistema operativo informe errores de E/S a la aplicación, lo que puede provocar la pérdida de transacciones o requerir una recuperación a nivel de la aplicación.
Consideraciones sobre la aplicación y el clúster
Si usas software o aplicaciones de clustering que automatizan la conmutación por error, configura los tiempos de espera de iSCSI para que se adapten a los eventos de mantenimiento de NetApp Volumes. La conmutación por error prematura puede anular las operaciones de E/S pendientes y provocar la pérdida de datos o transacciones. Consulta siempre la documentación de tu aplicación y sistema operativo para conocer las prácticas recomendadas sobre la configuración del tiempo de espera de iSCSI.
Interrupciones de la aplicación relacionadas con eventos de mantenimiento
En ocasiones, pueden ocurrir eventos de mantenimiento planificados, como actualizaciones de la plataforma y actualizaciones de software de los servicios. Desde la perspectiva de un protocolo de archivos (NFS o SMB), los eventos de mantenimiento se consideran no disruptivos, siempre y cuando la aplicación pueda controlar las pausas de E/S que podrían ocurrir durante estos eventos.
En el caso de los niveles de servicio Estándar, Premium y Extremo, las pausas de E/S suelen ser cortas y oscilan entre unos segundos y 30 segundos.
Para el nivel de servicio Flex, las pausas de E/S pueden durar hasta 70 segundos.
¿Qué sigue?
Lee sobre las consideraciones de seguridad de Google Cloud NetApp Volumes.