Delen via

Prestatieproblemen met Azure Files oplossen

  • Artikel

Notitie

CentOS waarnaar in dit artikel wordt verwezen, is een Linux-distributie en bereikt het einde van de levensduur (EOL). Houd rekening met uw gebruik en plan dienovereenkomstig. Zie De richtlijnen voor het einde van de levensduur van CentOS voor meer informatie.

Dit artikel bevat veelvoorkomende problemen met betrekking tot prestaties van Azure-bestandsshares en biedt mogelijke oorzaken en tijdelijke oplossingen. Als u de meeste waarde wilt krijgen uit deze gids voor probleemoplossing, raden we u aan eerst inzicht te krijgen in de prestaties van Azure Files.

Van toepassing op

Bestands sharetype SMB NFS
Standaardbestandsshares (GPv2), LRS/ZRS
Standaardbestandsshares (GPv2), GRS/GZRS
Premium bestandsshares (FileStorage), LRS/ZRS

Algemene prestatieproblemen oplossen

Sluit eerst enkele veelvoorkomende redenen uit waarom u mogelijk prestatieproblemen ondervindt.

U voert een oud besturingssysteem uit

Als op uw virtuele clientmachine (VM) Windows 8.1 of Windows Server 2012 R2 of een oudere Linux-distributie of -kernel wordt uitgevoerd, kunnen er prestatieproblemen optreden bij het openen van Azure-bestandsshares. Voer een upgrade uit van het client-besturingssysteem of pas de onderstaande oplossingen toe.

Overwegingen voor Windows 8.1 en Windows Server 2012 R2

Clients met Windows 8.1 of Windows Server 2012 R2 zien mogelijk een hogere latentie dan verwacht bij het openen van Azure-bestandsshares voor I/O-intensieve workloads. Zorg ervoor dat de KB3114025 hotfix is geïnstalleerd. Deze hotfix verbetert de prestaties van het maken en sluiten van ingangen.

U kunt het volgende script uitvoeren om te controleren of de hotfix is geïnstalleerd:

reg query HKLM\SYSTEM\CurrentControlSet\Services\LanmanWorkstation\Parameters\Policies

Als de hotfix is geïnstalleerd, wordt de volgende uitvoer weergegeven:

HKEY_Local_MACHINE\SYSTEM\CurrentControlSet\Services\LanmanWorkstation\Parameters\Policies {96c345ef-3cac-477b-8fcd-bea1a564241c} REG_DWORD 0x1

Notitie

Windows Server 2012 R2-installatiekopieën in Azure Marketplace hebben hotfix-KB3114025 standaard geïnstalleerd vanaf december 2015.

Uw workload wordt beperkt

Aanvragen worden beperkt wanneer de I/O-bewerkingen per seconde (IOPS), inkomend of uitgaand verkeer voor een bestandsshare worden bereikt. Als de client bijvoorbeeld de basislijn-IOPS overschrijdt, wordt deze beperkt door de Azure Files-service. Beperking kan ertoe leiden dat de client slechte prestaties ondervindt.

Zie Bestandsshare- en bestandsschaaldoelen voor meer informatie over de limieten voor Standard- en Premium-bestandsshares. Afhankelijk van uw workload kan beperking vaak worden vermeden door over te stappen van Standard naar Premium Azure-bestandsshares.

Voor meer informatie over hoe beperking op share- of opslagaccountniveau kan leiden tot hoge latentie, lage doorvoer en algemene prestatieproblemen, raadpleegt u Share of opslagaccount wordt beperkt.

Hoge latentie, lage doorvoer of lage IOPS

Oorzaak 1: Share- of opslagaccount wordt beperkt

Als u wilt controleren of uw share- of opslagaccount wordt beperkt, kunt u metrische gegevens van Azure openen en gebruiken in de portal. U kunt ook waarschuwingen maken die u op de hoogte stellen als een share wordt beperkt of op het punt staat om te worden beperkt. Zie Problemen met Azure Files oplossen door waarschuwingen te maken.

Belangrijk

