Ir al contenido
documentation.suse.com / Inicio rápido de Geo Clustering
SUSE Linux Enterprise High Availability 15 SP6

Inicio rápido de Geo Clustering

Fecha de publicación: 12 de diciembre de 2024

Geo Clustering protege las cargas de trabajo en centros de datos distribuidos por todo el mundo. Este documento sirve como guía para la configuración básica de un clúster geográfico mediante los guiones de bootstrap geográficos proporcionados por la shell crm.

Copyright © 2006–2024 SUSE LLC y colaboradores. Reservados todos los derechos.

Está permitido copiar, distribuir y modificar este documento según los términos de la licencia de documentación gratuita GNU, versión 1.2 o (según su criterio) versión 1.3. Este aviso de copyright y licencia deberán permanecer inalterados. En la sección titulada GNU Free Documentation License (Licencia de documentación gratuita GNU) se incluye una copia de la versión 1.2 de la licencia.

Para obtener información sobre las marcas comerciales de SUSE, consulte https://www.suse.com/company/legal/. Todas las marcas comerciales de otros fabricantes son propiedad de sus propietarios respectivos. Los símbolos de marcas comerciales (®, ™, etc.) indican marcas comerciales de SUSE y sus filiales. Los asteriscos (*) indican marcas comerciales de otros fabricantes.

Toda la información recogida en esta publicación se ha compilado prestando toda la atención posible al más mínimo detalle. Sin embargo, esto no garantiza una precisión total. Ni SUSE LLC, ni sus filiales, ni los autores o traductores serán responsables de los posibles errores o las consecuencias que de ellos pudieran derivarse.

1 Descripción conceptual

Los clústeres geográficos basados en SUSE® Linux Enterprise High Availability se pueden considerar clústeres de superposición en los que cada sitio de clúster se corresponde con un nodo de clúster en un clúster tradicional. El gestor de tickets del clúster de booth gestiona el clúster de superposición (en la instancia de booth al que se llama a continuación). Todas las partes implicadas en un clúster geográfico ejecutan un servicio, boothd. Este se conecta con los daemons de booth que se ejecuten en los demás sitios e intercambia detalles de conectividad. Para conseguir que los recursos del clúster tengan una alta disponibilidad en los sitios, la instancia de booth utiliza objetos de clúster denominados tickets. Un ticket otorga el derecho a ejecutar determinados recursos en un sitio de clúster específico. La instancia de booth garantiza que cada ticket solo se otorga a un único sitio a la vez.

Si se interrumpe la comunicación entre dos instancias de booth, puede deberse a una interrupción de la red entre los sitios de clúster o a una interrupción de un sitio de clúster. En tal caso, se necesita una instancia adicional (un tercer sitio de clúster o un arbitrator) para llegar a un consenso sobre las decisiones (por ejemplo, el failover de los recursos entre los sitios). Los árbitros son equipos individuales (exteriores a los clústeres) en los que se ejecuta una instancia de booth de un modo especial. Cada clúster geográfico puede tener uno o varios árbitros.

Clúster de dos sitios: 2x2 nodos + árbitro (opcional)
Figura 1: Clúster de dos sitios: 2x2 nodos + árbitro (opcional)

También es posible ejecutar un clúster geográfico de dos sitios sin árbitro. En este caso, un administrador de clústeres geográficos debe gestionar manualmente los tickets. Si es preciso otorgar un ticket a más de un sitio al mismo tiempo, booth muestra una advertencia.

Para obtener más detalles sobre el concepto, los componentes y la gestión de tickets que se usan para los clústeres geográficos, consulte el Book “Administration Guide”.

2 Ejemplo de uso

Los procedimientos de este documento conducen a un clúster geográfico básico con dos sitios de clúster y un árbitro:

  • Los sitios de clúster se denominan amsterdam y berlin.

  • Cada sitio estará compuesto por dos nodos. Los nodos alice y bob pertenecen al clúster amsterdam. Los nodos charlie y doro pertenecen al clúster berlin.

  • El sitio amsterdam recibe la siguiente dirección IP virtual: 192.168.201.100.

  • El sitio berlin recibe la siguiente dirección IP virtual: 192.168.202.100.

  • El árbitro tendrá la siguiente dirección IP: 192.168.203.100.

