Azure Files 성능 문제 해결

  • 아티클

참고

이 문서에서 참조하는 CentOS는 Linux 배포판이며 EOL(수명 종료)에 도달합니다. 사용을 고려하고 그에 따라 계획하십시오. 자세한 내용은 CentOS 수명 종료 지침을 참조하세요.

이 문서에서는 Azure 파일 공유 성능과 관련된 일반적인 문제를 나열하고 잠재적인 원인 및 해결 방법을 제공합니다. 이 문제 해결 가이드에서 가장 많은 가치를 얻으려면 먼저 Azure Files 성능 이해를 읽는 것이 좋습니다.

적용 대상

파일 공유 형식 SMB Nfs
표준 파일 공유(GPv2), LRS/ZRS
표준 파일 공유(GPv2), GRS/GZRS
프리미엄 파일 공유(FileStorage), LRS/ZRS

일반 성능 문제 해결

먼저 성능 문제가 발생할 수 있는 몇 가지 일반적인 이유를 배제합니다.

이전 운영 체제를 실행하고 있습니다.

클라이언트 VM(가상 머신)이 Windows 8.1 또는 Windows Server 2012 R2 또는 이전 Linux 배포판 또는 커널을 실행하는 경우 Azure 파일 공유에 액세스할 때 성능 문제가 발생할 수 있습니다. 클라이언트 OS를 업그레이드하거나 아래 수정 사항을 적용합니다.

Windows 8.1 및 Windows Server 2012 R2에 대한 고려 사항

Windows 8.1 또는 Windows Server 2012 R2를 실행하는 클라이언트는 I/O 집약적 워크로드에 대한 Azure 파일 공유에 액세스할 때 예상보다 높은 대기 시간을 볼 수 있습니다. KB3114025 핫픽스가 설치되어 있는지 확인합니다. 이 핫픽스는 핸들 만들기 및 닫기의 성능을 향상시킵니다.

다음 스크립트를 실행하여 핫픽스가 설치되었는지 여부를 검사 수 있습니다.

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

핫픽스가 설치되면 다음 출력이 표시됩니다.

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

참고

Azure Marketplace Windows Server 2012 R2 이미지에는 기본적으로 2015년 12월부터 핫픽스 KB3114025 설치되어 있습니다.

워크로드가 제한되고 있습니다.

파일 공유에 대한 IOPS(초당 I/O 작업), 수신 또는 송신 제한에 도달하면 요청이 제한됩니다. 예를 들어 클라이언트가 기준 IOPS를 초과하는 경우 Azure Files 서비스에 의해 제한됩니다. 제한으로 인해 클라이언트의 성능이 저하될 수 있습니다.

표준 및 프리미엄 파일 공유에 대한 제한을 이해하려면 파일 공유 및 파일 크기 조정 대상을 참조하세요. 워크로드에 따라 표준에서 프리미엄 Azure 파일 공유로 이동하여 제한을 피할 수 있는 경우가 많습니다.

공유 수준 또는 스토리지 계정 수준에서 제한이 높은 대기 시간, 낮은 처리량 및 일반적인 성능 문제를 일으키는 방법에 대한 자세한 내용은 공유 또는 스토리지 계정이 제한되고 있음을 참조하세요.

높은 대기 시간, 낮은 처리량 또는 낮은 IOPS

원인 1: 공유 또는 스토리지 계정이 제한되고 있습니다.

공유 또는 스토리지 계정이 제한되고 있는지 확인하려면 포털에서 Azure 메트릭에 액세스하고 사용할 수 있습니다. 공유가 제한되거나 제한될 경우 사용자에게 알리는 경고를 만들 수도 있습니다. 경고를 만들어 Azure Files 문제 해결을 참조하세요.

중요

