Bedrijfsimplementatie met hoge beschikbaarheid met Behulp van App Service Environment

Beschikbaarheidszones zijn fysiek gescheiden verzamelingen datacenters in een bepaalde regio. Het implementeren van resources in meerdere zones zorgt ervoor dat storingen die beperkt zijn tot een zone, geen invloed hebben op de beschikbaarheid van uw toepassingen. Deze architectuur laat zien hoe u de tolerantie van een App Service Environment-implementatie kunt verbeteren door deze te implementeren in een zone-redudant-architectuur. Deze zones zijn niet gerelateerd aan nabijheid. Ze kunnen worden toegewezen aan verschillende fysieke locaties voor verschillende abonnementen. In de architectuur wordt ervan uitgegaan dat er één abonnement wordt geïmplementeerd.

Wanneer u App Service Environment configureert als zone-redundant, implementeert het platform automatisch exemplaren van het Azure-app Service-plan in drie zones in de geselecteerde regio. Daarom is het minimale aantal exemplaren van het App Service-plan altijd drie.

Azure-services die ondersteuning bieden voor beschikbaarheidszones kunnen zonegebonden, zone-redundant of beide zijn. Zonegebonden services kunnen worden geïmplementeerd in een specifieke zone. Zone-redundante services kunnen automatisch worden geïmplementeerd in meerdere zones. Zie ondersteuning voor beschikbaarheidszones voor gedetailleerde richtlijnen en aanbevelingen. De vorige versie van App Service Environment (v2) ondersteunde alleen zonegebonden implementaties, maar de huidige versie (v3) ondersteunt zone-redundante implementaties.

Een referentie-implementatie voor deze architectuur is beschikbaar op GitHub.

Architectuur

Een Visio-bestand van deze architectuur downloaden.

De resources in de Subnetten van de App Service Environment in deze referentie-implementatie zijn hetzelfde als de resources in de standaard-App Service Environment-implementatiearchitectuur. Deze referentie-implementatie maakt gebruik van de zone-redundante mogelijkheden van App Service Environment v3 en Azure Cache voor Redis om een hogere beschikbaarheid te bieden. Houd er rekening mee dat het bereik van deze referentiearchitectuur beperkt is tot één regio.

Workflow

In deze sectie wordt de aard beschreven van beschikbaarheid voor services die in deze architectuur worden gebruikt:

• App Service Environment v3 kan worden geconfigureerd voor zoneredundantie. U kunt zoneredundantie alleen configureren tijdens het maken van de App Service Environment en alleen in regio's die ondersteuning bieden voor alle App Service Environment v3-afhankelijkheden. Elk App Service-plan in een zoneredundante App Service Environment moet minimaal drie exemplaren hebben, zodat ze in drie zones kunnen worden geïmplementeerd. De minimale kosten zijn voor negen instanties. Zie deze prijsrichtlijnen voor meer informatie. Zie App Service Environment Support voor Beschikbaarheidszones voor gedetailleerde richtlijnen en aanbevelingen.

• Azure Virtual Network omvat alle beschikbaarheidszones die zich in één regio bevinden. De subnetten in het virtuele netwerk hebben ook meerdere beschikbaarheidszones. Zie de netwerkvereisten voor App Service Environment voor meer informatie.

• Application Gateway v2 is zone-redundant. Net als het virtuele netwerk omvat het meerdere beschikbaarheidszones per regio. Daarom is één toepassingsgateway voldoende voor een maximaal beschikbaar systeem, zoals wordt weergegeven in de referentiearchitectuur. De referentiearchitectuur maakt gebruik van de WAF-SKU van Application Gateway, die betere bescherming biedt tegen veelvoorkomende bedreigingen en beveiligingsproblemen, op basis van een implementatie van de Core Rule Set (CRS) van het Open Web Application Security Project (OWASP). Zie Application Gateway v2 en WAF v2 schalen voor meer informatie.

