Inicio rápido de Geo Clustering #

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.

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 Administration Guide.

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

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

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

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

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).

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 Administration Guide.

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.

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

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:

# 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"

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

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.

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).

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.

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í.

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.

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.

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: 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 Capítulo 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 Sección 6.4, “Transferring the resource configuration to other cluster sites”.