VPS Inayosimamiwa au Isiyosimamiwa: Unahitaji Ipi?

VPS inayosimamiwa dhidi ya isiyosimamiwa: jibu fupi

Kuchagua kati ya VPS inayosimamiwa na isiyosimamiwa ni suala la kazi, si suala la bidhaa. Kwenye VPS isiyosimamiwa, wewe ndiye unayesimamia masasisho ya usalama, firewall, backups, monitoring na reboot saa 2 usiku. Kwenye VPS inayosimamiwa, mtoa huduma anakufanyia baadhi ya kazi hizo, na kiwango cha huduma hiyo hutofautiana sana kati ya watoa huduma. Ulinganisho pekee wenye manufaa ni orodha ya kazi ambazo kila mpango inakuondolea, ukilinganisha gharama yake na muda wako mwenyewe.

Hakuna ufafanuzi wa kawaida wa neno inayosimamiwa. Kwa mtoa huduma mmoja, hii inaweza kumaanisha kwamba operating system inafanyiwa patching na mtu anajibu ticket. Kwa mwingine, inaweza kumaanisha kwamba control panel imewekwa, lakini kila kitu kilicho juu yake ni jukumu lako. Kwa mtoa huduma wa tatu, inaweza kumaanisha mkataba wa huduma ulioandikwa wenye muda wa majibu uliowekwa. Mipango miwili yenye neno hilo hilo inaweza kutofautiana katika kila jambo muhimu, kwa hiyo soma hati ya upeo wa huduma kabla ya kusoma bei. Ikiwa bado unaamua mashine hiyo itatumika kwa kazi gani, unachoweza kufanya kwa kweli na VPS ndilo swali bora la kujibu kwanza.

Majukumu ambayo mtu anapaswa kuyawajibikia

Kila seva inayofanya kazi ina orodha hii ya majukumu. Kwenye mpango usiosimamiwa, orodha hiyo ni jukumu lako. Kwenye mpango unaosimamiwa, unalipia majukumu kuondolewa kwenye orodha hiyo. Pitia orodha hii na uandike jina karibu na kila jukumu.

• Kusasisha mfumo wa uendeshaji, pamoja na reboot zinazohitajika na masasisho ya kernel.
• Sheria za firewall, ambazo zinapaswa kubaki sahihi unapoongeza au kuondoa huduma. Misingi ya firewall ya ufw kwa VPS inaeleza ruleset ya kuanzia.
• Ufikiaji wa SSH: usimamizi wa keys, kuzima kuingia kwa kutumia password, kubatilisha key mtu anapoondoka, na kuwa na njia ya kuingia tena unapojifungia nje.
• Backups, nakala ya offsite, na restore ambayo umeitekeleza kwa vitendo.
• Monitoring, yaani kujua kwamba seva inafikika, disk ina nafasi, huduma bado inafanya kazi, na certificate haija-expire.
• Kukagua logs, pamoja na hatua ya kuchukua kitu kinapoonekana si sahihi kwenye logs hizo.
• Usanidi wa huduma za web server, database, reverse proxy, na queue ikiwa unatumia moja.
• Kufanya renewal ya certificate, pamoja na kurekebisha tatizo automatic renewal inapoacha kufanya kazi.
• Capacity, yaani kutambua kwamba memory imekwisha kabla ya out of memory (OOM) killer kutambua hilo kwa niaba yako.
• Incident response, yaani kuwa macho na kufikika katika muda ambao hujachagua.

Majukumu mengi kati ya hayo ni ya kawaida na yanaweza kukabidhiwa script. Incident response ndiyo jukumu ambalo haliwezi kukabidhiwa script, kwa sababu linahitaji mtu anayeweza kufanya uamuzi. Hicho ndicho kipengele halisi kinachouzwa na mpango unaosimamiwa. Ndiyo maana checklist iliyo hapa chini inaweka maswali yake mengi kwenye upeo wa support, badala ya patching.

Kile ambacho huduma inayosimamiwa kwa kawaida haijumuishi

