Fiabilidad máxima
Utilice los principios de alta disponibilidad y recuperación ante desastres para diseñar una arquitectura en la nube con una fiabilidad máxima.
Los sistemas de alta disponibilidad (HA) están diseñados para garantizar que ofrezcan el máximo potencial de tiempo de actividad y accesibilidad. Para garantizar una alta disponibilidad, elimine los puntos de fallo únicos, de modo que incluso si los componentes fallan, la aplicación permanezca en ejecución y disponible.
Un plan de recuperación ante desastres (DR) bien diseñado le permite recuperarse rápidamente ante desastres y seguir proporcionando servicios a sus usuarios. DR es el proceso de preparación y recuperación ante un desastre. Un desastre puede ser cualquier evento que ponga en riesgo sus aplicaciones, desde interrupciones de la red, pasando por fallos de equipos y aplicaciones hasta desastres naturales. Para diseñar la recuperación ante desastres, despliegue las aplicaciones esenciales en varias regiones y utilice la replicación asíncrona entre regiones. Planifique la recuperación ante desastres en todas las capas de la pila, incluidas la red, los recursos informáticos, el almacenamiento de objetos, la base de datos y la supervisión.
Recomendaciones de arquitectura para una fiabilidad máxima
Recomendamos un enfoque por fases para una fiabilidad máxima. En la primera fase, despliegue una arquitectura que proporcione capacidades de alta disponibilidad utilizando los dominios de errores de un dominio de disponibilidad. Si se necesita más resiliencia, en la segunda fase, despliegue una arquitectura que abarque varias regiones.
Para obtener más información sobre las regiones, los dominios de disponibilidad y los dominios de errores, consulte Regiones y dominios de disponibilidad.
Fase 1: distribución de instancias en dominios de errores
Los sistemas de alta disponibilidad están diseñados para evitar puntos de fallo únicos. Uno de los principios clave para diseñar un sistema de alta disponibilidad es distribuir las instancias entre varios dominios de errores. Al utilizar adecuadamente los dominios de errores, puede aumentar la disponibilidad de las aplicaciones que se ejecutan en Oracle Cloud Infrastructure.
La arquitectura de su aplicación determina si debe separar o agrupar instancias utilizando dominios de errores.
Escenario A: arquitectura de aplicación altamente disponible
En este escenario, tiene una aplicación altamente disponible; por ejemplo, tiene dos servidores web y una base de datos agrupada. En este escenario, debe agrupar un servidor web y un nodo de base de datos en un dominio de errores y la otra mitad de cada par en otro dominio de errores. Esta ubicación garantiza que un error de cualquier dominio de errores no provoque una interrupción de su aplicación.
Escenario B: servidor web único y arquitectura de instancia de base de datos
En este escenario, la arquitectura de su aplicación no está altamente disponible; tiene, por ejemplo, un servidor web y una instancia de base de datos. En este escenario, tanto el servidor web como la instancia de la base de datos deben ubicarse en el mismo dominio de errores para minimizar las interrupciones de clientes. Esta ubicación garantiza que su aplicación solo se vea afectada por el fallo de ese único dominio de errores, lo que proporciona una mayor disponibilidad general de la aplicación.
SLA compuestos
Cuando se utilizan servicios combinados, la disponibilidad general del sistema depende de la disponibilidad de cada uno de los subsistemas. Para maximizar la disponibilidad de un sistema con varios subcomponentes, debe minimizar las dependencias que tienen los subcomponentes entre sí. Esto significa que, en función de la arquitectura de su aplicación, podría obtener la mayor fiabilidad por una determinada cantidad de esfuerzo de ingeniería utilizando los dominios de errores dentro de un dominio de disponibilidad, en lugar de abarcar los recursos de los dominios de disponibilidad.
Fase 2: despliegue de recursos en varias regiones
Para maximizar la resiliencia de sus cargas de trabajo, despliegue sus cargas de trabajo en la nube en varias regiones, en lugar de en varios dominios de disponibilidad.
El despliegue en varias regiones permite minimizar los riesgos asociados a una interrupción regional, ya que una interrupción regional puede afectar a todos los dominios de disponibilidad de la región. El despliegue en varias regiones también maximiza el valor del esfuerzo de ingeniería que invierte en transferir las cargas de trabajo entre varios centros de datos.
Escenario C: arquitectura de varias regiones
En este escenario, la arquitectura replica la misma pila en dos regiones.
Para proporcionar un origen de datos consistente en ambas regiones, utilice capacidades de replicación como GoldenGate para la capa de datos, Autonomous Data Guard para la capa de base de datos y políticas de replicación de Object Storage en el cubo de origen que identifiquen la región y el cubo en los que se va a realizar la replicación.
Para el front-end y la capa de aplicación, cree un equilibrador de carga y configure las capacidades de comprobación del sistema en los recursos de backend que se despliegan en los dominios de errores de ambas regiones. Cada vez que despliegue una nueva aplicación en producción, despliegue la aplicación en instancias de ambas regiones.
Explorar más
Documentación: