Dell EMC Ready Solutions for HPC BeeGFS 고성능 스토리지

2019년 11월 Dell EMC HPC 및 AI 이노베이션 랩의 Nirmala Sundarajan이 작성한 문서

Dell EMC Ready Solutions for HPC BeeGFS 고성능 스토리지

목차

1. 소개
2. 솔루션 레퍼런스 아키텍처
3. 하드웨어 및 소프트웨어 구성
4. 솔루션 구성 세부 정보
   • 관리 서비스
   • 메타데이터 서비스
   • 스토리지 서비스
   • 클라이언트 서비스
5. R740xd, 24x NVMe 드라이브, CPU 매핑 세부 정보
6. 성능 특성화
   • 순차적 읽기 및 쓰기 N-N
   • 랜덤 읽기 및 쓰기 N-N
7. 결론 및 향후 작업
    

소개

솔루션 레퍼런스 아키텍처

하드웨어 및 소프트웨어 구성

표 1 및 2에서는 각각 관리 서버 및 메타데이터/스토리지 서버의 하드웨어 사양을 설명합니다. 표 3에는 솔루션에 사용되는 소프트웨어 버전이 설명되어 있습니다.

솔루션 구성 세부 정보

• 관리 서비스
• 메타데이터 서비스
• 스토리지 서비스
• 클라이언트 서비스

관리 서비스

메타데이터 서비스

그림 3:  메타데이터 서버

그림 4는 메타데이터 서버의 RAID 구성을 보여 줍니다. 이 그림에서는 메타데이터 서버에서 NUMA 존 0의 드라이브가 MDT를 호스팅하고 NUMA 존 1의 드라이브가 스토리지 데이터를 호스팅하는 동시에 두 NUMA 존에서 스토리지 서버가 ST를 호스팅하는 방법을 중점적으로 조명합니다.

스토리지 서비스

1. 쓰기 성능은 dd 명령을 사용하여 데이터에 대해 1MiB 블록 크기와 직접 I/O 기능을 갖는 10GiB 파일을 생성함으로써 측정했습니다. RAID 0 디바이스의 경우 각 디바이스의 평균이 5.1GB/s인 반면 RAID 10 디바이스의 경우 각 디바이스의 평균은 3.4GB/s였습니다.
2. StorageBench 벤치마크 테스트 결과 RAID 0 구성의 경우 최대 처리량이 5.5GB/s인 반면 RAID 10 구성의 경우 3.4GB/s인 것으로 나타났습니다. 이러한 결과는 dd 명령을 사용하여 얻은 결과와 같습니다.
3. RAID 10을 사용하면 디스크 용량의 50%를 활용할 수 있으며 쓰기 성능은 50% 감소합니다. RAID 10을 사용하면 스토리지 이중화를 확보하는 데 큰 비용이 소요됩니다.
4. NVMe 드라이브는 비용이 많이 들 뿐만 아니라 RAID 0 구성에서 가장 잘 활용되는 속도를 제공합니다.

클라이언트 서비스

$ cat /etc/beegfs/beegfs-mounts.conf
/mnt/beegfs-medium /etc/beegfs/beegfs-client-medium.conf
/mnt/beegfs-small /etc/beegfs/beegfs-client-small.conf

R740xd, 24x NVMe 드라이브, CPU 매핑 세부 정보

# cat /proc/sys/kernel/numa_balancing
0

성능 특성화

순차적 쓰기 및 읽기 N-N

순차적 읽기/쓰기를 평가하기 위해 IOzone 벤치마크에서는 순차적 읽기/쓰기 모드를 사용했습니다. 이 테스트는 스레드 한 개에서 시작하여 2의 제곱(최대 1024 스레드)으로 증가하는 다중 스레드에서 수행했습니다. 이 테스트는 스레드당 파일 한 개 또는 N-N(N Clinet to N File) 케이스로 작동하므로 각 스레드 개수에서 동일한 수의 파일이 생성되었습니다. 요청이 균등하게 분배되고 로드 밸런싱이 이루어지도록 프로세스는 라운드 로빈 또는 순환 방식으로 32개의 물리적 클라이언트 노드에 분산되었습니다. 총 파일 크기로 8TB를 선택했으며, 이 크기는 주어진 테스트 내에서 스레드 수로 동일하게 구분됩니다. 집계 파일 크기는 서버와 BeeGFS 클라이언트의 캐싱 효과를 최소화할 수 있을 정도로 크게 선택되었습니다. IOzone은 작업 간의 경계를 조정할 수 있도록 쓰기 후 읽기(-i 0, -i 1)의 조합 모드로 실행되었습니다. 이 테스트와 결과를 위해 모든 실행에 1MiB의 레코드 크기를 사용했습니다. 순차적 N-N 테스트에 사용되는 명령은 다음과 같습니다.

