కొత్త VPS కు సర్వర్‌ను ఎలా తరలించాలి

కొత్త VPS కు సర్వర్‌ను ముందస్తు పరీక్షించిన cutover విధానంలో తరలించడం

సర్వర్‌ను కొత్త VPS కు తరలించేటప్పుడు, ఈ మార్పును కేవలం కాపీ ప్రక్రియగా కాకుండా ముందుగా పరీక్షించిన cutover గా నిర్వహించండి. కొత్త సిస్టమ్‌ను మొదటి నుంచి నిర్మించండి. డేటాను రెండుసార్లు సమకాలీకరించండి. DNS ను మార్చే ముందు కొత్త సిస్టమ్ తన స్వంత IP address పై సరిగ్గా పనిచేస్తుందని నిర్ధారించండి. తరువాత records ను మార్చండి. మీరు పూర్తిగా నిర్ధారించుకునే వరకు పాత సిస్టమ్‌ను నడుస్తూనే ఉంచండి. Bytes ను కాపీ చేయడం సులభమైన భాగం. చర్యల క్రమమే ఈ మార్పు సమస్యలేకుండా పూర్తవుతుందా లేదా ఖరీదైన సమస్యగా మారుతుందా అన్నది నిర్ణయిస్తుంది.

ఈ guide ఒక web application, database మరియు TLS (transport layer security) certificate నడుపుతున్న ఒక Linux server ను కవర్ చేస్తుంది. చాలా single-server setups కు ఇది సరిపోతుంది. ఇందులో రెండు hosts ఉంటాయి. అందువల్ల ప్రతి ఉదాహరణలో అది ఏ host పై నడుస్తుందో comment లో పేర్కొంటుంది. Addresses documentation ranges నుంచి తీసుకున్నవి: 198.51.100.10 పాత server, 203.0.113.20 కొత్త server.

మీరు ప్రారంభించే ముందు మొత్తం runbook చదవండి. మొదటి దశ అయిన DNS TTL తగ్గింపు, మీరు నిజంగా ముఖ్యంగా భావించే దశకు కొన్ని రోజుల ముందే చేయాలి.

ఏదైనా నిర్మించే ముందు ఇన్వెంటరీ తీసుకోండి

మీరు వివరాలు నమోదు చేయని server ను పునర్నిర్మించలేరు. పాత server ఏమి చేస్తుందో రాయడానికి ఒక గంట కేటాయించండి. ఎందుకంటే migration తర్వాత విఫలమయ్యేది ఎవరూ గుర్తుంచుకోని అంశమే: cron job, firewall మినహాయింపు లేదా application directory వెలుపల ఉన్న environment file.

పాత server పై వీటిని అమలు చేసి, కొత్త server నుంచి చదవగలిగే చోట output ను భద్రపరచండి.

# old server: packages you asked for, not the dependencies they pulled in
apt-mark showmanual > ~/inv-packages.txt

# old server: what runs now, and what starts at boot
systemctl list-units --type=service --state=running --no-pager > ~/inv-services.txt
systemctl list-unit-files --state=enabled --no-pager >> ~/inv-services.txt
systemctl list-timers --all --no-pager > ~/inv-timers.txt

# old server: what is listening, on which address and port
sudo ss -tulpn > ~/inv-ports.txt

# old server: human accounts, skipping the system ones
awk -F: '$3 >= 1000 && $3 < 65534 {print $1, $3, $6, $7}' /etc/passwd

Dependencies గా వచ్చిన ప్రతిదాన్ని తొలగించి చూపుతుంది కాబట్టి apt-mark showmanual జాబితా ఉపయోగకరంగా ఉంటుంది. ఐదు సంవత్సరాల పాత server పై పూర్తి dpkg --get-selections అమలు చేస్తే రెండు వేల lines వస్తాయి. కానీ అవి ఎందుకు అవసరమో తెలియజేయవు.

Scheduled పనులు రెండు చోట్ల ఉండవచ్చు. కాబట్టి రెండింటినీ పరిశీలించండి. నెలకు ఒకసారి మాత్రమే నడిచే job ను migration తర్వాత ఆరు వారాలకు గుర్తించే అవకాశం ఉంటుంది.

# old server: per-user crontabs, then the system drop-ins
for u in $(cut -d: -f1 /etc/passwd); do sudo crontab -lu "$u" 2>/dev/null | sed "s/^/$u: /"; done
sudo ls -la /etc/cron.d /etc/cron.daily /etc/cron.hourly

తరువాత సాధారణ files కాని అంశాలను పరిశీలించండి: firewall rules, certificates, databases మరియు మీరు వాస్తవంగా ఎంత data ను తరలిస్తున్నారో.

# old server
sudo ufw status verbose        # or: sudo nft list ruleset
sudo certbot certificates
sudo -u postgres psql -c '\l'  # or: sudo mysql -e 'SHOW DATABASES;'
sudo du -xh --max-depth=1 / | sort -h

certbot certificates ప్రతి certificate పేరు, అది వర్తించే domains, expiry date మరియు disk పై ఉన్న files paths ను ముద్రిస్తుంది. ఆ output మీ TLS checklist. du -x ఒకే filesystem లోనే ఉంటుంది. అందువల్ల mounted backup volume లోకి వెళ్లి, వాస్తవ పరిమాణం కంటే పది రెట్లు ఎక్కువ సంఖ్యను చూపదు.

