PowerStore: 스토리지 어레이 성능 평가를 위한 효과적인 기법

참고: 벤치마킹은 모든 것이 PowerStore 모범 사례에 따라 설정되었으며 연결 또는 구성 문제가 없는 경우에만 유효합니다. 그렇지 않으면 테스트에서 관련 없는 데이터가 생성될 수 있습니다.

• 실제 워크로드/환경과 유사한 변수를 사용하여 테스트합니다. 대부분의 툴은 시뮬레이터이며 시뮬레이션된 실제 프로덕션 워크로드의 100%를 달성할 수 없습니다.
• 워크로드 범위가 넓은 경우 다양한 블록 크기 및 액세스 패턴으로 읽기/쓰기 테스트를 여러 번 반복하는 것이 좋습니다.
• 멀티스레드 및 비동기 작업이나 테스트를 사용하여 병렬 또는 동시 성능 기능을 보장하고 전체 집계 처리량 가능성이 실행되고 있는지 확인합니다. 
• 비즈니스의 생산 워크로드와 관련하여 평가 중인 장비에 대한 업계 표준 벤치마크를 고려하고 검토하십시오.
• 비어 있거나 공간 사용량이 적은 파일 시스템 및/또는 볼륨에 대한 테스트를 피하십시오. 쓰기 워크로드에 공간을 사전 할당하지 않으면 테스트 중에 공간의 즉석 할당으로 인해 지연 시간이 발생할 수 있습니다.
• 읽기 I/O는 대부분의 환경에서 일반적으로 두 가지 중 가장 많이 사용되므로 테스트하는 것을 잊지 마십시오. 테스트 중 네트워크 인프라스트럭처의 패킷/프레임 손실에 유의하십시오.
• 호스트 또는 클라이언트가 많은 일반적인 환경을 시뮬레이션하기 위해 여러 디바이스에 대해 테스트하고 있는지 확인합니다. 예를 들어 PowerStore에서는 16개의 볼륨이 적합합니다. 볼륨 수는 일반적으로 사용된 호스트 또는 클라이언트(물리적 또는 가상)의 수와 일치합니다. 여기서 동시성이 달성됩니다.

 

벤치마킹 툴 및 시뮬레이터
대부분의 도구는 시뮬레이터이며 실제 프로덕션 워크로드를 100% 시뮬레이션할 수 없다는 점을 명심하십시오. 이러한 벤치마킹 툴은 특정 상황에서 성능이 어떻게 될 수 있는지, 어떻게 해야 하는지 또는 어떻게 할 것인지에 대한 아이디어를 얻는 데 사용됩니다. Dell은 이러한 툴을 소유하지 않으며 이와 연관될 수 있는 문제에 대해 책임을 지지 않습니다.

모든 성능 테스트 상황에서 비동기 및 멀티스레딩 기능이 있는 툴을 사용해야 합니다. 이러한 도구의 예는 다음과 같습니다.

• 플렉시블 I/O 테스터(FIO)
• IOmeter
• Vdbench(브이드벤치) (Oracle 계정 필요)
• NFSometer (Fedora/NFS 전용)
• 인텔의 NAS 성능 체크리스트

 

다음과 같은 유형의 테스트를 피하십시오.

• 복사 및 붙여넣기
• 끌어서 놓기
• 디스크에 단일 파일 시스템 백업
• DD 테스트
• 라지(Rlarge)
• Wlarge(라지)
• mk파일
• 압축 풀기, 추출 및 압축

대부분의 벤치 마킹 시나리오에서 주의해야 할 몇 가지 사항이 있습니다. 이 섹션은 워크로드 규모 및 특성의 이해를 대체하는 것은 아닙니다. 그러나 과거 데이터가 부족하고 PowerStore의 기능(특정 워크로드 성능이 아님)을 벤치마킹하기 위해 애플리케이션 동작을 대략적으로 추정해야 하는 경우에는 다음 요소를 고려하십시오.

 

 

