Configuración de un cluster de dos nodos Db2 Pacemaker con fencing activado AWS

Este documento describe una configuración alternativa de Pacemaker que elimina la necesidad de un tercer host que actúe como árbitro del dispositivo de quórum (Qdevice) para Db2 V11.5.8.0 y posteriores. Describe las ventajas y desventajas de utilizar sólo el cercado, ayudando a los usuarios a evaluar el compromiso entre la reducción de costes de infraestructura y el aumento del tiempo de recuperación.

El objetivo de este documento es detallar una alternativa a la solución recomendada Pacemaker de dos nodos + dispositivo de quórum que se detalla en Soporte de dispositivos de quórum en Pacemaker - Documentación IBM

En AWS, no es estrictamente necesario configurar un dispositivo de quórum en un tercer host. En su lugar, puede desplegar un clúster de dos nodos Pacemaker utilizando fencing, tal y como se describe en este documento. La principal ventaja de esta configuración es la eliminación del tercer host que suele utilizarse para el arbitraje del quórum (Qdevice), lo que reduce la complejidad de la infraestructura y los costes continuos de la nube.

Sin embargo, la contrapartida es un mayor tiempo de recuperación en caso de que se produzca un fallo en el host primario. Este retraso se debe al tiempo necesario para vallar con éxito el nodo que ha fallado antes de que se pueda proceder a la conmutación por error. Según las pruebas internas realizadas en entornos controlados, la recuperación sólo con esgrima puede tardar hasta seis veces más en comparación con las configuraciones que incluyen un dispositivo de quórum. Para mitigar este retraso en los clusters HADR, el parámetro de configuración de la base de datos HADR_PEER_WINDOW debe establecerse en al menos 300 segundos. Esta configuración puede garantizar que la base de datos primaria permanezca en estado peer el tiempo suficiente para que el fencing y el failover se completen de forma segura.

En el caso de los clústeres de conmutación por error mutua, no se requiere ninguna configuración adicional para acomodar los retardos de esgrima. Sin embargo, la conmutación automática por error no puede iniciarse hasta que se haya completado con éxito el cercado.

La elección entre utilizar un dispositivo de quórum o sólo cercado debe basarse en los requisitos de su empresa, teniendo en cuenta tanto los objetivos de tiempo de recuperación como las limitaciones de costes. El vallado en AWS se implementa utilizando el agente fence_aws , una herramienta de vallado de E/S de código abierto que se comunica con las API AWS EC2 a través de la biblioteca boto3 Python.

En Db2 V11.5.5.0, el agente de cercado se incluía en el paquete de software de clúster Pacemaker, que se podía descargar por separado de IBM. A partir de Db2 V11.5.6.0, la pila de software Pacemaker se incluye en la imagen de instalación estándar Db2. Sin embargo, el agente de cercado sigue siendo una descarga independiente. Independientemente de la versión de Db2, el agente de esgrima para AWS debe obtenerse en el sitio de distribución oficial de IBM para garantizar la compatibilidad y el soporte. No utilice versiones de otras fuentes. Puede descargar el paquete de software Pacemaker y el agente de cercado AWS desde el sitio web de los servicios de registro de marketing IBM Db2 LUW Automated HADR with Pacemaker.

Instalación del agente de vallado

Para instalar el agente de cercado:

  1. Descargue la última versión del agente de cercado AWS.

    Para RHEL 9, descargar: Db2_RHEL9_AWS_fence_agents_4.15.0.tar.gz

    Para SLES 15, descargar: Db2_SLES15_AWS_fence_agents_4.15.0.tar.gz

  2. Descomprima el archivo con tar. Por ejemplo: tar -zxf Db2_RHEL9_AWS_fence_agents_4.15.0.tar.gz. El comando crea el directorio Db2_RHEL9_AWS_fence_agents_4.15.0 en el directorio de trabajo actual.
  3. Instale los paquetes rpm. Cambie al directorio y ejecute el siguiente comando:

    Para SLES: zypper install --allow-unsigned-rpm *.noarch.rpm.

    Para RHEL: dnf install *.noarch.rpm.

