Tutte le storie dell'orrore sulle migrazioni hanno la stessa parte centrale: qualcuno ha cambiato prima il DNS e poi ha iniziato a copiare. Il downtime durante un trasloco non dipende quasi mai da una copia lenta. Dipende dall'aver fatto i passi nell'ordine sbagliato.
Ecco l'ordine che funziona, che tu stia lasciando un altro provider o passando da una nostra tariffa a un'altra.
1. Due giorni prima: abbassa il TTL
Individua i record DNS che cambierai (di solito A, AAAA e gli eventuali CNAME che puntano a loro) e abbassa il loro TTL a 300 secondi. Poi aspetta almeno quanto durava il vecchio TTL. Un record con un TTL di un giorno significa che alcuni resolver continueranno a servire il vecchio indirizzo per un giorno dopo la modifica, e niente di ciò che fai sul server può accelerarlo.
È il passo che tutti saltano, ed è quello che trasforma un passaggio di cinque minuti in una giornata in cui metà degli utenti vede il vecchio server.
2. Fai l'inventario del vecchio server
Ricostruirai questa macchina altrove, quindi annota cosa fa davvero. Non cosa ricordi che faccia. Cosa fa:
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
Aggiungi alla lista: i certificati TLS e come si rinnovano, i file di ambiente con i segreti, le regole del firewall, gli utenti e le loro chiavi SSH, il database e la sua dimensione, e tutto ciò che parla con il server tramite indirizzo IP. Quest'ultimo gruppo è il più subdolo: la allowlist di un partner, le impostazioni dei webhook di un fornitore di pagamenti, un controllo di monitoraggio.
3. Costruisci il nuovo server accanto al vecchio
Ordina il nuovo server e lascia stare il vecchio. Scegli una tariffa dalla lista dei VPS con lo stesso disco o più di quello che usi davvero, non di quello che ti hanno venduto. Se la vecchia macchina riceve un qualsiasi traffico in entrata (un sito, webhook, un'API), la nuova ha bisogno di un IPv4 suo. Una tariffa NAT accetta connessioni in entrata solo sulla sua porta SSH, e cosa può fare e cosa no una sola porta inoltrata spiega perché conta.
Collegati, installa gli stessi pacchetti, ricrea utenti e firewall. La guida alla connessione copre le chiavi e il primo accesso.
4. Sincronizza i file due volte
La prima sincronizzazione copia tutto mentre il vecchio server continua a lavorare. Può durare ore; va bene così.
rsync -aHAX --numeric-ids --info=progress2 /var/www/ root@203.0.113.10:/var/www/
--numeric-ids mantiene i proprietari dei file per numero, evitando la classica sorpresa del «tutto appartiene all'utente sbagliato» quando i due sistemi hanno creato gli utenti in ordine diverso. Se non hai mai usato rsync via SSH, trasferire file su un VPS ti guida passo passo.
La seconda sincronizzazione, subito prima del passaggio, copia solo ciò che è cambiato dalla prima. Di solito dura pochi secondi.
5. Sposta il database con criterio
I file sono facili. Un database che riceve scritture è l'unico punto in cui «senza downtime» richiede o un piccolo compromesso o più lavoro.
La via semplice: fare un dump e un ripristino una volta per i test, poi al momento del passaggio fermare le scritture per un minuto (mettere l'app in sola lettura o fermarla), fare un dump fresco, ripristinarlo sul nuovo server e avviare lì l'app. Per la maggior parte dei piccoli progetti è una pausa di un paio di minuti, annunciata in anticipo.
La via senza pausa: impostare una replica dal vecchio database al nuovo, lasciarla recuperare, poi promuovere il nuovo al momento del passaggio. Più configurazione, e vale la pena quando anche un minuto di scritture perse è inaccettabile.
6. Testa il nuovo server prima che lo veda qualcun altro
Il DNS punta ancora al vecchio server, quindi puoi testare il nuovo in privato. Invia una richiesta per il tuo vero dominio al nuovo indirizzo:
curl --resolve example.com:443:203.0.113.10 https://example.com/health
Se il certificato non c'è ancora, testa allo stesso modo in HTTP, oppure aggiungi una riga temporanea al file hosts e naviga il sito nel browser. Controlla login, upload, job in background e posta in uscita. È il momento più economico per scoprire che manca un'estensione PHP.
7. Passa, e lascia acceso il vecchio server
Fai la sincronizzazione finale dei file e il passo del database, poi cambia i record DNS. Con un TTL di 300 secondi la maggior parte del traffico si sposta in pochi minuti. Tieni d'occhio il log di accesso del vecchio server: continuerà a ricevere un rivolo di richieste da resolver e client che ignorano il TTL. Lascialo acceso, invariato, per qualche giorno. Poi aggiorna tutto ciò che punta al vecchio IP: allowlist dei partner, URL dei webhook e, per la posta, il DNS inverso del nuovo indirizzo (sulle nostre tariffe con IP dedicato lo imposti tu, vedi DNS inverso) e il record SPF.
Cosa si rompe più spesso
Più o meno nell'ordine in cui lo vediamo accadere: un timer di systemd che nessuno aveva elencato, un file di configurazione con il vecchio IP scritto a mano, file che appartengono all'utente sbagliato, un firewall che blocca la porta dell'app stessa, un certificato che si rinnova sul vecchio server ma non sul nuovo, e posta che finisce nello spam perché il nuovo indirizzo non ha ancora un DNS inverso.
Dove questa checklist non va bene
Un database con scritture continue e nessuna tolleranza per le pause ha bisogno di una vera replica e di una prova generale, non di una checklist da blog. I server Windows si spostano con strumenti diversi da rsync. E se in realtà il trasloco riguarda le dimensioni, leggi prima questo: qui le tariffe crescono sul posto. Passare a una tariffa più grande dello stesso tipo di rete aggiunge vCPU, RAM e disco con un riavvio, senza alcuna migrazione. Serve un nuovo server solo per ridurre. Se ti stai spostando perché non sei sicuro che la macchina basti, quando ti servono davvero 64 GB di RAM potrebbe risparmiarti il viaggio, e VPS, hosting condiviso, server dedicato o cloud ti aiuta se non sei sicuro che un VPS sia la casa giusta.
Commenti
Ancora nessun commento. Sii il primo.