VPS inayodhibitiwa dhidi ya isiyodhibitiwa: ipi bora?

VPS inayodhibitiwa (managed) dhidi ya isiyodhibitiwa (unmanaged): jibu fupi

Kuchagua kati ya VPS inayodhibitiwa na isiyodhibitiwa ni swali la nguvu kazi, si swali la bidhaa. Isiyodhibitiwa inamaanisha unawajibika kwa patching, firewall, backups, ufuatiliaji, na kuwasha upya seva saa 8 usiku. Inayodhibitiwa inamaanisha mtoa huduma anafanya sehemu ya kazi hizo kwa ajili yako, na ukubwa wa sehemu hiyo hutofautiana sana kati ya watoa huduma. Ulinganisho pekee wenye manufaa ni orodha ya kazi ambazo kila mpango unakuondolea, ukilinganisha na gharama ya muda wako mwenyewe.

Hakuna ufafanuzi sanifu wa neno managed. Mtoa huduma mmoja anamaanisha kuwa mfumo wa uendeshaji (OS) utafanyiwa patching na binadamu atajibu tiketi yako ya msaada. Mwingine anamaanisha kuwa control panel imewekwa na kila kitu kilicho juu yake ni jukumu lako. Wa tatu anamaanisha mkataba wa huduma ulioandikwa wenye muda maalum wa majibu. Mipango miwili inayotumia neno lilelile inaweza kutofautiana katika kila jambo la msingi, kwa hivyo soma hati ya upeo wa huduma (scope document) kabla ya kusoma bei. Ikiwa bado unaamua mashine hiyo inafanya kazi gani, kile unachoweza kufanya kweli na VPS ndilo swali bora la kulimaliza kwanza.

Majukumu ambayo mtu lazima ayasimamie

Kila seva inayofanya kazi ina orodha ya kazi zinazofanana. Kwenye mpango usiosimamiwa, orodha hiyo ni yako. Kwenye mpango unaosimamiwa, unalipia ili kuondoa majukumu hayo kutoka kwako. Pitia orodha hii na uandike jina kando ya kila kipengele.

• Kusasisha mfumo wa uendeshaji (patching), na kuwasha upya seva (reboots) kunakohitajika na masasisho ya kernel.
• Sheria za firewall, zinazopaswa kusahihishwa unapoanzisha au kuondoa huduma. Misingi ya ufw firewall kwa VPS inaelezea seti ya kwanza ya sheria.
• Ufikiaji wa SSH: usimamizi wa funguo (keys), kuzima uingiaji kwa nenosiri, kubatilisha ufunguo wakati mtu anapoondoka, na njia ya kuingia tena unapojifungia nje.
• Hifadhi rudufu (backups), nakala iliyo nje ya seva, na urejeshaji (restore) ambao umewahi kuufanya kwa vitendo.
• Ufuatiliaji (monitoring), ambao unamaanisha kujua kuwa seva inafikika, diski ina nafasi, huduma bado inaendelea kufanya kazi, na cheti hakijaisha muda wake.
• Kupitia logi (log review), na majibu wakati kitu chochote kwenye logi hizo kinaonekana kuwa si sahihi.
• Usanidi wa huduma kwa web server, database, reverse proxy, na queue ikiwa unatumia mojawapo.
• Upyaji wa vyeti (certificate renewal), na ukarabati wakati upyaji wa kiotomatiki unapoacha kufanya kazi.
• Uwezo wa seva (capacity), ambao unamaanisha kutambua kuwa kumbukumbu (memory) imeisha kabla ya OOM (out of memory) killer haijatambua kwa niaba yako.
• Majibu ya dharura (incident response), ambayo yanamaanisha kuwa macho na kufikika wakati wowote usiochagua wewe.

Mengi ya haya ni ya kawaida na yanaweza kukabidhiwa kwa script. Majibu ya dharura ndilo jukumu pekee ambalo haliwezi kukabidhiwa kwa script, kwa sababu linahitaji mtu anayeweza kufanya maamuzi. Hiyo ndiyo bidhaa halisi inayouzwa na mpango unaosimamiwa, ndiyo maana orodha ya maswali hapa chini inajikita zaidi kwenye upeo wa usaidizi badala ya patching.

Mambo ambayo kwa kawaida hayajumuishwi katika huduma inayodhibitiwa

Hapa ndipo wanunuzi wanapopata matatizo, hivyo uwe makini sana. Mkataba wa huduma inayodhibitiwa (managed contract) kwa kawaida hugharamia mfumo wa uendeshaji (OS) na programu zilizosakinishwa na mtoa huduma. Huduma hii huishia kwenye mpaka wa programu yako.

