VPS Snapshot, Backup மற்றும் Clone: வித்தியாசம் என்ன?

Snapshot, backup மற்றும் clone ஆகியவற்றின் உண்மையான அர்த்தம்

VPS snapshot என்பது உங்கள் server-ன் disk image ஆகும். இது உங்கள் provider-ன் உள்கட்டமைப்பில், உங்கள் கணக்கிற்குள் சேமிக்கப்படுகிறது. Backup என்பது உங்கள் தரவுகளின் ஒரு சுதந்திரமான நகலாகும். இதை நீங்கள் வேறு எங்கும் restore செய்ய முடியும்; இதற்கு அசல் தரவை வைத்திருந்த provider-ன் உதவி தேவையில்லை. Clone என்பது ஒரு snapshot-லிருந்து உருவாக்கப்படும் புதிய instance ஆகும். எனவே, இது அசல் server-ன் அடையாளத்தோடு (identity) அதன் துல்லியமான நகலாகத் தொடங்குகிறது.

இவை வெவ்வேறு சிக்கல்களைத் தீர்க்கின்றன. ஒரு தோல்வியுற்ற upgrade-ஐ சில நிமிடங்களில் சரிசெய்ய snapshot உதவுகிறது, ஆனால் கணக்கு முடக்கப்பட்டால் இது பயனளிக்காது. Provider நிறுவனம் மூடப்பட்டாலும் backup பாதுகாப்பாக இருக்கும், ஆனால் இதை restore செய்ய அதிக நேரம் எடுக்கும், ஏனெனில் முதலில் நீங்கள் புதிய machine-ஐ உருவாக்க வேண்டும். Clone மூலம் ஒரே படியில் இரண்டாவது server-ஐ இயக்க முடியும், ஆனால் இது ஒரே அடையாளத்தைக் கொண்ட இரண்டு machine-களை உருவாக்கும்.

VPS snapshot ஏன் ஒரு backup ஆகாது

இதற்கான சிக்கல் தரவின் தரம் சார்ந்தது அல்ல, அது தோல்வி அடையும் எல்லை (failure domain) சார்ந்தது. ஒரு snapshot உங்கள் provider-ன் storage தளத்தில், பெரும்பாலும் அதே server இருக்கும் region-ல், மற்றும் எப்போதும் அதே account-க்குள் தான் இருக்கும். ஒரே ஒரு நிகழ்வு server-ஐயும் அதன் snapshot-ஐயும் ஒரே நேரத்தில் அழித்துவிடக்கூடும்.

• உங்கள் account முடக்கப்படுதல், பணம் செலுத்துவதில் தோல்வி, அல்லது login விவரங்கள் திருடப்படுதல்.
• API access கொண்ட ஒரு நபர் அல்லது script instance-ஐ நீக்குதல். பல provider-களில், ஒரு instance-ஐ நீக்கும்போது அதனுடன் அதன் snapshot-களும் நீக்கப்படும். அவ்வாறு நடக்காது என்று கருதுவதற்கு முன், உங்கள் provider-ன் ஆவணப்படுத்தப்பட்ட செயல்பாட்டை வாசிக்கவும்.
• அந்த region-ல் ஏற்படும் ஒரு பெரிய பாதிப்பால், அங்குள்ள அனைத்தும் ஒரே நேரத்தில் அணுக முடியாத நிலைக்குச் செல்லுதல்.
• server-ல் root பயனராக இயங்கும் ஏதேனும் ஒன்று, நீங்கள் /root-ல் விட்டுச் சென்ற provider API token-ஐக் கண்டறிந்து, disk-ஐத் தொடுவதற்கு முன்பே snapshot-களை நீக்கிவிடுதல்.

இந்த நான்கு சிக்கல்களையும் தாண்டி எஞ்சியிருக்கும் நகலே backup ஆகும். இதற்கான சோதனை ஒரு கேள்விதான்: இன்று மதியம் உங்கள் provider account இல்லாமல் போனால், உங்களால் எதை மீட்டெடுக்க முடியும், அதை எங்கே மீட்டெடுப்பீர்கள்? இந்தக் கேள்விக்குத் தோல்வியடையும் எதுவும் வெறும் rollback கருவி மட்டுமே. snapshot-களைத் தொடர்ந்து எடுங்கள், ஏனெனில் எதையும் விட வேகமாக அதை மீட்டெடுக்க முடியும். அதன்பின், உங்கள் provider-ன் கட்டுப்பாட்டில் இல்லாத storage-ல் இரண்டாவது நகலை வைத்திருங்கள்.

