Kirjoittajan arkisto

Puolen Petan Fugu

tiistaina 15. joulukuuta 2015

Kirjoittajat: Henri Strand ja Jesse Hulkko.

Yhdistyksen uusi storage lähenee tuotannollista käyttöönottoaan. Tässä kohti on hyvä hieman istahtaa alas ja käydä läpi Kapsin tähän asti suurimman, toiminnallisesti kriittisimmän (ja hintavimman) infrauudistuksen tavoitteita, projektin eri vaiheita ja tämänhetkistä tilaa näin blogin välityksellä.

Jokaisella Kapsin jäsenellä on käytössään 500 gigatavua erikseen varmentamatonta tallennustilaa varmuuskopioille. Tätä tallennustilaa kutsutaan Siiloksi ja se on ollut käytettävissä jokaisen jäsenen kotihakemistosta kansiosta ”~/siilo/”.

Kuten yllä olevasta kuvasta näkyy, Siilo-levytila on ollut aktiivisessa ja alati kasvavassa käytössä. Kapasiteettia on lisätty tarpeen vaatiessa.

Kuten yllä olevasta kuvasta näkyy, Siilo-levytila on ollut aktiivisessa ja alati kasvavassa käytössä. Kapasiteettia on lisätty tarpeen vaatiessa.

Nyt eteen on tullut kriittinen tilanne; Siilo-levytila on käytännössä täynnä. Noin viisi vuotta sitten käyttöön otettu Siika-levypalvelin on lastattu täyteen kiintolevyjä ja se on palvelusikänsä päätteessä. Tilannetta ei helpota se, että Siika-palvelimen Solaris-pohjainen ZFS-järjestelmä on rajusti muokattu sekä useita major-versioita vanha. Siihen ei uskalleta enää tehdä suuria muutoksia. Ylläpidossa pidettiin jopa pienenä ihmeenä sitä, että Siika selvisi syyskuun alussa tapahtuneesta uudelleenkäynnistyksestä hengissä.

Siika-palvelimen käyttöönotosta voi lukea viiden vuoden takaisesta blogipostauksesta: https://blog.kapsi.fi/2010/09/29/270-teran-siika/

Uusi levyjärjestelmä — Fugu

Keväällä hankimme pitkällisen tallennusjärjestelmän uudistamisprojektin päätteeksi Dell Compellent SC8000 -levypalvelimen, jonka nimesimme japanilaisen pallokalalajin mukaan Fuguksi. Ensialkuun Fugussa on 504 teratavua eli noin puoli petatavua levytilaa. RAID-tekniikkojen käytön jälkeen käytettävää tallennustilaa jää noin 486 teratavua. Tämän arvioidaan riittävän nykyisen kasvun ja projektien puitteissa riittävän pitkään. Järjestelmä on myöskin laajennettavissa edelleen lisäämällä siihen levyhyllyjä.

Fugu koostuu useasta eri osasta: kahdesta toisiaan varmentavasta kontrollerista, SSD-levyhyllystä ja HDD-levyhyllystä. HDD-kiintolevyhyllyssä on 84 kpl 6 Tt NLSAS-kiintolevyjä ja SSD-hyllyyn on kalustettu nyt 8 kpl 1,9 Tt SSD-kiintolevyä. Käytännön räkkitilaa Fugu vie 42 räkkiunitin kaapistamme tällä hetkellä 11 räkkiunittia eli käytännön mitoissa vajaa puoli metriä.

Fugu-levypalvelin sisältää kaksi ohjainyksikköä, SSD-hyllyn ja aluksi yhden varsinaisen 5U kokoisen levyhyllyn. Yhdistyksen muuhun infrastruktuuriin liittytään yhdistyksen 10GE verkkoinfran kautta.

Fugu-levypalvelin sisältää kaksi ohjainyksikköä, SSD-hyllyn ja aluksi yhden varsinaisen 5U kokoisen levyhyllyn. Yhdistyksen muuhun infrastruktuuriin liittytään yhdistyksen 10GE verkkoinfran kautta.

Fugu saapui Nebulan konesaliin toukokuun lopussa, jonka jälkeen alkoi työmaa.

Työmaan suurin ongelma on nykyisten datojen siirto Fugulle. Suurin osa Siian datasta on jäsenten käyttöön tarkoitetun Siilo-tallennustilan tiedostoja. Toisiksi suurin yksittäinen datamassa koostuu Maanmittauslaitoksen avoimesta paikkatietoaineistosta, jota julkaistaan osoitteessa kartat.kapsi.fi.

ZFS jää myös uuden järjestelmän pääasialliseksi tiedostojärjestelmäksi. Itse Fugu tarjoaa ulospäin ainoastaan iSCSI-blokkilevyjä, joten tiedostojärjestelmä täytyy toteuttaa muulla tavoin. Kapsin käytössä on pitkään ollut NFS-pohjainen palvelinten välille jaettu levytila, joka on vanha, mutta toimiva teknologia. Puutteena on kuitenkin erityisesti metadata-tietojen hitaus suuria tiedostomääriä käsitellessä. Tämä tuli vastaan myös pyrkiessämme virtualisoimaan ZFS:ää toteuttavan NAS-koneen jakamaan NFS:ää yhdistyksen jäsenten käytössä oleville koneille. Tässä kohti varsin iso prioriteetti on kuitenkin saada Siilon varaama osa Siika-levyjärjestelmää poistettua käytöstä.

Fugun looginen topologia

Fugun looginen topologia: Fugu itsessään tarjoaa blokkilevyä iSCSI:n ylitse. Siilo on esimerkki jaetusta isokokoisesta yksittäisestä tiedostojärjestelmästä, jota käytetään yhtäaikaisesti useammalta koneelta. Toteutuksena Kapsilla käytetään ZFS:ää, joka on virtualisoituna nyt siilo.kapsi.fi -palvelimella.