Antes de continuar, asegúrese de que se cumplen los siguientes requisitos:

Requisitos
Dos clústeres

Tiene al menos dos clústeres existentes que desea combinar en un clúster geográfico (si necesita configurar dos clústeres primero, siga las instrucciones del Article “Inicio rápido de instalación y configuración”).

Clústeres con nombres descriptivos

Cada clúster tiene un nombre significativo que refleja su ubicación, por ejemplo: amsterdam y berlin. Los nombres de clúster se definen en /etc/corosync/corosync.conf.

Árbitro

Se ha instalado un tercer equipo que no forma parte de los clústeres existentes y que se usará como árbitro.

Para los requisitos detallados de cada elemento, consulte también la Sección 3, “Requisitos”.

3 Requisitos

Todos los equipos (nodos de clúster y árbitros) necesitan al menos los siguientes módulos y extensiones:

  • Módulo de sistema base 15 SP6

  • Módulo de aplicaciones de servidor 15 SP6

  • SUSE Linux Enterprise High Availability 15 SP6

Al instalar los equipos, seleccione HA GEO Node como system role. De esta forma, se realiza una instalación mínima del sistema donde se instalan por defecto los paquetes del patrón Geo Clustering for High Availability (ha_geo).

Requisitos de red
  • Todo el clúster geográfico debe tener acceso a las direcciones IP virtuales que se utilizarán para cada sitio de clúster.

  • Debe ser posible acceder a los sitios en un puerto UDP y TCP por cada instancia de booth. Esto significa que los cortafuegos y los túneles IPsec intermedios deben configurarse según corresponda.

  • Si se realiza otra instalación distinta, puede ser necesario abrir más puertos (por ejemplo, para DRBD o para la réplica de la base de datos).

Otros requisitos y recomendaciones
  • Se deben sincronizar todos los nodos del clúster en todos los sitios con un servidor NTP fuera del clúster. Si desea información adicional, consulte Administration Guide for SUSE Linux Enterprise Server 15 SP6.

    Si no se sincronizan los nodos, resultará muy difícil analizar los archivos de registro y los informes del clúster.

  • Emplee un número impar de sitios en el clúster geográfico. Esto garantiza que, en caso de que la conexión de red se interrumpa, aún haya una mayoría de sitios (para evitar una situación de clúster con nodos malinformados, split brain). Si tiene un número par de sitios de clúster, utilice un árbitro para gestionar automáticamente el failover de tickets. Si no utiliza un árbitro, deberá gestionar manualmente el failover de tickets.

  • El clúster de cada sitio debe tener un nombre descriptivo, por ejemplo: amsterdam y berlin.

    Los nombres de clúster de cada sitio se deben definir en los archivos /etc/corosync/corosync.conf respectivos:

    totem {
        [...]
        cluster_name: amsterdam
        }

    Cambie el nombre con el comando siguiente de crmsh:

    # crm cluster rename NEW_NAME

    Detenga e inicie los servicios de clúster para que los cambios entren en vigor:

    # crm cluster restart
  • No se admiten las arquitecturas mixtas dentro de un mismo clúster. Sin embargo, en el caso de los clústeres geográficos, cada miembro del clúster geográfico puede tener una arquitectura distinta, ya sea un sitio de clúster o un árbitro. Por ejemplo, puede ejecutar un clúster geográfico con tres miembros (dos sitios de clúster y un árbitro), donde un sitio de clúster se ejecuta en IBM Z, el otro en x86 y el árbitro se ejecuta en POWER.