Server వెలుపల ఉండే రెండు అంశాలను ప్రతిసారీ మర్చిపోతారు. మొదటిది, మీ server IP address ను allowlist చేసే ఏదైనా third party: payment gateway, managed database, SMTP relay లేదా partner API. కొత్త server కు కొత్త address ఉంటుంది. కాబట్టి cutover కు ముందు allowlists లో కొత్త IP ను చేర్చాలి, తరువాత కాదు. రెండవది, మీరు స్వయంగా సృష్టించని DNS records. ఉదాహరణకు MX record లేదా text లో పాత IP ను పేర్కొనే SPF record.

పాత root filesystem ను clone చేయకుండా మళ్లీ నిర్మించడానికి కారణం

మొత్తం root filesystem ను కొత్త VPS కు clone చేయడం వేగంగా కనిపిస్తుంది. అది నిజంగానే వేగంగా ఉంటుంది, సమస్యలు మొదలయ్యే వరకు. సంవత్సరాలుగా production లో ఉన్న root filesystem లో ఎవరూ documentation చేయని చేతితో మార్చిన config, ప్రస్తుతం లేని repository నుంచి వచ్చిన packages, అలాగే పాత platform యొక్క virtual hardware కోసం రూపొందించిన boot setup ఉంటాయి. వీటన్నింటినీ import చేస్తే, migration చేయడానికి కారణమైన సమస్య కూడా మీతో పాటు వస్తుంది.

మొదటి రోజున rebuilding నెమ్మదిగా ఉంటుంది. ఆ తర్వాత ప్రతి రోజూ తక్కువ ఖర్చుతో ఉంటుంది. ప్రస్తుత release ను install చేసి, మీ base hardening అమలు చేయండి. తరువాత data మాత్రమే copy చేయండి: application directory, site configs, database dump, certificates, user uploads. మీరు వివరించలేని ఏదీ కొత్త సిస్టమ్‌కు తీసుకురావద్దు. కొత్త VPS పై మొదటి పది నిమిషాల్లో చేసే పనులతో ప్రారంభించండి: కొత్త VPS పై మొదటి పది నిమిషాలు. తరువాత inventory లోని services ను ఒక్కొక్కటిగా add చేయండి. తదుపరి service ను add చేసే ముందు ప్రతి service సరిగ్గా పనిచేస్తోందని నిర్ధారించండి.

image లేదా snapshot restore సరైన ఎంపిక అయ్యే సందర్భం

Rebuild చేయడానికి ఒక చెల్లుబాటు అయ్యే మినహాయింపు ఉంది. పాత server boot కాకపోతే, లేదా source నుంచి మళ్లీ build చేయడం ఇక సాధ్యం కాని application అయితే, provider image లేదా snapshot restore ఆచరణాత్మక పరిష్కారం. దీనికి స్పష్టమైన పరిమితులు ఉన్నాయి: ఇది ఒకే provider పరిధిలో మాత్రమే పనిచేస్తుంది. చాలాసార్లు ఒకే plan family లో మాత్రమే పనిచేస్తుంది. కారణం, restore చేసిన disk ఆ platform కు చెందిన virtual devices మరియు network naming పై ఆధారపడుతుంది.

నడుస్తున్న box యొక్క snapshot లో, live database ను file-level గా copy చేసినప్పుడు ఉండే consistency సమస్యే ఉంటుంది. Image restore ను migration plan గా కాకుండా recovery మార్గంగా పరిగణించండి. దానిపై plan రూపొందించే ముందు snapshot backup కు సమానం ఎందుకు కాదు చదవండి.

ఫైళ్లు ఎలా తరలుతాయి: SSH ద్వారా rsync

పాత server నుంచి rsync ను అమలు చేసి, కొత్త server కు డేటాను పంపండి. పంపడం సాధారణంగా సులభం, ఎందుకంటే డేటా ఇప్పటికే పాత server లో ఉంటుంది. sudo కింద ఉన్న మొత్తం డేటాను అది చదవగలదు.

# old server: dry run first, and read what it says it will do
sudo rsync -aHAX --dry-run --itemize-changes \
  -e 'ssh -i /root/.ssh/id_ed25519' \
  /srv/app/ deploy@203.0.113.20:/srv/app/

# old server: the real bulk pass
sudo rsync -aHAX --info=progress2 \
  -e 'ssh -i /root/.ssh/id_ed25519' \
  /srv/app/ deploy@203.0.113.20:/srv/app/

Flags ముఖ్యమైనవి. -a permissions, timestamps, symbolic links మరియు ownership ను భద్రపరుస్తుంది. -H hard links ను విడివిడిగా కాపీలుగా విస్తరించకుండా, hard links గానే ఉంచుతుంది. -A POSIX ACLs (access control lists) ను కాపీ చేస్తుంది. -X extended attributes ను కాపీ చేస్తుంది. చివరి రెండు లేకపోతే, ఒకేలా కనిపించే ఫైల్ భిన్నంగా పనిచేయవచ్చు. ఎందుకంటే SELinux labels మరియు ACLs extended attributes లో నిల్వ ఉంటాయి. వాటిని మరే ఇతర సమాచారం నమోదు చేయదు.

ఇక్కడ ఎక్కువ failures కు రెండు వివరాలే కారణమవుతాయి.

చివర ఉన్న slash డేటా ఎక్కడ చేరాలో నిర్ణయిస్తుంది. /srv/app/ అంటే ఆ directory లోని contents. /srv/app అంటే ఆ directory మొత్తం. దీన్ని తప్పుగా ఇస్తే, కొత్త server లో /srv/app/app ఏర్పడుతుంది. Application ప్రారంభమైన తరువాత missing files అని చూపిస్తుంది, ఎందుకంటే దానికి configure చేసిన paths ఇప్పుడు ఒక స్థాయి తక్కువగా ఉన్నాయి.

