High availability omgevingen voor e-commerce

High availability omgevingen voor e-commerce

31 July 2020 door in E-commerce Optimalisatie

Tijd is geld. Als amazon.com 1 minuut downtime heeft, lopen zij $ 203.577 mis. In de competitieve wereld van vandaag verwachten consumenten ononderbroken toegang tot hun favoriete diensten. Het hebben van een high availability omgeving, zeker voor e-commerce organisaties is een must. Het is absoluut noodzakelijk dat elke organisaties analyseert wat er nodig is om de uptime van applicaties te vergroten en de totale kosten van uitval te minimaliseren. Waar moet je op letten om een high availability omgeving te realiseren?

Hoe implementeer je een high availability omgeving?

In tegenstelling tot wat je misschien zou verwachten is het toevoegen van meer onderdelen aan het platform niet de oplossing om het stabieler en beter beschikbaar te maken. Sterker nog, je maakt het alleen maar erger omdat meerdere onderdelen de kansen op failures verhogen. Een moderne omgeving verdeelt de workloads over meerdere instances (bv. netwerk, clusters), wat helpt bij het optimaliseren van het gebruik van resources, beste performance, kortere responstijden en het vermijden van overbelasting door gebruik van load balancing. Hieronder valt ook het overschakelen naar een standby server/netwerk in geval van een storing, bekend als failover systemen.

Hoe realiseer je een high availability omgeving?

    1. Verwijder single points of failure
    2. Betrouwbare failovers
    3. Verschillende geografische locaties

Verwijder single points of failure

Door redundantie voorkom je dat door het falen van een component het hele systeem faalt. Een voor de hand liggende oplossing is om je applicatie over meerdere servers te implementeren. Hierbij kun je de belasting verdelen, zodat bij uitval of overbelasting van één server een andere server deze functies kan overnemen

Betrouwbare failovers

In systemen die redundant zijn uitgevoerd kan het voorkomen dat het failover mechanisme zelf een single point of failure wordt. Een betrouwbare, automatische, failover staat of valt bij een goede healthcheck. Een check die door de loadbalancer zeer regelmatig wordt uitgevoerd om te controleren of de backend nog gezond is. De healthcheck hoort alle aspecten van een applicatie te controleren zoals de database en storage.

Is een healthcheck niet gelukt, dan hoort de backend als ongezond te worden gemarkeerd en er niet langer verkeer naar toe gestuurd moeten worden. Daarnaast is het verstandig om een DevOps engineer in te schakelen die controleert of de redundantie vanzelf hersteld of dat het handmatig moet gebeuren.

Verschillende geografische locaties

Als jouw applicaties en databases op servers leven die op dezelfde fysieke locatie staan en er gaat iets mis met die locatie, dan kan dit alsnog tot flinke downtime leiden. Zorg er dus voor dat jouw servers op verschillende locaties staan. Dit kan door gebruik van meerdere datacenters of availability zones.

Best practices High Availability omgevingen

Wil je systeem failures onder de duim houden en zowel geplande als ongeplande downtime voorkomen? Het gebruik van een High Availability (HA) architectuur wordt dan sterk aangeraden, vooral voor bedrijfskritische applicaties. DevOps-ers bij Cyso staan erop dat elk onderdeel goed ontworpen en grondig getest moet zijn om altijd beschikbaar te zijn. Het ontwerp en de implementatie van een HA architectuur kan een flinke uitdaging zijn, gezien het brede scala aan software, hardware en implementatie opties. Je zal hiervoor hiervoor de eisen van de omgeving in kaart moeten brengen. Dit kan zowel vanuit business perspectief zijn als vanuit de techniek. De gekozen architectuur moet kunnen voldoen aan de gewenste niveaus van security, schaalbaarheid, performance en beschikbaarheid. Naast het ontwerpen van de architectuur kunnen organisaties de volgende best practices in acht nemen voor het online houden van hun cruciale applicaties:

1. Disaster Recovery

Welk back-up systeem het beste past bij jouw organisatie hangt vooral samen met het type business en welke eisen jij stelt aan de recovery time objective (RTO, de maximale restore tijd) en de recovery point objective (RPO, de hoeveelheid van dataverlies bij een restore).

Een betrouwbare en consistente back-up maken – en zeker weten dat je alle benodigde data terugkrijgt op het moment dat je moet restoren – klinkt als iets vanzelfsprekends, maar is vaak niet het geval. Een goed doordachte back-up-methode bespaart een hoop ellende in het geval dat er iets misgaat.

Er zijn verschillende methodes om data veilig te stellen: file-based back-ups, snapshots en image-based back-ups. Los van welke cloud je gebruikt, denk goed na over welke garanties er gegeven moeten worden op de RTO en RPO. Bepaal daarna hoe disaster recovery geregeld moet worden. Wij bevelen aan om regelmatig een restore test uit te voeren.

Kies vervolgens de back-up-methode die het beste aansluit bij jouw business. Ben je gebonden aan specifieke eisen rond de RTO/RPO, dan is de kans groot dat deze het best te realiseren zijn binnen een private of multi-cloud omgeving.