பழைய விதி இப்போதும் பொருந்தும்: தரவின் மூன்று நகல்கள், இரண்டு வகையான storage-களில், அதில் ஒன்று அந்தத் தளத்திற்கு வெளியேயானது. ஒரு provider snapshot மற்றும் தனித்தனி infrastructure-ல் உள்ள restic backup repository ஆகியவற்றைச் சேர்ப்பதன் மூலம், இரண்டு முக்கிய அங்கங்களுடன் இந்தத் தேவையைப் பூர்த்தி செய்ய முடியும்.

இயங்கும் database-ன் snapshot ஏன் சிதைந்த நிலையில் மீட்கப்படலாம்

ஒரு provider snapshot, block device-ஐ அது இருக்கும் நிலையிலேயே அப்படியே நகலெடுக்கிறது. இது உங்கள் application-களை முதலில் நிறுத்துமாறு கோருவதில்லை, மேலும் page cache-ல் தங்கியிருக்கும் எதையும் இதால் பார்க்க முடியாது. எனவே, இந்த image அதிகபட்சமாக crash-consistent நிலையில் மட்டுமே இருக்கும். மின் இணைப்பை திடீரெனத் துண்டித்தால் வட்டு (disk) எப்படி இருக்குமோ, அதே நிலையில் இது இருக்கும்.

பெரும்பாலான stack-கள் இதைச் சமாளித்துவிடும். ext4 மற்றும் XFS ஆகியவை mount செய்யும்போது தங்கள் journal-ஐ மீண்டும் இயக்கும் (replay), எனவே filesystem இயல்பு நிலைக்கு வரும். PostgreSQL தொடங்கும் போது அதன் write-ahead log-ஐ மீண்டும் இயக்கும், அந்த log-ல் இது குறிப்பிடப்பட்டிருக்கும்:

LOG:  database system was not properly shut down; automatic recovery in progress

InnoDB-வும் இதையே செய்கிறது மற்றும் தொடக்கத்தின் போது அதன் சொந்த crash recovery வரிகளை அச்சிடுகிறது. அந்த recovery என்பது database வடிவமைக்கப்பட்டபடி செயல்படுவதாகும், எனவே அமைதியாக இருக்கும் PostgreSQL அல்லது MySQL-ன் single-volume snapshot பொதுவாகச் சரியாகவே மீட்கப்படும்.

Crash-consistent நிலை போதுமானதாக இல்லாத சூழல்கள் உண்மையானவை, அவைதான் பாதிப்பை ஏற்படுத்தும். உங்கள் தரவு இரண்டு volumes-ல் பரவியிருந்தால், root disk மற்றும் தனிப்பட்ட data disk ஆகியவை வெவ்வேறு நேரங்களில் snapshot எடுக்கப்படும். இதனால் தரவுக் கோப்புகளும் (data files) log directory-யும் முரண்படலாம், அப்போது recovery செய்வதற்குச் சரியான தரவு இருக்காது. ஒரு application fsync-ஐ அழைக்காமல் எழுதும் எந்தவொரு கோப்பும், உதாரணமாக பாதியில் பெறப்பட்ட upload அல்லது queue file, பாதியாக வெட்டப்பட்ட நிலையில் (truncated) வரலாம். Application நினைவகத்தில் (memory) வைத்துக்கொண்டு குறிப்பிட்ட கால இடைவெளியில் எழுதும் எந்தவொரு தரவும் இந்த image-ல் இருக்காது.

எனவே, snapshot எடுப்பதற்கு முன் disk-ல் ஒரு dump-ஐ எழுதவும். அப்போது, live data files எந்த நிலையில் இருந்தாலும், உள்ளுக்குள் சீரான (internally consistent) ஒரு கோப்பு அந்த image-ல் இருக்கும்.

