Virtuaalserver, VPS või pilveserver: mida teie veebileht tegelikult vajab

Virtuaalserver, VPS ja pilveserver näivad hinnakirjas kolme võimsusastmena, aga erinevad kolmes kohas: mis teid naabritest samal masinal eraldab, kus konto piir vastu tuleb ja kes tarkvara uuendab.

Kolmapäeva hommikul kümne paiku muutub veebileht aeglaseks — mitte surnuks, ainult aeglaseks: leht avaneb viie sekundiga, halduspaneel keeldub kirjet salvestamast ja poole tunni pärast on kõik jälle korras, nagu midagi poleks juhtunud. Majutaja klienditugi vastab pärast lõunat, et konto on ületanud oma paketi piiranguid, ja pakub üleminekut järgmisele astmele, mis maksab kolm korda rohkem ja kannab hinnakirjas nime „pilveserver“.

Sel hetkel ei tea enamik ostjaid, mida nad täpselt ostavad, ja see ei ole etteheide: virtuaalserver, VPS ja pilveserver on hinnakirjas seatud üksteise alla nagu kolm võimsusastet ühele ja samale teenusele, kuigi need on kolm eri tehnilist lahendust, mis erinevad kolmes konkreetses kohas. Igaüht neist kolmest kohast saate kontrollida oma veebilehe arvudega käes, ja ühtegi neist ei saa paketi nimest välja lugeda.

Kolm kohta, milles paketid tegelikult erinevad

Esimene on isolatsioon, see tähendab, mis täpselt eraldab teie veebilehe teiste klientide veebilehtedest samal füüsilisel masinal. Virtuaalserveris on see konto operatsioonisüsteemis koos tuuma tasemele pandud ressursikonteineriga, VPS-i puhul eraldi virtuaalmasin oma operatsioonisüsteemiga, pilveserveris aga sama virtuaalmasin, ainult teisiti tellitud ja teisiti arveldatud. Praktiline vahe nende kolme variandi vahel on selles, kui palju naabri koormus teie veebilehte mõjutada saab ja kui palju masinast te üldse tohite muuta, kui selgub, et vaikeseadistus teile ei sobi.

Teine koht on piirang: kus konto vastu tuleb ja kuidas see välja paistab. Just siin tekib kõige rohkem arusaamatusi, sest inimesed ootavad, et ülekoormus tähendab aeglast lehte, kuigi osal juhtudel tähendab see lehte, mis ei avane üldse ja tagastab veakoodi, mida ostja oma elus kordagi näinud ei ole. Kolmas koht on vastutus: kes uuendab operatsioonisüsteemi, kes veebiserverit, kes PHP-d ja kes veebilehte ennast. Just siin arvavad VPS-i ostjad kõige sagedamini mööda, sest root-ligipääs ei ole kingitus, mille majutaja võimsama masinaga kaasa annab — see on kohustuste nimekirja üleminek temalt teile, ja see toimub vaikselt, samal minutil, kui parool teele pannakse.

Kõik ülejäänu, mis veebimajutuse võrdlustabelis ridu täidab, on kas kõigis pakettides ühesugune või ei ole see, mis vastu ei pea: NVMe-kettad on täna peaaegu kõikjal, aga „piiramatu andmeedastus“ on väide edastatud andmemahu, mitte ressursside kohta, ja see seisab tavaliselt täpselt selle tabeli kõrval, milles ressursid on viimase megabaidini kokku loetud. 99,9% on omakorda arv täpse juriidilise tähendusega ja erandite nimekirjaga selle all, ning suurem osa ostjaid arvab, et see katab midagi hoopis muud, kui see tegelikult katab.

Virtuaalserver: üks server, paljud kontod

Virtuaalserver on kasutajakonto masinal, kus elab veel sadu samasuguseid kontosid, ja Eesti majutajad nimetavad seda toodet kahel viisil: Zone kirjutab „veebimajutusteenus (virtuaalserver)“, Veebimajutus.ee pealkirjastab selle Virtuaalserveriks. Tehniliselt tähendab see mõlemal juhul sama kokkulepet — teile kuulub konto, mitte masin, veebilehte haldate cPaneli või sarnase paneeli kaudu, ja kõik, mis jääb selle paneeli alla, kuulub kellelegi teisele.

