Saltar a contenido

Alta disponibilidad

Puede desplegar Drovio Server en alta disponibilidad para evitar cualquier interrupción que degrade la experiencia de los usuarios. Drovio Server se apoya para ello en el clustering Hazelcast.

Desplegar varias instancias

Despliegue Drovio Server en al menos dos máquinas distintas. Asegúrese de que cada instancia esté configurada de la misma manera.

Deberá alojar la base de datos en una máquina aparte, para que sea accesible desde ambas instancias. Drovio Server solo admite PostgreSQL 14 y superior.

Tamaños de los pools

Ajuste con cuidado los dos tamaños de pool (pool_options.main.max_size y pool_options.licensing.max_size) en cada instancia: su suma global debe quedar por debajo del número máximo de conexiones que su base de datos puede aceptar. Por ejemplo, con max_connections = 60 y dos instancias, fije ambos max_size a 15 en cada instancia.

Puede consultar el valor máximo de conexiones con la herramienta PostgreSQL psql, mediante show max_connections;.

Activar el clustering

Abra el archivo de propiedades del clúster:

/etc/drovio-server/cluster.properties

C:\ProgramData\Drovio\Drovio Server\cluster.properties

Después:

  • Ponga enabled a true.
  • Compruebe que config_path apunta al archivo cluster.xml, normalmente situado en la misma carpeta que cluster.properties.
  • Indique en host la IP privada de la máquina, la que sirve para comunicarse con los demás miembros del clúster, o 0.0.0.0 para escuchar en todas las interfaces disponibles.
  • Puede dejar port a 0: Vert.x elige automáticamente un puerto libre y Hazelcast lo anuncia a los demás miembros durante el descubrimiento. Fije un puerto solo si sus reglas de cortafuegos lo exigen.

Configurar el clustering

Abra el archivo XML del clúster:

/etc/drovio-server/cluster.xml

C:\ProgramData\Drovio\Drovio Server\cluster.xml

Debe modificar el contenido de la etiqueta <network></network>, sin tocar las demás etiquetas. A partir de ahí dispone de varias opciones para que sus instancias se descubran mutuamente.

El multicast debe estar activado en su red para que esto funcione.

<network>
  <join>
    <multicast enabled="true">
      <multicast-group>224.2.2.3</multicast-group>
      <multicast-port>54327</multicast-port>
    </multicast>
  </join>
</network>

Indique las IP estáticas de los demás miembros, procurando desactivar el multicast.

<network>
  <join>
    <multicast enabled="false"/>
    <tcp-ip enabled="true">
      <member>10.12.38.2</member>
      <member>10.12.38.3</member>
    </tcp-ip>
  </join>
</network>

<network>
  <join>
    <multicast enabled="false"/>
    <aws enabled="true">
      <access-key>my-access-key</access-key>
      <secret-key>my-secret-key</secret-key>
      <iam-role>role</iam-role>
      <region>us-west-1</region>
      <host-header>ec2.amazonaws.com</host-header>
      <security-group-name>hazelcast-sg</security-group-name>
      <tag-key>type</tag-key>
      <tag-value>hz-nodes</tag-value>
    </aws>
  </join>
</network>

Todas estas etiquetas son opcionales. Sin access-key ni secret-key se usa el rol IAM, lo cual es lo recomendado, y lo mismo ocurre con iam-role. region vale us-east-1 de forma predeterminada, y host-header vale ec2.amazonaws.com, en cuyo caso region no debe indicarse. Por último, security-group-name y luego la pareja tag-key y tag-value restringen el descubrimiento a las instancias correspondientes.

Lo más sencillo para empezar con el descubrimiento AWS EC2 es:

  • Crear un rol IAM con el permiso ec2:DescribeInstances.
  • Asignarlo a cada instancia.
  • Utilizar únicamente region, tag-key y tag-value.

Para ir más lejos: README de hazelcast-aws.

Si las máquinas disponen de varias interfaces de red, por ejemplo cuando hay una VPN, puede indicar a Hazelcast cuál usar con la etiqueta <interface></interface>:

<network>
  <join>
    […]
  </join>
  <interfaces enabled="true">
    <interface>192.168.1.20</interface>
  </interfaces>