sudo -u postgres pg_dumpall --clean --file=/var/backups/pg-$(date +%F).sql
sudo mysqldump --single-transaction --routines --all-databases > /var/backups/mysql-$(date +%F).sql

--single-transaction, InnoDB tables-ஐ எழுதுபவர்களைத் தடுக்காமல் சீரான dump-ஐ வழங்குகிறது, ஏனெனில் அந்த dump ஒரு repeatable-read transaction-க்குள் இயங்குகிறது. இது MyISAM tables-க்கு பொருந்தாது, அதற்கு lock அல்லது server-ஐ நிறுத்த வேண்டியது அவசியம். dump காலியாகவோ அல்லது பாதியாகவோ இல்லை என்பதை உறுதிப்படுத்திய பின் அதை நம்புங்கள்: முழுமையான mysqldump-ன் இறுதியில் tail -n 1 /var/backups/mysql-$(date +%F).sql என்பது Dump completed என்ற குறிப்புடன் முடியும்.

உங்களிடம் தனிப்பட்ட data volume இருந்தால், snapshot-க்குத் தேவையான சில நொடிகள் அதை freeze செய்யலாம்:

sudo fsfreeze -f /srv
# take the snapshot from your provider's panel or API
sudo fsfreeze -u /srv

Data volume-ஐ மட்டும் freeze செய்யவும். ஒருபோதும் /-ஐ freeze செய்ய வேண்டாம். Frozen root filesystem, அந்த server-ல் நடக்கும் அனைத்து எழுதும் செயல்பாடுகளையும் தடுக்கும், unfreeze கட்டளையைத் தட்டச்சு செய்ய நீங்கள் பயன்படுத்தும் shell உட்பட. இதனால் நீங்கள் வெளியேற்றப்படுவீர்கள் (lock out) மற்றும் hard reset செய்ய வேண்டியிருக்கும்.

ஆஃப்சைட் (offsite) பகுதி: restic அல்லது Borg

ஸ்னாப்ஷாட் (snapshot) என்பது வேகமான பகுதி. ஆஃப்சைட் நகல் என்பது உங்கள் சேவை வழங்குநரின் (provider) தோல்வியிலும் தரவைப் பாதுகாக்கும் பகுதியாகும். restic ஒரு சிறந்த தேர்வாகும், ஏனெனில் இது deduplication செய்கிறது, client-side-ல் குறியாக்கத்தை (encryption) மேற்கொள்கிறது, மேலும் S3-compatible object storage, SFTP அல்லது சாதாரண directory-களில் தரவை எழுதுகிறது. இதற்கு storage VPS-ஐ ஆஃப்சைட் இலக்காகப் பயன்படுத்துவது சிறப்பாகச் செயல்படும், ஏனெனில் பேக்கப் களஞ்சியங்களுக்கு (repositories) IOPS-ஐ விட அதிக சேமிப்புத் திறன் (capacity) தேவைப்படுகிறது.

sudo apt update && sudo apt install -y restic
sudo sh -c 'umask 077; head -c 24 /dev/urandom | base64 > /root/.restic-pass'
sudo chmod 600 /root/.restic-pass
sudo cat /root/.restic-pass

அந்த passphrase-ஐ இப்போதே ஒரு password manager-ல் சேமிக்கவும்; அது இந்த server-ல் இருக்கக்கூடாது. passphrase இல்லாமல் restic repository-ஐத் திறக்க முடியாது, மேலும் தரவை மீட்க வேறு வழியும் இல்லை. நீங்கள் இழந்த server-ல் மட்டுமே அந்த password இருந்திருந்தால், உங்கள் பேக்கப் வெறும் குறியாக்கம் செய்யப்பட்ட பயனற்ற தரவாகவே இருக்கும்.

export RESTIC_REPOSITORY="s3:https://s3.example.com/vps-backups"
export RESTIC_PASSWORD_FILE=/root/.restic-pass
export AWS_ACCESS_KEY_ID="..."
export AWS_SECRET_ACCESS_KEY="..."
sudo -E restic init
sudo -E restic backup /etc /srv /var/backups
sudo -E restic snapshots

