Pilvipohjaisten pankkisovellusten korkean käytettävyyden varmistaminen

Pilvipohjaisten pankkisovellusten korkean käytettävyyden varmistaminen

On houkuttelevaa ajatella, että pilvipalveluntarjoaja takaa kriittisten pilvipohjaisten pankkisovellustesi korkean käytettävyyden. Ongelmana on, että he eivät todellakaan tee.

Pilvipohjaisten pankkisovellusten korkean käytettävyyden varmistaminen PlatoBlockchain Data Intelligence. Pystysuuntainen haku. Ai.Pilvipohjaisten pankkisovellusten korkean käytettävyyden varmistaminen PlatoBlockchain Data Intelligence. Pystysuuntainen haku. Ai.
Todd Doane, ratkaisuarkkitehti, SIOS Technology

Pilvipalveluntarjoajasi on saattanut auttaa sinua määrittämään virtuaalikoneiden klusterin, joka loppuu useista datakeskuksista tai käytettävyysvyöhykkeistä (AZ). Se on saattanut ottaa käyttöön automaattisen vikasietojärjestelmän varmistaakseen, että kokoonpanossa oleva valmiustilassa oleva VM voi ottaa haltuunsa välittömästi, jos ensisijainen VM yhtäkkiä siirtyy offline-tilaan. Kaikki kuulostaa siltä, ​​​​että sen pitäisi tarjota korkea saatavuus, eikö?

Mutta tarkastele tarkasti korkeaa käytettävyyttä koskevaa palvelutasosopimusta (SLA): SLA takaa, että vähintään yksi järjestelmäsi virtuaalikoneista on käytettävissä vähintään 99.9 % tai jopa 99.99 % ajasta. Mutta se ei takaa sovellusten tai tietojen saatavuutta. Jos jäljellä oleva virtuaalikone ei pääse käsiksi tallennusinfrastruktuuriin, jossa pankkisovelluksesi ja tietosi sijaitsevat, tärkeät sovelluksesi ovat käytännössä offline-tilassa.

Pilvien saavutettavuuden varmistaminen

Kuinka voit varmistaa, että kriittiset pankkisovelluksesi ja tietosi pysyvät helposti saatavilla pilvessä tai hybridi on-prem/pilvikokoonpanossa, jos taustalla olevan tekniikan määrittäminen automaattista vikasietoa varten useiden AZ:iden kesken ei riitä?

Aloitetaan sanomalla, että klusteroitujen virtuaalikoneiden levittäminen useiden AZ:iden kesken on tärkeää keskeisten sovellusten ja tietojesi korkean käytettävyyden (HA) varmistamiseksi. Tarvitset kuitenkin strategian, jolla varmistetaan, että jokaisella näistä virtuaalikoneista on pääsy kriittisiin sovelluksiin ja tietoihin, joita haluat jatkaa. Siellä perinteiset lähestymistavat HA: hun eroavat pilven suhteen.

Perinteisessä – eli paikallisessa – HA-kokoonpanossa voit luoda vikasietoklusterin, joka koostuu useista palvelimista tai virtuaalikoneista ja tallennusalueverkosta (SAN), jossa sovelluksesi ja tietosi sijaitsevat. Mikä tahansa klusterin palvelin tai virtuaalinen kone voisi olla vuorovaikutuksessa SAN:n sovellusten ja tietojen kanssa, joten jos avainsovellusta aktiivisesti käyttävä virtuaalikone yhtäkkiä siirtyy offline-tilaan, klusteri siirtyy automaattisesti toiseen virtuaalikoneeseen, joka voisi olla vuorovaikutuksessa SAN:n kanssa ja alkaa suorittaa sovellus ja päivittää sama tietokanta, jota edellinen kone oli käyttänyt.

Määritetään pilvipalvelua varten

Pilvessä ei kuitenkaan ole todellista mahdollisuutta luoda jaettua SAN-verkkoa. Joitakin jaettuja tallennusvaihtoehtoja on, mutta niitä ei ole suunniteltu tarjoamaan kriittisten pankkisovellustesi vaatimaa suorituskykyä tai HA-tasoja. Sen sijaan pilvipohjaiset HA-kokoonpanot riippuvat klusterin kuhunkin virtuaaliseen koneeseen liitetystä korkean suorituskyvyn tallennustilasta. Kun tietty virtuaalikone käyttää sovellusta, se on vuorovaikutuksessa tietokantaan tallennettujen tietojen kanssa, joka sijaitsee kyseiseen virtuaalikoneeseen liitetyssä tallennustilassa.