순차적 읽기 및 쓰기: iozone -i 0 -i 1 -c -e -w -r 1m -I -s $Size -t $Thread -+n -+m /path/to/threadlist

OS 캐시는 다음 명령을 실행하여 클라이언트 노드의 반복 사이 또는 쓰기 및 읽기 사이에서 삭제하거나 정리할 수도 있습니다.

# sync && echo 3 > /proc/sys/vm/drop_caches

Beegfs의 기본 스트라이프 수는 4입니다. 그러나 파일당 청크 크기와 타겟 수는 디렉토리별로 구성할 수 있습니다. 이 모든 테스트에서는 아래와 같이 NUMA 존당 타겟이 세 개이므로 BeeGFS 스트라이프 크기를 2MB로 선택하고 스트라이프 수를 3으로 선택했습니다.

$ beegfs-ctl --getentryinfo --mount=/mnt/beegfs /mnt/beegfs/benchmark --verbose
EntryID: 0-5D9BA1BC-1
ParentID: root
메타데이터 노드: node001-numa0-4 [ID: 4]
스트라이프 패턴 세부 정보:
+ 유형: RAID0
+ 청크크기: 2M
+ 스토리지 타겟 수: 희망: 3
+ 스토리지 풀: 1(기본값)
inode 해시 경로: 7/5E/0-5D9BA1BC-1

투명한 대용량 페이지가 비활성화되었으며 메타데이터 및 스토리지 서버에 다음과 같은 튜닝 옵션이 적용되었습니다.

• vm.dirty_background_ratio = 5 
• vm.dirty_ratio = 20 
• vm.min_free_kbytes = 262144 
• vm.vfs_cache_pressure = 50
• vm.zone_reclaim_mode = 2 
• kernel.numa_balancing = 0

위의 사항 외에도 다음과 같은 BeeGFS 튜닝 옵션이 사용되었습니다. 

• 메타데이터 구성 파일에서 tuneTargetChooser 매개변수가 "roundrobin"으로 설정되었습니다. 
• tuneNumWorkers 매개변수가 메타데이터에 대해 24, 스토리지에 대해 32로 설정되었습니다. 
• connMaxInternodeNum 매개변수가 메타데이터에 대해 32, 스토리지에 대해 12, 클라이언트에 대해 24로 설정되었습니다.

그림 9에서 최대 읽기 성능은 1024개 스레드에서 132GB/s이고 최대 쓰기 성능은 256개 스레드에서 121GB/s입니다. 각 드라이브는 3.2GB/s의 최고 읽기 성능과 1.3GB/s의 최고 쓰기 성능을 제공할 수 있으며, 이론적으로 최대 읽기 속도는 422GB/s, 쓰기 속도는 172GB/s입니다. 그러나 여기서 네트워크는 제한적 요소입니다. 설정에는 스토리지 서버에 대한 총 11개의 InfiniBand EDR 링크가 있습니다. 각 링크는 이론상 12.4GB/s의 최대 성능을 제공할 수 있으므로 이론상 최대 성능은 136.4GB/s입니다. 이론적 최대 성능에서 달성된 최대 읽기 및 쓰기 성능은 각각 97% 및 89%입니다.

단일 스레드의 쓰기 성능은 약 3GB/s, 읽기 속도는 약 3GB/s으로 관측됩니다. 쓰기 성능은 선형으로 증가해 256개 스레드에서 정점에 달한 후 감소하기 시작한다는 것을 발견했습니다. 그보다 스레드 수가 적으면 읽기 및 쓰기 성능은 동일합니다. 스레드가 8개일 때까지는 8개의 클라이언트가 24개의 타겟에 8개의 파일을 쓰게 되므로 모든 스토리지 타겟이 완전히 활용되지 않습니다. 시스템에는 33개의 스토리지 타겟이 있으므로 모든 서버를 완전히 활용하려면 최소 11개의 스레드가 필요합니다. 읽기 성능은 동시 스레드 수가 증가함에 따라 꾸준히 선형 증가를 기록하며 512개 및 1024개 스레드에서 거의 유사한 성능을 보입니다.

또한 스레드 수가 16개에서 128개인 경우 읽기 성능이 쓰기 성능보다 낮다가 그 후부터 증가하기 시작합니다. 이는 PCIe 읽기 작업이 요청과 완료가 모두 필요한 미게시 작업인 반면 PCIe 쓰기 작업은 자체 실행형 작업이기 때문입니다. 트랜잭션 레이어 패킷이 데이터 링크 레이어로 전달되면 작업이 완료됩니다. 쓰기 작업은 요청으로만 구성된 "게시" 작업입니다.

