Managed அல்லது unmanaged VPS: உங்களுக்கு எது தேவை?

Managed மற்றும் unmanaged VPS: சுருக்கமான பதில்

Managed மற்றும் unmanaged VPS இடையே தேர்வு செய்வது product தொடர்பான கேள்வி அல்ல; அது labour தொடர்பான கேள்வி. Unmanaged என்றால் patching, firewall, backups, monitoring, மேலும் அதிகாலை 2am-க்கு server-ஐ reboot செய்வது ஆகியவற்றை நீங்களே நிர்வகிக்க வேண்டும். Managed என்றால், provider அந்தப் பணிகளில் சிலவற்றை உங்கள் சார்பில் செய்கிறார். ஆனால் ஒவ்வொரு host-க்கும் அந்தப் பொறுப்பின் அளவு பெரிதும் மாறுபடும். ஒவ்வொரு plan-மும் உங்கள் பொறுப்பிலிருந்து எந்தப் பணிகளை நீக்குகிறது என்பதைப் பட்டியலிட்டு, அவற்றை உங்கள் சொந்த வேலை நேரத்துடன் ஒப்பிடுவதே பயனுள்ள ஒப்பீடு.

Managed என்ற சொல்லுக்கு நிலையான வரையறை இல்லை. ஒரு host-ல் operating system patch செய்யப்படலாம்; ticket-க்கு ஒரு நபர் பதிலளிக்கலாம். மற்றொரு host-ல் control panel மட்டும் நிறுவப்பட்டிருக்கும்; அதற்கு மேல் உள்ள அனைத்தும் உங்கள் பொறுப்பு. மூன்றாவது host-ல் response time குறிப்பிடப்பட்ட எழுத்துப்பூர்வமான service contract இருக்கலாம். ஒரே சொல்லைப் பயன்படுத்தும் இரண்டு plans, முக்கியமான ஒவ்வொரு அம்சத்திலும் வேறுபடலாம். எனவே price-ஐ பார்ப்பதற்கு முன் scope document-ஐ படிக்கவும். இந்த machine எதற்காக என்பதை நீங்கள் இன்னும் தீர்மானிக்கவில்லை என்றால், VPS மூலம் நீங்கள் உண்மையில் என்ன செய்ய முடியும் என்பதே முதலில் தீர்க்க வேண்டிய சிறந்த கேள்வி.

யாராவது பொறுப்பேற்க வேண்டிய பணிகள்

இயங்கும் ஒவ்வொரு server-க்கும் ஒரே வகையான பணிப் பட்டியல் இருக்கும். Unmanaged plan-ல் அந்தப் பட்டியல் முழுவதும் உங்களுடைய பொறுப்பு. Managed plan-ல், அந்தப் பட்டியலில் உள்ள சில பணிகளை நீக்குவதற்காக நீங்கள் கட்டணம் செலுத்துகிறீர்கள். பட்டியலில் உள்ள ஒவ்வொரு பணிக்கும் அருகில் அதற்குப் பொறுப்பான ஒருவரின் பெயரை எழுதுங்கள்.

• Operating system patching மற்றும் kernel updates தேவைப்படுத்தும் reboots.
• Services-ஐ சேர்க்கும்போதும் அகற்றும்போதும் சரியாக வைத்திருக்கும் firewall rules. VPS-க்கான ufw firewall அடிப்படைகள் தொடக்க ruleset-ஐ விளக்குகின்றன.
• SSH access: key handling, password login-ஐ முடக்குதல், ஒருவர் விலகும்போது அவருடைய key-ஐ revoke செய்தல், மேலும் உங்களை நீங்களே access-இல் இருந்து lock out செய்தால் மீண்டும் நுழையும் வழி.
• Backups, offsite copy, மேலும் நீங்கள் உண்மையில் performed செய்த restore.
• Monitoring: server reachable-ஆக உள்ளதா, disk-ல் போதிய இடம் உள்ளதா, service இன்னும் இயங்குகிறதா, certificate expire ஆகவில்லையா என்பதை அறிதல்.
• Log review மற்றும் அந்த logs-ல் ஏதேனும் தவறாகத் தெரிந்தால் மேற்கொள்ள வேண்டிய நடவடிக்கை.
• Web server, database, reverse proxy மற்றும் நீங்கள் பயன்படுத்தினால் queue ஆகியவற்றுக்கான service configuration.
• Certificate renewal மற்றும் automatic renewal செயல்படுவதை நிறுத்தினால் அதைச் சரிசெய்தல்.
• Capacity: out of memory (OOM) killer உங்களுக்காக அதைக் கண்டறிவதற்கு முன் memory தீர்ந்து கொண்டிருப்பதை கவனித்தல்.
• Incident response: நீங்கள் தேர்வு செய்யாத நேரத்திலும் விழித்திருந்து தொடர்புகொள்ளக்கூடிய நிலையில் இருப்பது.