Pilvipohjaisten pankkisovellusten HA:n avain on siis varmistaa, että jokaisella klusterin virtuaalikoneella on aina samat sovellukset ja samat tiedot. Jos klusterin ensisijainen VM yhtäkkiä pimenee, klusteri voi automaattisesti siirtyä valmiustilassa olevaan virtuaalikoneeseen, josta mikä tahansa voi alkaa ajaa sovellusta ja olla vuorovaikutuksessa tietojen kanssa välittömästi, koska kopio sovelluksesta ja tiedoista on omaa varastotilaa.

Pilvipalveluntarjoajasi voi helposti määrittää virtuaalikoneet, jotka tarjoavat kriittisten sovellusten vaatiman suorituskyvyn ja käytettävyyden. Se voi myös liittää tehokkaita tallennusjärjestelmiä näihin VM-koneisiin ja määrittää klusterin automaattista vikasietoa varten useille AZ:ille. Sitten sinun on otettava käyttöön mekanismi, joka automatisoi tietojen synkronisen replikoinnin kaikkien vikasietoklusterisi VM-koneisiin liitettyjen tallennusjärjestelmien välillä.

Tietojen replikointiratkaisut

Sinulla on useita vaihtoehtoja tiedon replikointiratkaisujen suhteen.

Jos klusterisi perustuu Windowsiin ja käytät Microsoft SQL Serveriä, voit käyttää SQL Serverin sisäänrakennettua Availability Groups (AGs) -ominaisuutta, joka replikoi automaattisesti käyttäjän nimetyt SQL-tietokannat kuhunkin klusterin solmuun. Tämän lähestymistavan haittapuoli on, että se replikoi vain SQL-tietokantoja, eikä jokaista tallennustilaa. Useiden SQL Server -tietokantojen replikoiminen useisiin valmiustilassa oleviin VM-koneisiin voi tulla erittäin kalliiksi, koska joudut käyttämään SQL Server Enterprise Editionia useamman kuin yhden tietokannan replikoimiseen tai tietokantojen replikointiin useisiin virtuaalikoneisiin, vaikka sovelluksesi toimisivat täydellisesti SQL Server Standard Editionin avulla. .

Vaihtoehtoisesti voit käyttää SANless-klusteriratkaisua, joka tarjoaa automaattisen lohkotason replikoinnin aktiivisesta ensisijaisesta VM:stä kuhunkin klusterin toissijaiseen virtuaalikoneeseen. SANless Clustering -ratkaisun etuna on, että se on sovellusten ja tietokantojen agnostikko; se yksinkertaisesti replikoi tietolohkoja yhdestä tallennusjärjestelmästä toiseen varmistaen, että kaikki ensisijaisessa tallennusjärjestelmässäsi olevat tiedot replikoidaan kuhunkin toiseen virtuaalikoneeseen. SAN-vapaan klusterointilähestymistavan haittapuoli on, että IT-tiimisi on lisensoitava ja opittava vielä yksi ohjelmisto, joka voi tuntua työlältä, jos voit käyttää SQL Serverin AG-toimintoja ilman lisäkustannuksia.

Tietojen replikointi on avainasemassa pilvipohjaisten pankkijärjestelmien HA:n varmistamisessa riippumatta siitä, käytätkö SQL Serverin kaltaisen ratkaisun toimintoja tai itsenäisen SAN-vapaan klusteriratkaisun toimintoja.

Pilvipalveluntarjoajasi voi tarjota sovellustesi vaatiman korkean suorituskyvyn infrastruktuurin, mutta sinun on varmistettava, että kunkin klusterin virtuaalikoneen käytettävissä olevat tiedot ja sovellukset ovat ajan tasalla, jos HA-ratkaisusi toimii odotetulla tavalla, kun sitä tarvitaan. sen tekemään niin.

Todd Doane on SIOS Technologyn ratkaisuarkkitehti. Hän on työskennellyt yli 20 vuotta pääasiassa finanssipalvelumaailmassa luoden korkean käytettävyyden referenssiarkkitehtuureja ja sovelluskohtaisia ​​suunnittelumalleja ja -periaatteita.

Aikaleima:

Lisää aiheesta Pankkiuudistus