VDI용 HPE SimpliVity 380 작동 방식: 까다로운 로드 테스트

고객은 VDI를 원했습니다. SimpliVity + VDI Citrix Virtual Desktop 조합을 실제로 살펴보았습니다. 사업자, 시청직원 등 모든 분들을 대상으로 합니다. 첫 번째 마이그레이션에만 XNUMX명의 사용자가 있으므로 부하 테스트를 고집했습니다. VDI는 속도가 느려지기 시작하고 침착하게 누울 수 있습니다. 채널 문제로 인해 항상 이런 일이 발생하는 것은 아닙니다. 우리는 VDI용으로 특별히 제작된 매우 강력한 테스트 패키지를 구입하여 디스크와 프로세서가 너무 무거워질 때까지 인프라를 로드했습니다.

따라서 정교한 VDI 테스트를 위해서는 플라스틱 병과 LoginVSI 소프트웨어가 필요합니다. 우리는 300명의 사용자를 위한 라이선스를 보유하고 있습니다. 그런 다음 서버당 최대 사용자 밀도 작업에 적합한 패키지에 포함된 HPE SimpliVity 380 하드웨어를 선택하고 초과 구독이 양호한 가상 머신을 잘라낸 다음 Win10에 Office 소프트웨어를 설치하고 테스트를 시작했습니다.

가자!

체계

HPE SimpliVity 380 Gen10 노드(서버) XNUMX개. 각각:

• 2개의 인텔 제온 플래티넘 8170 26c 2.1Ghz.
• RAM: 768GB, 12 x 64GB LRDIMM DDR4 2666MHz.
• 기본 디스크 컨트롤러: HPE Smart Array P816i-a SR Gen10.
• 하드 드라이브: 9 x 1.92TB SATA 6Gb/s SSD(RAID6 7+2 구성, 즉 HPE SimpliVity 용어로 중간 모델임).
• 네트워크 카드: 4Gb Eth(사용자 데이터) 1개, 2Gb Eth(SimpliVity 및 vMotion 백엔드) 10개.
• 중복 제거/압축을 위해 각 노드에 특수 내장 FPGA 카드가 있습니다.

노드는 SimpliVity 백엔드로 사용되며 NFS를 통해 가상 머신 데이터를 전송하는 데 사용되는 외부 스위치 없이 직접 10Gb 이더넷 상호 연결을 통해 서로 연결됩니다. 클러스터의 가상 머신 데이터는 항상 두 노드 간에 미러링됩니다.

노드는 vCenter에서 관리하는 Vmware vSphere 클러스터로 결합됩니다.

테스트를 위해 도메인 컨트롤러와 Citrix 연결 브로커가 배포되었습니다. 도메인 컨트롤러, 브로커 및 vCenter는 별도의 클러스터에 배치됩니다.


테스트 인프라로서 300개의 가상 데스크톱이 전용 – 전체 복사 구성으로 배포되었습니다. 즉, 각 데스크톱은 가상 머신 원본 이미지의 완전한 복사본이며 사용자가 변경한 모든 내용을 저장합니다.

각 가상 머신에는 2vCPU와 4GB RAM이 있습니다.

테스트에 필요한 다음 소프트웨어가 가상 머신에 설치되었습니다.

• Windows 10(64비트) 버전 1809.
• 어도비 리더 XNUMX.
• Citrix 가상 배달 에이전트 1811.1.
• 도로 PDF 1.82.
• 자바 7 업데이트 13.
• 마이크로소프트 오피스 프로페셔널 플러스 2016.

노드 간 - 동기 복제. 클러스터의 각 데이터 블록에는 두 개의 복사본이 있습니다. 즉, 이제 각 노드에 완전한 데이터 세트가 있습니다. 1개 이상의 노드로 구성된 클러스터에서는 블록 사본이 서로 다른 두 위치에 있습니다. 새 VM을 만들 때 클러스터 노드 중 하나에 추가 복사본이 생성됩니다. 한 노드에 장애가 발생하면 이전에 해당 노드에서 실행 중인 모든 VM이 복제본이 있는 다른 노드에서 자동으로 다시 시작됩니다. 노드에 오랜 시간 장애가 발생하면 점진적인 중복성 복원이 시작되고 클러스터는 N+XNUMX 중복성으로 돌아갑니다.

