Infra as a Service

Migrieren Sie Ihren Amazon S3-kompatiblen Objektspeicher zu einer europäischen Cloud-Infrastruktur, ohne Ihren Code zu ändern.

Behalten Sie die S3 API-Aufrufe Ihrer Anwendung bei, während Sie den Speicherendpunkt, die Anmeldeinformationen und Bereitstellungskonfiguration ändern. Dieser praktische Prozess umfasst die Übertragung von Objektdaten, die Validierung und das Cutover für die Produktion, Backups und regulierte Workloads. OVHcloud ist eine der führenden Alternativen zu Amazon S3 und unterstützt rund 80 % der Use Cases in der Produktion.
Migration ProgramObject Storage
OVHcloud_Public_Cloud_Generic_White_600x400.png

Operative Belege für eine kontrollierte europäische Migration

Überprüfen Sie die regionale Verfügbarkeit und Einschränkungen, bevor Sie den Storage zur europäischen Cloud migrieren.
Gear.svg
Native S3-API, fünf Speicherklassen und vier Bereitstellungsmodi
Gear.svg
Multi-Zone erstreckt sich über drei Zonen mit einem Verfügbarkeits-SLA von 99,99 %
Gear.svg
S3-Daten zu einer europäischen Cloud migrieren und die Datensouveränität stärken
Gear.svg
ISO-Zertifizierungen decken die meisten Regionen ab, HDS verfügbar

S3-kompatibel bedeutet nicht automatisch identisch

S3-kompatibler Objektspeicher

Mit dem S3-kompatiblen Objektspeicher bleiben gängige Operationen wie das Erstellen von Buckets, das Schreiben von Objekten, das Lesen von Daten und das Generieren vorab signierter URLs erhalten. Er reproduziert aber nicht jedes Verhalten der Originalplattform. Eine Anwendung kann fehlerfrei kompilieren und eine Verbindung herstellen, obwohl sie immer noch von einem nicht unterstützten API-Aufruf, einem nicht unterstützten Antwortformat oder einem nicht unterstützten SDK-Standardwert abhängt.

Was OVHcloud bietet

OVHcloud Object Storage ist eine starke europäische S3-Alternative für gängige Produktions- und Backup-Workloads sowie Workloads mit regulierten Daten. Überprüfen Sie die Kompatibilität im Hinblick auf S3-API-Operationen, das SDK-Verhalten und Service-Funktionen, die Ihre Anwendung benötigt. Wenn eine erforderliche Abhängigkeit nicht unterstützt wird, müssen Sie möglicherweise den Code ändern oder die Workload anders verwalten.

Inventarisierung vor Datenmigration

Erstellen Sie vor der Datenmigration ein Inventar. Halten Sie alles fest: API-Operationen, SDK und Version, Konsolen-Workflows, Wiederholungsregeln, Ereignisabhängigkeiten und Bucket-Features. Überprüfen Sie die Lebenszyklusregeln, Replikation, Versionierung, Objektsperre, Verschlüsselung, ACLs und CORS. Vergewissern Sie sich, dass das erforderliche Sicherheits- und Verschlüsselungsmodell in der gewählten Region verfügbar ist.

Echtes Nutzerverhalten

Bei der Überprüfung muss das tatsächliche Nutzerverhalten berücksichtigt werden. Testen Sie repräsentative Objektgrößen, die Anzahl gleichzeitiger Anfragen, Auflistungsmuster und die Fehlerbehandlung. Die Performance sollte am Standort der Anwendungsbereitstellung in Europa gemessen und nicht von einem generischen Benchmark abgeleitet werden.

Ziel über Konfiguration ändern