4 Descripción general de los guiones de bootstrap geográficos

  • El guion crm cluster geo_init convierte un clúster en el primer sitio de un clúster geográfico. Toma parámetros, como los nombres de los clústeres, al árbitro y uno o varios tickets, y crea el archivo /etc/booth/booth.conf a partir de ellos. Copia la configuración de booth a todos los nodos del sitio de clúster actual. También configura los recursos del clúster necesarios para booth en el sitio de clúster actual.

    Para obtener información, consulte la Sección 6, “Configuración del primer sitio de un clúster geográfico”.

  • El guion crm cluster geo_join añade el clúster actual a un clúster geográfico existente. Copia la configuración de booth de un sitio de clúster existente y lo escribe en el archivo /etc/booth/booth.conf en todos los nodos del sitio de clúster actual. También configura los recursos del clúster necesarios para booth en el sitio de clúster actual.

    Para obtener información, consulte la Sección 7, “Adición de otro sitio a un clúster geográfico”.

  • El guion crm cluster geo_init_arbitrator convierte el equipo actual en un árbitro para el clúster geográfico. Copia la configuración de booth de un sitio de clúster existente y lo escribe en el archivo /etc/booth/booth.conf.

    Para obtener información, consulte la Sección 8, “Adición del árbitro”.

Todos los guiones de bootstrap se registran en /var/log/crmsh/crmsh.log. Consulte el archivo de registro para obtener información sobre el proceso de bootstrap. Las opciones establecidas durante el proceso de bootstrap pueden modificarse más adelante (modificando la configuración de booth, los recursos, etc.). Para obtener información, consulte el Book “Administration Guide”.

5 Instalación de los paquetes de alta disponibilidad y clústeres geográficos

Los paquetes para configurar y gestionar un clúster geográfico se incluyen en los patrones de instalación High Availability y Geo Clustering for High Availability. Estos patrones solo están disponibles después de instalar SUSE Linux Enterprise High Availability.

Puede registrarse en el Centro de servicios al cliente de SUSE e instalar SUSE Linux Enterprise High Availability mientras instala SUSE Linux Enterprise Server o después de la instalación. Para obtener más información, consulte Deployment Guide para SUSE Linux Enterprise Server.

Procedimiento 1: Instalación de los patrones de alta disponibilidad y clústeres geográficos
  1. Instale los patrones de alta disponibilidad y clústeres geográficos desde la línea de comandos:

    # zypper install -t pattern ha_sles ha_geo
  2. Instale el patrón de alta disponibilidad y clústeres geográficos en todos los equipos que vayan a formar parte del clúster.

    Nota
    Nota: instalación de paquetes de software en todos los nodos

    Para realizar una instalación automática de SUSE Linux Enterprise Server 15 SP6 y SUSE Linux Enterprise High Availability 15 SP6, utilice AutoYaST para clonar los nodos existentes. Para obtener más información, consulte el Book “Administration Guide”, Chapter 3 “Installing SUSE Linux Enterprise High Availability”, Section 3.2 “Mass installation and deployment with AutoYaST”.

6 Configuración del primer sitio de un clúster geográfico

Use el comando crm cluster geo_init para convertir un clúster existente en el primer sitio de un clúster geográfico.

Procedimiento 2: Configuración del primer sitio (amsterdam) con crm cluster geo_init
  1. Defina una dirección IP virtual por cada sitio de clúster que se pueda usar para acceder al sitio. Supongamos que usa 192.168.201.100 y 192.168.202.100 para este propósito. Aún no es necesario configurar las direcciones IP virtuales como recursos del clúster. Eso lo hacen los guiones de bootstrap.

  2. Defina el nombre de al menos un ticket que otorgue el derecho a ejecutar ciertos recursos en un sitio de clúster. Utilice un nombre descriptivo que refleje los recursos que dependerán del ticket (por ejemplo, ticket-nfs). Los guiones de bootstrap solo necesitan el nombre del ticket; puede definir los detalles restantes más tarde (como dependencias de ticket de los recursos), como se describe en la Sección 10, “Pasos siguientes”.

  3. Inicie sesión en un nodo de un clúster existente (por ejemplo, en el nodo alice del clúster amsterdam).

  4. Ejecute crm cluster geo_init. Por ejemplo, use las siguientes opciones:

    # crm cluster geo_init \
      --clusters "amsterdam=192.168.201.100 berlin=192.168.202.100" \1
      --tickets ticket-nfs \2
      --arbitrator 192.168.203.1003

    1

    Los nombres de los sitios de clúster (como se definen en /etc/corosync/corosync.conf) y las direcciones IP virtuales que desea utilizar para cada sitio de clúster. En este caso, tenemos dos sitios de clúster (amsterdam y berlin) con una dirección IP virtual cada uno.

    2

    El nombre de uno o varios tickets.

    3

    El nombre de host o la dirección IP de un equipo situado fuera de los clústeres.

