Windows N-tier-toepassing in Azure Stack Hub met SQL Server

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

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.

• Beschikbaarheidsset. Beschikbaarheidsset is een datacenterconfiguratie voor vm-redundantie en beschikbaarheid. Deze configuratie binnen een Azure Stack Hub-stempel zorgt ervoor dat er tijdens een geplande of ongeplande onderhoudsgebeurtenis ten minste één virtuele machine beschikbaar is. VM's worden geplaatst in een beschikbaarheidsset die ze verspreidt over meerdere foutdomeinen (Azure Stack Hub-hosts)

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.

• Laag 7 Load Balancer. Omdat Application Gateway nog niet beschikbaar is in Azure Stack Hub, zijn er alternatieven beschikbaar op Azure Stack Hub Marketplace, zoals KEMP LoadMaster Load Balancer ADC Content Switch/ f5 Big-IP Virtual Edition of A10 vThunder ADC

• Load balancers. Gebruik Azure 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.

• DNS. Azure Stack Hub biedt geen eigen DNS-hostingservice, dus gebruik de DNS-server in uw ADDS.

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). Het instellen van AD DS-servers in VM's in hetzelfde virtuele netwerk heeft de voorkeursmethode om andere VM's aan AD DS toe te voegen. U kunt de VM's ook toevoegen aan bestaande Enterprise AD DS door een virtueel netwerk te verbinden met een enterprise-netwerk met een VPN-verbinding. Bij beide benaderingen moet u de DNS van het virtuele netwerk wijzigen in uw AD DS DNS-server (in een virtueel netwerk of bestaand ondernemingsnetwerk) om de FQDN van het AD DS-domein om te lossen.

• Cloudwitness. Voor een failovercluster moet meer dan de helft van de knooppunten worden uitgevoerd. Dit wordt quorum genoemd. Als het cluster slechts twee knooppunten heeft, kan een netwerkpartitie ervoor zorgen dat elk knooppunt denkt dat het het besturingsvlakknooppunt 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. In Azure Stack Hub verschilt het cloudwitness-eindpunt van het globale Azure.

Dit kan er als volgt uitzien:

• Voor globale Azure:
  https://mywitness.blob.core.windows.net/

• Voor Azure Stack Hub:
  https://mywitness.blob.<region>.<FQDN>

• Jumpbox. Wordt ook wel een bastionhost genoemd. Een beveiligde VM in het netwerk die beheerders kunnen 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 netwerkbeveiligingsgroep zou RDP-verkeer (extern bureaublad) moeten toestaan.

Aanbevelingen

Uw vereisten kunnen afwijken van de architectuur die hier wordt beschreven. Gebruik deze aanbevelingen als uitgangspunt.

Virtuele machines

Zie Een Windows-VM uitvoeren op Azure Stack Hub 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.

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 Laag 7-Load Balancer.

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.

1. Al het binnenkomende verkeer van het virtuele netwerk weigeren. (Gebruik de tag VIRTUAL_NETWORK in de regel.)

2. Inkomend verkeer van het subnet van de bedrijfslaag toestaan.

3. 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.

4. 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 - 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.

Voor hoge beschikbaarheid op de VM-laag moeten alle SQL-VM's zich in een beschikbaarheidsset bevindt.

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:

1. 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.

2. Maak een interne load balancer met een statisch privé-IP-adres.

3. Maak een listener voor de beschikbaarheidsgroep en wijs de DNS-naam van de listener toe aan het IP-adres van een interne load balancer.

4. 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 meer leesbewerkingen dan schrijfbewerkingen maakt, kunt u enkele 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.

Voor optimalisatie van SQL-prestaties kunt u ook het artikel BEST practices voor SQL Server raadplegen om de prestaties in Azure Stack Hub te optimaliseren.

Jumpbox

RdP-toegang vanaf het openbare internet tot de VM's waarop de toepassingsworkload wordt uitgevoerd, is niet toegestaan. 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 aan bij de andere VM's vanuit de jumpbox. De jumpbox staat RDP-verkeer van internet toe, maar alleen vanaf 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.

Schaalbaarheidsoverwegingen

Schaalsets

Voor de web- en bedrijfslagen kunt u overwegen om virtuele-machineschaalsets te gebruiken in plaats van afzonderlijke VM's te implementeren. Met een schaalset kunt u eenvoudig een set identieke VM's implementeren en beheren. Overweeg schaalsets als u vm's snel wilt uitschalen.

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. Deze ontwerpoverweging geldt meestal voor Azure Stack Hub, maar er zijn enkele opmerkingen:

• Virtuele-machineschaalsets in Azure Stack Hub bieden geen ondersteuning voor overprovisioning of rolling upgrades.

• U kunt virtuele-machineschaalsets niet automatisch schalen in Azure Stack Hub.

• U wordt ten zeerste aangeraden beheerde schijven in Azure Stack Hub te gebruiken in plaats van niet-beheerde schijven voor virtuele-machineschaalsets

• Op dit moment is er een limiet van 700 VM's voor Azure Stack Hub, die geldt voor alle Azure Stack Hub-infrastructuur-VM's, afzonderlijke VM's en schaalsetexemplaren.

Abonnementslimieten

Elk Azure Stack Hub-tenantabonnement heeft standaardlimieten, waaronder een maximum aantal VM's per regio dat is geconfigureerd door de Azure Stack Hub-operator. Zie Azure Stack Hub services, plans, offers, subscriptions overview (Overzicht van Azure Stack Hub-services, -abonnementen) voor meer informatie. Raadpleeg ook Quotumtypen in Azure Stack Hub.

Beveiligingsoverwegingen

Virtuele netwerken zijn een verkeersisolatiegrens in Azure. Standaard kunnen VM's in het ene virtuele netwerk niet rechtstreeks communiceren met VM's in een ander virtueel netwerk.

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.

Versleuteling. Versleutel gevoelige data-at-rest en gebruik Key Vault in Azure Stack Hub om de databaseversleutelingssleutels te beheren. 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.

Volgende stappen

• Zie Cloudontwerppatronen voor meer informatie over Azure-cloudpatronen.