X-IO Technologies ISE 1 G860 리뷰의 3부에서는 ISE 860 G3의 개요를 설명하고 애플리케이션 및 합성 벤치마크를 살펴보았습니다. 간단히 요약하면 플랫폼은 MySQL, SQL Server 및 합성 워크로드를 포함하여 우리가 던진 모든 작업에서 탁월한 성능을 보였습니다. 검토의 두 번째 부분에서는 VMmark 테스트를 통해 ISE 860 G3의 VMware 가상화 테스트를 확장하고 부하 상태에서 컨트롤러에 장애를 일으키고 MySQL 워크로드에서 ISE 860 G3의 QoS 엔진에 스트레스를 줄 것입니다.
X-IO Technologies ISE 1 G860 리뷰의 3부에서는 ISE 860 G3의 개요를 설명하고 애플리케이션 및 합성 벤치마크를 살펴보았습니다. 간단히 요약하면 플랫폼은 MySQL, SQL Server 및 합성 워크로드를 포함하여 우리가 던진 모든 작업에서 탁월한 성능을 보였습니다. 검토의 두 번째 부분에서는 VMmark 테스트를 통해 ISE 860 G3의 VMware 가상화 테스트를 확장하고 부하 상태에서 컨트롤러에 장애를 일으키고 MySQL 워크로드에서 ISE 860 G3의 QoS 엔진에 스트레스를 줄 것입니다.
VMmark 성능 분석
당사의 모든 애플리케이션 성능 분석과 마찬가지로 성능에 대한 회사의 주장과 비교하여 실제 생산 환경에서 제품이 어떻게 작동하는지 보여주려고 합니다. 우리는 스토리지를 더 큰 시스템의 구성 요소로 평가하는 것의 중요성을 이해하고 있으며, 가장 중요한 것은 주요 엔터프라이즈 애플리케이션과 상호 작용할 때 스토리지가 얼마나 반응이 좋은지 이해하고 있습니다. 이 테스트에서 우리는 VMware의 VMmark 가상화 벤치마크 다중 서버 환경에서.
VMmark는 설계상 매우 리소스 집약적인 벤치마크로, 스토리지, 네트워크 및 컴퓨팅 활동에 스트레스를 주는 VM 기반 애플리케이션 워크로드가 광범위하게 혼합되어 있습니다. 가상화 성능을 테스트할 때 VMmark는 스토리지 I/O, CPU 및 VMware 환경의 네트워크 성능까지 포함하는 많은 측면을 보기 때문에 이보다 더 나은 벤치마크는 거의 없습니다.
Dell PowerEdge R730 VMware VMmark 4노드 클러스터 사양
- Dell PowerEdge R730 서버(x4)
- CPU: Intel Xeon E5-2690 v3 2.6GHz(12C/24T) XNUMX개
- 메모리: 64 x 16GB DDR4 RDIMM
- Emulex LightPulse LPe16002B 16Gb FC 듀얼 포트 HBA
- Emulex OneConnect OCe14102-NX 10Gb 이더넷 듀얼 포트 NIC
- VM웨어 ESXi 6.0
ISE 860 G3(DataPac당 20×1.6TB SSD)
- RAID 이전: 51.2TB
- RAID 10 용량: 22.9TB
- RAID 5 용량: 36.6TB
- 리스트 가격 : $ 575,000
XIO ISE 860의 VMware VMmark 성능에 대한 초기 살펴보기에서는 다음을 사용합니다. Dell PowerEdge R730 13G 4노드 클러스터 워크로드의 원동력으로. 5개의 Intel E2690-3 v249.6 Haswell CPU를 갖춘 이 클러스터는 각 VMmark 타일의 일부로 실행되는 애플리케이션에 10GHz의 CPU 리소스를 제공합니다. 일반적으로 우리는 타일당 약 24GHz의 요구 사항을 보았습니다. 즉, 최적의 조건에서 이 클러스터는 26-5 타일 사이에서 실행할 수 있어야 합니다. 그 이상으로 서버를 클러스터에 추가하거나 E2697-3 v5 또는 E2699-3 vXNUMX와 같은 상위 계층 프로세서로 전환해야 합니다. 이는 이 클러스터가 가득 차도 스토리지에 여전히 더 높이 올라갈 수 있는 헤드룸이 있을 가능성이 높다는 것을 말하는 또 다른 방법입니다.
XIO ISE 860에서 VMmark 워크로드를 확장하면서 1타일에서 22타일로 강력한 선형 개선을 확인했습니다. 22타일 이후 컴퓨팅 클러스터가 CPU 사용률을 고정함에 따라 성능이 약간 떨어지기 시작했습니다. 클러스터가 클수록 XIO ISE 860은 추가 로드를 쉽게 처리할 수 있습니다. 1타일 실행 동안 대기 시간이 26ms 미만으로 측정되고 svmotion/deploy 작업 동안 소수의 한 자릿수 스파이크가 발생하여 배후에서 성능 모니터링에 뛰어들어 이를 뒷받침합니다. 지연 시간이 짧은 성능이 올플래시 어레이의 절대적인 필수 요소인 X-IO ISE 860은 전혀 실망하지 않습니다.
컨트롤러 고장 테스트
액티브/패시브 및 액티브/액티브와 같은 구성 차이뿐만 아니라 시장에는 다양한 SAN 설계가 있습니다. 장애 처리와 관련하여 두 설계 모두 기본 컨트롤러가 오프라인 상태가 되면 예비 컨트롤러 또는 보조 컨트롤러가 스토리지 작업을 대신할 수 있도록 합니다. 모든 플랫폼이 동일한 것은 아니기 때문에 서로 다른 플랫폼이 컨트롤러 실패에 어떻게 대처하는지 보여주는 데 점점 더 많은 관심을 갖게 되었습니다. 우리가 설계한 시나리오는 그 핵심이 다소 기본적입니다. 스토리지 어레이에 상당한 워크로드를 배포하고 워크로드가 안정 상태에 도달할 때까지 기다린 다음 컨트롤러를 가져옵니다. 이 프로세스 동안 우리는 성능 특성이 어떻게 변하는지 살펴보고 I/O 활동이 중단되었는지 모니터링하며 가장 중요한 것은 플랫폼이 테스트 중인 워크로드를 얼마나 빨리 재개하는지 살펴봅니다. X-IO ISE 860의 경우 Sysbench 워크로드를 사용했으며 4개의 인스턴스가 두 개의 볼륨에 분산되어 있습니다.
ISE 4에서 실행되는 860개의 Sysbench VM을 사용하여 워크로드가 스토리지 어레이에서 균등해질 때까지 대략 15분 동안 기다렸습니다. 이때 워크로드는 VM당 약 1,100TPS로 측정되었습니다. 하나의 컨트롤러를 당기면 모든 VM에서 3-4초 동안 성능이 감소하고 약 10초 동안 일시 중지한 다음 오류가 발생하기 전에 측정된 성능 수준을 빠르게 재개합니다. VMware ESXi 6.0 호스트는 이 스토리지 I/O 중단에 쉽게 대처하고 아무 일도 없었던 것처럼 계속 작동했습니다.
X-IO ISE Manager Suite에서 약 5분 후에 오류를 목격할 수 있었습니다(수동으로 새로 고치면 더 빨리 표시될 수 있음). 컨트롤러를 뽑은 후 10~15분 후에 X-IO 지원팀으로부터 컨트롤러 오류를 경고하는 자동 이메일 알림도 받았습니다.
기존 컨트롤러를 다시 접어 넣으려면(또는 교체 컨트롤러를 어레이에 추가하려면) 컨트롤러를 어레이의 뒷면에 삽입하고 어레이가 컨트롤러를 감지/분석하고 어레이와 병합할 수 있음을 나타내십시오. . 이 프로세스는 ISE Manager 컨트롤러 보기에 "추가" 버튼을 표시하는 데 몇 분이 걸렸습니다. 클릭한 후에는 비슷한 성능 저하를 보았고 어레이가 정상으로 돌아오기 전에 몇 초 동안 I/O가 일시 중지되었습니다. 원래의 실패와 마찬가지로 VMware ESXi 6.0은 이 중단을 처리하는 데 문제가 없었고 게스트 OS 수준에서 오류가 없었습니다. 이와 관련하여 모든 스토리지 어레이가 동일하게 생성되는 것은 아니며 ISE 860이 치명적인 오류를 쉽게 처리할 수 있다는 점을 확인하는 것이 좋습니다.
X-IO 기술 ISE 860 G3 QoS
검토의 첫 번째 부분에서 QoS에 대해 간략히 다루었습니다. 여기서는 좀 더 자세히 살펴보겠습니다. X-IO는 ISE 스토리지 어레이에서 QoS 기능을 제공합니다. QoS 설정은 사용자가 IOPS Max, IOPS Min 및 IOPS Burst를 지정할 수 있는 볼륨 수준에서 적용됩니다. 합성 결과는 주어진 장치에서 QoS 프로필이 얼마나 잘 작동하는지 보여주는 데 유용할 수 있지만 응용 프로그램이 QoS 프로필에 어떻게 반응하는지 확인하는 것이 훨씬 더 중요합니다. 이 섹션에서는 뛰어난 실시간 성능 모니터링 기능을 제공하는 Sysbench MySQL TPC-C 워크로드를 다시 사용했습니다. 시나리오에서는 한 볼륨에 두 개의 VM이 있고 다른 볼륨에 다른 두 개의 VM이 있는 4개의 VM 배포를 활용했습니다. 하나의 볼륨은 "프로덕션" 사용 사례로 설계되었습니다. 규제되지 않은 벤치마크에 비해 성능에 제한이 없기를 바라는 반면, 다른 볼륨은 "개발" 사용 사례가 될 것입니다. 이는 기본 스토리지에서 실행되는 여러 데이터베이스 인스턴스가 필요한 엔터프라이즈 설정을 반영하지만 개발 인스턴스는 프로덕션 VM에 영향을 줄 수 없습니다.
QoS를 활성화하고 볼륨 수준에서 구성하는 것은 X-IO ISE 860에서 매우 쉽습니다. 볼륨을 프로비저닝할 때 동일한 메뉴를 통해 설정에 액세스할 수 있으며 기본값은 "스토리지 규제" 또는 전체 성능입니다. QoS를 활성화하려면 IOPS 값을 입력하고 약간의 시행 착오를 거쳐 워크로드에 미치는 영향을 확인하십시오. 먼저 ISE Manager의 성능 보기를 통해 제한 없이 워크로드의 IOPS 수준을 모니터링하여 기준선을 얻는 것이 좋습니다. 이 경우 2개의 Sysbench VM이 20,000 IOPS 이상을 소비했으므로 프로덕션 워크로드를 실행하는 볼륨에서 최대 30k IOPS, 버스트 40k IOPS 및 최소 20k IOPS를 설정했습니다. 개발 볼륨의 경우 몇 가지 반복을 통해 I/O 프로필 제한이 라이브 Sysbench 실행에 어떤 영향을 미치는지 확인했습니다.
첫 번째 예는 QoS가 활성화된 상태로 프로덕션 볼륨에서 실행 중인 Sysbench를 보여줍니다. 우리는 규제되거나 완전히 제한되지 않은 스토리지에 비해 성능 변화가 없음을 확인했습니다.
개발 Sysbench 워크로드에서 낮은 성능 수준에도 불구하고 안정적으로 변환되는 성능 프로파일을 쉽게 제어할 수 있었습니다. 아래 예에서는 프로덕션 볼륨 성능의 절반으로 설정된 프로필에서 IOPS 수준을 원래의 25%로 낮추는 프로필로 변경했습니다. 보시다시피 I/O 중단이나 I/O 불안정 없이 성능 변화가 즉시 발생했습니다. 우선 순위가 높은 워크로드에 영향을 미칠 수 있는 잡음이 많은 이웃에 대해 우려하는 구매자를 위해 X-IO는 실제 조건에서 매우 잘 수행되는 고성능 QoS 기능 세트를 제공합니다.
파트 2 최종 생각
이 리뷰 시리즈의 두 번째 부분에서는 성능 및 서비스 문제를 광범위하게 살펴봅니다. 성능 면에서 ISE 860은 VMmark에서 26개의 타일을 제거하여 4노드 클러스터의 기능을 최대한 활용했습니다. 더 나아가 26타일 로드 쓰기 지연 시간은 1ms 미만으로 측정되었으며 스파이크는 10ms 미만이었습니다. ISE는 여기에 더 많은 헤드룸이 있으며, 이에 대해 더 자세히 살펴보겠습니다. XNUMX개의 서버가 던질 수 있는 모든 것을 가져가는 것은 결코 쉬운 일이 아니지만 그럼에도 불구하고 ISE가 다양한 워크로드에서 환상적인 성능을 계속해서 보여주기 때문에 예상되었습니다.
성능을 넘어 ISE 시리즈로 유명해진 X-IO의 주장 중 하나는 유지 관리가 필요 없다는 것입니다. 이 경우 드라이브에 오류가 발생해도 작동하지 않습니다. X-IO는 작동 중에 물리적으로 액세스할 수 있더라도 개별 드라이브 자체를 의도적으로 난독화하기 위해 스토리지를 집계합니다. 이 경우 활성 워크로드에 어떤 일이 발생하는지 확인하기 위해 컨트롤러를 정상적으로 가져오지 못했습니다. 두 번째 컨트롤러가 로드를 흡수하면서 약간의 깜박임과 함께 vCenter 또는 게스트 OS에서 문제 없이 모든 것이 계속되었습니다. 또한 ISE의 QoS 기능에 뛰어들어 볼륨별로 엄격한 제어가 가능합니다. 성숙한 QoS 기능은 기본 스토리지 어레이에서 널리 발견되지 않으므로 이러한 수준의 세분화된 액세스는 특히 기본 스토리지에서 중요하지 않은 개발 워크로드를 실행하거나 종종 잘 먹어 치울 수 있는 시끄러운 이웃이 있는 사람들에게 좋습니다. 자원의 공평한 몫 이상.
우리는 이 새로운 유형의 고성능 스토리지에 대한 테스트 전략을 추가로 개발하면서 ISE 860과 계속 협력할 것입니다. 다음 단계에는 블레이드 XNUMX개와 플래시 어레이가 능가할 수 있는 몇 가지 추가 워크로드가 있는 Cisco UCS Mini에 대한 테스트가 포함됩니다.
X-IO Technologies ISE 860 G3 검토: 1부
