Zum Inhalt

Hochverfügbarkeit

Sie können Drovio Server in Hochverfügbarkeit bereitstellen, um jede Unterbrechung zu vermeiden, die das Erlebnis der Benutzer beeinträchtigen würde. Drovio Server stützt sich dafür auf das Hazelcast-Clustering.

Mehrere Instanzen bereitstellen

Stellen Sie Drovio Server auf mindestens zwei verschiedenen Maschinen bereit. Stellen Sie sicher, dass jede Instanz auf dieselbe Weise konfiguriert ist.

Sie müssen die Datenbank auf einer separaten Maschine betreiben, damit sie von beiden Instanzen erreichbar ist. Drovio Server unterstützt ausschließlich PostgreSQL 14 und höher.

Poolgrößen

Stellen Sie die beiden Poolgrößen (pool_options.main.max_size und pool_options.licensing.max_size) auf jeder Instanz sorgfältig ein: ihre Gesamtsumme muss unter der maximalen Anzahl von Verbindungen bleiben, die Ihre Datenbank annehmen kann. Bei max_connections = 60 und zwei Instanzen setzen Sie zum Beispiel beide max_size auf jeder Instanz auf 15.

Den Wert für die maximale Anzahl von Verbindungen ermitteln Sie mit dem PostgreSQL-Werkzeug psql, über show max_connections;.

Das Clustering aktivieren

Öffnen Sie die Properties-Datei des Clusters:

/etc/drovio-server/cluster.properties

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

Dann:

  • Setzen Sie enabled auf true.
  • Prüfen Sie, ob config_path tatsächlich auf die Datei cluster.xml verweist, die normalerweise im selben Ordner wie cluster.properties liegt.
  • Tragen Sie in host die private IP der Maschine ein, also die Adresse, über die sie mit den anderen Mitgliedern des Clusters kommuniziert, oder 0.0.0.0, um auf allen verfügbaren Schnittstellen zu lauschen.
  • Sie können port auf 0 belassen: Vert.x wählt automatisch einen freien Port und Hazelcast kündigt ihn den anderen Mitgliedern bei der Discovery an. Legen Sie einen festen Port nur dann fest, wenn Ihre Firewallregeln es verlangen.

Das Clustering konfigurieren

Öffnen Sie die XML-Datei des Clusters:

/etc/drovio-server/cluster.xml

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

Sie müssen den Inhalt des Tags <network></network> ändern, die übrigen Tags dürfen nicht angetastet werden. Danach stehen Ihnen mehrere Möglichkeiten offen, damit sich Ihre Instanzen gegenseitig finden.

Multicast muss in Ihrem Netz aktiviert sein, damit das funktioniert.

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

Tragen Sie die statischen IPs der anderen Mitglieder ein und achten Sie darauf, Multicast zu deaktivieren.

<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>

Alle diese Tags sind optional. Ohne access-key und secret-key wird die IAM-Rolle verwendet, was empfohlen ist, und dasselbe gilt für iam-role. region lautet standardmäßig us-east-1, und host-header lautet ec2.amazonaws.com, wobei region in diesem Fall nicht gesetzt sein darf. security-group-name sowie das Paar tag-key und tag-value schränken die Discovery schließlich auf die entsprechenden Instanzen ein.

Am einfachsten beginnen Sie mit der AWS-EC2-Discovery so:

  • Erstellen Sie eine IAM-Rolle mit der Berechtigung ec2:DescribeInstances.
  • Weisen Sie sie jeder Instanz zu.
  • Verwenden Sie nur region, tag-key und tag-value.

Weiterführend: README von hazelcast-aws.

Wenn die Maschinen über mehrere Netzwerkschnittstellen verfügen, etwa bei einem VPN, können Sie Hazelcast mit dem Tag <interface></interface> mitteilen, welche zu verwenden ist:

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

Die angegebene Adresse ist die, die Ihrer Netzwerkschnittstelle zugeordnet ist. Weiterführend: Hazelcast, Discovery-Mechanismen.

Den Cluster starten

Starten Sie jede Instanz einzeln nacheinander. Beobachten Sie die Logs und warten Sie auf einen Eintrag wie den folgenden, bevor Sie die nächste starten, in der Regel rund zehn Sekunden zwischen den Starts:

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
}

Den Cluster aktualisieren