sudo లో tilde, root యొక్క home directory ను సూచిస్తుంది. ఒక sudo rsync లో -e 'ssh -i ~/.ssh/id_ed25519' రాస్తే, key ను /root/.ssh లో వెతుకుతుంది. మీ స్వంత home directory లో కాదు. అక్కడ key లేకపోతే, SSH Permission denied (publickey) ను చూపిస్తుంది. rsync rsync: connection unexpectedly closed ను చూపించి non-zero తో ముగుస్తుంది. Key path ను పూర్తి రూపంలో రాయండి. Path సరిచేసిన తరువాత కూడా ఆ authentication message కనిపిస్తే, publickey failure కు కొన్ని పరిమిత కారణాలే ఉంటాయి; తరువాత కొత్త server లో directory permissions ను పరిశీలించండి.

Ownership విషయంలో ఒక నిర్ణయం తీసుకోవాలి. root గా నడిపినప్పుడు, rsync default గా owner మరియు group ను పేరు ఆధారంగా map చేస్తుంది. అందువల్ల పాత box లో www-data కు చెందిన file, numeric UID (user ID) వేరుగా ఉన్నప్పటికీ కొత్త box లో www-data కు చెందినదిగా మారుతుంది. Rebuild కోసం ఇదే అవసరం. Target లో ఆ accounts లేని filesystem ను కాపీ చేస్తున్నప్పుడు మాత్రమే --numeric-ids ను జోడించండి. తరువాత ls -ln తో ఫలితాన్ని తనిఖీ చేయండి. Matching account లేని UID కు చెందిన file bare number గా కనిపిస్తుంది. దాన్ని చదివే ప్రతి service కు access నిరాకరించబడుతుంది.

పాత server ఇంకా traffic అందిస్తున్నప్పుడు, bulk pass ను కొన్ని రోజుల ముందే అమలు చేయండి. మీకు నచ్చినన్ని సార్లు దాన్ని పునరావృతం చేయవచ్చు. rsync మారిన డేటాను మాత్రమే పంపుతుంది. అందువల్ల రెండో pass గంటల బదులు కొన్ని నిమిషాల్లో పూర్తవుతుంది. Cutover window లో చేసే final pass కు --delete ను జోడించండి. అప్పుడు పాత server లో తొలగించిన files కొత్త server లో కూడా తొలగించబడతాయి.

# old server: final pass, inside the window, after the app has stopped writing
sudo rsync -aHAX --delete --info=progress2 \
  -e 'ssh -i /root/.ssh/id_ed25519' \
  /srv/app/ deploy@203.0.113.20:/srv/app/

Source లో లేని files ను destination నుంచి --delete తొలగిస్తుంది. అందువల్ల తప్పు source path తో పాటు --delete ఇస్తే destination directory ఖాళీ అవుతుంది. ప్రతి సారి ముందుగా --dry-run తో అమలు చేయండి. Laptop యొక్క SSH session disconnect అయినప్పుడు దీర్ఘకాలిక transfers కూడా ఆగిపోతాయి. కాబట్టి వాటిని పాత server లో tmux లేదా screen లో ప్రారంభించండి. పాత server ఇంకా users కు సేవలు అందిస్తున్నప్పుడు copy network link ను పూర్తిగా ఉపయోగిస్తే, --bwlimit=20M ను జోడించండి.

డేటాబేస్ ఎలా తరలించాలి: స్థానిక dump

డేటాబేస్ అనేది files లాగా కనిపించినప్పటికీ, కేవలం files ఉన్న directory కాదు. ఇది files, memoryలోని state, write-ahead log కలయిక. డేటాబేస్ స్వయంగా నిర్వచించే నిర్దిష్ట సమయాల్లో మాత్రమే ఇది consistentగా ఉంటుంది. అందుకే డేటాబేస్‌కు చెందిన toolనే ఉపయోగించాలి.

PostgreSQLకు రెండు dumps అవసరం, ఎందుకంటే roles మొత్తం clusterకు వర్తిస్తాయి మరియు pg_dump వాటిని చేర్చదు:

# old server
sudo -u postgres pg_dumpall --globals-only -f /var/backups/globals.sql
sudo -u postgres pg_dump -Fc -f /var/backups/appdb.dump appdb

# new server: restore in this order
sudo -u postgres psql -f /var/backups/globals.sql
sudo -u postgres createdb -O appuser appdb
sudo -u postgres pg_restore -d appdb --no-owner /var/backups/appdb.dump

globals.sqlను వదిలేస్తే ప్రతి table restore అవుతుంది, కానీ వాటిని చదవగల application role ఏదీ ఉండదు. కారణం, GRANT statements ఉనికిలో లేని userను సూచిస్తాయి. -Fc custom archive formatను రాస్తుంది. ఈ formatను pg_restore మాత్రమే చదవగలదు. తరువాత అవసరమైన tablesను మాత్రమే restore చేయడానికి ఇది అనుమతిస్తుంది. అదే major versionలో లేదా అంతకంటే కొత్త versionలో restore చేయాలి. ఉదాహరణకు 17 నుంచి 16కు వెనక్కి వెళ్లడం support చేయబడదు. ఏదైనా రాయడానికి ముందే file headerలో unsupported-version error చూపించి pg_restore archiveను తిరస్కరిస్తుంది.

MySQL మరియు MariaDB ఒకే commandను ఉపయోగిస్తాయి. అందులో defaultగా లేని నాలుగు options ఉన్నాయి:

# old server
sudo mysqldump --single-transaction --routines --triggers --events \
  --databases appdb > /var/backups/appdb.sql

# new server
sudo mysql < /var/backups/appdb.sql

