Hoge beschikbaarheid in openbare Azure MEC

Azure Traffic Manager
Azure Load Balancer
Azure Virtual Machine Scale Sets

Azure Public Multi-Access Edge Compute (MEC) is een geweldig platform voor het hosten van toepassingen aan de rand en kan ze responsiefer maken, maar momenteel biedt het geen ondersteuning voor functies voor hoge beschikbaarheid. In dit artikel wordt beschreven hoe u workloads implementeert in de actieve/stand-bymodus om hoge beschikbaarheid en herstel na noodgevallen te bereiken.

Apache, Apache® Ignite, Ignite en het vlamlogo zijn gedeponeerde handelsmerken of handelsmerken van de Apache Software Foundation in de Verenigde Staten en/of andere landen. Er wordt geen goedkeuring door De Apache Software Foundation geïmpliceerd door het gebruik van deze markeringen.

Architectuur

Diagram met een architectuur voor het implementeren van workloads in de actieve/stand-bymodus voor hoge beschikbaarheid en herstel na noodgevallen.

Een Visio-bestand van deze architectuur downloaden.

Workflow

  • Azure Traffic Manager. Configureer Traffic Manager voor het gebruik van prioriteitsroutering. Stel het IP-adres van de load balancer in openbare Azure MEC (primair)in op Prioriteit 1. Stel deze in de secundaire regio in op Prioriteit 2. Met deze configuratie wordt al het verkeer in de niet-failovercase naar het openbare Azure MEC verzonden.

    Notitie

    Traffic Manager voor openbare Azure MEC biedt momenteel geen ondersteuning voor prestatieroutering, waardoor de eerder beschreven routering dynamisch kan worden bepaald op basis van de laagste latentie naar het eindpunt.

    In deze architectuur wordt failback automatisch bereikt nadat de virtuele machines (VM's) en/of standard load balancer weer online zijn. Traffic Manager bepaalt dat de workloads up zijn en het verkeer terugsturen naar de primaire openbare Azure MEC-regio.

  • Openbare load balancer. Deze load balancer fronteert de toepassingslaag en verdeelt verkeer naar de groep virtuele machines in de virtuele-machineschaalset.

  • Interne load balancer. Deze load balancer wordt gebruikt voor toegang tot de databaselaag. Afhankelijk van het type database dat u voor uw toepassing gebruikt, hebt u hier mogelijk geen load balancer nodig, ervan uitgaande dat andere PaaS-services (Platform as a Service) hun eigen load balancer hebben.

  • Azure-virtuele-machineschaalset. De meeste productie-implementaties maken gebruik van Virtuele-machineschaalsets om hun workloads dynamisch te schalen op basis van de belasting van het verkeer. Openbare Azure MEC biedt ook ondersteuning voor Azure Kubernetes Service voor cloudtoepassingen en op containers gebaseerde toepassingen.

  • Databaselaag. Openbare Azure MEC biedt momenteel geen ondersteuning voor PAaS-services voor SQL-databases, zoals SQL Server op Azure Virtual Machines en Azure SQL Managed Instance. Het biedt momenteel ook geen ondersteuning voor NoSQL PaaS-services, zoals Azure Cosmos DB en Azure Managed Instance voor Apache Cassandra. U kunt oplossingen van derden implementeren die ondersteuning bieden voor SQL- of NoSQL-services en replicatie van gegevens in hun geografisch gedistribueerde clusters.

Onderdelen

  • Openbare Azure MEC is een edge-computingoplossing die een portfolio van Microsoft-compute-, netwerk- en toepassingsservices combineert die worden beheerd vanuit de cloud.
  • Azure Traffic Manager is een op DNS gebaseerde load balancer voor verkeer. U kunt deze gebruiken om binnenkomende DNS-aanvragen te leiden op basis van een routeringsmethode die u kiest.
  • Azure Load Balancer biedt hoge beschikbaarheid en hoge prestaties voor uw apps.
  • Met Azure Virtual Machine Scale Sets kunt u duizenden VM's beheren en schalen.

Alternatieven

Azure Backup en herstel na noodgevallen, die Azure Site Recovery- en back-upfuncties biedt:

  • Repliceert actief VM's van de openbare Azure MEC naar de bovenliggende regio en maakt ze beschikbaar voor failover en failback in geval van storing.
  • Back-ups maken van VM's om beschadiging of verlies van gegevens te voorkomen.

Deze benadering kost minder dan de methode die eerder is beschreven, omdat er geen niet-actieve resources zijn. Dit alternatief is alleen geschikt voor toepassingen die hogere RTO's toestaan.

Notitie

Azure Backup en herstel na noodgevallen voor openbare Azure MEC ondersteunt momenteel alleen virtuele machines.

Scenariodetails

Potentiële gebruikscases

Gebruik deze architectuur als u workloads in de actieve/stand-bymodus wilt implementeren om hoge beschikbaarheid en herstel na noodgevallen te bereiken. Dit scenario is ideaal voor de telecommunicatie-industrie.

Overwegingen

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

SLA

Microsoft ondersteunt serviceovereenkomsten (SLA's) voor grotere infrastructuur zoals Azure en Azure-regio's. Openbare Azure MEC is een kleinere footprintuitbreiding van Azure en heeft dus geen SLA-ondersteuning.

Prestaties

Openbare Azure MEC is ontworpen om latentiekritische toepassingen te hosten. Omdat failover naar een secundaire regio de latentie van de workloads verhoogt, biedt deze mogelijk niet hetzelfde prestatieniveau. Afhankelijk van de toepassing en de gevoeligheid voor deze verhoogde latentie, moet u beslissen welke van de services, indien aanwezig, een failover naar de regio moet uitvoeren.

Databases

Gegevensreplicatie en back-up zijn belangrijk wanneer u afhankelijk bent van databasefailovers. De meeste Azure PaaS-services bieden ingebouwde ondersteuning voor geo-replicatie en het maken van leesreplica's tussen regio's en geografische gebieden.

Notitie

Openbare Azure MEC biedt momenteel geen ondersteuning voor PaaS-services, zoals SQL Managed Instance, SQL Server op Azure Virtual Machines, Azure Database for MySQL of Azure Database for PostgreSQL. Aanbiedingen van derden, zoals Couchbase, MongoDB en Apache Cassandra, kunnen IaaS-services (Infrastructure as a Service) bieden die ondersteuning bieden voor geo-replicatie.

Traffic Manager

Failoveropties

Traffic Manager ondersteunt meerdere routeringsmethoden: prestaties, geografische, prioriteit en meer. Om toepassingen met lage latentie het beste te ondersteunen, verzendt u dynamisch gegevens naar de regio/openbare Azure MEC die zich het dichtst bij de gebruiker bevindt. Prestatieroutering wordt momenteel niet ondersteund op openbare Azure MEC. De volgende beste optie is om statisch prioriteit te geven aan de beste locatie voor een toepassing.

Gebruik een geneste routeringsmethode voor een wereldwijd gedistribueerde toepassing met workloads die zijn verdeeld over meerdere openbare Azure-pc's en -regio's. Gebruik geografische routering om verkeer te splitsen naar de juiste regio en gebruik vervolgens prioriteitsroutering om het verkeer verder te splitsen.

Failback

Nadat er een back-up van de workloads in openbare Azure MEC is gemaakt, detecteren Traffic Manager-tests dat het aanvragen kan aannemen en automatisch verkeer kan omleiden naar openbare Azure MEC.

Kostenoptimalisatie

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

Openbare Azure MEC wordt voornamelijk gebruikt voor scenario's met lage latentie en realtime berekeningen. Gegevens worden verwerkt door de rekeninstanties die worden uitgevoerd in openbare Azure MEC. Deze architectuur maakt gebruik van actief/stand-by met een hot stand-by. Werkbelastingen in de secundaire regio worden dus niet gebruikt, tenzij er een failover is.

Deze benadering voor het implementeren van workloads als stand-by kost Azure-implementatie, ook al worden de workloads niet gebruikt.

Voor meer informatie over prijzen:

Zie Overzicht van de pijler kostenoptimalisatie in de documentatie van Azure Well-Architected Framework voor meer informatie over het maken van een rendabele workload.

Medewerkers

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

Hoofdauteur:

Volgende stappen