Voor standaardopslagaccounts vindt beperking plaats op het niveau van het opslagaccount. Voor Premium-bestandsshares vindt beperking plaats op shareniveau.

  1. Ga in Azure Portal naar uw opslagaccount.

  2. Selecteer in het linkerdeelvenster onder Bewaking de optie Metrische gegevens.

  3. Selecteer Bestand als de metrische naamruimte voor het bereik van uw opslagaccount.

  4. Selecteer Transacties als de metrische waarde.

  5. Voeg een filter toe voor het antwoordtype en controleer vervolgens of aanvragen zijn beperkt.

    Voor standaardbestandsshares worden de volgende antwoordtypen geregistreerd als een aanvraag wordt beperkt op het niveau van het clientaccount:

    • ClientAccountRequestThrottlingError
    • ClientAccountBandwidthThrottlingError

    Voor Premium-bestandsshares worden de volgende antwoordtypen geregistreerd als een aanvraag wordt beperkt op shareniveau:

    • SuccessWithShareEgressThrottling
    • SuccessWithShareIngressThrottling
    • SuccessWithShareIopsThrottling
    • ClientShareEgressThrottlingError
    • ClientShareIngressThrottlingError
    • ClientShareIopsThrottlingError

    Als een beperkte aanvraag is geverifieerd met Kerberos, ziet u mogelijk een voorvoegsel dat het verificatieprotocol aangeeft, zoals:

    • KerberosSuccessWithShareEgressThrottling
    • KerberosSuccessWithShareIngressThrottling

    Zie Metrische dimensies voor meer informatie over elk antwoordtype.

    Schermopname van het eigenschapsfilter Antwoordtype.

Oplossing

Als u een Premium-bestandsshare gebruikt, verhoogt u de ingerichte bestandssharegrootte om de IOPS-limiet te verhogen. Zie het artikel Understanding provisioning voor Premium-bestandsshares voor meer informatie.

Oorzaak 2: zware werkbelasting voor metagegevens of naamruimte

Als het merendeel van uw aanvragen gericht is op metagegevens (zoals createfile, openfile, closefile, queryinfoof querydirectory), is de latentie slechter dan die van lees-/schrijfbewerkingen.

Als u wilt bepalen of de meeste aanvragen gericht zijn op metagegevens, begint u met de stappen 1-4, zoals eerder beschreven in Oorzaak 1. Voor stap 5 voegt u in plaats van een filter voor antwoordtype een eigenschapsfilter toe voor de API-naam.

Schermopname van het eigenschapsfilter API-naam.

Tijdelijke oplossingen

  • Controleer of de toepassing kan worden gewijzigd om het aantal metagegevensbewerkingen te verminderen.

  • Als u premium SMB Azure-bestandsshares gebruikt, gebruikt u caching van metagegevens.

  • Scheid de bestandsshare in meerdere bestandsshares binnen hetzelfde opslagaccount.

  • Voeg een virtuele harde schijf (VHD) toe aan de bestandsshare en koppel de VHD van de client om bestandsbewerkingen uit te voeren op basis van de gegevens. Deze benadering werkt voor scenario's of scenario's voor één schrijver/lezer met meerdere lezers en geen schrijvers. Omdat het bestandssysteem eigendom is van de client in plaats van Azure Files, kunnen metagegevensbewerkingen lokaal zijn. De installatie biedt prestaties die vergelijkbaar zijn met die van lokale rechtstreeks gekoppelde opslag. Omdat de gegevens zich echter in een VHD bevinden, kunnen deze niet worden geopend via een andere manier dan de SMB-koppeling, zoals REST API of via Azure Portal.

    1. Koppel de bestandsshare vanaf de computer die toegang nodig heeft tot de Azure-bestandsshare met behulp van de sleutel van het opslagaccount en wijs deze toe aan een beschikbaar netwerkstation (bijvoorbeeld Z:).
    2. Ga naar Schijfbeheer en selecteer Actie > VHD maken.
    3. Stel Locatie in op het netwerkstation waarop de Azure-bestandsshare is toegewezen, stel de grootte van de virtuele harde schijf in waar nodig en selecteer Vaste grootte.
    4. Selecteer OK. Zodra het maken van de VHD is voltooid, wordt deze automatisch gekoppeld en wordt er een nieuwe niet-toegewezen schijf weergegeven.
    5. Klik met de rechtermuisknop op de nieuwe onbekende schijf en selecteer Schijf initialiseren.
    6. Klik met de rechtermuisknop op het niet-toegewezen gebied en maak een nieuw eenvoudig volume.
    7. Er wordt een nieuwe stationsletter weergegeven in Schijfbeheer die deze VHD vertegenwoordigt met lees-/schrijftoegang (bijvoorbeeld E:). In Bestandenverkenner ziet u de nieuwe VHD op het netwerkstation van de toegewezen Azure-bestandsshare (Z: in dit voorbeeld). Om duidelijk te zijn, moeten er twee stationsletters aanwezig zijn: de standaard azure-bestandssharenetwerktoewijzing op Z:, en de VHD-toewijzing op het E:-station.
    8. Er moeten veel betere prestaties zijn voor zware metagegevensbewerkingen op bestanden op het toegewezen VHD-station (E:) versus het toegewezen station van de Azure-bestandsshare (Z:). Indien gewenst moet het mogelijk zijn om de toegewezen netwerkstation (Z:) los te koppelen en toch toegang te krijgen tot het gekoppelde VHD-station (E:).
    • Als u een VHD wilt koppelen op een Windows-client, kunt u ook de Mount-DiskImage PowerShell-cmdlet gebruiken.
    • Raadpleeg de documentatie voor uw Linux-distributie om een VHD op Linux te koppelen. Hier volgt een voorbeeld.