Hapa ndipo wanunuzi huingia hasara, kwa hiyo elewa mipaka hii kwa usahihi. Mkataba wa huduma inayosimamiwa kwa kawaida hushughulikia mfumo wa uendeshaji na programu iliyosakinishwa na mtoa huduma. Huduma hiyo huishia kwenye mpaka wa programu yako.

Msimbo wako ni jukumu lako. Hitilafu ya 500 kutoka kwenye programu yako si hitilafu ya seva. Mtoa huduma atathibitisha kuwa mchakato wa web server unaendelea kufanya kazi, kisha atakurudishia tiketi. Huo ni mpaka wa haki. Pia huo ndio pengo kubwa zaidi kati ya matarajio ya wanunuzi na huduma waliyonunua.

Matatizo ya kiwango cha programu kwa kawaida hayahusishwi. Query ya database inayochelewa, plugin iliyoharibika baada ya update, cache iliyosanidiwa vibaya, au mail queue iliyoacha kuondoa ujumbe: yote haya yako juu ya mpaka huo, hata kama mtoa huduma ndiye aliyesakinisha programu zinazotumika chini yake.

Urejeshaji wa data kwa kawaida hauhusishwi. Backups za mtoa huduma hulinda image ya mtoa huduma ya seva nzima, na huandaliwa kwa hali ambapo hardware ya host inashindwa. Mara chache huandaliwa kwa hali ambapo ulifuta row, uliendesha migration yenye hitilafu, au uliharibu file wiki sita zilizopita na ukagundua leo. Uliza muda wa retention ni upi, kama file moja linaweza kutolewa, na nani anaendesha restore.

Programu uliyosakinisha ni jukumu lako. Ukisakinisha Docker, kwa kawaida mtoa huduma anawajibika kwa host, huku wewe ukiwajibika kwa kila kitu kilicho ndani ya containers.

Mabadiliko ya moja kwa moja yanaweza kufuta usaidizi. Baadhi ya mikataba huondoa component kwenye wigo wa usaidizi baada ya mteja kuhariri configuration yake moja kwa moja. Uliza kuhusu hili ikiwa unapanga kufanya tuning yoyote.

Kadiria muda wako dhidi ya tofauti ya kila mwezi

Chukua nukuu hizo mbili zilizo mbele yako, kisha andika tofauti ya kila mwezi. Nambari hiyo ndiyo kiasi ambacho mtoa huduma anatoza ili kuondoa vipengele vilivyo kwenye orodha hapo juu. Sasa weka thamani kwenye upande wako wa uamuzi huu.

• Saa moja ya muda wako ina thamani gani, na orodha hiyo huchukua saa ngapi kwa mwezi baada ya kujiendesha kiotomatiki?
• Saa moja ya downtime hugharimu kiasi gani kwa kitu kinachoendesha kwenye seva hii?

Ubuntu box iliyo katika hali thabiti, yenye automatic updates na external monitoring, huhitaji uangalizi mdogo sana wa kawaida. Katika miezi mingi haihitaji uangalizi wowote. Kazi za kawaida huwa za gharama ndogo script inapozisimamia. Interrupts ndizo zenye gharama kubwa, na managed plan ndiyo huuza utatuzi wa interrupts hizo. Ikiwa seva inaendesha hobby project, outage haina gharama na unmanaged ndiyo chaguo la wazi. Ikiwa seva inapokea maagizo, chunguza kwa makini kama support contract kweli hupunguza muda wa outage, kwa sababu managed provider bado anapaswa kusoma ticket yako, kuiga tatizo, na kuchukua hatua kulitatua.

Tofauti hiyo pia huongezeka kadiri idadi ya seva inavyoongezeka. Managed fees kwa kawaida hutozwa kwa kila seva, ilhali automation huandikwa mara moja na kunakiliwa. Seva ya pili hupunguza kwa nusu gharama halisi ya script uliyoandika kwa seva ya kwanza. Kwa hiyo, soma jinsi ya kusimamia seva nyingi za Linux kabla ya kujifunga kwenye ada ya kila seva. Kwa nambari za msingi za kulinganisha pande zote mbili, gharama halisi ya VPS kwa mwezi huweka kiwango cha chini, na tofauti kati ya VPS na dedicated server huwa muhimu workload inapokuwa kubwa kiasi kwamba premium ya managed inakuwa ndogo sana kwenye jumla ya gharama.

