Dell EMC HPC NFS 스토리지 솔루션 – 고가용성(NSS7.4-HA) 구성

목차

1. 솔루션 개요
2. NSS7.4-HA 아키텍처
3. NSS7.4-HA와 NSS7.3-HA의 구성 요소 비교
4. 테스트베드 구성
5. NSS7.4-HA I/O 성능 요약
   • IPoIB 순차 쓰기 및 읽기 N-N
   • IPoIB 임의 쓰기 및 읽기 N-N
   • IPoIB 메타데이터 작업
6. 결론
7. 참조
   
    

---

솔루션 개요

이 블로그에서는 코드 이름 'Cascade Lake'라는 인텔의 2세대 제온 확장형 프로세서를 활용하는 Dell EMC HPC NFS 스토리지 솔루션 버전 7.4(NSS7.4-HA)에 대해 설명합니다.  이러한 향상된 제온 프로세서는 소켓당 최대 28개 코어, 최대 38.5MB의 라스트 레벨 캐시 및 2,933MT/s 메모리 채널 6개를 지원합니다.  하프 Lake 프로세서의 주요 특징은 측면 채널 공격, INTEL DL 부스트 (VNNI), 클럭 속도 및 메모리 속도 향상을 위한 통합 하드웨어 완화 입니다.

하프 Lake 및 해당 선행 Skylake에는 adddc (daptive dRAMdevice Correction) 라는 기능이 포함 되어 있습니다. ADDDC는 장애가 발생한 DRAM 디바이스를 동적으로 매핑하기 위해 런타임 시 동적으로 배포되는 동시에 런타임에 배치되어 SDDC(Single Device Data Correction), ECC(Error-Correcting Code) 메모리를 계속 제공하면서 DIMM 수명을 늘립니다. 이 기능은 x4 DRAM 디바이스에만 활성화되며 시스템에 x8 DRAM 디바이스가 있는 경우 아무 작업도 수행하지 않습니다. 최신 NSS-HA 버전 7.4는 16GB 메모리(x8)만 사용하므로 ADDDC가 회색으로 표시되고 BIOS에서 조정 가능한 옵션이 아닙니다. 하지만 x4 인 32GB 메모리를 사용 하는 경우에는 ADDDC를 조정 가능한 옵션으로 사용할 수 있으며, 사용 안 함으로 설정 하 여 RAS 기능에 대 한 성능을 저하 시키는 것이 좋습니다.

"인텔 캐스케이드 Lake forthe the the the the the the the the the the the the the the the the the the the the the the the the the the the the the the the the the the the the the the the the the the the the the the the the the the the the the the the the the the the the the the the HPC NFS 기존 시스템을 업그레이드하는 경우, CPU를 Cascade Lake 프로세서로 업그레이드하기 전에 BIOS를 Cascade Lake CPU를 지원하는 버전으로 먼저 업데이트해야 합니다. HPC 및 AI 이노베이션 랩의 HPC 엔지니어링팀은 Cascade Lake 프로세서가 탑재된 NSS 서버를 대상으로 일련의 벤치마크 테스트를 수행했으며, 그 결과를 이전 세대 'Skylake-SP' 제온 제품군 프로세서가 탑재된 최신 버전의 PowerEdge 서버를 사용한 NSS7.3-HA 솔루션과 비교했습니다. 벤치 마크 결과와 비교가이 블로그에서 제공 됩니다.

Dell EMC에서 제공 하는 NFS 스토리지 솔루션은 최상의 성능을 위해 최적화 되 고 조정 됩니다.  NSS7.4-HA 솔루션을 설정하는 동안 다음과 같은 핵심 사항을 명시해야 합니다.

1. Cascade Lake 프로세서를 사용하는 데 지원되는 최소 운영 체제는 Red Hat Enterprise Linux 7.6입니다. 그러나 커널 버전 3.10.0-957.el7을 사용하는 경우 NFS 공유가 kworker와 같은 작업과 어울리면서 CPU를 모두 소비합니다. 이 문제의 근본 원인은 TCP 레이어가 sunrpc 레이어 전송 상태와 동기화되지 않았기 때문입니다. 이 문제는 패키지 커널-3.10.0-957.5.1.el7 이상에서 해결되었습니다. 따라서 이 솔루션에 사용되는 기본 운영 체제는 RHEL7.6이며 사용된 커널 버전은 kernel-3.10.0-957.5.1.el7입니다. 자세한 내용은 https://access.redhat.com/solutions/3742871을 참조하십시오.
2. NSS7.4-HA 솔루션의 경우, 다음 패키지가 설치되지 않은 경우 nfsserver 리소스가 nfs-idmapd.service 시작 오류로 인해 시작되지 않습니다. 자세한 내용은 https://access.redhat.com/solutions/3746891을 참조하십시오.
   • resource-agents-4.1.1-12.el7_6.4
   • resource-agents-aliyun-4.1.1-12.el7_6.4
   • resource-agents-gcp-4.1.1-12.el7_6.4 이상