• Azure Firewall biedt ingebouwde ondersteuning voor hoge beschikbaarheid. Het kan meerdere zones kruisen zonder extra configuratie.

  Als dat nodig is, kunt u ook een specifieke beschikbaarheidszone configureren wanneer u de firewall implementeert. Zie Azure Firewall en Beschikbaarheidszones voor meer informatie. (Deze configuratie wordt niet gebruikt in de referentiearchitectuur.)

• Microsoft Entra ID is een maximaal beschikbare, zeer redundante wereldwijde service, die beschikbaarheidszones en regio's beslaat. Zie Geavanceerde beschikbaarheid van Microsoft Entra voor meer informatie.

• GitHub Actions biedt mogelijkheden voor continue integratie en continue implementatie (CI/CD) in deze architectuur. Omdat App Service Environment zich in het virtuele netwerk bevindt, wordt een virtuele machine gebruikt als een jumpbox in het virtuele netwerk om apps in de App Service-plannen te implementeren. Met de actie worden de apps buiten het virtuele netwerk gebouwd. Voor verbeterde beveiliging en naadloze RDP-/SSH-connectiviteit kunt u Azure Bastion gebruiken voor de jumpbox.

• Azure Cache voor Redis is een zone-redundante service. Een zone-redundante cache wordt uitgevoerd op VM's die zijn geïmplementeerd in meerdere beschikbaarheidszones. Deze service biedt een hogere tolerantie en beschikbaarheid.

Overwegingen

Met deze overwegingen worden de pijlers van het Azure Well-Architected Framework geïmplementeerd. Dit is een set richtlijnen die u kunt gebruiken om de kwaliteit van een workload te verbeteren. Zie Microsoft Azure Well-Architected Framework voor meer informatie.

Beschikbaarheid

App Service-omgeving

U kunt App Service Environment implementeren in beschikbaarheidszones om tolerantie en betrouwbaarheid te bieden voor uw bedrijfskritieke workloads. Deze configuratie wordt ook wel zoneredundantie genoemd.

Wanneer u zoneredundantie implementeert, implementeert het platform automatisch de exemplaren van het App Service-plan in drie zones in de geselecteerde regio. Daarom is het minimale aantal exemplaren van het App Service-plan altijd drie. Als u een capaciteit opgeeft die groter is dan drie en het aantal exemplaren deelbaar is door drie, worden de exemplaren gelijkmatig geïmplementeerd. Anders worden alle resterende exemplaren toegevoegd aan de resterende zone of geïmplementeerd in de resterende twee zones.

• U configureert beschikbaarheidszones wanneer u uw App Service Environment maakt.
• Voor alle App Service-plannen die zijn gemaakt in die App Service Environment, zijn minimaal drie exemplaren vereist. Ze worden automatisch zone-redundant.
• U kunt alleen beschikbaarheidszones opgeven wanneer u een nieuwe App Service-omgeving maakt. U kunt een bestaande App Service-omgeving niet converteren om beschikbaarheidszones te gebruiken.
• Beschikbaarheidszones worden alleen ondersteund in een subset van regio's.

Zie App Service Environment migreren naar ondersteuning voor beschikbaarheidszones voor meer informatie.

Tolerantie

De toepassingen die worden uitgevoerd in App Service Environment vormen de back-endpool voor Application Gateway. Wanneer een aanvraag voor de toepassing afkomstig is van het openbare internet, stuurt de gateway de aanvraag door naar de toepassing die wordt uitgevoerd in App Service Environment. Deze referentiearchitectuur implementeert statuscontroles binnen de hoofdwebfront-end, votingApp. Met deze statustest wordt gecontroleerd of de web-API en de Redis-cache in orde zijn. U kunt de code zien waarmee deze test wordt geïmplementeerd in Startup.cs:

            var uriBuilder = new UriBuilder(Configuration.GetValue<string>("ConnectionStrings:VotingDataAPIBaseUri"))
            {
                Path = "/health"
            };

            services.AddHealthChecks()
                .AddUrlGroup(uriBuilder.Uri, timeout: TimeSpan.FromSeconds(15))
                .AddRedis(Configuration.GetValue<string>("ConnectionStrings:RedisConnectionString"));