El guion de bootstrap crea el archivo de configuración de booth y lo sincroniza con todos los sitios del clúster. También crea los recursos básicos del clúster necesarios para booth. El Paso 4 del Procedimiento 2 dará como resultado la siguiente configuración de booth y los siguientes recursos del clúster:

Ejemplo 1: configuración de booth creada por crm cluster geo_init
# The booth configuration file is "/etc/booth/booth.conf". You need to
# prepare the same booth configuration file on each arbitrator and
# each node in the cluster sites where the booth daemon can be launched.

# "transport" means which transport layer booth daemon will use.
# Currently only "UDP" is supported.
transport="UDP"
port="9929"

arbitrator="192.168.203.100"
site="192.168.201.100"
site="192.168.202.100"
authfile="/etc/booth/authkey"
ticket="ticket-nfs"
expire="600"
Ejemplo 2: recursos de clúster creados por crm cluster geo_init
primitive1 booth-ip IPaddr2 \
  params rule #cluster-name eq amsterdam ip=192.168.201.100 \
  params rule #cluster-name eq berlin ip=192.168.202.100 \
primitive2 booth-site ocf:pacemaker:booth-site \
  meta resource-stickiness=INFINITY \
  params config=booth \
  op monitor interval=10s
group3 g-booth booth-ip booth-site \
meta target-role=Stopped4

1

Una dirección IP virtual para cada sitio de clúster. Se requiere para los daemons de booth que necesitan una dirección IP persistente en cada sitio de clúster.

2

Un recurso primitivo para el daemon de booth. Se comunica con los daemons de booth en los demás sitios del clúster. El daemon se puede iniciar en cualquier nodo del sitio. Para hacer que el recurso permanezca en el mismo nodo, si es posible, se debe definir el valor INFINITY en resource-stickiness.

3

Un grupo de recursos del clúster para ambos recursos primitivos. Con esta configuración, cada daemon de booth está disponible en su dirección IP individual, independientemente del nodo en el que se ejecute el daemon.

4

El grupo de recursos del clúster no se inicia por defecto. Después de verificar la configuración de los recursos del clúster (y añadir los recursos que necesita para completar la configuración), debe iniciar el grupo de recursos. Consulte Pasos necesarios para completar la configuración del clúster geográfico para obtener más información.

7 Adición de otro sitio a un clúster geográfico

Después de inicializar el primer sitio del clúster geográfico, añada un segundo clúster con crm cluster geo_join, como se describe en el Procedimiento 3. El guion necesita acceso SSH a un sitio de clúster ya configurado y añade el clúster actual al clúster geográfico.

Procedimiento 3: adición del segundo sitio (berlin) con crm cluster geo_join
  1. Inicie sesión en un nodo del sitio de clúster que desee añadir (por ejemplo, en el nodo charlie del clúster berlin).

  2. Ejecute el comando crm cluster geo_join. Por ejemplo:

    # crm cluster geo_join \
      --cluster-node 192.168.201.100\1
      --clusters "amsterdam=192.168.201.100 berlin=192.168.202.100"2

    1

    Especifica de dónde se debe copiar la configuración de booth. Utilice la dirección IP o el nombre de host de un nodo de un sitio de clúster geográfico ya configurado. También puede usar la dirección IP virtual de un sitio de clúster existente (como en este ejemplo). Como alternativa, use la dirección IP o el nombre de host de un árbitro ya configurado para el clúster geográfico.

    2

    Los nombres de los sitios de clúster (como se definen en /etc/corosync/corosync.conf) y las direcciones IP virtuales que desea utilizar para cada sitio de clúster. En este caso, tenemos dos sitios de clúster (amsterdam y berlin) con una dirección IP virtual cada uno.