LFS(큰 파일 공유)가 사용하도록 설정된 표준 스토리지 계정의 경우 계정 수준에서 제한이 발생합니다. LFS 사용하도록 설정되지 않은 프리미엄 파일 공유 및 표준 파일 공유의 경우 공유 수준에서 제한이 발생합니다.

  1. Azure Portal 스토리지 계정으로 이동합니다.

  2. 왼쪽 창의 모니터링에서 메트릭을 선택합니다.

  3. 스토리지 계정 scope 메트릭 네임스페이스로 파일을 선택합니다.

  4. 메트릭으로 트랜잭션 을 선택합니다.

  5. 응답 유형에 대한 필터를 추가한 다음 검사 요청이 제한되었는지 확인합니다.

    대용량 파일 공유를 사용하도록 설정하지 않은 표준 파일 공유의 경우 요청이 공유 수준에서 제한되면 다음 응답 형식이 기록됩니다.

    • SuccessWithThrottling
    • SuccessWithShareIopsThrottling
    • ClientShareIopsThrottlingError

    대용량 파일 공유를 사용하도록 설정된 표준 파일 공유의 경우 요청이 클라이언트 계정 수준에서 제한되는 경우 다음 응답 형식이 기록됩니다.

    • ClientAccountRequestThrottlingError
    • ClientAccountBandwidthThrottlingError

    프리미엄 파일 공유의 경우 공유 수준에서 요청이 제한되면 다음 응답 형식이 기록됩니다.

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

    제한된 요청이 Kerberos로 인증된 경우 다음과 같은 인증 프로토콜을 나타내는 접두사를 볼 수 있습니다.

    • KerberosSuccessWithShareEgressThrottling
    • KerberosSuccessWithShareIngressThrottling

    각 응답 유형에 대한 자세한 내용은 메트릭 차원을 참조하세요.

    '응답 유형' 속성 필터를 보여 주는 스크린샷

해결 방법

원인 2: 메타데이터 또는 네임스페이스가 많은 워크로드

대부분의 요청이 메타데이터 중심(예: createfile, , openfileclosefile, queryinfo또는 querydirectory)인 경우 대기 시간은 읽기/쓰기 작업의 대기 시간보다 더 나쁩니다.

대부분의 요청이 메타데이터 중심인지 여부를 확인하려면 먼저 원인 1에 설명된 대로 1-4단계를 수행합니다. 5단계의 경우 응답 유형에 대한 필터를 추가하는 대신 API 이름에 대한 속성 필터를 추가합니다.

'API 이름' 속성 필터를 보여 주는 스크린샷

대안

  • 메타데이터 작업 수를 줄이기 위해 애플리케이션을 수정할 수 있는지 확인합니다.

  • 파일 공유를 동일한 스토리지 계정 내의 여러 파일 공유로 구분합니다.

  • 파일 공유에 VHD(가상 하드 디스크)를 추가하고 클라이언트에서 VHD를 탑재하여 데이터에 대한 파일 작업을 수행합니다. 이 방법은 단일 기록기/읽기 권한자 시나리오 또는 여러 판독기가 있고 기록기가 없는 시나리오에 대해 작동합니다. 파일 시스템은 Azure Files 아닌 클라이언트가 소유하므로 메타데이터 작업을 로컬로 사용할 수 있습니다. 이 설정은 로컬 직접 연결된 스토리지와 유사한 성능을 제공합니다. 그러나 데이터는 VHD에 있으므로 REST API와 같은 SMB 탑재 이외의 다른 수단이나 Azure Portal 통해 액세스할 수 없습니다.

    1. Azure 파일 공유에 액세스해야 하는 컴퓨터에서 스토리지 계정 키를 사용하여 파일 공유를 탑재하고 사용 가능한 네트워크 드라이브(예: Z:)에 매핑합니다.
    2. 디스크 관리로 이동하여 작업 > VHD 만들기를 선택합니다.
    3. Azure 파일 공유가 매핑된 네트워크 드라이브로 위치를 설정하고, 필요에 따라 가상 하드 디스크 크기를 설정하고, 고정 크기를 선택합니다.
    4. 확인을 선택합니다. VHD 만들기가 완료되면 자동으로 탑재되고 할당되지 않은 새 디스크가 나타납니다.
    5. 알 수 없는 새 디스크를 마우스 오른쪽 단추로 클릭하고 디스크 초기화를 선택합니다.
    6. 할당되지 않은 영역을 마우스 오른쪽 단추로 클릭하고 새 단순 볼륨을 만듭니다.
    7. 디스크 관리에 읽기/쓰기 액세스 권한이 있는 이 VHD를 나타내는 새 드라이브 문자가 표시됩니다(예: E:). 파일 탐색기 매핑된 Azure 파일 공유의 네트워크 드라이브에 새 VHD가 표시됩니다(이 예제에서는 Z:). 명확히 하려면 Z:의 표준 Azure 파일 공유 네트워크 매핑과 E: 드라이브의 VHD 매핑이라는 두 개의 드라이브 문자가 있어야 합니다.
    8. VHD 매핑 드라이브(E:)의 파일에 대한 무거운 메타데이터 작업과 Azure 파일 공유 매핑 드라이브(Z:)의 성능이 훨씬 향상되어야 합니다. 원하는 경우 매핑된 네트워크 드라이브(Z:)의 연결을 끊고 탑재된 VHD 드라이브(E:)에 계속 액세스할 수 있어야 합니다.
    • Windows 클라이언트에 VHD를 탑재하려면 PowerShell cmdlet을 Mount-DiskImage 사용할 수도 있습니다.
    • Linux에 VHD를 탑재하려면 Linux 배포에 대한 설명서를 참조하세요. 다음은 예제입니다.

