Maak alles redundant

Zorg voor redundantie in uw toepassing om Single Points of Failure (afzonderlijke storingspunten) te voorkomen

Een flexibele toepassing creëert routes om fouten heen. Spoor kritieke paden in uw toepassing op. Is er redundantie op elk punt in het pad? Wanneer een subsysteem mislukt, voert de toepassing een failover uit naar iets anders?

Aanbevelingen

Bekijk uw zakelijke vereisten. De mate van redundantie die is ingebouwd in een systeem, kan van invloed zijn op zowel de kosten als de complexiteit. Uw architectuur moet worden geïnformeerd over uw bedrijfsvereisten, zoals RTO (Recovery Time Objective) en RPO (Recovery Point Objective). U moet ook rekening houden met uw prestatievereisten en de mogelijkheid van uw team om complexe sets resources te beheren.

Overweeg architecturen voor meerdere zones en meerdere regio's. Zorg ervoor dat u begrijpt hoe beschikbaarheidszones en regio's tolerantie en verschillende sets van architectonische afwegingen bieden.

Azure-beschikbaarheidszones zijn geïsoleerde sets datacenters binnen een regio. Door beschikbaarheidszones te gebruiken, kunt u bestand zijn tegen fouten in één datacenter of een volledige beschikbaarheidszone. U kunt beschikbaarheidszones gebruiken om compromissen te maken tussen kosten, risicobeperking, prestaties en herstelbaarheid. Wanneer u bijvoorbeeld zoneredundante services in uw architectuur gebruikt, biedt Azure automatische gegevensreplicatie en failover tussen geografisch gescheiden exemplaren, waardoor veel verschillende soorten risico's worden beperkt.

Als u een bedrijfskritieke workload hebt en het risico van een storing in de hele regio wilt beperken, kunt u een implementatie met meerdere regio's overwegen. Hoewel implementaties in meerdere regio's u isoleren tegen regionale rampen, komen ze ten koste van elkaar. Implementaties in meerdere regio's zijn duurder dan een implementatie met één regio en zijn ingewikkelder om te beheren. U hebt operationele procedures nodig om failover en failback af te handelen. Afhankelijk van uw RPO-vereisten moet u mogelijk iets lagere prestaties accepteren om replicatie van gegevens in meerdere regio's mogelijk te maken. De extra kosten en complexiteit kunnen worden gerechtvaardigd voor sommige bedrijfsscenario's.

Tip

Voor veel workloads biedt een zone-redundante architectuur de beste set compromissen. Overweeg een architectuur voor meerdere regio's als uw bedrijfsvereisten aangeven dat u het onwaarschijnlijke risico van een storing in de hele regio moet beperken en als u bereid bent de compromissen te accepteren die betrokken zijn bij een dergelijke benadering.

Zie Aanbevelingen voor het gebruik van beschikbaarheidszones en regio's voor meer informatie over het ontwerpen van uw oplossing voor het gebruik van beschikbaarheidszones en -regio's.

Plaats VM's achter een load balancer. Gebruik niet slechts één VM voor bedrijfskritieke werkbelastingen. Plaats in plaats daarvan meerdere VM's achter een load balancer. Als een VM niet beschikbaar is, verdeelt de load balancer het verkeer naar de resterende werkende VM's. Zie [Meerdere VM's voor schaalbaarheid en beschikbaarheid][multi-vm-blauwdruk] voor meer informatie over het implementeren van deze configuratie.

Repliceer databases. Azure SQL Database en Azure Cosmos DB repliceren automatisch de gegevens binnen een regio en kunnen worden geconfigureerd voor replicatie tussen beschikbaarheidszones voor een hogere tolerantie. U kunt er ook voor kiezen om geo-replicatie in te schakelen tussen regio's. Geo-replicatie voor Azure SQL Database en Azure Cosmos DB maakt secundaire leesbare replica's van uw gegevens in een of meer secundaire regio's. Als er een storing optreedt in de primaire regio, kan de database een failover uitvoeren naar de secundaire regio voor schrijfbewerkingen. Afhankelijk van de replicatieconfiguratie ondervindt u mogelijk gegevensverlies van niet-gerepliceerde transacties.

Als u een IaaS-databaseoplossing gebruikt, kiest u een oplossing die ondersteuning biedt voor replicatie en failover, zoals SQL Server AlwaysOn-beschikbaarheidsgroepen.

Partitioneer voor beschikbaarheid. Databasepartitionering wordt vaak gebruikt om de schaalbaarheid te verbeteren, maar kan ook de beschikbaarheid verbeteren. Als één shard niet beschikbaar is, kunnen de andere shards nog steeds worden bereikt. Een fout in één shard verstoort slechts een subset van de totale transacties.

Oplossingen voor meerdere regio's

Het volgende diagram toont een toepassing met meerdere regio's die gebruikmaakt van Azure Traffic Manager om failover af te handelen.

Als u Traffic Manager in een oplossing voor meerdere regio's gebruikt, kunt u de volgende aanbevelingen overwegen:

Synchroniseer front-end en back-end failover. Gebruik Traffic Manager om een failover van de front-end uit te voeren. Als de front-end in één regio niet meer bereikbaar is, leidt Traffic Manager nieuwe aanvragen om naar de secundaire regio. Afhankelijk van uw back-endonderdelen en databaseoplossing moet u mogelijk een failover van uw back-endservices en -databases coördineren.

Gebruik automatische failover, maar handmatige failback. Gebruik Traffic Manager voor automatische failover, maar niet voor automatische failback. Automatische failback brengt het risico met zich mee dat u overschakelt naar de primaire regio voordat de regio volledig in orde is. Controleer in plaats daarvan of alle subsystemen van de toepassing in orde zijn voordat u handmatig een failback uitvoert. Afhankelijk van de database moet u mogelijk ook de gegevensconsistentie controleren alvorens de failback uit te voeren.

Hiervoor schakelt u het primaire eindpunt van Traffic Manager uit na een failover. Houd er rekening mee dat als het bewakingsinterval van tests kort is en het getolereerde aantal fouten klein is, vindt failover en failback in korte tijd plaats. In sommige gevallen wordt het uitschakelen niet op tijd voltooid. Als u niet-bevestigd failback wilt voorkomen, kunt u ook een statuseindpunt implementeren dat kan controleren of alle subsystemen in orde zijn. Zie het patroon Statuseindpuntbewaking.

Voeg redundantie toe voor Traffic Manager. Traffic Manager is een mogelijk storingspunt. Controleer de SLA voor Traffic Manager en bepaal of het gebruik van alleen Traffic Manager voldoet aan uw zakelijke vereisten voor hoge beschikbaarheid. Als dat niet het geval is, overweeg dan een andere oplossing voor het beheer van verkeer toe te voegen als failback. Als de service Azure Traffic Manager uitvalt, wijzigt u de CNAME-records in DNS zodanig dat ze verwijzen naar de andere service voor verkeerbeheer.