Alta disponibilidad

Redundancia de hardware

La configuración mínima del bastidor base contiene componentes redundantes de red, almacenamiento y servidor para garantizar que el fallo de un único 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 interconexión de módulos y de racks. 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 bastidor mediante cableado cruzado a 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 permiten el tráfico externo al rack. Sus enlaces ascendentes a la red del centro de datos constan de dos pares de cables, que están interconectados a dos conmutadores redundantes ToR (parte superior del rack).

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 completamente activos. Las solicitudes entrantes pasan por la IP virtual del cluster de nodos de gestión y un equilibrador de carga las distribuye entre los tres nodos. Si uno de los nodos deja de responder y se cierra desde el cluster, el equilibrador de carga sigue enviando tráfico a los dos nodos restantes hasta que el nodo que falla vuelva a estar en buen estado y se vuelva a unir al cluster.

El dispositivo ZFS Storage Appliance interno proporciona almacenamiento para el sistema y para los recursos en la nube del entorno. 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 inherente al diseño del cluster. El entorno de orquestación de contenedores de Kubernetes también utiliza la agrupación en clusters tanto para sus propios nodos de controlador como para 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 sustituyan 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 están controlados por componentes internos del cluster MySQL.

Una parte significativa de la red de infraestructura a nivel de sistema está definida por software. La configuración de conmutadores virtuales, enrutadores y puertas de enlace no se almacena ni gestiona en 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.

La estructura de actualización aprovecha la redundancia del hardware y los diseños en cluster 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. El cambio de versión se completa cuando todas las instancias de componentes se han actualizado y vuelto a su funcionamiento normal.

Disponibilidad de instancia informática

Para 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, hipervisores e instancias informáticas se controla continuamente. Cada nodo de cálculo se sondea con un intervalo de 5 minutos. Cuando las instancias informáticas se caen, el sistema intenta recuperarlo automáticamente por defecto.

Por defecto, el sistema intenta reiniciar instancias en el dominio de errores seleccionado, pero reiniciará 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 que se especifica en la configuración de la instancia.

Si un nodo de cálculo deja de funcionar debido a un reinicio no planificado, cuando el nodo de cálculo vuelve correctamente al funcionamiento normal, se reinician las instancias. En el siguiente intervalo de sondeo, por defecto, si se encuentran instancias que se deben estar ejecutando pero que tienen un estado diferente, se vuelve a ejecutar el comando de inicio. 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 fallido cuando se ha desconectado de la red de datos o ha estado apagado durante unos 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 reinician en otro nodo de cálculo. Una vez finalizada la migración, el agente del nodo de cálculo con fallos indica que se han evacuado las instancias. Si el nodo de cálculo finalmente se reinicia correctamente, debe pasar por un proceso de limpieza que elimine todas las configuraciones de instancias anticuadas y los discos virtuales asociados. Después de la limpieza, el nodo de cálculo puede alojar las instancias informáticas de nuevo.

Durante toda la migración con reinicio, las instancias permanecen en estado de configuración "moving". Una vez finalizada la migración, el estado de configuración de la instancia cambia a "en ejecución". Las instancias que se detuvieron 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, 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 soportar la recuperación de la configuración del sistema y los servicios en caso de fallo, se realizan copias de seguridad consistentes y completas con regularidad.

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 implantación de la recuperación ante desastres. Para lograrlo, se deben configurar dos infraestructuras de Compute Cloud@Customer en diferentes sitios y configurarlas para que se reproduzcan 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 ambos. 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.