இவற்றில் பெரும்பாலானவை வழக்கமான பணிகள். அவற்றை script மூலம் ஒப்படைக்கலாம். Incident response-ஐ மட்டும் அவ்வாறு ஒப்படைக்க முடியாது. ஏனெனில் அதற்கு முடிவு எடுக்கக்கூடிய ஒருவர் தேவை. Managed plan உண்மையில் விற்பது இதுதான். அதனால்தான் கீழே உள்ள checklist-ல் patching பற்றி அல்லாமல் support scope பற்றி பெரும்பாலான கேள்விகள் உள்ளன.

Managed சேவையில் பொதுவாக சேராதவை

இங்குதான் வாங்குபவர்கள் பெரும்பாலும் பாதிக்கப்படுகிறார்கள். எனவே இதைத் தெளிவாகப் புரிந்துகொள்ள வேண்டும். Managed contract பொதுவாக operating system மற்றும் provider நிறுவிய software-ஐ உள்ளடக்கும். உங்கள் application-ன் எல்லையில் அது முடிவடைகிறது.

உங்கள் சொந்த code உங்களுடையது. உங்கள் application-லிருந்து வரும் 500 error, server fault அல்ல. Provider web server process இயங்குகிறதா என்பதை உறுதிப்படுத்திவிட்டு, ticket-ஐ உங்களிடம் மீண்டும் ஒப்படைப்பார். இது நியாயமான பொறுப்பு வரம்பு. அதே நேரத்தில், வாங்குபவர்கள் எதிர்பார்ப்பதற்கும் அவர்கள் வாங்கிய சேவைக்கும் இடையிலான மிகப்பெரிய வேறுபாடும் இதுவே.

Application-level பிரச்சினைகள் பொதுவாக service scope-க்கு வெளியே இருக்கும். Slow database query, update செய்த பிறகு செயலிழந்த plugin, தவறாக configured செய்யப்பட்ட cache, drain ஆகாமல் நின்ற mail queue ஆகியவை provider அவற்றின் அடிப்படை software-ஐ நிறுவியிருந்தாலும், இந்த வரம்புக்கு மேலுள்ள பிரச்சினைகளாகும்.

பெரும்பாலான data recovery service scope-க்கு வெளியே இருக்கும். Provider backups, முழு server-ன் provider image-ஐப் பாதுகாக்கும். Host hardware செயலிழக்கும் சூழ்நிலைக்காக அவை உருவாக்கப்பட்டிருக்கும். நீங்கள் ஒரு row-ஐ delete செய்தது, தவறான migration இயக்கியது, அல்லது ஆறு வாரங்களுக்கு முன்பு ஒரு file corrupt ஆனது இன்று தெரியவரும் சூழ்நிலைக்காக அவை அரிதாகவே வடிவமைக்கப்பட்டிருக்கும். Retention window எவ்வளவு, ஒரு குறிப்பிட்ட file-ஐ மட்டும் மீட்டெடுக்க முடியுமா, restore-ஐ யார் இயக்குவார் என்பவற்றைக் கேளுங்கள்.

நீங்கள் நிறுவிய software உங்களுடையது. Docker-ஐ நிறுவினால், provider பொதுவாக host-ஐ நிர்வகிப்பார்; containers-க்குள் உள்ள அனைத்தையும் நீங்கள் நிர்வகிப்பீர்கள்.