De volgende code laat zien hoe het commands_ha.azcli-script de back-endpools en de statustest voor de toepassingsgateway configureert:

# Generates parameters file for appgw script
cat <<EOF > appgwApps.parameters.json
[
{
    "name": "votapp",
    "routingPriority": 100,
    "hostName": "${APPGW_APP1_URL}",
    "backendAddresses": [
      {
        "fqdn": "${INTERNAL_APP1_URL}"
      }
    ],
    "certificate": {
      "data": "${CERT_DATA_1}",
      "password": "${PFX_PASSWORD}"
    },
    "probePath": "/health"
  }
]

Als een van de onderdelen (de webfront-end, de API of de cache) de statustest mislukt, stuurt Application Gateway de aanvraag naar de andere toepassing in de back-endpool. Deze configuratie zorgt ervoor dat de aanvraag altijd naar de toepassing wordt gerouteerd in een volledig beschikbaar Subnet van de App Service Environment.

De statustest wordt ook geïmplementeerd in de standaardreferentie-implementatie. Daar retourneert de gateway gewoon een fout als de statustest mislukt. De maximaal beschikbare implementatie verbetert echter de tolerantie van de toepassing en de kwaliteit van de gebruikerservaring.

Kostenoptimalisatie

Kostenoptimalisatie gaat over het verminderen van onnodige uitgaven en het verbeteren van operationele efficiëntie. Zie Overzicht van de pijler kostenoptimalisatie voor meer informatie.

De kostenoverwegingen voor de architectuur voor hoge beschikbaarheid zijn vergelijkbaar met die van de standaardimplementatie.

De volgende verschillen kunnen van invloed zijn op de kosten:

• Er worden ten minste negen App Service-planexemplaren in rekening gebracht in een zone-redundante App Service-omgeving. Zie prijzen voor App Service Environment voor meer informatie.
• Azure Cache voor Redis is ook een zone-redundante service. Een zone-redundante cache wordt uitgevoerd op VM's die zijn geïmplementeerd in meerdere beschikbaarheidszones om een hogere tolerantie en beschikbaarheid te bieden.

De compromissen voor een maximaal beschikbaar, tolerant en zeer veilig systeem zijn hogere kosten. Gebruik de prijscalculator om uw behoeften te evalueren met betrekking tot prijzen.

Implementatieoverwegingen

Deze referentie-implementatie maakt gebruik van dezelfde CI/CD-pijplijn op productieniveau als de standaardimplementatie, met slechts één jumpbox-VM. U kunt echter besluiten om één jumpbox te gebruiken voor elk van de drie zones. In deze architectuur wordt slechts één jumpbox gebruikt, omdat de jumpbox geen invloed heeft op de beschikbaarheid van de app. De jumpbox wordt alleen gebruikt voor implementatie en testen.

Dit scenario implementeren

Zie het Leesmij-leesmij-bestand voor GitHub voor informatie over het implementeren van de referentie-implementatie voor deze architectuur. Gebruik het script voor implementatie met hoge beschikbaarheid.

Inzenders

Dit artikel wordt onderhouden door Microsoft. De tekst is oorspronkelijk geschreven door de volgende Inzenders.

Belangrijkste auteurs:

• Deep Bhattacharya | Cloud Solution Architect
• Suhas Rao | Cloud Solution Architect

Als u niet-openbare LinkedIn-profielen wilt zien, meldt u zich aan bij LinkedIn.

Volgende stappen

U kunt deze architectuur wijzigen door uw toepassingen horizontaal te schalen, binnen dezelfde regio of in verschillende regio's, op basis van de verwachte piekbelastingscapaciteit. Het repliceren van uw toepassingen in meerdere regio's kan helpen bij het beperken van de risico's van bredere geografische datacenterfouten, zoals die worden veroorzaakt door aardbevingen of andere natuurrampen. Zie Geo Distributed Scale met App Service Environments voor meer informatie over horizontaal schalen. Voor een wereldwijde en maximaal beschikbare routeringsoplossing kunt u Overwegen Om Azure Front Door te gebruiken.