In de echte wereld kunnen er situaties zijn waarin een dip in de prestaties van uw servers optreedt als gevolg van gebeurtenissen die variëren van een plotselinge piek in het verkeer kan leiden tot een plotselinge stroomstoring. Het kan nog veel erger en uw servers kunnen worden verlamd – ongeacht of uw toepassingen worden gehost in de cloud of een fysieke machine. Dergelijke situaties zijn onvermijdelijk. Maar in plaats van te hopen dat het niet gebeurt, wat u eigenlijk zou moeten doen is uw systemen zo in te richten dat ze niet uitvallen.
Het antwoord op het probleem is het gebruik van High Availability (HA) configuratie of architectuur. Een hoge beschikbaarheidsarchitectuur is een benadering van het definiëren van de componenten, modules of implementatie van diensten van een systeem die optimale operationele prestaties garandeert, zelfs in tijden van hoge belasting. Hoewel er geen vaste regels zijn voor het implementeren van HA-systemen, zijn er over het algemeen een paar goede praktijken die men moet volgen, zodat u het meeste haalt uit de minste middelen.
Waarom heeft u het nodig?
Laten we downtime definiëren voordat we verder gaan. Downtime is de periode waarin uw systeem (of netwerk) niet beschikbaar is voor gebruik, of niet reageert. Downtime kan een bedrijf enorme verliezen opleveren, omdat al hun diensten stil komen te liggen als hun systemen down zijn. In augustus 2013 lag Amazon 15 minuten plat (zowel web- als mobiele diensten), en verloor uiteindelijk meer dan 66.000 dollar per minuut. Dat zijn enorme aantallen, zelfs voor een bedrijf van de omvang van Amazon.
Er zijn twee soorten downtimes- geplande en ongeplande. Een geplande downtime is het gevolg van onderhoud, dat onvermijdelijk is. Dit omvat het toepassen van patches, het bijwerken van software of zelfs wijzigingen in het databaseschema. Een ongeplande downtime wordt echter veroorzaakt door een onvoorziene gebeurtenis, zoals hardware- of softwarestoringen. Dit kan gebeuren door stroomuitval of het falen van een component. Geplande downtime wordt over het algemeen niet meegenomen in performance berekeningen.
Het belangrijkste doel van het implementeren van een High Availability architectuur is om ervoor te zorgen dat uw systeem of applicatie geconfigureerd is om verschillende belastingen en verschillende storingen aan te kunnen met minimale of geen downtime. Er zijn meerdere componenten die u helpen dit te bereiken, en we zullen ze kort bespreken.
Hoe wordt beschikbaarheid gemeten?
Organisaties die van plan zijn om een cloudinfrastructuur volledig te benutten, moeten ook in staat zijn om te voldoen aan de eisen voor 24/7 beschikbaarheid. Beschikbaarheid kan worden gemeten als het percentage van de tijd dat systemen beschikbaar zijn.
x = (n – y) * 100/n
Waarbij n het totale aantal minuten in een kalendermaand is en y het totale aantal minuten dat de dienst niet beschikbaar is in de gegeven kalendermaand. Hoge beschikbaarheid verwijst eenvoudigweg naar een component of systeem dat gedurende een wenselijk lange periode continu operationeel is. De wijdverbreide, maar bijna onhaalbare norm voor de beschikbaarheid van een product of systeem wordt aangeduid met de term “vijf negens” (99,999 procent) beschikbaarheid. Hoge beschikbaarheid is een vereiste voor elke onderneming die haar bedrijf hoopt te beschermen tegen de risico’s die een systeemstoring met zich meebrengt. Deze risico’s kunnen leiden tot miljoenen dollars verlies van inkomsten.
Is het echt het geld waard?
Het feit dat het kiezen voor een hoge beschikbaarheid architectuur u hogere prestaties geeft is prima, maar het komt op een grote kosten ook. Je moet jezelf afvragen of je denkt dat de beslissing gerechtvaardigd is vanuit financieel oogpunt.
Er moet een beslissing worden genomen over de vraag of de extra uptime echt de hoeveelheid geld waard is die er in moet worden gestoken. U moet zich afvragen hoe schadelijk mogelijke downtime voor uw bedrijf kan zijn en hoe belangrijk uw diensten zijn voor het runnen van uw bedrijf.
Hoe bereiken we het?
Nu u hebt besloten ermee door te gaan, laten we het eens hebben over de manieren om het te implementeren. Het is niet logisch dat het toevoegen van meer componenten aan een systeem niet helpt om het stabieler te maken en een hoge beschikbaarheid te bereiken. Het kan juist leiden tot het tegenovergestelde, omdat meer componenten de kans op storingen vergroten. Moderne ontwerpen maken het mogelijk de werklast te verdelen over meerdere instanties, zoals een netwerk of een cluster, wat helpt bij het optimaliseren van het gebruik van middelen, het maximaliseren van de output, het minimaliseren van de responstijden en het vermijden van overbelasting van een systeem in het proces dat bekend staat als load balancing. Het gaat ook om het overschakelen op een stand-by resource zoals een server, component of netwerk in het geval van een storing van een actieve, bekend als Failover-systemen.
Gebruik van meerdere applicatieservers:
Stel je voor dat je een enkele server hebt om je diensten te leveren en een plotselinge piek in het verkeer leidt tot het falen ervan (of crasht het). In een dergelijke situatie, totdat uw server opnieuw is opgestart, kunnen geen verzoeken meer worden geserveerd, wat leidt tot een downtime.
De voor de hand liggende oplossing hier is om uw toepassing uit te rollen over meerdere servers. Je moet de belasting over al deze verdelen, zodat geen van hen wordt overbelast en de output optimaal is. Je kunt ook delen van je applicatie op verschillende servers uitrollen. Er kan bijvoorbeeld een aparte server zijn voor het afhandelen van e-mails of een aparte voor het verwerken van statische bestanden zoals afbeeldingen (zoals een Content Delivery Network).
Verschalen van databases:
Databases zijn de meest populaire en misschien wel een van de meest conceptueel eenvoudige manieren om gebruikersgegevens op te slaan. Je moet niet vergeten dat databases voor je diensten even belangrijk zijn als je applicatieservers. Databases draaien op aparte servers (zoals de Amazon RDS) en zijn ook vatbaar voor crashes. Wat erger is, is dat crashes van databases kunnen leiden tot verlies van gebruikersgegevens, wat kostbaar kan blijken te zijn.
Redundantie is een proces dat systemen creëert met een hoge mate van beschikbaarheid door het bereiken van detecteerbaarheid van storingen en het vermijden van storingen met een gemeenschappelijke oorzaak. Dit kan worden bereikt door slaves in stand te houden, die kunnen ingrijpen als de hoofdserver crasht. Een ander interessant concept voor het schalen van databases is sharding. Een shard is een horizontale partitie in een database, waar rijen van dezelfde tabel die vervolgens wordt uitgevoerd op een aparte server.
Diversified Geographical Locations:
Het opschalen van uw toepassingen en vervolgens uw databases is een echt grote stap vooruit, maar wat als alle servers op dezelfde fysieke locatie en iets vreselijks zoals een natuurramp treft het datacenter waar uw servers zich bevinden? Dit kan leiden tot potentieel enorme downtimes.
Het is daarom absoluut noodzakelijk dat u uw servers op verschillende locaties houdt. De meeste moderne webdiensten bieden u de mogelijkheid de geografische locatie van uw servers te kiezen. U moet verstandig kiezen om ervoor te zorgen dat uw servers worden verspreid over de hele wereld en niet gelokaliseerd in een gebied.
In dit bericht heb ik geprobeerd om de basisideeën die het idee van hoge beschikbaarheid architectuur vormen aan te raken. Uiteindelijk is het duidelijk dat geen enkel systeem alle problemen kan oplossen. Daarom moet u uw situatie zorgvuldig beoordelen en beslissen welke opties het beste passen. We hopen dat dit u heeft geïntroduceerd in de wereld van hoge beschikbaarheidsarchitectuur en u heeft geholpen te beslissen hoe u dit voor uzelf kunt bereiken.
Wat zijn de beste praktijken?
Om systeemstoringen te beteugelen en zowel geplande als ongeplande downtime op afstand te houden, wordt het gebruik van een High Availability (HA)-architectuur sterk aanbevolen, vooral voor missiekritische toepassingen. Beschikbaarheidsexperts dringen erop aan dat de onderdelen van een systeem goed ontworpen en uitvoerig getest moeten zijn, wil het systeem hoogbeschikbaar zijn. Het ontwerp en de daaropvolgende implementatie van een architectuur voor hoge beschikbaarheid kan moeilijk zijn, gezien de grote verscheidenheid aan software, hardware en implementatieopties. Een succesvolle inspanning begint echter meestal met duidelijk gedefinieerde en goed begrepen bedrijfsvereisten. De gekozen architectuur moet in staat zijn om te voldoen aan de gewenste niveaus van beveiliging, schaalbaarheid, prestaties en beschikbaarheid.
De enige manier om te garanderen dat compute-omgevingen een gewenst niveau van operationele continuïteit hebben tijdens de productie-uren is door ze te ontwerpen met een hoge beschikbaarheid. Naast een goed ontwerp van de architectuur kunnen bedrijven cruciale toepassingen online houden door de aanbevolen best practices voor hoge beschikbaarheid in acht te nemen.
- Back-ups, herstel en replicatie van gegevens
Het kenmerk van een goed plan voor gegevensbescherming dat bescherming biedt tegen systeemstoringen, is een gedegen strategie voor back-up en herstel. Waardevolle gegevens mogen nooit worden opgeslagen zonder goede back-ups, replicatie of de mogelijkheid om de gegevens opnieuw te maken. Elk datacenter moet van tevoren plannen voor gegevensverlies of -corruptie. Fouten in gegevens kunnen problemen veroorzaken bij de authenticatie van klanten, financiële rekeningen beschadigen en vervolgens de geloofwaardigheid van het bedrijfsleven aantasten. De aanbevolen strategie voor het behoud van de gegevensintegriteit is het maken van een volledige back-up van de primaire database en vervolgens incrementeel testen van de bronserver op gegevensbeschadigingen. Het maken van volledige back-ups staat voorop bij het herstellen van catastrofale systeemstoringen.
- Clustering
Zelfs met de hoogste kwaliteit van software-engineering, zullen alle toepassingsdiensten op een gegeven moment falen. Bij hoge beschikbaarheid gaat het om het leveren van toepassingsdiensten, ongeacht storingen. Clustering kan onmiddellijke failover-applicatiediensten bieden in het geval van een storing. Een applicatiedienst die ‘cluster aware’ is, kan resources van meerdere servers aanroepen; hij valt terug op een secundaire server als de hoofdserver offline gaat. Een High Availability cluster bestaat uit meerdere nodes die informatie delen via gedeelde datageheugenrasters. Dit betekent dat een node kan worden losgekoppeld of afgesloten van het netwerk en dat de rest van het cluster normaal blijft werken, zolang ten minste één node volledig functioneel is. Elke node kan afzonderlijk worden geüpgraded en weer worden aangesloten terwijl het cluster in bedrijf blijft. De hoge kosten van de aanschaf van extra hardware voor de implementatie van een cluster kunnen worden beperkt door een gevirtualiseerd cluster op te zetten dat gebruikmaakt van de beschikbare hardwarebronnen.
- Network Load Balancing
Load balancing is een effectieve manier om de beschikbaarheid van kritieke webgebaseerde toepassingen te vergroten. Wanneer er serverstoringen worden gedetecteerd, worden deze naadloos vervangen doordat het verkeer automatisch wordt herverdeeld over servers die nog wel actief zijn. Niet alleen leidt load balancing tot een hoge beschikbaarheid, het vergemakkelijkt ook de incrementele schaalbaarheid. Netwerkload balancing kan worden bereikt via een ‘pull’- of een ‘push’-model. Het maakt een hoger niveau van fouttolerantie binnen servicetoepassingen mogelijk.
- Fail Over-oplossingen
Hoge-beschikbaarheidsarchitectuur bestaat van oudsher uit een reeks losjes gekoppelde servers die failover-mogelijkheden hebben. Failover is in feite een operationele back-upmodus waarbij de functies van een systeemcomponent worden overgenomen door een secundair systeem in het geval dat het primaire systeem offline gaat, hetzij door een storing, hetzij door geplande uitvaltijd. Een “koude failover” doet zich voor wanneer de secundaire server pas wordt opgestart nadat de primaire volledig is uitgeschakeld. Een “hot failover” doet zich voor wanneer alle servers tegelijk draaien, en de belasting op een gegeven moment volledig op één server wordt gericht. In beide scenario’s worden taken automatisch overgeheveld naar een stand-by systeemcomponent, zodat het proces voor de eindgebruiker zo naadloos mogelijk blijft verlopen. Failover kan worden beheerd via DNS, in een goed gecontroleerde omgeving.
- Geografische redundantie
Geo-redundantie is de enige verdedigingslinie als het gaat om het voorkomen van uitval van diensten bij catastrofale gebeurtenissen, zoals natuurrampen die systeemuitval veroorzaken. Net als in het geval van geo-replicatie worden meerdere servers ingezet op geografisch verschillende locaties. De locaties moeten wereldwijd gedistribueerd zijn en niet gelokaliseerd in een specifiek gebied. Het is van cruciaal belang om op elk van de locaties onafhankelijke applicatiestacks te draaien, zodat in het geval van een storing op één locatie, de andere door kan blijven draaien. Idealiter zouden deze locaties volledig onafhankelijk van elkaar moeten zijn.
- Plan voor mislukking
Ondanks het feit dat het toepassen van de beste praktijken voor hoge beschikbaarheid in wezen neerkomt op het plannen voor mislukking, zijn er andere acties die een organisatie kan ondernemen om beter voorbereid te zijn in het geval van een systeemstoring die tot uitvaltijd leidt. Organisaties moeten gegevens over storingen of het gebruik van hulpbronnen bijhouden, die kunnen worden gebruikt om problemen te isoleren en trends te analyseren. Deze gegevens kunnen alleen worden verzameld door continu toezicht op de operationele werklast. Er kan een helpdesk voor herstel worden opgezet om probleeminformatie te verzamelen, de probleemhistorie vast te stellen en onmiddellijk te beginnen met het oplossen van problemen. Een herstelplan moet niet alleen goed worden gedocumenteerd, maar ook regelmatig worden getest om de bruikbaarheid ervan bij ongeplande onderbrekingen te garanderen. Opleiding van personeel op het gebied van beschikbaarheidstechniek zal hun vaardigheden verbeteren bij het ontwerpen, implementeren en onderhouden van architecturen met een hoge beschikbaarheid. Beveiligingsbeleid moet ook worden ingevoerd om uitval van systemen als gevolg van inbreuken op de beveiliging te beperken.
Voorbeeld: FileCloud High Availability Architecture
In het volgende diagram wordt uitgelegd hoe FileCloud-servers kunnen worden geconfigureerd voor High Availability om de betrouwbaarheid van de service te verbeteren en downtime te verminderen. Klik hier voor meer informatie.