IODepth(큐 크기)
IOdepth가 낮거나 충분히 높지 않으면 상황에 따라 잠재적 처리량이 제한될 수 있습니다. 따라서 IOdepth가 워크로드의 동시성 요구 사항을 반영하거나 에뮬레이트할 수 있을 만큼 충분히 높은지 항상 확인하십시오. IOdepth가 너무 낮으면 디바이스를 최대한 활용하지 못할 수 있습니다. 또한 IOdepth가 너무 높으면 디바이스에 상당한 대기열이 발생할 수 있으며 디바이스의 서비스 시간에 따라 결과적으로 응답 시간이 길어질 수 있으므로 주의하십시오. 이는 과부하된 시스템의 모습을 반영할 수 있습니다.

이 테스트의 경우 IOdepth가 1일 때 64와 같은 실제 세계의 IOdepth와 비교할 때 숫자가 훨씬 낮습니다. 이것은 올플래시 어레이와 관련이 있으므로 이 개념은 극단적이지만 점점 더 일반적인 형태로 보입니다."

IOdepth=1" 테스트의 경우 약 ~30,000 IOPS(Input and Output Operations Per Second) 평균입니다.

 

"IOdepth=64"는 테스트에서 약 ~107,000 IOPS 평균입니다.

 

 

테스트의 "IOdepth=256"은 약 ~142,000 IOPS 평균입니다.

 

 

앞서 언급했듯이 성능은 대부분의 구성에서 특정 IOdepth에서 향상됩니다. 여기서는 대기열 깊이가 512이고 IOdepth 64에서 IOPS가 약간 증가합니다."

IOdepth=512"이며 테스트의 경우 약 ~146,000 IOPS 평균입니다.

 

 


비동기 vs 동기화
사용되는 두 가지 주요 고유 엔진이 있습니다. 성능 측면에서 가장 인기 있고 가장 효율적인 것은 "비동기 I/O"입니다. 효율성과 성능이 떨어지는 엔진 유형은 동기식 I/O이며 일반적으로 엄격한 데이터 무결성 및 보증 요구 사항이 있는 애플리케이션에 사용됩니다. 동기식 I/O는 0에 가까운 RPO(Recovery Point Objective) 복제 기술에서도 찾아볼 수 있습니다. 성능 테스트 및 벤치마킹에서 호스트 관점에서 비동기식은 다음 I/O를 요청하기 위해 단일 I/O에 대한 승인이 필요하지 않음을 의미합니다. 동기식 워크로드에서는 다음 I/O가 실행되기 전에 I/O에 대한 승인이 필요하고 요청된 모든 후속 I/O에 대해 승인(ACK)이 필요합니다. 따라서 동기 I/O에는 일반적으로 1개 이하의 큐가 있으며 리소스를 최대한 활용하지 않습니다. 동기 작업을 스레드 수가 적거나 단일 스레드와 결합하면 성능 잠재력이 심각하게 제한될 수 있으므로 항상 비동기 테스트를 수행하고 있는지 확인하고 동기 테스트를 사용하는 경우 애플리케이션 환경에서 명시적으로 언급하지 않는 한 여러 스레드를 사용해야 합니다.

비동기(Libaio - Linux 네이티브 비동기) = 1스레드



동기(동기식 I/O):  

 

 

스레드 개수
스레드는 중요합니다. 테스트는 특히 동기 테스트/워크로드에서 항상 여러 스레드를 사용하여 수행해야 합니다. 이는 엔터프라이즈 애플리케이션 프로세스의 동작을 기반으로 작업/테스트의 여러 반복을 시뮬레이션하기 위한 것입니다. 동시 작업과 결합된 다중 스레드는 시스템의 총 처리량이 달성되는 곳입니다. 대부분의 비동기 엔진은 여러 스레드를 사용하므로 스레드 수에 대해 크게 걱정할 필요가 없습니다. 동기 작업 중에 스레드가 충분하지 않으면 시스템에 대한 부하 테스트의 총 잠재적 처리량을 심각하게 제한할 수 있습니다."

