PowerScale, Isilon OneFS: Isilon에서 HBase 성능 테스트(영문)

소개

YCSB 벤치마킹 제품군 및 CDH 5.10을 사용하여 Isilon X410 클러스터에서 일련의 성능 벤치마킹 테스트를 수행했습니다.

CAE POC 실습 환경은 OneFS 8.0.0.4 이상 8.0.1.1 NFS 대형 블록 스트리밍 벤치마크를 실행하는 Isilon x410 노드 5개로 구성되었습니다. 이러한 테스트에서 이론상 최대 집계값은 5x~700MB/s 쓰기(3.5GB/s) 및 5x ~1GB/s 읽기(5GB/s)를 예상해야 합니다.

9개의 컴퓨팅 노드는 각각 2개의 18C/36T-인텔 제온® CPU E5-2697 v4@ 2.30GHz, 512GB RAM으로 구성된 CentOS 7.3.1611을 실행하는 Dell PowerEdge FC630 서버입니다. 로컬 스토리지는 RAID 1의 2xSSD로 운영 체제와 스크래치 공간/스필 파일 모두에 대해 XFS 형식으로 포맷됩니다.

또한 YCSB 로드를 구동하는 데 사용된 3개의 추가 엣지 서버가 있었습니다.

컴퓨팅 노드와 Isilon 간의 백엔드 네트워크는 NIC 및 스위치 포트에 대해 점보 프레임 세트(MTU=9162)가 있는 10Gbps입니다.

초기 테스트

첫 번째 테스트 시리즈는 전체 출력에 영향을 미치는 HBASE 측의 관련 매개변수를 결정하는 것이었습니다. YCSB 툴을 사용하여 HBASE에 대한 로드를 생성했습니다. 이 초기 테스트는 YCSB 및 4,000만 행의 '로드' 단계를 사용하여 단일 클라이언트(엣지 서버)를 사용하여 실행되었습니다. 이 표는 각 실행 전에 삭제되었습니다.
 

ycsb load hbase10 -P workloads/workloada1 -p table='ycsb_40Mtable_nr' -p columnfamily=family -threads 256 -p recordcount=40000000

hbase.regionserver.maxlogs - WAL(Write-Ahead Log) 파일의 최대 개수입니다. HDFS 블록 크기(dfs.blockize)를 곱한 값은 서버 충돌 시 재생해야 하는 WAL의 크기입니다. 이 값은 디스크에 대한 플러시 빈도에 반비례합니다.

hbase.wal.regiongrouping.numgroups - 여러 HDFS WAL을 WALProvider로 사용하는 경우 각 RegionServer에서 실행해야 하는 쓰기 미리 로그의 개수를 설정합니다. 이 수의 HDFS 파이프라인이 발생합니다. 지정된 리전에 대한 쓰기는 단일 파이프라인으로만 이동하여 총 RegionServer 로드를 분산합니다.

이 철학은 가능한 한 많은 쓰기를 병렬화하여 WAL 수를 늘리고 WAL당 스레드(파이프라인)의 수를 늘리는 것이었습니다. 이전 두 차트는 'maxlogs' 128 또는 256에 대해 지정된 번호에 대해 실제 변경 사항이 없음을 보여 줍니다. 이는 클라이언트 측에서 이 숫자를 실제로 푸시하지 않는다는 것을 나타냅니다. Oby는 파일당 '파이프라인'의 수를 다양하게 지정하지만 병렬화에 민감한 매개변수를 나타내는 추세를 볼 수 있습니다. 다음 질문은 Isilon이 디스크 I/O, 네트워크, CPU 또는 OneFS를 통해 "방해"하는 위치이며 Isilon 통계 보고서를 확인할 수 있습니다.


 
네트워크 및 CPU 그래프를 통해 Isilon 클러스터의 활용도가 0이 되며 더 많은 작업을 수행할 수 있는 공간이 있음을 알 수 있습니다. CPU는 > 80%이고 네트워크 대역폭은 3GB/s를 초과합니다.



이러한 플롯은 HDFS 프로토콜 통계와 OneFS에서 변환하는 방법을 보여줍니다. HDFS 운영은 dfs.blockize의 배수로, 여기서는 256MB입니다. 여기서 흥미로운 점은 '히트' 그래프에 OneFS 파일 작업이 표시되며 쓰기 및 잠금의 상관 관계를 볼 수 있다는 것입니다. 이 경우 HBase는 WAL에 추가를 수행하므로 OneFS는 추가된 각 쓰기에 대해 WAL 파일을 잠급니다. 클러스터 파일 시스템에서 안정적인 쓰기를 기대할 수 있습니다. 이러한 테스트는 이 테스트 세트의 제한 요인에 기여하는 것으로 보입니다.

HBase 업데이트

