Grundlegendes zu den logischen Clustern in einem Junos Space-Cluster

Apache Load-Balancer-Cluster

Der Apache HTTP-Server mit aktivierter mod_proxy Load-Balancer-Modul läuft jederzeit auf zwei Knoten im Cluster. Diese Server bilden einen aktiv-standby-logischen Cluster. Beide lauschen am TCP-Port 443 auf HTTP-Anforderungen von GUI und NBI-Clients. Alle Clients verwenden die virtuelle IP-Adresse (VIP) des Clusters, um auf seine Services zuzugreifen. Die VIP-Adresse gehört zu jeder Zeit nur einem Knoten im Cluster. Daher empfängt der Apache HTTP-Server auf dem Knoten, dem die VIP-Adresse gehört, alle HTTP-Anfragen von GUI- und NBI-Clients und fungiert als aktiver Load-Balancer-Server, während der andere Server als Standby fungiert. Ein Round-Robin-Load-Balancing-Algorithmus wird verwendet, um Anforderungen an JBoss-Server zu verteilen, die auf allen Knoten im Cluster ausgeführt werden. Der Load-Balancer verwendet außerdem Sitzungs-Stickiness, um sicherzustellen, dass alle HTTP-Anfragen von einer Benutzersitzung an den gleichen Knoten im Cluster gesendet werden. Um dies zu erreichen, setzt der Server ein Cookie mit dem Namen JSESSIONID. Der Wert dieses Cookies identifiziert den spezifischen Knoten im Cluster, der Anfragen bedient, die zu dieser Benutzersitzung gehören. Alle zusätzlichen Anforderungen enthalten diesen Cookie und der Load-Balancer leitet die Anfrage an den JBoss-Server weiter, der auf dem Knoten läuft, den dieser Cookie identifiziert.

Wenn der Apache HTTP-Server auf einem Knoten ausfällt, wird der Server automatisch vom Watchdog-Service auf diesem Knoten neu gestartet. Wenn dieser Knoten die VIP-Adresse besitzt, kann es auf der GUI und den NBI-Clients zu einem kurzen Serviceausfall kommen, bis der Apache HTTP-Server neu gestartet wird. Dieser Ausfall dauert jedoch nur wenige Sekunden (in der Regel zwei Sekunden) und wird von den Clients kaum bemerkt. Auf der anderen Seite, wenn der Apache HTTP-Server auf den Knoten ausfällt, der derzeit nicht die VIP-Adresse besitzt, werden keine Nebenwirkungen von irgendwelchen Clients oder anderen Komponenten bemerkt. Der Watchdog-Dienst startet den Server neu und der Server wird in etwa zwei Sekunden wieder hochgefahren.

JBoss-Cluster

Der JBoss-Anwendungsserver läuft auf allen Knoten außer dedizierten Datenbankknoten im Junos Space-Cluster. Die Knoten bilden einen einzigen, vollaktiven logischen Cluster, und der Load-Balancer-Server (oben beschrieben) verteilt die Last auf alle Knoten. Selbst wenn einer oder mehrere der JBoss-Server im Cluster ausfällt, ist die Anwendungslogik weiterhin von den überlebenden Knoten aus zugänglich. JBoss-Server auf allen Knoten werden mit derselben Konfiguration gestartet und verwenden UDP-Multicast, um sich gegenseitig zu erkennen und einen einzigen Cluster zu bilden. JBoss verwendet auch UDP-Multicast für Sitzungsreplikations- und Caching-Services auf allen Knoten.

Wenn der JBoss-Server auf einem Knoten ausfällt, erkennen andere Knoten im JBoss-Cluster diese Änderung und konfigurieren sich automatisch neu, um den ausgefallenen Knoten aus dem Cluster zu entfernen. Die Zeit, die andere Clustermitglieder benötigen, um einen ausgefallenen JBoss-Server zu erkennen, hängt davon ab, ob der JBoss-Serverprozess abnormal abstürzte oder nicht reagiert. Im ersten Fall erkennen Cluster-Mitglieder den Fehler sofort (etwa zwei Sekunden), da ihre TCP-Verbindungen zum abgestürzten JBoss-Server vom Betriebssystem geschlossen werden. In letzterem Fall erkennen Cluster-Mitglieder den Fehler in etwa 52 Sekunden. Wenn ein JBoss-Server abstürzt, wird der JBoss-Server automatisch durch den Watchdog-Service (jmp-watchdog) neu gestartet, der auf dem Knoten ausgeführt wird. Wenn der JBoss-Server wieder aktiviert wird, wird der JBoss-Server automatisch von anderen Cluster-Mitgliedern erkannt und dem Cluster hinzugefügt. Der JBoss-Server synchronisiert dann seinen Cache von den anderen Knoten im Cluster. Die typische Neustartzeit für den JBoss-Server beträgt zwei bis fünf Minuten, kann jedoch mehr Zeit in Anspruch nehmen, abhängig von der Anzahl der installierten Anwendungen, der Anzahl der verwalteten Geräte, der Anzahl der installierten DMI-Schemaversionen usw.