Mis teid naabritest eraldab, on konkreetne tarkvara, mitte lubadus hinnakirjas, ja seda tasub nimepidi tunda. Enamik cPaneli majutajaid töötab CloudLinuxil, milles igal kontol on oma failisüsteemi koopia: CloudLinuxi dokumentatsioon CageFS-i kohta kirjutab, et kasutajad ei saa teisi kasutajaid ega nende kasutajanimesid serveris näha ega tuvastada, ei saa veebiserveri seadistust lugeda ja näevad ainult kärbitud protsesside nimekirja. Teine kiht on LVE — tuuma taseme ressursikonteiner, mis määrab igale kontole protsessori, mälu, sisend-väljundi ja protsesside piirangud just selleks, et, nagu dokumentatsioon ise sõnastab, ükski üksik veebileht ei saaks kogu veebiserverit maha võtta.

Kolmas kiht on PHP-seadistus open_basedir, ja selle kohta tasub teada, mida ütleb PHP käsiraamat ise, mitte majutaja turundus: see on täiendav turvavõrk, mis ei ole mingil juhul kõikehõlmav ja millele ei saa tugineda siis, kui turvalisust tegelikult vajatakse. Sealtsamast hoiatab käsiraamat, et ka funktsioonide väljalülitamist disable_functionsiga saab mööda minna ja et jagatud keskkonnas ei ole see piisav turvameede. Midagi sellest ei ole argument virtuaalserveri vastu; see on argument selle kasuks, et isolatsiooni annavad siin tuum ja failisüsteem, mitte üks rida seadistusfailis, ja et majutaja, kes isolatsiooni küsimusele vastab sõnaga „turvaline“, ei ole sellele vastanud.

Mida virtuaalserveris valida ei saa, on sama tähtis kui see, mida saab: tuum on kõigile kontodele üks, seega tuumaversiooni te ei muuda, PHP versioonide nimekirja määrab majutaja ja see jääb tavaliselt uusimast ühe või kahe versiooni võrra maha, veebiserver on aga selline, nagu on paigaldatud, seega küsimusele paketi kohta, mida seal ei ole, on vastus „ei“, mitte „paigaldage“. Jagatud server on ka koht, kus intsidendi korral peab majutaja naaberkontod üle kontrollima, sest ründaja, kes on ühte kontosse pääsenud, proovib sama naabritega; mida teha, kui see on juba juhtunud, oleme kirjeldanud artiklis häkitud WordPressi veebilehest. Ükski neist piirangutest ei ole puudus: see on täpselt see kokkulepe, mis teeb selle toote odavaks, ja ostja, kes sellest aru saab, saab sellest kasu.

Mis juhtub, kui konto tuleb vastu oma piirile

Virtuaalserveri paketil on mitu eri otsa, need saavutatakse üksteisest sõltumatult ja paistavad täiesti erinevalt välja, seega on sümptom kasulik diagnostikavahend. CloudLinuxi vaikimisi piirangud ühe konto kohta on 100% ühest protsessorituumast, 1 GB füüsilist mälu, 1024 KB/s sisend-väljundit, sada protsessi ja kakskümmend entry processes'it, ja just viimane arv ostjaid üllatab, sest kakskümmend kõlab naeruväärselt väikese arvuna veebilehele, mis saab kuus kümme tuhat külastajat.

Seletus on selles, et entry process ei ole külastaja: see on protsess, mis tuleb kontosse väljast — uus HTTP-päring PHP-skriptile, SSH-seanss või croni töö, samas kui protsessid, mis tekivad juba sees, loetakse hoopis teise piirangu alla. Kui entry processes'ite arv on täis, ei lase Apache'i moodul järgmist päringut enam sisse ja tagastab vea 508 Resource Limit Reached, ning CloudLinux kirjeldab seda teadmusbaasis pehmendusteta: veebileht, mis tarbib liiga palju ressursse, lakkab töötamast, ülejäänud kliendid samal serveril töötavad aga edasi nagu tavaliselt. Täpselt see ongi selle mehhanismi mõte — lõigata ära üks konto, et masin ei seisaks.