Maswali ya kumuuliza mwenyeji kabla ya kulipia huduma ya managed premium

Uliza kabla ya kulipa, na uombe majibu yaandikwe. Ukurasa wa mauzo si hati ya mipaka ya huduma.

1. Ni mambo gani yako ndani ya huduma, kwa kila jukumu? Omba orodha, si brosha.
2. Je, support inahusu software ninayoweka, au ni software mliyoweka tu?
3. Je, mnafanya patching kiotomatiki, na mna-reboot kwa ajili ya kernel updates bila kuniuliza kwanza?
4. Nani anawajibika ikiwa patch mliyoweka inavuruga application yangu?
5. Je, mnafanya backups? Zinahifadhiwa wapi, zinatunzwa kwa muda gani, na ni nani anayefanya restore?
6. Je, hivi karibuni mmewahi kurestore server ya mteja, na ilichukua muda gani?
7. Muda wa kujibu ticket ni upi, na unatofautiana saa 03:00 siku ya Jumapili?
8. Je, ninabaki na root access, na kuitumia kunapunguza kiwango cha support mtakachotoa?
9. Je, ada inatozwa kwa kila server au kwa kila account?
10. Nikiondoka, ninaondoka na vitu gani? Setup iliyo ndani ya proprietary control panel inaweza kuwa vigumu ku-export.

Swali la 5 huamua majibu ya maswali mengine mengi. Mwenyeji anayejibu kwa usahihi anaonyesha kuwa amewahi kufanya restore hiyo. Jibu lisilo wazi linamaanisha kuwa restore haijawahi kujaribiwa, na backup ambayo haijajaribiwa ni copy tu. Swali la 5 pia lina upande wa location: mahali ambapo copies zimehifadhiwa kimwili ni suala la kisheria kama lilivyo la kiufundi, na kinachojalisha hasa unapochagua nchi ya hosting kinaeleza jambo hilo.

Njia ya kati: bila usimamizi wa mtoa huduma pamoja na automation

Wasomaji wengi wa kiufundi hawataki upande wowote uliokithiri. Wanataka mpango usio na managed support, huku kazi za kawaida zikifanywa na mashine na wao wakielekeza umakini kwenye mambo ambayo mashine haiwezi kutathmini. Weka usanidi huu siku ya kwanza. Dakika kumi za kwanza kwenye VPS mpya ni mwanzo wa kivitendo kwa mtu anayechagua huduma isiyosimamiwa, na kuimarisha ufikiaji wa SSH kunapaswa kufanywa katika session hiyo hiyo ya 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 inapaswa sasa kuwa na APT::Periodic::Update-Package-Lists "1"; na APT::Periodic::Unattended-Upgrade "1";. Faili ikiwa haipo, au ikiwa kuna 0 kwenye mstari wowote, hakuna kitakachoendeshwa na hutaarifiwa.

Ijaribu bila kubadili mfumo. Kumbuka kuwa package ni unattended-upgrades, lakini command iko katika umoja:

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

Output huorodhesha kila package iliyozingatiwa na kumalizia kwa 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 hiyo kagua hapo badala ya kukisia.

Masasisho ya kernel hayabadili chochote hadi mashine iwashwe upya, kwa sababu kernel inayoendelea kutumika ndiyo iliyopakiwa wakati wa boot. Faili /var/run/reboot-required huonekana reboot inapohitajika. Ama fuatilia faili hiyo, au acha mashine ishughulikie reboot katika /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. Hii ni salama zaidi kwenye mashine unayoitumia kwa maingiliano, lakini haina faida kwenye mashine ambayo hakuna mtu huingia. Usanidi kamili wa unattended upgrades kwenye Ubuntu unaeleza syntax ya blocklist na chaguo za email.

Monitoring inayoendeshwa mahali pengine

