Uus arendajasõbralikum veebilogide haldamise kord

Veebiserveri logide haldamise kord on Zone tarkvaraplatvormis läbimas ulatuslikku reformi, mis loob meie arendajatest klientidele uusi väärtuslikke võimalusi. Käesolevas blogipostis kirjutan uuest korraldusest lähemalt.

Uue korra kohaselt on Virtuaalserveri teenuse kliendi käsutuses reaalajas uuenevad veebiserveri logid. Kui varasemalt uuenes reaalajas vaid probleemide tuvastamiseks vajalik vealogi (Error Log) ning päringute logi pakkusime arhiivina, siis nüüdsest on klientide käeulatuses reaalajas uuenev päringute logi (Access Log).

Veebiserveri logid leiab klient Virtuaalserveri ‘logs’ kataloogist. Logimisel tehakse vahet turvamata ja turvatud ühendustel, mis salvestatakse eraldi failidesse (apache.ssl.access.log ja apache.access.log).

Virtuaalserveri alamdomeenide vea- ja päringulogid kombineeritakse peadomeeniga. Päringuid on võimalik logis üksteisest eristada sedaläbi, et iga rida algab seda konkreetset päringut teenindanud hosti nimega.

Veebiserveri logi kirje formaat põhineb Apache Combined Log’il. Kasuliku ja unikaalse lisavõimalusena paneme me PHP päringute puhul logisse kirja ka selle unikaalse identifikaatori ning PHP koodi töötlemisele kulunud aja (‘wallclock’ sekundites). Need aitavad arendajatel oma rakenduste jõudlust paremini monitoorida ning meil ühiselt probleeme ‘troubleshoot’-ida.

Juhin tähelepanu asjaolulule, et logiridade kronoloogiline järjestus ei ole absoluutne – aeglasemad päringud võivad järjestuses sattuda oma noorematest, kuid kiirematest sõsaratest tahapoole.

Logisid roteeritakse endiselt Zone poolt, kuid vaikimisi säilitatakse kliendi Virtuaalserveris nüüd viimase nelja päeva logisid. Need asuvad failides mille nimed on kujul apache.ssl.access.log.[1-4].gz. Eelmise päeva logi on seega alati failis apache.ssl.access.log.1.gz.

Kui kliendil on soovi oma logisid arhiveerida, siis on tal võimalik neid endale kopeerida enda seadistatud crontab’i töö abil.

Alates PHP versioonist 7.0 logitakse meil sarnasel printsiibil ka PHP tegevust. Varasematesse PHP versioonidesse sellist logimise tuge meil ei tule, seega on viimane aeg PHP ‘retro’ versioonidest loobuda.

Vana korra järgi seadistatud klientidel on võimalik uuele logide kasutuskorrale üle minna vabatahtlikult Virtuaalserveri seadistuses tehtava valiku kaudu.

Uue logide haldamise korra opt-in

Ühel hetkel lõpetame vana korra toetamise ära, kuid see ajakava ei ole veel paigas.

UPDATE: Tasub veel ära mainimist, et muutunud on ka Apache vealogide (ErrorLog) nimetused on nüüd apache.error.log ja apache.ssl.error.log. Nende roteerimise kohta kehtib kõik ülaltoodu.

Brexiti ohvriks võib langeda üle 300 000 domeeni

Seal kus kohtuvad poliitikud ja internet, hakkavad reeglina laastud lendama. Seekord pillub pilpaid laiali protsess nimega “Brexit”.

Hetkest, mil keskmine Suurbritannia valija otsustas end Euroopa Liidu küljest lahti haakida ning saareriigi vööri ulgumere poole keerata, tekkis paljudel eurooplastest internetihuvilistel küsimus, mis saab brittide poolt registreeritud EU-lõpulistest domeeninimedest? Aluseks asjaolu, et Euroopa Komisjoni regulatsiooni Nr 733/2002 artikli 4(2)(b) järgi võivad .EU domeene registreerida vaid isikud, kes resideeruvad Euroopa Liidus.

