Solidin korkean käyttöasteen tietokantajärjestelmä

Transkriptio

1 hyväksymispäivä arvosana arvostelija Solidin korkean käyttöasteen tietokantajärjestelmä Antti Viita Helsinki HELSINGIN YLIOPISTO Tietojenkäsittelytieteen laitos

2 HELSINGIN YLIOPISTO HELSINGFORS UNIVERSITET UNIVERSITY OF HELSINKI Tiedekunta/Osasto Fakultet/Sektion Faculty Laitos Institution Department Matemaattis-luonnontieteellinen Tekijä Författare Author Antti Viita Työn nimi Arbetets titel Title Tietojenkäsittelytieteen laitos Solidin korkean käyttöasteen tietokantajärjestelmä Oppiaine Läroämne Subject Tietojenkäsittelytiede Työn laji Arbetets art Level Aika Datum Month and year Sivumäärä Sidoantal Number of pages Tiivistelmä Referat Abstract sivua Tässä esitelmässä käydään läpi korkean käyttöasteen järjestelmiä. Ensin esitellään mitä nämä järjestelmät ovat ja miten niiden tehokkuutta voidaan mitata. Tämän jälkeen esitellään Solidin HA DBMS järjestelmä. Lopuksi käydään läpi testi, jossa mitattiin Solidin järjestelmän tehokkuutta. Artikkelissa myös esitellään asiat, joilla voidaan tehdä järjestelmä tehokkaamaksi. Avainsanat Nyckelord Keywords Solid, HA DBMS, korkea käyttöaste Säilytyspaikka Förvaringsställe Where deposited Muita tietoja övriga uppgifter Additional information

3 Sisältö ii 1 Johdanto 1 2 Korkean käyttöasteen järjestelmät Prosessien vikasietoisuus Tiedon vikasietoisuus Korkean käytettävyyden tehokkuus 4 4 Solidin korkean käyttöasteen järjestelmä 5 5 Solidin HA DBMS tehokkuus Tehokkuutta lisäävät tekijät Tehokkuusmenetelmät testattuna Lähteet 11

4 1 Johdanto 1 Tietokantajärjestelmiä käytetään aina vain vaativimpien palveluiden taustalla. Tämän johdosta tietokannoille tulee isompia vaatimuksia. Tämän esitelmän tarkoituksena on käydä läpi mitä tarkoitetaan korkean käyttöasteen järjestelmällä ja mikä se on. Lisäksi kartoitetaan miten tämän järjestelmän tehokkuutta voidaan säätää ja mitata. Tässä esitelmässä on myös esitelty Solid Technologiesin korkean käyttöasteen järjestelmä ja sen tehokkuuteen vaikuttavat ominaisuudet. Ensimmäisessä luvussa on käyty läpi yleisesti mitä ovat korkean käyttöasteen järjestelmät [DHM + 04]. Seuraavaksi kerrotaan kuinka prosessien ja tiedon vikasietoisuudella saavutetaan korkea käyttöaste. Tämän jälkeen tutustutaan menetelmiin, joilla voidaan mitata näiden järjestelmien tehokkuutta [WH05]. Sitten tutustutaan Solid Techologiesin korkean käyttöasteen toteutukseen yleisellä tasolla [Sol06]. Viimeisessä luvussa tutustutaan yhteen Solidin HA-järjestelmän tehokkuustutkimukseen [WR06]. Tutkimuksessa pyrittiin ottamaan selville tehokkuutteen vaikuttavista tekijöistä ja niiden konkreettisista vaikutuksista järjestelmän tehokkuuteen. 2 Korkean käyttöasteen järjestelmät Nykymaailmassa tietokantoja käytetään aina vain tärkeimmissä ja kriittisimmissä palveluissa. Siksi ei olekaan harvinaista, että palveluille halutaan "viiden yhdeksikön" (five nines) luotettavuutta [DHM + 04]. Tällä tarkoitetaan, että palvelun pitää olla vuodesta 99,999% käytettävissä. Käytännössä se tarkoittaa, että palvelu saa olla enintään 32 sekuntia alhaalla vuoden aikana. Palvelut myös käyttävät hyväkseen usein erilaisia tietokantajärjestelmiä. Tietokannoille voidaan myös asettaa tämä sama viiden yhdeksikön vaatimus. Tämän johdosta on kehitetty korkean käyttöasteen tietokantoja (HA DB, High Availability Database). Järjestelmä, millä käytetään ja ohjataan näitä, kutsutaan korkean