Nota: Los agentes de cercado deben estar instalados en ambos nodos del clúster.

Una vez instalado el agente de fencing, ya puede configurar un clúster HADR Pacemaker de dos hosts con fencing en AWS.

Configuración de un cluster HADR Pacemaker de dos hosts con fencing en AWS.

Requisitos previos:

Consulte en Restricciones en Pacemaker - IBM Documentación la lista de plataformas compatibles con Pacemaker. Estas mismas restricciones se aplican aquí.

Compruebe si su entorno AWS está configurado correctamente, incluidos los roles y las políticas de IAM, como se describe en ¿Qué es IAM? - AWS Identity and Access Management ( amazon.com ).

  1. Consulte la página Configuración de un entorno en clúster mediante la utilidad Db2 cluster manager ( db2cm ) de la documentación de IBM para implantar la solución HADR automatizada de la forma habitual.
  2. Asegúrese de que está instalada la última versión de la utilidad AWS CLI, tal como se describe en la documentación de AWS : Instalación o actualización de la última versión de AWS CLI. Una vez instalada la utilidad AWS, el comando aws debe ser accesible desde /usr/bin/aws. Para acceder a aws, puede ser necesario crear una dirección simbólica link.ln –s <aws cli location> /usr/bin/aws. Por ejemplo: ln –s /usr/local/aws-cli/v2/current/bin/aws /usr/bin/aws.
  3. Cree la siguiente política y adjúntela a las instancias con un rol IAM utilizando el ejemplo JSON. Consulte la documentación AWS Creación de políticas IAM para obtener más detalles.
    Nota: Sustituya los marcadores de posición <region>, <account-id> y <instance-id> en la política JSON por valores específicos de su cuenta AWS. A continuación, en la consola AWS Identity and Access Management (IAM) Console, cree un nuevo rol o utilice uno existente -como el rol configurado para Overlay IP- y cree una nueva política utilizando la plantilla JSON proporcionada. Una vez creada la política, adjúntela a la función de IAM seleccionada para habilitar las operaciones de vallado de su clúster Pacemaker.
    { 
    "Version": "2012-10-17", 
    "Statement": [ 
        { 
            "Sid": "Stmt000", 
            "Effect": "Allow", 
            "Action": [ 
                "ec2:DescribeInstances", 
                "ec2:DescribeInstanceAttribute", 
                "ec2:DescribeTags" 
            ], 
            "Resource": "*" 
        }, 
        { 
            "Sid": "Stmt001", 
            "Effect": "Allow", 
            "Action": [ 
                "ec2:ModifyInstanceAttribute", 
                "ec2:RebootInstances", 
                "ec2:StartInstances", 
                "ec2:StopInstances" 

            ], 
            "Resource": [ 
                "arn:aws:ec2:<region>:<account-id>:instance/<instance-id-hostA>", 
                "arn:aws:ec2:<region>:<account-id>:instance/<instance-id-hostB>" 
            ] 
        } 
    ] 
}

    Asigne el rol IAM a las instancias EC2 que forman parte del cluster. Para asignar el rol IAM, abra la consola EC2, seleccione la instancia. Seleccione Acciones > Seguridad > Modificar rol IAM. A continuación, seleccione la función creada anteriormente en el menú desplegable y haga clic en Actualizar función IAM.

  4. Asegúrese de que HADR_PEER_WINDOW está ajustado a 300 segundos como mínimo. Ejecute este comando en la base de datos primaria mediante HADR_PEER_WINDOW 300:
    db2 update db cfg for <database name>

    Reinicie HADR o reactive la base de datos para que el cambio surta efecto.

  5. Cree el recurso de agente de valla mediante el comando db2cm :
    db2cm -create -aws -fence

Eliminar los recursos de esgrima del clúster

  1. Utilice la utilidad db2cm para eliminar el recurso agente de vallado.
    db2cm -delete -aws –fence
  2. Compruebe que se ha eliminado el agente de la valla ejecutando el comando db2cm -list.
  3. Si el agente de valla se elimina de forma permanente, elimine la política IAM. Consulte la documentación de AWS Eliminación de políticas de IAM ( amazon.com ) para eliminar políticas.