Ülejäänud piirangud paistavad teistmoodi, ja sümptomist saab välja lugeda, milline täpselt on saavutatud, enne kui keegi hakkab arvama: protsessorit ja sisend-väljundit ei lõigata ära, vaid pidurdatakse, seega muutub leht aeglaseks ja avaneb lõpuks, mälu- ja protsessipiirangud annavad tavaliselt 500 või 503, see tähendab lehte, mis ei avane üldse. LiteSpeed-serveritel loetakse entry processes'eid teistmoodi kui Apache'il, seega ei tohi seal seda sama arvu tõlkida samaaegsete külastajate arvuks, ja see on üks sagedasemaid viise, kuidas õige arv satub valesse lausesse.

On veel neljas ots, millel koormusega üldse pistmist ei ole ja mis seepärast hiilib ootamatult ligi: inode on failisüsteemi kirje ühe faili või kausta kohta, seega on inodede arv kontos lihtsalt failide ja kaustade arv, kaasa arvatud postkast, mida keegi aastaid tühjaks ei ole teinud. Läti majutaja Hostnet avaldab inodede arvu hinnakirjas avatult — MINI paketis 400 000, PLUS 600 000, PRO 800 000 — ja samas tabelis seisavad MINI ja PLUS kõrval 100% ühest tuumast ja 2048 MB mälu, PRO-l 200% ja 3072 MB, pealegi kõigil kolmel 10 MB/s sisend-väljundit ja 150 samaaegset ühendust, samal ajal kui kuu andmeedastus on „piiramatu“. See kooslus on õige õppetund sõna „piiramatu“ kohta veebimajutuse hinnakirjas: see käib edastatud andmemahu kohta, ja kõik ülejäänud piirangud seisavad sealsamas kõrval, viimase arvuni kokku loetud.

VPS: oma operatsioonisüsteem jagatud raua peal

VPS on virtuaalmasin, milles teile kuulub operatsioonisüsteem, root-ligipääs ja võimalus paigaldada see, mida vaja, ja turul kirjutatakse seda nii lühendina kui lahti: VPS ehk Virtual Private Server. See, mida see nimi ei ütle, on kaks tehnilist küsimust, mis otsustavad, kui palju „oma serverist“ tegelikult teie oma on.

Esimene küsimus on, kas virtualiseerimine on riistvara või operatsioonisüsteemi tasemel. KVM on Linuxi tuuma moodul, mis kasutab protsessori virtualiseerimislaiendusi ja annab igale külalisele oma virtualiseeritud riistvara — võrgukaardi, ketta, videoadapteri — ja mis peamine, oma tuuma, seega saab sellel käitada ka muutmata Windowsi. LXC ja sellega seotud konteinerid on teine mehhanism: need kasutavad Linuxi nimeruume, cgroups'e ja õiguste piiramist, et luua keskkond, mis on võimalikult lähedane eraldi Linuxi paigaldusele, ent ilma eraldi tuumata. Tagajärg on lihtne ja praktiline — konteineris jäävad tuumaversioon, tuumamoodulid ja tuuma turvanõrkused peremeesmasinaga ühiseks, seega jäi osa sellest, mida te arvasite ostvat, tegelikult naabritele.

Teine küsimus on protsessori kohta, sest sõnad „oma server“ ei tähenda oma protsessorit. Hetzneri pilveserveritel on kaks eraldi tootesarja: jagatud ressursside pakettides jaotatakse arvutusressursid kõigi instantside vahel samal füüsilisel serveril baasjõudlusega ja võimalusega seda ajutiselt ületada, eraldatud ressursside pakettides on üks vCPU üks füüsilise tuuma lõim ja ainult teie oma. DigitalOcean sõnastab selle veel selgemalt: jagatud paketis võib lõim olla teistega jagatud, ja kui naabritel on suur koormus, saab instants lõime osi, mitte täielikku ligipääsu, nii et praktikas on täielik ligipääs võimalik, aga ei ole tagatud.