Haluaisimme siirtää kaiken datan nopeasti Fugulle. Tämä ei tietenkään onnistu nopeasti tai varsinkaan yksinkertaisesti. Ensimmäinen yritys oli siirtää koko siilo-datamassa kerralla hyödyntäen ZFS:n tiedostojärjestelmätason lähetys- ja vastaanotto-ominaisuutta (zfs send ja zfs recv). Ongelmaksi muodostui juurikin datan pirstaloitumisesta aiheutunut erittäin hidas siirtonopeus, jonka puitteissa siirto olisi vienyt noin 3 kuukautta aikaa. Tämä ei aikataulullisesti käynyt päinsä, vaan migraatio päätettiin tehdä tiedostotasolla käyttäen perinteisempää rsync-menetelmää.

Rsync-menetelmän etu on siinä, että käyttäjät voidaan siirtää uutteen järjestelmään yksitellen, jolloin yhden käyttäjän kokema palvelukatko on hyvin lyhyt, vain jotain minuutteja. Lisäksi pystyimme käyttämään yhdistyksen toimihenkilöiden siilo-levytiloja koekaniinina ja korjaamaan varsinaisen migraation aikana tulleita virhetilanteita jo hyvin aikaisessa vaiheessa.

Tämän hetken tilanne – Siilon migraatio

Nyt uusi Siilo-levytila Fugu-palvelimen tarjoamana on käytössä jo 4/5 käyttäjistä eli tämän hetken käyttäjämäärällä noin 4800 käyttäjää ja sisältäen noin 137 teratavua dataa. Migraatio ei ole mennyt täysin ilman ongelmia. Uusi virtualisoitu ZFS-tiedostojärjestelmää tarjoava siilo-virtuaalikone on odotettua hitaampi ja vie huomattavan määrän CPU-aikaa suhteessa vanhaan järjestelmään.  Seuraavaksi parannamme virtualisoidun siilo.kapsi.fi -palvelimen suorituskykyä päivittämällä ZFS on Linux -ajurin sekä verkkoajurit uudempaan ja lisäämällä koneen käyttöön CPU coreja.

Suorituskykyyn liittyvien ongelmien ratkomisen jälkeen jatkamme migraatiota siirtämällä myös nykyiset käyttäjien varsinaiset kotihakemistot vastaavaan virtualisoidun ZFS on Linux -palvelimen palveltavaksi. Itse Fugu on osoittautunut erittäin nopeaksi ja toimivaksi ratkaisuksi. Kapsin ympäristössä haasteena on nimenomaisesti isokokoinen ja monelle koneelle jaettu yksittäinen tiedostojärjestelmä. Tästä on joka tapauksessa hyvä jatkaa ja kehittää yhdistyksen palveluita edelleen.

Suomalainen Edubox-palvelu maksuttomaan kokeilukäyttöön yhdistyksen jäsenille

tiistaina 24. helmikuuta 2015

Kapsin jäsenistölle on tarjottu Edubox-palvelu maksuttomaan kokeilukäyttöön maaliskuun loppuun saakka. Palvelussa on tarjolla hieman yli sata opintokokonaisuutta liittyen erilaisten Internet-palveluiden ja tietokoneohjelmistojen peruskäyttöön sekä jonkin verran yleisesti tietotekniikkaan. Kokonaisuudet on jaettu lyhyisiin muutaman minuutin esityksiin aiheittain.

Palvelu löytyy osoitteesta www.edubox.fi. Tutustumaan pääsee rekisteröitymällä käyttäen @kapsi.fi -sähköpostiosoitetta, jonka jälkeen materiaalit ovat vapaasti katsottavissa 31.3.2015 saakka. Toivomme palautetta palvelun hyödyllisyydestä ja kiinnostavuudesta blogin kommentteihin!

HELP! Minulla ei ole yhdistyksen sähköpostia käytössäni?!

Yhdistysken sähköpostilaatikko on olemassa kaikilla jäsenillä ja oletusarvoisesti osoitteet ovat muotoa tunnus@kapsi.fi. Helpoiten pääset tarkistamaan sähköpostisi kirjautumalla Webmailiin tunnuksillasi. Lisää ohjeita sähköpostiin liittyen löytyy yhdistyksen verkkosivuilta: https://www.kapsi.fi/ohjeet/email.html

Yhteistoiminta, yhdistys ja tulevaisuus – atlas.kapsi.fi

sunnuntaina 28. syyskuuta 2014

Santtu lupaili edellisessä blogipostissa Atlassianin ohjelmistoja Kapsin tarjoamaa yhteis- ja yhteisötoimintaportaalina kaikkine projekti- ja ohjelmistospesifisine höystöineen. Tarve saada Kapsilaiset mukaan toimintaan muokkaamaan ja kommentoimaan sisältöä realisoituikin yllättävän nopeasti ja ensiversio yhteisöportaalista on auki yhdistyksen jäsenille nyt. Aloitimme Confluence-ryhmätyöympäristön turvin ja muut osa-alueet täydentyvät syksyn edetessä. Aluksi liikkeelle lähdetään lähinnä Kapsiin itseensä liittyvin projektein. Myöhemmin jäsenet voivat saada käyttöönsä omia työtiloja projekteilleen sekä mahdollisuuden liittää wiki- ja projektiympäristöön myös kapsin ulkopuolisia käyttäjiä.

Projektin ensimmäisen vaiheen vauhdittava voimana toimi kesän aikana alkanut pohdinta yhdistyksen tulevaisuudesta ja toiminnan eteenpäin viemisestä. Pohdinta muuttui kirjoitelmaksi ja kirjoitelma jaloistui kokonaisuudeksi, joka oli valmis yhdistyksen aktiivisten toimihenkilöiden kommenteille noin viikko sitten. Hyvin nopeasti kävi selväksi, että kirjoitusharjoitus ei välttämättä mennyt asiasisällöltään aivan metsään ja siitä syntyi hyvää keskustelua ja jatkomietintää toimariporukan sisällä.