Monitor inayoendesha kwenye seva haiwezi kukujulisha kuwa seva iko chini, kwa sababu yenyewe pia iko chini. Weka check kwenye host ya pili au kwenye huduma ya nje. Uptime Kuma kwa monitoring ya hali ndiyo chaguo la kawaida la self-hosting, na inapaswa kuwekwa kwenye mashine tofauti na ile inayofuatiliwa.

Fuatilia vitu vinne kwa kiwango cha chini: upatikanaji, matumizi ya diski, ikiwa application inajibu kwenye port yake halisi, na muda wa kuisha kwa certificate. Diski ndiyo huwashtua watu. Log file au database inayokua kidogo kila siku inaweza kuangusha mashine wakati ambao hakuna kitu kingine kinachotabiri, na dalili ya kwanza mara nyingi huwa service inayoshindwa kuandika kisha kujizima.

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

Pia ongeza heartbeat. Timer kwenye seva huita URL baada ya kila backup au health check iliyofanikiwa, na monitor hutoa alert simu hiyo inapoacha kufika. Hivyo, seva iliyonyamaza hutengeneza alert yenyewe. Pull-only check haiwezi kufanya hivyo wakati njia ya mtandao ndiyo iliyoharibika.

Backups ambazo umewahi kurejesha 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 repository ambayo tayari ipo husababisha failure badala ya kuandika juu yake. Hii ndiyo tabia unayotaka. Hifadhi nakala ya passphrase hiyo nje ya seva. Repository haiwezi kusomeka bila passphrase 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 run uliyofanya sasa hivi pamoja na tarehe ya leo. restic check huthibitisha muundo wa repository na kuchapisha no errors were found. Sasa fanya hatua ambayo watu wengi huiruka:

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

Faili uliyotarajia ama ipo ama haipo. Kugundua hilo sasa kunachukua dakika kumi. Kisha weka run kwenye timer ili isikutegemee. 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 huonyesha run inayofuata na muda uliobaki. Matokeo matupu yanamaanisha uliwezesha service badala ya timer. Hili ndilo kosa linalotokea zaidi hapa. Persistent=true huendesha job iliyokosa baada ya boot inayofuata, kwa hiyo mashine iliyokuwa imezimwa usiku bado hupata backup yake. Restic backups kwenye VPS inaeleza zaidi kuhusu mpangilio wa repository na retention, na services na timers za systemd inaeleza unit files mstari kwa mstari.

Automation isiyokupatia nini

Haikupi uwezo wa kufanya maamuzi. Reboot ya kiotomatiki saa 02:00 hutokea bila kujali ikiwa application yako itarudi katika hali nzuri, kwa hiyo thibitisha kwamba kila service huanza yenyewe, kisha fanya reboot kwa makusudi ukiwa macho:

systemctl is-enabled nginx docker
sudo reboot

Unattended upgrade inaweza pia kusakinisha package inayoharibu application yako, na hakuna sehemu katika pipeline inayojua kwamba hilo limetokea. Monitor yako ndiyo hugundua hali hiyo. Ndiyo maana monitor si ya hiari tena masasisho yanapokuwa ya kiotomatiki. Mashine hushughulikia kazi za kawaida. Tukio bado ni jukumu lako.

Wakati managed inafaa kwa gharama yake

Tathmini chaguo la managed kwa usawa. Hali nne hulifanya liwe chaguo sahihi.

• Hakuna mtu kwenye timu anayeendesha Linux, na kuajiri mtu si mpango.
• Sharti la compliance linamtaja mhusika anayewajibika kuweka patches, na mhusika huyo huwezi kuwa wewe.
• Stack ni mojawapo ya zile ambazo host amebobea nazo, hivyo support yao imewahi kushughulikia failure kama yako.
• Mtu ambaye angefanya kazi hiyo ni mfanyakazi wako mwenye gharama kubwa zaidi, na saa moja ya kazi yake inagharimu zaidi ya mwezi mmoja wa premium.

