Azure Files 성능 문제 해결

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

적용 대상

파일 공유 유형	중소기업	네트워크 파일 시스템 (NFS)
표준 파일 공유(GPv2), LRS/ZRS
표준 파일 공유(GPv2), GRS/GZRS
프리미엄 파일 공유(FileStorage), LRS/ZRS

일반 성능 문제 해결

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

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

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

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

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

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

공유 수준 또는 스토리지 계정 수준에서 제한으로 인해 어떻게 긴 대기 시간, 낮은 처리량, 일반적인 성능 문제가 발생할 수 있는지 알아보려면 공유 또는 스토리지 계정이 제한되고 있음을 참조하세요.

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

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

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

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

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

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

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

5. 응답 형식에 대한 필터를 추가한 다음, 요청이 제한되었는지 여부를 확인합니다.

   표준 파일 공유의 경우 클라이언트 계정 수준에서 요청이 제한되면 다음 응답 형식이 기록됩니다.

   • 클라이언트 계정 요청 제한 오류
   • 클라이언트 계정 대역폭 제한 오류

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

   • 공유 이그레스 제한 성공
   • 공유 진입 제어 성공
   • 성공적인 공유 IOPS 조절
   • ClientShareEgressThrottlingError
   • ClientShareIngress 쓰로틀링 오류
   • 클라이언트 공유 IOPS 스로틀링 오류(ClientShareIopsThrottlingError)

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

   • Kerberos 성공 시 공유 송출 제한 설정
   • KerberosSuccessWithShareIngressThrottling (Kerberos 공유 인그레스 제한과 함께 성공)

   각 응답 형식에 대해 자세히 알아보려면 메트릭 차원을 참조하세요.

   

해결 방법

프리미엄 파일 공유를 사용하는 경우 프로비전된 파일 공유 크기를 늘려 IOPS 제한을 늘입니다. 자세한 내용은 프리미엄 파일 공유를 위한 프로비저닝 이해하기를 참조하세요.

원인 2: 메타데이터 또는 네임스페이스에 워크로드가 과도함

대부분의 요청이 메타데이터 중심이라면(예: createfile, openfile, closefile, queryinfo 또는 querydirectory) 대기 시간이 읽기/쓰기 작업에서보다 늘어날 수 있습니다.

대부분의 요청이 메타데이터 중심인지 확인하려면 먼저 원인 1에 설명된 대로 1-4단계를 수행합니다. 5단계의 경우 응답 형식에 대한 필터를 추가하는 대신 API 이름에 대한 속성 필터를 추가합니다. 자세한 내용은 메타데이터 IOPS별 사용률 모니터링을 참조하세요.

해결 방법

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

• 프리미엄 SMB Azure 파일 공유를 사용하는 경우 메타데이터 캐싱을 사용합니다.

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

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

  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)를 사용합니다. 이 작은 값은 대용량 파일의 읽기 처리량을 줄일 수 있습니다.

해결 방법

커널 매개 변수 값을 MiB(15메비바이트)로 늘리는 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에서 달성할 수 있는 최대 처리량은 단일 코어에 의해 바인딩됩니다.

해결 방법

• 프리미엄 파일 공유의 경우 SMB 다중 채널을 사용하도록 설정합니다.
• 더 큰 코어로 VM을 확보하면 처리량을 개선하는 데 도움이 될 수 있습니다.
• 여러 VM에서 클라이언트 애플리케이션을 실행하면 처리량이 증가합니다.
• 가능한 경우 REST API를 사용합니다.
• NFS Azure 파일 공유에 대해 nconnect를 사용할 수 있습니다. nconnect를 사용하여 NFS Azure 파일 공유 성능 향상을 참조하세요.

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 옵션이 없는 경우 설명서에서 탑재 명령을 실행하여 Azure Files를 분리하고 다시 탑재합니다. 그런 다음 /etc/fstab 항목에 올바른 옵션이 있는지 다시 확인합니다.

원인 2: 스로틀링

