Compartir a través de

Solución de problemas de disponibilidad en cuentas de Azure Storage

  • Artículo

Este artículo le ayuda a investigar los cambios en la disponibilidad (por ejemplo, el número de solicitudes con error). Estos cambios en la disponibilidad a menudo se pueden identificar mediante la supervisión de métricas de almacenamiento en Azure Monitor. Para obtener información general sobre el uso de métricas y registros en Azure Monitor, consulte los siguientes artículos:

Supervisión de disponibilidad

Debe supervisar la disponibilidad de los servicios de almacenamiento en la cuenta de almacenamiento mediante la supervisión del valor de la métrica Disponibilidad. La métrica Disponibilidad contiene un valor de porcentaje. Se calcula tomando el valor total de las solicitudes facturables y dividiéndolo por el número de solicitudes aplicables, incluidas las solicitudes que generaron errores inesperados.

Si el valor es inferior al 100%, significa que algunas solicitudes de almacenamiento no se están realizando correctamente. Para ver por qué se producen errores, examine la dimensión ResponseType para ver los tipos de error, como ServerTimeoutError. Debería esperar ver que la disponibilidad cae temporalmente por debajo del 100 % por motivos como tiempos de espera transitorios del servidor mientras el servicio mueve las particiones a mejores solicitudes de equilibrio de carga; la lógica de reintento en la aplicación cliente debe controlar estas condiciones intermitentes. La métrica Disponibilidad solo estará disponible durante períodos de tiempo cuando también se produzcan transacciones en la cuenta.

Puede usar características de Azure Monitor para avisarle si la disponibilidad de un servicio está por debajo de un umbral que especifique.

Las métricas muestran un aumento de errores de limitación

Los errores de limitación se producen cuando supera los objetivos de escalabilidad de un servicio de almacenamiento. El servicio de almacenamiento aplica la limitación para asegurarse de que ningún cliente o inquilino pueda usar el servicio a expensas de otros. Para obtener más información, consulte Objetivos de escalabilidad y rendimiento para cuentas de almacenamiento estándar para obtener detalles sobre los objetivos de escalabilidad de las cuentas de almacenamiento y los objetivos de rendimiento de las particiones que hay dentro de las cuentas de almacenamiento.

Si el valor ClientThrottlingError o ServerBusyError de la dimensión ResponseType muestra un aumento en el porcentaje de solicitudes con errores de limitación, debe investigar uno de estos dos escenarios:

  • Aumento transitorio de PercentThrottlingError
  • Aumento permanente del error PercentThrottlingError

A menudo, se produce un aumento de los errores de limitación al mismo tiempo que un aumento en el número de solicitudes de almacenamiento o cuando se prueba inicialmente la carga de la aplicación. Esto también puede manifestarse en el cliente como los mensajes de estado HTTP “503 Servidor ocupado” o “500 Se agotó el tiempo de espera de la operación” de las operaciones de almacenamiento.

Aumento transitorio de errores de limitación

Si ve picos en los errores de limitación que coinciden con períodos de alta actividad para la aplicación, implementará una estrategia de retroceso exponencial (no lineal) para los reintentos en el cliente. Los reintentos de retroceso reducen la carga inmediata en la partición y ayudan a la aplicación a suavizar los picos de tráfico. Para más información sobre cómo implementar directivas de reintentos mediante la biblioteca cliente de almacenamiento, vea la propiedad RetryOptions.MaxRetries.

Nota:

También puede ver picos en los errores de limitación que no coinciden con períodos de alta actividad para la aplicación. La causa más probable es que el servicio de almacenamiento mueva particiones para mejorar el equilibrio de carga.

Aumento permanente de errores de limitación

Si ve un valor constantemente alto para los errores de limitación después de un aumento permanente de los volúmenes de transacciones o al realizar las pruebas de carga iniciales en la aplicación, debe evaluar cómo usa la aplicación las particiones de almacenamiento y si se aproxima a los objetivos de escalabilidad de una cuenta de almacenamiento. Por ejemplo, si ve errores de limitación en una cola (que cuenta como una sola partición), considere la posibilidad de usar colas adicionales para distribuir las transacciones entre varias particiones. Si ve errores de limitación en una tabla, considere la posibilidad de usar un esquema de partición diferente para distribuir las transacciones entre varias particiones mediante un intervalo más amplio de valores de clave de partición. Una causa común de este problema es el antipatrón anteponer o anexar, donde se selecciona la fecha como clave de partición y, a continuación, todos los datos de un día determinado se escriben en una partición (en carga, esto puede dar lugar a un cuello de botella de escritura). Considere un diseño de creación de particiones diferente o evalúe si el uso de Blob Storage podría ser una solución mejor. Además, compruebe si se está produciendo una limitación debido a picos en el tráfico e investigue formas de suavizar el patrón de solicitudes.

