Hosting wijzigen: plan gegevens en omschakeling samen
Plan database, bestanden en schrijftoegang samen. Een uitgewerkt plan scheidt voorbereiding, omschakeling en terugkeer na nieuwe wijzigingen.
Een hostingwissel is voor uw team afgerond als de afgesproken werkwijze op de nieuwe locatie met de juiste gegevensstand werkt. Leg vooraf vast wanneer wijzigingen worden aangenomen, wie de omschakeling vrijgeeft en onder welke voorwaarden het team kan terugkeren.
De werkwijze en schrijfpaden vastleggen
In het fictieve voorbeeld beheert een bedrijf het klantportaal P-65. Een klant maakt aanvraag A-65 met bijlage F-65 aan. Database en bestandsopslag horen bij elkaar. Naast de browser kunnen een interface en een achtergrondproces gegevens wijzigen. Al deze schrijfpaden moeten in het overgangsplan staan.
Dit voorbeeld voorziet in een aangekondigde schrijfpauze. Dat is een bewuste keuze, geen eis voor iedere migratie. Het team rondt lopende wijzigingen gecontroleerd af en legt vast welke open taken op de bestemming mogen doorgaan. Nieuwe wijzigingen voortdurend overnemen zou een andere methode zijn, met eigen synchronisatie- en conflictcontroles.
De omschakeling als werkvolgorde afspreken
AWS adviseert afhankelijkheden, taakvolgorde, verantwoordelijken, controles en terugkeer vooraf vast te leggen en te oefenen. Het ingevulde plansjabloon bevat voorgenomen stappen, geen resultaten van een uitgevoerde migratie.
Fase | Afspraak in het voorbeeld | Verantwoordelijke rol | Voorwaarde voor de volgende stap |
|---|---|---|---|
Voorbereiding | Doelomgeving met een consistente database- en bestandskopie controleren. | Toepassingsteam | Aanmelding en toegestane toegang werken, ongeoorloofde toegang wordt geweigerd en het bijbehorende bestand opent in de geïsoleerde test. |
Schrijfpauze | Aannemen en verwerken van nieuwe wijzigingen op alle oude schrijfpaden stoppen; laatste consistente stand overdragen. | Beheer en toepassingsteam | Open werk is vastgelegd; database en bestanden passen bij elkaar. |
Vrijgave | Gecontroleerde doeltoegang openen en wijzigingen alleen op het bedoelde nieuwe schrijfdoel aannemen. | Verantwoordelijken voor bedrijfsproces en beheer | Leidende gegevensstand, toegangsroute en stopbesluit zijn duidelijk. |
Stoppen en terugkeren vooraf onderscheiden
Microsoft adviseert stopcriteria en geoefende terugkeerstappen op de werklast af te stemmen. In het voorbeeld verhindert een ontbrekende bijlage al de vrijgave. Zolang op het doel geen nieuwe wijzigingen zijn aangenomen, kan een voorbereide terugkeer naar de ongewijzigd gehouden oude stand passen.
Na nieuwe wijzigingen op het doel volstaat het terugzetten van het DNS-adres niet. Die wijzigingen ontbreken mogelijk in het oude systeem. Terugkeer vereist dan een vastgelegde leidende gegevensstand en een gecontroleerde methode voor tussentijdse wijzigingen. Intussen worden geen ongecoördineerde parallelle schrijfpaden geopend. Als het team dit geval niet veilig kan afhandelen, moet het vóór de vrijgave het plan aanpassen.
DNS en overgang samen afronden
De DNS-TTL beschrijft normale caching van een antwoord. Sommige clients kunnen daardoor nog de oude toegang gebruiken. Het gedrag daarvan moet passen bij de schrijfpauze of het nieuwe leidende systeem; twee onafhankelijk beschrijfbare kopieën vormen geen afgeronde wissel.
Controleer de hele werkwijze in een geschikte testomgeving, inclusief nieuwe aanvraag, bijlage, rollen en achtergrondwerk. Externe acties blijven daar beperkt tot testdoelen. Plan ook bewaking en een verantwoordelijk contact na de vrijgave. De oude dienst wordt pas uitgezet wanneer de afgesproken afrondingsvoorwaarden en back-upaanpak zijn opgehelderd.
Bronnen
Verder lezen
Alle artikelen
Cloud & beheer met ASES
Hosting, deployment, onderhoud en support