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

  • Artikel
  • 30 minuten om te lezen

VAN TOEPASSING OP: SQL Server op virtuele Azure-machine

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.

Samenvatting:

Het bepalen welk toepassingspatroon of welke patronen u moet gebruiken voor uw SQL Server-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 Azure-specifieke ontwikkelingsstrategieën beschreven, zodat u uw toepassingen correct kunt ontwerpen. Vanwege de vele mogelijke toepassingspatronen is het raadzaam dat architecten en ontwikkelaars het meest geschikte patroon kiezen voor hun toepassingen en gebruikers.

Technische inzenders: Luis Carlos Vargas Herring, Madhan Arumugam Ramakrishish

Technische revisoren: CoreyKering, Drew McDaniel, Narayan Annamalai, Nir Mashkov, Sanjay Mishra, Zoudenno Cohrai,Slid Schackow, Tim Jamey, Tim Wieman, Xin Jin

Introductie

U kunt veel soorten n-tier-toepassingen 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, front-endweblaag en gegevenstoegangslaagonderdelen 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
Stijl De presentatielaag (weblaag, front-endlaag) is de laag waarin gebruikers met een toepassing communiceren.
Business 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.
Gegevens De gegevenslaag is in feite de server die de gegevens van een toepassing opgeslagen (bijvoorbeeld een server met SQL Server).

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 kunnen zich op dezelfde fysieke computer (dezelfde laag) bevinden of worden gedistribueerd over afzonderlijke computers (n-tier) en de onderdelen in elke laag communiceren met onderdelen in andere lagen via goed gedefinieerde interfaces. U kunt de term laag zien als verwijzing naar fysieke distributiepatronen, zoals tweelaags, drielaags en n-laag. Een toepassingspatroon met twee lagen bevat twee toepassingslagen: de toepassingsserver en de databaseserver. De directe communicatie vindt plaats tussen de toepassingsserver en de databaseserver. De toepassingsserver bevat zowel weblaag- als bedrijfsonderdelen. In een toepassingspatroon met drie lagen zijn er drie toepassingslagen: webserver, toepassingsserver, die de gegevenstoegangsonderdelen voor de bedrijfslogicalaag en/of bedrijfslaag bevat, en de databaseserver. De communicatie tussen de webserver en de databaseserver vindt plaats via de toepassingsserver. Zie microsoft Application Architecture Guide (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 Books Online SQL Server ,SQL Server in Azure Virtual Machines en Azure.com voor meer Azure.com.

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

Kies SQL Server azure-Virtual Machines, wanneer:

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

  • U hebt volledige compatibiliteit met uw SQL Server bestaande toepassingen wilt verplaatsen naar Azure.

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

    • Databasegrootte: op het moment dat dit artikel werd bijgewerkt, SQL Database een database van maximaal 1 TB aan gegevens ondersteunen. Als uw toepassing meer dan 1 TB aan gegevens vereist en u geen aangepaste sharding-oplossingen wilt implementeren, is het raadzaam om SQL Server te gebruiken in een virtuele Machine van Azure. Zie Scaling Out Azure SQL Database, DTU-Based Purchasing Modelen vCore-Based Purchasing Model(preview) voor de meest recente informatie.
    • HIPAA-naleving: klanten in de gezondheidszorg en onafhankelijke softwareleveranciers (ISV's) kunnen SQL Server kiezen op Azure Virtual Machines in plaats van Azure SQL Database omdat SQL Server in Azure Virtual Machines valt onder de HIPAA Business Associate Agreement (BAA). Zie vertrouwenscentrum voor naleving Microsoft Azure informatie over naleving.
    • Functies op exemplaarniveau: op dit moment biedt SQL Database geen ondersteuning voor functies buiten de database (zoals gekoppelde servers, agenttaken, FileStream, Service Broker, enzovoort). Zie voor meer informatie Azure SQL Database Richtlijnen en beperkingen.

1-laag (eenvoudig): Eén virtuele machine

In dit toepassingspatroon implementeert u uw SQL Server 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 zijn logisch gescheiden, maar bevinden 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 aan hun systeem toe te voegen.

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 op dezelfde virtuele machine in hetzelfde Azure-datacenter houden om de latentie tussen lagen te verminderen.
  • U wilt snel ontwikkel- en testomgevingen inrichten voor korte perioden.
  • U wilt stresstests uitvoeren voor verschillende workloadniveaus, maar tegelijkertijd wilt u niet de hele tijd eigenaar zijn van veel fysieke machines en deze onderhouden.

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

Toepassingspatroon met één laag

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.

Aangezien dit een heel gebruikelijk patroon is om mee te beginnen, kan het volgende artikel over migratie nuttig zijn voor het verplaatsen van uw gegevens naar uw SQL Server-VM: Een database migreren naar SQL Server op een Azure-VM.

Drielaags (eenvoudig): meerdere virtuele machines

In dit toepassingspatroon implementeert u een toepassing met drie lagen in Azure door elke toepassingslaag op 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. Het is bijvoorbeeld mogelijk dat u gedeelde databases hebt die voor rapportagedoeleinden in meerdere regio's zijn geïmplementeerd.
  • 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 perioden.
  • U wilt stresstests uitvoeren voor verschillende workloadniveaus, maar tegelijkertijd wilt u niet de hele tijd eigenaar zijn van veel fysieke machines en deze 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.

Toepassingspatroon met drie lagen

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

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 wordt ingericht en beschikbaar is.

2-laag en 3-laag met uitschalen van presentatielaag

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

Dit toepassingspatroon is handig wanneer:

  • U wilt bedrijfstoepassingen verplaatsen van on-premises gevirtualiseerde platforms naar Azure Virtual Machines.
  • U wilt de presentatielaag uitschalen vanwege een groter aantal inkomende clientaanvragen.
  • U wilt snel ontwikkel- en testomgevingen inrichten voor korte perioden.
  • U wilt stresstests uitvoeren voor verschillende workloadniveaus, maar tegelijkertijd wilt u niet de hele tijd eigenaar zijn van veel fysieke machines en deze 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 inkomende clientaanvragen. Zoals u in het diagram ziet, is Azure Load Balancer verantwoordelijk voor het distribueren van verkeer over meerdere virtuele machines en het bepalen met welke webserver verbinding moet worden gemaakt. Meerdere exemplaren van de webservers achter een load balancer zorgen voor hoge beschikbaarheid van de presentatielaag.

Toepassingspatroon - uitschalen van presentatielaag

Best practices voor patronen met twee lagen, drie lagen of n-lagen met meerdere VM's in één laag

Het is raadzaam om de virtuele machines die tot dezelfde laag behoren, 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 en upgradedomeinen plaatsen.

Als u meerdere VM-exemplaren van een laag wilt gebruiken, moet u Azure Load Balancer tussen toepassingslagen. Als u Load Balancer in elke laag wilt configureren, maakt u afzonderlijk een eindpunt met load balanced op de VM's van elke laag. Maak voor een specifieke laag 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 in die laag voor taakverdeling. Door een set met load balanced te maken, verdeelt u verkeer over meerdere virtuele machines en staat u de Load Balancer ook toe om te bepalen welk knooppunt verbinding moet maken wanneer een back-end-VM-knooppunt uitvalt. Als u bijvoorbeeld meerdere exemplaren van de webservers achter een load balancer zorgt u voor hoge beschikbaarheid van de presentatielaag.

Als best practice moet u er altijd voor zorgen dat alle internetverbinding eerst naar de presentatielaag gaan. De presentatielaag heeft toegang tot de bedrijfslaag en vervolgens heeft de bedrijfslaag toegang tot de gegevenslaag. Zie Externe toegang tot uw VM toestaan met behulp van de 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.

Bovendien raden we u aan om een privé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 of drie lagen in Azure Virtual Machines door elke toepassingslaag op een andere virtuele machine te plaatsen. Bovendien wilt u mogelijk 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.
  • Vanwege de complexiteit van uw toepassing wilt u de onderdelen van de toepassingsserver distribueren naar meerdere virtuele machines.
  • U wilt zakelijke logica met veel on-premises LOB-toepassingen (Line-Of-Business) verplaatsen naar Azure Virtual Machines. LOB-toepassingen zijn een reeks essentiële computertoepassingen die essentieel zijn voor het uitvoeren van een onderneming, zoals boekhouding, HR, salarissen, toeleveringsketenbeheer en toepassingen voor resourceplanning.
  • U wilt snel ontwikkel- en testomgevingen inrichten voor korte perioden.
  • U wilt stresstests uitvoeren voor verschillende workloadniveaus, maar tegelijkertijd wilt u niet de hele tijd eigenaar zijn van veel fysieke machines en deze onderhouden.
  • U wilt eigenaar zijn van een infrastructuuromgeving die op aanvraag omhoog en omlaag kan worden geschaald.

In het volgende diagram worden een on-premises scenario en de cloudoplossing gedemonstreerd. In dit scenario zet u de toepassingslagen op meerdere virtuele machines in Azure door de bedrijfslaag uit te schalen, die de bedrijfslogicalaag en gegevenstoegangsonderdelen bevat. Zoals u in het diagram ziet, is Azure Load Balancer verantwoordelijk voor het distribueren van verkeer over meerdere virtuele machines en het bepalen met welke webserver verbinding moet worden gemaakt. Meerdere exemplaren van de toepassingsservers achter een load balancer zorgt voor hoge beschikbaarheid van de bedrijfslaag. Zie Best practices for 2-tier, 3-tier, or n-tier application patterns that have multiple virtual machines in one tier (Best practicesvoor toepassingspatronen met 2 lagen, 3 lagen of n-tier) met meerdere virtuele machines in één laag voor meer informatie.

Toepassingspatroon met uitschalen van bedrijfslaag

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

In dit toepassingspatroon implementeert u een databasetoepassing met twee of drie 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 HADR-oplossingen (High Availability and Disaster Recovery) voor uw databases in Azure Virtual Machines.

Dit toepassingspatroon is handig wanneer:

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

In het volgende diagram worden een on-premises scenario en de cloudoplossing gedemonstreerd. 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 (High Availability and Disaster Recovery) voor SQL Server databases in Azure.

Als u meerdere exemplaren van een toepassing in verschillende VM's wilt uitvoeren, zorgt u ervoor dat u taakverdelingsaanvragen over deze VM's maakt. 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, Azure Load Balancer de status van VM's bij en worden binnenkomende aanroepen naar de goed functionerende VM-knooppunten door sturen. Zie Taakverdeling voor Azure-infrastructuurservices voor meer informatie over het instellen van taakverdeling van de virtuele machines. Als u meerdere exemplaren van web- en toepassingsservers achter een load balancer zorgt u voor hoge beschikbaarheid van de presentatie- en bedrijfslagen.

Uitschalen en hoge beschikbaarheid

Best practices voor toepassingspatronen waarvoor SQL HADR

Wanneer u een SQL Server voor hoge beschikbaarheid en noodherstel in Azure Virtual Machines instelt, is het instellen van een virtueel netwerk voor uw virtuele machines met behulp van Azure Virtual Network verplicht. Virtuele machines binnen een Virtual Network hebben een stabiel privé-IP-adres, zelfs na downtime van een service, zodat u de updatetijd kunt vermijden die nodig is voor DNS-naamresolutie. 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 vereist.

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

Zie High Availability and Disaster Recovery for SQL Server on Azure Virtual Machines (Hoge beschikbaarheid en herstel na noodherstel voor meer informatie en zelfstudies over technieken voor hoge beschikbaarheid en herstel na nood Virtual Machines.

2-laag en 3-laag met Behulp van Azure Virtual Machines en Cloud Services

In dit toepassingspatroon implementeert u een toepassing met twee of drie 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 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 rekenin instance op Cloud Services een eenvoudig beheer, implementatie, bewaking en uitschalen biedt.

Met Cloud Services onderhoudt Azure de infrastructuur voor u, voert routineonderhoud uit, patcht de besturingssystemen en probeert te herstellen van service- en hardwarefouten. Wanneer voor uw toepassing uitschaal-, automatische en handmatige uitschaalopties beschikbaar zijn, zijn deze beschikbaar voor uw cloudserviceproject door het aantal exemplaren of virtuele machines dat door uw toepassing wordt gebruikt, te verhogen of te verlagen. Daarnaast kunt u on-premises toepassingen gebruiken Visual Studio toepassing te implementeren in een cloudserviceproject in Azure.

Kortom, als u geen uitgebreide beheertaken voor de presentatie-/bedrijfslaag wilt hebben 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 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 webtoepassingsprogrammering zoals ondersteund door IIS en ASP.NET. De bedrijfs- of back-endlaag bevat een werkrol. Dit is een Cloud Services-onderdeel dat wordt uitgevoerd in de Azure-uitvoeringsomgeving. De laag is handig voor ge generaliseerde ontwikkeling en kan achtergrondverwerking voor een webrol uitvoeren. De databaselaag bevindt zich in een SQL Server virtuele 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 verplaatsen van gevirtualiseerde on-premises platforms naar Azure door SQL Server mogelijkheden voor hoge beschikbaarheid en herstel na noodgevallen te implementeren.
  • U wilt eigenaar zijn van een infrastructuuromgeving die op aanvraag omhoog en omlaag kan worden geschaald.
  • Azure SQL Database ondersteunt niet alle functies die uw toepassing of database nodig heeft.
  • U wilt stresstests uitvoeren voor verschillende workloadniveaus, maar tegelijkertijd wilt u niet de hele tijd eigenaar zijn van veel fysieke machines en deze onderhouden.

In het volgende diagram worden een on-premises scenario en de cloudoplossing gedemonstreerd. In dit scenario zet u de presentatielaag in webrollen, de bedrijfslaag in werkrollen, maar in de gegevenslaag in virtuele machines in Azure. Het uitvoeren van meerdere kopieën van de presentatielaag in verschillende webrollen zorgt ervoor dat aanvragen over de verschillende rollen worden verdeeld. Wanneer u uw Azure Cloud Services met Azure Virtual Machines, raden we u aan om ook Azure-Virtual Network in te stellen. Met Azure Virtual Networkkunt u stabiele en permanente privé-IP-adressen binnen dezelfde cloudservice in de cloud hebben. Zodra u een virtueel netwerk voor uw virtuele machines en cloudservices definieert, kunnen ze onderling communiceren via het privé-IP-adres. Bovendien biedt het hebben van virtuele machines en Azure-web-/werkrollen in dezelfde Azure-Virtual Network lage latentie en veiligere connectiviteit. Zie Wat is een cloudservice voor meer informatie.

Zoals u in het diagram kunt zien, Azure Load Balancer verkeer over meerdere virtuele machines en wordt ook bepaald met welke webserver of toepassingsserver verbinding moet worden gemaakt. Meerdere exemplaren van de web- en toepassingsservers achter een load balancer zorgt voor hoge beschikbaarheid van de presentatielaag en de bedrijfslaag. Zie Best practices for application patterns requiring SQL HADR (Best practices voor toepassingspatronen waarvoor SQL HADR) voor meer informatie.

Diagram met on-premises fysieke of virtuele machines die zijn verbonden met webrol-exemplaren in een virtueel Azure-netwerk via een Azure-load balancer.

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 een logica te implementeren voor het opslaan van de sessietoestand met behulp van een van de volgende technologieën: Azure Caching, Azure Table Storage of Azure SQL Database.

Diagram met on-premises fysieke of virtuele machines die zijn verbonden met geconsolideerde web-/werkrol-exemplaren in een virtueel Azure-netwerk.

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

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

In dit toepassingspatroon implementeert u een databasetoepassing in Azure door de presentatie- en bedrijfslagen op dezelfde virtuele machine te plaatsen en toegang te krijgen tot een database op 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 die is 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 perioden.
  • Uw bedrijfslogica en gegevenstoegangsonderdelen kunnen op zichzelf staan in een webtoepassing.

In het volgende diagram worden een on-premises scenario en de cloudoplossing gedemonstreerd. In dit scenario plaats u de toepassingslagen op één virtuele machine in Azure en krijgt u toegang tot gegevens in Azure SQL Database.

Gemengd toepassingspatroon

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

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

Patroon hybride toepassing met meerdere lagen

In een hybride toepassingspatroon met meerdere lagen 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 een specifieke laag kunt toevoegen zonder de andere lagen te wijzigen. Als u uw bedrijfsnetwerk wilt uitbreiden naar de cloud, gebruikt u Azure Virtual Network service.

Dit patroon voor hybride toepassingen is handig wanneer:

  • U wilt toepassingen bouwen die deels in de cloud en deels 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 perioden.
  • U wilt een rendabele manier om back-ups te maken voor bedrijfsdatabasetoepassingen.

In het volgende diagram wordt een hybride toepassingspatroon met n-aantal lagen gedemonstreerd dat on-premises en Azure omvat. Zoals u in het diagram kunt zien, bevat de on-premises infrastructuur Active Directory Domain Services domeincontroller ter ondersteuning van gebruikersverificatie en autorisatie. In het diagram wordt een scenario gedemonstreerd, waarbij sommige delen van de gegevenslaag zich in een on-premises datacentrum in een on-premises datacentrum leven, terwijl sommige delen van de gegevenslaag in Azure aanwezig zijn. 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 houden, maar de gegevenslaag in Azure.

Patroon N-tier-toepassing

In Azure kunt u Active Directory gebruiken als een zelfstandige clouddirectory voor uw organisatie, of u kunt bestaande on-premises Active Directory integreren met Azure Active Directory. Zoals u in het diagram kunt zien, hebben de onderdelen van de bedrijfslaag toegang tot meerdere gegevensbronnen, zoals SQL Server in Azure via een intern privé-IP-adres, tot on-premises SQL Server via Azure Virtual Network oftot SQL Database met behulp van de .NET Framework-technologieën voor gegevensproviders. In dit diagram is Azure SQL Database een optionele gegevensopslagservice.

In een hybride toepassingspatroon met meerdere lagen kunt u de volgende werkstroom implementeren in de opgegeven volgorde:

  1. Identificeer bedrijfsdatabasetoepassingen die naar de cloud moeten worden verplaatst met behulp van de Microsoft Assessment and Planning -Toolkit. De MAP Toolkit verzamelt inventaris- en prestatiegegevens van computers die u overweegt voor virtualisatie en doet 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 Azure Virtual Network. Als u de verbinding tussen het bedrijfsnetwerk on-premises en een virtuele machine in Azure wilt instellen, gebruikt u een van de volgende twee methoden:

    1. Een verbinding tot stand brengen 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 in uw virtuele machine te gebruiken. Stel daarnaast de regels voor uw netwerkbeveiligingsgroep in om openbaar verkeer naar de VM te controleren. Zie Externe toegang tot uw VM toestaanmet behulp van de Azure Portal.

    2. Een verbinding tot stand brengen tussen on-premises en Azure via een 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 deze Windows in uw virtuele machine. Momenteel ondersteunt 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. Dit wordt meestal aanbevolen voor ontwikkelings- en testdoeleinden.

      Zie Verbinding maken met een virtuele machine SQL Server Azure voor Verbinding maken van een virtuele machine SQL Server 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 Back-up en herstellen SQL Server Azure Blob Storage-service en Back-upen herstellen voor SQL Server in Azure Virtual Machines voor meer informatie.

  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 ongevoelige gegevens bewaren in een databaseserver in Azure, terwijl u de gevoelige gegevens on-premises houdt.
    2. U kunt uw webserver en toepassingsserver on-premises houden, terwijl de databaseserver zich op een virtuele machine in Azure.
    3. U kunt uw databaseserver, webserver en toepassingsserver on-premises houden terwijl u de databasereplica's op virtuele machines in Azure houdt. 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. U wordt aangeraden dit scenario te implementeren voor zware leesworkloads en ontwikkelingsdoeleinden. Zie voor meer informatie over het maken van databasereplica's in Azure AlwaysOn-beschikbaarheidsgroepen hoge beschikbaarheid en herstel na noodherstel voor SQL Server op Azure Virtual Machines.

Strategieën voor webontwikkeling vergelijken in Azure

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

  • Stel een traditionele webserver (IIS - Internet Information Services) in Azure in en krijg toegang tot databases in SQL Server azure Virtual Machines.
  • Implementeer en implementeer een cloudservice in Azure. Zorg er vervolgens voor dat deze cloudservice toegang heeft tot databases in SQL Server 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 in 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 Azure Virtual Machines Cloudservices in Azure Webhosting met Azure Web Apps
Toepassingsmigratie van on-premises Bestaande toepassingen zoals ze zijn. Toepassingen hebben web- en werkrollen nodig. Bestaande toepassingen zijn as-is, 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 promovert. Visual Studio, WebMatrix, Visual Web Developer, FTP, GIT, BitBucket, CodePlex, DropBox, GitHub, Mercurial, TFS, Web Deploy, PowerShell.
Beheer en installatie U bent verantwoordelijk voor beheertaken voor de toepassing, gegevens, firewallregels, virtuele netwerken en het besturingssysteem. U bent verantwoordelijk voor beheertaken voor de toepassing, gegevens, firewallregels en het virtuele netwerk. U bent alleen verantwoordelijk voor beheertaken voor de toepassing en gegevens.
Hoge beschikbaarheid en herstel na noodherstel (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 maakt het behouden van uw VM's in dezelfde cloudservice taakverdeling mogelijk en kunnen VM's rechtstreeks met elkaar communiceren via het lokale netwerk in een Azure-datacenter.

U bent verantwoordelijk voor het implementeren van een oplossing voor hoge beschikbaarheid en herstel na nood SQL Server azure-Virtual Machines downtime te voorkomen. Zie Hoge beschikbaarheid en herstel na noodherstel voor SQL Server op Azure Virtual Machines voor ondersteunde HADR-Virtual Machines.

U bent verantwoordelijk voor het maken van back-up van uw eigen gegevens en toepassing.

Azure kan uw virtuele machines verplaatsen als de hostmachine in het datacenter uitvalt vanwege hardwareproblemen. Bovendien kan er geplande downtime van uw VM zijn wanneer de hostmachine wordt bijgewerkt voor beveiligings- 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 back-up van uw eigen gegevens en toepassing.

Voor databases die zich in een SQL Server-database in een Azure-VM, bent u verantwoordelijk voor het implementeren van een oplossing voor hoge beschikbaarheid en herstel na noodherstel om downtime te voorkomen. Zie High Availability and Disaster Recovery for SQL Server on Azure Virtual Machines (Hoge beschikbaarheid en herstel na noodherstel voor hdar-technologieën) voor ondersteunde HDAR-Virtual Machines.

SQL Server databasespiegeling: gebruiken met Azure Cloud Services (web-/werkrollen). SQL Server VM's en een cloudserviceproject kunnen zich in dezelfde Azure-Virtual Network. Als SQL Server VM zich niet in dezelfde Virtual Network, moet u een SQL Server Alias maken om communicatie naar het exemplaar van de virtuele SQL Server. Bovendien moet de aliasnaam overeenkomen met de SQL Server naam.		 Hoge beschikbaarheid wordt overgenomen van Azure-werkrollen, Azure Blob Storage en Azure SQL Database. Zo onderhoudt Azure Storage drie replica's van alle blob-, tabel- en wachtrijgegevens. Op elk moment houdt Azure SQL Database drie replica's van gegevens actief: één primaire replica en twee secundaire replica's. Zie voor meer informatie Azure Storage en Azure SQL Database.

Wanneer u SQL Server in een Azure-VM als gegevensbron voor Azure Web Apps gebruikt, 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 gaan. Dit kan enkele beperkingen veroorzaken voor scenario's met hoge beschikbaarheid en herstel na nood gevallen. De clienttoepassing op 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 azure Virtual Network moet worden ingesteld tussen SQL Server-host-VM's in Azure. Daarom wordt het SQL Server databasespiegeling met Azure Web Apps momenteel niet ondersteund.

SQL Server AlwaysOn-beschikbaarheidsgroepen: u kunt een AlwaysOn-beschikbaarheidsgroepen instellen bij het gebruik van Azure Web Apps met SQL Server-VM's in Azure. Maar u moet de AlwaysOn-beschikbaarheidsgroeplistener configureren om de communicatie naar de primaire replica via openbare eindpunten met taakverde taakverde ning te laten lopen.
Cross-premises-connectiviteit U kunt Azure Virtual Network om verbinding te maken met on-premises. U kunt Azure Virtual Network om verbinding te maken met on-premises. Azure Virtual Network wordt ondersteund. Zie integratie Web Apps Virtual Network voor meer informatie.
Schaalbaarheid U kunt omhoog schalen door de grootte van de virtuele machine te vergroten of meer schijven toe te voegen. Zie Grootten van virtuele machines voor Azure voor meer informatie over de grootten van virtuele machines.

Voor databaseserver: uitschalen is beschikbaar via databasepartitietechnieken en SQL Server AlwaysOn-beschikbaarheidsgroepen.

Voor zware leesworkloads kunt u AlwaysOn-beschikbaarheidsgroepen op meerdere secundaire knooppunten gebruiken, evenals SQL Server replicatie.

Voor zware schrijfworkloads kunt u horizontale partitionering van gegevens op meerdere fysieke servers implementeren om uitschaling van toepassingen mogelijk te maken.

Bovendien kunt u uitschalen met behulp van SQL Server met gegevensafhankelijke routering. Met Gegevensafhankelijke routering (DDR) moet u het partitioneringsmechanisme implementeren in de clienttoepassing, meestal in de laag bedrijfslaag, om de databaseaanvragen te routeren naar meerdere SQL Server knooppunten. De bedrijfslaag bevat toewijzingen aan de manier waarop de gegevens worden gepartitiefd en welk knooppunt de gegevens bevat.

U kunt toepassingen schalen die virtuele machines uitvoeren. Zie How to Scale an Application (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 verlagen. Deze functie garandeert dat de eindgebruikerservaring niet negatief wordt beïnvloed tijdens piekperioden en dat 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 de virtuele SQL Server bevat. De reden hiervoor is dat Azure met de functie Automatisch schalen een virtuele machine kan in schakelen wanneer het CPU-gebruik in die VM hoger is dan een bepaalde drempelwaarde, en een virtuele machine kan uitschakelen wanneer het CPU-gebruik lager is dan deze. De functie Automatisch schalen is handig voor staatloze toepassingen, zoals webservers, waarbij elke VM de workload kan beheren zonder verwijzingen naar een eerdere status. De functie Automatisch schalen is echter niet nuttig 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 Groottes configureren voor Cloud Services voor meer informatie over de grootte van virtuele machines voor webrollen en werkrollen.

Wanneer u Cloud Services, kunt u meerdere rollen definiëren om de verwerking te distribueren en ook flexibele schaalbaarheid van uw toepassing te bereiken. Elke cloudservice bevat een of meer webrollen en/of werkrollen, elk met eigen toepassingsbestanden en configuratie. U kunt een cloudservice omhoog schalen door het aantal rol-exemplaren (virtuele machines) te verhogen dat voor een rol is geïmplementeerd en een cloudservice omlaag te schalen door het aantal rol-exemplaren te verlagen. Zie Azure Execution Models (Azure-uitvoeringsmodellen) 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 in een Azure-datacenter.

U kunt automatisch schalen instellen op de Azure Portal en de planningstijden. Zie Automatisch schalen configureren voor een cloudservice in de portal voor meer informatie.		 Omhoog en omlaag schalen: u kunt de grootte vergroten/verlagen van de instantie (VM) die is gereserveerd voor uw website.

Uitschalen: u kunt meer gereserveerde instanties (VM's) toevoegen voor uw website.

U kunt automatisch schalen instellen in de portal en op de planningstijden. Zie Voor meer informatie How to Scale Web Apps.

Zie Azure Web Apps, Cloud Services en VM's:wanneer u gebruikt voor meer informatie over het kiezen tussen deze programmeermethoden.

Volgende stappen

Zie Overzicht van SQL Server Azure SQL Server voor Virtual Machines meer informatie over het uitvoeren van Virtual Machines in Azure.