Windows N-tier-toepassing in Azure

Deze referentiearchitectuur laat zien hoe u virtuele machines (VM's) en een virtueel netwerk implementeert dat is geconfigureerd voor een toepassing met n-aantal lagen, met behulp van SQL Server op Windows voor de gegevenslaag. Deze oplossing implementeren.

Een Visio-bestand van deze architectuur downloaden.

Architectuur

De architectuur heeft de volgende onderdelen:

Algemeen

• Resourcegroep. Resourcegroepen worden gebruikt om Azure-resources te groepen, 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 meerdere zones te plaatsen, wordt de toepassing bestand tegen fouten binnen een zone.

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.

• Toepassingsgateway. Application Gateway is een laag 7 load balancer. 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 Protection. Hoewel het Azure-platform basisbeveiliging biedt tegen DDoS-aanvallen (Distributed Denial of Service), raden we u aan DDoS Protection Standardte gebruiken, dat verbeterde DDoS-beperkingsfuncties heeft. Zie Beveiligingsoverwegingen.

• Azure DNS. Azure DNS is een hostingservice voor DNS-domeinen. Het biedt naamoplossing met behulp 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 Always On-beschikbaarheidsgroep. Biedt hoge beschikbaarheid in de gegevenslaag door replicatie en failover in te schakelen. Er wordt gebruikgemaakt 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).

• Cloud witness. 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 ertoe leiden dat elk knooppunt denkt dat het het primaire knooppunt is. In dat geval hebt u een witness nodig om de bindingen te verbreken en quorum tot stand te laten komen. Een witness is een resource zoals een gedeelde schijf die kan fungeren als een tie-breaker om een quorum tot stand te laten komen. Cloud witness is een type witness dat gebruikmaakt van Azure Blob Storage. Zie Understanding cluster and pool quorum (Cluster- en poolquorum begrijpen) voor meer informatie over het concept quorum. Zie Deploy a Cloud Witness for a Failover Cluster (Een cloud-witness implementeren voor een failovercluster) voor meer informatie overCloud Witness.

• Jumpbox. Wordt ook wel een bastionhost genoemd. Van oudsher 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 Remote Desktop Protocol (RDP)-verkeer 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 uitvoeren in Azure 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 tussen het virtuele netwerk en uw on-premises netwerk moet instellen. Wanneer u het virtuele netwerk hebt aan maak, 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 configuratieoverzicht voor meer Application Gateway over Application Gateway configuratie.

Load balancers

Maak de VM's niet rechtstreeks bloot aan internet, maar geef elke VM een privé-IP-adres. Clients maken verbinding met behulp van het openbare IP-adres dat is gekoppeld aan Application Gateway.

Definieer load balancer-regels om netwerkverkeer door te sturen naar de virtuele machines. Als u bijvoorbeeld HTTP-verkeer wilt inschakelen, moet u poort 80 van de front-endconfiguratie aan poort 80 in de back-endadresgroep wijsen. 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 gedistribueerd 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 inkomende verkeer van het virtuele netwerk weigeren. (Gebruik de tag VIRTUAL_NETWORK in de regel.)
2. Sta inkomende verkeer van het subnet van de bedrijfslaag toe.
3. Sta het inkomende verkeer van het subnet van de databaselaag zelf toe. Deze regel staat communicatie toe tussen de database-VM's, die nodig zijn voor databasereplicatie en failover.
4. Sta RDP-verkeer (poort 3389) van het jumpbox-subnet toe. 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.

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, 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 in een particulier virtueel netwerk, zoals in deze architectuur, hebt u toegang nodig tot virtuele machines voor software-installatie, patching, en meer. Maar het is geen goed idee om deze machines toegankelijk te maken voor het openbare internet, omdat het aanvalsoppervlak hierdoor aanzienlijk toeneemt. 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 jumpbox. In dat scenario zijn de volgende aanbevelingen van toepassing:

• Sta geen RDP-toegang van het openbare internet toe tot de VM's die de toepassingsworkload uitvoeren. 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 vanuit de jumpbox aan bij de andere VM. 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.

Voor een door de klant beheerde VM zijn al deze regels van toepassing. De huidige aanbeveling is echter het gebruik van Azure Bastion, een beheerde jumpbox-oplossing waarmee HTML5-toegang tot RDP of SSH achter Azure AD-beveiliging mogelijk is. Dit is een veel eenvoudigere oplossing met uiteindelijk een lagere total cost of ownership (TCO) voor de klant.

Schaalbaarheidsoverwegingen

Schaalsets

Voor de web- en bedrijfslagen kunt u virtuele-machineschaalsets 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 afbeelding echter up-to-date houden.

Zie Ontwerpoverwegingen voor schaalsets voor meer informatie.

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 Azure-abonnement- en servicelimieten, quota en beperkingen voor meer informatie.

Application Gateway

Application Gateway ondersteuning voor de modus voor 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 werkbelastingen met variabele verkeer. Zie Autoscaling and Zone-redundant Application Gateway v2 (Automatisch schalen en zone-redundante Application Gateway v2) voor meer informatie

