Smart Mirroring: CI/CD-Skalierung und verbesserte Geo-Performance mit Bitbucket Data Center

Vor etwas mehr als drei Jahren hat Atlassian das Feature Smart Mirroring für Bitbucket Data Center vorgestellt. Davon profitieren insbesondere verteilte Software-Teams, die mit großen Repositories arbeiten, denn diese Spiegelserver steigern die Git-Performance speziell beim Lesen und Kopieren signifikant.

Die Smart-Mirroring-Option versetzt uns in die Lage, an Remote-Standorten einen oder mehrere Spiegelknoten mit Read-only-Kopien unserer Repositories aufzusetzen, die automatisch mit der Primärinstanz synchronisiert werden. Ein solcher Spiegel kann alle oder auch nur bestimmte Git-Repos des Primärsystems hosten. Statt mit dem Primärknoten zu interagieren, beziehen verteilte Teammitglieder ihre Repository-Kopien von den Spiegeln, was den dafür erforderlichen Zeitaufwand deutlich senkt.

Die Einführung dieser Funktionalität hat diverse Herausforderungen gelöst, mit denen Software-Teams hadern, und in diesem Zusammenhang vor allem für eine Verbesserung von git read und eine nachhaltige Erhöhung der Geschwindigkeit beim Klonen gesorgt.

Doch mit einem hohen Grad an Verteilung in einer Organisation geht oft das Problem einher, dass das steigende Aufkommen an Continuous-Integration-Builds mitunter Staus und Verstopfung verursacht, was wiederum die Arbeit verlangsamt und sie manchmal sogar komplett zum Stillstand bringen kann.

Die Evolution des Smart Mirroring

Sehen wir uns das in der Praxis an und stellen uns ein Team in Indien vor, das (in geographischer Nähe) einen Spiegel aufgesetzt hat. Diese Entwickler verweisen ihre Builds auf den Standalone-Spiegel, stellen aber schnell fest, dass diese Methode nicht skaliert. Sie denken darüber nach, einen weiteren Spiegelserver hinzuzufügen, aber damit wäre das Skalierungsproblem nicht gelöst: Es sind komplexe Konfigurationen nötig, um festzulegen, welcher Build von welchem Spiegel kopiert.

Um solchen Teams zu helfen, hat Atlassian eine weitere Evolutionsstufe des Smart-Mirroring-Features ausgeliefert: Spiegelfarmen, die die CI/CD-Kapazitäten skalieren und erhöhen. Diese neue Funktionalität erlaubt es, Spiegel in "Farmen" zu clustern, die hinter einem Load Balancer gruppiert sind.

Das verkürzt die Wartezeiten auf die Build-Resultate erheblich. Teams können ihre Builds auf einen einzelnen Ort verweisen (die URL des Load Balancers) und jederzeit zusätzliche Spiegel für eine elastische Skalierung integrieren. Und die Teams profitieren nicht nur von der verbesserten Skalierbarkeit, sondern auch von einer hochverfügbaren Spiegelinfrastruktur: Falls ein Mirror in einer Farm ausfällt, können die übrigen Spiegel die Build-Last unterstützen.

Spiegelfarm-Migration bei Atlassian

Atlassian praktiziert diesen Ansatz selbst. Vor einigen Monaten sind die dortigen Entwicklungsteams auf Spiegelfarmen migriert, um der ständig steigenden Zahl der Builds Herr zu werden. Am Anfang der iterativen Umstellung der internen CI-Systeme standen einige kleinere Bamboo-Instanzen. Sollte das erfolgreich sein, würde ein Produkt mit erheblich höheren Anforderungen an die CI-Ressourcen folgen. Bei diesem Wechsel haben die Atlassian-Teams darauf verzichtet, das Pre-Warming der Repository-Caches zu aktivieren, was in einem signifikanten Datenaufkommen und CPU-Spitzen nahe 100 Prozent resultierte.

Trotzdem blieb die Farm stabil und verfügbar. Um den Migrationsprozess weiter zu vereinfachen, haben die beteiligten Teams sich einen neuen REST-Endpunkt zunutze gemacht, um ganze Instanzen mit einem Schlag zu migrieren. (Diese Option ist mit der Bamboo-Version 6.10.3 für alle Kunden verfügbar.) Auf diese Weise konnten schließlich mehr als zehn Instanzen ohne jeden Vorfall migriert werden. Anschließend hat Atlassian den gesamten Traffic auf den Haupt-Cluster umgeschaltet.

Die begleitenden Performance-Tests sprechen eine ziemlich deutliche Sprache: Wird die Zahl der Spiegelfarm-Knoten erhöht, steigert sich der Durchsatz des Load Balancers linear.

Übrigens unterstützt Atlassian Data Center nicht nur Spiegelfarmen, sondern inzwischen auch Content Delivery Networks (CDN). Dank dieser Funktion lassen sich beliebige CDNs (öffentlich, privat oder Reverse-Proxy) aktivieren, um statische Assets zwischenzuspeichern, was zu einem zusätzlichen Performance-Zuwachs für verteilte Teams führt.

Git und Bitbucket effektiv nutzen? Wir sind Ihr Partner!

Möchten Sie mehr über Atlassians Git-Repository-Manager Bitbucket erfahren? Würden Sie die Lösung gerne unverbindlich testen? Oder suchen Sie Unterstützung bei der Transition zu Git? Wir sind Atlassian Platinum Solution Partner und helfen Ihnen bei allen Aspekten rund um die Einführung von Bitbucket Server oder Bitbucket Data Center: Evaluierung, Lizenzierung, Adaption, Optimierung.