El comando crm cluster geo_join copia la configuración de booth de 1, consulte el Ejemplo 1. Además, crea los recursos del clúster necesarios para la instancia de booth (consulte el Ejemplo 2).

8 Adición del árbitro

Después de configurar todos los sitios del clúster geográfico con crm cluster geo_init y crm cluster geo_join, configure el árbitro con crm cluster geo_init_arbitrator.

Procedimiento 4: Configuración del árbitro mediante crm cluster geo_init_arbitrator
  1. Inicie sesión en el equipo que desea utilizar como árbitro.

  2. Ejecute el comando siguiente. Por ejemplo:

    # crm cluster geo_init_arbitrator --cluster-node 192.168.201.1001

    1

    Especifica de dónde se debe copiar la configuración de booth. Utilice la dirección IP o el nombre de host de un nodo de un sitio de clúster geográfico ya configurado. Como alternativa, puede usar la dirección IP virtual de un sitio de clúster ya existente (como en este ejemplo).

El guion crm cluster geo_init_arbitrator copia la configuración de booth de 1, consulte el Ejemplo 1. También habilita e inicia el servicio de booth en el árbitro. Por lo tanto, el árbitro está listo para comunicarse con las instancias de booth de los sitios de clúster cuando los servicios de booth se ejecutan allí.

9 Supervisión de los sitios de clúster

Para ver ambos sitios de clúster con los recursos y el ticket que ha creado durante el proceso de bootstrap, utilice Hawk2. La interfaz Web Hawk2 permite supervisar y gestionar varios clústeres (no relacionados) y clústeres geográficos.

Requisitos previos
  • En todos los clústeres que se van a supervisar con la consola de Hawk2 se debe ejecutar SUSE Linux Enterprise High Availability 15 SP6.

  • Si aún no ha sustituido el certificado autofirmado de Hawk2 en cada nodo de clúster por su propio certificado (o por un certificado firmado por una autoridad certificadora oficial), haga lo siguiente: inicie sesión en Hawk2 en cada nodo y en cada clúster al menos una vez. Verifique el certificado (o añada una excepción en el navegador para omitir la advertencia). De lo contrario, Hawk2 no podrá conectarse al clúster.

Procedimiento 5: Uso de la consola de Hawk2
  1. Abra un navegador Web y escriba la dirección IP virtual del primer sitio de clúster, amsterdam:

    https://192.168.201.100:7630/

    Como alternativa, utilice la dirección IP o el nombre de host de los nodos alice o bob. Si ha configurado ambos nodos con los guiones de bootstrap, el servicio hawk debe ejecutarse en ambos nodos.

  2. Inicie sesión en la interfaz Web de Hawk2.

  3. En la barra de navegación izquierda, seleccione Consola.

    Hawk2 muestra un resumen de los nodos y los recursos del sitio de clúster actual. También muestra todos los tickets que se han configurado para el clúster geográfico. Si necesita información acerca de los iconos utilizados en esta vista, haga clic en Leyenda.

    Consola de Hawk2 con un sitio de clúster (amsterdam)
    Figura 2: Consola de Hawk2 con un sitio de clúster (amsterdam)
  4. Para añadir una consola del segundo sitio de clúster, haga clic en Añadir clúster.

    1. Introduzca un valor en Nombre de clúster para identificar el clúster en la consola. En este caso, berlin.

    2. Escriba el nombre de host completo de uno de los nodos del clúster (en este caso, charlie o doro).

    3. Haga clic en Añadir. Hawk2 muestra una segunda pestaña para el sitio de clúster recién añadido con un resumen de sus nodos y recursos.

      Consola de Hawk2 con ambos sitios de clúster
      Figura 3: Consola de Hawk2 con ambos sitios de clúster
  5. Para ver más detalles sobre un sitio de clúster, o para gestionarlo, cambie a la pestaña del sitio y haga clic en el icono de cadena.

    Hawk2 abre la vista Estado de ese sitio en una nueva ventana o pestaña del navegador. Allí, podrá administrar esa parte del clúster geográfico.

