Managed की unmanaged VPS: तुमच्यासाठी योग्य कोणते?

व्यवस्थापित आणि अव्यवस्थापित VPS: थोडक्यात उत्तर

व्यवस्थापित आणि अव्यवस्थापित VPS यांपैकी निवड करणे हा उत्पादनाचा नव्हे, तर कामाच्या जबाबदारीचा प्रश्न आहे. अव्यवस्थापित VPS मध्ये patching, firewall, backups, monitoring आणि पहाटे 2 वाजता reboot करण्याची जबाबदारी तुमची असते. व्यवस्थापित VPS मध्ये provider यांपैकी काही कामे तुमच्यासाठी करतो. मात्र तो भाग वेगवेगळ्या hosts मध्ये मोठ्या प्रमाणात बदलतो. प्रत्येक plan तुमच्याकडून कोणती कामे काढून घेतो, आणि त्याची किंमत तुमच्या स्वतःच्या कामाच्या तासांच्या तुलनेत किती आहे, हीच उपयुक्त तुलना आहे.

managed या शब्दाची कोणतीही प्रमाणित व्याख्या नाही. एका host कडे operating system patch केला जातो आणि एखादी व्यक्ती ticket ला उत्तर देते. दुसऱ्या host कडे control panel install केलेले असते आणि त्यावरील सर्व जबाबदारी तुमची असते. तिसऱ्या host कडे response time नमूद केलेला लेखी service contract असतो. एकाच शब्दाचा वापर असलेल्या दोन plans मध्ये महत्त्वाच्या प्रत्येक बाबतीत फरक असू शकतो. त्यामुळे किंमत पाहण्यापूर्वी scope document वाचा. मशीनचा उपयोग नेमका कशासाठी करायचा हेच तुम्ही अद्याप ठरवत असाल, तर VPS वापरून तुम्ही प्रत्यक्षात काय करू शकता हा प्रश्न आधी निश्चित करणे अधिक योग्य आहे.

ज्या कामांची जबाबदारी कोणीतरी स्वीकारणे आवश्यक आहे

चालू असलेल्या प्रत्येक सर्व्हरवर कामांची एकच यादी असते. unmanaged plan मध्ये ही संपूर्ण यादी तुमची जबाबदारी असते. managed plan मध्ये या यादीतील काही कामे काढून घेण्यासाठी तुम्ही पैसे देता. यादीतील प्रत्येक कामासमोर त्याची जबाबदारी कोणाची आहे ते लिहा.

• ऑपरेटिंग सिस्टमचे patching आणि kernel updates साठी आवश्यक असलेले reboots.
• Firewall rules. सेवा जोडताना किंवा काढताना त्या योग्य ठेवणे आवश्यक आहे. VPS साठी ufw firewall ची मूलभूत माहिती सुरुवातीच्या ruleset चे वर्णन करते.
• SSH access: key handling, password login बंद ठेवणे, एखादी व्यक्ती सोडल्यानंतर तिची key revoke करणे आणि स्वतःला access बाहेर लॉक केल्यास पुन्हा प्रवेश मिळवण्याची व्यवस्था.
• Backups, offsite copy आणि तुम्ही प्रत्यक्षात करून पाहिलेला restore.
• Monitoring. याचा अर्थ server reachable आहे, disk वर पुरेशी जागा आहे, सेवा अजून चालू आहे आणि certificate expired झालेले नाही हे माहीत असणे.
• Log review आणि त्या logs मध्ये काही चुकीचे दिसल्यास करावयाची कार्यवाही.
• Web server, database, reverse proxy आणि queue वापरत असल्यास तिच्यासाठी service configuration.
• Certificate renewal आणि automatic renewal काम करणे थांबवल्यास त्याची दुरुस्ती.
• Capacity. याचा अर्थ out of memory (OOM) killer ला त्याची जाणीव होण्यापूर्वी memory संपत असल्याचे लक्षात घेणे.
• Incident response. याचा अर्थ तुम्ही स्वतः निवडलेली नसलेली वेळ असली तरी जागे आणि reachable असणे.

यांपैकी बहुतेक कामे नियमित स्वरूपाची असतात आणि script कडे सोपवता येतात. Incident response मात्र तसे करता येत नाही, कारण त्यासाठी निर्णय घेऊ शकणारी व्यक्ती आवश्यक असते. managed plan विकला जातो तेव्हा प्रत्यक्षात हेच मुख्य उत्पादन असते. म्हणून पुढील checklist मध्ये patching पेक्षा support scope विषयीच्या प्रश्नांना अधिक महत्त्व दिले आहे.

