Verständnis von Hochverfügbarkeitsknoten in einem Cluster
Ein Junos Space-Cluster muss mindestens zwei Knoten umfassen, um hohe Verfügbarkeit (HA) zu erreichen. Wenn der Cluster mehr als zwei Knoten umfasst, steigt die Verfügbarkeit des Clusters nicht, aber die Last, die der Cluster bewältigen kann, steigt mit jedem Knoten, der dem Cluster hinzugefügt wird. Daher stellen zu jeder Zeit nur zwei Knoten im Cluster für den gesamten Cluster ha zur Verfügung. Standardmäßig bilden diese beiden Knoten allein (im Cluster als Hochverfügbarkeitsknoten bezeichnet) den Linux HA-Cluster, den Apache Load Balancer-Cluster und den MySQL-Cluster. Wenn Sie dem Cluster dedizierte Datenbankknoten hinzugefügt haben, wird der MySQL-Cluster aus den primären und sekundären Datenbankknoten gebildet.
Standardmäßig fungieren die ersten beiden Knoten, die dem Cluster hinzugefügt wurden, als Hochverfügbarkeitsknoten. Im Thema Verstehen der logischen Cluster in einem Junos Space-Cluster zeigt das Beispiel, dass es sich bei den ersten beiden Knoten (Node-1 und Node-2) um Hochverfügbarkeitsknoten handelt. Wenn Sie Node-1 oder Node-2 aus der Netzwerkmanagementplattform > Administration > Fabric-Arbeitsbereich löschen möchten, prüft das System, ob andere Knoten im Cluster verfügbar sind, um den gelöschten Ha-Knoten zu ersetzen. Das System zeigt dann die Liste der fähigen Knoten an (nur Node-3 im Beispiel), die Sie auswählen können. Nachdem Sie den ausgewählten Knoten bestätigt haben, fügt der DrM-Dienst (Distributed Resource Manager) den Knoten dem Cluster mit hoher Verfügbarkeit hinzu, indem Er Anforderungen an den Node Management Agent (NMA) sendet, der auf dem neu ausgewählten Knoten ausgeführt wird. Die folgenden Aktionen werden auf dem Knoten eingeleitet, der dem Cluster mit hoher Verfügbarkeit hinzugefügt wurde:
Der Apache HTTP-Server mit dem mod_proxy Load Balancer wird auf dem Knoten gestartet und der Knoten wird mit allen JBoss-Knoten als Member konfiguriert.
Wenn sich keine dedizierten Datenbankknoten im Cluster befinden, wird die Datenbank vom MySQL-Server auf dem anderen Ha-Knoten im Cluster kopiert und der MySQL-Server auf dem Knoten gestartet. Dieser Server wird als Backup des anderen MySQL-Servers im Cluster konfiguriert und resynchronisiert sich mit dem primären im Hintergrund. Der vorhandene MySQL-Server ist ebenfalls so konfiguriert, dass er als Backup dieses neuen Servers fungiert, um eine symmetrische Primär-/Backup-Konfiguration auf beiden zu gewährleisten.
Wenn Sie dem Junos Space-Cluster dedizierte Datenbankknoten hinzufügen, fügen Sie zwei Knoten als primäre und sekundäre Datenbankknoten zusammen, um den MySQL-Cluster zu bilden. Die Datenbank wird vom aktiven Ha-Knoten auf die beiden Datenbankknoten kopiert und auf den Ha-Knoten deaktiviert. Wenn Sie einen der Datenbankknoten aus dem Cluster löschen möchten, wird der andere Datenbankknoten als primärer Datenbankknoten bezeichnet. Das System prüft, ob Nicht-Hochverfügbarkeitsknoten im Cluster verfügbar sind, um den gelöschten Datenbankknoten zu ersetzen, und zeigt die Liste der Knoten an, die Sie zum Ersetzen des gelöschten Knotens auswählen können.
Nachdem Sie einen Knoten ausgewählt haben, fügt der DrM-Service (Distributed Resource Manager) den Knoten dem MySQL-Cluster hinzu, indem er Anfragen an den Node Management Agent (NMA) sendet, der auf dem neu ausgewählten Knoten ausgeführt wird.
Die folgenden Aktionen werden auf dem Knoten eingeleitet, der dem MySQL-Cluster hinzugefügt wurde:
Die Datenbank vom MySQL-Server auf dem primären Datenbankknoten im Cluster wird kopiert und der MySQL-Server wird auf dem neu hinzugefügten sekundären Datenbankknoten gestartet. Dieser Server wird als Backup des MySQL-Servers auf dem primären Datenbankknoten konfiguriert und resynchronisiert sich mit dem primären im Hintergrund. Der vorhandene MySQL-Server auf dem primären Datenbankknoten wird ebenfalls so konfiguriert, dass er als Backup dieses neuen Servers auf dem sekundären Datenbankknoten fungiert, um eine symmetrische Primär-/Backup-Konfiguration auf beiden zu gewährleisten.
Der JBoss-Server wird auf dem neu hinzugefügten Datenbankknoten angehalten.
Wenn Sie einen Cassandra-Cluster als Teil der Junos Space-Fabric haben, werden zusätzlich zu den drei standardmäßigen logischen Clustern auch die auf Cassandra hochgeladenen Dateien auf alle Cassandra-Knoten kopiert, die Teil des Cassandra-Clusters sind. Wenn also ein Cassandra-Knoten ausfällt, gehen die Dateien vom ausgefallenen Knoten nicht verloren. Die Junos Space-Plattform kann jedoch keine Dateien in die Cassandra-Datenbank hochladen oder dateien löschen, bis der ausgefallene Knoten gelöscht wurde.
Wenn der Cassandra-Service auf einem Ha-Knoten aktiviert ist und dieser Knoten ausfällt, und wenn Sie den Cassandra-Dienst auf dem neu hinzugefügten Ha-Knoten ausführen möchten, müssen Sie den Cassandra-Dienst auf dem Knoten manuell aktivieren und starten. Wenn der letzte Knoten mit dem ausgeführten Cassandra-Dienst gelöscht wird, gehen die in der Cassandra-Datenbank gespeicherten Dateien verloren.