Einführung

Die Entwicklungszeiten für Spiele werden immer länger, und die F&E-Kosten steigen schneller als je zuvor. Die Branche ist an einem Punkt angelangt, an dem leistungsstarke neue Tools benötigt werden, um diese Trends zu durchbrechen und es den Verlagen zu ermöglichen, neue Titel schneller auf den Markt zu bringen. Aufgrund der zunehmenden Größe der Builds und der Größe der modernen verteilten Entwicklungsteams war die Herausforderung für Spieleentwickler und DevOps noch nie so groß. Sie sind an einem Punkt angelangt, an dem ältere Systeme und Tools nicht mehr in der Lage sind, den Anforderungen der Inhalte gerecht zu werden.

Mit den bahnbrechenden Fähigkeiten von Resilio für die Übertragung großer Dateien über die bestehende Infrastruktur hinweg können die Bereitstellung von Builds für die Entwicklung, Testeinrichtungen und globale Partnerstandorte optimiert werden, wodurch die Release-Zeiten auf Kurs gehalten werden und gleichzeitig Zeit und Geld gespart wird. Sobald der bereitgestellte Build lokal ist, beschleunigt die Resilio-Lösung die Verteilung innerhalb jeder Einrichtung und bietet nahezu sofortigen und gleichzeitigen Zugriff, unabhängig von der Team- oder Buildgröße und ohne zusätzliche lokale Bandbreite und Infrastruktur.

Überprüfung der Herausforderungen und Lösungen

Die Spieleentwicklung verändert sich in einer Weise, die die Verteilung von Builds immer schwieriger macht. Es ist üblich, dass mehrere Teams am Entwicklungsprozess teilnehmen, die sich an entfernten Standorten befinden. CI/CD-Praktiken bedeuten, dass Builds häufiger verteilt werden, was die Verteilungssysteme belastet und zu einer wesentlich höheren Datenlast für die Schlüsselinfrastruktur führt. Schließlich, wenn das Spielerlebnis immer reicher wird, wächst die Größe der Builds um Größenordnungen.

Um die Herausforderungen, vor denen moderne DevOps-Teams stehen, besser zu verstehen, hilft es, zunächst einen Blick auf die vorhandenen Lösungen im gemeinsamen Gebrauch zu werfen, im Hinblick auf ein wirklich gemeinsames Szenario: Verteilung von Builds auf 1000s von Endpunkten an mehreren verteilten Standorten. Am Ende dieses Abschnitts erfahren Sie, wie Resilio Connect alle Hürden überwindet, um die zuverlässigste und schnellste Dateiverteilungslösung zu liefern und die täglichen CI/CD-Workflows zu optimieren.

Einfache Lösungen für den Dateitransfer

Unzuverlässig bei der Skalierung

Auf atomarer Ebene verschiebt die Build-Verteilung einfach große Dateien von einem Ort zum anderen, immer und immer wieder. Mit dieser Ansicht ist es nicht verwunderlich, dass frühe Systeme mit gängigen und einfachen Dateitransfer-Tools wie FTP, scp, curl, wget und Robocopy erstellt wurden.

Diese einfachen Tools sind alles andere als auf dem neuesten Stand der Technik und erweisen sich letztendlich als unzureichend und sind nicht leicht skalierbar. Alle basieren auf TCP oder basieren auf der Client-Server-Architektur. Als Transportprotokoll kann TCP in Frage gestellt werden, wenn die Entfernungen zwischen den Entwicklungseinrichtungen zunehmen oder wenn die Verbindungsnetze nicht die beste Qualität aufweisen, was letztendlich zu langsamen Verteilzeiten führt. Die Client-Server-Architektur ist skalierbar und erfordert eine teure Infrastruktur, um diese Einschränkungen zu überwinden, oder das Ergebnis sind wiederum langsame Verteilzeiten und Einschränkungen des gleichzeitigen Zugriffs, um die Nachfrage zu reduzieren. Darüber hinaus fehlen diesen Tools sogar grundlegende Funktionen zur Datenwahrnehmung und -verwaltung, was für DevOps mehr Arbeit bedeutet, um die für den Betrieb notwendigen Skripte zu erstellen und zu verwalten.

Alle diese Herausforderungen verschärfen sich, wenn die Anzahl der Entwicklungszentren und die Entfernung zwischen ihnen wächst. Der weitere Druck steigt, wenn die Größe des Baus und/oder die Größe des Teams, das Zugang benötigt, wächst. Leider sind all diese Trends unerbittlich, wenn es um die moderne Spieleentwicklung geht, was diese gängigen Tools obsolet macht.

RSync