Oorzaak 3: Toepassing met één thread

Als de toepassing die u gebruikt één thread heeft, kan deze instelling leiden tot een aanzienlijk lagere IOPS-doorvoer dan de maximaal mogelijke doorvoer, afhankelijk van de ingerichte sharegrootte.

Oplossing

  • Verhoog de parallelle uitvoering van toepassingen door het aantal threads te verhogen.
  • Schakel over naar toepassingen waar parallelle uitvoering mogelijk is. Voor kopieerbewerkingen kunt u bijvoorbeeld AzCopy of RoboCopy van Windows-clients of de parallelle opdracht van Linux-clients gebruiken.

Oorzaak 4: Het aantal SMB-kanalen overschrijdt vier

Als u SMB meerdere kanalen gebruikt en het aantal kanalen dat u hebt, groter is dan vier kanalen, resulteert dit in slechte prestaties. Als u wilt bepalen of het aantal verbindingen groter is dan vier, gebruikt u de PowerShell-cmdlet get-SmbClientConfiguration om de huidige instellingen voor het aantal verbindingen weer te geven.

Oplossing

Stel de windows-instelling per NIC in voor SMB, zodat het totale aantal kanalen niet groter is dan vier. Als u bijvoorbeeld twee NIC's hebt, kunt u het maximum per NIC instellen op twee met behulp van de volgende PowerShell-cmdlet: Set-SmbClientConfiguration -ConnectionCountPerRssNetworkInterface 2.

Oorzaak 5: Leesdoorloopgrootte is te klein (alleen NFS)

Vanaf Linux-kernelversie 5.4 gebruikt de Linux NFS-client een standaardwaarde read_ahead_kb van 128 kibibytes (KiB). Deze kleine waarde kan de hoeveelheid leesdoorvoer voor grote bestanden verminderen.

Oplossing

U wordt aangeraden de parameterwaarde van de read_ahead_kb kernel te verhogen naar 15 mebibytes (MiB). Als u deze waarde wilt wijzigen, stelt u de grootte voor lezen permanent in door een regel toe te voegen in udev, een Linux-kernelapparaatbeheer. Volg vervolgens deze stappen:

  1. Maak in een teksteditor het bestand /etc/udev/rules.d/99-nfs.rules door de volgende tekst in te voeren en op te slaan:

    SUBSYSTEM=="bdi" \
, ACTION=="add" \
, PROGRAM="/usr/bin/awk -v bdi=$kernel 'BEGIN{ret=1} {if ($4 == bdi) {ret=0}} END{exit ret}' /proc/fs/nfsfs/volumes" \
, ATTR{read_ahead_kb}="15360"

  2. Pas in een console de udev-regel toe door de opdracht udevadm uit te voeren als supergebruiker en de regelbestanden en andere databases opnieuw te laden. Als u udev op de hoogte wilt stellen van het nieuwe bestand, hoeft u deze opdracht slechts één keer uit te voeren.

    sudo udevadm control --reload

Zeer hoge latentie voor aanvragen

Oorzaak

De client-VM kan zich in een andere regio bevinden dan de bestandsshare. Een andere reden voor hoge latentie kan worden veroorzaakt door de latentie die wordt veroorzaakt door de client of het netwerk.

