Vorläufige Stabilität trotz Zwangstrennungen
Der Trick, die Interfaces nicht mehr zu löschen, scheint erfolgreich zu sein. Es herrscht eine befremdliche Stabilität.
Das sind insgesamt 16 L2TP-Tunnel zu zwei verschiedenen geographischen Zuführungen.
Man sieht schön wie
- jede Nacht die Kunden der (nicht existierenden) Zwangstrennung zuvorkommen wollen.
- die Kunden bei der Wahl des Trennungszeitpunkts ein 10min Raster bevorzugen.
- gleichverteilt die Sessions auf den LNS landen.
- örtliche Ausfälle sich auch nur geographisch auswirken auswirken.
- das System stabil durchläuft.
Hurra.
Manische Trennungen
Insbesondere die vorgezogene Zwangstrennung ist ein stetiger Quell wiederkehrender Lasttests für die Plattform. Es ist so ähnlich wie der Witz mit den synchron springenden Chinesen, nur das das so erzeugte Erdbeben die gesamte Anbindung der "springenden Kunden" selbst betrifft. Sie trennen sich sozusagen selbst aus dem Netz: In doppelter Hinsicht.
Eine Zwangstrennung ist trotzdem für einen Teil der Kunden vorhanden: Wer dynamische, öffentliche IP(v4) gebucht haben, bekommen zwangsweise in mehr oder weniger regelmäßigen Abständen eine neue Adresse. Dazu werden die Verbindungen bei Bedarf nachts getrennt. Wer öffentliche, statische Adressen oder NAT-Adressen hat, kann seine Verbindung stehen lassen, solange er will.
Was man nicht sieht, ist eine interessante Clusterbildung. Da die LACs die neuen Sessions bevorzugt an die LNS zuteilen, die die wenigsten Sessions haben, sammeln sich zeitliche Haufen an den LNS. Einer hat die ganzen Kunden, die bevorzugt um 2:00 trennen, denn er bekommt die Leute, die um die Zeit rausfliegen (egal wo), gleich wieder zugeteilt. Das geht so weiter bis der letzte Server die Kunden abfängt, die kurz vor 6:00 die "Zwangstrennung vorziehen".
Diese Korrelation zwischen Server und Zeit ist selbstverstärkend. Dies bedeutet insbesondere, daß Kunden fast immer auf dem gleichen LNS landen und so langfristig an den LNS gebunden sind. Anderseits heißt es aber auch, daß sich die Trennungslast auf eine Maschine konzentriert, der Lasttest also besonders schlimm ausfällt. Die bedingt dann eine erhöhte Ausfallwahrscheinlichkeit durch Raceconditions auf dem aktuelle betroffenen Server.
Partielle Stabilität
Die Tatsache, daß sich eine stabile Kunden-LNS-Beziehung entwickelt, hat für das Ausrollen von Software-Änderungen eine entscheidende Bedeutung.
Nur wenige Kunden weichen von der Norm(alität) so ab, daß Sonderanpassungen notwendig sind. Rollt man also eine entsprechende neue Software erstmal nur auf einem LNS aus, so besagt auch eine sehr lange Laufzeit der Gesamtplattform nichts über die Funktionstüchtigkeit der neusten Änderungen. Es ist vielmehr wahrscheinlich, daß diese Software gar nicht mit dem Problem in Berührung kommt.
Das erklärt, warum die Plattform aktuell stabil läuft, obwohl erst ein LNS die aktuelleste Software benutzt: Er hat die Problemfälle nach seinem Wiederanlaufen eingefangen und behält sie. Deswegen muß die Software nach und nach auf die anderen Server ausgerollt werden.
Dieses Ausrollen gestaltet sich gar nicht so einfach. Zum Wechsel der Software müßte der entsprechende MPD-Daemon neu gestartet werden. Er darf zu diesem Zeitpunkt aber keine Sessions mehr haben, um ein spontanten Verbindungsverlust der Kunden zu vermeiden. Man müßte also die Annahme von neuen Verbindungen verweigern und auf eine rege Beteiligung an der "vorgezogenen Zwangstrennung" hoffen. Glücklicherweise ist genau das aber schon implementiert.
Die einfangs gezeigte Kurve wird es also auf lange Sicht nicht mehr geben. Regelmäßig werden Updates, kleine Verbesserungen oder Anpassungen an neue Anforderungen ausgerollt werden. Und das immer schrittweise. Vermutlich werden öfters keine zwei LNS den gleichen Softwarestand haben.
So und jetzt geht der Server mit der ältesten Software in den Update-Zyklus.
int PhysIsBusy(Link l) {
return (l->die || l->rep || l->state != PHYS_STATE_DOWN ||
l->lcp.fsm.state != ST_INITIAL || l->lcp.auth.acct_msg != NULL ||
(l->tmpl && (l->children >= l->conf.max_children ||
gChildren >= gMaxChildren)));
}Man kann also einfach die globale Anzahl der Kinder herabsetzen, radikal. Denn schon von Anfang an hatte ich dem MPD beigebracht, sich nach dem Verlust der letzten Sitzung zu beenden.
[] show global Global settings: ... max-children : 0 Global options: ... delayed-one-shot enable
Danach startet der Wrapper instantan die neue Version.
Allerdings gibt es Situationen, wo auch die Kontrollverbindungen in der Last dann untergehen (auf den "Evil Overload" habe ich verlinkt, "L2TP Timeout" kann man in der Blog Suche eingeben), was dann wie beim Domino der Reihe nach immer weitere L2TP Tunnel mit (wie zu sehen) knapp 1000 Kunden mit einem Schlag aus dem Netz kegelt.
Natürlich kommt das alles wieder. Unschön ist es trotzdem.
Und ja, das ist hervorragend synchronisiert (dank NTP). Die vier deutlichsten Spikes sind ja selbst in dem Sammelgraphen gut zu erkennen. Das entspricht jeweils einer Stromabschaltung einer ganzen Gruppe von Ortschaften.
Zu diesem habe ich dann doch mal eine Frage, vielleicht ist sie auch meiner naiven Laiensicht geschuldet: Ich verstehe nicht ganz, wieso die (unnötigen) Zwangstrennungs-Vorbeuger ein Problem sind. So wie ich das sehe, sind die Zeitpunkte der selbst initiierten Pseudo-Zwangstrennung zwar nicht über den Tag gleichmäßig verteilt, sondern konzentrieren sich auf ein paar Stunden, sind aber doch so gestreut, dass es eigentlich kein Problem geben sollte, da meiner Meinung nach das System viel "schlimmere" Szenarien aushalten können sollte.
Was ist z. B., wenn es einen großräumigen Stromausfall gibt und ein paar Hundert bis Tausend Kunden gleichzeitig wieder Strom bekommen und ihre Verbindung praktisch zeitgleich wieder aufbauen? Das müsste die Installation vielleicht nicht problemlos wegstecken, aber zumindest doch sauber abarbeiten. Oder sind die Pseudo-Zwangstrennungen in ihrer Masse vielleicht doch so regelmäßig, dass damit jede Nacht quasi durch Unwissenheit (unterstützt durch synchronisierte Uhren und viele Cronjob-Reconnect-Events zur "vollen Stunde") Pseudo-Stromausfälle mittlerer Größenordnung "simuliert" werden?
4 Kommentare