sudo -E அந்த variables-ஐ வைத்திருக்கிறது, ஏனெனில் அது இல்லையெனில் root-க்கு ஒரு சுத்தமான சூழல் மட்டுமே கிடைக்கும், மேலும் repository location குறிப்பிடப்படவில்லை என restic பிழையைத் தெரிவிக்கும். restic snapshots நீங்கள் இப்போது செய்த run-ஐ அதன் host மற்றும் paths-உடன் பட்டியலிட வேண்டும். repository-ஐ அவ்வப்போது அட்டவணைப்படி சரிபார்க்கவும்; கட்டமைப்பை மட்டும் பார்க்காமல், சில தரவுகளை மீண்டும் படித்துச் சரிபார்க்கவும்:

sudo -E restic check --read-data-subset=5%
sudo -E restic restore latest --target /tmp/restore-check
sudo -E restic forget --keep-daily 7 --keep-weekly 4 --keep-monthly 6 --prune

சோதிக்கப்படாத பேக்கப் என்பது வெறும் ஊகம் மட்டுமே. குறைந்தபட்சம் ஒரு முறையாவது வேறொரு VPS-ல் தரவை மீட்டு (restore) சோதிக்கவும். அந்த நேரத்தைக் குறித்துக் கொள்ளவும், ஏனெனில் அந்த கால அளவுதான் உங்கள் உண்மையான மீட்பு இலக்கு (recovery target). Borg மற்றொரு சிறந்த தேர்வாகும்; இது object storage-க்கு பதிலாக SSH வழியாக repository-ஐச் சேமிக்கிறது. இவற்றிற்கிடையேயான வேறுபாடுகள் restic மற்றும் BorgBackup ஒப்பீடு பகுதியில் விளக்கப்பட்டுள்ளன.

ஒரு cloned VPS-ஐ production-க்கு கொண்டு செல்லும் முன் சரிசெய்ய வேண்டியவை

ஒரு clone என்பது அசல் server-ன் துல்லியமான நகல். இதுவே அதன் சிறப்பம்சம், ஆனால் இதுவே சிக்கலும் கூட. அசலை தனித்துவமாக்கிய அனைத்தும் இதில் நகலெடுக்கப்படுவதால், அவை ஒன்றோடொன்று மோதிக்கொள்ளும்.

SSH host keys-ஐ மீண்டும் உருவாக்கவும். இந்த clone அசல் server-ன் /etc/ssh/ssh_host_* கோப்புகளைக் கொண்டிருப்பதால், இரண்டு server-களும் ஒரே host identity-ஐக் காட்டுகின்றன. ஒரு server-ஐக் கட்டுப்படுத்துபவர், அந்த key-ஐ ஏற்கனவே ஏற்றுக்கொண்ட எந்தவொரு client-க்கும் தன்னை அசல் server-ஆகக் காட்டிக்கொள்ள முடியும். SSH எந்த எச்சரிக்கையும் தராது, ஏனெனில் client எதிர்பார்த்த அதே key தான் அங்கும் உள்ளது.

sudo rm -f /etc/ssh/ssh_host_*
sudo ssh-keygen -A
sudo systemctl restart ssh
ssh-keygen -lf /etc/ssh/ssh_host_ed25519_key.pub

ssh-keygen -A கட்டளையானது daemon எதிர்பார்க்கும் அனைத்து வகையான புதிய key-களையும் உருவாக்கும். கடைசி கட்டளையின் fingerprint, அசல் server-ல் இருந்ததிலிருந்து மாறுபட்டிருக்க வேண்டும். sshd-ஐ restart செய்வது ஏற்கனவே உள்ள இணைப்புகளைத் துண்டிக்காது என்பதால், உங்கள் தற்போதைய session அப்படியே இருக்கும். clone-க்கு யாரும் இணைவதற்கு முன்பே இதைச் செய்துவிடவும். இதைத் தள்ளிப்போட்டால், ஏற்கனவே அந்த key-ஐ நம்பியிருந்த ஒவ்வொரு client-க்கும் WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED! பிழை ஏற்படும், அவர்கள் முதலில் ssh-keygen -R <host> கட்டளையை இயக்க வேண்டியிருக்கும்.

