SMB Azure 파일 공유 성능 향상

이 문서에서는 SMB 다중 채널 및 메타데이터 캐싱(미리 보기) 사용을 포함하여 프리미엄 SMB Azure 파일 공유의 성능을 향상시키는 방법을 설명합니다.

적용 대상

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

성능 최적화

성능을 최적화하는 데 도움이 되는 팁은 다음과 같습니다.

  • 네트워크 대기 시간을 줄이기 위해 스토리지 계정과 클라이언트가 동일한 Azure 지역에 함께 배치되었는지 확인합니다.
  • 다중 스레드 애플리케이션을 사용하여 부하를 여러 파일에 분산합니다.
  • SMB 다중 채널의 성능 이점은 부하를 분산하는 파일 수가 늘어날수록 더 커집니다.
  • 프리미엄 공유 성능은 프로비저닝된 공유 크기(IOPS/송신/수신) 및 단일 파일 제한에 의해 바인딩됩니다. 자세한 내용은 프리미엄 파일 공유를 위한 프로비저닝 이해를 참조하세요.
  • 단일 VM 클라이언트의 최대 성능은 VM 제한에 계속 바인딩되어 있습니다. 예를 들어 Standard_D32s_v3는 최대 대역폭 16000MBps(또는 2GBps)를 지원할 수 있습니다. VM에서의 송신(스토리지 쓰기)은 측정되었고 수신(스토리지 읽기)은 측정되지 않았습니다. 파일 공유 성능은 머신 네트워크 제한, CPU, 내부 스토리지 사용이 가능한 네트워크 대역폭, IO 크기, 병렬 처리 및 기타 요인에 따라 달라집니다.
  • 초기 테스트는 일반적으로 준비입니다. 결과를 취소하고 테스트를 반복합니다.
  • 단일 클라이언트에 의해 성능이 제한되고 워크로드가 여전히 프로비전된 공유 제한을 밑도는 경우에는, 여러 클라이언트에 부하를 분산하여 성능을 더 높일 수 있습니다.

IOPS, 처리량과 I/O 크기 간의 관계

처리량 = IO 크기 * IOPS

I/O 크기가 클수록 처리량이 늘어나고 지연 시간이 길어져 네트워크 IOPS 수가 줄어듭니다. I/O 크기가 작을수록 IOPS가 높아지지만 네트워크 처리량이 적어지고 지연 시간이 줄어듭니다. 자세한 내용은 Azure Files 성능 이해를 참조하세요.

SMB 다중 채널

SMB 다중 채널을 사용하면 SMB 3.x 클라이언트가 SMB 파일 공유에 대한 다중 네트워크 연결을 설정할 수 있습니다. Azure Files는 프리미엄 파일 공유(FileStorage 스토리지 계정 종류의 파일 공유)에서 SMB 다중 채널을 지원합니다. 서비스 쪽에서 SMB 다중 채널은 Azure Files 사용하지 않도록 기본적으로 설정되지만 사용하도록 설정하기 위한 추가 비용은 없습니다.

이점

SMB 다중 채널을 사용하면 클라이언트는 소유 비용을 줄이는 동시에 성능을 향상시키는 여러 네트워크 연결을 사용할 수 있습니다. 여러 NIC의 대역폭 집계를 통해 성능을 향상시키고 NIC에 대한 RSS(수신측 스케일링) 지원을 활용하여 I/O 부하를 여러 CPU에 분산시킵니다.

  • 향상된 처리량: 다중 연결을 사용하면 여러 경로를 통해 데이터를 병렬로 전송할 수 있으므로, 더 큰 I/O와 파일 크기를 사용하며 더 많은 처리량을 요구하는 워크로드를 단일 VM 또는 더 작은 VM 집합에서도 훌륭히 활용할 수 있습니다. 해당 워크로드에는 콘텐츠 생성 또는 코드 변환, 유전체학, 금융 서비스 위험 분석을 위한 미디어와 엔터테인먼트가 포함됩니다.
  • 높은 IOPS: NIC RSS 기능을 사용하면 다중 연결된 여러 CPU에서 효과적으로 부하를 분산할 수 있습니다. 이렇게 하면 VM CPU의 IOPS 규모를 늘리고 더 효율적으로 활용할 수 있습니다. 데이터베이스 애플리케이션과 같이 I/O 크기가 작은 워크로드에 유용합니다.
  • 네트워크 내결함성: 클라이언트가 더 이상 개별 연결에 의존하지 않으므로 다중 연결은 중단 위험을 완화합니다.
  • 자동 구성: SMB 다중 채널이 클라이언트 및 스토리지 계정에서 사용하도록 설정되면 기존 연결을 동적으로 검색할 수 있으며 필요에 따라 추가 연결 경로를 만들 수 있습니다.
  • 비용 최적화: 프리미엄 공유에 연결했을 때 단일 VM 또는 소규모 VM 세트에서 더 큰 규모의 워크로드를 수행할 수 있습니다. 이렇게 하면 워크로드를 실행하고 관리하는 데 필요한 VM 수를 줄여 총 소유 비용을 줄일 수 있습니다.

