탑재 옵션 및 클라이언트 VM 구성

5분

이 모듈에서는 Azure NetApp Files에서 HPC 또는 EDA 애플리케이션을 실행하는 동안 성능을 향상하는 탑재 옵션 및 클라이언트 VM 구성을 설명합니다.

참고 항목

NFS 클라이언트 모범 사례는 사용되는 애플리케이션에 따라 달라집니다. 다음 제안은 절대적이 아니며 애플리케이션 권장 사항 또는 워크로드 테스트로 재정의될 수 있습니다. 해당 사례를 프로덕션에 배포하기 전에 테스트하는 것이 좋습니다.

actimeo 및 nocto 탑재 옵션을 사용하여 성능 향상

다음 탑재 옵션을 사용하여 비교적 정적인 데이터 세트와 대규모 읽기 시나리오에서 성능을 향상할 수 있습니다.

actimeo: 디렉터리의 NFS 클라이언트 캐시 특성을 제어합니다. 지정하지 않으면 NFS 클라이언트는 60초의 기본 최댓값을 사용합니다.
nocto: ‘no close-to-open’을 뜻하는데 이는 시간 절약을 위해 쓰기가 완료되기 전에 파일을 닫을 수 있음을 의미합니다. 기본적으로 nocto은(는) NFS 탑재 옵션에서 설정되지 않습니다. 즉, 모든 파일은 닫기를 허용하기 전에 쓰기가 완료될 때까지 대기합니다.

이 시나리오의 EDA를 포함한 대부분의 HPC 애플리케이션에는 상대적으로 정적인 데이터 세트(데이터가 자주 변경되지 않음을 의미함)가 있습니다. 이 경우 nocto 및 actimeo을(를) 사용하여 스토리지에 대한 getattr 또는 액세스 작업을 줄일 수 있으며, 이를 통해 애플리케이션을 가속화하는 데 도움을 줄 수 있습니다.

예를 들어, EDA 도구 및 라이브러리 볼륨에 대해 "nocto,actimeo=600"(600초 또는 10분)을(를) 설정하는 것이 좋습니다. 해당 파일은 변경되지 않으므로 유지 관리할 캐시 일관성이 없습니다. 이러한 탑재 옵션을 설정하면 메타데이터 호출이 감소하여 전반적인 성능이 향상됩니다.

최적의 성능을 위한 시스템 매개 변수 튜닝

Tuned은(는) 연결된 디바이스를 Linux 클라이언트에서 모니터링하고 구성하는 데 사용할 수 있는 디먼입니다. 대부분의 경우 tuned은(는) 기본적으로 설치됩니다. 설치되지 않은 경우, 내장된 기본 템플릿을 사용하여 클라이언트 쪽 튜닝 매개 변수를 간소화하기 위해 추가하고 활성화할 수 있습니다.

다음 명령을 실행하여 클라이언트 VM에 대한 기본 서버 튜닝 및 일반적 대기 시간 튜닝을 적용합니다.

sudo systemctl enable --now tuned
sudo tuned-adm profile latency-performance

다음 시스템 매개 변수(/etc/sysctl.conf) 중 일부 또는 모두는 최적의 성능을 위해 Linux 클라이언트 VM에 유용할 수 있습니다. 많은 용량의 RAM이 있는 클라이언트 VM 또는 InfiniBand처럼 더 높은 네트워크 대역폭이 있는 경우 다음 예제의 값보다 훨씬 높은 값을 설정하는 것이 좋습니다.