Näin vaalikokouksen alla on väistämätöntä, että yhdistyksen tulevaisuutta koskevat visiot ja pohdinnat tulevat väistämättä vaikuttamaan siihen, mistä vaalikokouksessa keskustellaan. Tästä syystä on ensiarvoisen tärkeää, että kaikilla yhdistyksen jäsenillä on mahdollisuus omalta osaltaan osallistua tähän keskusteluun ja tuoda ajatukset esille, vaikka itse kokoukseen ei pääsisikään osallistumaan.

Pidemmittä puheitta, kirjautumaan pääsee Kapsin käyttäjänimellä ja salasanalla: atlas.kapsi.fi

Kommentteja toivotaan ensialkuun nyt erityisesti artikkeliin Kapsin Visio ja Strategia vuodesta 2015 tulevaisuuteen.

[Edit: Typo korjattu.]

Kapsin toimarimiitti syyskuussa 2013

keskiviikkona 2. lokakuuta 2013

Kapsin toimihenkilöt ovat kokoontuneet muutaman viime vuoden aikana säännöllisen epäsäännöllisesti käymään läpi yhdistyksen toiminnan tilaa, suunnittelemaan tulevaisuutta ja tekemään pieniä säätörupeamia saunan, ruuan ja hyvän seuran merkeissä. Edellisestä toimareiden kokoustuksesta on vierähtänyt jo jopa luvattoman kauan. Monet asiat kaipaavat kipeästi huomiota, mielipiteitä ja keskustelua.

DSCF3048

 Toimarit säätötunnelmissa. Kuva: Jarkko Vääräniemi

Tämänkertaisen toimarimiitin paikkana toimi Technopolis Vantaalla. Agendana esille nousi erityisesti ylläpidotoiminnan tila, ylläpidon henkilösidonnaisen tietotaidon saattaminen paremmin muiden ylläpitäjien tietoon, tulevaisuuden mahdolliset palvelukonseptit sekä yleiset yhdistyksen toimihenkilöstön organisoitumiseen liittyvät seikat. Ohessa säädettiin tekniikkaa, vaihdettiin kuulumisia sekä nähtiin myös harvemmin fyysisesti havainnoitavissa olevia toimareita.

Kapsin kaltaisen yhdistyksen tärkeintä pääomaa on henkilöiden tietotaito yhdistyksen toiminnan kannalta merkityksellisestä teknologiasta. Tämän tietotaidon saattaminen mahdollisimman laajan joukon tietoon palvelee ylläpitotoiminnan jatkuvuuden turvaamisen tavoitteita sekä edesauttaa ylläpitäjien yleistä teknistä osaamista. Uutena asiana tulee kiinnittää erityistä huomiota myös yleisluontoisen tietotaidon saattamiseksi yhdistyspiirin ja toimariporukan ulkopuolelle. Tällä edistetään yleistä tietotekniikan osaamista, joka on myös yksi yhdistyksen toiminnan keskeisistä tavoitteista.

IMG_0292

Odottelemassa paluukyytiin nousua, erota kapsilaiset? Kuva: Olli Vainio

 

Muita esille tulleita visioita olivat muun muassa selkeä helppokäyttöisen, salatun varmistus- ja tiedonjakopalvelun saaminen yhdistyksen jäsenistön käyttöön. Tavoitteena on löytää ratkaisu, joka mahdollistaisi jokaiselle jäsenelle kunnollisen laitteiden varmennuksen Kapsin levytilaan sekä mahdollisuuden tietojen jakamiseen helposti laajemmalle yleisölle. Eri varmennuspalveluratkaisuja kartoitetaan. Varmennusten lisäksi myös muita Kapsin jäsenpalvelukonseptiin sopivia valmiita palvelukokonaisuuksia etsitään. Yhdistyksen omaan ohjelmistokehitykseen käytettävät resurssit eivät nykyisin harrastajavoimin tule riittämään erityisten palvelukokonaisuuksien tekemiseen harrastajavoimin.

IMG_0311

Tämän blogin muodostuminen paluulennolla. Kuva: Olli Vainio

Kapsin omista ohjelmistoprojekteista tapetilla oli myös Sikteeri, yhdistyksen jäsenhallinta, jonka prosesseja hiottiin sekä joitain uusia ominaisuuksia taidettiin jopa keretä koodata toimarimiitin aikana. Luonnollisesti sopivassa rinnakkaisajossa saunomisen kanssa. Myös Sikteeri-projekti kaipaisi lisää resursseja, jotta kahvia saataisiin muutettua koodiksi toisinaan hieman vauhdikkaammin.

Kapsi kehittyy säätö säädöltä, miitti miitiltä ja sauna saunalta aina vain paremmaksi. Tästä on siis kovin hyvä jatkaa kohti uusia haasteita.

Linux – HA – grsec – BFS – Kapsi – ???

perjantaina 30. elokuuta 2013

$ uname -a
Linux lakka 3.2.46-grbfs-kapsi #1 SMP Wed Jun 5 19:48:35 EEST 2013 x86_64 GNU/Linux

Niin mistä puhe?

Ydin eli kerneli (engl. kernel) on tietokoneen käyttöjärjestelmän alin osa, joka mahdollistaa kaikkien muiden tietokoneen ohjelmien toiminnan. ( Wikipedia )

