Inicio rápido de Geo Clustering - documentation.suse.com...escenario de ejemplo con un clúster...

Inicio rápido de Geo Clustering

Geo Clustering para SUSE Linux Enterprise High AvailabilityExtension 12 SP2

Hay disponible capacidad para usar clústeres de alta disponibilidad adistancias ilimitadas como una extensión independiente, denominada GeoClustering para SUSE Linux Enterprise High Availability Extension. Graciasa los clústeres geográficos, es posible contar con varios sitios dispersosgeográficamente con un clúster local cada uno. El failover entre estosclústeres se coordina mediante una entidad de nivel superior: el daemonde booth ( boothd ). En este documento se explica cómo configurar unescenario de ejemplo con un clúster geográco de dos sitios, un árbitro yréplica de datos a través de DRBD.

Fecha de publicación: 18/05/2020

Tabla de contenidos

1 Instalación como extensión 3

2 Desafíos de los clústeres geográficos 5

3 Descripción conceptual 5

4 Requisitos 9

5 Escenario de ejemplo y pasos básicos: descripción general 10

6 Configuración de los servicios de booth 11

7 Configuración de DRBD 23

8 Sincronización de archivos de configuración en todos los sitios y árbitros 30

1 Inicio rápido de Geo Clustering

9 Configuración de los recursos y las restricciones del clúster 37

10 Configuración de la reubicación de IP mediante la actualización de DNS 47

11 Gestión de los clústeres geográficos 48

12 Solución de problemas 56

13 Actualización a la última versión del producto 57

A GNU Licenses 61


1 Instalación como extensiónPara utilizar High Availability Extension y Geo Clustering para SUSE Linux Enterprise HighAvailability Extension, necesita los paquetes incluidos en los siguientes patrones de instalación:

Alta disponibilidad

GeoCluster para alta disponibilidad

Nota: requisitos del paquete para árbitrosSi la instalación del clúster geográco incluye uno o varios árbitros (consulte Árbitro),estos solo necesitan el patrón GeoCluster para alta disponibilidad . Para obtenermás información sobre cómo instalar este patrón, consulte la Sección 1.2, “Instalación de

paquetes en árbitros”.

Ambos patrones solo están disponibles si ha registrado el sistema en el Centro de serviciosal cliente de SUSE (o en un servidor de registro local) y ha añadido los canales de productocorrespondientes o los medios de instalación como una extensión. Para obtener informaciónsobre cómo instalar extensiones, consulte la Guía de distribución de SUSE Linux Enterprise 12SP2, disponible en http://www.suse.com/documentation/ . Consulte el capítulo Instalación demódulos, extensiones y productos complementarios de otros fabricantes.

1.1 Instalación de paquetes en nodos del clúster

En caso de que se haya agregado tanto High Availability Extension como Geo Clustering paraSUSE Linux Enterprise High Availability Extension como extensiones, pero los paquetes aún nose hayan instalado, proceda como sigue:

1. Para instalar los paquetes de ambos patrones mediante la línea de comandos, utiliceZypper:

sudo zypper in -t pattern ha_sles ha_geo

2. Como alternativa, utilice YaST para realizar una instalación gráca:

a. Inicie YaST como usuario Root y seleccione Software Gestión de software.


http://www.suse.com/documentation/

b. Haga clic en Ver Patrones y active los patrones siguientes:

Alta disponibilidad

GeoCluster para alta disponibilidad

c. Haga clic en Aceptar para iniciar la instalación de los paquetes.

Importante: instalación de paquetes de software en todas laspartesLos paquetes de software necesarios para los clústeres de alta disponibilidad y geográficosno se copian automáticamente en los nodos del clúster.

Instale SUSE Linux Enterprise Server 12 SP2 y los patrones Alta disponibilidady GeoCluster para alta disponibilidad en todos los equipos que formaránparte del clúster geográco.

Si no desea instalar los paquetes de forma manual en todos los nodos que formaránparte del clúster, utilice AutoYaST para duplicar los nodos existentes. Encon-trará más información en la Guía de administración de SUSE Linux EnterpriseHigh Availability Extension 12 SP2, disponible en http://www.suse.com/documen-

tation/ . Consulte el capítulo Instalación y configuración básica, sección Distribuciónmasiva con AutoYaST.Para todos los equipos que necesitan la extensión Geo Clustering, actualmente debeinstalar los paquetes de los clústeres geográficos de forma manual. La compatibi-lidad de AutoYaST con Geo Clustering para SUSE Linux Enterprise High AvailabilityExtension aún no está disponible.

1.2 Instalación de paquetes en árbitros

1. Asegúrese de que Geo Clustering para SUSE Linux Enterprise High Availability Extensionse ha añadido a los equipos que sirven como árbitros.

2. Entre en cada árbitro e instale los paquetes con el comando siguiente:

sudo zypper in -t pattern ha_geo




Como alternativa, utilice YaST para instalar el patrón GeoCluster para alta dispo-nibilidad .

2 Desafíos de los clústeres geográficosPor lo general, los entornos geográficos están demasiado alejados para admitir la comunicaciónsincrónica entre los sitios. Eso provoca los siguientes desafíos:

¿Cómo asegurarse de que un sitio de clúster está activo y en funcionamiento?

¿Cómo asegurarse de que los recursos solo se han iniciado una vez?

¿Cómo asegurarse de que se puede lograr quórum entre los distintos sitios y se puede evitaruna situación de clúster con nodos malinformados?

¿Cómo se puede mantener el CIB actualizado en todos los nodos y sitios?

¿Cómo se gestiona el failover entre los sitios?

¿Cómo hay que ocuparse de la alta latencia en el caso de recursos que se deben detener?

En las secciones siguientes, encontrará información sobre cómo superar estos retos con SUSELinux Enterprise High Availability Extension.

3 Descripción conceptualLos clústeres geográficos basados en SUSE Linux Enterprise High Availability Extension sepueden considerar clústeres de “superposición” en los que cada sitio de clúster se correspondecon un nodo de clúster en un clúster tradicional. La superposición de clústeres se gestionamediante el mecanismo de booth. Garantiza que los recursos del clúster tengan siempre una altadisponibilidad en los distintos sitios del clúster. Esto se consigue mediante objetos de clústerdenominados tickets, que se tratan como dominios de failover entre sitios del clúster en casode que un sitio deje de estar activo. El mecanismo booth garantiza que cada ticket pertenecea un único sitio en cada momento.

En la lista siguiente se explican con más detalle los componentes individuales y los mecanismosque se han introducido para los clústeres geográficos.

COMPONENTES Y GESTIÓN DE TICKETS

Ticket


Un ticket otorga el derecho a ejecutar determinados recursos en un sitio de clústerespecíco. El ticket solo puede ser propiedad de un sitio en cada momento. Inicialmente,ninguno de los sitios tiene un ticket; el administrador del clúster debe otorgar cada ticketuna vez. Después, booth gestiona los tickets para el failover automático de los recursos.Aunque los administradores también pueden intervenir y otorgar o revocar tickets manual-mente.Después de que un ticket se revoque administrativamente, deja de estar gestionado porbooth. Para que booth vuelva a gestionar el ticket, este debe otorgarse de nuevo a un sitio.Los recursos se pueden asociar a un ticket determinado mediante dependencias. Losrecursos correspondientes a un ticket denido solo se inician si este está disponible en unsitio. Y viceversa, si el ticket se elimina, los recursos dependientes se detienen automáti-camente.La presencia o ausencia de tickets para un sitio se almacena en el CIB como un estadodel clúster. En relación con un ticket determinado, solo existen dos estados para un sitio:verdadero (el sitio tiene el ticket) o falso (el sitio no tiene el ticket). La situación en laque un determinado ticket está ausente (durante el estado inicial del clúster geográco)no es distinta a cuando el ticket se ha revocado. Ambos casos quedan reflejados con elvalor falso .Un ticket en un clúster de superposición es similar a un recurso en un clúster tradicional.Pero, a diferencia de los clústeres tradicionales, los tickets son el único tipo de recurso deun clúster de superposición. Se trata de recursos primitivos que no es necesario configurarni duplicar.

Gestor de tickets de clúster de booth

El mecanismo booth es la instancia que gestiona la distribución de los tickets y, por lo tanto,el proceso de failover entre los sitios de un clúster geográco. Todos los clústeres y árbitrosparticipantes ejecutan un servicio, boothd . Este se conecta con los daemons de booth quese ejecuten en los demás sitios e intercambia detalles de conectividad. Después de quese otorgue un ticket a un sitio, el mecanismo booth puede gestionar el ticket automática-mente: si el sitio que contiene el ticket está fuera de servicio, los daemons de booth votaráncuál de los otros sitios recibirá el ticket. Para protegerse contra fallos de conexión breves,los sitios que pierdan la votación (ya sea explícitamente o de forma implícita al desconec-tarse del cuerpo de la votación) deberán ceder el ticket tras un tiempo de espera. De estaforma, se garantiza que el ticket solo se redistribuirá una vez que el sitio anterior lo hayacedido. Consulte también Dependencia de hombre muerto ( loss-policy="fence" ).

Árbitro


Cada sitio ejecuta una instancia de booth que es responsable de la comunicación con losdemás sitios. Si en su instalación hay un número par de sitios, necesita una instanciaadicional para lograr el consenso a la hora de tomar decisiones, por ejemplo para elfailover de los recursos en los sitios. En tal caso, puede añadir uno o varios árbitros que seejecuten en sitios adicionales. Los árbitros son máquinas individuales en las que se ejecutauna instancia de booth de un modo especial. Dado que todas las instancias de booth secomunican entre sí, los árbitros ayudan a tomar decisiones más ables sobre si se debenotorgar o revocar tickets. Los árbitros no pueden contener tickets.Disponer de un árbitro es especialmente importante en el caso de que haya dos sitios; porejemplo, hay dos causas posibles por las que el sitio A ya no puede comunicarse con elsitio B :

Un fallo de red entre A y B .

El sitio B está inactivo.

Sin embargo, si el sitio C (el árbitro) aún puede comunicarse con el sitio B , el sitio B aúndebe estar activo y en ejecución.

Failover del ticket

Si el ticket se pierde, lo que signica que las demás instancias de booth no tienen noticiasdel propietario del ticket durante un tiempo lo suficientemente prolongado, uno de lossitios restantes adquirirá el ticket. Esto se denomina failover del ticket. Si los miembrosrestantes no consiguen formar una mayoría, no se puede realizar el failover del ticket.

Dependencia de hombre muerto ( loss-policy="fence" )

Cuando se revoca un ticket, puede pasar mucho tiempo antes de que todos los recursosdependientes del ticket se detengan, especialmente en el caso de los recursos en cascada.Para acortar el proceso, el administrador del clúster puede configurar, junto con las depen-dencias del ticket, una directiva de pérdida ( loss-policy ) por si el ticket se revoca enun sitio. Si la directiva de la pérdida se dene como un límite ( fence ), los nodos en losque se encuentran los recursos dependientes se aíslan.

Aviso: pérdida potencial de datosPor otro lado, loss-policy="fence" acelera considerablemente el proceso derecuperación del clúster y garantiza que los recursos se puedan migrar con másrapidez.


Pero también puede producir una pérdida de todos los datos no escritos, porejemplo:

Los datos que se encuentran en un almacenamiento compartido (como DRBD).

Los datos de una base de datos de réplica (por ejemplo, MariaDB o PostgreSQL)que aún no haya accedido al otro sitio porque su enlace de red sea lento.

FIGURA 1: CLÚSTER DE DOS SITIOS (4 NODOS + ÁRBITRO)

Probablemente, el caso más habitual sea el de un clúster geográco con dos sitios y un únicoárbitro en un tercer sitio. Esto requiere tres instancias de booth, consulte la Figura 1, “Clúster de

dos sitios (4 nodos + árbitro)”. El límite máximo (actualmente) es de 16 instancias de booth.

Como es habitual, el CIB se sincroniza en cada clúster, pero no se sincroniza automáticamenteen todos los sitios de un clúster geográco. Sin embargo, a partir de SUSE Linux EnterpriseHigh Availability Extension12, transferir configuraciones de recursos a otros sitios de clúster esmás fácil. Para obtener información, consulte la Sección 9.3, “Transferencia de la configuración del

recurso a otros sitios de clúster”.


4 RequisitosREQUISITOS DE SOFTWARE

Todos los clústeres que formarán parte del clúster geográco deben basarse en SUSE LinuxEnterprise High Availability Extension 12 SP2.

SUSE® Linux Enterprise Server 12 SP2 debe estar instalado en todos los árbitros.

Geo Clustering para SUSE Linux Enterprise High Availability Extension debe estar instaladoen todos los nodos del clúster y en todos los árbitros que formarán parte del clústergeográco.

REQUISITOS DE RED

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

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 NTPfuera del clúster. Para obtener más información, consulte la Guía de administración de SUSELinux Enterprise Server 12 SP2, disponible en http://www.suse.com/documentation/ .Consulte el capítulo Sincronización de hora con NTP.Si no se sincronizan los nodos, resultará muy difícil analizar los archivos de registro y losinformes del clúster.



5 Escenario de ejemplo y pasos básicos: descripcióngeneralEn las secciones siguientes se muestra un escenario de ejemplo como se describe a continuación:

EJEMPLO 1: ESCENARIO CON UN CLÚSTER DE DOS SITIOS, UN ÁRBITRO Y RÉPLICA DE DATOS A TRAVÉS DE DRBD

Un clúster geográco con dos sitios, amsterdam y berlin , y un árbitro.

Cada sitio tiene una red privada enrutada a otro sitio:

amsterdam: 192.168.201.x

berlin: 192.168.202.x

En cada sitio se ejecuta un clúster de dos nodos:

El clúster amsterdam consta de los nodos alice y bob .

El clúster berlin consta de los nodos charly y doro .

Los datos se replican en todos los sitios con DRBD en modo asincrónico para larecuperación tras fallo.

La configuración del booth y de otros archivos de configuración importantes sesincroniza en los sitios del clúster y en el árbitro mediante Csync2.

Para configurar este escenario hay que realizar los pasos básicos siguientes:

Configuración de los servicios de booth

1. Selección de si se desea utilizar Configuración por defecto de booth o Configuración de

booth para varios inquilinos.

2. Sincronización de la configuración de booth en todos los sitios y árbitros.

3. Configuración de los recursos del clúster para el booth, como se explica en Depen-

dencias, restricciones y recursos del ticket para booth.

4. Transferencia de la configuración del recurso a otros sitios de clúster.

5. Habilitación e inicio de los servicios de booth.


Configuración de DRBD

1. Configuración de DRBD, como se describe en Configuración de DRBD.

2. Configuración de los recursos del clúster para DRBD, como se explica en Recursos y

restricciones de DRBD.

3. Transferencia de la configuración del recurso a otros sitios de clúster.

4. Sincronización de los archivos de configuración de DRBD, como se muestra en Sincro-