கையால் செய்த edits support-ஐ செல்லாததாக்கலாம். சில contracts-ல் customer configuration-ஐ நேரடியாக edit செய்தவுடன், அந்த component service scope-க்கு வெளியேற்றப்படும். ஏதேனும் configuration-ஐ tune செய்யத் திட்டமிட்டிருந்தால், இதைப் பற்றி முன்கூட்டியே கேளுங்கள்.

monthly delta அடிப்படையில் உங்கள் நேரத்திற்கான மதிப்பை கணக்கிடுங்கள்

உங்கள் முன் உள்ள இரண்டு quotes-ஐ எடுத்துக்கொண்டு, monthly difference-ஐ எழுதிக் கொள்ளுங்கள். மேலே உள்ள பட்டியலில் இருந்து அந்தப் பணிகளை provider நீக்குவதற்காக வசூலிக்கும் தொகையே அது. இப்போது இந்த பரிமாற்றத்தில் உங்கள் பக்கத்தின் மதிப்பையும் கணக்கிடுங்கள்.

• உங்கள் நேரத்தின் ஒரு மணி நேர மதிப்பு என்ன? இந்தப் பட்டியலில் உள்ள பணிகள் automated செய்யப்பட்ட பிறகு, மாதத்திற்கு எத்தனை மணி நேரம் பிடிக்கும்?
• இந்த server-ல் இயங்கும் சேவைக்கு ஒரு மணி நேர downtime ஏற்பட்டால் அதன் செலவு என்ன?

automatic updates மற்றும் external monitoring கொண்ட நிலையான Ubuntu box-க்கு வழக்கமான பராமரிப்பு மிகவும் குறைவு. பெரும்பாலான மாதங்களில் எந்த routine attention-மும் தேவையில்லை. ஒரு script அந்தப் பணிகளைச் செய்யத் தொடங்கிய பிறகு, routine work மலிவானதாகிறது. Interrupts-தான் அதிக செலவு ஏற்படுத்தும்; managed plan விற்பது அந்த interrupts-ஐ கையாளும் சேவையே. server ஒரு hobby project-ஐ இயக்கினால், outage-க்கு செலவு எதுவும் இருக்காது; unmanaged தேர்வுதான் தெளிவான முடிவு. server orders-ஐ ஏற்றுக்கொண்டால், support contract உண்மையில் outage-ஐ குறைக்கிறதா என்பதை கவனமாக மதிப்பிடுங்கள். Managed provider கூட உங்கள் ticket-ஐ படித்து, fault-ஐ மீண்டும் உருவாக்கி, பின்னர் நடவடிக்கை எடுக்க வேண்டியிருக்கும்.

server count அதிகரிக்கும்போது delta-வும் பெருகும். Managed fees பொதுவாக ஒவ்வொரு server-க்கும் வசூலிக்கப்படும்; automation-ஐ ஒருமுறை எழுதிக் கொண்டு பல server-களில் copy செய்யலாம். முதல் server-க்காக நீங்கள் எழுதிய script-ன் effective cost-ஐ இரண்டாவது server பாதியாகக் குறைக்கும். ஆகவே per-server fee-க்கு ஒப்புக்கொள்வதற்கு முன் பல Linux server-களை எவ்வாறு நிர்வகிப்பது என்பதைப் படிக்கவும். ஒப்பீட்டின் இரு பக்கங்களுக்குமான அடிப்படை தொகைகளைப் புரிந்துகொள்ள, ஒரு VPS-க்கு மாதத்திற்கு உண்மையில் எவ்வளவு செலவாகும் என்பதைக் காணுங்கள். Workload போதுமான அளவு பெரிதாகி, managed premium-ன் தாக்கம் rounding error அளவுக்கு குறையும் போது, VPS மற்றும் dedicated server இடையிலான தேர்வு முக்கியமாகிறது.

Managed premium-ஐ செலுத்தும் முன் host-இடம் கேட்க வேண்டிய கேள்விகள்

பணம் செலுத்தும் முன் கேளுங்கள். பதில்களை எழுத்துப்பூர்வமாகப் பெறுங்கள். Sales page என்பது scope document அல்ல.