데이터 밸런싱 및 저장은 SimpliVity 자체의 소프트웨어 저장 수준에서 발생합니다.

가상 머신은 가상화 클러스터를 실행하며 이를 소프트웨어 스토리지에도 배치합니다. 책상 자체는 표준 템플릿에 따라 만들어졌습니다. 재무 담당자와 운영 담당자의 책상이 테스트를 위해 왔습니다(이들은 두 가지 다른 템플릿입니다).

테스트

테스트에는 LoginVSI 4.1 소프트웨어 테스트 스위트가 사용되었습니다. 제어 서버와 테스트 연결용 시스템 12개로 구성된 LoginVSI 컴플렉스는 별도의 물리적 호스트에 배포되었습니다.


테스트는 세 가지 모드로 수행되었습니다.

벤치마크 모드 - 로드 케이스는 지식 근로자 300명, 스토리지 근로자 300명입니다.

표준 모드 - 로드 케이스 300 Power Workers.

Power Worker가 작업하고 로드 다양성을 높일 수 있도록 추가 Power Library 파일 라이브러리가 LoginVSI 컴플렉스에 추가되었습니다. 결과의 반복성을 보장하기 위해 모든 테스트 벤치 설정은 기본값으로 유지되었습니다.

지식 및 전력 작업자 테스트는 가상 워크스테이션에서 작업하는 사용자의 실제 작업 부하를 시뮬레이션합니다.

스토리지 작업자 테스트는 데이터 스토리지 시스템 테스트를 위해 특별히 제작되었으며, 실제 워크로드와는 거리가 멀고 대부분 사용자가 다양한 크기의 수많은 파일을 작업하는 것과 관련됩니다.

테스트하는 동안 사용자는 약 48초마다 한 명의 사용자가 10분 동안 워크스테이션에 로그인합니다.

조사 결과

LoginVSI 테스트의 주요 결과는 사용자가 시작한 다양한 작업의 실행 시간에서 컴파일된 VSImax 메트릭입니다. 예: 메모장에서 파일을 여는 데 걸리는 시간, 7-Zip으로 파일을 압축하는 데 걸리는 시간 등

측정항목 계산에 대한 자세한 설명은 공식 문서에서 확인할 수 있습니다. 링크.

즉, LoginVSI는 사무실 제품군에서의 사용자 작업 시뮬레이션, PDF 읽기 등의 일반적인 로드 패턴을 반복하고 다양한 대기 시간을 측정합니다. "모든 것이 느려지고 작업이 불가능합니다"라는 심각한 수준의 지연이 있으며, 그 전에는 최대 사용자 수에 도달하지 않은 것으로 간주됩니다. 이 "모든 것이 느립니다" 상태보다 응답 시간이 1ms 빠르면 시스템이 정상적으로 작동하는 것으로 간주되어 더 많은 사용자를 추가할 수 있습니다.

주요 지표는 다음과 같습니다.

측정항목

취한 조치

상세 описание

로드된 구성 요소

N.S.L.D.

텍스트 오픈 시간
무게가 1KB인 파일

메모장이 열리고
풀에서 복사된 임의의 1KB 문서를 엽니다.
자원

CPU 및 I/O

NFO

대화 시작 시간
메모장의 창

VSI-Notepad 파일 열기 [Ctrl+O]

CPU, RAM 및 I/O

 

ZHC*

고도로 압축된 Zip 파일을 만드는 시간

로컬 압축
다음에서 복사된 임의의 5MB .pst 파일
자원 풀

CPU 및 I/O

ZLC*

약하게 압축된 Zip 파일을 만드는 시간

로컬 압축
다음에서 복사된 임의의 5MB .pst 파일
자원 풀

I / O

 

CPU

큰 계산
무작위 데이터 배열

대규모 배열 만들기
입출력 타이머(I/O 타이머)에 사용될 임의의 데이터

CPU

테스트가 수행되면 시스템에 로드 없이 작업이 실행되는 속도를 보여주는 기본 VSIbase 메트릭이 처음에 계산됩니다. 이를 기반으로 VSImax 임계값이 결정되며 이는 VSIbase + 1ms와 같습니다.

