Oman palvelimeni suunnittelu

Olen saapunut tilanteeseen, jossa suunnittelen oman fyysisen palvelimen ottamista käyttöön. Paljon on jo rautaa hankittuna valmiiksi, mutta paljon on myös opeteltavaa ja tehtävää. Oman palvelimen ylläpitäminen on ehkä hieman haastavaa, mutta samalla myös opettavaista ja mukavaa. Se on kiinnostavuudeltaan hieman verrattavissa chilien tai muiden vastaavien kasvien sisäkasvatukseen.

CloudFlare

Sivustot elävät ja ovat jatkuvassa muutoksessa. Omakin blogini elää ja vaihtelee osoitteita, joissa se toimii. Tämän ei kannata antaa häiritä. Toisinaan sivusto on alhaalla, eikä itselläni ole tavoitteenakaan päästä 99.95 % saavutettavuuteen. Pyrin kuitenkin pitämään blogini pystyssä, koska kuvan 2 mukaisesti päivittäin blogissani on kävijöitä usein ainakin 300 eri IP-osoitteesta, joista n. 10 – 20 % on Suomesta.

Kuva 2. kävjämäärät CloudFlaren tilastojen mukaan 23.2.2019.

Ihan harrastusmielessä sivustoa ylläpidän, oman osaamisen kartuttamiseksi. Työkseni teen tällä hetkellä Front End -ohjelmointia. Kuitenkin yleisen alan tuntemuksen takia on tärkeää, että hallitsee myös palvelinten ylläpidon edes välttävällä tasolla. Kaikki ohjelmistokehityksen ”tasoja” työstävää ohjelmoijaa kutsutaan Full Stack -ohjelmoijaksi, etenkin kun kyse on vähintään keskisuuresta ohjelmistosta.

Joskus on käynyt niin, että ei ole saanut omaan palvelimeeni yhteyttä moneen tuntiin. Lopulta onkin paljastunut, että virtuaalipalvelin on itsessään ollut jostain syystä pimeänä. Jos kotiin omat palvelimet saan, niin saavutettavuuden ei voi ainakaan odottaa parantuvan nykyisestä, vaikka OVH-hostingin toimintavarmuus ei oikein vakuuta itseäni. Lupaus 99.95 % saavutettavuudesta meni kerralla, kun palvelin yksinkertaisesti pimeni moneksi tunniksi SSH-avaimen käyttöönoton jälkeen ilman omaa syytä. Oli varsin pelottavaa siinä tilassa, asiakaspalvelu ei tietysti tiennyt mitään, eikä mukamas mitään tietoa ollut palvelinten toimintaongelmista heidän tiedossaan. Se herätti entistä enemmän epäilyksi OVH-hostingin laadusta, kun eivät itsekään olleet tietoisia, että palvelin oli kaatuneena/pimeänä monta tuntia ilman, että firma itse olisi mitenkään tietoinen asiakkaalle aivan selvästi ilmenneestä todella pitkästä blackoutista, jossa suora yhteys palvelimen IP-osoitteeseen ei vastannut mitään ja PuTTY aikakatkaisee yhteyspyynnöt. OVH-hostingilla oli vieläpä pokkaa väittää; ettei niin olisi käynyt, vaan vika olisi ollut asiakkaan osaamattomuudessa.

Riskienhallinta

Todennäköisesti tulevassa palvelimessani ei ole minkäänlaista varavirtaa, ja saattaa johtoja tökkii robotti-imuri viikoittain. Itse joskus saatan repiä jatkoroikkia omiin tarkoituksiini, kaataa olutlasin (kerran melkein kävi jo näin -Admin) taikka oksennan raudan päälle tai kusen sen päälle baarista tullessani, todennäköisesti imuroin täyhdellä kaistalla pornoa levyn täyteen, saatan heitellä palvelinlaitteistoa PCP-meta -kombopsykoosissa, kännissä tai muussa vastaavassa tilassa konffaan tai rekursiivisesti deletoin jotain vääriä tiedostoja kunnes pääsen ulos hullujenhuoneelta, poliisit takavarikoivat palvelimen kuulusteluita varten pariksi viikoksi minun ollessa samalla pidätettynä sellissä epäiltynä, jonka jälkeen tulen muuttamaan eri asuntoon odottamaan verkkoliittymää. 3G verkko ruuhkautuu niin pahoin, että yhteys käytännössä katkeaa etenkin Supon ja muiden minua vihaavien tahojen palvelunestohyökkäyksen aikana. Positiivisena puolena todennäköisesti ainakin osa palvelimen sähköistä voi olla jopa vikavirtasuojatun jakorasian päässä, ellei sitä satu tarvitsemaan johonkin muuhun käyttöön, jolloin palvelin voi olla ilman sähköjä, jos esim. pitää kolvata piirilevyä. Olen siis akateemisesti koulutettuna tietotekniikan DI;nä miettinyt riskienhallintaa ja riskien ehkäisyä hyvin tarkasti, etenkin todennäköisesti toteutuvat riskit palvelimen saavutettavuuden menettämiseen kirjasin ylös, osittain myös arvioin riskin toteutumista seuraavan keston palvelimen saavutettavuuden menetykselle.