1. ஒவ்வொரு task-ஆக எது scope-க்குள் வருகிறது? Brochure-ஐ அல்ல, முழுப் பட்டியலைக் கேளுங்கள்.
2. நீங்கள் install செய்யும் software-க்கும் support வழங்கப்படுமா, அல்லது அவர்கள் install செய்த software-க்கு மட்டும் வழங்கப்படுமா?
3. அவர்கள் தானாகவே patch செய்கிறார்களா? Kernel updates-க்காக முன்கூட்டியே உங்களிடம் கேட்காமல் reboot செய்கிறார்களா?
4. அவர்கள் apply செய்த patch உங்கள் application-ஐ செயலிழக்கச் செய்தால், அதற்குப் பொறுப்பு யாருடையது?
5. அவர்கள் backups எடுக்கிறார்களா? அவை எங்கே சேமிக்கப்படுகின்றன, எவ்வளவு காலம் வைத்திருக்கப்படுகின்றன, restore-ஐ யார் செய்கிறார்கள்?
6. சமீபத்தில் ஏதேனும் customer server-ஐ restore செய்துள்ளார்களா? அதற்கு எவ்வளவு நேரம் எடுத்தது?
7. Ticket-க்கு பதிலளிக்கும் நேரம் எவ்வளவு? Sunday அன்று 03:00 மணிக்கும் அதே நேரமா?
8. root access உங்களிடம் தொடருமா? அதைப் பயன்படுத்தினால் அவர்கள் வழங்கும் support வரம்பு குறையுமா?
9. Fee ஒவ்வொரு server-க்கும் விதிக்கப்படுகிறதா, அல்லது ஒவ்வொரு account-க்கும் விதிக்கப்படுகிறதா?
10. நீங்கள் service-ஐ விட்டு வெளியேறினால், என்னென்னவற்றை எடுத்துச் செல்ல முடியும்? Proprietary control panel-க்குள் இருக்கும் setup-ஐ export செய்வது கடினமாக இருக்கலாம்.

Question 5 மற்ற கேள்விகளில் பெரும்பாலானவற்றுக்கான முடிவைத் தீர்மானிக்கிறது. அதற்கு துல்லியமாகப் பதிலளிக்கும் host, இதை ஏற்கனவே செய்து பார்த்திருப்பதைச் சுட்டிக்காட்டுகிறது. தெளிவற்ற பதில், restore ஒருபோதும் சோதிக்கப்படவில்லை என்பதைக் குறிக்கிறது. சோதிக்கப்படாத backup என்பது ஒரு copy மட்டுமே. Question 5-க்கு location தொடர்பான ஒரு பகுதியும் உள்ளது. Copies physical-ஆக எங்கே வைக்கப்படுகின்றன என்பது technical கேள்வி மட்டுமல்ல; legal கேள்வியும் ஆகும். hosting country-ஐத் தேர்ந்தெடுக்கும்போது உண்மையில் முக்கியமானவை இதை விரிவாக விளக்குகிறது.

நடுப்பாதை: unmanaged மற்றும் automation இணைந்து

பெரும்பாலான technical readers எந்த ஒரு தீவிரமான அணுகுமுறையையும் விரும்புவதில்லை. Routine பணிகளை machine-க்கு ஒப்படைத்த unmanaged plan அவர்களுக்கு வேண்டும்; machine தீர்மானிக்க முடியாத விஷயங்களில் மட்டும் அவர்கள் கவனம் செலுத்த விரும்புகிறார்கள். இதை முதல் நாளிலேயே அமைக்கவும். புதிய VPS-ல் முதல் பத்து நிமிடங்கள் unmanaged முறையைத் தேர்வு செய்பவர்களுக்கான நடைமுறைத் தொடக்கமாகும். அதே முதல் session-ல் SSH access-ஐ harden செய்தல் செய்ய வேண்டும்.

Automatic security updates

sudo apt update && sudo apt install -y unattended-upgrades
sudo dpkg-reconfigure --priority=low unattended-upgrades
cat /etc/apt/apt.conf.d/20auto-upgrades