nización de cambios con Csync2.

Sincronización de archivos de configuración en todos los sitios y árbitros

1. Configuración de Csync2, como se explica en Configuración de Csync2 para clústeres

geográficos.

2. Sincronización inicial de todos los archivos de configuración relevantes en los sitiosy árbitros, como se describe en Sincronización de cambios con Csync2.

6 Configuración de los servicios de boothLa configuración de booth por defecto es /etc/booth/booth.conf . Este archivo debe ser elmismo en todos los sitios del clúster geográco, incluidos los árbitros. Para mantener la confi-guración de booth sincronizada en todos los sitios y árbitros, utilice Csync2, como se describeen la Sección 6.3, “Sincronización de la configuración de booth en todos los sitios y árbitros”.

Nota: propiedad de /etc/booth y los archivosEl directorio /etc/booth y todos los archivos incluidos en él deben pertenecer al usuariohacluster y al grupo haclient . Siempre que copie un archivo nuevo desde este direc-torio, utilice la opción -p para que el comando cp preserve la propiedad. Como alter-nativa, cuando cree un archivo nuevo, dena el usuario y el grupo después mediantechown hacluster:haclientARCHIVO .

En las instalaciones que incluyen varios clústeres geográficos, es posible “compartir” el mismoárbitro (a partir de SUSE Linux Enterprise High Availability Extension 12). Al proporcionarvarios archivos de configuración de booth, es posible iniciar varias instancias de booth en el


mismo árbitro, ejecutando cada instancia en un puerto distinto. De este modo, puede utilizar unúnico equipo como árbitro para distintos clústeres geográficos. Para obtener información sobrecómo configurar booth para varios clústeres geográficos, consulte la Sección 6.2, “Configuración

de booth para varios inquilinos”.

Para impedir que partes malintencionadas puedan interrumpir el servicio de booth, es posibleconfigurar que el servicio de autenticación se comunique con booth basándose en una clavecompartida. Para obtener más información, consulte 5 en el Ejemplo 2, “Archivo de configuración

de booth”. Todos los hosts que se comunican con varios servidores de booth necesitan esta clave.Por lo tanto, asegúrese de incluir el archivo de clave en la configuración de Csync2 o sincronícelomanualmente a todas las partes.

6.1 Configuración por defecto de booth

Para configurar todos los parámetros necesarios para booth, edite manualmente los archivos deconfiguración de booth o mediante el módulo GeoCluster de YaST. Para acceder al módulo deYaST, inícielo en la línea de comandos con yast2 geo-cluster (o inicie YaST y seleccioneAlta disponibilidad GeoCluster).

EJEMPLO 2: ARCHIVO DE CONFIGURACIÓN DE BOOTH

transport = UDP 1

port = 9929 2

arbitrator = 147.2.207.14 3

site = 192.168.201.151 4

site = 192.168.202.151 4

authfile = /etc/booth/authkey 5

ticket = "ticket-nfs" 6

expire = 600 7

timeout = 10 8

retries = 5 9

renewal-freq = 30 10

before-acquire-handler 11 = /etc/booth/ticket-nfs 12 ms_drbd_nfs 13

acquire-after = 60 14

ticket = "ticketA" 6

expire = 600 7

timeout = 10 8

retries = 5 9


before-acquire-handler 11 = /etc/booth/ticket-A 12 db-1 13


ticket = "ticketB" 6

expire = 600 7


timeout = 10 8

retries = 5 9


before-acquire-handler 11 = /etc/booth/ticket-B 12 db-8 13


1 El protocolo de transporte utilizado para la comunicación entre los sitios. Solo se admiteUDP, pero se incluirán otras capas de transporte en el futuro. Actualmente, este parámetrose puede omitir.

2 El puerto que se debe usar para la comunicación entre las instancias de booth de cada sitio.Si no usa el puerto por defecto ( 9929 ), elija uno que no se utilice ya en otros servicios.Asegúrese de abrir el puerto en el cortafuegos de los nodos y los árbitros. Los clientes debooth utilizan TCP para comunicarse con boothd . El mecanismo booth siempre se asociaa los puertos UDP y TCP y realiza la escucha en ellos.

3 La dirección IP del equipo que se debe usar como árbitro. Añada una entrada para cadaárbitro que utilice en la configuración del clúster geográco.

4 La dirección IP que se utiliza para boothd en un sitio. Añada una entrada para cada sitioque utilice en la configuración del clúster geográco. Asegúrese de insertar las direccionesIP virtuales correctas ( IPaddr2 ) para cada sitio; de lo contrario, el mecanismo booth nofuncionará correctamente. Para obtener información sobre cómo configurar la dirección IPvirtual para booth, consulte el Procedimiento 7, “Configuración de un grupo de recursos para

boothd”. booth funciona con direcciones IPv4 e IPv6.

5 Parámetro opcional. Permite la autenticación de booth para los clientes y servidoresbasándose en una clave compartida. Este parámetro especica la vía al archivo de clave.

REQUISITOS DE LA CLAVE

La clave puede ser binaria o de texto.Si es de texto, los siguientes caracteres se omiten: los espacios en blanco inicial y naly los saltos de línea.

La clave debe tener entre 8 y 64 caracteres.

La clave debe pertenecer al usuario hacluster y al grupo haclient .

Solo el propietario de la clave debe ser capaz de leerla.

6 El ticket que se va a gestionar en booth. Para cada ticket, añada una entrada ticket . Eneste ejemplo, se usará el ticket ticket-nfs para el failover de NFS y DRBD. Consulte laSección 7, “Configuración de DRBD” para obtener más información.


7 Parámetro opcional. Dene el tiempo de caducidad del ticket en segundos. Un sitio al quese la ha otorgado un ticket lo renovará con regularidad. Si booth no recibe informaciónacerca de la renovación del ticket en el tiempo de caducidad denido, el ticket se revoca yse otorga a otro sitio. Si no se especica ningún tiempo de caducidad, el ticket caduca pordefecto después de 600 segundos. No se debe establecer un valor inferior a 120 segundospara este parámetro.

8 Parámetro opcional. Dene un periodo de tiempo límite en segundos. Después de esetiempo, booth vuelve a enviar los paquetes si no ha recibido una respuesta. El tiempo límitedenido debe ser lo suficientemente largo para permitir que los paquetes lleguen a otrosmiembros de booth (todos los árbitros y sitios).

9 Parámetro opcional. Dene el número de veces que booth intenta enviar los paquetes antesde que deje de esperar una confirmación de otros sitios. No se admiten valores inferioresa 3 , que impedirían que booth se iniciara.

10 Parámetro opcional. Establece la frecuencia de renovación del ticket. La renovación delticket se produce por defecto a la mitad del tiempo límite. Si la fiabilidad de la red se reducea menudo por largo periodos de tiempo, es aconsejable renovar con más frecuencia. Antesde cada renovación, se ejecuta before-acquire-handler .

11 Parámetro opcional. Admite uno o varios guiones. Si desea utilizar más de un guion,cada uno de ellos puede ser responsable de comprobaciones diferentes, como el estadodel clúster, la conectividad del centro de datos, los sensores de estado del entorno, etc.Almacene todos los guiones en el directorio /etc/booth.d/TICKET_NAME y asegúresede que tienen la propiedad correcta (usuario hacluster y grupo haclient ). Asigne elnombre de directorio como valor para el parámetro before-acquire-handler .Los guiones de este directorio se ejecutan en orden alfabético. Todos los guiones se llamanantes de que boothd intente adquirir o renovar un ticket. Para que el informe se otorgue ose renueve, todos los guiones se deben completar correctamente. La semántica es la mismaque para un único guion: si el código de salida no es 0 , boothd cede el ticket.

12 El guion /usr/share/booth/service-runnable se incluye en el producto como ejemplo.Para usarlo, enlácelo en el directorio “ticket” correspondiente:

root # ln -s /usr/share/booth/service-runnable /etc/booth.d/TICKET_NAME

Supongamos que el directorio /etc/booth.d/TICKET_NAME contiene el guion service-runnable . Este guion sencillo se basa en crm_simulate . Se puede utilizar para probarsi un recurso de clúster determinado puede ejecutarse en el sitio actual del clúster. Estosignica que comprueba si el clúster está en un estado lo suficientemente bueno para


ejecutar el recurso (se cumplen todas las dependencias del recurso, la partición de clústertiene quórum, no hay nodos contaminados, etc.). Por ejemplo, si un servicio de la cadenade dependencias tiene como número de fallos el valor INFINITY en todos los nodos dispo-nibles, el servicio no se puede ejecutar en dicho sitio. En tal caso, reclamar el ticket nosirve de nada.

13 El recurso que se va a probar mediante before-acquire-handler (en este caso, por elguion service-runnable ). Debe hacer referencia al recurso que está protegido por elticket respectivo. En este ejemplo, el recurso db-1 está protegido por ticketA , mientrasque db-8 está protegido por ticketB . El recurso para DRBD ( ms_drbd_nfs ) estáprotegido por el ticket ticket-nfs .

14 Parámetro opcional. Cuando se pierda un ticket, booth esperará este tiempo de más antesde adquirir el ticket. Esto sirve para permitir que el sitio que ha perdido el ticket cedalos recursos, ya sea deteniéndolos o delimitándolos. Un retraso típico puede ser de 60segundos, pero en última instancia depende de los recursos protegidos y la configuraciónde delimitación. El valor por defecto es 0 .Si no tiene claro cuánto tiempo tardarán en detenerse o bajar de nivel los recursos o enaislarse un nodo (depende de loss-policy ), utilice este parámetro para impedir que losrecursos se ejecuten en dos sitios al mismo tiempo.

PROCEDIMIENTO 1: EDICIÓN MANUAL DEL ARCHIVO DE CONFIGURACIÓN DE BOOTH

1. Entre en un nodo de clúster como usuario root o equivalente.

2. Copie el archivo de configuración de booth de ejemplo /etc/booth/

booth.conf.example para /etc/booth/booth.conf :

root # cp -p /etc/booth/booth.conf.example /etc/booth/booth.conf

3. Edite /etc/booth/booth.conf de acuerdo con el Ejemplo 2, “Archivo de configuración de

booth”.

4. Compruebe los cambios y guarde el archivo.

5. En todos los nodos del clúster y árbitros, abra el puerto en el cortafuegos que se hayaconfigurado para booth. Consulte el Ejemplo 2, “Archivo de configuración de booth”, posición

2 .

PROCEDIMIENTO 2: CONFIGURACIÓN DE BOOTH CON YAST

1. Entre en un nodo de clúster como usuario root o equivalente.


2. Inicie el módulo GeoCluster de YaST.

3. Seleccione la opción Editar para modicar un archivo de configuración de booth existenteo Añadir para crear un nuevo archivo de configuración de booth:

a. En la pantalla que aparece, congure los siguientes parámetros:

Archivo de configuración. Un nombre para el archivo de configuración debooth. YaST sugiere booth por defecto. Esto hace que la configuraciónde booth se escriba en /etc/booth/booth.conf . Cambie este valor solo sinecesita configurar varias instancias de booth para diferentes clústeres geográ-ficos, tal y como se describe en la Sección 6.2, “Configuración de booth para varios

inquilinos”.

Transporte. El protocolo de transporte utilizado para la comunicación entrelos sitios. Solo se admite UDP, pero se incluirán otras capas de transporteen el futuro. Consulte también el Ejemplo 2, “Archivo de configuración de booth”,posición 1 .

Puerto. El puerto que se debe usar para la comunicación entre las instanciasde booth de cada sitio. Consulte también el Ejemplo 2, “Archivo de configuración

de booth”, posición 2 .

Árbitro. La dirección IP del equipo que se debe usar como árbitro. Consultetambién el Ejemplo 2, “Archivo de configuración de booth”, posición 3 .Para especificar un árbitro, haga clic en Añadir. En el recuadro de diálogo quese abre, introduzca la dirección IP de su árbitro y haga clic en Aceptar.

Sitio. La dirección IP que se utiliza para boothd en un sitio. Consulte tambiénel Ejemplo 2, “Archivo de configuración de booth”, posición 4 .Para especificar un sitio del clúster geográco, haga clic en Añadir. En elrecuadro de diálogo que se abre, introduzca la dirección IP de un sitio y hagaclic en Aceptar.

Ticket. El ticket que se va a gestionar en booth. Consulte también el Ejemplo 2,

“Archivo de configuración de booth”, posición 6 .Para especificar un ticket, haga clic en Añadir. En el recuadro de diálogo quese abre, introduzca un nombre de ticket exclusivo. Si necesita denir variostickets con los mismos parámetros y valores, puede ahorrarse el esfuerzo de


configuración creando una “plantilla de ticket” que especifique los parámetrosy valores por defecto para todos los tickets. Para hacerlo, utilice __default__como nombre de ticket.

Autenticación. Para habilitar la autenticación para booth, haga clic en Auten-ticación y, en el recuadro de diálogo que se abre, active Habilitar autenticaciónde seguridad. Si ya tiene una clave, especifique la vía y el nombre del archivoen Archivo de autenticación. Para generar un archivo de clave para un clústergeográco nuevo, haga clic en Generar archivo de clave de autenticación. La clavese crea y se escribe en la ubicación especificada en Archivo de autenticación.Asimismo, puede especificar parámetros opcionales para el ticket. Para obteneruna descripción general, consulte el Ejemplo 2, “Archivo de configuración de booth”,posiciones 7 a 14 .Haga clic en Aceptar para conrmar los cambios.

FIGURA 2: DEPENDENCIA DE TICKET DE EJEMPLO

b. Haga clic en Aceptar para cerrar la pantalla de configuración de booth actual. YaSTmuestra el nombre del archivo de configuración de booth que haya denido.

4. Antes de cerrar el módulo de YaST, cambie a la categoría Configuración del cortafuegos.

5. Para abrir el puerto que ha configurado para booth, habilite Abrir puerto en el cortafuegos.


Importante: configuración del cortafuegos solo para elequipo localLa configuración del cortafuegos solo se aplica al equipo actual. Abre lospuertos TCP/UDP de todos los puertos que se han especificado en /etc/booth/booth.conf o en cualquier otro archivo de configuración de booth (consulte laSección 6.2, “Configuración de booth para varios inquilinos”).

Asegúrese de abrir también los puertos correspondientes en todos los demás nodosdel clúster y árbitros de la configuración del clúster geográco. Puede hacerlomanualmente o sincronizando los archivos siguientes con Csync2:

/etc/sysconfig/SuSEfirewall2

/etc/sysconfig/SuSEfirewall2.d/services/booth

6. Haga clic en Finalizar para conrmar todos los ajustes y cerrar el módulo de YaST. Depen-diendo del NOMBRE del archivo de configuración especificado en el Paso 3.a, la configuraciónse escribe en /etc/booth/NOMBRE.conf .

6.2 Configuración de booth para varios inquilinos