--single-transaction writersను block చేయకుండా consistent snapshot తీసుకుంటుంది. అయితే ఇది InnoDB tablesకు మాత్రమే వర్తిస్తుంది. అదే databaseలోని MyISAM tableకు ఈ హామీ ఉండదు. అందువల్ల dumpపై ఆధారపడే ముందు మీ storage enginesను తనిఖీ చేయాలి. --routines, --triggers మరియు --events defaultగా offలో ఉంటాయి. అంటే plain dump మీ dataను restore చేస్తుంది, కానీ stored procedures మరియు scheduled eventsను మౌనంగా వదిలేస్తుంది. Database users మరియు వాటి grants mysql system databaseలో ఉంటాయి. --databases appdb dump ఈ databaseను ఎప్పుడూ చేర్చదు. కాబట్టి కొత్త serverలో వాటిని CREATE USER మరియు GRANTతో మళ్లీ సృష్టించాలి. MariaDB 11లో ఇదే tool mariadb-dump పేరుతో అందుబాటులో ఉంటుంది. mysqldumpను symbolic linkగా కొనసాగిస్తుంది. అందువల్ల August 2026 నాటికి ఈ రెండు పేర్లలో ఏదైనా పనిచేస్తుంది.

SQLite ఒకే fileగా ఉంటుంది. Application రాస్తున్న సమయంలో దాన్ని copy చేస్తే file అసంపూర్ణంగా మారుతుంది. దానికి సురక్షితమైన ప్రత్యేక విధానం ఉంది:

# old server
sqlite3 /var/lib/app/app.db ".backup '/var/backups/app.db'"

ఏ engine అయినా dumpపై ఆధారపడే ముందు దాన్ని తనిఖీ చేయాలి. Disk నిండిపోవడం వల్ల మధ్యలో ఆగిపోయిన dump కూడా ఎలాంటి error లేకుండా restore కావచ్చు. అయితే అది truncate అయిన స్థానం వరకు మాత్రమే restore అవుతుంది.

# old server: a complete mysqldump ends with a line reading "-- Dump completed on ..."
tail -n 3 /var/backups/appdb.sql

# new server: after restore, count rows in a table whose size you know
sudo mysql -e 'SELECT COUNT(*) FROM appdb.orders;'

నడుస్తున్న database పై rsync ఎందుకు ఉపయోగించలేరు

rsync ఫైల్‌ను ఒక్కొక్కటిగా copy చేస్తుంది. నడుస్తున్న database ఒకేసారి అనేక ఫైళ్లలో writes చేస్తుంది. అందువల్ల rsync చివరి ఫైల్‌కు చేరే సమయానికి మొదటి ఫైల్ ఇప్పటికే పాతదై ఉంటుంది. ఈ copyలో వేర్వేరు సమయాలకు చెందిన pages ఉంటాయి. databaseలో అలాంటి state ఎప్పుడూ ఉండదు. ఫలితంగా server ప్రారంభం కావడానికి నిరాకరించవచ్చు. లేదా మరింత ప్రమాదకరంగా, server ప్రారంభమై ఒక వారం పాటు సరైన సమాధానాలు అందించవచ్చు. తరువాత ఏదైనా query దెబ్బతిన్న pageను చేరినప్పుడు విఫలమవుతుంది. మధ్యలో ఎలాంటి warning ఉండదు.

ఫైళ్లను స్వయంగా తరలించడానికి రెండు సురక్షితమైన మార్గాలు ఉన్నాయి. databaseను stop చేసి, copy చేసి, మళ్లీ start చేయండి. ఇది సరైనది, సరళమైనది. అయితే downtime copy పూర్తయ్యేంత సమయం ఉంటుంది. లేదా నడుస్తున్న server యొక్క physical copy కోసం రూపొందించిన toolను ఉపయోగించండి. PostgreSQL కోసం అది pg_basebackup. ఇది serverతో సమన్వయం చేసి copy consistentగా ఉండేలా చేస్తుంది:

# new server: pull a physical copy from the old one
pg_basebackup -h 198.51.100.10 -U replicator -D /var/lib/postgresql/16/main -X stream -P

దీనికి REPLICATION attribute ఉన్న role మరియు పాత serverలో సరిపోయే pg_hba.conf entry అవసరం. అందువల్ల dumpతో పోలిస్తే దీనికి ఎక్కువ setup అవసరం. dump మరియు restore మీ maintenance windowలో పూర్తికానింత పెద్ద database ఉన్నప్పుడు ఇది ఉపయోగకరంగా ఉంటుంది. సాధారణ single-server migration కోసం dump ఉత్తమమైన ఎంపిక.

కట్‌ఓవర్‌కు ముందు certificates ను పునర్నిర్మించండి, తరువాత కాదు

TLS certificate domain name కు అనుసంధానమై ఉంటుంది, IP address కు కాదు. అందువల్ల certificate file ను ఎలాంటి సమస్య లేకుండా తరలించవచ్చు. అయితే renewal సజావుగా తరలదు. Certbot యొక్క default HTTP-01 challenge ద్వారా certificate authority, ధృవీకరించాల్సిన name వద్ద port 80 మీద file ను fetch చేయమని కోరుతుంది. DNS కొత్త server ను సూచించే వరకు ఆ fetch పాత server కు చేరుతుంది. అందువల్ల కొత్త server యొక్క renewal విఫలమవుతుంది.

మొదటి ఎంపికగా ఇప్పటికే ఉన్న certificates మరియు వాటి renewal state ను copy చేయండి. వాటిని ఏ server ఉంచినా, expiry date వరకు అవి చెల్లుబాటులో ఉంటాయి.

