Deze referentiearchitectuur laat zien hoe u virtuele machines (VM's) en een virtueel netwerk implementeert dat is geconfigureerd voor een N-tier-toepassing, met behulp van SQL Server in Windows voor de gegevenslaag.
Architectuur
Een Visio-bestand van deze architectuur downloaden.
Werkstroom
De architectuur heeft de volgende onderdelen:
Algemeen
Resourcegroep. Resourcegroepen worden gebruikt om Azure-resources te groeperen, zodat ze kunnen worden beheerd op basis van levensduur, eigenaar of andere criteria.
Beschikbaarheidszones. Beschikbaarheidszones zijn fysieke locaties binnen een Azure-regio. Elke zone bestaat uit een of meer datacenters met onafhankelijke voeding, koeling en netwerken. Door VM's in zones te plaatsen, wordt de toepassing bestand tegen fouten binnen een zone.
Netwerken en taakverdeling
Virtueel netwerk en subnetten. Elke Virtuele Azure-machine wordt geïmplementeerd in een virtueel netwerk dat kan worden gesegmenteerd in subnetten. Maak een apart subnet voor elke laag.
Toepassingsgateway. Application Gateway is een load balancer op laag 7. In deze architectuur worden HTTP-aanvragen gerouteerd naar de webfront-end. Application Gateway biedt ook een Web Application Firewall (WAF) die de toepassing beschermt tegen veelvoorkomende aanvallen en beveiligingsproblemen.
Load balancers. Gebruik Azure Standard Load Balancer om netwerkverkeer te distribueren van de weblaag naar de bedrijfslaag en van de bedrijfslaag naar SQL Server.
Netwerkbeveiligingsgroepen (NSG's). Gebruik NSG's om netwerkverkeer binnen het virtuele netwerk te beperken. In de architectuur met drie lagen die hier wordt weergegeven, accepteert de databaselaag bijvoorbeeld geen verkeer van de webfront-end, alleen van de bedrijfslaag en het beheersubnet.
DDoS-beveiliging. Hoewel het Azure-platform basisbeveiliging biedt tegen DDoS-aanvallen (Distributed Denial of Service), raden we u aan Azure DDoS Network Protection te gebruiken, dat verbeterde DDoS-risicobeperkingsfuncties heeft. Zie Beveiligingsoverwegingen.
Azure DNS. Azure DNS is een hostingservice voor DNS-domeinen. Het biedt naamomzetting met behulp van de Microsoft Azure-infrastructuur. Door uw domeinen in Azure te hosten, kunt u uw DNS-records met dezelfde referenties, API's, hulpprogramma's en facturering beheren als voor uw andere Azure-services.
Virtuele machines
SQL Server AlwaysOn-beschikbaarheidsgroep. Biedt hoge beschikbaarheid in de gegevenslaag door replicatie en failover in te schakelen. Het maakt gebruik van WSFC-technologie (Windows Server Failover Cluster) voor failover.
AD DS-servers (Active Directory Domain Services). De computerobjecten voor het failovercluster en de bijbehorende geclusterde rollen worden gemaakt in Active Directory Domain Services (AD DS).
Cloudwitness. Voor een failovercluster moet meer dan de helft van de knooppunten worden uitgevoerd. Dit staat bekend als quorum. Als het cluster slechts twee knooppunten heeft, kan een netwerkpartitie ervoor zorgen dat elk knooppunt denkt dat het het primaire knooppunt is. In dat geval hebt u een getuige nodig om de banden te verbreken en het quorum vast te stellen. Een witness is een resource zoals een gedeelde schijf die kan fungeren als een tie-breaker om het quorum tot stand te brengen. Cloudwitness is een type witness dat gebruikmaakt van Azure Blob Storage. Zie Inzicht in cluster- en poolquorum voor meer informatie over het concept quorum. Zie Een cloudwitness implementeren voor een failovercluster voor meer informatie over cloudwitness.
Jumpbox. Wordt ook wel een bastionhost genoemd. Traditioneel is dit een beveiligde VM in het netwerk die beheerders gebruiken om verbinding te maken met de andere VM's. De jumpbox heeft een netwerkbeveiligingsgroep die alleen extern verkeer vanaf openbare IP-adressen op een lijst met veilige adressen toelaat. De NSG moet RDP-verkeer (Remote Desktop Protocol) toestaan. Azure biedt de beheerde oplossing Azure Bastion om aan deze behoefte te voldoen.
Aanbevelingen
Uw vereisten kunnen afwijken van de architectuur die hier wordt beschreven. Gebruik deze aanbevelingen als uitgangspunt.
Virtuele machines
Zie Een Virtuele Windows-machine uitvoeren in Azure voor aanbevelingen over het configureren van de VM's.
Virtueel netwerk
Wanneer u het virtuele netwerk maakt, bepaalt u hoeveel IP-adressen uw resources in elk subnet nodig hebben. Geef een subnetmasker en een netwerkadresbereik op dat groot genoeg is voor de vereiste IP-adressen, met behulp van CIDR-notatie . Gebruik een adresruimte die valt binnen de standaard privé-IP-adresblokken, te weten 10.0.0.0/8, 172.16.0.0/12 en 192.168.0.0/16.
Kies een adresbereik dat niet overlapt met uw on-premises netwerk, voor het geval u later een gateway tussen het virtuele netwerk en uw on-premises netwerk moet instellen. Nadat u het virtuele netwerk hebt gemaakt, kunt u het adresbereik niet meer wijzigen.
Houd rekening met de vereisten voor functionaliteit en beveiliging wanneer u subnetten ontwerpt. Alle VM's binnen dezelfde laag of rol moeten worden geplaatst in hetzelfde subnet dat een beveiligingsgrens kan vormen. Zie Azure Virtual Networks plannen en ontwerpen voor meer informatie over het ontwerpen van virtuele netwerken en subnetten.
Application Gateway
Zie overzicht van Application Gateway configuratie voor meer informatie over het configureren van Application Gateway.
Load balancers
Maak de VM's niet rechtstreeks beschikbaar op internet, maar geef in plaats daarvan elke VM een privé-IP-adres. Clients maken verbinding met behulp van het openbare IP-adres dat is gekoppeld aan de Application Gateway.
Definieer load balancer-regels om netwerkverkeer door te sturen naar de virtuele machines. Als u bijvoorbeeld HTTP-verkeer wilt inschakelen, wijst u poort 80 van de front-endconfiguratie toe aan poort 80 in de back-endadresgroep. Wanneer een client een HTTP-aanvraag naar poort 80 verzendt, selecteert de load balancer een back-end-IP-adres met behulp van een hash-algoritme met het IP-adres van de bron. Clientaanvragen worden verdeeld over alle VM's in de back-endadresgroep.
Netwerkbeveiligingsgroepen
Gebruik NSG-regels om het verkeer tussen lagen te beperken. In de architectuur met drie lagen die hierboven wordt weergegeven, communiceert de weblaag niet rechtstreeks met de databaselaag. Als u deze regel wilt afdwingen, moet de databaselaag binnenkomend verkeer van het subnet van de weblaag blokkeren.
- Al het binnenkomende verkeer van het virtuele netwerk weigeren. (Gebruik de tag
VIRTUAL_NETWORKin de regel.) - Inkomend verkeer van het subnet van de bedrijfslaag toestaan.
- Inkomend verkeer van het subnet van de databaselaag zelf toestaan. Deze regel staat communicatie tussen de database-VM's toe, wat nodig is voor databasereplicatie en failover.
- RDP-verkeer (poort 3389) toestaan vanaf het jumpbox-subnet. Deze regel zorgt ervoor dat beheerders vanuit de jumpbox verbinding kunnen maken met de databaselaag.
Maak regels 2 tot en met 4 met een hogere prioriteit dan de eerste regel, zodat deze wordt overschreven.
AlwaysOn-beschikbaarheidsgroepen in SQL Server
Voor een hoge beschikbaarheid van SQL Server worden AlwaysOn-beschikbaarheidgroepen aangeraden. Vóór Windows Server 2016 vereisten AlwaysOn-beschikbaarheidsgroepen een domeincontroller en moesten alle knooppunten in de beschikbaarheidsgroep zich in hetzelfde AD-domein bevinden.
Andere lagen maken verbinding met de database via een listener voor de beschikbaarheidsgroep. De listener maakt het mogelijk dat een SQL-client verbinding maakt zonder de naam van het fysieke exemplaar van SQL Server te kennen. Virtuele machines die toegang hebben tot de database, moeten worden toegevoegd aan het domein. De client (in dit geval een andere laag) gebruikt DNS om de naam van het virtuele netwerk van de listener om te zetten in IP-adressen.
U configureert de AlwaysOn-beschikbaarheidsgroep in SQL Server als volgt:
Maak een WSFC-cluster (Windows Server Failover Clustering), een AlwaysOn-beschikbaarheidsgroep in SQL Server en een primaire replica. Zie Aan de slag met AlwaysOn-beschikbaarheidsgroepen voor meer informatie.
Maak een interne load balancer met een statisch privé-IP-adres.
Maak een listener voor de beschikbaarheidsgroep en wijs de DNS-naam van de listener toe aan het IP-adres van een interne load balancer.
Maak een load balancer-regel voor de SQL Server-controlepoort (standaard TCP-poort 1433). De load balancer-regel moet zwevende IP-adressen, ook wel Direct Server Return, inschakelen. Dit zorgt ervoor dat de VM rechtstreeks antwoordt naar de client, waardoor een directe verbinding met de primaire replica mogelijk is.
Notitie
Als zwevende IP-adressen zijn ingeschakeld, moet het front-end poortnummer hetzelfde zijn als het back-end poortnummer in de load balancer-regel.
Wanneer een SQL-client verbinding probeert te maken, stuurt de load balancer de verbindingsaanvraag door naar de primaire replica. Als er een failover naar een andere replica is, stuurt de load balancer nieuwe aanvragen automatisch door naar een nieuwe primaire replica. Zie Een ILB-listener voor AlwaysOn-beschikbaarheidsgroepen in SQL Server configureren voor meer informatie.
Tijdens een failover worden bestaande clientverbindingen gesloten. Nadat de failover is voltooid, worden nieuwe verbindingen doorgestuurd naar de nieuwe primaire replica.
Als uw toepassing veel meer leesbewerkingen dan schrijfbewerkingen uitvoert, kunt u enkele van de alleen-lezen query's offloaden naar een secundaire replica. Zie Een listener gebruiken om verbinding te maken met een secundaire alleen-lezen replica (alleen-lezen routering).
Test uw implementatie door een handmatige failover van de beschikbaarheidsgroep te forceren.
Jumpbox
Wanneer u virtuele machines uitvoert in een particulier virtueel netwerk, zoals in deze architectuur, is er behoefte aan toegang tot virtuele machines voor software-installatie, patching, enzovoort. Maar het is geen goed idee om deze machines toegankelijk te maken voor het openbare internet, omdat het de kwetsbaarheid voor aanvallen aanzienlijk vergroot. In plaats daarvan wordt een jumpbox gebruikt als een middelste toegangslaag.
In het verleden kon een VM die door de klant wordt beheerd, worden gebruikt als een jumpbox. In dat scenario zijn de volgende aanbevelingen van toepassing:
- Sta geen RDP-toegang vanaf het openbare internet toe tot de VM's waarop de toepassingsworkload wordt uitgevoerd. In plaats daarvan moet alle RDP-toegang tot deze VM's via de jumpbox verlopen. Een beheerder meldt zich aan bij de jumpbox en meldt zich vervolgens vanuit de jumpbox aan bij de andere virtuele machine. De jumpbox staat RDP-verkeer toe van internet, maar alleen van bekende, veilige IP-adressen.
- De jumpbox heeft minimale prestatievereisten, dus selecteer een kleine VM-grootte. Maak een openbaar IP-adres voor de jumpbox. Plaats de jumpbox in hetzelfde virtuele netwerk als de andere VM's, maar in een afzonderlijk beheersubnet.
- Als u de jumpbox wilt beveiligen, voegt u een NSG-regel toe die RDP-verbindingen alleen toestaat vanuit een veilige set openbare IP-adressen. Configureer de NSG's voor de andere subnetten zodanig dat RDP-verkeer van het beheersubnet is toegestaan.
Voor een door de klant beheerde VM zijn al deze regels van toepassing. De huidige aanbeveling is echter om Azure Bastion te gebruiken, een beheerde jumpbox-oplossing die HTML5-toegang tot RDP of SSH mogelijk maakt achter Azure AD beveiliging. Dit is een veel eenvoudigere oplossing die uiteindelijk een lagere TCO (Total Cost of Ownership) voor de klant heeft.
Overwegingen
Schaalbaarheid
Schaalsets
Voor de web- en bedrijfslaag kunt u overwegen om Virtual Machine Scale Sets te gebruiken in plaats van afzonderlijke VM's te implementeren. Met een schaalset kunt u eenvoudig een set identieke VM's implementeren en beheren en de VM's automatisch schalen op basis van metrische prestatiegegevens. Als de belasting op de virtuele machines toeneemt, worden er automatisch extra virtuele machines toegevoegd aan de load balancer. Overweeg schaalsets te gebruiken als u virtuele machines snel wilt uitschalen, of automatisch wilt schalen.
Er zijn twee basismethoden voor het configureren van virtuele machines die worden geïmplementeerd in een schaalset:
Gebruik extensies om de VM te configureren nadat deze is geïmplementeerd. Bij deze methode duurt het opstarten van nieuwe VM-exemplaren langer dan bij een VM zonder extensies.
Een beheerde schijf met een aangepaste installatiekopie implementeren. Het implementeren gaat waarschijnlijk sneller bij deze methode. U moet de installatiekopieën echter up-to-date houden.
Zie Ontwerpoverwegingen voor schaalsets voor meer informatie.
Tip
Wanneer u een oplossing voor automatisch schalen gebruikt, moet u deze ruim van tevoren testen met werkbelastingen op productieniveau.
Abonnementslimieten
Voor elk Azure-abonnement gelden standaardlimieten, inclusief een maximum aantal virtuele machines per regio. U kunt de limiet verhogen door een ondersteuningsaanvraag daartoe in te dienen. Zie Limieten, quota en beperkingen voor Azure-abonnementen en -services voor meer informatie.
Application Gateway
Application Gateway ondersteunt de modus met vaste capaciteit of de modus voor automatisch schalen. De modus Vaste capaciteit is handig voor scenario's met consistente en voorspelbare workloads. Overweeg het gebruik van de modus voor automatisch schalen voor workloads met variabel verkeer. Zie Automatisch schalen en zone-redundante Application Gateway v2 voor meer informatie
Beschikbaarheid
Beschikbaarheidszones bieden de beste tolerantie binnen één regio. Als u nog hogere beschikbaarheid nodig hebt, kunt u overwegen om de toepassing te repliceren in twee regio's, met behulp van Azure Traffic Manager voor failover. Zie Multi-region N-tier application for high availability (Multi-region N-tier application for high availability) voor meer informatie.
Niet alle regio's ondersteunen beschikbaarheidszones en niet alle VM-grootten worden in alle zones ondersteund. Voer de volgende Azure CLI-opdracht uit om de ondersteunde zones te vinden voor elke VM-grootte binnen een regio:
az vm list-skus --resource-type virtualMachines --zone false --location <location> \
--query "[].{Name:name, Zones:locationInfo[].zones[] | join(','@)}" -o table
Als u deze architectuur implementeert in een regio die geen ondersteuning biedt voor beschikbaarheidszones, plaatst u de VM's voor elke laag in een beschikbaarheidsset. VM's binnen dezelfde beschikbaarheidsset worden geïmplementeerd op meerdere fysieke servers, rekenrekken, opslageenheden en netwerkswitches voor redundantie. Schaalsets maken automatisch gebruik van plaatsingsgroepen, die fungeren als een impliciete beschikbaarheidsset.
Gebruik bij het implementeren in beschikbaarheidszones de Standard-SKU van Azure Load Balancer en de v2-SKU van Application Gateway. Deze SKU's bieden ondersteuning voor redundantie tussen zones. Zie voor meer informatie:
- Load Balancer van het type Standard en beschikbaarheidszones
- Automatisch schalen en zone-redundantie in Application Gateway v2
- Hoe biedt Application Gateway ondersteuning voor hoge beschikbaarheid en schaalbaarheid?
Eén Application Gateway implementatie kan meerdere exemplaren van de gateway uitvoeren. Voer voor productieworkloads ten minste twee exemplaren uit.
Statuscontroles
Application Gateway en Load Balancer gebruiken beide statustests om de beschikbaarheid van VM-exemplaren te bewaken.
- Application Gateway gebruikt altijd een HTTP-test.
- Load Balancer kunt HTTP of TCP testen. Als een VIRTUELE machine een HTTP-server uitvoert, gebruikt u over het algemeen een HTTP-test. Gebruik anders TCP.
Als een test een exemplaar niet binnen een time-outperiode kan bereiken, stopt de gateway of load balancer met het verzenden van verkeer naar die VM. De test blijft controleren en retourneert de VM naar de back-endpool als de VM weer beschikbaar is.
HTTP-tests verzenden een HTTP GET-aanvraag naar een opgegeven pad en luisteren naar een HTTP 200-antwoord. Dit pad kan het hoofdpad ('/') zijn of een statuscontrole-eindpunt dat aangepaste logica implementeert om de status van de toepassing te controleren. Voor het eindpunt moeten anonieme HTTP-aanvragen worden toegestaan.
Zie voor meer informatie over statustests:
Zie Statuseindpuntcontrolepatroon voor overwegingen over het ontwerpen van een statustesteindpunt.
Kostenoptimalisatie
Gebruik de Azure-prijscalculator om de kosten te schatten. Hier volgen enkele andere overwegingen.
Virtuele-machineschaalsets
Virtuele-machineschaalsets zijn beschikbaar op alle Vm-grootten van Windows. Er worden alleen kosten in rekening gebracht voor de Azure-VM's die u implementeert en eventuele aanvullende onderliggende infrastructuurresources die worden verbruikt, zoals opslag en netwerken. Er zijn geen incrementele kosten voor de Virtual Machine Scale Sets-service.
Zie Prijzen voor virtuele Windows-machines voor prijsopties voor individuele VM's
SQL Server
Als u Azure SQL DBaas kiest, kunt u kosten besparen omdat u geen AlwaysOn-beschikbaarheidsgroep en domeincontrollercomputers hoeft te configureren. Er zijn verschillende implementatieopties, te beginnen van één database tot een beheerd exemplaar of elastische pools. Zie prijzen voor Azure SQL voor meer informatie.
Zie Prijzen voor SQL-VM's voor prijsopties voor SQL Server-VM's.
Load balancers
Er worden alleen kosten in rekening gebracht voor het aantal geconfigureerde taakverdelings- en uitgaande regels. Binnenkomende NAT-regels zijn gratis. Er worden geen kosten per uur in rekening gebracht voor de Standard Load Balancer wanneer er geen regels zijn geconfigureerd.
Raadpleeg de kostensectie in Microsoft Azure Well-Architected Framework voor meer informatie.
Beveiliging
Virtuele netwerken zijn een verkeersisolatiegrens in Azure. Standaard kunnen VM's in één virtueel netwerk niet rechtstreeks communiceren met VM's in een ander virtueel netwerk. U kunt virtuele netwerken echter expliciet verbinden met behulp van peering voor virtuele netwerken.
NSG's. Gebruik netwerkbeveiligingsgroepen (NSG's) om verkeer van en naar internet te beperken. Zie voor meer informatie Microsoft-cloudservices en -netwerkbeveiliging.
DMZ. Overweeg een virtueel netwerkapparaat (NVA) toe te voegen om een perimeternetwerk (DMZ) te maken tussen internet en het virtuele Azure-netwerk. NVA is een algemene term voor een virtueel apparaat dat netwerkgerelateerde taken kan uitvoeren, zoals een firewall, pakketinspectie, controle en aangepaste routering. Zie Een DMZ tussen Azure en internet implementeren voor meer informatie.
Versleuteling. Versleutel gevoelige data-at-rest en gebruik Azure Key Vault om de versleutelingssleutels voor de database te beheren. Key Vault kan versleutelingssleutels opslaan in hardwarebeveiligingsmodules (HSM's). Zie voor meer informatie Integratie van Azure Sleutelkluis configureren voor SQL Server op Azure-VM's. Het wordt ook aanbevolen om toepassingsgeheimen, zoals databaseverbindingsreeksen, op te slaan in Key Vault.
DDoS-beveiliging. Het Azure-platform biedt standaard DDoS-basisbeveiliging. Deze basisbeveiliging is gericht op het beveiligen van de Azure-infrastructuur als geheel. Hoewel DDoS-basisbeveiliging automatisch is ingeschakeld, raden we u aan Azure DDoS Network Protection te gebruiken. Netwerkbeveiliging maakt gebruik van adaptieve afstemming, op basis van de netwerkverkeerspatronen van uw toepassing, om bedreigingen te detecteren. Hierdoor kunnen oplossingen worden toegepast tegen DDoS-aanvallen die mogelijk onopgemerkt blijven door het DDoS-beleid voor de hele infrastructuur. Netwerkbeveiliging biedt ook waarschuwingen, telemetrie en analyse via Azure Monitor. Zie Azure DDoS Protection: Best practices en referentiearchitecturen voor meer informatie.
Operationele uitmuntendheid
Omdat alle hoofdresources en hun afhankelijkheden zich in hetzelfde virtuele netwerk in deze architectuur bevinden, worden ze geïsoleerd in dezelfde basisworkload. Dit maakt het eenvoudiger om de specifieke resources van de workload aan een team te koppelen, zodat het team alle aspecten van deze resources onafhankelijk kan beheren. Dankzij deze isolatie kan DevOps continue integratie en continue levering (CI/CD) uitvoeren.
U kunt ook verschillende implementatiesjablonen gebruiken en deze integreren met Azure DevOps Services om binnen enkele minuten verschillende omgevingen in te richten, bijvoorbeeld om productiescenario's zoals scenario's of belastingtestomgevingen alleen te repliceren wanneer dat nodig is, wat kosten bespaart.
In dit scenario worden uw virtuele machines geconfigureerd met behulp van Extensies voor virtuele machines, omdat ze de mogelijkheid bieden om bepaalde extra software te installeren, zoals antimalware en beveiligingsagenten. VM-extensies worden alleen geïnstalleerd en uitgevoerd tijdens het maken van de VM. Dit betekent dat als het besturingssysteem in een latere fase onjuist wordt geconfigureerd, een handmatige interventie nodig is om het weer naar de juiste status te verplaatsen.
Hulpprogramma's voor configuratiebeheer, met name Desired State Configuration (DSC), worden in deze architectuur gebruikt om Active Directory en een SQL Server AlwaysOn-beschikbaarheidsgroep te configureren.
Overweeg het gebruik van de Azure Monitor voor het analyseren en optimaliseren van de prestaties van uw infrastructuur, het bewaken en diagnosticeren van netwerkproblemen zonder u aan te melden bij uw virtuele machines. Application Insights is eigenlijk een van de onderdelen van Azure Monitor, waarmee u uitgebreide metrische gegevens en logboeken krijgt om de status van uw volledige Azure-landschap te controleren. Met Azure Monitor kunt u de status van uw infrastructuur volgen.
Zorg ervoor dat u niet alleen uw rekenelementen bewaakt die uw toepassingscode ondersteunen, maar ook uw gegevensplatform, met name uw databases, omdat een lage prestaties van de gegevenslaag van een toepassing ernstige gevolgen kan hebben.
Als u de Azure-omgeving wilt testen waarin de toepassingen worden uitgevoerd, moet deze worden beheerd en geïmplementeerd via dezelfde mechanismen als toepassingscode. Vervolgens kan deze worden getest en gevalideerd met behulp van DevOps-testparadigma's.
Zie de sectie Operational Excellence in Azure Well-Architected Framework voor meer informatie.