Mikäli olet sinut Kapsin tarjoamien palveluiden kanssa oletan, että tiedät vähintäänkin pääpiirteissään mistä tässä kaikessa on kyse. Nyt vajotaan ihan vähäisesti pintaa syvemmälle niihin periaatteisiin ja perusteisiin, jotka ovat olleet Kapsin Linux-käyttöjärjestelmäytimen kasauksen ja konfiguraation pohjana.

Yleistä Kapsin kerneliarkkitehtuurista

Ensimmäinen huomionarvoinen seikka Kapsin järjestelmiä tarkastellessa on se, että vaikka käytössä on pääosin Debian-distribuution mukaisia järjestelmiä, käytetty käyttöjärjestelmäydin ei ole Debian-projektin tarjoama. Kapsin ylläpito on varsin varhaisessa vaiheessa yhdistyksen historiaa alkanut ylläpitää omaa versiota Linux-kernelin käännöksestä. Tämä ei tarkoita sitä, että käytössä olisi  mitenkään suuresti normaalista Linux-ytimestä eroava versio, vaan pikemminkin lähtökohdiltaan Kapsin käyttämän laitteiston sekä tarpeiden mukaan säädetty versio kulloinkin vakaaksi todetusta ”vanilla”-versiosta.

Ymmärtääksemme nykyisen tilanteen kunnolla, täytyy tarkastelussa palata historiassa taaksepäin, aikaan vuosia ennen kuin itse liityin tähän kirjavaan joukkoon ylläpitäjiä, joiden prioriteetti on pitää Kapsin järjestelmät turvassa ja toimivina. Kapsin historia alkoi vuonna 2003.

Linux 2.6 joulukuussa 2003 lisäsi XFS- ja JFS-tiedostojärjestelmät, sisälsi uudet ALSA-ääni- ja syöttölaitteiden ajuritNPTL-säikeistyksen tuen ja tehosti käyttöä suurissa järjestelmissä.

Linux 2.6 oli Kapsin ensimmäisten toimintavuosien ajan ”uusi juttu”. Mentiin Debianinkin käyttämän 2.4-sarjan voimin hyvin pitkään. Nykyään  käytössä on vielä 3.2-sarjan kerneli, jota päivitetään eteenpäin käytännössä Kapsin käyttämien patchien sekä muun mahdollisen tarpeen mukaisesti.

Kernelin päivitykset ovat yhdistyksen toimintojen kannalta aika voimakkaasti käyttäjille näkyviä operaatioita ja aiheuttavat varsinkin shellipalveluihin ikävän käyttökatkon. Tästä syystä toimivaa ja turvallista kerneliversiota pyritään ajamaan mahdollisimman pitkään.

Kapsin käyttämät kernelipatchit

Kapsin kernelin suunnittelussa on otettu huomioon useita erityisesti yhdistyksen toimintaa koskettavia tekijöitä. Haasteina on ollut erityisesti tietoturva, suorituskyky sekä järjestelmien vakaus pitkänkin yhtäjaksoisen päälläolon jälkeen.

Käydään hieman läpi Kapsin käyttämiä patcheja sekä niiden taustoja ja osuutta kokonaisuudessa.

HA-patch

Kapsin historian alkuaikoina käytetyistä spesiaalisäädöistä tiedän vain sen verran, että käytössä oli jo tuolloin niinsanottu HA-patch. Nimi ei viittaa ”High Availabilityyn” kuten äkkiseltään voisi kuvitella, vaan patchin tekijöiden sukunimien ensimmäisiin kirjaimiin. Patchin kirjoitti Jaakko Heusala, yhdistyksen alkuvuosien puheenjohtaja ja ylläpitäjä usean vuoden ajalta. Jaakko osasi kertoa kommenteissa tämän historiasta sekä nimeämisestä, joten lainaan Jaakkoa tähän: 

”Tuo HA-pätsin nimi tulee ”huoh access limit” lyhennyksestä, koska käytin silloin nimimerkkiä huoh. Osittain se ehkä viittasi myös siihen fiilikseen, että oli etsitty toimivaa ratkaisua simppeliin ongelmaan maailmalta kuitenkaan hyvää ratkaisua löytämättä ja se pätsi oli vähän sellainen tulos ”nyt se kernelin koodi tänne, korjaan sen itse!” (Kernelin muokkaaminen oli melkeinpä niitä viimeisiä juttuja joita halusin ruveta tekeen silloin.)”

HA-patch on pohjimmiltaan hyvin yksinkertainen. Sen tarkoitus on pitää käyttäjien tiedostot piilossa toisilta käyttäjiltä chmod-määreistä riippumatta. Tämä on käyttäjille näkyvin muutos Kapsin kernelin osalta. HA-patch on myös koodillisesti erittäin yksinkertainen ja on siten tominut lähes muutoksitta aina versioista 2.4 asti.

Grsecurity

Toinen merkittävä virstanpylväs yhdistyksen kernel arkkitehtuurissa on grsec. Se on laaja patchset, jonka tarvoite on antaa lisäsuojaa erilaisia mahdollisia käyttöjärjestelmäytimen haavoittuvuuksien hyödyntämisyrityksiä vastaan. Kapsin tietoturva-arkkitehtuurissa grsecistä on pitkään käytetty sellaisia osia, jotka eivät vaadi suuria järjestelmäriippuvaisia konfiguraatioita. Esimerkiksi RBAC (Role Based Access Control) ei ole ollut toistaiseksi laajassa käytössä.