Kui palju naabreid ühel masinal on, ei avalda ükski suur teenuseosutaja, ja suhe, mille te ajaveebidest leiate, ei ole kellegi avaldatud mõõtmine, seega ei tasu seda ei tsiteerida ega uskuda. Ainus dokumenteeritud suurus, millele saab tugineda, on see, kas pakett lubab jagatud või eraldi ressursse, ja see vahe on tavaliselt kirjutatud päris avatult — kahe eri tootenime, kahe eri spetsifikatsiooni ja hinnavahega, mis on mitmekordne.

Pilveserver on sama VPS, ostetud teisiti

Pilveserver on tehniliselt virtuaalmasin hüperviisoril, see tähendab täpselt sama mis VPS, ja nii seletavad seda ka teenuseosutajad ise: CloudHosting kirjutab oma küsimuste jaos, et cloud server ehk pilveserver on virtuaalmasin, ja Hetzneri dokumentatsioon algab sama lausega — pilveserverid on virtuaalmasinad, mis töötavad füüsilistel serveritel. Kui te kahelt pakkumiselt ootate eri riistvara, ei ole ootusel alust.

Vahe ei ole riistvaras, vaid ostmise viisis, ja seda kirjeldab kõige täpsemalt USA standardiameti NIST määratlus, mida valdkond endiselt tsiteerib: pilvel on viis tunnust — iseteenindus nõudmisel, ligipääs võrgu kaudu, ressursside koondamine mitme rentnikuga, kiire elastsus ja mõõdetud tarbimine. Praktikas tähendab see API-d, millega masina saab luua ja lammutada programmiliselt, tunnipõhist arveldust kuu ülempiiriga ja lisadetaile, mida saab eraldi külge ühendada: snapshot'e, eraldi plokksalvestit, teisaldatavat IP-aadressi ja koormuse tasakaalustajat.

Igal neist detailidest on piirid, mida tasub teada enne ostu, mitte kuu aega pärast seda. Hetzneri paketi vahetus ei saa ketta suurust vähendada ka siis, kui sellest on kasutusel ainult osa; pärast ketta suurendamist tuleb partitsioon ise päästerežiimis laiendada, ja paketi vahetus ise on loetletud käideldavuse garantii erandina. Snapshot omakorda ei ole varukoopia, kuigi turul kasutatakse mõlemat sõna sünonüümidena: Hetzneri snapshot'idesse ei kuulu juurde ühendatud köited, ja järjepidevust ei tagata, kui server töötab, seega on see hea asi enne uuendust ja halb asi ainsa andmekoopiana. Teisaldatav IPv4-aadress maksab eraldi, nagu ka peamine IPv4-aadress instantsi enese juures.

Viie leheküljega ettevõtte veebilehel ei kasutata neist detailidest tavaliselt ühtegi, ja see on selle jao ausaim lause: kui veebileht ei muuda kunagi võimsust, ei lülitu kunagi teisele masinale ega ühendu kunagi API-ga, on pilveserver ja sama suurusega VPS üks ja sama masin kahe eri arvega. See ei ole argument pilve vastu, sest seal, kus elastsust kasutatakse, maksab see vähem kui püsivalt hoitud varu. See on argument selle kasuks, et valik on võimaluste vahel, mida te tegelikult kasutate, mitte sõnade vahel, mis kõlavad moodsana.

Kes uuendab mida

Suurim praktiline vahe kolme paketi vahel ei ole kiirus, vaid kohustuste jaotus, ja kõige selgemalt on selle sõnastanud pilveteenuse osutajad ise. AWS-i jagatud vastutuse mudel jagab kõik kaheks: pilve turvalisus on AWS-i vastutus — riistvara, tarkvara, võrk ja ruumid, milles teenused töötavad, aga turvalisus pilves on kliendi vastutus. Paikade küsimuses on see kirjutatud eraldi ja sõna-sõnalt: AWS vastutab taristu paikade ja defektide eest, klient vastutab oma külalise operatsioonisüsteemi ja oma rakenduste paikade eest.

