GitLab Geo vs. HA – Architekturentscheidungen im Enterprise-Betrieb
Einleitung
GitLab beginnt in vielen Organisationen als reines Werkzeug zur Versionsverwaltung. Ein Ort für Code, vielleicht erste CI/CD-Pipelines, etwas Automatisierung. Mit zunehmender Reife der Infrastruktur verändert sich diese Rolle jedoch grundlegend.
GitLab wird zur zentralen Plattform für Entwicklung, Deployment und operative Steuerung. Entscheidungen, die früher manuell getroffen wurden, werden in Pipelines überführt.
Konfigurationen werden versioniert. Infrastruktur wird nicht mehr nur betrieben, sondern beschrieben.
In unserem Setup geht diese Entwicklung noch einen Schritt weiter.
GitLab ist bei uns die zentrale Steuerungsebene für:
Infrastructure as Code DNS as Code Configuration as Code CI/CD Pipelines Deployment- und Build-Prozesse
Damit entsteht eine neue Realität:
GitLab ist nicht nur ein Tool – sondern ein kritischer Bestandteil der gesamten Plattform.
Ein Ausfall von GitLab bedeutet nicht nur eingeschränkte Entwicklung. Im Worst Case ist auch die Fähigkeit eingeschränkt, Infrastruktur zu verändern, Systeme neu bereitzustellen oder Fehler zu beheben.
Genau aus diesem Grund stellt sich irgendwann eine zentrale Frage:
Wie betreibt man GitLab in einer produktiven, verteilten Umgebung so, dass man nicht nur Ausfälle vermeidet, sondern im Ernstfall kontrolliert reagieren kann?
Wenn GitLab zur kritischen Infrastruktur wird
In kleinen Umgebungen ist ein Ausfall von GitLab meist verkraftbar. Entwickler können lokal weiterarbeiten, Deployments lassen sich im Notfall manuell durchführen.
In gewachsenen Umgebungen sieht das anders aus.
Deployments laufen automatisiert über Pipelines. Infrastruktur wird aus Repositories erzeugt.
DNS wird dynamisch gesteuert. Sicherheitsprüfungen sind Teil des Build-Prozesses. Änderungen erfolgen nicht mehr direkt auf Systemen, sondern ausschließlich über definierte Prozesse.
GitLab wird damit zu einer Art Steuerzentrale.
Und genau hier entsteht die eigentliche Herausforderung: Je stärker man auf Automatisierung setzt, desto kritischer wird die Plattform, die diese Automatisierung steuert.
Die Frage ist also nicht mehr nur:
„Wie halten wir GitLab verfügbar?“
Sondern vielmehr:
„Wie bleiben wir handlungsfähig, wenn GitLab nicht verfügbar ist?“
Der erste Impuls: High Availability
Der naheliegende Ansatz ist in vielen Fällen ein klassisches High-Availability-Setup. Mehrere GitLab-Instanzen werden hinter einem Load Balancer betrieben. Die Datenbank wird repliziert, Redis wird verteilt, Storage wird geteilt. Ziel ist es, den Ausfall einzelner Komponenten transparent abzufangen.
Auf den ersten Blick ist das eine überzeugende Lösung. Systeme bleiben erreichbar, Nutzer bemerken im Idealfall keinen Unterschied. Doch diese Perspektive greift oft zu kurz.
Die Realität von HA in komplexen Umgebungen
Ein HA-Setup ist kein einzelnes System, sondern ein komplexes Zusammenspiel vieler Komponenten.
Datenbank, Storage, Cache und Netzwerk müssen konsistent zusammenarbeiten. Fehler in einer dieser Schichten wirken sich unmittelbar auf das Gesamtsystem aus.
In einer einzelnen Region lässt sich das mit ausreichend Aufwand stabil betreiben. Sobald jedoch mehrere Standorte ins Spiel kommen, verändert sich die Situation deutlich.
Latenzen steigen. Synchrone Replikation wird schwieriger. Netzwerke werden anfälliger für Störungen. Die Wahrscheinlichkeit für inkonsistente Zustände nimmt zu.
Ein typisches Beispiel ist das sogenannte Split-Brain-Szenario. Durch Netzwerkprobleme können mehrere Knoten gleichzeitig davon ausgehen, dass sie aktiv sind. Daten divergieren, und die Wiederherstellung wird aufwendig und fehleranfällig.
Auch das Thema Storage wird häufig unterschätzt. Shared Storage ist in vielen HA-Architekturen ein zentraler Baustein und gleichzeitig eine der größten Schwachstellen.
Performance-Probleme, Locking-Verhalten und Abhängigkeiten führen schnell dazu, dass genau dieser Bestandteil zum Engpass oder sogar zum Single Point of Failure wird.
Das Ergebnis ist ein System, das zwar theoretisch hochverfügbar ist, in der Praxis jedoch mit hoher Komplexität und entsprechendem Betriebsaufwand einhergeht.
GitLab Geo verfolgt einen anderen Ansatz.
Anstatt zu versuchen, ein global konsistentes System aufzubauen, wird die Architektur bewusst vereinfacht:
Ein Primary Node übernimmt alle Schreiboperationen Ein oder mehrere Secondary Nodes replizieren die Daten Replikation erfolgt asynchron.
Diese Asynchronität ist kein Nachteil, sondern eine bewusste Entscheidung. Sie ermöglicht eine klare Trennung von Verantwortlichkeiten und reduziert die Abhängigkeit von global synchronisierten Systemen.
Während HA versucht, Ausfälle unsichtbar zu machen, akzeptiert Geo, dass Unterschiede zwischen Standorten existieren können und nutzt diese bewusst, um Komplexität zu reduzieren.
Unsere Architektur: Zwei Standorte, klare Rollen
In unserer Umgebung betreiben wir GitLab über zwei Standorte:
Deutschland als Primary Österreich als Secondary.
Alle Schreiboperationen, Authentifizierungen und Pipeline-Ausführungen erfolgen über den Primary. Der Secondary repliziert kontinuierlich und dient als zusätzlicher Zugriffspunkt sowie als Grundlage für Disaster Recovery.
Diese klare Rollenverteilung sorgt für ein vorhersehbares und kontrollierbares Verhalten.
Es gibt keinen Wettbewerb zwischen mehreren aktiven Schreibknoten. Es gibt keine komplexe globale Synchronisation. Stattdessen existiert ein klar definierter Ort für Änderungen und eine replizierte Kopie für Ausfallszenarien.
Der entscheidende Perspektivwechsel: Recovery statt perfekte Uptime
Die wichtigste Entscheidung in unserer Architektur war nicht technischer Natur, sondern konzeptionell.
Wir haben uns bewusst dagegen entschieden, auf perfekte Verfügbarkeit zu optimieren.
Stattdessen optimieren wir auf schnelle Wiederherstellbarkeit.
Perfekte Uptime ist ein theoretisches Ziel, das in der Praxis mit zunehmender Komplexität erkauft wird. Je mehr man versucht, Ausfälle vollständig zu vermeiden, desto komplexer und damit fehleranfälliger wird das System.
Recovery hingegen basiert auf einer anderen Annahme:
Ausfälle passieren. Entscheidend ist, wie schnell und kontrolliert man darauf reagieren kann.
Ein realistisches Szenario: Standortausfall
Nehmen wir ein konkretes Beispiel.
Der Primary-Standort fällt vollständig aus. Netzwerkprobleme, Infrastrukturfehler oder ein größeres Incident-Szenario machen den Zugriff unmöglich.
In einem klassischen HA-Setup stellt sich sofort die Frage nach Konsistenz, Failover und Stabilität.
In unserem Setup verschiebt sich der Fokus.
Der Secondary enthält bereits eine replizierte Version aller relevanten Daten. Repositories sind vorhanden, Artefakte sind verfügbar, und die Grundlage für alle weiteren Prozesse ist gegeben.
Der nächste Schritt ist nicht, ein komplexes System zu stabilisieren, sondern die Arbeitsfähigkeit wiederherzustellen.
Pipelines können gestartet werden. Infrastruktur kann aus Code neu aufgebaut werden.
Systeme lassen sich reproduzierbar bereitstellen.
GitLab ist dabei nicht nur ein Bestandteil der Lösung, es ist die Grundlage für den gesamten Wiederaufbauprozess.
GitLab als Single Source of Truth
Dieser Ansatz funktioniert nur, weil GitLab in unserer Architektur eine zentrale Rolle einnimmt. Alle relevanten Informationen über den Zustand der Infrastruktur befinden sich im System:
Konfigurationsdefinitionen Deployment-Logik DNS-Zonen Automatisierungsprozesse.
Das bedeutet, dass wir nicht von einzelnen Systemzuständen abhängig sind, sondern jederzeit in der Lage sind, den gewünschten Zustand neu zu erzeugen.
Infrastruktur wird damit nicht nur betrieben, sondern beschrieben. Und genau diese Beschreibung macht es möglich, sie im Ernstfall wiederherzustellen.
Grenzen und praktische Aspekte
So überzeugend der Geo-Ansatz ist, er bringt auch Einschränkungen mit sich.
Authentifizierung erfolgt in der Regel über den Primary. Der Secondary ist nicht dafür ausgelegt, alle Funktionen vollständig zu übernehmen.
Auch nicht alle GitLab-Funktionen sind vollständig Geo-aware. Bestimmte Downloads oder Artefaktzugriffe können weiterhin über den Primary laufen.
Diese Eigenschaften sind keine Fehler, sondern Teil des Designs. Sie lassen sich planen, müssen jedoch bewusst in die Architektur einbezogen werden.
GitLab Runner und Security als integraler Bestandteil
Ein weiterer wichtiger Bestandteil unseres Setups sind die GitLab Runner.
Diese werden isoliert betrieben, beispielsweise innerhalb von Kubernetes-Umgebungen, und sind klar von der GitLab-Instanz getrennt. Dadurch lassen sich Workloads sauber trennen und flexibel skalieren.
In Kombination mit GitLab Ultimate entsteht ein zusätzlicher Vorteil: Sicherheitsmechanismen sind direkt in die Entwicklungsprozesse integriert.
Analysen wie SAST, DAST oder Dependency Scanning erfolgen nicht nachgelagert, sondern direkt innerhalb der Pipelines. Schwachstellen werden früh erkannt, und
Sicherheitsanforderungen werden automatisiert durchgesetzt. Security wird damit nicht zu einem separaten Prozess, sondern zu einem integralen Bestandteil des Systems.
Wann HA sinnvoll ist und wann nicht
GitLab Geo ist nicht in jedem Szenario die richtige Wahl. In Umgebungen mit nur einem Standort, niedriger Latenz und klaren Anforderungen an sofortige
Konsistenz kann ein klassisches HA-Setup sinnvoll sein. Sobald jedoch mehrere Regionen ins Spiel kommen, Disaster Recovery an Bedeutung gewinnt
und Systeme reproduzierbar aufgebaut werden sollen, verschiebt sich die Bewertung. Hier spielt Geo seine Stärken aus.
Ausblick: Was passiert, wenn GitLab selbst nicht verfügbar ist?
Bei aller Fokussierung auf Architektur und Betrieb stellt sich eine weitergehende Frage:
Was passiert, wenn nicht nur unsere eigene Infrastruktur ausfällt, sondern die Plattform selbst, auf die wir setzen?
In einer global vernetzten IT-Landschaft sind Abhängigkeiten von einzelnen Anbietern nicht nur technische, sondern auch strategische Risiken. Politische Entwicklungen, regulatorische.
Anforderungen oder Änderungen in Geschäftsmodellen können Einfluss darauf haben, ob und wie bestimmte Services genutzt werden können.
Gerade bei Plattformen wie GitLab, die tief in Entwicklungs- und Betriebsprozesse integriert sind, entsteht dadurch eine neue Dimension von Abhängigkeit.
Aus diesem Grund betrachten wir kritische Systeme grundsätzlich unter einem zusätzlichen Gesichtspunkt:
Wie austauschbar ist das System im Ernstfall? Für GitLab bedeutet das, dass wir unsere Prozesse bewusst so gestalten, dass sie nicht untrennbar an eine einzelne Plattform gebunden sind.
Infrastructure as Code, standardisierte Schnittstellen und reproduzierbare Deployments ermöglichen es uns, zentrale Teile unserer Umgebung auch mit alternativen Werkzeugen
abzubilden.
Das umfasst beispielsweise:
Alternative Git-Plattformen unabhängige CI/CD-Systeme exportierbare Konfigurationen standardisierte Deployment-Prozesse.
Das Ziel ist dabei nicht, GitLab kurzfristig zu ersetzen. Vielmehr geht es darum, langfristig handlungsfähig zu bleiben.
Kritische Systeme werden daher nicht nur hochverfügbar betrieben, sondern auch so gestaltet, dass sie im Zweifel ersetzbar sind.
Fazit
Die Entscheidung zwischen GitLab HA und GitLab Geo ist keine reine Technologieentscheidung.
Es ist eine Frage der Architektur, der Prioritäten und der langfristigen Strategie.
In unserem Fall lag der Fokus nicht auf maximaler Verfügbarkeit um jeden Preis, sondern auf einem System, das auch im Ernstfall kontrollierbar bleibt.
GitLab Geo ist dabei ein zentraler Baustein.
Durch die Kombination aus klarer Rollenverteilung, kontinuierlicher Replikation und Infrastructure as Code entsteht eine Umgebung, die nicht nur stabil betrieben werden kann,
sondern sich im Zweifel auch schnell wiederherstellen lässt.
Und genau das ist in komplexen, verteilten Infrastrukturen oft der entscheidende Vorteil.
