Hosting wechseln: Datenstand und Umschaltung gemeinsam planen
Planen Sie Datenbank, Dateien und Schreibzugriffe gemeinsam. Ein ausgearbeiteter Ablauf trennt Vorbereitung, Umschaltung und den Rückweg nach neuen Änderungen.
Ein Hostingwechsel ist für Ihr Team abgeschlossen, wenn der vereinbarte Arbeitsablauf am neuen Standort mit dem richtigen Datenstand funktioniert. Legen Sie vorab fest, wann Änderungen angenommen werden, wer die Umschaltung freigibt und unter welchen Bedingungen das Team zurückkehren kann.
Den Ablauf und seine Schreibwege erfassen
Im erfundenen Beispiel betreibt ein Unternehmen das Kundenportal P-65. Ein Kunde erstellt die Anfrage A-65 mit der Anlage F-65. Datenbank und Dateiablage gehören zusammen. Neben dem Browser können eine Schnittstelle und ein Hintergrundprozess Daten verändern. Alle diese Schreibwege müssen in den Übergangsplan eingehen.
Für dieses Beispiel ist eine angekündigte Schreibpause vorgesehen. Das ist eine bewusst gewählte Variante, keine Forderung für jede Migration. Das Team beendet laufende Änderungen kontrolliert und hält fest, welche offenen Arbeiten später im Ziel fortgesetzt werden dürfen. Eine laufende Übernahme neuer Änderungen wäre ein anderes Verfahren mit eigener Synchronisations- und Konfliktprüfung.
Die Umschaltung als Arbeitsfolge vereinbaren
AWS empfiehlt, Abhängigkeiten, Aufgabenfolge, Zuständige, Prüfungen und Rückweg vor dem Wechsel festzuhalten und zu proben. Die folgende ausgefüllte Planvorlage enthält vorgesehene Schritte, keine Ergebnisse einer ausgeführten Migration.
Phase | Vereinbarung im Beispiel | Zuständige Rolle | Bedingung für den nächsten Schritt |
|---|---|---|---|
Vorbereitung | Zielumgebung mit konsistenter Datenbank- und Dateikopie prüfen. | Anwendungsteam | Anmeldung und erlaubter Zugriff funktionieren, unerlaubter Zugriff wird verweigert und die zugehörige Datei lässt sich im isolierten Test öffnen. |
Schreibpause | Annahme und Verarbeitung neuer Änderungen an allen alten Schreibwegen anhalten; letzten konsistenten Stand übertragen. | Betrieb und Anwendungsteam | Offene Arbeiten sind erfasst; Datenbank und Dateien passen zusammen. |
Freigabe | Geprüften Zielzugang öffnen und Änderungen nur am vorgesehenen neuen Schreibziel annehmen. | Fach- und Betriebsverantwortung | Führender Datenstand, Zugangsweg und Abbruchentscheidung sind eindeutig. |
Abbruch und Rückweg vorab unterscheiden
Microsoft empfiehlt, Abbruchkriterien und erprobte Rückkehrschritte auf die jeweilige Arbeitslast abzustimmen. Im Beispiel verhindert eine fehlende Anlage bereits die Freigabe. Solange im Ziel keine neuen Änderungen angenommen wurden, kann ein vorbereiteter Rückweg zum unverändert gehaltenen alten Stand passen.
Nach neuen Änderungen im Ziel reicht das Zurücksetzen der DNS-Adresse nicht aus. Diese Änderungen fehlen möglicherweise im alten System. Dann braucht der Rückweg einen geklärten führenden Datenstand und ein geprüftes Verfahren für die zwischenzeitlichen Änderungen. Bis dahin werden keine unkoordinierten parallelen Schreibwege geöffnet. Kann das Team diesen Fall nicht sicher behandeln, muss es den Übergangsplan vor der Freigabe ändern.
DNS und den Übergang gemeinsam abschließen
Die DNS-TTL beschreibt die reguläre Zwischenspeicherung einer Antwort. Manche Clients können deshalb noch den alten Zugang verwenden. Dessen Verhalten muss zur Schreibpause oder zum neuen führenden System passen; zwei unabhängig beschreibbare Kopien sind kein abgeschlossener Wechsel.
Prüfen Sie in einer geeigneten Testumgebung den vollständigen Ablauf einschließlich neuer Anfrage, Anlage, Rollen und Hintergrundarbeit. Externe Aktionen bleiben dort auf Testziele begrenzt. Planen Sie außerdem Beobachtung und einen verantwortlichen Kontakt nach der Freigabe. Der alte Dienst wird erst außer Betrieb genommen, wenn die vereinbarten Abschlussbedingungen und der Sicherungsweg geklärt sind.
Quellen
Weiterlesen
Alle Beiträge
Cloud & Betrieb mit ASES
Hosting, Deployment, Wartung und Betreuung