Virtuaalserveris kuulub see kiht majutajale, ja see on selle toote suurim väärtus, millele harva keegi mõtleb: tuuma, veebiserverit ja PHP-d uuendavad nemad, ja teie ei tea sellest midagi, kuni miski katki ei lähe. Isehallatavas VPS-is või pilveserveris läks see kõik teile üle koos root-parooliga, ja Hetzner ütleb seda oma tingimustes ka teiselt poolt: tarkvara, seadistus ja süsteemiseaded, mille klient sisse viib, ei loeta käideldavuse häireks, seega nende eest ei vastuta teenuseosutaja ja need ei kuulu ühegi hüvitise alla.

Veebileht ise jääb teie vastutusele kõigil kolmel juhul, ja see on punkt, milles pakkumisi tuleb lugeda tähelepanelikult, sest sõna „hallatav“ tähendab valdkonnas tavaliselt operatsioonisüsteemi ja serveritarkvara, mitte WordPressi tuuma, pistikprogramme ja teemat. Ka meie enda taristu rendi hooldusse kuuluvad operatsioonisüsteemi ja serveritarkvara uuendused, turvaseadistus, varukoopiad kontrollitud taastamisega, monitooring ja reageerimine SLA järgi — ja seal ei ole kirjas, et me uuendame teie pistikprogramme, sest see on teine rida hinnakirjas ja teine leping, ja me ütleme seda selgelt, et keegi ei avastaks seda piiri intsidendi päeval.

Praktiline test enne tellimust on üks küsimus, esitatud otse ja kolme osaga: kes uuendab operatsioonisüsteemi, kes veebiserverit ja PHP-d, ja kes veebilehe koodi. Kui vastus mõnele neist kolmest on „teie ise“, on see töö, milleks on vaja kas inimest ajaga või lepingut kellegi teisega, ja kumbki ei ole tasuta. Vastamata see küsimus ei kao — see tuleb kaheksateistkümne kuu pärast tagasi süsteemina, millesse ei ole keegi pannud ühtegi paika, ja siis ei ole see enam paketi valiku küsimus.

Mida tähendab 99,9% ja mida see ei kata

Käideldavuse protsent hinnakirjas näeb välja lubadusena, aga tegelikult on valem erandite nimekirjaga. Hetzneri pilveserverite teenusetaseme kokkulepe lubab 99,9% kuus ühe instantsi kohta, ja Hetzner ise arvutab oma seletuses välja, mida see arv praktikas tähendab: kolmekümnepäevases kuus on 43 minutit seisakut endiselt kokkuleppe piires, see tähendab, et see ei ole rikkumine ja selle eest ei ole ette nähtud mingit hüvitist.

Hüvitis ise on sama konkreetne ja palju väiksem, kui inimesed ootavad: see arvutatakse lävest üle jäävatest minutitest, teisendatakse tundideks ja korrutatakse instantsi tunnihinnaga, ning makstakse välja krediidina edasise tarbimise vastu, mitte rahana. Hetzneri enda näites annab 185-minutiline seisak 142 minutit üle läve ehk 2,37 tundi ja krediidi 0,87 €, mis on vähem, kui maksab tund tööd selle väljaarvutamiseks. Tagasi saamata käive, kaotatud tellimused ja kukkunud positsioonid otsingutulemustes ei kuulu sinna kuhugi, ja ükski veebimajutuse kokkulepe, mida oleme lugenud, neid ei kata.

