Μεταφορά του VPS σας σε νέο πάροχο χωρίς διακοπή

Κάθε ιστορία τρόμου για μετάβαση έχει την ίδια μέση: κάποιος άλλαξε πρώτα το DNS και μετά άρχισε να αντιγράφει. Η διακοπή σε μια μεταφορά σχεδόν ποτέ δεν οφείλεται σε αργή αντιγραφή. Οφείλεται σε λάθος σειρά βημάτων.

Αυτή είναι η σειρά που δουλεύει, είτε φεύγετε από άλλον πάροχο είτε αλλάζετε ανάμεσα σε δύο δικά μας τιμολόγια.

1. Δύο μέρες πριν: χαμηλώστε το TTL

Βρείτε τις εγγραφές DNS που θα αλλάξετε (συνήθως A, AAAA και όποια CNAME δείχνουν σε αυτές) και χαμηλώστε το TTL τους στα 300 δευτερόλεπτα. Μετά περιμένετε τουλάχιστον όσο ήταν το παλιό TTL. Μια εγγραφή με TTL μίας μέρας σημαίνει ότι κάποιοι resolvers θα συνεχίσουν να δίνουν την παλιά διεύθυνση για μία μέρα μετά την αλλαγή, και τίποτα στον server δεν το επιταχύνει.

Είναι το βήμα που παραλείπουν οι περισσότεροι, και αυτό ακριβώς μετατρέπει μια αλλαγή πέντε λεπτών σε μια μέρα όπου οι μισοί χρήστες βλέπουν τον παλιό server.

2. Κάντε απογραφή του παλιού server

Θα ξαναστήσετε αυτό το μηχάνημα κάπου αλλού, οπότε γράψτε τι κάνει πραγματικά. Όχι τι θυμάστε. Τι κάνει:

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

Προσθέστε στη λίστα: τα πιστοποιητικά TLS και πώς ανανεώνονται, αρχεία περιβάλλοντος με μυστικά, κανόνες firewall, χρήστες και τα κλειδιά SSH τους, τη βάση δεδομένων και το μέγεθός της, και οτιδήποτε μιλά με τον server μέσω IP. Αυτή η τελευταία ομάδα είναι η ύπουλη: το allowlist ενός συνεργάτη, οι ρυθμίσεις webhook ενός παρόχου πληρωμών, ένας έλεγχος παρακολούθησης.

3. Στήστε τον νέο server δίπλα στον παλιό

Παραγγείλτε τον νέο server και αφήστε τον παλιό ήσυχο. Διαλέξτε τιμολόγιο από τη λίστα VPS με ίδιο ή μεγαλύτερο δίσκο από αυτόν που πραγματικά χρησιμοποιείτε, όχι από αυτόν που σας πούλησαν. Αν το παλιό μηχάνημα δέχεται οποιαδήποτε εισερχόμενη κίνηση (site, webhooks, API), το νέο χρειάζεται δικό του IPv4. Ένα τιμολόγιο NAT δέχεται εισερχόμενες συνδέσεις μόνο στη θύρα SSH του, και το τι μπορεί και τι δεν μπορεί να κάνει μία προωθημένη θύρα εξηγεί γιατί αυτό μετράει.

Συνδεθείτε, εγκαταστήστε τα ίδια πακέτα, ξαναφτιάξτε τους χρήστες και το firewall. Ο οδηγός σύνδεσης καλύπτει τα κλειδιά και την πρώτη είσοδο.

4. Συγχρονίστε τα αρχεία δύο φορές

Ο πρώτος συγχρονισμός αντιγράφει τα πάντα ενώ ο παλιός server συνεχίζει να δουλεύει. Μπορεί να πάρει ώρες· δεν πειράζει.

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

Το --numeric-ids κρατά τους ιδιοκτήτες αρχείων με βάση τον αριθμό, κάτι που αποτρέπει την κλασική έκπληξη «όλα ανήκουν σε λάθος χρήστη» όταν τα δύο συστήματα δημιούργησαν χρήστες με διαφορετική σειρά. Αν δεν έχετε χρησιμοποιήσει ποτέ rsync μέσω SSH, το πώς μεταφέρετε αρχεία σε ένα VPS σας καθοδηγεί βήμα βήμα.

Ο δεύτερος συγχρονισμός, ακριβώς πριν από την αλλαγή, αντιγράφει μόνο όσα άλλαξαν από τον πρώτο. Συνήθως παίρνει δευτερόλεπτα.

5. Μεταφέρετε τη βάση δεδομένων συνειδητά

Τα αρχεία είναι εύκολα. Μια βάση που δέχεται εγγραφές είναι το μόνο σημείο όπου το «χωρίς διακοπή» θέλει είτε έναν μικρό συμβιβασμό είτε περισσότερη δουλειά.