Grsecin ajatus tietoturvan kannalta on toimia yhtenä monista muuttujista, joita mahdollisen haavoittuvuuksia hyödyntävän hyökkääjän on vaikea ottaa huomioon yhdistyksen järjestelmiin suunnattuja toimia pohtiessaan. Lähtökohtaisesti grsec ei koskaan pysty täydellisesti estämään muun kernelin osa-alueen haavoittuvuuden hyödyntämistä, vaan aiheuttaa lähinnä tarpeen kohdistaa hyökkäystä juuri tätä kyseistä ympäristöä vastaan. Toisinsanoen yleisesti saatavilla olevat hyökkäyskoodit eivät välttämättä, toivottavasti, toimi sellaisenaan sopivin grsecin tarjoamin optioin varustettua järjestelmää vastaan. Käytännön kannalta grsec parhaimmillaankin ostaa ylläpidolle vain aikaa järjestelmän päivityksen valmisteluun.

Grsecin ja HA-patchin lisäksi kernelin suojauksessa on käytössä yksi vähemmän ”hieno”, mutta enemmän käytännönläheinen ajatusmalli turvallisuuteen liittyen. Pohjimmaisena on periaate, jonka mukaan kerran käynnistettyä järjestelmäydintä ei tule voida peukaloida. Grsec tarjoaa itsessään jonkin verran erilaisia kernelin muistialueen suojauksia tähän liittyen, mutta haittaohjelmien ja rootkittejen kannalta yleisin toimintamalli riitävät oikeudet hankittuaan on puuttua suoraan käytössä olevan kernelin toimintaan.

Kernelimoduulituki

Helpoin ja toimivin tapa muuttaa kernelin toimintaa järjestelmän ollessa käynnissä on ladata moduuli, joka toteuttaa hyökkääjän kannalta oleellisia toimintoja. Nämä voivat olla esimerkiksi kyseisen modulin olemassaolon ja tiettyjen hyökkääjän käyttämien palveluiden ja verkkoliikenteen piilottaminen koko muun järjestelmän näkyviltä. Tällainen palikka tunnetaan myös nimellä rootkit.

Kapsin lähestymistapa rootkiteiltä suojautumiseen on tehdä kernelistä mahdollisimman vaikeasti muutettava ajon aikana. Linux-järjestelmissä tähän on olemassa erittäin helppo ja yksinkertainen keino. Kernelistä on jätetty moduulituki kokonaan pois, jolloin kernelin muuttamiseksi vaaditaan koneen uudelleenkäynnistys. Kapsin kerneli on rakennettu juurikin näin.

Schedulointi ja BFS

Tästä aiheesta voisi ja ehkä pitäisikin kirjoittaa ihan oma blogiposti – tai kirja. Sen verran tuntuu olevan vaikeasti lähestyttävä kokonaiskonsepti kyseessä. Käydään nyt kuitenkin asia läpi popularistisellä tasolla ja yksinkertaistettuna niin ettei aiheuteta lukijoille välttämättä päänsärkyä.

Isoa shell-käyttäjämäärää palvelevan linux-koneen haasteena on väistämättä suoritettavien prosessejen suuri määrä. Kapsi ei ole toiminnassaan koskaan pyrkinyt asettamaan tiukkoja rajoja, vaan käyttäjien toimille asetetut järjestelmätason rajat pyrkivät vähentämään mahdollisten väärinkäytösten, tahattomien tai tahallisten, aiheuttamaa haittaa järjestelmän muille käyttäjille.

Yhdeksi merkittäväksi haasteeksi linuxin ja suuren prosessimäärän kanssa nousee interaktiiviset prosessit, jotka käyttävät yleensä hyvin pienen määrän suoritinaikaa kerrallaan, mutta todella usein. Esimerkkejä tällaisista interaktiivisista prosesseista ovat vaikkapa verkkoliikennettä vastaanottavat prosessit, jotka heräävät käsittelemään saapuneita paketteja tai SSH tai irssi, jotka ottavat käyttäjän syötteitä vastaan ja pitävät yllä aktiivisia yhteyksiä internettiin.

Suuri määrä interaktiivisia prosesseja on luonteeltaan haastava kuorma kernelille koska kernelin prosessischeduleri joutuu pitämään kirjaa ja tekemään päätökset siitä, mikä prosessi milloinkin saa suoritinaikaa ja mitkä prosessit joutuvat odottamaan pääsyä suoritukseen. Tämä kernelin sisäinen prosessi vie myös itsessään suoritinaikaa ja koneen resursseja riippuen kernelin sisäisen schedulerin toimintaperiaatteesta ja tehokkuudesta päätöksenteossa sekä seurannassa.

Linux-kernelin oletusarvoinen prosessischeduleri tunnetaan nimeltä CFS (Completely Fair Scheduler). Se pyrkii tarjoamaan tasa-arvoa prosessien suoritinajan suhteen ja päästää vähäisesti suoritinaikaa käyttävät prosessit suoritettavaksi useammin kuin pitkään suoritettavat prosessit. Tämä periaate on sinänsä hyvä ja toimiva, mutta Kapsin kaltaiesssa ympäristössä CFS:n toteutus aiheesta jätti huomattavasti toivomisen varaa.

Kapsin pääasiallinen shellipalvelin, Lakka, kärsi huomattavasta hitaudesta aina iltapäivisin ruuhka-aikaan talvella 2010. Tuolloin käytössä oli vielä HP DL380 G5 -sarjan palvelinkone, jossa oli kaksi fyysistä neljän ytimen suoritinta ja 16 Gt muistia.

lakka-kapsi-fi-vmstat-year-png

VMstat-kuvaaja kertoo suoritusta odottavien prosessejen määrän arvona ”running” ja levyoperaatioita odottavien prosessejen määrän arvona ”I/O sleep”. Running-arvon tulisi olla kaikissa tilanteissa pienempi kuin käytettävien prosessoriytimien määrä parhaan suorituskyvyn takaamiseksi. Kuvaajan vasen laita on ajalta ennen siirtymistä BFS-scheduleriin.

