다음을 통해 공유


Azure NetApp Files의 SMB 성능 모범 사례

이 문서는 Azure NetApp Files의 SMB 성능 및 모범 사례를 이해하는 데 도움이 됩니다.

SMB 다중 채널

SMB 다중 채널은 SMB 공유에서 기본적으로 사용할 수 있습니다. 기존 SMB 볼륨보다 이전의 모든 SMB 공유에는 해당 기능이 사용하도록 설정되어 있으며, 새로 만들어진 모든 볼륨에도 만들기 시점에 해당 기능이 사용하도록 설정되어 있습니다.

SMB 다중 채널 기능을 활용하려면 해당 기능이 사용하도록 설정되기 전에 설정된 모든 SMB 연결을 다시 설정해야 합니다. 재설정하려면 SMB 공유 연결을 끊었다가 다시 연결할 수 있습니다.

Windows는 최상의 성능을 사용할 수 있도록 Windows 2012 이후 SMB 다중 채널을 지원합니다. 자세한 내용은 SMB 다중 채널 배포SMB 다중 채널의 기본 사항을 참조하세요.

SMB 다중 채널의 혜택

SMB 다중 채널 기능을 사용하면 SMB3 클라이언트가 단일 NIC(네트워크 인터페이스 카드) 또는 여러 NIC를 통해 연결 풀을 설정하고 이를 사용하여 단일 SMB 세션에 대한 요청을 보낼 수 있습니다. 반면, 설계상 SMB1과 SMB2는 클라이언트가 하나의 연결을 설정하고 해당 연결을 통해 특정 세션에 대한 모든 SMB 트래픽을 전송하도록 요구합니다. 이 단일 연결은 단일 클라이언트에서 달성할 수 있는 전체 프로토콜 성능을 제한합니다.

SMB 다중 채널의 성능

다음 테스트 및 그래프는 단일 인스턴스 워크로드에서 SMB 다중 채널의 기능을 보여줍니다.

임의 I/O

클라이언트에서 SMB 다중 채널을 사용하지 않도록 설정한 상태에서 FIO와 40GiB 작업 집합을 사용하여 순수한 4KiB 읽기 및 쓰기 테스트를 수행했습니다. 각 테스트 사이에 SMB 공유가 분리되었으며, SMB 클라이언트 연결 수는 , 1, 4, 8, 16set-SmbClientConfiguration -ConnectionCountPerRSSNetworkInterface <count> 네트워크 인터페이스 설정에 따라 증가했습니다. 테스트 결과 I/O 집약적인 작업에는 기본 설정인 4가 충분하며, 816으로 증가하면 무시해도 될 정도의 효과가 있었습니다.

netstat -na | findstr 445 명령은 1에서 4로, 4에서 8로, 8에서 16으로 증가하여 추가 연결이 설정되었음을 입증했습니다. perfmon Per Processor Network Activity Cycles 통계(이 문서에는 포함되지 않음)로 확인되었듯이 각 테스트에서 4개의 CPU 코어가 SMB에 완전히 사용되었습니다.

SMB 다중 채널의 임의 I/O 비교를 보여주는 차트.

Azure VM(가상 머신)은 SMB(또는 NFS) 스토리지 I/O 제한에 영향을 미치지 않습니다. 다음 차트에서 볼 수 있듯이 D32ds 인스턴스 형식은 캐시된 스토리지 I/OPS의 경우 속도가 308,000, 캐시되지 않은 스토리지 I/OPS의 경우 속도가 51,200으로 제한됩니다. 하지만 위의 그래프는 SMB를 통해 훨씬 더 많은 I/O를 보여줍니다.

임의 I/O 비교 테스트를 보여주는 차트.

순차 I/O

앞에서 설명한 임의 I/O 테스트와 유사한 테스트는 64KiB 순차 I/O로 수행되었습니다. RSS 네트워크 인터페이스당 클라이언트 연결 수가 4개를 넘어 증가하더라도 임의 I/O에는 눈에 띄는 영향이 없었지만, 순차 I/O에는 동일한 영향이 적용되지 않았습니다. 다음 그래프에서 볼 수 있듯이 각 증가량은 읽기 처리량의 증가와 관련이 있습니다. Azure에서 각 인스턴스 형식 및 크기에 대해 네트워크 대역폭을 제한했기 때문에 쓰기 처리량은 일정하게 유지되었습니다.

처리량 테스트 비교를 보여주는 차트.

Azure는 각 VM 형식과 크기에 네트워크 속도 제한을 적용합니다. 속도 제한은 아웃바운드 트래픽에만 적용됩니다. VM에 있는 NIC의 수는 해당 컴퓨터에서 사용할 수 있는 총 대역폭 양에 영향을 미치지 않습니다. 예를 들어, D32ds 인스턴스 형식에는 초당 16,000MB(2,000MiB/s)의 네트워크 제한이 적용됩니다. 위의 순차 그래프에서 볼 수 있듯이, 제한은 아웃바운드 트래픽(쓰기)에 영향을 미치지만 다중 채널 읽기에는 영향을 미치지 않습니다.