Nambari zako (code) ni zako. Hitilafu ya 500 kutoka kwenye programu yako si kosa la seva. Mtoa huduma atathibitisha kuwa mchakato wa web server unafanya kazi na kukurudishia tiketi ya usaidizi. Huo ni mpaka wa haki. Hii pia ndiyo pengo kubwa zaidi kati ya kile wanunuzi wanachotarajia na kile walichonunua.

Matatizo ya kiwango cha programu (application-level) kwa kawaida yako nje ya wigo. Query ya database inayochelewa, plugin iliyoharibika baada ya update, cache iliyosanidiwa vibaya, au foleni ya barua pepe (mail queue) iliyoacha kufanya kazi: haya yote yako juu ya mstari wa wajibu wa mtoa huduma, hata kama yeye ndiye aliyesakinisha programu iliyo chini yake.

Urejeshaji wa data nyingi uko nje ya wigo. Backup za mtoa huduma hulinda taswira ya seva nzima ya mtoa huduma, na zipo kwa ajili ya hali ambapo maunzi (hardware) ya seva yanashindwa kufanya kazi. Mara chache sana backup hizi huundwa kwa ajili ya hali ambapo umefuta mstari (row) wa data, umefanya migration mbaya, au umeharibu faili wiki sita zilizopita na kugundua leo. Uliza muda wa kuhifadhi data (retention window), kama faili moja linaweza kutolewa, na nani anayefanya urejeshaji.

Programu uliyosakinisha ni yako. Ukisakinisha Docker, mtoa huduma kwa kawaida anamiliki seva (host) wakati wewe unamiliki kila kitu kilicho ndani ya containers.

Marekebisho ya mikono yanaweza kufuta msaada wa kiufundi. Mikataba mingine huondoa sehemu ya mfumo kutoka kwenye wigo wa usaidizi pindi mteja anapohariri usanidi wake moja kwa moja. Uliza kuhusu hili ikiwa unapanga kurekebisha chochote.

Pima thamani ya muda wako dhidi ya tofauti ya kila mwezi

Chukua nukuu mbili ulizo nazo na uandike tofauti ya gharama ya kila mwezi. Namba hiyo ndiyo kiasi ambacho mtoa huduma anatoza ili kuondoa kazi zilizo kwenye orodha hapo juu. Sasa weka thamani kwa upande wako wa makubaliano.

• Saa moja ya muda wako ina thamani gani, na inachukua saa ngapi kwa mwezi kukamilisha orodha hiyo pindi itakapokuwa imefanyiwa otomatiki?
• Saa moja ya seva kutopatikana (downtime) inagharimu kiasi gani huduma inayotumia seva hii?

Seva ya Ubuntu iliyo thabiti yenye masasisho ya kiotomatiki na ufuatiliaji wa nje inahitaji uangalizi mdogo sana wa kawaida. Miezi mingi haihitaji uangalizi wowote. Kazi za kawaida huwa nafuu pindi script inapozishughulikia. Usumbufu wa ghafla ndio sehemu ya gharama kubwa, na usumbufu ndio kitu ambacho mpango wa usimamizi (managed plan) huuza. Ikiwa seva inaendesha mradi wa burudani, hitilafu haigharimu chochote na chaguo la kutotumia mtoa huduma (unmanaged) ndilo dhahiri. Ikiwa seva inachakata maagizo, chunguza kwa makini kama mkataba wa usaidizi unapunguza muda wa hitilafu, kwa sababu mtoa huduma anayesimamia bado anapaswa kusoma tiketi yako, kurudia kosa hilo, na kuchukua hatua.

Tofauti ya gharama pia huongezeka kulingana na idadi ya seva. Ada za usimamizi kwa kawaida hutoza kwa kila seva, wakati otomatiki huandikwa mara moja na kunakiliwa. Seva ya pili hupunguza kwa nusu gharama halisi ya script uliyoiandika kwa seva ya kwanza, kwa hivyo soma jinsi ya kusimamia seva nyingi za Linux kabla ya kukubaliana na ada ya kila seva. Kwa namba za msingi za kulinganisha, gharama halisi ya VPS kwa mwezi huweka kiwango cha chini, na mabadilishano kati ya VPS na seva ya kujitolea (dedicated server) huwa muhimu pindi mzigo wa kazi unapokuwa mkubwa kiasi kwamba ada ya ziada ya usimamizi inakuwa ndogo sana.

