Toepassingspatronen en ontwikkelingsstrategieën voor SQL Server op Azure Virtual Machines

Van toepassing op: SQL Server op Azure VM

Notitie

Azure heeft twee verschillende implementatiemodellen voor het maken van en werken met resources: Resource Manager en het klassieke model. In dit artikel komen beide modellen aan de orde, maar u wordt aangeraden voor de meeste nieuwe implementaties het Resource Manager-model te gebruiken.

Overzicht

Bepalen welk toepassingspatroon of -patronen moeten worden gebruikt voor uw op SQL Server gebaseerde toepassingen in een Azure-omgeving is een belangrijke ontwerpbeslissing en vereist een solide kennis van hoe SQL Server en elk infrastructuuronderdeel van Azure samenwerken. Met SQL Server in Azure Infrastructure Services kunt u uw bestaande SQL Server-toepassingen die zijn gebouwd op Windows Server eenvoudig migreren, onderhouden en bewaken naar virtuele machines (VM's) in Azure.

Het doel van dit artikel is om oplossingsarchitecten en ontwikkelaars een basis te bieden voor een goede toepassingsarchitectuur en -ontwerp, die ze kunnen volgen bij het migreren van bestaande toepassingen naar Azure en het ontwikkelen van nieuwe toepassingen in Azure.

Voor elk toepassingspatroon vindt u een on-premises scenario, de bijbehorende cloudoplossing en de bijbehorende technische aanbevelingen. Daarnaast worden in het artikel specifieke ontwikkelingsstrategieën van Azure besproken, zodat u uw toepassingen correct kunt ontwerpen. Vanwege de vele mogelijke toepassingspatronen wordt aanbevolen dat architecten en ontwikkelaars het meest geschikte patroon voor hun toepassingen en gebruikers moeten kiezen.

Technische inzenders: Luis Carlos Vargas Herring, Madhan Arumugam Ramakrishnan

Technische revisoren: Corey Sanders, Drew McDaniel, Narayan Annamalai, Nir Mashkow, Sanjay Mishra, Silvano Coriani, Stefan Schackow, Tim Hickey, Tim Wieman, Jin

Inleiding

U kunt veel soorten toepassingen met n-lagen ontwikkelen door de onderdelen van de verschillende toepassingslagen op verschillende computers en in afzonderlijke onderdelen te scheiden. U kunt bijvoorbeeld de onderdelen van de clienttoepassing en bedrijfsregels op één computer, de front-endweblaag en onderdelen van de gegevenstoegangslaag op een andere computer en een back-enddatabaselaag op een andere computer plaatsen. Dit soort structurering helpt bij het isoleren van elke laag van elkaar. Als u wijzigt waar gegevens vandaan komen, hoeft u de client of webtoepassing niet te wijzigen, maar alleen de onderdelen van de gegevenstoegangslaag.

Een typische n-tier-toepassing omvat de presentatielaag, de bedrijfslaag en de gegevenslaag:

Laag	Beschrijving
Presentatie	De presentatielaag (weblaag , front-endlaag) is de laag waarin gebruikers interactie hebben met een toepassing.
Bedrijf	De bedrijfslaag (middelste laag) is de laag die de presentatielaag en de gegevenslaag gebruiken om met elkaar te communiceren en bevat de kernfunctionaliteit van het systeem.
Data	De gegevenslaag is in feite de server waarin de gegevens van een toepassing worden opgeslagen (bijvoorbeeld een server waarop SQL Server wordt uitgevoerd).

Toepassingslagen beschrijven de logische groeperingen van de functionaliteit en onderdelen in een toepassing; terwijl lagen de fysieke distributie van de functionaliteit en onderdelen op afzonderlijke fysieke servers, computers, netwerken of externe locaties beschrijven. De lagen van een toepassing bevinden zich mogelijk op dezelfde fysieke computer (dezelfde laag) of kunnen worden verdeeld over afzonderlijke computers (n-laag) en de onderdelen in elke laag communiceren met onderdelen in andere lagen via goed gedefinieerde interfaces. U kunt de termlaag beschouwen als verwijzingen naar fysieke distributiepatronen, zoals twee lagen, drie lagen en n-laag. Een toepassingspatroon met twee lagen bevat twee toepassingslagen: toepassingsserver en databaseserver. De directe communicatie vindt plaats tussen de toepassingsserver en de databaseserver. De toepassingsserver bevat zowel weblaag- als bedrijfslaagonderdelen. In een toepassingspatroon met drie lagen zijn er drie toepassingslagen: webserver, toepassingsserver, die de bedrijfslogicalaag en/of de gegevenstoegangsonderdelen van de bedrijfslaag en/of de databaseserver bevat. De communicatie tussen de webserver en de databaseserver vindt plaats via de toepassingsserver. Zie de Handleiding voor Microsoft-toepassingsarchitectuur voor gedetailleerde informatie over toepassingslagen en -lagen.

Voordat u begint met het lezen van dit artikel, moet u kennis hebben van de basisconcepten van SQL Server en Azure. Zie SQL Server Books Online, SQL Server on Azure Virtual Machines en Azure.com voor meer informatie.

In dit artikel worden verschillende toepassingspatronen beschreven die geschikt kunnen zijn voor uw eenvoudige toepassingen en de zeer complexe bedrijfstoepassingen. Voordat u elk patroon detailleert, raden we u aan vertrouwd te raken met de beschikbare gegevensopslagservices in Azure, zoals Azure Storage, Azure SQL Database en SQL Server op een virtuele Azure-machine. Als u de beste ontwerpbeslissingen voor uw toepassingen wilt nemen, moet u weten wanneer u welke gegevensopslagservice duidelijk moet gebruiken.

Kies SQL Server op virtuele Azure-machines wanneer:

• U hebt controle nodig over SQL Server en Windows. Dit kan bijvoorbeeld de SQL Server-versie, speciale hotfixes, prestatieconfiguratie, enzovoort zijn.

• U hebt een volledige compatibiliteit met SQL Server nodig en u wilt bestaande toepassingen naar Azure als zodanig verplaatsen.

• U wilt gebruikmaken van de mogelijkheden van de Azure-omgeving, maar Azure SQL Database biedt geen ondersteuning voor alle functies die uw toepassing nodig heeft. Dit kan de volgende gebieden omvatten:

  • Databasegrootte: Op het moment dat dit artikel is bijgewerkt, ondersteunt SQL Database een database van maximaal 1 TB aan gegevens. Als voor uw toepassing meer dan 1 TB aan gegevens is vereist en u geen aangepaste shardingoplossingen wilt implementeren, wordt u aangeraden SQL Server te gebruiken in een virtuele Azure-machine. Zie Het uitschalen van Azure SQL Database, aankoopmodel op basis van DTU en aankoopmodel op basis van vCore (preview) voor de meest recente informatie.
  • HIPAA-naleving: Klanten in de gezondheidszorg en onafhankelijke softwareleveranciers (ISV's) kunnen SQL Server op Azure Virtual Machines kiezen in plaats van Azure SQL Database, omdat SQL Server op Azure Virtual Machines wordt gedekt door de HIPAA Business Associate Agreement (BAA). Zie Het Vertrouwenscentrum van Microsoft Azure voor meer informatie over naleving : Naleving.
  • Functies op exemplaarniveau: Op dit moment biedt SQL Database geen ondersteuning voor functies die zich buiten de database bevinden (zoals gekoppelde servers, agenttaken, FileStream, Service Broker, enzovoort). Zie Richtlijnen en beperkingen voor Azure SQL Database voor meer informatie.

1-laag (eenvoudig): Enkele virtuele machine

In dit toepassingspatroon implementeert u uw SQL Server-toepassing en -database op een zelfstandige virtuele machine in Azure. Dezelfde virtuele machine bevat uw client/webtoepassing, bedrijfsonderdelen, gegevenstoegangslaag en de databaseserver. De code voor presentatie, bedrijf en gegevenstoegang is logisch gescheiden, maar bevindt zich fysiek op een computer met één server. De meeste klanten beginnen met dit toepassingspatroon en vervolgens schalen ze uit door meer webrollen of virtuele machines toe te voegen aan hun systeem.

Dit toepassingspatroon is handig wanneer:

• U wilt een eenvoudige migratie naar het Azure-platform uitvoeren om te evalueren of het platform voldoet aan de vereisten van uw toepassing of niet.
• U wilt alle toepassingslagen die worden gehost op dezelfde virtuele machine in hetzelfde Azure-datacenter behouden om de latentie tussen lagen te verminderen.
• U wilt snel ontwikkel- en testomgevingen inrichten voor korte tijd.
• U wilt stresstests uitvoeren voor verschillende werkbelastingniveaus, maar tegelijkertijd wilt u niet de eigenaar zijn en veel fysieke machines voortdurend onderhouden.

In het volgende diagram ziet u een eenvoudig on-premises scenario en hoe u de cloudoplossing in één virtuele machine in Azure kunt implementeren.

Het implementeren van de bedrijfslaag (bedrijfslogica en onderdelen voor gegevenstoegang) op dezelfde fysieke laag als de presentatielaag kan de prestaties van toepassingen maximaliseren, tenzij u een afzonderlijke laag moet gebruiken vanwege schaalbaarheid of beveiligingsproblemen.

Omdat dit een zeer gebruikelijk patroon is om mee te beginnen, vindt u mogelijk het volgende artikel over migratie nuttig voor het verplaatsen van uw gegevens naar uw SQL Server-VM: Migratiehandleiding: SQL Server naar SQL Server op Virtuele Azure-machines.

Drie lagen (eenvoudig): Meerdere virtuele machines

In dit toepassingspatroon implementeert u een toepassing met drie lagen in Azure door elke toepassingslaag in een andere virtuele machine te plaatsen. Dit biedt een flexibele omgeving voor eenvoudige scenario's voor omhoog schalen en uitschalen. Wanneer de ene virtuele machine uw client/webtoepassing bevat, host de andere de bedrijfsonderdelen en de andere als host voor de databaseserver.

Dit toepassingspatroon is handig wanneer:

• U wilt een migratie uitvoeren van complexe databasetoepassingen naar Azure Virtual Machines.
• U wilt dat verschillende toepassingslagen worden gehost in verschillende regio's. U hebt bijvoorbeeld gedeelde databases die zijn geïmplementeerd in meerdere regio's voor rapportagedoeleinden.
• U wilt bedrijfstoepassingen verplaatsen van on-premises gevirtualiseerde platforms naar Azure Virtual Machines. Zie Wat is een bedrijfstoepassing voor een gedetailleerde bespreking van bedrijfstoepassingen.
• U wilt snel ontwikkel- en testomgevingen inrichten voor korte tijd.
• U wilt stresstests uitvoeren voor verschillende werkbelastingniveaus, maar tegelijkertijd wilt u niet de eigenaar zijn en veel fysieke machines voortdurend onderhouden.

In het volgende diagram ziet u hoe u een eenvoudige toepassing met drie lagen in Azure kunt plaatsen door elke toepassingslaag in een andere virtuele machine te plaatsen.

In dit toepassingspatroon is er slechts één virtuele machine in elke laag. Als u meerdere VM's in Azure hebt, raden we u aan een virtueel netwerk in te stellen. Azure Virtual Network maakt een vertrouwde beveiligingsgrens en stelt VM's ook in staat om onderling te communiceren via het privé-IP-adres. Zorg er bovendien altijd voor dat alle internetverbinding alleen naar de presentatielaag gaat. Wanneer u dit toepassingspatroon volgt, beheert u de regels voor de netwerkbeveiligingsgroep om de toegang te beheren. Zie Externe toegang tot uw VIRTUELE machine toestaan met behulp van Azure Portal voor meer informatie.

In het diagram kunnen internetprotocollen TCP, UDP, HTTP of HTTPS zijn.

Notitie

Het instellen van een virtueel netwerk in Azure is gratis. Er worden echter kosten in rekening gebracht voor de VPN-gateway die verbinding maakt met on-premises. Deze kosten zijn gebaseerd op de hoeveelheid tijd die de verbinding is ingericht en beschikbaar is.

Uitschalen van de presentatielaag met 2 lagen en 3 lagen

In dit toepassingspatroon implementeert u een databasetoepassing met twee lagen of drie lagen in Azure Virtual Machines door elke toepassingslaag in een andere virtuele machine te plaatsen. Daarnaast schaalt u de presentatielaag uit vanwege een groter volume aan binnenkomende clientaanvragen.

Dit toepassingspatroon is handig wanneer:

• U wilt bedrijfstoepassingen verplaatsen van on-premises gevirtualiseerde platforms naar Azure Virtual Machines.
• U wilt de presentatielaag uitbreiden vanwege een groter aantal binnenkomende clientaanvragen.
• U wilt snel ontwikkel- en testomgevingen inrichten voor korte tijd.
• U wilt stresstests uitvoeren voor verschillende werkbelastingniveaus, maar tegelijkertijd wilt u niet de eigenaar zijn en veel fysieke machines voortdurend onderhouden.
• U wilt eigenaar zijn van een infrastructuuromgeving die op aanvraag omhoog en omlaag kan worden geschaald.

In het volgende diagram ziet u hoe u de toepassingslagen op meerdere virtuele machines in Azure kunt plaatsen door de presentatielaag uit te schalen vanwege een groter aantal binnenkomende clientaanvragen. Zoals te zien is in het diagram, is Azure Load Balancer verantwoordelijk voor het distribueren van verkeer over meerdere virtuele machines en het bepalen met welke webserver verbinding moet worden gemaakt. Als u meerdere exemplaren van de webservers achter een load balancer hebt, zorgt u voor een hoge beschikbaarheid van de presentatielaag.

Aanbevolen procedures voor patronen met twee lagen, 3 lagen of n-lagen met meerdere VM's in één laag

Het is raadzaam om de virtuele machines die deel uitmaken van dezelfde laag in dezelfde cloudservice en in dezelfde beschikbaarheidsset te plaatsen. Plaats bijvoorbeeld een set webservers in CloudService1 en AvailabilitySet1 en een set databaseservers in CloudService2 en AvailabilitySet2. Met een beschikbaarheidsset in Azure kunt u de knooppunten met hoge beschikbaarheid in afzonderlijke foutdomeinen plaatsen en domeinen upgraden.

Als u meerdere VM-exemplaren van een laag wilt gebruiken, moet u Azure Load Balancer tussen toepassingslagen configureren. Als u Load Balancer in elke laag wilt configureren, maakt u een eindpunt met gelijke taakverdeling op de VM's van elke laag afzonderlijk. Voor een specifieke laag maakt u eerst VM's in dezelfde cloudservice. Dit zorgt ervoor dat ze hetzelfde openbare virtuele IP-adres hebben. Maak vervolgens een eindpunt op een van de virtuele machines in die laag. Wijs vervolgens hetzelfde eindpunt toe aan de andere virtuele machines op die laag voor taakverdeling. Door een set met gelijke taakverdeling te maken, distribueert u verkeer over meerdere virtuele machines en stelt u de Load Balancer ook in staat om te bepalen welk knooppunt verbinding moet maken wanneer een back-end-VM-knooppunt mislukt. Als u bijvoorbeeld meerdere exemplaren van de webservers achter een load balancer hebt, zorgt u voor een hoge beschikbaarheid van de presentatielaag.

Zorg er altijd voor dat alle internetverbinding eerst naar de presentatielaag gaat. De presentatielaag heeft toegang tot de bedrijfslaag en vervolgens heeft de bedrijfslaag toegang tot de gegevenslaag. Zie Externe toegang tot uw virtuele machine toestaan met behulp van Azure Portal voor meer informatie over het toestaan van toegang tot de presentatielaag.

De load balancer in Azure werkt vergelijkbaar met load balancers in een on-premises omgeving. Zie Taakverdeling voor Azure-infrastructuurservices voor meer informatie.

Daarnaast raden we u aan een particulier netwerk in te stellen voor uw virtuele machines met behulp van Azure Virtual Network. Hierdoor kunnen ze onderling communiceren via het privé-IP-adres. Zie Azure Virtual Network voor meer informatie.

2-laag en 3-laag met uitschalen van bedrijfslaag

In dit toepassingspatroon implementeert u een databasetoepassing met twee lagen of drie lagen in Azure Virtual Machines door elke toepassingslaag in een andere virtuele machine te plaatsen. Daarnaast kunt u de onderdelen van de toepassingsserver distribueren naar meerdere virtuele machines vanwege de complexiteit van uw toepassing.

Dit toepassingspatroon is handig wanneer:

• U wilt bedrijfstoepassingen verplaatsen van on-premises gevirtualiseerde platforms naar Azure Virtual Machines.
• U wilt de onderdelen van de toepassingsserver distribueren naar meerdere virtuele machines vanwege de complexiteit van uw toepassing.
• U wilt bedrijfslogica zware on-premises LOB-toepassingen (Line-Of-Business) verplaatsen naar Azure Virtual Machines. LOB-toepassingen zijn een set essentiële computertoepassingen die essentieel zijn voor het uitvoeren van een onderneming, zoals accounting, human resources (HR), salarisadministratie, toeleveringsketenbeheer en resourceplanningstoepassingen.
• U wilt snel ontwikkel- en testomgevingen inrichten voor korte tijd.
• U wilt stresstests uitvoeren voor verschillende werkbelastingniveaus, maar tegelijkertijd wilt u niet de eigenaar zijn en veel fysieke machines voortdurend onderhouden.
• U wilt eigenaar zijn van een infrastructuuromgeving die op aanvraag omhoog en omlaag kan worden geschaald.

In het volgende diagram ziet u een on-premises scenario en de cloudoplossing. In dit scenario plaatst u de toepassingslagen op meerdere virtuele machines in Azure door de bedrijfslaag uit te schalen, die de bedrijfslogicalaag en gegevenstoegangsonderdelen bevat. Zoals te zien is in het diagram, is Azure Load Balancer verantwoordelijk voor het distribueren van verkeer over meerdere virtuele machines en het bepalen met welke webserver verbinding moet worden gemaakt. Als u meerdere exemplaren van de toepassingsservers achter een load balancer hebt, zorgt u voor een hoge beschikbaarheid van de bedrijfslaag. Zie Aanbevolen procedures voor toepassingspatronen met twee lagen, drie lagen of n-lagen met meerdere virtuele machines in één laag voor meer informatie.

2-laag en 3-laag met presentatie- en bedrijfslagen uitschalen en HADR

In dit toepassingspatroon implementeert u een databasetoepassing met twee lagen of 3 lagen in Azure Virtual Machines door de presentatielaag (webserver) en de onderdelen van de bedrijfslaag (toepassingsserver) te distribueren naar meerdere virtuele machines. Daarnaast implementeert u OPLOSSINGEN voor hoge beschikbaarheid en herstel na noodgevallen (HADR) voor uw databases in Azure Virtual Machines.

Dit toepassingspatroon is handig wanneer:

• U wilt bedrijfstoepassingen on-premises verplaatsen van gevirtualiseerde platforms naar Azure door de mogelijkheden voor hoge beschikbaarheid en herstel na noodgevallen van SQL Server te implementeren.
• U wilt de presentatielaag en de bedrijfslaag uitbreiden vanwege een groter volume aan binnenkomende clientaanvragen en de complexiteit van uw toepassing.
• U wilt snel ontwikkel- en testomgevingen inrichten voor korte tijd.
• U wilt stresstests uitvoeren voor verschillende werkbelastingniveaus, maar tegelijkertijd wilt u niet de eigenaar zijn en veel fysieke machines voortdurend onderhouden.
• U wilt eigenaar zijn van een infrastructuuromgeving die op aanvraag omhoog en omlaag kan worden geschaald.

In het volgende diagram ziet u een on-premises scenario en de cloudoplossing. In dit scenario schaalt u de presentatielaag en de onderdelen van de bedrijfslaag uit op meerdere virtuele machines in Azure. Daarnaast implementeert u HADR-technieken (hoge beschikbaarheid en herstel na noodgevallen) voor SQL Server-databases in Azure.

Als u meerdere exemplaren van een toepassing op verschillende VM's uitvoert, moet u ervoor zorgen dat u taakverdelingsaanvragen over deze aanvragen uitvoert. Wanneer u meerdere virtuele machines hebt, moet u ervoor zorgen dat al uw VM's op één moment toegankelijk zijn en worden uitgevoerd. Als u taakverdeling configureert, houdt Azure Load Balancer de status van VM's bij en stuurt binnenkomende aanroepen naar de goed werkende VM-knooppunten correct. Zie Taakverdeling voor Azure-infrastructuurservices voor informatie over het instellen van taakverdeling van de virtuele machines. Het hebben van meerdere exemplaren van web- en toepassingsservers achter een load balancer zorgt voor hoge beschikbaarheid van de presentatie- en bedrijfslagen.

Aanbevolen procedures voor toepassingspatronen waarvoor SQL HADR is vereist

Wanneer u oplossingen voor hoge beschikbaarheid en herstel na noodgevallen voor SQL Server instelt in Azure Virtual Machines, is het instellen van een virtueel netwerk voor uw virtuele machines met behulp van Azure Virtual Network verplicht. Virtuele machines in een virtueel netwerk hebben een stabiel privé-IP-adres, zelfs na uitvaltijd van een service, zodat u de updatetijd voor DNS-naamomzetting kunt voorkomen. Daarnaast kunt u met het virtuele netwerk uw on-premises netwerk uitbreiden naar Azure en een vertrouwde beveiligingsgrens maken. Als uw toepassing bijvoorbeeld beperkingen voor bedrijfsdomeinen heeft (zoals Windows-verificatie, Active Directory), is het instellen van Azure Virtual Network nodig.

De meeste klanten, die productiecode uitvoeren in Azure, houden zowel primaire als secundaire replica's in Azure.

Zie voor uitgebreide informatie en zelfstudies over hoge beschikbaarheid en technieken voor herstel na noodgevallen hoge beschikbaarheid en herstel na noodgevallen voor SQL Server op virtuele Azure-machines.

Twee lagen en drie lagen met azure Virtual Machines en Cloud Services

In dit toepassingspatroon implementeert u een toepassing met twee lagen of 3 lagen in Azure met behulp van zowel Azure Cloud Services (web- als werkrollen - Platform as a Service (PaaS) en Azure Virtual Machines (Infrastructure as a Service (IaaS)). Het gebruik van Azure Cloud Services voor de presentatielaag/bedrijfslaag en SQL Server in Azure Virtual Machines voor de gegevenslaag is nuttig voor de meeste toepassingen die worden uitgevoerd in Azure. De reden hiervoor is dat het uitvoeren van een rekenproces in Cloud Services een eenvoudig beheer, implementatie, bewaking en uitschalen biedt.

Met Cloud Services onderhoudt Azure de infrastructuur voor u, voert routineonderhoud uit, patches op de besturingssystemen en probeert te herstellen van service- en hardwarefouten. Wanneer uw toepassing uitschalen, automatisch en handmatig uitschalen nodig heeft, zijn er opties voor uitschalen beschikbaar voor uw cloudserviceproject door het aantal exemplaren of virtuele machines dat door uw toepassing wordt gebruikt, te vergroten of te verlagen. Daarnaast kunt u on-premises Visual Studio gebruiken om uw toepassing te implementeren in een cloudserviceproject in Azure.

Kortom, als u geen uitgebreide beheertaken wilt uitvoeren voor de presentatie-/bedrijfslaag en uw toepassing geen complexe configuratie van software of het besturingssysteem vereist, gebruikt u Azure Cloud Services. Als Azure SQL Database niet alle functies ondersteunt die u zoekt, gebruikt u SQL Server in een virtuele Azure-machine voor de gegevenslaag. Het uitvoeren van een toepassing in Azure Cloud Services en het opslaan van gegevens in Azure Virtual Machines combineert de voordelen van beide services. Zie de sectie in dit onderwerp over het vergelijken van ontwikkelingsstrategieën in Azure voor een gedetailleerde vergelijking.

In dit toepassingspatroon bevat de presentatielaag een webrol. Dit is een Cloud Services-onderdeel dat wordt uitgevoerd in de Azure-uitvoeringsomgeving en is aangepast voor het programmeren van webtoepassingen, zoals ondersteund door IIS en ASP.NET. De bedrijfs- of back-endlaag bevat een werkrol, een Cloud Services-onderdeel dat wordt uitgevoerd in de Azure-uitvoeringsomgeving en is handig voor gegeneraliseerde ontwikkeling en kan achtergrondverwerking uitvoeren voor een webrol. De databaselaag bevindt zich in een virtuele SQL Server-machine in Azure. De communicatie tussen de presentatielaag en de databaselaag vindt rechtstreeks of via de bedrijfslaag plaats: werkrolonderdelen.

Dit toepassingspatroon is handig wanneer:

• U wilt bedrijfstoepassingen on-premises verplaatsen van gevirtualiseerde platforms naar Azure door de mogelijkheden voor hoge beschikbaarheid en herstel na noodgevallen van SQL Server te implementeren.
• U wilt eigenaar zijn van een infrastructuuromgeving die op aanvraag omhoog en omlaag kan worden geschaald.
• Azure SQL Database biedt geen ondersteuning voor alle functies die uw toepassing of database nodig heeft.
• U wilt stresstests uitvoeren voor verschillende werkbelastingniveaus, maar tegelijkertijd wilt u niet de eigenaar zijn en veel fysieke machines voortdurend onderhouden.

In het volgende diagram ziet u een on-premises scenario en de cloudoplossing. In dit scenario plaatst u de presentatielaag in webrollen, de bedrijfslaag in werkrollen, maar de gegevenslaag in virtuele machines in Azure. Als u meerdere exemplaren van de presentatielaag in verschillende webrollen uitvoert, zorgt u ervoor dat aanvragen over de verschillende lagen worden verdeeld. Wanneer u Azure Cloud Services combineert met Azure Virtual Machines, wordt u aangeraden ook Azure Virtual Network in te stellen. Met Azure Virtual Network kunt u stabiele en permanente privé-IP-adressen binnen dezelfde cloudservice in de cloud hebben. Zodra u een virtueel netwerk definieert voor uw virtuele machines en cloudservices, kunnen ze met elkaar communiceren via het privé-IP-adres. Bovendien biedt het hebben van virtuele machines en Azure-web-/werkrollen in hetzelfde virtuele Azure-netwerk lage latentie en veiligere connectiviteit. Zie Wat is een cloudservice voor meer informatie.

Zoals u in het diagram ziet, distribueert Azure Load Balancer verkeer over meerdere virtuele machines en bepaalt ook met welke webserver of toepassingsserver verbinding moet worden gemaakt. Meerdere exemplaren van de web- en toepassingsservers achter een load balancer zorgen voor hoge beschikbaarheid van de presentatielaag en de bedrijfslaag. Zie Best practices voor toepassingspatronen waarvoor SQL HADR is vereist voor meer informatie.

Een andere benadering voor het implementeren van dit toepassingspatroon is het gebruik van een geconsolideerde webrol die zowel presentatielaag- als bedrijfslaagonderdelen bevat, zoals wordt weergegeven in het volgende diagram. Dit toepassingspatroon is handig voor toepassingen waarvoor stateful ontwerp is vereist. Omdat Azure staatloze rekenknooppunten op web- en werkrollen biedt, raden we u aan om een logica te implementeren voor het opslaan van sessiestatus met behulp van een van de volgende technologieën: Azure Caching, Azure Table Storage of Azure SQL Database.

Patroon met Azure Virtual Machines, Azure SQL Database en Azure-app Service (Web Apps)

Het primaire doel van dit toepassingspatroon is om u te laten zien hoe u IaaS-onderdelen (Infrastructure as a Service) kunt combineren met Azure PaaS-onderdelen (Platform-as-a-Service) in uw oplossing. Dit patroon is gericht op Azure SQL Database voor relationele gegevensopslag. Het omvat geen SQL Server in een virtuele Azure-machine, die deel uitmaakt van de Azure-infrastructuur als een serviceaanbieding.

In dit toepassingspatroon implementeert u een databasetoepassing in Azure door de presentatie- en bedrijfslagen in dezelfde virtuele machine te plaatsen en toegang te krijgen tot een database in Azure SQL Database-servers (SQL Database). U kunt de presentatielaag implementeren met behulp van traditionele weboplossingen op basis van IIS. U kunt ook een gecombineerde presentatie en bedrijfslaag implementeren met behulp van Azure-app Service.

Dit toepassingspatroon is handig wanneer:

• U hebt al een bestaande SQL Database-server geconfigureerd in Azure en u wilt uw toepassing snel testen.
• U wilt de mogelijkheden van de Azure-omgeving testen.
• U wilt snel ontwikkel- en testomgevingen inrichten voor korte tijd.
• Uw bedrijfslogica en onderdelen voor gegevenstoegang kunnen zelfstandig zijn binnen een webtoepassing.

In het volgende diagram ziet u een on-premises scenario en de cloudoplossing. In dit scenario plaatst u de toepassingslagen op één virtuele machine in Azure en opent u gegevens in Azure SQL Database.

Als u ervoor kiest om een gecombineerde web- en toepassingslaag te implementeren met behulp van Azure Web Apps, raden we u aan om de middelste laag of toepassingslaag te behouden als DLL's (Dynamic Link Libraries) in de context van een webtoepassing.

Bekijk bovendien de aanbevelingen in de sectie Webontwikkelingsstrategieën in Azure vergelijken aan het einde van dit artikel voor meer informatie over programmeertechnieken.

Hybride toepassingspatroon met N-laag

In een hybride toepassingspatroon met n-laag implementeert u uw toepassing in meerdere lagen die zijn gedistribueerd tussen on-premises en Azure. Daarom maakt u een flexibel en herbruikbaar hybride systeem, dat u kunt wijzigen of toevoegen aan een specifieke laag zonder de andere lagen te wijzigen. Als u uw bedrijfsnetwerk wilt uitbreiden naar de cloud, gebruikt u de Azure Virtual Network-service .

Dit hybride toepassingspatroon is handig wanneer:

• U wilt toepassingen bouwen die deels in de cloud en gedeeltelijk on-premises worden uitgevoerd.
• U wilt enkele of alle elementen van een bestaande on-premises toepassing migreren naar de cloud.
• U wilt bedrijfstoepassingen verplaatsen van on-premises gevirtualiseerde platforms naar Azure.
• U wilt eigenaar zijn van een infrastructuuromgeving die op aanvraag omhoog en omlaag kan worden geschaald.
• U wilt snel ontwikkel- en testomgevingen inrichten voor korte tijd.
• U wilt een rendabele manier om back-ups te maken voor bedrijfsdatabasetoepassingen.

In het volgende diagram ziet u een hybride toepassingspatroon met een n-laag dat zich over on-premises en Azure bevindt. Zoals in het diagram wordt weergegeven, bevat de on-premises infrastructuur Active Directory-domein Services-domeincontroller ter ondersteuning van gebruikersverificatie en -autorisatie. In het diagram ziet u een scenario waarin sommige delen van de gegevenslaag zich in een on-premises datacenter bevinden, terwijl sommige delen van de gegevenslaag zich in Azure bevinden. Afhankelijk van de behoeften van uw toepassing kunt u verschillende andere hybride scenario's implementeren. U kunt bijvoorbeeld de presentatielaag en de bedrijfslaag in een on-premises omgeving behouden, maar de gegevenslaag in Azure.

In Azure kunt u Microsoft Entra ID (voorheen Azure Active Directory) gebruiken voor identiteits- en toegangsbeheer, of u kunt een bestaande on-premises Active Directory integreren met Microsoft Entra-id. Zoals u in het diagram kunt zien, kunnen de onderdelen van de bedrijfslaag zich verifiëren bij meerdere gegevensbronnen, waaronder: SQL Server op Azure-VM's via een privé intern IP-adres, on-premises SQL Server via Azure Virtual Network of Azure SQL Database met behulp van de .NET Framework-gegevensprovidertechnologieën. In dit diagram is Azure SQL Database een optionele gegevensopslagservice.

In een hybride toepassingspatroon met een n-laag kunt u de volgende werkstroom implementeren in de opgegeven volgorde:

1. Identificeer bedrijfsdatabasetoepassingen die moeten worden verplaatst naar de cloud met behulp van de Microsoft Assessment and Planning (MAP) Toolkit. De MAP Toolkit verzamelt inventaris- en prestatiegegevens van computers die u overweegt voor virtualisatie en biedt aanbevelingen voor capaciteits- en evaluatieplanning.

2. Plan de resources en configuratie die nodig zijn in het Azure-platform, zoals opslagaccounts en virtuele machines.

3. Stel netwerkconnectiviteit in tussen het on-premises bedrijfsnetwerk en het virtuele Azure-netwerk. Als u de verbinding tussen het on-premises bedrijfsnetwerk en een virtuele machine in Azure wilt instellen, gebruikt u een van de volgende twee methoden:

   1. Maak een verbinding tussen on-premises en Azure via openbare eindpunten op een virtuele machine in Azure. Deze methode biedt een eenvoudige installatie en stelt u in staat OM SQL Server-verificatie in uw virtuele machine te gebruiken. Stel bovendien de regels voor uw netwerkbeveiligingsgroep in om openbaar verkeer naar de VIRTUELE machine te beheren. Zie Externe toegang tot uw VIRTUELE machine toestaan met behulp van Azure Portal voor meer informatie.

   2. Maak een verbinding tussen on-premises en Azure via vpn-tunnel (Virtual Private Network) van Azure. Met deze methode kunt u domeinbeleid uitbreiden naar een virtuele machine in Azure. Daarnaast kunt u firewallregels instellen en Windows-verificatie gebruiken op uw virtuele machine. Op dit moment ondersteuning voor Azure beveiligde site-naar-site-VPN- en punt-naar-site-VPN-verbindingen:

      • Met een beveiligde site-naar-site-verbinding kunt u netwerkconnectiviteit tot stand brengen tussen uw on-premises netwerk en uw virtuele netwerk in Azure. Het wordt aanbevolen om uw on-premises datacenteromgeving te verbinden met Azure.
      • Met een beveiligde punt-naar-site-verbinding kunt u een netwerkverbinding tot stand brengen tussen uw virtuele netwerk in Azure en uw afzonderlijke computers die overal worden uitgevoerd. Het wordt meestal aanbevolen voor ontwikkelings- en testdoeleinden.

      Zie Verbinding maken met een virtuele SQL Server-machine in Azure voor meer informatie over het maken van verbinding met SQL Server in Azure.

4. Stel geplande taken en waarschuwingen in die een back-up maken van on-premises gegevens op een schijf van een virtuele machine in Azure. Zie VOOR meer informatie SQL Server Backup and Restore with Azure Blob Storage and Backup and Restore for SQL Server on Azure Virtual Machines.

5. Afhankelijk van de behoeften van uw toepassing kunt u een van de volgende drie veelvoorkomende scenario's implementeren:

   1. U kunt uw webserver, toepassingsserver en niet-gevoelige gegevens in een databaseserver in Azure bewaren, terwijl u de gevoelige gegevens on-premises bewaart.
   2. U kunt uw webserver en toepassingsserver on-premises houden, terwijl de databaseserver zich op een virtuele machine in Azure bevindt.
   3. U kunt uw databaseserver, webserver en toepassingsserver on-premises houden, terwijl u de databasereplica's op virtuele machines in Azure bewaart. Met deze instelling hebben de on-premises webservers of rapportagetoepassingen toegang tot de databasereplica's in Azure. Daarom kunt u de workload in een on-premises database verlagen. We raden u aan dit scenario te implementeren voor zware leesworkloads en ontwikkelingsdoeleinden. Zie AlwaysOn-beschikbaarheidsgroepen bij hoge beschikbaarheid en herstel na noodgevallen voor SQL Server op virtuele Azure-machines voor meer informatie over het maken van databasereplica's in Azure.

Strategieën voor webontwikkeling vergelijken in Azure

Als u een op SQL Server gebaseerde toepassing met meerdere lagen in Azure wilt implementeren en implementeren, kunt u een van de volgende twee programmeermethoden gebruiken:

• Stel een traditionele webserver (IIS - Internet Information Services) in Azure in en open databases in SQL Server op Azure Virtual Machines.
• Implementeer en implementeer een cloudservice in Azure. Zorg er vervolgens voor dat deze cloudservice toegang heeft tot databases in SQL Server op azure Virtual Machines. Een cloudservice kan meerdere web- en werkrollen bevatten.

De volgende tabel bevat een vergelijking van traditionele webontwikkeling met Azure Cloud Services en Azure Web Apps met betrekking tot SQL Server op Azure Virtual Machines. De tabel bevat Azure Web Apps, omdat het mogelijk is om SQL Server in een Azure-VM te gebruiken als gegevensbron voor Azure Web Apps via het openbare virtuele IP-adres of de DNS-naam.

	Traditionele webontwikkeling in virtuele Azure-machines	Cloudservices in Azure	Webhosting met Azure Web Apps
Toepassingsmigratie van on-premises	Bestaande toepassingen als zodanig.	Toepassingen hebben web- en werkrollen nodig.	Bestaande toepassingen als zodanig, maar geschikt voor zelfstandige webtoepassingen en webservices waarvoor snelle schaalbaarheid is vereist.
Ontwikkeling en implementatie	Visual Studio, WebMatrix, Visual Web Developer, WebDeploy, FTP, TFS, IIS Manager, PowerShell.	Visual Studio, Azure SDK, TFS, PowerShell. Elke cloudservice heeft twee omgevingen waarin u uw servicepakket en configuratie kunt implementeren: fasering en productie. U kunt een cloudservice implementeren in de faseringsomgeving om deze te testen voordat u deze naar productie promoveert.	Visual Studio, WebMatrix, Visual Web Developer, FTP, GIT, BitBucket, CodePlex, DropBox, GitHub, Mercurial, TFS, Web Deploy, PowerShell.
Beheer beheer en installatie	U bent verantwoordelijk voor beheertaken voor de toepassing, gegevens, firewallregels, virtueel netwerk en besturingssysteem.	U bent verantwoordelijk voor beheertaken in de toepassing, gegevens, firewallregels en het virtuele netwerk.	U bent alleen verantwoordelijk voor beheertaken voor de toepassing en gegevens.
Hoge beschikbaarheid en herstel na noodgevallen (HADR)	U wordt aangeraden virtuele machines in dezelfde beschikbaarheidsset en in dezelfde cloudservice te plaatsen. Door uw VM's in dezelfde beschikbaarheidsset te houden, kan Azure de knooppunten met hoge beschikbaarheid in afzonderlijke foutdomeinen en upgradedomeinen plaatsen. Op dezelfde manier zorgt het houden van uw VM's in dezelfde cloudservice ervoor dat taakverdeling mogelijk is en vm's rechtstreeks met elkaar kunnen communiceren via het lokale netwerk in een Azure-datacenter. U bent verantwoordelijk voor het implementeren van een oplossing voor hoge beschikbaarheid en herstel na noodgevallen voor SQL Server op Azure Virtual Machines om downtime te voorkomen. Zie voor ondersteunde HADR-technologieën hoge beschikbaarheid en herstel na noodgevallen voor SQL Server op virtuele Azure-machines. U bent verantwoordelijk voor het maken van een back-up van uw eigen gegevens en toepassing. Azure kan uw virtuele machines verplaatsen als de hostmachine in het datacenter mislukt vanwege hardwareproblemen. Daarnaast kan er sprake zijn van geplande downtime van uw VIRTUELE machine wanneer de hostmachine wordt bijgewerkt voor beveiligingsupdates of software-updates. Daarom raden we u aan ten minste twee VM's in elke toepassingslaag te onderhouden om de continue beschikbaarheid te garanderen. Azure biedt geen SLA voor één virtuele machine.	Azure beheert de fouten die het gevolg zijn van de onderliggende hardware- of besturingssysteemsoftware. U wordt aangeraden meerdere exemplaren van een web- of werkrol te implementeren om de hoge beschikbaarheid van uw toepassing te garanderen. Zie Cloud Services, Virtual Machines en Virtual Network Service Level Agreement voor meer informatie. U bent verantwoordelijk voor het maken van een back-up van uw eigen gegevens en toepassing. Voor databases die zich in een SQL Server-database op een Azure-VM bevinden, bent u verantwoordelijk voor het implementeren van een oplossing voor hoge beschikbaarheid en herstel na noodgevallen om downtime te voorkomen. Zie Voor ondersteunde HDAR-technologieën hoge beschikbaarheid en herstel na noodgevallen voor SQL Server op virtuele Azure-machines. SQL Server Database Mirroring: Gebruiken met Azure Cloud Services (web-/werkrollen). VIRTUELE SQL Server-machines en een cloudserviceproject kunnen zich in hetzelfde virtuele Azure-netwerk bevinden. Als de SQL Server-VM zich niet in hetzelfde virtuele netwerk bevindt, moet u een SQL Server-alias maken om de communicatie naar het exemplaar van SQL Server te routeren. Daarnaast moet de aliasnaam overeenkomen met de SQL Server-naam.	Hoge beschikbaarheid wordt overgenomen van Azure-werkrollen, Azure Blob Storage en Azure SQL Database. Azure Storage onderhoudt bijvoorbeeld drie replica's van alle blob-, tabel- en wachtrijgegevens. In Azure SQL Database blijven drie replica's van gegevens actief: één primaire replica en twee secundaire replica's. Zie Azure Storage en Azure SQL Database voor meer informatie. Wanneer u SQL Server gebruikt in een Azure-VM als gegevensbron voor Azure Web Apps, moet u er rekening mee houden dat Azure Web Apps geen ondersteuning biedt voor Azure Virtual Network. Met andere woorden, alle verbindingen van Azure Web Apps naar SQL Server-VM's in Azure moeten via openbare eindpunten van virtuele machines lopen. Dit kan enkele beperkingen veroorzaken voor scenario's met hoge beschikbaarheid en herstel na noodgevallen. De clienttoepassing in Azure Web Apps die verbinding maakt met EEN SQL Server-VM met databasespiegeling, kan bijvoorbeeld geen verbinding maken met de nieuwe primaire server, omdat voor databasespiegeling vereist is dat u Azure Virtual Network instelt tussen VM's van de SQL Server-host in Azure. Daarom wordt het gebruik van SQL Server Database Mirroring met Azure Web Apps momenteel niet ondersteund. Sql Server AlwaysOn-beschikbaarheidsgroepen: u kunt AlwaysOn-beschikbaarheidsgroepen instellen wanneer u Azure Web Apps gebruikt met SQL Server-VM's in Azure. Maar u moet alwayson-listener voor beschikbaarheidsgroepen configureren om de communicatie naar de primaire replica te routeren via openbare eindpunten met gelijke taakverdeling.
Cross-premises connectiviteit	U kunt Azure Virtual Network gebruiken om verbinding te maken met on-premises.	U kunt Azure Virtual Network gebruiken om verbinding te maken met on-premises.	Azure Virtual Network wordt ondersteund.
Schaalbaarheid	Omhoog schalen is beschikbaar door de grootte van de virtuele machine te vergroten of meer schijven toe te voegen. Zie Virtuele-machinegrootten voor Azure voor meer informatie over grootten van virtuele machines. Voor Database Server: uitschalen is beschikbaar via databasepartitioneringstechnieken en SQL Server AlwaysOn-beschikbaarheidsgroepen. Voor zware leesworkloads kunt u AlwaysOn-beschikbaarheidsgroepen op meerdere secundaire knooppunten en SQL Server-replicatie gebruiken. Voor zware schrijfworkloads kunt u horizontale partitioneringsgegevens implementeren op meerdere fysieke servers om toepassing uit te schalen. Daarnaast kunt u een uitschaal implementeren met behulp van SQL Server met gegevensafhankelijke routering. Met DDR (Data Dependent Routing) moet u het partitioneringsmechanisme in de clienttoepassing implementeren, meestal in de laag bedrijfslaag, om de databaseaanvragen naar meerdere SQL Server-knooppunten te routeren. De bedrijfslaag bevat toewijzingen voor hoe de gegevens worden gepartitioneerd en welk knooppunt de gegevens bevat. U kunt toepassingen waarop virtuele machines worden uitgevoerd schalen. Zie Een toepassing schalen voor meer informatie. Belangrijke opmerking: met de functie Automatisch schalen in Azure kunt u de virtuele machines die door uw toepassing worden gebruikt, automatisch vergroten of verkleinen. Deze functie garandeert dat de eindgebruikerservaring niet negatief wordt beïnvloed tijdens piekperioden en VM's worden afgesloten wanneer de vraag laag is. Het is raadzaam om de optie Automatisch schalen niet in te stellen voor uw cloudservice als deze SQL Server-VM's bevat. De reden hiervoor is dat met de functie Automatisch schalen azure een virtuele machine kan inschakelen wanneer het CPU-gebruik in die VM hoger is dan een bepaalde drempelwaarde en een virtuele machine uitschakelt wanneer het CPU-gebruik lager wordt dan het CPU-gebruik. De functie Automatisch schalen is handig voor staatloze toepassingen, zoals webservers, waarbij elke VIRTUELE machine de werkbelasting kan beheren zonder verwijzingen naar een eerdere status. De functie Automatisch schalen is echter niet handig voor stateful toepassingen, zoals SQL Server, waarbij slechts één exemplaar het schrijven naar de database toestaat.	Omhoog schalen is beschikbaar met behulp van meerdere web- en werkrollen. Zie Grootten configureren voor Cloud Services voor meer informatie over de grootte van virtuele machines voor webrollen en werkrollen. Wanneer u Cloud Services gebruikt, kunt u meerdere rollen definiëren om de verwerking te distribueren en ook flexibele schaalaanpassing van uw toepassing te bereiken. Elke cloudservice bevat een of meer webrollen en/of werkrollen, elk met een eigen toepassingsbestanden en -configuratie. U kunt een cloudservice omhoog schalen door het aantal rolinstanties (virtuele machines) te verhogen dat is geïmplementeerd voor een rol en door een cloudservice omlaag te schalen door het aantal rolinstanties te verlagen. Zie Azure Execution Models voor gedetailleerde informatie. Uitschalen is beschikbaar via ingebouwde ondersteuning voor hoge beschikbaarheid van Azure via Cloud Services, Virtual Machines en Virtual Network Service Level Agreement en Load Balancer. Voor een toepassing met meerdere lagen raden we u aan om de toepassing web-/werkrollen te verbinden met databaseserver-VM's via Azure Virtual Network. Daarnaast biedt Azure taakverdeling voor VM's in dezelfde cloudservice, waarbij gebruikersaanvragen over deze vm's worden verspreid. Virtuele machines die op deze manier zijn verbonden, kunnen rechtstreeks met elkaar communiceren via het lokale netwerk binnen een Azure-datacenter. U kunt Automatische schaalaanpassing instellen in Azure Portal, evenals de planningstijden. Zie Automatisch schalen configureren voor een cloudservice in de portal voor meer informatie.	Omhoog en omlaag schalen: u kunt de grootte van het exemplaar (VM) dat is gereserveerd voor uw website vergroten/verkleinen. Uitschalen: U kunt meer gereserveerde instanties (VM's) toevoegen voor uw website. U kunt Automatische schaalaanpassing instellen in de portal, evenals de planningstijden. Zie Web Apps schalen voor meer informatie.

Zie Azure Web Apps, Cloud Services en VM's voor meer informatie over het kiezen tussen deze programmeermethoden : Wanneer te gebruiken.

Volgende stap

Zie overzicht van SQL Server op Azure Virtual Machines voor meer informatie over het uitvoeren van SQL Server op Azure Virtual Machines.