5 2 käyttöasteen tietokantajärjestelmän hallintajärjestelmäksi (HA-DBMS, High Availability Database Management System). Näiden järjestelmien avulla häiriötilanteista pystytään selviämään ilman katkoksia tai hyvin minimaalisilla katkoilla. HA-DBMS toimii hyvin samalla tavoin kuin korkean käyttöasteen ohjelmistot (HA application, High Availability Application). Korkea käytettävyys saavutetaan prosessien vikasietoisuudella (process redundancy) ja tiedon vikasietoisuudella (data redundancy). Prosessien vikasietoisuus saavutetaan suorittamalla montaa kopiota ohjelmasta samanaikaisesti. Tiedon vikasietoisuus tarkoittaa, että tietokannalla on aina saavutettavissa tietokannan tiedot, vaikka tulisi virhetilanteita. Näiden lisäksi on myös hyvin tärkeää, että vikatilanteen sattuessa, järjestelmä pystyy säilyttämään tilansa. Kaiken tämän vikasietoisuuden pitää tapahtua täysin käyttäjille näkymättömästi. Seuraavissa kappaleissa käydään tarkemmin läpi nämä korkean käyttöasteen saavuttamiseen tarvittavat ominaisuudet. 2.1 Prosessien vikasietoisuus HA-DBMS pitää huolen, että DMBS pysyy toiminnassa, vaikka tulisi vikatilanteita. DBMS prosessit jaetaan aktiivisiin ja passiivisiin prosesseihin. Aktiiviset prosessit hoitavat kaiken toiminnallisuuden ja passiiviset prosessit ovat valmiina ottamaan toimillisuusvastuun, mikäli aktiivinen prosessi jostain syystä kuolee. Vikasietoisuuden saavuttamiseksi molempia, aktiivisia sekä passiivisia, pitää olla vähintään yksi kappale [DHM + 04]. Prosessien vikasietoisuusmalleja on monia. Yleisin malli on 2N-malli (Active/Standby), jossa jokaisella aktiivisella prosessilla on varalla passiivinen prosessi toisella fyysisellä koneella. Asiakasohjelmistot keskustelevat aktiivisen prosessin kanssa. Päivitykset siirtyvät passiivisen prosessin käytettäväksi replikaatioprotokollan (replication protocol) avulla tai jaetun levyn välityksellä. Kuvassa 1 on esitetty perus HA-malli, jossa käytettään replikointia.

6 3 Kuva 1: Kahden palvelimen vikasietoisuus käyttäen replikointia [DHM + 04] Toinen hyvin yleinen malli on N:n tavan malli (N-Way Active). Tässä mallissa kaikki prosessit ovat aktiivisia ja tarjoavat tietokannan palveluita. Tämän mallin suurimpana etuna on sen tarjoama tehokkuus ja heikkoutena on suuri rinnakkaisuusaste jaetulle tiedolle, joka voi johtaa konflikteihin. 2.2 Tiedon vikasietoisuus Tiedon vikasietoisuus voidaan hoitaa joko fyysisellä tai loogisella tasolla. Fyysisen tason vikasietoisuudella tarkoitetaan ohjelmistoja tai laitteisto tietokantajärjestelmän alla. Näitä tekniikoita ovat mm. eri RAID tasot ja hajautetut levyjärjestelmät. Hyvin usein fyysinen vikasietoisuus toteutetaan prosessivikasietoisuuden kanssa, esimerkiksi käyttäen SAN (Storage Area Network) järjestelmiä [DHM + 04]. Loogisen tason vikasietoisuudessa tietokantajärjestelmän tieto monistetaan ja hajautetaan. Tiedon hajauttamiseen ja ylläpitoon käytettään erilaisia replikointiprotokollia, joiden tehtävänä on pitää tieto eheänä ja yksiselitteisenä kaikille sen käyttäjille. Replikointia

7 4 voidaan suorittaa joko synkronisena tai asynkronisena. Replikointi voi olla turvallisuudeltaan 1-safe tai 2-safe. 1-safe replikoinnissa (asynkroninen) transaktiot replikoidaan vasta sen jälkeen, kun aktiiviprosessi on kommitoinut sen. 2-safe replikoinnissa (synkroninen) transaktiot replikoidaan ennen kommitointia. Turvallisuusasteet on esitetty kuvassa 2. Kuva 2: Replikoinnin turvallisuusasteet [DHM + 04] 3 Korkean käytettävyyden tehokkuus HA-DBMS järjestelmän tehokkuus on hyvin subjektiivinen. Sen tehokkuuden mittaaminenkaan ei ole aina täysin yksiselitteistä [WR06]. Eräs tehokkuuden hyvistä mittareista on kuitenkin käytettävyysaste (service availability). Se on prosenttiarvo, joka kuvaa palvelun käytettävyyttä suhteessa sen olettuun käytettävyyteen. A = MTBF 100 MTBF+MTTR

