Managed vs unmanaged VPS: మీకు ఏది అవసరం?

Managed vs unmanaged VPS: సంక్షిప్త సమాధానం

Managed మరియు unmanaged VPS మధ్య ఎంచుకోవడం ఉత్పత్తికి సంబంధించిన ప్రశ్న కాదు; శ్రమకు సంబంధించిన ప్రశ్న. Unmanaged అంటే patching, firewall, backups, monitoring, అలాగే రాత్రి 2amకు reboot చేయడం మీ బాధ్యత. Managed అంటే provider ఆ పనిలో కొంత భాగాన్ని మీ తరఫున చేస్తాడు. అయితే ఆ భాగం hosts మధ్య చాలా మారవచ్చు. ప్రతి plan మీ బాధ్యతల నుంచి ఏ పనులను తొలగిస్తుంది, వాటి ధర మీ స్వంత పని గంటలతో పోలిస్తే ఎలా ఉంది అనేదే ఉపయోగకరమైన పోలిక.

Managed అనే పదానికి ప్రామాణిక నిర్వచనం లేదు. ఒక hostలో operating system patch చేయబడుతుంది మరియు ఒక వ్యక్తి ticketకు సమాధానం ఇస్తాడు. మరొక hostలో control panel మాత్రమే install చేసి ఉంటుంది; దాని పైన ఉన్న ప్రతిదీ మీ బాధ్యత. ఇంకొక hostలో response timeతో కూడిన వ్రాతపూర్వక service contract ఉంటుంది. ఒకే పదాన్ని ఉపయోగించే రెండు plans, ముఖ్యమైన ప్రతి అంశంలోనూ భిన్నంగా ఉండవచ్చు. అందువల్ల ధరను చూసే ముందు scope document చదవండి. ఈ machine అసలు దేనికి ఉపయోగపడుతుందో ఇంకా నిర్ణయించకపోతే, VPSతో మీరు వాస్తవంగా ఏమి చేయగలరు అనే ప్రశ్నకు ముందుగా సమాధానం కనుగొనడం మంచిది.

ఎవరెవరు ఏ పనికి బాధ్యత వహించాలి

ప్రతి నడుస్తున్న సర్వర్‌లో ఒకే రకమైన పనుల జాబితా ఉంటుంది. Unmanaged plan‌లో ఆ జాబితా మీ బాధ్యత. Managed plan‌లో ఆ జాబితాలోని కొన్ని పనులను మీ నుంచి తొలగించడానికి మీరు చెల్లిస్తారు. జాబితాలోని ప్రతి పని పక్కన ఒకరి పేరు రాయండి.

• Operating system patching, అలాగే kernel updates అవసరం చేసే reboots.
• Firewall rules. మీరు services‌ను add లేదా remove చేసినప్పుడు అవి సరైనవిగా ఉండేలా నిర్వహించాలి. VPS కోసం ufw firewall ప్రాథమికాలులో ప్రారంభ ruleset వివరించబడింది.
• SSH access: key నిర్వహణ, password login‌ను నిలిపివేయడం, ఎవరైనా సంస్థను విడిచిపెట్టినప్పుడు వారి key‌ను revoke చేయడం, అలాగే మీరు మీరే access‌ను కోల్పోయినప్పుడు తిరిగి ప్రవేశించడానికి ఒక మార్గం.
• Backups, offsite copy, అలాగే మీరు వాస్తవంగా అమలు చేసి చూసిన restore.
• Monitoring. అంటే server చేరుకోగలిగే స్థితిలో ఉందా, disk‌లో తగినంత స్థలం ఉందా, service ఇంకా నడుస్తుందా, certificate గడువు ముగియలేదా అన్నది తెలుసుకోవడం.
• Log review, అలాగే logs‌లో ఏదైనా తప్పుగా కనిపించినప్పుడు తీసుకునే చర్య.
• Web server, database, reverse proxy, అలాగే మీరు ఉపయోగిస్తే queue కోసం service configuration.
• Certificate renewal, అలాగే automatic renewal పనిచేయడం ఆగిపోయినప్పుడు దాన్ని సరిచేయడం.
• Capacity. అంటే out of memory (OOM) killer మీకు బదులుగా గుర్తించేలోపు memory పూర్తిగా వినియోగించబడిందని గుర్తించడం.
• Incident response. అంటే మీరు ఎంచుకోని సమయానికి మేల్కొని, అందుబాటులో ఉండటం.