원인 3: 단일 스레드 애플리케이션

사용 중인 애플리케이션이 단일 스레드인 경우 이 설정은 프로비전된 공유 크기에 따라 가능한 최대 처리량보다 IOPS 처리량이 훨씬 낮아질 수 있습니다.

해결 방법

  • 스레드 수를 늘려 애플리케이션 병렬 처리를 늘립니다.
  • 병렬 처리가 가능한 애플리케이션으로 전환합니다. 예를 들어 복사 작업의 경우 Windows 클라이언트의 AzCopy 또는 RoboCopy 또는 Linux 클라이언트의 병렬 명령을 사용할 수 있습니다.

원인 4: SMB 채널 수가 4개를 초과합니다.

SMB MultiChannel을 사용하고 있고 채널 수가 4개를 초과하는 경우 성능이 저하됩니다. 연결 수가 4를 초과하는지 확인하려면 PowerShell cmdlet get-SmbClientConfiguration 을 사용하여 현재 연결 수 설정을 확인합니다.

해결 방법

총 채널이 4개를 초과하지 않도록 SMB에 대한 NIC당 Windows 설정을 설정합니다. 예를 들어 NIC가 두 개 있는 경우 PowerShell cmdlet Set-SmbClientConfiguration -ConnectionCountPerRssNetworkInterface 2을 사용하여 NIC당 최대값을 2로 설정할 수 있습니다.

원인 5: 미리 읽기 크기가 너무 작음(NFS만 해당)

Linux 커널 버전 5.4부터 Linux NFS 클라이언트는 기본 read_ahead_kb 값인 128kibibytes(KiB)를 사용합니다. 이 작은 값은 대용량 파일의 읽기 처리량을 줄일 수 있습니다.

해결 방법

커널 매개 변수 값을 15메비바이트(MiB)로 늘리는 read_ahead_kb 것이 좋습니다. 이 값을 변경하려면 Linux 커널 디바이스 관리자인 udev에 규칙을 추가하여 미리 읽기 크기를 영구적으로 설정합니다. 다음 단계를 따릅니다.

  1. 텍스트 편집기에서 다음 텍스트를 입력하고 저장하여 /etc/udev/rules.d/99-nfs.rules 파일을 만듭니다.

    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. 콘솔에서 udevadm 명령을 슈퍼 사용자로 실행하고 규칙 파일 및 기타 데이터베이스를 다시 로드하여 udev 규칙을 적용합니다. udev가 새 파일을 인식하도록 하려면 이 명령을 한 번만 실행하면 됩니다.

    sudo udevadm control --reload

요청에 대한 대기 시간이 매우 짧음

원인

클라이언트 VM은 파일 공유와 다른 지역에 있을 수 있습니다. 대기 시간이 긴 다른 이유는 클라이언트 또는 네트워크로 인한 대기 시간 때문일 수 있습니다.