Ylläpidolla oli kaksi vaihtoehtoa hitailun ratkaisemiseksi. Joko hankkia uusi, järeämpi palvelinkone tai yrittää löytää resurssiongelmaan jokin muu ratkaisu. Käyttäjien toimien rajoittaminen ei kuulunut edes tuolloin harkittuihin vaihtoehtoihin.

Havaittiin eräänlainen ristiriita prosessejen suoritusjonon ja koneen CPU:n käyttöasteen välillä.

lakka-kapsi-fi-cpu-year-png

Kuvassa Lakka-palvelimen CPU-käyttö. CFS:n ollessa käytössä (kuvan vasen laita) CPU-resursseista oli käytössä yhteensä vain noin 25 %. Kuvaajan ”hassut” arvot oikealla johtuvat kyseisten kerneliversioiden epävakaudesta sekä lukuisista käyttökatoista vuoden 2010 aikana.

Suoritusjonon ja CPU-käytön välinen ristiriitatilanne antoi viitteitä siitä, että ehkä kernelin toiminnassa voisi olla parantamisen varaa prosessien scheduloinnin suhteen. Tutkittiin vaihtoehtoja ja päädyttiin kokeilemaan BFS-patchia Kapsin kernelissä. Muutos oli aika radikaali ja hitailuongelmat kerralla poissa.

Tässä vielä muutama kuva, jotka antavat käsitystä koneen yhtäaikaisten käyttäjien määrästä.

lakka-kapsi-fi-interrupts-year-png

Context switches -arvo kertoo sen, kuinka usein suoritettava prosessi vaihtuu sekunnin aikana. Oikealla olevat piikit ovat jälleen kerneliongelmien aiheuttamia vääristymiä kuvaajissa.

Tämä kuvaaja on lähinnä referenssiksi siitä, että CFS:sta BFS:iin vaihtaessa koneen käyttöaste ei juuri muuttunut. Vuosien 2010 ja 2011 aikana yhdistys kuitenkin sai paljon uusia jäseniä ja toisaalta shellikoneella alettiin myös ajamaan entistä raskaampia palvelinprosesseja kuiten Minecraft-palvelimia.

lakka-kapsi-fi-ps_sshd-year-png

SSHd-prosessien määrä Lakka-palvelimella CFS:sta BFS:iin siirryttäessä ja sen jälkeen.

SSHd-prosessien määrä kertoo yhtäaikaisesti palvelimella kirjautuneena olevat sessiot. Vaaleamman vihreä alue näyttää vuorokausivaihtelun kirjautumismäärissä. Käyttäjämäärien nousu vuoden 2011 alkuun mennessä on kohtuu huomattava.

Kokonaisuudessaan siirtyminen Kapsin kernelissä CFS-schedulerista BFS-scheduleriin ei ollut helppo tie. Epävakaus oli vuoden 2010 aikana todellinen riesa ja vasta Linux-kernelin VM (Virtual Memory) -kokonaisuuden suurempi korjaus toi lopulta helpotuksen vakausongelmiin. Suorituskyky nousi kuitenkin vaihdoksen myötä aivan uudelle tasolle, kun prosessien schedulointi ei enää ollut pullonkaula järjestelmän toiminnassa.

 

Teknisempää settiä voi seurata tai olla seuraamatta riippuen blogaajien mielenkiinnosta, käytettävissä olevasta ajasta sekä kuun asennosta. Kuulostellaan myös lukijoiden mielenkiintoa aiheeseen. 😉

Onnea Kapsi!

lauantaina 2. helmikuuta 2013

kapsi-logo-vari-tarkenne

Kiitos!

Kaikki eivät varmasti tunne yhdistyksen historiaa niin hyvin, että tietäisitte tämän merkityksen. Kaikki eivät ole olleet yhdistyksen toiminnan piirissä niin pitkään, että tämä herättäisi suuria tunteita. Kaikki eivät ole välttämättä tulleet ajatelleeksi niitä lukuisia ilon, surun, tuskan, väsymyksen, riemun, turhautumisen, onnistumisen ja välillä myös ylpeyden aiheita, jotka ovat yhdistyksen matkan varrella kohdanneet niin ylläpitoa, hallintoa kuin yhdistyksen jäsenistöäkin.

Kapsi on tullut toiminnan vakiintuneisuutta kuvaavaan ikään. Kapsi on 10 vuotias.

Kiitos jokaiselle Kapsin jäsenelle! Te tuotte tälle toiminnalle tarkoituksen ja teette tämän mahdolliseksi!

Kiitos yhdistyksen toimihenkilöille! Te olette tehneet omalla panoksellanne yhdistyksestä toimivan kokonaisuuden!

Sekä kiitos kaikille kumppaneille, joiden kanssa Kapsi on saanut toimia ja kasvaa yhdistyksenä nykyiseen muotoonsa!

Kapsin kymmenvuotinen taival on pitänyt sisällään runsaasti tapahtumia ja vaiheita. Itse aloitin Kapsin piirissä puuhastelun liittymällä jäseneksi syksyllä 2004. Tuolloin yhdistykseen kuului noin 200 jäsentä. Oli yhdistyksen toinen toimintavuosi. Liittymisestäni asti, vajaan yhdeksän vuoden ajan Kapsin toiminta on kehittynyt jatkuvasti pienin tasaisin askelin kohti nykyistä tilannetta. Kehitys jatkuu edelleen ja sitä ajaa yksinomaan jäsenistön tarpeet luotettaville, huolella ja taidolla ylläpidetylle alustalle, jonka päälle on hyvä rakentaa itselle merkittäviä palveluita.

Vajaan yhdeksän vuoden aikana Kapsista on muodostunut minulle elämäntapa. Yhdistyksen monimuotoinen toiminta on antanut puitteet omien taitojen kehittymiseen ja verkostoitumiseen IT- ja tietoliikennealan ammattilaisten kanssa. Mielenkiintoista puuhaa löytyy aina, kun sille itseltä löytyy aikaa. Isot ja pienet asiat etenevät päivä päivältä. Kapsi jatkaa kehitystään ja minä pienenä osana kokonaisuutta sen mukana. Suunnataan siis yhdessä kohti seuraavaa vuosikymmentä ja uusia haasteita!