Nicht ideal für eine großflächige Verteilung an viele Standorte über weite Entfernungen hinweg.

Um die Verwaltbarkeit und das mangelnde Datenbewusstsein in den einfachen Tools oben zu verbessern, wenden sich viele Teams an rsync. Mit Delta-Codierung, Deduplizierung und der Möglichkeit, Änderungen zu erkennen und Daten synchron zu halten, verbessert dieses Tool die Effizienz und Handhabbarkeit.

Rsync ist eine Punkt-zu-Punkt-Lösung und arbeitet über TCP, was die Skalierbarkeit von Natur aus einschränkt und bei schlechter Fehlerbehebung nicht die ideale großflächige Verteilung über weite Entfernungen und viele für die Spieleentwicklung typische Standorte ist.

WAN-Optimierungstools

Schlechte Leistung bei geringem Umfang und hohem Wartungsaufwand.

Um Latenz- und Paketverlustprobleme bei der Datenübertragung über weite Entfernungen zu vermeiden, setzen einige Unternehmen in jeder Einrichtung WAN Accelerators ein. Diese Produkte helfen bei den TCP-Beschränkungen in rsync und anderen einfachen Dateiübertragungs-Tools und sind zwar teuer, aber nützlich bei Punkt-zu-Punkt-Konfigurationen zwischen zwei Einrichtungen.

Einschränkungen ergeben sich jedoch, wenn die Anzahl der Einrichtungen, die Daten benötigen, über zwei hinausgeht. Die Kapazität und Effektivität des WAN Accelerators wird effektiv durch die Anzahl der Standorte dividiert. Wenn Sie 10 Möglichkeiten haben, ist der WAN Accelerator nur 10% effektiver als eine Punkt-zu-Punkt-Konfiguration, da er den gleichen Datentransfer 10 mal wiederholen muss. Sie sind auch recht kostspielig in der Wartung.

DFS

Mengen an Umfang erfordern aufwendige Investitionen in die eigene Infrastruktur

Die DFS ist ein komplexes, über alle Standorte verteiltes Dateisystem, um eine konsistente und kohärente Sicht auf alle Gebäudedaten zu gewährleisten. Während die nahtlose Konsistenz ein klares Nebenprodukt ist, leiden auch diese Konfigurationen unter der Größenordnung. Auch hier bedeutet TCP und mangelndes Datenbewusstsein, dass die Lösungen ineffizient sind und ohne WAN-Beschleunigung über weite Strecken leiden.

Aufgrund der Komplexität der Konfiguration sind diese Lösungen möglicherweise nicht für alle Standorte ideal. Unabhängig davon erfordert die zentralisierte Beschaffenheit der Dateiserver an jedem Standort bei zunehmender Skalierung (d.h. Daten- oder Teamgröße) eine riesige und teure Infrastruktur, um die Builds lokal verfügbar zu machen.

Open-Source P2P-Lösungen

Komplex zum Erstellen & Pflegen, Mangel an Deduplizierungs- und WAN-Optimierungsfunktionen

Um Größenbeschränkungen zu überwinden, haben sich einige Unternehmen für maßgeschneiderte Lösungen mit Open-Source-P2P-Implementierungen wie z.B. libtorrent entschieden, die mit steigender Nachfrage sogar schneller werden.

Diese Lösungen sind jedoch komplex zu implementieren und erfordern Entwicklerressourcen für den Aufbau und die Wartung. Diese Ressourcen sind oft knapp und werden am besten für unternehmenskritische Aufgaben in der Spieleentwicklung eingesetzt. Open Source P2P fehlt die WAN-Beschleunigung für entfernte Peer-Verbindungen und die Datenwahrnehmung und -Deduplizierung für grundlegende Effizienz. Außerdem ist die Lösung in der Regel schwer zu verwalten, da es keine zentrale Sicht auf P2P-Datenflüsse und -Konfigurationen gibt.

Finally, an Efficient, Reliable and Scalable Solution, Powered By Peer-to-Peer Technology

Automatische Skalierung nach Ihren Bedürfnissen

Resilio nutzt die P2P-Technologie so, dass die gesamte Infrastruktur funktioniert. Wie Sie in Abbildung 2 unten sehen können, ermöglicht die Nutzung von Ressourcen in allen Einrichtungen eine viel schnellere und kostengünstigere Verteilung des Baus. P2P verwandelt jeden Client in einen Server und wird mit steigendem Bedarf deutlich schneller. Für Großprojekte wie die Verteilung von Gebäuden ist es die ideale Technologie, um die Markteinführung bei der Entwicklung an vielen Standorten zu beschleunigen.