Maswali ya kumuuliza mtoa huduma kabla ya kulipia huduma ya usimamizi (managed premium)

Uliza kabla ya kulipa, na uhakikishe unapata majibu kwa maandishi. Ukurasa wa mauzo si hati ya upeo wa kazi (scope document).

1. Ni nini kinachohusika katika huduma, kazi kwa kazi? Omba orodha, si broshua ya matangazo.
2. Je, msaada wa kiufundi unahusu programu ninazozisakinisha mimi, au zile ulizozisakinisha wewe pekee?
3. Je, unafanya patching kiotomatiki, na je, unaanzisha upya (reboot) seva kwa ajili ya kernel updates bila kuniuliza kwanza?
4. Nani anawajibika ikiwa patch uliyoiweka itaharibu programu yangu?
5. Je, unachukua backups? Zinahifadhiwa wapi, zinakaa kwa muda gani, na nani anafanya urejeshaji (restore)?
6. Je, umewahi kurejesha seva ya mteja hivi karibuni, na ilichukua muda gani?
7. Muda wa kujibu tiketi (ticket response time) ni upi, na je, unabadilika saa 03:00 siku ya Jumapili?
8. Je, ninabaki na root access, na je, kuitumia kunapunguza kiwango cha msaada utakaonipa?
9. Je, ada inatozwa kwa kila seva au kwa kila akaunti?
10. Nikiondoka, nitaondoka na nini? Usanidi unaotegemea control panel ya kipekee (proprietary) unaweza kuwa mgumu kuhamishika.

Swali la 5 linaamua majibu ya maswali mengine mengi. Mtoa huduma anayelijibu swali hili kwa usahihi anakuonyesha kuwa amewahi kufanya kazi hiyo hapo awali. Jibu lisilo wazi linamaanisha kuwa urejeshaji haujawahi kufanyiwa majaribio, na backup isiyojaribiwa ni nakala tu. Swali la 5 pia lina sehemu ya mahali: mahali ambapo nakala hizo zinapohifadhiwa kimwili ni swali la kisheria vilevile kama lilivyo la kiufundi, na mambo muhimu ya kuzingatia unapochagua nchi ya kuhifadhi data yanaelezea hilo kwa kina.

Njia ya kati: usimamizi wa kawaida pamoja na otomatiki

Wasomaji wengi wa kiufundi hawataki ncha yoyote kati ya hizo mbili. Wanataka mpango usiosimamiwa kikamilifu huku kazi za kawaida zikifanywa na mashine, na wao wakizingatia mambo ambayo mashine haiwezi kuyaamua. Iweke sawa siku ya kwanza. Dakika kumi za kwanza kwenye VPS mpya ndiyo hatua ya kuanzia kwa mtu yeyote anayechagua mfumo usiosimamiwa, na kuimarisha usalama wa SSH ni sehemu ya kikao hicho cha kwanza.

Masasisho ya usalama ya kiotomatiki

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

Faili hiyo sasa inapaswa kuwa na APT::Periodic::Update-Package-Lists "1"; na APT::Periodic::Unattended-Upgrade "1";. Faili inayokosekana, au 0 kwenye mojawapo ya mistari hiyo, inamaanisha hakuna kinachoendelea na hutaarifiwa.

Ijaribu bila kubadilisha mfumo. Kumbuka kuwa kifurushi ni unattended-upgrades wakati amri ni ya umoja:

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

Matokeo yanaorodhesha kila kifurushi kilichozingatiwa na kumalizia na mstari kama No packages found that can be upgraded unattended wakati hakuna kinachosubiri. Uendeshaji halisi huandikwa kwenye /var/log/unattended-upgrades/unattended-upgrades.log, kwa hivyo angalia huko badala ya kukisia.

Sasisho la kernel halibadilishi chochote hadi mashine iwake upya, kwa sababu kernel inayotumika ni ile iliyopakiwa wakati wa kuwasha. Faili ya /var/run/reboot-required huonekana wakati reboot inasubiriwa. Aidha fuatilia faili hiyo, au acha mashine ishughulikie yenyewe kwenye /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" huzuia reboot wakati mtu ameingia kwenye mfumo, jambo ambalo ni salama zaidi kwenye seva unayotumia kwa njia ya mwingiliano na halina faida kwenye seva ambayo hakuna anayeingia. Usanidi kamili wa unattended upgrades kwenye Ubuntu unaelezea sintaksia ya blocklist na chaguzi za barua pepe.

Ufuatiliaji unaoendeshwa mahali pengine

