Alta Disponibilidad

Redundancia de hardware

La configuración mínima de bastidor base contiene componentes redundantes de red, almacenamiento y servidor para garantizar que el fallo de un solo elemento no afecte a la disponibilidad general del sistema.

La conectividad de datos en todo el sistema se basa en pares redundantes de conmutadores de hoja y columna vertebral. La agregación de enlaces se configura en todas las interfaces: puertos de conmutador, NIC de host y enlaces ascendentes. Los conmutadores de hoja interconectan los componentes del rack mediante cableado cruzado con interfaces de red redundantes en cada componente. Cada switch de interconexión de módulos también tiene una conexión con cada uno de los switches de interconexión de racks, que también están interconectados. Los switches de interconexión de racks forman la columna vertebral de la red y activan el tráfico externo al rack. Sus enlaces ascendentes a la red del centro de datos constan de dos pares de cables, que se conectan entre sí a dos conmutadores redundantes ToR (parte superior del bastidor).

El cluster de gestión, que ejecuta el software del controlador y los servicios de nivel de sistema, consta de tres nodos de gestión totalmente activos. Las solicitudes entrantes pasan por la IP virtual del cluster de nodos de gestión y las distribuye un equilibrador de carga entre los tres nodos. Si uno de los nodos deja de responder y se aleja del cluster, el equilibrador de carga sigue enviando tráfico a los dos nodos restantes hasta que el nodo con fallos vuelva a estar en buen estado y se vuelva a unir al cluster.

El almacenamiento del sistema y de los recursos en la nube del entorno lo proporciona el dispositivo ZFS Storage Appliance interno. Sus dos controladores forman un cluster activo-activo, lo que proporciona alta disponibilidad y un excelente rendimiento al mismo tiempo. Las agrupaciones ZFS se crean en discos en una configuración reflejada para obtener la mejor protección de datos.

Disponibilidad del Sistema

La capa de software y servicios se despliega en el cluster de gestión de tres nodos y aprovecha la alta disponibilidad que es inherente al diseño del cluster. El entorno de orquestación de contenedores de Kubernetes también utiliza la agrupación en clusters para sus propios nodos de controlador y los pods de servicio que aloja. Muchas réplicas de los microservicios se están ejecutando en un momento determinado. Los nodos y los pods se distribuyen entre los nodos de gestión, y Kubernetes garantiza que los pods con fallos se reemplacen por nuevas instancias para mantener todos los servicios en ejecución en una configuración activa/activa.

Todos los servicios y componentes almacenan datos en una base de datos MySQL central común. La base de datos de cluster MySQL tiene instancias desplegadas en los tres nodos de gestión. La disponibilidad, el equilibrio de carga, la sincronización de datos y la agrupación en clusters se controlan mediante componentes internos del cluster MySQL.

Una parte importante de la red de infraestructura a nivel de sistema está definida por software. La configuración de conmutadores virtuales, enrutadores y gateways no se almacena ni gestiona mediante los conmutadores, sino que se distribuye entre varios componentes de la arquitectura de red. El controlador de red se implementa como un servicio en contenedores de alta disponibilidad.

El marco de actualización aprovecha la redundancia de hardware y los diseños agrupados en clusters para proporcionar actualizaciones sucesivas para todos los componentes. Durante el cambio de versión de una instancia de componente, las instancias restantes garantizan que no haya tiempo de inactividad. La actualización se completa cuando todas las instancias de componentes se han actualizado y vuelto al funcionamiento normal.

Disponibilidad de instancia informática

En el caso de una instancia informática, la alta disponibilidad hace referencia a la recuperación automatizada de una instancia en caso de que falle la infraestructura subyacente. El estado de los nodos de cálculo, los hipervisores y las instancias informáticas se supervisa continuamente. Cada nodo de cálculo se sondea con un intervalo de 5 minutos. Cuando las instancias informáticas se caen, el sistema intenta recuperarlas automáticamente por defecto.

Por defecto, el sistema intenta reiniciar las instancias en el dominio de errores seleccionado, pero reiniciará las instancias en otros dominios de errores si no hay suficientes recursos disponibles en el dominio de errores seleccionado. El dominio de errores seleccionado es el dominio de errores especificado en la configuración de la instancia.

Si un nodo de cálculo cae debido a un reinicio no planificado, cuando el nodo de cálculo vuelve correctamente al funcionamiento normal, las instancias se reinician. En el siguiente intervalo de sondeo, por defecto, si se encuentran instancias que deben estar en ejecución pero que están en un estado diferente, el comando de inicio se vuelve a ejecutar. Si alguna instancia se ha parado y permanece en ese estado, el hipervisor intenta reiniciarlas hasta 5 veces. Las instancias que no se estaban ejecutando antes de que el nodo de cálculo dejara de estar disponible permanecen cerradas cuando el nodo de cálculo está activo y en ejecución de nuevo.

Un nodo de cálculo se considera que falla cuando se ha desconectado de la red de datos o ha estado en estado apagado durante aproximadamente 5 minutos. Este timeout de 5 minutos se corresponde con dos intentos de sondeo incorrectos y es el umbral para colocar el nodo de cálculo en estado FAIL y su agente en estado EVACUATING. Esta condición es necesaria antes de que se pueda iniciar la migración con reinicio.

La migración con reinicio implica que todas las instancias informáticas del nodo de cálculo con fallos se paran y se reinician en otro nodo de cálculo. Cuando se completa la migración, el agente del nodo de cálculo con fallos indica que las instancias se han evacuado. Si el nodo de cálculo finalmente se reinicia correctamente, debe pasar por un proceso de limpieza que elimine todas las configuraciones de instancia obsoletas y los discos virtuales asociados. Después de la limpieza, el nodo de cálculo puede volver a alojar instancias informáticas.

Durante toda la migración de reinicio, las instancias permanecen en estado de configuración de "traslado". Una vez finalizada la migración, el estado de configuración de la instancia cambia a "running". Las instancias que se pararon antes del fallo no se migran porque no están asociadas a ningún nodo de cálculo.

Continuidad del servicio

Compute Cloud@Customer ofrece varias funciones que mejoran aún más la alta disponibilidad. La monitorización de la salud en todos los niveles del sistema es un factor clave. Los datos de diagnóstico y rendimiento se recopilan de todos los componentes y, a continuación, se almacenan y procesan de forma centralizada y se ponen a disposición del personal de Oracle.

Para mitigar la pérdida de datos y apoyar la recuperación de la configuración del sistema y los servicios en caso de fallo, se realizan copias de seguridad consistentes y completas regularmente.

Opcionalmente, las cargas de trabajo desplegadas en Compute Cloud@Customer se pueden proteger contra el tiempo de inactividad y la pérdida de datos mediante la implementación de la recuperación ante desastres. Para lograrlo, dos infraestructuras de Compute Cloud@Customer deben configurarse en diferentes sitios y configurarse para que sean réplicas entre sí. Los recursos bajo control de recuperación ante desastres se almacenan por separado en los dispositivos de almacenamiento ZFS de cada sistema y se replican entre los dos. Cuando se produce un incidente en un sitio, el entorno se activa en el sistema de réplica con un tiempo de inactividad mínimo. Recomendamos que la recuperación ante desastres se implemente para todos los sistemas de producción críticos.