GitLab-Migration: Monkeypatching von GitLab für Multicore-Backup
Herausforderung: Multicore-Backups bei GitLab-Migrationen
Vor kurzem haben wir für einen Kunden eine sehr große GitLab-Installation von einem alten Ubuntu auf einen Debian-basierten systemd-nspawn-Container migriert, der auf einem Archlinux-Host läuft.
Das System war ursprünglich als GitLab–Omnibus–Installation in Standardgröße geplant, aber aufgrund der starken Nutzung wurde es im Laufe der Zeit zu einem riesigen Ungetüm. Es speicherte mehrere Terabytes an Daten auf mehreren Festplatten und wurde auf einem veralteten Ubuntu-System betrieben. Wir entschieden uns für eine Migration auf unsere Standardplattform mit einem Debian-Container auf einem frischen Rolling-Release-Betriebssystem. (Wir haben uns für einen containerisierten Ansatz entschieden, da GitLab nur Ubuntu-, Debian-, Suse- und RHEL-basierte Distributionen unterstützt und wir die Bereitstellung so einfach originalgetreu wie möglich halten wollen).
Das Problem
Die Anforderungen unseres Kunden sahen vor, dass das GitLab-System während der regulären Arbeitstage rund um die Uhr verfügbar sein musste, da Teile des Unternehmens in einer anderen Zeitzone arbeiten. Das Migrationsfenster betrug maximal 48 Stunden an einem Wochenende, also wiesen wir der VM mehrere Terabyte virtuellen Speicherplatz zu und starteten das GitLab-Backup an einem Freitagabend.
Allerdings mussten wir die Datensicherung abbrechen, nachdem sie fast zwei Tage lang ununterbrochen gelaufen war. Später berechneten wir, dass der gesamte Prozess etwa drei Tage in Anspruch nehmen würde, und diese Schätzung bezog sich ausschließlich auf den Datenexport. Die Wiederherstellungsphase hätte vermutlich schneller sein können als die Backup-Phase, aber angesichts des Zeitrahmens unserer Migration von einem Wochenende war dieses Verfahren keine Option, und das gesamte Projekt musste neu geplant werden.
Mit diesem Problem waren wir nicht allein. Viele Kunden von Gitlab Enterprise haben Probleme mit der GitLab-Backup-Routine für große Instanzen. Es scheint, dass das Backup-Skript für GitLab in den letzten Jahren nur wenig Beachtung gefunden hat. Da wir mit der 48-Stunden-Grenze nicht weiterkamen, mussten wir uns eine eigene Lösung einfallen lassen.
Schritt-für-Schritt-Lösung
Wir klonten die gesamte VirtualMachine und führten einige Experimente durch. Schließlich kamen wir zu einer überraschend einfachen Lösung, die die Zeit für Sicherung und Wiederherstellung um eine Größenordnung reduzierte.
- Ersetzen des Systems gzip durch pigz
- Patch des Helperskript für das Backup
- Erhöhung der Anzahl der virtuellen CPU-Kerne
- Überspringen des unnötigen tar-Schrittes im Backup
1. Ersetzen des System gzip durch pigz
Die Experimente haben gezeigt, dass der vom Backup-Skript ausgeführte Komprimierungsprozess aufgrund einer gzip-Operation mit nur einem Kern zu Engpässen führt. Daher installierten wir pigz1https://zlib.net/pigz/, eine parallele Implementierung von gzip, die für moderne Multiprozessor- und Multi-Core-Maschinen entwickelt wurde.
Dann haben wir das System gzip durch Pigz ersetzt.
Wenn man also gzip --version aufruft, wird pigz 2.7 zurückgegeben.
2. Patch des Backup-Helperskripts
Die Verwendung von pigz allein reichte nicht aus, aber glücklicherweise haben sich die CPUs seit den Anfängen von pigz weiterentwickelt, so dass wir die Größe der Kompressionsblöcke von dem winzigen Standardwert von 128KiB auf 4096KiB erhöht haben. Größere Werte könnten funktionieren, aber wir haben es nicht weiter getestet.
Wir haben /opt/gitlab/embedded/service/gitlab-rails/lib/backup/helper.rb in den Zeilen 35 und 37 gepatcht.
3. Erhöhung der Anzahl der virtuellen CPU-Kerne nach Bedarf
Nach einigen kurzen Tests haben wir herausgefunden, dass 16 virtuelle Kerne der ideale Wert für pigz auf unserer virtuellen Maschine sind.
4. Überspringen des unnötigen tar-Schrittes im Backup
Schließlich entdeckten wir, dass das Skript die mehreren gzip–Ausgaben in ein einziges tar–Archiv leitet (das dann nach Abschluss der Sicherung abstürzt und den gesamten Fortschritt löscht). Da dieser Vorgang – mit nur einem Rechenkern – Zeit in Anspruch nimmt und der Schritt durch Angabe eines cli-Flags übersprungen werden kann, haben wir ihn ausgeführt:
Ergebnisse
Die Sicherungszeit konnte um eine Größenordnung auf etwa vier Stunden reduziert werden. Für den Wiederherstellungsprozess ist es nicht erforderlich, dass die Sicherung im tar-Format vorliegt, stattdessen reicht eine Sammlung von gzip-Dateien aus. Der Wiederherstellungsprozess wurde ebenfalls innerhalb von etwa 4 Stunden abgeschlossen. Nach 8 Stunden lief also die sehr große GitLab-Installation problemlos auf dem neuen System.
Hier lesen Sie den Artikel auf englisch: Solving GitLab Migration Issue: Monkeypatching GitLab for Multicore Backup
Hinterlasse einen Kommentar