இப்போது அந்த file-ல் APT::Periodic::Update-Package-Lists "1"; மற்றும் APT::Periodic::Unattended-Upgrade "1"; இருக்க வேண்டும். File இல்லாவிட்டாலும், அல்லது ஏதேனும் ஒரு line-ல் 0 இருந்தாலும், எதுவும் இயங்காது; உங்களுக்குத் தகவலும் கிடைக்காது.

System-ஐ மாற்றாமல் இதைச் சோதிக்கவும். package என்பது unattended-upgrades, ஆனால் command singular வடிவில் இருப்பதை கவனிக்கவும்:

sudo unattended-upgrade --dry-run --debug

Output பரிசீலித்த ஒவ்வொரு package-ஐயும் பட்டியலிடும். Pending updates இல்லாவிட்டால், இறுதியில் No packages found that can be upgraded unattended போன்ற line வரும். உண்மையில் இயங்கிய runs /var/log/unattended-upgrades/unattended-upgrades.log-ல் எழுதப்படும். எனவே ஊகிக்காமல் அந்த இடத்தைச் சரிபார்க்கவும்.

Kernel update செய்தாலும் machine reboot ஆகும் வரை மாற்றம் ஏற்படாது. காரணம், இயங்கும் kernel boot நேரத்தில் load செய்யப்பட்ட kernel ஆகும். Reboot தேவைப்படும் போது /var/run/reboot-required file தோன்றும். அந்த file-ஐ monitor செய்யலாம்; அல்லது machine-ஐ /etc/apt/apt.conf.d/50unattended-upgrades முறையில் இதை நிர்வகிக்க விடலாம்:

Unattended-Upgrade::Automatic-Reboot "true";
Unattended-Upgrade::Automatic-Reboot-WithUsers "false";
Unattended-Upgrade::Automatic-Reboot-Time "02:00";

யாராவது login செய்திருக்கும்போது Automatic-Reboot-WithUsers "false" reboot-ஐத் தடுக்கிறது. நீங்கள் interactive முறையில் பயன்படுத்தும் machine-க்கு இது பாதுகாப்பானது; யாரும் login செய்யாத machine-க்கு இது பயனற்றது. Ubuntu-வில் unattended upgrades-ஐ முழுமையாக அமைத்தல் blocklist syntax மற்றும் email options குறித்து விளக்குகிறது.

வேறு இடத்தில் இயங்கும் Monitoring

Server-ல் இயங்கும் monitor, server down ஆகியிருப்பதைத் தெரிவிக்க முடியாது. Monitor-மும் அதே server-ல் இருப்பதால் அது கூட down ஆகிவிடும். Check-ஐ இரண்டாவது host-ல் அல்லது வெளிப்புற service-ல் அமைக்கவும். Status monitoring-க்கான Uptime Kuma வழக்கமாகப் பயன்படுத்தப்படும் self-hosted தீர்வாகும். அது monitor செய்யும் machine-இலிருந்து வேறு machine-ல் இருக்க வேண்டும்.

குறைந்தபட்சம் நான்கு விஷயங்களை monitor செய்யவும்: reachability, disk usage, application அதன் உண்மையான port-ல் பதிலளிக்கிறதா என்பது, மற்றும் certificate expiry. Disk usage தான் பலரையும் சிக்கலில் ஆழ்த்தும். தினமும் சிறிதளவு பெரிதாகும் log file அல்லது database, வேறு எந்த அறிகுறியும் முன்கூட்டியே காட்டாத நேரத்தில் box-ஐ down செய்யலாம். முதலில் காணப்படும் அறிகுறி, எழுத முடியாமல் service exit செய்வதாக இருக்கலாம்.

df -h
sudo du -xh --max-depth=1 /var | sort -h
journalctl --disk-usage

மேலும் heartbeat-ஐச் சேர்க்கவும். ஒவ்வொரு successful backup அல்லது health check-க்குப் பிறகும் server-ல் உள்ள timer ஒன்று URL-ஐ call செய்யும். அந்த call வருவது நிறுத்தப்பட்டால் monitor alert அனுப்பும். Network path-ல்தான் பிரச்சினை ஏற்பட்டிருந்தாலும், pull-only check இதை கண்டறிய முடியாத நிலையில், silent server தானாகவே alert உருவாக்கும்.

