Compartir a través de

Configuración de grupos de disponibilidad e instancias de clúster de conmutación por error Always On de varias subredes

  • Artículo

Se aplica a: SQL Server - Linux

Cuando un grupo de disponibilidad (AG) o una instancia de clúster de conmutación por error (FCI) Always On abarca más de un sitio, cada sitio suele tener sus propias redes, lo que significa a menudo que cada sitio tiene su propia dirección IP.

Por ejemplo, las direcciones del sitio A empiezan por 192.168.1.<x>, mientras que las del sitio B comienzan por 192.168.2.<x>, donde <x> es la parte de la dirección IP que es única para el servidor. Si no hay aplicado ningún tipo de enrutamiento en el nivel de red, estos servidores no pueden comunicarse entre sí.

Hay dos formas de controlar este escenario:

  • configurar una red que una las dos subredes diferentes (conocida como VLAN)
  • configurar el enrutamiento entre las subredes

Solución basada en VLAN

Requisito previo: En el caso de una solución basada en VLAN, cada servidor que participa en un grupo de disponibilidad o una instancia de conmutación por error necesita dos tarjetas de red (NIC) para una disponibilidad adecuada (una NIC de puerto doble sería un solo punto de error en un servidor físico), a fin de que se le puedan asignar direcciones IP en su subred nativa, así como una en la VLAN. Este requisito se suma a cualquier otra necesidad de red, como iSCSI, que también necesita su propia red.

La creación de la dirección IP para el grupo de disponibilidad o la instancia de clúster de conmutación por error se realiza en la VLAN. En el ejemplo siguiente, la VLAN tiene una subred de 192.168.3.<x>, por lo que la dirección IP creada para el grupo de disponibilidad o la instancia de clúster de conmutación por error es 192.168.3.104. No es necesario configurar nada más, ya que hay una dirección IP única asignada al grupo de disponibilidad o la instancia de conmutación por error.

Diagrama que muestra cómo configurar varias subredes con VLAN.

Configuración con Pacemaker

En Windows, un clúster de conmutación por error de Windows Server (WSFC) admite de forma nativa varias subredes y administra varias direcciones IP a través de una dependencia OR en la dirección IP. En Linux, no hay ninguna dependencia OR, pero hay una manera de lograr una subred múltiple adecuada de forma nativa con Pacemaker, aunque no puede usar la línea de comandos normal de Pacemaker. En su lugar, debe modificar la base de información del clúster (CIB). CIB es un archivo XML con la configuración de Pacemaker.

Diagrama que muestra cómo configurar varias subredes con Pacemaker.

Actualización del CIB

  1. Exporte el CIB.

    sudo pcs cluster cib <filename>

    Donde <filename> es el nombre que quiere asignar al CIB.

  2. Edite el archivo generado. Busque la sección <resources>. Verá los distintos recursos creados para el grupo de disponibilidad o la instancia de clúster de conmutación por error. Busque el asociado a la dirección IP. Agregue una sección <instance_attributes> con la información de la segunda dirección IP, ya sea antes o después de la existente, pero antes de <operations>. Es similar a la siguiente sintaxis:

    <instance_attributes id="<NameForAttribute>">
    <nvpair id="<NameForIP>" name="ip" value="<IPAddress>"/>
</instance_attributes>

    donde <NameForAttribute> es el nombre único de este atributo, <NameForIP> es el nombre asociado a la dirección IP e <IPAddress> es la dirección IP de la segunda subred.

    A continuación se muestra un ejemplo.

    <instance_attributes id="virtualip-instance_attributes">
    <nvpair id="virtualip-instance_attributes-ip" name="ip" value="192.168.1.102"/>
</instance_attributes>

    De forma predeterminada, solo hay un objeto <instance_attributes /> en el archivo XML CIB exportado. Si hay dos subredes, necesita dos entradas <instance_attributes />.

    Este es un ejemplo de entradas para dos subredes:

    <instance_attributes id="virtualip-instance_attributes1">
    <rule id="Subnet1-IP" score="INFINITY" boolean-op="or">
        <expression id="Subnet1-Node1" attribute="#uname" operation="eq" value="Node1" />
        <expression id="Subnet1-Node2" attribute="#uname" operation="eq" value="Node2" />
    </rule>
    <nvpair id="IP-In-Subnet1" name="ip" value="192.168.1.102"/>
</instance_attributes>
<instance_attributes id="virtualip-instance_attributes2">
    <rule id="Subnet2-IP" score="INFINITY">
        <expression id="Subnet2-Node1" attribute="#uname" operation="eq" value="Node3" />
    </rule>
    <nvpair id="IP-In-Subnet2" name="ip" value="192.168.2.102"/>
</instance_attributes>

    Usaría boolean-op="or" cuando la subred tenga más de un servidor.

  3. Importe el CIB modificado y vuelva a configurar Pacemaker.

    sudo pcs cluster cib-push <filename>

    Donde <filename> es el nombre del archivo CIB con la información de dirección IP modificada.

Comprobación de la conmutación por error

  1. Después de que el CIB se haya aplicado correctamente con la configuración actualizada, haga ping al nombre DNS asociado al recurso de dirección IP en Pacemaker. Debe reflejar la dirección IP asociada a la subred que hospeda actualmente el grupo de disponibilidad o la instancia de clúster de conmutación por error.

  2. Conmute el grupo de disponibilidad o la instancia de clúster de conmutación por error en la otra subred.

  3. Una vez que el grupo de disponibilidad o la instancia de clúster de conmutación por error estén totalmente en línea, haga ping al nombre DNS asociado a la dirección IP. Debe reflejar la dirección IP de la segunda subred.

  4. Si quiere, conmute el grupo de disponibilidad o la instancia de clúster de conmutación por error en la subred original.

Contenido relacionado