다음 테스트는 규모에 따라 어떤 일이 벌어지는지 좀 더 실험하는 것이었습니다& 10억 행 테이블을 생성한 다음 YCSB를 실행하여 'workloada' 설정(50/50 읽기/쓰기)을 사용하여 1,000만 개의 행을 업데이트했습니다. 이 작업은 단일 클라이언트에서 실행되었으며, 생성할 수 있는 처리량도 가장 많이 찾고 있었기 때문에 이를 YCSB 스레드 수의 함수로 실행했습니다. 다른 한 가지 참고로, Isilon을 일부 튜닝하고 OneFS 8.0.1.1로 이동하여 데이터 노드 서비스에 대한 성능 조정을 수행했습니다. 이전 실행 세트와 비교하여 성능이 상승하는 것을 볼 수 있습니다. 이러한 실행을 위해 hbase.regionserver.maxlogs = 256 및 hbase.wal.regiongrouping.numgroups = 20을 설정합니다.

이러한 실행을 보면 가장 먼저 눈에 보이는 것은 스레드 수가 많을 때의 낙하입니다. 이것이 Isilon 문제인지 아니면 클라이언트 측 문제인지 궁금했습니다. 향후 단락에서 이와 관련하여 몇 가지 추가 테스트를 볼 수 있습니다. 하지만 3ms의 업데이트 레이턴시로 200K+ Ops를 < 구동하는 것은 인상적이라고 할 수 있습니다. 이러한 업데이트 실행은 각각 빠르며 하나씩 수행할 수 있으며 아래 그래프는 이러한 실행에 대한 Isilon 노드 전체의 균등한 균형을 보여줍니다.



열 그래프에서 파일 작업이 WAL 프로세스의 추가 특성에 해당하는 쓰기 및 잠금이라는 것을 다시 볼 수 있습니다.

지역 서버 확장

다음 테스트는 Isilon 노드(그 중 5개)가 다른 수의 리전 서버와 어떻게 비교할지를 결정하는 것이었습니다. 이전 테스트에서 실행된 동일한 업데이트 스크립트가 여기에서 실행되었습니다. 단일 클라이언트와 YCSB 스레드가 51개인 'workloada'를 사용하여 10억 행 표와 1,000만 행을 업데이트한 결과, maxlogs 및 파이프라인(각각 256 및 20)에서도 동일한 설정을 유지했습니다.

 
결과는 놀라운 일이 아니지만 유용한 정보입니다. HBase의 스케일 아웃 특성과 Isilon의 스케일 아웃 특성이 결합되어==더 우수합니다. 이 테스트는 고객이 자체 사이징 연습의 일환으로 자신의 환경에서 실행하는 것을 권장하는 테스트입니다. 반품이 줄어들 수도 있지만, 여기에 5개의 Isilon 노드를 밀어붙이는 9개의 서버가 있으며 더 많은 것을 위한 공간이 있는 것 같습니다.

더 많은 클라이언트

마지막 일련의 테스트는 테스트 중인 시스템을 중단시키는 깊은 어두운 곳에서 수행됩니다. 결국, 테스트가 중단될 때까지 테스트를 래치업하여 테스트 중인 매개변수의 상한이 무엇인지 아는 것은 완벽하게 유효한 과학적 방법입니다. 이 일련의 테스트에서는 클라이언트를 실행하는 데 사용할 수 있는 서버가 두 개 추가되었습니다. 또한 각각 2개의 YCSB 클라이언트를 실행하여 각각 512개의 스레드를 구동하는 6개의 클라이언트까지 확장할 수 있었고, 이는 전체적으로 4,096개의 스레드가 될 것입니다. 다시 돌아가서 40억 개의 행이 600개 리전으로 분할되고 1개는 4,000만 행이 90개 지역으로 분할된 두 개의 테이블을 만들었습니다.  

 



 

보시다시피 이 테스트에서 테이블의 크기는 거의 중요하지 않습니다. Isilon 히트 차트를 다시 보면 40억 행 표에서 4억 행 행으로의 차이와 파일 작업 수가 대부분 인라인으로 표시되는 비율이 몇 퍼센트 차이가 있음을 알 수 있습니다.

결론

HBase는 주로 스케일 아웃 아키텍처 때문에 Isilon에서 실행할 수 있는 좋은 후보입니다. HBase는 자체 캐싱을 많이 수행하며, HBase에서 데이터로 스케일 아웃할 수 있는 많은 지역에 걸쳐 테이블을 분할하고 있습니다. 즉, 자체 요구 사항을 잘 처리하며 파일 시스템은 지속성을 보장합니다. 로드 테스트를 실제 중단 지점으로 푸시할 수는 없지만 HBase 설계에서 40억 행을 살펴보고 레이턴시가 3ms 미만인 800,000개의 작업을 예상하는 경우 이 아키텍처가 이를 지원합니다. HBase 자체에 적용할 수 있는 수많은 다른 클라이언트 측 조정 사항에 대해 자세히 언급하지 않았다면 이 모든 조정 사항이 여전히 유효하고 이 테스트 범위를 초과할 것으로 예상됩니다.