Delen via

Aanbevelingen voor zelfherstel en zelfbehoud

  • Artikel

Is van toepassing op deze aanbeveling voor de controlelijst voor betrouwbaarheid 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 met behulp van op infrastructuur gebaseerde betrouwbaarheidspatronen en op software gebaseerde ontwerppatronen voor het afhandelen van onderdeelfouten en tijdelijke fouten. Bouw mogelijkheden in het systeem in om fouten in het oplossingsonderdeel te detecteren en automatisch corrigerende actie te starten terwijl de workload volledig of beperkt blijft werken.

Verwante handleidingen: Tijdelijke fouten bij achtergrondtaken |

In deze handleiding worden de aanbevelingen beschreven voor het bouwen 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 foutendetectie en automatische corrigerende acties te bouwen om te reageren op verschillende fouttypen.

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

Definities

Termijn Definitie
Zelfherstellend De mogelijkheid van uw workload om problemen automatisch op te lossen door 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 ontwerppatronen voor infrastructuur- en toepassingsarchitectuur om de tolerantie van uw workload te optimaliseren. Om de kans op een volledige storing in de toepassing te minimaliseren, verhoogt u de tolerantie van uw oplossing door single points of failure te elimineren en de straal van storingen te minimaliseren. De ontwerpmethoden 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 indien mogelijk automatische schaalaanpassing . Met automatisch schalen kunt u uw workload beschermen tegen onverwachte bursts in activiteiten, waardoor uw infrastructuur verder wordt versterkt.

Gebruik het patroon Implementatiestempels of het schotpatroon om de straalstraal te minimaliseren wanneer er problemen optreden. Deze patronen helpen uw workload beschikbaar te houden als een afzonderlijk onderdeel niet beschikbaar is. Gebruik de volgende ontwerppatronen voor toepassingen in combinatie met uw strategie voor automatisch schalen.

  • Patroon implementatiestempels: Een gevarieerde groep resources inrichten, beheren en bewaken om meerdere workloads of tenants te hosten en te gebruiken. Elke afzonderlijke kopie wordt een stempel genoemd, of soms een service-eenheid, schaaleenheid of cel.

  • Schotpatroon: Partitieservice-exemplaren in verschillende groepen, ook wel pools genoemd, op basis van de vereisten voor de belasting en beschikbaarheid van de consument. Dit ontwerp helpt fouten te isoleren en stelt u in staat om servicefunctionaliteit voor sommige consumenten 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 met één onderdeel te verminderen. U kunt bijvoorbeeld het gebruik van een servicebus standaardiseren om alle asynchrone communicatie te verwerken. Het standaardiseren van communicatieprotocollen zorgt ervoor dat het ontwerp van toepassingen consistent en vereenvoudigd is, waardoor de workload betrouwbaarder en gemakkelijker te verhelpen is wanneer er storingen optreden. Wanneer dit praktisch is, geeft u de voorkeur aan asynchrone communicatie tussen onderdelen via synchrone communicatie om time-outproblemen te minimaliseren, zoals dead-lettering. Met de volgende ontwerppatronen kunt u uw workload ordenen en de communicatie tussen onderdelen definiëren 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 heeft een duidelijk antwoord nodig.

  • Cache-Aside-patroon: Laad gegevens op aanvraag uit een gegevensarchief in een cache. Dit patroon kan de prestaties verbeteren en helpen consistentie te behouden tussen gegevens die zijn opgeslagen in de cache en gegevens die zich in het onderliggende gegevensarchief bevinden.

  • Circuitonderbrekerpatroon: gebruik circuitonderbrekers om proactief te bepalen of een bewerking moet worden voortgezet of om een uitzondering te retourneren 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 de client wordt overweldigd of vertraagd.

  • Patroon concurrerende consumenten: schakel meerdere gelijktijdige consumenten in om 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 wordt verbeterd en de werkbelasting wordt afgestemd.

  • Time-outs voor aanvragen configureren: time-outs voor 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 hostexemplaren 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 load leveling op basis van wachtrij: koppel de taken los van de service in uw oplossing met behulp van een wachtrij ertussen, zodat ze elk asynchroon kunnen worden uitgevoerd. Gebruik een wachtrij als buffer tussen een taak en een service die wordt aangeroepen, om onregelmatige zware belasting te verhelpen die ertoe kan leiden dat de service mislukt of dat er een time-out optreedt voor de taak. Dit patroon kan helpen bij het minimaliseren van het effect van pieken in de vraag op beschikbaarheid en reactiesnelheid voor de taak en de service.

  • 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 serviceovereenkomsten (SLA's), zelfs wanneer een toename van de vraag een extreme belasting op resources plaatst.

  • Patroon tijdelijke foutafhandeling en patroon voor opnieuw proberen: implementeer een strategie voor het afhandelen van tijdelijke fouten om tolerantie in uw workload te bieden. Tijdelijke fouten zijn normaal en verwacht in cloudomgevingen. Veelvoorkomende oorzaken van tijdelijke fouten zijn momentgebonden verlies van netwerkconnectiviteit, een verbroken databaseverbinding of een time-out wanneer een service bezet is. Zie de handleiding voor het afhandelen 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 er geen gebruikersinvoer of feedback nodig is en of deze 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 bepaald tijdstip.
  • Langlopende werkstromen, zoals het voltooien van een order of het inrichten van services en systemen.

Zie Aanbevelingen voor achtergrondtaken voor meer informatie.

Zelfherstelrichtlijnen

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 neemt 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 infrastructuurontwerp

Op infrastructuurniveau moeten uw kritieke stromen worden ondersteund door een redundant architectuurontwerp met geautomatiseerde failover ingeschakeld voor onderdelen die deze 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 clustermogelijkheden 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 werkt. Dit kan betekenen dat de client het servicequotum heeft overschreden. Maar als een client het quotum consistent overschrijdt of 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 op trapsgewijze fouten 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.

  • Compensating Transaction pattern: 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 werk ongedaan te maken dat door de stappen is uitgevoerd.

  • Probleemloos verslechteren: 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 bijvoorbeeld het weergeven van productaanbeveling waarschijnlijk minder kritiek dan het verwerken van orders. Graceful 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 verminderd.

  • Patroon leiderverkiezing: Wanneer u een taak moet 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 off-the-shelf oplossing, zoals ZooKeeper, overwegen.

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

  • Gebruik controlepunten voor langlopende transacties: Controlepunten kunnen tolerantie bieden als een langlopende bewerking mislukt. Wanneer de bewerking opnieuw wordt opgestart, 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 de status transparant, 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 vaardighedenset en voorkeursontwikkelingstechnologieën van uw team, 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. Door geautomatiseerde acties te gebruiken, kunt u snel herstellen en de noodzaak van menselijke interventie 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 tijdelijke foutafhandeling 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 bent 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.

Opmerking

Zie bijvoorbeeld het betrouwbare web-app-patroon voor .NET. Volg deze stappen om een referentie-implementatie te implementeren.

Controlelijst voor betrouwbaarheid

Raadpleeg de volledige set aanbevelingen.

Controlelijst voor betrouwbaarheid