Betrouwbaarheid
Stel dat u een klinisch systeem uitvoert voor een organisatie in de gezondheidszorg. Artsen en verzorgers hebben weinig tolerantie voor downtime. Ze moeten de hele tijd toegang hebben tot klinische IT-systemen om ervoor te zorgen dat ze altijd de hoogste kwaliteit zorg 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 les leert u hoe u elementen uit de betrouwbaarheidspijler in uw architectuurontwerp kunt opnemen.
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 ervoor zorgen dat uw toepassing gelokaliseerde fouten afhandelt door hoge beschikbaarheid in elk onderdeel te integreren. Dit toepassingsontwerp elimineert single points of failure. Een dergelijk ontwerp beperkt ook het effect van onderhoud aan de infrastructuur tot het minimum. Ontwerpen voor hoge beschikbaarheid zijn doorgaans bedoeld om de impact van incidenten snel en automatisch te elimineren en ervoor te zorgen dat het systeem aanvragen met weinig tot geen effect kan verwerken.
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.
Het opnemen van hoge beschikbaarheid en herstelbaarheid in uw architectuurontwerp beschermt uw bedrijf tegen financiële verliezen die het gevolg zijn van downtime en verloren gegevens. Ze beschermen uw bedrijf ook tegen een verlies van reputatie als gevolg van een verlies van vertrouwen van uw klanten.
Met ontwerpen voor betrouwbaarheid zorgt u ervoor dat uw toepassing kan voldoen aan de verplichtingen die u uw klanten hebt toegezegd. U wilt ervoor zorgen dat uw systemen beschikbaar zijn voor eindgebruikers en kunnen herstellen na eventuele fouten.
Een architectuur met hoge beschikbaarheid bouwen
Voor beschikbaarheid identificeert u de SLA (Service Level Agreement) waarvoor u zich verbindt. Bekijk de mogelijke mogelijkheden voor hoge beschikbaarheid van uw toepassing ten opzichte van uw SLA en bepaal 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 belangrijk inzicht in de prioriteiten van uw organisatie en wordt de rol van uw toepassing verduidelijkt. De resultaten van uw analyse moeten deze duurwaarden voor uw toepassing bevatten:
Beoogde herstelpunt (RPO): 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.
Beoogde hersteltijd (RTO):de maximale duur van acceptabele downtime, waarbij uw specificatie 'downtime' definieert. Als de acceptabele downtime bijvoorbeeld acht uur is als er een noodgeval is, 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 is gericht op het ophalen van gegevens na een noodgeval.