#
# Recommended client tuning 
#
# For more information, see sysctl.conf(5) and sysctl.d(5)
# Network parameters, in units of bytes
net.core.wmem_max = 16777216
net.core.wmem_default = 1048576
net.core.rmem_max = 16777216
net.core.rmem_default = 1048576
net.ipv4.tcp_rmem = 1048576 8388608 16777216
net.ipv4.tcp_wmem = 1048576 8388608 16777216
net.core.optmem_max = 2048000
net.core.somaxconn = 65535
#
# These settings are in 4-KiB chunks, in bytes:
# Min=16MiB, Def=350MiB, Max=16GiB
# In units of 4K pages
net.ipv4.tcp_mem = 4096 89600 4194304
#
# Miscellaneous network options and flags
#
net.ipv4.tcp_window_scaling = 1
net.ipv4.tcp_timestamps = 0
net.ipv4.tcp_sack = 1
net.ipv4.tcp_no_metrics_save = 1
net.ipv4.route.flush = 1
net.ipv4.tcp_low_latency = 1
net.ipv4.ip_local_port_range = 1024 65000
net.ipv4.tcp_slow_start_after_idle = 0
net.core.netdev_max_backlog = 300000
#
# Various file system and page cache options
#
vm.dirty_expire_centisecs = 100
vm.dirty_writeback_centisecs = 100
vm.dirty_ratio = 20
vm.dirty_background_ratio = 5
#
# Recommended by: https://cromwell-intl.com/open-source/performance-tuning/tcp.html
#
net.ipv4.tcp_sack = 0
net.ipv4.tcp_dsack = 0
net.ipv4.tcp_fack = 0

이 튜닝을 지속적으로 적용하려면 다음을 실행합니다.

sudo sysctl -P

해당하는 경우 nconnect 탑재 옵션을 사용하여 네트워크 연결 확장

nconnect NFS 탑재 옵션은 Linux 커널 5.3 이상에서 일반 공급으로 전환되었습니다. 클라이언트 VM의 Linux 커널을 확인하려면 다음을 실행합니다.

uname -r

nconnect의 목적은 클라이언트에서 TCP 연결별 또는 탑재 지점별로 다수의 전송 연결을 제공하는 것입니다. 이 기술은 NFS 탑재의 병렬 처리와 성능을 향상하는 데 도움이 됩니다.

클라이언트 수가 적을수록 nconnect은(는) 어쩌면 모든 가용한 네트워크 대역폭을 활용할 수 있으므로 성능 향상에 도움이 되는 데 더 많은 값을 제공합니다. 클라이언트 수가 증가하면 이 값은 점차 감소합니다. 배분될 총 대역폭은 일정량에 불과하며 최대 TCP 연결 수는 더 빠르게 소진될 수 있으므로, TCP 연결이 해제될 때까지 서비스 거부가 발생할 수 있습니다.

Azure NetApp Files는 스로틀(리소스를 사용할 수 있게 될 때까지 새 요청이 큐에서 대기 중인 경우)이 발생하기 전에 TCP 연결당 최대 128개의 동시 인플라이트 요청을 허용하므로, nconnect은(는) 탑재 지점당 가용한 TCP 연결을 늘림으로써 허용되는 인플라이트 요청의 수를 확장하는 데 도움을 줄 수 있습니다. 예를 들어, nconnect이(가) 8개의 TCP 연결을 사용하도록 설정된 경우 클라이언트에게는 어쩌면 1,024(8x128)개의 요청이 사용 가능합니다.

최신 Linux 클라이언트는 연결당 최대 65,535개(동적 값)의 요청을 허용합니다. 이로 인해 어쩌면 Azure NetApp Files 볼륨의 가용한 인플라이트 요청 큐가 초과되어서, 클라이언트가 주어진 시간에 처리할 수 있는 것보다 더 많은 요청을 보내는 바람직하지 않은 성능 결과가 발생할 수 있습니다. 이 동작으로 인한 성능 영향의 위험을 줄이려면, nconnect=8 또는 16을(를) 사용 중인 경우 sunrpc.tpc_max_slot_table_entries=256 또는 512을(를) 더 낮은 고정된 값으로 설정하는 것이 좋습니다. 다음 테이블의 지침을 따릅니다.

참고 항목

Linux 클라이언트 OS의 유형에 따라 이 값을 설정하는 방법이 다를 수 있습니다. 자세한 내용은 OS 설명서를 참조하세요.

`nconnect` 값	권장되는 TCP 슬롯 테이블 항목의 최댓값
0-1	128
2~4	256
6-8	512
>8	변경은 필요 없음

