Betrouwbaarheid

• 10 minuten

Stel dat u een klinisch systeem uitvoert voor een organisatie in de gezondheidszorg. Artsen en verzorgers hebben weinig tolerantie voor downtime. Ze moeten dag en nacht toegang hebben tot klinische IT-systemen om er zeker van te zijn dat ze te allen tijde de beste zorg kunnen leveren.

Om te voldoen aan deze vereisten van artsen, moeten de toepassingen fouten kunnen afhandelen met minimale gevolgen voor de gebruikers. Hoe zorgen ze ervoor dat hun toepassingen blijven werken, zowel bij lokale incidenten als in grootschalige noodsituaties?

In deze eenheid leert u elementen van de pijler betrouwbaarheid in uw architectuurontwerp op te nemen.

Wat is betrouwbaarheid?

In een complexe toepassing kan een willekeurig aantal dingen op elke schaal verkeerd gaan. Afzonderlijke servers en harde schijven kunnen uitvallen. Bij een probleem met de implementatie kunnen per ongeluk alle tabellen in een database worden verwijderd. Gehele datacentra kunnen onbereikbaar worden. Bij een incident met ransomware kunnen al uw gegevens opzettelijk worden versleuteld. Het is essentieel dat uw toepassing betrouwbaar blijft en zowel gelokaliseerde als grote incidenten kan afhandelen.

Ontwerpen voor betrouwbaarheid omvat het handhaven van de bedrijfstijd bij kleinschalige incidenten en in tijdelijke omstandigheden, zoals gedeeltelijke netwerkstoringen. U kunt controleren of uw toepassing gelokaliseerde fouten kan verwerken door de integratie van hoge beschikbaarheid in elk onderdeel van de toepassing en door het elimineren van SPOF's (Single Points of Failure). Een dergelijk ontwerp beperkt ook het effect van onderhoud aan de infrastructuur tot het minimum. Bij ontwerpen voor een hoge beschikbaarheid wordt doorgaans geprobeerd de gevolgen van incidenten snel en automatisch te verhelpen en ervoor te zorgen dat het systeem aanvragen kan blijven verwerken, met weinig tot geen gevolgen.

Ontwerpen voor betrouwbaarheid zijn bovendien gericht op herstel na gegevensverlies en grootschalige calamiteiten. Herstel van dit soort incidenten vereist vaak actief ingrijpen, hoewel stappen voor automatisch herstel ervoor kunnen zorgen dat het herstel minder tijd in beslag neemt. Dit soort incidenten kan leiden tot enige downtime of permanent gegevensverlies. Herstel na noodgevallen heeft net zoveel te maken met een zorgvuldige planning als met de uitvoering.

Door een hoge beschikbaarheid en herstelmogelijkheden in het ontwerp van uw architectuur op te nemen, wordt uw bedrijf beschermd tegen financiële verliezen als gevolg van downtime en gegevensverlies. Deze zorgen ervoor dat er geen negatieve gevolgen voor uw reputatie zijn doordat uw klanten vertrouwen in u verliezen.

Met ontwerpen voor betrouwbaarheid zorgt u ervoor dat uw toepassing kan voldoen aan de verplichtingen die u uw klanten hebt toegezegd. Dit omvat het controleren of uw systemen beschikbaar zijn voor eindgebruikers en van fouten kunnen herstellen.

Een architectuur met hoge beschikbaarheid bouwen

Stel voor beschikbaarheid de SLA (Service Level Agreement) vast waartoe u zich hebt verplicht. Onderzoek de potentiële mogelijkheden voor hoge beschikbaarheid van uw toepassing ten opzichte van uw SLA en stel vast waar u de juiste dekking hebt en waar u verbeteringen moet aanbrengen. Uw doel is om redundantie toe te voegen aan onderdelen van de architectuur, zodat u minder gauw een storing ervaart.

Voorbeelden van een ontwerp voor hoge beschikbaarheid zijn onder meer clustering en taakverdeling:

• Bij clustering wordt een enkele virtuele machine vervangen door een serie gecoördineerde virtuele machines. Wanneer één virtuele machine uitvalt of niet meer bereikbaar is, kunnen services overschakelen op een andere die de aanvragen afhandelt.

• Taakverdeling verspreidt aanvragen over veel instanties van een service, waardoor uitgevallen instanties worden gedetecteerd en wordt voorkomen dat aanvragen daarnaar worden doorgestuurd.

Een architectuur bouwen die van fouten kan herstellen

Voor herstelmogelijkheden moet u een analyse uitvoeren die uw mogelijke gegevensverlies en scenario's voor ernstige uitvaltijd onderzoekt. Uw analyse moet een verkenning van herstelstrategieën en een kosten-batenanalyse voor elke strategie bevatten. In deze oefening krijgt u een belangrijk inzicht in de prioriteiten van uw organisatie en wordt de rol van uw toepassing verduidelijkt. De resultaten moeten het volgende bevatten:

• RPO (Recovery Point Objective, beoogd herstelpunt): De maximale duur van acceptabel gegevensverlies. RPO wordt gemeten in tijdseenheden, niet in volume. Voorbeelden zijn 30 minuten aan gegevens, vier uur aan gegevens enzovoort. RPO draait om het beperken en herstellen van gegevensverlies, niet gegevensdiefstal.

• RTO (Recovery Time Objective): De maximaal aanvaardbare duur van de downtime, waarbij downtime volgens uw eigen specificatie wordt gedefinieerd. Als de acceptabele duur van de downtime bijvoorbeeld acht uur is wanneer zich een noodgeval voordoet, is uw RTO acht uur.

Nadat de RPO en RTO zijn bepaald, kunt u in uw architectuur mogelijkheden voor back-up, terugzetten, replicatie en herstel ontwerpen om aan deze doelstellingen te voldoen.

Elke cloudprovider biedt een pakket services en functies waarmee u de beschikbaarheid en herstelmogelijkheden van uw toepassing kunt verbeteren. Gebruik, indien mogelijk, bestaande services en best practices en kom niet in de verleiding om uw eigen te maken.

Harde schijven kunnen uitvallen, datacenters kunnen onbereikbaar worden en hackers kunnen aanvallen. Het is belangrijk dat uw reputatie bij uw klanten goed blijft met behulp van de beschikbaarheid en herstelmogelijkheden. Beschikbaarheid is gericht op het handhaven van bedrijfstijd bij omstandigheden zoals storingen, en herstelmogelijkheden zijn gericht op het ophalen van gegevens na een noodgeval.

Test uw kennis