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

  • Artikel
  • 9 minuten om te lezen

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 op Windows voor de gegevenslaag.

Architectuur

De architectuur heeft de volgende onderdelen:

The diagram shows a virtual network comprising six subnets: Application Gateway, Management, Web tier, Business tier, Data tier, and Active Directory. The Data tier subnet uses Cloud Witness. There are three load balancers.

Algemeen

  • Resourcegroep. Resourcegroepen worden gebruikt om Azure-resources te groeperen, zodat ze kunnen worden beheerd door levensduur, eigenaar of andere criteria.

  • Beschikbaarheidsset. Beschikbaarheidsset is een datacenterconfiguratie om VM-redundantie en beschikbaarheid te bieden. 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 in een beschikbaarheidsset geplaatst die deze verspreidt over meerdere foutdomeinen (Azure Stack Hub-hosts)

Netwerken en taakverdeling

  • Virtueel netwerk en subnetten. Elke Azure-VM 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 de Markt van Azure Stack Hub, 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 van de weblaag te distribueren 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 vanuit 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. Er wordt gebruikgemaakt van Windows WSFC-technologie (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 op 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 koppelen aan bestaande Enterprise AD DS door een virtueel netwerk te verbinden met het Enterprise-netwerk met een VPN-verbinding. Met beide benaderingen moet u de DNS van het virtuele netwerk wijzigen in uw AD DS DNS-server (in virtueel netwerk of bestaand Enterprise-netwerk) om de FQDN van het AD DS-domein op te lossen.

  • Cloudwitness. Voor een failovercluster moeten meer dan de helft van de knooppunten worden uitgevoerd. Dit wordt ook wel quorum genoemd. Als het cluster slechts twee knooppunten heeft, kan een netwerkpartitie ertoe leiden dat elk knooppunt het knooppunt van het besturingsvlak is. In dat geval hebt u een getuige nodig om de banden te verbreken en quorum vast te stellen. Een witness is een resource zoals een gedeelde schijf die kan fungeren als een tie breaker om quorum vast te stellen. Cloudwitness is een type witness dat gebruikmaakt van Azure Blob Storage. Zie Cluster- en poolquorum begrijpen voor meer informatie over het concept van quorum. Zie Een cloudwitness implementeren voor een failovercluster voor meer informatie over Cloud Witness. In Azure Stack Hub verschilt het cloudwitness-eindpunt van azure.

Het 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 in Azure Stack Hub voor aanbevelingen voor 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 moet instellen tussen het virtuele netwerk en uw on-premises netwerk. 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 VIRTUELE machine 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 hierboven weergegeven architectuur met drie lagen 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. Binnenkomend verkeer vanaf het subnet van de bedrijfslaag toestaan.

  3. Inkomend verkeer van het subnet van de databaselaag zelf toestaan. Deze regel maakt communicatie mogelijk tussen de database-VM's, die nodig zijn voor databasereplicatie en failover.

  4. RDP-verkeer (poort 3389) vanuit het jumpbox-subnet toestaan. 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 ze deze overschrijven.

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 van VM-lagen moeten alle SQL VM's zich in een beschikbaarheidsset 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:

  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 automatisch nieuwe aanvragen 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-lezenquery'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 SQL prestatieoptimalisatie kunt u ook het artikel SQL aanbevolen procedures voor servers raadplegen om de prestaties in Azure Stack Hub te optimaliseren.

Jumpbox

RdP-toegang vanaf het openbare internet niet toestaan naar de VM's waarop de toepassingsworkload wordt uitgevoerd. In plaats daarvan moet alle RDP-toegang tot deze VM's via de jumpbox gaan. 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 waarmee RDP-verbindingen alleen worden toegestaan 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 VIRTUELE machine 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. Hiervoor moet u de installatiekopieën echter up-to-date houden.

Zie Ontwerpoverwegingen voor schaalsets voor meer informatie. Deze ontwerpoverweging is meestal waar 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.

  • We raden u ten zeerste aan beheerde schijven te gebruiken in Azure Stack Hub in plaats van niet-beheerde schijven voor virtuele-machineschaalsets

  • Er is momenteel een limiet van 700 VM's voor Azure Stack Hub, die rekening houdt met alle VM's van de Azure Stack Hub-infrastructuur, afzonderlijke VM's en instanties van schaalsets.

Abonnementslimieten

Elk Azure Stack Hub-tenantabonnement heeft standaardlimieten, inclusief een maximum aantal VM's per regio dat is geconfigureerd door de Azure Stack Hub-operator. Zie Azure Stack Hub-services, abonnementen, aanbiedingen, abonnementen voor meer informatie. Raadpleeg ook quotumtypen in Azure Stack Hub.

Beveiligingsoverwegingen

Virtuele netwerken zijn een verkeersisolatiegrens in Azure. VM's in één virtueel netwerk kunnen standaard 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