Machine ID-ஐ reset செய்யவும். /etc/machine-id என்பது systemd முதல்முறை boot ஆகும்போது உருவாக்கும் ஒரு தனித்துவமான அடையாளமாகும்; clone இதை அப்படியே பெற்றுக்கொள்கிறது.

sudo truncate -s 0 /etc/machine-id
sudo rm -f /var/lib/dbus/machine-id
sudo ln -s /etc/machine-id /var/lib/dbus/machine-id
sudo reboot

ஒரு காலியான /etc/machine-id கோப்பு, அடுத்த boot-ன் போது புதிய மதிப்பை உருவாக்குமாறு systemd-க்கு அறிவுறுத்துகிறது; இதனால்தான் கோப்பை நீக்காமல் அதன் உள்ளடக்கத்தை மட்டும் காலி செய்கிறோம் (truncate). இது நகலெடுக்கப்பட்டிருக்கும்போது இரண்டு விஷயங்கள் பாதிக்கப்படுகின்றன. DHCP மூலம் IP முகவரி பெறும் images-ல், systemd-networkd இயல்பாகவே machine ID-லிருந்துதான் DHCP client identifier-ஐப் பெறுகிறது. இதனால் இரண்டு clone-களும் ஒரே client-ஆக முகவரி கேட்கின்றன, server இரண்டிற்கும் ஒரே முகவரியை வழங்குகிறது. மேலும், journald ஒவ்வொரு பதிவிலும் machine ID-ஐ முத்திரையிடுவதால், ஒரு மையப்படுத்தப்பட்ட log collector இரண்டு server-களையும் ஒரே machine-ஆகக் கருதும். reboot செய்த பிறகு cat /etc/machine-id கட்டளையை இயக்கி, மதிப்பு மாறியுள்ளதா என்பதை உறுதிப்படுத்தவும்.

Hostname-ஐ மாற்றவும்.

sudo hostnamectl set-hostname web-02
grep 127.0.1.1 /etc/hosts

hostnamectl கட்டளையானது /etc/hostname கோப்பை எழுதி, பெயரை உடனடியாக மாற்றும். இது /etc/hosts கோப்பை மாற்றாது, எனவே 127.0.1.1 வரியை அதற்கு ஏற்ப திருத்தவும். இதைச் செய்யாவிட்டால் புதிய பெயர் எங்கும் resolve ஆகாது, ஒவ்வொரு sudo அழைப்பும் தோல்வியுற்ற lookup-க்காகக் காத்திருந்து sudo: unable to resolve host web-02: Name or service not known பிழையை அச்சிடும்.

Image-ல் உள்ள அனைத்து credentials-களையும் மாற்றவும். clone அசல் server-ன் ரகசியங்களைக் கொண்டிருக்கிறது, இப்போது இரண்டு இயந்திரங்களும் அசல் server போலவே செயல்பட முடியும். SSH authorized_keys கோப்புகள், provider மற்றும் DNS API tokens, application .env கோப்புகள், database passwords, TLS private keys, monitoring enrolment tokens மற்றும் restic repository password ஆகியவற்றை ஒவ்வொன்றாக மாற்றவும். இவற்றைத் தேட இந்த கட்டளை உதவும்:

sudo grep -rIlE 'PASSWORD|SECRET|TOKEN|API_KEY' /etc /srv /opt /home 2>/dev/null
sudo find / -name '.env' -not -path '/proc/*' -not -path '/sys/*' 2>/dev/null

clone என்பது traffic-ஐக் கையாளாத ஒரு சோதனை நகல் என்றால், அவற்றை மாற்றுவதற்குப் பதிலாக ரத்து (revoke) செய்யவும். ஒரு live production API token-ஐ வைத்திருக்கும் staging box என்பது, பாதுகாப்பு குறைபாடுள்ள ஒரு production box-க்கு சமம்.

இரண்டு முறை இயங்கும் பணிகளை (jobs) நிறுத்தவும். ஒரே crontab-ஐ இயக்கும் இரண்டு server-களும் ஒரே நிமிடத்தில் ஒரே external system-ஐத் தாக்கும்.

systemctl list-timers --all
sudo crontab -l
sudo ls -l /etc/cron.d /etc/cron.daily