Kiitos Kapsista kuuluu teille kaikille!

 

Cyber Defence Exercise 2012 – CDX12

perjantaina 19. lokakuuta 2012

Tammikuu 2012, IRC-chat, yksityisviesti:

”Haluasikohan Kapsin ylläpito osallistua kybersotaharjotuksen harjotukseen =)”

Näin alkoi eräs hyvin mielenkiintoinen keskustelu, joka johti omaltani sekä yhdistyksen kannalta vieläkin mielenkiintoisempaan tapahtumaketjuun. Meille tarjottiin tilaisuus osallistua kansainväliseen CDX12-kybersotaharjoitukseen pienessä sivuroolissa. Olimme Viron Cyber Defence Leaguen ohella toinen ”koekaniiniryhmä”, jonka tarkoitus oli testata harjoituksen skenaariota sekä infraa noin kuukausi ennen varsinaista harjoitusta.

Helmikuun alku. Harjoituksen testiajo lähestyi. Ylläpidosta kasattiin kymmenen hengen ”Blue Team” osallistumaan harjoitukseen. Erilaisia valmistelevia pohdintoja alettiin pitää mahdollisista tekniikoista, joilla erilaisiin infraa vastaan kohdistuviin verkkohyökkäyksiin voitaisiin parhaalla mahdollisella tavalla vastata. Strategian pohjaksi valittiin tietysti Kapsin oma tietoturvamalli ja samat tekniikat, jotka on käytössä myös yhdistyksen järjestelmien suojaamisessa. Pohdittiin uusia tapoja havainnoida hyökkäyksiä ja löytää järjestelmästä poikkeavuuksia. Koodia syntyi, speksi kehittyi.

All hands on deck!

Ylläpitäjäjoukko saa hälytyksen. Kansallisesti merkittävän Internet-operaattorin järjestelmiin kohdistuu parhaillaan kyberhyökkäys! Operaattorin pääasiallinen ylläpitotiimi on poissa ja tavoittamattomissa. Kasataan porukka, joka ei tunne infraa juuri entuudestaan. Dokumentaatio ei ole ajan tasalla. Verkkokuvista ja järjestelmäkuvauksista on jotain apua tilanteen hahmottamisessa. Omituisia asioita tapahtuu eri puolilla verkkoja.

Kapsin urhoollinen task force kokoontuu saman katon alle, tälläkertaa yhdistyksen pieneksi käyvään toimitilaan, selvittämään tilannetta ja turvaamaan infraa. Osa järjestelmistä on todella vanhoja, päivittämättä ja pahasti haavoittuvia. Tuntemattomassa tilanteessa infra täytyy saada nopeasti haltuun. Mahdollisimman moni julkisesti saatavilla oleva järjestelmä päivitetään ja Linux-kernelit vaihdetaan Kapsin omiin käännöksiin. Varustelu on alkanut.

Kaikkien järjestelmien logit ajetaan keskitettyyn paikkaan ja filtteröidään isolle screenille kaikkien nähtäville. Jos jotain merkittävää tapahtuu, se näkyy kaikille heti. Muut havainnointi ja vastatoimet alkavat olla paikoillaan.

Verkkotiimi alkaa päästä ennalta tuntemattoman palomuuriratkaisun jäljille. Verkko on ensimmäinen elementti, jossa hyökkääjä voidaan havaita. Samalla myös viimeinen työkalu, jolla mahdollinen tunkeutuja saadaan irti järjestelmistä. Ennakkovalmisteluja ei juuri verkon osalta keretty tekemään. Nyt mennään vaistojen ja pitkän kokemuksen turvin. Verkkotiimissä on kaksi henkilöä, mukana on Kapsin ylläpitotiimin tuolloin tuorein vahvistus, pitkän linjan kokenut verkkosäätäjä.

Hyökkäyksiä aletaan havaita. Jollain koneella on backdoor. Onneksi tilanne näkyy heti ja hälytykset sekä vastatoimet toimivat. Hyökkääjä on järjestelmistä ulkona jo ennen kuin tilanteeseen keretään reagoida. Kolmen ylläpitäjän vahvuiselle response-teamille jäi tälläerää vain takaoven siivoilu järjestelmästä.

Tästä eteenpäin hyökkäyksiä tulee useita yhtäaikaisesti ja kädet täyttyvät töistä. Operaattorin asiakkaiden WWW-sivuja onnistutaan töhrimään PHP-reiän kautta. Myös web-palvelimelle yritetään rootiksi, mutta jälleen kerran tuloksetta. Response-team hoitaa Linux-järjestelmiä jatkuvasti parempaan suuntaan ja paikkailee löydettyjä haavoittuvuuksia ja konfiguraatiovirheitä.

Windows-rintamalla yritetään asennella päivityksiä ja tarkastaa turvallisuusasetukset kohdalleen. Osa Windows-työasemista simuloi yrityksen hallinnon käyttöä. Käyttäjät availevat sähköpostilla tulleita linkkejä ja tiedostoja. Yksi PDF-tiedosto jäi verkkotiimin pystyttämään web-proxyyn. Haitanteko estyi jo ennalta.

Sähköpostipalvelimet eivät toimi. Harjoitusinfrassa on selkeitä ongelmia virtuaalikoneiden levyjen kanssa. Järjestelmät ovat hitaita ja osa koneista täysin käyttökelvottomia. Harjoituksen tekninen tiimi tutkii tilannetta. Ongelmiin ei saatu ratkaisua testiajon aikana. On syytä käydä asiat läpi ennen varsinaista harjoitusta. Testitiimejä oli kaksi, varsinaisessa harjoituksessa on yhdeksän. Tilanne ei näytä erityisen hyvältä.

