Analysieren der Entscheidungskriterien für die Toolauswahl und das Migrationsmodell
Nachdem Sie nun die Optionen für Migrationsmethoden und -tools untersucht haben, können Sie die Entscheidungskriterien für die Durchführung der Migration zu Azure Database for PostgreSQL – Flexibler Server untersuchen. Die drei Hauptkriterien für Ihre Entscheidungen sind Downtime, Speicherort der Quelldatenbank und Anpassbarkeit.
Ausfallzeit
Die Downtime ist ein wichtiger Aspekt von Migrationsaktivitäten. Sie legt die Dauer fest, die für alle Projektbeteiligten akzeptabel ist, und sie hilft bei der Entscheidung, ob eine Offline- oder Onlinemigrationsaktivität ausgeführt werden soll.
Normalerweise werden Migrationsaktivitäten bereits im Voraus geplant, um sicherzustellen, dass geeignete Änderungskontrollen und zugehörige Governancemaßnahmen für die Aktivität ausgeführt werden. Diese Planung ermöglicht, im Dialog mit wichtigen Projektbeteiligten zu verstehen, wie lange das System offline sein kann. In solchen Situationen ist es ratsam zu wissen, wie lange die verschiedenen Optionen dauern, damit Sie geschätzte Mindest- und Höchstausfallzeit festlegen können.
Die Festlegung der minimalen für die Durchführung einer Anwendungsübertragung erforderlichen Downtime ist dabei besonders wichtig. Letztendlich ist dies die Zeit, die Sie das System offline schalten müssen – selbst bei einer Onlinemigration (oder einer Migration mit minimaler Downtime). Dieser Zeitrahmen hängt von der Komplexität der Anwendung ab. Bei einer relativ einfachen Anwendung kann dieser Prozess lediglich das Beenden eines Diensts, das Aktualisieren einer Konfigurationsdatei und das erneute Aktivieren eines Diensts umfassen. In komplexeren Umgebungen kann dieser Prozess viel länger dauern, z. B. wenn mehrere Server und Anwendungsebenen beteiligt sind.
Die Kenntnis der Dauer von Online- oder Offlinemigrationsaktivitäten ist der nächste wichtige Faktor im Zusammenhang mit der Downtime. Wenn es sich um eine Offlinemigration handelt, umfasst die Downtime die Zeit zum Extrahieren, Übertragen und Laden der Daten aus der Quelle an das Ziel, gefolgt von Validierung und Überprüfung. Diese Downtime liegt zwischen der Deaktivierung und der erneuten Aktivierung der App oder Workload.
Bei einer Onlinemigration (oder einer Migration mit minimaler Downtime) ist die Downtime die Zeit, die erforderlich ist, um die letzten Änderungen an der Quelle mit dem Ziel zu synchronisieren, nachdem die Anwendung deaktiviert wurde. Verlängert wird diese Downtime durch die Validierungs- und Überprüfungsaktivitäten vor der Neukonfiguration und der Aktivierung der App oder Workload.
Wenn Sie diese Informationen kennen, können Sie sich die technischen Aspekte der Migration ansehen, um die geeigneten Optionen zu ermitteln.
Speicherort der Quelldatenbank
Der Quellspeicherort der zu migrierenden Datenbanken spielt aufgrund der wahrscheinlichen Einschränkungen einer bestimmten Konfiguration eine Rolle.
Lokale oder Azure-fremde Quellen
Bei einer lokalen oder nicht in Azure gespeicherten Datenbank ist die wichtigste Einschränkung in der Regel die Netzwerkkonnektivität zwischen Quelle und Ziel. Die drei Punkte, die Sie berücksichtigen sollten, sind Bandbreite, Latenz und Datenvolumen. Wenn Sie diese Punkte verstanden haben, können Sie eine fundierte Entscheidung darüber treffen, welcher Typ von Migration anwendbar ist.
Wenn ein großes Datenvolumen migriert werden soll, aber nur eine proportional niedrige Bandbreite verfügbar ist, werden eine einfache Sicherung und Wiederherstellung wahrscheinlich nicht möglich sein. Wenn Sie über ein großes Datenvolumen und eine große Bandbreite verfügen, ist dies weniger bedenklich.
Wenn es sich um eine Onlinemigration handelt, bei der eine Datensynchronisierung stattfindet, ist die Latenz einer der wichtigsten Faktoren. Wenn die Latenz hoch ist, kann es zu negativen Auswirkungen auf die Systemleistung kommen, da der Synchronisierungsprozess lange dauert.
Ein wichtiger Faktor, der auch bei der Migration von anderen Cloudanbietern berücksichtigt werden muss, sind mögliche Gebühren für den Datenausgang. In diesem Fall könnten Sie überlegen, den physischen Fußabdruck der zu übertragenden Daten zu minimieren. In solchen Situationen kann die Komprimierungstechnologie für Sicherungen oder Datenströme wichtig sein, die für die Synchronisierung verwendet werden.
Andere Azure-basierte Dienste
Es gibt Situationen, in denen Sie von anderen Azure-basierten Diensten zu Azure Database for PostgreSQL – Flexibler Server migrieren möchten. Diese Quelldatenbanken können sich auf Azure-VMs, in Azure-Containern oder in Azure Database for PostgreSQL – Einzelserver befinden. In diesem Fall sind andere Überlegungen erforderlich, es gibt aber in solchen Szenarien gleichzeitig mehrere Möglichkeiten, um von Optimierungen innerhalb der Azure-Dienste zu profitieren.
Anpassbarkeit
Der letzte Aspekt ist, wie viele Anpassungen erforderlich oder gewünscht sind. Dies kann z. B. Änderungen an der Quelldatenbankstruktur zur Unterstützung der Datenreplikation umfassen, oder es könnte Einfluss darauf haben, wie einfach eine Automatisierung per Skripts für Sie ist.
Ein gutes Beispiel ist die Automatisierung der Offlinemigration einer Datenbank mit pg_dump und pg_restore mit gleichzeitiger Komprimierung und Dekomprimierung der Speichersicherungsdateien.
Entscheidungsfindung
Nachdem Sie nun den Prozess zum Sammeln aller dieser Informationen durchlaufen haben, können Sie mit allen Beteiligten zusammenarbeiten, um die beste Option für ein bestimmtes Szenario zu ermitteln. Bei der Entscheidung, welche Methoden und Technologien verwendet werden sollen, ist es wichtig, nicht nur mit den Geschäftsbeteiligten, sondern auch mit den technischen Projektbeteiligten zusammenzuarbeiten. Diese Zusammenarbeit trägt dazu bei, Situationen zu vermeiden, in denen das Unternehmen eine Migration mit minimaler Downtime anstrebt, die das technische Team aufgrund von Personal-, Ressourcen- oder Technologieeinschränkungen nicht bewerkstelligen kann.
In diesem Fall ist es das Wichtigste, die Erwartungen zu kommunizieren und einen offenen und ehrlichen Dialog zu führen. Es ist auch wichtig sicherzustellen, dass das Unternehmen Validierungsaufgaben übernimmt, die außerhalb des Aufgabenbereichs der technischen Teams liegen, die die Datenbankmigration durchführen. Diese Validierung kann Datenkonsistenz- und andere Überprüfungen sowie Tests der Benutzererfahrung umfassen.