Een geografisch gedistribueerde gegevensarchitectuur ontwerpen
- 6 minuten
Het laatste deel van het ontwerp van de architectuur van onze toepassing om rekening mee te houden, is de gegevensopslaglaag. We willen er zeker van zijn dat gegevens zowel leesbaar als beschrijfbaar zijn met volledige functionaliteit na een storing in de hele regio.
In de portal voor het bijhouden van verzendingen hebben we ervoor gekozen om Azure Front Door te gebruiken om alle aanvragen naar App Services in de regio VS - oost te verzenden. Als de regio VS - oost mislukt, detecteert Front Door de fout en verzendt aanvragen naar dubbele App Services-onderdelen in de regio VS - west. In onze oorspronkelijke architectuur met één regio hebben we relationele gegevens opgeslagen in Azure SQL Database en semi-gestructureerde gegevens in Cosmos DB. Nu willen we weten hoe we ervoor kunnen zorgen dat beide databases beschikbaar blijven als de regio VS - oost mislukt.
Hier leert u hoe u gegevens tussen regio's repliceert en hoe u ervoor kunt zorgen dat failover snel kan plaatsvinden, indien nodig.
Azure SQL-database
Als u een implementatie met meerdere regio's wilt maken van Azure SQL Database voor het opslaan van relationele gegevens, kunt u gebruikmaken van:
- Actieve geo-replicatie
- Automatische failover-groepen
Actieve geo-replicatie
Met de functie voor actieve geo-replicatie kan Azure SQL Database een database en alle wijzigingen ervan automatisch van de ene database naar een andere repliceren. Alleen de primaire logische server fungeert als host voor een beschrijfbare kopie van de database. We kunnen maximaal vier andere logische servers maken die alleen-lezen kopieën van de database hosten.
Maak voor de portal voor het bijhouden van verzendingen een secundaire database in de regio VS - west en configureer geo-replicatie vanuit de regio VS - oost. Wanneer er een regionale fout optreedt, stuurt Front Door gebruikersaanvragen om naar App Services in de regio VS - west. App Services en Azure Functions kunnen toegang krijgen tot de relationele gegevens omdat er al een kopie is gerepliceerd naar de regio VS - west.
Deze wijziging is automatisch, maar onthoud dat de secundaire database in VS - west alleen-lezen is. Als een gebruiker gegevens probeert te wijzigen, bijvoorbeeld door een nieuwe verzending te maken, kunnen er fouten optreden. We kunnen handmatig een failover naar VS - west initiëren zodra het probleem in Azure Portal is opgetreden. Als we dit proces willen automatiseren, kunnen onze ontwikkelaars code schrijven die de failover-methode aanroept in de REST API van Azure SQL Database.
Notitie
Door beheerde exemplaren van Azure SQL Database wordt actieve geo-replicatie niet ondersteund. Beheerde exemplaren zijn ontworpen om het eenvoudig te maken om gegevens van een on-premises SQL Server te migreren terwijl de beveiliging gehandhaafd blijft. Als u een beheerd exemplaar gebruikt, kunt u in plaats daarvan failovergroepen gebruiken.
Automatische failover-groepen
Een automatische failover-groep is een groep databases waarin gegevens automatisch van een primaire naar een of meer secundaire servers worden gerepliceerd. Dit ontwerp lijkt op actieve geo-replicatie en maakt gebruik van dezelfde gegevensreplicatiemethode. We kunnen de reactie op een storing echter automatiseren door een beleid te definiëren.
Voor de verzendportal maken we een secundaire database in de regio VS - west. Vervolgens voegen we een beleid toe waarmee een failover wordt uitgevoerd van de primaire replica van de database naar VS - west als er een onherstelbare fout optreedt in de regio VS - oost. Als dat gebeurt, wordt de replica in VS - west automatisch de beschrijfbare primaire database, en blijft de volledige functionaliteit gehandhaafd.
Overweeg het gebruik van een automatische failover-groep als u de failover van de beschrijfbare database wilt automatiseren zonder aangepaste code te schrijven om deze te activeren. Gebruik ook groepen voor automatische failover als uw database wordt uitgevoerd in een beheerd exemplaar van Azure SQL Database.
Belangrijk
De replicatie die zowel actieve geo-replicatie als automatische failovergroepen ten grondslag liggen, zijn asynchroon. Er wordt een bevestiging naar de client verzonden wanneer een wijziging wordt toegepast op de primaire replica. Op dit moment wordt de transactie als voltooid beschouwd en wordt er een replicatie uitgevoerd. Als er een storing plaatsvindt, zijn de meest recente wijzigingen die zijn aangebracht in de primaire database mogelijk niet naar de secundaire gerepliceerd. Houd er wel rekening mee dat de meest recente databasewijzigingen mogelijk verloren zijn gegaan na een noodgeval.
Azure Cosmos DB
Onze configuratie is minder complex met Azure Cosmos DB omdat deze is ontworpen als een databasesysteem voor meerdere regio's in de cloud. Cosmos DB is een database met meerdere modellen, waarmee u relationele gegevens, semi-gestructureerde gegevens en andere vormen van gegevens kunt opslaan. Zelfs als we Cosmos DB in één regio uitvoeren, worden gegevens naar meerdere exemplaren in verschillende foutdomeinen gerepliceerd voor de beste beschikbaarheid.
Wanneer we een Cosmos DB-account maken met meerdere regio's, kunnen we kiezen uit de volgende modi:
Multiregio-accounts met meerdere schrijfregio's.
In deze modus zijn alle kopieën van de database altijd beschrijfbaar. Als er een storing plaatsvindt in een regio, is er geen failover nodig.
Accounts verspreid over meerdere regio's met één enkele schrijfgeregio.
In deze modus bevat alleen de primaire regio beschrijfbare databases. De gegevens die naar de secundaire regio's worden gerepliceerd, zijn alleen-lezen. Updates zijn standaard uitgeschakeld wanneer er een storing plaatsvindt in de primaire regio. We kunnen echter automatische failover inschakelen , zodat Cosmos DB automatisch een failover uitvoert van de primaire, beschrijfbare kopie van de database naar een andere regio.
Belangrijk
In Cosmos DB is gegevensreplicatie synchroon. Wanneer een wijziging wordt toegepast, wordt de transactie niet als voltooid beschouwd totdat naar een quorum van replica's wordt gerepliceerd. Vervolgens wordt er een bevestiging naar de client verzonden. Als er een storing plaatsvindt, gaan er geen recente wijzigingen verloren omdat de replicatie al is uitgevoerd.