멀티스레드"는 여러 스레드가 병렬로 작업하는 것을 의미합니다. 예를 들어 동기 워크로드에서 1000 IOPS를 서비스할 수 있는 단일 디바이스가 있는 경우 큐 없이 응답 시간이 1ms인 디바이스로 나옵니다(따라서 큐 없음, 서비스 시간 및 응답 시간은 동의어여야 함). 분명히 응답 시간이 1ms인 디바이스는 1000 IOPS보다 훨씬 더 많은 작업을 수행할 수 있으며, 이는 동일한 워크로드의 여러 스레드 또는 병렬 스트림을 스태킹하여 달성할 수 있습니다. 따라서 스레드 (또는이 특정 작업을 수행하는 작업)를 10으로 늘리면 이제 1ms에서 장치에 대한 I / O를 수행하는 10 개의 개별 스레드가 있습니다. 각 개별 워크로드 스레드는 여전히 1ms를 얻고 있습니다. 즉, 각 스레드는 여전히 1000 IOPS에 도달하고 있지만 이제 이러한 여러 스레드에 의해 실행되는 전체 "프로세스" 또는 "작업"은 10,000 IOPS를 얻고 있습니다.

단일 스레드로 디바이스의 한계에 적절하게 도달할 수 있는 툴과 워크로드가 있으며 일부는 더 많이 필요합니다. 요약하면, 동기 로드를 시뮬레이션할 때 전체 응답 시간에 영향을 주지 않고 가능한 한 많은 스레드/작업자/스트림을 사용하려고 합니다. 스레드 수를 늘리면 더 이상 긍정적인 영향을 미치지 않는 지점이 있습니다(장치가 100% 사용 중일 때). 일반적으로 비동기 워크로드의 경우 스레드 수가 기본적으로 처리됩니다. 예를 들어 아래에서는 비동기 워크로드에 대해 1개의 스레드와 10개의 차이가 있지만 중요하지는 않지만 여전히 볼 수 있습니다. 이 이야기의 교훈은 비동기 워크로드를 사용하면 스레드에 대해 많이 걱정할 필요가 없다는 것입니다. 

여기서 단일 스레드는 "libaio"(비동기) 엔진을 사용하여 68,000 IOPS를 달성할 수 있습니다. 

 

스레드(numjobs)를 10으로 늘리면 IOPS가 계속 증가하는 것을 볼 수 있습니다.

 

동기식 워크로드의 경우 극단적인 경우이지만 테스트의 성능이 저하되는 두 가지 주요 요인이 있을 수 있습니다. 바로 동기식 특성입니다. 

I/O-1 보내기, ACK 대기, I/O-2 보내기, ACK 대기 등

 그리고 동일한 목적을 위해 여러 스레드를 쌓을 수 없습니다. 

job1=송신 I/O-1 - job2=송신 I/O-1 - job3=송신 I/O-1..... job1=get ack, 송신 I/O-2 - job2=get ack, 송신 I/O-2 - job3= get ack, 송신 I/O-2 등

직접 플래그

일부 도구, 특히 *nix 기반 도구/OS를 사용하면 "Direct I/O" 옵션이 표시될 수 있습니다. 이는 "비동기" 엔진과 함께 사용할 수 있으며 "동기" I/O와 혼동해서는 안 됩니다. 이 플래그가 지정되지 않은 일부 도구에서는 디스크에 직접 쓰지 않고 서버 캐시에 쓸 수 있습니다. 호스트가 원하는 것은 자체 캐시를 우회하고 디스크에 직접 쓰는 것입니다. 이는 스토리지를 테스트할 때 필수적인 요소입니다. "direct" 플래그가 설정되어 있으면 기술적으로 디스크에 쓰는 것이지만 이 경우 "disk"는 실제로 스토리지 캐시입니다. 이는 올바른 워크로드가 있더라도 실제 환경에서 이 워크로드가 동작하는 방식을 시뮬레이션하고 정확하게 모방하기 때문에 테스트 목적으로 여전히 허용됩니다. 프로덕션 로드도 승인을 다시 보내기 전에 캐시에 도달합니다. (백엔드 스핀들뿐만 아니라 관련된 캐시의 성능 수치를 얻는다고 해서 속았다고 생각하지 마십시오.)

 

대역폭(MB/s) 대 처리량(IOPS)

테스트할 수 있는 두 가지 주요 관점이 있습니다. 네트워킹 및 성능 영역에서의 처리량은 일반적으로 데이터 전송을 의미하지만, SAN/블록 환경에서는 IOPS를 나타내기 위해 "처리량"을 사용하는 것이 일반적입니다. 따라서 먼저 테스트하려는 워크로드 특성을 이해해야 합니다.

