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

பெரும்பாலான தொழில்நுட்ப வாசகர்கள் இரண்டு தீவிர நிலைகளையும் விரும்புவதில்லை. அவர்கள் ஒரு unmanaged திட்டத்தை விரும்புகிறார்கள், ஆனால் வழக்கமான பணிகளை இயந்திரத்திடம் ஒப்படைத்துவிட்டு, இயந்திரத்தால் தீர்மானிக்க முடியாத விஷயங்களுக்கு மட்டும் தங்கள் கவனத்தைச் செலுத்த விரும்புகிறார்கள். இதை முதல் நாளிலேயே அமைத்துவிடுங்கள். புதிய VPS-ல் முதல் பத்து நிமிடங்கள் என்பது unmanaged-ஐத் தேர்ந்தெடுக்கும் எவருக்கும் நடைமுறைத் தொடக்கப் புள்ளியாகும், மேலும் SSH access-ஐ பலப்படுத்துதல் அதே முதல் அமர்வில் செய்யப்பட வேண்டிய ஒன்றாகும்.

தானியங்கி பாதுகாப்பு மேம்படுத்தல்கள் (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

அந்தக் கோப்பில் இப்போது APT::Periodic::Update-Package-Lists "1"; மற்றும் APT::Periodic::Unattended-Upgrade "1"; இருக்க வேண்டும். கோப்பு விடுபட்டால் எதுவும் இயங்காது, அது குறித்து உங்களுக்குத் தெரிவிக்கப்படவும் மாட்டாது. இந்த இரண்டு வரிகளும் வெவ்வேறு பணிகளைச் செய்கின்றன. இரண்டாவது வரியில் 0 இருந்தால், எந்த மேம்படுத்தல்களும் நிறுவப்படாது. முதல் வரியில் 0 இருந்தால், அது package பட்டியல்கள் புதுப்பிக்கப்படுவதை மட்டுமே தடுக்கும்; இதனால் பழைய பட்டியல்களை வைத்தே மேம்படுத்தல்கள் இயங்கும், மேலும் புதிய பாதுகாப்புத் திருத்தங்களைக் கண்டறிய முடியாமல் அமைதியாக நின்றுவிடும். இந்த இரண்டு தவறுகளுமே எந்தப் பிழையையும் (error) காட்டாது.

அமைப்பை மாற்றாமல் இதைச் சோதிக்கவும். package என்பது unattended-upgrades, ஆனால் கட்டளை ஒருமை (singular) என்பதை கவனிக்கவும்:

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

வெளியீடு அது பரிசீலித்த ஒவ்வொரு package-ஐயும் பட்டியலிடும், மேலும் எதுவும் நிலுவையில் இல்லை என்றால் No packages found that can be upgraded unattended and no pending auto-removals என்ற வரியுடன் முடிவடையும். உண்மையான செயல்பாடுகள் /var/log/unattended-upgrades/unattended-upgrades.log-ல் எழுதப்படும், எனவே ஊகிப்பதற்குப் பதிலாக அங்கு சரிபார்க்கவும்.

இயங்கும் kernel என்பது boot நேரத்தில் ஏற்றப்பட்டது என்பதால், இயந்திரம் reboot ஆகும் வரை kernel மேம்படுத்தல் எதையும் மாற்றாது. reboot நிலுவையில் இருக்கும்போது /var/run/reboot-required என்ற கோப்பு தோன்றும். அந்தக் கோப்பைக் கவனியுங்கள் அல்லது /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";

யாராவது லாக்-இன் செய்திருக்கும்போது Automatic-Reboot-WithUsers "false" reboot-ஐத் தடுத்து நிறுத்தும். நீங்கள் நேரடியாகப் பயன்படுத்தும் பெட்டியில் இது பாதுகாப்பானது, ஆனால் யாரும் லாக்-இன் செய்யாத பெட்டியில் இது பயனற்றது. Ubuntu-வில் முழுமையான unattended upgrades அமைப்பு என்பது blocklist தொடரியல் மற்றும் மின்னஞ்சல் விருப்பங்களை விளக்குகிறது.

வேறொரு இடத்தில் இயங்கும் கண்காணிப்பு (Monitoring)

server-ல் இயங்கும் ஒரு monitor-ஆல் server செயலிழந்துவிட்டது என்று சொல்ல முடியாது, ஏனெனில் அதுவும் செயலிழந்திருக்கும். அந்தச் சோதனையை இரண்டாவது host-ல் அல்லது வெளிப்புறச் சேவையில் வைக்கவும். நிலை கண்காணிப்பிற்கான Uptime Kuma என்பது பொதுவாகப் பயன்படுத்தப்படும் self-hosted தீர்வாகும், இது கண்காணிக்கப்படும் இயந்திரத்திலிருந்து வேறொரு இயந்திரத்தில் இருக்க வேண்டும்.

குறைந்தது நான்கு விஷயங்களைக் கவனியுங்கள்: அணுகக்கூடிய தன்மை (reachability), disk பயன்பாடு, application அதன் உண்மையான port-ல் பதிலளிக்கிறதா என்பது, மற்றும் certificate காலாவதி. disk பயன்பாடுதான் பலரைச் சிக்கலில் தள்ளும். ஒவ்வொரு நாளும் சிறிது சிறிதாக வளரும் log கோப்பு அல்லது database, எதிர்பாராத நேரத்தில் பெட்டியைச் செயலிழக்கச் செய்யும். அதன் முதல் அறிகுறி, ஒரு service-ஆல் எழுத முடியாமல் வெளியேறுவதாகும்.

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

இதனுடன் heartbeat-ஐயும் சேர்க்கவும். ஒவ்வொரு வெற்றிகரமான backup அல்லது health check-க்குப் பிறகும் server-ல் உள்ள timer ஒரு URL-ஐ அழைக்கும். அந்த அழைப்பு வருவது நின்றால் monitor எச்சரிக்கை செய்யும். network பாதை துண்டிக்கப்பட்டால், pull-only சோதனையால் இதைக் கண்டறிய முடியாது; ஆனால் silent server தானாகவே எச்சரிக்கையை உருவாக்கும்.

குறைந்தபட்சம் ஒருமுறை மீட்டமைக்கப்பட்ட 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:...-ஐ ஒருமுறை அச்சிடும். ஏற்கனவே இருக்கும் repository-ல் இதை இயக்கினால், அது மேலெழுதாமல் (overwrite) தோல்வியடையும்; இதுவே நீங்கள் விரும்பும் நடத்தை. அந்த passphrase-ன் நகலை server-க்கு வெளியே எங்காவது வைத்திருங்கள்: அது இல்லாமல் repository-ஐப் படிக்க முடியாது, மேலும் மீட்பதற்கான வழியும் இல்லை.

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 நீங்கள் செய்த இன்றைய தேதியிட்ட செயல்பாட்டைப் பட்டியலிட வேண்டும். restic check repository கட்டமைப்பைச் சரிபார்த்து no errors were found-ஐ அச்சிடும். இப்போது பெரும்பாலானோர் தவிர்க்கும் அந்தப் பகுதியைச் செய்யுங்கள்:

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

நீங்கள் எதிர்பார்த்த கோப்பு அங்கு இருக்கிறதா இல்லையா என்பது இப்போது தெரிந்துவிடும், இதைக் கண்டறிய பத்து நிமிடங்கள் மட்டுமே ஆகும். பிறகு, உங்களைச் சார்ந்து இருக்காதபடி அந்தச் செயல்பாட்டை ஒரு 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 அடுத்த செயல்பாட்டையும் மீதமுள்ள நேரத்தையும் காட்டும். முடிவு காலியாக இருந்தால், நீங்கள் timer-க்கு பதிலாக service-ஐ இயக்கியுள்ளீர்கள் என்று அர்த்தம்; இதுவே இங்கு நடக்கும் பொதுவான தவறு. Persistent=true அடுத்த boot-க்குப் பிறகு விடுபட்ட வேலையை இயக்கும், எனவே இரவு முழுவதும் அணைக்கப்பட்டிருந்த இயந்திரமும் அதன் backup-ஐப் பெற்றுவிடும். VPS-ல் Restic backups என்பது repository அமைப்பு மற்றும் தக்கவைப்பு (retention) பற்றி ஆழமாக விளக்குகிறது, மேலும் systemd services மற்றும் timers unit கோப்புகளை வரி வரியாக விளக்குகிறது.

தானியங்கி முறை உங்களுக்கு எதை வழங்காது

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

systemctl is-enabled nginx docker
sudo reboot

ஒரு unattended upgrade உங்கள் application-ஐப் பாதிக்கும் ஒரு package-ஐ நிறுவலாம், அது நடந்ததை pipeline-ல் உள்ள எதுவும் அறியாது. உங்கள் monitor தான் அதைக் கண்டறியும், அதனால்தான் மேம்படுத்தல்கள் தானியங்கி முறையில் இருக்கும்போது monitor என்பது விருப்பத்தேர்வு அல்ல. இயந்திரம் வழக்கமான பணிகளைக் கவனிக்கும். ஆனால், சிக்கல்களைக் கையாள்வது உங்கள் பொறுப்பு.

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 தேவைப்படாது.