Vielleicht haben Sie bereits bemerkt, dass unser S3-Produkt überarbeitet wurde und nun eine Migration zur Version 2 des Produktes möglich ist. In diesem Blogbeitrag möchten wir die Gründe rund um die Entscheidung, das Produkt zu überarbeiten, erläutern. Dabei möchten wir beleuchten, wie wir die technischen Herausforderungen angegangen sind und ein Fazit ziehen. Hat sich der Aufwand gelohnt? Also los, Kaffee (oder Tee) schnappen, es sich gemütlich machen und mit uns in die Details der Produktüberarbeitung eintauchen.
Warum
Die erste Version unseres S3-Service stellt eine Abstraktion eines von einem Drittanbieter bezogenen Managed Services dar. Dieses Servicepaket umfasst neben der Software auch den Support und die dedizierte Hardwareumgebung, die durch den Anbieter betrieben wird.
Bereits kurz nach der Einführung des S3-Produktes haben uns Kundenanfragen erreicht, bei denen uns klar wurde, dass die Umgebung entgegen ersten Tests nicht die Breite aller Kundenanforderungen erfüllt. In unserer Testumgebung konnten wir diese Erfahrungen reproduzieren. Teilweise niedriger Datendurchsatz und Verbindungsabbrüche verzögerten unsere Entwicklung teils erheblich. Leider waren unsere Beobachtungen nicht nur auf die Testumgebung beschränkt.
Die relevanten Leistungsmerkmale waren auch in der Produktionsumgebung ungenügend. Trotz des geschlossenen Servicevertrages konnte uns der Support des Anbieters keine praktikablen Lösungsansätze aufzeigen. Da einige unserer Produkte und Entwicklungsabläufe auf dem S3-Produkt aufbauen, konnten wir die Frustration unserer Kunden bestens nachvollziehen. Der Bedarf für eine Verbesserung des S3-Produktes war offensichtlich.
Aufgrund der technischen Einschränkungen des Produktes und des mangelnden Supports des Herstellers wurde uns früh bewusst, dass unser Ziel, eines auf Self-Service ausgerichteten, skalierbaren und leistungsfähigen S3-Produktes nur durch eine Neuentwicklung erreichbar ist.
Was
Unsere Evaluationskriterien umfassten neben der Leistungsfähigkeit insbesondere auch die Integrationsmöglichkeiten in unsere Self-Service API. Nach der Evaluation mehrerer Produkte haben wir uns für Nutanix Objects als künftige Lösung entschieden.
Da wir die Lösungen und Infrastruktur von Nutanix bereits in all unseren Rechenzentrumsstandorten für die Bereitstellung anderer Produkte nutzen, beispielsweise virtuelle Server und unser Produkt NKE, konnten wir auf den bestehenden Plattformen aufbauen und bereits existierende Automationsansätze über die Nutanix API für das neue Produkt ausbauen.
Wie
Ein bestehendes Produkt zu ersetzen, bringt besondere Anforderungen an das «Wie» einer Implementation mit sich. Nicht nur möchten wir unseren Kunden so schnell wie möglich ein besseres Produkt anbieten können, auch eine Datenmigration soll so einfach wie möglich vonstatten gehen. Von Beginn an lag unser Fokus darauf, unseren Kunden eine automatisierte Datenmigration anzubieten, die Ende zu Ende verschlüsselt die Daten innerhalb der Nine Infrastruktur migriert; ganz ohne unsere Kunden mit Down- oder Uploads von Daten zu beschäftigen.
Neben der Automation der Datenmigration war die Integration der Lösung in unsere Self-Service API essentiell. Auch hier sollte für unsere Kunden keine nennenswerte Änderung bei der Nutzung der API entstehen. Daher haben wir Unterschiede im Backend der API abstrahiert, so dass Kunden lediglich den Parameter "backendVersion" auf den Wert "v2" setzen müssen, um neue Buckets auf Basis des neuen Produktes zu erstellen. Zwischenzeitlich wurde dies als neuer Standard festgelegt.
Um ein “v1” Bucket zu migrieren, müssen die folgenden Informationen bereitgestellt werden:
- Ein “v1” Quell-Bucket sowie ein Benutzer mit Leseberechtigung
- Ein “v2” Ziel-Bucket sowie ein Benutzer mit Schreibberechtigung
- Festlegung eines Intervalls für den Abgleich der Buckets
- Ein Parameter, der angibt, ob Daten, die im Ziel-Bucket vorhanden sind, überschrieben werden sollen
Für die Datenmigration nutzen wir rclone, ein äusserst empfehlenswertes Tool für die Verwaltung von S3-Buckets. Für die Migration nutzen wir zwei rclone Funktionen: “sync” und “copy”.
“sync” synchronisiert das Ziel- mit dem Quell-Bucket. Dabei werden auch alle Daten im Ziel-Bucket entfernt, die nicht (mehr) im Quell-Bucket vorhanden sind.
|
rclone sync source:sourcepath dest:destpath |
“copy” hingegen kopiert die Daten im Quell-Bucket in das Ziel-Bucket, ohne Daten im Ziel-Bucket zu löschen.
|
rclone copy source:sourcepath dest:destpath |
Die rclone-Befehle werden in Kubernetes-Pods innerhalb unserer Infrastruktur ausgeführt. So stellen wir neben der Ende-zu-Ende-Verschlüsselung sicher, dass die Daten auch während der Migration unser Netzwerk nicht verlassen.
|
apiVersion: batch/v1 schedule: 7,22,37,52 * * * * |
Die abgebildete CronJob-Definition startet schlussendlich einen rclone KubernetesPod, der den Migrationsprozesses ausführt.
Im nächsten Schritt schauen wir uns an, wie eine Migration einer Applikation auf das neue S3-Produkt ablaufen kann. Exemplarisch migrieren wir eine Applikation, die wir selbst betreiben: Loki, einen Dienst zur Aggregation von Logfiles.
Vorbereitend wurde ein “v2”-Bucket erstellt. Für die Migration wurde ein “copy”-Job erstellt. Das Ziel-Bucket enthält keine Daten, ein “sync”-Job war daher nicht notwendig. Da auch später lediglich ein Delta des Quell-Buckets übertragen werden soll, könnte ein “sync”-Job gar zu einem Datenverlust führen, da wir im weiteren Verlauf die Applikation auf das Ziel-Bucket schreiben lassen.
Im ersten Schritt erstellen wir einen Bucket-Migration-Job über die Nine-API.
Nach dem ersten Durchlauf des Migrations-Jobs können wir Loki so konfigurieren, dass die Logs fortan in das “v2”-Bucket geschrieben werden.
Nachdem die Loki-Konfiguration angepasst wurde, lassen wir einen weiteren Migrations-Job ausführen So übertragen wir die Daten aus dem “v1”-Bucket, die zwischen der ersten Ausführung des Jobs und der Anpassung der Applikation auf das “v2”-Bucket geschrieben wurden.
Würden wir statt eines “copy”-Jobs einen “sync”-Job verwenden, würde das Delta im “v2”-Bucket gelöscht werden. Mit dem erneuten Abgleich der Buckets ist die Datenmigration und die Umstellung der Applikation abgeschlossen.
Fazit
Ein Produkt abzulösen stellt immer eine besondere Herausforderung dar. Leistung, Automatisierungsgrad, Simplizität in der Benutzung, der Migrationspfad und der Preis spielen in der finalen Betrachtung eine grosse Rolle.
Kunden haben uns vielfach berichtet, dass die Leistung des “v2” S3-Produktes merklich besser ist als die seines Vorgängers. In unseren automatisierten Code- und End-to-End Tests konnten wir dies ebenfalls beobachten. Wo wir vormals häufig mit Abbrüchen der Tests konfrontiert waren, ist das S3-Backend nun kein limitierender Faktor mehr. Leistungstests haben gezeigt, dass das Hochladen einzelner Objekte teils weniger als die Hälfte der Zeit benötigt, als dies auf der vorherigen Lösung der Fall war. Unser konsequenter Fokus auf Automatisierung, auch für die Datenmigration, baut den Automatisierungsgrad weiter aus.
Neben gesteigerter Leistung und ausgebauter Automation konnten wir den Preis für unsere Kunden drastisch senken. Das konsequente Aufbauen auf bestehenden Lösungen hat es uns erlaubt, den Preis um 66% von 0,09 CHF auf 0,03 CHF pro Monat und Gigabyte zu senken.
Wir sind glücklich, dass wir heute nicht nur ein schnelleres und verlässlicheres Produkt, sondern auch ein kostengünstigeres offerieren können.
Die Ablösung des bisherigen Produktes kann guten Gewissens als Win-Win-Situation bezeichnet werden, und wir könnten mit dem Ergebnis zufriedener kaum sein.
Ein Ausblick in die Zukunft
Derzeit ist die Funktion der Bucket Migration darauf beschränkt, Daten zwischen “v1”- und “v2”-Buckets zu synchronisieren. In naher Zukunft planen wir, diese Funktionalität zu erweitern und auch die Synchronisierung zwischen “v2”-Buckets zu unterstützen.
Darüber hinaus prüfen wir die Möglichkeit, die Migration extern betriebener Buckets zu ermöglichen. So wäre es beispielsweise denkbar, unser S3-Produkt zum Zweck eines Offsite-Backups zu nutzen; oder auf einfache Art und Weise Daten in unsere Umgebung zu migrieren. 🙂
Wir hoffen, unser Blog konnte Ihre Kaffee- oder Tee-Pause versüssen und freuen uns auf Ihre Rückmeldung. Sollten Sie eine Bucket-Migration planen und sich über Detailfragen unschlüssig sein, zögern Sie nicht, mit uns in Kontakt zu treten.
