Flyt din VPS til en ny udbyder uden nedetid

Hver gyserhistorie om en migrering har den samme midte: Nogen ændrede DNS først og begyndte så at kopiere. Nedetid under en flytning skyldes næsten aldrig, at kopieringen er langsom. Den skyldes, at trinene bliver taget i den forkerte rækkefølge.

Her er rækkefølgen, der virker, uanset om du forlader en anden udbyder eller skifter mellem to af vores tariffer.

1. To dage før: sænk TTL'en

Find de DNS-poster, du skal ændre (som regel A, AAAA og eventuelle CNAME, der peger på dem), og sænk deres TTL til 300 sekunder. Vent derefter mindst lige så længe, som den gamle TTL var. En post med en TTL på et døgn betyder, at nogle resolvere bliver ved med at udlevere den gamle adresse et døgn efter ændringen, og intet, du gør på serveren, kan fremskynde det.

Det er det trin, folk springer over, og det er netop det, der forvandler et skift på fem minutter til en dag, hvor halvdelen af brugerne ser den gamle server.

2. Lav en oversigt over den gamle server

Du skal bygge denne maskine op et andet sted, så skriv ned, hvad den faktisk gør. Ikke hvad du husker. Hvad den gør:

ss -tlnp                                # what is listening, and which process
crontab -l; ls /etc/cron.d              # scheduled jobs
systemctl list-timers --all             # the scheduled jobs people forget
systemctl list-units --type=service --state=running

Føj til listen: TLS-certifikaterne og hvordan de fornyes, miljøfiler med hemmeligheder, firewallregler, brugere og deres SSH-nøgler, databasen og dens størrelse, og alt, der taler med serveren via IP-adresse. Den sidste gruppe er den lumske: en partners allowlist, en betalingsudbyders webhook-indstillinger, et overvågningstjek.

3. Byg den nye server ved siden af den gamle

Bestil den nye server og lad den gamle være. Vælg en tarif fra VPS-listen med lige så meget eller mere disk, end du faktisk bruger, ikke end du blev solgt. Modtager den gamle maskine overhovedet indgående trafik (et website, webhooks, et API), skal den nye have sin egen IPv4. En NAT-tarif tager kun imod indgående forbindelser på sin SSH-port, og hvad én videresendt port kan og ikke kan forklarer, hvorfor det betyder noget.

Forbind, installer de samme pakker, opret brugerne og firewallen igen. Forbindelsesguiden gennemgår nøgler og første login.

4. Synkroniser filerne to gange

Den første synkronisering kopierer alt, mens den gamle server arbejder videre. Den kan tage timer; det er fint.

rsync -aHAX --numeric-ids --info=progress2 /var/www/ root@203.0.113.10:/var/www/

--numeric-ids bevarer filejerne efter nummer, hvilket undgår den klassiske overraskelse „alt tilhører den forkerte bruger“, når de to systemer har oprettet brugere i forskellig rækkefølge. Har du aldrig brugt rsync over SSH, gennemgår sådan overfører du filer til en VPS det trin for trin.

Den anden synkronisering, lige før skiftet, kopierer kun det, der er ændret siden den første. Den tager som regel sekunder.

5. Flyt databasen med omtanke

Filer er nemme. En database, der modtager skrivninger, er den ene del, hvor „uden nedetid“ kræver enten et lille kompromis eller mere arbejde.

Den enkle vej: dump og gendan én gang for at teste, og ved skiftet stop skrivningerne i et minut (sæt appen i skrivebeskyttet tilstand eller stop den), tag et frisk dump, gendan det på den nye server og start appen dér. For de fleste små projekter er det en pause på et minut eller to, varslet i forvejen.

Vejen uden pause: sæt replikering op fra den gamle database til den nye, lad den indhente forspringet, og gør den nye til primær ved skiftet. Mere opsætning, og det er det værd, når selv et minuts tabte skrivninger er uacceptabelt.

6. Test den nye server, før nogen andre ser den

DNS peger stadig på den gamle server, så du kan teste den nye i fred. Send en forespørgsel for dit rigtige domæne til den nye adresse:

curl --resolve example.com:443:203.0.113.10 https://example.com/health

Er certifikatet der ikke endnu, så test på samme måde over HTTP, eller tilføj en midlertidig linje i din hosts-fil og klik rundt på sitet i en browser. Tjek logins, uploads, baggrundsjob og udgående mail. Billigere finder du aldrig en manglende PHP-udvidelse.

7. Skift, og lad den gamle server køre

Lav den sidste filsynkronisering og databasetrinnet, og ændr så DNS-posterne. Med en TTL på 300 sekunder flytter det meste af trafikken inden for få minutter. Hold øje med den gamle servers adgangslog: Der kommer stadig en strøm af forespørgsler fra resolvere og klienter, der ignorerer TTL. Lad den køre uændret i et par dage. Opdater derefter alt, der peger på den gamle IP: partneres allowlists, webhook-URL'er og for mail den nye adresses reverse DNS (på vores tariffer med dedikeret IP sætter du den selv, se reverse DNS) og din SPF-post.

Det, der oftest går i stykker

Nogenlunde i den rækkefølge, vi ser det: en systemd-timer, som ingen havde skrevet ned, en konfigurationsfil med den gamle IP hårdkodet, filer, der ejes af den forkerte bruger, en firewall, der blokerer appens egen port, et certifikat, der fornyes på den gamle server, men ikke på den nye, og mail, der havner i spam, fordi den nye adresse endnu ikke har reverse DNS.

Hvor denne tjekliste ikke passer

En hårdt belastet database med konstante skrivninger og nul tolerance for pauser kræver rigtig replikering og en generalprøve, ikke en blogtjekliste. Windows-servere flytter med andre værktøjer end rsync. Og hvis flytningen i virkeligheden handler om størrelse, så læs dette først: Her vokser tariffer på stedet. Skift til en større tarif af samme netværkstype tilføjer vCPU, RAM og disk med én genstart, helt uden migrering. Kun for at skrumpe kræves en ny server. Flytter du, fordi du ikke er sikker på, at maskinen er stor nok, kan hvornår du faktisk har brug for 64 GB RAM spare dig turen, og VPS, delt hosting, dedikeret server eller cloud hjælper, hvis du er i tvivl om, hvorvidt en VPS overhovedet er det rigtige hjem.