Oplossing

  • Voer de toepassing uit vanaf een virtuele machine die zich in dezelfde regio bevindt als de bestandsshare.
  • Bekijk voor uw opslagaccount de metrische transactiegegevens SuccessE2ELatency en SuccessServerLatency via Azure Monitor in Azure Portal. Een hoog verschil tussen metrische waarden voor SuccessE2ELatency en SuccessServerLatency is een indicatie van latentie die waarschijnlijk wordt veroorzaakt door het netwerk of de client. Zie metrische gegevens over transacties in Azure Files Monitoring-gegevens.

Client kan geen maximale doorvoer bereiken die wordt ondersteund door het netwerk

Oorzaak

Een mogelijke oorzaak is een gebrek aan SMB-ondersteuning voor meerdere kanalen voor standaardbestandsshares. Momenteel ondersteunt Azure Files slechts één kanaal voor standaardbestandsshares, dus er is slechts één verbinding van de client-VM naar de server. Deze enkele verbinding wordt gekoppeld aan één kern op de client-VM, zodat de maximale doorvoer die kan worden verkregen vanaf een VIRTUELE machine wordt gebonden door één kern.

Tijdelijke oplossing

  • Schakel voor Premium-bestandsshares SMB meerdere kanalen in.
  • Het verkrijgen van een VIRTUELE machine met een grotere kern kan helpen de doorvoer te verbeteren.
  • Het uitvoeren van de clienttoepassing vanaf meerdere VM's verhoogt de doorvoer.
  • Gebruik waar mogelijk REST API's.
  • Voor NFS Azure-bestandsshares nconnect is beschikbaar. Zie Prestaties van NFS Azure-bestandsshares verbeteren met nconnect.

Langzame prestaties van een Azure-bestandsshare die is gekoppeld aan een Linux-VM

Oorzaak 1: Opslaan in cache

Een mogelijke oorzaak van trage prestaties is het in de cache opslaan uitgeschakeld. Caching kan handig zijn als u herhaaldelijk toegang hebt tot een bestand. Anders kan het een overhead zijn. Controleer of u de cache gebruikt voordat u deze uitschakelt.

Oplossing voor oorzaak 1

Als u wilt controleren of caching is uitgeschakeld, zoekt u de cache= vermelding.

Cache=none geeft aan dat caching is uitgeschakeld. Koppel de share opnieuw met behulp van de standaardkoppelingsopdracht of door expliciet de cache=strict optie toe te voegen aan de koppelingsopdracht om ervoor te zorgen dat de standaardcachingmodus of de 'strikte' cachingmodus is ingeschakeld.

In sommige scenario's kan de serverino koppelingsoptie ertoe leiden dat de ls opdracht wordt uitgevoerd stat op elke mapvermelding. Dit gedrag resulteert in prestatievermindering wanneer u een grote map vermeldt. U kunt de koppelingsopties in uw /etc/fstab-vermelding controleren:

//azureuser.file.core.windows.net/cifs /cifs cifs vers=2.1,serverino,username=xxx,password=xxx,dir_mode=0777,file_mode=0777

U kunt ook controleren of de juiste opties worden gebruikt door de opdracht uit te voeren en de sudo mount | grep cifs uitvoer ervan te controleren. Hier volgt een voorbeeld van uitvoer:

//azureuser.file.core.windows.net/cifs on /cifs type cifs (rw,relatime,vers=2.1,sec=ntlmssp,cache=strict,username=xxx,domain=X,uid=0,noforceuid,gid=0,noforcegid,addr=192.168.10.1,file_mode=0777, dir_mode=0777,persistenthandles,nounix,serverino,mapposix,rsize=1048576,wsize=1048576,actimeo=1)

Als de cache=strict of serverino optie niet aanwezig is, ontkoppelt en koppelt u Azure Files opnieuw door de koppelingsopdracht uit de documentatie uit te voeren. Controleer vervolgens opnieuw of de vermelding /etc/fstab de juiste opties heeft.

Oorzaak 2: beperking

Mogelijk ondervindt u beperking en worden uw aanvragen verzonden naar een wachtrij. U kunt dit controleren door gebruik te maken van metrische gegevens van Azure Storage in Azure Monitor. U kunt ook waarschuwingen maken die u waarschuwen als een share wordt beperkt of op het punt staat te worden beperkt. Zie Problemen met Azure Files oplossen door waarschuwingen te maken.

Oplossing voor oorzaak 2

Zorg ervoor dat uw app binnen de Azure Files-schaaldoelen valt. Als u standaard Azure-bestandsshares gebruikt, kunt u overwegen om over te schakelen naar Premium.

