Este documento está en proceso de actualización. Mientras tanto, es posible que parte del contenido no sea preciso.

Las traducciones son generadas a través de traducción automática. En caso de conflicto entre la traducción y la version original de inglés, prevalecerá la version en inglés.

Planteamiento en torno a los modos de falla

A la hora de diseñar una aplicación o un sistema de alta disponibilidad, se debe tener en cuenta qué componentes pueden fallar, qué impacto tendrán los errores de los componentes en el sistema y qué mecanismos se pueden implementar para mitigar o eliminar el impacto de estos errores. ¿La aplicación en cuestión se ejecuta en un único servidor, en un único rack o en un único centro de datos? ¿Qué ocurrirá cuando un servidor, rack o centro de datos experimente un error temporal o permanente? ¿Qué ocurre cuando se produce un error en un subsistema esencial como la red o en la propia aplicación? Hablamos de modos de error.

El usuario debe tener en cuenta los modos de error especificados en esta sección cuando planifique las implementaciones de Outposts y otras aplicaciones. En las secciones siguientes, se analizará cómo mitigar estos modos de error para proporcionar un mayor nivel de alta disponibilidad para el entorno de aplicaciones.

Modo de error 1: red

Una implementación de Outposts depende de una conexión resiliente con su región principal para su propia administración y supervisión. Las interrupciones de la red pueden deberse a diversos problemas, como errores del operador, errores del equipo e interrupciones del proveedor de servicios. Una implementación de Outposts, que puede estar compuesta por uno o más racks conectados entre sí en el sitio, se considera desconectada cuando no puede comunicarse con la región a través del enlace de servicio.

Las rutas de red redundantes pueden ayudar a mitigar el riesgo de que se produzcan eventos de desconexión. Se deben asignar el tráfico de red y las dependencias de la aplicación para conocer el impacto que los eventos de desconexión tendrían en las operaciones de las cargas de trabajo. El usuario debe planificar una redundancia de red suficiente para satisfacer los requisitos de disponibilidad de las aplicaciones.

Durante un evento de desconexión, las instancias que se ejecutan en un Outpost siguen ejecutándose y se puede acceder a ellas desde las redes locales a través de la puerta de enlace local de Outpost (). LGW Las cargas de trabajo y los servicios locales pueden verse dañados o fallar si dependen de los servicios de la región. Las solicitudes de mutación (como iniciar o detener instancias en el Outpost), las operaciones del plano de control y la telemetría del servicio (por ejemplo, las CloudWatch métricas) fallarán mientras el Outpost esté desconectado de la región.

Modo de error 2: instancias

EC2Las instancias pueden estropearse o fallar si el servidor en el que se ejecutan tiene un problema o si la instancia sufre un error en el sistema operativo o en la aplicación. La forma en que las aplicaciones gestionan estos tipos de errores depende de la arquitectura de la aplicación. Las aplicaciones monolíticas suelen utilizar funciones de aplicaciones o sistemas para la recuperación, mientras que las arquitecturas modulares orientadas a los servicios o de microservicios suelen sustituir los componentes con errores para garantizar la disponibilidad del servicio.

Puede reemplazar las instancias fallidas por instancias nuevas mediante mecanismos automatizados, como los grupos de EC2 Auto Scaling. La recuperación automática de instancias puede reiniciar las instancias que fallan debido a errores en el servidor, siempre que haya suficiente capacidad libre disponible en los servidores restantes.

Modo de error 3: computación

Los servidores pueden fallar o verse dañados. Es posible que sea necesario ponerlos fuera de servicio (temporal o permanentemente) por diversos motivos, como errores de los componentes y operaciones de mantenimiento programadas. La forma en que los servicios del rack de Outposts gestionan los errores y los problemas de los servidores varía y puede depender de la forma en que los clientes configuren las opciones de alta disponibilidad.

El usuario debe solicitar una capacidad informática suficiente para admitir un modelo de disponibilidad N+M, en el que N es la capacidad requerida y M es la capacidad de reserva que se aprovisiona para adaptarse a los errores de los servidores.

Los reemplazos de hardware para los servidores averiados se proporcionan como parte del servicio de AWS Outposts rack totalmente gestionado. AWS supervisa activamente el estado de todos los servidores y dispositivos de red en una implementación de Outpost. Si es necesario realizar un mantenimiento físico, AWS programará una visita al sitio del usuario para sustituir los componentes con errores. El aprovisionamiento de la capacidad de reserva permite mantener las cargas de trabajo en funcionamiento mientras los servidores con errores están fuera de servicio y en proceso de sustitución.

Modo de error 4: racks o centros de datos

Los errores de los racks pueden producirse debido a una pérdida total de la alimentación de estos o a problemas con el entorno, como una pérdida de la refrigeración o daños físicos en el centro de datos a causa de una inundación o un terremoto. Las deficiencias en las arquitecturas de distribución eléctrica del centro de datos o los errores que se producen durante el mantenimiento de la alimentación estándar del centro de datos pueden provocar la pérdida de energía en uno o más racks, o incluso en todo el centro de datos.

Estos escenarios se pueden mitigar mediante la implementación de la infraestructura en varios pisos o ubicaciones del centro de datos que sean independientes entre sí dentro del mismo campus o área metropolitana.

Adoptar este enfoque con AWS Outposts rack requerirá una cuidadosa consideración de cómo se diseñan y distribuyen las aplicaciones para que se ejecuten en varios Outposts lógicos independientes a fin de mantener la disponibilidad de las aplicaciones.

Modo de error 5: zona o AWS región de disponibilidad

Cada implementación de Outposts está anclada a una zona de disponibilidad (AZ) específica dentro de una Región de AWS. Los errores de la región principal o la zona de disponibilidad de anclaje pueden provocar la pérdida de la gestión y la mutabilidad de Outposts, así como interrumpir la comunicación de red entre Outposts y la región.

Al igual que los errores de la red, los de la zona de disponibilidad o la región pueden provocar que Outposts se desconecte de la región. Las instancias que se ejecutan en un Outpost siguen ejecutándose y se puede acceder a ellas desde las redes locales a través de la puerta de enlace local de Outpost (LGW) y es posible que se estropeen o fallen si dependen de los servicios de la región, como se describió anteriormente.

Para mitigar el impacto de los fallos en las AWS zonas de disponibilidad y las regiones, puedes desplegar varios Outposts, cada uno de ellos anclado a una zona de disponibilidad o región diferente. A continuación, puede diseñar su carga de trabajo para que funcione en un modelo de despliegue distribuido de varios Outpost utilizando muchos de los mecanismos y patrones arquitectónicos similares a los que utiliza actualmente para diseñar e implementar. AWS