Um S3 zu europäischer Cloud-Infrastruktur zu migrieren, ersetzen Sie die bestehende Adresse mit dem europäischen Ziel-Endpunkt und stellen Sie neu erstellte Zugangsdaten bereit. Behalten Sie die gleichen S3-Client- und Objektoperationen bei, wenn die Plattform sie unterstützt. Speichern Sie jedes Secret in einem verwalteten Vault, nicht in Code. Erstellen Sie IAM-äquivalente Berechtigungen mit nur dem Zugriff, den die Software erfordert. Dieser Schritt begrenzt das Risiko, wenn Anmeldeinformationen kompromittiert werden. Behandeln Sie den Endpunkt-Wechsel als Konfigurationsänderung für Nicht-Produktionstests. Eine erfolgreiche Verbindung beweist weder, dass die gespeicherten Daten vollständig sind noch dass das komplette Systemverhalten fehlerfrei bereitsteht. Nutzen Sie den Deployment-Guide, um die neue Ansicht festzuhalten, bevor öffentlicher Traffic ankommt oder die Datenübertragung beginnt.
[object Object]
Kartieren Sie jede S3-API-Operation, die von der bestehenden Anwendung verwendet wird. Erfassen Sie die Objekt- und Dateigröße, Anforderungsfrequenz, Parallelität, Latenzziele und Fehlerbehandlung. Vergleichen Sie diese Anforderungen mit den unterstützten Produktfeatures, bevor Sie mit dem Testen beginnen. Die Bereitschaft hängt vom vollständigen Produktionspfad ab, nicht von einem erfolgreichen Test-Upload. Verwenden Sie repräsentativen Traffic und typische Daten, um zu entscheiden, ob S3 zu europäischer Cloud-Infrastruktur migriert werden soll.
Für eine Backup-Workload sind Katalogintegrität, Aufbewahrungsrichtlinien, Unveränderlichkeit und eine zuverlässige Wiederherstellung essenziell. OVHcloud Object Storage ist Veeam Ready-zertifiziert und laut Angaben mit HYCU, Cohesity, Veritas NetBackup und CloudCasa kompatibel. Überprüfen Sie die genaue Software-Version und Konfiguration. Stellen Sie dann repräsentative Daten in einer isolierten Umgebung wieder her. Das Angebot muss sowohl den geplanten Schutz als auch die Wiederherstellungsstrategie unterstützen, einschließlich der Wiederherstellungszeit und der Aufbewahrungsanforderungen.
Regulierte Workloads erfordern Kontrollen, die auf das geltende Recht und interne Richtlinien abgestimmt sind. Bewerten Sie Zuständigkeiten (Jurisdiktion), Verschlüsselung, Object Lock, Schlüsselbesitz, Aufbewahrungsfristen und Löschverfahren. Identifizieren Sie, wo sich jede Datenkopie, jeder Verschlüsselungsschlüssel und jedes Betriebsprotokoll befindet. Eine Service-Zertifizierung kann die Compliance unterstützen, stellt jedoch keine Compliance für Ihren spezifischen Verarbeitungskontext her. Nutzen Sie diese Ergebnisse, um einen Proof of Concept zu starten, die Architektur zu überarbeiten oder ausgewählte Buckets beim bestehenden Anbieter zu belassen. Eine schrittweise Strategie ermöglicht es, zuerst geeigneten Speicher zu migrieren, während Abhängigkeiten, die Codeänderungen oder eine weitere Validierung erfordern, an der Quelle verbleiben.
Kartieren Sie jede S3-API-Operation, die von der bestehenden Anwendung verwendet wird. Erfassen Sie die Objekt- und Dateigröße, Anforderungsfrequenz, Parallelität, Latenzziele und Fehlerbehandlung. Vergleichen Sie diese Anforderungen mit den unterstützten Produktfeatures, bevor Sie mit dem Testen beginnen. Die Bereitschaft hängt vom vollständigen Produktionspfad ab, nicht von einem erfolgreichen Test-Upload. Verwenden Sie repräsentativen Traffic und typische Daten, um zu entscheiden, ob S3 zu europäischer Cloud-Infrastruktur migriert werden soll.

Eine den betrieblichen Anforderungen entsprechende Übertragungsart wählen

Objekte mit rclone 
kopieren

Verwenden Sie rclone, um Objekt-Sets zwischen dem Quell- und dem Zielservice zu übertragen. Behalten Sie unterstützte Metadaten wo möglich bei, prüfen Sie die Parallelität und vergleichen Sie die Prüfsummen oder Listen danach. Planen Sie genug Zeit für Wiederholungen und Abstimmungen ein.

Backup-Management beibehalten

Zertifizierte oder kompatible Backup-Software ist besser geeignet, wenn Katalogisierung, Aufbewahrung, Wiederherstellungsreihenfolge und Richtliniendurchsetzung wichtiger sind als eine reine Datenkopie. Validieren Sie Schutz und Wiederherstellung über denselben Produkt-Workflow, der auch in der Produktion verwendet wird.

Native Übertragungstools 
verwenden

Die CLI oder MinIO mc können kontrollierte, skriptbare Kopieraufträge erstellen. Schränken Sie die Zugriffsberechtigungen ein, erfassen Sie Protokolle und stellen Sie sicher, dass fehlgeschlagene Objekte identifiziert und erneut übertragen werden können, ohne den gesamten Transfer neu starten zu müssen.

Standort auswählen

Wählen Sie Frankreich, Deutschland oder eine andere verfügbare europäische Region aus, je nachdem, was sich im Hinblick auf Datenresidenz, Latenz und Compliance-Richtlinien für Sie eignet. S3-kompatibler Objektspeicher in Europa erfordert eine standortspezifische Überprüfung der Dienstverfügbarkeit und organisatorische Zugriffskontrollen.