# old server
sudo rsync -aHAX -e 'ssh -i /root/.ssh/id_ed25519' \
  /etc/letsencrypt/ root@203.0.113.20:/etc/letsencrypt/

/etc/letsencrypt/renewal/ కింద ఉన్న ప్రతి file certificate ను issue చేసిన authenticator plugin పేరును సూచిస్తుంది. అందువల్ల అదే plugin ను కొత్త server లో install చేయండి (ఉదాహరణకు python3-certbot-nginx). లేకపోతే unknown authenticator గురించి message తో మొదటి renewal విఫలమవుతుంది. దానిపై ఆధారపడే ముందు renewal పనిచేస్తుందని నిర్ధారించండి:

# new server, after DNS has moved
sudo certbot renew --dry-run

రెండవ ఎంపికగా కొత్త server లో DNS-01 challenge ఉపయోగించి తాజా certificate ను issue చేయండి. ఇది TXT record ద్వారా నియంత్రణను నిరూపిస్తుంది మరియు port 80 ను అసలు ఉపయోగించదు. Migration కు ముందే ఇది పనిచేస్తుంది, ఎందుకంటే ఆ సమయంలో name ఇప్పటికీ పాత server కు resolve అవుతుంది. DNS provider ను automate చేయగలిగితే ఇది మరింత సరళమైన ఎంపిక. DNS-01 challenge తో certificates issue చేయడంలో plugin మరియు credential setup వివరించబడింది.

ఏ ఎంపికను ఉపయోగించినా, DNS మార్చకుండా కొత్త server వాస్తవంగా ఏ certificate ను అందిస్తుందో తనిఖీ చేయండి:

# your laptop
echo | openssl s_client -connect 203.0.113.20:443 -servername example.com 2>/dev/null \
  | openssl x509 -noout -subject -dates -issuer

-servername SNI (server name indication) ను పంపుతుంది. దీని వల్ల web server సరైన virtual host ను ఎంచుకుంటుంది. దీనిని వదిలేస్తే, ఆ IP కు సంబంధించిన default certificate అందుతుంది. అప్పుడు కనిపించే mismatch నిజమైన సమస్యలా అనిపిస్తుంది, కానీ అది సమస్య కాదు.

కట్‌ఓవర్‌కు కొన్ని రోజుల ముందు DNS TTL ను తగ్గించండి

జాగ్రత్తగా చేసే migration కూడా DNS కారణంగా విఫలం కావచ్చు. కారణం, ఇందులో ఆలస్యం అంతర్గతంగా ఉంటుంది. ఆ రోజున దాన్ని తగ్గించడం సాధ్యం కాదు. మీ A record ను cache చేసిన resolver, అందుకున్న TTL (time to live) గడువు పూర్తయ్యే వరకు అదే record ను అందిస్తూనే ఉంటుంది. పది నిమిషాల క్రితం పాత విలువతో record ను cache చేసిన resolver కు ఇప్పుడు TTL తగ్గించడం వల్ల ఉపయోగం ఉండదు. అది పాత TTL మిగిలినంతకాలం పాత విలువనే ఉంచుతుంది. ఆ తర్వాత మాత్రమే కొత్త, తక్కువ TTL ను తెలుసుకుంటుంది. అందువల్ల cutover కు కనీసం ఒక పూర్తి పాత TTL వ్యవధి ముందే TTL ను తగ్గించండి. ఒక రోజు ముందుగా చేయడం సౌకర్యవంతమైన విధానం. ఇక్కడి అంశాలు మీకు కొత్తవైతే, records, resolvers మరియు caching పై వివరణ నేపథ్య సమాచారాన్ని అందిస్తుంది.

క్రింది సంఖ్యలు TTL ఆధారంగా చేసిన గణనలు. అవి కొలతల ఫలితాలు కావు.

[
  {
    "label": "TTL 3600 s (common default)",
    "ttl_seconds": 3600,
    "worst_case_stale_minutes": 60
  },
  {
    "label": "TTL 900 s",
    "ttl_seconds": 900,
    "worst_case_stale_minutes": 15
  },
  {
    "label": "TTL 300 s (lowered for cutover)",
    "ttl_seconds": 300,
    "worst_case_stale_minutes": 5
  },
  {
    "label": "TTL 60 s (short window)",
    "ttl_seconds": 60,
    "worst_case_stale_minutes": 1
  }
]

3600 seconds TTL తో ప్రచురించిన A record, మీరు దాన్ని మార్చిన తర్వాత కూడా 60 నిమిషాల వరకు వినియోగదారులను పాత IP కు పంపవచ్చు. దాన్ని 300 seconds కు తగ్గిస్తే, అత్యంత ప్రతికూల పరిస్థితిలో ఈ వ్యవధి 5 నిమిషాలకు తగ్గుతుంది. ఈ సంఖ్యలను హామీగా కాకుండా కనిష్ఠ అంచనాగా పరిగణించండి. కొన్ని resolvers తమ స్వంత minimum TTL ను అమలు చేసి, దానికంటే తక్కువ విలువలను విస్మరిస్తాయి. కొన్ని application runtimes resolved address ను process నడుస్తున్నంతకాలం cache చేస్తాయి. అందువల్ల మీ మార్పుకు ముందు ప్రారంభమైన client, restart అయ్యే వరకు మళ్లీ lookup చేయకపోవచ్చు.

తగ్గించిన TTL అమల్లోకి వచ్చిందో తనిఖీ చేసేటప్పుడు, మీ స్వంత cache ను కాకుండా authoritative answer ను చదవండి:

# your laptop: ask the zone's own nameserver, so no cache is involved
dig +short NS example.com
dig +noall +answer @$(dig +short NS example.com | head -n1) example.com A

