Een App Service Environment v1 configureren

Belangrijk

Dit artikel gaat over App Service Environment v1. App Service Environment v1 wordt op 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 29 januari 2024 kunt u geen nieuwe App Service Environment v1-resources meer maken met behulp van een van de beschikbare methoden, waaronder ARM/Bicep-sjablonen, Azure Portal, Azure CLI of REST API. U moet vóór 31 augustus 2024 migreren naar App Service Environment v3 om te voorkomen dat resources worden verwijderd en gegevens verloren gaan.

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
  • Een klassiek(V1) of Resource Manager(V2) Azure Virtual Network (VNet)
  • 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 ingericht.
  • 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 daadwerkelijk 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 ingericht.
  • 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 werkrolgroep worden uitgevoerd.

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

  • 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 wijzigingen 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, evenals 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 VNet dat met uw ASE wordt gebruikt, kan een VNet zijn dat u hebt gemaakt toen u de ASE hebt gemaakt of die 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 VNet, 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 8 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 Resource Manager-VNet. De portal- en API-ervaringen verschillen enigszins tussen klassieke en Resource Manager-VNets, maar de ASE-ervaring is hetzelfde.

Het VNet 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 VNet 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 VNET-integratie of hybride Verbinding maken ionen hoeft te gebruiken om toegang te krijgen tot resources in of verbonden met uw virtuele netwerk. U kunt beide functies echter nog steeds gebruiken voor toegang tot resources in netwerken die niet zijn verbonden met uw virtuele netwerk.

U kunt bijvoorbeeld VNET-integratie 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 hybride Verbinding maken ionen nog steeds gebruiken om toegang te krijgen tot resources die zich in andere netwerken bevinden, net zoals u dat gewend bent.

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 VNet 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. Een ILB ASE vereist nog steeds een extern VIP, maar 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 u as-omgeving hebt 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:

App Service Environment symbol

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.

UI for monitoring and managing your App Service Environment

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 op de manier van 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.

Metrics UI

De metrische gegevens die zojuist 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 Instellingen sectie met verschillende belangrijke mogelijkheden:

>Instellingen Eigenheden: De blade Instellingen wordt automatisch geopend wanneer u de ASE-blade opent. Bovenaan ziet u Eigenschappen. Er zijn hier een aantal items die overbodig zijn voor wat u ziet in Essentials, maar wat erg nuttig is, is virtueel IP-adres, evenals uitgaande IP-adressen.

Settings blade and Properties

>Instellingen IP-adressen: 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 End Pool / Worker Pools: Elk van deze resourcegroep-blades 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. Vanuit de blade werkrolgroep Instellingen hebt u toegang tot alle Apps- of App Service-abonnementen die in deze werkgroep worden uitgevoerd.

Worker pool settings UI

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 toegepast als één bewerking.
  • Een handmatige schaalbewerking vanaf de blade Schaal van afzonderlijke resourcegroepen, die zich onder Instellingen bevindt.
  • 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.

Scale UI

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

Scale settings UI

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 2 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 1 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 2 front-endservers en 2 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.

Delete an App Service Environment UI

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.