8 5 Missä A on käytettävyysaste, MT BF (mean time between failures) on keskimääräinen aika ongelmien välissä ja MT T R (mean time to repair) on keskimääräinen aika vikatilanteen korjautumiseen. Korkean käyttöasteen järjestelmiltä vaaditaan kuitenkin riippumatonta ja itsenäistä toimintaa. Itsenäisen järjestelmän tehokkuuden mittaaminen onkin jo todella haastavaa ja yleensä eri järjestelmät eivät olekaan keskenään vertailukelpoisia. Tämän johdosta tehokkuutta pitäisikin mitata juuri järjestelmän suunniteltuun käytön toteuttamiseen [WR06]. Tätä varten järjestelmästä tulee kartoittaa mahdolliset virhetilanteet ja sen jälkeen tunnistaa tulevat ongelmat. Tämän kartoituksen tuloksena nähdään onko kyseinen HA-DBMS tarpeeksi itsenäinen hoitamaan mahdolliset virhetilanteet. Nähdään,yös pystyykö se palautumaan niistä itse vai tarvitseeko se ylläpitäjien apua. Lisäksi voidaan arvioida onko järjestelmän omat päätökset hyväksyttäviä. Tehokkuus voi siis riippua täysin siitä kuinka järjestelmä on määritelty selviämään erilaisista virhetilanteista. 4 Solidin korkean käyttöasteen järjestelmä Kaikilta suurilla tietokantajärjestelmätoimittajilla löytyy oma HA-DBMS järjestelmä. Tässä esitelmässä tutustutaan Solidin 1 ratkaisuun. Solidin korkean käyttöasteen järjestelmän nimi on "Solid Database with CarrierGrade Option"[Sol06]. Tällä tuotteella on kaikki normaalit HA-DBMS järjestelmän ominaisuudet ja sitä voidaan käyttää suurissa ja kriittisissä tietojärjestelmissä [WH05]. Tässä kappaleessa käydään läpi yleisesti sen toimintaperiaate. Solidin High Availability tietokanta perustuu kahden tietokantapalvelimen järjestelmään. Ensimmäinen kone toimii ensisijaisena (primary) palvelimena, jossa toimii aktiivinen tietokanta. Toinen kone on toissijainen (secondary) palvelin, joka toimii valmiuspalvelimena (hot standby server). Kaikki tieto löytyy molemmilta palvelimilta koko ajan ja mikäli en- 1 Solid Information Technology.

9 6 sisijainen palvelin hajoaa, pystyy toissijainen palvelin jatkamaan palveluiden tarjoamista ilman katkosta. Myös ensisijainen palvelin pystyy jatkamaan toimintaa, vaikka toissijainen palvelin hajoaisi. Tällöin menetään vain vikasietoisuus. Toissijaisesta palvelimesta voidaan myös tehdä ensisijainen mikäli tarve niin vaatii. Tällaisia tilanteita voi olla esimerkiksi silloin, kun ensisijainen kone hajoaa ja se aiotaan korvata kokonaan uudella koneella. Tällöin toissijaisesta voidaan tehdä valiaikaisesti ensisijainen ja se hoitaa palvelut niin pitkään, kunnes uusi palvelin saadaan käyntiin. Tämän jälkeen voidaan haluttaessa taas vaihtaa rooleja. Toinen tapaus, jossa tätä ominaisuutta voidaan käyttää, on ohjelmiston tai laitteiston päivitykset. Ensisisijaisen palvelimen päivityksen ajaksi se voidaan irrottaa HA-ympäristöstä silti tekemättä palvelukatkosta. Kaikki nämä järjestelmämuutokset tehdään normaalilla SQL-asiakasohjelmistolla. Kommennot voi kirjoittaa järjestelmän ylläpitäjä itse tai hän voi luoda omat skriptit tätä varten. Toinen, Solidin suosittelema, vaihtoehto on käyttää Watchdog-ohjelmistoa. Se on Solidin tuote, joka automatisoi HA-ympäristön toiminnallisuuden. Sen avulla järjestelmä saa "aivot", joiden avulla se osaa toimia automaattisesti erilaisissa tilanteissa. Watchdogohjelmalle tulee kuitenkin etukäteen määritellä säännöt, joiden mukaan se toimii. Tätä ohjelmaa suoritetaan eri koneella kuin sillä, jossa ensisijainen tai toissijainen tietokanta on. Muussa tapauksessa vikatilanteessa saattaisi Watchdog kuolla tietokannan mukana ja silloin ei olisi enää mikään ohjaamssa automaattisesti HA-ympäristöä. Watchdog tarkkailee käytännössä molempia palvelimia ja mikäli toinen poistuu tai hajoaa, toimii se sääntöjensä mukaisesti ja lähettää toimintakäskyt jäljelle jääneelle palvelimelle. Solidin HA järjestelmä toimii oletuksena 2-Safe turvallisuusasteella. Eli replikointi palvelimien välillä tapahtuu synkronisesti. Tätä voidaan kuitenkin säätää 1-Safe tasolle ja tämän lisäksi 2-Safen astettakin voidaan mukauttaa kolmeen erilaiseen toimintamalliin. Oletuksena on 2-Safe Received-malli, jossa toissijainen palvelin kuittaa transaktion heti saatuaan datan. Toinen vaihtoehto on 2-Safe Visible-malli, jossa tranksaktio kommitoidaan ensin toissijaisella palvelimilla ja sitten vasta kuitataan. Kolmas ja tiukin vaihtoehto