시스템 성능에 대한 결론은 시스템 속도를 결정하는 VSIbase와 시스템이 심각한 성능 저하 없이 처리할 수 있는 최대 사용자 수를 결정하는 VSImax 임계값이라는 두 가지 지표를 기반으로 이루어집니다.

300명의 지식 근로자 벤치마크

지식 근로자는 다양한 작은 피크로 메모리, 프로세서 및 IO를 정기적으로 로드하는 사용자입니다. 이 소프트웨어는 마치 무언가(PDF, Java, 오피스 스위트, 사진 보기, 7-Zip)를 끊임없이 찌르는 것처럼 까다로운 사무실 사용자의 작업량을 에뮬레이트합니다. 사용자를 300명에서 XNUMX명까지 추가하면 각 사용자에 대한 지연 시간이 점차 늘어납니다.

VSImax 통계 데이터:

VSIbase = 986ms, VSI 임계값에 도달하지 않았습니다.

SimpliVity 모니터링의 스토리지 시스템 로드 통계:


이러한 유형의 로드를 사용하면 시스템은 사실상 성능 저하 없이 증가된 로드를 견딜 수 있습니다. 사용자 작업을 완료하는 데 걸리는 시간이 원활하게 증가하고 시스템 응답 시간은 테스트 중에 변경되지 않으며 쓰기의 경우 최대 3ms, 읽기의 경우 최대 1ms입니다.

결론 : 300명의 지식 사용자는 문제 없이 현재 클러스터에서 작업하고 서로 간섭하지 않으며 pCPU/vCPU 초과 구독 1~6에 도달합니다. 전체 지연은 로드가 증가함에 따라 고르게 증가하지만 규정된 제한에 도달하지 않았습니다.

300명의 스토리지 작업자 벤치마크

이들은 각각 30대 70의 비율로 꾸준히 쓰고 읽는 사용자들이다. 이 테스트는 실험을 위해 더 많이 수행되었습니다. VSImax 통계 데이터:


VSIbase = 1673, VSI 임계값이 240명의 사용자에게 도달했습니다.

SimpliVity 모니터링의 스토리지 시스템 로드 통계:

이러한 유형의 로드는 기본적으로 스토리지 시스템의 스트레스 테스트입니다. 실행되면 각 사용자는 다양한 크기의 무작위 파일을 디스크에 씁니다. 이 경우, 일부 사용자의 경우 특정 로드 임계값을 초과하면 파일 쓰기 작업을 완료하는 데 걸리는 시간이 늘어나는 것을 알 수 있습니다. 동시에 호스트의 스토리지 시스템, 프로세서 및 메모리에 대한 로드는 크게 변경되지 않으므로 현재로서는 지연의 원인을 정확히 파악하는 것이 불가능합니다.

이 테스트를 사용한 시스템 성능에 대한 결론은 다른 시스템의 테스트 결과와 비교해서만 내릴 수 있습니다. 왜냐하면 이러한 로드는 합성적이고 비현실적이기 때문입니다. 그러나 전반적으로 테스트는 잘 진행되었습니다. 210 세션까지 모든 것이 순조롭게 진행된 후 Login VSI를 제외하고는 어디에서도 추적되지 않는 이상한 응답이 시작되었습니다.

전력 노동자 300명

이들은 CPU, 메모리, 높은 IO를 좋아하는 사용자입니다. 이러한 "고급 사용자"는 새 소프트웨어 설치, 대규모 아카이브 압축 풀기 등 장기간 집중적으로 복잡한 작업을 정기적으로 실행합니다. VSImax 통계 데이터:


VSIbase = 970, VSI 임계값에 도달하지 않았습니다.

SimpliVity 모니터링의 스토리지 시스템 로드 통계:


테스트 중에 시스템 노드 중 하나에서 프로세서 로드 임계값에 도달했지만 이는 작동에 큰 영향을 미치지 않았습니다.

이 경우 시스템은 심각한 성능 저하 없이 증가된 부하를 견딜 수 있습니다. 사용자 작업을 완료하는 데 걸리는 시간이 원활하게 증가하고 시스템 응답 시간은 테스트 중에 변경되지 않으며 쓰기의 경우 최대 3ms, 읽기의 경우 최대 1ms입니다.