참고 항목

nconnect 옵션은 Linux 커널 5.3 이상 VM에만 사용할 수 있습니다. 커널을 업그레이드할 때 VM을 다시 시작해야 할 수 있습니다. 즉, 일부 경우에는 적용하지 못할 수 있습니다.

성능만 고려하는 경우에는 NFSv4.1 대신 NFSv3 사용

NFSv3는 상태 비저장 프로토콜이며, 이는 클라이언트와 서버가 사용 중인 파일에 대해 서로 통신하지 않음을 의미합니다. 잠금은 프로토콜 스택 외부에서 NLM(네트워크 잠금 관리자)에 의해 수행되므로, 잠금이 부실해지고 수동으로 정리해야 할 때 몇 가지 문제가 발생합니다. 잠금은 애플리케이션의 요청에 의해서만 설정되므로, 잠금을 협상할 필요가 없는 시나리오가 있을 수 있습니다. 추적할 클라이언트 ID, 상태 ID, 세션 ID, 잠금 상태 등이 없으므로, NFSv3는 일부 워크로드에서 NFSv4.1보다 성능이 조금 더 우수한 경향이 있습니다. 특히, EDA 및 소프트웨어 개발과 같이 파일 수나 메타데이터가 많은 워크로드에서 그렇습니다.

NFSv4.1은 잠금을 포함하여 파일의 상태를 추적합니다. NFSv4.1에서 한 번에 많은 파일이 사용 중인 경우 각 파일은 상태 ID를 할당받고 잠금을 수신합니다. 각 상태 및 잠금이 NFS 서버에서 처리되어야 하므로, 상태 저장이 되면 워크로드 성능에 오버헤드가 추가됩니다. 일부 워크로드(예: EDA)에서 NFSv4.1의 성능은 25%와 75% 사이의 어떤 값만큼 영향을 받을 수 있습니다. 대용량 파일, 스트리밍 IO 또는 데이터베이스와 같은 다른 워크로드는 NFSv4.1을 사용할 때 성능 저하를 보이지 않으며, 심지어 해당 프로토콜이 사용하는 복합 작업의 이점을 누릴 수도 있다.

Azure NetApp Files는 NFSv3 및 NFSv4.1 둘 다를 지원합니다. NFS 버전 간의 유사점과 차이점을 비교(및 테스트)하고 적절한 버전을 사용하여 볼륨을 생성함으로써 애플리케이션에 필요한 버전의 유효성을 검사해야 합니다. 필요한 경우 Azure NetApp Files 볼륨은 생성 후에 다른 프로토콜 버전으로 구성될 수 있습니다.

rsize 및 wsize 탑재 옵션에 적합한 값 선택

탑재 옵션 rsize (읽기 크기) 및 wsize (쓰기 크기)는 전송된 각 패킷에 대해 NFS 클라이언트와 서버 간에 전송되는 데이터의 양을 결정합니다. 예를 들어, rsize 또는 wsize를 65,536으로 설정하면 패킷당 최대 64K의 데이터를 보낼 수 있습니다. 애플리케이션이 더 작은 청크(예: 8K)로 데이터를 전송하는 경우 전송되는 데이터의 양은 사용되는 탑재 옵션(예: sync)에 따라 달라집니다.

Azure NetApp Files의 모범 사례는 rsize 및 wsize를 동일한 값으로 설정하는 것입니다. 일반적으로 탑재 옵션에서 rsize 및 wsize 값은 둘 다 262144 (256 K)로 설정하는 것이 좋습니다.

동기 및 비동기 탑재 옵션에 대한 이해

sync이(가) 사용되는 경우 각 WRITE 호출은 FILE_SYNC 명령과 함께 전송됩니다. 즉, 다음 WRITE이(가) 발생하기 전에 모든 WRITE는 서버에서 승인되고 디스크로 커밋되어야 합니다. 애플리케이션이 모든 데이터가 디스크로 커밋되도록 보장해야 하는 경우 Sync이(가) 사용됩니다. WRITE 호출은 애플리케이션의 블록 크기로 지정된 데이터 양만 전송합니다. 즉, 더 작은 블록 크기는 탑재의 wsize 및 rsize 값에 관계없이 더 많은 NFS 트래픽을 생성하여 성능에 영향을 줍니다.