Verkon osoitekin vaihtelee dynaamisesti, joiden muuttuessa reititin lähettelee DNS:n muutospyynnön CloudFlarelle, josta se sitten korjaantuu luultavasti tunnin sisällä eri DNS-palveluihin. Sertit on jo nyt sekaisin, kun ei kiinnosta maksaa viittä euroa kuukaudessa päivitettävistä serteistä. Kiintolevyille, virranlähteille ja millekään muullekaan komponentille ei ole minkäänlaista varmennusta, korkeintaan varmuuskopioin sivustoa kerran vuorokaudessa, parhaimmillaan kuukausittain tulisi virtuaalikoneista varmuuskopiot, mahdollisesti kovan kryptauksen jälkeen siirrän varmuuskopiot muutaman kertaa vuodessa pilvipalveluun suojaa erilliseen tilaan, jos vaikka joku pesäpallomailla riehuva rosvo murtautuu ja hakkaa/varastaa palvelimeni ja kaikki varmuuskopiot, niin kyseisen hirveän katastrofin ja sairaalan teho-osastolta poistumisen jälkeen saan vielä palautettua järjestelmät viimeisenä oljenkortena äärimmäisen hyvin suojatun ja paperiin kirjatun salausavaimen avulla, samalla kun muu omaisuus ja elämä on muuten täydellisesti tuhottu materiaalisesti ja henkisesti. Jos esim. levyasema hajoaa tai muuta pientä, niin aivan hyvin voi tulla viikon käyttökatko palvelun palaamiseksi uudestaan linjalle, jos nopeasti korjaan laitteiston kuntoon eli tilaan heti Suomesta uutta rautaa rikkinäisen tilalle, jonka jälkeen kaikki onnistuu täydellisesti ja asiat menee kerralla nappiin kuin elokuvissa, kunhan harjoittelen sitä muutaman kertaa valmiiksi.

Viikon käyttökatko tarkoittaa vuodessa 98 % saavutettavuutta, jos ei huomioi muita katkoksia. 99 % pidetään yleensä tyydyttävänä tasona, 95 % eli puolen kuukauden off-line vuoden aikana on välttävä minimitaso, jonka alittamista pidetään rajana surkealle palvelinten toimintavarmuudelle. 99.9 % eli 8 tuntia 45 minuuttia on hyvä, 99.99 % eli 52 minuuttia 35 sekunttia erittäin hyvä, 99.999 % eli 5 minuuttia 15 sekuntia on erinomainen ja 99.9999 eli 31 sekuntia on jatkuva on-line. Jotkin pilvipalvelut lupaavat jopa 99.99995 % saavuttavuutta eli palvelin voi olla saavuttamattomissa vuoden aikana korkeintaan 15 sekuntia, Joskus Facebookin palvelimet olivat 5 -15 minuuttiin alhaalla eli kerran kymmenessä vuodessa poikkeuksellisesti 99.99 % – 99.999 % matalassa saavutettavuudessa, josta tuli jopa heti juttua moniin lehtiin [3, 4]. Kyse oli luultavasti kriittisestä (epäonnistuneesta?) päivityksestä sivuston palvelimiin, joiden jatkuvan yhtäjaksoisen toiminnan aikana työntekijämäärä oli kasvanut 10 000 kertaiseksi ja käyttäjämäärä 1 000 000 kertaiseksi edellisen huoltokatkon jälkeen.

Rautaa

Itse olen oman kuvan 1 mukaisen mini-itx -kokoisen NUC-koneen ostanut. Aiemmin ollut toinen Intel Atomilla varustettu mini-itx, mutta päätin sittenkin ostaa ihan uuden reilun 100 puntaa maksavan eli halvimman Celeronilla varustetun tietokoneen palvelinharjoitteluun [2]. Aiemman koneen kotelo oli varsin heikosti hengittävä.

Kuva 1. Itse ostin tällaista rautaa palvelinkäyttöön, harjoitusmielessä. [2]

On yllättävää huomata, että energispihejä mini-itx -koneita on jopa palvelinkäytössä nykyään [1]. Kuitenkin esim. blogit kuormittavat todella vähän palvelinta, selaimen päässä tapahtuva kuormitus on valtavasti suurempaa. Täten nykyajan palvelimissa usein riittää aivan hyvin kännykän prosessorin tasoinen suorituskyky vähintäänkin riittävästi. Useimmiten suuri osa palvelimista on lähes tyhjällä kuormalla, jos niitä käytetään vain pelkkien blogien tai yksinkertaisten verkkosivujen näyttämiseen jopa suurella kävijämäärällä.

Kuva 2.Räkki-mallin mini-ITX-palvelin. [5]

Haluan antaa erityisen kunniamaininnan tekstini oikolukemisesta Oikofix-sivustolle. Kyseinen sivusto on ehkäpä para suomen kielen oikolukija. Itse todennäköisesti oikoluen vastaisuudella sillä blogiartikkelini. [6]

REFERENSSIT

[1] Mini-itx.com: Servers
[2] Mini-itx.com: Intel NUC5CPYH
[3] YLE: Facebook ei toimi – vikaa selvitetään
[4] IL: Facebook ja Instagram kaatuivat ympäri maailmaa – alhaalla myös Suomessa: ”Jokin meni vikaan”
[5] Mini-itx.com: R1U200 – 20W Short Depth 1U Rackmount Servers with Low Power Consumption Celeron N2930 and 1 or 5 Intel LAN
[6] Oikofix – oikoluen tekstisi

Vastaa

Sähköpostiosoitettasi ei julkaista.

This site uses Akismet to reduce spam. Learn how your comment data is processed.