குறைந்தது ஒருமுறை restore செய்த Backups

sudo apt install -y restic
sudo sh -c 'umask 077; printf %s "a-long-random-passphrase" > /root/.restic-pass'
export RESTIC_REPOSITORY=sftp:backup@backup.example.com:/srv/restic/web01
export RESTIC_PASSWORD_FILE=/root/.restic-pass
sudo -E restic init

restic init ஒருமுறை created restic repository <id> at sftp:...-ஐ print செய்யும். ஏற்கனவே உள்ள repository-க்கு எதிராக இதை இயக்கினால் overwrite செய்வதற்குப் பதிலாக fail ஆகும். நீங்கள் விரும்பும் behaviour இதுதான். அந்த passphrase-ன் ஒரு copy-ஐ server-க்கு வெளியே பாதுகாப்பாக வைத்திருக்கவும். அது இல்லாமல் repository-ஐ வாசிக்க முடியாது; recovery path எதுவும் இல்லை.

sudo -E restic backup /etc /home /srv
sudo -E restic snapshots
sudo -E restic forget --keep-daily 7 --keep-weekly 4 --keep-monthly 6 --prune
sudo -E restic check

restic snapshots இன்று செய்த run-ஐ இன்றைய date-உடன் பட்டியலிட வேண்டும். restic check repository structure-ஐ verify செய்து no errors were found-ஐ print செய்யும். இப்போது பெரும்பாலானவர்கள் தவிர்க்கும் பகுதியைச் செய்யவும்:

sudo -E restic restore latest --target /tmp/restore-check
ls /tmp/restore-check/etc

நீங்கள் எதிர்பார்த்த file அங்கே இருக்கும் அல்லது இருக்காது. இதை இப்போது கண்டறிய பத்து நிமிடங்கள் போதும். பின்னர் run-ஐ timer-ல் அமைக்கவும். அது உங்கள் நினைவில் இருப்பதைச் சார்ந்திருக்கக் கூடாது. /etc/systemd/system/restic-backup.service-ஐ எழுதவும்:

[Unit]
Description=restic backup
After=network-online.target
Wants=network-online.target

[Service]
Type=oneshot
Environment=RESTIC_REPOSITORY=sftp:backup@backup.example.com:/srv/restic/web01
Environment=RESTIC_PASSWORD_FILE=/root/.restic-pass
ExecStart=/usr/bin/restic backup /etc /home /srv
ExecStart=/usr/bin/restic forget --keep-daily 7 --keep-weekly 4 --keep-monthly 6 --prune

மேலும் /etc/systemd/system/restic-backup.timer:

[Unit]
Description=Run restic backup daily

[Timer]
OnCalendar=daily
RandomizedDelaySec=30m
Persistent=true

[Install]
WantedBy=timers.target

sudo systemctl daemon-reload
sudo systemctl enable --now restic-backup.timer
sudo systemctl start restic-backup.service
journalctl -u restic-backup.service -n 30 --no-pager
systemctl list-timers restic-backup.timer

list-timers அடுத்த run மற்றும் மீதமுள்ள நேரத்தைக் காட்டும். Empty result கிடைத்தால், timer-க்குப் பதிலாக service-ஐ enable செய்துள்ளீர்கள் என்று பொருள். இங்கு இது மிகவும் பொதுவான தவறு. Persistent=true அடுத்த boot-க்குப் பிறகு missed job-ஐ இயக்கும். எனவே machine இரவு முழுவதும் off நிலையில் இருந்தாலும் அதன் backup பின்னர் பெறப்படும். VPS-ல் Restic backups repository layout மற்றும் retention குறித்து விரிவாக விளக்குகிறது. systemd services மற்றும் timers unit files-ஐ line by line விளக்குகிறது.

Automation வழங்காதவை

