Vai al contenuto

Alta disponibilità

Potete distribuire Drovio Server in alta disponibilità per evitare qualsiasi interruzione che degraderebbe l'esperienza degli utenti. Drovio Server si appoggia a tal fine sul clustering Hazelcast.

Distribuire più istanze

Distribuite Drovio Server su almeno due macchine distinte. Assicuratevi che ogni istanza sia configurata allo stesso modo.

Dovrete ospitare la base di dati su una macchina a parte, affinché sia raggiungibile da entrambe le istanze. Drovio Server supporta solo PostgreSQL 14 e superiore.

Dimensioni dei pool

Impostate con cura le due dimensioni di pool (pool_options.main.max_size e pool_options.licensing.max_size) su ogni istanza: la loro somma complessiva deve restare inferiore al numero massimo di connessioni che la vostra base può accettare. Per esempio, con max_connections = 60 e due istanze, fissate entrambi i max_size a 15 su ogni istanza.

Potete rilevare il valore del massimo di connessioni con lo strumento PostgreSQL psql, tramite show max_connections;.

Attivare il clustering

Aprite il file di proprietà del cluster:

/etc/drovio-server/cluster.properties

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

Poi:

  • Portate enabled a true.
  • Verificate che config_path designi effettivamente il file cluster.xml, normalmente situato nella stessa cartella di cluster.properties.
  • Valorizzate host con l'IP privato della macchina, quello che serve a comunicare con gli altri membri del cluster, oppure 0.0.0.0 per ascoltare su tutte le interfacce disponibili.
  • Potete lasciare port a 0: Vert.x sceglie automaticamente una porta libera e Hazelcast la annuncia agli altri membri durante la scoperta. Fissate una porta solo se le vostre regole di firewall lo esigono.

Configurare il clustering

Aprite il file XML del cluster:

/etc/drovio-server/cluster.xml

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

Dovete modificare il contenuto del tag <network></network>, mentre gli altri tag non devono essere toccati. Vi si offrono allora più opzioni perché le vostre istanze si scoprano a vicenda.

Il multicast deve essere attivato sulla vostra rete perché ciò funzioni.

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

Valorizzate gli IP statici degli altri membri, avendo cura di disattivare il 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>

Tutti questi tag sono facoltativi. Senza access-key né secret-key viene usato il ruolo IAM, il che è raccomandato, e lo stesso vale per iam-role. region vale us-east-1 per impostazione predefinita, e host-header vale ec2.amazonaws.com, nel qual caso region non deve essere valorizzato. Infine, security-group-name e poi la coppia tag-key e tag-value restringono la scoperta alle istanze corrispondenti.

Il modo più semplice per cominciare con la scoperta AWS EC2 è:

  • Creare un ruolo IAM dotato del permesso ec2:DescribeInstances.
  • Attribuirlo a ogni istanza.
  • Usare solo region, tag-key e tag-value.

Per approfondire: README di hazelcast-aws.

Se le macchine dispongono di più interfacce di rete, per esempio in presenza di una VPN, potete indicare a Hazelcast quale usare con il tag <interface></interface>:

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

L'indirizzo indicato è quello associato alla vostra interfaccia di rete. Per approfondire: Hazelcast, meccanismi di scoperta.

Avviare il cluster

Avviate ogni istanza una alla volta. Sorvegliate i log e attendete una voce come quella qui sotto prima di avviare la successiva, in genere una decina di secondi tra un avvio e l'altro:

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
}

Aggiornare il cluster

Quando dovete aggiornare Drovio Server, procedete un'istanza alla volta per evitare ogni interruzione e per non perdere i dati condivisi tra le istanze. Arrestate l'istanza manualmente, consultate i log dell'altra istanza e attendete una voce di questo tipo prima di lanciare l'aggiornamento:

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

Commutazione di indirizzo (solo Linux)

Il vostro cluster funziona, ma le istanze hanno indirizzi IP differenti. Vorrete configurare una semplice commutazione di indirizzo, affinché un solo IP possa designare l'una o l'altra istanza. Su Linux, keepalived si presta bene allo scopo.

Il principio è piuttosto semplice:

  • Per due istanze disponete di tre indirizzi IP, uno dei quali condiviso dalle due istanze.
  • Designate l'istanza master e l'istanza di riserva.
  • L'IP condiviso, per esempio 10.0.12.16, designa l'istanza master, per esempio 10.0.12.17.
  • Quando l'istanza master cade, l'IP condiviso designa allora l'istanza di riserva, per esempio 10.0.12.18.

keepalived deve essere distribuito su tutte le vostre istanze Drovio perché ciò funzioni.

La commutazione di indirizzo è la soluzione più rapida quando volete garantire la disponibilità del servizio. Quando il clustering è attivato, Drovio Server distribuisce già internamente buona parte delle operazioni. Per contro, le richieste HTTP arrivano sempre sulla stessa istanza, e le connessioni WebSocket che Drovio Server mantiene con i client attivi sono anch'esse portate dalla stessa istanza. Vorrete quindi senza dubbio distribuire il carico sull'insieme dell'installazione man mano che il carico e il numero di utenti aumentano.

Bilanciamento del carico (solo Linux)

Il bilanciamento del carico si ottiene con HAProxy o Nginx (Plus). Drovio Server è un'applicazione HTTP e WebSocket. Vi serve almeno una macchina supplementare su cui distribuire HAProxy o Nginx.

Warning

In questo scenario, se la macchina di bilanciamento cade, tutto il servizio cade con lei. Vorrete senza dubbio distribuire almeno due macchine supplementari e combinarle con una tecnica di commutazione come quella descritta più sopra, per esempio HAProxy e keepalived.

AWS Elastic Load Balancing

Se le istanze di Drovio Server sono distribuite su Amazon AWS, potete allestire rapidamente un bilanciatore con AWS ELB. Commutazione, bilanciamento del carico, WebSocket, tutto è supportato e richiede solo qualche clic. Fate riferimento alla documentazione AWS, Application Load Balancer.

Drenaggio delle connessioni

Quando dovete arrestare un'istanza per manutenzione, ritiratela temporaneamente dal gruppo di destinazione e attendete la fine del drenaggio prima di arrestarla davvero. Senza questo, l'ELB restituirà risposte HTTP 502 per circa un minuto, dato che la connessione persistente con l'istanza arrestata risulta interrotta.

Risposta multivalore AWS Route 53

Se il vostro nome di dominio è gestito da AWS Route 53, un'altra soluzione è la politica di instradamento a risposta multivalore. Associato a controlli di salute, il DNS risponde alle richieste con l'IP dell'una o dell'altra istanza ancora in piedi, fino a otto, a turno. Vedere politiche multivalore e semplice.

Note

La connessione tra un client Drovio e il cluster impiega più tempo a ristabilirsi che con il metodo ELB, circa cinque secondi per l'ELB contro trenta secondi o un minuto per la risposta multivalore. Per contro, durante la commutazione, le sessioni di condivisione dello schermo in corso non vengono interrotte, grazie all'architettura peer-to-peer di Drovio.