Een App Service Environment v1 configureren

Belangrijk

Dit artikel gaat over App Service Environment v1. App Service Environment v1 en v2 worden vanaf 31 augustus 2024 buiten gebruik gesteld. Er is een nieuwe versie van App Service Environment die eenvoudiger te gebruiken is en wordt uitgevoerd op een krachtigere infrastructuur. Voor meer informatie over de nieuwe versie begint u met de inleiding tot de App Service-omgeving. Als u momenteel App Service Environment v1 gebruikt, volgt u de stappen in dit artikel om te migreren naar de nieuwe versie.

Vanaf 31 augustus 2024 zijn Service Level Agreement (SLA) en servicetegoeden niet langer van toepassing op App Service Environment v1- en v2-workloads die in productie blijven omdat ze buiten gebruik worden gesteld. Het buiten gebruik stellen van de App Service Environment v1- en v2-hardware is gestart. Dit kan van invloed zijn op de beschikbaarheid en prestaties van uw apps en gegevens.

U moet de migratie naar App Service Environment v3 onmiddellijk voltooien of uw apps en resources kunnen worden verwijderd. We proberen alle resterende App Service Environment v1 en v2 automatisch te migreren met behulp van de in-place migratiefunctie, maar Microsoft maakt geen claim of garanties over de beschikbaarheid van toepassingen na automatische migratie. Mogelijk moet u handmatige configuratie uitvoeren om de migratie te voltooien en de SKU-keuze van uw App Service-plan te optimaliseren om aan uw behoeften te voldoen. Als automatische migratie niet haalbaar is, worden uw resources en bijbehorende app-gegevens verwijderd. We dringen er ten zeerste op aan dat u nu actie moet ondernemen om een van deze extreme scenario's te voorkomen.

Als u extra tijd nodig hebt, kunnen we een eenmalige respijtperiode van 30 dagen aanbieden om uw migratie te voltooien. Raadpleeg het overzicht van de respijtperiode voor meer informatie en om deze respijtperiode aan te vragen. Ga vervolgens naar Azure Portal en ga naar de blade Migratie voor elk van uw App Service-omgevingen.

Zie de buitengebruikstelling van App Service Environment v1/v2 voor de meest recente informatie over de buitengebruikstelling van App Service Environment v1 en v2.

Overzicht

Op hoog niveau bestaat een Azure-app Service Environment uit verschillende belangrijke onderdelen:

• Rekenresources die worden uitgevoerd in de gehoste App Service Environment-service
• Storage
• Een database
• A Classic(V1) of Resource Manager(V2) Azure Virtual Network (virtueel netwerk)
• Een subnet met de gehoste App Service Environment-service die erin wordt uitgevoerd

Rekenresources

U gebruikt de rekenresources voor uw vier resourcegroepen. Elke As-omgeving (App Service Environment) heeft een set front-ends en drie mogelijke werkgroepen. U hoeft niet alle drie de werkgroepen te gebruiken. Als u wilt, kunt u slechts één of twee groepen gebruiken.

De hosts in de resourcegroepen (front-ends en werkrollen) zijn niet rechtstreeks toegankelijk voor tenants. U kunt rdP (Remote Desktop Protocol) niet gebruiken om er verbinding mee te maken, hun inrichting te wijzigen of als beheerder te fungeren.

U kunt de hoeveelheid en grootte van de resourcegroep instellen. In een ASE hebt u vier grootteopties, die zijn gelabeld als P1 tot en met P4. Zie App Service-prijzen voor meer informatie over deze grootten en hun prijzen. Het wijzigen van de hoeveelheid of grootte wordt een schaalbewerking genoemd. Er kan slechts één schaalbewerking tegelijk worden uitgevoerd.

Front-ends: de front-ends zijn de HTTP/HTTPS-eindpunten voor uw apps die in uw ASE zijn opgeslagen. U voert geen workloads uit in de front-ends.