10 Pasos siguientes

Los guiones de bootstrap de los clústeres geográficos proporcionan una forma rápida de configurar un clúster geográfico básico que puede utilizarse con fines de prueba. Sin embargo, para convertir el clúster geográfico resultante en un clúster geográfico funcional que pueda usarse en entornos de producción, son necesarios más pasos.

Pasos necesarios para completar la configuración del clúster geográfico
Inicio de los servicios de booth en sitios de clúster

Después del proceso de bootstrap, el servicio booth del árbitro aún no puede comunicarse con los servicios booth de los sitios de clúster, ya que no se inician por defecto.

El servicio booth de cada sitio de clúster se gestiona mediante el grupo de recursos de booth g-booth (consulte el Ejemplo 2, “recursos de clúster creados por crm cluster geo_init). Para iniciar una instancia del servicio de booth en cada sitio, inicie el grupo de recursos de booth correspondiente en cada sitio de clúster. Esto permite que todas las instancias de booth se comuniquen entre sí.

Configuración de las dependencias del ticket y petición de restricciones

Para hacer que los recursos dependan del ticket que ha creado durante el proceso de bootstrap del clúster geográfico, debe configurar restricciones. Para cada restricción, establezca una loss-policy que defina qué debe ocurrir con los recursos respectivos si se revoca el ticket desde un sitio de clúster.

Para obtener información, consulte el Book “Geo Clustering Guide”, Chapter 6 “Configuring cluster resources and constraints”.

Concesión inicial de un ticket a un sitio

Antes de que la instancia de booth pueda gestionar un ticket determinado en el clúster geográfico, debe otorgarlo a un sitio manualmente. Puede utilizar la herramienta de línea de comandos del cliente de booth o Hawk2 para otorgar un ticket.

Para obtener más información, consulte el Book “Geo Clustering Guide”, Chapter 8 “Managing Geo clusters”.

Los guiones de bootstrap crean los mismos recursos de booth en ambos sitios de clúster, además de los mismos archivos de configuración de booth en todos los sitios, incluido el árbitro. Si extiende la configuración del clúster geográfico (para convertirlo en un entorno de producción), es probable que ajuste los detalles de la configuración de booth y que cambie la configuración de los recursos del clúster relacionados con la instancia de booth. Después, debe sincronizar los cambios realizados con los demás sitios del clúster geográfico para que entren en vigor.

Nota
Nota: sincronización de los cambios en todos los sitios de clúster
  • Para sincronizar los cambios de la configuración de booth en todos los sitios de clúster (incluido el árbitro), utilice Csync2. Hay más información disponible en el Book “Geo Clustering Guide”, Chapter 5 “Synchronizing configuration files across all sites and arbitrators”.

  • La CIB (base de datos de información del clúster) no se sincroniza automáticamente con los sitios de clúster de un clúster geográfico. Esto significa que los cambios en la configuración del recurso que se necesiten en todos los sitios de clúster deben transferirse a los demás sitios manualmente. Para hacerlo, etiquete los recursos respectivos, expórtelos desde la CIB actual e impórtelos a la CIB de los demás sitios de clúster. Para obtener información, consulte el Book “Geo Clustering Guide”, Chapter 6 “Configuring cluster resources and constraints”, Section 6.4 “Transferring the resource configuration to other cluster sites”.

11 Para más información