3. RHEL7.6의 릴리스 노트는 LVM의 I/O 레이어 버그로 인해 물리적 볼륨의 할당 가능한 첫 128KB 공간에서 데이터 손상이 발생한다는 사실에 주목합니다.  lvm2-2.02.180-10.el7_6.2 이상에서 문제가 해결되었습니다.  lvm2 패키지를 최신 버전으로 업데이트해야 합니다. lvm2 업데이트가 옵션이 아닌 경우 VG의 논리 볼륨이 사용하는 동안 lvcreate 또는 lvextend와 같은 볼륨 그룹(VG) 메타데이터를 변경하는 LVM 명령을 사용하지 않는 것이 좋습니다.

---

NSS7.4-HA 아키텍처

그림 1은 NSS7.4-HA의 설계를 보여줍니다. 필요한 소프트웨어 및 펌웨어 업데이트를 제외하고, NSS7.4-HA 및 NSS7.3-HA는 동일한 HA 클러스터 구성 및 스토리지 구성을 공유합니다. 액티브-패시브 고가용성 구성의 NFS 서버 쌍이 PowerVault ME4084에 연결되어 있습니다. 각 NFS 서버에는 듀얼 SAS 카드가 있습니다. 각 카드에는 공유 스토리지의 각 컨트롤러마다 SAS 케이블이 있어 단일 SAS 카드 또는 SAS 케이블 오류가 데이터 가용성에 영향을 미치지 않습니다. (구성에 대한 자세한 내용은 NSS7.3-HA 백서를 참조하십시오.) NSS7.4-HA 아키텍처

 

---

 

NSS7.4-HA와 NSS7.3-HA의 구성 요소 비교

Dell NSS-HA 솔루션은 최초의 NSS-HA 릴리스 이후 가용성, 성능 및 스토리지 용량을 높이기 위해 많은 하드웨어 및 소프트웨어 업그레이드를 지원 받고 있지만 NSS-HA 솔루션 제품군의 아키텍처 설계 및 배포 지침은 그대로 유지됩니다. 이 최신 버전과 이전 버전의 NSS7.3-HA는 Power Vault ME4084와 동일한 스토리지 백엔드를 공유합니다. 다음 표에서는 최신 NSS7.4-HA 솔루션과 이전 NSS7.3-HA 솔루션의 구성 요소를 비교합니다.

 

블로그의 나머지 부분에서는 NSS7.4-HA의 테스트베드 및 I/O 성능 정보가 제공됩니다. NSS7.4-HA와 이전 릴리스의 성능 차이를 보여 주기 위해 NSS7.3-HA의 해당 성능 번호도 표시됩니다.

 

---

테스트베드 구성

NSS7.4-HA 솔루션의 성능 및 기능을 평가하는 데 사용되는 테스트베드가 여기에 설명되어 있습니다. 이 작업에 대해 제시간에 제온 골드 6240 CPU를 받지 못했기 때문에 성능 테스트에 사용된 CPU는 이 솔루션을 위해 선택한 CPU와 다릅니다. 6240 프로세서를 사용할 수 있게 되면 테스트 중 일부를 반복하고 필요에 따라 이 보고서를 수정할 계획입니다.
    

표 4: NSS 7.4-HA 클라이언트 구성   

---

NSS7.4-HA I/O 성능 요약

이 섹션에서는 현재 NSS7.4 솔루션에 대한 I/O 성능 테스트 결과를 설명합니다. 모든 성능 테스트는 솔루션의 최대 성능을 측정하기 위해 무결함 시나리오에서 수행했습니다. 이 테스트는 큰 순차 읽기 및 쓰기, 작은 임의 읽기 및 쓰기, 세 가지 메타데이터 작업(파일 생성, 통계 및 제거)의 세 가지 I/O 패턴 유형에 초점을 맞추었습니다. 이전 버전 NSS 7.3-HA와 마찬가지로 솔루션은 만료 된 I/o 스케줄러와 256 NFS 데몬이를 사용 합니다.