SMB 다중 채널에 대한 자세한 내용은 Windows 설명서를 참조하세요.

이 기능은 다중 스레드 애플리케이션의 성능을 크게 향상시키지만 일반적으로 단일 스레드 애플리케이션에는 도움이 되지 않습니다. 자세한 내용은 성능 비교 섹션을 참조하세요.

제한 사항

Azure 파일 공유에 대한 SMB 다중 채널에는 현재 다음과 같은 제한 사항이 있습니다.

  • SMB 3.1.1을 사용하는 Windows 클라이언트에서만 지원됩니다. SMB 클라이언트 운영 체제가 권장 수준으로 패치되었는지 확인합니다.
  • 현재 Linux 클라이언트에 대해 지원되거나 권장되지 않습니다.
  • 최대 채널 수는 4개입니다. 자세한 내용은 여기를 참조하세요.

구성

SMB 다중 채널은 기능이 클라이언트 측(사용자의 클라이언트)과 서비스 측(사용자의 Azure 스토리지 계정) 양쪽에서 사용하도록 설정된 경우에만 작동합니다.

Windows 클라이언트에서 SMB 다중 채널은 기본적으로 사용하도록 설정되어 있습니다. 다음 PowerShell 명령을 실행하여 설정을 확인할 수 있습니다.

Get-SmbClientConfiguration | Select-Object -Property EnableMultichannel

Azure 스토리지 계정에서 SMB 다중 채널을 사용하도록 설정해야 합니다. SMB 다중 채널 사용을 참조하세요.

SMB 다중 채널 사용 안 함

대부분의 시나리오, 특히 다중 스레드 워크로드의 경우 클라이언트는 SMB 다중 채널로 인한 성능 향상을 확인하게 될 것입니다. 하지만 단일 스레드 워크로드와 같은 일부 특정 시나리오, 혹은 테스트 목적으로 SMB 다중 채널을 사용하지 않도록 설정할 수도 있습니다. 자세한 내용은 성능 비교를 참조하세요.

SMB 다중 채널이 올바르게 구성되었는지 확인

  1. 프리미엄 파일 공유를 만들거나 기존 파일 공유를 사용합니다.
  2. 클라이언트에서 SMB 다중 채널을 지원하는지 확인합니다(하나 이상의 네트워크 어댑터에서 수신측 배율을 사용하도록 설정된 경우). 자세한 내용은 Windows 설명서를 참조하세요.
  3. 파일 공유를 클라이언트에 탑재합니다.
  4. 애플리케이션을 사용하여 부하를 생성합니다. robocopy/MT와 같은 복사 도구나 파일 읽기/쓰기를 할 수 있는 Diskspd와 같은 퍼포먼스 툴로 부하를 생성할 수 있습니다.
  5. 관리자 권한으로 PowerShell을 열고 Get-SmbMultichannelConnection |fl 명령을 실행합니다.
  6. MaxChannelsCurrentChannels 속성을 찾습니다.

Screenshot of Get-SMBMultichannelConnection results.

성능 비교