వీటిలో చాలా పనులు routine పనులు. వాటిని script‌కు అప్పగించవచ్చు. Incident response‌ను మాత్రం script‌కు అప్పగించలేరు. ఎందుకంటే దానికి నిర్ణయం తీసుకోగల వ్యక్తి అవసరం. 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 సమస్యలు సాధారణంగా scope లో ఉండవు. Slow database query, update తర్వాత పనిచేయకుండా పోయిన plugin, తప్పుగా configure చేసిన cache, ఖాళీ కాకుండా నిలిచిపోయిన mail queue — provider వాటి కింద ఉన్న software ను ఇన్‌స్టాల్ చేసినా, ఇవన్నీ ఆ బాధ్యతా సరిహద్దుకు పైభాగంలో ఉంటాయి.

చాలా data recovery పనులు scope లో ఉండవు. Provider backups మొత్తం server కు సంబంధించిన provider image ను రక్షిస్తాయి. Host hardware విఫలమైనప్పుడు ఉపయోగించడానికి అవి ఉంటాయి. మీరు ఒక row ను తొలగించినప్పుడు, తప్పు migration నడిపినప్పుడు లేదా ఆరు వారాల క్రితం file పాడై, ఈరోజు అది గుర్తించినప్పుడు ఉపయోగపడేలా అవి సాధారణంగా రూపొందించబడవు. Retention window ఎంత ఉందో, ఒకే file ను తిరిగి పొందగలరా, restore ను ఎవరు నిర్వహిస్తారో అడగండి.

మీరు ఇన్‌స్టాల్ చేసిన software మీదే. Docker ను ఇన్‌స్టాల్ చేస్తే provider సాధారణంగా host ను నిర్వహిస్తుంది; containers లోపల ఉన్న ప్రతిదానికి మీరు బాధ్యత వహిస్తారు.

చేతితో చేసిన మార్పులు support ను రద్దు చేయవచ్చు. Customer నేరుగా configuration ను మార్చిన తర్వాత కొన్ని contracts ఒక component ను scope నుంచి తొలగిస్తాయి. మీరు ఏదైనా tune చేయాలని భావిస్తే, దీనిపై ముందుగానే అడగండి.

మీ సమయానికి నెలవారీ తేడా ఆధారంగా విలువ కేటాయించండి

మీ ముందున్న రెండు కోట్‌లను తీసుకుని, వాటి మధ్య నెలవారీ తేడాను రాసుకోండి. పై జాబితా నుంచి అంశాలను తొలగించడానికి provider వసూలు చేసే మొత్తం అదే. ఇప్పుడు ఈ మార్పిడిలో మీ వైపు ఉన్న విలువను కూడా లెక్కించండి.

• మీ సమయం ఒక గంటకు ఎంత విలువైనది? ఆ జాబితాను automate చేసిన తర్వాత నెలకు ఎన్ని గంటలు పడతాయి?
• ఈ server‌పై నడుస్తున్న వ్యవస్థకు downtime లో ఒక గంటకు ఎంత ఖర్చవుతుంది?