Erandite nimekiri on sama tähtis kui arv, sest just see määrab, kui sageli seda arvu üldse kohaldatakse: kokkuleppest jäävad välja ette teatatud hooldus, kliendi enda tarkvara ja seadistus, kliendi nõutud paketi vahetus, live-migratsioonid peremeesmasina stabiilsuse pärast ja võrk teenuseosutaja põhivõrgust väljas. See kõik on kirjutatud ausalt ja avatult, ja sellest järeldub lihtne järeldus: protsent käib masina, mitte teie veebilehe kohta, seega veebileht, mis kukkus pärast ebaõnnestunud uuendust, on sellest lepingust täielikult väljas.

Pealegi ei ole 99,9% valdkonna konstant, kuigi seda kasutatakse sageli nii, nagu oleks. Amazoni EC2 kokkulepe lubab ühe instantsi kohta 99,5%, aga 99,99% ainult siis, kui instantsid on paigutatud vähemalt kahte saadavustsooni, see tähendab, et need on kaks eri lepingut kahe eri arvuga, ja lause „valdkonnas on 99,9%“ surub need mõlemad üheks. Virtuaalserveris sellist dokumenti tavaliselt üldse ei ole — on ainult arv veebilehel ilma määratluse, mõõtmismeetodi ja tagajärgedeta, ja see on väide, mitte siduv kohustus.

Kuidas veebileht enne valikut ära mõõta

Arv, mis otsustab, ei ole külastajate arv kuus, kuigi just selle ostja peast teab ja just seda müüja esimesena küsib. Otsustab samaaegsete PHP-päringute arv hetkel, kui koormus on kõige suurem, ja see on hoopis teine suurus, mis kuu külastatavusega korreleerub nõrgalt.

Kaks veebilehte ühesuguse külastatavusega võivad asuda ühe ja sama piirangu eri pooltel, ja vahe on selles, kui kaua iga leht protsessi kinni hoiab. Staatilist, vahemällu pandud ettevõtte veebilehte teenindab enamasti veebiserver ilma PHP-ta, seega ei tarbi see entry processes'eid peaaegu üldse ja kümme tuhat külastajat kuus ei tähenda sellele midagi. E-pood, milles iga ostukorv, iga sisselogimine ja iga naasmine makseväravast hoiab PHP-protsessi kaks sekundit, võib sama piirangu saavutada juba kahekümne samaaegse ostja juures, ja just seepärast kukuvad kampaania esimesel tunnil need poed, kes kampaania on kinni maksnud.

Koos selle arvuga tasub lugeda veel kolm, ja kõik kolm on kättesaadavad ilma arendaja abita. Esimene on andmebaasi suurus ja aeglasim päring selles, sest just see on tavaliselt tõeline aeglusepõhjus, mitte masina võimsus. Teine on failide arv kontos, sest inodede piirangu saavutavad suured meediateegid ja vana postkast ootamatult ja ilma hoiatuseta. Kolmas on see, mida veebileht teeb väljaspool brauserit — croni tööd, posti saatmine, liidestused raamatupidamissüsteemiga, sest ka need protsessid tulevad kontosse väljast ja loetakse samasse piirangusse, mille te just ostjate jaoks ära mõõtsite.

Kõik neli arvu on ühe pärastlõunaga loetavad majutuspaneeli statistikast ja serveri logidest, ja see on ainus koht, kus on teie veebilehe tegelik koormus, mitte oletus sellest. Paketi nimi neid arve ei tea, müüja, kes neid näinud ei ole, samuti mitte, ja vestlus, mis nendega algab, lõpeb tavaliselt odavama vastusega kui vestlus, mis algab pakettide nimekirjaga.

Millal üleminek aitab ja millal ei lahenda midagi

Üleminek suuremale paketile on õige vastus tunduvalt harvem, kui seda pakutakse, ja esimene juhtum, kui see ei aita, on ka kõige sagedasem. Kui veebileht on aeglane sellepärast, et üks päring loeb kogu toodetetabeli igal lehe avamisel, täidab võimsam masin selle kiiremini, probleem jääb, ja te olete ostnud aega, mitte lahendust. Sama kehtib neljakümne pistikprogrammi, töötlemata originaalsuuruses piltide ja teema kohta, mis igal päringul ehitab menüü nullist.