restic விஷயத்தில் கவனமாக இருக்க வேண்டும், ஏனெனில் இது பிழையை மட்டும் காட்டாமல், உங்கள் தரவுத் தக்கவைப்பு (retention) கொள்கையையும் சிதைக்கும். restic ஒவ்வொரு snapshot-க்கும் host name-ஐக் குறிச்சொல்லாக இடுகிறது, மேலும் restic forget --keep-daily 7 ஒவ்வொரு host-க்கும் தனித்தனியாகத் தனது கொள்கையைச் செயல்படுத்துகிறது. ஒரே host name-ஐக் கொண்ட இரண்டு இயந்திரங்கள் ஒரே host-ஆகக் கருதப்படும். இதனால், அசல் server-ன் snapshot-கள் நீக்கப்பட்டு, ஏழு "daily" snapshot-களும் clone-லிருந்து மட்டுமே வரக்கூடும். முதல் backup இயங்குவதற்கு முன்பே hostname-ஐச் சரிசெய்யவும் அல்லது clone-ல் உள்ள timer-ஐ நிறுத்தவும். certbot-ன் நிலை எளிதானது: ஒரே பெயர்களைப் புதுப்பிக்கும் இரண்டு server-கள், certificate authority-ன் duplicate certificate rate limit-ஐத் தாக்கும். ஏற்கனவே அதிகப்படியான certificate-கள் வழங்கப்பட்டதால், தோல்வியுற்ற செயல் பிழையைத் தரும். அசல் domain-ஐ இன்னும் சுட்டிக்காட்டும் clone-ஆல் HTTP challenge-ஐப் பூர்த்தி செய்ய முடியாது, எனவே அங்கு renewal-ஐ முடக்கவும்.

Monitoring agent-ஐக் கவனிக்கவும். பெரும்பாலான agent-கள் hostname அல்லது install செய்யும்போது உருவாக்கப்பட்ட ID கோப்பு மூலம் தங்களை அடையாளம் காணும். இதனால் ஒரே host-ஆகத் தகவல்களை அனுப்பும் இரண்டு agent-கள், metrics-ஐக் குழப்பிவிடும். CPU வரைபடங்கள் எந்த ஒரு இயந்திரமும் உருவாக்காத மதிப்புகளைக் காட்டும், alerts அடிக்கடி தவறாகத் தோன்றும் (flap). clone-ல் உள்ள agent-ஐ நிறுத்தி நீக்கவும், அல்லது உங்கள் vendor-ன் ஆவணங்களின்படி புதிய hostname-ல் மீண்டும் enrol செய்யவும்.

Network configuration-ல் அசல் முகவரி உள்ளதா எனச் சரிபார்க்கவும். image-ல் netplan மூலம் static address அமைக்கப்பட்டிருந்தால், clone மற்றொரு இயந்திரத்திற்குச் சொந்தமான IP-ஐக் கோரும்.

ip -br addr
sudo grep -r addresses /etc/netplan/

இந்த clone ஒரு template-ஆக மாறினால், cloud-init நிலையை நீக்கவும்.

sudo cloud-init clean --logs

இது /var/lib/cloud-ன் கீழ் உள்ள cloud-init நிலையை நீக்கும். இதனால் அடுத்த boot-ன் போது first-boot modules மீண்டும் இயங்கும், இதில் SSH host keys இல்லாதபோது அவற்றை உருவாக்குவதும் அடங்கும். சில பதிப்புகள் machine ID-ஐ reset செய்ய ஒரு flag-ஐயும் வழங்குகின்றன. மற்றவர்களின் ஆவணங்களை நம்புவதை விட, உங்கள் image-ல் எது வேலை செய்கிறது என்பதைப் பார்க்க cloud-init clean --help கட்டளையை இயக்கவும்.

எந்தச் சூழலில் எதைப் பயன்படுத்த வேண்டும்