840TB (원시 스토리지 크기) 구성이 EDR을 통해 IPoIB 네트워크 연결로 benchmarked 됩니다. 벤치마킹 테스트를 위한 워크로드를 생성하는 데 32노드 컴퓨팅 클러스터를 사용했습니다. 각 테스트는 일련의 클라이언트를 통해 실행 되어 솔루션의 확장성을 테스트 합니다.

이 연구에서는 IOzone 및 mdtest 벤치 마크를 사용 했습니다. 순차 및 임의 테스트에 IOzone을 사용했습니다. 순차 테스트의 경우 1024KiB의 요청 크기를 사용했습니다. NFS 서버 캐시가 포화되도록 전송된 총 데이터 양은 2TB였습니다. 임의 테스트의 경우 4KiB 요청 크기를 사용했고 각 클라이언트는 4GiB 파일을 읽고 기록했습니다. 메타데이터 테스트는 OpenMPI와 함께 mdtest 벤치마크를 사용하여 수행했으며 파일 생성, 통계 및 제거 작업을 포함했습니다. (테스트에 사용된 전체 명령은 NSS7.3-HA 백서의 부록 A를 참조하십시오.)

 

IPoIB 순차 쓰기 및 읽기 N-N

순차 읽기/쓰기를 평가하기 위해 IOzone 벤치마크인 버전 3.487을 순차 읽기/쓰기 모드로 사용했습니다. 이 테스트는 스레드 한 개에서 시작하여 2의 제곱(최대 64 스레드)으로 증가하는 다중 스레드에서 수행했습니다. 이 테스트는 스레드당 파일 한 개 또는 N-N 케이스로 작동하므로 각 스레드 개수에서 동일한 수의 파일이 생성되었습니다. 지정 된 테스트 내에서 스레드 수 간에 균등 하 게 분할 되는 총 파일 크기 (2TB)를 선택 했습니다.

그림 2에는 NSS 7.3 버전에 해당 하는 NSS 7.4-HA 버전의 순차 입출력 성능이 비교 되어 있습니다. 그림에서 최신 NSS7.4 및 이전 NSS7.3이 7GB/s의 읽기 성능과 5Gb/s의 쓰기 성능을 나타내는 등 최대 성능이 비슷한 것으로 확인되었습니다. 그러나 일부 스레드에서는 NSS7.3-HA 솔루션과 비교했을 때 쓰기 성능이 15~20% 감소한 것으로 측정되었습니다. 이러한 성능 차이에 대한 조사가 현재 진행 중입니다. 읽기 성능은 스레드 수가 1과 2일 때 약 45% 증가했고 스레드 수가 8일 때 18% 증가했습니다. 스레드 수가 8개를 초과하는 경우, 읽기 성능은 NSS7.3-HA 솔루션의 읽기 성능과 유사합니다. 스레드 수가 적을수록 읽기 성능이 향상되는 것은 부채널 공격에 대해 Cascade Lake 프로세서에 적용된 하드웨어 완화 때문입니다. IPoIB 대규모 순차 I/O 성능




 

IPoIB 임의 쓰기 및 읽기 N-N

임의 IO 성능을 평가하기 위해 IOzone 버전 3.487을 임의 모드에서 사용했습니다. 테스트는 스레드 수를 1에서 최대 64까지 2의 제곱으로 수행했습니다. 레코드 크기를 4KB로 선택했습니다. 각 클라이언트는 작은 임의 데이터 액세스를 시뮬레이션하기 위해 4GiB 파일을 읽거나 썼습니다.  클러스터에 32 노드만 있기 때문에 각각 2 개의 스레드를 실행 하는 32 클라이언트를 사용 하 여 64 스레드 데이터 지점을 얻었습니다.

그림 3에는 NSS 7.3을 사용 하는 NSS 7.4-HA의 임의 쓰기 및 읽기 입출력 성능이 비교 되어 있습니다. 그림처럼 NSS7.4가 NSS7.3-HA, ~7300 IOPS와 유사한 임의 쓰기 최고 성능을 보이는 것으로 나타났습니다.  NSS7.4-HA 솔루션의 경우 스레드 수가 1과 2로 더 적기 때문에 이전 버전의 솔루션에 비해 쓰기 성능이 약 14% 더 낮으며, 이에 대해서는 현재 조사 중입니다.  임의 읽기 성능은 NSS7.4에서 꾸준히 증가하여 64 스레드에서 16607 IOPS의 최고 성능을 발휘합니다. 이전 릴리스(NSS7.3-HA)에서는 32개 스레드에서 28811 IOPS의 최고 성능을 달성했으며, 이는 NSS7.4-HA 솔루션의 임의 읽기에서 얻은 최고 성능보다 42% 더 높습니다. IPoIB 임의 I/O 성능



 

