Wir haben Normalität erreicht
Wir haben Normalität erreicht, ich wiederhole, wir haben Normalität erreicht. Alles, womit Sie jetzt noch immer nicht fertig werden, ist folglich Ihr Problem. (Audio) Der Ausfall eines Radius-Servers zeigte, daß der MPD auch nur ein Gewohnheitstier ist und sich dann völlig falsch verhält.
Die MPD Plattform läuft inzwischen wirklich stabil durch. Davon hatte ich ja bereits berichtet. Letzte Woche trat aber ein Vorfall ein, dessen Analyse ein ungewöhnliches Verhalten des Systems zu Tage förderte.
Die PPP Plattform macht ihre Authentisierung und ihr Reporting gegen zwei Radius-Server, die mit identischen Kopien des Datenbstandes jeder für sich autonom laufen. Dies soll sicherstellen, daß die Plattform immer einen korrekt funktionierenden Server vorfindet.
Die Redundanz
Dazu finden sich in jeder L2TP Konfiguration auch die beiden Server. Pro Tunnel sind also beide Radius-Server benutzbar. Allerdings werden die Radius-Server abwechselnd genannt, weil der MPD diese in der Reihenfolge der Nennung bevorzugt benutzt.
Dies ergibt eine Lastverteilung. Und es funktioniert auch wie vorgesehen:
[s7-jen-1] sh radius Configuration: Timeout : 5 Retries : 3 Config-file : none Me (NAS-IP) : 172.27.44.20 v6Me (NAS-IP): UNSPEC Identifier : server7 --------------- Radius Server 1 --------------- hostname : 172.27.44.5 secret : ********* auth port : 1812 acct port : 1813 --------------- Radius Server 2 --------------- hostname : 172.27.44.4 secret : ********* auth port : 1812 acct port : 1813
Im Laufe der Zeit bemerkt der MPD, daß einer der Server für ihn stabiler arbeitet. Das fängt mit kleinen Unpäßlichkeiten eines Servers an und schaukelt sich hoch. Jeder MPD lernt so, einen Server zu bevorzugen. Andere Installationen bevorzugen den anderen Radius-Server, weil dieser nun mehr Zeit für diese Anfragen hat.
So ergibt sich – aufgrund der langen Laufzeit der Plattform – eine natürliche Clusterbildung.
Der Ausfall
Eines schönen Tages hat sich ein Radius-Server verschluckt. Der Dienst lief noch, beantwortete aber die Anfragen nicht oder nur sehr spärlich.
Aufgrund der langen und guten Statisitiken hat der MPD, der diesen Radius-Server benutzte, keinen Grund zum Umschalten auf den zweiten Radius-Server gesehen. Er benutzte den defekten Server einfach weiter.
Da er keine Nutzer mehr authentisieren konnte, brachen die Verbindungen über ihn nach und nach ein. Der LAC auf der anderen Seite hatte so nun wenig benutzte L2TP Tunnel, die er bevorzugt bediente: Nämlich die Tunnel zu dem betroffenen MPD (LNS).
Im Ergebnis wurden die Nutzer langsam an die anderen LNS verteilt, obwohl eigentlich der LNS in Ordnung war.
Wie man die Radius-Zuordnung im Fehlerfall schneller umschaltet, ist eine noch zu erforschende Fragestellung.
1 Kommentare