Geschmeidige Datenmigration zwischen MinIO-Services mithilfe des MinIO-Clients
In der Kubernetes-Landschaft unseres Kunden Contargo kommen mehrere Object-Storage-Services in Form von MinIO-Clustern zum Einsatz. Diese dienen u.a. als Storage für Datenbankbackups, aber auch für Assets. Aufgrund eines größeren Landschaftsumbaus müssen diese Services migriert werden. Das Vorgehen wiederholt sich, sodass sich eine Teilautomatisierung lohnt.
Synchronisation der Daten
Im Laufe der Migration erfolgt eine Umkonfiguration der Domain, die auf das MinIO-Cluster zeigt. Da diese Umkonfiguration durch DNS-Caches nicht garantiert zeitgleich bei allen Clients ankommt können geschriebene Daten sowohl im alten als auch im neuen Cluster landen. Eine dauerhafte Synchronisation hilft, die Daten in beiden Clustern synchron zu halten, bis bei allen Clients die DNS-Umstellung angekommen ist.
MinIO-Client als Helfer
MinIO-Client (kurz mc
) bietet das Kommando mirror
an, welches im Stil von rsync
Daten von beispielsweise einem MinIO-Cluster in ein anderes synchronisieren kann.
Eine dauerhafte Synchronisation der Daten ermöglicht die mc mirror
-Option --watch
.
Kubernetes als Umgebung
Kubernetes bietet die Möglichkeit, sehr einfach einen Pod mit MinIO-Client zu deployen, der das Synchronisieren übernehmen kann. Ein Kubernetes-Deployment bietet sich an, um sicherzugehen, dass der minio-client
-Pod bei Terminierung wieder erstellt wird.
Die betroffenen MinIO-Cluster werden in Kubernetes betrieben. Das Deployment wird im Namespace des alten MinIO-Clusters konfiguriert, also der Quelle. Das ermöglicht bereits den Zugriff auf die in einem Secret abgelegten root-Zugangsdaten, die für die globale Synchronisation gebraucht werden.
Kubernetes-Konfigurationen für die Migration der Daten
Das minio-client
-Image von Bitnami bietet die passende Umgebung für die Synchronisation und ist die Grundlage für das Deployment.
Der Entrypoints des Images muss überschrieben werden, da das Image darauf ausgelegt ist genau ein mc
-Kommando auszuführen.
Um Aliasse für das Quell- und das Ziel-Cluster zu hinterlegen und danach die Synchronisation zu starten müssen allerdings mehrere Kommandos hintereinander ausgeführt werden.
Die Zugangsdaten der MinIO-Services werden vom Deployment als Umgebungsvariable erwartet. Die Werte können sich aus Secrets oder ConfigMaps speisen.
Der Quellservice ist auf Basis des Bitnami MinIO-Helm-Charts deployed und die root-Zugangsdaten bereits in einem Secret hinterlegt. Die root-Zugangsdaten des Zielservices werden ebenfalls in einem Secret konfiguriert.
Nun kann mit mc mirror --fake
geprüft werden, ob die Verbindung steht und Daten übertragen werden würden.
Kommt die Verbindung erfolgreich zustande, kann --fake
durch --watch
ersetzt werden. Nachdem die Konfiguration deployed wurde, sollte die eigentliche Synchronisation starten. Im Log des minio-client
-Pods sollten Logs erscheinen, die den folgenden ähneln:
Contargo/k8s-mc-mirror
Alle angesprochenen Konfigurationen sind auf GitHub im Projekt Contargo/k8s-mc-mirror verfügbar und dokumentiert. MinIO-Client unterstützt übrigens nicht nur MinIO-Services, sondern ist auch zu Amazon S3 Cloud-Storages kompatibel, sodass der Anwendungsfall dahingehend erweitert werden kann.