Ein JBoss-Server im Cluster fungiert immer als Primärer des Clusters. Der Hauptzweck der primären Bezeichnung besteht darin, Services zu hosten, die als clusterweite Singletons (HA-Singletons) bereitgestellt werden, z. B. Services, die jederzeit nur auf einem Server im Cluster bereitgestellt werden müssen. Junos Space verwendet mehrere Services dieses Typs, einschließlich des Job Poller-Service, der einen einzigen Timer für die Planung von Aufträgen im gesamten Cluster bereitstellt, und den Distributed Resource Manager (DRM)-Service, der die Knoten im Cluster überwacht und verwaltet. Diese Services werden nur auf dem JBoss-Server bereitgestellt, der als primärer Server festgelegt ist.

MySQL-Cluster

Der MySQL-Server läuft jederzeit auf zwei Knoten im Junos Space-Cluster. Diese Knoten bilden einen logischen Aktiv-Standby-Cluster und beide Knoten lauschen auf TCP-Port 3306 auf Datenbankanfragen von JBoss-Servern. Standardmäßig sind JBoss-Server so konfiguriert, dass sie die virtuelle IP-Adresse (VIP) des Clusters für den Zugriff auf Datenbankservices verwenden. Die VIP-Adresse gehört zu jeder Zeit nur einem Knoten im Cluster. So empfängt der MySQL-Server auf dem Knoten, dem die VIP-Adresse gehört, alle Datenbankanfragen vom JBoss-Server, der als aktiver Datenbankserver fungiert, während der andere Server als Standby fungiert.

Wenn Sie die Leistung der Junos Space Network Management-Plattform und der Junos Space-Anwendungen verbessern möchten, können Sie zwei Junos Space-Knoten hinzufügen, die als dedizierte Datenbankknoten ausgeführt werden. Wenn Sie beliebige zwei Junos Space-Knoten als primären und sekundären Datenbankknoten hinzufügen, wird der MySQL-Server auf die beiden dedizierten Datenbankknoten verschoben und auf den ersten beiden Knoten des Junos Space-Clusters deaktiviert. Dadurch werden Systemressourcen auf dem aktiven VIP-Knoten Junos Space frei und die Leistung des Knotens verbessert.

JBoss-Server verwenden eine separate virtuelle Datenbank-IP-Adresse (VIP), um auf Datenbankservices auf dedizierten Datenbankknoten zuzugreifen. Sie geben die VIP-Adresse für die Datenbank an, wenn Sie Knoten als dedizierte Datenbankknoten zum Junos Space-Cluster hinzufügen. Diese VIP-Adresse gehört dem Knoten, der für den primären Datenbankknoten bestimmt ist. Der MySQL-Server auf dem primären Datenbankknoten fungiert als aktiver Datenbankserver, und der Server auf dem sekundären Datenbankknoten fungiert als Standby. Abbildung 2 zeigt die logischen Cluster (Apache Load Balancer-Cluster, JBoss-Cluster und MySQL-Cluster), die in einem Junos Space-Cluster gebildet werden, wenn Sie dedizierte Datenbankknoten als Teil des Junos Space-Clusters haben.

Abbildung 2: Logische Cluster von Junos Space mit dedizierten Datenbankknoten