Wenn Sie Drovio Server aktualisieren müssen, gehen Sie Instanz für Instanz vor, um jede Unterbrechung zu vermeiden und die zwischen den Instanzen geteilten Daten nicht zu verlieren. Stoppen Sie die Instanz von Hand, sehen Sie in den Logs der anderen Instanz nach und warten Sie auf einen Eintrag dieser Art, bevor Sie die Aktualisierung starten:

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

Adressumschaltung (nur Linux)

Ihr Cluster läuft, doch die Instanzen haben unterschiedliche IP-Adressen. Sie werden eine einfache Adressumschaltung einrichten wollen, damit eine einzige IP mal die eine, mal die andere Instanz bezeichnet. Unter Linux eignet sich keepalived dafür gut.

Das Prinzip ist recht einfach:

  • Für zwei Instanzen verfügen Sie über drei IP-Adressen, von denen eine von beiden Instanzen geteilt wird.
  • Sie bestimmen die Master-Instanz und die Backup-Instanz.
  • Die geteilte IP, zum Beispiel 10.0.12.16, bezeichnet die Master-Instanz, zum Beispiel 10.0.12.17.
  • Fällt die Master-Instanz aus, bezeichnet die geteilte IP fortan die Backup-Instanz, zum Beispiel 10.0.12.18.

keepalived muss auf allen Ihren Drovio-Instanzen bereitgestellt sein, damit das funktioniert.

Die Adressumschaltung ist die schnellste Lösung, wenn Sie die Verfügbarkeit des Dienstes sicherstellen wollen. Ist das Clustering aktiviert, verteilt Drovio Server intern bereits einen guten Teil der Operationen. Die HTTP-Anfragen landen jedoch stets auf derselben Instanz, und auch die WebSocket-Verbindungen, die Drovio Server mit den aktiven Clients unterhält, werden von derselben Instanz getragen. Sie werden die Last daher vermutlich über die gesamte Installation verteilen wollen, sobald Last und Benutzerzahl wachsen.

Lastverteilung (nur Linux)

Die Lastverteilung erreichen Sie mit HAProxy oder Nginx (Plus). Drovio Server ist eine HTTP- und WebSocket-Anwendung. Sie brauchen mindestens eine zusätzliche Maschine, auf der Sie HAProxy oder Nginx bereitstellen.

Warning

In diesem Szenario fällt der gesamte Dienst mit der Maschine für die Lastverteilung aus, wenn diese ausfällt. Sie werden vermutlich mindestens zwei zusätzliche Maschinen bereitstellen und sie mit einem Umschaltverfahren wie dem oben beschriebenen kombinieren wollen, zum Beispiel HAProxy und keepalived.

AWS Elastic Load Balancing

Wenn die Instanzen von Drovio Server auf Amazon AWS bereitgestellt sind, können Sie mit AWS ELB schnell einen Load Balancer aufsetzen. Umschaltung, Lastverteilung, WebSockets: alles wird unterstützt und erfordert nur wenige Klicks. Sehen Sie in der AWS-Dokumentation nach, Application Load Balancer.

Verbindungen drainieren

Wenn Sie eine Instanz zur Wartung stoppen müssen, nehmen Sie sie vorübergehend aus der Zielgruppe heraus und warten Sie das Ende des Drainings ab, bevor Sie sie tatsächlich stoppen. Andernfalls liefert der ELB etwa eine Minute lang HTTP-502-Antworten aus, da die dauerhafte Verbindung zur gestoppten Instanz unterbrochen ist.

Multivalue Answer von AWS Route 53

Wenn Ihr Domainname von AWS Route 53 verwaltet wird, ist die Routing-Policy Multivalue Answer eine weitere Lösung. In Verbindung mit Health Checks antwortet das DNS auf die Anfragen reihum mit der IP der einen oder der anderen noch stehenden Instanz, bis zu acht. Siehe Multivalue- und Simple-Policies.

Note

Die Verbindung zwischen einem Drovio-Client und dem Cluster braucht länger, um sich wiederherzustellen, als bei der ELB-Methode, rund fünf Sekunden beim ELB gegenüber dreißig Sekunden bis einer Minute bei der Multivalue Answer. Während der Umschaltung werden die laufenden Sitzungen mit Bildschirmfreigabe dank der Peer-to-Peer-Architektur von Drovio jedoch nicht unterbrochen.