व्यवस्थापित सेवेमध्ये सहसा काय समाविष्ट नसते

याच ठिकाणी ग्राहकांची दिशाभूल होऊ शकते, त्यामुळे या बाबतीत अचूक माहिती घ्या. व्यवस्थापित करारामध्ये सामान्यतः ऑपरेटिंग सिस्टम आणि provider ने स्थापित केलेले software समाविष्ट असते. त्याची व्याप्ती तुमच्या application च्या स्तरापर्यंत पोहोचत नाही.

तुमचा स्वतःचा code तुमची जबाबदारी आहे. तुमच्या application कडून आलेली 500 error ही server fault नाही. Provider web server process चालू आहे याची पुष्टी करेल आणि ticket तुमच्याकडे परत पाठवेल. ही जबाबदारीची योग्य सीमा आहे. तसेच, ग्राहकांच्या अपेक्षा आणि त्यांनी प्रत्यक्षात घेतलेल्या सेवेमधील हा सर्वात मोठा फरक आहे.

Application-level समस्या सहसा कराराच्या व्याप्तीबाहेर असतात. Database query धीमी असणे, update नंतर plugin काम करणे बंद होणे, cache चुकीच्या पद्धतीने configure केलेले असणे किंवा mail queue मधील संदेशांची प्रक्रिया थांबणे: provider ने त्यांखालील software स्थापित केलेले असले तरी या समस्या त्या व्याप्तीच्या पलीकडे असतात.

बहुतेक data recovery कराराच्या व्याप्तीबाहेर असते. Provider चे backups संपूर्ण server ची provider कडे असलेली image सुरक्षित ठेवतात आणि host hardware fail झाल्यास त्यांचा उपयोग होतो. तुम्ही एखादा row delete केला, चुकीचे migration चालवले किंवा सहा आठवड्यांपूर्वी file corrupt झाली आणि आज लक्षात आले, अशा परिस्थितीसाठी ते क्वचितच तयार केलेले असतात. Retention window किती आहे, एकच file restore करता येते का आणि restore कोण चालवतो, हे विचारा.

तुम्ही स्थापित केलेले software तुमची जबाबदारी आहे. Docker स्थापित केल्यानंतर provider कडे सामान्यतः host ची जबाबदारी असते, तर containers मधील सर्व गोष्टींची जबाबदारी तुमची असते.

हाताने केलेले बदल support रद्द करू शकतात. ग्राहकाने configuration थेट संपादित केल्यानंतर काही करारांमध्ये संबंधित component कराराच्या व्याप्तीबाहेर टाकला जातो. तुम्ही कोणतेही tuning करणार असाल, तर याबाबत आधी विचारा.

तुमच्या वेळेची किंमत मासिक फरकाशी तुलना करा

तुमच्यासमोर असलेल्या दोन्ही कोट्स घ्या आणि त्यांतील मासिक फरक लिहून ठेवा. वरील यादीतील कामे काढून टाकण्यासाठी provider आकारत असलेली रक्कम म्हणजे हा फरक. आता या व्यवहारातील तुमच्या बाजूची किंमत ठरवा.

• तुमच्या एका तासाच्या वेळेची किंमत किती आहे आणि ही यादी automate केल्यानंतर तिच्यासाठी दर महिन्याला किती तास लागतात?
• या सर्व्हरवर चालणाऱ्या गोष्टीसाठी एक तासाच्या downtime ची किंमत किती आहे?

Automatic updates आणि external monitoring असलेल्या स्थिर Ubuntu box कडे नियमित लक्ष देण्याची गरज फार कमी असते. बहुतेक महिन्यांत अजिबात गरज नसते. एखादी script हे काम हाताळत असेल, तर नियमित कामाचा खर्च कमी असतो. महागडा भाग म्हणजे व्यत्यय; आणि managed plan मध्ये मुख्यतः याच व्यत्ययांसाठी पैसे घेतले जातात. सर्व्हरवर hobby project चालत असेल, तर outage मुळे कोणताही खर्च होत नाही आणि unmanaged पर्याय स्पष्टपणे योग्य ठरतो. सर्व्हरवर orders घेतले जात असतील, तर support contract मुळे outage खरोखर कमी वेळात दूर होईल का याचा काळजीपूर्वक विचार करा. Managed provider ला तुमचे ticket वाचावे, fault पुन्हा निर्माण करावा आणि त्यावर कृती करावीच लागते.