• Een ASE begint met twee P2's, wat voldoende is voor ontwikkel-/testworkloads en productieworkloads op laag niveau. We raden P3's ten zeerste aan voor gemiddelde tot zware productieworkloads.
• Voor gemiddelde tot zware productieworkloads raden we u aan ten minste vier P3's te hebben om ervoor te zorgen dat er voldoende front-ends worden uitgevoerd wanneer gepland onderhoud plaatsvindt. Geplande onderhoudsactiviteiten brengen één front-end tegelijk neer. Dit vermindert de totale beschikbare front-endcapaciteit tijdens onderhoudsactiviteiten.
• Het kan een uur duren voordat front-ends zijn geïmplementeerd.
• Voor verdere afstemming van de schaal moet u het CPU-percentage, het geheugenpercentage en de metrische gegevens voor actieve aanvragen voor de front-endpool bewaken. Als de CPU- of geheugenpercentages hoger zijn dan 70 procent bij het uitvoeren van P3's, voegt u meer front-ends toe. Als de waarde actieve aanvragen gemiddelden bedraagt van 15.000 tot 20.000 aanvragen per front-end, moet u ook meer front-ends toevoegen. Het algemene doel is om cpu- en geheugenpercentages onder de 70% te houden en actieve aanvragen met een gemiddelde van minder dan 15.000 aanvragen per front-end wanneer u P3's gebruikt.

Werknemers: De werkrollen zijn waar uw apps worden uitgevoerd. Wanneer u uw App Service-abonnementen omhoog schaalt, worden er werkrollen in de gekoppelde werkgroep gebruikt.

• U kunt geen werknemers direct toevoegen. Het kan een uur duren voordat ze zijn geïmplementeerd.
• Het schalen van de grootte van een rekenresource voor elke pool duurt < 1 uur per updatedomein. Er zijn 20 updatedomeinen in een ASE. Als u de rekenkracht van een werkrolgroep met 10 exemplaren hebt geschaald, kan het tot 10 uur duren voordat deze is voltooid.
• Als u de grootte wijzigt van de rekenresources die worden gebruikt in een werkrolgroep, veroorzaakt u koude start van de apps die in die werkgroep worden uitgevoerd.

De snelste manier om de rekenresourcegrootte te wijzigen van een werkrolgroep waarop geen apps worden uitgevoerd, is om:

• Schaal het aantal werknemers omlaag naar 2. De minimale grootte voor omlaag schalen in de portal is 2. Het duurt enkele minuten om de toewijzing van uw exemplaren ongedaan te maken.
• Selecteer de nieuwe rekenkracht en het aantal exemplaren. Vanaf hier duurt het maximaal 2 uur voordat het is voltooid.

Als uw apps een grotere rekenresourcegrootte vereisen, kunt u niet profiteren van de vorige richtlijnen. In plaats van de grootte van de werkrolgroep die als host fungeert voor deze apps te wijzigen, kunt u een andere werkrolgroep vullen met werknemers van de gewenste grootte en uw apps naar die pool verplaatsen.

• Maak de extra exemplaren van de benodigde rekenkracht in een andere werkgroep. Dit duurt maximaal een uur.
• Wijs uw App Service-abonnementen opnieuw toe die als host fungeren voor de apps die een grotere grootte nodig hebben voor de zojuist geconfigureerde werkrolgroep. Dit is een snelle bewerking die minder dan een minuut duurt.
• Schaal de eerste werkrolgroep omlaag als u deze ongebruikte exemplaren niet meer nodig hebt. Het duurt enkele minuten voordat deze bewerking is voltooid.

Automatisch schalen: een van de hulpprogramma's waarmee u het verbruik van rekenresources kunt beheren, is automatisch schalen. U kunt automatische schaalaanpassing gebruiken voor front-end- of werkgroepen. U kunt dingen doen, zoals het verhogen van uw exemplaren van elk pooltype 's ochtends en het in de avond verminderen. Of misschien kunt u exemplaren toevoegen wanneer het aantal werknemers dat beschikbaar is in een werkgroep onder een bepaalde drempelwaarde daalt.

Als u regels voor automatische schaalaanpassing wilt instellen voor metrische gegevens van de rekenresourcegroep, moet u rekening houden met de tijd die nodig is voor inrichting. Zie Automatische schaalaanpassing configureren in een App Service-omgeving voor meer informatie over het automatisch schalen van App Service Environment.

Storage

