Scenario 1 oplossing - op wereldwijde schaal en veilige toegang

10 minuten

In het vorige gedeelte hebt u met een scenario gewerkt met betrekking tot het wereldwijd schalen van een netwerk voor contentlevering. In dit gedeelte beoordeelt u één potentiele oplossing en een aantal items waarmee u rekening moet houden.

Tijdens de beoordeling moet u de aangeboden oplossing vergelijken met de oplossing die u in het vorige gedeelte hebt ontwikkeld. Vaak bestaan er meerdere oplossingen voor een probleem: wat zijn de belangrijkste verschillen. Welke items van uw oplossing wijken af van de voorgestelde oplossing? Is er iets aan uw oplossing dat u zou willen aanpassen? Is iets aan de aangeboden oplossing waarvan u denkt dat het beter is uitgewerkt in uw oplossing?

Implementatieoptie en -configuratie

De eerste beslissing die u moet nemen is welke implementatieoptie van Azure SQL moet worden gekozen. Hoewel SQL Server in een virtuele machine (VM) van Azure zou werken, sluit een PaaS-aanbieding (platform as a service) waarschijnlijk beter aan waardoor u minder beheerwerk hebt.

De klant gebruikt de Common Language Runtime (CLR). Dit is een functie binnen het bereik van het exemplaar. Azure SQL Managed Instance IS de enige PaaS-implementatieoptie die ondersteuning biedt voor functies binnen het bereik van een exemplaar, zoals CLR, Service Broker en Database Mail. Om die reden kan Azure SQL Managed Instance deze functies verplaatsen naar een PaaS-aanbieding zonder dat hun CLR-toepassingen hoeven te worden herschreven naar een oplossing die compatibel is met Azure SQL Database (zoals Elastische taken).

De volgende beslissing die moet worden genomen is welke servicelaag moet worden gebruikt. Omdat de klant de lees- en schrijfworkloads willen scheiden, is het gebruik van de bedrijfskritische servicelaag de eenvoudigste manier om dat te bereiken. Bij de bedrijfskritische servicelaag wordt er een AlwaysOn-beschikbaarheidsgroep achter de schermen geïmplementeerd. Een van deze secundaire replica's kan worden gebruikt voor alleen-lezen workloads.

Bedrijfskritisch is hierbij slechts de helft van de configuratie om lees- en schrijfworkloads van elkaar te scheiden. In het scenario wordt aangegeven dat de klant moet kunnen opschalen naar meerdere regio's waarbij meerdere query's tegelijk plaatsvinden en dat leesworkloads en schrijfworkloads kunnen worden gescheiden.

De twee opties die deze uitdaging mogelijk aankunnen, zijn geo-replicatie en groepen voor automatische failover. Geo-replicatie wordt momenteel echter niet ondersteund in Azure SQL Managed Instance. Een groep voor automatische failover is daarom de enige optie waarmee in dit scenario een leesworkload naar wereldwijd kan worden opgeschaald.

Omdat de klant nu gebruikmaakt van groepen voor automatische failover, is het afhankelijk van het aantal Alleen lezen-eindpunten dat vereist is voor de analytische workload, of hij een bedrijfskritische servicelaag nodig heeft of niet. Met een groep voor automatische failover in de bedrijfskritische servicelaag krijgt de klant drie leesbare eindpunten:

Eén secundaire replica van de beschikbaarheidsgroep van de primaire regio
De secundaire groep van de failovergroep (de primaire replica van de database in de secundaire regio)
De secundaire replica van de beschikbaarheidsgroep van de secundaire regio

Als voor de analytische workload niet al deze leesbare replica's nodig zijn, is Algemene gebruik een rendabelere oplossing.

De meest geschikte verificatiemethoden selecteren

Het andere deel van dit scenario heeft betrekking op het bepalen van de beste manier voor elke toepassing/persoon om verbinding te maken met de oplossing, gezien de noodzaak om de veiligste technologieën te maken en te gebruiken. Het scenario kan worden opgedeeld in vier individuele clients die toegang nodig hebben tot Azure SQL Managed Instance:

Toepassing die wordt uitgevoerd op een virtuele machine van Azure
Een toepassing op een niet-Azure-machine die domein-gekoppeld is
DBA's of andere gebruikers van SQL-beheertools (SQL Server Management Studio, Azure Data Studio, PowerShell) vanaf een niet-Azure-machine die niet domein-gekoppeld is
Oudere toepassingen die worden uitgevoerd op een niet-Azure-machine, waarop u het stuurprogramma of de verbindingsreeks niet kunt wijzigen

Laten we elke individuele client eens nader bekijken om de beste verificatiemethode en enkele aanvullende overwegingen en beperkingen te bepalen.

Toepassing die wordt uitgevoerd op een virtuele machine van Azure

Beheerde identiteiten voor Azure-resources zijn in het algemeen de aanbevolen vorm van wachtwoordloze verificatie voor toepassingen die worden uitgevoerd op Azure-VM's.

Een toepassing op een niet-Azure-machine die domein-gekoppeld is

Voor machines die niet van Azure zijn, is het gebruik van beheerde identiteiten geen optie. Geïntegreerde verificatie via Microsoft Entra ID is de aanbevolen verificatiemethode voor apps die worden uitgevoerd op computers die lid zijn van een domein buiten Azure, ervan uitgaande dat het domein is gefedereerd met Microsoft Entra ID.

Als de niet-Azure-machine niet domein-gekoppeld is, kunt u:

Maak een toepassings-id voor uw toepassing in Microsoft Entra ID.
Een certificaat koppelen aan de toepassings-id.
Uw toepassing voor het verkrijgen van een token voor Azure SQL Database wijzigen door een client-ID en een certificaat op te geven.

Hoewel het certificaat een persoonlijke sleutel moet bevatten en moet worden geïmplementeerd op de computer die als host fungeert voor uw toepassing, hoeft u in elk geval geen toepassingsgeheim in de toepassingscode of configuratie vast te leggen (hardcoding). (U moet de app configureren met de vingerafdruk van het certificaat.)

DBA's of andere gebruikers van SQL-beheerhulpprogramma's vanaf een niet-Azure-machine die niet domein-gekoppeld is

Voor gebruikers buiten Azure wordt aanbevolen het gebruik van wachtwoorden, indien mogelijk, te vermijden. U kunt het gebruik van wachtwoorden met SQL-hulpprogramma's elimineren met behulp van geïntegreerde Microsoft Entra-verificatie. De hulpprogramma's moeten echter worden uitgevoerd op een computer die lid is van een domein en het domein moet zijn gefedereerd met Microsoft Entra ID, wat niet het geval is voor dit scenario.

Omdat de omgeving niet voldoet aan de vereisten voor geïntegreerde verificatie, raden we u aan om interactieve Microsoft Entra-verificatie te gebruiken met meervoudige verificatie, die de meeste SQL-hulpprogramma's ondersteunen.

Oudere toepassingen die worden uitgevoerd op een niet-Azure-machine, waarop u het stuurprogramma of de verbindingsreeks niet kunt wijzigen

In scenario's waarin het stuurprogramma of de verbindingsreeks niet kan worden gewijzigd, bestaat er momenteel geen optie om wachtwoorden te verwijderen. Deze oudere toepassingen moeten SQL-verificatie blijven gebruiken. U kunt echter overwegen de beperkingen nader te onderzoeken om te bepalen hoe ze kunnen worden opgeheven, zodat een veiligere verificatiemethode voor toepassingen kan worden geïmplementeerd.