VDI katkos #1
Olen selvästikin täysin korvaamaton KyAMK:lle. Samana päivänä kun viikon lomani alkoi, VDI-ympäristö kaatui. Jälkikäteen kuultujen raporttien perusteella voin kertoa tapahtuneesta seuraavaa..
Allekirjoittaneen jossain vaiheessa asennusta tekemä (ja unohtama) NFS mount levyjärjestelmästä yhdelle brokerille (levytilaa VDI-imagejen siirtoa varten) aiheutti toistaiseksi tuntemattomasta syystä melkoista kuormaa levyjärjestelmään. Tästä aiheutui yleistä hitautta VDI-työasemille, jotka sijaitsivat samassa levyjärjestelmässä.
Ympäristössä on jonkin aikaa ollut ongelma, joka aiheuttaa päätteiden www-hallinnan kaatumisen tietyssä tilanteessa. Tämä on ollut tiedossa ja odotellut korjaantumista “itsestään” 3.1-päivityksen yhteydessä. Katkoksen aikana tämän lisäksi myös VDI-hallinta oli kuulemma tavoittamattomissa ja kokoa VDI-ympäristö oli “jumissa”. Virtuaalityöasemat eivät toimineet eikä niihin saanut yhteyttä.
Vianselvityksessä paikallinen mikrotuki oli yhteydessä Sunin tukeen, joka oli todennut VDA-palvelun olleen jollain tapaa jumissa ja järjestelmän palautuneen toimintakuntoiseksi uudelleenkäynnistämällä VDA-palvelun. Samassa yhteydessä on ilmennyt epäilyjä MySQL-kannan toiminnasta mutta tätä ei ole toistaiseksi pystytty todentamaan. Vianselvitystä hieman haittasi Unix/Solaris-osaamisen puute paikan päällä.
Lomalta palattuani huomasin virtuaalityöasemien kärsivän IP-osoitepulasta, mikä ei ainakaan ole vähentänyt katkoksen aikana syntyneitä ongelmia. Mahdollisesti ainakin osa VDA-palvelun yhteysongelmista on johtunut tästä. Sun kuitenkin selvittää vielä mahdollisen MySQL-ongelman olemassaoloa.
Opittua
Vastaavaa ei tietenkään pitäisi koskaan tapahtua, mutta hyvä että tapahtui nyt eikä vuoden kuluttua. Tapahtuneen ansiosta selvisi, että nykyisellä kalustuksella 7410:stä irtoaa luokkaa 6 000 I/O-operaatiota sekunnissa, mikä on varsin kunnioitettava luku noin 20 ATA-levyltä! Varsinkin kun se on noin kolme kertaa enemmän kuin 20 ATA-levyltä on teoriassa mahdollista saada.. ZFS-caching rules.
Varsinaisen syyn selvitys on vielä kesken, mutta suosittelen ainakin ylläpitosopimuksen tekemistä ratkaisutoimittajan kanssa. Maanantaina alkaa VDI-järjestelmän päivitys uuteen. Sitä ennen yritämme ensin toistaa ongelman Sunin supporttia varten, tällä kertaa debug-lokien kera.
22.12.2009
Hmmm.. ai että 6000 iopsia sata-levyiltä? Jos fakta on kuitenkin se, että yhdeltä sata-levyltä saa n. 70 IOPSia, niin yksinkertaisella matematiikalla sieltä ei 20 levyn ryhmällä raid0 tasollakaan voi tulla kuin 1400 IOPSia. Tietty cachet välissä auttaa asiaa, mutta jokatapauksessa jokainen I/O-operaatio täytyy jossain vaiheessa levyille kirjoittaa niin ei kait mistään tyhjästä voi tulla tuommoisia IOPSeja? Ja onkos teillä siis 20 sata-levyä yhdessä raid-setissä? Sieltä kun yksi poksahtaa, niin johan sen pakan uudelleen rakentaminen kestää iäisyyden. Mitenkäs suorituskyky sen aikana? Mää vaan suurest ihmettelen.
22.12.2009
Naah, olet vaan kade..
Eihän tuollaista IOPS-lukua tuollaiselta levymäärältä kovin helposti ulos saa, vaikka olisi kuitulevyjäkin. Siellä on toki yksi FileZilla ja LogZilla cachettamassa lukuja ja kirjoituksia – sekä tietysti RAM:ia jonkin verran. Se on muistaakseni 12+12 peilattu RAID-Z. Mää voin joululomalla lukea tarkemmin mitä tapahtuu kun sieltä yksi levy hajoaa..
Todennäköisesti tuosta luvusta on aika iso osa cachesta tulevia lukuja joka tapauksessa. Mutta oli miten oli, ihan hyvä luku silti..
Lähetä kommentti