सर्व्हरची संख्या वाढल्यावर हा फरकही बदलतो. Managed fees साधारणपणे प्रत्येक सर्व्हरसाठी आकारले जातात, तर automation एकदाच लिहून नंतर copy करता येते. पहिल्या सर्व्हरसाठी लिहिलेल्या script मुळे दुसऱ्या सर्व्हरवर तिचा प्रभावी खर्च निम्मा होतो. त्यामुळे प्रत्येक सर्व्हरसाठी आकारल्या जाणाऱ्या fee ला मान्यता देण्यापूर्वी एकाधिक Linux सर्व्हर कसे व्यवस्थापित करावे हे वाचा. तुलनेसाठी दोन्ही बाजूंच्या मूलभूत आकड्यांमध्ये VPS ची प्रत्यक्ष मासिक किंमत किती असते हा किमान आधार ठरतो. Workload पुरेसा मोठा झाल्यावर, managed premium हा एकूण खर्चातील नगण्य rounding error ठरत असेल, तर VPS आणि dedicated server मधील तडजोड महत्त्वाची ठरते.

पेड managed सेवा निवडण्यापूर्वी host ला विचारायचे प्रश्न

पैसे देण्यापूर्वी प्रश्न विचारा आणि त्यांची उत्तरे लेखी स्वरूपात मागा. Sales page हे scope document नसते.

1. कोणती कामे scope मध्ये आहेत? Brochure नको; प्रत्येक कामाची यादी मागा.
2. Support मध्ये मी install केलेले software समाविष्ट आहे का, की फक्त तुम्ही install केलेले software?
3. तुम्ही आपोआप patch करता का? Kernel updates साठी माझी पूर्वपरवानगी न घेता reboot करता का?
4. तुम्ही लागू केलेल्या 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 करणे कठीण असू शकते.

Question 5 मुळे इतर बहुतेक प्रश्नांची उत्तरे स्पष्ट होतात. Host या प्रश्नाचे नेमके उत्तर देत असेल, तर त्याने हे काम यापूर्वी केलेले आहे असे समजा. अस्पष्ट उत्तराचा अर्थ restore कधीही तपासले गेलेले नाही असा होतो; आणि तपासलेले नसलेले backup म्हणजे फक्त एक copy असते. Question 5 मध्ये location चा भागही आहे: copies प्रत्यक्ष कुठे साठवल्या आहेत हा तांत्रिक प्रश्नाइतकाच कायदेशीर प्रश्न आहे. hosting country निवडताना प्रत्यक्षात काय महत्त्वाचे असते याचे स्पष्टीकरण देते.

मध्यम मार्ग: व्यवस्थापनाशिवाय, पण automation सह

बहुतेक तांत्रिक वाचकांना कोणतेही टोकाचे पर्याय नको असतात. त्यांना unmanaged योजना हवी असते, ज्यामध्ये नियमित कामे machine कडे सोपवली जातात आणि machine ज्या गोष्टींचा निर्णय घेऊ शकत नाही त्यांच्यासाठी त्यांचे स्वतःचे लक्ष राखले जाते. पहिल्याच दिवशी ही रचना करा. unmanaged पर्याय निवडणाऱ्या प्रत्येकासाठी नवीन VPS वरील पहिली दहा मिनिटे हा व्यावहारिक प्रारंभबिंदू आहे. SSH प्रवेश hardening करणे हेही त्याच पहिल्या सत्रात केले पाहिजे.

स्वयंचलित सुरक्षा अद्यतने

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 नसणे किंवा कोणत्याही ओळीवर 0 असणे याचा अर्थ काहीही चालणार नाही आणि तुम्हाला त्याची सूचना मिळणार नाही.

system मध्ये बदल न करता त्याची चाचणी करा. package चे नाव unattended-upgrades आहे, मात्र command एकवचनी आहे:

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

output मध्ये command ने विचारात घेतलेले प्रत्येक package दिसते. काहीही प्रलंबित नसल्यास शेवटी No packages found that can be upgraded unattended सारखी ओळ दिसते. प्रत्यक्ष runs /var/log/unattended-upgrades/unattended-upgrades.log मध्ये लिहिल्या जातात. त्यामुळे अंदाज न लावता तेथे तपासा.

kernel update झाल्यानंतर machine reboot करेपर्यंत त्याचा परिणाम होत नाही, कारण boot वेळी load केलेला kernelच चालू असतो. reboot प्रलंबित असल्यास /var/run/reboot-required file दिसते. ही file तपासा किंवा 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 करत नसलेल्या box वर याचा उपयोग नाही. Ubuntu वरील संपूर्ण unattended upgrades setup मध्ये blocklist syntax आणि email पर्याय स्पष्ट केले आहेत.