ఆ answer line లోని రెండవ field TTL ను seconds లో చూపిస్తుంది. తరువాత తరచుగా మరచిపోయే records ను కూడా పరిశీలించండి: పాత server వద్ద IPv6 ఉంటే AAAA record, ప్రత్యేక A record గా ఉన్నప్పుడు CNAME కాకుండా ఉండే www name, server వైపు చూపే ఏదైనా MX record, పాత IP ను పేర్కొనే SPF record, అలాగే కొత్త address పై reverse DNS (PTR) record. Server mail పంపితే cutover కు ముందే provider యొక్క control panel ద్వారా PTR ను సెట్ చేయండి. Receiving mail servers దాన్ని తనిఖీ చేస్తాయి. PTR లేకపోతే, మిగతావన్నీ సరిగ్గా కనిపించినా కొన్ని గంటల తర్వాత mail rejected కావచ్చు.

DNS ను మార్చే ముందు కొత్త server ను దాని IPపై ధృవీకరించండి

DNS ఇప్పటికీ పాత server వైపు చూపుతున్నప్పటికీ, కొత్త server పై మొత్తం అప్లికేషన్‌ను పరీక్షించవచ్చు. ఒక అభ్యర్థన కోసం name lookup ను override చేయండి:

# your laptop: force one name to the new IP, for this request only
curl -sS --resolve example.com:443:203.0.113.20 \
  -o /dev/null -w '%{http_code} %{ssl_verify_result}\n' https://example.com/

--resolve కనెక్షన్ ఎక్కడికి వెళ్తుందో మాత్రమే మారుస్తుంది. TLS certificate ను ఇప్పటికీ అసలు పేరుతోనే తనిఖీ చేస్తుంది. అందువల్ల certificate తో పాటు service కూడా సరిగ్గా పనిచేస్తోందని ఇది ధృవీకరిస్తుంది. chain ధృవీకరించబడినప్పుడు %{ssl_verify_result}, 0 ను ప్రింట్ చేస్తుంది.

బ్రౌజర్‌లో site ను క్లిక్ చేస్తూ పరీక్షించాలంటే, మీ laptop లోని /etc/hosts కు లేదా Windows లోని C:\Windows\System32\drivers\etc\hosts కు ఒక line జోడించి, మొత్తం machine కోసం name ను override చేయండి:

203.0.113.20 example.com www.example.com

తరువాత user ఉపయోగించినట్లే అప్లికేషన్‌ను పరిశీలించండి. Login చేయండి. Database నుంచి data చదివే page ను load చేయండి. Database లో data రాసే form ను submit చేయండి. File ను upload చేసి, అది disk పై సరిగ్గా చేరిందని నిర్ధారించండి. Email పంపే ఏదైనా చర్యను trigger చేసి, అది చేరిందో తనిఖీ చేయండి. కొత్త IP నుంచి outbound SMTP తరచుగా అనుకోని సమస్యలను కలిగిస్తుంది. పని పూర్తయిన వెంటనే hosts line ను తొలగించండి. దాన్ని అలాగే ఉంచితే, మిగతా అందరికీ site సరిగ్గా కనిపిస్తున్నప్పటికీ, మీరు ఒక గంట పాటు దానిని debug చేసే పరిస్థితి వస్తుంది.

కట్‌ఓవర్: దశలవారీగా

1. కొన్ని రోజుల ముందుగా: TTL ను తగ్గించండి, bulk rsync ను నడపండి, కొత్త server ను సిద్ధం చేసి hosts override ద్వారా దాని వెనుక పరీక్షించండి.
2. కట్‌ఓవర్ రోజున, window ప్రారంభానికి ముందు: ప్రతి third-party allowlist కు కొత్త IP ను జోడించండి. కొత్త server యొక్క backup job configure అయి, మీ repository ను లక్ష్యంగా చేసుకుని ఉందని నిర్ధారించండి.
3. window ప్రారంభించండి: పాత server లో application ను maintenance mode లో ఉంచండి. దీనివల్ల అది writes ను స్వీకరించడం ఆపుతుంది.
4. తుది database dump తీసుకోండి. తరువాత --delete తో తుది rsync pass ను నడపండి.
5. కొత్త server లో dump ను restore చేసి services ను start చేయండి.
6. --resolve మరియు hosts override ద్వారా మళ్లీ పరీక్షించండి. ఇందులో ఒక నిజమైన write ను కూడా పరీక్షించండి.
7. A మరియు AAAA records ను కొత్త IP కు మార్చండి.
8. రెండు servers ను monitor చేయండి. పాత server యొక్క access log లో ఇంకా అక్కడికి వస్తున్న users కనిపిస్తారు. TTL వ్యవధిలో ఆ సంఖ్య క్రమంగా సున్నాకు చేరాలి.
9. maintenance page ను తొలగించండి.
10. పాత server ను కనీసం ఒక వారం పాటు నడుస్తున్న స్థితిలో, ఎలాంటి మార్పులు చేయకుండా ఉంచండి.

Maintenance mode దశను చాలామంది దాటవేస్తారు. అయితే రక్షణ కల్పించేది ఇదే. కొత్త database ఒకసారి write ను స్వీకరించిన తర్వాత rollback చేయాలంటే, ఆ write ను కోల్పోవాలి లేదా కొత్త database ను dump చేసి మళ్లీ పాత database లోకి load చేయాలి. కొన్ని నిమిషాల read-only window తక్కువ ఖర్చుతో కూడుకున్నది. రెండు databases లోనూ writes జరిగితే, వాటిని manually reconcile చేయడానికి రోజులు పడతాయి.

Rollback ప్రణాళిక