Intelligentes Routing & Fehlertoleranz

Der Namensgeber von Resilio ist „resilience“ und kombiniert P2P mit intelligentem Routing, um ein möglichst belastbares und fehlertolerantes System zu liefern. Für jede Einrichtung und jede Verbindung findet und nutzt Resilio die schnellstmögliche Datenquelle intelligent. Wenn die Herkunft nicht stimmt oder aus irgendeinem Grund nicht gut funktioniert, kann Resilio auf viele andere potenzielle Datenquellen zurückgreifen und liefert wichtige Infrastrukturredundanzen in der Größenordnung der Anzahl der Knoten im System. Selbst einfache Probleme wie eine kurze Unterbrechung der Verbindung erfordern keinen kompletten Neustart der Verteilung. Aufgrund des Block-Level-Awareness stellt die Resilio-Lösung nahtlos wieder her und setzt dort an, wo sie aufgehört hat.
Resilio ist von Natur aus ein hochverfügbares (HA) aktives/aktives System. Es besteht keine operative Abhängigkeit von zentralen Systemen, so dass Knoten und Aufträge, sobald sie konfiguriert sind, teilautonom arbeiten können, ohne auf zentralisierte Systeme, Standorte oder die Cloud angewiesen zu sein. Dies reduziert die Ausfallzeiten und verbessert die Zuverlässigkeit.

Effizienz & Datenbewusstsein

Die schnellsten Daten in Ihrem Netzwerk sind die Daten, die Sie nie senden müssen. Weil es bereits da ist. Resilio beinhaltet die Erkennung und Deduplizierung von Daten auf Blockebene. Wenn ein Block lokal aus einem früheren Build existiert, wird das Resilio-System ihn nicht anfordern. Dies reduziert die Belastung der strapazierten Infrastruktur und verbessert gleichzeitig die Geschwindigkeiten für viele Verteilaufgaben erheblich.

Integrierte WAN-Optimierung (Over µTP)

Resilio Connect kombiniert WAN-Optimierungsprotokolle für jede vorhandene P2P-Verbindung und überwindet die Punkt-zu-Punkt-Natur der bestehenden WAN-Optimierung sowie die Einschränkungen durch hohen Paketverlust und Latenzzeiten im Netzwerk. Darüber hinaus müssen Sie keine zusätzliche Soft- oder Hardware einsetzen oder gar komplexe Konfigurationen für Ihr WAN pflegen. Resilio verarbeitet und optimiert nahtlos jede Verbindung, die es herstellt.

Pull & Push Strategie

Resilio Connect bietet zwei Möglichkeiten, um Ingenieuren Builds zur Verfügung zu stellen. DevOps kann einen Build an einen dedizierten Ingenieur oder ein Team weiterleiten. Der Zielbenutzer oder das Team wird über die Konfiguration von einer Managementkonsole aus definiert (manuell oder über die API). Dies ist sehr nützlich, da das Build-System, wenn es einen Build erstellt, ihn automatisch an das dafür vorgesehene Team liefert.
Die Pull-Methode zeigt einem Teammitglied alle verfügbaren Artefakte an, und dieses Teammitglied entscheidet, was heruntergeladen werden soll. Wenn der Download gestartet wird, arbeiten alle Datenoptimierungsprotokolle (WAN, P2P-Deduplizierung), um Builds schneller zu liefern.

“Our engineers deployed a successful test version in a hour – without reading a ton of manuals – that delivered the best result of all the solutions we tried…”Roman Sakno, Enterprise Architect at Wargaming.

Zusammenfassung der Herausforderungen und Lösungen

Workflow-Beispiele

Beispiel #1: Aufbau der Verteilung von einem Artifactory Server auf Remote R&D Server & Endpunkte über WAN & LAN

Dieses Beispiel zeigt eine stufenweise Verteilung von Builds. In der ersten Phase verteilt Job #1 Builds an entfernte Büros. Je nach Build kann es an lokale Teams verteilt werden oder auch nicht. Wenn die Builds an Teams verteilt werden müssen, führt Job #2 die lokale Verteilung des Builds durch, wie in der folgenden Abbildung dargestellt.

Schritte:

1. Das Build-System (Beispiel Jenkins/Travis) erstellt einen neuen Spielbau.
2. Es speichert Binärdateien in der Artifactory/GFS oder anderen Build-Speichersystemen.
3. Wenn der Build erste Tests besteht und bereit für die Verteilung ist, wird der Build auf einen Server gezogen, um an entfernte Teams verteilt zu werden > Connect Agents startet Job #1 (blaue Linie), um Builds an Server in den entfernten Büros zu verteilen.
4. Sobald der Build an die Remote-Server übermittelt wird, startet der lokale Verteilungsauftrag: Job #2 (violette Linie) zieht Build vom lokalen Server und verteilt ihn an alle Teammitglieder.