दुसरीकडे चालणारे monitoring

server वर चालणारा monitor server down असल्याचे सांगू शकत नाही, कारण तोही down असतो. check दुसऱ्या host वर किंवा external service वर ठेवा. status monitoring साठी Uptime Kuma हा नेहमीचा self-hosted पर्याय आहे. तो ज्या machine वर monitoring करतो त्यापेक्षा वेगळ्या machine वर असला पाहिजे.

किमान चार गोष्टी monitor करा: reachability, disk usage, application तिच्या प्रत्यक्ष port वर उत्तर देते का, आणि certificate expiry. Disk ही गोष्ट अनेकदा लक्षात येत नाही. दररोज थोडी वाढणारी log file किंवा database अशा वेळी box down करू शकते जेव्हा इतर कोणताही संकेत मिळत नाही. सुरुवातीचे लक्षण बहुतेकदा write करू न शकणारी आणि बंद होणारी service असते.

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 देतो. त्यानंतर silent server स्वतः alert निर्माण करतो. network path मध्येच बिघाड झाला असल्यास pull-only check हे करू शकत नाही.

किमान एकदा 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 चा कोणताही मार्ग नाही.

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 ने आजच्या date सह तुम्ही नुकताच केलेला run दाखवला पाहिजे. restic check repository structure पडताळते आणि 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 आणि उरलेला वेळ दाखवते. रिकामा result मिळाल्यास तुम्ही timer ऐवजी service enable केली आहे. ही येथे सर्वात सामान्य चूक आहे. Persistent=true पुढील boot नंतर चुकलेला job चालवते. त्यामुळे machine रात्रभर बंद असली तरी तिचा backup घेतला जातो. VPS वरील Restic backups मध्ये repository layout आणि retention यांचे अधिक सविस्तर वर्णन आहे. systemd services आणि timers मध्ये unit files ओळीनुसार स्पष्ट केले आहेत.

automation मुळे काय मिळत नाही

automation मुळे निर्णयक्षमता मिळत नाही. 02:00 वाजता होणारा automatic reboot application व्यवस्थित परत सुरू होते की नाही याची पर्वा करत नाही. त्यामुळे प्रत्येक service स्वतः सुरू होते का ते तपासा आणि तुम्ही जागे असताना जाणीवपूर्वक reboot करा:

systemctl is-enabled nginx docker
sudo reboot

unattended upgrade मुळे तुमचे application बिघडवणारे package install होऊ शकते. pipeline मधील कोणत्याही घटकाला ते घडल्याचे कळत नाही. ते monitor पकडते. म्हणून updates automatic झाल्यानंतर monitor ऐच्छिक राहत नाही. नियमित काम machine हाताळते. Incident ची जबाबदारी मात्र तुमचीच राहते.

प्रीमियम सेवा घेणे कधी योग्य ठरते

Managed पर्यायाचा योग्य विचार करा. चार परिस्थितींमध्ये तो योग्य पर्याय ठरतो.

• टीममधील कोणीही Linux चालवत नाही आणि एखाद्याची नियुक्ती करण्याची योजना नाही.
• अनुपालनाच्या आवश्यकतेनुसार patching साठी एका पक्षाची जबाबदारी निश्चित केली आहे आणि तो पक्ष तुम्ही असू शकत नाही.
• तुमचा stack हा host ज्या तंत्रज्ञानात विशेष प्रावीण्य ठेवतो त्यापैकी आहे. त्यामुळे त्यांच्या support टीमने तुमच्यासारखी समस्या यापूर्वी हाताळलेली असते.
• हे काम अन्यथा करणारी व्यक्ती तुमची सर्वाधिक खर्चिक कर्मचारी आहे आणि तिच्या एका तासाचा खर्च premium सेवेच्या एका महिन्याच्या खर्चापेक्षा जास्त आहे.

Managed सेवा आपोआप अधिक सुरक्षित असते असे नाही. दुर्लक्ष करणाऱ्या मालकापेक्षा Managed plans patching लवकर करतात आणि हा प्रत्यक्ष लाभ आहे. त्या अनेकदा control panel देखील install करतात. Control panel हे login page आणि स्वतःचा vulnerability history असलेले मोठे network-facing application असते. हा स्वीकारार्ह तडजोडीचा पर्याय ठरू शकतो; पण तरीही ती तडजोडच असते.