ஆபத்தான upgrade-ஐத் திரும்பப் பெறுதல் (Rollback): snapshot எடுங்கள். மாற்றத்தைச் செய்வதற்கு சில நிமிடங்களுக்கு முன்பு snapshot எடுங்கள், upgrade-ஐச் செய்யுங்கள், ஏதேனும் தவறு நடந்தால் image-ஐ restore செய்யுங்கள். Restore செய்யும்போது snapshot எடுத்த பிறகு நடந்த அனைத்து மாற்றங்களும் நீக்கப்படும். எனவே, நேரடி traffic-ஐக் கையாளும் server-ல், முதலில் database-ஐ dump செய்துவிட்டு, எந்தத் தரவுகளை இழக்க நேரிடும் என்பதைத் தெளிவாகத் தெரிந்துகொள்ளுங்கள். பத்து நிமிடங்கள் offline-ல் வைக்கக்கூடிய ஒரு server-ல் உள்ள do-release-upgrade-க்கு, snapshot எடுப்பதே முழுமையான தீர்வாகும்.

பெரிய plan-க்கு மாறுதல் (Migration): clone-ஐ deploy செய்யுங்கள். பெரிய plan-ல் snapshot-லிருந்து ஒரு clone-ஐ உருவாக்குங்கள். மேலே உள்ள identity பட்டியலைச் சரிபார்த்து, traffic-ஐ மாற்றுவதற்கு முன்பு புதிய IP-ல் அதைச் சோதியுங்கள். மாற்றத்தை விரைவாகச் செய்ய, ஒரு நாள் முன்பே DNS TTL-ஐக் குறைத்துவிடுங்கள். புதிய server-ல் உண்மையான traffic சீராக இயங்கும் வரை பழைய server-ஐ அப்படியே வைத்திருங்கள். அதிக vCPU-கள் கொண்ட hardware எப்போதும் சிறந்ததாக இருக்காது என்பதால், இரண்டு server-களிலும் ஒரே benchmark முறையைப் பயன்படுத்தி, பெரிய plan உங்கள் பணிச்சுமைக்கு உண்மையில் வேகமானதா என்பதை முதலில் உறுதிப்படுத்துங்கள்.

Template உருவாக்குதல்: சுத்தப்படுத்தப்பட்ட machine-ன் snapshot. ஒரு server-ஐ நிறுவி, பாதுகாப்பு அம்சங்களை (harden) மேம்படுத்துங்கள். image எடுப்பதற்கு முன்பு தனித்துவமான அனைத்துத் தரவுகளையும் நீக்குங்கள். host keys, machine ID, தனிப்பட்ட authorized_keys, credentials மற்றும் cloud-init தரவுகள் நீக்கப்பட வேண்டும். அதன் பிறகு snapshot எடுங்கள். இதிலிருந்து உருவாக்கப்படும் ஒவ்வொரு instance-ம் முதல்முறை boot ஆகும்போது அதன் சொந்த identity-ஐ உருவாக்கிக்கொள்ளும், எனவே மேலே உள்ள சரிபார்ப்புப் பட்டியல் (checklist) தேவையில்லை. இதை புதிய VPS-ல் செய்ய வேண்டிய முதல் பத்து நிமிடப் பணிகள் உடன் இணைத்துக்கொள்ளுங்கள்; அப்போதுதான் நீங்கள் மீண்டும் மீண்டும் செய்ய வேண்டிய வேலைகள் ஏற்கனவே அந்த template-ல் இருக்கும்.

FAQ

VPS snapshot என்பது ஒரு backup-ஆ?

இல்லை, ஏனெனில் இது எந்த server-லிருந்து எடுக்கப்பட்டதோ அதே failure domain-ஐப் பகிர்ந்து கொள்கிறது. Snapshot உங்கள் provider-ன் storage-ல், உங்கள் கணக்கின் கீழ், பொதுவாக அதே region-ல் இருக்கும். கணக்கு முடக்கம், திருடப்பட்ட API key, அல்லது தவறுதலாக instance-ஐ நீக்குதல் போன்றவை server மற்றும் அதன் snapshots ஆகிய இரண்டையும் ஒரே நேரத்தில் அழித்துவிடும். பல provider-களில், ஒரு instance-ஐ நீக்கினால் அதன் snapshots-ம் தானாகவே நீக்கப்படும் வகையில் வடிவமைக்கப்பட்டுள்ளது. Snapshot என்பது மிக விரைவான rollback முறையாகும், எனவே அதைத் தொடர்ந்து எடுங்கள். அதேசமயம், உங்கள் provider-ன் கட்டுப்பாட்டில் இல்லாத வேறொரு உள்கட்டமைப்பில் அதன் மறைகுறியாக்கப்பட்ட (encrypted) நகல் ஒன்றைப் பாதுகாப்பாக வைத்திருங்கள்.