고객을 위한 정기 테스트로는 충분하지 않았으며 더 나아가 VM 특성(초과 구독 및 디스크 크기 증가를 평가하기 위한 vCPU 수)을 늘리고 추가 로드를 추가했습니다.

추가 테스트를 수행할 때 다음 스탠드 구성이 사용되었습니다.
300개의 가상 데스크톱이 4vCPU, 4GB RAM, 80GB HDD 구성에 배포되었습니다.

테스트 머신 중 하나의 구성:


머신은 전용 - 전체 복사 옵션으로 배포됩니다.

300명 초과 구독이 포함된 지식 근로자 벤치마크 12

VSImax 통계 데이터:


VSIbase = 921ms, VSI 임계값에 도달하지 않았습니다.

SimpliVity 모니터링의 스토리지 시스템 로드 통계:


얻은 결과는 이전 VM 구성을 테스트한 것과 유사합니다.

300개 초과 구독이 있는 전력 작업자 12명

VSImax 통계 데이터:


VSIbase = 933, VSI 임계값에 도달하지 않았습니다.

SimpliVity 모니터링의 스토리지 시스템 로드 통계:


이 테스트 중에 프로세서 로드 임계값에도 도달했지만 이는 성능에 큰 영향을 미치지 않았습니다.

얻은 결과는 이전 구성을 테스트한 것과 유사합니다.

10시간 동안 로드를 실행하면 어떻게 되나요?

이제 '축적 효과'가 있는지 확인하고 10시간 연속 테스트를 실행해 보겠습니다.

섹션에 대한 장기 테스트 및 설명은 트러스에 장기간 하중이 가해질 때 트러스에 문제가 발생하는지 확인하기를 원한다는 사실을 목표로 해야 합니다.

지식 근로자 벤치마크 300명 + 10시간

또한 300명의 지식 근로자를 대상으로 로드 케이스를 테스트한 후 10시간 동안 사용자 작업을 수행했습니다.

VSImax 통계 데이터:


VSIbase = 919ms, VSI 임계값에 도달하지 않았습니다.

VSImax 상세 통계 데이터:


그래프는 전체 테스트에서 성능 저하가 관찰되지 않았음을 보여줍니다.

SimpliVity 모니터링의 스토리지 시스템 로드 통계:


스토리지 시스템 성능은 테스트 내내 동일하게 유지됩니다.

합성 하중을 추가하여 추가 테스트

고객이 디스크에 와일드 로드를 추가해 달라고 요청했습니다. 이를 위해 사용자가 시스템에 로그인할 때 디스크에 종합 로드를 실행하는 작업이 사용자의 각 가상 머신에 있는 스토리지 시스템에 추가되었습니다. 로드는 IOPS 수에 따라 디스크 로드를 제한할 수 있는 fio 유틸리티에 의해 제공되었습니다. 각 머신에서 22 IOPS 70%/30% 무작위 읽기/쓰기 양의 추가 로드를 시작하는 작업이 시작되었습니다.

지식 근로자 벤치마크 300명 + 사용자당 22 IOPS

초기 테스트에서 fio는 가상 머신에 상당한 CPU 오버헤드를 부과하는 것으로 나타났습니다. 이로 인해 호스트의 CPU 과부하가 급속히 발생하고 시스템 전체의 작동에 큰 영향을 미쳤습니다.

호스트 CPU 로드:




동시에 스토리지 시스템 지연도 자연스럽게 증가했습니다.


240명의 사용자를 중심으로 컴퓨팅 성능 부족이 매우 중요해졌습니다.


얻은 결과로 인해 CPU를 덜 사용하는 테스트를 수행하기로 결정되었습니다.

230명의 직장인 벤치마크 + 사용자당 22 IOPS

CPU의 부하를 줄이기 위해 사무직 부하 유형을 선택했으며, 각 세션에 22 IOPS의 합성 부하도 추가했습니다.

최대 CPU 부하를 초과하지 않기 위해 테스트는 230 세션으로 제한되었습니다.

테스트는 최대 부하에 근접한 상태에서 장기간 작동 시 시스템의 안정성을 확인하기 위해 10시간 동안 사용자를 대상으로 실행되었습니다.

VSImax 통계 데이터:


VSIbase = 918ms, VSI 임계값에 도달하지 않았습니다.

VSImax 상세 통계 데이터:


그래프는 전체 테스트에서 성능 저하가 관찰되지 않았음을 보여줍니다.

CPU 로드 통계:




이 테스트를 수행할 때 호스트 CPU의 로드는 거의 최대였습니다.

SimpliVity 모니터링의 스토리지 시스템 로드 통계:


스토리지 시스템 성능은 테스트 내내 동일하게 유지됩니다.

테스트 중 스토리지 시스템의 부하는 6/500 비율(읽기 60 IOPS, 쓰기 40 IOPS)에서 약 3 IOPS였으며, 이는 워크스테이션당 약 900 IOPS입니다.

응답 시간은 쓰기의 경우 평균 3ms, 읽기의 경우 최대 1ms입니다.

합계

HPE SimpliVity 인프라에서 실제 로드를 시뮬레이션할 때 SimpliVity 노드 쌍에서 최소 300개 전체 복제 시스템의 가상 데스크탑을 지원하는 시스템 기능을 확인하는 결과를 얻었습니다. 동시에, 스토리지 시스템의 응답 시간은 전체 테스트에서 최적의 수준으로 유지되었습니다.

우리는 구현하기 전에 오랜 테스트와 솔루션 비교에 대한 접근 방식에 깊은 인상을 받았습니다. 원하는 경우 워크로드에 대한 성능도 테스트할 수 있습니다. 기타 하이퍼컨버지드 솔루션을 포함합니다. 언급된 고객은 현재 다른 솔루션에 대한 테스트를 동시에 완료하고 있습니다. 현재 인프라는 단순히 각 작업장의 PC, 도메인 및 소프트웨어로 구성되어 있습니다. 물론 테스트 없이 VDI로 전환하는 것은 상당히 어렵습니다. 특히 실제 사용자를 VDI 팜으로 마이그레이션하지 않고서는 VDI 팜의 실제 기능을 이해하기 어렵습니다. 그리고 이러한 테스트를 통해 일반 사용자의 개입 없이 특정 시스템의 실제 기능을 신속하게 평가할 수 있습니다. 이 연구가 나온 곳은 바로 여기이다.

두 번째 중요한 접근 방식은 고객이 즉시 적절한 확장을 약속한다는 것입니다. 여기서 추가 서버를 구입하고 팜을 추가할 수 있습니다. 예를 들어 사용자가 100명인 경우 사용자 가격으로 모든 것을 예측할 수 있습니다. 예를 들어, 300명의 사용자를 더 추가해야 하는 경우 전체 인프라 업그레이드를 재고하는 대신 이미 정의된 구성에 두 대의 서버가 필요하다는 사실을 알게 됩니다.

HPE SimpliVity 페더레이션의 가능성은 흥미롭습니다. 사업이 지리적으로 분리되어 있으므로 멀리 떨어진 사무실에 별도의 VDI 하드웨어를 설치하는 것이 합리적입니다. SimpliVity 페더레이션에서 각 가상 머신은 지리적으로 원격 클러스터 간에 매우 빠르게 복제하고 채널에 부하를 주지 않고 복제할 수 있는 기능을 통해 일정에 따라 복제됩니다. 이는 매우 좋은 수준의 내장 백업입니다. 사이트 간에 VM을 복제할 때 채널은 가능한 한 최소한으로 사용되므로 단일 제어 센터와 여러 분산된 스토리지 사이트가 있는 경우 매우 흥미로운 DR 아키텍처를 구축할 수 있습니다.

연맹

이 모든 것을 통해 재정적 측면을 매우 자세하게 평가하고, 회사의 성장 계획에 VDI 비용을 추가하고, 솔루션이 얼마나 빨리 성과를 거두고 어떻게 작동하는지 이해할 수 있습니다. 모든 VDI는 궁극적으로 많은 리소스를 절약하는 솔루션이지만 동시에 사용 후 5~7년 내에 이를 변경할 수 있는 비용 효율적인 기회가 없을 가능성이 높습니다.

일반적으로 의견을 제시할 수 없는 질문이 있는 경우 이메일로 저에게 편지를 보내주세요. [이메일 보호].

출처 : habr.com