Etiquetas

Se han invertido cantidades enormes de tiempo, energía y capital intelectual en la compilación de aplicaciones locales muy resistentes. Esto se reduce normalmente a separar la aplicación en componentes de estado bajo (servidores de aplicaciones, conexión de red) y los componentes de estado alto (bases de datos, redes SAN), y hacer que cada uno sea resistente a los modos de error.

En este contexto, un modo de error hace referencia a una combinación de:

a) Observar el sistema en un estado de error.

b) Observar resultado del motivo del error.

Por ejemplo, una base de datos que es inaccesible debido a una actualización de la contraseña mal configurada es un modo de error; el estado del error es la incapacidad para conectarse (conexión rechazada, credenciales no aceptadas), y la causa del error es una actualización de contraseña que no se comunicó correctamente al código de la aplicación.

La experiencia en la ejecución de sistemas de escala ha demostrado que, en cualquier sistema suficientemente grande lleva a algunas partes del sistema a interrumpirse constantemente. La plataforma Azure se diseñó de forma tal que pudiera trabajar con esta limitación, en lugar de contra ella, confiando en la recuperación automatizada de los eventos de error del nivel de nodo. Esta intención del diseño aplica a todos los servicios esenciales de Azure y es clave para diseñar una aplicación que funcione con el modelo de disponibilidad de Azure.

Azure cambia el asunto de un desafío de la redundancia de infraestructura a un desafío de la redundancia de los servicios. Muchos de los servicios principales que dominan el planeamiento on-premise de la disponibilidad “simplemente siguen trabajando” en Azure.

Las cargas de trabajo centradas en la movilidad o en las redes sociales (como las aplicaciones web públicas con aplicaciones de dispositivo móvil) tienden a ser mucho más dinámicas que las que apuntan a audiencias cautivas y solo requieren un enfoque más sofisticado para controlar los eventos de ráfaga y la carga máxima. Los conceptos clave que se deben tener en cuenta para diseñar la disponibilidad en las aplicaciones de Azure se describen en estos ejes centrales:

  • Cada servicio o componente de Azure proporciona un contrato de nivel de servicio (SLA); este SLA no se puede correlacionar directamente con la métrica de disponibilidad necesaria para ejecutar la aplicación. Comprender todos los componentes del sistema, su SLA de disponibilidad y cómo interactúan es importante para saber la disponibilidad global que se puede entregar a los usuarios.
      1. Evite los puntos de error únicos que puedan degradar el SLA, como los roles de una sola instancia.
      2. Componga o recurra a varios componentes para mitigar el impacto de que un servicio específico se quede sin conexión o no esté disponible.

 

  • Cada servicio o componente de Azure puede experimentar un error, ya sea un evento transitorio y efímero o un evento duradero. La aplicación debe escribirse de tal forma que controle el error correctamente.
      1. Para los errores transitorios, proporcione los mecanismos de reintento apropiados para volver a conectar o reenviar el trabajo.
      2. Para otros eventos de error, proporcione una instrumentación enriquecida del evento de error (que informa del error en las operaciones) y un mensaje de error adecuado para el usuario.
      3. Siempre que sea posible, recurra a otro servicio o flujo de trabajo. Por ejemplo, si una solicitud para insertar datos en la Base de datos SQL produce un error (por cualquier motivo no transitorio, como un esquema no válido), escriba los datos en el almacenamiento de blob en un formato serializado. Esto permitiría que los datos se capturen de forma duradera y se envíen a la base de datos una vez resuelto el problema de esquema.

 

  • Todos los servicios tienen una capacidad máxima, ya sea explícita (mediante una directiva de limitación o asíntota de carga máxima) o implícita (cuando se alcanza un límite de recursos del sistema).
      1. Diseñe la aplicación de forma que se degrade correctamente en el caso de alcanzar los límites de recursos, y realice la acción adecuada para suavizar el impacto para el usuario.
      2. Implemente la lógica de retroceso y reintento adecuada para evitar un efecto de “convoy” en los servicios. Sin un mecanismo de retroceso adecuado, los servicios de nivel inferiores no tendrán nunca la probabilidad de ponerse al día después de experimentar un evento de tráfico máximo (por ejemplo, que la aplicación intente insertar más carga en el servicio, lo que activa la directiva de limitación o el agotamiento de los recursos).

 

  • Los servicios que pueden experimentar eventos rápidos de ráfaga deben tratar de superar correctamente la carga máxima, normalmente a través de la funcionalidad de pérdida.
      1. De forma parecida a como el cuerpo humano limita el flujo de sangre a las extremidades al enfrentarse a frío extremo, debe diseñar los servicios para perder los servicios menos importantes en eventos de carga extrema.
      2. El corolario aquí no consiste en que no todos los servicios suministrados por la aplicación tienen una importancia empresarial equivalente y pueden estar sujetos a unos SLA diferentes.

Tenga presente que el centro de datos sigue siendo un punto de error en las aplicaciones grandes; ya se trate de suministros o de un error de los sistemas, la infraestructura y los problemas de las aplicaciones han desactivado centros de datos. Aunque son relativamente poco habituales, las aplicaciones que requieren los mayores niveles de tiempo de actividad deben implementarse en varios centros de datos redundantes.

La implementación de aplicaciones en varios centros de datos requiere diversas capacidades de infraestructura y de las aplicaciones:

  • Lógica de la aplicación para direccionar a los usuarios de los servicios al centro de datos adecuado (basado en la localización geográfica, la partición en la que se encuentre el usuario u otra lógica de afinidad).

 

  • Sincronización y replicación del estado de la aplicación entre los centros de datos, con la latencia y los niveles de coherencia adecuados.

 

  • La implementación autónoma de aplicaciones, de forma que las dependencias entre los centros de datos se minimice (es decir, que impida la situación donde un error en el centro de datos A desencadena un error en el centro de datos B).