Hendrik Lüth

Probleme mit dem Radius-Server sind eine spaßige Angelegenheit. In den meisten Fällen geht entweder gar nichts und das Icinga bewirft einen mit Mails oder es geht gar nichts und die User tun es für einen. (Wozu habe ich noch ein Monitoring-System?) In diesem Fall habe ich es ausnahmsweise selbst gemerkt. Ich komme ins Büro, klappe das Laptop auf und fange an zu arbeiten. Kein WLAN. Erstmal den Admin anrufen… Oh, warte. Da war ja was.

Das Problem, welches sich mir auftat war, dass mein Laptop zu lange brauchte um sich zu verbinden. Dank i3status konnte ich sehen, dass es wirklich am Radius-Server liegen musste. Als ich dann endlich eine Verbindung zum WLAN bekam, hatte ich schon über LAN unser AirWave-System aufgerufen. Wir haben da eine schöne Funktion namens „Clarity„. Die tut nichts anderes als Daten über die sämtliche Laufzeiten von Anmeldungen zu sammeln. Leider habe ich bisher nie wirklich auf die Graphen geschaut. Ich habe immer den Durchschnittswert von 8,245ms gesehen und dachte: „Jo, das passt.„ – hätte ich nicht denken sollen. Was mir an diesem tag erst auffiel ist, dass unser Hersteller Aruba ja aus den USA kommt und dort drüben bei Zahlen ein Punkt ein Komma und ein Komma ein Punkt ist. Anscheinend ist die durchschnittliche Anmeldezeit über 8 Sekunden. Mist. Dann mal den Graph anschauen. Auch nicht besser. Ja, der Durchschnitt liegt bei acht Sekunden, allerdings ist es Nachts deutlich niedriger und, wieso sollte Netzwerk auch so einfach sein, tagsüber bei mindesten 10-15, in Spitzen sogar 30-40 Sekunden. Ich habe sogar einen Peak mit 60 Sekunden entdecken können. Das erklärt dann auch, warum das Anmelden so lange dauerte.

Wir haben schon seit ein oder zwei Monaten den Plan, dass wir die aktuellen Radius-Server abschalten und durch neue Instanzen mit FreeRadius ersetzen. Leider dauert die Umsetzung noch etwas, da wir ein neues VLAN-Assignement Konzept umsetzen wollen. Dazu in einem anderen Blogeintrag mehr.

Nächste Station in der Kette des Debuggings war meine Chefin, welche auch die Radius-Server administriert. Wir haben zwei Radius-VMs mit 8 CPU Kernen, pro Kern haben wir eine Radiator-Instanz laufen, da dieses Perl-Script natürlich singlethreaded und nicht sehr effizient ist. Wie bei Turnschuhen ist Rot auch bei Servern eher uncool. Zumindest, wenn die CPU-Auslastung im roten Bereich hängt. Die Server glänzten mit einem Load-Average von 3.35 und einer CPU-Auslastung bei knapp 80-90 Prozent. Das machte dann klar, wo wohl der Fehler liegt. Was macht man in so einem Fall? Die neuen Server sind noch nicht fertig, also werfen wir einfach so lange Hardware auf das Problem, bis es funktioniert. Wie bei Java-Software halt. Nach Rücksprache mit unserem VM-Team haben wir dann leider erfahren, dass wir keine Hardware mehr auf die VMs werfen können, weil die Hosts auch nur 8 Kerne haben. Mist. Auch das Deployen von weiteren Servern war leider nicht möglich, da wir Zertifikate bräuchten, die Radius-Server noch nicht im Ansible waren und wir auch erst bei einer anderen Abteilung neue Keys und Zugänge für das Active Directory hätten beantragen müssen.

Bild: Die durchschnittliche Antwortzeiten des Radius-Servers zur Prüfungszeit (wenig Last).

Unsere Lösung war dann, dass wir anstatt einem vier Threads pro CPU-Core haben laufen lassen. Es hat zwar die Antwortzeiten nur halbiert, aber immerhin, die Situation hat sich verbessert. Aktuell ist es sogar ganz annehmbar, da aber wir haben auch Prüfungszeit, da ist ja eh nicht so viel los, Problem gelöst.