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? Als een subsysteem uitvalt, zal de toepassing dan een fail-over over naar iets anders gaan?
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 zijn gebaseerd op uw zakelijke vereisten, zoals de beoogde hersteltijd (RTO). Een implementatie met meerdere regio's is bijvoorbeeld duurder dan een implementatie met één regio en is gecompliceerder om te beheren. U hebt operationele procedures nodig om failover en failback af te handelen. De extra kosten en complexiteit zijn mogelijk gerechtvaardigd voor bepaalde zakelijke scenario's, maar niet voor andere.
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 voor meer informatie over het implementeren van deze configuratie.
Repliceer databases. Azure SQL Database en Cosmos DB repliceren de gegevens automatisch binnen een regio en u kunt geo-replicatie tussen regio's inschakelen. Als u een IaaS-databaseoplossing gebruikt, kiest u een oplossing die replicatie en failover ondersteunt, zoals SQL Server Always On-beschikbaarheidsgroepen.
Actieve geo-replicatie. Geo-replicatie voor Azure SQL Database en Cosmos DB creëert secundaire leesbare replica's van uw gegevens in een of meer secundaire regio's. In het geval van een storing kan de database via failover voor schrijfbewerkingen overschakelen naar de secundaire regio.
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.
Implementeer in meer dan één regio. Voor de hoogste beschikbaarheid implementeert u de toepassing in meer dan één regio. In het zeldzame geval dat een probleem een hele regio treft, kan de toepassing via failover overschakelen naar een andere regio. Het volgende diagram toont een toepassing met meerdere regio's die gebruikmaakt van Azure Traffic Manager om failover af te handelen.
Synchroniseer front-end en back-end failover. Gebruik Azure Traffic Manager voor failover van de front-end. Als de front-end in één regio niet meer bereikbaar is, leidt Traffic Manager nieuwe aanvragen om naar de secundaire regio. Afhankelijk van uw databaseoplossing moet u mogelijk failover van de database 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.
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.