IPoIB 메타데이터 작업

시스템의 메타데이터 성능을 평가하기 위해 MDTest Tool 버전 1.9.3을 사용했습니다. 사용된 MPI 배포는 OpenMPI 버전 1.10.7이었습니다.  메타데이터 테스트는 최대 32개의 스레드에 대해 960000개의 파일을 생성한 후 파일 수를 늘려 표 5에 나와 있는 것처럼 솔루션의 확장성을 테스트하여 수행했습니다. 메타 데이터 테스트: 스레드 간의 파일 및 디렉토리 배포 

스레드 수	디렉터리당 파일 수	스레드당 디렉터리 수	총 파일 수
1	3000	320	960000
2	3000	160	960000
4	3000	80	960000
8	3000	40.	960000
16	3000	20	960000
32	3000	10	960000
64.	3000	8	1536000
128	3000	4	1436000
256	3000	4	3072000
512	3000	4	6144000

그림 4, 그림 5 및 그림 6은 파일 생성, 통계 및 제거 작업의 결과를 각각 보여줍니다. HPC 컴퓨팅 클러스터에 컴퓨팅 노드가 32개 있으므로 아래 그래프에서 각 클라이언트는 최대 32개에 대해 노드당 최대 1개의 스레드를 실행했습니다. 클라이언트의 수가 64개, 128개, 256개, 512개 경우, 각 노드가 2개, 4개, 8개 또는 16개의 작업을 동시에 실행했습니다. 그림 4: IPoIB 파일 생성


성능
그림 5: IPoIB fiel stat 성능



그림 6: IPoIB fie remove 성능



 

---

결론

다음 표에는 NSS7.4와 NSS7.3 간의 성능 차이가 요약되어 있습니다.  표 5:  NSS7.4 및 NSS7.3 HA 버전의 성능 비교

Dell EMC HPC NFS 스토리지	NSS7.4-HA	NSS7.4-HA NSS7.3-HA
순차 1MB 쓰기 피크: 1.4% 감소	4,834MB/s	4,906 MB/s
순차 1MB 읽기 피크: 0.7% 감소	7,024 MB/s	7,073 MB/s
임의 4KB 쓰기 피크: 0.7% 감소	7,290IOps	7,341IOps
임의 4KB 읽기 피크: 42% 감소	16,607IOps	28,811IOps
생성 작업/초 피크: 1.1% 감소	54,197Op/s	54,795Op/s
Stat 작업/초 최고: 35% 감소	522,231Op/s	808,317Op/s
작업 제거/두 번째 피크: 35% 감소	47,345Op/s	73,320Op/s

위 결과를 토대로, 현재 NSS7.4-HA 솔루션이 이전 모델인 NSS7.3-HA 솔루션과 비슷한 성능을 제공한다는 결론을 내릴 수 있습니다. 임의 읽기 성능 저하뿐만 아니라 파일 통계 및 파일 제거 작업에서 스레드 수가 많을수록 성능이 저하되는 이유가 NSS7.4-HA 솔루션의 성능을 벤치마킹하는 데 사용되는 제온 골드 6244 CPU(프로세서당 8개 코어)의 코어 수가 더 적기 때문인지 알아보기 위해 프로세서당 18개의 코어를 가진 제온 골드 6240 CPU로 벤치마크 테스트를 실시할 계획입니다.

---

참조

NSS-HA 솔루션에 대한 자세한 내용은 게시된 백서를 참조하십시오.

 

•  Dell HPC NFS 스토리지 솔루션 - Dell PowerEdge 13세대 서버의 고가용성(NSS6.0-HA) 구성, 릴리스 버전 NSS6.0-HA, 2014년 11월에 게시했습니다.
•  Dell HPC NFS 스토리지 솔루션 - 고가용성(NSS7.0-HA) 구성, 릴리스 버전 NSS7.0-HA, 2016년 5월에 게시했습니다.
•  Dell EMC Ready Solution for HPC NFS Storage, 릴리스 버전 NSS7.3-HA, 2019년 3월에 게시했습니다.