Todellisessa maailmassa voi olla tilanteita, joissa palvelimesi suorituskyky saattaa heikentyä tapahtumista, jotka johtuvat esimerkiksi äkillisestä liikennepiikistä, joka voi johtaa äkilliseen sähkökatkokseen. Se voi olla paljon pahempaa ja palvelimesi voivat rampautua – riippumatta siitä, onko sovelluksesi isännöity pilvessä vai fyysisessä koneessa. Tällaiset tilanteet ovat väistämättömiä. Sen sijaan, että toivoisit, ettei niitä tapahdu, sinun pitäisi kuitenkin itse asiassa varautua niin, että järjestelmissäsi ei tapahdu vikoja.
Vastaus ongelmaan on korkean saatavuuden (HA) konfiguraation tai arkkitehtuurin käyttö. Korkean saatavuuden arkkitehtuuri on lähestymistapa, jossa määritellään järjestelmän komponentit, moduulit tai palveluiden toteutus, jolla varmistetaan optimaalinen toiminnallinen suorituskyky myös suurten kuormitusten aikana. Vaikka HA-järjestelmien toteuttamiseen ei ole olemassa kiinteitä sääntöjä, on yleisesti ottaen olemassa muutamia hyviä käytäntöjä, joita on noudatettava, jotta vähimmistä resursseista saadaan paras mahdollinen hyöty.
Mihin sitä tarvitaan?
Määritellään seisokkiaika, ennen kuin edetään pidemmälle. Downtime on ajanjakso, jolloin järjestelmäsi (tai verkko) ei ole käytettävissä tai ei vastaa. Toimintahäiriö voi aiheuttaa yritykselle valtavia tappioita, koska kaikki palvelut ovat poissa käytöstä, kun järjestelmät ovat poissa käytöstä. Elokuussa 2013 Amazonin toimintahäiriö kesti 15 minuuttia (sekä verkko- että mobiilipalvelut), ja se menetti lopulta yli 66000 dollaria minuutissa. Nämä ovat valtavia lukuja jopa Amazonin kokoiselle yritykselle.
Kahdentyyppisiä seisokkeja on kahdenlaisia – suunniteltuja ja suunnittelemattomia. Suunniteltu seisokki on seurausta huollosta, joka on väistämätön. Tällaisia ovat esimerkiksi korjaustiedostojen levittäminen, ohjelmistojen päivittäminen tai jopa tietokantakaavion muutokset. Suunnittelematon seisokkiaika johtuu kuitenkin jostain odottamattomasta tapahtumasta, kuten laitteisto- tai ohjelmistovioista. Tämä voi johtua sähkökatkoista tai jonkin komponentin vikaantumisesta. Suunnitelmattomat seisokkiajat jätetään yleensä suorituskykylaskelmien ulkopuolelle.
Korkean käytettävyyden arkkitehtuurin toteuttamisen ensisijaisena tavoitteena on varmistaa, että järjestelmä tai sovellus on konfiguroitu käsittelemään erilaisia kuormituksia ja erilaisia vikoja mahdollisimman pienellä tai olemattomalla seisokkiajalla. Tämän saavuttamisessa auttavat useat komponentit, ja käsittelemme niitä lyhyesti.
Miten käytettävyyttä mitataan?
Organisaatioiden, jotka aikovat hyödyntää pilvi-infrastruktuuria täysimittaisesti, on myös pystyttävä vastaamaan 24/7-saatavuusvaatimuksiin. Saatavuutta voidaan mitata prosenttiosuutena ajasta, jonka järjestelmät ovat käytettävissä.
x = (n – y) * 100/n
Jossa n on kalenterikuukauden minuuttien kokonaismäärä ja y on niiden minuuttien kokonaismäärä, jotka palvelu ei ole käytettävissä kyseisen kalenterikuukauden aikana. Korkealla käytettävyydellä tarkoitetaan yksinkertaisesti komponenttia tai järjestelmää, joka on jatkuvasti toiminnassa halutun pitkän ajanjakson ajan. Tuotteen tai järjestelmän laajalle levinnyt, mutta lähes mahdoton saavuttaa käytettävyysstandardi on ”viisi yhdeksää” (99,999 prosenttia). Korkea käytettävyys on vaatimus kaikille yrityksille, jotka toivovat voivansa suojata liiketoimintaansa järjestelmäkatkoksen aiheuttamilta riskeiltä. Nämä riskit voivat johtaa miljoonien dollarien tulonmenetyksiin.
Onko se todella rahan arvoista?
Se, että korkean käytettävyyden arkkitehtuuriin siirtyminen antaa paremman suorituskyvyn, on ihan oikein, mutta sillä on myös suuri hinta. Sinun on kysyttävä itseltäsi, onko päätös mielestäsi taloudellisesti perusteltu.
Päätöstä on tehtävä siitä, onko ylimääräinen käytettävyys todella sen rahamäärän arvoinen, joka siihen on käytettävä. Sinun on kysyttävä itseltäsi, kuinka haitallisia mahdolliset käyttökatkokset voivat olla yrityksellesi ja kuinka tärkeitä palvelusi ovat liiketoimintasi pyörittämisessä.
Miten se saavutetaan?
Nyt kun olet päättänyt ryhtyä toimeen, keskustellaan siitä, miten se toteutetaan. Ei ole intuitiivista, että komponenttien lisääminen järjestelmään ei auta tekemään siitä vakaampaa ja saavuttamaan korkeaa käytettävyyttä. Se voi itse asiassa johtaa päinvastaiseen, sillä komponenttien lisääminen lisää vikojen todennäköisyyttä. Nykyaikaiset mallit mahdollistavat työkuormien jakamisen useisiin instansseihin, kuten verkkoon tai klusteriin, mikä auttaa optimoimaan resurssien käyttöä, maksimoimaan tuotoksen, minimoimaan vasteajat ja välttämään minkään järjestelmän ylikuormittumista prosessissa, jota kutsutaan kuorman tasapainottamiseksi. Siihen kuuluu myös siirtyminen vararesurssiin, kuten palvelimeen, komponenttiin tai verkkoon, aktiivisen resurssin vikaantuessa, jota kutsutaan Failover-järjestelmiksi.
Moninkertaisten sovelluspalvelimien käyttö:
Kuvittele, että sinulla on yksi palvelin, joka tuottaa palvelujasi, ja yhtäkkinen ruuhkahuippu johtaa sen vikaantumiseen (tai kaataa sen). Tällaisessa tilanteessa ennen kuin palvelimesi käynnistetään uudelleen, pyyntöjä ei voida enää palvella, mikä johtaa käyttökatkokseen.
Tässä tilanteessa ilmeinen ratkaisu on ottaa sovelluksesi käyttöön useilla palvelimilla. Sinun on jaettava kuorma kaikkien näiden kesken, jotta mikään niistä ei kuormitu liikaa ja tuotos on optimaalinen. Voit myös ottaa käyttöön osia sovelluksestasi eri palvelimilla. Esimerkiksi sähköpostien käsittelyä varten voisi olla erillinen palvelin tai staattisten tiedostojen, kuten kuvien, käsittelyä varten erillinen palvelin (kuten Content Delivery Network).
Tietokantojen skaalaus:
Tietokannat ovat suosituin ja ehkä yksi käsitteellisesti yksinkertaisimmista tavoista tallentaa käyttäjätietoja. On muistettava, että tietokannat ovat yhtä tärkeitä palveluille kuin sovelluspalvelimet. Tietokannat toimivat erillisillä palvelimilla (kuten Amazon RDS) ja ovat myös alttiita kaatumisille. Vielä pahempaa on se, että tietokantojen kaatuminen voi johtaa käyttäjätietojen menetykseen, mikä voi osoittautua kalliiksi.
Redundanssi on prosessi, jolla luodaan järjestelmiä, joilla on korkea käytettävyys saavuttamalla vikojen havaittavuus ja välttämällä yhteisten syiden aiheuttamia vikoja. Tämä voidaan saavuttaa ylläpitämällä orjapalvelimia, jotka voivat tulla tilalle, jos pääpalvelin kaatuu. Toinen mielenkiintoinen käsite tietokantojen skaalautumisessa on jakaminen. Shard on tietokannan horisontaalinen osio, jossa on saman taulukon rivejä, joita sitten ajetaan erillisellä palvelimella.
Diversifioituja maantieteellisiä sijainteja:
Sovellusten ja sen jälkeen tietokantojen skaalaus on todella suuri askel eteenpäin, mutta entä jos kaikki palvelimet ovat samassa fyysisessä sijainnissa ja jokin kauhea luonnonkatastrofin kaltainen onnettomuus iskee datakeskukseen, jossa palvelimesi sijaitsevat? Tämä voi johtaa mahdollisesti valtaviin käyttökatkoksiin.
Sen vuoksi on ehdottoman tärkeää, että palvelimet sijaitsevat eri paikoissa. Useimmissa nykyaikaisissa verkkopalveluissa voit valita palvelinten maantieteellisen sijainnin. Sinun kannattaa valita viisaasti, jotta palvelimesi ovat hajautettu ympäri maailmaa eikä paikallistettu jollekin alueelle.
Tässä postauksessa olen yrittänyt käsitellä perusajatuksia, jotka muodostavat ajatuksen korkean käytettävyyden arkkitehtuurista. Loppujen lopuksi on selvää, että mikään yksittäinen järjestelmä ei voi ratkaista kaikkia ongelmia. Näin ollen sinun on arvioitava tilanteesi huolellisesti ja päätettävä, mitkä vaihtoehdot sopivat niihin parhaiten. Toivottavasti tämä johdatti sinut korkean käytettävyyden arkkitehtuurin maailmaan ja auttoi sinua päättämään, miten voit toteuttaa sen itsellesi.
Mitkä ovat parhaat käytännöt?
Järjestelmävikojen hillitsemiseksi ja sekä suunniteltujen että suunnittelemattomien seisokkien pitämiseksi loitolla korkean käytettävyyden arkkitehtuurin (High Availability, HA) käyttöä suositellaan erittäin paljon, erityisesti kriittisissä sovelluksissa. Käytettävyysasiantuntijat korostavat, että jotta mikä tahansa järjestelmä olisi erittäin käytettävissä, sen osien tulisi olla hyvin suunniteltuja ja tiukasti testattuja. Korkean käytettävyyden arkkitehtuurin suunnittelu ja toteutus voi olla vaikeaa, kun otetaan huomioon ohjelmisto-, laitteisto- ja käyttöönottovaihtoehtojen laaja kirjo. Onnistunut hanke alkaa kuitenkin yleensä selkeästi määritellyistä ja kattavasti ymmärretyistä liiketoimintavaatimuksista. Valitun arkkitehtuurin pitäisi pystyä täyttämään halutut tietoturvan, skaalautuvuuden, suorituskyvyn ja käytettävyyden tasot.
Ainoa tapa taata laskentaympäristöjen toivottu toiminnan jatkuvuus tuotantoaikana on suunnitella ne korkean käytettävyyden kannalta. Arkkitehtuurin asianmukaisen suunnittelun lisäksi yritykset voivat pitää elintärkeät sovellukset toiminnassa noudattamalla suositeltuja korkean käytettävyyden parhaita käytäntöjä.
- Datan varmuuskopiointi, toipuminen ja replikointi
Hyvän tietosuojasuunnitelman, joka suojaa järjestelmävirheiltä, tunnusmerkkinä on järkevä varmuuskopiointi- ja palautusstrategia. Arvokkaita tietoja ei pitäisi koskaan säilyttää ilman asianmukaisia varmuuskopioita, replikointia tai mahdollisuutta luoda tiedot uudelleen. Jokaisen datakeskuksen tulisi varautua tietojen katoamiseen tai korruptoitumiseen etukäteen. Tietovirheet voivat aiheuttaa asiakkaiden todennusongelmia, vahingoittaa rahoitustilejä ja sen jälkeen liikeyhteisön uskottavuutta. Suositeltava strategia tietojen eheyden ylläpitämiseksi on luoda täydellinen varmuuskopio ensisijaisesta tietokannasta ja testata sitten asteittain lähdepalvelinta tietojen korruptoitumisen varalta. Täydellisten varmuuskopioiden luominen on etusijalla katastrofaalisesta järjestelmävirheestä toipumisessa.
- Clustering
Kaikkien sovelluspalveluiden on pakko epäonnistua jossakin vaiheessa, vaikka ohjelmistosuunnittelu olisikin korkealaatuisinta. Korkeassa käytettävyydessä on kyse sovelluspalvelujen toimittamisesta vioista huolimatta. Klusteroinnilla voidaan tarjota sovelluspalveluiden välitön vikasietoisuus vikatilanteessa. Sovelluspalvelu, joka on ”klusteritietoinen”, pystyy kutsumaan resursseja useilta palvelimilta; se turvautuu toissijaiseen palvelimeen, jos pääpalvelin menee pois käytöstä. Korkean saatavuuden klusteriin kuuluu useita solmuja, jotka jakavat tietoja jaettujen datamuistiverkkojen kautta. Tämä tarkoittaa, että mikä tahansa solmu voidaan irrottaa verkosta tai sammuttaa, ja klusterin muut osat jatkavat toimintaansa normaalisti niin kauan kuin vähintään yksi solmu on täysin toimintakykyinen. Kukin solmu voidaan päivittää yksitellen ja liittää uudelleen klusterin toimiessa. Klusterin toteuttamiseen tarvittavan lisälaitteiston hankkimisesta aiheutuvia korkeita kustannuksia voidaan lieventää perustamalla virtualisoitu klusteri, joka hyödyntää käytettävissä olevia laitteistoresursseja.
- Verkon kuormituksen tasaus
Kuormituksen tasaus on tehokas keino lisätä kriittisten verkkopohjaisten sovellusten käytettävyyttä. Kun havaitaan palvelimen vikaantuneita instansseja, ne korvataan saumattomasti, kun liikenne jaetaan automaattisesti uudelleen palvelimille, jotka ovat vielä toiminnassa. Kuormituksen tasaaminen ei ainoastaan johda korkeaan käytettävyyteen, vaan se myös helpottaa asteittaista skaalautuvuutta. Verkon kuormanjako voidaan toteuttaa joko pull- tai push-mallilla. Se helpottaa korkeampaa vikasietoisuutta palvelusovelluksissa.
- Vikaantumisratkaisut
Korkean käytettävyyden arkkitehtuuri koostuu perinteisesti joukosta löyhästi toisiinsa kytkettyjä palvelimia, joilla on vikasietoisuus. Failover on periaatteessa varatoimintatila, jossa järjestelmän komponentin toiminnot ottaa hoitaakseen toissijainen järjestelmä siinä tapauksessa, että ensisijainen järjestelmä poistuu käytöstä joko vian tai suunnitellun seisokin vuoksi. Kylmä vikaantuminen tapahtuu, kun toissijainen palvelin käynnistetään vasta sen jälkeen, kun ensisijainen palvelin on sammutettu kokonaan. Kuuma vikaantuminen (hot failover) tapahtuu, kun kaikki palvelimet ovat käynnissä samanaikaisesti ja kuormitus kohdistuu kokonaan yhteen palvelimeen tiettynä ajankohtana. Molemmissa skenaarioissa tehtävät siirretään automaattisesti varajärjestelmän komponentille, jotta prosessi pysyy loppukäyttäjän kannalta mahdollisimman saumattomana. Vaihtoa voidaan hallita DNS:n kautta hyvin valvotussa ympäristössä.
- Geografinen redundanssi
Geografinen redundanssi on ainoa puolustuslinja, kun halutaan estää palvelukatkokset katastrofaalisissa tapahtumissa, kuten luonnonkatastrofeissa, jotka aiheuttavat järjestelmäkatkoksia. Georeplikoinnin tapaan useita palvelimia sijoitetaan maantieteellisesti erillisiin paikkoihin. Sijaintien tulisi olla globaalisti hajautettuja eikä paikallistettuja tietylle alueelle. On ratkaisevan tärkeää käyttää itsenäisiä sovelluspinoja kussakin toimipisteessä, jotta yhden toimipisteen vikaantuessa toisen toimipisteen toimintaa voidaan jatkaa. Ihannetapauksessa näiden toimipisteiden tulisi olla täysin riippumattomia toisistaan.
- Suunnittele vikaantumista varten
Huolimatta siitä, että korkean käytettävyyden parhaiden käytäntöjen soveltaminen on pohjimmiltaan vikaantumisen varalta suunnittelua, on olemassa muitakin toimia, joilla organisaatio voi parantaa valmiuttaan, jos järjestelmän vikaantuminen johtaa käyttökatkokseen. Organisaatioiden tulisi säilyttää vika- tai resurssien kulutustietoja, joita voidaan käyttää ongelmien eristämiseen ja trendien analysointiin. Näitä tietoja voidaan kerätä vain seuraamalla jatkuvasti operatiivista työmäärää. Ongelmatietojen keräämiseksi, ongelmahistorian selvittämiseksi ja ongelmien välittömien ratkaisujen aloittamiseksi voidaan ottaa käyttöön elvytyspalvelu. Elvytyssuunnitelman pitäisi olla hyvin dokumentoitu, mutta sitä pitäisi myös testata säännöllisesti, jotta voidaan varmistaa, että se on käytännöllinen ennalta suunnittelemattomissa häiriötilanteissa. Henkilöstön koulutus käytettävyystekniikasta parantaa heidän taitojaan korkean käytettävyyden arkkitehtuurien suunnittelussa, käyttöönotossa ja ylläpidossa. Lisäksi olisi otettava käyttöön tietoturvakäytäntöjä, joilla voidaan hillitä tietoturvaloukkauksista johtuvia järjestelmäkatkoksia.
Esimerkki: FileCloudin korkean saatavuuden arkkitehtuuri
Seuraavassa kaaviossa selitetään, miten FileCloud-palvelimet voidaan konfiguroida korkeaa saatavuutta varten palvelun luotettavuuden parantamiseksi ja käyttökatkosten vähentämiseksi. Klikkaa tästä saadaksesi lisätietoja.