Automation judgement-ஐ வழங்காது. 02:00 மணிக்கு automatic reboot நடக்கும். உங்கள் application சரியாகத் திரும்பி வருகிறதா இல்லையா என்பதை அது பார்க்காது. எனவே ஒவ்வொரு service-மும் தானாகத் தொடங்குகிறதா என்பதை உறுதிப்படுத்தவும். பின்னர் நீங்கள் விழித்திருக்கும் நேரத்தில் திட்டமிட்டு reboot செய்யவும்:

systemctl is-enabled nginx docker
sudo reboot

Unattended upgrade, உங்கள் application-ஐ பாதிக்கும் package-ஐ install செய்யக்கூடும். இது நடந்ததை pipeline-ல் உள்ள எந்தப் பகுதியும் அறியாது. Monitor தான் இதைக் கண்டறியும். அதனால் updates automatic ஆனவுடன் monitor கட்டாயம். Routine பணிகளை machine கையாளும். Incident-க்கான பொறுப்பு இன்னும் உங்களுடையதே.

Managed சேவைக்கு பணம் செலுத்துவது பயனுள்ள சூழல்கள்

Managed சேவையின் தரப்பையும் நியாயமாக மதிப்பிட வேண்டும். கீழே உள்ள 4 சூழல்களில் அது சரியான தேர்வாக இருக்கலாம்.

• குழுவில் யாரும் Linux நிர்வகிப்பதில்லை; வேறு ஒருவரை பணியமர்த்தும் திட்டமும் இல்லை.
• Patching-க்கு பொறுப்பான தரப்பை ஒரு compliance requirement குறிப்பிடுகிறது; அந்தப் பொறுப்பு உங்களுடையதாக இருக்க முடியாது.
• நீங்கள் பயன்படுத்தும் stack-ல் host provider சிறப்பு பெற்றுள்ளது; எனவே உங்கள் failure போன்ற பிரச்சினைகளை அவர்களின் support குழு ஏற்கனவே சந்தித்திருக்கலாம்.
• இந்தப் பணியை இல்லையெனில் செய்ய வேண்டியவர் உங்கள் நிறுவனத்தின் அதிகச் செலவான employee; அவரின் ஒரு மணி நேரச் செலவு premium-ன் ஒரு மாதக் கட்டணத்தைவிட அதிகம்.

Managed சேவை தானாகவே அதிக security வழங்காது. கவனக்குறைவான owner-ஐவிட Managed plans வேகமாக patch செய்வது உண்மையான நன்மை. ஆனால் அவை பெரும்பாலும் control panel-ஐயும் நிறுவுகின்றன. அது login page மற்றும் தனக்கென vulnerability history கொண்ட, network-க்கு வெளிப்படையாக இருக்கும் பெரிய application ஆகும். இது ஏற்றுக்கொள்ளக்கூடிய trade ஆக இருக்கலாம்; இருந்தாலும் அது ஒரு trade-தான்.

ஒவ்வொரு முறையும் முடிவு அதே பட்டியலை அடிப்படையாகக் கொண்டது. அந்த 10 tasks-ஐ எழுதுங்கள். ஒவ்வொரு quote-ன் கீழும் ஒவ்வொரு task-ஐ யார் பொறுப்பேற்கிறார்கள் என்று குறிக்கவும். பின்னர் அந்த வேறுபாட்டை, உங்கள் கவனத்தின் ஒரு மணி நேரத்திற்கான மதிப்புடன் ஒப்பிடவும். இதைச் செய்யும் பெரும்பாலான technical readers, unmanaged தேர்வை எடுத்து routine பணிகளை timer மூலம் இயக்குகின்றனர். இது மலிவான பதில் அல்ல; நியாயப்படுத்தக்கூடிய பதிலாகும்.

FAQ

managed மற்றும் unmanaged VPS-க்கு இடையிலான வேறுபாடு என்ன?

unmanaged VPS உங்களுக்கு machine-ஐ மட்டும் வழங்கும். Patching, firewall, backups, monitoring, மற்றும் kernel update பிறகு reboot செய்வது ஆகிய அனைத்தும் உங்கள் பொறுப்பு. managed VPS இந்தப் பணிகளில் ஒரு பகுதியை provider-க்கு மாற்றுகிறது. பொதுவாக operating system layer மற்றும் provider உங்களுக்காக நிறுவிய software இதில் அடங்கும். ஆனால் சரியான பொறுப்பு வரம்பு ஒவ்வொரு provider-க்கும் மாறுபடும். எனவே இரண்டு விலைகளை ஒப்பிடுவதற்கு முன், task-by-task scope-ஐ எழுத்துப்பூர்வமாகக் கேளுங்கள்.