Automatic updates మరియు external monitoring కలిగిన స్థిరంగా నడిచే Ubuntu box‌కు సాధారణ నిర్వహణలో చాలా తక్కువ శ్రద్ధ అవసరం. చాలా నెలల్లో ఎలాంటి శ్రద్ధ అవసరం ఉండదు. ఒక script ఆ పనిని నిర్వహించిన తర్వాత routine work ఖర్చు తక్కువగా ఉంటుంది. Interrupts ఖరీదైనవి. Managed plan విక్రయించేది కూడా ఈ interrupts‌ను నిర్వహించే సేవే. Server hobby project‌ను నడిపితే outage వల్ల ఎలాంటి ఖర్చు ఉండదు. అందువల్ల unmanaged ఎంపిక స్పష్టంగా సరైనదే. Server ద్వారా orders స్వీకరిస్తే, support contract నిజంగా outage‌ను తగ్గిస్తుందా అనే విషయాన్ని జాగ్రత్తగా పరిశీలించండి. Managed provider కూడా ముందుగా మీ ticket‌ను చదవాలి, fault‌ను పునరుత్పత్తి చేయాలి, తరువాత చర్య తీసుకోవాలి.

Serverల సంఖ్య పెరిగే కొద్దీ ఈ తేడా కూడా పెరుగుతుంది. Managed fees సాధారణంగా ప్రతి server‌కు వసూలు చేస్తారు. Automation‌ను మాత్రం ఒకసారి రాసి, ఇతర serverలకు copy చేయవచ్చు. మొదటి server కోసం రాసిన script‌ను రెండో server‌కు ఉపయోగించినప్పుడు దాని ప్రభావవంతమైన ఖర్చు సగానికి తగ్గుతుంది. అందువల్ల ప్రతి server‌కు fee చెల్లించాలా అని నిర్ణయించే ముందు అనేక Linux serverలను ఎలా నిర్వహించాలి చూడండి. పోలికలో ఇరువైపులా ఉపయోగించే ప్రాథమిక మొత్తాల కోసం VPSకు నెలకు వాస్తవంగా ఎంత ఖర్చవుతుంది కనీస స్థాయి ఖర్చును చూపుతుంది. Workload తగినంత పెద్దదై managed premium మొత్తం ఖర్చులో గణనీయంగా కనిపించనప్పుడు VPS మరియు dedicated server మధ్య ఎంపికలో తేడాలు ముఖ్యమవుతుంది.

చెల్లింపు చేయడానికి ముందు managed premium అందించే host ను అడగాల్సిన ప్రశ్నలు

చెల్లింపు చేయడానికి ముందు ప్రశ్నలు అడగండి. సమాధానాలను రాతపూర్వకంగా ఇవ్వమని అడగండి. Sales page అనేది scope document కాదు.

1. ఏ పనులు scope లో ఉన్నాయి? ప్రతి task ను విడిగా అడగండి. Brochure కాకుండా జాబితాను అడగండి.
2. నేను install చేసిన software కు కూడా support అందిస్తారా, లేక మీరు install చేసిన software కు మాత్రమేనా?
3. మీరు patches ను స్వయంచాలకంగా install చేస్తారా? Kernel updates కోసం నా అనుమతి లేకుండా reboot చేస్తారా?
4. మీరు apply చేసిన patch వల్ల నా application పనిచేయకపోతే బాధ్యత ఎవరిది?
5. మీరు backups తీసుకుంటారా? అవి ఎక్కడ నిల్వ ఉంటాయి, ఎంతకాలం ఉంచుతారు, restore ను ఎవరు నిర్వహిస్తారు?
6. ఇటీవల customer server ను restore చేశారా? దానికి ఎంత సమయం పట్టింది?
7. Ticket కు response time ఎంత? ఆదివారం 03:00 సమయంలో అది వేరుగా ఉంటుందా?
8. నాకు root access కొనసాగుతుందా? దాన్ని ఉపయోగించడం వల్ల మీరు అందించే support పరిధి తగ్గుతుందా?
9. Fee ప్రతి server కు వసూలు చేస్తారా, లేక ప్రతి account కు వసూలు చేస్తారా?
10. నేను ఈ సేవను వదిలిపెడితే, నాతో పాటు ఏమి తీసుకెళ్లగలను? Proprietary control panel లోనే ఉండే setup ను export చేయడం కష్టంగా ఉండవచ్చు.