(기본) async 탑재 작업을 사용하는 경우, 클라이언트는 UNSTABLE 명령을 사용하여 NFS를 통해 여러 WRITE 호출을 전송할 수 있습니다. 이 시나리오에서는 제한 시간이 지난 후 데이터가 디스크로 플러시됩니다. NFS 클라이언트가 다음 WRITE를 시작하기 전에 서버가 디스크로 데이터를 커밋하기를 항상 기다리는 것은 아니므로, 비동기 탑재에 대한 쓰기의 작업 완료 시간은 동기 탑재의 경우보다 훨씬 짧습니다. 더 작은 블록 크기가 rsize 및 wsize의 더 큰 값과 함께 사용되는 경우, WRITE 호출은 단일 NFS 호출에서 허용되는 만큼의 데이터를 전송합니다. 예를 들어, 8K의 블록 크기가 64K의 wsize/rsize과(와) 함께 사용되는 경우 각 NFS WRITE 호출은 패킷당 8개 블록(64K/8K)을 전송합니다. 쓰기가 디스크로 플러시되면 NFS 서버는 FILE_SYNC 회신을 NFS 클라이언트로 다시 전송합니다. 이렇게 하면, 작업을 완료하는 데 필요한 네트워크를 통한 WRITE 호출과 회신의 전체 수가 줄어들어 성능이 향상됩니다.

예를 들어, 8K 블록 크기를 사용하여 1GiB 파일을 만든 테스트에서, sync 탑재 옵션을 사용할 때 262,144개의 WRITE호출과 회신이 생성되어70초 만에 완료되었습니다. 8K 블록 크기와 async 탑재 옵션을 사용하여 동일한 파일을 만들었을 때 16,384개의 WRITE 호출과 회신만 전송되어 6초 만에 완료되었습니다.

Azure NetApp Files는 들어오는 NFS 쓰기를 위한 버퍼 캐시로 배터리 지원 NVRAM 스토리지를 사용합니다. NVRAM의 데이터는 10초마다 또는 버퍼 캐시가 다 찰 때(둘 중 먼저 도래하는 시점에) 디스크로 플러시됩니다. NVRAM은 배터리로 지원되기 때문에, 가능성이 낮은 Azure 데이터센터의 전력 손실과 같은 예기치 않은 정전에도 최소 72시간 동안 데이터를 유지하면서 버틸 수 있습니다. Azure NetApp Files의 데이터 복원력과 sync 탑재 옵션 사용의 성능 영향이 결합되면, 거의 모든 사용 사례에서 비동기 탑재가 선호되는 선택이 됩니다.

wsize 및 rsize 값의 영향에 대한 이해

NFS를 통해 탑재하는 경우 wsize 및 rsize의 값은 NFS 호출당 NFS 서버로 전송할 수 있는 데이터의 양을 결정합니다. 탑재 옵션에서 지정되지 않은 경우 해당 값은 NFS 서버를 구성할 때 사용한 값으로 설정됩니다. Azure NetApp Files는 wsize 및 rsize 모두에 대해 1MB(1,048,576)의 최대 전송 크기를 사용합니다. 이 값은 Azure NetApp Files에서 변경할 수 없습니다. 즉, NFS 탑재에서 wsize 및 rsize의 값을 지정하지 않으면 탑재의 기본값은 1MB입니다. EDA 워크로드에서 NFS 탑재의 경우 권장되는 wsize 및 rsize의 값은 256K입니다.

애플리케이션이 Azure NetApp Files NFS 탑재에서 1GiB 파일을 만들어야 하는 경우, 스토리지에 1,048,576KiB를 써야 합니다. 수학 연습을 통해, 더 효율적인 wsize 또는 rsize 값을 사용하면 성능이 향상될 수 있는 이유를 확인할 수 있다.