순차 I/O 비교 테스트를 보여주는 차트.

SMB 서명

SMB(서버 메시지 블록) 프로토콜은 원격 Windows 관리와 같은 파일 및 인쇄 공유 그리고 기타 네트워킹 작업에 대한 기초를 제공합니다. 전송 중인 SMB 패킷을 수정하는 중간자(man-in-the-middle) 공격을 방지하기 위해 SMB 프로토콜은 SMB 패킷의 디지털 서명을 지원합니다.

SMB 서명은 Azure NetApp Files에서 지원하는 모든 SMB 프로토콜 버전에 대해 지원됩니다.

SMB 서명이 성능에 미치는 영향

SMB 서명은 SMB 성능에 부정적 영향을 미칩니다. 성능 저하가 발생할 수 있는 다른 잠재적인 원인들 중에서, 각 패킷의 디지털 서명은 아래 Perfmon 출력과 같이 추가적인 클라이언트측 CPU를 사용합니다. 이 경우 코어 0은 SMB 서명을 포함하여 SMB를 담당하는 것으로 보입니다. 이전 섹션의 비 다중 채널 순차 읽기 처리량 수와 비교한 결과, SMB 서명은 전체 처리량을 875MiB/s에서 약 250MiB/s로 줄였습니다.

SMB 서명 성능 영향을 보여주는 차트.

1TB 데이터 세트가 포함된 단일 인스턴스에 대한 성능

읽기/쓰기 조합을 통해 워크로드에 대한 자세한 정보를 제공하기 위해 다음 두 차트는 1TB 데이터 세트와 4개의 SMB 다중 채널을 통해 50TB의 단일 Ultra 서비스 수준 클라우드 볼륨의 성능을 보여줍니다. 최적의 IODepth는 16으로 사용되었으며, FIO(Flexible I/O) 매개 변수를 사용하여 네트워크 대역폭(numjobs=16)을 최대한 활용했습니다.

다음 차트는 단일 VM 인스턴스와 10% 간격의 읽기/쓰기 혼합을 사용한 4KiB 임의 I/O에 대한 결과를 보여 줍니다.

Windows 2019 표준 _D32ds_v4 4 KiB 임의 I/O 테스트를 보여 주는 차트.

다음 차트에서는 순차 I/O의 결과를 보여줍니다.

Windows 2019 표준 _D32ds_v4 64 KiB 순차 처리량을 보여 주는 차트.

1TB 데이터 세트가 포함된 VM 5대를 사용하여 스케일링하는 경우의 성능

5개의 VM을 사용한 이러한 테스트에서는 단일 VM과 동일한 테스트 환경을 사용하며 각 프로세스는 자체 파일에 씁니다.

다음 차트는 임의 I/O에 대한 결과를 보여줍니다.

Windows 2019 표준 _D32ds_v4 4 KiB 5인스턴스 randio IO 테스트를 보여 주는 차트.

다음 차트에서는 순차 I/O의 결과를 보여줍니다.

Windows 2019 표준 _D32ds_v4 64 KiB 5개 인스턴스 순차 처리량을 보여 주는 차트.

Hyper-V 이더넷 어댑터를 모니터링하는 방법

FIO로 테스트 하는 데 사용되는 한 가지 전략은 numjobs=16을 설정하는 것입니다. 이렇게 하면 각 작업이 16개의 특정 인스턴스로 포크되어 Microsoft Hyper-V 네트워크 어댑터를 최대화할 수 있습니다.

Windows 성능 모니터의 각 어댑터에서 성능 모니터 > 카운터 추가 > 네트워크 인터페이스 > Microsoft Hyper-V 네트워크 어댑터를 선택하여 활동을 확인할 수 있습니다.

성능 모니터 카운터 추가 인터페이스를 보여주는 스크린샷.

볼륨에서 데이터 트래픽을 실행한 후 Windows 성능 모니터에서 어댑터를 모니터링할 수 있습니다. 이 16개의 가상 어댑터를 모두 사용하지 않으면 네트워크 대역폭 용량을 최대화하지 못할 수 있습니다.

성능 모니터 출력을 보여주는 스크린샷.

SMB 암호화

이 섹션은 SMB 암호화(SMB 3.0 및 SMB 3.1.1)를 이해하는 데 도움이 됩니다.

SMB 암호화는 SMB 데이터에 대한 엔드투엔드 암호화 기능을 제공하며, 신뢰할 수 없는 네트워크에서 발생하는 도청으로부터 데이터를 보호합니다. SMB 암호화는 SMB 3.0 이상에서 지원됩니다.