Doorvoer op Linux-clients is lager dan die van Windows-clients

Oorzaak

Dit is een bekend probleem met het implementeren van de SMB-client in Linux.

Tijdelijke oplossing

  • Spreid de belasting over meerdere VM's.
  • Gebruik op dezelfde VIRTUELE machine meerdere koppelpunten met een nosharesock optie en verspreid de belasting over deze koppelpunten.
  • Probeer in Linux te koppelen met een nostrictsync optie om te voorkomen dat SMB wordt leeggemaakt bij elke fsync aanroep. Voor Azure Files heeft deze optie geen invloed op gegevensconsistentie, maar dit kan leiden tot verouderde bestandsmetagegevens in mapvermeldingen (ls -l opdracht). Het rechtstreeks opvragen van metagegevens van bestanden met behulp van de stat opdracht retourneert de meest recente metagegevens van bestanden.

Hoge latenties voor workloads met veel metagegevens met uitgebreide open/dicht-bewerkingen

Oorzaak

Geen ondersteuning voor directoryleases.

Tijdelijke oplossing

  • Vermijd, indien mogelijk, het gebruik van een overmatige ingang voor openen/sluiten op dezelfde map binnen een korte periode.
  • Voor Linux-VM's verhoogt u de cachetime-out voor mapvermeldingen door op te geven als koppelingsoptie actimeo=<sec> . De time-out is standaard 1 seconde, dus een grotere waarde, zoals 30 seconden, kan helpen.
  • Voor CentOS Linux- of Red Hat Enterprise Linux-VM's (RHEL) moet u het systeem upgraden naar CentOS Linux 8.2 of RHEL 8.2. Voor andere Linux-distributies moet u de kernel upgraden naar 5.0 of hoger.

Trage inventarisatie van bestanden en mappen

Oorzaak

Dit probleem kan optreden als er onvoldoende cache is op de clientcomputer voor grote mappen.

Oplossing

U kunt dit probleem oplossen door de DirectoryCacheEntrySizeMax registerwaarde aan te passen zodat grotere mapvermeldingen op de clientcomputer in de cache kunnen worden opgeslagen:

  • Locatie: HKEY_LOCAL_MACHINE\System\CCS\Services\Lanmanworkstation\Parameters
  • Waardenaam: DirectoryCacheEntrySizeMax
  • Waardetype: DWORD

U kunt deze bijvoorbeeld instellen 0x100000 en zien of de prestaties verbeteren.

Trage bestandskopie van en naar Azure-bestandsshares

Mogelijk ziet u trage prestaties wanneer u bestanden probeert over te dragen naar de Azure Files-service. Als u geen specifieke minimale I/O-groottevereiste hebt, raden we u aan 1 MiB te gebruiken als de I/O-grootte voor optimale prestaties.

Bestanden worden langzaam gekopieerd van en naar Azure Files in Windows

  • Als u weet wat de uiteindelijke grootte is van een bestand dat u uitbreidt met schrijfbewerkingen en uw software geen compatibiliteitsproblemen heeft wanneer de ongeschreven staart van het bestand nullen bevat, stelt u de bestandsgrootte vooraf in in plaats van elke schrijfbewerking een uitbreidingsschrijfbewerking te maken.

  • Gebruik de juiste kopieermethode:

    • Gebruik AzCopy voor een overdracht tussen twee bestandsshares.
    • Robocopy gebruiken tussen bestandsshares op een on-premises computer.

Overmatige DirectoryOpen/DirectoryClose-aanroepen

Oorzaak

Als het aantal DirectoryOpen/DirectoryClose-aanroepen een van de belangrijkste API-aanroepen is en u niet verwacht dat de client dat veel aanroepen doet, kan het probleem worden veroorzaakt door de antivirussoftware die is geïnstalleerd op de Azure-client-VM.

Tijdelijke oplossing

Er is een oplossing voor dit probleem beschikbaar in de platformupdate van april voor Windows.

SMB meerdere kanalen worden niet geactiveerd

Oorzaak

Recente wijzigingen in SMB-configuratie-instellingen voor meerdere kanalen zonder opnieuw te koppelen.

