sábado, 18 de enero de 2025

Curso de DevOps: Automatización VI. Relaciones, dependencias y políticas

El objetivo de este post es identificar las relaciones, dependencias y las políticas de automatización que se utilizan para derivar un clúster de automatización de referencia, con componentes heterogéneos. Para crear una arquitectura de automatización de clústeres, debemos centrarnos en ciertos elementos esenciales.

Curso de DevOps: Relaciones, dependencias y políticas

La automatización de un clúster implica varios componentes diferentes, y cada componente tiene un papel esencial que desempeñar. El componente central es la sala de control, que asume la responsabilidad de la concesión de licencias y proporciona capacidades de visualización de conocimientos, almacenamiento en caché, mensajería, servicio de conocimientos y descubrimiento de servicios de conocimientos. Toda la configuración para la automatización del clúster se realiza en una base de datos persistente, que puede ser PostgreSQL o cualquier otra base de datos de nuestra elección, donde podremos almacenar la base de datos de metadatos del panel. La base de datos persistente puede funcionar con capacidades de Elasticsearch para proporcionar una búsqueda rápida que permita una mejor búsqueda. Podemos tener varios componentes conectados a la sala de control, que se gestionarán para la automatización del clúster. Uno de ellos es el servidor SQL, podemos optar por un servidor Oracle, que tendrá una base de datos de sala de control y una base de datos de análisis. Podremos tener un servidor de versiones, que será un componente opcional. Nuestra sala de control también deberá funcionar con archivos compartidos, que pueden ser SMB. Utilizando todos estos componentes, podemos crear capacidades de automatización de clústeres.

Curso de DevOps: Relaciones, dependencias y políticas


Ahora vamos a ver los componentes esenciales del clúster. El primer componente es el propio grupo de clústeres. Podemos considerar un grupo de clústeres como un grupo de servicios agrupados que conmutan juntos si hay un fallo en uno de ellos, pues estarán estrechamente acoplados entre sí. En segundo lugar está el host, es la máquina del clúster, que se requiere para alojar el servicio. El tercero es el nodo, es un término genérico que se usa para máquinas en un clúster. Los nodos pueden ser de dos tipos: nodo primario que contiene el servicio de base de datos activo y un nodo secundario que es el servicio duplicado pasivo o en espera. Y finalmente, tendremos un servidor, que se encarga de escuchar todas las solicitudes y gestionar y procesar las solicitudes.

Curso de DevOps: Relaciones, dependencias y políticas


Dentro de la tarea del clúster de automatización. Dependiendo de nuestras  necesidades, podemos configurar un clúster de automatización para brindarnos la posibilidad de administrar fallas de aplicaciones y servicios, administrar fallas de sitios en organizaciones de múltiples sitios y ocuparnos de fallas de sistemas y hardware. Aparte de eso, también debemos identificar las razones críticas por las que utilizar el clúster de automatización. La primera razón es que nos facilita la replicación. Esta replicación puede ser de varios tipos, puede ser replicación sincrónica o replicación asincrónica. El objetivo principal es garantizar que el nodo primario y el nodo secundario estén sincronizados. La segunda razón para utilizar un clúster de automatización es gestionar el tiempo de inactividad y la conmutación por recuperación. La recuperación por recuperación se considera un proceso de restauración de la aplicación en un estado de conmutación por error a su estado original, que es el que tenía antes del error. El tercer uso importante del clúster de automatización es gestionar de forma inteligente la conmutación por error. La conmutación por error en una arquitectura de alta disponibilidad,  significa la capacidad del sistema de cambiar servicios esenciales, como servicios de base de datos y servicios SVN, automáticamente a un servidor de base de datos en espera o, a veces, a un servidor SVN. Y, por último, se trata de gestionar la degradación y la redundancia elegantes. Cuando el proceso de degradación es elegante, permite que las dependencias del clúster funcionen correctamente en un nodo primario degradado, mientras que se utiliza la redundancia para evitar un punto único de falla.

No hay comentarios:

Publicar un comentario