Si distribuye las transacciones por varias particiones, aun así, debe ser consciente de los límites de escalabilidad establecidos para la cuenta de almacenamiento. Por ejemplo, si ha usado 10 colas, cada una procesa el máximo de 2000 1 KB de mensajes por segundo, estará en el límite total de 20 000 mensajes por segundo para la cuenta de almacenamiento. Si necesita procesar más de 20 000 entidades por segundo, considere la posibilidad de usar varias cuentas de almacenamiento. También debe tener en cuenta que el tamaño de las solicitudes y entidades afecta cuando el servicio de almacenamiento limita los clientes. Si tiene solicitudes y entidades más grandes, es posible que se limite antes.

Un diseño ineficiente de las consultas también puede hacer que alcance los límites de escalabilidad de las particiones de tabla. Por ejemplo, una consulta con un filtro que solo selecciona un uno por ciento de las entidades de una partición, pero que examina todas las entidades de una partición, tendrá que acceder a cada una de las entidades. Cada lectura de entidad contará para el número total de transacciones de esa partición. Por lo tanto, puede alcanzar fácilmente los objetivos de escalabilidad.

Nota:

Las pruebas de rendimiento deberían revelar todos los diseños de consulta ineficientes de la aplicación.

Las métricas muestran un aumento de errores de tiempo de espera

Los errores de tiempo de espera se producen cuando la dimensión ResponseType es igual a ServerTimeoutError o ClientTimeout.

Las métricas muestran un aumento de los errores de tiempo de espera en uno de los servicios de almacenamiento. Al mismo tiempo, el cliente recibe un gran volumen de mensajes de estado HTTP “500 Se agotó el tiempo de espera de la operación” de las operaciones de almacenamiento.

Nota:

Puede que, temporalmente, vea errores de tiempo de espera, dado que el servicio de almacenamiento equilibra la carga de las solicitudes moviendo particiones a servidores nuevos.

Los errores de tiempo de espera del servidor (ServerTimeOutError) se deben a un error en el servidor. Los tiempos de espera del cliente (ClientTimeout) se producen porque una operación en el servidor ha superado el tiempo de espera especificado por el cliente. Por ejemplo, un cliente que usa la biblioteca cliente de storage puede establecer un tiempo de espera para una operación.

Los errores de tiempo de espera del servidor indican que existe un problema con el servicio de almacenamiento que se debe investigar más. Puede utilizar las métricas para ver si está alcanzando los límites de escalabilidad del servicio y para identificar los picos de tráfico que puedan estar provocando este problema. Si el problema es intermitente, puede que se deba a la actividad de equilibrio de carga del servicio. Si el problema es persistente y no se debe a que la aplicación alcance los límites de escalabilidad del servicio, debe informar al soporte técnico de que existe un problema. En el caso de los tiempos de espera de cliente, debe decidir si el tiempo de espera se establece en un valor adecuado en el cliente y cambiar el valor de tiempo de espera establecido en el cliente o investigar cómo puede mejorar el rendimiento de las operaciones en el servicio de almacenamiento, por ejemplo, optimizando las consultas de tabla o reduciendo el tamaño de los mensajes.

Las métricas muestran un aumento de errores de red

Los errores de red se producen cuando la dimensión ResponseType es igual a NetworkError. Se producen cuando el servicio de almacenamiento detecta un error de red cuando el cliente realiza una solicitud de almacenamiento.

El motivo más común de este error es que un cliente se desconecte antes de que expire un tiempo de espera en el servicio de almacenamiento. Investigue el código en el cliente para comprender por qué y cuándo se desconecta el cliente del servicio de almacenamiento. También puede utilizar herramientas de análisis de red de terceros para investigar los problemas de conectividad de red desde el cliente.

Consulte también

Ponte en contacto con nosotros para obtener ayuda

Si tiene preguntas o necesita ayuda, cree una solicitud de soporte o busque consejo en la comunidad de Azure. También puede enviar comentarios sobre el producto con los comentarios de la comunidad de Azure.