Elke ASE is geconfigureerd met 500 GB aan opslagruimte. Deze ruimte wordt gebruikt in alle apps in de ASE. Deze opslagruimte maakt deel uit van de ASE en kan momenteel niet worden overgeschakeld naar uw opslagruimte. Als u aanpassingen aanbrengt in de routering of beveiliging van uw virtuele netwerk, moet u nog steeds toegang tot Azure Storage toestaan, of de ASE kan niet werken.

Database

De database bevat de informatie die de omgeving definieert en de details over de apps die erin worden uitgevoerd. Dit maakt ook deel uit van het Azure-abonnement. Het is niet iets dat u direct kunt manipuleren. Als u wijzigingen aanbrengt in de routering of beveiliging van uw virtuele netwerk, moet u nog steeds toegang tot SQL Azure toestaan, of de ASE kan niet werken.

Netwerk

Het virtuele netwerk dat wordt gebruikt met uw ASE, kan een netwerk zijn dat u hebt gemaakt toen u de ASE hebt gemaakt of een netwerk dat u van tevoren hebt gemaakt. Wanneer u het subnet maakt tijdens het maken van de ASE, wordt de ASE gedwongen in dezelfde resourcegroep te staan als het virtuele netwerk. Als u wilt dat de resourcegroep die door uw ASE wordt gebruikt, anders is dan die van uw virtuele netwerk, moet u uw ASE maken met behulp van een Azure Resource Manager-sjabloon.

Er gelden enkele beperkingen voor het virtuele netwerk dat wordt gebruikt voor een ASE:

• Het virtuele netwerk moet een regionaal virtueel netwerk zijn.
• Er moet een subnet zijn met acht of meer adressen waar de ASE is geïmplementeerd.
• Nadat een subnet is gebruikt om een ASE te hosten, kan het adresbereik van het subnet niet worden gewijzigd. Daarom raden we aan dat het subnet ten minste 64 adressen bevat om toekomstige ASE-groei aan te kunnen.
• Er kan niets anders zijn in het subnet, maar de ASE.

In tegenstelling tot de gehoste service die de ASE bevat, staan het virtuele netwerk en subnet onder gebruikersbeheer. U kunt uw virtuele netwerk beheren via de gebruikersinterface van het virtuele netwerk of PowerShell. Een ASE kan worden geïmplementeerd in een klassiek of virtueel Resource Manager-netwerk. De portal- en API-ervaringen verschillen enigszins tussen klassieke en Resource Manager-VNets, maar de ASE-ervaring is hetzelfde.

Het virtuele netwerk dat wordt gebruikt om een ASE te hosten, kan privé-RFC1918 IP-adressen gebruiken of openbare IP-adressen gebruiken. Als u een IP-bereik wilt gebruiken dat niet wordt gedekt door RFC1918 (10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16), moet u uw virtuele netwerk en subnet maken dat door uw ASE moet worden gebruikt voordat de ASE wordt gemaakt.