읽기/쓰기 워크로드 패턴에는 단일 스레드 및 다중 스레드의 두 가지 범주가 있습니다. 대부분의 워크로드는 여러 파일을 사용하지만 단일 파일을 공유는 특정한 사용 사례도 있을 수 있습니다. 이 섹션에서는 다양한 사용 사례와 각 사례가 성능에 끼치는 영향을 설명합니다. 일반적으로 대부분의 워크로드는 다중 스레드이며 워크로드를 여러 파일에 분산하여 SMB 다중 채널의 상당한 성능 향상을 확인할 수 있습니다.

  • 다중 스레드/다중 파일: 워크로드 패턴에 따라 다중 채널에 I/O 읽기 및 쓰기 성능의 비약적인 향상을 확인할 수 있습니다. 성능 향상은 IOPS, 처리량, 대기 시간 면에서 2X부터 4X까지 차이가 있습니다. 이 카테고리에서는 최고의 성능을 위해 SMB 다중 채널을 사용하도록 설정해야 합니다.
  • 다중 스레드/단일 파일: 이 카테고리의 대부분의 사용 사례에서는 SMB 다중 채널을 사용한 워크로드, 특히 워크로드의 평균 I/O 크기가 > ~16k인 경우에 성능이 향상됩니다. SMB 다중 채널의 혜택을 받은 몇 가지 예제 시나리오는 큰 크기의 단일 파일 백업 또는 복구입니다. SMB 다중 채널을 사용하지 않도록 설정할 예외 사례는 워크로드 부하가 작은 I/O인 경우 정도입니다. 이 경우에는 ~10% 정도 성능이 약간 저하될 수 있습니다. 사용 사례에 따라 부하를 여러 파일에 분산하거나 기능을 사용하지 않도록 설정하는 것이 좋습니다. 자세한 내용은 구성 섹션을 참조하세요.
  • 단일 스레드/다중 파일 또는 단일 파일: 대부분의 단일 스레드 워크로드의 경우 병렬 처리 부족으로 인해 성능상의 이점이 미미합니다. 일반적으로 SMB 다중 채널을 사용하는 경우 성능이 ~10%로 약간 저하됩니다. 이 경우 한 가지 예외 사례를 제외하고 SMB 다중 채널을 사용하지 않도록 설정하는 게 이상적입니다. 단일 스레드 워크로드에서 여러 파일에 부하를 분산하고 더 큰 I/O 크기(> ~16k)를 평균적으로 사용하는 경우, SMB 다중 채널을 사용하면 성능이 약간 향상됩니다.

성능 테스트 구성

이 문서의 차트에서 사용된 구성은 4개의 채널이 포함된 단일 RSS를 사용하도록 설정된 NIC를 사용하는 단일 표준 D32s v3 VM입니다. 부하는 I/O 깊이 10 및 다양한 I/O 크기의 무작위 I/O로 다중 스레드 처리된 diskspd.exe를 이용해 생성하였습니다.

크기 vCPU 메모리: GiB 임시 스토리지(SSD) GiB 최대 데이터 디스크 수 최대 캐시 및 임시 스토리지 처리량: IOPS/MBps(캐시 크기는 GiB) 최대 캐시되지 않은 디스크 처리량: IOPS/MBps 최대 NIC 수 예상 네트워크 대역폭(Mbps)
Standard_D32s_v3 32 128 256 32 64000/512 (800) 51200/768 8 16000

Screenshot that shows the performance test configuration.

SMB 다중 채널을 사용하는 다중 스레드/복수 파일

다양한 IO 크기의 10개 파일로 부하가 생성되었습니다. 스케일 업 테스트 결과, SMB 다중 채널을 사용하도록 설정된 IOPS 및 처리량 테스트 결과 양쪽 모두에서 상당한 성능 향상을 보였습니다. 다음은 결과를 나타낸 다이어그램입니다.

Diagram of performance.

Diagram of throughput performance.

  • 단일 NIC에서 읽기의 경우 2X에서 3X의 성능 향상이 관찰되었고, 쓰기의 경우 IOPS와 처리량 양쪽 모두 3X-4X의 향상을 기록했습니다.
  • SMB 다중 채널은 IOPS와 처리량이 단일 NIC와 4개 채널로 제한이 걸린 상태에서도 VM의 한계치까지 도달하게 했습니다.
  • 송신 또는 스토리지 읽기는 측정되지 않아서 읽기 처리량은 VM 게시 제한인 16000Mbps(2GiB/s)를 초과할 수 있었습니다. 테스트에서는 >2.7GiB/s를 기록했습니다. 수신 또는 저장소 쓰기에서는 여전히 VM 한계치에 종속되었습니다.
  • 여러 파일에 부하를 분산시킴으로써 상당히 개선되었습니다.

이 테스트에 사용된 예제 명령은 다음과 같습니다.

