Seite wählen

NETWAYS Blog

rsync und was dann?

Diese Woche hatte ich die zweifelhafte Ehre die mit 1,6TB schon etwas größere MySQL-Datenbank (MariaDB) eines Kunden auf den zweiten Datenbankknoten zu spielen. Dabei war die Herausforderung das die ganze Show außerhalb der Geschäftszeiten von 17:30 Uhr bis max. 5:00 Uhr stattfindet. Ein Dump der Datenbank dauert erfahrungsgemäß zu lange um das Wartungsfenster einzuhalten. Kein Problem dachte ich mir, dann halt rsync auf Dateiebene. Also die Datenbankzugriffe pünktlich zu Beginn des Wartungsfensters unterbunden, die Datenbank gestoppt und den rsync vom Zielsystem aus wie folgt gestartet:

# rsync -avPz --exclude 'ib_logfile*' root@a.b.c.d:/var/lib/mysql/ /var/lib/mysql/

Eine kurze Erklärung der gesetzten Parameter:

  • a – kopiert rekursiv unter Beibehaltung der Dateiberechtigungen
  • v – sorgt für eine ausführlichere Ausgabe (verbose)
  • P – zeigt eine Fortschrittsanzeige (progress) und setzt den Transfer bei einem evtl. Abbruch fort (partial)
  • z – aktiviert die Komprimierung, meistens bei einer Übertragung via Netzwerk sinnvoll

Die beiden InnoDB Logfiles (ib_logfile0 und ib_logfile1) mit jeweils 11GB wurden für eine schnellere Übertragung ausgeschlossen, da sie beim Anstarten eh wieder neu erstellt werden.

Leider hat sich relativ schnell herausgestellt dass das nicht der Weisheit letzter Schluss war, da die Übertragung mit ca. 15MB/s an die 32 Stunden gedauert und damit das Wartungsfenster überschritten hätte. Auch eine Anpassung der Parameter und der Synchronisationsvorgang auf ein schnelleres Storage mit max. 40MB/s und damit fast 15 Stunden wären zu lange gewesen.

Nach einer kurzen Internetrecherche bin ich auf eine mögliche Lösung mit mbuffer gestossen. Der „measuring buffer“ steht bereits als kleines Paket für die gängigen Linux-Distributionen zur Verfügung und sorgt dafür das es durch einen Puffer nie zu einem Leerlauf des Datenstroms kommt und die Verbindung somit nicht abreißen kann. Mit Komprimierungsfunktionalität und etwas „Bash-Magic“ außenrum kann das dann so aussehen:

# tar cf - * | mbuffer -m 1024M | ssh a.b.c.d '(cd /var/lib/mysql; tar xf -)'

Dem zuzusehen war schon fast eine Freude, hätte nur noch eine Tüte Chips und vielleicht ein passendes Kaltgetränk gefehlt. Mit Transferraten von bis zu 350MB/s hat der Kopiervorgang so gerade mal über 2 Stunden gedauert (Durchschnitt 216MB/s) und die Umgebung bis zum Ende des Wartungsfensters längst wieder im Normalzustand. Das in vielen Fällen schon hilfreiche rsync kommt v.a. bei sehr vielen oder sehr großen Dateien durch die Checksummenberechnung an seine Grenzen, sodass mbuffer hier durchaus mehr als nur eine Alternative sein kann.

Markus Waldmüller
Markus Waldmüller
Head of Strategic Projects

Markus war bereits mehrere Jahre als Sysadmin in Neumarkt i.d.OPf. und Regensburg tätig. Nach Technikerschule und Selbständigkeit ist er nun Anfang 2013 bei NETWAYS als Senior Manager Services gelandet. Seit September 2023 kümmert er sich bei der NETWAYS Gruppe um strategische Projekte. Wenn er nicht gerade die Welt bereist, ist der sportbegeisterte Neumarkter mit an Sicherheit grenzender Wahrscheinlichkeit auf dem Mountainbike oder am Baggersee zu finden.

ReaR mal anders

Bereits vor ein paar Jahren habe ich einen Blogpost zur Disaster Recovery Lösung Relax-and-Recover (kurz: ReaR) geschrieben. Vor Kurzem hatte ich ein Anwendungsbeispiel, in dem ich ebenfalls auf die in vielen Fällen bewährte Lösung zugreifen wollte: Ziel war es, unsere Schulungsnotebooks auch außerhalb des Headquarters nach erfolgtem Training möglichst automatisch auch für nichttechnische Anwender auf den Auslieferungszustand zurück zu setzen. Bisher werden die Notebooks mittels Foreman jedes Mal neu provisoniert, was v.a. einiges an unnötiger Zeit frisst.
Demzufolge lag der Ansatz nahe, das mit ReaR zu lösen. Da ich auf zusätzliche Medien wie USB-Sticks verzichten wollte und das Ganze auch offline funktionieren soll, bleibt nur die lokal verbaute Platte als Speicherort für Rescueimage und Backupdateien übrig. Zudem sollte noch ein Booteintrag für die Rücksetzung erstellt werden. Die ReaR-Konfiguration in „/etc/rear/local.conf“ dazu sieht so aus:
OUTPUT=ISO
OUTPUT_URL=file:///backupshare
BACKUP=NETFS
BACKUP_URL=file:///backupshare
GRUB_RESCUE=1

Problem dabei ist, dass die Backupdateien als Archiv (backup.tar.gz) in einer der Partitionen auf der Festplatte (/dev/sdaX) liegen. Beim Wiederherstellungsvorgang löscht ReaR leider standardmäßig alle Laufwerksinformationen und erstellt diese neu, sodass die Backupdateien in dem Fall verloren gehen. Mit dem Parameter PRE_RECOVERY_SCRIPT kann man den Backupshare zumindest mounten und das Backuparchiv in das Filesystem des Rescueimages kopieren.
Ein anderer Ansatz ist die Backupdateien direkt im IOS-Image des Rescuesystems abzulegen, das geht mit folgender Konfiguration:
OUTPUT=ISO
OUTPUT_URL=file:///backupshare
BACKUP=NETFS
BACKUP_URL=iso://backup
GRUB_RESCUE=1

Auch hier zeigen sich allerdings in der Praxis Probleme. Je nach Größe der Backupdateien wächst das ISO-Image dadurch natürlich entsprechend an. Außerdem verwendet das von uns auf den Schulungsnotebooks eingesetzte Betriebssystem, CentOS 7, zum Erstellen des ISO’s in der Standardinstallation genisoimage. Hier besteht eine feste Grenze von 4GB pro Image. Diese lässt sich zwar mit ISO_MAX_SIZE bei ReaR fix konfigurieren, führt aber dazu, dass die Backupdateien im Rescueimage aufgrund des Abbruchs eben nicht vollständig enthalten sind. Indem man genisoimage gegen das nachzuinstallierende xorriso austauscht und den symbolischen Link für mkisofs anpasst, lässt sich die Begrenzung jedoch umgehen. Je nach Größe der Backupdateien macht das allerdings oft nur bedingt Sinn.
In unserem Fall hat sich gezeigt, dass ReaR für das spezielle Anwendungsszenario der lokalen Wiederherstellung von Notebooks leider nicht die ideale Wahl ist, da die Software ursprünglich für andere Anwendungszwecke konzipiert wurde. Die Suche nach der optimalen Lösung dauert daher aktuell noch an…

Markus Waldmüller
Markus Waldmüller
Head of Strategic Projects

Markus war bereits mehrere Jahre als Sysadmin in Neumarkt i.d.OPf. und Regensburg tätig. Nach Technikerschule und Selbständigkeit ist er nun Anfang 2013 bei NETWAYS als Senior Manager Services gelandet. Seit September 2023 kümmert er sich bei der NETWAYS Gruppe um strategische Projekte. Wenn er nicht gerade die Welt bereist, ist der sportbegeisterte Neumarkter mit an Sicherheit grenzender Wahrscheinlichkeit auf dem Mountainbike oder am Baggersee zu finden.

Noch mehr Inhalte für unser Graphing Training

Nachdem wir in den ersten Monaten des Jahres mit unseren Trainings etwas zurückhaltend waren, geht’s nun wieder voll los. Neben vielen anderen Schulungen, startet
in knapp zwei Wochen auch das Graphite + Grafana Training in die neue Saison. Gerade in dem Bereich gibt es allerlei Neuigkeiten und so war es für uns natürlich klar diesen Fortschritt auch in die Schulungsunterlagen einfließen zu lassen.
Zuerst stand natürlich Versionspflege an: Die Graphite Version in Folien und Trainingsumgebung wurde auf 1.1.2 angehoben, die große Änderung seit 1.1.x ist der sog. Tag Support.
Die wohl größte Aufmerksamkeit gilt aber Grafana in der neuen Version 5. Dashboards, Erscheinungsbild, Einstellungen und Themes wurden komplett überarbeitet. Außerdem können Dashboards zu Verzeichnissen zusammengefasst werden, was große Vorteile und Erleichterungen bei der Vergabe von Berechtigungen bringt. In dem Zuge besteht nun auch die Möglichkeit Benutzer in Teams zu strukturieren.

Grafana v5


Das InfluxDB-Kapitel wurde auf die aktuelle Version 1.5 angehoben. Neben InfluxDB werfen wir in der Schulung auch einen kurzen Blick auf die anderen Komponenten des TICK-Stacks bestehend aus Telegraf, Chronograf und Kapacitor.
Auch die Integrationen haben wir gehörig überarbeitet: Der eingesetzte Icinga 2 Core und Icinga Web 2 wurden jeweils auf die aktuellen Versionen angehoben. Neben dem Grafana-Modul kann nun auch das kürzlich releaste Graphite-Modul für Icinga Web 2 behandelt werden. Der Logstash-Teil ist einer Kombination aus Icingabeat und Elasticsearch gewichen, sodass eine anschauliche Übung für Annotations in Grafana Platz findet.
Zusätzliche Slides stellen mögliche Alternativen zu den Standard Carbon-Komponenten vor und erklären dessen Vor- und Nachteile. Weiterhin geben wir Performancetipps und Hinweise auf mögliche Optimierungen der Graphite-Umgebung. In diesem Zusammenhang gehen wir insbesondere auf Bottlenecks und entsprechende Admin- und Benchmarktools ein.
Um die Darstellung der Folien und v.a. der Handouts zu verbessern, setzen wir auf eine neue Showoff-Version (0.19). Dazu wurde das CSS-Layout einer kompletten Überarbeitung unterzogen. Die eingesetzten VirtualBox-Images werden nun von Grund auf mit Vagrant provisioniert, wohingegen die Installation und Konfiguration der Notebooks nach wie vor mit Foreman und Puppet stattfindet.
Der Umfang des Trainings ist mit zwei Tagen gleich geblieben. Die neuen Inhalte werden in wenigen Tagen ebenso wie die Vagrantfiles auch auf dem GitHub-Repository zur Schulung verfügbar sein. Und auch danach geben wir uns größte Mühe mit unseren Trainings so nah wie möglich am „Puls der Zeit“ zu sein.

Markus Waldmüller
Markus Waldmüller
Head of Strategic Projects

Markus war bereits mehrere Jahre als Sysadmin in Neumarkt i.d.OPf. und Regensburg tätig. Nach Technikerschule und Selbständigkeit ist er nun Anfang 2013 bei NETWAYS als Senior Manager Services gelandet. Seit September 2023 kümmert er sich bei der NETWAYS Gruppe um strategische Projekte. Wenn er nicht gerade die Welt bereist, ist der sportbegeisterte Neumarkter mit an Sicherheit grenzender Wahrscheinlichkeit auf dem Mountainbike oder am Baggersee zu finden.

Annotations in Grafana

Im Zuge der diesjährigen Open Source Monitoring Conference durfte ich mit Timeseries & Analysis with Graphite and Grafana einen der Workshops am Vortag der eigentlichen Konferenz halten. Wie man dem Titel unschwer entnehmen kann spielte dabei auch Grafana eine besondere Rolle. Grafana ist vielen als schöneres Dashboard für Graphite bekannt und unterstützt mit Elasticsearch, CloudWatch, InfluxDB, OpenTSDB, Prometheus, MySQL als auch Postgres in der aktuellen Version 4.6.2 allerdings noch eine ganze Reihe weiterer Datensourcen nativ. Zusätzlich können diese herkömmlichen Datensourcen auch noch durch Community Plugins ergänzt werden.
Ganz besonders hilfreich ist es wenn man die Informationen aus verschiedenen Datensourcen miteinander vereint. So lassen sich beispielsweise Zusammenhänge besser erkennen und Rückschlüsse auf bestimmte Ereignisse ziehen, die ansonsten vielleicht unentdeckt blieben. Metriken, die z.B. aus Graphite stammen, können bei Grafana nun durch sogenannte Annotations um zusätzliche Informationen angereichert werden. Neben Annotations aus den unterstützten Datensourcen können solche Events seit v4.6 übrigens auch direkt in der eigenen Grafana-Datenbank gespeichert werden, ob man das wiederum möchte ist allerdings eine ganz andere Frage…
Als Praxisbeispiel habe ich für meinen Workshop im Rahmen der OSMC überraschenderweise Icinga gewählt. Hier ist es möglich über die Icinga 2 API verschiedene Daten wie Checkergebnisse, Statusänderungen, Benachrichtigungen, Bestätigungen, Kommentare oder auch Downtimes mit dem Icingabeat direkt an Elasticsearch oder wenn man möchte alternativ auch an Logstash zu senden. Über das Annotation-Feature von Grafana lassen sich so die Benachrichtigungen aus Icinga über die Elasticsearch Datasource passend zu den jeweiligen Statusänderungen der Host- oder Serivcechecks einblenden:

Wer dazu mehr erfahren möchte dem kann ich unsere Graphite + Grafana Schulung ans Herz legen, neben vielen anderen Themen werden dort auch Grafana und Annotations in aller Ausführlichkeit behandelt. Und wer’s nicht schafft, für den findet sich vielleicht der ein oder andere passende Workshop im Rahmen unserer Konferenzen.

Markus Waldmüller
Markus Waldmüller
Head of Strategic Projects

Markus war bereits mehrere Jahre als Sysadmin in Neumarkt i.d.OPf. und Regensburg tätig. Nach Technikerschule und Selbständigkeit ist er nun Anfang 2013 bei NETWAYS als Senior Manager Services gelandet. Seit September 2023 kümmert er sich bei der NETWAYS Gruppe um strategische Projekte. Wenn er nicht gerade die Welt bereist, ist der sportbegeisterte Neumarkter mit an Sicherheit grenzender Wahrscheinlichkeit auf dem Mountainbike oder am Baggersee zu finden.

Trick 17 mit dem Director

Möchte man die Schnittmenge aus mehreren Importquellen im Icinga Director vereinen, so gibt es dafür einen Lösungsweg der bislang vielen noch nicht bekannt ist.
Beispielhaft dienen folgende zwei SQL-Tabellen als Ausgangslage, testhost03 ist dabei nur in der Tabelle „hosts01“ enthalten:
MariaDB [cmdb]> SELECT * FROM cmdb.hosts01;
+----+------------+----------+---------+
| id | hostname   | address  | os      |
+----+------------+----------+---------+
|  1 | testhost01 | 10.0.0.1 | Windows |
|  2 | testhost02 | 10.0.0.2 | Linux   |
|  3 | testhost03 | 10.0.0.3 | Windows |
+----+------------+----------+---------+

MariaDB [cmdb]> SELECT * FROM cmdb.hosts02;
+----+------------+----------+---------+
| id | hostname   | address  | os      |
+----+------------+----------+---------+
|  1 | testhost01 | 10.0.0.1 | Windows |
|  2 | testhost02 | 10.0.0.2 | Linux   |
+----+------------+----------+---------+

Um nun die Daten aus beiden Quellen abzugleichen ohne gleich Objekte im Director zu erzeugen, behilft man sich mit einer Datenliste als Zwischenschritt. Die ID der neu erstellten Datenliste wird später benötigt und kann über die Director-Datenbank herausgefunden werden:
MariaDB [director]> SELECT * FROM director.director_datalist WHERE list_name = "Hosts from 2nd import source";
+----+------------------------------+-------------+
| id | list_name                    | owner       |
+----+------------------------------+-------------+
|  2 | Hosts from 2nd import source | icingaadmin |
+----+------------------------------+-------------+

Wie dem Namen der Liste unschwer zu entnehmen ist sollen dort die Hosts aus der 2ten Importquelle, also von „hosts02“, zwischengespeichert werden.
Mit diesen Informationen kann die entsprechende Sync Rule für die Synchronisation der Hosts aus der 2ten Quelle in die Datenliste erstellt werden. Neben der ID als jeweilige „list_id“ (hier „2“) werden die Felder „entry_name“ und „entry_value“ definiert:

Nach dem Syncvorgang erhält die Datenliste die entsprechenden Einträge. Im Beispiel sind das testhost01 und testhost02. In der Import Source für die erste Datenquelle werden deren Einträge nun anhand des „Map“-Modifiers mit den Einträgen aus der Datenliste abgeglichen:

Damit ergibt sich folgende Vorschau der Import Source:

In der darauf aufbauenden Sync Rule ist es wichtig eine entsprechende Filter expression zu setzen:

Ist sie negiert, wie im vorangegangenen Beispiel, werden die Hosts die in beiden Datenquellen vorkommen erzeugt. Im Beispiel wären das testhost01 und testhost02. Liegt keine Negierung vor (z.B. „map=“), so werden nur die Hosts erzeugt die in der zweiten Datenquelle nicht vorkommen. Also beispielhaft testhost03. Damit der Filter greift, muss der Bezeichner (hier „map“) allerdings auch als Eigenschaft der Sync Rule vorkommen.
Der Icinga Director hält noch wesentlich mehr Funktionen für verschiedenste Anwendungsbereiche bereit. Das vorangegangene Beispiel dient lediglich dazu die Fähigkeiten dieses mächtigen Tools etwas zu veranschaulichen. Bei weiteren Fragen rund um den Director oder auch Icinga 2 stehen wir bei NETWAYS natürlich gerne zur Verfügung.

Markus Waldmüller
Markus Waldmüller
Head of Strategic Projects

Markus war bereits mehrere Jahre als Sysadmin in Neumarkt i.d.OPf. und Regensburg tätig. Nach Technikerschule und Selbständigkeit ist er nun Anfang 2013 bei NETWAYS als Senior Manager Services gelandet. Seit September 2023 kümmert er sich bei der NETWAYS Gruppe um strategische Projekte. Wenn er nicht gerade die Welt bereist, ist der sportbegeisterte Neumarkter mit an Sicherheit grenzender Wahrscheinlichkeit auf dem Mountainbike oder am Baggersee zu finden.