Beschikbaarheidsoverwegingen

Beschikbaarheidszones bieden de beste tolerantie binnen één regio. Als u nog hogere beschikbaarheid nodig hebt, kunt u overwegen om de toepassing te repliceren tussen twee regio's, met behulp Azure Traffic Manager failover. Zie Multi-region N-tier application for high availability (Toepassing met meerdere regio's voor hoge beschikbaarheid) voor meer informatie.

Niet alle regio's ondersteunen beschikbaarheidszones en niet alle VM-grootten worden ondersteund in alle zones. Voer de volgende Azure CLI-opdracht uit om de ondersteunde zones voor elke VM-grootte binnen een regio te vinden:

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, moet u de VM's voor elke laag in een beschikbaarheidsset zetten. VM's binnen dezelfde beschikbaarheidsset worden geïmplementeerd op meerdere fysieke servers, rekenrekken, opslageenheden en netwerkswitches voor redundantie. Schaalsets gebruiken automatisch plaatsingsgroepen die fungeren als een impliciete beschikbaarheidsset.

Wanneer u implementeert in beschikbaarheidszones, gebruikt u de Standaard-SKU van Azure Load Balancer en de v2-SKU van Application Gateway. Deze SKU's ondersteunen redundantie in meerdere zones. Zie voor meer informatie:

• Load Balancer van het type Standard en beschikbaarheidszones
• Automatisch schalen en zone-redundantie in Application Gateway v2
• Hoe ondersteunt Application Gateway hoge beschikbaarheid en schaalbaarheid?

Met één Application Gateway kunnen meerdere exemplaren van de gateway worden uitgevoerd. Voor productieworkloads moet u ten minste twee exemplaren uitvoeren.

Statuscontroles

Application Gateway en Load Balancer beide statustests gebruiken om de beschikbaarheid van VM-exemplaren te bewaken.

• Application Gateway maakt altijd gebruik van een HTTP-test.
• Load Balancer kunt HTTP of TCP testen. Over het algemeen, als op een VM een HTTP-server wordt uitgevoerd, gebruikt u een HTTP-test. Gebruik anders TCP.

Als een test een exemplaar niet binnen een time-outperiode kan bereiken, stopt de gateway of load balancer het verzenden van verkeer naar die VM. De test blijft het controleren en retournt de VM naar de back-endpool als de VM weer beschikbaar wordt.

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 eindpunt voor statuscontrole 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:

• Statustesten voor Load Balancer
• Application Gateway statuscontrole

Zie Health Endpoint Monitoring pattern (Patroon Status van eindpuntbewaking) voor overwegingen over het ontwerpen van een eindpunt voor een statustest.

Kostenoverwegingen

Gebruik de Azure-prijscalculator om een schatting te maken van de kosten. Hier zijn enkele andere overwegingen.

Virtuele-machineschaalsets

Virtuele-machineschaalsets zijn beschikbaar op Windows VM-grootten. Er worden alleen kosten in rekening gebracht voor de Azure-VM's die u implementeert en eventuele extra onderliggende infrastructuurbronnen die worden verbruikt, zoals opslag en netwerken. Er worden geen incrementele kosten in rekening gebracht voor de service voor virtuele-machineschaalsets.

Zie Prijzen van virtuele Windows voor prijzen voor afzonderlijke VM's

SQL Server

Als u Azure SQL DPlatform, kunt u besparen op kosten omdat u geen Always On-beschikbaarheidsgroep en domeincontrollermachines hoeft te configureren. Er zijn verschillende implementatieopties, van individuele databases tot beheerde exemplaren of elastische pools. Zie Prijzen voor Azure SQL voor meer informatie.

Zie prijzen SQL VM's voor meer SQL server-VM's.

Load balancers

Er worden alleen kosten in rekening gebracht voor het aantal geconfigureerde taakverdelings- en uitgaande regels. Inkomende NAT-regels zijn gratis. Er worden geen kosten per uur in rekening Standard Load Balancer wanneer er geen regels zijn geconfigureerd.

Raadpleeg de kostensectie in Microsoft Azure Well-Architected Framework voor meer informatie.

Beveiligingsoverwegingen

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 is ook raadzaam 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 om DDoS Protection Standard te gebruiken. Standaardbeveiliging maakt gebruik van adaptieve afstemming, op basis van de netwerkverkeerspatronen van uw toepassing, om bedreigingen te detecteren. Hierdoor kunnen er oplossingen worden toegepast tegen DDoS-aanvallen die mogelijk niet worden opgemerkt door het DDoS-beleid voor de hele infrastructuur. Standaardbeveiliging biedt ook waarschuwingen, telemetrie en analyses via Azure Monitor. Zie voor meer informatie Azure DDoS Protection: Best practices en referentiearchitecten.

DevOps overwegingen