Ziel als Code angeben

S3-APITerraform
Verwenden Sie Terraform, um Bucket, Region, Speicherklasse, Versionierung, Lebenszykluseinstellungen und Zugriffssteuerungsrichtlinien vor der Migration zu definieren. Vergleichen Sie den resultierenden Zustand mit dem genehmigten Design und den Quellanforderungen. Wählen Sie Single-Zone oder Multi-Zone entsprechend der Latenz, Verfügbarkeit und Kritikalität der Workloads. Multi-Zone erstreckt sich über drei Availability Zones und umfasst ein SLA von 99,99 %. Für Kubernetes und andere Container-Workloads stellen Sie Zugangsdaten und Richtlinien über die Deployment-Pipeline bereit. Diese kontrollierte Grundlage hilft Teams, von S3 zu OVHcloud zu wechseln, ohne eine nicht verwaltete digitale Infrastruktur zu erstellen. Die Quelle bleibt maßgeblich, bis die Validierung abgeschlossen ist.
Technisches Diagramm von S3-kompatiblen Anwendungen und SDKs, die über einen geänderten Endpunkt mit OVHcloud Object Storage verbunden sind, mit Kompatibilitätsprüfungen

Vier kontrollierten Phasen für die Migration

1. Provisionierung 
des Ziels

Erstellen Sie den Bucket, die Zugriffsrichtlinien und die erforderlichen Einstellungen mit Terraform oder der CLI. Erfassen Sie die OVHcloud Region, die Speicherklasse, die Versionierung und die Aufbewahrungskonfiguration. Überprüfen Sie kontinuierlich die Infrastrukturdefinitionen, damit die bereitgestellte Lösung dem genehmigten Standard entspricht.

2. Übertragung, wobei die Quelle maßgeblich bleibt

Kopieren Sie Objekte mit rclone oder anderen unterstützten Tools. Belassen Sie Lese- und Schreibzugriffe der Produktion während des ersten Transfers auf dem Quellanbieter. Planen Sie Quell-Egress, temporären Speicher, Tools und Arbeitsaufwand in den Migrationskosten ein. Der Egress des Ziel-Objektspeichers ist kostenlos, das Gesamtprojekt ist es jedoch nicht.

3. Daten 
und Verhalten überprüfen

Vergleichen Sie Objektanzahl, Gesamtgrößen, Prüfsummen, Metadaten und repräsentative Lesevorgänge. Testen Sie Multipart-Uploads, Lifecycle-Aktionen, Zugriffskontrollen und Wiederherstellungsvorgänge, sofern relevant. Gehen Sie jeder Abweichung nach, statt sich auf Stichproben zu verlassen, durch die mögliche Risiken unentdeckt bleiben.

4. Umstellung mit einem Rollback-Zeitfenster

Pausieren Sie Schreibvorgänge oder gleichen Sie Änderungen ab, die nach der ersten Kopie vorgenommen wurden. Aktualisieren Sie Anmeldeinformationen und den Endpunkt und leiten Sie den Datenverkehr anschließend innerhalb eines kontrollierten Zeitfensters um. Überwachen Sie Fehlerraten, Latenzzeiten von Anfragen und Anwendungsprotokolle. Behalten Sie die Quelle sowie einen dokumentierten Weg zur Rückabwicklung bei, bis die Abnahmekriterien erfüllt sind.

Jurisdiktion, Betrieb und Kosten berücksichtigen

Eine europäische Cloud-Region definiert den Standort der Daten. Für die Souveränität sind aber auch noch andere Aspekte entscheidend, darunter die Eigentumsverhältnisse des Anbieters, die geltende Rechtsordnung und die Frage, ob ausländische Behörden Zugriff verlangen können. Prüfen Sie deshalb die relevanten Servicebedingungen und verifizieren Sie diese Aspekte unabhängig. Für eine S3-Migration ohne Codeänderungen sollten Sie API-Abdeckung, Ziel-Endpunkt, Verfügbarkeitskonzept, Support, Zertifizierungen und das Enterprise-Betriebsmodell vergleichen. Für Serverless-Anwendungen können andere Anforderungen in Sachen Latenz und Anfragen gelten. Bei der Preisgestaltung müssen der Datenexport aus der Quellumgebung, die doppelte Speicherung, Tools, der Engineering-Aufwand und das Ausfallrisiko berücksichtigt werden. Ein Zielsystem ohne Egress-Gebühren kann die laufenden Kosten zwar reduzieren, aber auch eine Migration ohne Egress-Kosten ist nicht kostenlos.
Wählen Sie den Support, der zu Ihrem Migrationsumfang passt.
Migrationsexpert:innen kontaktieren