managed VPS பயன்படுத்தினால் எனது சொந்த backups தேவையில்லையா?

தேவையில்லை. Provider backups பொதுவாக முழு server-ன் provider image-ஐப் பாதுகாக்கும். Host தோல்வியடையும் சூழலுக்காக அவை இருக்கும். நீங்கள் ஒரு file-ஐ நீக்கிவிட்டால், தவறான migration இயக்கினால், அல்லது சில வாரங்களுக்கு முன் data corruption ஏற்பட்டதை இன்று கண்டறிந்தால், அந்த backups பெரும்பாலும் உதவாது. Snapshots எவ்வளவு காலம் வைக்கப்படுகின்றன, தனிப்பட்ட file-ஐ restore செய்ய முடியுமா, restore-ஐ யார் செய்கிறார்கள் என்பதைக் கேளுங்கள். பின்னர் restic போன்ற tool மூலம் உங்கள் சொந்த offsite copy-ஐ வைத்திருங்கள். அது செயல்படுகிறது என்பதை உறுதிப்படுத்த restic restore latest --target /tmp/restore-check மூலம் அதைச் சோதிக்கவும்.

unmanaged VPS-ஐ விட managed VPS அதிக secure-ஆக இருக்குமா?

அதுவே காரணமாக இல்லை. ஒருபோதும் login செய்யாத owner-ஐ விட managed plan வேகமாக patches-ஐ நிறுவும். இதனால் ஆபத்து உண்மையில் குறையும். பல managed plans control panel-ஐயும் நிறுவும். ஒரு panel என்பது network-facing application ஆகும். அதற்கு தனிப்பட்ட login page மற்றும் தனிப்பட்ட vulnerabilities history இருக்கும். Automatic security updates, மூடிய firewall, key-only SSH, மற்றும் தேவையற்ற listening services இல்லாத unmanaged server, panel இயங்கும் managed server-ஐ விட சிறிய target ஆக இருக்கும்.

முதலில் unmanaged-ஆகத் தொடங்கி பின்னர் managed-ஆக மாற்ற முடியுமா?

பொதுவாக முடியும். ஆனால் இது அரிதாகவே ஒரு checkbox மூலம் செய்யப்படும். Provider-கள் server-ஐ தங்கள் பொறுப்பில் எடுப்பதற்கு முன் பொதுவாக audit அல்லது rebuild செய்வார்கள். தாங்கள் பார்க்க முடியாத configuration-க்கு அவர்கள் support வழங்கமாட்டார்கள். Onboarding-ல் என்னென்ன அடங்கும், reinstall தேவைப்படுமா, பின்னர் நீங்கள் தனியாகச் செய்த எந்த configuration-கள் scope-க்கு வெளியே இருக்கும் என்பதைக் கேளுங்கள்.

managed VPS-ல் root access என்னிடம் தொடருமா?

பெரும்பாலான managed VPS plans-ல் root access தொடரும். ஆனால் root access மற்றும் support scope ஒன்றுடன் ஒன்று தொடர்புடையவை. நீங்கள் கைமுறையாகத் திருத்திய component-க்கு சில providers support-ஐக் குறைக்கலாம் அல்லது முழுமையாகத் தவிர்க்கலாம். Ticket ஒரு குறிப்பிட்ட அளவைத் தாண்டினால், சில providers தங்கள் சொந்த template-ல் இருந்து server-ஐ rebuild செய்வார்கள். எதையும் tune செய்வதற்கு முன் அந்த விதியை எழுத்துப்பூர்வமாகப் பெறுங்கள். உங்கள் configuration files-ஐ version control-ல் வைத்திருங்கள். அப்போது rebuild-க்கு ஒரு மணி நேரம் போதுமானதாக இருக்கும்; முழு weekend தேவைப்படாது.