Differences

This shows you the differences between two versions of the page.

--- univention:rejoining_a_node [2024/04/23 14:33]
47.76.99.127 old revision restored (2023/06/24 06:37)
+++ univention:rejoining_a_node [2024/05/09 09:15] (current)
3.144.238.20 old revision restored (2024/04/27 04:15)
@@ Line 1: / Line 1: @@
-====== Rejoining an active node to the UCS cluster ======
+====== Rejoining a node to the UCS cluster ======
 The replication of a replica/slave happens initially during the joining
@@ Line 6: / Line 6: @@
 Afterwards all further changes are sent using the Notifier/Listener mechanism. A previously installed system can rejoin the cluster. During a rejoin all installed components would be reinstalled using the "Join Scripts".
-Therefore it would, generally, be a good idea to ensure that the system to rejoin the cluster can no longer accept any client connections. Due to the fact that certain services could restart during the process it is best to block all connections until the rejoin is completed.
+Es ist somit einleuchtend, dass ein produktives System während des
+erneuten Systembeitritts nicht sinnvoll genutzt werden kann und man gut
-Rejoining a node takes quite a few hours. How long depends on how large the LDAP instance is. That being said, it is usually best in situations such as this to make use of "screen" to ensure that a lose of connection is not an issue. You will also want to keep an eye on the join log (tail -f /var/log/univention/join.log) as well as the current processes using either top or pstree (watch "pstree | tail -20").
+beraten ist, dafür zu sorgen, dass jeglicher Zugriff durch die Nutzer
+unterbunden wird. Meine Präferenz wäre, das betroffene System auf einem
+vorgeschalteten Loadbalancer zu deaktivieren. Das hat auch den Vorteil,
+dass man nach Abschluß der Arbeiten gezielte Funktionstests durchführen
+kann. Die von mir in der Vergangenheit genutzte Methode, die auf dem
+Loadbalancer konfigurierten Backendchecks, die bei Nichterreichbarkeit
+eines Dienstes auf die verbleibenden Server verteilen ist nicht ganz so
+günstig. Man muss sich dann darauf einstellen, dass die manuell
+gestoppten Dienste während der Arbeiten dann doch wieder durch
+eingebaute Automatismen gestartet werden und unbeabsichtigt
+Nutzeraktivitäten auf dem System, dessen Zustand man nicht genau kennt,
+stattfinden.
+Der Zeitbedarf für den Re-Join liegt bei mehreren Stunden, wie lange
+genau, hängt von mehreren Faktoren ab zu denen nicht nur die Größe der
+LDAP-Datenbank, sondern auch aktuelle Softwareeinstellungen sowie die
+Leistungsfähigkeit des Systems bzw. eben auch die der
+Virtualisierungsplattform gehören. Bei den letzten Re-Joins haben wir
+etwa 3 Stunden gebraucht, auf meinem Testsystem, welches zwar nur 10000
+Nutzer hat, sich aber wesentlich mehr Ressourcen mit anderen VMs teilen
+muss, waren es gestern 4,5 Stunden.
+Sicherheitshalber möchte ich an dieser Stelle darauf hinweisen, dass man
+einen Prozess mit dieser Laufzeit über ssh (univention-join) nur
+startet, wenn man z.B. mit "screen" dafür sorgt, dass ein
+Verbindungsabbruch keine Auswirkungen hat. "univention-join" wird
+während der Arbeit über Minuten oder vielleicht Stunden keine weiteren
+Ausgaben zeigen. Ich nehme dann immer weitere screen-Konsolen und lasse
+/var/log/univention/join.log mitlaufen und schaue z.B. mit "pstree"
+(watch "pstree | tail -20"), was konkret passiert.
 Für beimx-000087-016 gibt es noch einige Besonderheiten. Dieses System

Chucks notes and stuff

User Tools

Site Tools

Differences

Page Tools