스토리지에 요청을 보낼 때 클라이언트는 요청을 암호화하고, 스토리지에서 암호를 해독합니다. 마찬가지로, 응답은 서버에서 암호화되고 클라이언트에서 암호를 해독합니다.

Windows 10, Windows 2012 이상 버전에서 SMB 암호화를 지원합니다.

SMB 암호화 및 Azure NetApp Files

Azure NetApp Files의 공유 수준에서는 AES(Advanced Encryption Standard)를 사용한 SMB 암호화가 사용하도록 설정되어 있습니다. SMB 3.0은 AES-CCM 알고리즘을 사용하는 반면 SMB 3.1.1은 AES-GCM 알고리즘을 사용합니다.

SMB 암호화는 필요하지 않습니다. 따라서 사용자가 Azure NetApp Files에서 해당 기능을 사용하도록 설정하도록 요청한 경우에만 해당 공유에 대해 해당 기능이 사용하도록 설정됩니다. Azure NetApp Files 공유는 인터넷에 노출되지 않습니다. Azure NetApp Files 공유는 VPN이나 ​​익스프레스 경로를 통해 지정된 가상 네트워크 내에서만 액세스할 수 있으므로 본질적으로 안전합니다. SMB 암호화를 사용할지 여부는 전적으로 사용자의 선택입니다. 이 기능을 사용하도록 설정하기 전에 예상되는 성능 저하를 확인합니다.

SMB 암호화가 클라이언트 워크로드에 미치는 영향

SMB 암호화는 클라이언트(메시지 암호화 및 암호 해독을 위한 CPU 오버헤드)와 스토리지(처리량 감소)에 모두 영향을 주지만 다음 표에는 스토리지 영향만 나와 있습니다. 프로덕션에 워크로드를 배포하기 전에 암호화 성능이 애플리케이션에 미치는 영향을 테스트해야 합니다.

I/O 프로필 영향
읽기 및 쓰기 워크로드 10%~15%
메타데이터 집약적 5%

가속 네트워킹

최대 성능을 위해 가능한 경우 VM에서 가속화된 네트워킹을 구성하는 것이 좋습니다. 다음 고려 사항에 유의하시기 바랍니다.

  • Azure Portal은 이 기능을 지원하는 VM에 대해 기본적으로 가속화된 네트워킹을 사용하도록 설정합니다. 하지만 Ansible이나 비슷한 구성 도구와 같은 다른 배포 방법은 불가능합니다. 가속화된 네트워킹을 활성화하지 못하면 컴퓨터 성능이 저하될 수 있습니다.
  • 인스턴스 형식이나 크기에 대한 지원 부족으로 인해 VM의 네트워크 인터페이스에서 가속화된 네트워킹이 사용하도록 설정되지 않은 경우, 더 큰 인스턴스 형식에서는 사용 안 함 상태로 유지됩니다. 이런 경우에는 수동적인 개입이 필요합니다.
  • Azure NetApp Files의 전용 서브넷에 있는 NIC에 대해 가속화된 네트워킹을 설정할 필요가 없습니다. 가속화된 네트워킹은 Azure VM에만 적용되는 기능입니다. Azure NetApp Files NIC는 디자인상 최적화되어 있습니다.

수신측 크기 조정

Azure NetApp Files는 RSS(수신 쪽 스케일링)를 지원합니다.

SMB 다중 채널을 사용하면 SMB3 클라이언트가 단일 RSS가 가능한 NIC(네트워크 인터페이스 카드)를 통해 Azure NetApp Files SMB 서버에 여러 TCP 연결을 설정할 수 있습니다.

Azure VM NIC가 RSS를 지원하는지 확인하려면 다음과 같이 명령 Get-SmbClientNetworkInterface를 실행하고 필드 RSS Capable을 확인합니다.

Azure VM에 대한 RSS 출력을 보여 주는 스크린샷.

SMB 클라이언트의 여러 NIC

SMB의 경우 클라이언트에 여러 개의 NIC를 구성하면 안 됩니다. SMB 클라이언트가 SMB 서버에서 반환한 NIC 수와 일치하지 않습니다. 각 스토리지 볼륨은 단 하나의 스토리지 엔드포인트에서만 액세스할 수 있습니다. 즉, 지정된 SMB 관계에는 단 하나의 NIC만 사용됩니다.

아래 Get-SmbClientNetworkInterface의 출력에서 ​​볼 수 있듯이 VM에는 15와 12라는 두 개의 네트워크 인터페이스가 있습니다. 다음 명령 Get-SmbMultichannelConnection에서 볼 수 있듯이 RSS 지원 NIC가 두 개 있더라도 SMB 공유와 관련하여 인터페이스 12만 사용되고 인터페이스 15는 사용되지 않습니다.

RSS 지원 NIC의 출력을 보여 주는 스크린샷.

다음 단계