ప్రశ్న 5 మిగిలిన చాలా ప్రశ్నలకు సమాధానం ఇస్తుంది. దానికి ఖచ్చితమైన సమాధానం ఇచ్చే host ఈ పనిని ఇంతకు ముందు నిర్వహించినట్లు తెలుస్తుంది. అస్పష్టమైన సమాధానం అంటే restore ను ఎప్పుడూ పరీక్షించలేదని అర్థం. పరీక్షించని backup కేవలం ఒక copy మాత్రమే. ప్రశ్న 5లో location గురించిన భాగం కూడా ఉంది. Copies భౌతికంగా ఎక్కడ ఉంటాయనేది technical question మాత్రమే కాదు, legal question కూడా. hosting country ను ఎంచుకునేటప్పుడు వాస్తవంగా ముఖ్యమైనది ఏమిటి దీన్నే వివరిస్తుంది.

మధ్యమార్గం: unmanaged మరియు automation

చాలా మంది సాంకేతిక పాఠకులు ఈ రెండు అంచుల్లో ఏదీ కోరుకోరు. వారు సాధారణ పనిని యంత్రానికి అప్పగించే unmanaged ప్రణాళికను కోరుకుంటారు. యంత్రం అంచనా వేయలేని విషయాలపై తమ దృష్టిని కేంద్రీకరించాలనుకుంటారు. దీన్ని మొదటి రోజే ఏర్పాటు చేయండి. కొత్త VPS పై మొదటి పది నిమిషాలు unmanaged ఎంపిక చేసుకునే ప్రతి ఒక్కరికీ ఉపయోగకరమైన ప్రారంభం. SSH ప్రాప్యతను hardening చేయడం కూడా అదే మొదటి session లో చేయాలి.

స్వయంచాలక 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 ఉన్నా, ఏదీ అమలు కాదు. మీకు ఎలాంటి సమాచారం కూడా అందదు.

సిస్టమ్‌లో మార్పులు చేయకుండా దీన్ని పరీక్షించండి. Package పేరు unattended-upgrades, కానీ command singular రూపంలో ఉంటుందని గమనించండి:

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

పరిశీలించిన ప్రతి package ను output చూపిస్తుంది. ఏదీ pending లో లేకపోతే, చివరలో No packages found that can be upgraded unattended వంటి పంక్తి కనిపిస్తుంది. నిజమైన runs /var/log/unattended-upgrades/unattended-upgrades.log లో వ్రాయబడతాయి. కాబట్టి ఊహించకుండా అక్కడే పరిశీలించండి.

Kernel update చేసిన వెంటనే మార్పు కనిపించదు. నడుస్తున్న kernel boot సమయంలో load చేయబడినదే కాబట్టి, machine reboot అయ్యే వరకు కొత్త kernel ఉపయోగించబడదు. Reboot అవసరమైనప్పుడు /var/run/reboot-required ఫైల్ కనిపిస్తుంది. ఆ ఫైల్ కోసం 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";

ఎవరైనా logged in ఉన్నప్పుడు Automatic-Reboot-WithUsers "false" reboot ను నిలిపివేస్తుంది. Interactive గా ఉపయోగించే box కు ఇది సురక్షితం. ఎవరూ login చేయని machine పై దీనివల్ల ప్రయోజనం ఉండదు. Ubuntu పై పూర్తి unattended upgrades setup blocklist syntax మరియు email options ను వివరిస్తుంది.

వేరే చోట నడిచే monitoring

Server పై నడిచే monitor, server down అయిందని మీకు తెలియజేయలేడు. ఎందుకంటే monitor కూడా down అవుతుంది. Check ను రెండవ host పై లేదా external service లో ఉంచండి. Status monitoring కోసం Uptime Kuma సాధారణ self-hosted ఎంపిక. అది monitor చేసే machine కంటే వేరే machine పై ఉండాలి.