Üleminek on õige vastus siis, kui piirang on saavutatud korrektse koodiga: kui veebileht on vahemälus, päringud on korras ja konto tuleb ikka vastu entry processes'ite arvule, on see paketi piirang, mitte defekt koodis, ja rohkem optimeerida ei ole midagi. Samuti on üleminek ainus vastus siis, kui on vaja midagi, mida jagatud kontosse paigaldada ei saa — teine PHP versioon, järjekorratöötleja, Redis, oma cron minuti sammuga — või kui valdkonna, hanke või kliendi nõue määrab, millises riigis andmed füüsiliselt asuvad.

On ka kolmas juhtum, millest müüjad räägivad harva, sest see vähendab arvet: mõnikord on õige liikumine allapoole. Veebileht, mis kolm aastat tagasi tõsteti VPS-ile ühe reklaamikampaania pärast ja saab sellest ajast kakssada külastajat päevas, maksab masina eest, mida ei kasuta, ja maksab kaks korda — rahaga arvel ja inimese ajaga, sest VPS-i operatsioonisüsteemi peab keegi uuendama ka siis, kui sinna keegi sisse ei tule.

Enne mis tahes ümberkolimist tasub lahendada veel üks küsimus, millel võimsusega üldse pistmist ei ole: kelle nimele on domeen registreeritud ja kelle nimele on majutuskonto. Sellest kirjutasime eraldi artiklis vigadest veebilehe tellimisel, ja see on üks neist küsimustest, mida migratsiooni päeval enam kiiresti korda ei saa, sest vastus sõltub inimesest, kellega te ehk enam ei räägi.

Mida te ostate, kui pakett kannab nime hallatav

Hinnavahe isehallatava ja hallatava masina vahel on suur, ja see ei ole juurdehindlus ühe ja sama kauba peale, seega on aus panna mõlemad arvud kõrvuti. Hetzneri hinnakirjas, mis jõustus 2026. aasta 15. juunil, maksab CX23 pilveserver kahe vCPU, nelja gigabaidi mälu ja 40 GB kettaga 5,49 € kuus ilma käibemaksuta, ja peamine IPv4-aadress tuleb sellele otsa 0,50 € kuus. Meie hallatav veebimajutus algab 45 € kuus, ja vahe nende kahe arvu vahel on täpselt see, millest see jagu on.

Vahe on töö, ja seda saab üles lugeda ühekaupa: operatsioonisüsteemi ja serveritarkvara uuendused, turvaseadistus, monitooring Zabbixiga ööpäev läbi ja reageerimine SLA järgi, varukoopiad iga päev 30-päevase säilitamisega ja regulaarselt kontrollitud taastamisega, eriti kriitilise taristu puhul — kuni 365 päeva ja kahes eri Euroopa Liidu riigis. Keskkonna ettevalmistus ja ümberkolimine võtavad 3–10 päeva, migratsiooni teeme paralleelselt ja DNS-i lülitame planeeritud aknas, ning pärast seda on teil üks vastutav kontakt, mitte tugipilet teises ajavööndis.

Ausalt tuleb öelda ka teine pool, sest ilma selleta oleks see jagu hinnakiri artikliga ümber. Kui teie veebileht on staatiline, külastus väike ja keegi ei küsi kunagi PHP versiooni, mida majutajal ei ole, on virtuaalserver mõne euroga kuus õige vastus, ja hallatav keskkond oleks tasu meelerahu eest, mis teil niigi on. Me ütleme seda ka neile, kes selle küsimusega helistavad, sest müüa keskkonda, mida ei kasutata, on lühiajaline tehing — aasta pärast tuleb see tagasi küsimusena, mille eest tegelikult maksti, ja sellele ei ole head vastust.

Kui te ei ole kindlad, kummal pool seda piiri teie veebileht on, saab need neli arvu koos läbi lugeda: kirjutage meile, ja me ütleme, mida teie praeguse konto statistika näitab ja milline piirang on teile lähim — ka siis, kui vastus osutub, et kolida ei ole mingit vajadust ja raha on parem panna veebilehe kiirusesse.