Sel nädalal on Euroopa Komisjon otsustanud selleteemalistele oletustele lõpu teha. Nimelt on komisjon välja andnud kommünikee (https://ec.europa.eu/info/sites/info/files/notice_to_stakeholders_brexit_eu_domain_names.pdf), milles väljendatakse seisukohta, et Suurbritannia lahkumise järel Euroopa Liidust, 30. märtsil 2019, ei ole brittidel enam õigust registreerida või pikendada .EU domeeninimesid.

Brexit

Kui otsus puudutaks vaid uute domeenide loomist, oleks olukord küllalt sirgjooneline, kuid komisjon ütleb selgelt, et mõjutatud on ka eksisteerivad domeenid, mida samuti enam pikendada ei tohi. Britid va võrukaelad on aga registreerinud kõvasti üle 300 000 EU-lõpulise domeeninime, mis moodustab ca 8% kõigist .EU domeenidest. See on märkimisväärne number.

Mida brittidel selles olukorras teha, kus nende ettevõtte või organisatsiooni interneti-identiteet käest võetakse?

Esimene ja robustseim variant on kiiresti loobuda .EU domeeninime kasutamisest, kaks aastat on piisavalt pikk periood mille jooksul on võimalik uus identiteet edukalt kehtestada. Kui otsus tehtud, siis venitamine ei oleks kindlasti kasulik, kuna uue domeeninimede leitavusel ja usaldusväärsusel otsingumootorite silmis on kuuldavasti ka ajaline mõõde.

Teine variant on leida endale Euroopast partner, kelle nimele domeen ümber registreerida. On täiesti kindel, et sellist teenust on peagi valmis pakkuma nii mõnedki advokaadibürood või registripidajad.

Kolmas variant on oodata ja kannatada, sest poliitikutele kohaselt on komisjon loomulikult endale lahti jätnud taganemistee – otsust võivad mõjutada edasiste läbirääkimiste käigus sõlmitavad lepped. Ei ole sajaprotsendiliselt välistatud, et läbirääkimiste käigus astutakse suuremeelselt mõned sammud tagasi.

Neljas variant on pikendada oma domeen kohe 10-ks aastaks ära ja siis rahulikult oma võimalusi kaaluda. Isiklikult on mul raske ette kujutada, et domeene, mis on kümneks aastaks pikendatud, hakataks enne registreerimisperioodi lõppu kustutama.

Jätkame huviga kujuneva olukorra jälgimist.

Miks mu veeb aeglane on? Vaata BlackFire abil järgi!

Enamus “server on aeglane” hädadest osutub lähemal uurimisel veebirakenduse koodi probleemideks – suur hulk andmebaasipäringuid, välise teenuse järel ootamine, ebaefektiivne tõlkelahendus vms.

Kuidas aga see kitsaskoht üles leida?

Esimene samm: väline monitooring

Minul on kombeks kõiki jõudlusprobleeme asuda lahendama kõige lihtsamast veebilehe monitooringust: pingdom.com teeb iga minut veebipäringu, joonistab vastamiseks kulunud ajast graafiku ning saadab e-postile teavituse, kui saab vea või vastus liiga kaua aega võtab*.

Kuvades lehtede või toodete lisandumisel kuude jooksul aeglasemaks muutuvat rakendust, võib tulemus olla näiteks selline:

Suur hulk probleeme on aga “jalutavad” – ehk enamiku ajast töötab veeb kiiresti, mingite sündmuste koosmõjul läheb aga aeglaseks:

Teine samm: mis toimub koodis?

Veebirakendustel on probleemide leidmiseks sageli omad lisad või pluginad, nt WordPressi puhul aitab Query Monitor kiiresti üles leida probleemsed andmebaasipäringud.

Visuaalsema pildi toimuvast annab aga BlackFire, mille PHP-laienduse saab Zone Virtuaalserveri puhul hõlpsalt sisse lülitada ja oma BlackFire kontoga siduda, kohaks Veebiserver » Seaded » Muuda » PHP laiendused:

Võrreldes rakenduste pidevaks monitooringuks mõeldud teenustega (nt NewRelic, mille saab meil muideks samast kohast aktiveerida) on BlackFire probleemide tuvastamise rollis oluliselt mõistlikuma hinnastusega – 19,90€ eest kuus saab endale “profileerija” konto, mida arendaja saab vabalt kasutada kõigi oma töös olevate (või ootamatult sisse sadavate) projektide puhul.

Kõige lihtsam viis profileerimiseks on Chrome laiendus – kui serveri poolel seadistus tehtud, lähed huvipakkuvale (alam)lehele ja vajutad nuppu. BlackFire kogub serveri poolel inffi ja saadab selle oma teenusesse, kus saad tulemust soovi korral teiste asjaosalistega jagada, näiteks nii.

Kuidas aga saadud tulemust lahti mõtestada? Võtame (anonüümselt) ette mõned reaalse elu juhtumid ja vaatame, kuidas probleemi otsimine käib. Alustuseks üks veeb, mis võiks vabalt olla Pingdomi juures mainitud “jalutava probleemi” graafikul kuvatu.

Probleem 1: veeb ootab välise päringu taga

Esimese asjana vaatan ma ülemist rida. Sedapuhku torkab kohe silma pea 3 sekundit, mis kulunud http-päringutele mingite väliste süsteemide pihta. Probleeme tekitav funktsioon on parempoolsel graafil kenasti punane ja sellele klikkides kuvatakse ka lisa-infot – kes teda kutsus, mida funktsioon tegi ja kelle poole edasi pöördus.

Sedapuhku kulub igal lehekuvamisel aega välise CRM-teenuse peale, kust kahel korral http-päringuga mingit infot laetakse. On seda infot ikka hädasti vaja? Miks tehakse kaks päringut? Miks see teenus aeglane on? Kas oleks võimalik vastust puhverdada? Kas selle päringu võiks teha kasutaja brauser pärast ülejäänud lehesisu laadimist?

3-sekundiline lehelaadimine on aga vaid väike osa probleemist – kui seda teeb server, kuhu külastajaid satub rohkem tulema (õnnestunud kampaania?), saab serveris lubatud PHP-protsesside arv varsti täis ning järgmised päringud peavad ootama eelmiste lõppemist.

Tehes käsurealt top avaneb siis selline pilt:

Virtuaalserveris on kasutajale lubatud kuni 15 PHP protsessi, Nutika Privaatserveri puhul võiks neid lubada niipalju kui klient soovib… aga (a) kui neid on rohkem kui protsessoril tuumasid ei lähe asi kuidagi kiiremaks (b) probleemi juurpõhjust ressurssidega loopimise meetodil ikkagi ei lahenda.

Sellised PHP käivitamise taga ootavad päringud näevad muideks BlackFire’is välja täiesti normaalsete sekundiliste vastustena – sest kuniks veebiserver (Apache) ootab vaba PHPd, ei ole ju ka mingit aega mõõta…

Ja kui PHPs tehtava päringu puhul on jäänud mõistliku pikkusega timeout seadistamata ning mõne lehe kuvamine hoiab PHP protsessi kinni 30 sekundit … siis pole kampaaniat vajagi. Probleemi avastamise teeb raskemaks see, kui aegavõtva päringu põhjustab suvaline alamleht (mida otsimootor parasjagu indekseerida proovib).

See on täpselt see probleem, mida tähistab üleval Pingdomi graafikul kell 14-15 algav küür. “Meie veebil” polnud häda midagi, aga üks teine veebiserver (või selle netiühendus) käis käntsu…

Probleem 2: meeletult SQL-päringuid

Tuhatkond andmebaasi-päringut pole küll mingi rekord – mulle meenub esileht, mille kuvamiseks tehti 12000 – aga väikseks rehkenduseks sobib hästi:

Oletame, et üks kiire andmebaasipäring võtab 2 millisekundit. Kui neid teha 1350 tükki, siis kulub sellega sahmerdamiseks … ligemale 3 sekundit. Lihtne soovitus – pea meeles,  et tuhandega korrutades saab millisekundist sekund.

Ülaloleval pildil on Magento otsingulehe kuvamine ning kuna see pole puhverdatud, siis on suur hulk päringuid paratamatu. Aga kui sa paned kampaania landing‘uks otsingulehe, siis võib see lisakoormus osutuda probleemseks.

Päris ilma cache’ta Magento 1.x kategoorialehe puhul on pilt selline, jõud kulub hulgast XMLidest konfiguratsiooni kokku ehitamisele:

Probleem 3: laeme kogu tabeli mällu ja siis sõõlame seda PHPs

Järgmine probleem on ilmselt esimese Pingdomi graafiku pideva kasvu taga – andmebaasi vastu tehakse küll vähe päringuid, aga küsitakse terve tabeli sisu ning siis asutakse seda PHPs läbi lappama. Näiteks selleks, et kuvada kategoorialehel 20tuh tootest järgmised 10:

Ole inime, ära tapa PHPd tööga, seda saab teha ka elektriga … st SQLiga. Kategooria lappamiseks sobiks nt LIMIT 10 OFFSET 1200.

Probleem 4: imetabased (ent indekseerimata) metaväljad ja andmebaas kui prügimägi

WordPressi puhul on tüüpilisemaks probleemiks pluginad, mis hoiavad oma andmeid post_meta tabelis ning teevad selle pihta imetabaseid päringuid. TOP-3 võiks olla selline:

  • Advanced Custom Fields – mugav viis lisada postitusele lisainfot või kindla vormindusega sisublokke. Aga selle peale ei tasu ehitada suuremat andmebaasilahendust, mis teeb otsinguid meta-väljade sisu kasutades. Mis ei ole vaikimis teps mitte indekseeritud (indeksi lisamine parandab olukorda mõnevõrra, aga mistahes andmetüüpide tekstiväljas hoidmine ei ole parim strateegia muretuks pensionipõlveks)
  • WooCommerce – aga mis oleks, kui me paneks kõik toodete, tellimuste jne kohta käiva informatsiooni nendesse metaväljadesse? Yep, that’s WooCommerce. Jube mõnus tööriist sajakonna tootega poe jaoks, aga pane ennast korraks andmebaasi mootori olukorda – kui kogu su 10tuh tootega pood asub laoruumis mustades prügikottides. “Tahaks M suurust punaseid särke mis ei maksa rohkem kui 12€” – “Juba jooksen!” – “[piinlikult pikk paus, kuulda on ähkimist, kohmitsemist ja kilekottide rebenemist]”.
  • WPML – minu ammune lemmik mitmekeelse veebi tegemiseks, hea mugav lehti ja postitusi tõlkida. Aga WordPressil on olemas väga normaalne .po/.mo failidega tõlkimise tugi, mille asendamiseks pakub WPML mugavusvõimalust need andmebaasi migreerida. Sa püha püss, kus kiirus kukub! Ja kui nüüd paneks juurde WooCommerce metaväljades oleva sisu tõlkimise … (me soovitame “lihtsaks rauaga tapmise lahenduseks” Nutikat Privaatserverit, sest siis püsib kogu see tarbetult keeruline andmebaasimudru kenasti mälus :-).

Mul ei ole hetkel head näite-pilti, lisan kui leian. Või kui sina saadad 🙂

Probleem 5 – visuaalsed jms lehe-ehitajad

BlackFire’s on lisaks funktsiooni-graafile olemas ka väga ilus ajajoon, mis annab aja kulumisest ning funktsioonide seostest isegi parema pildi:

See on üks veidi keerulisem alamleht, kus kuvati 8 … ütleme, et “toodet” ning iga ühe kohta nimistut sellega seotud postitustest. Nimistu kuvamine oli tehtud pluginaga, mis lubas lisada lehele PHP-koodi sisaldava shortcode’i ning koodis oli lihtne get_posts() ja foreach tsükkel … mida jooksutati eval() abil. Tuleb välja, et selline tsükkel on vääääääga aeglane, probleemi lahendab lehe-templiit … või siis oma shortcode, mis võtab parameetriks toote ja siis kuvab mida-vaja.

Teine esile toodud aega kulutav element on mitme-tasemelise menüü ehitamine – WordPressi puhul on ka menüü sisuliselt hulk eritüübilisi postitusi ja neist hierarhia kokkuehitamine misiganes põhjusel aeglane. Kuna menüü sisu eriti sageli ei muutu, siis ma prooviks selle ära cacheda.

* * *

Kui jutt huvi tekitas, siis proovi ise järgi – Zone Virtuaalserveri peal katsetades ei nõua isegi paigaldamine mingeid eriteadmisi. Mina alustasin BlackFire õppimist tasuta Hack plan’iga, siis proovisin Premiumi trialit, aga jäin lõpuks Profiler’i peale pidama.

Send moare freak bugs 🙂

Zone kroonika: 2017

 

On saanud tavaks, et veebruari lõpus/märtsi alguses, kui koostame oma aastaaruandeid, anname aru ka oma klientidele ja avalikustame märkmed olulisematest möödunud aastasse jäänud tegemistest. Nii ka seekord.

Domeenid

Domeeninduses möödus 2017. aasta märksa rahulikumalt, kui sellele eelnenu.

Aasia spekulantide toel amokki jooksnud turg sai päitsed pähe, kuna paljud senised domeenidega hangeldanud pöörasid oma tähelepanu krüptovaluutadele.

Idas toimunud pöörde mõjul lasti lõpuks õhk välja ka Eesti tippdomeenist, mis kaotas korraks oma tipust ligi 17 000 domeeni. Majanduse hea seis kasvatab aga uusi registreerimisi jõudsalt.

Zonet mõjutasid mullistused turul niipalju, et spekulantide toel paisunud registripidajate turuosa kahanedes taastus meie osa normaalsele tasemele. Aasta lõpu seisuga oli Zone taas registreerinud enam .EE domeene, kui ükski teine registripidaja. Tervelt 45% kõikidest .EE domeeni registreerijatest usaldab Zone teenuseid. Arvestades, et registripidajaid .EE domeenis on kokku ligi 40, siis on see märkimist väärt usalduskrediit, mida soovime väga hoida.

Kui majandusel läheb hästi, siis otsivad ettevõtjad oma auahned ekspordiplaanid sahtlipõhjast välja ning pühivad tolmust puhtaks. Meie lähinaabrite Soome, Läti ja Leedu tippdomeenides domeeni registreerimiste märkimisväärne kasv 2017. aastal näitab, et Eesti ettevõtjatel jagub taas ambitsioone. Kõige suurem kasvaja on Eesti arvelt olnud Soome, kes 2016. aastast võimaldab .FI domeene registreerida ka Eesti ettevõtjatele ja kelle registrisse oleme sellest ajast edastanud tuhandeid taotlusi.

Meie tarkvaraplatvormis oli suurim domeenidega seotud muutus see, et muutsime oma domeenide pikendamise senisest lihtsamaks – kus vähegi võimalik ei pea domeeni pikendamiseks enam esitama eraldi taotlust või täitma vormi – piisab vaid ettevalmistatud arve tasumisest.

Laienes ka DNSSEC tugi, mis muutus kättesaadavaks mitmetes tippdomeenides, mille puhul see varem toetatud ei olnud.

Pilveserverid

Pilveserver VPS teenus läbis eelmise aasta sügisel märkimisväärse värskenduskuuri. Uuendasime kõikides teenuspakettides klientidele pakutavaid ressursse, mis enamasti lausa mitmekordistusid.

Kõik olemasolevad kliendid said tehtud muudatustest ka kohe osa, sest muutsime nende olemasolevad virtuaalmasinad sisuliselt üleöö mitu korda võimsamaks.

Markantseim näide siinkohal oleks Pilveserver VPS teenuse esimene pakett, mille muutmälu (RAM) näiteks kasvas 256 MB pealt 2 GB peale.

Peeter Marvet ei pannud kiusatusele vastu ja tegi ka mõned võrdlevad testid meie pilveserverite ja “konkureerivate teenuste” vahel ning selgub, et meil pole häbeneda midagi. Kui kedagi huvitab, siis võrdleva info ja värskendatud KKK teenuse kohta leiab aadressilt https://www.zone.ee/et/pilveserver/vps/

API

Üks vägevamaid töid, mille meie tarkvaraarendajad eelmisel aastal korda saatsid, oli Zone API viimine seisukorda, kus me julgeme sellest avalikult rääkida ja selle kasutamist soovitada ka teistele lõppkasutajatele peale hulljulgete katselendurite.

Meie API kirjelduse leiab aadressilt https://api.zone.eu/v2 ja mõned näpunäited selle kasutamiseks omakorda lehelt https://help.zone.eu/Knowledgebase/Article/View/546/0/zoneid-api-v2

API on äärmiselt kasulik näiteks neile, kas haldavad meie juures sadu või tuhandeid DNS kirjeid või soovivad integreerida meie Virtuaalserveri või Nutika Privaatserveri omaenda väärtuspakkumisse.

API’t arendame me käsikäes klientidega, mis tähendab, et eelkõige lisame sellele võimalusi, mida nood meilt soovivad.

Virtuaalserverite ja Privaatserverite platvorm

MongoDB

Üks esimesi tarkvaraplatvormi uuendusi eelmisel aastal oli MongoDB andmebaaside tugi.

MongoDB on NoSQL andmebaasimootor, mis kasutab andmete säilitamiseks JSON-i laadseid dokumente. MongoDB ei vaja andmebaaside skeema loomist või muutmist, kuna andmete vorm on kirjeldatud säilitatavates dokumentides endis. Teatud juhtudel võimaldab see näiteks säilitada ühe kirjena andmeid, mille töötlemiseks oleks relatsioonilises andmebaasis vaja luua mitmeid tabeleid. See omadus sobib väga hästi ka iteratiivse arendusmudeliga, mille käigus säilitatavad andmed võivad pidevalt täieneda või muutuda.

MongoDB toe lisamine oli osa meie soovist pakkuda oma kasutajatele ka väljapoole klassikalist LAMP stäkki jäävaid tööriistu. Varasemalt olime näiteks juba lisanud Redis andmebaaside ja Node.js käigukeskkonna toe.

Millega oma platvormil nüüd eksperimenteerime on Java rakendused. Näiteks kasutame täna omaenda virtuaalservereid selleks, et käivitada Atlassiani perekonda kuuluvaid tooteid nagu Confluence, Jira, Bitbucket jt.

MongoDB kohta kirjutas blogis Andris: https://blog.zone.ee/2017/01/09/mongodb-andmebaas-zone-virtuaalserveris/

SSH 

SSH ligipääs Zone platvormi kasutavatele serveritele muutus paindlikumaks. Senine jäik ligipääsupoliitika, mis nõudis igale kasutajale ka IP-de määramist, asendus leebemaga, mis jätab IP põhiste ligipääsupiirangute seadmisel ka võimaluse lubada ühendusi kogu maailmast. Seda me mõistagi ise ei soovita ja sestap vaikimisi on IP usaldusnimekiri ikka kasutusel, kuid kliendil on seda võimalik välja lülitada.

Ka usaldusnimekirjad ise muutusid veidi paremaks ning võimaldavad varasematele hostipõhistele reeglitele ka võrgupõhiseid reegleid.

SSH kasutus sai ka oma veebipõhise logi, mis võimaldab näha millise võtmega ja millal teenust kasutati.

Väiksemaid muudatusi oli teisigi, täpsemalt saab juba lugeda varasemast blogipostist https://blog.zone.ee/2017/05/03/zone-ssh-ligipaasupoliitika-muutus-paindlikumaks/

PHP

PHP kasutajatel muutus eelmise aasta kevadel uute serverite ja alamdomeenide vaikeversiooniks PHP 7.1.

Aasta lõpuks said kasutajad aga hakata mängima juba PHP 7.2 versiooniga, mis lasti ametlikult välja 30. novembril ja oli meie klientidele kättesaadav 4. detsembrist. Uueks vaikeversiooniks muutub see käesoleva aasta suvel.

Salamisi lisasime PHP kasutajatele ka sellise huvitava võimaluse, et nüüdsest on neil võimalik oma vealogi näha reaalajas. Ettearvatavalt asub vastav fail virtuaalserveri “logs” kataloogis ja on nimega “php.log”.

Logid roteeritakse vaikimisi igal öösel ja säilitatakse maksimaalselt viit viimast logi versiooni, vanemad failid kustutatakse.

PHP 7.1 kohta kirjutas Peeter ka siin: https://blog.zone.ee/2017/05/30/php–7–1-vaikeversioonina/

Blackfire ja New Relic’u tugi

Tarkvaraarendajate elu ei ole lihtne, tihti elavad tähtajad seljas ja uute rakenduste jõudlustestimiseks endal keskkonda pole või seda enne ‘live’ minekut üldse ei jõuta. See ei ole aga hea.

Otsustasime arendajate elu lihtsamaks teha ja lisasime oma platvormi toe New Relic’u ja Blackfire agentidele, mis mõlemad võimaldavad oma rakenduste jõudlusel silma peal hoida.

Blackfire’t soovitame eelkõige kasutada tarkvara arendamise ja testimise faasis ning hiljem New Relicut rakenduse tööl pidevalt silma peal hoidmiseks.

Mõlemad on võimalik sisse lülitada haldusliidesest PHP laienduste juurest.

Juhin tähelepanu, et tegemist on väliste teenustega, mille litsents tuleb täna kasutajal endal hankida.

DNS

Virtuaalserverite DNS funktsionaalsus sai omakorda juurde toe SSHFP ja CAA tüüpi DNS kirjetele, mis võimaldavad täiendada SSH ja TLS ühenduste turvalisust DNS-i abil. 

SPF kõikidele virtuaalserveritele

Suvel teostasime oma ammuse unistuse ja lisasime kõikidele Zone meilindust kasutavatele serveritele SPF DNS kirjed, mis aitavad meie klientide kirju spämmist eristada ja vähendavad võimalust, et keegi kolmas saab nende nimelt karistamatult saasta maailma laiali pritsida.

Täpsemalt kirjutas selle kohta Peeter blogipostituses: https://blog.zone.ee/2017/08/24/spf-kirje-koigil-domeenidel/

HTTPS

Aasta lõpuks kandsid suuri vilju meie pingutused turvatud veebiühenduste propageerimisel.

HTTPS protokolli vaikimisi sisselülitamise tulemusena ületas meie platvormil majutatud klientide veebides turvatud ühenduste arv turvamata HTTP ühenduste arvu ja see osakaal jätkab kasvamist. 

Uuenes serverite monitooringuplatvorm

Meie köögipoolelt, mis kasutajatele veidi ka näha, on üks oluline muudatus senise jõudlus- ja töökindlusmonitooringu välja vahetamine uuema, täpsema ja paindlikuma lahenduse vastu. Nimelt joonistame nüüd endale ja klientidele monitooringu jaoks graafikuid Grafana nimelise tarkvara abil, mis annab varasemaga võrreldes palju täpsemalt ja operatiivsemalt infot serverite seisukorra üle.

Klientidest puudutab see eelkõige meie Nutika Privaatserveri teenuse kasutajaid, kes näevad oma serveri(te) graafikuid meie haldusliidesest.

Planet.ee uuendus

Nagu paljud teavad, siis pakume me lisaks Zone.ee kaubamärgile äärmiselt hinnatundlikule kliendile teenuseid ka Planet.ee nime alt, kus kasutaja saab endale minimaalsete kuludega internetioleluse luua. Peamiseks sihtgrupiks on õpilased, tudengid ja muud asjaarmastajad.

Eelmise aasta sügisel läbis Planet.ee uuenduskuuri, selle kasutajad said enda käsutusse senisest rohkem ressursse ning uue serveriplatvormi, mis vastab oma võimalustelt rohkem Zone omale.

Planet.ee pakkumisega on võimalik tutvuda aadressil https://www.planet.ee/

Infrastruktuur

Meie operatsioonide meeskonnal olid eelmisel aastal käed tööd täis jaanuarist detsembrini.

Kolimine Amsterdamis

Amsterdamis ühest andmekeskusest teise kolimist tingis vajadus parandada meie Pilveserver PRO teenuse kvaliteeti.

 Pilveserver PRO on platvorm, mis on optimeeritud eelkõige virtuaalmasinate töökindlusele ja paindlikkusele vastamaks parimal viisil nõudliku kliendi vajadustele – puuduvad fikseeritud teenuspaketid, teenuse eest makstakse vastavalt tellitud ressurssidele ja erinevalt Pilveserver VPS teenusest saab kasutada oma Linux kernelit ning vajadusel ka Windows operatsioonisüsteemi.

Aasta alguses kolisime selle teenuse osutamiseks mõeldud infrastruktuuri ühest andmekeskusest teise ning lisasime märkimisväärselt serveri ja võrguressursse.

Peeter kirjutas selle kohta siin nii: https://blog.zone.ee/2017/01/25/amsterdam-kolib-amsterdami/

Lisaks Pilveserver PRO teenusele saab täna meilt Amsterdamis ka Pilveserver VPS ja Virtuaalserver teenuseid.

(Saladuskatte all võin paljastada, et eriti headele klientidele oleme teinud sinna ka Nutikate Privaatserverite pakkumisi.)

Varukoopiate kolimine

Kes on Zone hingeeluga kursis, see teab, et juba väga pikka aega on Zone teinud kõik kliendiandmetest loodud varukoopiad vaikimisi eraldi andmekeskusesse. Selle eesmärk on tagada klientide ja meie enda talitluspidevus ka siis, kui peaks juhtuma mõnd meie andmekeskust puudutav suurõnnetus, olgu selle põhjustajaks siis tulekahju, terrorism vms.

Aastaid asus see andmekeskus umbkaudu 3–4 kilomeetri kaugusel meie peamistest asukohtadest. Eelmisest aastast on selleks vahemaaks üle 10 kilomeetri.

Au ja kiitus meie ettevaatlikele tehnikutele, kes petabaite suudavad turvaliselt ühest kohast teise liigutada.

Laienemine

Kolimine ühest kohast teise ei ole kindlasti ainukene asi, millega meie tehnikud tegelevad. Tuleb ette, et on vaja ka samas andmekeskuses laieneda. Serverite lisandumise tõttu kahekordistus näiteks ühes meie peamistest andmekeskusest serverikappide “jalajälg” ca 100% võrra.

 

Numbrid

Kuna kõigile meeldivad vahvad numbrid, siis seekord tooksin esile meie klienditeenindust, kes vastas 2017. aastal 50 000 kirjale ja 19 000 telefonikõnele.

2018. aastale astusime me vastu 28 töötajaga, aga tänaseks on see arv kasvanud 30 peale.

Palju on projekte, mille kallal käis töö juba eelmisel aastal, kuid mis jõuavad avalikustamiseni sel aastal. Lugemata arvul oli täiendusi ja parandusi, mis eraldi eriletõstmist ei vääri, kuid mille teostamise eest olen meie meeskonnale ülimalt tänulik.

 

Meltdown ja Spectre ehk kuidas bittidega spekuleerida ja võõras mälus sobrada

Saabunud aasta algas IT-inimestele korraliku üllatusega – 3. jaanuaril jõudis avalikkus ette info, et protsessoritest on avastatud turvaprobleemid, mis võimaldavad sõltumata kasutatavast opsüsteemist pahatahtlikel tegelastel saada ligipääs andmetele, millele nad kuidagi ligi saada ei tohiks.

Kuigi alguses oli jutt peamiselt Inteli protsessoritest, sai peagi selgeks, et ka teiste tootjate protsessorid on probleemist mõjutatud, kuigi oluliselt vähem kui Inteli toodetud.

Üldise meeleolu illustreerimiseks sobib kenasti video terasetehasest. Meie püüame olla need tegelased lõpukaadritest, kes paanikasse ei satu, toimuvat dokumenteerivad ja rahulikult tagajärgedega tegelemiseks valmistuvad 🙂

Nagu tänapäeval tavaline, said turvaprobleemid oma tavapärastele CVE numbritele lisaks nime, veebilehe jpms. Peamiselt ainult Intelit puudutav probleem sai nimeks Meltdown (CVE-2017-5754) ja kaasaegsete protsessorite enamust puudutav probleem on Spectre, millel on kaks variatsiooni (CVE-2017-5753 ja CVE-2017-5715).

Kui üritada seda ühe lausega öelda, siis mõlema näol on tegemist on nõrkustega, mis võimaldavad pahatahtlikel rakendustel spekulatiivselt koodi käivitatavate protsessorite disainiprobleeme ära kasutades lugeda seadmetes külgkanalründe abil mälu, millele nad tegelikult ligi pääseda ei tohiks. Kuidas saab protsessoris üldse selliseid vigu olla ning millega täpsemalt tegemist, on jäänud paljudele arusaamatuks.

Sõnad “külgkanalrünne protsessori spekulatiivse käivitusse realisatsioonide vastu” ei tee enamusele asja oluliselt selgemaks, kuid neile, kes huvi tunnevad, on postituse lõpus lihtsustatud kokkuvõte probleemi olemusest. Kõik, kel jõud ja mõistus üle käib, peaksid kindlasti läbi lugema probleemid avastanud teadlaste originaalartiklid.

Mida siis nende probleemide tõttu tegelikult teha saab?

Praktiliselt ainult Inteli protsessoreid puudutav Meltdown on kahest probleemist tõsisem – kui pahatahtlik rakendus saab seadmes ennast käivitada, siis sellest piisab, et kogu operatsioonisüsteemi tuuma kasutuses olevat mälu maha lugeda. Lugemine ei toimu küll eriti kiiresti, kuid piisavalt, et sellest edasiseks ründeks ära kasutatavaid andmeid (paroolid, krüptovõtmed jms) leida. Probleemi on võimalik vältida tarkvaraliste vahenditega ja tänase päeva (15.01.2018) seisuga on kõik peamised operatsioonisüsteemid (Windows, MacOSX, iOS, Linux, Android) ka turvapaigad väljastanud.

Spectre võimaldab pahatahtlikul rakendusel lugeda nii operatsioonisüsteemi tuuma kui ka teiste rakenduste mälu, kuid selle ära kasutamine on oluliselt keerulisem. Selleks ei piisa lihtsalt koodi käivitamisest – see eeldab ka konkreetsete ära kasutatavate koodimustrite olemasolu operatsioonisüsteemi tuumas või teistes rakendustes. Keerukam on ka Spectre mõjude kõrvaldamine ning see võtab veel aega. Üks Spectre variatsioonidest on ilmselt suhteliselt lihtsalt lahendatav operatsioonisüsteemi tuuma tasemel, kuid teise vastaste meetmete otsing veel käib. Praegu olemas olevad lahendused on väga kulukad – kas kannatab jõudlus väga palju või peaks kõik seadmetes olevad rakendused uue kompilaatoriga ringi kompileerima.

Arusaadaval põhjusel on eelkõige ohustatud keskkonnad, kus kasutajad saavad vabalt koodi käivitada – eelkõige jagatud serverid ning virtuaalmasinate keskkonnad. Virtuaalmasinate puhul võimaldavad need nõrkused kasutajal ka ennast virtuaalmasinast välja murda – lugeda hüperviisori ja teiste virtuaalmasinate mälu. Kuid ohus on ka kõik tavalised tööjaamad – probleeme uurinud eksperdid on tõestanud, et rünnak toimib ka JavaScripti kaudu. Praeguseks on kõik suuremad brauserid rakendanud meetmed, et veebi kaudu probleemide ära kasutamine oleks vähemalt hästi keeruline.

Suhteliselt pessimistliku kirjelduse peale tekib kindlasti küsimus, et kuhu poole nüüd paanikas jooksma peaks ja mida tegema? Ja miks see üleüldse nii kaua aega võtab?

Üks on selge – protsessoreid välja vahetama ei hakka ei Intel ega ka ükski teine tootja ning nendest probleemidest vabad protsessorid jõuavad meieni ilmselt alles järgmisel aastal. Kuid rahu, ainult rahu. Probleemid on vaatamata tõsidusele protsessoritootjate abiga tarkvaras lahendatavad ning kõigi arenduses olevate operatsioonisüsteemide arendajad on praegu ametis. Aega võtab see ka selle pärast, et olukord on väga paljudele uus – tarkvara ja riistvara tootjad peavad tegema koostööd ja üksteist ka usaldama. Ma olen kindel, et tsivilisatsioon ei kuku veel selle pärast kokku, kuid turvapaikade operatiivne paigaldamine on olulisem kui kunagi varem. Nagu juba eespool öeldud, on Meltdown praeguseks juba suuremates opsüsteemides paigatud ning kui sul on uuemad turvapaigad seadmetes, oled sa tõenäoliselt selle vastu juba kaitstud.

Oluline on ka mõista, et kui ründajal pole seadmes võimalik koodi käivitada, otsest ohtu pole. Mis ei tähenda muidugi seda, et esimesel võimalusel uuendamist siiski ette võtma ei peaks – Meltdown ja Spectre võivad olla osa keerulisemast ründest, kus mingi teise turvaprobleemi tõttu saavutatakse kõigepealt koodi käivitamise õigus.

Kuidas Meltdown ja Spectre Zone servereid mõjutavad?

Nii Virtuaalserverite kui Pilveserverite puhul jagab hulk kliente sama riistvaralist serverit ning turvaprobleemid, kus ühe kliendi serveris jooksev kood võib mõjutada teisi, on meie jaoks kõrgeima prioriteediga. Tänaseks on Zone serverid Meltdowni vastu kaitstud – enamus juba 06-08.01 nädalavahetusel.

Küll aga tuletame meelde, et Pilverserver PRO kasutajad peavad oma virtuaalmasinate kernelite uuendamise eest ise hoolt kandma (Pilveserver VPS kernelid uuendasime 07.01 varahommikul).

Meie tehnikud jälgivad sündmuste arenguid ja paigaldavad parandused ka Spectre vastu niipea kui võimalik. Võimalik, et selleks on vaja veel üht erakorralist hooldusakent.

Kas Meltdown’i paikamine mõjutas ka serverite töökiirust?

Paikade mõju sõltub rakendusteks, aga tavapärase veebirakenduse puhul on meie seninsed testid näidanud, et muutus on pea olematu. Tegime oma koormustestiks kasutatava WordPress+WooCommerce+WPML+Flatsome näidisrakendusega teste ning uurisime rakenduse tasemel monitooringus olevate veebide käitumist ning mingit mõõdetavat erinevust ei tuvastanud.

Küll aga on muutus näha Pilveserver VPS protsessori-aja kasutuses. Sellel pildil on üks hardware node, kus ilmselt VPSides jooksvate rakenduste eripärast lähtuvalt on syscall’ide osakaal märkimisväärne ja kasvab ca 2% pealt ca 10% peale:

Kuna enamikul ülejäänutest oli kasv oluliselt väiksem, tasub rakenduse töökiiruse muutumisel vaadata üle kõik syscall’e põhjustav ehk ennekõike IO, sh andmebaasikasutus. Selle osa optimeerimine on mõistlik ka ilma Meltdown ja Spectre paikade negatiivse mõju peale mõtlemata.

Trivialiseeritud Meltdown ehk “Kuidas lugeda võõrast mälu?”

Probleemide olemuse mõistmine pole tegelikult ühelegi programmeerimisega kokku puutunule üle jõu käiv, kuid illustreerib väga hästi külgkanalründe olemust. Alljärgnev on kõvasti lihtustatud versioon Meltdown probleemist. Kõigepealt räägime pisut kaasaegse protsessori tööst.

Kaasaegsed protsessorid on kiired, kuid mälust lugemine ja sinna kirjutamine ca 100x aeglasem. Et protsessor mälu taga pidevalt ootama ei peaks, on protsessoritel varuks hulga trikke, millest olulisimad on spekulatiivne käivitamine ja vahemälu.

Kui arvutitunnis räägiti teile, et protsessor käivitab ühe käsu teise järel, siis tänapäeval ei vasta see tihti enam tõele. Kuna protsessorid on mälust nii palju kiiremad, üritavad nad juhul, kui neil midagi targemat teha pole, järgmiseks käivitatavaid programmi harusid ette aimata ning selle töö ka igaks juhuks ette ära teha. Kui peaks juhtuma, et tõenäoline stsenaarium siiski ei realiseerunud, unustatakse see igaks juhuks ette tehtud töö tulemus lihtsalt ära. Kuna spekulatiivset tööd tehakse protsessori “vabast ajast”, ei muuda see midagi aeglasemaks, kuid kui stsenaarium realiseerub, on kiirusevõit oluline.

Võtame näiteks alltoodud veebilehe vaatamise pseudokoodi. Lehe kerimine on veebilehel oluliselt tõenäolisem sündmus kui lingile vajutamine ning protsessoril on kasulik see alati ette ära teha, isegi kui kasutaja veel kerimise liigutust teinud pole.

kui (kasutaja kerib lehte alla) {
  liigu rida allapoole;
} vastasel juhul kui (vajutatakse lingile) {
  liigu uuele lehele;
}

Sellisest spekulatiivsest käivitamisest poleks iseenesest aga väga palju kasu, sest suure tõenäosusega vajavad ka need käsud mälu poole pöördumist. Selle vältimiseks on protsessorites endis olemas hästi kiire vahemälu, kus hoitakse hiljuti kasutatud või sagedamini vaja minevaid andmeid neid mälust sinna portsu kaupa laadides. Kui protsessor vajab käsu täitmiseks andmeid mälust, laaditakse need vahemällu, kuhu need jäetakse ka pärast käsu täitmist – igaks juhuks, äkki läheb vaja.

Nüüd on meil olemas kõik põhiteadmised, et mõista alljärgnevat pseudokoodi. Pahatahtlik häkker soovib teada saada mis on mäluaadressi 0x200 vähima kaaluga biti väärtus. Rakendus ei saa seda mäluaadressi otseselt lugeda, kuid ta saab kirjutada sellise programmi.

kui (tingimus) {
  kui (aadressil 0x200 on 1) {
    loe väärtus aadressilt 0x800;
  } vastasel juhul {
    loe väärtus aadressilt 0x900;
  }
}
loe väärtus aadressilt 0x800;
mõõda eelmise käsu täitmiseks kulunud aeg;
loe väärtus aadressilt 0x900;
mõõda eelmise käsu täitmiseks kulunud aeg;

Protsessor täidab spekulatiivselt tingimuslaused ja kuigi selle käigus toimub lugemine aadressilt 0x200, millele pahatahtlik rakendus ei tohiks ligi saada, on see esmapilgul ohutu, sest protsessor on disainitud nii, et rakendus lõpetaks töö kohe, kui „tingimus“ peaks tõeks osutuma ja enne, kui 0x200 aadressilt lugemine rakenduseni reaalselt jõuaks. Sellel spekulatiivsel tingimuslausete täitmisel on aga kõrvalefekt – kas 0x800 või 0x900 aadress laaditakse protsessori vahemällu. Kui nüüd pärast seda mõõta 0x800 ja 0x900 aadresside lugemiseks kuluvat aega, on meil võimalik järeldada kas kumbki neist oli juba protsessori vahemälus olemas (kiire) või tuli seda mälust lugemas käia (aeglane) ning sellest järeldada aadressil 0x200 asuva biti väärtuse.

Tegelikult on probleemide olemus ja ära kasutamine muidugi märksa keerulisem, kuid põhimõte on just nii lihtne – pahatahtlik rakendus saab aja mõõtmise abil järeldada mis väärtused on mäluaadressidel, millele ta muidu ligi ei pääse. Kuna mäluaadresse otse ei loeta, vaid seal leiduva kohta tehakse järeldusi käskude käivitamiseks kulunud aega mõõtes, nimetataksegi selliseid ründeid külgkanalrünneteks (inglise keeles side-channel attack).