Oplossing

  • Nadat de configuratie-instellingen voor meerdere kanalen van de Windows SMB-client of -account zijn gewijzigd, moet u de share ontkoppelen, 60 seconden wachten en de share opnieuw koppelen om de multichannel te activeren.
  • Voor windows-clientbesturingssystemen genereert u IO-belasting met een hoge wachtrijdiepte, bijvoorbeeld QD=8, bijvoorbeeld het kopiëren van een bestand om SMB meerdere kanalen te activeren. Voor serverbesturingssystemen wordt SMB meerdere kanalen geactiveerd met QD=1, wat betekent dat zodra u een IO voor de share start.

Trage prestaties bij het opheffen van bestanden

Afhankelijk van de exacte compressiemethode en de gebruikte uitpakbewerking, kunnen decompressiebewerkingen langzamer worden uitgevoerd op een Azure-bestandsshare dan op uw lokale schijf. Dit komt vaak doordat bij het opheffen van hulpprogramma's een aantal metagegevensbewerkingen worden uitgevoerd tijdens het uitvoeren van de decomprimatie van een gecomprimeerd archief. Voor de beste prestaties raden we u aan om het gecomprimeerde archief van de Azure-bestandsshare naar uw lokale schijf te kopiëren, daar uit te schakelen en vervolgens een kopieerprogramma zoals Robocopy (of AzCopy) te gebruiken om terug te kopiëren naar de Azure-bestandsshare. Met behulp van een hulpprogramma voor kopiëren, zoals Robocopy, kunnen de verminderde prestaties van metagegevensbewerkingen in Azure Files ten opzichte van uw lokale schijf worden gecompenseerd door meerdere threads te gebruiken om gegevens parallel te kopiëren.

Hoge latentie op websites die worden gehost op bestandsshares

Oorzaak

Melding over het wijzigen van bestanden met een groot aantal bestanden op bestandsshares kan leiden tot hoge latentie. Dit gebeurt meestal bij websites die worden gehost op bestandsshares met een diep geneste mapstructuur. Een typisch scenario is een door IIS gehoste webtoepassing waarbij een melding voor bestandswijzigingen wordt ingesteld voor elke map in de standaardconfiguratie. Elke wijziging (ReadDirectoryChangesW) op de share die de client heeft geregistreerd voor pusht een wijzigingsmelding van de bestandsservice naar de client, die systeembronnen neemt en het probleem verslechtert met het aantal wijzigingen. Dit kan leiden tot beperking van delen en leidt dus tot een hogere latentie aan de clientzijde.

Ter bevestiging kunt u Metrische gegevens van Azure gebruiken in de portal.

  1. Ga in Azure Portal naar uw opslagaccount.
  2. Selecteer in het linkermenu onder Bewaking de optie Metrische gegevens.
  3. Selecteer Bestand als de metrische naamruimte voor het bereik van uw opslagaccount.
  4. Selecteer Transacties als de metrische waarde.
  5. Voeg een filter voor ResponseType toe en controleer of aanvragen een antwoordcode hebben van SuccessWithThrottling (voor SMB of NFS) of ClientThrottlingError (voor REST).

Oplossing

  • Als de melding voor bestandswijziging niet wordt gebruikt, schakelt u de melding voor bestandswijziging uit (voorkeur).

  • Verhoog de frequentie van het polling-interval voor bestandswijzigingen om het volume te verminderen.

    Werk het polling-interval voor het W3WP-werkproces bij naar een hogere waarde (bijvoorbeeld 10 of 30 minuten) op basis van uw behoeften. Stel HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\W3SVC\Parameters\ConfigPollMilliSeconds in het register in en start het W3WP-proces opnieuw op.

  • Als de toegewezen fysieke map van uw website een geneste mapstructuur heeft, kunt u proberen het bereik van bestandswijzigingsmeldingen te beperken om het meldingsvolume te verminderen. IIS maakt standaard gebruik van configuratie van Web.config-bestanden in de fysieke map waaraan de virtuele map is toegewezen, evenals in onderliggende mappen in die fysieke map. Als u geen Web.config-bestanden in onderliggende mappen wilt gebruiken, geeft u false het allowSubDirConfig kenmerk in de virtuele map op. Hier vindt u meer informatie.

    Stel de instelling voor virtuele IIS-mappen allowSubDirConfig in Web.Config in om false toegewezen fysieke onderliggende mappen uit te sluiten van het bereik.

Zie ook

Contact met ons opnemen voor ondersteuning

Als u vragen hebt of hulp nodig hebt, maakt u een ondersteuningsaanvraag of stelt u ondersteuning voor de Azure-community. U kunt ook productfeedback verzenden naar de Azure-feedbackcommunity.