Betrouwbaarheid in Azure Spring Apps
Dit artikel bevat gedetailleerde informatie over regionale tolerantie met beschikbaarheidszones en herstel na noodgevallen in meerdere regio's en ondersteuning voor bedrijfscontinuïteit voor Azure Spring Apps.
Ondersteuning voor beschikbaarheidszone
Azure-beschikbaarheidszones zijn ten minste drie fysiek afzonderlijke groepen datacenters binnen elke Azure-regio. Datacenters binnen elke zone zijn uitgerust met onafhankelijke energie-, koelings- en netwerkinfrastructuur. In het geval van een storing in een lokale zone worden beschikbaarheidszones zodanig ontworpen dat als de ene zone wordt beïnvloed, regionale services, capaciteit en hoge beschikbaarheid worden ondersteund door de resterende twee zones.
Fouten kunnen variëren van software- en hardwarefouten tot gebeurtenissen zoals aardbevingen, overstromingen en brand. Tolerantie voor fouten wordt bereikt met redundantie en logische isolatie van Azure-services. Zie Regio's en beschikbaarheidszones voor meer informatie over beschikbaarheidszones in Azure.
Services met azure-beschikbaarheidszones zijn ontworpen om het juiste niveau van betrouwbaarheid en flexibiliteit te bieden. Ze kunnen op twee manieren worden geconfigureerd. Ze kunnen zone-redundant zijn, met automatische replicatie tussen zones of zonegebonden, waarbij exemplaren zijn vastgemaakt aan een specifieke zone. U kunt deze benaderingen ook combineren. Zie Aanbevelingen voor meer informatie over zone-redundante versus zone-redundante architectuur voor het gebruik van beschikbaarheidszones en regio's.
Azure Spring Apps biedt ondersteuning voor zoneredundantie. Wanneer u een Azure Spring Apps-service-exemplaar maakt waarvoor zoneredundantie is ingeschakeld, distribueert Azure Spring Apps automatisch fundamentele resources over logische secties van de onderliggende Azure-infrastructuur. De onderliggende rekenresource distribueert VM's over alle beschikbaarheidszones om ervoor te zorgen dat u kunt berekenen. De onderliggende opslagresource repliceert gegevens over beschikbaarheidszones om deze beschikbaar te houden, zelfs als er datacenterfouten zijn. Deze distributie biedt een hoger beschikbaarheidsniveau en beschermt tegen hardwarefouten of geplande onderhoudsgebeurtenissen.
Vereisten
Zoneredundantie is niet beschikbaar in het Basic-abonnement.
Azure Spring Apps ondersteunt beschikbaarheidszones in de volgende regio's:
- Australië - oost
- Brazilië - zuid
- Canada - midden
- Central US
- Azië - oost
- VS - oost
- VS - oost 2
- Frankrijk - centraal
- Duitsland - west-centraal
- Europa - noord
- Japan - oost
- Korea - centraal
- Zuid-Afrika - noord
- VS - zuid-centraal
- Azië - zuidoost
- Verenigd Koninkrijk Zuid
- Europa -west
- VS - west 2
- US - west 3
Een Azure Spring Apps-exemplaar maken waarvoor beschikbaarheidszones zijn ingeschakeld
Notitie
U kunt zoneredundantie alleen inschakelen wanneer u uw Azure Spring Apps-service-exemplaar maakt. U kunt de eigenschap zoneredundantie niet wijzigen nadat deze is gemaakt.
U kunt zoneredundantie inSchakelen in Azure Spring Apps met behulp van de Azure CLI of Azure Portal.
Als u een service wilt maken in Azure Spring Apps waarvoor zoneredundantie is ingeschakeld met behulp van de Azure CLI, neemt u de --zone-redundant parameter op wanneer u uw service maakt, zoals wordt weergegeven in het volgende voorbeeld:
az spring create \
--resource-group <your-resource-group-name> \
--name <your-Azure-Spring-Apps-instance-name> \
--location <location> \
--zone-redundant true
Uw eigen resource inschakelen met beschikbaarheidszones ingeschakeld
U kunt uw eigen resource inschakelen in Azure Spring Apps, zoals uw eigen permanente opslag. U moet er echter voor zorgen dat zoneredundantie voor uw resource is ingeschakeld. Zie Uw eigen permanente opslag inschakelen in Azure Spring Apps voor meer informatie.
Zone-down-ervaring
Wanneer een app-exemplaar mislukt omdat het zich op een VM-knooppunt in een mislukte zone bevindt, maakt Azure Spring Apps een nieuw app-exemplaar voor de mislukte app op een ander VM-knooppunt in een andere beschikbaarheidszone. Gebruikers kunnen gedurende deze tijd een korte onderbreking ervaren. Er is geen gebruikersactie vereist en het betrokken Azure Spring Apps-exemplaar wordt hersteld door de service.
Prijzen
Er zijn geen extra kosten verbonden aan het inschakelen van zoneredundantie. U hoeft alleen te betalen voor het Standard- of Enterprise-abonnement. Dit is vereist om zoneredundantie in te schakelen.
Herstel na noodgevallen en bedrijfscontinuïteit tussen regio's
Herstel na noodgevallen (DR) gaat over het herstellen van gebeurtenissen met een hoge impact, zoals natuurrampen of mislukte implementaties die downtime en gegevensverlies tot gevolg hebben. Ongeacht de oorzaak is de beste oplossing voor een noodgeval een goed gedefinieerd en getest DR-plan en een toepassingsontwerp dat actief dr ondersteunt. Zie Aanbevelingen voordat u nadenkt over het maken van uw plan voor herstel na noodgevallen.
Als het gaat om herstel na noodgevallen, gebruikt Microsoft het model voor gedeelde verantwoordelijkheid. In een model voor gedeelde verantwoordelijkheid zorgt Microsoft ervoor dat de basisinfrastructuur en platformservices beschikbaar zijn. Tegelijkertijd repliceren veel Azure-services niet automatisch gegevens of vallen ze terug van een mislukte regio om kruislings te repliceren naar een andere ingeschakelde regio. Voor deze services bent u verantwoordelijk voor het instellen van een plan voor herstel na noodgevallen dat geschikt is voor uw workload. De meeste services die worden uitgevoerd op PaaS-aanbiedingen (Platform as a Service) van Azure bieden functies en richtlijnen ter ondersteuning van herstel na noodgeval en u kunt servicespecifieke functies gebruiken om snel herstel te ondersteunen om uw DR-plan te ontwikkelen.
De Azure Spring Apps-service biedt geen geo-noodherstel, maar een zorgvuldige planning kan u beschermen tegen downtime.
Implementeer uw toepassingen die worden gehost in Azure Spring Apps in meerdere regio's om hoge beschikbaarheid en bescherming tegen rampen te garanderen. Azure biedt een lijst met gekoppelde regio's , zodat u uw app-implementaties dienovereenkomstig kunt plannen.
Houd rekening met de volgende belangrijke factoren bij het ontwerpen van uw architectuur:
- Beschikbaarheid in regio’s. Als u de netwerkvertraging en overdrachtstijd wilt minimaliseren, kiest u een regio die zoneredundantie van Azure Spring Apps ondersteunt of een geografisch gebied dicht bij uw gebruikers.
- Gekoppelde Azure-regio's. Om ervoor te zorgen dat gecoördineerde platformupdates en herstelinspanningen met prioriteit, indien nodig, gekoppelde regio's in uw gekozen geografische gebied kiezen.
- Beschikbaarheid van de service. Bepaal of uw gekoppelde regio's dynamisch/dynamisch, warm/warm of warm/koud moeten worden uitgevoerd.
Azure Traffic Manager gebruiken om verkeer te routeren
Azure Traffic Manager biedt op DNS gebaseerde verkeerstaakverdeling en kan netwerkverkeer verdelen over meerdere regio's. Gebruik Azure Traffic Manager om klanten naar het dichtstbijzijnde Azure Spring Apps-service-exemplaar te leiden. Voor de beste prestaties en redundantie stuurt u al het toepassingsverkeer via Azure Traffic Manager voordat u het verzendt naar uw Azure Spring Apps-service-exemplaar. Zie Wat is Traffic Manager?
Als u toepassingen in Azure Spring Apps in meerdere regio's hebt, kan Azure Traffic Manager de verkeersstroom naar uw toepassingen in elke regio beheren. Definieer een Azure Traffic Manager-eindpunt voor elk service-exemplaar met behulp van het IP-adres van het exemplaar. U moet verbinding maken met een DNS-naam van Azure Traffic Manager die verwijst naar het Azure Spring Apps-service-exemplaar. Azure Traffic Manager verdeelt het verkeer over de gedefinieerde eindpunten. Als een noodgeval een datacenter aantreft, stuurt Azure Traffic Manager verkeer van die regio naar het paar, waardoor de servicecontinuïteit wordt gewaarborgd.
Gebruik de volgende stappen om een Azure Traffic Manager-exemplaar te maken voor Azure Spring Apps-exemplaren:
Azure Spring Apps-exemplaren maken in twee verschillende regio's. Maak bijvoorbeeld service-exemplaren in VS - oost en Europa - west, zoals wordt weergegeven in de volgende tabel. Elk exemplaar fungeert als een primair eindpunt en een failover-eindpunt voor verkeer.
Servicenaam Locatie Toepassing service-sample-a VS - oost gateway/auth-service/account-service service-sample-b Europa -west gateway/auth-service/account-service Stel een aangepast domein in voor de service-exemplaren. Zie Zelfstudie: Een bestaand aangepast domein toewijzen aan Azure Spring Apps voor meer informatie. Na een geslaagde installatie binden beide service-exemplaren zich aan hetzelfde aangepaste domein, zoals
bcdr-test.contoso.com.Maak een Traffic Manager en twee eindpunten. Zie Quickstart: Een Traffic Manager-profiel maken met behulp van Azure Portal, dat het volgende Traffic Manager-profiel produceert voor instructies:
- DNS-naam van Traffic Manager:
http://asa-bcdr.trafficmanager.net - Eindpuntprofielen:
Profile Type Doel Prioriteit Aangepaste headerinstellingen Eindpunt A-profiel Extern eindpunt service-sample-a.azuremicroservices.io1 host: bcdr-test.contoso.comEindpunt B-profiel Extern eindpunt service-sample-b.azuremicroservices.io2 host: bcdr-test.contoso.com- DNS-naam van Traffic Manager:
Maak een CNAME-record in een DNS-zone die vergelijkbaar is met het volgende voorbeeld:
bcdr-test.contoso.com CNAME asa-bcdr.trafficmanager.net.
De omgeving is nu ingesteld. Als u de voorbeeldwaarden in de gekoppelde artikelen hebt gebruikt, moet u toegang hebben tot de app met behulp van https://bcdr-test.contoso.com.
Azure Front Door en Azure-toepassing Gateway gebruiken om verkeer te routeren
Azure Front Door is een wereldwijd, schaalbaar toegangspunt dat gebruikmaakt van het wereldwijde edge-netwerk van Microsoft om snelle, veilige en breed schaalbare webtoepassingen te maken. Azure Front Door biedt dezelfde multi-geo-redundantie en routering naar de dichtstbijzijnde regio als Azure Traffic Manager. Azure Front Door biedt ook geavanceerde functies, zoals beëindiging van TLS-protocol, verwerking van toepassingslagen en WaF (Web Application Firewall). Zie Wat is Azure Front Door voor meer informatie ?
In het volgende diagram ziet u de architectuur van een redundantie in meerdere regio's, een geïntegreerd Azure Spring Apps-service-exemplaar met een virtueel netwerk. In het diagram ziet u de juiste reverse proxy-configuratie voor Application Gateway en Front Door met een aangepast domein. Deze architectuur is gebaseerd op het scenario dat wordt beschreven in Toepassingen beschikbaar maken met end-to-end TLS in een virtueel netwerk. Deze benadering combineert twee met Application Gateway geïntegreerde azure Spring Apps virtual-network-injection-exemplaren in een geografisch redundant exemplaar.