해결 방법

  • 파일 공유와 동일한 지역에 있는 VM에서 애플리케이션을 실행합니다.
  • 스토리지 계정의 경우 Azure Portal Azure Monitor를 통해 트랜잭션 메트릭 SuccessE2ELatency 및 SuccessServerLatency를 검토합니다. SuccessE2ELatency와 SuccessServerLatency 메트릭 값 간의 높은 차이는 네트워크 또는 클라이언트로 인해 발생할 수 있는 대기 시간을 나타냅니다. Azure Files 모니터링 데이터 참조의 트랜잭션 메트릭을 참조하세요.

클라이언트가 네트워크에서 지원하는 최대 처리량을 달성할 수 없음

원인

한 가지 잠재적인 원인은 표준 파일 공유에 대한 SMB 다중 채널 지원 부족입니다. 현재 Azure Files 표준 파일 공유에 대해 단일 채널만 지원하므로 클라이언트 VM에서 서버로의 연결은 하나만 있습니다. 이 단일 연결은 클라이언트 VM의 단일 코어에 고정되므로 VM에서 달성할 수 있는 최대 처리량은 단일 코어로 바인딩됩니다.

해결 방법

Linux VM에 탑재된 Azure 파일 공유의 성능 저하

원인 1: 캐싱

성능 저하의 원인 중 하나는 캐싱을 사용하지 않도록 설정하기 위한 것입니다. 캐싱은 파일에 반복적으로 액세스하는 경우에 유용할 수 있습니다. 그렇지 않으면 오버헤드가 될 수 있습니다. 캐시를 사용하지 않도록 설정하기 전에 캐시를 사용하고 있는지 확인합니다.

원인 1에 대한 해결 방법

캐싱을 사용하지 않도록 설정할지 여부를 검사 항목을 찾습니다cache=.

Cache=none 는 캐싱을 사용하지 않도록 설정되었음을 나타냅니다. 기본 탑재 명령을 사용하거나 탑재 명령에 옵션을 명시적으로 추가하여 cache=strict 기본 캐싱 또는 "엄격한" 캐싱 모드를 사용하도록 설정하여 공유를 다시 탑재합니다.

일부 시나리오에서는 탑재 옵션으로 serverino 인해 명령이 ls 모든 디렉터리 항목에 대해 실행 stat 될 수 있습니다. 이 동작은 큰 디렉터리를 나열할 때 성능이 저하됩니다. /etc/fstab 항목에서 탑재 옵션을 검사 수 있습니다.

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

명령을 실행하고 sudo mount | grep cifs 출력을 확인하여 올바른 옵션을 사용하고 있는지 여부를 검사 수도 있습니다. 다음은 출력 예제입니다.

//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)

cache=strict 또는 serverino 옵션이 없는 경우 설명서에서 mount 명령을 실행하여 Azure Files 탑재 해제하고 다시 탑재합니다. 그런 다음 /etc/fstab 항목에 올바른 옵션이 있는지 다시 확인합니다.

원인 2: 제한

제한이 발생하고 요청이 큐로 전송될 수 있습니다. Azure Monitor에서 Azure Storage 메트릭을 활용하여 이를 확인할 수 있습니다. 공유가 제한되거나 제한될 경우 사용자에게 알리는 경고를 만들 수도 있습니다. 경고를 만들어 Azure Files 문제 해결을 참조하세요.

원인 2에 대한 해결 방법

앱이 Azure Files 확장 대상 내에 있는지 확인합니다. 표준 Azure 파일 공유를 사용하는 경우 프리미엄으로 전환하는 것이 좋습니다.

Linux 클라이언트의 처리량이 Windows 클라이언트의 처리량보다 낮습니다.

원인

이는 Linux에서 SMB 클라이언트를 구현하는 데 알려진 문제입니다.

해결 방법

  • 부하를 여러 VM에 분산합니다.
  • 동일한 VM에서 옵션과 함께 nosharesock 여러 탑재 지점을 사용하고 이러한 탑재 지점에 부하를 분산합니다.
  • Linux에서 모든 fsync 호출에서 nostrictsync SMB 플러시를 강제로 적용하지 않도록 옵션을 사용하여 탑재해 보세요. Azure Files 경우 이 옵션은 데이터 일관성을 방해하지 않지만 디렉터리 목록(ls -l명령)에서 파일 메타데이터가 부실할 수 있습니다. 명령을 사용하여 stat 파일 메타데이터를 직접 쿼리하면 최신 파일 메타데이터가 반환됩니다.

