Skift hosting: planlæg data og omlægning sammen
Planlæg database, filer og skriveadgang sammen. En gennemarbejdet plan adskiller forberedelse, omlægning og tilbagevenden efter nye ændringer.
Et hostingskift er afsluttet for dit team, når det aftalte arbejdsforløb fungerer på det nye sted med den rigtige datatilstand. Fastlæg på forhånd, hvornår ændringer modtages, hvem der godkender omlægningen, og under hvilke betingelser teamet kan vende tilbage.
Kortlæg forløbet og dets skriveveje
I det tænkte eksempel driver en virksomhed kundeportalen P-65. En kunde opretter anmodningen A-65 med bilaget F-65. Database og fillager hører sammen. Ud over browseren kan en grænseflade og en baggrundsproces ændre data. Alle disse skriveveje skal med i overgangsplanen.
Eksemplet omfatter en varslet skrivepause. Det er et bevidst valg, ikke et krav ved enhver migrering. Teamet afslutter igangværende ændringer kontrolleret og registrerer, hvilke åbne opgaver der må fortsætte på destinationen. Løbende overførsel af nye ændringer ville være en anden metode med egne synkroniserings- og konfliktkontroller.
Aftal omlægningen som en arbejdsrækkefølge
AWS anbefaler at dokumentere og øve afhængigheder, opgaverækkefølge, ansvarlige, kontroller og tilbagevenden før skiftet. Den udfyldte planskabelon indeholder planlagte trin, ikke resultater fra en udført migrering.
Fase | Aftale i eksemplet | Ansvarlig rolle | Betingelse for næste trin |
|---|---|---|---|
Forberedelse | Kontrollér målmiljøet med en konsistent database- og filkopi. | Applikationsteam | Login og tilladt adgang virker, uautoriseret adgang afvises, og den tilhørende fil kan åbnes i den isolerede test. |
Skrivepause | Stop modtagelse og behandling af nye ændringer ved alle gamle skriveveje; overfør den sidste konsistente tilstand. | Drift og applikationsteam | Åbent arbejde er registreret; database og filer passer sammen. |
Frigivelse | Åbn den kontrollerede måladgang, og modtag kun ændringer ved det planlagte nye skrivemål. | Forretnings- og driftsansvarlige | Den gældende datatilstand, adgangsvejen og beslutningen om at stoppe er klare. |
Skeln på forhånd mellem stop og tilbagevenden
Microsoft anbefaler at tilpasse stopkriterier og afprøvede tilbageførselstrin til arbejdsbelastningen. I eksemplet forhindrer et manglende bilag allerede frigivelsen. Så længe destinationen ikke har modtaget nye ændringer, kan en forberedt tilbagevenden til den uændrede gamle tilstand være passende.
Efter nye ændringer på destinationen er det ikke nok at stille DNS-adressen tilbage. Ændringerne kan mangle i det gamle system. Tilbagevenden kræver da en fastlagt gældende datatilstand og en kontrolleret metode til de mellemliggende ændringer. Indtil da åbnes ingen ukoordinerede parallelle skriveveje. Kan teamet ikke håndtere dette sikkert, må det ændre overgangsplanen før frigivelse.
Afslut DNS og overgang sammen
DNS-TTL beskriver normal caching af et svar. Nogle klienter kan derfor stadig bruge den gamle adgang. Dens adfærd skal passe til skrivepausen eller det nye gældende system; to uafhængigt skrivbare kopier er ikke et afsluttet skift.
Kontrollér hele forløbet i et egnet testmiljø, inklusive ny anmodning, bilag, roller og baggrundsarbejde. Eksterne handlinger begrænses dér til testmål. Planlæg også overvågning og en ansvarlig kontakt efter frigivelsen. Den gamle tjeneste tages først ud af drift, når aftalte afslutningsbetingelser og backupforløb er afklaret.
Kilder
Læs videre
Alle artikler
Cloud & drift med ASES
Hosting, deployment, vedligeholdelse og support