대역폭(MB/s) - 대역폭은 파이프 또는 시스템에서 한 번에 (또는 X 간격 내, 일반적으로 "초당") 맞출 수 있는 데이터의 측정값입니다. 즉, 일정 기간 동안 전송한 데이터의 양을 측정합니다. 대역폭과 IOPS는 상호 배타적이지 않지만 동일한 양의 IOPS로 더 높거나 더 낮은 대역폭 수를 가질 수 있으며 모두 블록 크기에 따라 다릅니다. 대역폭으로 속도를 측정하는 것이 아닙니다. 속도는 완전히 다른 것입니다. 대역폭에 영향을 미치기는 하지만 일반적으로 고대역폭 워크로드에서는 제어할 수 없는 것입니다. 따라서 대역폭을 테스트하는 경우 I/O당 데이터가 IOPS를 테스트하는 경우보다 커지도록 항상 큰 블록을 사용하십시오(합리적인 범위 내에서). 예를 들어 1MB/s를 달성하고 싶지만 8KB 블록 크기를 사용하는 경우 이를 달성하려면 약 125 IOPS를 푸시해야 합니다. 그러나 512KB 블록을 사용하는 경우 2개의 IOPS만 필요합니다.
(125 IOPS를 유지하면서 블록 크기를 8KB에서 512KB로 늘리면 이제 64MB/s가 푸시됩니다!)

그러나 단일 I/O 내에 더 많은 데이터가 있기 때문에 일반적으로 해당 I/O를 "패키지"하는 데 시간이 더 오래 걸립니다(찾기, 함께 연결 등). 따라서 서비스 시간은 자연스럽게 더 길어질 수 있습니다. 때로는 대기열이 더 작기 때문에 응답 시간은 당연히 더 높지만 다소 가까워야 합니다. 응답 시간은 달성할 수 있는 대역폭의 양에 중요한 역할을 하지만 일반적으로 I/O당 데이터 양의 증가가 해당 I/O 유형당 응답 시간(RT)의 약간의 증가보다 큽니다. 응답 시간이 더 길기 때문에 대형 블록 워크로드가 랜덤이 되는 것을 원하지 않습니다. 따라서 대역폭 워크로드는 순차적인 경향이 있습니다. 대규모 블록 워크로드에 랜덤 속성을 도입하면 안정적인 데이터 전송 속도가 지속적으로 중단되고 I/O당 약간 더 높은 응답 시간의 영향을 느끼기 시작합니다.

처리량(IOPS) - 처리량/IOPS는 특히 랜덤하게 증가하는 소규모 블록 워크로드에 대한 가장 일반적인 관점입니다. 32KB-64KB를 초과하는 것은 큰 블록으로 간주될 수 있습니다. 처리량에서는 위에서 언급한 요소(예: 스레드 수, 동기화 또는 비동기, 큐 크기 등)가 가장 중요합니다. 여기서는 X 간격 동안 전송할 수 있는 전체 데이터의 양이 아니라 서비스하려는 해당 데이터를 전달하는 개별 패키지(I/O 요청)의 수(x 간격마다)를 측정하려고 합니다. OLTP(뱅킹)와 같은 환경에서는 데이터 공간이 대개 작기 때문에 전송할 수 있는 데이터의 양에 대해 크게 신경 쓰지 않습니다. 그러나 이러한 작은 데이터 집합은 대개 사용 중일 수 있습니다. 이러한 데이터 집합에는 높은 편향이 있습니다(적은 양의 공간이 참조되지만 적극적이고 일관되게 변함). 작은 데이터 패키지에는 일반적으로 숫자 또는 더 작은 문자열 값을 가진 블록을 변경/업데이트하기 위한 요청만 포함되므로 큰 I/O 패키지가 필요하지 않습니다. 그러나 거래의 특성과 그 수가 너무 많기 때문에 각 개별 수요를 따라갈 수 있는지 확인하려고 합니다. 일반적으로 블록 크기가 작을수록 주어진 시나리오에서 더 많은 IOPS를 달성할 수 있으며, 작은 블록 워크로드는 대부분 랜덤 액세스와 관련이 있지만 작은 블록 순차적 워크로드를 사용하면 훨씬 더 많은 처리량을 달성할 수 있습니다. 그러나 소규모 블록 순차적 워크로드는 구체적이고 일반적이지 않으므로 환경에 필요한 경우에만 이러한 시나리오를 테스트하십시오.