광범위한 개방형/닫기 작업과 관련된 메타데이터가 많은 워크로드에 대한 높은 대기 시간

원인

디렉터리 임대에 대한 지원 부족.

해결 방법

  • 가능하면 짧은 시간 내에 동일한 디렉터리에 과도한 열기/닫기 핸들을 사용하지 마세요.
  • Linux VM의 경우 탑재 옵션으로 를 지정 actimeo=<sec> 하여 디렉터리 항목 캐시 시간 제한을 늘입니다. 기본적으로 시간 제한은 1초이므로 30초와 같은 더 큰 값이 도움이 될 수 있습니다.
  • CentOS Linux 또는 RHEL(Red Hat Enterprise Linux) VM의 경우 시스템을 CentOS Linux 8.2 또는 RHEL 8.2로 업그레이드합니다. 다른 Linux 배포판의 경우 커널을 5.0 이상으로 업그레이드합니다.

파일 및 폴더의 느린 열거형

원인

이 문제는 큰 디렉터리에 대한 클라이언트 컴퓨터에 캐시가 충분하지 않은 경우에 발생할 수 있습니다.

해결 방법

이 문제를 resolve 클라이언트 컴퓨터에서 더 큰 디렉터리 목록을 캐싱할 수 있도록 레지스트리 값을 조정 DirectoryCacheEntrySizeMax 합니다.

  • 위치: HKEY_LOCAL_MACHINE\System\CCS\Services\Lanmanworkstation\Parameters
  • 값 이름: DirectoryCacheEntrySizeMax
  • 값 유형: DWORD

예를 들어 로 설정하고 0x100000 성능이 향상되는지 확인할 수 있습니다.

Azure 파일 공유로 또는 Azure 파일 공유에서 파일 복사 속도가 느림

Azure Files 서비스로 파일을 전송하려고 할 때 성능이 저하될 수 있습니다. 특정 최소 I/O 크기 요구 사항이 없는 경우 최적의 성능을 위해 I/O 크기로 1MiB를 사용하는 것이 좋습니다.

Windows에서 Azure Files 파일 복사 속도 저하

  • 쓰기를 사용하여 확장하는 파일의 최종 크기를 알고 있고 파일의 기록되지 않은 꼬리에 0이 포함되어 있을 때 소프트웨어에 호환성 문제가 없는 경우 모든 쓰기를 확장 쓰기로 만드는 대신 파일 크기를 미리 설정합니다.

  • 올바른 복사 방법을 사용합니다.

    • 두 파일 공유 간의 전송에 AzCopy 를 사용합니다.
    • 온-프레미스 컴퓨터의 파일 공유 간에 Robocopy 를 사용합니다.

과도한 DirectoryOpen/DirectoryClose 호출

원인

DirectoryOpen/DirectoryClose 호출 수가 상위 API 호출 중 하나이고 클라이언트가 많은 호출을 수행할 것으로 예상하지 않는 경우 Azure 클라이언트 VM에 설치된 바이러스 백신 소프트웨어로 인해 문제가 발생할 수 있습니다.

해결 방법

이 문제에 대한 수정 사항은 Windows용 4월 플랫폼 업데이트에서 사용할 수 있습니다.

SMB 다중 채널이 트리거되지 않음

원인

다시 탑재하지 않고 SMB 다중 채널 구성 설정에 대한 최근 변경 내용입니다.

해결 방법

  • Windows SMB 클라이언트 또는 계정 SMB 다중 채널 구성 설정을 변경한 후에는 공유를 분리하고, 60초 동안 기다린 다음, 공유를 다시 탑재하여 다중 채널을 트리거해야 합니다.
  • Windows 클라이언트 OS의 경우 QD=8과 같이 큐 깊이가 높은 IO 로드를 생성합니다(예: 파일을 복사하여 SMB 다중 채널 트리거). 서버 OS의 경우 SMB 다중 채널은 QD=1로 트리거됩니다. 즉, 공유에 대한 IO를 시작하는 즉시 를 의미합니다.

파일 압축을 풀 때 성능 저하