요청이 제한을 받을 가능성이 있으며, 요청이 큐로 전송되고 있을 수 있습니다. Azure Monitor에서 Azure Storage 메트릭을 활용하여 이를 확인할 수 있습니다. 공유가 제한되거나 제한될 예정인 경우에 대해 알림을 설정할 수도 있습니다. 경고를 만들어 Azure Files 문제 해결을 참조하세요.

원인 2의 해결 방법

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

원인 3: Azure 파일 공유가 용량에 도달

Azure 파일 공유가 용량에 근접한 경우 중요한 단계는 스토리지를 최적화하기 위해 가장 큰 파일 및 디렉터리를 식별하는 것입니다. 이 단계는 가장 많은 공간을 사용하는 파일 및 폴더를 이해하는 데 도움이 됩니다.

해결 방법

전체 공유에서 스토리지 사용량을 포괄적으로 보려면 공유의 루트를 탑재합니다. 이 작업을 통해 파일 및 디렉터리 크기를 철저히 검사할 수 있습니다. 파일 공유의 루트에서 다음 명령을 실행하여 가장 큰 파일 및 디렉터리를 식별합니다.

	cd /path/to/mount/point
	du -ah --max-depth=1 | sort -rh | head -n 20

이 명령은 20개의 가장 큰 파일 및 디렉터리를 내림차순으로 표시합니다. 이 디스플레이는 스토리지 사용량에 대한 명확한 개요를 제공합니다.

공유의 루트를 탑재할 수 없는 경우 Azure Storage Explorer 또는 타사 도구를 사용하여 스토리지 사용량을 분석합니다. 이러한 도구는 공유를 탑재할 필요 없이 파일 및 디렉터리 크기에 대한 유사한 인사이트를 제공합니다.

Linux 클라이언트의 처리량이 Windows 클라이언트의 처리량보다 적음

원인

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

해결 방법

• 부하를 여러 VM에 분산합니다.
• 동일한 VM에서 옵션이 있는 nosharesock 여러 탑재 지점을 사용하고 이러한 탑재 지점에 부하를 분산합니다.
• Linux에서 fsync 호출마다 SMB 플러시가 강제되지 않도록 nostrictsync 옵션을 사용하여 마운트를 시도하세요. Azure Files의 경우 이 옵션은 데이터 일관성을 방해하지 않지만 디렉터리 목록(ls -l 명령)에서 부실 파일 메타데이터를 발생시킬 수 있습니다. 명령을 사용하여 파일 메타데이터를 직접 쿼리하면 stat 가장 up-to날짜 파일 메타데이터가 반환됩니다.

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

원인

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

해결 방법

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

파일 및 폴더의 느린 열거

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

Azure 파일 공유로의 느린 파일 복사 및 Azure 파일 공유에서의 느린 파일 복사

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

과도한 DirectoryOpen/DirectoryClose 호출

원인

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

해결 방법

이 문제에 대한 해결 방법은 Windows용 4월 플랫폼 업데이트에서 확인할 수 있습니다.

SMB 다중 채널이 작동되지 않음

원인

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

해결 방법

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

파일 압축을 풀 때 성능 저하

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

파일 공유에서 호스트되는 웹 사이트의 높은 대기 시간

원인

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

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

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

해결 방법

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

  • FCNMode를 업데이트하여 파일 변경 알림을 사용하지 않도록 설정합니다.
  • 레지스트리에서 설정 HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\W3SVC\Parameters\ConfigPollMilliSeconds 하여 W3WP(IIS 작업자 프로세스) 폴링 간격을 0으로 업데이트하고 W3WP 프로세스를 다시 시작합니다. 이 설정에 대해 알아보려면 IIS의 여러 부분에서 사용되는 공통 레지스트리 키를 참조하세요.

• 볼륨을 줄이기 위해 파일 변경 알림 폴링 간격의 빈도를 늘립니다.

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

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

  Web.Config에서 IIS 가상 디렉터리 allowSubDirConfig 설정을 설정하여 false 매핑된 물리적 자식 디렉터리를 범위에서 제외합니다.

참고하십시오

• Azure 파일 문제 해결
• 경고를 만들어 Azure Files 문제 해결
• Azure Files 성능 이해
• Microsoft Azure의 경고 개요
• Azure Files FAQ

도움을 요청하십시오.

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