En las instalaciones que incluyen varios clústeres geográficos, es posible “compartir” el mismoárbitro (a partir de SUSE Linux Enterprise High Availability Extension 12). Al proporcionarvarios archivos de configuración de booth, es posible iniciar varias instancias de booth en elmismo árbitro, ejecutando cada instancia en un puerto distinto. De este modo, puede utilizar unúnico equipo como árbitro para distintos clústeres geográficos.

Supongamos que dispone de dos clústeres geográficos, uno en la zona EMEA (Europa, Orientemedio y África) y otro en la región Asia-Pacíco (APAC).

Para utilizar el mismo árbitro para ambos clústeres geográficos, cree dos archivos de confi-guración en el directorio /etc/booth : /etc/booth/emea.conf y /etc/booth/apac.conf .Como mínimo, debe haber diferencias entre ambos en los siguientes parámetros:

El puerto utilizado para la comunicación de las instancias de booth.

Los sitios que pertenecen a los distintos clústeres geográficos para los que se usa el árbitro.


EJEMPLO 3: /etc/booth/apac.conf

transport = UDP 1

port = 9133 2

arbitrator = 147.2.207.14 3

site = 192.168.2.254 4

site = 192.168.1.112 4

authfile = /etc/booth/authkey-apac 5

ticket ="tkt-db-apac-intern" 6

timeout = 10 retries = 5 renewal-freq = 60 before-acquire-handler 11 = /usr/share/booth/service-runnable 12 db-apac-intern 13 ticket = "tkt-db-apac-cust" 6

timeout = 10 retries = 5 renewal-freq = 60 before-acquire-handler = /usr/share/booth/service-runnable db-apac-cust

EJEMPLO 4: /etc/booth/emea.conf

transport = UDP 1

port = 9150 2

arbitrator = 147.2.207.14 3

site = 192.168.201.151 4

site = 192.168.202.151 4

authfile = /etc/booth/authkey-emea 5

ticket = "tkt-sap-crm" 6

expire = 900 renewal-freq = 60 before-acquire-handler 11 = /usr/share/booth/service-runnable 12 sap-crm 13

ticket = "tkt-sap-prod" 6

expire = 600 renewal-freq = 60 before-acquire-handler = /usr/share/booth/service-runnable sap-prod

1 El protocolo de transporte utilizado para la comunicación entre los sitios. Solo se admiteUDP, pero se incluirán otras capas de transporte en el futuro. Actualmente, este parámetrose puede omitir.

2 El puerto que se debe usar para la comunicación entre las instancias de booth de cada sitio.Los archivos de configuración utilizan puertos diferentes para iniciar varias instancias debooth en el mismo árbitro.

3 La dirección IP del equipo que se debe usar como árbitro. En los ejemplos anteriores, seutiliza el mismo árbitro para diferentes clústeres geográficos.


4 La dirección IP que se utiliza para boothd en un sitio. Los sitios denidos en ambosarchivos de configuración de booth son distintos, ya que pertenecen a dos clústeres geográ-ficos diferentes.

5 Parámetro opcional. Permite la autenticación de booth para los clientes y servidoresbasándose en una clave compartida. Este parámetro especica la vía al archivo de clave.Utilice archivos de clave diferentes para distintos inquilinos.

REQUISITOS DE LA CLAVE

La clave puede ser binaria o de texto.Si es de texto, los siguientes caracteres se omiten: los espacios en blanco inicial y naly los saltos de línea.

La clave debe tener entre 8 y 64 caracteres.

La clave debe pertenecer al usuario hacluster y al grupo haclient .

Solo el propietario de la clave debe ser capaz de leerla.

6 El ticket que se va a gestionar en booth. En teoría, es posible denir el mismo nombre deticket en distintos archivos de configuración de booth: los tickets no interferirán entre síporque forman parte de clústeres geográficos distintos que están gestionados por distintasinstancias de booth. Sin embargo, (para facilitar el resumen) es recomendable utilizarnombres de ticket distintos para cada clúster geográco, tal y como se muestra en losejemplos anteriores.

11 Parámetro opcional. Si se dene, el comando especificado se llamará antes de que boothdintente adquirir o renovar un ticket. Si el código de salida es distinto a 0 , boothd cedeel ticket.

12 El guion service-runnable al que se hace referencia aquí se incluye en el producto comoejemplo. Se trata de un guion sencillo basado en crm_simulate . Se puede utilizar paraprobar si un recurso de clúster determinado puede ejecutarse en el sitio actual del clúster.Esto signica que comprueba si el clúster está en un estado lo suficientemente bueno paraejecutar el recurso (se cumplen todas las dependencias del recurso, la partición de clústertiene quórum, no hay nodos contaminados, etc.). Por ejemplo, si un servicio de la cadenade dependencias tiene como número de fallos el valor INFINITY en todos los nodos dispo-nibles, el servicio no se puede ejecutar en dicho sitio. En tal caso, reclamar el ticket nosirve de nada.


13 El recurso que se va a probar mediante before-acquire-handler (en este caso, por elguion service-runnable ). Debe hacer referencia al recurso que está protegido por elticket respectivo.

PROCEDIMIENTO 3: USO DEL MISMO ÁRBITRO PARA DISTINTOS CLÚSTERES GEOGRÁFICOS

1. Cree archivos de configuración de booth distintos en /etc/booth , como se muestra enel Ejemplo 3, “/etc/booth/apac.conf” y el Ejemplo 4, “/etc/booth/emea.conf”. Hágalomanualmente o mediante YaST, como se describe en el Procedimiento 2, “Configuración de

booth con YaST”.

2. En el árbitro, abra los puertos denidos en alguno de los archivos de configuración debooth de /etc/booth .

3. En los nodos que pertenecen a los clústeres geográficos individuales para los que se utilizael árbitro, abra el puerto que se utiliza para la instancia de booth respectiva.

4. Sincronice los archivos de configuración de booth correspondientes en todos los nodosdel clúster y en los árbitros que utilicen la misma configuración de booth. Para obtenerinformación, consulte la Sección 6.3, “Sincronización de la configuración de booth en todos los

sitios y árbitros”.

5. En el árbitro, inicie las instancias individuales de booth, como se describe en Inicio de los

servicios de booth en árbitros para las configuraciones de varios inquilinos.

6. En los clústeres geográficos individuales, inicie el servicio de booth como se describe enInicio de los servicios de booth en sitios de clúster.

6.3 Sincronización de la configuración de booth en todos los sitiosy árbitros

Nota: uso de la misma configuración de booth en todos lossitios y árbitrosPara que booth funcione correctamente, todos los nodos del clúster y los árbitros de unclúster geográco deben utilizar la misma configuración de booth.

Puede utilizar Csync2 para sincronizar la configuración de booth. Para obtener másdetalles, consulte la Sección 8.1, “Configuración de Csync2 para clústeres geográficos” y laSección 8.2, “Sincronización de cambios con Csync2”.


En caso de que cambie alguna configuración de booth, asegúrese de actualizar en conse-cuencia los archivos de configuración en todas las partes y reinicie los servicios de booth,tal y como se describe en la Sección 6.5, “Reconfiguración de booth durante la ejecución”.

6.4 Habilitación e inicio de los servicios de booth

Inicio de los servicios de booth en sitios de clúster

El servicio de booth para cada sitio de clúster se gestiona mediante el grupo de recursos debooth configurado en el Procedimiento 7, “Configuración de un grupo de recursos para boothd”.Para iniciar una instancia del servicio de booth en cada sitio, inicie el grupo de recursosde booth correspondiente en cada sitio de clúster.

Inicio de los servicios de booth en árbitros

A partir de SUSE Linux Enterprise 12, los árbitros de booth se gestionan con systemd.El archivo de unidad se denomina [email protected] . El signo @ indica la posibilidadde ejecutar el servicio con un parámetro, que en este caso es el nombre del archivo deconfiguración.Para habilitar el servicio de booth en un árbitro, utilice el comando siguiente:

root # systemctl enable booth@booth

Después de habilitar el servicio en la línea de comandos, se puede usar Gestor de serviciosde YaST para gestionar el servicio, siempre que no esté inhabilitado. En tal caso, desapa-recerá de la lista de servicios de YaST la próxima vez que se reinicie systemd.Sin embargo, el comando para iniciar el servicio de booth depende de la configuraciónde booth:

Si utiliza la instalación por defecto descrita en la Sección 6.1, “Configuración por defecto

de booth”, solo se congura /etc/booth/booth.conf . En tal caso, entre en cadaárbitro y utilice el comando siguiente:

root # systemctl start booth@booth

Si se ejecuta booth en el modo de varios inquilinos descrito en la Sección 6.2, “Confi-

guración de booth para varios inquilinos”, habrá configurado varios archivos de confi-guración de booth en /etc/booth . Para iniciar los servicios de las instancias indivi-


duales de booth, utilice systemctl start booth@ NOMBRE , donde NOMBRE repre-senta el nombre del archivo de configuración /etc/booth/NOMBRE.conf correspon-diente.Por ejemplo, si dispone de los archivos de configuración de booth /etc/booth/emea.conf y /etc/booth/apac.conf , entre en su árbitro y ejecute los comandossiguientes:

root # systemctl start booth@emearoot # systemctl start booth@apac

De esta forma, se inicia el servicio de booth en modo de árbitro. Se puede comunicar contodos los demás daemons de booth, pero a diferencia de los daemons de booth que seejecutan en los sitios de clúster, no se le puede otorgar un ticket. Los árbitros de boothsolo actúan en las elecciones. En otras situaciones, están en desuso.

6.5 Reconfiguración de booth durante la ejecución

En caso de que necesite cambiar la configuración de booth mientras los servicios de booth estánen ejecución, haga lo siguiente:

1. Ajuste los archivos de configuración de booth como desee.

2. Sincronice los archivos de configuración de booth actualizados con todos los nodos declúster y los árbitros que formen parte de su clúster geográco. Para obtener información,consulte la Sección 8, “Sincronización de archivos de configuración en todos los sitios y árbitros”.

3. Reinicie los servicios de booth en los árbitros y los sitios de clúster, como se describe enla Sección 6.4, “Habilitación e inicio de los servicios de booth”. Esto no afecta de ninguna formaa los tickets que ya se han otorgado a los sitios.

7 Configuración de DRBDPara obtener una descripción del escenario general, consulte la Sección 5, “Escenario de ejemplo

y pasos básicos: descripción general”. Supongamos que tiene dos sitios de clúster que se conectancon una conexión IPv4 o IPv6 enrutada y una velocidad de transmisión de entre unos pocos Mb/s y 10 Gb/s, por lo que utilizar un sistema de archivos de clúster entre los sitios no será posibledebido a la alta latencia. Pero se puede utilizar DRBD para replicar los datos a n de conseguir


un failover rápido en caso de que uno de los sitios quede fuera de servicio (configuración activo/pasivo). DRBD es un software para replicar datos de almacenamiento mediante la duplicacióndel contenido de los dispositivos de bloque (discos duros, particiones, volúmenes lógicos etc.)entre hosts ubicados en sitios diferentes. El failover se gestiona mediante los servicios de booth;consulte Gestor de tickets de clúster de booth.

7.1 Escenario de DRBD y pasos básicos

En la Figura 3, “Configuración de DRBD y apilamiento de recursos” se muestra una representacióngráca de la configuración y los recursos que se configurarán en las secciones siguientes.

FIGURA 3: CONFIGURACIÓN DE DRBD Y APILAMIENTO DE RECURSOS

DETALLES DEL ESCENARIO

Debe proporcionarse un sistema de archivos para todo el clúster geográco mediante NFS.


LVM se utiliza como capa de almacenamiento por debajo de DRBD.

Un recurso DRBD “apilado:”

La instancia de DRBD de la capa superior se ejecuta en un nodo por sitio y es respon-sable de replicar los datos al otro sitio del clúster geográco.

La instancia de DRBD de la capa inferior es responsable de la réplica local de los datos(entre los nodos de un sitio de clúster). Después de activar uno de los dispositivosDRBD de la capa inferior en un nodo por sitio, se iniciará la IP de servicio (que debeconfigurarse como recurso de clúster).

En el sitio amsterdam, DRBD se ejecuta con el protocolo C , un protocolo de réplicasincrónico. Utiliza las direcciones IP locales en una LAN.

La IP de servicio no solo se utiliza para el servicio en sí, sino que también sirve como puntojo al que puede acceder el dispositivo DRBD de la capa superior (que se ejecuta en estadosecundario) para la réplica.

En el sitio donde se debe ejecutar el servicio del sistema de archivos, la instancia deDRBD de la capa superior se establece en modo primario mediante el agente de recursoocf:linbit:drbd . Esto signica que las aplicaciones podrán montar y usar el sistema dearchivos incluido.

Opcionalmente, la conexión DRBD con el otro sitio del clúster geográco puede utilizarun proxy de DRBD intermedio.

En este escenario de configuración, debe llevar a cabo los siguientes pasos básicos:

1. Edite los archivos de configuración de DRBD para que incluyan los fragmentos de confi-guración para cada sitio del clúster geográco y la conexión DRBD entre los sitios. Paraobtener información, consulte los ejemplos de la Sección 7.2, “Configuración de DRBD”.

2. Congure los recursos del clúster como se explica en la Sección 9.1, “Recursos y restricciones

de DRBD”.

3. Congure booth como se describe en la Sección 6, “Configuración de los servicios de booth”.

4. Congure la sincronización entre DRBD y los archivos de configuración de booth dentrode cada clúster local y en todos los sitios del clúster geográco. Para obtener informacióndetallada, consulte la Sección 8, “Sincronización de archivos de configuración en todos los sitios

y árbitros”.


7.2 Configuración de DRBD

A partir de DRBD 8.3, el archivo de configuración de DRBD se divide en varios archivos indepen-dientes. Deben estar ubicados en el directorio /etc/drbd.d/ . Los fragmentos de configuraciónde DRBD siguientes muestran una configuración de DRBD básica en el escenario mencionadoen Detalles del escenario. Todos los fragmentos pueden añadirse a un único archivo de configu-ración de recursos de DRBD, por ejemplo, /etc/drbd.d/nfs.res . A continuación, es posiblesincronizar este archivo mediante Csync2, como se describe en la Sección 8.1, “Configuración

de Csync2 para clústeres geográficos”. Tenga en cuenta que los fragmentos de configuración deDRBD siguientes son básicos: no incluyen ninguna opción de ajuste de rendimiento ni elementossimilares. Para obtener información sobre cómo ajustar DRBD, consulte el capítulo DRBD enla Guía de administración de SUSE Linux Enterprise High Availability Extension, disponible enhttp://www.suse.com/documentation/ .

EJEMPLO 5: FRAGMENTO DE CONFIGURACIÓN DE DRBD PARA EL SITIO 1 (AMSTERDAM)