Kifuatiliaji kinachoendeshwa kwenye seva hakiwezi kukuambia kuwa seva imeshuka, kwa sababu nacho pia kimeshuka. Weka ukaguzi huo kwenye seva nyingine au kwenye huduma ya nje. Uptime Kuma kwa ufuatiliaji wa hali ndiyo jibu la kawaida la self-hosted, na inapaswa kuwa kwenye mashine tofauti na ile inayofuatiliwa.

Fuatilia mambo manne angalau: uwezo wa kufikika, matumizi ya diski, kama programu inajibu kwenye port yake halisi, na muda wa kuisha kwa cheti. Diski ndiyo inayowashika watu wengi. Faili ya logi au database inayokua kidogo kila siku huangusha seva wakati ambapo hakuna kingine kinachotabiri, na dalili ya kwanza mara nyingi ni huduma inayoshindwa kuandika na kujifunga.

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

Pia ongeza heartbeat. Kipima muda kwenye seva hupiga URL baada ya kila backup iliyofanikiwa au ukaguzi wa afya, na kifuatiliaji hutoa tahadhari wakati wito huo unapoacha kufika. Seva iliyo kimya basi hutoa tahadhari yenyewe, jambo ambalo ukaguzi wa pull-only hauwezi kufanya wakati njia ya mtandao ndiyo iliyovunjika.

Backup ambazo umewahi kuzirejesha angalau mara moja

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 huchapisha created restic repository <id> at sftp:... mara moja. Kuiendesha dhidi ya hazina (repository) ambayo tayari ipo kutashindwa badala ya kuandika juu yake, ambayo ndiyo tabia unayotaka. Weka nakala ya passphrase hiyo mahali nje ya seva: hazina haiwezi kusomeka bila hiyo, na hakuna njia ya kuirejesha.

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 inapaswa kuorodhesha uendeshaji ulioufanya sasa hivi na tarehe ya leo. restic check inathibitisha muundo wa hazina na kuchapisha no errors were found. Sasa fanya sehemu ambayo watu wengi huruka:

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

Faili uliyotarajia iko hapo au haipo, na kugundua sasa kunagharimu dakika kumi. Kisha weka uendeshaji huo kwenye kipima muda ili usitegemee wewe. Andika /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

Na /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 inaonyesha uendeshaji unaofuata na muda uliobaki. Matokeo tupu yanamaanisha uliwezesha huduma badala ya kipima muda, ambayo ndiyo makosa ya kawaida hapa. Persistent=true huendesha kazi iliyokosa baada ya kuwasha upya, kwa hivyo mashine iliyokuwa imezimwa usiku kucha bado hupata backup yake. Restic backups kwenye VPS inaenda kwa kina zaidi kuhusu mpangilio wa hazina na uhifadhi, na systemd services na timers inaelezea faili za unit mstari kwa mstari.

Mambo ambayo otomatiki haikupatii

Haikupatii uamuzi. Reboot ya kiotomatiki saa 02:00 hutokea bila kujali kama programu yako inarudi vizuri au la, kwa hivyo thibitisha kila huduma inaanza yenyewe na kisha fanya reboot kwa makusudi ukiwa macho:

systemctl is-enabled nginx docker
sudo reboot

Sasisho lisilosimamiwa linaweza pia kusakinisha kifurushi kinachovunja programu yako, na hakuna kitu kwenye mchakato huo kinachojua hilo limetokea. Kifuatiliaji chako ndicho kinachokigundua, ndiyo maana kifuatiliaji si cha hiari mara tu masasisho yanapokuwa ya kiotomatiki. Mashine inashughulikia kazi za kawaida. Tukio bado ni lako.

Wakati huduma iliyosimamiwa (managed) inapostahili gharama

Kuwa na haki kwa upande wa huduma zilizosimamiwa. Hali nne hufanya iwe ununuzi sahihi.

• Hakuna mtu kwenye timu anayeweza kutumia Linux, na kuajiri mtu si sehemu ya mpango.
• Sharti la kufuata kanuni (compliance) linataja mhusika anayewajibika kwa patching, na mhusika huyo huwezi kuwa wewe.
• Stack inayotumika ni ile ambayo mtoa huduma ana utaalamu nayo, hivyo support yao imeshawahi kuona hitilafu yako hapo awali.
• Mtu ambaye angefanya kazi hiyo ndiye mfanyakazi wako wa gharama kubwa zaidi, na saa moja ya kazi yake inagharimu zaidi ya mwezi mmoja wa ada ya premium.