కనీసం నాలుగు విషయాలను monitor చేయండి: reachability, disk usage, application తన నిజమైన port పై సమాధానం ఇస్తుందా లేదా, మరియు certificate expiry. Disk సమస్యను చాలామంది ఆలస్యంగా గుర్తిస్తారు. ప్రతి రోజు కొద్దిగా పెరిగే 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 పై దీన్ని run చేస్తే 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 తో list చేయాలి. 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 ను run చేస్తుంది. అందువల్ల రాత్రంతా 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 స్వయంగా start అవుతుందని నిర్ధారించండి. తరువాత మీరు మేల్కొని ఉన్నప్పుడు ఉద్దేశపూర్వకంగా reboot చేయండి:

systemctl is-enabled nginx docker
sudo reboot

Unattended upgrade మీ application ను విరిచే package ను install చేయవచ్చు. అది జరిగిందని pipeline లోని ఏ భాగానికీ తెలియదు. దాన్ని గుర్తించేది మీ monitor. Updates automatic అయిన తర్వాత monitor తప్పనిసరి కావడానికి ఇదే కారణం. సాధారణ పనిని machine చూసుకుంటుంది. Incident బాధ్యత మాత్రం మీదే.

నిర్వహిత సేవకు చెల్లించడం సముచితమైన సందర్భాలు

నిర్వహిత సేవల వైపును కూడా న్యాయంగా పరిశీలించాలి. ఈ 4 పరిస్థితుల్లో అది సరైన ఎంపిక అవుతుంది.

• బృందంలో Linux నిర్వహించేవారు ఎవరూ లేరు, అలాగే ఎవరినైనా నియమించాలనే ప్రణాళిక లేదు.
• Patching కు బాధ్యత వహించే పక్షాన్ని compliance అవసరం స్పష్టంగా పేర్కొంది, కానీ ఆ బాధ్యతను మీరు స్వీకరించలేరు.
• మీరు ఉపయోగిస్తున్న stack ఆ హోస్ట్ ప్రత్యేక నైపుణ్యం కలిగినదే, కాబట్టి మీ సమస్యను వారు గతంలోనే పరిష్కరించి ఉండవచ్చు.
• ఈ పనిని సాధారణంగా చేసే వ్యక్తి మీ సంస్థలో అత్యధిక ఖర్చుతో కూడిన ఉద్యోగి, మరియు అతని ఒక గంట ఖర్చు premium సేవకు ఒక నెల చెల్లింపు కంటే ఎక్కువ.

Managed సేవ స్వయంచాలకంగా మరింత సురక్షితమైనది కాదు. నిర్లక్ష్యంగా నిర్వహించే యజమాని కంటే managed plans patches ను వేగంగా అమలు చేస్తాయి. ఇది నిజమైన ప్రయోజనం. అయితే అవి తరచుగా control panel ను కూడా install చేస్తాయి. అది login page మరియు స్వంత vulnerability history కలిగిన, network కు బహిర్గతమయ్యే పెద్ద అప్లికేషన్. ఇది సముచితమైన మార్పిడి కావచ్చు, కానీ అది మార్పిడే.

నిర్ణయం ప్రతిసారీ ఇదే జాబితాపై ఆధారపడుతుంది. ఆ 10 పనులను రాసి, ప్రతి quote కింద ప్రతి పనికి బాధ్యత ఎవరిదో గుర్తించండి. తరువాత ఆ తేడాను మీ ఒక గంట సమయానికి ఉన్న విలువతో పోల్చండి. ఇలా చేసిన సాంకేతిక పాఠకుల్లో చాలామంది unmanaged ఎంపికను తీసుకుని, సాధారణ పనులను timer కు అప్పగిస్తారు. తక్కువ ఖర్చు కారణంగా కాకుండా, సమర్థించగల నిర్ణయంగా ఇది పరిగణించవచ్చు.

FAQ

నిర్వహిత మరియు నిర్వహించని VPS మధ్య తేడా ఏమిటి?

