Erste Überlegungen
Probleme, die Sie vor der Migration berücksichtigen sollten:
DNS-Änderungen-sind-nicht-automatisch, also-müssen-Sie-einen -Plan! !
Wenn sich Ihr Cloud-Server nicht hinter einem Load Balancer befindet, wird es eine IP-Änderung geben. Das bedeutet, dass Sie Ihre DNS-Einträge auf die neue IP ändern müssen. Wir empfehlen, die TTL („Time to live“) auf einen niedrigen Wert (300 Sekunden / 5 Minuten) zu überprüfen und mindestens 24 Stunden zu warten, bis die Änderung wirksam wird. Diese Änderung stellt sicher, dass alle Änderungen, die Sie an Ihrem DNS vornehmen, innerhalb von 5 Minuten oder weniger durch das System weitergegeben werden.
Wozu dient dieser Server?
Es ist wichtig, sich Zeit zu nehmen, um festzustellen, welche Rolle der Server übernimmt. Nur für Webanwendungen? Hosten Sie E-Mail Gibt es Datenbanken? Eine gute Erstbewertung kann viel Zeit sparen und Last-Minute-Panik vermeiden, wenn Sie vom alten Server auf den neuen wechseln. Es ist wichtig zu identifizieren, wo sich Ihre Daten, Konfigurationsdateien usw. befinden. Ein gutes Verständnis Ihrer Umgebung hilft Ihnen bei einer erfolgreichen Migration.
Probieren Sie die Migration mit einem Puffer aus!
Einer der Vorteile der Cloud-Migration ist, wie schnell und einfach es ist, einen Server zu erstellen oder zu entfernen. Wir empfehlen Ihnen, sobald Sie sich für bereit halten, zwischen dem alten und dem neuen Server zu wechseln, den alten Server nur herunterzufahren und ihn noch nicht zu löschen. Lassen Sie es zwischen 24 Stunden und einer Woche in diesem Zustand. Wenn Sie feststellen, dass Ihre Website oder andere Anwendung ordnungsgemäß funktioniert, können Sie die Migration wahrscheinlich als abgeschlossen betrachten. Wenn Sie beim Herunterfahren des alten Servers Probleme bemerken, haben Sie möglicherweise nicht alles migriert, was migriert werden musste. Sie haben immer noch den alten Server, sodass Sie ihn wieder einschalten können (wählen Sie die Option „Neustart“ im Portal)
Den Job machen
Überprüfen Sie die Größe des alten Servers
Um den auf Ihrem neuen Server erforderlichen Mindestspeicherplatz zu bestimmen, müssen Sie wissen, wie viel Ihr alter Server belegt.
Sie können den folgenden Befehl verwenden, um die Festplattennutzung Ihres alten Servers zu überwachen:
df -h
Wenn Sie mehr als 160 GB benötigen (die maximale Festplattengröße für einen „Allzweck“-Server), müssen Sie Cloud Block Storage-Volumes auf dem neuen Server verwenden, um alle Ihre Daten zu speichern.
Verzeichnisanforderungen identifizieren
Wenn Sie Cloud Block Storage-Volumes einrichten, sollten Sie die Größe der Verzeichnisse auf Ihrem Ursprungsserver überprüfen. Diese Informationen helfen Ihnen bei der Planung der Organisation von Informationen auf dem neuen Server und geben an, welche Informationen auf der Systemfestplatte gespeichert werden und welche anderen Informationen auf zusätzlichen Volumes gespeichert werden.
Unter Linux können Sie den von Dateien und Verzeichnissen belegten Speicherplatz mit folgendem Befehl ermitteln:
du -hs *
Sie können den Namen des Verzeichnisses oder der Datei auch mit dem folgenden Befehl angeben:
du -hs NombredeDirectorio
Sobald Sie wissen, welche Informationen Sie auf die Systemfestplatte und welche Informationen Sie auf die zusätzliche Festplatte kopieren werden, können Sie die Größe des neuen Servers und seiner zusätzlichen Volumes planen.
Zielserver erstellen
Beim Erstellen des Zielservers ist es wichtig, die Anforderungen an Festplattenspeicher sowie Arbeitsspeicher, CPU und Netzwerk zu berücksichtigen.
Wenn die Größe Ihrer Daten die Größe der Systemfestplatte des Servers überschreitet, müssen Sie entscheiden, ob Sie eine oder mehrere zusätzliche Festplatten (nur E/A-Typ-Server) oder ein Cloud Block Storage-Volume verwenden möchten Berücksichtigen Sie die aktuellen Anforderungen sowie zukünftige Anforderungen.
Die Größe von E/A-optimierten Servern kann nach der Erstellung nicht mehr geändert werden. Sie können also nur Speicherplatz mithilfe von Cloud Block Storage hinzufügen oder entfernen. Server vom Typ „Universal“ haben eine maximale Größe von 8 GB RAM/160 GB auf der Festplatte. Nur Server vom Typ „General Purpose“, die nicht den Virtualisierungsmodus Precate Paravirtual (PV) verwenden, können ihre Größe ändern.
In einer Umgebung mit einem einzelnen Server ist es zum Ändern von RAM- oder CPU-Ressourcen erforderlich, auf einen neuen Server zu migrieren.
Wenn Sie davon ausgehen, dass Ressourcen in Ihrer Umgebung erhöht oder verringert werden müssen, können Sie Ihre Lösung so entwerfen, dass sie die Vorteile der horizontalen Skalierung nutzt.Mit einem Load Balancer können Sie Ihre Anwendung auf mehreren Knoten ausführen und Sie können Knoten hinzufügen oder entfernen die Belastung ändert sich. Zu beachten ist, dass die horizontale Skalierung nicht unbedingt für alle Anwendungen die richtige ist.
Der Artikel zur offenen Cloud-Referenzarchitektur veranschaulicht einige Beispiele verschiedener Cloud-Umgebungen.
Hinweis: Wenn Sie Server vom Typ Performance verwenden, ist es wichtig zu beachten, dass die Datenfestplatten nicht enthalten sind, wenn Sie ein Image erstellen.Um Datenfestplatten zu sichern, müssen Sie den RackspaceCloud Backup-Dienst oder eine andere ähnliche Lösung verwenden. Wenn Ihr Speicher portabel sein muss oder Sie Snapshots erstellen müssen, empfehlen wir die Verwendung von Cloud Block Storage-Volumes.
Cloud Block Storage-Volumes oder -Datenträger vorbereiten
Nachdem der neue Server erstellt wurde, müssen die Datenträger für Daten oder Cloud Block Storage vorbereitet werden, indem der Datenträger formatiert und das Betriebssystem für die Verwendung konfiguriert wird.
Informationen zum Vorbereiten von Cloud Block Storage finden Sie unter Cloud Block Storage-Volume vorbereiten.
Informationen zum Vorbereiten von Datenfestplatten auf E/A-optimierten Servern finden Sie unter Vorbereiten von Datenfestplatten auf einem Linux-Cloud-Server.
Wenn Sie die zusätzlichen Festplatten in der RAID-Konfiguration unter Linux verwenden möchten, sehen Sie sich Linux Software-RAID HOWTO an.
Optionen für die manuelle Migration
Es gibt mehrere Optionen für eine manuelle Migration unter Linux, darunter Rackspace Cloud Backup, Rackspace Cloud Block Storage oder rsync.
Cloud-Sicherung
Um bestimmte Verzeichnisse zu migrieren, können Sie Cloud Backup verwenden. Sie können eine Sicherungskopie Ihrer Daten auf dem Quellserver erstellen und auf dem Zielserver wiederherstellen.
###Cloud-Blockspeicher
Um bestimmte Daten zu migrieren, können Sie Cloud Block Storage verwenden. Sie fügen die Festplatte Ihrem Ursprungsserver hinzu und kopieren die Daten. Dann unmounten Sie es vom Quellserver, mounten es auf dem Zielserver und kopieren die Daten.
rsync unter Linux für die Verzeichnismigration
Unter Linux können Sie mit rsync ein Verzeichnis direkt über das Netzwerk kopieren. Beispielsweise können Sie auf dem Quellserver den folgenden Befehl ausführen, um /var/lib/mysql:
zu kopierenrsync -e 'ssh' -avl --stats --progress /var/lib/mysql [email protected]:/var/lib/mysql
Wichtig: Wenn sich die beiden Cloud-Server im selben regionalen Rechenzentrum (DFW, ORD, IAD, LON, HKG, SYD) befinden, können Sie die den beiden Servern zugewiesene 10.x-IP-Adresse zur Übertragung Ihrer Daten verwenden. Wenn Sie dieses Netzwerk verwenden, werden Ihnen keine Gebühren für die Nutzung der Bandbreite zwischen Servern berechnet. Wenn Sie die Daten über die öffentliche IP-Adresse übertragen, fallen Gebühren für die Bandbreitennutzung an.
Weitere Informationen zu rsync finden Sie unter Sichern Sie Ihre Dateien mit rsync.
Anwendungsspezifische Optionen
Andere Anwendungen können ihre eigenen Mittel haben, um die Datenmigration zu erleichtern. Um beispielsweise eine Datenbank zu migrieren, können Sie eine Slave-Instanz auf dem Zielserver erstellen und die Daten automatisch vom Quellserver replizieren. Informationen zum Erstellen einer Master-Slave-Replikation finden Sie hier.
Aufgaben nach der Migration
Sobald sich alle Ihre Daten auf dem Zielserver befinden, empfehlen wir, Ihre Anwendung gründlich zu testen, um sicherzustellen, dass sie wie erwartet ausgeführt wird. Wie bereits zu Beginn dieses Artikels erwähnt, empfehlen wir, den Ursprungsserver herunterzufahren, aber nicht zu löschen. Warten Sie 1–7 Tage, bis Sie feststellen können, ob bei der Migration, bei der die alte IP-Adresse verwendet wurde, etwas fehlte. Wenn nach 7 Tagen alles in Ordnung zu sein scheint, ist es im Allgemeinen sicher, mit dem Löschen des Ursprungsservers fortzufahren.
Falls noch nicht geschehen, ist jetzt ein guter Zeitpunkt, um einen Backup-Plan auf dem Zielserver zu implementieren.