Omdat deze mogelijkheid de Azure-app Service in uw virtuele netwerk plaatst, betekent dit dat uw apps die in uw ASE worden gehost, nu rechtstreeks toegang hebben tot resources die beschikbaar worden gesteld via ExpressRoute of site-naar-site virtuele privénetwerken (VPN's). Voor de apps die zich in uw App Service-omgeving bevinden, zijn geen extra netwerkfuncties vereist voor toegang tot resources die beschikbaar zijn voor het virtuele netwerk dat als host fungeert voor uw App Service-omgeving. Dit betekent dat u geen gebruik hoeft te maken van integratie van virtuele netwerken of hybride verbindingen om resources in of verbonden met uw virtuele netwerk te krijgen. U kunt beide functies nog steeds gebruiken voor toegang tot resources in netwerken die niet zijn verbonden met uw virtuele netwerk.

U kunt bijvoorbeeld integratie van virtuele netwerken gebruiken om te integreren met een virtueel netwerk dat zich in uw abonnement bevindt, maar niet is verbonden met het virtuele netwerk waarin uw ASE zich bevindt. U kunt nog steeds hybride verbindingen gebruiken om toegang te krijgen tot resources die zich in andere netwerken bevinden, net zoals u dat normaal kunt.

Als u uw virtuele netwerk wel hebt geconfigureerd met een ExpressRoute VPN, moet u rekening houden met een aantal routeringsbehoeften die een ASE heeft. Er zijn enkele door de gebruiker gedefinieerde routeconfiguraties (UDR) die niet compatibel zijn met een ASE. Zie Een App Service Environment uitvoeren in een virtueel netwerk met ExpressRoute voor meer informatie over het uitvoeren van een ASE in een virtueel netwerk met ExpressRoute.

Binnenkomend verkeer beveiligen

Er zijn twee primaire methoden om inkomend verkeer naar uw ASE te beheren. U kunt netwerkbeveiligingsgroepen (NSG's) gebruiken om te bepalen welke IP-adressen toegang hebben tot uw ASE, zoals hier wordt beschreven hoe u inkomend verkeer in een App Service-omgeving beheert en u kunt uw ASE ook configureren met een interne load balancer (ILB). Deze functies kunnen ook samen worden gebruikt als u de toegang wilt beperken met behulp van NSG's naar uw ILB ASE.

Wanneer u een ASE maakt, wordt er een VIP in uw virtuele netwerk gemaakt. Er zijn twee VIP-typen, extern en intern. Wanneer u een ASE maakt met een extern VIP, zijn uw apps in uw ASE toegankelijk via een routeerbaar IP-adres via internet. Wanneer u Intern uw ASE selecteert, wordt geconfigureerd met een ILB en is deze niet rechtstreeks toegankelijk via internet. Voor een ILB AS-omgeving is nog steeds een extern VIP vereist, maar deze wordt alleen gebruikt voor toegang tot Azure-beheer en -onderhoud.

Tijdens het maken van ILB ASE geeft u het subdomein op dat wordt gebruikt door de ILB ASE en moet u uw eigen DNS beheren voor het subdomein dat u opgeeft. Omdat u de naam van het subdomein instelt, moet u ook het certificaat beheren dat wordt gebruikt voor HTTPS-toegang. Nadat de ASE is gemaakt, wordt u gevraagd het certificaat op te geven. Voor meer informatie over het maken en gebruiken van een ILB ASE leest u hoe u een ASEv1 maakt op basis van een sjabloon.

Portal

U kunt uw App Service Environment beheren en bewaken met behulp van de gebruikersinterface in Azure Portal. Als u een ASE hebt, ziet u waarschijnlijk het App Service-symbool op de zijbalk. Dit symbool wordt gebruikt om App Service-omgevingen weer te geven in Azure Portal:

Als u de gebruikersinterface met al uw App Service-omgevingen wilt openen, kunt u het pictogram gebruiken of de dubbele punthaak (>''-symbool) onder aan de zijbalk selecteren om App Service-omgevingen te selecteren. Als u een van de vermelde AS's selecteert, opent u de gebruikersinterface die wordt gebruikt om deze te bewaken en te beheren.

Op deze eerste blade ziet u enkele eigenschappen van uw ASE, samen met een grafiek met metrische gegevens per resourcegroep. Sommige eigenschappen die worden weergegeven in het Essentials-blok zijn ook hyperlinks waarmee de blade wordt geopend die eraan is gekoppeld. U kunt bijvoorbeeld de naam van het virtuele netwerk selecteren om de gebruikersinterface te openen die is gekoppeld aan het virtuele netwerk waarin uw ASE wordt uitgevoerd. App Service-plannen en -apps openen elke blade waarin deze items in uw ASE worden weergegeven.

Controleren

Met de grafieken kunt u verschillende metrische prestatiegegevens in elke resourcegroep bekijken. Voor de front-endpool kunt u de gemiddelde CPU en het gemiddelde geheugen bewaken. Voor werkgroepen kunt u de hoeveelheid bewaken die wordt gebruikt en de beschikbare hoeveelheid.

Meerdere App Service-plannen kunnen gebruikmaken van de werknemers in een werkrolgroep. De werkbelasting wordt niet op dezelfde manier gedistribueerd als bij de front-endservers, dus het CPU- en geheugengebruik bieden niet veel nuttige informatie. Het is belangrijker om bij te houden hoeveel werknemers u hebt gebruikt en beschikbaar zijn, vooral als u dit systeem beheert voor gebruik door anderen.

U kunt ook alle metrische gegevens gebruiken die in de grafieken kunnen worden bijgehouden om waarschuwingen in te stellen. Het instellen van waarschuwingen werkt hier hetzelfde als elders in App Service. U kunt een waarschuwing instellen vanuit het onderdeel Waarschuwingeninterface of inzoomen op een gebruikersinterface voor metrische gegevens en waarschuwing toevoegen selecteren.

De metrische gegevens die zijn besproken, zijn de metrische gegevens van de App Service Environment. Er zijn ook metrische gegevens beschikbaar op het niveau van het App Service-plan. Dit is waar het bewaken van CPU en geheugen veel zin heeft.

In een ASE zijn alle App Service-plannen toegewezen App Service-abonnementen. Dat betekent dat de enige apps die worden uitgevoerd op de hosts die aan dat App Service-plan zijn toegewezen, de apps in dat App Service-plan zijn. Als u details van uw App Service-plan wilt bekijken, opent u uw App Service-plan vanuit een van de lijsten in de ASE-gebruikersinterface of vanuit App Service-abonnementen bladeren (waarin alle abonnementen worden vermeld).

Instellingen

Op de blade ASE bevindt zich een sectie Instellingen die verschillende belangrijke mogelijkheden bevat:

Eigenschappen van instellingen: de blade Instellingen> wordt automatisch geopend wanneer u de ASE-blade opent. Bovenaan ziet u Eigenschappen. Er zijn hier veel items die overbodig zijn voor wat u ziet in Essentials, maar wat nuttig is, is virtueel IP-adres en uitgaande IP-adressen.

IP-adressen voor instellingen>: wanneer u een SSL-app (IP Secure Sockets Layer) in uw ASE maakt, hebt u een IP SSL-adres nodig. Om er een te verkrijgen, heeft uw ASE IP SSL-adressen nodig die eigenaar zijn van die kunnen worden toegewezen. Wanneer een ASE wordt gemaakt, heeft deze één IP SSL-adres voor dit doel, maar u kunt meer toevoegen. Er worden kosten in rekening gebracht voor extra IP SSL-adressen, zoals wordt weergegeven in prijzen voor App Service (in de sectie over SSL-verbindingen). De extra prijs is de IP SSL-prijs.

Instellingen>front-endpoolwerkgroepen / : elk van deze resourcegroepblade's biedt de mogelijkheid om alleen informatie over die resourcegroep weer te geven, naast het bieden van besturingselementen om die resourcegroep volledig te schalen.

De basisblade voor elke resourcegroep biedt een grafiek met metrische gegevens voor die resourcegroep. Net als bij de grafieken van de ASE-blade kunt u naar de grafiek gaan en waarschuwingen naar wens instellen. Het instellen van een waarschuwing vanaf de ASE-blade voor een specifieke resourcegroep doet hetzelfde als dat van de resourcegroep. Op de blade Instellingen voor de werkrolgroep hebt u toegang tot alle Apps- of App Service-abonnementen die in deze werkgroep worden uitgevoerd.

Mogelijkheden voor portalschaal

Er zijn drie schaalbewerkingen:

• Het aantal IP-adressen in de ASE wijzigen dat beschikbaar is voor IP SSL-gebruik.
• De grootte wijzigen van de rekenresource die wordt gebruikt in een resourcegroep.
• Het aantal rekenresources wijzigen dat in een resourcegroep wordt gebruikt, handmatig of via automatische schaalaanpassing.

In de portal kunt u op drie manieren bepalen hoeveel servers u in uw resourcegroepen hebt:

• Een schaalbewerking vanaf de belangrijkste ASE-blade bovenaan. U kunt meerdere schaalconfiguratiewijzigingen aanbrengen in de front-end- en werkrolgroepen. Ze worden allemaal als één bewerking toegepast.
• Een handmatige schaalbewerking vanaf de blade Schaal van afzonderlijke resourcegroepen, onder Instellingen.
• Automatisch schalen, dat u instelt vanaf de blade Schaal van afzonderlijke resourcegroepen.

Als u de schaalbewerking op de ASE-blade wilt gebruiken, sleept u de schuifregelaar naar de gewenste hoeveelheid en slaat u deze op. Deze gebruikersinterface ondersteunt ook het wijzigen van de grootte.

Als u de mogelijkheden voor handmatige of automatische schaalaanpassing in een specifieke resourcegroep wilt gebruiken, gaat u naar Instellingen>front-endpoolwerkgroepen / , indien van toepassing. Open vervolgens het zwembad dat u wilt wijzigen. Ga naar Instellingen>uitschalen of Instellingen>omhoog schalen. Met de blade Uitschalen kunt u de hoeveelheid exemplaren beheren. Met omhoog schalen kunt u de resourcegrootte beheren.

Overwegingen voor fouttolerantie

U kunt een App Service Environment configureren voor het gebruik van maximaal 55 rekenresources. Van deze 55 rekenresources kunnen slechts 50 worden gebruikt voor het hosten van workloads. De reden hiervoor is tweeledig. Er zijn minimaal twee front-end rekenresources. Dit zorgt ervoor dat maximaal 53 ondersteuning biedt voor de toewijzing van de werkrolgroep. Als u fouttolerantie wilt bieden, moet u een extra rekenresource hebben die is toegewezen volgens de volgende regels:

• Elke werkrolgroep heeft ten minste één extra rekenresource nodig die niet beschikbaar is om een workload toe te wijzen.
• Wanneer de hoeveelheid rekenresources in een werkgroep boven een bepaalde waarde komt, is er een andere rekenresource vereist voor fouttolerantie. Dit is niet het geval in de front-endpool.

Binnen één werkrolgroep zijn de fouttolerantievereisten die gelden voor een bepaalde waarde van X-resources die zijn toegewezen aan een werkrolgroep:

• Als X tussen 2 en 20 ligt, is de hoeveelheid bruikbare rekenresources die u voor workloads kunt gebruiken X-1.
• Als X tussen 21 en 40 ligt, is de hoeveelheid bruikbare rekenresources die u voor workloads kunt gebruiken X-2.
• Als X tussen 41 en 53 ligt, is de hoeveelheid bruikbare rekenresources die u voor workloads kunt gebruiken X-3.

De minimale footprint heeft twee front-endservers en twee werkrollen. Met de bovenstaande instructies zijn hier enkele voorbeelden om het volgende te verduidelijken:

• Als u 30 werkrollen in één pool hebt, kunnen er 28 worden gebruikt om workloads te hosten.
• Als u twee werkrollen in één pool hebt, kunt u 1 gebruiken om workloads te hosten.
• Als u 20 werkrollen in één pool hebt, kunnen er 19 worden gebruikt om workloads te hosten.
• Als u 21 werkrollen in één pool hebt, kunnen er nog steeds maar 19 worden gebruikt om workloads te hosten.

Het aspect fouttolerantie is belangrijk, maar u moet er rekening mee houden wanneer u boven bepaalde drempelwaarden schaalt. Als u meer capaciteit wilt toevoegen van 20 exemplaren, gaat u naar 22 of hoger omdat 21 geen capaciteit meer toevoegt. Hetzelfde geldt voor meer dan 40, waarbij het volgende aantal dat capaciteit toevoegt 42 is.

Een App Service-omgeving verwijderen

Als u een App Service-omgeving wilt verwijderen, gebruikt u de actie Verwijderen boven aan de blade App Service Environment. Wanneer u dit doet, wordt u gevraagd de naam van uw App Service Environment in te voeren om te bevestigen dat u dit echt wilt doen. Houd er rekening mee dat wanneer u een App Service-omgeving verwijdert, u ook alle inhoud erin verwijdert.

Aan de slag

Zie Een ASEv1 maken op basis van een sjabloon om aan de slag te gaan met App Service Environments.

Notitie

Als u aan de slag wilt met Azure App Service voordat u zich aanmeldt voor een Azure-account, gaat u naar App Service uitproberen. Hier kunt u direct een tijdelijke web-app maken in App Service. U hebt geen creditcard nodig en u gaat geen verplichtingen aan.