10 on 2-Safe Durable-malli, jossa transaksio kirjoitetaan levylle saakka ja sitten vasta kuitataan. Vaihtoehdot ovat kuvattu Kuvassa 3. 7 Kuva 3: Replikoinnin turvallisuusasteet [DHM + 04] Solidilta löytyy myös tuote nimeltä Smart Flow, jolla pysytytään replikoimaan kokonaisuudessaan koko HA järjestelmä (sis. ensisijainen ja toissijainen palvelin). Tämän avulla pystytään vikasietoisuutta ja tehokkuutta lisäämään vielä lisää, mutta tässä esitelmässä ei puututa tähän tuotteeseen enempää. 5 Solidin HA DBMS tehokkuus Solidin järjestelmässä on monia muuttujia, jotka vaikuttavat koko järjestelmän tehokkuuteen. Tässä luvussa on ensin esitelty asiat, jotka vaikuttavat tehokkuuteen. Tämän jälkeen

11 8 on käyty läpi testattuna asiat, jotka oikeasti todella vaikuttavat siihen. 5.1 Tehokkuutta lisäävät tekijät Korkean käyttöasteen järjestelmästä on helppoa tehdä hyvin vikasietoinen, mutta samalla sen tehokkuus kärsii huomattavasti. Teoriassa HA järjestelmä voi olla yli kaksi kertaa hitaampi kuin vastaava yksinäinen tietokanta. Tämä johtuu tiedon kahdentamisesta, lokitiedostojen kahdentamisesta ja palvelimien välisen keskustelun tuomasta latenssista. Käytännössä asiat eivät kuitenkaan ole näin huonosti. HA-järjestelmissä on monia asioita, joita voidaan säätää ja samalla lisätä tehokuutta siihen. Yleisesti voidaan nimetä kolme ominaisuutta, joita säätämällä saadaan lisää tehoa tai kestävyyttä. Nämä ovat: tiedon kestävyys (data durability), keskeytysaika (failover time) ja tehokkuus (performance) [WR06]. Yleisesti HA-järjestelmissä on oletuksena käytössä tiukka kestävyys. Se tarkoittaa, että kaikki transaktiot kirjoitetaan synkronisesti levylle tai muulle vastaalle massamuistille. Tästä löytyy yleensä järjestelmän ensimmäinen pullonkaula. Mikäli järjestelmän kestävyysrajoitetta voidaan löysentää, saadaan järjestelmästä huomattavasti tehokkaampi. Toinen tarkastelun kohde on käytetty replikointiprotokolla ja sen toimintamenetelmä. Solidin järjestelmä käyttää oletuksena mukautuvaa kestävyyttä (adaptive durability) [Sol06]. Tämä tarkoittaa, että järjestelmän ensisijainen palvelin toimii vapautuneessa kestävyydessä (relaxed durability) aina kun järjestelmä on eheä. Vapautuneessa kestävyydessä palvelin kasaa transaktioiden kirjoittamiset ryppäisiin ja pyrkii kirjoittamaan ne levylle vasta, kun palvelin ei ole enää niin kiireinen. Toissijainen palvelin siis saa muutokset itselleen, mutta tehokkuus saadaan siitä, että transaktion sitouttamisen ei tarvitse odottaa hitaita levylle kirjoittamisia. Vikatilanteen sattuessa siirrytään automaattisesti tiukkaan kestävyyteen. Solidin HA järjestelmässä voidaan kyselyitä jakaa järjestelmän molemmille palvelimille. Toissijainen palvelin voi ottaa vastaan kyselyitä, jotka eivät vaadi päivityksien tekemistä tietokantaan. Tätä ominaisuutta hyödyntäen voidaan jakaa järjestelmän kuormaa molem-