Notizen:

Job #1 wird beschleunigt und kann auf eine unbegrenzte Anzahl von Büros skaliert werden, während Job #2 sicherstellt, dass die lokalen Fachleute in jedem Büro nicht auf den Zugriff auf den lokalen Build-Server warten müssen.

Beispiel #2: Aufbau der Verteilung von einem Artifactory Server auf entfernte R&D-Endpunkte über WAN & LAN (ohne Verwendung eines lokalen Servers an entfernten Standorten)

Dieses Beispiel zeigt die Verteilung von Builds ohne Server am entfernten Standort. Diese Architektur ist extrem wichtig für kleine Büros, in denen Sie keine dedizierten Server einsetzen können oder den Fall übertreffen, dass Teams mobil sind oder remote arbeiten. Es gibt einen einzigen Verteilungsauftrag, der Builds vom Build-Server direkt an die Maschinen des Entwicklers liefert, ohne dass ein Server in den entfernten Büros verwendet werden muss. Dieser Ansatz vereinfacht die Infrastruktur, da weniger Hardware benötigt wird. Jede Maschine lädt zuerst Daten von lokalen Geräten herunter und nur wenn keine anderen Teile verfügbar sind, zieht sie sie diese vom zentralen Server.

Schritte:

1. Das Build-System (Beispiel Jenkins/Travis) erstellt einen neuen Spielbau.
2. Es speichert Binärdateien in der Artifactory/GFS oder anderen Build-Speichersystemen.
3. Wenn der Build erste Tests besteht und bereit für die Verteilung ist, wird der Build auf einen Server gezogen, um ihn an entfernte Teams zu verteilen > Connect Agent startet den Job (blaue Linie), um Builds an Maschinen in allen entfernten Büros (über WAN & LAN) zu verteilen.

Notizen:

Dieses Beispiel zeigt, wie Resilio Connect DevOps helfen kann, die Infrastrukturkosten drastisch zu senken und gleichzeitig Builds schneller denn je zu liefern, selbst für Remote-Entwicklungsteams. Es zeigt auch, wie Resilio in der Lage ist, eine Vielzahl von Netzwerkbedingungen zu überwinden, um Builds auch über schlechte Netzwerke zuverlässig und effektiv zu verteilen.

Beispiel #3: Leiten Sie Daten und Builds durch eine Reihe von Richtlinien und Job-Konfigurationen an Teams weiter.

Dieses Beispiel deckt einen Fall ab, in dem Sie mit dem Testen eines Build mit einem kleinen Team beginnen, das sich in einem oder mehreren Büros befinden könnte. Im Laufe des Tests und wenn Sie größere Teams einbeziehen müssen, wird der Build automatisch an das breitere Team verteilt.

Schritte:

1. Das Build-System (Beispiel Jenkins) erstellt einen neuen Spielbau.
2. Es speichert Binärdateien in der Artifactory/GFS oder anderen Build-Speichersystemen.
3. Wenn der Build erste Tests besteht und bereit für die Verteilung ist, wird der Build auf einen Server gezogen, um ihn an entfernte Teams zu verteilen.
– Connect Agents starten den Job (blaue Linie), um Builds an Maschinen des ersten Testteams zu verteilen.
– Im Laufe des Prozesses muss das zweite Team in einem anderen Büro einbezogen werden (Gradientenlinien). Die benannten Agenten, die dem Verteilungsauftrag hinzugefügt wurden, und Connect beginnen mit der Übertragung der Daten.

Notizen:

Dieses Beispiel veranschaulicht den hohen Grad an Kontrolle, den Resilio den DevOps-Teams bietet, mit der Fähigkeit, Daten und Builds programmatisch und intelligent an Teams durch eine Reihe von Richtlinien und Stellenbeschreibungen zu leiten. Diese Richtlinien können über die zentrale Verwaltungskonsole oder programmgesteuert über die API festgelegt werden.

Hauptvorteile

Verbessern Sie die Geschwindigkeit und Serverauslastung und senken Sie gleichzeitig Ihre IT-Infrastrukturkosten.