읽기 작업에는 같은 양의 데이터에 대해 쓰기 하나가 아닌 두 개의 트랜잭션이 필요하기 때문에 읽기 처리량은 일반적으로 쓰기 처리량보다 낮습니다. PCI Express는 읽기에 분할 트랜잭션 모델을 사용합니다. 읽기 트랜잭션에는 다음 단계가 포함됩니다.

• 요청자가 MRR(Memory Read Request)를 전송합니다.
• 완료자가 MRR로 확인 메시지를 보냅니다.
• 완료자가 데이터를 완료해 돌려보냅니다.

읽기 처리량은 읽기 요청이 발행된 시간과 완료자가 데이터를 반환하는 데 걸린 시간 사이에 발생한 지연에 따라 달라집니다. 그러나 애플리케이션이 이 지연을 커버할 수 있을 만큼 충분한 수의 읽기 요청을 발행하면 처리량이 최대화됩니다. 따라서 16개 스레드에서 128개 스레드에서는 읽기 성능이 쓰기 성능보다 낮지만 요청 수가 증가함에 따라 처리량 증가를 측정합니다.  더 낮은 처리량은 요청자가 요청이 완료되기를 기다렸다가 다음 요청을 발행할 때 측정됩니다. 처리량은 첫 번째 데이터가 반환된 후 지연을 상각하기 위해 여러 요청이 실행될 때 더 높게 기록됩니다.

랜덤 쓰기 및 읽기 N-N

IO의 랜덤 성능을 평가하기 위해 IOzone이 랜덤 모드에서 사용되었습니다. 테스트는 스레드 수가 4개에서 최대 1024개까지 달할 때까지 수행되었습니다. IOzone 실행에는 모든 작업이 버퍼 캐시를 우회하여 디스크로 직접 이동하도록 직접 IO 옵션(-I)이 사용되었습니다. BeeGFS 스트라이프 3개와 2MB 크기의 청크가 사용되었습니다. IOzone에서는 4KiB 요청 크기가 사용됩니다. 성능은 IOPS(I/O Operations per Second)로 측정됩니다. BeeGFS 서버와 BeeGFS 클라이언트의 실행 사이에서 OS 캐시가 삭제되었습니다. 랜덤 쓰기 및 읽기를 실행하는 데 사용되는 명령은 다음과 같습니다.

랜덤 쓰기 및 읽기: iozone -i 2 -w -c -O -I -r 4K -s $Size -t $Thread -+n -+m /path/to/threadlist

그림 10:  총 파일 크기가 8TB인 IOzone을 사용한 랜덤 읽기 및 쓰기 성능

그림 10에 나와 있는 것처럼 랜덤 쓰기는 512개 스레드에서 약 360만 IOPS로 정점을 기록하고 랜덤 읽기는 1024개 스레드에서 약 350만 IOPS로 정점을 기록합니다. I/O 요청 수가 많을 때 쓰기 및 읽기 성능이 모두 더 높습니다. 이는 NVMe 표준이 최대 64K I/O 대기열과 대기열당 최대 64K 명령을 지원하기 때문입니다. 이 대규모 NVMe 대기열 풀은 더 높은 수준의 I/O 병렬 처리를 제공하므로 IOPS가 3백만 개를 초과하는 것을 확인할 수 있습니다.

결론 및 향후 작업

이 블로그에서는 Dell EMC 고성능 BeeGFS 스토리지 솔루션의 릴리스를 발표하고 성능적 특성을 중점적으로 설명합니다. 이 솔루션의 순차적 읽기 및 쓰기 최대 성능은 각각 약 132GB/s 및 약 121GB/s이며 랜덤 쓰기는 약 360만 IOPS, 랜덤 읽기는 약 350만 IOPS에서 정점에 이릅니다.

이 블로그 문서는 고성능 스크래치 공간에 중점을 두고 설계된 "BeeGFS 스토리지 솔루션"의 1부입니다. 서버 수를 늘려 성능과 용량을 늘리는 방식으로 솔루션을 확장하는 방법을 설명하는 블로그 시리즈의 2부를 계속 지켜봐 주시기 바랍니다. 블로그 시리즈의 3부에서는 BeeGFS의 추가 기능에 대해 논의하고 BeeGFS의 기본 제공 스토리지 타겟 벤치마크인 "StorageBench"의 사용을 중점적으로 다룹니다.

다음 단계의 일환으로 메타데이터 성능과 1 파일 IOR 성능에 대한 N 스레드, 설계 고려 사항, 튜닝 및 구성에 대한 추가 세부 정보가 포함된 백서를 차후 게시할 예정입니다.

참조