నిర్వహించని VPS మీకు సర్వర్‌ను మాత్రమే ఇస్తుంది. Patching, firewall, backups, monitoring, అలాగే kernel update తర్వాత reboot చేయడం మీ బాధ్యత. నిర్వహిత VPSలో ఈ పనిలో కొంత భాగాన్ని provider నిర్వహిస్తుంది. సాధారణంగా operating system layer మరియు provider మీ కోసం install చేసిన software ఇందులో ఉంటాయి. ఖచ్చితమైన బాధ్యతల పరిమితి ఆ పదం ద్వారా నిర్ణయించబడదు; ప్రతి provider దానిని వేరుగా నిర్ణయిస్తుంది. అందువల్ల రెండు ధరలను పోల్చే ముందు task-by-task scope ను లిఖితపూర్వకంగా అడగండి.

నిర్వహిత VPS ఉంటే నా స్వంత backups అవసరం లేదా?

అవసరం ఉంది. Provider backups సాధారణంగా మొత్తం server యొక్క provider image ను రక్షిస్తాయి. Host విఫలమైనప్పుడు అవి ఉపయోగపడతాయి. మీరు file ను delete చేసినప్పుడు, తప్పు migration నడిపినప్పుడు లేదా వారాల క్రితం data పాడై అది ఈరోజు గుర్తించినప్పుడు అవి చాలా అరుదుగా సహాయపడతాయి. Snapshots ఎంతకాలం ఉంచుతారు, ఒకే file ను restore చేయవచ్చా, restore ను ఎవరు నిర్వహిస్తారు అనే విషయాలను అడగండి. తరువాత restic వంటి tool తో మీ స్వంత offsite copy ను ఉంచండి. అది పనిచేస్తుందని నిర్ధారించుకోవడానికి restic restore latest --target /tmp/restore-check తో test చేయండి.

నిర్వహిత VPS, నిర్వహించని VPS కంటే మరింత secure గా ఉంటుందా?

అది స్వయంచాలకంగా జరగదు. ఎప్పుడూ login కాని owner కంటే managed plan వేగంగా patches install చేస్తుంది. ఇది వాస్తవంగా risk ను తగ్గిస్తుంది. అనేక managed plans control panel ను కూడా install చేస్తాయి. Panel అనేది తన సొంత login page మరియు vulnerabilities చరిత్ర కలిగిన, network కు ఎదురుగా ఉండే పెద్ద application. Automatic security updates, closed firewall, key-only SSH మరియు అదనంగా ఏమీ listening లో లేని unmanaged server, panel నడుస్తున్న managed server కంటే చిన్న target అవుతుంది.

Unmanaged తో ప్రారంభించి తరువాత managed కు మారవచ్చా?

సాధారణంగా మారవచ్చు. అయితే ఇది అరుదుగా ఒక checkbox తో పూర్తవుతుంది. Provider బాధ్యత తీసుకునే ముందు సాధారణంగా server ను audit చేస్తుంది లేదా rebuild చేస్తుంది. తమకు కనిపించని configuration కు వారు support ఇవ్వరు. Onboarding లో ఏమి ఉంటుందో, reinstall అవసరమా, తరువాత మీరు స్వయంగా configure చేసిన వాటిలో ఏవి scope వెలుపల ఉంటాయో అడగండి.

Managed VPSలో root access నాదగ్గరే ఉంటుందా?

చాలా managed VPS plans లో ఉంటుంది. అయితే root access మరియు support scope పరస్పరం ప్రభావితం చేసుకుంటాయి. మీరు చేతితో మార్చిన component కు కొంతమంది providers support ను తగ్గించవచ్చు లేదా పూర్తిగా రద్దు చేయవచ్చు. Ticket లోతుగా వెళ్లినప్పుడు కొంతమంది providers తమ స్వంత template నుండి server ను rebuild చేయవచ్చు. ఏదైనా tune చేయడానికి ముందు ఆ నియమాన్ని లిఖితపూర్వకంగా పొందండి. Rebuild కు ఒక weekend కాకుండా ఒక గంట మాత్రమే పట్టేలా మీ configuration files ను version control లో ఉంచండి.