12 9 mille koneille ja näin siitä saadaan enemmän irti. 5.2 Tehokkuusmenetelmät testattuna Wolskin ja Raatikan artikkelissa [WR06] on konkreettisesti testattu erilaisia menetelmiä, jolla voidaan tehostaa HA-järjestelmää. Heidän artikkelissaan on käytetty TM1 nimistä mittausjärjestelmää [Str03]. TM1 on erityisesti suunniteltu mittaamaan tietoliikennejärjestelmiä. Artikkelissa järjestetyssä testissä tehtiin Solid HA DBMS järjestelmä ja sitä käytti kaksi asiakastietokonetta ajaen TM1 mittausta. Ennen testejä heillä oli hypoteesina, että lokitiedostojen kirjoittaminen ja synrkonisuus tulevat viemään eniten aikaa. Jos näistä päästään eroon tai näitä pysytytään keventämään, saadaan järjestelmä toimimaan huomattavasti tehokkaamin. Artikkelissa käytiin läpi kolme erilaista testitapausta. Seuraavassa käydään läpi tulokset. Ensimmäisessä testissä testattiin millainen vaikutus oli käyttää mukautettua kestävyyttä verrattuna tiukkaan kestävyyteen yhdellä palvelimella. Testin tuloksena oli, että kun käytettiin mukautettua kestävyyttä (asynkroninen lokien kirjoittaminen) saavutettiin 20-40% tehokkuuden parannus. Seuraavassa testissä otettiin toissijainen palvelin mukaan ja suoritettiin sama testi. Tässä testissä mukautettu kestävyys toi järjestelmälle % tehokkuuden parannuksen. Näin suuren parannuksen syynä on lokin kirjoitusvastuun siirtyminen toissijaiselle palvelimelle. Viimeisessä testissä otettiin selvää kuinka replikoinnin turvallisuusasteet vaikuttavat tehokkuuteen. Tämän testin tuloksena oli, että testin ääripäiden tehokkuus ero oli yli 300%. Hieman yllätyksenä tuli, että testin tehokkain 1-Safe ei ole kovin paljon tehokkaampi kuin toisena ollut 2-Safe Received. Kuvassa 4 näkyy kolmannen testin tulokset. Testien tuloksista voidaan siis päätellä, että asynkronisuudella saadaan huomattavaa lisätehokkuutta korkean käyttöasteen järjestelmään. Tämän lisäksi auttaa myös lokien kirjoittamisen siirtäminen toissijaiselle palvelimelle, mutta ei välttämättä yhtä paljon. Korkean

13 10 Kuva 4: Replikointiprotokollan tehokkuus [WR06] käyttöasteen palvelun optimointi onkin siis tasapainottelua annettujen turvavaatimusten ja turvallisuusasteen löysentämisen välillä.

14 Lähteet 11 DHM + 04 Drake, S., Hu, W., McInnis, D., Sköld, M., Srivastava, A., Thalmann, L., Tikkanen, M., Torbjørnsen, Ø. ja Wolski, A., Architecture of Highly Available Databases. Int. Service Availability Symposium (ISAS), sivut Sol06 Solid Information Technology, Solid High Availability User Guide, 4.5 painos, Str03 Strandell, T., Open source database systems: Systems study, performance and scalability. Pro gradu, University of Helsinki, Department of Computer Science, May WH05 Wolski, A. ja Hofhauser, B., A Self-Managing High-Availability Database: Industrial Case Study. Proceedings of the 21st International Conference on Data Engineering Workshops. WR06 Wolski, A. ja Raatikka, V., Performance Measurement and Tuning of Hot- Standby Databases. Int. Service Availability Symposium (ISAS), sivut