소개
요 블로그에서의 에피소드-1 우리는 RHCS,BlueStore 도입,실험실 하드웨어의 세부 사항, 벤치마킹 방법론과 성과 비교는 기본 Ceph 구성 vs 조정 Ceph 구성
이은 두 번째 에피소드의 성능 시리즈 블로그에 RHCS3.2BlueStore 에서 실행 되는 플래시 클러스터입니다. 블록 크기를 소형,중형 및 대형 범주로 분류하는 엄지 손가락 규칙은 없습니다. 따라서 우리는 작은 블록 크기 범주에 4 천개 지정,8 천개-64 천개 중간 및 1 메터-4 메터 큰 블록 크기 범주에. 이 에피소드에서는 랜덤 읽기,랜덤 쓰기 및 랜덤 읽기-쓰기 워크로드 패턴에 걸쳐 소형(4 천개),중형(8 천개-32 천개)및 대형(1 백만-4 백만)블록 크기에 대한 블록 스토리지의 성능 특성에 대해 알아봅니다.
요약
- 작은 블록 4 천개 워크로드,최대 2 전달.200 만 개의 랜덤 읽기,691,000 개의 랜덤 읽기 쓰기(70/30)및 463,000 개의 랜덤 쓰기 기능이 있습니다.
- 작은 블록 워크로드와 유사하게,중간 블록 성능은 중앙 처리 장치와 미디어 경합에 의해 제한되는 것으로 밝혀졌다.
- 대형 블록 4 메터 워크로드 피크 성능 기록 10.9 기가바이트/초 모든 세 테스트 패턴 즉,랜덤 읽기,쓰기 및 읽기-쓰기(70/30)혼합 의해 제한 될 때까지 클라이언트 네트워크 대역폭.
제 1 부:작은 블록 크기(4 킬로바이트)성능
키 테이크 아웃
- 랜덤 읽기 워크로드는 2 보였다.미디어 채도에 의해 병목 될 때까지 평균 대기 시간.
- 임의의 읽기-쓰기(70/30)혼합 작업량을 보여주었 691K IOPS@6ms 평균 대기 시간까지 병목 현상이 발생하여 Ceph 노드 CPU 의 리소스 경쟁이 일어납니다.2986>
- 무작위 쓰기:463,000.
요약
테스트의 이 부분에서,블록 스토리지 인터페이스는 랜덤 읽기,랜덤 쓰기 및 랜덤 읽기-쓰기(70/30)혼합 패턴에 걸쳐 작은 블록 크기(4 킬로바이트)워크로드로 실행되었습니다. 테스트 중에 캡처된 주요 메트릭에는 아이옵,평균,대기 시간,중앙 집중식 노드 및 미디어 사용률이 포함됩니다.
그래프-1 은 5 개의 모든 플래시 노드가있는 다양한 액세스 패턴에서 4 천개 블록 크기에 대한 최상위 성능을 보여줍니다. 따라서 최대 성능은 다음과 같습니다
- 2018 년 12 월 1 일,2018 년 12 월 1 일,2018 년 12 월 1 일,2018 년 12 월 1 일,2018 년 12 월 1 일,2018 년 12 월 1 일,2018 년 12 월 1 일,2018 년 12 월 1 일,2018 년 12 월 1 일,2018 년 12 월 1 일,2018 년 12 월 1 일,2018 년 12 월: 463 천개 아이옵스@11 천분의 1 초 평균 대기 시간
그래프-2 와 그래프-3 에서 캡처된 중앙 처리 장치와 미디어 활용은 다양한 워크로드 패턴의 병목 현상을 이해하는 데 도움이 되었습니다.
- 그러나 미디어 사용률도 높은 편인 것으로 나타났습니다. 따라서 무작위 읽기 성능이 더 높아질 수 있습니다.
- 랜덤 쓰기 및 랜덤 읽기-쓰기(70/30)혼합의 경우 성능이 더 높은 프로세서 소비로 병목되었습니다. 흥미롭게도 동시에 미디어 연산 능력의 부족 때문에 사용 하지 않는 남아 있는 충분 한 예비 처리량을 했다. 따라서 무작위 쓰기&무작위 읽기-쓰기 혼합 워크로드에 대해 더 높은 성능을 제공할 수 있습니다. 2986>
데이터 사용률이 50%미만으로 유지된 인텔 옵테인 디바이스는 블루스토어 월 및 록스데이비데이터 메타데이터를 호스팅하고 있는 90%가 매우 바쁜 것으로 밝혀졌다. 16 킬로바이트 미만의 모든 쓰기가 지연된 경우,쓰기가 먼저 월마트 장치로 이동한 다음 비동기적으로 오에스디데이터에 기록됩니다. 2015 년 11 월 15 일에 확인함. 그러나 이러한 경험을 바탕으로 우리는 하나의 인텔 옵테인 뒤에 7 개 이상의 장치를 넣어 권하고 싶지 않다.
그래프 2
그래프 3
우리가 실행 한 또 다른 흥미로운 테스트는 클라이언트 스윕 테스트로,20 에서 시작하여 최대 140 까지의 클라이언트 수를 선형으로 확장했습니다. 클라이언트 부하를 증가시키면서 선형 성능 향상을 관찰했습니다. 100 명의 클라이언트와 함께 우리는~445,000 개의 집계 된 4,000 개의 쓰기 작업을 관찰했습니다. 이 시점 시스템 자원 혼잡 후 높은 꼬리 대기 시간 결과. 메타 데이터로 사용되는 인텔 옵테인은 평균 대기 시간이 40 밀리초 미만으로 유지되므로 많은 수의 병렬 클라이언트와 함께 대기 시간 스파이크를 흡수하는 데 도움이되었습니다.
지
파트-2: 중간 블록 크기 성능
주요 테이크 아웃
- 중앙 처리 장치 및 미디어 포화에 의해 성능이 병목 될 때까지 5 개의 올 플래시 네트워크 노드가~180 만 개의 랜덤 읽기,~636,000 개의 랜덤 읽기(70/30)및~410,000 개의 랜덤 쓰기 기능을 전달했습니다.2986>
- 성능을 확장하려면 기존 클러스터에 추가 노드가 추가되어야 했습니다.
요약
다음 그래프에서는 아이옵,평균 대기 시간,꼬리 대기 시간,중앙 집중식 노드 및 미디어 사용률과 같은 다양한 데이터 포인트를 표현하려고 시도했습니다. 랜덤 쓰기,랜덤 읽기 및 랜덤 읽기-쓰기(70/30)믹스를 위해 4,000 에서 최대 64,000 사이의 블록 크기 범위에 걸쳐이 모든 것을 제공합니다.
몇 가지 흥미로운 데이터 포인트는
- 예상대로,작은 블록 크기는 중간 블록 크기에 비해 가장 높은 아이옵 및 낮은 평균 및 꼬리 대기 시간을 보였다. 따라서 우리는 무작위 읽기,무작위 읽기 쓰기 혼합 및 무작위 쓰기 워크로드에 대해 각각~180 만,~636,000,~410,000 을 관찰했습니다.
- 중앙 처리 장치 및 미디어 장치에서 높은 사용률이 관찰되었다. 사용률은 중앙 처리 장치와 미디어에 대해 각각~90%및~80%로 높은 것으로 나타났습니다. 따라서 기존 클러스터에 노드를 추가할 수 있습니다.
3297
2 부:대형 블록 크기 성능
주요 테이크 아웃
- 대형 블록 4 미터 성능은 10 에서 정점에 도달했습니다.9 기가바이트/초 랜덤 읽기,쓰기 및 읽기-쓰기(70/30)믹스.
- 클라이언트 네트워크가 제한 요인으로 발견되어 성능 병목 현상이 발생했습니다.
- 성능이 더 높았을 수도 있고,더 많은 클라이언트 노드 또는 더 큰 네트워크 파이프가 있었을 수도 있습니다.
요약
우리가 테스트 한 모든 다른 패턴,즉 대형 블록 크기에 대한 무작위 읽기,쓰기 및 읽기-쓰기(70/30)혼합 4 백만 워크로드는 10.9 기가 바이트/초 집계 처리량을 차지했습니다. 클라이언트 네트워크가 성능 병목 현상을 일으키는 제한 요인으로 확인되었습니다. 그러나 네트워크 이외의 두 번째로 가장 많이 사용되는 리소스는 미디어였으며,네트워크가 병목 현상이 아닌 경우 더 많은 성능을 제공 할 수있는 충분한 헤드 룸을 확보했습니다.
다음 섹션에서는 벤치마킹 블로그 시리즈를 계속 진행하면 확장성 테스트 3.2 와 관련된 결과를 설명합니다. “3 노드 클러스터에서 5 노드로 이동하여 성능이 어떻게 변경됩니까?”와 같은 몇 가지 주요 질문에 답하십시오. 계속 지켜봐 주시기 바랍니다.