Betrouwbare Azure-toepassingen ontwerpen

  • Artikel
  • 4 minuten om te lezen

Een betrouwbare toepassing bouwen in de cloud is anders dan traditioneel toepassingen bouwen. Hoewel u in het verleden mogelijk niveaus van redundante hogere endhardware hebt aangeschaft om de kans te minimaliseren dat een volledig toepassingsplatform uitvallen, bevestigen we in de cloud van te voren dat er fouten zullen optreden. In plaats van fouten helemaal te proberen te voorkomen, is het doel de effecten van een onderdeel met een storing te beperken. Fouten die u hier kunt verwachten, zijn inherent aan zeer gedistribueerde systemen, geen functie van Azure.

Belangrijke punten

  • Gebruik Beschikbaarheidszones waar van toepassing om de betrouwbaarheid te verbeteren en de kosten te optimaliseren.
  • Ontwerp toepassingen die moeten worden gebruikt wanneer ze worden beïnvloed door fouten.
  • Gebruik de systeemeigen tolerantiemogelijkheden van PaaS om de algehele betrouwbaarheid van toepassingen te ondersteunen.
  • Ontwerp om uit te schalen.
  • Controleer of de vereiste capaciteit binnen de limieten en quota voor azure-serviceschaal valt.

Gebruik Beschikbaarheidszones binnen een regio

Als uw vereisten een nog grotere foutisolatie vragen dan Beschikbaarheidszones bieden, kunt u overwegen om in meerdere regio's te implementeren. Er moeten meerdere regio's worden gebruikt voor failover-doeleinden in een noodtoestand. Er moet rekening worden gehouden met extra kosten. Voorbeelden van kostenbehoeften zijn gegevens en netwerken, en services zoals Azure Site Recovery.

Ontwerp uw toepassingsarchitectuur voor het gebruik Beschikbaarheidszones binnen een regio. Beschikbaarheidszones kunnen worden gebruikt om de beschikbaarheid van toepassingen binnen een regio te optimaliseren door fouttolerantie op datacenterniveau te bieden. De toepassingsarchitectuur mag echter geen afhankelijkheden delen tussen zones om ze effectief te kunnen gebruiken.

Notitie

Beschikbaarheidszones kunnen prestatie- en kostenoverwegingen introduceren voor toepassingen die zeer 'gepraat' zijn tussen zones, gezien de impliciete fysieke scheiding tussen elke zone en bandbreedtekosten tussen zones. Dit betekent ook dat Beschikbaarheidszones kunnen worden beschouwd als een hogere SLA tegen lagere kosten.

Overweeg of componentbijheid vereist is om prestatieredenen van de toepassing. Als de hele of een deel van de toepassing zeer gevoelig is voor latentie, kan co-lokaliteit van onderdelen worden verplicht, waardoor de toepasbaarheid van strategieën voor meerdere regio's en meerdere zones kan worden beperkt.

Reageren op fouten

Het voorkomen van fouten is onmogelijk in de openbare cloud en als gevolg hiervan vereisen toepassingen tolerantie om te reageren op storingen en betrouwbaarheid te leveren. De toepassing moet daarom worden ontworpen om te worden gebruikt, zelfs wanneer deze wordt beïnvloed door regionale, zonale, service- of onderdeelfouten in kritieke toepassingsscenario's en functionaliteit. Toepassingsbewerkingen kunnen verminderde functionaliteit of verminderde prestaties ervaren tijdens een storing.

Definieer een beschikbaarheidsstrategie om vast te leggen hoe de toepassing beschikbaar blijft in een fouttoestand. Het moet van toepassing zijn op alle toepassingsonderdelen en het implementatiestempel van de toepassing als geheel, zoals via een implementatie met meerdere geografische schaaleenheden. Dit heeft ook gevolgen voor de kosten: Er moeten van tevoren meer resources worden ingericht om hoge beschikbaarheid te kunnen bieden. Actief-actief-installatie is duurder dan een enkele implementatie, maar kan de kosten in balans brengen door de belasting van één stempel te verlagen en de totale hoeveelheid benodigde resources te verminderen.

Definieer naast een beschikbaarheidsstrategie een BCDR-strategie (Business Continuity Disaster Recovery) voor de toepassing en/of de belangrijkste scenario's. Een strategie voor herstel na noodherstel moet vastleggen hoe de toepassing reageert op een noodsituatie, zoals een regionale storing of het verlies van een kritieke platformservice, met behulp van een re-implementatie, warm-spare actief-passief of hot-spare actief-actief-benadering.

Als u de kosten wilt omlaag, kunt u toepassingsonderdelen en -gegevens opsplitsen in groepen. Bijvoorbeeld:

  • Moet beveiligen
  • Goed om te beveiligen
  • Kortstondig/kan opnieuw worden opgebouwd/verloren gaan, in plaats van alle gegevens te beveiligen met hetzelfde beleid

Overwegingen voor het verbeteren van de betrouwbaarheid

Is de toepassing ontworpen voor het gebruik van beheerde services?

Door Azure beheerde services bieden native tolerantiemogelijkheden ter ondersteuning van de algehele betrouwbaarheid van toepassingen. PaaS-aanbiedingen (Platform as a Service) moeten worden gebruikt om deze mogelijkheden te benutten. PaaS-opties zijn eenvoudiger te configureren en te beheren. U hoeft geen virtuele machines in te inrichten, VNets in te stellen, patches en updates te beheren en u hebt geen last van alle andere overhead die komt kijken bij het uitvoeren van software op een virtuele machine. Zie Beheerde services gebruiken voor meer informatie.

Is de toepassing ontworpen om uit te schalen?

Azure biedt elastische schaalbaarheid en u moet ontwerpen om uit te schalen. Toepassingen moeten echter gebruikmaken van een schaaleenheidbenadering om te navigeren door service- en abonnementslimieten om ervoor te zorgen dat afzonderlijke onderdelen en de toepassing als geheel horizontaal kunnen worden geschaald. Vergeet niet in te schalen, wat belangrijk is om de kosten omlaag te houden. U kunt bijvoorbeeld in- en uitschalen voor App Service via regels. Klanten schrijven vaak regels voor uitschalen en schrijven nooit regels voor schalen. Hierdoor zijn App Service duurder.

Wordt de toepassing geïmplementeerd in meerdere Azure-abonnementen?

Het is belangrijk om inzicht te krijgen in het abonnementslandschap van de toepassing en hoe onderdelen binnen of tussen abonnementen zijn ingedeeld, wanneer u analyseert of er kan worden genavigeerd naar relevante abonnementslimieten of quota. Controleer de limieten van het Azure-abonnement en de Azure-service om te controleren of de vereiste capaciteit binnen de schaallimieten en quota van de Azure-service valt. Zie Azure-abonnement en servicelimieten voor meer informatie.

Volgende stap

Tolerantie en afhankelijkheden

Terug het hoofdartikel: Ontwerpen