In deze architectuur gebruikt u [Azure-bouwstenensjablonen][azbb-template] voor het inrichten van de Azure-resources en de afhankelijkheden ervan. Omdat alle hoofdresources en hun afhankelijkheden zich in hetzelfde virtuele netwerk hebben, zijn ze geïsoleerd in dezelfde basisworkload, waardoor het eenvoudiger wordt om de specifieke resources van de workload aan een team te koppelen, zodat het team alle aspecten van deze resources onafhankelijk kan beheren. Door 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 terichten, bijvoorbeeld om productiescenario's te repliceren of omgevingen voor belastingstests alleen wanneer dat nodig is, wat kosten bespaart.

In dit sceanario worden uw virtuele machines geconfigureerd met virtual machine-extensies, omdat ze de mogelijkheid bieden om bepaalde aanvullende software te installeren, zoals antimalware en beveiligingsagents. VM-extensies worden alleen geïnstalleerd en uitgevoerd op het moment dat de VM wordt gemaakt. Dit betekent dat als het besturingssysteem in een latere fase onjuist wordt geconfigureerd, er handmatig moet worden ingegrepen om het besturingssysteem weer in de juiste staat te krijgen.

Configuratiebeheerprogramma's, met name Desired State Configuration (DSC), worden in deze architectuur gebruikt om Active Directory en een SQL Server Always On-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 in feite een van de onderdelen van Azure Monitor, die u uitgebreide metrische gegevens en logboeken biedt om de status van uw volledige Azure-landschap te controleren. Azure Monitor helpt u de status van uw infrastructuur te volgen.

Controleer niet alleen uw rekenelementen die uw toepassingscode ondersteunen, maar ook uw gegevensplatform, met name uw databases, omdat een lage prestaties van de gegevenslaag van een toepassing ernstige gevolgen kunnen hebben.

Als u de Azure-omgeving wilt testen waarin de toepassingen worden uitgevoerd, moet de versie worden beheerd en geïmplementeerd via dezelfde mechanismen als toepassingscode. Vervolgens kan deze ook worden getest en gevalideerd met behulp van DevOps-testparadigma's.

Zie de sectie Operational Excellence in Azure Well-Architected Framework voor meer informatie.

De oplossing implementeren

Een implementatie voor deze referentiearchitectuur is beschikbaar op GitHub. De volledige implementatie kan een uur duren, waaronder het uitvoeren van de scripts voor het configureren van AD DS, het Windows Server-failovercluster en de SQL Server-beschikbaarheidsgroep.

Als u een regio opgeeft die beschikbaarheidszones ondersteunt, worden de VM's geïmplementeerd in beschikbaarheidszones. Anders worden de VM's geïmplementeerd in beschikbaarheidssets. Zie Services-ondersteuning per regio voor een lijst met regio's die beschikbaarheidszones ondersteunen.

Vereisten

1. Kloon, vertak of download het zip-bestand voor de GitHub-opslagplaats met referentiearchitecturen.

2. Installeer Azure CLI 2.0.

3. Node en NPM installeren

4. Installeer het NPM-pakket met Azure-bouwstenen.

   npm install -g @mspnp/azure-building-blocks
   

5. Meld u via een opdrachtprompt, Bash-prompt of PowerShell-prompt als volgt aan bij uw Azure-account:

   az login
   

Implementatiestappen

1. Navigeer virtual-machines\n-tier-windows naar de map van de referentiearchitect GitHub opslagplaats.

2. Open het bestand n-tier-windows.json.

3. Zoek in n-tier-windows.json het bestand naar alle exemplaren van en vervang deze door een sterk [replace-with-password] [replace-with-safe-mode-password] wachtwoord. Sla het bestand op.

   Notitie

   Als u de gebruikersnaam van de beheerder wijzigt, moet u ook de blokken extensions in het JSON-bestand bijwerken.

4. Voer de volgende opdracht uit om de architectuur te implementeren.

   azbb -s <your subscription_id> -g <resource_group_name> -l <location> -p n-tier-windows.json --deploy
   

5. Wanneer de implementatie is voltooid, opent u de Azure Portal en navigeert u naar de resourcegroep. Zoek het opslagaccount dat begint met 'sqlcw'. Dit is het opslagaccount dat wordt gebruikt voor de cloud-witness van het cluster. Navigeer naar het opslagaccount, selecteer Toegangssleutels en kopieer de waarde van key1 . Kopieer ook de naam van het opslagaccount.

6. Open het bestand n-tier-windows-sqlao.json.

7. Zoek in n-tier-windows-sqlao.json het bestand naar alle exemplaren van en vervang deze door een sterk [replace-with-password] [replace-with-sql-password] wachtwoord.

   Notitie

   Als u de gebruikersnaam van de beheerder wijzigt, moet u ook de blokken extensions in het JSON-bestand bijwerken.

8. Zoek in n-tier-windows-sqlao.json het bestand naar alle exemplaren van en en vervang deze door de waarden uit stap [replace-with-storageaccountname] [replace-with-storagekey] 5. Sla het bestand op.

9. Voer de volgende opdracht uit om de SQL Server Te configureren.

   azbb -s <your subscription_id> -g <resource_group_name> -l <location> -p n-tier-windows-sqlao.json --deploy
   

Volgende stappen

• Microsoft Learn module: Een rondleiding door de architectuurstijl met meerdere lagen