resource nfs-lower-amsterdam 1 { disk /dev/volgroup/lv-nfs; 2

meta-disk internal; 3

device /dev/drbd0; 4

protocol C; 5

net { shared-secret "2a9702a6-8747-11e3-9ebb-782bcbd0c11c"; 6

}

on alice { 7

address 192.168.201.111:7900; 8

node-id 0; 9

} on bob { 7

address 192.168.201.112:7900; 8

node-id 1; 9

} connection-mesh { 10

hosts alice bob; }}

1 Un nombre de recurso que permite algunas asociaciones con el servicio respectivo (en estecaso: NFS). Si también se incluye el nombre del sitio, es posible sincronizar la configuracióncompleta de DRBD con todos los sitios sin provocar conictos de nombre.

2 El dispositivo que se replica entre los nodos. En este ejemplo, LVM se utiliza como capa dealmacenamiento por debajo de DRBD y el nombre de grupo del volumen es volgroup .



3 El parámetro meta-disk suele incluir el valor internal , pero es posible especificar explí-citamente un dispositivo para guardar los metadatos. Consulte http://www.drbd.org/users-

guide-emb/ch-internals.html#s-metadata para obtener más información.

4 El nombre de dispositivo para DRBD y su número secundario. Para diferenciar entre lainstancia de DRBD de la capa inferior para la réplica local y la de la capa superior parala réplica entre los sitios del clúster geográco, se utilizan los números secundarios dedispositivo 0 y 10 .

5 DRBD se ejecuta con el protocolo C , un protocolo de réplica sincrónico. Se considera quelas operaciones de escritura locales en el nodo principal se han completado solo después deque tanto la escritura en el disco local como en el disco remoto se haya conrmado. Comoresultado, se garantiza que la pérdida de un solo nodo no suponga pérdida de datos. Porsupuesto, la pérdida de datos es inevitable incluso con este protocolo de réplica si ambosnodos (o sus subsistemas de almacenamiento) se destruyen irreversiblemente al mismotiempo.

6 Se usa un secreto compartido para validar los pares de conexión. Se necesita un secretocompartido distinto para cada par de conexión. Puede obtener valores únicos con elprograma uuidgen .

7 La sección on indica a qué host se aplica esta declaración de la configuración.

8 La dirección IP local y el número de puerto del nodo respectivo. Cada recurso DRBD necesitaun puerto individual.

9 El ID de nodo es necesario si se configuran más de dos nodos. Debe ser un número enterono negativo exclusivo para diferenciar los distintos nodos.

10 Dene todos los nodos de una red en malla. El parámetro hosts contiene todos los nombresde host que comparten la misma configuración de DRBD.

EJEMPLO 6: FRAGMENTO DE CONFIGURACIÓN DE DRBD PARA EL SITIO 2 (BERLIN)

La configuración para el sitio 2 (berlin) es casi idéntica que la del sitio 1: puedeconservar los valores de la mayoría de los parámetros, incluidos los nombres del grupo devolumen y el volumen lógico. Sin embargo, deben modificarse los valores de los siguientesparámetros:

El nombre del recurso de DRBD ( 1 )

El nombre y las direcciones IP locales de los nodos ( 7 y 8 )

El secreto compartido ( 6 )


http://www.drbd.org/users-guide-emb/ch-internals.html#s-metadata


resource nfs-lower-berlin 1 { disk /dev/volgroup/lv-nfs; 2

meta-disk internal; 3

device /dev/drbd0; 4

protocol C; 5

net { shared-secret "2e9290a0-8747-11e3-a28c-782bcbd0c11c"; 6

}

on charly { 7

address 192.168.202.111:7900; 8

node-id 0; } on doro { 7

address 192.168.202.112:7900; 8

node-id 1; } connection-mesh { hosts charly doro; }}

1 Un nombre de recurso que permite algunas asociaciones con el servicio respectivo(en este caso: NFS). Si también se incluye el nombre del sitio, es posible sincronizarla configuración completa de DRBD con todos los sitios sin provocar conictos denombre.

2 El dispositivo que se replica entre los nodos. En este ejemplo, LVM se utiliza comocapa de almacenamiento por debajo de DRBD y el nombre de grupo del volumen esvolgroup .

3 El parámetro meta-disk suele incluir el valor internal , pero es posible especi-ficar explícitamente un dispositivo para guardar los metadatos. Consulte http://

www.drbd.org/users-guide-emb/ch-internals.html#s-metadata para obtener másinformación.

4 El nombre de dispositivo para DRBD y su número secundario. Para diferenciar entre lainstancia de DRBD de la capa inferior para la réplica local y la de la capa superior parala réplica entre los sitios del clúster geográco, se utilizan los números secundariosde dispositivo 0 y 10 .

5 DRBD se ejecuta con el protocolo C , un protocolo de réplica sincrónico. Se consideraque las operaciones de escritura locales en el nodo principal se han completadosolo después de que tanto la escritura en el disco local como en el disco remoto se




haya conrmado. Como resultado, se garantiza que la pérdida de un solo nodo nosuponga pérdida de datos. Por supuesto, la pérdida de datos es inevitable incluso coneste protocolo de réplica si ambos nodos (o sus subsistemas de almacenamiento) sedestruyen irreversiblemente al mismo tiempo.

6 Se usa un secreto compartido para validar los pares de conexión. Se necesita unsecreto compartido distinto para cada par de conexión. Puede obtener valores únicoscon el programa uuidgen .

7 La sección on indica a qué host se aplica esta declaración de la configuración.

8 La dirección IP local y el número de puerto del nodo respectivo. Cada recurso DRBDnecesita un puerto individual.

EJEMPLO 7: FRAGMENTO DE CONFIGURACIÓN DE DRBD PARA CONEXIÓN ENTRE SITIOS

resource nfs-upper 1 { disk /dev/drbd0; 2

meta-disk internal; device /dev/drbd10; 3

protocol A; 4

net { shared-secret "3105dd88-8747-11e3-a7fd-782bcbd0c11c"; 5

ping-timeout 20; 6

}

stacked-on-top-of nfs-lower-amsterdam { 7

address 192.168.201.151:7910; 8

} stacked-on-top-of nfs-lower-berlin { 7

address 192.168.202.151:7910; 8

}}

1 Un nombre de recurso que permite algunas asociaciones con el servicio respectivo (en estecaso: NFS). Esta es la configuración de la instancia de DRBD de la capa superior, responsablede replicar los datos con el otro sitio del clúster geográco.

2 El disco de almacenamiento que se debe replicar es el dispositivo DRBD, /dev/drbd0 .Puede utilizar /dev/drbd/by-res/nfs-sitio-inferior-N/0 en su lugar, pero esa confi-guración sería especíca para el sitio y, por lo tanto, habría que trasladarla a la confi-guración de cada sitio; es decir, por debajo de la palabra clave stacked-on-top-ofrespectiva.


3 El nombre de dispositivo para DRBD y su número secundario. Para diferenciar entre lainstancia de DRBD de la capa inferior para la réplica local y la de la capa superior parala réplica entre los sitios del clúster geográco, se utilizan los números secundarios dedispositivo 0 y 10 .

4 DRBD se ejecuta con el protocolo A , un protocolo de réplica asíncrona empleado para lasréplicas a larga distancia. Se considera que las operaciones de escritura local en el nodoprincipal se han completado cuando naliza la escritura en el disco local y el paquete deréplica se ha colocado en el búfer de envío TCP local. Si se produce un failover forzado,podría producirse una pérdida de datos. Los datos del nodo de reserva son coherentesdespués del failover. Sin embargo, las actualizaciones más recientes realizadas antes delfallo podrían perderse.

6 Debido a la mayor latencia, establezca el tiempo límite de ping en 20 .

6 Se usa un secreto compartido para validar los pares de conexión. Se necesita un secretocompartido distinto para cada par de conexión. Puede obtener valores únicos con elprograma uuidgen .

7 En lugar de pasar los nombres de host, se indica a DRBD que apile sobre el dispositivoinferior. Esto implica que el dispositivo inferior debe ser el primario .

8 Para permitir la conexión TCP/IP con el otro sitio de clúster geográco si no sabe qué nododel clúster cuenta con el dispositivo DRBD inferior primario , utilice la dirección IP deservicio configurada para NFS. Consulte el Procedimiento 5, “Configuración de recursos para

una configuración de DRBD” para comprobar cómo se congura una IP de servicio.

8 Sincronización de archivos de configuración entodos los sitios y árbitrosPara replicar los archivos de configuración importantes en todos los nodos del clúster y entrelos clústeres geográficos, utilice Csync2. Csync2 puede gestionar cualquier número de hosts,ordenados en grupos de sincronización. Cada grupo de sincronización tiene su propia lista dehosts miembros y sus patrones de inclusión y exclusión que denen qué archivos se deben sincro-nizar en el grupo de sincronización. Los grupos, los nombres de host que pertenecen a cadagrupo y las reglas de inclusión y exclusión de cada grupo se especifican en el archivo de confi-guración de Csync2, /etc/csync2/csync2.cfg .


Para la autenticación, Csync2 utiliza las direcciones IP y las claves precompartidas en cadagrupo de sincronización. Debe generar un archivo de clave para cada grupo de sincronizacióny copiarlo en todos los miembros del grupo.

Csync2 se pondrá en contacto con otros servidores a través de un puerto TCP (por defecto 6556 )e iniciará instancias remotas de Csync2. Para obtener información detallada sobre Csync2,consulte http://oss.linbit.com/csync2/paper.pdf

8.1 Configuración de Csync2 para clústeres geográficos

En la Guía de administración de SUSE Linux Enterprise High Availability Extension, capítuloInstalación y configuración básicas, sección Transferencia de la configuración a todos los nodos, seexplica cómo configurar Csync2 para clústeres individuales con YaST. Sin embargo, YaST nopuede gestionar configuraciones de Csync2 más complejas, como las necesarias para los clústeresgeográficos. Para la siguiente instalación, congure manualmente Csync2 editando los archivosde configuración, como se muestra en la Figura 4, “Configuración de Csync2 de ejemplo para clústeres

geográficos”.

Para ajustar Csync2 a n de sincronizar archivos que no solo se encuentren en clústeres locales,sino también en sitios dispersos geográficamente, debe denir dos grupos de sincronización enla configuración de Csync2:

Un grupo global ha_global (para los archivos que deban sincronizarse globalmente, entodos los sitios y con árbitros que pertenezcan a un clúster geográco).

Un grupo para el sitio de clúster local ha_local (para los archivos que deban sincronizarseen el clúster local).

Para obtener una descripción general de los archivos de configuración de Csync2 para los dosgrupos de sincronización, consulte la Figura 4, “Configuración de Csync2 de ejemplo para clústeres

geográficos”.


http://oss.linbit.com/csync2/paper.pdf

csync2.cfg

group ha_local{ key /etc/csync2/ha_local.key; host this-site-host-1; host this-site-host-2;

config /etc/csync2/ha_local.cfg;

}config /etc/csync2/ha_global.cfg;

group ha_global{ key /etc/csync2/ha_global.key; host site-1-host-1; host site-1-host-2; host site-2-host-1; host site-2-host-2; árbitro de host;

include /etc/csync2/ha_global.cfg;

include /etc/csync2/ha_global.key;

include /etc/booth/;

include /etc/drbd.conf; include /etc/drbd.d;

include /etc/zypp./repos.d;

include /root/.bash-logout; include /root/.vimrc; include /root/.vim; exclude /root/.vim/netrwhist; include /etc/bash.bashrc.local;}

ha_global.cfg

ha_local.cfg

include /etc/csync2/csync2.cfg;

include /etc/csync2/ha_local.key;

include /etc/corosync/corosync.conf;include /etc/corosync/authkey;include /etc/ha.d;include /etc/ctdb/nodes;include /etc/ha.d/ldirectord.cf;include /etc/sysconfig/pacemaker;include /etc/sysconfig/sbd;

FIGURA 4: CONFIGURACIÓN DE CSYNC2 DE EJEMPLO PARA CLÚSTERES GEOGRÁFICOS

Los archivos de clave de autenticación y sus referencias se muestran en rojo. Los nombres de losarchivos de configuración de Csync2 aparecen en azul y sus referencias, en verde. Para obtenerinformación detallada, consulte Configuración de Csync2 de ejemplo: archivos de configuración.

CONFIGURACIÓN DE CSYNC2 DE EJEMPLO: ARCHIVOS DE CONFIGURACIÓN

/etc/csync2/csync2.cfg


Es el principal archivo de configuración de Csync2. Es corto y sencillo a propósito y soloincluye lo siguiente:

La denición del grupo de sincronización ha_local . El grupo consta de dosnodos ( this-site-host-1 y this-site-host-2 ) y emplea /etc/csync2/ha_lo-cal.key para la autenticación. En otro archivo de configuración de Csync2, /etc/csync2/ha_local.cfg , se dene una lista de archivos que deben sincronizarse paraeste grupo. Se incluye con la declaración config .

Una referencia a otro archivo de configuración de Csync2, /etc/csync2.cfg/ha_global.cfg , incluida con la declaración config .

/etc/csync2/ha_local.cfg

Este archivo afecta solo al clúster local. Especica una lista de archivos que deben sincroni-zarse solo dentro del grupo de sincronización ha_local , ya que estos archivos son especí-ficos de cada clúster. Los más importantes son los siguientes:

El archivo /etc/csync2/csync2.cfg contiene la lista de los nodos del clúster local.

La clave de autenticación /etc/csync2/ha_local.key , que se debe usar para lasincronización de Csync2 en el clúster local.

El archivo /etc/corosync/corosync.conf dene los canales de comunicaciónentre los nodos del clúster local.

/etc/corosync/authkey es la clave de autenticación de Corosync.

El resto de la lista de archivos depende de la configuración especíca del clúster. Losarchivos mostrados en la Figura 4, “Configuración de Csync2 de ejemplo para clústeres geográ-

ficos” son meros ejemplos. Si también desea sincronizar archivos de aplicaciones específicasdel sitio, puede incluirlos en ha_local.cfg . Aunque ha_local.cfg está dirigido a losnodos que pertenecen a un sitio del clúster geográco, el contenido puede ser idéntico entodos los sitios. Si se necesitan conjuntos diferentes de hosts o claves distintas, puede sernecesario añadir grupos adicionales.

/etc/csync2.cfg/ha_global.cfg

Este archivo dene el grupo de sincronización ha_global de Csync2. El grupo abarca todoslos nodos de clúster en varios sitios, incluido el árbitro. Dado que se recomienda utilizaruna clave independiente para cada grupo de sincronización de Csync2, este grupo utiliza


/etc/csync2/ha_global.key para la autenticación. Las declaraciones include denenla lista de archivos que se van a sincronizar en el grupo de sincronización ha_global . Losmás importantes son los siguientes:

/etc/csync2/ha_global.cfg y /etc/csync2/ha_global.key (el archivo deconfiguración para el grupo de sincronización ha_global y la clave de autenticaciónusada para la sincronización dentro del grupo).