wsize 값이 64K로 설정된 경우 1GiB 파일을 쓰는 데 필요한 작업/패킷 수는 1,048,576/64=16,384입니다.
wsize 값이 256K로 설정된 경우 1GiB 파일을 쓰는 데 필요한 작업/패킷 수는 1,048,576/256=4,096입니다.

패킷/작업 수가 더 작으면 (RTT에 영향을 미치는) 네트워크 대기 시간이 워크로드에 영향을 덜 미치기 때문에 클라우드 배포에 중요할 수 있습니다. 그러나 애플리케이션이 wsize/rsize 값보다 더 작은 파일을 쓰는 경우 더 큰 wsize/rsize 값은 성능에 영향을 주지 않습니다.

데이터 청크가 클수록 클라이언트와 서버에서 처리 주기가 늘어나지만, 대부분의 최신 CPU는 이러한 요청을 효율적으로 처리할 수 있는 충분한 기능을 갖추고 있습니다.

Azure NetApp Files의 모범 사례는 rsize 및 wsize를 동일한 값으로 설정하는 것입니다. 탑재 옵션에서 rsize 및 wsize 값을 모두 262,144(256K)로 설정하는 것이 좋습니다. 이 설정은 애플리케이션 읽기 및 쓰기 크기 값의 배열을 다룹니다.

hard, soft, intr 탑재 옵션의 적절한 설정 선택

hard 및 soft 탑재 옵션은 NFS를 사용하는 파일을 사용하고 있는 프로그램이 다음 작업 중 하나를 수행해야 하는지 여부를 지정합니다.

NFS 서버를 사용할 수 없는 경우 서버가 다시 온라인으로 전환될 때까지 중지하고 대기합니다(hard). 이 옵션은 클라이언트에서 탑재 중단으로 표시되지만, 네트워크 정전이 발생할 때 진행 중이던 작업이 손실되지 않도록 보장합니다. 대신, 클라이언트는 서버가 가용해지거나 애플리케이션의 제한 시간이 지날 때까지 계속 요청을 다시 시도합니다.
오류를 신고합니다(soft). 탑재는 중단되지 않지만, 진행 중인 작업은 손실될 수 있습니다.

intr 탑재 옵션을 사용하면 탑재가 hard 탑재(예: CTRL+C)로 지정될 때 NFS 프로세스가 중단될 수 있습니다. 데이터 안정성과 관리 효율성에 대한 최상의 조합에 적용할 수 있는 경우 hard 탑재와 함께 intr을(를) 사용하는 것이 좋습니다.

MTU 변경 없음 고려

Azure VM의 기본 MTU(최대 전송 단위)는 1,500바이트입니다. 고객은 점보 프레임의 VM MTU를 늘리지 않는 것이 좋습니다.

탑재 예제

다음 예제 코드에서는 actimeo, nocto, NFSv3, nconnect, rsize, wsize, hard, intr, tcp에 이전 모범 사례를 사용하고 기본 MTU(1,500)를 사용하여 Azure NetApp Files 볼륨을 탑재합니다.

sudo mount -t nfs -o rw,nconnect=16,nocto,actimeo=600,hard,intr,rsize=262144,wsize=262144,vers=3,tcp 10.1.x.x:/ultravol ultravol

참고 항목

NFS 탑재는 기본적으로 async(으)로 설정되므로 Async은(는) 지정되지 않았습니다.

탑재 옵션 및 클라이언트 VM 구성

actimeo 및 nocto 탑재 옵션을 사용하여 성능 향상

최적의 성능을 위한 시스템 매개 변수 튜닝

해당하는 경우 nconnect 탑재 옵션을 사용하여 네트워크 연결 확장

성능만 고려하는 경우에는 NFSv4.1 대신 NFSv3 사용

rsize 및 wsize 탑재 옵션에 적합한 값 선택

동기 및 비동기 탑재 옵션에 대한 이해

wsize 및 rsize 값의 영향에 대한 이해

hard, soft, intr 탑재 옵션의 적절한 설정 선택

MTU 변경 없음 고려

탑재 예제

피드백