निर्णय प्रत्येक वेळी त्याच यादीवर आधारित असतो. ती दहा कामे लिहून काढा. प्रत्येक quote अंतर्गत प्रत्येक कामाची जबाबदारी कोणाकडे आहे ते नोंदवा. त्यानंतर त्या फरकाची तुलना तुमच्या लक्ष देण्याच्या एका तासाच्या मूल्याशी करा. असे केल्यानंतर बहुतेक तांत्रिक वाचक unmanaged पर्याय निवडतात आणि routine काम timer कडे सोपवतात. हा स्वस्त पर्याय नसून समर्थनीय निर्णय असतो.

FAQ

व्यवस्थापित आणि अव्यवस्थापित VPS मध्ये काय फरक आहे?

अव्यवस्थापित VPS मध्ये तुम्हाला मशीन आणि त्याव्यतिरिक्त काहीही मिळत नाही. त्यामुळे patching, firewall, backups, monitoring आणि kernel update नंतर reboot करण्याची जबाबदारी तुमची असते. व्यवस्थापित VPS मध्ये या कामांपैकी काही कामे provider कडे सोपवली जातात. यामध्ये सामान्यतः operating system layer आणि provider ने तुमच्यासाठी install केलेले software येते. नेमकी जबाबदारी प्रत्येक provider ठरवतो; ती केवळ या संज्ञेवरून ठरत नाही. त्यामुळे दोन किंमतींची तुलना करण्यापूर्वी प्रत्येक कामाची व्याप्ती लेखी स्वरूपात विचारा.

व्यवस्थापित VPS म्हणजे मला स्वतःचे backups ठेवण्याची गरज नाही का?

नाही. Provider backups सामान्यतः संपूर्ण server ची provider कडे असलेली image सुरक्षित ठेवतात आणि host fail झाल्यास उपयोगी पडतात. तुम्ही एखादी file delete केली, चुकीची migration चालवली किंवा काही आठवड्यांपूर्वी data corrupt झाला आणि ते आज लक्षात आले, तर ते backups क्वचितच मदत करतात. Snapshots किती काळ ठेवले जातात, एकच file restore करता येते का आणि restore कोण करतो, हे विचारा. त्यानंतर restic सारख्या tool ने स्वतःची offsite copy ठेवा आणि ती कार्यरत आहे याची खात्री करण्यासाठी restic restore latest --target /tmp/restore-check ने तिची चाचणी घ्या.

व्यवस्थापित VPS अव्यवस्थापित VPS पेक्षा अधिक सुरक्षित असतो का?

स्वतःहून नाही. कधीही login न करणाऱ्या मालकापेक्षा managed plan मध्ये patches जलद लागू होतात. त्यामुळे जोखीम प्रत्यक्षात कमी होते. अनेक managed plans मध्ये control panel देखील install केले जाते. Panel हे login page आणि स्वतःचा vulnerabilities चा इतिहास असलेले मोठे network-facing application असते. Automatic security updates, बंद firewall, key-only SSH आणि अनावश्यकपणे listening असलेली कोणतीही सेवा नसलेला unmanaged box, panel चालू असलेल्या managed box पेक्षा लहान target असतो.

मी सुरुवातीला अव्यवस्थापित VPS घेऊन नंतर व्यवस्थापित VPS वर switch करू शकतो का?

सामान्यतः होय, परंतु हे क्वचितच checkbox निवडण्याइतके सोपे असते. Provider जबाबदारी स्वीकारण्यापूर्वी server चे audit किंवा rebuild करतात. कारण त्यांना दिसत नसलेल्या configuration ला ते support करणार नाहीत. Onboarding मध्ये काय समाविष्ट आहे, reinstall आवश्यक आहे का आणि तुम्ही स्वतः केलेली configuration नंतर support scope बाहेर जाईल का, हे विचारा.

व्यवस्थापित VPS वर माझ्याकडे root access राहतो का?

बहुतेक managed VPS plans मध्ये root access राहतो. मात्र root access आणि support scope यांचा परस्पर संबंध असतो. तुम्ही हाताने edit केलेल्या component साठी काही providers support कमी करतात किंवा रद्द करतात. एखादा ticket पुरेसा गुंतागुंतीचा झाल्यास काही providers त्यांच्या स्वतःच्या template मधून server rebuild करतात. तुम्ही कोणतीही tuning करण्यापूर्वी हा नियम लेखी स्वरूपात मिळवा. तसेच configuration files version control मध्ये ठेवा, म्हणजे rebuild साठी संपूर्ण weekend न लागता एक तास पुरेल.