Munin: Optimierung der Festplatten-IOs

Munin wird dazu verwendet, Laufzeitwerte über verschiedene Dienste oder Rechner zu sammeln und diese statistisch in Grafiken auf einer eigenen Webseite aufzubereiten. Bei Über- oder Unterschreiten eines Grenzwertes können entsprechende E-Mails versenden. Die gesammelten Daten werden rollierend in RRDs (Robin-Round-Database) festgehalten.

In der Standardkonfiguration wird in den meisten RRDs nur jeweils ein Wert gespeichert. Das ergibt z.B. bei 10 Hosts á 20 zu speichernden Werten 200 RRDs, die von Munin alle 5 Minuten (dem Standard-Abfrageintervall) fast gleichzeitig geschrieben werden. Diese Häufung von IOs, zumal sie nicht gestreckt über den gesamten Zeitraum sondern punktuell auftritt, kann für große Installationen schnell zum Problem werden. Im Folgenden wird eine Methode vorgestellt, wie diese Festplatten-Last um den Faktor 10 gesenkt werden kann.

Munin-Grafiken nur auf Anforderung erstellen

Munin ist unter Debian so voreingestellt, dass per Cron anschließend an das Sammeln der Werte alle HTML- und Grafikdateien neu erstellt werden. Das ist natürlich unnötig, wenn sich niemand die Grafiken anschaut. Eine erste Optimierung ist, diese Dateien erst erstellen zu lassen, wenn die Webseite von Munin angezeigt werden soll. In "/etc/munin/munin.conf" wird dazu eingestellt:

Anschließend muss der jeweilig verwendete Webserver dahingehend angepasst werden, per CGI Anfragen an die entsprechenden Munin-Scripte weiterzuleiten. Eine Anleitung für verschiedene Webserver findet sich im Munin-Wiki.

Eine Konfiguration für Nginx könnte folgendermaßen aussehen:

Zu beachten ist hier, das Munin in diesem Beispiel auf einer eigenen Domain läuft und nicht in einem Unterverzeichnis einer anderen Webseite. Für andere Konfigurationen sind die Pfade bei "location" und "fastcgi_split_path_info" entsprechend dem oben genannten Wiki-Eintrag anzupassen.

Anschließend müssen noch ensprechende CGI-Handler installiert werden. Hier kommt spawn-fcgi zum Einsatz, dessen Konfiguration ebenfalls im obigen Wiki-Eintrag beschrieben ist.

Allein durch diese Anpassung erreicht man schon eine Senkung der Festplatten-IOs um ca. 30%.

Anzumerken zu obigen Beispiel ist noch das Setzen von RRDCACHED_ADDRESS. Diese Einstellung behebt einen Bug in Munin, der beim Einsatz der folgenden Optimierung auftritt.

Cachen des RRD-Schreibens

Ein Tipp brachte mich zum Programm rrdcached, dessen Zweck es ist, Schreibzugriffe auf RRDs zwischenzuspeichern und erst nach einem konfigurierbaren Intervall aggregiert in die RRDs zu schreiben. Es ist die optimale Ergänzung zu Munin, um das andauernde Schreiben aller RRDs im 5-Minuten-Takt zu verhindern. rrdcache kann so eingestellt werden, dass die Daten in viel größeren Intervallen in die RRDs geschrieben werden. Eine konfigurierbare zufällige Verzögerung sorgt dafür, dass nicht alle RRDs gleichzeitig geschrieben werden. Munin 2.0 ist bereits für den Einsatz von rrdcache vorbereitet. In "/etc/munin/munin.conf" muss dazu nur

aktiviert werden.

Leider ist rrdcached in der mit Debian ausgelieferten Version nicht auf Munin angepasst. Da ich hier Debian 8 mit systemd einsetze habe ich mich entschieden, dass mitgelieferte Init-Skript nicht zu verwenden, sondern das von Munin bereitgestellte Unit-File für systemd einzusetzen. Dort sind schon alle Anpassungen für Munin unter Debian enthalten.

Als erstes stoppt man den nach der Installation bereits laufenden rrdcached, erstellt anschließend in "/etc/systemd/system/rrdcached.service" das entsprechende Unit-File und startet rrdcache mit systemd.

Ab jetzt sollte Munin die Daten bei rrdcache abliefern und rrdcached diese erst in den voreingestellten Intervallen in die RRDs schreiben.

Ergebnis

Munin vda-day nach Optimierung

Im linken Teil der Grafik sieht man die Dauerlast, die Munin in der Standardkonfiguration selbst bei kleinen Installationen erzeugt. Im mittleren Teil war die Erstellung der HTML- und Grafikdateien nur auf Anforderung aktiv und im rechten Teil ist zu sehen, wie sich der Einsatz von rrdcached weiter positiv auf die Festplatten-Last auswirkt. Die Anzahl der IO-Operationen konnte mit den obigen zwei Methoden um den Faktor 10 gesenkt werden.

Einen weiteren Vorteil dieser Optimierung zeigte sich erst auf den zweiten Blick. Munin läuft hier in einer eigenen Mini-VM, die sonst nichts anderes als Munin macht. Der darunterliegende VM-Host konnte die alle 5 Minuten auftretenden Massen-IOs nicht mehr optimieren und reagierte mit gesteigerter Festplatten-Latenz. Dieses Problem ist nun auch beseitigt, wie man in folgender Grafik schön sieht:

Munin diskstats_latency-day

Bewerte diesen Beitrag

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.