Aanbevelingen voor zelfherstel en zelfbehoud

  • Artikel

Is van toepassing op deze aanbeveling voor de betrouwbaarheidschecklist van Azure Well-Architected Framework:

RE:07 Verbeter de tolerantie en herstelbaarheid van uw workload door zelfbehoud en zelfherstelmaatregelen te implementeren. Bouw mogelijkheden in de oplossing in door gebruik te maken van op infrastructuur gebaseerde betrouwbaarheidspatronen en ontwerppatronen op basis van software om fouten en tijdelijke fouten van onderdelen af te handelen. Bouw mogelijkheden in het systeem in om fouten met oplossingsonderdelen te detecteren en automatisch corrigerende actie te starten terwijl de workload met volledige of verminderde functionaliteit blijft werken.

Gerelateerde handleidingen:Tijdelijkefoutenvoor achtergrondtaken |

In deze handleiding worden de aanbevelingen beschreven voor het inbouwen van mogelijkheden voor zelfherstel en zelfbehoud in uw toepassingsarchitectuur om de betrouwbaarheid te optimaliseren.

Mogelijkheden voor zelfbehoud voegen tolerantie toe aan uw workload. Ze verminderen de kans op een volledige storing en zorgen ervoor dat uw workload in een gedegradeerde status werkt terwijl mislukte onderdelen worden hersteld. Zelfherstelmogelijkheden helpen u downtime te voorkomen door foutdetectie en automatische corrigerende acties in te bouwen om te reageren op verschillende fouttypen.

In deze handleiding worden ontwerppatronen beschreven die gericht zijn op zelfbehoud en zelfherstel. Neem ze op in uw workload om de tolerantie en herstelbaarheid te verbeteren. Als u geen patronen implementeert, lopen uw apps het risico te mislukken wanneer zich onvermijdelijke problemen voordoen.

Definities

Termijn Definitie
Zelfherstellend De mogelijkheid van uw workload om problemen automatisch op te lossen door de betrokken onderdelen te herstellen en indien nodig een failover uit te voeren naar redundante infrastructuur.
Zelfbehoud De mogelijkheid van uw workload om bestand te zijn tegen potentiële problemen.

Belangrijke ontwerpstrategieën

Richtlijnen voor zelfbehoud

Als u uw workload wilt ontwerpen voor zelfbehoud, volgt u de ontwerppatronen voor infrastructuur- en toepassingsarchitectuur om de tolerantie van uw workload te optimaliseren. Om de kans op een volledige toepassingsstoring te minimaliseren, verhoogt u de tolerantie van uw oplossing door single points of failure te elimineren en de straal van storingen te minimaliseren. De ontwerpbenaderingen in dit artikel bieden verschillende opties om de tolerantie van uw workload te versterken en te voldoen aan de gedefinieerde betrouwbaarheidsdoelen van uw workload.

Richtlijnen en patronen voor infrastructuurontwerp

Op infrastructuurniveau moet een redundant architectuurontwerp uw kritieke stromen ondersteunen, met resources die zijn geïmplementeerd in beschikbaarheidszones of regio's. Implementeer waar mogelijk automatisch schalen . Automatisch schalen helpt uw workload te beschermen tegen onverwachte pieken in activiteit, waardoor uw infrastructuur verder wordt versterkt.

Gebruik het patroon Implementatiestempels of het bulkhead-patroon om de straal van de ontploffing te minimaliseren wanneer zich problemen voordoen. Deze patronen helpen om uw workload beschikbaar te houden als een afzonderlijk onderdeel niet beschikbaar is. Gebruik de volgende toepassingsontwerppatronen in combinatie met uw strategie voor automatisch schalen.

  • Patroon implementatiestempels: Richt een gevarieerde groep resources in, beheer en bewaak deze om meerdere workloads of tenants te hosten en uit te voeren. Elke afzonderlijke kopie wordt een stempel genoemd, of soms een service-eenheid, schaaleenheid of cel.

  • Bulkhead-patroon: Partitioneer service-exemplaren in verschillende groepen, ook wel pools genoemd, op basis van de belasting en beschikbaarheidsvereisten van de consument. Dit ontwerp helpt bij het isoleren van fouten en stelt u in staat om de servicefunctionaliteit voor sommige gebruikers te behouden, zelfs tijdens een storing.

Richtlijnen en patronen voor het ontwerpen van toepassingen