MySQL-Server auf jedem Knoten sind mit individuellen Server-IDs konfiguriert. Die Primär-Backup-Beziehung wird auch symmetrisch auf den Knoten konfiguriert, sodass der Server auf dem ersten Knoten mit dem zweiten Knoten als primärem konfiguriert wird. und der Server auf dem zweiten Knoten wird mit dem ersten Knoten als Primärknoten konfiguriert. So können beide Knoten als Backup für den anderen fungieren, und der Server auf dem Knoten, der die VIP-Adresse besitzt, fungiert jederzeit als Primärer, wodurch sichergestellt wird, dass die Primär-Backup-Beziehung dynamisch als VIP-Eigentümer-Switches von einem Knoten zum anderen wechselt. Alle transaktionen, die auf dem aktiven (primären) Server vorgenommen werden, werden mithilfe der asynchronen Replikationslösung [2] von MySQL, die auf dem binären Protokollierungsmechanismus basiert, nahezu in Echtzeit auf den Standby (Backup)-Server repliziert. Der MySQL-Server, der als primärer Server (die Quelle der Datenbankänderungen) arbeitet, schreibt Updates und Änderungen als "Ereignisse" in das Binärprotokoll. Die Informationen im Binärprotokoll werden je nach den aufgezeichneten Datenbankänderungen in verschiedenen Protokollierungsformaten gespeichert. Der Backup-Server ist so konfiguriert, dass er das Binärprotokoll aus dem primären protokoll liest und alle Ereignisse im Binärprotokoll in der lokalen Datenbank des Backups ausführt.

Wenn der MySQL-Server auf einem Knoten ausfällt, wird der Server automatisch vom Watchdog-Service auf diesem Knoten neu gestartet. Beim Neustart sollte der MySQL-Server innerhalb von 20 bis 60 Sekunden hochgefahren werden. Wenn dieser Knoten die VIP-Adresse besitzt, kann es bei JBoss für diese Dauer von 20 bis 60 Sekunden zu einem kurzen Datenbankausfall kommen. Alle Anforderungen, die Datenbankzugriff erfordern, schlagen in diesem Zeitraum fehl. Auf der anderen Seite, wenn der MySQL-Server auf den Knoten ausfällt, der derzeit nicht die VIP-Adresse besitzt, werden JBoss keine Nebenwirkungen bemerkt. Der Watchdog-Dienst startet den Server neu und der Server wird in weniger als einer Minute wieder hochgefahren. Nachdem der Server wieder aktiv ist, wird er mit dem primären im Hintergrund synchronisiert, und die Zeit für die Neusynchronisierung hängt von der Anzahl der Änderungen ab, die während des Ausfalls vorgenommen wurden.

Cassandra-Cluster

Ab Version 15.2R2 ist der Cassandra-Cluster ein optionaler logischer Cluster, den Sie in den Junos Space-Cluster aufnehmen können. Der Cassandra-Cluster entsteht, wenn innerhalb der Junos Space-Fabric zwei oder mehr dedizierte Cassandra-Knoten oder zwei oder mehr JBoss-Knoten mit dem Cassandra-Service oder einer Kombination aus beiden vorhanden sind. Sie können den Cassandra-Service auf keinem oder auf allen Knoten in der Fabric ausführen, außer auf dedizierten Datenbankknoten und FMPM-Knoten. Der Cassandra-Service, der auf Junos Space-Knoten ausgeführt wird, bietet ein verteiltes Dateisystem zum Speichern von Geräteimages und -Dateien von Junos Space-Anwendungen (z. B. Juniper Message Bundle [JMB], generiert von Service Now und RRD-Dateien, die von Network Director generiert werden). Wenn sich keine Cassandra-Knoten in der Fabric befinden, werden Imagedateien der Geräte und Junos Space-Anwendungsdateien in der MySQL-Datenbank gespeichert. Abbildung 3 zeigt die logischen Cluster (Apache Load Balancer-Cluster, JBoss-Cluster, MySQL-Cluster und Cassandra-Cluster), die in einem Junos Space-Cluster gebildet werden, wenn Sie Cassandra-Knoten als Teil des Junos Space-Clusters haben.

Abbildung 3: Logische Cluster von Junos Space einschließlich des Cassandra-Clusters

Der Cassandra-Service wird auf allen Cassandra-Knoten in einer Aktiv-Aktiv-Konfiguration mit Echtzeitreplikation der Cassandra-Datenbank ausgeführt. Alle in die Cassandra-Datenbank hochgeladenen Dateien werden auf alle Knoten im Cassandra-Cluster kopiert. JBoss-Server senden Anfragen an die Cassandra-Knoten im Cassandra-Cluster im Round-Robin-Modus und greifen über die IP-Adresse (der eth0-Schnittstelle) des jeweiligen Cassandra-Knotens auf die Knoten zu.

Wenn ein Cassandra-Knoten ausfällt, kann die Junos Space-Plattform keine Dateien in die Cassandra-Datenbank hochladen oder dateien aus der Cassandra-Datenbank löschen, bis der knoten, der aus der Fabric entfernt ist. Wenn alle vorhandenen Cassandra-Knoten gelöscht werden, gehen die in der Cassandra-Datenbank gespeicherten Dateien verloren.