Snapshot எடுப்பதற்கு முன் database-ஐ நிறுத்த வேண்டுமா?

எப்போதும் தேவையில்லை, ஆனால் அதன் விளைவுகளை நீங்கள் ஏற்றுக்கொள்ள வேண்டும். ஒரு provider snapshot என்பது crash-consistent ஆகும்; அதாவது, மின்சாரம் திடீரென துண்டிக்கப்பட்டால் disk எப்படி இருக்குமோ, அதே நிலையில் இந்த image இருக்கும். PostgreSQL மற்றும் InnoDB ஆகியவை தொடங்கும் போது இதிலிருந்து மீண்டு வரும், அப்போது PostgreSQL database system was not properly shut down; automatic recovery in progress-ஐ logs-ல் காட்டும். வெவ்வேறு நேரங்களில் snapshot செய்யப்பட்ட இரண்டு volumes-ல் உங்கள் தரவு பரவியிருக்கும் போதோ, அல்லது ஒரு application fsync இல்லாமல் தரவை எழுதும் போதோ, தரவு மீட்பு (recovery) உறுதி செய்யப்படாது. எனவே, முதலில் ஒரு pg_dumpall அல்லது mysqldump --single-transaction-ஐ disk-ல் எழுதுங்கள்; அப்போதுதான் அந்த image-ல் உங்களுக்குத் தெரிந்த ஒரு சீரான (consistent) கோப்பு இருக்கும்.

இரண்டு cloned servers ஒரே IP address-க்காக ஏன் மோதுகின்றன?

ஏனெனில் அவை /etc/machine-id-ஐப் பகிர்ந்து கொள்கின்றன. DHCP-ஐப் பயன்படுத்தும் images-ல், systemd-networkd அதன் DHCP client identifier-ஐ machine ID-லிருந்து உருவாக்குகிறது. இதனால், இரண்டு clones-ம் ஒரே client-ஆக lease கோருகின்றன, DHCP server இரண்டிற்கும் ஒரே முகவரியை வழங்குகிறது. /etc/machine-id-ஐ பூஜ்ஜிய bytes-க்கு சுருக்கி, /var/lib/dbus/machine-id-ஐ நீக்கி, அதை மீண்டும் /etc/machine-id-க்கு symlink செய்யுங்கள். பிறகு reboot செய்தால், systemd புதிய மதிப்பை உருவாக்கும். மற்றொரு பொதுவான காரணம் /etc/netplan/-ல் எழுதப்பட்டிருக்கும் static address ஆகும்; clone அதை அப்படியே நகலெடுத்திருக்கும். அதை ip -br addr மூலம் சரிபார்க்கவும்.

ஒரு clone-ஐ production-ல் பயன்படுத்துவதற்கு முன் சரிபார்க்க வேகமான வழி எது?

அசல் server-உடன் நான்கு விஷயங்களை ஒப்பிட்டுப் பாருங்கள். இரண்டிலும் ssh-keygen -lf /etc/ssh/ssh_host_ed25519_key.pub-ஐ இயக்கி, fingerprints வெவ்வேறாக இருப்பதை உறுதி செய்யவும். இரண்டிலும் cat /etc/machine-id-ஐ இயக்கி, மதிப்புகள் வெவ்வேறாக இருப்பதை உறுதி செய்யவும். hostnamectl status-ஐ இயக்கி, பெயர் புதியதாக இருப்பதையும், அது சரியாக resolve ஆவதையும் உறுதி செய்யவும்; அப்போதுதான் sudo எச்சரிக்கை தராது. பிறகு systemctl list-timers --all-ஐ இயக்கி, backups, certificate renewal, அல்லது monitoring agent போன்ற பகிரப்பட்ட system-உடன் தொடர்பு கொள்ளும் அனைத்து timers-களையும் நிறுத்துங்கள். எந்த machine அந்தப் பணியைச் செய்ய வேண்டும் என்று முடிவு செய்த பிறகு அவற்றை மீண்டும் இயக்கலாம்.