Vermijd het bouwen van monolithische toepassingen in uw toepassingsontwerp. Gebruik losjes gekoppelde services of microservices die met elkaar communiceren via goed gedefinieerde standaarden om het risico op uitgebreide problemen bij storingen bij één onderdeel te verminderen. U kunt bijvoorbeeld het gebruik van een servicebus standaardiseren om alle asynchrone communicatie af te handelen. Het standaardiseren van communicatieprotocollen zorgt ervoor dat het ontwerp van toepassingen consistent en vereenvoudigd is, waardoor de workload betrouwbaarder is en gemakkelijker op te lossen wanneer er storingen optreden. Wanneer dit praktisch is, geeft u de voorkeur aan asynchrone communicatie tussen onderdelen boven synchrone communicatie om time-outproblemen, zoals onbestelbare berichten, te minimaliseren. De volgende ontwerppatronen helpen u bij het organiseren van uw workload en het definiëren van de communicatie tussen onderdelen op een manier die het beste voldoet aan uw bedrijfsvereisten.

  • Ambassador-patroon: Scheid uw bedrijfslogica van uw netwerkcode en tolerantielogica. Helper-services maken die netwerkaanvragen verzenden namens een consumentservice of toepassing. U kunt dit patroon gebruiken om mechanismen voor opnieuw proberen of circuitonderbreking te implementeren.

  • Asynchroon Request-Reply patroon: koppel back-endverwerking los van een front-endhost als back-endverwerking asynchroon moet zijn, maar de front-end een duidelijk antwoord nodig heeft.

  • Cache-Aside-patroon: laad gegevens op aanvraag uit een gegevensarchief in een cache. Dit patroon kan de prestaties verbeteren en zorgen voor consistentie tussen gegevens die in de cache zijn opgeslagen en gegevens in het onderliggende gegevensarchief.

  • Circuitonderbrekerpatroon: gebruik circuitonderbrekers om proactief te bepalen of een bewerking moet worden voortgezet of dat een uitzondering moet worden geretourneerd op basis van het aantal recente fouten.

  • Claimcontrolepatroon: splits een groot bericht in een claimcontrole en een nettolading. Verzend de claimcontrole naar het berichtenplatform en sla de nettolading op in een externe service. Met dit patroon kunnen grote berichten worden verwerkt terwijl de berichtenbus wordt beschermd en wordt voorkomen dat de client wordt overweldigd of vertraagd.

  • Patroon concurrerende consumenten: meerdere gelijktijdige consumenten in staat stellen berichten te verwerken die op hetzelfde berichtenkanaal worden ontvangen. Een systeem kan meerdere berichten gelijktijdig verwerken, waardoor de doorvoer wordt geoptimaliseerd, de schaalbaarheid en beschikbaarheid worden verbeterd en de werkbelasting in balans wordt.

  • Time-outs voor aanvragen configureren: time-outs van aanvragen configureren voor aanroepen naar services of databases. Time-outs voor databaseverbindingen zijn doorgaans ingesteld op 30 seconden.

  • Gatekeeper-patroon: beveilig toepassingen en services met behulp van een toegewezen hostexemplaar om aanvragen tussen clients en de toepassing of service te brokeren. De broker valideert en ontsmet de aanvragen en kan een extra beveiligingslaag bieden om de kwetsbaarheid voor aanvallen van het systeem te beperken.

  • Patroon voor taakverdeling op basis van wachtrijen: koppel de taken los van de service in uw oplossing door ertussen een wachtrij te gebruiken, zodat ze allemaal asynchroon kunnen worden uitgevoerd. Gebruik een wachtrij als buffer tussen een taak en een service die wordt aangeroepen om onregelmatige zware belasting soepel te laten verlopen, waardoor de service kan mislukken of een time-out voor de taak kan optreden. Dit patroon kan helpen het effect van pieken in de vraag op de beschikbaarheid en reactiesnelheid voor de taak en de service te minimaliseren.

  • Beperkingspatroon: beheer het verbruik van resources die worden gebruikt door een exemplaar van een toepassing, een afzonderlijke tenant of een hele service. Met dit patroon kan het systeem blijven functioneren en voldoen aan Service Level Agreements (SLA's), zelfs wanneer een toename van de vraag een extreme belasting voor resources met zich brengt.

  • Patroon voor tijdelijke foutafhandeling en patroon voor opnieuw proberen: implementeer een strategie voor het afhandelen van tijdelijke fouten om tolerantie te bieden in uw workload. Tijdelijke fouten zijn normale en verwachte gebeurtenissen in cloudomgevingen. Veelvoorkomende oorzaken van tijdelijke fouten zijn een tijdelijk verlies van de netwerkverbinding, een verbroken databaseverbinding of een time-out wanneer een service bezet is. Zie de handleiding voor het verwerken van tijdelijke fouten in deze reeks voor meer informatie over het ontwikkelen van een strategie voor opnieuw proberen.

Achtergrondtaken

Achtergrondtaken zijn een effectieve manier om de betrouwbaarheid van een systeem te verbeteren door taken los te koppelen van de gebruikersinterface (UI). Implementeer een taak als achtergrondtaak als deze geen gebruikersinvoer of feedback vereist en als dit geen invloed heeft op de reactiesnelheid van de gebruikersinterface.

Veelvoorkomende voorbeelden van achtergrondtaken zijn:

  • CPU-intensieve taken, zoals het uitvoeren van complexe berekeningen of het analyseren van structurele modellen.
  • I/O-intensieve taken, zoals het uitvoeren van meerdere opslagbewerkingen of het indexeren van grote bestanden.
  • Batchtaken, zoals het regelmatig bijwerken van gegevens of het verwerken van taken op een specifiek tijdstip.
  • Langlopende werkstromen, zoals het voltooien van een bestelling of het inrichten van services en systemen.

Zie Aanbevelingen voor achtergrondtaken voor meer informatie.

Zelfherstellende richtlijnen

Als u uw workload wilt ontwerpen voor zelfherstel, implementeert u foutdetectie, zodat automatische reacties worden geactiveerd en kritieke stromen probleemloos worden hersteld. Schakel logboekregistratie in om operationele inzichten te bieden over de aard van de fout en het succes van het herstel. De benaderingen die u gebruikt om zelfherstel voor een kritieke stroom te bereiken, zijn afhankelijk van de betrouwbaarheidsdoelen die zijn gedefinieerd voor die stroom en de onderdelen en afhankelijkheden van de stroom.

Richtlijnen voor het ontwerpen van infrastructuur

Op infrastructuurniveau moeten uw kritieke stromen worden ondersteund door een redundant architectuurontwerp met automatische failover ingeschakeld voor onderdelen die dit ondersteunen. U kunt automatische failover inschakelen voor de volgende typen services:

  • Rekenresources: Azure Virtual Machine Scale Sets en de meeste PaaS-rekenservices (Platform as a Service) kunnen worden geconfigureerd voor automatische failover.

  • Databases: Relationele databases kunnen worden geconfigureerd voor automatische failover met oplossingen zoals Azure SQL failoverclusters, AlwaysOn-beschikbaarheidsgroepen of ingebouwde mogelijkheden met PaaS-services. NoSQL-databases hebben vergelijkbare clusteringmogelijkheden en ingebouwde mogelijkheden voor PaaS-services.

  • Opslag: gebruik redundante opslagopties met automatische failover.

Richtlijnen en patronen voor het ontwerpen van toepassingen

  • Slechte actoren blokkeren: als u een client beperkt, betekent dit niet dat de client kwaadwillend heeft opgegeven. Dit kan betekenen dat de client het servicequotum heeft overschreden. Maar als een client consistent het quotum overschrijdt of zich anderszins slecht gedraagt, kunt u deze blokkeren. Definieer een out-of-band-proces voor een client om de blokkering op te heffen.

  • Circuitonderbrekerpatroon: als een fout zich blijft voordoen nadat uw mechanisme voor opnieuw proberen is gestart, loopt u het risico dat er trapsgewijze fouten optreden als gevolg van een groeiende achterstand van aanroepen. Een circuitonderbreker die is ontworpen om te werken met het mechanisme voor opnieuw proberen, beperkt het risico op trapsgewijze fouten door te voorkomen dat de app herhaaldelijk probeert een bewerking uit te voeren die waarschijnlijk mislukt.

  • Patroon compenserende transactie: als u een uiteindelijk consistente bewerking gebruikt die bestaat uit een reeks stappen, implementeert u het patroon Compenserende transactie. Als een of meer van de stappen mislukken, kunt u dit patroon gebruiken om het uitgevoerde werk ongedaan te maken.

  • Probleemloos degraderen: Soms kunt u een probleem niet omzeilen, maar u kunt verminderde functionaliteit bieden. Neem als voorbeeld een toepassing met een boekencatalogus. Als de toepassing de miniatuurafbeelding voor het omslag niet kan ophalen, dan kan er tijdelijk een vervangende afbeelding worden getoond. Volledige subsystemen zijn mogelijk niet-kritiek voor de toepassing. Voor een e-commercewebsite is het weergeven van productaanbeveling bijvoorbeeld waarschijnlijk minder belangrijk dan het verwerken van orders. Probleemloze degradatie kan ook automatische failoverbewerkingen omvatten. Wanneer een database automatisch een failover naar een replica uitvoert vanwege een probleem met het primaire exemplaar, worden de prestaties gedurende korte tijd verslechterd.

  • Leiderverkiezingspatroon: wanneer u een taak wilt coördineren, gebruikt u leiderverkiezing om een coördinator te selecteren, zodat één coördinator geen Single Point of Failure is. Als de coördinator niet slaagt, wordt er een nieuwe geselecteerd. In plaats van een volledig nieuw algoritme voor leiderverkiezing te implementeren, kunt u een standaardoplossing overwegen, zoals ZooKeeper.

  • Testpatronen: neem het testen op van de patronen die u implementeert als onderdeel van uw standaardtestprocedures.

  • Controlepunten gebruiken voor langlopende transacties: controlepunten kunnen tolerantie bieden als een langdurige bewerking mislukt. Wanneer de bewerking opnieuw wordt gestart, bijvoorbeeld als deze wordt opgehaald door een andere virtuele machine, kan deze worden hervat vanaf het laatste controlepunt. Overweeg om een mechanisme te implementeren waarmee statusinformatie over de taak met regelmatige tussenpozen wordt vastgelegd. Sla deze status op in duurzame opslag die toegankelijk is voor elk exemplaar van het proces dat de taak uitvoert. Als het proces wordt afgesloten, kan het werk dat het heeft uitgevoerd, worden hervat vanaf het laatste controlepunt met behulp van een ander exemplaar. Er zijn bibliotheken die deze functionaliteit bieden, zoals NServiceBus en MassTransit. Ze behouden transparant de status, waarbij de intervallen worden afgestemd op de verwerking van berichten uit wachtrijen in Azure Service Bus.

Geautomatiseerde zelfherstelacties

Een andere benadering van zelfherstel is het gebruik van geautomatiseerde acties die worden geactiveerd door uw bewakingsoplossing wanneer vooraf vastgestelde statuswijzigingen worden gedetecteerd. Als uw bewaking bijvoorbeeld detecteert dat een web-app niet reageert op aanvragen, kunt u automatisering bouwen via een PowerShell-script om de app-service opnieuw te starten. Afhankelijk van de vaardigheden van uw team en de voorkeursontwikkelingstechnologieën, gebruikt u een webhook of functie om complexere automatiseringsacties te bouwen. Zie de referentiearchitectuur voor cloudautomatisering op basis van gebeurtenissen voor een voorbeeld van het gebruik van een functie om te reageren op databasebeperking. Met behulp van geautomatiseerde acties kunt u snel herstellen en de noodzaak van menselijke tussenkomst minimaliseren.

Azure-facilitering

De meeste Azure-services en client-SDK's bevatten een mechanisme voor opnieuw proberen. Maar ze verschillen omdat elke service verschillende kenmerken en vereisten heeft, dus elk mechanisme voor opnieuw proberen is afgestemd op een specifieke service. Zie Aanbevelingen voor het afhandelen van tijdelijke fouten voor meer informatie.

Gebruik Azure Monitor-actiegroepen voor meldingen, zoals e-mail, spraak of sms, en om geautomatiseerde acties te activeren. Wanneer u op de hoogte wordt gesteld van een fout, activeert u een Azure Automation runbook, Azure Event Hubs, een Azure-functie, een logische app of een webhook om een geautomatiseerde herstelactie uit te voeren.

Overwegingen

Maak uzelf vertrouwd met de overwegingen voor elk patroon. Zorg ervoor dat het patroon geschikt is voor uw workload en bedrijfsvereisten vóór de implementatie.

Voorbeeld

Zie het betrouwbare web-app-patroon voor .NET voor voorbeelden van gebruiksvoorbeelden van bepaalde patronen. Volg deze stappen om een referentie-implementatie te implementeren.

Controlelijst voor betrouwbaarheid

Raadpleeg de volledige set aanbevelingen.

Controlelijst voor betrouwbaarheid