Das bei weitem größte Problem ist die Verteilung eines großen Build von einem zentralen Server an Entwickler und QS-Maschinen. Die beteiligten Computer sind sehr leistungsfähig und das Netzwerk ist schnell und konsistent, so dass selbst kleine Mengen dieser Maschinen eine Last erzeugen könnten, die der zentrale Server nicht unterstützen kann. Wenn eine Einrichtung mit SMB/NFS auf diese Server zugreift, muss bereits bei einer einfachen Kopie die Übertragung neu beginnen, wenn die Verbindung unterbrochen wird. Wenn Entwickler stattdessen Tools wie ftp/scp verwenden, liegt das Problem in der Belastung der zentralen Server.

An dieser Stelle gibt es zwei Möglichkeiten für klassische DevOps-Systeme, die keine ideale Lösung darstellen:
1. Bereitstellung einer riesigen Menge an lokaler Server-, Speicher- und Netzwerkinfrastruktur (kapitalintensiv)
2. Die Rate begrenzt die Anzahl der Entwickler und QS-Profis, die gleichzeitig auf den Build zugreifen können (arbeitsintensiv, oder genauer gesagt, arbeitsunwirksam).

Ein weitaus besserer Ansatz ist die Nutzung der bereits vorhandenen Infrastruktur zur Unterstützung dieser Aufgabe, nämlich der leistungsfähigen QA- und Entwicklungsmaschinen und Spielkonsolen, die ansonsten meist untätig sind. Der Resilio Connect Agent ist ein kleines Stück P2P-Software, das einfach auf diesen Rechnern installiert werden kann, um sie in Betrieb zu nehmen und die Bereitstellung jedes Build an Nachbarn im LAN zu beschleunigen, anstatt sich ausschließlich auf zentralisierte Server zu verlassen. In diesem Sinne gilt: Je mehr Entwickler Sie haben, desto schneller wird die Resilio-Lösung. Darüber hinaus kann die Nutzung dieser ansonsten ungenutzten Computerressourcen den Bedarf an teurer zentralisierter Serverinfrastruktur reduzieren oder eliminieren.

In diesem Sinne ist der ROI von Resilio im Vergleich zu den hohen Kosten für die Aufrüstung und Überholung lokaler Server, Speicher und Netzwerkinfrastruktur in jeder Entwicklungseinrichtung sehr einfach.

Einfache Integration von Resilio Connect in bestehende Workflows durch die Verwendung der API von Triggers & Connect.

Um die Integration in bestehende Systeme zu erleichtern, hat Resilio Connect das Konzept der Trigger. Auslöser sind spezifische Ereignisse, die die Skriptausführung zu Beginn der Übertragung, nach Abschluss der Übertragung oder nachdem alle Zielbenutzer den Build erhalten haben, auslösen. Dies ermöglicht verschiedene Integrationen auf QA-Maschinen, wie z.B. das Aktualisieren von Builds auf der Maschine, das Anzeigen von Benachrichtigungen an den Benutzer, dass der neue Build verfügbar ist, oder alle anderen damit verbundenen Aktionen.

„Resilio erfüllte alle unsere technischen Anforderungen, war sehr einfach zu implementieren und in unseren Workflow zu integrieren. Uns hat auch gefallen, dass die Einfachheit auf transparente Preise und klare Dokumentation übertragen wurde… „Roman Sakno, Enterprise Architect bei Wargaming.

Die Resilio Management Console verfügt über eine REST-API zur Steuerung der Artefaktverteilung. Die API verwendet den Befehlskanal, um Gruppen von Benutzern zu definieren, Richtlinien zu definieren, Buildauslieferungen zu planen und andere verschiedene Parameter für die Auftragsübertragung zu steuern. Die REST-API ermöglicht es dem Bereitstellungssystem, sich einfach in jeden bestehenden Workflow zu integrieren und den Fortschritt der bestehenden Datenübertragung zu dokumentieren.

Zusammenfassung

Skalierbarkeitsherausforderungen für die Build-Verteilung können sich in vielerlei Hinsicht manifestieren. Selbst die Verteilung über ein lokales Netzwerk innerhalb jedes Büros kann leiden, wenn die lokale Infrastruktur nicht ausreicht, um die Nachfrage zu decken. Resilio bietet eine einzigartige Software und Funktionen, um den Zyklus der endlosen Infrastruktur-Upgrades in jedem Büro zu durchbrechen und bietet ein kostengünstiges und hoch skalierbares System für die lokale Build-Verteilung, das schneller ist als alles, was Sie je zuvor gesehen haben.

Sie benötigen unsere Hilfe?

Kontaktieren Sie uns

In einem ersten Gespräch teilen Sie uns Ihre Wünsche und Anforderungen mit. Auf dieser Basis erarbeiten wir ein individuelles Konzept für Sie.

Support

Jetzt Anrufen

Kontakt

Kontaktieren Sie uns und starten Sie eine großartige Zusammenarbeit.