</network>

La dirección indicada es la asociada a su interfaz de red. Para ir más lejos: Hazelcast, mecanismos de descubrimiento.

Iniciar el clúster

Inicie cada instancia de una en una. Vigile los registros y espere una entrada como la de abajo antes de iniciar la siguiente, en general una decena de segundos entre cada arranque:

Members [2] {
  Member [192.168.1.105]:5701 - 899898be-b8aa-49aa-8d28-40917ccba56c
  Member [192.168.1.105]:5702 - d6b81800-2c78-4055-8a5f-7f5b65d49f30 this
}

Actualizar el clúster

Cuando deba actualizar Drovio Server, proceda de una instancia a la vez para evitar cualquier interrupción y para no perder los datos compartidos entre las instancias. Detenga la instancia manualmente, consulte los registros de la otra instancia y espere una entrada de este tipo antes de lanzar la actualización:

Members [1] {
  Member [192.168.1.105]:5702 - d6b81800-2c78-4055-8a5f-7f5b65d49f30 this
}

Conmutación por error (solo Linux)

Su clúster ya funciona, pero las instancias tienen direcciones IP distintas. Querrá configurar una conmutación de dirección sencilla, para que una sola IP pueda designar a una u otra instancia. En Linux, keepalived se presta bien a ello.

El principio es bastante simple:

  • Para dos instancias, dispone de tres direcciones IP, una de ellas compartida por ambas instancias.
  • Usted designa la instancia maestra y la instancia de reserva.
  • La IP compartida, por ejemplo 10.0.12.16, designa la instancia maestra, por ejemplo 10.0.12.17.
  • Cuando la instancia maestra cae, la IP compartida designa entonces la instancia de reserva, por ejemplo 10.0.12.18.

keepalived debe estar desplegado en todas sus instancias Drovio para que esto funcione.

La conmutación por error es la solución más rápida cuando quiere garantizar la disponibilidad del servicio. Cuando el clustering está activado, Drovio Server ya reparte internamente buena parte de las operaciones. En cambio, las peticiones HTTP siempre llegan a la misma instancia, y las conexiones WebSocket que Drovio Server mantiene con los clientes activos también las sostiene la misma instancia. Por tanto, querrá repartir la carga sobre el conjunto de la instalación a medida que la carga y el número de usuarios aumenten.

Balanceo de carga (solo Linux)

El balanceo de carga se obtiene con HAProxy o Nginx (Plus). Drovio Server es una aplicación HTTP y WebSocket. Necesita al menos una máquina adicional en la que desplegar HAProxy o Nginx.

Warning

En este escenario, si la máquina de balanceo cae, todo el servicio cae con ella. Querrá sin duda desplegar al menos dos máquinas adicionales y combinarlas con una técnica de conmutación como la descrita más arriba, por ejemplo HAProxy y keepalived.

AWS Elastic Load Balancing

Si las instancias de Drovio Server están desplegadas en Amazon AWS, puede montar rápidamente un balanceador con AWS ELB. Conmutación, balanceo de carga, WebSockets: todo está cubierto y solo requiere unos pocos clics. Consulte la documentación de AWS, Application Load Balancer.

Drenaje de las conexiones

Cuando deba detener una instancia por mantenimiento, retírela temporalmente del grupo de destino y espere al final del drenaje antes de detenerla realmente. Sin eso, el ELB devolverá respuestas HTTP 502 durante alrededor de un minuto, al estar rota la conexión persistente con la instancia detenida.

Respuesta multivalor de AWS Route 53

Si su nombre de dominio está gestionado por AWS Route 53, otra solución es la política de enrutamiento de respuesta multivalor. Asociada a comprobaciones de estado, el DNS responde a las consultas con la IP de una u otra instancia que siga en pie, hasta ocho, por turnos. Véase políticas multivalor y simple.

Note

La conexión entre un cliente Drovio y el clúster tarda más en restablecerse que con el método ELB: unos cinco segundos con el ELB frente a treinta segundos o un minuto con la respuesta multivalor. En cambio, durante la conmutación, las sesiones de compartición de pantalla en curso no se interrumpen, gracias a la arquitectura par a par de Drovio.