Managed si salama zaidi kiotomatiki. Managed plans huweka patches haraka kuliko owner asiyejali, na hilo ni faida halisi. Pia mara nyingi husakinisha control panel, ambayo ni application kubwa inayokabili mtandao yenye ukurasa wa login na historia yake ya vulnerabilities. Hilo linaweza kuwa trade inayokubalika, lakini bado ni trade.

Uamuzi hutegemea orodha ileile kila mara. Andika tasks hizo kumi, weka alama ya anayemiliki kila task chini ya kila quote, kisha linganisha tofauti hiyo na thamani ya saa moja ya muda na umakini wako. Wasomaji wengi wa kiufundi wanaofanya hivyo huishia kuchagua unmanaged na kukabidhi routine kwa timer, na hilo ni jibu linaloweza kutetewa, si jibu la kuchagua kwa sababu ya bei ndogo.

FAQ

Kuna tofauti gani kati ya VPS inayosimamiwa na VPS isiyosimamiwa?

VPS isiyosimamiwa hukupa mashine pekee, bila huduma nyingine. Kwa hiyo, jukumu la patching, firewall, backups, monitoring na reboot baada ya kernel update linakuwa lako. VPS inayosimamiwa huhamisha sehemu ya kazi hiyo kwa provider, kwa kawaida safu ya mfumo wa uendeshaji na software aliyokusakinishia. Mipaka halisi huwekwa na kila provider, si na neno lenyewe. Kwa hiyo, omba maelezo ya maandishi ya kazi zinazojumuishwa kabla ya kulinganisha bei mbili.

Je, VPS inayosimamiwa inamaanisha kwamba sihitaji backups zangu mwenyewe?

Hapana. Backups za provider kwa kawaida hulinda image ya provider ya seva nzima na hutumika pale host inapofeli. Mara nyingi hazisaidii unapofuta file, kuendesha migration yenye hitilafu, au kuharibu data wiki kadhaa zilizopita na kugundua leo. Uliza snapshots huhifadhiwa kwa muda gani, kama file moja inaweza kurejeshwa, na ni nani anayefanya restore. Kisha hifadhi copy yako mwenyewe offsite kwa kutumia tool kama restic, na ijaribu kwa restic restore latest --target /tmp/restore-check ili uhakikishe inafanya kazi.

Je, VPS inayosimamiwa ni salama zaidi kuliko VPS isiyosimamiwa?

Si kwa sababu hiyo pekee. Mpango unaosimamiwa huweka patches haraka kuliko mmiliki ambaye haingii kamwe kwenye seva, na hilo hupunguza risk kwa kweli. Mipango mingi inayosimamiwa pia husakinisha control panel. Panel ni application kubwa inayokabili mtandao, yenye login page yake na historia yake ya vulnerabilities. Seva isiyosimamiwa iliyo na automatic security updates, firewall iliyofungwa, SSH inayotumia keys pekee, na hakuna huduma za ziada zinazosikiliza, huwa target ndogo kuliko seva inayosimamiwa inayoendesha panel.

Je, naweza kuanza na VPS isiyosimamiwa kisha nihamie kwenye inayosimamiwa baadaye?

Kwa kawaida ndiyo, ingawa mara chache huwa ni checkbox pekee. Providers kwa kawaida hukagua au hujenga upya seva kabla ya kuichukua kuwa jukumu lao, kwa sababu hawataunga mkono configuration ambayo hawawezi kuiona. Uliza onboarding inahusisha nini, kama inahitaji reinstall, na kama chochote ulichosanidi mwenyewe kitaendelea kuwa nje ya scope baadaye.

Je, nitaendelea kupata root access kwenye VPS inayosimamiwa?

Kwenye mipango mingi ya VPS inayosimamiwa, ndiyo. Hata hivyo, root access na scope ya support vina uhusiano. Baadhi ya providers hupunguza au kufuta support kwa component uliyoihariri mwenyewe. Wengine hujenga upya seva kwa kutumia template yao ikiwa ticket itahitaji uchunguzi wa kina. Pata kanuni hiyo kwa maandishi kabla ya kufanya tuning yoyote. Pia hifadhi configuration files zako kwenye version control ili rebuild ichukue saa moja badala ya wikendi nzima.