Tutustun hieman tarkemmin harjoituksen taustalla olevaan tekniseen ympäristöön. Käy ilmi, että SAN-valmistajan ilmoittama levyjärjestelmän vauhti ei aivan vastaa reaalimailman toteumaa. Täytyy keksiä jokin vaihtoehtoinen ratkaisu. Aikaa on alle kolme viikkoa.

Kapsin uusi Siika-levyjärjestelmä otettiin ajoon reilut kaksi kuukautta aiemmin. Sitä ennen testausta tehtiin lähes vuosi. Pohdinta siirtyi Siika-järjestelmän hyödyntämään Solaris-pohjaiseen OpenIndiana-käyttöjärjestelmään ja sen ZFS-tiedostojärejstelmään. Saataisiinko tehokkaalla cachella riittävän paljon suorituskykyä olemassaolevalla raudalla, jotta testiajon ongelmat eivät toistuisi? Asiaa täytyy kokeilla käytännössä.

Kaksi Kapsin ylläpidon edustajaa pystyttää yhdelle blade-palvelimelle OpenIndianan. Levyt tulevat SAN-järjestelmästä 10 Gbps -verkon ylitse. Alustavat suorituskykyarvot vaikuttavat erittäin lupaavilta. Testauksen jälkeen päädytään siihen yhdessä teknisen tiimin kanssa, että tämä on paras ratkaisu mikä tällä aikataululla on järjestettävissä. Muita virtualisointijärjestelmän osa-alueita hienosäädetään. Harjoitus lähestyy.

To be continued, mikäli lukijoita kiinnostaa… 😉

Kapsilta poistettujen HP-palvelinten lahjoitus

tiistaina 27. joulukuuta 2011

Tänää maanantain puolella pidetyssä hallituksen kokouksessa päätettiin Kapsin käytöstä poistettujen HP:n palvelinkoneiden kohtalo. Hakemukset on nyt käsitelty ja lahjoituspäätökset tehty.

Valinnassa painotettiin toiminnan laajuutta, jatkuvuutta sekä kykyä hyödyntää lahjoitettavaa kalustoa. Valinnassa huomioitiin erityisesti sellaiset tarpeet, joita ei ole mahdollista toteuttaa Kapsin tarjoamin jäsenpalveluin tai hakijayhdistyksen omin voimin ilman lahjoitettavaa palvelinta.

Hakemuksia tuli yhteensä 21 kpl, joista 18 päätyi käsiteltäväksi. Kolme hakemusta hylättiin, koska lahjoituksen hakija ei edustanut rekisteröityä yhdistystä. Periaatepäätös poistettujen palvelimien lahjoituksesta on tehty yhdistyksen vaalikokouksessa vuonna 2009.

Suurin osa hakemuksista oli todella hyvin kirjoitettu ja niistä selvisi toiminnan tarkoitus sekä konkreettiset suunnitelmat lahjoitettavan palvelimen varalle. Tämänkertaisista hakemuksista kuitenkin kävi erittäin selväksi, että monet yhdistykset kaipaavat pohjimmiltaan tietynlaisia palveluita, jotka olisivat hyvinkin toteutettavissa Kapsin resurssein.

Pyrimme jatkossa aktiivisesti kehittämään palveluita myös yhdistyksien tarpeisiin. Tavoitteemme on, että yhdistykset voivat keskittyä paremmin tarkoituksensa toteuttamiseen Kapsin keskittyessä toteuttamaan puolestaan omaa tarkoitustaan tuottamalla jäsenilleen Internet-palveluita. Näkisin, että tähän mennessä olemme onnistuneet tässä tehtävässä loistavasti ainoastaan yksityisjäsenten osalta. Yhdistysten yleiset tarpeet ovat kuitenkin usein erilaiset emmekä ole Internet-painotteisena yhdistyksenä osanneet vastata niihin riittävän hyvin.

Lahjoituksen saajat

Lahjoitukset päätyivät hallituksen päätöksellä seuraavanlaisiin kohteisiin.

HP DL380 G5, entinen lakka.kapsi.fi:nä palvellut rauta lahjoitettiin Tietokonekerho LanTrek ry:lle. LanTrek järjestää Tampereella vuosittain huomattavan isoa verkkopelitapahtumaa sekä toimii aktiivisesti verkkopeliscenen hyväksi yhteistyössä muiden järjestäjien kanssa. Hakijoista kaksi oli niin tasavertaisia, että emme kyenneet valitsemaan niiden väliltä, joten lopullisen tuloksen LanTrekin eduksi ratkaisi arpa.

HP DL320s G1, entinen herukka, Kapsin varmuuskopiopalvelin lahjoitettiin Päivölän kansanopiston kannattajayhdistys r.y:lle. Yhdistys ylläpitää kansalaisopistoa ja edistää koulutustoimintaa suomessa. Kapsilta poistunut palvelin menee hoitamaan oppilaitoksen keskitetyn levypalvelimen virkaa entisen, levytilaltaan sekä resursseiltaan pieneksi jääneen laitteen tilalle.

Kiitos kaikille hakijoille. Olisimme mieluusti jakaneet enemmänkin palvelinkalustoa eteenpäin, mikäli olisi mitä jakaa. Käytettyä palvelinkalustoa yhdistyskäyttöön voi kysellä myös yliopistoilta sekä suuremmilta alan yrityksiltä.

Otamme vielä erikseen yhteyttä niihin hakijoihin, joiden hakemuksessa esitetyt tarpeet voisivat olla täytettävissä Kapsin tarjoamin palveluin.