/etc/booth/ , el directorio por defecto que contiene la configuración de booth. Encaso de que utilice una configuración de booth para varios inquilinos, este directoriocontiene más de un archivo de configuración de booth. Si utiliza la autenticaciónpara booth, resulta útil colocar también el archivo de clave en este directorio.

/etc/drbd.conf y /etc/drbd.d (si utiliza DRBD en la configuración del clúster).La configuración de DRBD se puede sincronizar globalmente, ya que se obtiene apartir de los nombres de host incluidos en el archivo de configuración del recurso.

/etc/zypp/repos.de . Es probable que los repositorios de paquetes sean los mismosen todos los nodos del clúster.

Los demás archivos mostrados /etc/root/* ) son ejemplos que se pueden incluir porcomodidad (para facilitar el trabajo de los administradores del clúster).

NotaLos archivos csync2.cfg y ha_local.key son específicos de cada sitio, lo que signicaque se deben crear archivos distintos para cada sitio de clúster. Los archivos son idénticosen los nodos que pertenecen al mismo clúster, pero distintos a los de otros clústeres. Cadaarchivo csync2.cfg debe contener una lista de hosts (nodos de clúster) que pertenecenal sitio, además de una clave de autenticación especíca del sitio.

El árbitro necesita también un archivo csync2.cfg ; aunque solo es necesario que hagareferencia a ha_global.cfg .


8.2 Sincronización de cambios con Csync2

Para sincronizar correctamente los archivos con Csync2, deben cumplirse los siguientes requi-sitos previos:

La misma configuración de Csync2 debe estar disponible en todos los equipos que perte-nezcan al mismo grupo de sincronización.

La clave de autenticación de Csync2 de cada grupo de sincronización debe estar disponibleen todos los miembros de ese grupo.

Csync2 debe ejecutarse en todos los nodos y en el árbitro.

Por lo tanto, antes de la primera ejecución de Csync2, debe llevar a cabo los preparativossiguientes:

1. Entre en un equipo en cada grupo de sincronización y genere una clave de autenticaciónpara el grupo correspondiente:

root # csync2 -k NAME_OF_KEYFILE

Pero no vuelva a generar el archivo de clave en ningún otro miembro del mismo grupo.Respecto a la Figura 4, “Configuración de Csync2 de ejemplo para clústeres geográficos”, se produ-cirán los archivos de clave siguientes: /etc/csync2/ha_global.key y una clave local ( /etc/csync2/ha_local.key ) por cada sitio.

2. Copie cada archivo de clave en todos los miembros del grupo de sincronización correspon-diente. Respecto a la Figura 4, “Configuración de Csync2 de ejemplo para clústeres geográficos”:

a. Copie /etc/csync2/ha_global.key en todas las partes (el árbitro y todos los nodosdel clúster en todos los sitios del clúster geográco). El archivo de claves debe estardisponible en todos los hosts del grupo ha_global denidos en ha_global.cfg .

b. Copie el archivo de clave local para cada sitio ( /etc/csync2/ha_local.key ) entodos los nodos del clúster que pertenezcan al sitio correspondiente del clústergeográco.

3. Copie el archivo de configuración especíco del sitio /etc/csync2/csync2.cfg en todoslos nodos del clúster que pertenezcan al sitio correspondiente del clúster geográco y elárbitro.


4. Ejecute el comando siguiente en todos los nodos y el árbitro para provocar que el serviciocsync2 se inicie automáticamente durante el arranque:

root # systemctl enable csync2.socket

5. Ejecute el comando siguiente en todos los nodos y el árbitro para iniciar el servicio ahora:

root # systemctl start csync2.socket

PROCEDIMIENTO 4: SINCRONIZACIÓN DE ARCHIVOS CON CSYNC2

1. Para sincronizar inicialmente todos los archivos una vez, ejecute el comando siguiente enel equipo desde el que desea copiar la configuración:

root # csync2 -xv

Esto sincronizará todos los archivos una vez enviándolos a los otros miembros de losgrupos de sincronización. Si todos los archivos se sincronizan correctamente, Csync2 secompleta sin errores.Si uno o varios de los archivos que se van a sincronizar se han modicado en otros equipos(no solo en el actual), Csync2 informa sobre un conicto. Obtendrá un resultado similaral siguiente:

While syncing file /etc/corosync/corosync.conf:ERROR from peer site-2-host-1: File is also marked dirty here!Finished with 1 errors.

2. Si tiene la seguridad de que la versión del archivo en el equipo actual es la “mejor”, puederesolver el conicto forzando el uso de este archivo y volviendo a sincronizar:

root # csync2 -f /etc/corosync/corosync.confroot # csync2 -x

Para obtener información sobre las opciones de Csync2, ejecute csync2 -help .

Nota: aplicación de sincronización después de realizarcualquier cambioCsync2 solo aplica los cambios. No sincroniza de forma continua los archivos entre losequipos.


Cada vez que actualice archivos que deban sincronizarse, deberá enviar los cambios aotros equipos del mismo grupo de sincronización: ejecute csync2 -xv en el equipodonde realizó los cambios. Si ejecuta el comando en cualquier otro equipo con archivossin cambiar, no ocurrirá nada.

9 Configuración de los recursos y las restricciones delclústerAparte de los recursos y las restricciones que debe denir para la configuración especíca delclúster, los clústeres geográficos requieren recursos y restricciones adicionales que se describen acontinuación. Puede configurarlos con la shell de crm (crmsh), como se muestra en los ejemplossiguientes, o con la consola Web de alta disponibilidad HA Web Konsole (Hawk2).

Esta sección se centra en las tareas específicas de los clústeres geográficos. Para obtener infor-mación básica sobre la herramienta de gestión de clústeres preferida así como instruccionesgenerales sobre cómo configurar sus recursos y restricciones, consulte uno de los capítulossiguientes de la Guía de administración de SUSE Linux Enterprise High Availability Extension,disponible en http://www.suse.com/documentation/ :

Hawk2: capítulo Configuración y gestión de recursos del clúster (interfaz Web)

crmsh: capítulo Configuración y gestión de recursos del clúster (línea de comandos)

Importante: sin sincronización del CIB en los sitiosEl CIB no se sincroniza automáticamente entre los sitios de clúster de un clústergeográco. Esto signica que debe configurar en consecuencia todos los recursos quedeben contar con alta disponibilidad en el clúster geográco para cada sitio.

Para simplificar la transferencia de la configuración a otros sitios de clúster, es posibleconfigurar cualquier recurso con parámetros específicos del sitio de forma que los valoresde los parámetros dependan del nombre del sitio de clúster donde se ejecuta el recurso.

Para que ese sistema funcione, los nombres de clúster para cada sitio deben estardenidos en los archivos /etc/corosync/corosync.conf respectivos. Por ejemplo,/etc/corosync/corosync.conf del sitio 1 ( amsterdam ) debe contener la siguienteentrada:

totem {



[...] cluster_name: amsterdam }

Después de configurar los recursos en un sitio, puede etiquetar los recursos necesarios entodos los sitios de clúster, exportarlos desde el CIB actual y, después, importarlos en el CIBde otro sitio de clúster. Para obtener información, consulte la Sección 9.3, “Transferencia de

la configuración del recurso a otros sitios de clúster”.

9.1 Recursos y restricciones de DRBD

Para completar la configuración de DRBD, debe configurar algunos recursos y restricciones,como se muestra en el Procedimiento 5 y transferirlos a los demás sitios de clúster, como se explicaen la Sección 9.3, “Transferencia de la configuración del recurso a otros sitios de clúster”.

PROCEDIMIENTO 5: CONFIGURACIÓN DE RECURSOS PARA UNA CONFIGURACIÓN DE DRBD

1. En uno de los nodos del clúster amsterdam , inicie una shell y entre como usuario rooto equivalente.

2. Escriba crm configure para cambiar a la shell interactiva de crm.

3. Congure la dirección IP de servicio (dependiente del sitio) para NFS como recursoprimitive básico:

crm(live)configure# primitive ip_nfs ocf:heartbeat:IPaddr2 \ params iflabel="nfs" nic="eth1" cidr_netmask="24" params rule #cluster-name eq amsterdam ip="192.168.201.151" \ params rule #cluster-name eq berlin ip="192.168.202.151" \ op monitor interval=10

4. Congure un recurso de sistema de archivos y un recurso para el servidor NFS:

crm(live)configure# primitive nfs_fs ocf:heartbeat:Filesystem \ params device="/dev/drbd/by-res/nfs/0" directory="/mnt/nfs" \ fstype="ext4"crm(live)configure# primitive nfs_service systemd:nfs-server

5. Congure los recursos primitive siguientes y los recursos de varios estados para DRBD:

crm(live)configure# primitive drbd_nfs ocf:linbit:drbd \


params drbd_resource="nfs-upper" \ op monitor interval="31" role="Slave" \ op monitor interval="30" role="Master"crm(live)configure# primitive drbd_nfs_lower ocf:linbit:drbd \ params rule #cluster-name eq amsterdam \ drbd_resource="nfs-lower-amsterdam" \ params rule #cluster-name eq berlin \ drbd_resource="nfs-lower-berlin" \ op monitor interval="31" role="Slave" \ op monitor interval="30" role="Master"crm(live)configure# ms ms_drbd_nfs drbd_nfs \ meta master-max="1" master-node-max="1" \ clone-max="1" clone-node-max="1" notify="true"crm(live)configure# ms ms_drbd_nfs_lower drbd_nfs_lower \ meta master-max="1" master-node-max="1" \ clone-max="2" clone-node-max="1" notify="true"

6. Añada un grupo con la colocación y las restricciones de orden siguientes:

crm(live)configure# group g_nfs nfs_fs nfs_servicecrm(live)configure# colocation col_nfs_ip_with_lower \ inf: ip_nfs:Started ms_drbd_nfs_lower:Mastercrm(live)configure# colocation col_nfs_g_with_upper \ inf: g_nfs:Started ms_drbd_nfs:Mastercrm(live)configure# colocation col_nfs_upper_with_ip \ inf: ms_drbd_nfs:Master ip_nfs:Startedcrm(live)configure# order o_lower_drbd_before_ip_nfs \ inf: ms_drbd_nfs_lower:promote ip_nfs:startcrm(live)configure# order o_ip_nfs_before_drbd \ inf: ip_nfs:start ms_drbd_nfs:promotecrm(live)configure# order o_drbd_nfs_before_svc \ inf: ms_drbd_nfs:promote g_nfs:start

7. Revise los cambios con el comando show .

8. Si todo está correcto, envíe los cambios con el comando commit y salga de la configuraciónen tiempo real de crm con el comando exit .La configuración se guarda en el CIB.


9.2 Dependencias, restricciones y recursos del ticket para booth

Para completar la configuración de booth, debe llevar a cabo los pasos siguientes para configurarlos recursos y las restricciones necesarias para booth y para el failover de los recursos:

Configuración de dependencias de recursos del ticket

Configuración de un grupo de recursos para boothd

Adición de una restricción de orden

Las configuraciones del recurso deben estar disponibles en todos los sitios de clúster. Transfié-ralas a los demás sitios como se describe en la Sección 9.3, “Transferencia de la configuración del

recurso a otros sitios de clúster”.

PROCEDIMIENTO 6: CONFIGURACIÓN DE DEPENDENCIAS DE RECURSOS DEL TICKET

Para los clústeres geográficos, puede especificar los recursos que dependen de un ticketdeterminado. Además de este tipo especial de restricción, puede denir un atributo loss-policy que dena lo que debe ocurrir con los recursos respectivos si el ticket se revoca.El atributo loss-policy puede tener los valores siguientes:

fence : aísla los nodos en los que se ejecutan los recursos relevantes.

stop : detiene los recursos relevantes.

freeze : no hace nada con los recursos relevantes.

demote : baja de nivel los recursos relevantes que se ejecutan en el modo principala modo esclavo .

1. En uno de los nodos del clúster amsterdam, inicie una shell y entre como usuario rooto equivalente.


3. Congure las restricciones que denen qué recursos dependerán de un ticket determinado.Por ejemplo, se necesita la siguiente restricción para el escenario de DRBD descrito en laSección 7.1, “Escenario de DRBD y pasos básicos”:

crm(live)configure# rsc_ticket nfs-req-ticket-nfs ticket-nfs: \ ms_drbd_nfs:Master loss-policy=demote


Este comando crea una restricción con el ID nfs-req-ticket-nfs . Dene que el recursode varios estados ms_drbd_nfs depende de ticket-nfs . Sin embargo, solo el modoprincipal del recurso depende del ticket. En caso de que ticket-nfs se revoque,ms_drbd_nfs baja de nivel automáticamente a modo esclavo , lo que a su vez devolveráa DRBD al modo secundario . De este modo, se garantiza que la réplica de DRBD siga enejecución aunque un sitio no tenga el ticket.

4. Si desea que otros recursos dependan de otros tickets, cree tantas restricciones como seannecesarias con rsc_ticket .



EJEMPLO 8: DEPENDENCIA DEL TICKET PARA RECURSOS PRIMITIVE

Este es otro ejemplo de restricción que hace que un recurso primitive rsc1 dependa deticketA :

crm(live)configure# rsc_ticket rsc1-req-ticketA ticketA: \ rsc1 loss-policy="fence"

En caso de que ticketA se revoque, el nodo en el que se ejecuta el recurso deberá aislarse.

PROCEDIMIENTO 7: CONFIGURACIÓN DE UN GRUPO DE RECURSOS PARA boothd

Se debe ejecutar una instancia de boothd en cada sitio que se comunique con los demásdaemons de booth. El daemon puede iniciarse en cualquier nodo, por lo tanto, debe confi-gurarse como recurso primitive. Para que el recurso de boothd permanezca en el mismonodo, si es posible, añada persistencia del recurso a la configuración. Como cada daemonnecesita una dirección IP permanente, congure otro recurso primitive con una direcciónIP virtual. Agrupe ambos recursos primitive:

1. En uno de los nodos del clúster amsterdam , inicie una shell y entre como usuario rooto equivalente.


3. Escriba lo siguiente para crear ambos recursos primitive y para añadirlos a un grupo, g-booth :

crm(live)configure# primitive ip-booth ocf:heartbeat:IPaddr2 \


params iflabel="ha" nic="eth1" cidr_netmask="24" params rule #cluster-name eq amsterdam ip="192.168.201.151" \ params rule #cluster-name eq berlin ip="192.168.202.151" crm(live)configure# primitive booth ocf:pacemaker:booth-site \ meta resource-stickiness="INFINITY" \ params config="nfs" op monitor interval="10s"crm(live)configure# group g-booth ip-booth booth

Con esta configuración, cada daemon de booth estará disponible en su dirección IPindividual, independientemente del nodo en el que se ejecute el daemon.



PROCEDIMIENTO 8: ADICIÓN DE UNA RESTRICCIÓN DE ORDEN

Si se ha otorgado un ticket a un sitio pero todos los nodos de dicho sitio no pueden alojarel grupo de recursos de boothd por cualquier motivo, se puede producir una situaciónde “clúster con nodos malinformados” entre lugares geográficamente dispersos. En talcaso, no habrá disponible ninguna instancia de boothd para gestionar de forma segurael failover del ticket a otro sitio. Para evitar una posible infracción por simultaneidad delticket (el ticket se otorga a varios sitios al mismo tiempo), añada una restricción de orden:

1. En uno de los nodos del clúster amsterdam, inicie una shell y entre como usuario rooto equivalente.


3. Cree una restricción de orden:

crm(live)configure# order o-booth-before-nfs inf: g-booth ms_drbd_nfs:promote

La restricción de orden o-booth-before-nfs dene que el recurso ms_drbd_nfs solopuede subirse de nivel a modo principal después de que se haya iniciado el grupo derecursos g-booth .

4. Para cualquier otro recurso que dependa de un determinado ticket, dena otras restric-ciones de orden.




EJEMPLO 9: RESTRICCIÓN DE ORDEN PARA RECURSOS PRIMITIVE

Si el recurso que depende de un ticket determinado no es un recurso de varios estadossino un recurso primitive, la restricción de orden tendrá un aspecto similar al siguiente:

crm(live)configure# order o-booth-before-rsc1 inf: g-booth rsc1

Dene que rsc1 (que depende de ticketA ) solo se puede iniciar después del grupo derecursos g-booth .

9.3 Transferencia de la configuración del recurso a otros sitios declúster

Si ha configurado recursos para un sitio de un clúster como se describe en la Sección 9.1 y enla Sección 9.2, aún no ha terminado. Debe transferir la configuración del recurso a los demássitios del clúster geográco.

Para simplificar la transferencia, puede etiquetar todos los recursos necesarios en todos los sitiosde clúster, exportarlos desde el CIB actual y después importarlos en el CIB de otro sitio declúster. En el Procedimiento 9, “Transferencia de la configuración del recurso a otros sitios de clúster”

se proporciona un ejemplo de cómo hacerlo. Se basa en los siguientes requisitos previos:

REQUISITOS PREVIOS

Dispone de un clúster geográco con dos sitios: el clúster amsterdam y el clúster berlin .

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

totem { [...] cluster_name: amsterdam }


Esto se puede realizar manualmente (editando /etc/corosync/corosync.conf ) o conel módulo de clúster de YaST, tal y como se describe en la Guía de administración deSUSE Linux Enterprise High Availability Extension 12 SP2, disponible en http://www.su-

se.com/documentation/ . Consulte el capítulo Instalación y configuración básica, procedi-miento Denición del primer canal de comunicación.

Debe haber configurado los recursos necesarios para DRBD y booth, como se describe enla Sección 9.1, “Recursos y restricciones de DRBD” y en la Sección 9.2, “Dependencias, restricciones

y recursos del ticket para booth”.

PROCEDIMIENTO 9: TRANSFERENCIA DE LA CONFIGURACIÓN DEL RECURSO A OTROS SITIOS DE CLÚSTER

1. Entre en uno de los nodos del clúster amsterdam .

2. Inicie el clúster con:

root # systemctl start pacemaker


4. Etiquete los recursos y las restricciones necesarios en el clúster geográco:

a. Revise la configuración del CIB actual:

crm(live)configure# show

b. Introduzca el comando siguiente para agrupar los recursos relacionados con el clústergeográco con la etiqueta geo_resources :

crm(live)configure# tag geo_resources: \ ip_nfs nfs_fs nfs_service drbd_nfs drbd_nfs_lower ms_drbd_nfs \ ms_drbd_nfs_lower g_nfs 1 \ col_nfs_ip_with_lower col_nfs_g_with_upper col_nfs_upper_with_ip 1 \ o_lower_drbd_before_ip_nfs o_ip_nfs_before_drbd \ o_drbd_nfs_before_svc 1 \ nfs-req-ticket-nfs ip-booth booth g-booth o-booth-before-nfs 2

[...] 3

El etiquetado no crea ninguna relación de colocación ni de orden entre los recursos.

1 Recursos y restricciones de DRBD, consulte la Sección 9.1, “Recursos y restricciones

de DRBD”.




2 Recursos y restricciones de boothd, consulte la Sección 9.2, “Dependencias, restric-

ciones y recursos del ticket para booth”.

3 Cualquier otro recurso de su configuración particular que necesite en todos lossitios del clúster geográco.

c. Revise los cambios con el comando show .

d. Cuando la configuración se adapte a sus preferencias, envíe los cambios con elcomando submit y salga del shell en tiempo real de crm mediante exit .

5. Exporte los recursos y las restricciones etiquetados a un archivo denominado expor-ted.cib :

root # crm configure show tag:geo_resources geo_resources > exported.cib

El comando crm configure show tag: NOMBREETIQUETA muestra todos los recursos quepertenecen a la etiqueta NOMBREETIQUETA .

6. Entre en uno de los nodos del clúster berlin y haga lo siguiente:

a. Inicie el clúster con:

root # systemctl start pacemaker

b. Copie el archivo exported.cib del clúster amsterdam a este nodo.

c. Importe los recursos y las restricciones etiquetados del archivo exported.cib alCIB del clúster berlin :

root # crm configure load update PATH_TO_FILE/exported.cib

Si se utiliza el parámetro update para el comando crm configure load , crmshintenta integrar el contenido del archivo en la configuración del CIB actual (en lugarde sustituir el CIB actual con el contenido del archivo).

d. Consulte la configuración del CIB actualizado con el siguiente comando:

root # crm configure show

Los recursos y las restricciones importados aparecerán en el CIB.


Esta configuración dará como resultado lo siguiente:

Si se otorga ticket-nfs al clúster amsterdam , el nodo donde se aloja el recurso ip_nfsobtendrá la dirección IP 192.168.201.151 .

Si se otorga ticket-nfs al clúster berlin , el nodo donde se aloja el recurso ip_nfsobtendrá la dirección IP 192.168.202.151 .

EJEMPLO 10: REFERENCIA A LOS PARÁMETROS DEPENDIENTES DEL SITIO EN LOS RECURSOS

Según el ejemplo del Procedimiento 5, también puede crear recursos que hagan referenciaa parámetros específicos del sitio de otro recurso; por ejemplo, los parámetros de IP deip_nfs . Proceda de la siguiente manera:

1. En el clúster amsterdam , cree un recurso falso que haga referencia a los parámetrosde IP de ip_nfs y utilícelos como valores para el parámetro state :

crm(live)configure# primitive dummy1 ocf:pacemaker:Dummy \ params rule #cluster-name eq amsterdam \ @ip_nfs-instance_attributes-0-ip:state \ params rule #cluster-name eq berlin \ @ip_nfs-instance_attributes-1-ip:state \ op monitor interval=10

2. Añada una restricción para que el recurso dummy1 dependa también de ticket-nfs :

crm(live)configure# rsc_ticket dummy1-dep-ticket-nfs \ ticket-nfs: dummy1 loss-policy=stop

3. Etiquete el recurso y la restricción:

crm(live)configure# tag geo_resources_2: dummy1 \ dummy1-dep-ticket-nfs

4. Revise los cambios con el comando show , envíe los cambios con submit y salga dela shell en tiempo real de crm con exit .

5. Exporte los recursos con la etiqueta geo_resources_2 del clúster amsterdam eimpórtelos en el CIB del clúster berlin , igual que del Paso 5 al Paso 6.d del Proce-

dimiento 9.


Esta configuración dará como resultado lo siguiente:

Al otorgar ticket-nfs al clúster amsterdam , se creará el archivo siguienteen el nodo donde se aloja el recurso dummy : /var/lib/heartbeat/

cores/192.168.201.151 .

Al otorgar ticket-nfs al clúster berlin , se creará el archivo siguiente en el nododonde se aloja el recurso dummy : /var/lib/heartbeat/cores/192.168.202.151 .

10 Configuración de la reubicación de IP mediante laactualización de DNSEn caso de que un sitio del clúster geográco esté apagado y aparezca un failover de ticket, sueleser necesario ajustar el enrutamiento de red consecuencia (o debe haber configurado un failoverde red para cada ticket). Dependiendo del tipo de servicio que esté asociado a un ticket, existeuna solución alternativa para volver a configurar el enrutamiento: puede utilizar la actualizaciónde DNS dinámica y cambiar en su lugar la dirección IP de un servicio.

En ese caso, se deben cumplir los siguientes requisitos previos:

El servicio al que se debe aplicar el failover debe estar asociado con un nombre de host.

El servidor DNS debe estar configurado para las actualizaciones de DNS dinámicas. Paraobtener información sobre cómo hacerlo con BIND/named, consulte la documentación denamed o consulte http://www.semicomplete.com/articles/dynamic-dns-with-dhcp/ . Paraobtener información sobre cómo configurar un DNS, incluida la actualización dinámicade datos de la zona, consulte el capítulo sobre el Sistema de nombres de dominio dela Guía de administración de SUSE Linux Enterprise. Está disponible en http://www.su-

se.com/documentation/ .

En el siguiente ejemplo se presupone que las actualizaciones de DNS están protegidas poruna clave compartida (clave TSIG) para la zona que se va a actualizar. La clave se puedecrear con dnssec-keygen :

root # dnssec-keygen -a hmac-md5 -b 128 -n USER geo-update

Para obtener más información, consulte la página man de dnssec-keygen o la Guía deadministración de SUSE Linux Enterprise, disponibles en http://www.suse.com/documen-

tation/ . Consulte el capítulo Sistema de nombres de dominio, sección Transacciones seguras.


http://www.semicomplete.com/articles/dynamic-dns-with-dhcp/





En el Ejemplo 11, “Configuración del recurso para la actualización de DNS dinámica” se explica cómoutilizar el agente de recurso ocf:heartbeat:dnsupdate para gestionar el comando nsupdate .El agente de recurso admite tanto IPv4 como IPv6.

EJEMPLO 11: CONFIGURACIÓN DEL RECURSO PARA LA ACTUALIZACIÓN DE DNS DINÁMICA

crm(live)configure# primitive dns-update-ip ocf:heartbeat:dnsupdate params \ hostname="www.domain.com" 1 ip="192.168.3.4" 2 \ keyfile="/etc/whereever/Kgeo-update*.key" 3 \ server="192.168.1.1" 4 serverport="53" 5

1 Nombre de host asociado con el servicio en el que debe aplicarse el failover juntocon el ticket. La dirección IP de este nombre de host debe actualizarse mediante DNSdinámico.

2 Dirección IP del servidor donde se aloja el servicio que se va a migrar. La dirección IPespecificada aquí también puede controlarse mediante el clúster. Este no gestiona elfailover local, pero se asegura de que se dirija a las partes externas al sitio adecuadotras un failover de ticket.

3 Vía al archivo de clave pública generado con dnssec-keygen .

4 Dirección IP del servidor DNS al que se van a enviar las actualizaciones. Si no seproporciona ningún servidor, se usa por defecto el servidor principal para la zonacorrecta.

5 Puerto que se debe usar para la comunicación con el servidor DNS. Esta opción solose aplica si se especica un servidor DNS.

Con la configuración de recurso anterior, el agente de recurso se encarga de eliminar elsitio erróneo del clúster geográco del registro de DNS y de cambiar la dirección IP paraun servicio mediante la actualización de DNS dinámica.

11 Gestión de los clústeres geográficosAntes de que booth pueda gestionar un ticket determinado en el clúster geográco, debeotorgarlo a un sitio manualmente.


11.1 Con la línea de comandos

Utilice la herramienta de línea de comandos cliente de booth para otorgar, mostrar o revocartickets, como se describe en Descripción general de los comandos del cliente de booth. Loscomandos del cliente de booth se pueden ejecutar en cualquier equipo del clúster, no solo enlos que se ejecuta boothd . Los comandos del cliente de booth intentan encontrar el clúster“local” en el archivo de configuración de booth y en las direcciones IP denidas localmente.Si no especica un sitio con el que deba conectarse el cliente de booth (con la opción -s ), seconectará siempre al sitio local.

Nota: cambios de sintaxisSe ha simplificado la sintaxis de los comandos del cliente de booth desde la versión SUSELinux Enterprise High Availability Extension 11. Por ejemplo, la palabra clave clientse puede omitir para las operaciones list , grant o revoke : booth list . Además, laopción -t se puede omitir cuando se especica un ticket.

Aún se admite la sintaxis anterior. Para obtener información detallada, consulte la secciónResumen en la página man de booth. Sin embargo, en los ejemplos en este manual seutiliza la sintaxis simplificada.

DESCRIPCIÓN GENERAL DE LOS COMANDOS DEL cliente de booth

Listado de todos los tickets

root # booth listticket: ticketA, leader: noneticket: ticketB, leader: 10.2.12.101, expires: 2014-08-13 10:28:57

Si no se especica un sitio determinado con -s , se solicita la información de los ticketsa la instancia de booth local.

Concesión de un ticket a un sitio

root # booth grant -s 192.168.201.151 ticketAbooth[27891]: 2014/08/13_10:21:23 info: grant request sent, waiting for the result ...booth[27891]: 2014/08/13_10:21:23 info: grant succeeded!

En este caso, ticketA se otorga al sitio 192.168.201.151 . Si omite la opción -s , boothse conecta automáticamente al sitio actual (el sitio en el que se ejecuta el cliente de booth)y pide la operación grant .


Antes de otorgar un ticket, el comando ejecuta una comprobación. Si el mismo ticket yase ha otorgado a otro sitio, se le advertirá al respecto y se le pedirá que revoque primeroel ticket del sitio actual.

Revocación de ticket a un sitio

root # booth revoke ticketAbooth[27900]: 2014/08/13_10:21:23 info: revoke succeeded!

Booth comprueba qué sitio tiene actualmente otorgado el ticket y pide la operaciónrevoke para ticketA . La operación de revocación se ejecuta de inmediato.

Las operaciones grant y, en determinadas circunstancias, revoke pueden tardar un poco endevolver el resultado denitivo de la operación. El cliente espera el resultado el tiempo límiteindicado para el ticket antes de abandonar la operación, a no ser que se haya utilizado la opción-w , en cuyo caso espera indefinidamente. Para comprobar el estado exacto, consulte los archivosde registro o utilice el comando crm_ticket -L .

Aviso: crm_ticket y crm site ticketEn caso de que el servicio booth no se esté ejecutando por cualquier motivo,también puede gestionar los tickets de forma manual con los comandos crm_ticket ocrm site ticket . Ambos comandos solo están disponibles en los nodos de clúster. Encaso de intervención, utilícelos con mucho cuidado, ya que no es posible comprobar si elmismo ticket ya se ha otorgado en otro lugar. Para obtener más información, consultelas páginas man.

Siempre que booth esté activo y en ejecución, utilice solo el cliente de booth paraintervenir manualmente.

Después de otorgar inicialmente un ticket a un sitio, el mecanismo booth tomará la iniciativa ygestionará de forma automática el ticket. Si el sitio que contiene un ticket está fuera de servicio,el ticket se revoca automáticamente después del tiempo de caducidad y se otorga a otro sitio.En los recursos que dependen del ticket se producirá una operación de failover al nuevo sitiodonde se encuentre el ticket. Los nodos que hayan ejecutado antes los recursos se tratarán deacuerdo con la directiva loss-policy que haya establecido en la restricción.


PROCEDIMIENTO 10: GESTIÓN MANUAL DE TICKETS

Por ejemplo, si desea trasladar manualmente ticket-nfs del sitio amsterdam (con la IPvirtual 192.168.201.151 ) al sitio berlin (con la IP virtual 192.168.202.151 ), hagalo siguiente:

1. Pase ticket-nfs a modo de reserva con el siguiente comando:

root # crm_ticket -t ticket-nfs -s

2. Espere a que los recursos que dependen de ticket-nfs se detengan o bajen de nivel sinproblemas.

3. Revoque ticket-nfs del sitio amsterdam con:

root # booth revoke -s 192.168.201.151 ticket-nfs

4. Después de que el ticket se haya revocado en su sitio original, otórguelo al sitio berlincon:

root # booth grant -s 192.168.202.151 ticket-nfs

11.2 Con HA Web Konsole (Hawk2)

Hawk2 es una interfaz de usuario basada en Web para la gestión de clústeres y clústeres geográ-ficos.

11.2.1 Supervisión de varios clústeres con la consola de Hawk2

La información de clúster que se muestra en la consola se almacena en el servidor y se sincronizaentre los nodos de clúster (si se ha configurado el acceso SSH sin contraseña entre estos). Paraobtener información, consulte la Guía de administración de SUSE Linux Enterprise High Availa-bility Extension, disponible en http://www.suse.com/documentation/ . Consulte el capítuloEjecución de informes de clúster sin acceso de root , sección Configuración de una cuenta SSHsin contraseña. Sin embargo, para este propósito no es necesario que el equipo en el que seejecute Hawk2 forme parte de ningún clúster: puede encontrarse en un sistema independienteno relacionado.



PROCEDIMIENTO 11: SUPERVISIÓN DE VARIOS CLÚSTERES CON HAWK2

REQUISITOS PREVIOS

En todos los clústeres que se van a supervisar con la consola de Hawk2 se debeejecutar SUSE Linux Enterprise High Availability Extension 12 SP2. No es posiblesupervisar clústeres en los que se ejecuten versiones anteriores de SUSE Linux Enter-prise High Availability Extension.

Si no ha sustituido el certificado autormado de Hawk2 en cada nodo de clúster porsu propio certificado (o por un certificado rmado por una autoridad certificadoraocial), entre en Hawk2 en cada nodo y en cada clúster al menos una vez. Veriqueel certificado (o añada una excepción en el navegador para omitir la advertencia).

1. Inicie el servicio Web de Hawk2 en el equipo que desee utilizar para supervisar variosclústeres:

root # systemctl start hawk

2. Inicie un navegador Web y, como URL, introduzca la dirección IP o el nombre de host delequipo en el que se ejecuta Hawk2:

https://HAWKSERVER:7630/

3. Entre en la interfaz Web de Hawk2.

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

5. Para añadir consolas para varios clústeres, haga clic en Añadir clúster.


a. Introduzca un valor en Nombre de clúster personalizado para identificar el clúster enla consola.

b. Escriba el Nombre de host del nodo en el clúster.

c. Conrme los cambios con Añadir.

d. Para añadir más clústeres a la consola, haga clic en Añadir clúster de nuevo e intro-duzca los detalles del clúster siguiente.


FIGURA 5: CONSOLA DE HAWK2

6. Para eliminar un clúster de la consola, haga clic en el icono de x situado junto al nombredel clúster.

7. Para ver información sobre un clúster, introduzca una contraseña y haga clic en Conectar.Hawk2 mostrará un resumen con el estado de los nodos correspondientes, los recursos ylos tickets. Al hacer clic en un nombre de clúster se abre la vista Estado de dicho clúster,desde donde podrá administrarlo de la forma habitual.

Los cambios de estado en los nodos o los recursos se reejan casi de inmediato en la consola.

11.2.2 Gestión de tickets con Hawk2

Los tickets pueden verse en Hawk2 si se han otorgado o revocado al menos una vez o si se hacereferencia a ellos en una dependencia de ticket.

Hawk2 muestra los siguientes estados de tickets:

Otorgado: los tickets que se han otorgado al sitio actual.

En otro lugar: los tickets que se han otorgado en otro sitio.

Revocado: los tickets que se han revocado. Además, Hawk2 también muestra los ticketscomo revocados cuando se hace referencia a ellos en una dependencia de ticket, pero nose han otorgado aún a ningún sitio.


Nota: concesión de tickets al sitio actual y revocación de ticketsAunque puede ver los tickets de todos los sitios con Hawk2, las operaciones paraotorgarlos o revocarlos activadas por Hawk2 solo se aplican al sitio actual (al que se haconectado con Hawk2). Para otorgar un ticket a otro sitio del clúster geográco, inicieHawk2 en uno de los nodos de clúster que pertenecen al sitio correspondiente.

Solo puede otorgar tickets que aún no se hayan cedido a ningún sitio.

PROCEDIMIENTO 12: VISUALIZACIÓN, CONCESIÓN Y REVOCACIÓN DE TICKETS CON HAWK2

1. Inicie un navegador Web y entre en Hawk2.

2. En la barra de navegación izquierda, seleccione Estado.Junto a la información sobre los nodos de clúster y los recursos, Hawk2 también muestrala categoría Tickets, donde se muestran los estados del ticket, el ID de la restricción a laque hace referencia el ticket y el nombre del ticket. La categoría Tickets también contienedos columnas para la gestión de los tickets.

3. Para mostrar información de un ticket concreto, haga clic en el icono Detalles situadojunto al ticket. En una ventana se indica si el ticket ya se ha otorgado, qué directiva depérdida se ha denido (en el caso de que un ticket se revoque en un sitio) y los recursosque dependen del ticket.

FIGURA 6: HAWK2: DETALLES DEL TICKET


4. Para revocar un ticket otorgado desde el sitio actual o para otorgar un ticket al sitio actual,haga clic en el conmutador de la columna Otorgado situado junto al ticket. Al hacer clic,se muestra la acción disponible. Conrme su elección en el mensaje de confirmación deHawk2.Si no es posible otorgar o revocar el ticket por cualquier motivo, Hawk2 muestra unmensaje de error. Si el ticket se otorga o se revoca correctamente, Hawk2 actualiza elestado del ticket.

12 Solución de problemasEn booth se utiliza el mismo mecanismo de registro que en CRM. Por lo tanto, el cambio delnivel de registro también surte efecto en el registro de booth. Los mensajes de registro de boothtambién contienen información acerca de los tickets.

Tanto los mensajes de registro como el archivo de configuración de booth se incluyen en crmreport .

Si se produce cualquier problema o un comportamiento inesperado de booth, compruebe losdatos de registro con el comando sudo journalctl - n o cree un informe detallado del clústercon crm report .

En caso de que pueda acceder a los nodos del clúster en todos los sitios (además de en losárbitros) desde un único host a través de SSH, es posible recopilar archivos de registro de todosellos con el mismo comando crm report . Al llamar a crm report con la opción -n , seobtienen los archivos de registro de todos los hosts que haya especificado con el parámetro ‑n .(Si no se indica -n , se intenta obtener la lista de nodos del clúster respectivo). Por ejemplo,para crear un único crm report que incluya los archivos de registro de clústeres de dos nodos( 192.168.201.111 | 192.168.201.112 y 192.168.202.111 | 192.168.202.112 ) además deun árbitro ( 147.2.207.14 ), utilice el comando siguiente:

root # crm report -n "147.2.207.14 192.168.201.111 192.168.201.112 \ 192.168.202.111 192.168.202.112" -f 10:00 -t 11:00 db-incident

Si el problema solo es de booth y sabe en qué nodos de clúster se está ejecutando booth, especi-fique solo esos dos nodos y el árbitro.


Si no es posible acceder a todos los sitios desde un host, ejecute crm report de forma individualen el árbitro y en los nodos de clúster de los sitios individuales, especificando el mismo períodode tiempo. Para recopilar los archivos de registro en un árbitro, debe utilizar la opción -S parala operación de nodo único:

amsterdam # crm report -f 10:00 -t 11:00 db-incident-amsterdamberlin # crm report -f 10:00 -t 11:00 db-incident-berlinarbitrator # crm report -S -f 10:00 -t 11:00 db-incident-arbitrator

Sin embargo, es preferible producir un único informe crm report para todos los equipos sobrelos que se necesiten los archivos de registro.

13 Actualización a la última versión del productoPara obtener instrucciones generales sobre cómo actualizar un clúster, consulte la Guía deadministración de SUSE Linux Enterprise High Availability Extension 12 SP2, disponible en http://

www.suse.com/documentation/ . En el capítulo Actualización del clúster y de los paquetes desoftware también se describen los preparativos necesarios antes de iniciar el proceso de actua-lización.

TABLA 1: VÍAS DE ACTUALIZACIÓN ADMITIDAS PARA SLE HA Y SLE HA GEO

Actualización(origen y destino)

Vía de actuali-zación

Para obtener más detalles, consulte:

SLE HA 11 SP3 aSLE HA (Geo) 12

Migración sinconexión

Sistema base: Guía de distribución de SUSELinux Enterprise Server 12, parte Actuali-zación de SUSE Linux Enterprise

SLE HA: Guía de administración de SUSELinux Enterprise High Availability Extension12 SP1, capítulo Actualización del clústery de los paquetes de software, secciónMigración sin conexión

SLE HA Geo: Migración sin conexión







SLE HA (Geo) 11 SP4aSLE HA (Geo) 12 SP1

Migración sinconexión

Sistema base: Guía de distribución de SUSELinux Enterprise Server 12 SP1, parte Actua-lización de SUSE Linux Enterprise

SLE HA: Guía de administración de SUSELinux Enterprise High Availability Extension12 SP1, capítulo Actualización del clústery de los paquetes de software, secciónMigración sin conexión

SLE HA Geo: Actualización del árbitro

SLE HA (Geo) 12 aSLE HA (Geo) 12 SP1

Actualizaciónsobre la marcha


SLE HA: Guía de administración de SUSELinux Enterprise High Availability Extension12 SP1, capítulo Actualización del clústery de los paquetes de software, secciónMigración sobre la marcha


SLE HA (Geo) 12 SP1aSLE HA (Geo) 12 SP2

Actualizaciónsobre la marcha


SLE HA: Guía de administración de SUSELinux Enterprise High Availability Extension12 SP2, capítulo Actualización del clústery de los paquetes de software, secciónMigración sobre la marcha






DRBD 8 a DRBD 9: Guía de administraciónde SUSE Linux Enterprise High AvailabilityExtension 12 SP2, capítulo DRBD, secciónMigración de DRBD 8 a DRBD 9

13.1 Migración sin conexión

Esta sección se aplica a los escenarios siguientes:

Actualización de SLE HA Geo 11 SP3 a SLE HA Geo 12

La versión 0.1 de booth de SUSE Linux Enterprise High Availability Extension 11 a 11 SP3 sebasaba en el algoritmo Paxos. La versión 0.2 de booth de SUSE Linux Enterprise High AvailabilityExtension 11 SP4 y SUSE Linux Enterprise High Availability Extension 12 y 12 SPx se basalibremente en raft y no es compatible con la versión 0.1. Por lo tanto, no es posible llevar acabo una actualización sobre la marcha desde ningún sistema donde se ejecute la versión debooth antigua a uno donde se ejecute la nueva. En su lugar, todos los nodos de clúster debenestar sin conexión y el clúster debe migrarse como un conjunto, tal y como se describe en elProcedimiento 13, “Realización de una migración de todo el clúster sin conexión”.

Debido a la nueva función de varios inquilinos, el nuevo guion init del árbitro no puede detenerni comprobar el estado del árbitro Paxos 0.1. Al actualizar a la versión 0.2, el árbitro se detiene,si está en ejecución. El agente de recurso OCF ocf:pacemaker:booth-site es capaz de detenery supervisar el daemon del sitio de la versión 0.1 de booth.

PROCEDIMIENTO 13: REALIZACIÓN DE UNA MIGRACIÓN DE TODO EL CLÚSTER SIN CONEXIÓN

1. Para llevar a cabo una actualización de los nodos de clúster, siga las instrucciones de laGuía de administración de SUSE Linux Enterprise High Availability Extension 12 SP1, capítuloActualización del clúster y de los paquetes de software, sección Migración sin conexión.


2. Si utiliza árbitros fuera de los sitios de clúster:

a. Actualice cada árbitro a la versión que desee de SUSE Linux Enterprise Server. Paraobtener la información sobre los procesos de actualización individuales, consulte laTabla 1, “Vías de actualización admitidas para SLE HA y SLE HA Geo”.

b. Añada la extensión de clústeres geográficos e instale los paquetes como se describeen la Sección 1.2, “Instalación de paquetes en árbitros”.

3. Dado que la sintaxis y el algoritmo de consenso de booth han cambiado, debe actualizarlos archivos de configuración de booth para que cumplan los requisitos más recientes.Anteriormente, si lo desea, puede especificar el tiempo de caducidad y ponderacionesañadiéndolos al nombre del ticket con un punto y coma ( ; ) como separador. La nuevasintaxis tiene testigos independientes para todas las opciones del ticket. Consulte laSección 6, “Configuración de los servicios de booth” para obtener más información. Si noespecica un tiempo de caducidad o ponderaciones distintos a los valores por defecto yno desea usar la función de varios inquilinos, puede seguir utilizando el antiguo archivo/etc/booth/booth.conf .

4. Sincronice los archivos de configuración de booth actualizados en todos los sitios de clústery árbitros.

5. Inicie el servicio de booth en los sitios de clúster y en los árbitros, como se describe en laSección 6.4, “Habilitación e inicio de los servicios de booth”.

13.2 Actualización del árbitro

Esta sección se aplica a los escenarios siguientes:

Actualización de SLE HA Geo 11 SP4 a SLE HA Geo 12 SP1

Actualización de SLE HA Geo 12 a SLE HA Geo 12 SP1

Actualización de SLE HA Geo 12 SP1 a SLE HA Geo 12 SP2

PROCEDIMIENTO 14: ACTUALIZACIÓN DE LOS ÁRBITROS FUERA DEL CLÚSTER

Si utiliza árbitros fuera de los sitios de clúster, siga estos pasos para cada árbitro:

1. Lleve a cabo una actualización a la versión de destino que desee de SUSE Linux Enter-prise Server. Para obtener la información sobre los procesos de actualización individuales,consulte la Tabla 1, “Vías de actualización admitidas para SLE HA y SLE HA Geo”.


2. Añada la extensión de clústeres geográficos e instale los paquetes como se describe en laSección 1.2, “Instalación de paquetes en árbitros”.

A GNU LicensesThis appendix contains the GNU Free Documentation License version 1.2.

GNU Free Documentation License

Copyright (C) 2000, 2001, 2002 Free Software Foundation, Inc. 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA. Everyone is permitted to copy and distribute verbatim copies of thislicense document, but changing it is not allowed.

0. PREAMBLE

The purpose of this License is to make a manual, textbook, or other functional and useful document "free" in the sense of freedom: to assure everyone the eective freedom to copy and redistributeit, with or without modifying it, either commercially or noncommercially. Secondarily, this License preserves for the author and publisher a way to get credit for their work, while not beingconsidered responsible for modifications made by others.

This License is a kind of "copyleft", which means that derivative works of the document must themselves be free in the same sense. It complements the GNU General Public License, which isa copyleft license designed for free software.

We have designed this License in order to use it for manuals for free software, because free software needs free documentation: a free program should come with manuals providing the samefreedoms that the software does. But this License is not limited to software manuals; it can be used for any textual work, regardless of subject matter or whether it is published as a printed book.We recommend this License principally for works whose purpose is instruction or reference.

1. APPLICABILITY AND DEFINITIONS

This License applies to any manual or other work, in any medium, that contains a notice placed by the copyright holder saying it can be distributed under the terms of this License. Such a noticegrants a world-wide, royalty-free license, unlimited in duration, to use that work under the conditions stated herein. The "Document", below, refers to any such manual or work. Any member ofthe public is a licensee, and is addressed as "you". You accept the license if you copy, modify or distribute the work in a way requiring permission under copyright law.

A "Modied Version" of the Document means any work containing the Document or a portion of it, either copied verbatim, or with modifications and/or translated into another language.

A "Secondary Section" is a named appendix or a front-matter section of the Document that deals exclusively with the relationship of the publishers or authors of the Document to the Document'soverall subject (or to related matters) and contains nothing that could fall directly within that overall subject. (Thus, if the Document is in part a textbook of mathematics, a Secondary Sectionmay not explain any mathematics.) The relationship could be a matter of historical connection with the subject or with related matters, or of legal, commercial, philosophical, ethical or politicalposition regarding them.

The "Invariant Sections" are certain Secondary Sections whose titles are designated, as being those of Invariant Sections, in the notice that says that the Document is released under this License.If a section does not t the above denition of Secondary then it is not allowed to be designated as Invariant. The Document may contain zero Invariant Sections. If the Document does notidentify any Invariant Sections then there are none.

The "Cover Texts" are certain short passages of text that are listed, as Front-Cover Texts or Back-Cover Texts, in the notice that says that the Document is released under this License. A Front-Cover Text may be at most 5 words, and a Back-Cover Text may be at most 25 words.

A "Transparent" copy of the Document means a machine-readable copy, represented in a format whose specification is available to the general public, that is suitable for revising the documentstraightforwardly with generic text editors or (for images composed of pixels) generic paint programs or (for drawings) some widely available drawing editor, and that is suitable for inputto text formatters or for automatic translation to a variety of formats suitable for input to text formatters. A copy made in an otherwise Transparent le format whose markup, or absence ofmarkup, has been arranged to thwart or discourage subsequent modification by readers is not Transparent. An image format is not Transparent if used for any substantial amount of text. Acopy that is not "Transparent" is called "Opaque".

Examples of suitable formats for Transparent copies include plain ASCII without markup, Texinfo input format, LaTeX input format, SGML or XML using a publicly available DTD, and standard-conforming simple HTML, PostScript or PDF designed for human modification. Examples of transparent image formats include PNG, XCF and JPG. Opaque formats include proprietary formatsthat can be read and edited only by proprietary word processors, SGML or XML for which the DTD and/or processing tools are not generally available, and the machine-generated HTML,PostScript or PDF produced by some word processors for output purposes only.

The "Title Page" means, for a printed book, the title page itself, plus such following pages as are needed to hold, legibly, the material this License requires to appear in the title page. For worksin formats which do not have any title page as such, "Title Page" means the text near the most prominent appearance of the work's title, preceding the beginning of the body of the text.

A section "Entitled XYZ" means a named subunit of the Document whose title either is precisely XYZ or contains XYZ in parentheses following text that translates XYZ in another language. (HereXYZ stands for a specic section name mentioned below, such as "Acknowledgements", "Dedications", "Endorsements", or "History".) To "Preserve the Title" of such a section when you modifythe Document means that it remains a section "Entitled XYZ" according to this denition.

The Document may include Warranty Disclaimers next to the notice which states that this License applies to the Document. These Warranty Disclaimers are considered to be included by referencein this License, but only as regards disclaiming warranties: any other implication that these Warranty Disclaimers may have is void and has no eect on the meaning of this License.

2. VERBATIM COPYING

You may copy and distribute the Document in any medium, either commercially or noncommercially, provided that this License, the copyright notices, and the license notice saying this Licenseapplies to the Document are reproduced in all copies, and that you add no other conditions whatsoever to those of this License. You may not use technical measures to obstruct or control thereading or further copying of the copies you make or distribute. However, you may accept compensation in exchange for copies. If you distribute a large enough number of copies you mustalso follow the conditions in section 3.

You may also lend copies, under the same conditions stated above, and you may publicly display copies.


3. COPYING IN QUANTITY

If you publish printed copies (or copies in media that commonly have printed covers) of the Document, numbering more than 100, and the Document's license notice requires Cover Texts, youmust enclose the copies in covers that carry, clearly and legibly, all these Cover Texts: Front-Cover Texts on the front cover, and Back-Cover Texts on the back cover. Both covers must also clearlyand legibly identify you as the publisher of these copies. The front cover must present the full title with all words of the title equally prominent and visible. You may add other material on thecovers in addition. Copying with changes limited to the covers, as long as they preserve the title of the Document and satisfy these conditions, can be treated as verbatim copying in other respects.

If the required texts for either cover are too voluminous to t legibly, you should put the rst ones listed (as many as t reasonably) on the actual cover, and continue the rest onto adjacent pages.

If you publish or distribute Opaque copies of the Document numbering more than 100, you must either include a machine-readable Transparent copy along with each Opaque copy, or state inor with each Opaque copy a computer-network location from which the general network-using public has access to download using public-standard network protocols a complete Transparentcopy of the Document, free of added material. If you use the latter option, you must take reasonably prudent steps, when you begin distribution of Opaque copies in quantity, to ensure thatthis Transparent copy will remain thus accessible at the stated location until at least one year after the last time you distribute an Opaque copy (directly or through your agents or retailers)of that edition to the public.

It is requested, but not required, that you contact the authors of the Document well before redistributing any large number of copies, to give them a chance to provide you with an updatedversion of the Document.

4. MODIFICATIONS

You may copy and distribute a Modied Version of the Document under the conditions of sections 2 and 3 above, provided that you release the Modied Version under precisely this License,with the Modied Version lling the role of the Document, thus licensing distribution and modification of the Modied Version to whoever possesses a copy of it. In addition, you must dothese things in the Modied Version:

A. Use in the Title Page (and on the covers, if any) a title distinct from that of the Document, and from those of previous versions (which should, if there were any, be listed in the Historysection of the Document). You may use the same title as a previous version if the original publisher of that version gives permission.

B. List on the Title Page, as authors, one or more persons or entities responsible for authorship of the modifications in the Modied Version, together with at least ve of the principalauthors of the Document (all of its principal authors, if it has fewer than ve), unless they release you from this requirement.

C. State on the Title page the name of the publisher of the Modied Version, as the publisher.

D. Preserve all the copyright notices of the Document.

E. Add an appropriate copyright notice for your modifications adjacent to the other copyright notices.

F. Include, immediately after the copyright notices, a license notice giving the public permission to use the Modied Version under the terms of this License, in the form shown inthe Addendum below.

G. Preserve in that license notice the full lists of Invariant Sections and required Cover Texts given in the Document's license notice.

H. Include an unaltered copy of this License.

I. Preserve the section Entitled "History", Preserve its Title, and add to it an item stating at least the title, year, new authors, and publisher of the Modied Version as given on theTitle Page. If there is no section Entitled "History" in the Document, create one stating the title, year, authors, and publisher of the Document as given on its Title Page, then addan item describing the Modied Version as stated in the previous sentence.

J. Preserve the network location, if any, given in the Document for public access to a Transparent copy of the Document, and likewise the network locations given in the Documentfor previous versions it was based on. These may be placed in the "History" section. You may omit a network location for a work that was published at least four years before theDocument itself, or if the original publisher of the version it refers to gives permission.

K. For any section Entitled "Acknowledgements" or "Dedications", Preserve the Title of the section, and preserve in the section all the substance and tone of each of the contributoracknowledgements and/or dedications given therein.

L. Preserve all the Invariant Sections of the Document, unaltered in their text and in their titles. Section numbers or the equivalent are not considered part of the section titles.

M. Delete any section Entitled "Endorsements". Such a section may not be included in the Modied Version.

N. Do not retitle any existing section to be Entitled "Endorsements" or to conict in title with any Invariant Section.

O. Preserve any Warranty Disclaimers.

If the Modied Version includes new front-matter sections or appendices that qualify as Secondary Sections and contain no material copied from the Document, you may at your option designatesome or all of these sections as invariant. To do this, add their titles to the list of Invariant Sections in the Modied Version's license notice. These titles must be distinct from any other section titles.

You may add a section Entitled "Endorsements", provided it contains nothing but endorsements of your Modied Version by various parties--for example, statements of peer review or that thetext has been approved by an organization as the authoritative denition of a standard.

You may add a passage of up to ve words as a Front-Cover Text, and a passage of up to 25 words as a Back-Cover Text, to the end of the list of Cover Texts in the Modied Version. Onlyone passage of Front-Cover Text and one of Back-Cover Text may be added by (or through arrangements made by) any one entity. If the Document already includes a cover text for the samecover, previously added by you or by arrangement made by the same entity you are acting on behalf of, you may not add another; but you may replace the old one, on explicit permissionfrom the previous publisher that added the old one.

The author(s) and publisher(s) of the Document do not by this License give permission to use their names for publicity for or to assert or imply endorsement of any Modied Version.

5. COMBINING DOCUMENTS

You may combine the Document with other documents released under this License, under the terms dened in section 4 above for modied versions, provided that you include in the combinationall of the Invariant Sections of all of the original documents, unmodied, and list them all as Invariant Sections of your combined work in its license notice, and that you preserve all theirWarranty Disclaimers.

The combined work need only contain one copy of this License, and multiple identical Invariant Sections may be replaced with a single copy. If there are multiple Invariant Sections with thesame name but dierent contents, make the title of each such section unique by adding at the end of it, in parentheses, the name of the original author or publisher of that section if known, orelse a unique number. Make the same adjustment to the section titles in the list of Invariant Sections in the license notice of the combined work.

In the combination, you must combine any sections Entitled "History" in the various original documents, forming one section Entitled "History"; likewise combine any sections Entitled "Acknow-ledgements", and any sections Entitled "Dedications". You must delete all sections Entitled "Endorsements".


6. COLLECTIONS OF DOCUMENTS

You may make a collection consisting of the Document and other documents released under this License, and replace the individual copies of this License in the various documents with a singlecopy that is included in the collection, provided that you follow the rules of this License for verbatim copying of each of the documents in all other respects.

You may extract a single document from such a collection, and distribute it individually under this License, provided you insert a copy of this License into the extracted document, and followthis License in all other respects regarding verbatim copying of that document.

7. AGGREGATION WITH INDEPENDENT WORKS

A compilation of the Document or its derivatives with other separate and independent documents or works, in or on a volume of a storage or distribution medium, is called an "aggregate" if thecopyright resulting from the compilation is not used to limit the legal rights of the compilation's users beyond what the individual works permit. When the Document is included in an aggregate,this License does not apply to the other works in the aggregate which are not themselves derivative works of the Document.

If the Cover Text requirement of section 3 is applicable to these copies of the Document, then if the Document is less than one half of the entire aggregate, the Document's Cover Texts may beplaced on covers that bracket the Document within the aggregate, or the electronic equivalent of covers if the Document is in electronic form. Otherwise they must appear on printed coversthat bracket the whole aggregate.

8. TRANSLATION

Translation is considered a kind of modification, so you may distribute translations of the Document under the terms of section 4. Replacing Invariant Sections with translations requires specialpermission from their copyright holders, but you may include translations of some or all Invariant Sections in addition to the original versions of these Invariant Sections. You may include atranslation of this License, and all the license notices in the Document, and any Warranty Disclaimers, provided that you also include the original English version of this License and the originalversions of those notices and disclaimers. In case of a disagreement between the translation and the original version of this License or a notice or disclaimer, the original version will prevail.

If a section in the Document is Entitled "Acknowledgements", "Dedications", or "History", the requirement (section 4) to Preserve its Title (section 1) will typically require changing the actual title.

9. TERMINATION

You may not copy, modify, sublicense, or distribute the Document except as expressly provided for under this License. Any other attempt to copy, modify, sublicense or distribute the Documentis void, and will automatically terminate your rights under this License. However, parties who have received copies, or rights, from you under this License will not have their licenses terminatedso long as such parties remain in full compliance.

10. FUTURE REVISIONS OF THIS LICENSE

The Free Software Foundation may publish new, revised versions of the GNU Free Documentation License from time to time. Such new versions will be similar in spirit to the present version,but may dier in detail to address new problems or concerns. See http://www.gnu.org/copyleft/ .

Each version of the License is given a distinguishing version number. If the Document species that a particular numbered version of this License "or any later version" applies to it, you havethe option of following the terms and conditions either of that specied version or of any later version that has been published (not as a draft) by the Free Software Foundation. If the Documentdoes not specify a version number of this License, you may choose any version ever published (not as a draft) by the Free Software Foundation.

ADDENDUM: How to use this License for your documents

Copyright (c) YEAR YOUR NAME. Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.2 or any later version published by the Free Software Foundation; with no Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license is included in the section entitled “GNU Free Documentation License”.

If you have Invariant Sections, Front-Cover Texts and Back-Cover Texts, replace the “with...Texts.” line with this:

with the Invariant Sections being LIST THEIR TITLES, with the Front-Cover Texts being LIST, and with the Back-Cover Texts being LIST.

If you have Invariant Sections without Cover Texts, or some other combination of the three, merge those two alternatives to suit the situation.

If your document contains nontrivial examples of program code, we recommend releasing these examples in parallel under your choice of free software license, such as the GNU General PublicLicense, to permit their use in free software.


http://www.gnu.org/copyleft/

Inicio rápido de Geo Clustering - documentation.suse.com...escenario de ejemplo con un clúster...

Documents

Transcript of Inicio rápido de Geo Clustering - documentation.suse.com...escenario de ejemplo con un clúster...