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?

In een perfecte implementatie kan het toevoegen van uniforme redundantie exponentieel de beschikbaarheid van uw systeem verhogen. Stel dat u gelijkwaardige, even evenwichtige onderdelen hebt N die:

• kan onafhankelijk en tegelijkertijd uit het zwembad worden verwijderd
• identieke status of geen status hebben
• geen werk in uitvoering hebben dat permanent verloren gaat tijdens de storing
• identiek zijn in mogelijkheden
• geen afhankelijkheden voor elkaar hebben
• zorgt voor het verminderen van de capaciteit zonder extra storing

Als elk afzonderlijk onderdeel een beschikbaarheid heeft, Akan de algehele systeembeschikbaarheid worden berekend met behulp van de formule 1 - (1 - A)^N.

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.

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.

Test en valideer uw redundante onderdelen. Betrouwbaarheidsvoordelen op veel manieren van eenvoud en redundantie kunnen de complexiteit verhogen. Om ervoor te zorgen dat het toevoegen van redundantie daadwerkelijk leidt tot hogere beschikbaarheid, moet u het volgende valideren:

• Kan uw systeem op betrouwbare en betrouwbare wijze redundante en beschadigde onderdelen detecteren en ze veilig en snel verwijderen uit de onderdelengroep?
• Kan uw systeem betrouwbaar uitschalen en in de redundante onderdelen?
• Kunnen uw routine-, ad-hoc- en noodworkloadbewerkingen de redundantie verwerken?

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 of Azure Front Door in een oplossing voor meerdere regio's gebruikt als uw failoverrouteringsmechanisme, kunt u de volgende aanbevelingen overwegen:

Synchroniseer front-end en back-end failover. Gebruik uw routeringsmechanisme om een failover van de front-end uit te voeren. Als de front-end onbereikbaar wordt in één regio, routeer dan nieuwe aanvragen 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 automatisering voor failover, maar niet voor 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. U moet ook de consistentie van gegevens controleren voordat u een failback uitvoert.

Als u dit wilt bereiken, schakelt u het primaire eindpunt 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.

Neem redundantie op voor uw routeringsoplossing. Overweeg om een globale oplossing voor routeringredundantie te ontwerpen voor bedrijfskritieke webtoepassingen.