Rollback ఒకే చర్యతో పూర్తవుతుంది: DNS records ను తిరిగి 198.51.100.10 కు మార్చాలి. ఇది ముందుగా మీరు చేసిన నాలుగు పనుల వల్ల మాత్రమే సాధ్యమవుతుంది.

• పాత server ఇంకా నడుస్తోంది. దాని services అందుబాటులో ఉన్నాయి, data యథాతథంగా ఉంది. మీరు అక్కడ writes ను ఆపారు; దాన్ని decommission చేయలేదు.
• TTL ఇంకా తక్కువగానే ఉంది. అందువల్ల ముందుకు మారిన వేగంతోనే తిరిగి మారవచ్చు.
• పాత IP ను భర్తీ చేయకుండా, కొత్త IP ను third-party allowlists కు జోడించారు. పాత address ను తొలగిస్తే payment gateway వద్ద rollback మార్గం విఫలమవుతుంది.
• కొత్త server లో మీరు గుర్తించలేని writes ఏవీ జరగలేదు. ఇప్పటివరకు జరిగిన writes మీ స్వంత test transactions మాత్రమే.

window ప్రారంభమయ్యే ముందే rollback ను ప్రేరేపించే పరిస్థితులను నిర్ణయించండి. రెండు triggers సరిపోతాయి: నిర్ణయించిన నిమిషాల సంఖ్యలో diagnose చేయలేని ఏదైనా error, మరియు ఏ పరిమాణంలోనైనా data loss. వీటిని ముందుగానే రాసి ఉంచడం వల్ల పది నిమిషాల outage ఎక్కువసేపు కొనసాగేలా చేసే, ఊహాగానాలతో గడిచే గంటను నివారించవచ్చు.

మైగ్రేషన్ విజయవంతమైందని నిర్ధారించండి

సైట్ లోడ్ అయినప్పుడు మైగ్రేషన్ పూర్తయినట్లు కాదు. తర్వాత మాత్రమే విఫలమయ్యే అంశాలను పరిశీలించండి.

# new server
systemctl --failed
journalctl -p err -b --no-pager | tail -n 40
sudo certbot certificates
sudo systemctl list-timers --all --no-pager

systemctl --failed reporting 0 loaded units listed మీరు కోరుకునే ఫలితం. certbot certificates లో మీరు ఆశించే expiry dates కనిపించాలి. list-timers లో మీ inventoryలోని ప్రతి scheduled jobకు ఖాళీగా కాకుండా వాస్తవ next-run time కనిపించాలి.

తర్వాత కొత్త serverను ఉద్దేశపూర్వకంగా ఒకసారి reboot చేయండి. ఆ సమయంలో దాన్ని గమనిస్తూ ఉండండి. ఎవరైనా చేతితో start చేసి enable చేయని service, తెల్లవారుజామున మూడు గంటలకు జరిగే మొదటి అనుకోని reboot వరకు సరిగ్గా పనిచేస్తుంది.

# new server
sudo reboot

# your laptop, once it comes back
curl -sS -o /dev/null -w '%{http_code}\n' https://example.com/

అప్లికేషన్ containersలో నడుస్తుంటే ఇదే సమస్య వేరే రూపంలో కనిపిస్తుంది, ఎందుకంటే reboot తర్వాత తిరిగి ప్రారంభించడానికి compose stackకు స్పష్టమైన restart policy అవసరం.

వాయిదా వేయడం సులభమైనదైనా, అత్యంత ముఖ్యమైన చివరి తనిఖీ backup job. backup లేని serverతో ముగిసే migration ఒక ప్రమాదాన్ని మరొక ప్రమాదంతో మార్చినట్లే. కొత్త boxలో backupను చేతితో run చేసి, దానిలోని ఒక fileను temporary directoryకి restore చేయండి. మీరు వాస్తవంగా పరీక్షించిన restoreతో కూడిన restic repository ఈ అవసరానికి ఉపయోగపడే రూపం. పాత మరియు కొత్త serverలను ఒక వారం పాటు పక్కపక్కనే నడుపుతున్నట్లయితే, ప్రతి hostను చేరుకోవడానికి మరియు configure చేయడానికి ఒక స్థిరమైన విధానం రెండూ liveగా ఉన్నప్పుడు వాటి configurationలు వేరుపడకుండా నిరోధిస్తుంది.

కట్‌ఓవర్ తర్వాత: పాత సర్వర్ మరియు చివరి పనులు

పాత సర్వర్‌ను ఒకటి నుంచి రెండు వారాల పాటు ఉంచండి. మీరు రద్దు చేయబోతున్న plan కు మరో నెల ఖర్చవుతుంది, కానీ మీ వద్ద ఉన్న ఏకైక rollback అదే. ఆ తర్వాత మిగిలిన పనులను పూర్తి చేయండి.

• కొత్త box కోసం మీ ~/.ssh/config లో అదే hostname ను మళ్లీ ఉపయోగిస్తే, మొదటి connectionలో WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED! కనిపిస్తుంది. కారణం, ఆ పేరు ఇప్పుడు వేరే host keyతో సమాధానం ఇస్తోంది. అది ఎందుకు మారిందో నిర్ధారించిన తర్వాత ssh-keygen -R example.com తో పాత entryని తొలగించండి. హెచ్చరిక కనిపించిన ప్రతిసారీ ఆలోచించకుండా తొలగించవద్దు, ఎందుకంటే interception attack జరిగినప్పుడు కూడా ఇదే హెచ్చరిక కనిపిస్తుంది. ఏ keys ఏ వనరులను చేరుకోగలవో సమీక్షించడానికి migration సరైన సమయం కూడా. దీనికోసమే చిన్న fleetలో SSH key నిర్వహణ ఉపయోగపడుతుంది.
• పాత సర్వర్‌కు ఒక చివరి snapshot లేదా backup తీసుకుని, దాన్ని పాత providerకు చెందని వేరే ప్రదేశంలో నిల్వ చేయండి.
• monitoring checks, SPF records, third-party allowlists నుంచి పాత IPని తొలగించండి. ఈ క్రమంలోనే, చివరి పనిగా చేయండి.
• ఆ చివరి copyని వేరే ప్రదేశంలో సరిగ్గా చదవగలమని నిర్ధారించిన తర్వాత మాత్రమే పాత planను రద్దు చేయండి.