Huduma iliyosimamiwa si salama zaidi moja kwa moja. Mipango iliyosimamiwa hufanya patching haraka kuliko mmiliki asiyejali, na hiyo ni faida ya kweli. Mara nyingi pia husakinisha control panel, ambayo ni programu kubwa inayoelekea kwenye mtandao ikiwa na ukurasa wa kuingia na historia yake ya udhaifu (vulnerability). Hiyo inaweza kuwa biashara ya kuridhisha, lakini bado ni biashara (trade-off).

Uamuzi unarudi kwenye orodha ileile kila wakati. Andika kazi kumi, weka alama nani anayemiliki kila moja chini ya kila nukuu, kisha linganisha pengo hilo na thamani ya saa moja ya umakini wako. Wasomaji wengi wa kiufundi wanaofanya hivyo huishia kutumia huduma zisizosimamiwa (unmanaged) huku kazi za kawaida zikikabidhiwa kwa timer, na hiyo ni jibu linaloteteweka badala ya kuwa la bei nafuu tu.

FAQ

Kuna tofauti gani kati ya VPS inayodhibitiwa (managed) na isiyodhibitiwa (unmanaged)?

VPS isiyodhibitiwa inakupa mashine pekee bila huduma nyingine, kwa hivyo unawajibika kwa patching, firewall, backups, ufuatiliaji, na kuwasha upya seva baada ya sasisho la kernel. VPS inayodhibitiwa huhamishia sehemu ya kazi hiyo kwa mtoa huduma, kwa kawaida katika ngazi ya mfumo wa uendeshaji na programu walizokuwekea. Mpaka kamili huwekwa na kila mtoa huduma badala ya neno lenyewe, kwa hivyo uliza wigo wa kazi kwa kazi kwa maandishi kabla ya kulinganisha bei mbili.

Je, VPS inayodhibitiwa inamaanisha sihitaji backups zangu mwenyewe?

Hapana. Backups za mtoa huduma kwa kawaida hulinda picha ya seva nzima ya mtoa huduma na zipo kwa ajili ya hali ambapo host inafeli. Mara chache husaidia unapofuta faili, unapofanya migration mbaya, au unapoharibu data wiki kadhaa zilizopita na kugundua leo. Uliza snapshots zinahifadhiwa kwa muda gani, kama faili moja linaweza kurejeshwa, na nani anayefanya urejeshaji. Kisha hifadhi nakala yako nje ya seva (offsite) ukitumia zana kama restic, na uijaribu kwa restic restore latest --target /tmp/restore-check ili uhakikishe inafanya kazi.

Je, VPS inayodhibitiwa ni salama zaidi kuliko isiyodhibitiwa?

Si lazima. Mpango unaodhibitiwa hufanya patching haraka zaidi kuliko mmiliki ambaye haingii kwenye seva kamwe, jambo ambalo hupunguza hatari. Mipango mingi inayodhibitiwa pia husakinisha control panel, na panel ni programu kubwa inayoelekea kwenye mtandao ikiwa na ukurasa wake wa kuingia na historia yake ya udhaifu (vulnerabilities). Seva isiyodhibitiwa yenye sasisho za kiotomatiki za usalama, firewall iliyofungwa, SSH ya ufunguo pekee, na bila huduma nyingine za ziada zinazosikiliza, ni shabaha ndogo kuliko seva inayodhibitiwa inayoendesha panel.

Je, ninaweza kuanza bila kudhibitiwa na kubadili hadi inayodhibitiwa baadaye?

Kwa kawaida ndiyo, ingawa mara chache ni kwa kubofya kisanduku tu. Watoa huduma kwa kawaida hukagua au kujenga upya seva kabla ya kuchukua jukumu lake, kwa sababu hawatasaidia usanidi wasiouona. Uliza onboarding inahusisha nini, kama inahitaji usakinishaji upya, na kama chochote ulichosanidi mwenyewe kitabaki nje ya wigo wa msaada baadaye.

Je, ninabaki na root access kwenye VPS inayodhibitiwa?

Katika mipango mingi ya VPS inayodhibitiwa unayo, lakini root access na wigo wa msaada huingiliana. Baadhi ya watoa huduma hupunguza au kufuta msaada kwa sehemu uliyohariri kwa mkono, na wengine watajenga upya kutoka kwa template yao wenyewe ikiwa tiketi ya msaada itakuwa ngumu sana. Pata kanuni hiyo kwa maandishi kabla ya kurekebisha chochote, na uhifadhi faili zako za usanidi kwenye version control ili ujenzi upya uchukue saa moja badala ya wikendi nzima.