Ο απλός δρόμος: κάντε dump και επαναφορά μία φορά για δοκιμή, και τη στιγμή της αλλαγής σταματήστε τις εγγραφές για ένα λεπτό (βάλτε την εφαρμογή σε λειτουργία μόνο ανάγνωσης ή σταματήστε την), πάρτε ένα φρέσκο dump, επαναφέρετέ το στον νέο server και ξεκινήστε εκεί την εφαρμογή. Για τα περισσότερα μικρά έργα αυτό είναι μια παύση ενός-δύο λεπτών, ανακοινωμένη από πριν.

Ο δρόμος χωρίς παύση: στήστε αναπαραγωγή από την παλιά βάση στη νέα, αφήστε τη να προλάβει και τη στιγμή της αλλαγής προαγάγετε τη νέα σε κύρια. Περισσότερη προετοιμασία, και αξίζει όταν ούτε ένα λεπτό χαμένων εγγραφών δεν είναι αποδεκτό.

6. Δοκιμάστε τον νέο server πριν τον δει κάποιος άλλος

Το DNS δείχνει ακόμα στον παλιό server, οπότε μπορείτε να δοκιμάσετε τον νέο ιδιωτικά. Στείλτε ένα αίτημα για το πραγματικό σας domain στη νέα διεύθυνση:

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

Αν το πιστοποιητικό δεν είναι ακόμα εκεί, δοκιμάστε με τον ίδιο τρόπο μέσω HTTP ή προσθέστε μια προσωρινή γραμμή στο αρχείο hosts και περιηγηθείτε στο site με browser. Ελέγξτε συνδέσεις, ανεβάσματα, εργασίες στο παρασκήνιο και εξερχόμενα email. Είναι η φθηνότερη στιγμή για να ανακαλύψετε ότι λείπει μια επέκταση PHP.

7. Κάντε την αλλαγή και κρατήστε τον παλιό server ανοιχτό

Κάντε τον τελικό συγχρονισμό αρχείων και το βήμα της βάσης, και μετά αλλάξτε τις εγγραφές DNS. Με TTL 300 δευτερολέπτων, το μεγαλύτερο μέρος της κίνησης μετακινείται μέσα σε λίγα λεπτά. Παρακολουθήστε το access log του παλιού server: θα συνεχίσει να δέχεται λίγα αιτήματα από resolvers και clients που αγνοούν το TTL. Αφήστε τον να τρέχει αναλλοίωτος λίγες μέρες. Μετά ενημερώστε ό,τι δείχνει στην παλιά IP: allowlists συνεργατών, URL webhook και, για το email, το reverse DNS της νέας διεύθυνσης (στα τιμολόγιά μας με αποκλειστική IP το ορίζετε μόνοι σας, δείτε reverse DNS) καθώς και την εγγραφή SPF σας.

Τι χαλάει πιο συχνά

Περίπου με τη σειρά που το βλέπουμε: ένας timer του systemd που κανείς δεν είχε καταγράψει, ένα αρχείο ρυθμίσεων με την παλιά IP γραμμένη σταθερά, αρχεία που ανήκουν σε λάθος χρήστη, ένα firewall που μπλοκάρει τη θύρα της ίδιας της εφαρμογής, ένα πιστοποιητικό που ανανεώνεται στον παλιό server αλλά όχι στον νέο, και email που καταλήγουν στα ανεπιθύμητα επειδή η νέα διεύθυνση δεν έχει ακόμα reverse DNS.

Πού δεν ταιριάζει αυτή η λίστα

Μια πολυάσχολη βάση με συνεχείς εγγραφές και μηδενική ανοχή σε παύσεις χρειάζεται κανονική αναπαραγωγή και πρόβα, όχι μια λίστα από blog. Οι Windows servers μεταφέρονται με άλλα εργαλεία, όχι με rsync. Κι αν η μεταφορά αφορά στην πραγματικότητα το μέγεθος, διαβάστε πρώτα αυτό: εδώ τα τιμολόγια μεγαλώνουν επί τόπου. Η μετάβαση σε μεγαλύτερο τιμολόγιο του ίδιου τύπου δικτύου προσθέτει vCPU, RAM και δίσκο με μία επανεκκίνηση, χωρίς καμία μεταφορά. Νέος server χρειάζεται μόνο για σμίκρυνση. Αν μετακομίζετε επειδή δεν είστε σίγουροι ότι το μηχάνημα φτάνει, το Πότε χρειάζεστε πραγματικά 64 GB RAM μπορεί να σας γλιτώσει το ταξίδι, και το VPS, shared hosting, dedicated server ή cloud βοηθά αν δεν είστε σίγουροι ότι ένα VPS είναι καν το σωστό σπίτι.