사용되는 정확한 압축 방법 및 압축 해제 작업에 따라 압축 해제 작업은 로컬 디스크보다 Azure 파일 공유에서 더 느리게 수행될 수 있습니다. 압축 해제 도구는 압축된 보관 파일의 압축 해제를 수행하는 과정에서 여러 메타데이터 작업을 수행하기 때문입니다. 최상의 성능을 위해 압축된 보관 파일을 Azure 파일 공유에서 로컬 디스크로 복사하고 압축을 풀고 Robocopy(또는 AzCopy)와 같은 복사 도구를 사용하여 Azure 파일 공유로 다시 복사하는 것이 좋습니다. Robocopy와 같은 복사 도구를 사용하면 여러 스레드를 사용하여 데이터를 병렬로 복사하여 로컬 디스크를 기준으로 Azure Files 메타데이터 작업의 성능 저하를 보정할 수 있습니다.

파일 공유에서 호스트되는 웹 사이트의 대기 시간이 짧습니다.

원인

파일 공유에 대한 파일 변경 알림 수가 많을 경우 대기 시간이 높아질 수 있습니다. 이는 일반적으로 깊은 중첩된 디렉터리 구조의 파일 공유에서 호스트되는 웹 사이트에서 발생합니다. 일반적인 시나리오는 IIS 호스팅 웹 애플리케이션으로, 기본 구성의 각 디렉터리에 대해 파일 변경 알림이 설정됩니다. 클라이언트가 등록되어 있는 공유의 각 변경 내용(ReadDirectoryChangesW)은 파일 서비스에서 클라이언트로 변경 알림을 푸시하여 시스템 리소스를 사용하고 변경 횟수에 따라 문제가 악화됩니다. 이로 인해 공유 제한이 발생하여 클라이언트 쪽 대기 시간이 길어질 수 있습니다.

확인하려면 포털에서 Azure 메트릭을 사용할 수 있습니다.

  1. Azure Portal 스토리지 계정으로 이동합니다.
  2. 왼쪽 메뉴의 모니터링에서 메트릭을 선택합니다.
  3. 스토리지 계정 scope 메트릭 네임스페이스로 파일을 선택합니다.
  4. 메트릭으로 트랜잭션 을 선택합니다.
  5. ResponseType 및 검사 대한 필터를 추가하여 요청의 응답 코드 SuccessWithThrottling (SMB 또는 NFS의 경우) 또는 ClientThrottlingError (REST의 경우)가 있는지 확인합니다.

해결 방법

  • 파일 변경 알림을 사용하지 않는 경우 파일 변경 알림(기본 설정)을 사용하지 않도록 설정합니다.

  • 파일 변경 알림 폴링 간격의 빈도를 늘려 볼륨을 줄입니다.

    요구 사항에 따라 W3WP 작업자 프로세스 폴링 간격을 더 높은 값(예: 10분 또는 30분)으로 업데이트합니다. 레지스트리에서 를 설정하고 HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\W3SVC\Parameters\ConfigPollMilliSeconds W3WP 프로세스를 다시 시작합니다.

  • 웹 사이트의 매핑된 실제 디렉터리에 중첩된 디렉터리 구조가 있는 경우 파일 변경 알림의 scope 제한하여 알림 볼륨을 줄일 수 있습니다. 기본적으로 IIS는 가상 디렉터리가 매핑되는 실제 디렉터리의 Web.config 파일과 해당 물리적 디렉터리의 모든 자식 디렉터리의 구성을 사용합니다. 자식 디렉터리에서 Web.config 파일을 사용하지 않으려면 가상 디렉터리의 특성에 대해 allowSubDirConfig 를 지정 false 합니다. 자세한 내용은 여기에서 확인할 수 있습니다.

    Web.ConfigIIS 가상 디렉터리 allowSubDirConfig 설정을 로 설정하여 false 매핑된 물리적 자식 디렉터리를 scope 제외합니다.

참고 항목

도움을 요청하십시오.

질문이 있거나 도움이 필요한 경우 지원 요청을 생성하거나Azure 커뮤니티 지원에 문의하세요. Azure 피드백 커뮤니티에 제품 피드백을 제출할 수도 있습니다.