FAQ

కొత్త VPS కు సర్వర్‌ను మైగ్రేట్ చేయడానికి ఎంత సమయం పడుతుంది?

వినియోగదారులకు కనిపించే outage సాధారణంగా చివరి database dump, చివరి rsync pass మరియు service start సమయంలోనే ఉంటుంది. చిన్న అప్లికేషన్‌కు ఇది సాధారణంగా పది నుంచి ముప్పై నిమిషాలు పడుతుంది. అయితే మొత్తం calendar time ఎక్కువగా ఉంటుంది. మార్పు చేయడానికి కనీసం ఒక పాత-TTL వ్యవధి ముందు DNS TTL ను తగ్గించాలి. ఒక రోజు ముందుగా తగ్గించడం మరింత సురక్షితం. Bulk data copy ను కూడా కొన్ని రోజుల ముందే ప్రారంభించండి. ఇది live server పై నడుస్తుంది. తరువాత దీన్ని మళ్లీ నడిపితే, చివరి pass తర్వాత మారిన డేటా మాత్రమే బదిలీ అవుతుంది.

నడుస్తున్న MySQL లేదా PostgreSQL database ను dump చేయకుండా rsync చేయవచ్చా?

లేదు. Database ఒకేసారి అనేక files లో రాస్తుండగా rsync వాటిని file by file కాపీ చేస్తుంది. అందువల్ల కాపీలో వేర్వేరు సమయాలకు చెందిన pages ఉంటాయి. Database లో ఎప్పుడూ లేని state ను అది సూచిస్తుంది. Database ప్రారంభం కావడానికి నిరాకరించవచ్చు. లేదా ప్రారంభమై, query దెబ్బతిన్న page ను చేరుకున్నప్పుడు తరువాత విఫలమవచ్చు. pg_dump ను pg_dumpall --globals-only తో ఉపయోగించండి, లేదా mysqldump --single-transaction ను ఉపయోగించండి. మరో మార్గంగా ముందుగా database ను ఆపి, తరువాత files ను కాపీ చేయండి. పెద్ద PostgreSQL cluster కోసం, నడుస్తున్న server యొక్క consistent physical copy ను pg_basebackup సృష్టిస్తుంది.

DNS మార్చే ముందు కొత్త VPS ను ఎలా పరీక్షించాలి?

మీ స్వంత machine పై name lookup ను override చేయండి. ఒక్క request కోసం, certificate ను అసలు name కు వ్యతిరేకంగా తనిఖీ చేస్తూనే connection ను కొత్త IP కు curl --resolve example.com:443:203.0.113.20 https://example.com/ పంపుతుంది. Browser testing కోసం, మీ laptop లోని /etc/hosts కు 203.0.113.20 example.com జోడించండి. Login, database read, form write మరియు file upload ను పరీక్షించండి. తరువాత ఆ line ను తొలగించండి. Certificate ను మాత్రమే పరిశీలించడానికి openssl s_client -connect 203.0.113.20:443 -servername example.com అమలు చేయండి.

ఏ TTL సెట్ చేయాలి? దాన్ని ఎప్పుడు తగ్గించాలి?

A మరియు AAAA records ను 300 seconds కు తగ్గించండి. Cutover కు కనీసం ఒక పూర్తి పాత-TTL వ్యవధి ముందు దీన్ని చేయండి. మీ మార్పుకు ముందు record ను cache చేసిన resolver, పాత TTL మిగిలినంతకాలం పాత value ను ఉంచుతుంది. కాబట్టి పాత TTL 86400 అయితే, ఒక గంట ముందుగా TTL తగ్గించినా ప్రయోజనం ఉండదు. Migration తర్వాత కొన్ని రోజులకు, పాత server యొక్క access log నిశ్శబ్దంగా మారిన తరువాత, TTL ను మీ సాధారణ value కు తిరిగి పెంచండి.

TLS certificate ను కాపీ చేయాలా, లేదా కొత్త server పై కొత్తది జారీ చేయాలా?

రెండు విధానాలూ పనిచేస్తాయి. /etc/letsencrypt/ ను కాపీ చేస్తే certificate దాని ప్రస్తుత expiry వరకు చెల్లుబాటులో ఉంటుంది. అయితే కొత్త server పై అదే certbot authenticator plugin ను install చేయాలి. లేకపోతే మొదటి renewal విఫలమవుతుంది. అందువల్ల DNS switch తర్వాత నిర్ధారించడానికి certbot renew --dry-run అమలు చేయండి. DNS-01 challenge ఉపయోగించగలిగితే కొత్త certificate జారీ చేయడం మరింత శుభ్రమైన విధానం. ఇది TXT record ద్వారా control ను నిరూపిస్తుంది. DNS కొత్త server వైపు చూపించే ముందే ఇది పనిచేస్తుంది. DNS మారే వరకు కొత్త server పై HTTP-01 challenge ను ఉపయోగించలేరు. Validation request పాత server కు చేరుతుంది.