High Availability

Waarom HA

Publieke clouds zijn ontworpen om high availability aan te bieden zonder dat de klant hiervoor extra hoeft te betalen. Bij AWS, Azure en Google Cloud is elke regio (bv. europe-west-1) nog eens onderverdeeld in zones (bvb eu-west-1a, eu-west-1b). Deze zones zijn onafhankelijk van elkaar. Het zijn datacenters die ver genoeg van elkaar staan, en aparte stroomvoorzieningen hebben. Onderling zijn ze verbonden met glasvezel, zodat de latency laag genoeg is om snelle datareplicatie te kunnen uitvoeren over het netwerk.

Dankzij dit opzet is het mogelijk om de applicaties en databases zo te plaatsen, dat wanneer er een zone uitvalt, de applicatie of database toch verder kan functioneren.

HA met DBaaS

Een database opzetten met DBaaS in high availability is letterlijk een checkbox afvinken tijdens de setup. Wanneer bijvoorbeeld bij AWS de eigenschap multi_az geactiveerd is, dan wordt de database automatisch gerepliceerd naar een andere zone. Het architectuur diagram ziet er dan zo uit:

Wanneer er een onderbreking is in eu-west-1a, dan wordt de standby database van eu-west-1b de master en kan de applicatie gewoon verder blijven werken (als de applicatie zelf ook in een HA setup geconfigureerd is).

HA met IaaS

Om de applicatielaag high available te maken, dient er gebruik gemaakt te worden van een load balancer. In AWS kan een enkele loadbalancer in verschillende zones geplaatst worden. Elke loadbalancer kan dan 1 of meerdere instances onder zich hebben waarnaar het data stuurt. Valt er 1 zone uit, dan wordt onmiddellijk al het dataverkeer naar de overblijvende zone gestuurd, die dan het verkeer naar de healthy (gezonde) instances zal sturen. Schematisch ziet het er zo uit:

Deze setup kan ook uitgebreid worden naar een 3-zone high availability setup. De loadbalancer zal dan in 3 zones aanwezig zijn.

Multi-region HA

het is ook mogelijk om een setup uit te werken dat zich spreidt over verschillende regios. Er kan een read-replica database toegevoegd worden die in een andere regio staat. Deze database kan dan gebruikt worden als een alleen-lezen database door de applicatielaag dat in dezelfde regio als de read-replica staat:

In bovenstaande architectuur is er een applicatie in 2 zones. Eén in eu-west-1 en in een andere in us-east-1. De database kan alleen maar een standby database hebben in dezelfde regio vanwege latency vereisten. In andere regios kan de database een read-replica hebben. Dit is een database waar alleen maar van gelezen kan worden, er kan niet naar geschreven worden.

De latency tussen eu-west-1 en eu-east-1 is natuurlijk wel significant hoger. Daardoor zal een query naar de database dat een schrijf-operatie moet uitvoeren, langer duren dan wanneer dit in us-east-1 gebeurt. Daar dient rekening mee gehouden te worden tijdens het ontwerpen of herontwerpen van applicatie.

Routering tussen zones gebeurt op DNS niveau. Zo heeft route53 van AWS bepaalde functionaliteit ingebouwd om routering te laten gebeuren afhankelijk van waar de eindgebruiker zich bevindt (EU of US in dit geval).

• Volgend hoofdstuk: Self-healing