diskspd.exe -W300 -C5 -r -w100 -b4k -t8 -o8 -Sh -d60 -L -c2G -Z1G z:\write0.dat z:\write1.dat z:\write2.dat z:\write3.dat z:\write4.dat z:\write5.dat z:\write6.dat z:\write7.dat z:\write8.dat z:\write9.dat .

SMB 다중 채널을 사용하는 다중 스레드/단일 파일 워크로드

부하는 단일 128GiB 파일로 생성되었습니다. SMB 다중 채널을 사용하도록 설정했을 때 다중 스레드/단일 파일로 수행한 스케일 업 테스트는 대부분의 사례에서 향상된 결과를 보여 주었습니다. 다음은 결과를 나타낸 다이어그램입니다.

Diagram of IOPS performance.

Diagram of single file throughput performance.

  • 평균 I/O 크기가 더 큰 단일 NIC(> ~16k)에서는 읽기 및 쓰기 성능이 모두 크게 향상되었습니다.
  • 더 작은 I/O 크기의 경우 SMB 다중 채널을 사용하는 경우 성능에 ~10% 정도 약간의 영향을 받았습니다. 부하를 여러 파일에 분산하거나 기능을 사용하지 않도록 설정하여 이 현상을 완화할 수 있었습니다.
  • 성능은 여전히 단일 파일 제한에 의해 바인딩됩니다.

프리미엄 SMB 파일 공유에 대한 메타데이터 캐싱

메타데이터 캐싱은 메타데이터 대기 시간을 줄이고, 사용 가능한 IOPS를 늘리며, 네트워크 처리량을 높이는 것을 목표로 하는 SMB Azure 프리미엄 파일 공유를 위한 향상된 기능입니다. 이 미리 보기 기능은 다음 메타데이터 API를 향상시키고 Windows 및 Linux 클라이언트 모두에서 사용할 수 있습니다.

  • 만들기
  • 열기
  • 닫기
  • 삭제

온보딩하기 위해 공개 미리 보기에 등록하면 추가 세부 정보가 제공됩니다. 현재 이 미리 보기 기능은 프리미엄 SMB 파일 공유(FileStorage 스토리지 계정 종류의 파일 공유)에만 사용할 수 있습니다. 이 기능 사용과 관련된 추가 비용은 없습니다.

국가별 가용성

현재 메타데이터 캐싱 미리 보기는 다음 Azure 지역에서만 사용할 수 있습니다.

  • 오스트레일리아 동부
  • 브라질 남동부
  • 프랑스 남부
  • 독일 중서부
  • 스위스 북부
  • 아랍에미리트 중부
  • 아랍에미리트 북부
  • 미국 중서부

메타데이터 캐싱을 통한 성능 향상

메타데이터를 포함하는 대부분의 워크로드 또는 사용 패턴은 메타데이터 캐싱의 이점을 누릴 수 있습니다. 워크로드에 메타데이터가 포함되어 있는지 확인하려면 Azure Monitor를 사용하여 트랜잭션을 API 차원별로 분할할 수 있습니다.

일반적인 메타데이터 집약적 워크로드 및 사용 패턴은 다음과 같습니다.

  • 웹/앱 서비스
  • DevOps 작업
  • 인덱싱/일괄 처리 작업
  • 주로 많은 작은 파일, 디렉터리 또는 핸들과 상호 작용하는 홈 디렉터리 또는 기타 워크로드가 있는 가상 데스크톱

다음 다이어그램에서는 잠재적인 결과를 보여 줍니다.

메타데이터 대기 시간 단축

향후 조회를 위해 파일 및 디렉터리 경로를 캐싱함으로써 메타데이터 캐싱은 대규모 메타데이터 집약적 워크로드에 자주 액세스하는 파일 및 디렉터리의 대기 시간을 30% 이상 줄일 수 있습니다.

Chart showing latency in milliseconds with and without metadata caching.

사용 가능한 IOPS 늘리기

메타데이터 캐싱은 대규모 메타데이터 집약적 워크로드의 경우 사용 가능한 IOPS를 60% 이상 늘릴 수 있습니다.

Chart showing available IOPS with and without metadata caching.

네트워크 처리량 증가

메타데이터 캐싱은 메타데이터 집약적 워크로드의 네트워크 처리량을 60% 이상 증가시킬 수 있습니다.

Chart showing network throughput with and without metadata caching.

다음 단계