2. Clustering

Clustering maakt het mogelijk om instant failover applicatie diensten te bieden in het geval van een fout of storing. Een applicatie met clusters kan bronnen van meerdere servers aanroepen en terugvallen op een secundaire server als de hoofdserver offline gaat.

Een high-availability cluster bevat meerdere nodes. Dit betekent dat elke node losgekoppeld of afgesloten kan worden van het netwerk terwijl de rest van het cluster normaal blijft werken zolang ten minste twee nodes volledig operationeel zijn. Dit houdt ook in dat elke node individueel geüpgraded kan worden en opnieuw aangesloten terwijl het cluster actief is.

3. Schaalbare databases

Een crash van een database kan leiden tot verlies van data, wat een kostbare aangelegenheid kan zijn. Redundantie kan bereikt worden door secondary servers te gebruiken die het kunnen overnemen als de primary server onbeschikbaar wordt door een crash of onderhoud. Een andere optie om de database te schalen is door sharding. Een shard is een horizontale partitie in een database, waar rijen van dezelfde tabel worden uitgevoerd op een aparte server.

4. Maak een (nood)plan

Het implementeren van best practices voor high availability is in essentie het voorbereiden op downtime, maar dat is niet het enige wat je kan doen als organisatie. Het wordt aangeraden om storing logs en andere data bij te houden om problemen en trends te signaleren. Dat kan alleen door het continue monitoren van de operationele workload.

Een noodplan voor herstel moet niet alleen goed zijn vastgelegd maar ook regelmatig getest worden om de effectiviteit ervan te verzekeren in geval van ongeplande storingen.

Engineers moeten hun vaardigheden verbeteren bij het ontwerpen, implementeren en onderhouden van hoge beschikbaarheid architecturen. Verder moet er een securitybeleid zijn met procedures in geval van downtime door inbreuken of aanvallen op het systeem.

Past een high availability omgeving bij jouw organisatie?

Terugkomend op ons voorbeeld, laten we zeggen dat we onze React applicatie zes keer willen deployen. Elke versie van de applicatie heeft ongeveer 128MB RAM nodig en we willen regels vastleggen wanneer een herstart van de applicatie of container gedaan moet worden. Deze regels kan je instellen in Kubernetes. Als onze applicatie crasht, dan zal Kubernetes het automatisch opnieuw starten in de staat die we hiervoor hebben aangegeven.

1. Je applicatie moet hiervoor geschikt zijn

    Denk hierbij bijvoorbeeld aan sessies. De applicaties, verspreid over meerdere servers, moeten allemaal om kunnen gaan met dat er sessies leven tussen de servers. Hierbij zijn technieken voor sessie storage nodig, zoals bijvoorbeeld Memcached of Redis.
    Als de applicatie shared bestanden heeft die op alle servers nodig zijn dan moet je hier shared storage voor hebben. Denk aan bijvoorbeeld een avatar van een gebruiker, die moet op alle servers aanwezig zijn. Een alternatieve oplossing kan bijvoorbeeld zijn een Object Store (Swift/S3)

2. Developers moeten om kunnen gaan met een high availability omgeving

    Een HA omgeving kan erg snel complex worden. Developers moeten kunnen omgaan met het feit dat er een nieuwe manier van deployen is: niet langer op een statische server maar op meerdere. Een andere optie is in containers of op een Kubernetes platform.

3. Deployment strategie met CI/CD

    Omdat de applicatie niet op een, maar op twee of drie plekken aangepast moet worden bij een release van een nieuwe versie, moet je een deploy strategie kiezen die hierbij past. Een CI/CD straat helpt daarbij. Je kan vanaf een Git repository een deployment automatiseren.

Conclusie: voor iedereen een high availability omgeving?

Door je omgeving in te zetten als een high availability architectuur voorkom je dat een storing of calamiteit invloed heeft op de beschikbaarheid van data en applicaties. Het sleutelwoord hier is redundantie. Echter brengt een HA architectuur ook een risico met zich mee. Een HA architectuur is altijd ingewikkelder en dit vergroot de kans op een storing als de organisatie er niet klaar voor is. Als de developers nog niet klaar zijn voor een complexe omgeving kan het soms beter zijn om niet voor een HA architectuur te kiezen.

Is een high availability omgeving wat voor jouw organisatie?

Heb je vragen hoe je de best practices moet implementeren of hoe een high availability omgeving er voor jouw organisatie uit kan zien? Bij Cyso helpen we jouw websites, bedrijfskritische platformen en applicaties 24×7 online te houden. We zijn een 100% Nederlandse, onafhankelijke managed hosting provider met roots in Alkmaar. Met onze persoonlijke & cloud-neutrale aanpak zorgen we voor passende hosting-oplossingen voor elke business case. Laten we een (virtueel) kopje koffie pakken. Neem contact met ons op!


Kwaliteit. Betrouwbaar. Betrokken.
  • 24/7 service support
  • Nederlandse datacenters
  • ISO 27001 gecertificeerd
Bel me terug