Solución de problemas de gateways de archivos

Puede configurar la gateway de archivos con un grupo de registros de Amazon CloudWatch cuando ejecute la alta disponibilidad (HA) de VMware vSphere. Si lo hace, recibirá notificaciones sobre el estado de la gateway de archivos y de los errores que detecta la gateway de archivos. Puede encontrar información sobre estas notificaciones de estado y errores en CloudWatch Logs.

En las siguientes secciones puede encontrar información que le ayudará a comprender la causa de cada notificación de estado y error y cómo solucionar los problemas.

Error: ObjectMissing

Puedes obtener unObjectMissingerror cuando un escritor que no sea la gateway de archivos especificada elimina el archivo especificado de Amazon FSx. Cualquier carga posterior a Amazon FSx o recuperación desde Amazon FSx fallará.

Para resolver un objeto Error que falta

1. Guarde la copia más reciente del archivo en el sistema de archivos local del cliente SMB (necesita esta copia de archivos en el paso 3).

2. Elimine el archivo de la gateway de archivos mediante el cliente SMB.

3. Copie la versión más reciente del archivo que ha guardado en el paso 1 Amazon FSx mediante el cliente SMB. Haga esto mediante la gateway de archivos.

Notificación: Reinicio

Puede recibir una notificación de reinicio cuando la MV de la gateway se reinicia. Puede reiniciar la MV de una gateway mediante la consola de gestión de hipervisor de MV o la consola de Storage Gateway. También puede llevar a cabo el reinicio de la gateway mediante el software de la gateway durante el ciclo de mantenimiento de la gateway.

Si la hora del reinicio se encuentra dentro de un periodo de 10 minutos desde la hora de inicio de mantenimiento configurada de la gateway, es probable que este reinicio sea un evento normal y no sea signo de ningún problema. Si el reinicio se produce significativamente fuera del periodo de mantenimiento, compruebe si la gateway se ha reiniciado de forma manual.

Notificación: HardReboot

Puede recibir una notificación HardReboot cuando la MV de la gateway se reinicia de forma inesperada. Este reinicio se puede deber a una pérdida de potencia, un fallo de hardware u otro evento. En las gateways de VMware, un reinicio provocado por la monitorización de aplicaciones de alta disponibilidad de vSphere puede provocar este evento.

Cuando la gateway se ejecuta en dicho entorno, compruebe si hay notificaciones HealthCheckFailure y consulte el registro de eventos de VMware para la MV.

Notificación: HealthCheckFailure

En una gateway de HA de VMware vSphere, puede recibir una notificación HealthCheckFailure cuando se produce un error en una comprobación de estado y se solicita un reinicio de la MV. Este evento también se produce durante una prueba para monitorizar la disponibilidad y se indica mediante una notificación AvailabilityMonitorTest. En este caso, la notificación HealthCheckFailure es normal.

nota

Esta notificación es únicamente para las gateways de VMware.

Si este evento se produce de forma repetida sin una notificación AvailabilityMonitorTest, compruebe si la infraestructura de la MV presenta algún problema (almacenamiento, memoria, etc.). Si necesita asistencia adicional, póngase en contacto conAWS Support.

Notificación: AvailabilityMonitorTest

Obtienes unAvailabilityMonitorTestnotificación cuandoejecutar una pruebadelSupervisión de disponibilidad y aplicacionessistema en las gateways que se ejecutan en una plataforma de HA de VMware vSphere.

Error: RoleTrustRelationshipInvalid

Recibe este error cuando el rol de IAM de un recurso compartido de archivos tiene una relación de confianza de IAM mal configurada (es decir, el rol de IAM no confía en la entidad principal de Storage Gateway denominadastoragegateway.amazonaws.com). Como resultado, la gateway de archivos no podría obtener las credenciales para ejecutar ninguna operación en el bucket de S3 que realiza una copia de seguridad del recurso compartido de archivos.

Para resolver un error RoleTrustRelationshipInvalid

• Utilice la consola de IAM o la API de IAM para incluirstoragegateway.amazonaws.comcomo una entidad principal en la que confía en el IAMRole de su recurso compartido de archivos. Para obtener información acerca del rol de IAM, consulteTutorial: delegar el acceso a travésAWScuentas que utilizan roles de IAM.

Solución de problemas con métricas de CloudWatch

A continuación encontrará información sobre las acciones para solucionar los problemas mediante el uso de las métricas de Amazon CloudWatch con Storage Gateway.

Temas

• La puerta de enlace reacciona lentamente al navegar por los directorios
• Tu gateway no responde
• No ve archivos en el sistema de archivos de Amazon FSx
• La gateway transfiere datos lentamente a Amazon FSx
• El trabajo de copia de seguridad de la gateway falla o se producen errores al escribir en la gateway

La puerta de enlace reacciona lentamente al navegar por los directorios

Si la gateway de archivos reacciona lentamente al ejecutar lalscomando o navegar por directorios, compruebe laIndexFetchyIndexEvictionMetrics de CloudWatch:

• Si el archivo deIndexFetchmétrica es mayor que 0 cuando ejecuta unlso examina directorios, la gateway de archivos se ha iniciado sin información acerca del contenido del directorio afectado y tuvo que acceder a Amazon S3. Los esfuerzos posteriores para mostrar el contenido de ese directorio deberían realizarse más rápidamente.

• Si el archivo deIndexEvictionla métrica es mayor que 0, significa que la gateway de archivos ha alcanzado el límite de lo que puede gestionar en la caché en ese momento. En este caso, la gateway de archivos tiene que liberar espacio de almacenamiento del directorio al que se ha accedido menos recientemente para crear un nuevo directorio. Si esto se produce con frecuencia e incluye un impacto en el rendimiento, póngase en contacto conAWS Support.

  Conversar conAWS Supportel contenido del sistema de archivos de Amazon FSx relacionado y las recomendaciones para mejorar el rendimiento en función del caso de uso.

Tu gateway no responde

Si la gateway de archivos no responde, haga lo siguiente:

• Si se ha producido una actualización de software o un reinicio recientemente, compruebe la métrica IOWaitPercent. Esta métrica muestra el porcentaje de tiempo en el que la CPU está inactiva cuando hay una solicitud de E/S del disco pendiente. En algunos casos, puede ser elevado (10 o más) y se puede producir después de que el servidor se haya reiniciado o actualizado. En estos casos, es posible que se produzca un efecto embudo en la gateway de archivos a causa de un disco raíz lento, ya que reanuda la caché de índice en la RAM. Puede solucionar este problema mediante el uso de un disco físico más rápido para el disco raíz.

• Si el archivo deMemUsedBytesmétrica es igual o casi igual que laMemTotalBytesmétrica, la gateway de archivos se está quedando sin RAM disponible. Asegúrese de que la gateway de archivos tenga el menos la RAM mínima requerida. Si ya la tiene, considere añadir más RAM a la gateway de archivos en función de la carga de trabajo y el caso de uso.

  Si el recurso compartido de archivos es SMB, el problema también podría deberse al número de clientes SMB conectados a dicho recurso. Para ver el número de clientes que están conectados en cualquier momento, compruebe la métrica SMBV(1/2/3)Sessions. Si hay muchos clientes conectados, es posible que necesite agregar más RAM a la gateway de archivos.

No ve archivos en el sistema de archivos de Amazon FSx

Si observa que los archivos de la puerta de enlace no se reflejan en el sistema de archivos de Amazon FSx, compruebe laFilesFailingUploadMétrica de. Si la métrica informa de que algunos archivos no se han cargado, compruebe las notificaciones de estado. Cuando los archivos no se cargan, la puerta de enlace genera una notificación de estado que contiene más detalles sobre el problema.

La gateway transfiere datos lentamente a Amazon FSx

Si la gateway de archivos transfiere lentamente datos a Amazon S3, haga lo siguiente:

• Si el archivo deCachePercentDirtyla métrica es 80 o superior, la gateway de archivos escribe los datos en el disco a una velocidad más rápida de la que puede utilizar para cargar los datos en Amazon S3. Considere aumentar el ancho de banda de carga de la gateway de archivos, ya sea mediante la adición de uno o varios discos en caché o mediante la ralentización de las escrituras de los clientes.

• Si el archivo deCachePercentDirtymétrica baja, compruebe laIoWaitPercentMétrica de. SiIoWaitPercentes mayor que 10, es posible que se produzca un efecto embudo en la gateway de archivos por la velocidad del disco en caché local. Recomendamos el uso de discos locales de unidades de estado sólido (SSD) para la caché, preferiblemente NVM Express (NVMe). Si dichos discos no están disponibles, intente utilizar varios discos en caché desde discos físicos independientes para mejorar el rendimiento.

El trabajo de copia de seguridad de la gateway falla o se producen errores al escribir en la gateway

Si el trabajo de copia de seguridad de la gateway de archivos falla o hay errores al escribir en la gateway de archivos, haga lo siguiente:

• Si el archivo deCachePercentDirtymétrica es del 90 por ciento o superior, la gateway de archivos no puede aceptar nuevas escrituras en disco porque no hay suficiente espacio disponible en el disco de caché. Para ver a qué velocidad carga la gateway de archivos en Amazon FSx o Amazon S3, consulte la Guía del usuarioCloudBytesUploadedMétrica de. Compara esa métrica con laWriteBytesmétrica, que muestra a qué velocidad escribe archivos el cliente en la gateway de archivos. Si la gateway de archivos escribe más rápido de lo que puede cargar en Amazon FSx o Amazon S3, añada más discos de caché para cubrir al menos el tamaño del trabajo de copia de seguridad. También puede aumentar el ancho de banda de carga.

• Si falla un trabajo de copia de seguridad, pero elCachePercentDirtyla métrica es inferior al 80 por ciento, es posible que la gateway de archivos esté alcanzando el tiempo de espera de la sesión del lado del cliente. Para SMB, puede aumentar este tiempo de espera mediante el comando de PowerShell Set-SmbClientConfiguration -SessionTimeout 300. Al ejecutar este comando, el tiempo de espera se establece en 300 segundos.

  Para NFS, asegúrese de que el cliente se haya montado mediante un montaje rígido en lugar de un montaje blando.