Sikre høy tilgjengelighet for skybaserte bankapplikasjoner

Det er fristende å tro at en skytjenesteleverandør vil sikre høy tilgjengelighet av dine kritiske skybaserte bankapplikasjoner. Problemet er at de virkelig ikke gjør det.

Skyleverandøren din kan ha hjulpet deg med å konfigurere en klynge av virtuelle maskiner (VM) som går tom for flere datasentre eller tilgjengelighetssoner (AZ). Den kan ha implementert et automatisert failover-system for å sikre at en standby-VM i konfigurasjonen kan ta over umiddelbart hvis den primære VM-en plutselig går offline. Det hele høres ut som det burde gi høy tilgjengelighet, ikke sant?

Men se nøye på tjenestenivåavtalen (SLA) som skisserer høy tilgjengelighet: SLAen garanterer at minst én av VM-ene i systemet ditt vil være tilgjengelig minst 99.9 % eller til og med 99.99 % av tiden. Men det er ikke en garanti for applikasjon eller datatilgjengelighet. Hvis den gjenværende virtuelle maskinen ikke får tilgang til lagringsinfrastrukturen der bankapplikasjonene og dataene dine ligger, er de kritiske applikasjonene dine effektivt offline.

Sikre skytilgjengelighet

Hvordan kan du sikre at dine kritiske bankapplikasjoner og data forblir svært tilgjengelige i skyen eller i en hybrid on-prem/cloud-konfigurasjon, hvis konfigurering av den underliggende teknologien for automatisert failover på tvers av flere AZ-er ikke er tilstrekkelig?

La oss starte med å si at det å ha grupperte VM-er spredt mellom flere AZ-er er avgjørende for å sikre høy tilgjengelighet (HA) til nøkkelapplikasjonene og dataene dine. Det du trenger i tillegg, er imidlertid en strategi for å sikre at hver av disse VM-ene har tilgang til de kritiske applikasjonene og dataene du vil fortsette å kjøre. Det er der tradisjonelle tilnærminger til HA divergerer når det kommer til skyen.

I en tradisjonell – altså lokalt – HA-konfigurasjon, kan du opprette en failover-klynge som består av flere servere eller VM-er og et lagringsområdenettverk (SAN), der programmene og dataene dine ligger. En hvilken som helst server eller VM i klyngen kan samhandle med applikasjonene og dataene i SAN, så hvis VM som aktivt kjører en nøkkelapplikasjon plutselig gikk offline, ville klyngen automatisk mislykkes til en annen VM som kunne samhandle med SAN og begynne å kjøre applikasjon og oppdatering av den samme databasen som den forrige maskinen hadde brukt.

Konfigurerer for skyen

I skyen er det imidlertid ikke noe reelt alternativ for å opprette et delt SAN. Det finnes noen alternativer for delt lagring, men de er ikke bygd for å gi ytelsen eller nivåene av HA dine kritiske bankapplikasjoner krever. I stedet er skybaserte HA-konfigurasjoner avhengig av høyytelseslagring knyttet til hver av VM-ene i klyngen. Når en gitt VM kjører en applikasjon, samhandler den med data som er lagret i en database som ligger i lagringen som er knyttet til den VM.

Nøkkelen til HA for skybaserte bankapplikasjoner er derfor å sikre at hver VM i klyngen din alltid har de samme applikasjonene og de samme dataene. På den måten, hvis den primære VM-en i klyngen plutselig blir mørk, kan klyngen automatisk svikte over til en standby VM, hvorav hvilken som helst kan begynne å kjøre applikasjonen og samhandle med dataene umiddelbart fordi en kopi av applikasjonen og dataene ligger i sin egen tilknyttede lagring.

Skyleverandøren din kan enkelt konfigurere VM-ene som vil gi ytelses- og tilgjengelighetsnivåene som dine kritiske applikasjoner krever. Den kan også knytte høyytelseslagringssystemer til disse VM-ene, og den kan konfigurere klyngen din for automatisk failover på tvers av flere AZ-er. Deretter må du distribuere en mekanisme som automatiserer synkron replikering av data blant alle lagringssystemene som er koblet til VM-ene i failover-klyngen.

Datareplikeringsløsninger

Du har en rekke valg når det gjelder datareplikeringsløsninger.

Hvis klyngen din er basert på Windows og du bruker Microsoft SQL Server, kan du bruke SQL Servers innebygde Availability Groups (AGs)-funksjon, som automatisk vil replikere brukernavngitte SQL-databaser til hver av nodene i klyngen din. Ulempen med denne tilnærmingen er at den bare replikerer SQL-databaser, i stedet for hver blokk med data i lagring. Å replikere flere SQL Server-databaser til flere VM-er i standby-modus kan bli veldig dyrt, ettersom du må bruke SQL Server Enterprise Edition for å replikere mer enn én database eller for å replikere databaser til flere VM-er, selv om applikasjonene dine kjører perfekt med SQL Server Standard Edition .

Alternativt kan du bruke en SAN-fri klyngeløsning, som gir automatisert replikering på blokknivå av data fra den aktive primære VM til hver av de sekundære VMene i en klynge. Fordelen med å bruke en SANless Clustering-løsning er at den er applikasjons- og databaseagnostisk; den replikerer ganske enkelt blokker med data fra ett lagringssystem til et annet, og sikrer at alle dataene i det primære lagringssystemet ditt blir replikert til hver av de andre VM-ene. Ulempen med en SAN-fri klyngetilnærming er at det er enda et stykke programvare for IT-teamet ditt å lisensiere og lære, noe som kan føles tungt hvis du kan bruke AG-funksjonaliteten til SQL Server uten ekstra kostnad.

Datareplikering er nøkkelen til å sikre HA for skybaserte banksystemer, enten du bruker funksjonaliteten innebygd i en løsning som SQL Server, eller funksjonaliteten som tilbys av en uavhengig SAN-fri klyngeløsning.

Skyleverandøren din kan tilby den høyytelsesinfrastrukturen som applikasjonene dine krever, men du må sørge for at dataene og applikasjonene som er tilgjengelige for hver av VM-ene i den klyngen er oppdatert hvis HA-løsningen din skal fungere som forventet når du trenger det å gjøre det.

Todd Doane er løsningsarkitekt hos SIOS Technology. Han har brukt mer enn 20 år, først og fremst i finansverdenen, på å lage referansearkitekturer med høy tilgjengelighet og applikasjonsspesifikke designmønstre og prinsipper.

• SEO-drevet innhold og PR-distribusjon. Bli forsterket i dag.
• Platoblokkkjede. Web3 Metaverse Intelligence. Kunnskap forsterket. Tilgang her.
• kilde: https://bankautomationnews.com/allposts/core-cloud/ensuring-high-availability-for-cloud-based-banking-applications/