VMware Hands-on Lab - HOL-1904-01-SDC


실습 개요 - HOL-1904-01-SDC - vSphere 6.7 성능 진단 및 벤치마킹

실습 지침


참고: 이 실습을 완료하는 데 90분 이상 소요됩니다. 한 번에 전체 실습 모듈을 다 완료하지 못할 수도 있습니다. 각 모듈은 서로 독립적이므로 순서에 관계없이 원하는 모듈부터 실습을 시작할 수 있습니다. 목차를 사용하여 원하는 모듈에 바로 액세스할 수 있습니다.

목차는 실습 설명서 오른쪽 상단에서 볼 수 있습니다.

실습 모듈 목록:

실습 담당자:

  • David Morse - 성능 엔지니어, 미국

이 실습 설명서는 다음 Hands-on Lab 문서 사이트에서 다운로드할 수 있습니다.

http://docs.hol.vmware.com 이 실습은 다른 언어로도 제공될 수 있습니다. 원하는 언어로 설정하고 실습과 함께 배포되는 현지화된 설명서를 보려면 실습 과정을 수행할 때 다음 문서를 참조하십시오.

http://docs.hol.vmware.com/announcements/nee-default-language.pdf


 

주 콘솔 위치

 

  1. 빨간색 상자로 표시된 영역에 주 콘솔이 표시됩니다. 실습 설명서는 주 콘솔의 오른쪽 탭에 있습니다.
  2. 실습에 따라 왼쪽 위의 별도 탭에 추가 콘솔이 제공될 수 있습니다. 필요할 경우 별도의 콘솔을 열라는 지침이 표시됩니다.
  3. 실습이 시작되면 타이머에 90분이 표시됩니다. 이 실습은 저장할 수 없습니다. 실습 세션 동안 모든 작업을 완료해야 합니다. 그러나 EXTEND(연장)를 클릭하여 시간을 늘릴 수는 있습니다. VMware에서 수행되는 실습에 참석한 경우 실습 시간을 두 번에 걸쳐 총 30분 연장할 수 있습니다. 한 번 클릭할 때마다 15분이 추가됩니다. VMware 외부에서 진행되는 행사인 경우 실습 시간을 최대 9시간 30분까지 연장할 수 있습니다. 클릭할 때마다 1시간이 추가됩니다.

 

 

키보드 이외의 데이터 입력 방법

이 모듈에서는 주 콘솔에 텍스트를 입력하게 됩니다. 콘솔에 직접 입력하는 대신, 더 쉽게 복잡한 데이터를 입력할 수 있는 두 가지 다른 방법이 있습니다.

 

 

실습 설명서 컨텐츠를 클릭하여 콘솔 활성 창으로 끌어서 놓기

 
 

실습 설명서에서 바로 텍스트와 명령줄 인터페이스(CLI) 명령을 클릭하여 주 콘솔의 활성 창에 끌어 놓을 수 있습니다.  

 

 

온라인 다국어 키보드 액세스

 

주 콘솔에 있는 온라인 다국어 키보드를 사용할 수도 있습니다.

  1. Windows 빠른 실행 작업 표시줄에 있는 키보드 아이콘을 클릭합니다.

 

 

활성 콘솔 창 클릭

 

이 예에서는 온라인 키보드를 사용하여 e-메일 주소에 사용되는 "@" 기호를 입력합니다. "@" 기호는 미국 키보드 배열에서 Shift+2입니다.

  1. 활성 콘솔 창을 한 번 클릭합니다.
  2. Shift 키를 클릭합니다.

 

 

@ 키 클릭

 

  1. "@" 키를 클릭합니다.

활성 콘솔 창에 @ 기호가 입력됩니다.

 

 

정품 인증 확인 또는 워터마크

 

실습을 처음 시작하면 바탕 화면에 Windows의 정품 인증이 확인되지 않았음을 나타내는 워터마크를 볼 수 있습니다.  

가상화의 주요 이점 중 하나는 가상 머신을 이동하여 모든 플랫폼에서 실행할 수 있다는 점입니다. Hands-on Lab은 이러한 이점을 활용하므로 여러 데이터 센터에서 실습을 실행할 수 있습니다. 하지만, 이러한 데이터 센터는 동일한 프로세서가 아닐 수 있으므로 인터넷을 통한 Microsoft 정품 인증 확인이 필요합니다.

VMware 및 Hands-on Lab은 Microsoft 라이센싱 요구 사항을 완벽하게 준수하고 있습니다. 사용하는 실습 환경은 독립형 포드로, Windows 정품 인증을 위한 인터넷 전체 액세스 권한을 가지고 있지 않습니다. 인터넷에 대한 전체 액세스 권한이 없으면 자동 프로세스가 실패하게 되며 이 워터마크가 나타납니다.

그러나 이러한 외관상의 문제는 실습에 영향을 미치지 않습니다.  

 

 

화면 오른쪽 아랫부분 확인

 

시작 절차가 모두 완료되어 실습을 시작할 준비가 되었는지 확인합니다. "Ready"(준비) 상태가 아니면 몇 분 더 기다려야 합니다. 5분 후에도 "Ready"(준비) 상태로 바뀌지 않으면 도움을 요청하십시오.

 

vSphere 6.7 성능 소개


HOL-SDC-1904-01 실습에서는 vSphere 성능에 대해 다룹니다. 우선 6.7 릴리스에서 특별히 향상된 기능과 새로운 기능에 대해 살펴봅니다. 또한 DVD Store, Weathervane, X-Mem과 같은 광범위한 벤치마크와 esxtop 및 고급 성능 차트와 같은 성능 모니터링 툴을 사용하여 vSphere 환경에서 성능과 진단의 병목 현상을 측정하는 방법에 대해서도 알아봅니다. 뿐만 아니라 가상 머신 적정 규모 산정, 가상 NUMA, 지연 시간 민감도, 호스트 전원 관리와 같은 성능과 관련된 vSphere 기능에 대해서도 살펴봅니다.

이 실습의 짧은 시간으로 인해 예시로 검토할 수 있는 성능 문제의 수가 제한적이므로 vSphere 환경에서 일반적으로 나타나는 관련 문제를 선별했습니다. 이러한 예시를 살펴보면서 일반적인 성능 문제를 보다 잘 파악하고 이해할 수 있어야 합니다.

전체 성능 문제 해결 방법과 VMware 모범 사례 목록은 vmware.com 웹 사이트를 참조하십시오.

https://www.vmware.com/content/dam/digitalmarketing/vmware/en/pdf/techpaper/performance/whats-new-vsphere67-perf.pdf

https://www.vmware.com/content/dam/digitalmarketing/vmware/en/pdf/techpaper/performance/whats-new-vsphere65-perf.pdf

https://www.vmware.com/content/dam/digitalmarketing/vmware/en/pdf/techpaper/drs-vsphere65-perf.pdf

또한 성능 관련 문서에 관심이 있는 경우 VMware VROOM! 블로그를 살펴보십시오.

http://blogs.vmware.com/performance/


모듈 1 - vSphere 6.7 성능: 새로운 기능 (30분)

소개


각 VMware vSphere® 릴리스에는 많은 성능 및 확장성 개선 사항이 기본 제공됩니다. vSphere 6.7 플랫폼은 전체 소프트웨어 정의 데이터 센터의 성공적인 가상화 및 관리를 보장하기 위해 업계 최고의 성능과 기능을 지속적으로 제공합니다.


 

바탕 화면 오른쪽 하단에서 실습 상태 확인

 

시작 절차가 모두 완료되어 실습을 시작할 준비가 되었는지 확인합니다. "Ready"(준비) 상태가 아니면 몇 분 더 기다려야 합니다. 5분 후에도 "Ready"(준비) 상태로 바뀌지 않으면 도움을 요청하십시오.

 

 

Chrome 열기

 

작업 표시줄에서 Chrome 아이콘을 클릭합니다.

 

 

vCenter 로그인

 

자격 증명이 미리 입력되어 있으므로 Login(로그인) 버튼을 클릭합니다.

 

 

호스트 및 클러스터 선택

 

 

더 빠른 수명주기 관리


VMware vSphere 6.7에는 호스트 수명주기 관리 환경을 가속화하여 시스템 관리자의 시간을 절감하는 여러 개선 사항이 포함되어 있습니다.


 

새로운 vSphere Update Manager 인터페이스

 

실습 환경에서 Update Manager를 표시하려면 다음을 수행합니다.

  1. Menu(메뉴) 드롭다운을 클릭합니다.
  2. Update Manager를 선택합니다.

 

 

Update Manager

 

이번 vSphere 릴리스에는 HTML5 Web Client의 일부인 새로운 Update Manager 인터페이스가 포함되어 있습니다.

  1. Updates(업데이트) 탭을 클릭합니다.
  2. Release(릴리스) 열을 클릭하여 가장 최근 릴리스순으로 정렬합니다.
  3. 옵션 버튼을 클릭하여 특정 업데이트에 대한 추가 정보를 확인합니다.

vSphere 6.7의 Update Manager는 시스템 관리자가 최신 패치 및 보안 수정을 손쉽게 배포할 수 있도록 하여 VMware ESXi 6.0~6.7 호스트를 안정적이고 안전하게 유지합니다. 또한 이전 릴리스를 최신 버전의 ESXi 6.7로 업그레이드해야 하는 경우에도 Update Manager를 사용하면 해당 작업을 간편하게 실행할 수 있습니다.

새로운 HTML 5 Update Manager 인터페이스는 이전 Flex 클라이언트의 단순한 포트 이상을 의미합니다. 즉, 새로운 사용자 인터페이스는 훨씬 더 간소화된 문제 해결 프로세스를 제공합니다. 예를 들어 여러 단계로 이루어진 이전 문제 해결 마법사가 몇 번의 클릭만으로 절차를 시작할 수 있는 훨썬 더 효율적인 워크플로우로 교체되었습니다. 이 외에도 사전 검사는 이제 시스템 관리자가 워크플로우를 시작하기 전에 클러스터를 업그레이드할 준비가 되어 있는지 확인할 수 있는 별도의 작업입니다.

이 새로운 인터페이스의 초기 릴리스는 최소한의 실행 가능한 제품으로 VMware ESXi 호스트를 업그레이드하고 패치를 적용하는 데 필요한 워크플로우를 지원합니다. 또한 많은 고객은 vSphere 호스트 패치 적용 및 업그레이드 이외에도 Update Manager를 활용합니다. VMware Tools 업그레이드 및 하드웨어 호환성과 같은 추가 기능은 후속 릴리스에 포함될 예정입니다.

 

 

ESXi 6.5에서 6.7로 더 빠른 업그레이드

현재 ESXi 6.5에서 실행 중인 호스트는 이전보다 훨씬 더 빠른 속도로 6.7로 업그레이드됩니다. 기존에 호스트 업그레이드에 필요했던 2회의 재부팅을 1회로 줄이는 등 업그레이드 경로에 대해 여러 최적화가 이루어졌기 때문입니다. 이전에는 Update Manager를 사용해 업그레이드된 호스트가 업그레이드 프로세스를 시작하기 위해 처음 재부팅된 다음 업그레이드가 완료된 후에 다시 한 번 재부팅되었습니다.

그러나 수백 기가비트 RAM이 장착된 최신 서버 하드웨어는 초기화하고 자가 테스트를 수행하는 데 몇 분이면 충분합니다. 업그레이드 중에 하드웨어 초기화를 두 번 수행하면 실제로 시간이 추가되기 때문에 이 새로운 최적화를 통해 vSphere 인프라 클러스터를 업그레이드하는 데 필요한 유지 보수 기간이 대폭 단축됩니다.

이러한 새로운 개선 사항 덕분에 클러스터 업그레이드에 필요한 전반적인 시간이 줄어들어 유지 보수 기간이 단축되므로 다른 중요한 부분에 더욱 집중할 수 있습니다.

DRS 및 vMotion 덕분에 애플리케이션은 하이퍼바이저 업그레이드 중에도 다운타임이 발생하지 않습니다. 가상 머신은 필요에 따라 호스트 간에 원활하게 이동할 수 있습니다.

 

 

ESXi 6.7 Update Manager 비디오(3:48)

이 실습은 클라우드에서 실행되므로 ESXi 호스트를 6.7로 업그레이드하는 것은 실용적이지 않습니다. 대신 이 비디오에서 프로세스가 어떻게 전개되는지 확인하십시오.

 
 

 

 

vSphere 빠른 부팅

vSphere 6.7은 업데이트 작업 중에 VMware ESXi 호스트를 재부팅하는 데 필요한 시간을 줄이기 위해 고안된 새로운 기능인 vSphere 빠른 부팅을 지원합니다.

호스트 재부팅은 자주 수행되는 것은 아니지만 일반적으로 하이퍼바이저에 패치를 적용하거나 타사 구성 요소 또는 드라이버를 설치하는 등의 작업을 수행한 후에 필요합니다. 대용량 RAM이 장착된 최신 서버 하드웨어는 디바이스 초기화 및 자가 테스트를 수행하는 데 몇 분이면 충분합니다.

빠른 부팅 기능을 사용하면 ESXi를 체계적인 방식으로 종료한 다음 즉시 재시작할 수 있으므로 시간이 많이 걸리는 하드웨어 초기화 단계가 필요 없습니다. 물리적 하드웨어에서 디바이스를 초기화하고 필요한 자가 테스트를 수행하는 데 몇 분 이상 소요되는 경우 빠른 부팅 기능을 사용하면 그만큼의 시간을 절감할 수 있을 것입니다. 일반적으로 한 번에 하나의 호스트의 문제를 해결할 수 있는 대규모 클러스터에서 이 새로운 기술을 사용하면 데이터 센터 유지 보수에 필요한 시간이 대폭 줄어드는 것을 쉽게 확인할 수 있습니다.

 

 

빠른 부팅 비디오(1:53)

이 실습은 클라우드에서 실행되므로 물리적 호스트의 재부팅 과정을 시연할 수 없습니다. 대신 이 비디오에서 재부팅의 작동 방식을 확인하십시오.

 
 

 

 

결론

간소화된 새로운 Update Manager 인터페이스, 단일 재부팅 업그레이드 및 vSphere 빠른 부팅은 호스트 수명주기 관리 작업에 필요한 시간을 단축하여 VMware vSphere 6.7을 하이브리드 클라우드를 위한 효율성이 뛰어나고 안전한 플랫폼으로 만들어줍니다.

 

vCenter Server 6.7


vSphere 6.7은 기능이 향상된 VMware vCenter® Server Appliance™(vCSA)로 탁월한 환경을 제공합니다. vSphere 6.7에는 고객이 필요로 하는 일반적인 워크플로우뿐만 아니라 VMware NSX®, VMware vSAN™, VMware vSphere® Update Manager™(VUM), 타사 구성 요소의 관리와 같은 다른 주요 기능을 지원하는 기능이 추가되었습니다.


 

2배 더 빠른 초당 vCenter 작업 성능

VMware 성능 엔지니어는 자체 벤치마크 vcbench를 사용하여 vCenter에서 수행한 초당 작업 수(처리량)를 측정했습니다.

이 벤치마크는 가상 머신 전원 켜기 및 끄기를 비롯한 일반적인 vCenter 작업을 수행하여 vCenter Server에 부담을 주고 있습니다. vCenter 6.7은 초당 16.7개 작업을 수행합니다. 이는 vCenter 6.5에서 수행한 초당 8.3개 작업보다 두 배 증가한 것입니다.

 

 

3배 더 빠른 작업, 메모리 사용량 3배 감소

vCenter는 가상 머신의 전원을 켜기 전에 먼저 DRS를 비롯한 여러 하위 시스템을 참조하여 vSphere 호스트에서 가상 머신의 초기 배치를 지원합니다. 이 컨텍스트에서 지연 시간은 이 프로세스의 지속 시간을 측정한 수치입니다. VMware는 이러한 하위 시스템을 조정하여 여러 최적화를 거쳐 전원 켜기 지연 시간을 9.5초에서 2.8초로 단축했습니다.

또한 VMware는 핵심 vCenter 프로세스(vpxd)를 최적화하여 동일한 워크로드를 완료하는 데 메모리를 훨씬 적게 사용합니다(3배 감소).

 

핵심 플랫폼 개선 사항


호스트 최대값, 대용량 메모리 페이지, 가상 머신별 EVC, 가상 하드웨어 버전 14, 영구 메모리(PMEM/NVDIMM), VBS(Virtualization Based Security), 인스턴트 클론 측면에서 vSphere 6.7에 도입된 다양한 개선 사항을 살펴보겠습니다.


 

호스트 확장성

vSphere 6.7 ESXi 호스트 최대값에 대해 주목할 만한 몇 가지 개선 사항이 있습니다.

 

 

1GB 대용량 메모리 페이지

 

SAP HANA와 같은 대용량 메모리 설치가 필요한 애플리케이션은 액세스 패턴을 사용하여 하드웨어 메모리 하위 시스템, 즉 TLB(Translation Lookaside Buffer)에 압박을 가할 수 있습니다. 최신 프로세서는 메모리에 대한 대규모 매핑을 생성하고 애플리케이션의 메모리 범위를 늘려 성능에 미치는 영향을 완화할 수 있습니다. 이전 릴리스에서는 ESXi가 2MB 페이지 크기를 기반으로 게스트 운영 체제 메모리 매핑을 허용했습니다. 이번 릴리스에서는 1GB 페이지 크기에 대한 메모리 매핑이 도입되었습니다.

이 그림에서 볼 수 있듯이 TLB 및 프로세서 L1-L3 캐시의 효율적인 사용을 통해 2MB 페이지 크기와 비교하여 1GB 메모리 액세스 성능이 최대 26% 개선됩니다.

이 고급 특성을 사용하도록 설정하려면 https://docs.vmware.com/en/VMware-vSphere/6.7/com.vmware.vsphere.resmgmt.doc/GUID-F0E284A5-A6DD-477E-B80B-8EFDF814EE01.html에서 1GB 페이지를 사용하여 게스트 vRAM 지원을 참조하십시오.

 

 

CPU 스케줄러 개선 사항

vSphere ESXi CPU 스케줄러의 확장성은 현재의 요구 사항과 미래의 요구 사항을 모두 지원하기 위해 매 릴리스마다 개선되고 있습니다. vSphere 6.7의 새로운 기능으로 지난 전역 잠금을 제거하여 스케줄러가 수만 개의 환경(VMkernel에서 실행 중인 다양한 프로세스, 예: 각 가상 CPU에 연결된 환경)을 지원할 수 있습니다. 이 기능을 사용하면 vSphere가 컨테이너 및 마이크로 서비스에 대한 플랫폼으로서의 선도적 위치를 유지할 수 있습니다.

 

 

가상 머신별 EVC

전체 클러스터 수준에서 특정 가상 머신 마이그레이션의 특성을 가정할 수 있으므로(예를 들어 프로세서가 모든 ESXi 호스트 전반에서 동일하지 않은 경우에도 EVC는 계속 작동함) vSphere는 이전에 EVC(Enhanced vMotion Compatibility)를 클러스터 전체에 적용되는 특성으로 구현했습니다. 그러나 이 정책은 vCenter 호스트 또는 vSphere 클러스터 간에 마이그레이션하려고 할 때 문제를 야기할 수 있습니다. 가상 머신별 EVC를 구현하면 EVC 모드가 클러스터에서 부팅되는 특정 프로세서 세대가 아니라 가상 머신의 특성이 됩니다.

 

특정 가상 머신에 대한 EVC를 구성하려면 다음을 수행합니다.

  1. 호스트 및 클러스터 뷰가 표시되는지 확인합니다(아래에 줄이 표시되어야 함).
  2. perf-worker-01a 가상 머신을 선택합니다.
  3. Configure(구성) 탭을 클릭합니다.
  4. 목록에서 VMware EVC를 선택합니다.
  5. "VMware EVC is Disabled"(VMware EVC가 비활성화됨)라는 메시지가 표시됩니다. EDIT...(편집...) 버튼을 클릭하여 선택 사항을 확인합니다.

 

  1. Enable EVC for Intel hosts(Intel 호스트에 대해 EVC 사용) 옵션 버튼을 클릭합니다.
  2. VMware EVC Mode(VMware EVC 모드) 드롭다운을 클릭하고 Intel "Haswell" Generation
    을 선택합니다. 이 모드에 대한 Description(설명)을 읽어 보면 가상 머신이 Haswell 또는 차세대 Intel 프로세서로 제한될 수 있음을 언급하고 있습니다.
  3. Cancel(취소)을 클릭합니다(이 실습은 예시일 뿐이므로 실제로 EVC 적용을 원하지 않음).

 

 

가상 하드웨어 14

가상 하드웨어 14는 다음을 추가로 지원합니다.

 

perf-worker-01a 가상 머신이 가상 하드웨어 버전 14를 실행 중인지 확인합니다.

  1. 호스트 및 클러스터 뷰가 표시되는지 확인합니다(아래에 줄이 표시되어야 함).
  2. perf-worker-01a 가상 머신을 선택합니다.
  3. Summary(요약) 탭을 클릭합니다.
  4. ESXi 6.7 이상과만 호환되는 VM version 14(가상 머신 버전 14)로 구성되어 있음을 확인할 수 있습니다.

이제 기존 가상 머신을 이 버전으로 업그레이드하는 방법에 대해 알아보겠습니다.

 

 

영구 메모리(PMEM)

 

영구 메모리(PMEM)는 DRAM의 속도를 내지만 전원 주기를 통해 컨텐츠를 유지하는 일종의 비휘발성 DRAM(NVDIMM)입니다. NAND 플래시와 DRAM 중간에 위치하는 새로운 계층으로 더 빠른 성능을 제공합니다. 또한 DRAM과 달리 비휘발성입니다.

vSphere 6.7은 영구 메모리에 액세스하는 두 가지 모드를 지원합니다.

vPMEMDisk - NVDIMM 용량을 로컬 호스트 데이터스토어로 제공하므로 이 기술을 활용하기 위해 게스트 운영 체제를 변경할 필요가 없습니다.

vPMEM - 새로운 가상 NVDIMM 디바이스를 통해 NVDIMM 용량을 가상 머신에 제공합니다. 게스트 운영 체제는 이를 블록 디바이스로 사용하거나 DAX 모드에서 사용합니다.

이 차트는 MySQL 벤치마크인 Sysbench를 사용하여 실행한 성능 테스트 결과를 보여줍니다. 벤치마크는 MySQL 워크로드의 처리량과 지연 시간을 측정합니다. 여기에서는 테이블 3개, 스레드 9개, 80:20 읽기-쓰기 비율을 사용하여 테스트를 실행했습니다. 또한 vSphere 6.7에서 호스팅되는 가상 머신에서 MySQL 서버를 실행했습니다.

파란색 막대는 초당 트랜잭션을 측정한 처리량을 나타내고 녹색 선은 95번째 백분위수로 측정한 지연 시간(밀리초)을 나타냅니다.

가상 PMEM이 표준 SSD 기술에 비해 처리량은 최대 1.8배 높이고 지연 시간은 최대 2.3배 낮추는 등 성능을 개선할 수 있는 것으로 관찰됩니다.

 

 

vSphere 6.7 영구 메모리 비디오(2:00)

 
 

이 비디오에서 vSphere 영구 메모리가 어떻게 기존 애플리케이션과 새로운 애플리케이션 성능을 모두 대폭 향상시킬 수 있는지 자세히 알아보십시오.

 

 

VBS(Virtualization Based Security) 개요

 

Windows 10 및 Windows Server 2016 운영 체제의 기능인 Microsoft VBS는 시스템 보안을 개선하기 위해 분리되고 하이퍼바이저에 제한된 전용 하위 시스템을 생성하여 하드웨어 및 소프트웨어 가상화를 사용합니다. vSphere 6.7 및 가상 하드웨어 14부터 Windows 게스트 운영 체제에서 Microsoft VBS(Virtualization Based Security)를 사용하도록 설정할 수 있습니다.

VMware 엔지니어링 팀은 VBS 지원 가상 머신의 성능을 향상시키기 위해 수많은 vSphere 기능 및 개선 사항을 구현했습니다.

VBS가 지원되는 Windows를 실행하는 vSphere 6.7 가상 머신의 성능을 측정하기 위해 VMware는 벤치마킹 애플리케이션인 HammerDB를 사용했습니다. 테스트에서는 22명의 가상 사용자가 Microsoft SQL Server 2016 데이터베이스에 작성하는 OLTP 워크로드를 생성하는 상황을 시뮬레이션했습니다. 이 워크로드는 TPC-C와 같았습니다.

표시된 바와 같이 이러한 엔지니어링 작업으로 초당 트랜잭션이 33% 증가했습니다.

 

 

VBS 지원 가상 머신 생성

 

VBS 지원 가상 머신을 생성합니다.

  1. 호스트 및 클러스터 뷰가 표시되는지 확인합니다.
  2. esx-02a.corp.local을 호스트로 선택합니다.
  3. ACTIONS(작업) 드롭다운을 선택합니다.
  4. New Virtual Machine...(새 가상 머신...)을 선택합니다.

 

Create a new virtual machine(새 가상 머신 생성)이 강조 표시됩니다. NEXT(다음) 버튼을 클릭합니다.

 

가상 머신 이름으로 VBS를 입력하고 NEXT(다음)를 클릭합니다.

 

esx-02a.corp.local이 이미 호스트로 선택되어 있어야 합니다. NEXT(다음)를 클릭합니다.

 

RegionA01-ISCSI02 데이터스토어를 선택하고 NEXT(다음)를 클릭합니다.

 

가상 머신 버전을 선택합니다. 기본적으로 VBS에 필요한 ESXi 6.7 and later(ESXi 6.7 이상)가 선택되어 있으므로 NEXT(다음)를 클릭합니다.

 

  1. Windows가 Guest OS Family(게스트 OS 제품군)로 선택되어 있는지 확인합니다.
  2. Guest OS Version(게스트 OS 버전)을 Microsoft Windows Server 2016 (64-bit)(Microsoft Windows Server 2016(64비트))로 변경합니다.
  3. VBS에 대해 새로운 Enable Windows Virtualization Based Security(Windows VBS(Virtualization Based Security) 사용) 확인란이 표시됩니다. 이 확인란을 선택합니다.
  4. NEXT(다음)를 클릭합니다.

 

  1. VM Options(가상 머신 옵션)를 클릭합니다.
  2. Boot Options(부팅 옵션) 섹션을 확장합니다.
    VBS를 사용하도록 설정하면 EFI 펌웨어Secure Boot(보안 부팅) 같은 필수 옵션이 필요하며 자동으로 설정됩니다.
  3. NEXT(다음)를 클릭합니다.

 

VBS(Virtualization Based Security)가 Enabled(사용)로 설정되어 있으므로 VBS 사전 요건이 자동으로 설정된 VBS 지원 Windows Server 2016 가상 머신을 손쉽게 프로비저닝할 수 있습니다.

게스트 설치를 계속하지 않을 것이므로 CANCEL(취소)을 클릭합니다.

 

 

인스턴트 클론

 

vSphere 6.7 인스턴트 클론을 사용하여 클론 64개를 완전히 배포하고 부팅하는 시간이 이전 링크드 클론 아키텍처에 비해 약 2.8배 단축되었습니다.

인스턴트 클론 기술을 사용하여 전원이 켜진 한 가상 머신이 실행되는 상태에서 전원이 켜진 다른 가상 머신을 생성할 수 있습니다. 인스턴트 클론 작업을 수행하면 소스 가상 머신과 동일한 새로운 가상 머신이 생성됩니다. 인스턴트 클론을 통해 제어된 시점에서 새로운 가상 머신을 생성할 수 있습니다. 인스턴트 클론은 메모리 효율성을 보장하고 단일 호스트에서 수많은 가상 머신을 생성할 수 있으므로 대규모 애플리케이션 배포에 매우 편리한 기술입니다.

 
 

이 인스턴트 클론 비디오 데모는 2분 내에 20개의 CentOS 가상 머신을 프로비저닝하는 방법을 보여줍니다(출처: LearnVMware.online). 결과를 빨리 확인하고자 하는 경우 3분 11초를 시청하면 됩니다.

 

결론


vSphere 6.7의 이러한 성능, 확장성 및 기능 개선 사항을 기반으로 VMware는 업계 최고의 성능을 지속적으로 입증하고 있습니다.


 

모듈 1 완료

모듈 1을 완료했습니다.

다음과 같은 링크를 통해 vSphere 6.7 성능에 대한 추가 정보를 알아보십시오.

 

모듈 2 - 최적의 성능을 위해 vSphere 가상 머신 적정 규모 산정(45분)

소개


 

몬스터 가상 머신인 Melvin을 소개합니다. vSphere 6.5는 Melvin을 비롯한 기타 모든 대규모 비즈니스 크리티컬 워크로드("와이드" 또는 "몬스터" 가상 머신이라고도 함)를 손쉽게 처리할 수 있습니다.

이 모듈에서는 실제로 가상 머신의 적정 규모를 산정하는 방법에 대해 자세히 다룹니다. 특히 가상 머신이 여러 물리적 프로세서 또는 메모리 노드 경계에 걸쳐 있을 정도로 대규모인 경우에 대해 살펴봅니다. vCPU, pCPU, 소켓당 코어 수, NUMA(pNUMA 및 vNUMA) 등의 용어에 대해 살펴본 후에 최적의 성능을 위해 가상 머신의 적정 규모를 산정하는 방법에 대해 알아보겠습니다.


NUMA 및 vNUMA


UMA, NUMA, vNUMA와 같은 약어의 의미를 파악하고 아키텍처 관점에서 어떤 모습일지 살펴보겠습니다.


 

UMA

 

UMA(Uniform Memory Access)는 더 이상 최신 서버의 설계 수단이 아니므로 이미 사용할 수 없는 기능입니다. 그렇다면 이유가 무엇일까요?
메모리를 요청하는 모든 CPU 또는 I/O가 이 계층을 통과해야 했기 때문에 메모리 컨트롤러(강조 표시됨)에 빠른 병목 현상이 발생했습니다 (출처: frankdenneman.nl).

 

 

NUMA

NUMA는 중앙 집중식 메모리 풀에서 벗어나 토폴로지 개념을 도입합니다. 프로세서에서 메모리까지의 신호 경로 길이에 따라 메모리 위치를 분류하면 지연 시간과 대역폭 병목 현상을 방지할 수 있습니다. 이렇게 하려면 전체 프로세서 및 칩셋 시스템을 재설계해야 합니다. NUMA 아키텍처는 90년대 말에 Cray Origin 2000과 같은 SGI 수퍼컴퓨터에서 사용되면서 대중화되었습니다. NUMA는 메모리의 위치를 파악하는 데 도움이 되었습니다. 이러한 시스템에서는 어떤 섀시의 어떤 메모리 영역에 메모리 비트를 보유하고 있는지 파악해야 했습니다.

2000년대 초반에 AMD는 UMA 시스템이 가장 각광을 받았던 기업 환경에 NUMA를 도입했습니다. 2003년에는 각 CPU에 메모리 뱅크가 지정되고 메모리 컨트롤러가 통합된 AMD Opteron 제품군이 출시되었습니다. 현재는 각 CPU마다 메모리 주소 공간을 보유합니다. ESXi와 같이 NUMA에 최적화된 운영 체제를 사용하면 워크로드에서 두 메모리 주소 공간의 메모리를 모두 사용하는 동시에 로컬 메모리 액세스를 최적화할 수 있습니다. 단일 시스템 내에서 로컬 메모리 액세스와 원격 메모리 액세스의 차이를 명확하게 구분하기 위해 CPU가 2개인 시스템을 예로 들어 보겠습니다.

(출처: frankdenneman.nl

 

CPU1의 메모리 컨트롤러에 연결된 메모리는 로컬 메모리로 간주되고, 다른 CPU 소켓(CPU2)에 연결된 메모리는 CPU1에 대한 외부 또는 원격 메모리로 간주됩니다. 원격 메모리 액세스는 상호 연결(지점 간 링크)을 통과하고 원격 메모리 컨트롤러에 연결해야 하므로 로컬 메모리 액세스와 달리 지연 시간 오버헤드가 추가적으로 발생합니다. 메모리 위치가 다르므로 이 시스템은 "통일되지 않은" 메모리 액세스 시간을 경험하게 됩니다.

 

 

vNUMA 미사용

 

이 예에서는 vCPU가 12개인 가상 머신이 각각 코어가 6개인 4개의 NUMA 노드가 있는 호스트에서 실행되고 있습니다. 이 가상 머신은 물리적 NUMA 구성으로 제공되지 않으므로 게스트 OS 및 애플리케이션에 단일 NUMA 노드만 표시됩니다. 즉, 게스트는 프로세스와 메모리를 물리적 NUMA 노드 내에 배치할 수 없습니다.

메모리 지역성이 낮습니다.

 

 

vNUMA 사용

vSphere 5부터 ESXi에는 여러 개의 NUMA 노드를 게스트 운영 체제에 제공할 수 있는 vNUMA(가상 NUMA) 기능이 지원되었습니다. 기존에는 가상 머신의 크기나 기본 하드에어에 관계없이 가상 머신에 단일 NUMA 노드만 제공되었습니다. 또한 점점 더 많은 워크로드가 가상화되면서 게스트 OS 및 애플리케이션에서 애플리케이션 실행 위치와 메모리 배치 위치를 결정할 수 있는 기능이 더욱 중요해졌습니다.

VMware ESXi는 NUMA를 인식하며 가능하면 단일 물리적 NUMA 노드 내에 가상 머신을 배치하려고 합니다. 하지만 대규모의 "몬스터 가상 머신"의 경우에는 불가능할 수 있습니다.

이 모듈의 목적은 vNUMA가 그 자체로 어떻게 작동하는지와 소켓당 코어 수 기능과 함께 사용할 때 어떻게 작동하는지를 파악하는 것입니다.

 

이 예에서는 vCPU가 12개인 가상 머신이 각각 코어가 6개인 4개의 NUMA 노드가 있는 호스트에서 실행되고 있습니다. 이 가상 머신은 물리적 NUMA 구성으로 제공되므로 게스트 OS 및 애플리케이션에 NUMA 노드 2개가 표시됩니다. 즉, 게스트는 가능한 경우 프로세스와 그에 수반되는 메모리를 물리적 NUMA 노드 내에 배치할 수 있습니다.

메모리 지역성이 좋습니다.

 

vCPU 및 vNUMA 적정 규모 산정


가상화를 사용하면 다양한 워크로드에 맞게 다양한 가상 CPU(vCPU) 구성을 사용하여 신속하게 가상 머신을 생성할 수 있는 유연성을 확보할 수 있습니다.

하지만 최대 28개의 코어를 사용하는 최신 세대 프로세서에 데이터베이스와 같이 점점 더 까다로워지는 대규모 워크로드를 가상화할 때는 성능을 최적화하기 위해 vCPU vNUMA 구성에 신중을 기해야 합니다.


 

vCPU, 소켓당 코어 수, vSocket, CPU 핫 플러그/Hot Add

 

vSphere Web Client에서 직접 캡처한 이 스크린샷에 가장 중요한 값이 표시되고 있습니다.
참고: 이 필드의 일부를 보거나 변경하려면 CPU 드롭다운을 확장해야 합니다.

  1. CPU: 게스트 OS에 제공된 총 vCPU 수입니다(이 예의 경우 20개).
  2. Cores per Socket(소켓당 코어 수): 이 값이 1(기본값)인 경우 모든 CPU가 게스트에 단일 코어 프로세서로 제공됩니다.
    대부분의 가상 머신은 기본값으로 충분하지만 이 값을 늘려야 하는 경우가 있습니다. 이에 대해서는 잠시 후 살펴보겠습니다.
    이 예에서는 이 값을 10으로 늘렸습니다. 이 경우 게스트에 멀티 코어(10코어) 프로세서가 표시됩니다.
  3. Sockets(소켓): 구성 가능한 값이 아니라 단순하게 Cores per Socket(소켓당 코어 수)로 나눈 CPU 수입니다. 이 예에서는 20 / 10 = 2입니다.
    "가상 소켓" 또는 "vSocket"이라고도 합니다.
  4. CPU Hot Plug(CPU 핫 플러그): CPU Hot Add라고도 하며, 이 확인란을 선택하면 "실시간"으로 CPU를 추가할 수 있습니다(게스트 전원이 켜진 경우).
    처음부터 가상 머신의 적정 규모를 산정한 경우, 이 기능을 사용하도록 설정하지 않아야 합니다. vNUMA가 비활성화
    되는 주요 단점이 있습니다. 자세한 내용은 VCPU 핫 플러그가 사용하도록 설정된 경우 vNUMA 비활성화됨(KB 2040375)을 참조하십시오.

구성된 대로 소켓 2개 x 소켓당 코어 수 10개인 이 가상 머신을 20 vCPU 가상 머신이라고 하겠습니다.

 

 

소켓당 코어 수: 라이센싱 고려 사항

 

소켓당 코어 수 값에 대해 살펴보겠습니다. 앞에서 언급한 대로 기본값 1은 모든 가상 CPU가 게스트 가상 머신에 Socket(소켓)으로 제공된다는 것을 의미합니다. 대부분의 경우 문제가 없습니다.

그러나 운영 체제 및 애플리케이션이 프로세서 단위로 이루어지는 Microsoft 라이센싱의 관점에서는 적합하지 않을 수 있습니다. 다음은 몇 가지 예입니다.

 

 

vSphere 6.5 이상에서의 vNUMA 동작 변경 사항

최적의 성능을 낼 수 있도록 구성을 자동화하고 간소화하기 위해 vSphere 6.5에서는 vNUMA 동작에 몇 가지 변경 사항을 도입했습니다. 이 내용에 대해 자세히 기술하고 있는 Frank Denneman의 글을 참조하십시오.

http://frankdenneman.nl/2016/12/12/decoupling-cores-per-socket-virtual-numa-topology-vsphere-6-5/

기본적으로 vSphere 6.5/6.7에서 vNUMA 제공은 더 이상 소켓당 코어 수의 영향을 받지 않습니다. 이제 vSphere는 항상 최적의 vNUMA 토폴로지만 제공합니다(고급 설정을 사용하지 않는 경우).

하지만 CPU 값과 Cores per Socket(소켓당 코어 수) 값은 여전히 신중하게 선택해야 합니다. 몇 가지 모범 사례를 참조하십시오.

 

 

소켓당 코어 수 및 vNUMA에 대한 모범 사례

일반적으로 vNUMA 및 소켓당 코어 수와 관련하여 다음 모범 사례를 따라야 합니다.

고급 가상 NUMA 특성은 여러 개가 있지만(전체 목록을 보려면 클릭) 여기에서는 몇 가지 지침만 설명합니다. 하지만 일반적으로 기본값이 가장 바람직합니다.

 

물론 그림(이 경우 표)이 천 마디의 단어보다 이해하는 데 더 효과적입니다. 이 표에는 듀얼 소켓, 10코어 물리적 호스트에서 가상 머신을 어떻게 구성하면 vSphere 버전에 관계없이 최적의 vNUMA 토폴로지 및 성능을 보장할 수 있는지 간략하게 나와 있습니다.

 

vCPU/vNUMA를 확인할 수 있는 게스트 OS 툴


vSphere Client를 사용하여 가상 머신의 vCPU 및 소켓당 코어 수의 적정 규모를 산정하는 방법을 살펴봤습니다.

게스트 OS 관점에서 볼 때 이러한 토폴로지는 어떻게 구성되어 있을까요? 게스트에 예상되는 프로세서 및 NUMA 구성이 표시되는지 확인할 수 있는 Windows 및 Linux용 툴에 대한 몇 가지 예를 살펴보겠습니다.


 

vSphere Client CPU/소켓당 코어 수 예시

 

앞에서도 설명했지만 화면에 나타나는 값을 다시 살펴보겠습니다.

  1. CPU: 게스트 OS에 제공된 총 vCPU 수입니다(이 예의 경우 20개).
  2. Cores per Socket(소켓당 코어 수): 이 값이 1(기본값)인 경우 모든 CPU가 게스트에 단일 코어 프로세서로 제공됩니다.
    대부분의 가상 머신은 기본값으로 충분하지만 이 값을 늘려야 하는 경우가 있습니다. 이에 대해서는 잠시 후 살펴보겠습니다.
    이 예에서는 이 값을 10으로 늘렸습니다. 이 경우 게스트에 멀티 코어(10코어) 프로세서가 표시됩니다.
  3. Sockets(소켓): 구성 가능한 값이 아니라 단순하게 Cores per Socket(소켓당 코어 수)로 나눈 CPU 수입니다. 이 예에서는 20 / 10 = 2입니다.
    "가상 소켓" 또는 "vSocket"이라고도 합니다.
  4. CPU Hot Plug(CPU 핫 플러그): CPU Hot Add라고도 하며, 이 확인란을 선택하면 "실시간"으로 CPU를 추가할 수 있습니다(게스트 전원이 켜진 경우).
    처음부터 가상 머신의 적정 규모를 산정한 경우, 이 기능을 사용하도록 설정하지 않아야 합니다. vNUMA가 비활성화되는 주요 단점이 있습니다.

구성된 대로 소켓 2개 x 소켓당 코어 수 10개인 이 가상 머신을 20 vCPU 가상 머신이라고 하겠습니다.

 

 

Windows: Coreinfo

Microsoft Sysinternals 웹 사이트에 따르면 Coreinfo는 논리적 프로세서와 물리적 프로세서, NUMA 노드, 논리적 프로세서가 상주하는 소켓뿐만 아니라 각 논리적 프로세서에 할당된 캐시와의 매핑을 보여주는 명령줄 유틸리티입니다. Windows의 GetLogicalProcessorInformation 함수를 사용해 이 정보를 얻고 화면에 출력하여 별표(‘*’)로 논리적 프로세스에 대한 매핑을 표시합니다.

Coreinfo는 시스템의 프로세서와 캐시 토폴로지에 대한 통찰력을 얻는 데 유용합니다.

매개 변수 설명
-c
코어에 대한 덤프 정보입니다.
-f
코어 기능에 대한 덤프 정보입니다.
-g
그룹에 대한 덤프 정보입니다.
-l
캐시에 대한 덤프 정보입니다.
-n
NUMA 노드에 대한 덤프 정보입니다.
-s
소켓에 대한 덤프 정보입니다.
-m
덤프 NUMA 액세스 비용입니다.
-v
덤프 전용 가상화 관련 기능입니다.

 

여기에 앞서 언급한 20 vCPU 가상 머신에 대한 coreinfo의 출력이 표시됩니다(명령줄 옵션 없음). 이 출력을 분석하면 다음과 같습니다.

  1. Logical to Physical Processor Map(논리적 프로세서-물리적 프로세서 맵): 이 섹션에서는 Windows에서 vCPU 20개를 식별하는지 확인할 수 있습니다(1:1 매핑으로 논리적 프로세서물리적 프로세서로 제공).
  2. Logical Processor to Socket Map(논리적 프로세서-소켓 맵): 이 섹션에서는 Windows에서 각 소켓에 논리적 프로세서가 8개 있는 소켓 2개를 식별하는지 확인할 수 있습니다. vSocket이라고도 합니다.
  3. Logical Processor to NUMA Node Map(논리적 프로세서-NUMA 노드 맵): 이 섹션에서는 Windows에서 각 노드에 논리적 프로세서가 8개 있는 NUMA 노드 2개를 식별하는지 확인할 수 있습니다. 이는 가상 머신이므로 이 노드를 vNUMA 노드라고 합니다.

 

 

Linux: numactl

Linux의 경우 가상 NUMA에 대한 정보를 얻는 가장 유용한 매개 변수는 numactl입니다. OS에 대한 numactl 툴을 제공하는 패키지를 설치해야 할 수도 있습니다.(RHEL/CentOS 7에 적합한 명령은 yum install numactl입니다.)

매개 변수 설명
-c
코어에 대한 덤프 정보입니다.
-f
코어 기능에 대한 덤프 정보입니다.
-g
그룹에 대한 덤프 정보입니다.
-l
캐시에 대한 덤프 정보입니다.
-n
NUMA 노드에 대한 덤프 정보입니다.
-s
소켓에 대한 덤프 정보입니다.
-m
덤프 NUMA 액세스 비용입니다.
-v
덤프 전용 가상화 관련 기능입니다.

 

여기에 numactl -H의 출력이 나와 있습니다.(-H는 하드웨어의 약자입니다. 이용 가능한 모든 매개 변수를 보려면 man numactl 명령을 사용합니다.) 이 출력을 간단히 설명하면 다음과 같습니다.

  1. numactl -H: 출력을 얻기 위해 입력한 명령입니다.
  2. available: 2 nodes (0-1)(이용 가능: 노드 2개(0-1)): 이 섹션에서는 Linux에서 NUMA 노드 2개(vNUMA 노드라고도 함)를 식별하는지 확인할 수 있습니다.
  3. node 0 cpus, node 1 cpus(노드 0 CPU, 노드 1 CPU): 이 섹션에서는 Linux에서 각 NUMA 노드에 논리적 프로세서 10개(vCPU 총 20개)를 식별하는지 확인할 수 있습니다.

 

결론


축하합니다! 이제 vSphere 6.7에 대한 최적의 가상 머신 적정 규모를 산정하는 방법을 알게 되었습니다.


 

참고 자료/유용한 링크

다음과 같은 링크를 통해 가상 머신, NUMA/vNUMA 및 vSphere 성능의 일반적인 적정 규모 산정에 대한 자세한 내용을 알아보십시오.

 

모듈 3 - DVD Store를 사용한 데이터베이스 성능 테스트(30분)

소개


 

이 모듈에서는 DS3라고도 하는 DVD Store 3에 대해 소개합니다. DVD Store 3은 고객이 로그인하여 DVD를 검색하고, 고객 리뷰를 읽고, 리뷰의 등급을 매기고, DVD를 구매할 수 있는 온라인 매장을 시뮬레이션합니다.

이 모듈의 내용에 대한 간단한 개요는 다음과 같습니다.


DVD Store 3 소개


이 레슨에서는 모든 다양한 기능을 포함하여 DVD Store가 무엇인지에 대해 설명합니다.


 

DVD Store 3 설명

 

다음은 DVD Store 3(DS3) 벤치마크에 대한 개요입니다.

 

 

DVD Store 3 데이터베이스 크기

DVD Store 3의 지원 대상은 세 가지 표준 크기인 소형, 중형대형입니다. DVD Store 설정 중에 이러한 표준 크기 외에 맞춤형 크기를 지정할 수 있습니다. DVD Store 3 데이터베이스를 구성하는 여러 테이블의 행 수는 지정된 크기에 따라 달라집니다.

아래 표는 표준 크기의 고객, 주문 및 제품 테이블의 행 수를 예로 보여줍니다.

데이터베이스
크기
고객
주문
제품
소형
10MB
20,000명
1,000/월
10,000개
중형
1GB
2,000,000명
100,000/월
100,000개
대형
100GB
200,000,000명
10,000,000/월
1,000,000개

 

DVD Store 3 다운로드/설치


이 레슨에서는 DVD Store 3 벤치마크를 설치하는 방법에 대해 설명합니다. 특히 LAMP 스택(Linux, Apache, MySQL, PHP 스택)을 사용하여 이 실습 환경에 맞게 설정하는 방법을 살펴봅니다.

참고 1: LAMP 스택은 DVD Store 3에 지원되는 환경 중 하나일 뿐입니다. 벤치마크는 Microsoft SQL Server, Oracle, MySQL, PostgreSQL 등 다양한 데이터베이스를 지원합니다.

참고 2: 이 가상 머신 및 데이터베이스는 이미 생성되었으므로, 자체 환경에서 테스트를 위해 설정하려는 경우 참조할 수 있습니다.
데이터베이스를 생성하려면 시간 및 스토리지 측면에서 리소스가 많이 소비되므로 Hands-on Lab 환경에서 다루기 어렵습니다.


 

Linux 가상 머신 생성

 

이 스크린샷은 실습 환경에서 DVD Store 3이 vCPU 1개, 1GB 메모리, 10GB 하드 디스크로 구성된 CentOS Linux 가상 머신에 설치되어 있음을 보여줍니다.

최소 시스템 요구 사항이 Weathervane 모듈보다 낮다는 것을 알 수 있습니다. 여기에는 다음 두 가지 이유가 있습니다.

  1. 이 가상 머신에서는 몇 개의 애플리케이션(즉, 데이터베이스 Tier의 경우 MySQL, 웹 서버 Tier의 경우 Apache HTTP Server)만 실행하고 있습니다.
  2. 이 가상 머신은 소형 데이터베이스 크기로 구축되었습니다. 이전 레슨에서 DVD Store 3이 소형(10MB), 중형(1GB), 대형(100GB)의 세 가지 크기로 제공된다는 것을 알았습니다.
    중형 또는 대형 데이터베이스를 구축하려면 CPU, 메모리 및 디스크 크기를 그에 맞게 수직 확장해야 합니다.

 

 

OS 설치/설치 후 작업

DVD Store는 모든 최신 Linux 배포에서 작동해야 합니다. 이 가상 머신은 CentOS 6.8과 함께 설치되었습니다.

OS 설치 후 일부 작업을 루트 사용자로 실행한 다음에 DS3을 설치해야 합니다.
참고: 이 작업은 이미 실습 환경에서 수행되었으므로 지금 이러한 명령을 실행하지 마십시오.

  1. yum update 명령을 실행하여 모든 소프트웨어 패키지 업데이트
  2. VMware Tools 설치(또는 open-vm-tools)
  3. service iptables stop을 실행하여 방화벽을 중지하고 chkconfig iptables off를 실행하여 부팅 시 비활성화
    (참고: 테스트/개발 환경에서 손쉽게 사용하기 위한 것이므로 운영 환경에서는 사용하지 마십시오.)
  4. yum install mysql-server를 실행하여 MySQL을 설치하고 service mysqld start를 실행하여 시작
  5. yum install httpd httpd-devel을 실행하여 Apache HTTPD Server 설치
  6. yum install php php-mysql을 실행하여 MySQL 지원으로 PHP 설치
  7. 지정 사용자 웹 생성 및 웹 암호 설정:
    useradd web passwd web chmod 755 /home/web
  8. MySQL 내에서 이 새로운 사용자에 대한 사용 권한 설정:
    mysql >create user 'web'@'localhost' identified by 'web'; >grant ALL PRIVILEGES on *.* to 'web'@'localhost' IDENTIFIED BY 'web'; >exit;

 

 

DS3 다운로드 및 추출

 

DVD Store 3은 적극적으로 개발 및 유지되는 오픈 소스 프로젝트입니다. 최신 버전은 여기 나와 있는 것처럼 GitHub(https://github.com/dvdstore/ds3/)에서 다운로드할 수 있습니다.

DS3을 추출하려면 CentOS 호스트에 루트 사용자로 로그인하고 unzip ds3-master.zip 명령을 사용하여 압축을 풉니다.

참고: 이 작업은 이미 Hands-on Lab 환경에서 수행되었으므로 실습 가상 머신에서 이 명령을 실행하지 마십시오.

마지막으로 PHP 웹 페이지를 호스트의 올바른 위치에 복사해야 합니다. 마찬가지로 이 작업은 이미 실습에서 수행되었으므로 실행하지 않아도 됩니다.

mkdir /var/www/html/ds3
cp /root/home/ds3/mysqlds3/web/php5/* /var/www/html/ds3
service httpd restart

 

DVD Store 3 데이터베이스 구축/실습 시작


이 레슨에서는 DVD Store 3 데이터베이스를 직접 구축하는 방법에 대해 설명합니다.

구성 스크립트를 실행하여 필요한 SQL 명령을 생성할 것이며 시간 및 리소스 제약으로 인해 실제 빌드는 실행하지 않습니다.
실습 환경에는 바로 실행할 수 있도록 데이터베이스가 사전 구축되어 있습니다.


 

성능 실습 모듈 변환기 실행

 

주 콘솔의 바탕 화면에 있는 Performance Lab MS(성능 실습 모듈 변환기) 바로 가기를 두 번 클릭합니다.

 

 

모듈 3 시작

 

Module 3(모듈 3) 아래 Start(시작) 버튼을 클릭하면(강조 표시됨) PowerShell 스크립트가 실행되어 DVD Store 3 가상 머신이 시작되고 PuTTY 세션이 열립니다.

 

모듈 3이 시작되면 화면에 표시된 것처럼 PuTTY 창과 모듈 3이 시작되었음을 나타내는 팝업 상자가 표시됩니다. OK(확인)를 클릭합니다.

이제 DS3 데이터베이스를 구축하는 방법을 알아볼 준비가 되었습니다.

 

 

Install_DVDStore.pl 스크립트 실행

 

앞에서 DS3이 세 가지 데이터베이스 크기(소형, 중형, 대형)로 제공된다는 사실을 확인했습니다. 물론 구축할 맞춤형 데이터베이스 크기를 지정할 수도 있습니다. 방법은 다음과 같습니다.
(각 명령/값을 입력한 후 Enter 키를 누릅니다.)

  1. DS3 디렉토리로 변경합니다. 이 가상 머신에서는 /root/ds3에 설치되었고 이미 /root 폴더에 있으므로 다음을 입력합니다.
    cd ds3
  2. Install_DVDStore Perl 스크립트를 실행합니다.
    perl Install_DVDStore.pl
  3. 이제 원하는 DS3 데이터베이스의 크기를 선택해야 합니다. 100MB MySQL 데이터베이스를 구축해 보겠습니다.
    100
  4. 데이터베이스 크기를 MB 또는 GB 중에 선택해야 하며, MB를 지정합니다.
    MB
  5. DS3은 여러 데이터베이스를 지원하므로 MYSQL을 지정해야 합니다.
    MYSQL
  6. 마지막으로 DS3에서 데이터베이스 서버를 Windows 시스템에서 실행할지 또는 Linux 시스템에서 실행할지 결정해야 합니다. 그러면 입력 파일이 CR/LF(DOS 형식)를 보유할지 여부가 결정됩니다. LINUX를 선택합니다.
    LINUX

이제 Install_DVDStore.pl 스크립트로 다음이 수행됩니다.

Perl 스크립트가 완료될 때까지 기다리십시오.

 

완료되면 스크립트가 위와 같이 나타납니다. 강조 표시된 Completed creating and writing build scripts for MySQL database...(MySQL 데이터베이스에 대한 빌드 스크립트 생성 및 작성이 완료되었습니다.) 메시지를 확인합니다.

이제 모든 MySQL 스크립트가 생성되었으므로 데이터베이스는 일반적으로 이 시점에 구축됩니다. 데이터베이스를 직접 생성하지 않고 스크립트를 생성하는 이유는 개별 환경의 특정 테스트 요구 사항을 충족하기 위해 나중에 데이터베이스를 간편하게 재생성하거나 필요에 따라 수정할 수 있도록 하기 위해서입니다.

데이터베이스 구축은 다음 명령을 사용하여 완료합니다. 참고: 실습 환경에서는 다음 명령을 실행하지 마십시오. 데이터베이스 구축에는 시간이 오래 걸리고 이미 데이터베이스가 구축되어 바로 실행할 수 있기 때문입니다.

# 참고: 실습 환경에서는 다음 명령을 실행하지 마십시오.
cd mysqlds3
sh mysqlds3_create_all.sh

지금까지 DS3 데이터베이스를 구축하는 방법을 살펴봤으므로 실제로 실행해 보겠습니다.

 

DVD Store 3 구성/실행


이 레슨에서는 DVD Store 3 로드 드라이버를 구성하고 실습 환경에 배포된 MySQL 데이터베이스 가상 머신에 대해 이를 실행하는 방법에 대해 설명합니다.


 

DVD Store 가상 머신에서 top 시작

 

DVD Store 가상 머신의 성능을 확인하려면 top 명령을 입력하고 Enter 키를 누릅니다. 그러면 CPU 및 메모리 사용량과 가상 머신을 가장 많이 사용하는 프로세스가 표시됩니다.

이제 Windows 시스템에서 DS3 드라이버를 시작해 보겠습니다.

 

 

주 콘솔에서 DVD Store 드라이버 시작

 

주 콘솔(Windows 바탕 화면)에서 DVD Store 3 Driver(DVD Store 3 드라이버) 아이콘을 두 번 클릭합니다(참고: 아이콘을 표시하기 위해 일부 창을 최소화해야 할 수도 있음).

 

 

실행 중에 드라이버 및 PuTTY 창 모니터링

 

실행이 처리 중일 때 top을 실행하는 PuTTY 콘솔(상단에 표시됨)과 DS3 드라이버 창(하단에 표시됨)을 모두 살펴봐야 합니다.

이 스크린샷에서 몇 가지 사항을 살펴보겠습니다(참고: 클라우드의 변동성으로 인해 성능이 다를 수 있음).

  1. 상단의 CPU 사용률을 나타내는 줄에 34.2%가 사용자 공간(애플리케이션)에서 사용되고 9.3%가 시스템(커널)에서 사용되어 총 43.5% CPU가 사용되는 것을 알 수 있습니다. 그러나 유휴 시간은 0입니다. 나머지 CPU(55.5%)는 I/O 대기 중으로, 이는 환경에 디스크 또는 네트워크 병목 현상이 발생하고 있을 가능성이 있음을 의미합니다.
  2. 아까 언급한 CPU 사용률의 43.5%를 사용하는 프로세스는 mysqld(MySQL 데이터베이스)입니다. 데이터베이스 벤치마크가 이에 영향을 주므로 일리가 있습니다.
    드라이버의 출력을 살펴보겠습니다.
  3. 이는 정상적인 DS3 드라이버 시작 메시지로 실제 실행이 시작되기 전에 다양한 스레드가 데이터베이스 서버에 연결된다는 것을 나타냅니다.
  4. 약 10초마다 성능 요약 출력이 화면에 표시됩니다(경과 시간을 나타내는 et가 각 줄마다 10씩 증가함).
  5. 각 줄에 여러 통계가 나타나지만(대부분이 응답 시간을 나타내는 rt를 표시하고 있음) 주요 DVD Store 처리량 성능 측정지표(분당 주문 건수를 나타내는 opm)를 가장 중점적으로 살펴 보아야 합니다. 여기에서 평균적으로 대략 40 opm을 달성하는 것을 알 수 있습니다. 이는 매우 낮은 수치입니다. 최적화된 테스트 베드에서 훨씬 더 높은 opm 수치를 얻을 수 있습니다.

축하합니다! 이제 DVD Store가 실행되고 있습니다.

참고로 Windows 시스템에서 드라이버를 시작하기 위해 사용한 명령은 다음과 같습니다.

c:\hol\ds3mysqldriver --target=dvdstore-01a.corp.local --n_threads=5 --warmup_time=0 --detailed_view=Y

이러한 각 드라이버 매개 변수의 의미를 살펴보겠습니다.

 

 

드라이버 매개 변수 표시

 

명령 프롬프트 아이콘을 클릭하여 명령 프롬프트 창을 엽니다.

 

다음 명령을 입력하고 Enter 키를 누릅니다.
ds3mysqldriver

Parameter Name(매개 변수 이름), Description(설명) 및 Default Value(기본값)가 나와 있는 목록이 표시됩니다. 각 매개 변수를 수동으로 설정하는 대신 구성 파일을 생성하여 명령줄에 전달할 수도 있습니다.

 

결과 분석/DVD Store 3 성능 향상


이 레슨에서는 DVD Store 3 결과를 분석(특히 성능이 저조한 실행과 성능이 우수한 실행 비교)한 다음 성능을 향상시킬 수 있는 방법에 대해 설명합니다.


 

DVD Store 3 성능 측정지표: opm(처리량) 및 rt(응답 시간)

성능 측정지표(약어) 정의
opm 분당 주문 건수(처리량) 높을수록 좋음
rt 응답 시간(지연 시간) 낮을수록 좋음

몇 가지 "나쁜" 결과와 "좋은" 결과를 살펴보겠습니다.

 

 

출력 예: "나쁜" 성능(낮은 opm, 높은 rt)

 

이는 성능이 저조한 구성의 출력 예시입니다. 여기서 몇 가지 주요 영역을 살펴보겠습니다.

  1. 실시간 출력: 10초마다(et경과 시간을 의미하며 초 단위로 표시됨) DS3 드라이버는 실행 경과 시간, 달성한 분당 주문 건수(opm) 및 응답 시간(rt)을 보여주는 줄을 출력합니다.
  2. 드라이버가 완료되면 전반적인 성능 통계를 보여주는 Final(최종)로 시작되는 줄이 출력됩니다.
    et=  60.0은 실행 시간이 1분으로 매우 짧았음을 나타냅니다.
  3. opm=41은 데이터베이스 서버가 분당 41개 작업만 처리할 수 있었음을 나타냅니다. 이는 낮은 수치이지만 다른 많은 실습과 리소스를 공유하는 중첩된 Hands-on Lab 환경에서 실행되었으므로 예상된 수치입니다.
  4. rt_tot_avg=13218평균 응답 시간13218밀리초(13.218초)였음을 나타냅니다. 이는 높은 수치이지만 마찬가지로 예상된 수치입니다.

이 성능이 저조한 실행을 분리된 전용 실습 환경에서 수행된 성능이 우수한 실행과 비교해 보겠습니다.

 

 

출력 예: "좋은" 성능(높은 opm, 낮은 rt)

 

이는 성능이 우수한 구성의 출력 예시입니다.

  1. Final(최종)로 시작되는 이 요약 줄에서 전반적인 성능 통계를 보여줍니다.
    et=  609.4는 실행 시간이 약 10분(약 600초)이었음을 나타냅니다.
  2. opm=74932는 데이터베이스 서버가 분당 74,932개 작업을 처리할 수 있었음을 나타냅니다. 이는 이전 예에서보다 훨씬 더 높은 수치로, 제대로 조정된 성능 구성이기 때문에 가능한 것입니다.
  3. rt_tot_avg=87평균 응답 시간87밀리초에 불과했음을 나타냅니다. 이 낮은 수치도 이전 예와 극명하게 대조됩니다.

그렇다면 데이터베이스 서버가 높은 로드를 지속하여 최대 opm을 달성할 수 있는지 여부를 결정하는 요소는 무엇일까요?

 

 

데이터베이스 성능 요소

이 실습 환경에서 가능한 최대 opm(데이터베이스 성능)을 달성해야 합니다.
성능에 영향을 미치는 많은 요소가 있지만, 이 실습에서 모든 요소를 자세히 다루기에는 시간이 충분하지 않으므로 참고할 수 있는 자료 목록만 간단히 언급하겠습니다(참고: 일부 참고 자료는 6.5에 대한 것이지만 6.7에도 여전히 적용됨).

운영 환경을 구축하기 전에 이 가이드에 따라 특정 환경의 성능을 테스트하면 가상화된 데이터베이스가 최대 처리량을 달성하는지 확인할 수 있습니다.

 

정리 및 결론


축하합니다! 이제 DVD Store 3 벤치마크를 설치, 구성 및 실행하는 방법을 알게 되었습니다.

또한 최대 분당 주문 건수(opm)를 달성하도록 데이터베이스 서버를 조정하는 방법도 알아봤으므로, 이제 데이터베이스 처리량은 최대한 높이고 응답 시간은 최대한 낮출 수 있습니다.


 

모듈 3 중지

 

이 모듈을 종료하려면 다음을 수행합니다.

  1. 작업 표시줄에 있는 모듈 변환기(또는 이를 닫은 경우 바탕 화면 아이콘)를 클릭합니다.
  2. Module 3(모듈 3) 아래 Stop(중지) 버튼을 클릭합니다.

 

 

참고 자료/유용한 링크

이 모듈을 완료했습니다.

다음과 같은 링크를 통해 DVD Store 3과 전반적인 데이터베이스 성능에 대한 자세한 내용을 알아보십시오.

모범 사례:

DVD Store 블로그/백서:

DVD Store 3은 VMmark 3.0의 주요 워크로드 중 하나이기도 합니다.

 

모듈 4 - Weathervane을 사용한 애플리케이션 성능 테스트(45분)

소개


 

이 모듈에서는 가상화된 최신 클라우드 인프라에서 성능 장단점을 조사할 수 있도록 설계된 새로운 애플리케이션 수준 성능 벤치마크인 Weathervane에 대해 소개합니다.

이 모듈의 내용에 대한 간단한 개요는 다음과 같습니다.


Weathervane 소개


이 레슨에서는 Weathervane 벤치마크가 무엇이고 기존의 벤치마크 워크로드와 어떻게 다른지에 대해 설명합니다.


 

Weathervane 설명

 

 

 

Weathervane 구성 요소

 

Weathervane은 3개의 기본 구성 요소로 이루어져 있습니다.(위의 그림이 복잡해 보여도 걱정하지 마십시오. 이 실습에서 1대의 Linux 가상 머신 내에서 실행되는 3개 구성 요소를 모두 다룹니다.) 1대의 가상 머신 또는 컨테이너에서 모든 Weathervane 서비스를 실행할 수도 있지만 특정 서비스 Tier 또는 특정 서비스 인스턴스만 실행할 수도 있습니다.

  1. 애플리케이션에 대해 실제적이고 반복 가능한 로드를 제공할 수 있는 워크로드 드라이버
  2. 실행을 수행하고 결과 및 관련 성능 데이터를 수집하는 프로세스를 자동화하는 실행 하네스
  3. 실시간 옥션을 호스팅하는 웹 애플리케이션인 옥션 애플리케이션

이러한 각 구성 요소를 보다 자세히 살펴본 후 실습 환경에서 Weathervane을 실행해 보겠습니다.

 

 

워크로드 드라이버

 

Weathervane의 워크로드 드라이버에는 다음과 같은 몇 가지 주요 기능이 있습니다.

 

 

실행 하네스

 

Weathervane의 실행 하네스는 다음 사항을 비롯하여 배포에 대해 설명하는 구성 파일을 통해 제어됩니다.

하네스는 다음과 같은 매우 유용한 작업도 수행합니다.

이 모듈 뒷부분에서 하네스를 사용하여 실습 환경에서 실제로 실행을 시작해 보겠습니다. 말 그대로 하나의 명령만 사용하는 것이 얼마나 간편한지 확인할 수 있습니다.

 

 

옥션 애플리케이션

 

위의 그림에서 알 수 있듯이 옥션 애플리케이션은 Weathervane에서 가장 복잡한 부분입니다.

실시간 옥션 호스팅을 시뮬레이션하는 웹 애플리케이션으로 광범위한 사용자 로드에 맞게 배포를 손쉽게 확장할 수 있고 규모를 산정할 수 있는 아키텍처를 사용합니다. 애플리케이션 배포에는 캐싱, 메시징, 데이터스토어, 관계형 데이터베이스 Tier와 같은 다양한 지원 서비스가 수반됩니다. 많은 서비스가 선택 사항이며 일부는 여러 공급업체 구현을 지원합니다.

본 실습의 가상 머신과 같은 기본 Weathervane 배포는 아래와 같은 애플리케이션을 사용합니다(애플리케이션에 대한 자세한 내용은 링크 클릭). 모두 벤치마크와 함께 제공되는 자동 설정 스크립트를 통해 "즉시 사용 가능하게"(바로 실행할 수 있게) 설정되어 있습니다.

또한 이러한 서비스 중 일부의 인스턴스 수를 사전 설정된 스케줄 또는 모니터링한 성능 측정지표에 대응하여 런타임 시 탄력적으로 확장할 수 있습니다. 애플리케이션 배포의 유연성 덕분에 광범위하고 복잡한 인프라 관련 성능 문제를 조사할 수 있습니다.

 

Weathervane 다운로드/설치


이 레슨에서는 Weathervane 벤치마크를 설치하는 방법에 대해 설명합니다. 대부분의 설정이 자동화되었으므로 설정이 매우 간편합니다.

참고: Weathervane은 이미 Hands-on Lab 환경에 설치되어 있으므로, 이 레슨은 정보 제공의 목적으로만 제공됩니다.(예를 들어 Weathervane을 자체 환경에서 얼마나 쉽게 설치할 수 있는지 알아보려는 경우 참조할 수 있습니다.) 다음 레슨에서는 실습 환경에서 Weathervane을 구성하고 실행해 보겠습니다.


 

Weathervane 가상 머신 생성

 

Weathervane 호스트 생성은 상대적으로 간단합니다. Weathervane 설정 프로세스는 워크로드 드라이버, 실행 하네스 및 애플리케이션 구성 요소를 실행하기 위해 구성할 CentOS 7 가상 머신인 Weathervane 호스트를 생성하는 것으로 시작합니다. 가상 머신을 생성할 때 Linux를 게스트 OS 제품군으로 선택하고 Red Hat Enterprise Linux 7 (64-bit)(Red Hat Enterprise Linux 7(64비트))를 게스트 OS 버전으로 선택합니다. 이는 가상 머신을 복제할 때 사용자 지정 스크립트가 제대로 작동하기 위해 필요합니다.

스크린샷과 같이 가상 하드웨어에는 최소 CPU 2개, 8GB 메모리, 20GB 디스크 공간이 있어야 합니다(이 예에서는 30GB 사용). 대규모 배포의 경우 하드웨어를 그에 맞게 수직 확장할 수 있습니다(자세한 내용은 Weathervane 설명서 참조).

 

 

CentOS 7 설치

 

CentOS 7 설치는 화면에 나타난 기본값인 Minimal Install(최소 설치) 또는 완전한 데스크톱 설치일 수 있습니다.

실제로 완전한 데스크톱 설치로 하네스를 실행하기 위한 하나의 Weathervane 호스트를 생성하고 최소 설치로 다양한 Weathervane 서비스를 실행하도록 가상 머신에 복제하기 위한 두 번째 호스트를 생성할 수 있습니다.

 

 

OS 설치 후 작업

OS 설치를 완료한 후 일부 작업을 완료한 다음에 Weathervane을 설치해야 합니다

  1. yum update 명령을 루트 사용자로 실행하여 모든 소프트웨어 패키지를 업데이트합니다.
  2. yum install -y open-vm-tools 명령을 루트 사용자로 실행하여 VMware Tools를 설치합니다(CentOS 7의 경우 open-vm-tools).
  3. yum install –y java-1.8.0-openjdk* 명령을 루트 사용자로 실행하여 Java를 설치합니다.
  4. yum install –y perl 명령을 루트 사용자로 실행하여 Perl을 설치합니다.

참고: 이러한 명령은 실습 환경에서 작동하지 않지만 해당 작업은 이미 가상 머신에서 수행되었습니다.

 

 

Weathervane 다운로드 및 추출

 

Weathervane은 VMware에서 개발한 오픈 소스 프로젝트입니다. 따라서 최신 릴리스 tarball(.tar.gz)은 여기 나와 있는 것처럼 https://github.com/vmware/weathervane/releases에서 다운로드할 수 있습니다.

릴리스 tarball은 알려진 정상 시점에 캡처된 저장소의 스냅샷입니다. 릴리스는 일반적으로 마스터 브랜치의 최신 체크인보다 더 면밀하게 테스트됩니다.

Weathervane을 설치하려면 CentOS 호스트에 루트 사용자로 로그인하고 tar zxf weathervane-1.0.14.tar.gz 명령을 사용하여 tarball의 압축을 풉니다.
참고: 이 작업은 이미 Hands-on Lab 환경에서 수행되었으므로 실습 가상 머신에서 이 명령을 실행하지 마십시오.

tarball의 압축을 풀었으면 Weathervane 실행 파일을 구축해야 합니다.

 

 

Weathervane 실행 파일 구축

Weathervane 실행 파일을 구축하려면 이전 단계에서 tarball의 압축을 푼 다음
./gradlew clean release 명령을 실행하여 생성된 /root/weathervane 디렉토리로 이동합니다.
참고: 이 작업은 이미 Hands-on Lab 환경에서 수행되었으므로 실습 가상 머신에서 이 명령을 실행하지 마십시오.

Weathervane을 처음 구축하면 많은 종속성이 다운로드됩니다. 구축이 완료될 때까지 기다린 후 다음 단계를 진행합니다.

 

 

Weathervane auto-setup 스크립트 실행

auto-setup 스크립트는 Weathervane 구성 요소를 모두 실행하도록 가상 머신을 구성합니다.
참고: 이 프로세스를 성공적으로 완료하려면 가상 머신이 인터넷에 연결되어 있어야 합니다.

Weathervane 디렉토리에서
./autoSetup.pl 명령을 사용하여 스크립트를 실행합니다.
참고: 이 작업은 이미 Hands-on Lab 환경에서 수행되었으므로 실습 가상 머신에서 이 명령을 실행하지 마십시오.

인터넷 연결 속도와 호스트 하드웨어의 기능에 따라 auto-setup 스크립트를 실행하는 데 1시간 또는 그 이상 걸릴 수 있습니다.
완료되면 가상 머신을 재부팅해야 합니다. 이제 Weathervane을 실행할 준비가 되었습니다.

 

Weathervane 구성


이 레슨에서는 실습을 시작하고 실습 환경 배포에 Weathervane 벤치마크를 구성하는 방법에 대해 설명합니다.


 

성능 실습 모듈 변환기 실행

 

주 콘솔의 바탕 화면에 있는 Performance Lab MS(성능 실습 모듈 변환기) 바로 가기를 두 번 클릭하거나 작업 표시줄을 사용해 해당 창으로 이동합니다.

 

 

모듈 4 시작

 

Module 4(모듈 4) 아래 Start(시작) 버튼을 클릭하면(강조 표시됨) PowerShell 스크립트가 실행되어 Weathervane 가상 머신이 시작되고 2개의 PuTTY 세션이 열립니다.

 

모듈 4가 시작되면 화면에 표시된 것처럼 2개의 PuTTY 창이 나란히 나타나고 팝업 창이 표시됩니다. OK(확인)를 클릭합니다.

이제 Weathervane을 구성하고 실행할 준비가 되었습니다.

 

 

Weathervane 구성

 

이 벤치마크를 어떻게 구성할 수 있는지 확인하려면 Weathervane 구성 파일을 살펴봐야 합니다.

왼쪽의 PuTTY 창에 다음 명령을 입력하고 Enter 키를 누릅니다.

less weathervane.config

이제 표준 탐색 키(위쪽/아래쪽 화살표, PgUp/PgDn)를 사용하여 사용자 지정할 다양한 매개 변수를 볼 수 있습니다.

 

화면에 Weathervane 구성 파일의 앞부분이 표시되고 있습니다. 대부분의 구성 파일에서 표준인 "#"으로 시작하는 줄은 주석이므로 Weathervane에서 무시됩니다.

여기에 가장 유용한 매개 변수 중 하나(따라서 상단에 나옴)인 users가 강조 표시되어 있습니다. 주석에 명시된 바와 같이 이 매개 변수는 Weathervane 벤치마크 실행 중에 시뮬레이션된 사용자의 활성 수를 결정합니다. 이는 실습 환경의 제약으로 인해 이미 최소값인 60으로 축소되었지만, 아래에 나타나는 것처럼 기본값은 300입니다.

 

오른쪽의 PuTTY 창에 다음 명령을 입력하고 Enter 키를 누릅니다.
참고: less 앞의 문자는 파이프 기호입니다(일반적으로 Shift 키를 누른 상태에서 백슬래시(\) 키를 눌러 입력). 이 텍스트를 선택하고 끌어서 PuTTY 창에 직접 놓을 수도 있으니 시도해 보시기 바랍니다.

./weathervane.pl --help |less

 

방금 실행한 --help 명령으로 모든 Weathervane 명령줄 매개 변수가 나열됩니다. 이러한 매개 변수 중 하나라도 명령줄에 설정된 경우 Parameter Default(매개 변수 기본값)와 방금 살펴본 weathervane.config 파일에 설정된 값을 모두 재정의합니다.

이 스크린샷과 같이 users 매개 변수의 기본값은 300이지만 weathervane.config에서 최소값인 60으로 설정했습니다. 사용자 100명에 대해 Weathervane을 실행하려고 하는 경우 명령줄에서 이를 재정의할 수 있습니다(즉, ./weathervane.pl --users=100).

 

양 PuTTY 창에서 PgDn 키를 눌러 아래로 스크롤하여 다음 페이지로 이동하면 이와 유사한 화면이 표시되어야 합니다. 도움말 텍스트에서 설명하는 것과 같이 Weathervane에는 3개의 실행 길이 매개 변수인 rampUp, steadyState 및 rampDown이 있습니다. runLength를 short, medium 또는 long으로 변경하여 3개 매개 변수 모두를 한 번에 설정할 수 있습니다.

실행 시간은 실습 환경에서 필요한 기간보다 더 오래 실행되지 않도록 구성 파일에서 값을 각각 30, 60, 0으로 설정했습니다. 실제 벤치마크 환경에서 더 오랜 기간 동안 성능을 평가하기 위해 runLength를 medium 또는 long으로 설정할 수 있습니다.

이때 화살표 키PgUp/PgDn 키를 필요에 따라 사용하여 Weathervane에서 지원하는 모든 매개 변수를 볼 수 있습니다. 보시는 것처럼 자유롭게 구성할 수 있습니다.

 

지금까지 Weathervane 구성 파일과 도움말 텍스트에 대해 살펴봤으므로, 각 PuTTY 창을 마우스 왼쪽 버튼으로 클릭하고 q를 눌러 less를 종료하고 bash 셸로 돌아갑니다. 위와 유사한 화면이 표시되어야 합니다.

다음 레슨에서는 실제로 Weathervane 벤치마크 실행을 시작해 보겠습니다.

 

Weathervane 실행/조정


이 레슨에서는 실습 환경에 배포된 가상 머신을 사용하여 Weathervane 벤치마크를 실행하고 조정하는 방법에 대해 설명합니다.


 

Weathervane 실행

 

지금까지 Weathervane 구성 방법에 대해 알아봤으므로 이제 테스트 실행을 시작할 수 있습니다. 지정된 실행 길이가 경과하면 실행 하네스가 필요한 서비스 시작, 성능 통계 수집, 벤치마크 중지를 자동화하므로 이는 실제로 가장 쉬운 부분입니다.

왼쪽의 PuTTY 창을 클릭한 후, 아래의 간단한 명령을 입력하고 Enter 키를 눌러 실행하여 Weathervane 벤치마크 하네스를 시작합니다.

./weathervane.pl

이미 /root/weathervane 디렉토리에 있으므로 현재 디렉토리에서 weathervane.pl을 호출합니다.

오른쪽의 PuTTY 창에서 Linux top 명령을 입력하고 Enter 키를 눌러 실행하여 Weathervane이 실행되는 동안 CPU, 메모리 등을 사용하는 프로세스를 실시간으로 모니터링할 수 있습니다.

top

 

이제 Weathervane이 실행되어야 합니다.

상단 출력은 3개 섹션으로 구분할 수 있습니다.

  1. 이 섹션은 두 가상 CPU(vCPU)의 CPU 사용률을 보여줍니다. 이 값은 전체 실행 동안 변동됩니다. 이 스크린샷에는 두 CPU 모두 사용률이 높은 것으로 나타납니다(95-96%). 이는 이 벤치마크에 예상된 결과입니다.
  2. 이 섹션은 가상 머신의 메모리 사용률을 보여줍니다.
    첫 번째 줄(KiB Mem(KiB 메모리))은 가상 머신에 할당된 8GB가 대부분 used(사용됨) 상태이고 free(여유) 용량이 거의 없음을 보여줍니다. 많은 서비스/프로세스가 실행되어 RAM을 사용하고 있으므로 이는 예상된 결과입니다.
    반대로 두 번째 줄(KiB Swap(KiB 스왑))은 스왑 공간이 약 3GB이며 대부분이 free(여유) 공간이고 used(사용됨) 공간이 거의 없음을 보여줍니다. 따라서 Linux에서 메모리를 디스크로 스와핑하지 않아도 됩니다(가상 머신에 4GB 등의 충분한 메모리를 할당하지 않을 경우 발생할 가능성이 높음).
  3. top 출력의 아랫부분은 실행 중인 프로세스를 CPU 사용률(%CPU)이 가장 높은 순으로 정렬하여 보여줍니다. 간략히 살펴보면 java(Tomcat), mongod(MongoDB) 및 postgres(PostgreSQL)가 CPU 사용률이 높습니다.

이 벤치마크 실행을 완료하려면 약간의 시간이 소요됩니다(처음부터 끝까지 약 15분). 기다리는 동안 Weathervane 설명서에서 성능을 개선하는 방법을 살펴볼 수 있습니다.

 

 

매개 변수 조정(사용자 가이드)

 

작업 표시줄에서 Windows 탐색기 바로 가기를 클릭합니다.

 

  1. C: 드라이브를 두 번 클릭합니다.
  2. weathervane 디렉토리를 클릭합니다.
  3. 하단으로 스크롤하여 weathervane_users_guide.pdf를 두 번 클릭합니다.

이는 Weathervane을 설치, 구성, 조정하는 방법이 나와 있는 PDF 파일로 벤치마크와 함께 제공됩니다.

 

이 99페이지 문서를 처음부터 끝까지 읽을 필요는 없습니다. 설치 및 구성과 관련하여 이 설명서에 나와 있는 내용은 상당 부분 이미 다룬 내용입니다.

따라서 아래로 스크롤하여 Component Tuning(구성 요소 조정) 섹션이 나와 있는 56페이지(화면에 표시됨)로 이동하십시오. 다음 몇 페이지를 대강 훑어보면 Weathervane 내 다양한 Tier를 조정하기 위해 사용해 볼 수 있는 매개 변수에 대해 파악할 수 있습니다.

Weathervane 환경의 성능을 개선하는 또 다른 방법은 Weathervane 호스트 가상 머신을 복제하고 각각에 다른 서비스를 할당하는 것입니다. 예를 들어 애플리케이션 서버, 웹 서버, NoSQL 데이터스토어 등의 역할을 하는 별도의 여러 가상 머신을 사용할 수 있습니다. 자세한 내용은 사용자 가이드의 섹션 7.5 "Cloning the Weathervane VM"(Weathervane 가상 머신 복제)을 참조하십시오.

 

 

Weathervane 실행 확인

 

주기적으로 PuTTY 창으로 다시 전환하여 실행 진행 상황을 확인합니다. Weathervane 벤치마크 실행이 완료되면 이와 유사한 화면이 표시됩니다. 구체적으로 살펴보면 다음과 같습니다.

  1. 왼쪽에는 Cleaning and compacting storage(스토리지 정리 및 압축)와 실행의 Passed(통과) 또는 Failed(실패) 여부를 나타내는 메시지가 표시됩니다.
    참고: Failed(실패)가 표시되거나 Failed Response-Time metric(실패한 응답 시간 측정지표) 등의 메시지가 표시되어도 문제 없습니다. 공유 실습 환경에서 응답 시간은 벤치마크 요구 사항을 충족하지 않을 가능성이 큽니다. 전용 테스트/개발 환경에서 이는 문제가 되지 않습니다.
  2. 끝에 실행 번호가 구체적으로 표시됩니다(이 예의 경우 Run 8(실행 8)). 이 번호는 다음 단계에서 출력 파일을 확인할 때 사용됩니다.
  3. 오른쪽top 화면은 Linux 가상 머신이 현재 유휴 상태임을 나타냅니다(%Cpu가 1% 미만이고 대부분의 메모리가 free(여유) 용량임).
  4. 실행이 완료된 것을 확인했으면 오른쪽 상단의 "X"를 클릭하여 오른쪽의 PuTTY 창을 닫습니다(PuTTY 종료 확인 메시지가 표시되면 OK(확인) 클릭).
  5. 화면에 표시된 바와 같이 오른쪽 상단의 최대화 버튼을 클릭하여 왼쪽의 남은 PuTTY 창을 최대화합니다.

 

 

 

Weathervane 벤치마크 출력 분석

벤치마크를 실행하면 Weathervane 실행 하네스가 수집하는 다양한 로그 파일을 볼 수 있습니다.

  1. cd output(모든 Weathervane 출력은 /root/weathervane/output에 저장됨)
  2. ls(이 가상 머신의 모든 실행을 표시하여 가장 최근의 실행 파악)
  3. cd 8/(가장 최근의 실행 번호로 교체)
  4. cat version.txt(이 결과를 실행하는 데 사용된 Weathervane 버전 기록)
  5. cat run.log(각 애플리케이션 인스턴스의 모든 오류와 응답 시간 세부 정보 표시)
  6. cat console.log(표시되지 않음, 서비스 시작/중지, 실행 통과 또는 실패 여부, 정리 등 이미 확인한 PuTTY 콘솔에 대한 출력을 기록)

이러한 파일을 모두 확인했으면 이 PuTTY 콘솔을 닫을 수 있습니다.

실행이 통과하면 애플리케이션 배포 및 기본 인프라가 사용자 작업에 허용 가능한 응답 시간으로 지정된 수의 사용자에 의해 야기된 로드를 지원할 수 있다는 것을 의미합니다.

일반적인 Weathervane 사용 방법은 인프라의 일부 구성 요소가 변경될 때 지원할 수 있는 최대 사용자 수를 비교하는 것입니다. 예를 들어 동일한 애플리케이션 구성이 두 개의 다른 서버에서 실행되는 경우, 서버에서 지원되는 최대 사용자 로드를 비교하여 이러한 유형의 웹 애플리케이션에 더 나은 성능을 제공하는 구성을 결정할 수 있습니다.

축하합니다! 이제 Weathervane을 실행하는 방법을 알게 되었습니다.

 

정리 및 결론


축하합니다! 이제 Weathervane 벤치마크를 설치, 구성 및 실행하는 방법을 알게 되었습니다.


 

모듈 4 종료 방법

 

이 모듈을 종료하려면 모듈 변환기 창을 열고 Module 4(모듈 4) 아래 Stop(중지) 버튼을 클릭합니다.

 

 

참고 자료/유용한 링크

다음과 같은 링크를 통해 Weathervane에 대한 자세한 내용을 알아보십시오.

 

모듈 5 - CPU 성능, 기본 개념 및 문제 해결(15분)

CPU 성능 문제 해결 소개


본 모듈의 목적은 가상화된 환경에서의 CPU 경합 문제를 소개하는 것입니다. 또한 다양한 성능 측정지표와 설정을 확인하여 성능 문제를 신속하게 파악하는 방법도 안내할 것입니다.

성능 문제는 CPU 리소스가 수요를 충족할 정도로 충분하지 않을 때 발생할 수 있습니다. vSphere 호스트에서 CPU 리소스를 과도하게 요구하는 이유는 다양할 수 있습니다. 일부 경우 원인은 간단합니다. vSphere 호스트를 컴퓨팅 사용이 많은 애플리케이션을 실행하는 너무 많은 가상 머신으로 채울 경우 개별 가상 머신 모두에 충분한 CPU 리소스를 공급하는 것이 불가능할 수 있습니다. 그러나 사용 가능한 리소스의 비효율적인 사용이나 최적이 아닌 가상 머신 구성과 관련하여 보다 미묘한 원인이 있을 수도 있습니다.

이제 시작하겠습니다.


 

바탕 화면 오른쪽 하단에서 실습 상태 확인

 

시작 절차가 모두 완료되어 실습을 시작할 준비가 되었는지 확인합니다. "Ready"(준비) 상태가 아니면 몇 분 더 기다려야 합니다. 5분 후에도 "Ready"(준비) 상태로 바뀌지 않으면 도움을 요청하십시오.

 

 

Chrome 열기

 

작업 표시줄에서 Chrome 아이콘을 클릭합니다.

 

 

vCenter 로그인

 

자격 증명이 미리 입력되어 있으므로 Login(로그인) 버튼을 클릭합니다.

 

 

호스트 및 클러스터 선택

 

 

CPU 경합


다음은 가장 일반적인 CPU 성능 문제입니다.

긴 준비 시간: 가상 머신이 바로 실행 가능한 상태지만 vSphere 스케줄러가 가상 머신을 실행할 물리적 호스트 CPU 리소스를 찾을 없어서 실행할 수 없는 경우 CPU는 준비 상태입니다. 10% 이상의 준비 시간은 CPU 경합을 나타낼 수 있고 CPU 사용이 많은 애플리케이션의 성능에 영향을 미칠 수 있습니다. 하지만 CPU 사용이 적은 일부 애플리케이션 및 가상 머신은 준비 시간 값이 훨씬 더 높을 수 있지만 여전히 만족스러운 성능을 보일 수 있습니다.

긴 동시 중지 시간: 동시 중지 시간은 vCPU가 필요한 것보다 더 많다는 것과 초과 vCPU가 가상 머신의 성능을 저하시키는 오버헤드를 발생시킨다는 것을 나타냅니다. 가상 머신은 더 적은 vCPU로 더 안정적으로 실행될 가능성이 있습니다. 동시 중지 시간이 긴 vCPU는 실행되지 않고 대신 더 많은 다른 유휴 vCPU가 사용량이 많은 vCPU를 따라 잡습니다.

CPU 제한: CPU 제한은 가상 머신이 정해진 양의 CPU 리소스보다 더 많이 사용하지 못하도록 합니다. 모든 CPU 제한은 가상 머신이 해당 제한보다 더 많은 리소스를 필요로 하는 경우 CPU 성능 문제를 초래할 수 있습니다.

호스트 CPU 포화: vSphere 호스트의 물리적 CPU가 85% 이상으로 일관되게 활용되는 경우 vSphere 호스트가 포화될 수 있습니다. vSphere 호스트가 포화되면 스케줄러가 가상 머신을 실행하기 위해 사용할 수 있는 물리적 CPU 리소스를 찾기가 더 어려워집니다.

게스트 CPU 포화: 게스트 CPU(vCPU) 포화는 가상 머신 내의 애플리케이션이 가상 머신에 할당된 CPU 리소스를 90% 이상 사용하고 있는 것입니다. 이는 애플리케이션이 vCPU 리소스에 병목 현상을 야기한다는 것을 나타내는 지표일 수 있습니다. 이러한 상황에서 추가 vCPU 리소스를 가상 머신에 추가하면 성능이 향상될 수 있습니다.

과도한 가상 머신 vCPU 규모 산정: 대규모 SMP(Symmetric Multi-Processing)를 사용하면 가상 머신이 불필요한 오버헤드를 초래할 수 있습니다. 가상 머신은 가상 머신에서 실행하기 위한 애플리케이션에 맞게 올바르게 규모를 산정해야 합니다. 일부 애플리케이션은 특정 수의 스레드까지만 멀티스레딩을 지원할 수 있습니다. 추가 vCPU를 가상 머신에 할당하면 추가 오버헤드가 초래될 수 있습니다. vCPU 사용량에 가상 머신이 여러 vCPU로 구성되어 있지만 이중 하나만 사용하고 있다고 표시되는 경우, 이는 가상 머신 내의 애플리케이션이 추가 vCPU 용량을 활용할 수 없거나 게스트 OS가 잘못 구성되어 있음을 나타내는 지표일 수 있습니다.

낮은 게스트 사용량: 낮은 게스트 내 CPU 사용률은 애플리케이션이 올바르게 구성되어 있지 않거나 애플리케이션이 I/O 또는 메모리와 같은 다른 리소스가 부족하여 할당된 vCPU 리소스를 완전히 활용할 수 없음을 나타내는 지표일 수 있습니다.


 

Performance Lab 모듈 변환기 실행

 

주 콘솔의 바탕 화면에 있는 Performance Lab MS 바로 가기를 두 번 클릭합니다.

 

 

모듈 5 시작

 

Module 5(모듈 5) 아래 Start(시작) 버튼을 클릭하면 스크립트가 실행됩니다.

 

스크립트를 실행하는 데 몇 분이 소요됩니다.  

 

 

계속 진행하려면 "Press Enter to continue"(계속하려면 Enter 키를 누르십시오.)가 나타날 때까지 기다렸다가 Enter 키를 누르십시오.

 

 

CPU 테스트 시작

 

스크립트가 완료되면 두 개의 원격 데스크톱 창이 열립니다(참고: 위와 같이 나란히 표시하려면 두 창 중 하나를 이동해야 함).

스크립트가 perf-worker-01a 가상 머신과 perf-worker-01b 가상 머신 모두에서 CPU 사용이 많은 벤치마크(SPECjbb2005)를 시작했고, 이 워크로드가 실행될 때 GUI에 실시간 성능 값이 표시됩니다.

SPECjbb2005 창이 열려 있지 않은 경우 왼쪽 상단에서 바로 가기를 실행하십시오.

위의 스크린샷은 벤치마크 성능이 약 15,000임을 보여주는 예입니다.

중요 참고 사항: 실험실 환경의 로드 변경으로 인해 실제 값은 스크린샷에 표시된 값과 다를 수 있습니다.

 

 

perf-worker-01a(가상 머신 수준) 성능 차트로 이동

 

Chrome 아이콘을 클릭하여 브라우저 창을 엽니다.

 

Login(로그인) 버튼을 클릭하여 vSphere Client를 엽니다.

 

  1. 왼쪽의 가상 머신 목록에서 perf-worker-01a 가상 머신을 선택합니다.
  2. Monitor(모니터) 탭을 클릭합니다.
  3. Performance(성능)를 클릭합니다.
  4. Advanced(고급)를 클릭합니다.
  5. 전용 차트 팝업 창이 열리도록 팝업 차트 아이콘을 클릭합니다.

 

 

성능 모니터링을 준비할 CPU 선택

 

잠재적 CPU 문제를 조사할 때 중요하게 분석해야 하는 여러 가지 카운터가 있습니다.

  1. 최대화 아이콘을 클릭합니다(닫기를 클릭하지 않도록 주의!)
  2. 상단에서 Chart Options(차트 옵션)를 클릭합니다.
  3. 목록을 스크롤하여 Demand(수요), Ready(준비)Usage in MHz(사용량(MHz)) 카운터를 표시합니다.
  4. perf-worker-01a 객체만 선택합니다.
  5. OK(확인)를 클릭합니다.

 

 

CPU 상태 시간 설명

 

가상 머신은 다음 네 개의 CPU 상태 중 하나일 수 있습니다.

 

 

수요 및 사용량 모니터링

 

이 가상 머신이 요구하는 CPU 양을 확인하고 이를 가상 머신에 실제로 할당되는 CPU 사용량(MHz)과 비교합니다. 가상 머신은 현재 사용할 수 있는 것보다 더 많이 요구합니다.

또한 가상 머신은 많은 준비 시간을 필요로 하는 것을 알 수 있습니다.

지침: 준비 시간이 10%를 초과하면 성능에 문제가 있을 수 있습니다.

 

 

값 변환 설명

 

참고: vCenter는 밀리초(ms) 단위의 "준비 시간"과 같은 몇 가지 측정지표를 보고합니다. 위의 공식을 사용하여 밀리초(ms) 값을 퍼센트로 변환하십시오.

다중 vCPU 가상 머신의 경우 샘플 기간에 가상 머신의 vCPU 수를 곱하여 총 샘플 기간을 결정합니다. 다중 vCPU 가상 머신에서 동시 중지 시간을 모니터링하는 것도 도움이 됩니다. 준비 시간과 마찬가지로 10%를 초과하는 동시 중지 시간은 성능 문제를 나타낼 수 있습니다. 이제 준비 시간 측정지표와 동시 중지 측정지표를 vCPU당 및 가상 머신당 조사할 수 있습니다.  Per vCPU(vCPU당)가 이러한 통계를 확인하는 가장 정확한 방법입니다.

 

 

호스트 수준 CPU 차트 뷰로 이동

 

  1. esx-01a.corp.local을 선택합니다.
  2. Monitor(모니터) 탭을 선택합니다.
  3. Performance(성능)를 선택한 다음 Advanced (고급)를 선택합니다.
  4. 팝업 차트 아이콘을 선택합니다.

 

 

ESX 호스트 수준 CPU 측정지표 확인

 

창 최대화 아이콘을 클릭하여 공간을 최대화합니다.  차트를 보면 호스트의 1개 CPU에만 상당한 워크로드가 실행되고 있는 것을 알 수 있습니다.

CPU 1개는 100% 활용되지만(녹색으로 표시됨) 호스트의 다른 CPU는 많이 활용되지 않고 있습니다.

 

 

원격 데스크톱 연결 닫기

 

두 개의 원격 데스크톱 연결을 닫습니다.

 

결론 및 정리


이 실습의 나머지 부분에 사용할 리소스를 확보하기 위해 사용된 가상 머신을 종료하고 이 구성을 재설정해야 합니다.


 

모듈 5 중지

 

바탕 화면의 모듈 변환기 창에서 Module 5(모듈 5) 아래 Stop(중지) 버튼을 클릭합니다.

 

 

핵심 사항

CPU 경합 문제는 일반적으로 쉽게 감지됩니다. 실제로 vCenter에는 호스트 CPU 사용률 또는 가상 머신 CPU 사용률이 장시간에 걸쳐 너무 높은 경우 이를 트리거하는 여러 가지 경보가 있습니다. 

vSphere 6을 사용하면 최대 128개의 vCPU가 있는 초대형 가상 머신을 생성할 수 있습니다. 따라서 실행할 애플리케이션 워크로드에 맞게 가상 머신의 규모를 산정하는 것이 가장 중요합니다. 워크로드가 실제로 사용할 수 있는 것보다 불필요하게 큰 리소스로 가상 머신의 규모를 산정하면 하이퍼바이저 오버헤드가 발생할 수 있고 또한 성능 문제를 야기할 수 있습니다.

다음은 일반적인 CPU 성능과 관련한 몇 가지 팁입니다.

플랫폼이 너무 작은 경우 대형 가상 머신을 사용하지 마십시오.

사용량이 적은 워크로드에서처럼 사용량이 많은 워크로드에서 높은 통합 비율을 기대하지 마십시오.

 

모듈 6 - CPU 성능 향상 기능: 전원 정책(15분)

전원 정책 소개 및 전원 정책이 성능에 미치는 영향


VMware vSphere는 다양한 애플리케이션 에코시스템에 대한 공통 가상화 플랫폼의 역할을 합니다. 애플리케이션마다 반드시 충족해야 하는 성능 요구 사항이 다지만, 최근 데이터 센터의 밀도 및 컴퓨팅 요구 사항 증가가 이러한 애플리케이션을 실행하는 전원 및 냉각 용량과 비용이 한계에 이르고 있습니다.

vSphere HPM(호스트 전원 관리)은 컴퓨터 시스템 또는 기기가 비활성 상태이거나 최대 속도로 실행할 필요가 없을 때 컴퓨터 시스템 또는 기기의 특정 부분을 절전 상태로 전환하여 에너지를 절약하는 기술입니다.  vSphere는 ACPI(Advanced Configuration and Power Interface)의 성능 및 전원 상태를 활용하여 전원 관리를 처리합니다. VMware vSphere® 5.0에서는 기본 전원 관리 정책이 DVFS(Dynamic Voltage and Frequency Scaling)를 기반으로 했습니다. 이 기술은 프로세서의 성능 상태를 활용하므로 이를 사용하면 프로세서를 낮은 주파수와 전압에서 실행하여 전원을 절약할 수 있습니다. 그러나 VMware vSphere 5.5부터는 기본 HPM 정책에서 성능은 그대로 양호하게 유지하면서 이전 릴리스에 비해 전원 절감 효과를 대폭 높이기 위해 DVFS 외에도 깊은 중지 상태(C-상태)를 사용합니다.

그러나 ESXi로 이러한 기능을 제어할 수 있으려면 서버 BIOS 전원 관리 프로필을 "OS Control mode"(OS 제어 모드) 또는 동급으로 설정해야 합니다.

이 실습에서 살펴볼 내용은 다음과 같습니다.

  1. 서버 BIOS 설정의 사용자 지정(스크린샷의 예 사용)
  2. ESXi가 제공하는 네 가지 전원 정책에 대해 설명하고 이 설정을 변경하는 방법 시연
  3. 전원과 성능의 균형을 유지(대부분의 환경에 권장됨)하거나 최대 성능을 최적화(일부 전원 절감 효과를 포기해야 할 수 있음)할 수 있도록 환경 최적화

 

모듈 시작

 

이 모듈을 시작하겠습니다.

작업 표시줄에 있는 바로 가기에서 Chrome을 실행합니다.

 

 

vSphere 로그인

 

Login(로그인)을 클릭하여 vSphere에 로그인합니다.

 

서버 BIOS 전원 관리 설정 구성


VMware ESXi에는 다양한 호스트 전원 관리 기능이 있습니다. 이러한 기능은 ESXi 호스트가 완전히 활용되지 않을 때 전원을 절감합니다. ESXi가 하드웨어에서 제공하는 전원 관리 기능을 가장 유연하게 사용할 수 있도록 서버 BIOS 설정을 구성하고 (다음 섹션)하는 것이 가장 좋습니다.

대부분의 시스템에서 기본 설정은 BIOS를 통해 제어되는 전원 관리입니다. 해당 설정에서는 ESXi가 전원을 관리할 수 없습니다. 대신 BIOS 펌웨어를 통해 관리합니다. 다음 섹션에서는 이 설정을 OS Control(OS 제어)로 변경(대부분의 환경에 권장됨)하는 방법에 대해 설명합니다.

일부 경우 성능 저하가 ESXi 또는 서버 하드웨어에 의해 구현된 프로세서 전원 관리와 관련이 있을 수 있습니다. 프로세서 전원 관리 기능을 사용할 경우 처리 속도 지연 시간에 매우 민감한 일부 애플리케이션에서 예상보다 낮은 성능이 관측될 수 있습니다. 해당 애플리케이션에서 최고의 성능을 실현하려면 ESXi 및 서버 하드웨어 전원 관리 기능을 해제해야 할 수 있습니다.  이 설정은 일반적으로 BIOS에서 Maximum Performance(최대 성능) 모드라고 합니다.

참고: 전원 관리를 해제하면 특히 로드가 적은 경우 시스템에서 더 많은 전원이 소비됩니다. 대부분의 애플리케이션은 성능에 미치는 영향이 거의 또는 전혀 없이 전원 관리를 통해 전원 절감 효과를 누립니다.

결론: 몇 가지 형태의 전원 관리가 권장되며, 테스트 결과에서 애플리케이션 성능에 부정적인 영향을 미치는 것으로 나타나는 경우에만 해제해야 합니다.

구성 방법과 구성 대상에 대한 자세한 내용은 백서(http://www.vmware.com/files/pdf/techpaper/hpm-perf-vsphere55.pdf)를 참조하십시오.


 

OS 제어 모드로 BIOS 구성(Dell 예)

 

상기 스크린샷은 OS(ESXi)에서 CPU 전원 절감 기능을 직접 제어할 수 있도록 11세대 Dell PowerEdge 서버 BIOS를 구성하는 방법을 보여줍니다.

UEFI(Unified Extensible Firmware Interface)를 사용하는 Dell PowerEdge 12세대 이상 서버의 경우에는 System Setup > System BIOS(시스템 설정 > 시스템 BIOS) 설정에서 System Profile(시스템 프로필) 모드를 검토합니다. 다음과 같은 옵션이 표시됩니다.

Performance Per Watt (OS)(와트당 성능(OS))를 선택합니다.

이제 ESXi에서 사용하는 전원 관리 정책을 확인해야 합니다(다음 섹션 참조).

 

 

OS 제어 모드로 BIOS 구성(HP 예)

 

상기 스크린샷은 RBSU(ROM 기반 설정 유틸리티)를 통해 HP ProLiant 서버 BIOS를 구성하는 방법을 보여줍니다. 빨간색으로 강조 표시된 설정을 사용하면 OS(ESXi)에서 일부 CPU 전원 절감 기능을 직접 제어할 수 있습니다.

이제 ESXi에서 사용하는 전원 관리 정책을 확인해야 합니다(다음 섹션 참조).

 

 

최대 성능 모드로 BIOS 구성(Dell 예)

 

상기 스크린샷은 11세대 Dell PowerEdge 서버 BIOS를 구성하여 전원 관리를 해제하는 방법을 보여줍니다.

UEFI를 사용하는 Dell PowerEdge 12세대 이상 서버의 경우에는 System Setup > System BIOS(시스템 설정 > 시스템 BIOS) 설정에서 System Profile(시스템 프로필) 모드를 검토합니다. 다음과 같은 옵션이 표시됩니다.

Performance(성능)를 선택하여 전원 관리를 해제합니다.

참고: 전원 관리를 해제하면 특히 로드가 적은 경우 시스템에서 더 많은 전원이 소비됩니다. 대부분의 애플리케이션은 성능에 미치는 영향이 거의 또는 전혀 없이 전원 관리를 통해 전원 절감 효과를 누립니다. 따라서 전원 관리를 해제했을 때 성능 향상이 이루어지지 않는 경우 VMware는 전원 관리를 다시 사용하도록 설정하여 전원 소비를 줄일 것을 권장합니다.

 

 

최대 성능 모드로 BIOS 구성(HP 예)

 

상기 스크린샷은 서버의 RBSU에서 HP Power Profile(HP 전원 프로필) 모드를 Maximum Performance(최대 성능) 설정으로 지정하여 전원 관리를 해제하는 방법을 보여줍니다.

참고: 전원 관리를 해제하면 특히 로드가 적은 경우 시스템에서 더 많은 전원이 소비됩니다. 대부분의 애플리케이션은 성능에 미치는 영향이 거의 또는 전혀 없이 전원 관리를 통해 전원 절감 효과를 누립니다. 따라서 전원 관리를 해제했을 때 성능 향상이 이루어지지 않는 경우 VMware는 전원 관리를 다시 사용하도록 설정하여 전원 소비를 줄일 것을 권장합니다.

 

 

BIOS 맞춤형 설정 구성(고급)

 

상기 스크린샷은 System Profile(시스템 프로필)에서 Custom(맞춤형)을 선택한 경우 개별 매개 변수를 수정할 수 있다는 것을 보여줍니다. 다음은 이러한 설정에 대한 몇 가지 예입니다. 자세한 내용은 서버의 BIOS 설정 매뉴얼을 참조하십시오.

 

ESXi의 호스트 전원 관리 구성


VMware ESXi에는 다양한 호스트 전원 관리 기능이 있습니다. 이러한 기능은 ESXi 호스트가 완전히 활용되지 않을 때 전원을 절감합니다. ESXi가 하드웨어에서 제공하는 전원 관리 기능을 가장 유연하게 사용할 수 있도록 하고 ESXi 내에서 원하는 전원 관리 기능을 선택하는 것이 가장 좋습니다. 이러한 기능은 아래 기술되어 있습니다.


 

esx-01a에 대한 호스트 전원 관리 설정 선택

 

  1. "esx-01a.corp.local"을 선택합니다.
  2. "Configure"(구성)를 선택합니다.
  3. "Hardware"(하드웨어)를 선택합니다(하단까지 스크롤해야 함).
  4. "Power Management"(전원 관리)를 선택합니다.

 

 

전원 관리 정책

 

물리적 호스트에서 Power Management(전원 관리) 옵션은 이와 유사합니다(물리적 호스트의 프로세서에 따라 다를 수 있음).

여기에서 호스트에 제공된 ACPI 상태와 현재 활성 상태인 전원 관리 정책을 볼 수 있습니다. ESXi 5.0, 5.1, 5.5, 6.0 및 ESXi/ESX 4.1에서는 네 가지 전원 관리 정책을 이용할 수 있습니다.

  • High Performance(고성능)
  • Balanced(밸런싱)(기본값)
  • Low Power(저전원)
  • Custom(맞춤형)
  1. 다른 옵션을 표시하려면 "Edit"(편집)를 클릭하십시오.

참고: 이 실습 환경의 특성으로 인해 물리적 서버와 직접 상호 작용하지 않으므로 전원 관리 정책을 변경해도 두드러진 영향은 없습니다. 따라서 다음 섹션에서 각 전원 관리 정책에 대해 설명하지만 실제로 이 설정을 변경하지는 않을 것입니다.

 

 

High Performance(고성능)

 

High Performance(고성능) 전원 정책은 성능을 극대화하고 전원 관리 기능을 사용하지 않습니다. 이는 CPU를 항상 최고의 P-상태로 유지합니다. 이는 깊은 상태(에: 최신 Intel 프로세서의 경우 C3 및 C6)가 아니라 두 개의 상위 C-상태(실행 중 및 중단됨)만 사용합니다. High Performance(고성능)는 5.0 이전의 ESX/ESXi 릴리스에 대한 기본 전원 정책이었습니다.

 

 

Balanced(밸런싱)(기본값)

 

Balanced(밸런싱) 전원 정책은 성능에 전혀 또는 거의 영향을 주지 않으면서 호스트 전원 소비를 줄이도록 고안되었습니다. Balanced(밸런싱) 정책은 프로세서의 P-상태를 활용하는 알고리즘을 사용합니다. 이는 ESXi 5.0 이후 기본 전원 정책입니다.  ESXi 5.5부터는 Balanced(밸런싱) 전원 정책에서 깊은 C-상태(C1보다 깊음)도 사용합니다. 이전에는 CPU가 유휴 상태였을 때 항상 C1이 되었습니다. 이제 ESXi는 다음에 CPU를 다시 시작해야 할 때의 추정치에 따라 적합한 깊은 C-상태를 선택합니다.

 

 

Low Power(저전원)

 

Low Power(저전원) 정책은 성능 저하의 리스크가 있을 때 P-상태 및 C-상태 선택 알고리즘을 더욱 적극적으로 만들어서 Balanced(밸런싱) 정책보다 훨씬 더 많은 전원을 절감하도록 고안되었습니다.

 

 

Custom(맞춤형)

 

Custom(맞춤형) 전원 정책은 Balanced(밸런싱)와 동일하게 시작되지만 개별 매개 변수를 수정할 수 있습니다.

"Cancel"(취소)을 클릭하여 종료합니다.

다음 단계에서는 Custom(맞춤형) 전원 정책을 제어하는 설정에 대해 설명합니다.

 

 

고급 시스템 설정 편집

 

맞춤형 전원 정책 설정을 구성하는 방법은 다음과 같습니다.

  1. System(시스템) 섹션에서 Advanced System Settings(고급 시스템 설정)를 선택합니다.
  2. EDIT...(편집...) 버튼을 클릭합니다.

 

 

고급 시스템 설정 필터링

 

전원 설정에 대한 시스템 설정을 필터링하는 방법은 다음과 같습니다.

  1. Filter(필터) 아이콘 옆에 있는 Filter(필터) 텍스트 상자 안을 클릭하고 Power.를 입력합니다(Power 뒤에 마침표를 추가해야 함).
  2. 첫 번째 매개 변수 Power.ChargeMemoryPct를 클릭합니다.
  3. 설명과 함께 유효한 최소값최대값이 왼쪽 하단에 표시됩니다.
  4. 이 목록을 검토한 후 CANCEL(취소)을 클릭합니다.

사용자 지정할 수 있는 고급 설정은 다음과 같습니다.

  • Power.CStateMaxLatency: 지연 시간이 이 값보다 큰 경우 C-상태를 사용하지 않습니다.
  • Power.CStatePredictionCoef: 유휴 상태가 되는 CPU가 얼마나 오래 유휴 상태로 남아 있을지를 예측하는 ESXi 알고리즘의 매개 변수입니다. 이 값을 변경하는 것은 권장되지 않습니다.
  • Power.CStateResidencyCoef: CPU가 유휴 상태가 될 때 가장 깊은 C-상태를 선택합니다. 이 값을 곱한 지연 시간은 CPU가 얼마나 오래 유휴 상태로 남아 있을지에 대해 호스트가 예측한 값보다 작아야 합니다. 값이 더 크면 ESXi가 깊은 C-상태를 사용하는 데 보수적이 됩니다. 값이 작을수록 공격적이 됩니다.
  • Power.MaxCpuLoad: P-상태를 사용하여 CPU가 실제보다 적은 기간 동안 사용 중일 때만 CPU에서 전원을 절감합니다.
  • Power.MaxFreqPct: 다음에 이용 가능한 P-상태까지 반올림하여 전체 CPU 속도의 지정된 비율보다 빠른 P-상태를 사용하지 않습니다.
  • Power.MinFreqPct: 전체 CPU 속도의 지정된 비율보다 느린 P-상태를 사용하지 않습니다.
  • Power.PerfBias: 성능 에너지 바이어스 힌트입니다(Intel만 해당). Intel 프로세서의 MSR을 Intel 권장값으로 설정합니다. Intel은 High Performance(고성능)의 경우 0, Balanced(밸런싱)의 경우 6, Low Power(저전원)의 경우 15를 권장합니다. 다른 값은 정의되지 않았습니다.
  • Power.TimerHz: ESXi에서 각 CPU가 어느 P-상태에 있어야 하는지를 재평가하는 초당 횟수를 제어합니다.
  • Power.UseCStates: 프로세서가 유휴 상태일 때 깊은 ACPI C-상태(C2 이하)를 사용합니다.
  • Power.UsePStates: 프로세서가 사용 중일 때 ACPI P-상태를 사용하여 전원을 절감합니다.

 

결론


이것으로 모듈 6, CPU 성능 향상 기능: 전원 정책을 마치겠습니다. 을 마치겠습니다. 이 모듈이 유익한 시간이 되었기를 바랍니다. 완료되면 설문조사를 작성해 주십시오. 이제 몇 가지 핵심 사항과 향후 진행 방향에 대해 검토해 보겠습니다.


 

핵심 사항

이제 서버 BIOS 수준에서 뿐만 아니라 ESXi 자체적으로 전원 정책을 변경하는 방법에 대해 파악하셨기를 바랍니다.

전원 관리 정책과 관련된 몇 가지 모범 사례를 요약하자면 다음과 같습니다.

  • 물리적 호스트(서버 BIOS)를 전원 정책으로 OS Control(OS 제어) 모드로 구성합니다. 해당되는 경우 터보 모드인 C-상태(깊은 C-상태 포함)를 사용하도록 설정합니다. 일반적으로 기본값입니다.
  • ESXi 내에서 기본 Balanced(밸런싱) 전원 관리 정책은 대부분의 워크로드에 대해 와트당 최적의 성능을 달성합니다.
  • 최대 성능을 요구하는 애플리케이션의 경우, BIOS 전원 정책 및/또는 ESXi 전원 관리 정책을 각각 Maximum Performance(최대 성능) 및 High Performance(고성능)으로 전환합니다. 여기에는 응답 시간에 대한 엄격한 제약 조건 내에서 실행해야 하는 지연 시간에 민감한 애플리케이션이 포함됩니다. 하지만 이는 일반적으로 미미한 성능 향상만 가져올 뿐이고 모든 잠재적 전원 절감 효과는 없습니다.

애플리케이션과 ESXi 호스트의 활용 수준에 따라 올바른 전원 정책 설정이 성능과 에너지 소비 모두에 상당한 영향을 미칠 수 있습니다. 최신 하드웨어에서는 ESXi가 사용된 하드웨어 플랫폼의 전원 관리 기능을 제어하도록 할 수 있습니다. 사전 정의된 정책을 사용하도록 선택할 수도 있고 직접 맞춤형 정책을 생성할 수도 있습니다.

최근 연구에서는 ESXi가 전원 정책을 제어하도록 하는 것이 가장 효과적인 것으로 나타났습니다.

 

모듈 7 - X-Mem을 사용한 메모리 성능(30분)

소개


 

본 모듈의 목적은 가상화된 환경에서 메모리 성능을 특성화하는 방법에 대해 알아보는 것입니다.  VMware vSphere에는 페이지 공유, 리소스 할당 제어 및 기타 메모리 관리 기술을 통해 이용 가능한 메모리 사용을 극대화하는 정교한 메커니즘이 포함되어 있습니다.

호스트 메모리는 한정된 리소스지만 최적의 성능을 위해 각 가상 머신에 충분한 리소스(특히 메모리와 CPU)를 할당해야 합니다.

메모리 대역폭(처리량)메모리 지연 시간(액세스 시간)을 모두 특성화하는 데 사용할 수 있는 X-Mem이라는 오픈 소스 메모리 벤치마크에 대해 살펴보겠습니다.


X-Mem 소개/X-Mem을 선택해야 하는 이유


이 레슨에서는 X-Mem이 무엇이고 이 실습에서 메모리 성능을 특성화하는 데 X-Mem을 사용하기로 결정한 이유에 대해 설명합니다.


 

X-Mem 소개: 클라우드를 위한 플랫폼 간 확장 가능한 메모리 특성화 툴

GitHub의 X-Mem 페이지에서 발췌한 내용(https://github.com/Microsoft/X-Mem):

X-Mem은 메모리 계층 구조 처리량, 지연 시간, 전원 등을 특성화하기 위한 유연한 오픈 소스 리서치 툴입니다. 이 툴은 Microsoft와 UCLA NanoCAD Lab이 공동으로 개발했습니다. 이 프로젝트는 Microsoft Research에서 2014년 여름에 인턴으로 근무한 Mark Gottscho 박사(e-메일: mgottscho@ucla.edu)가 시작했습니다. X-Mem은 MIT 라이센스에 따라 무료로 릴리스되는 오픈 소스입니다. 이 프로젝트는 현재 개발 중입니다.

 

 

X-Mem을 선택해야 하는 이유/대안 제품군

 

X-Mem이 유일한 메모리 벤치마크는 아닙니다. X-Mem과 STREAM, lmbench, Intel의 mlc 같은 다른 메모리 벤치마크의 특징을 비교했습니다(출처). 다음은 이 둘을 구분하는 몇 가지 주요 이점을 간단하게 요약한 내용입니다.

 

 

연구 논문 및 특성

X-Mem의 동기, 설계 및 구현에 대해 설명하는 리서치 툴 논문과 클라우드 공급업체와 구독자 모두에게 유용한 통찰력을 제공하기 위해 툴을 사용하는 세 가지 시험 고객 사례가 있습니다. 자세한 내용은 다음 링크를 참조하십시오.

인용문:

Mark Gottscho, Sriram Govindan, Bikash Sharma, Mohammed Shoaib 및 Puneet Gupta. X-Mem: 클라우드를 위한 플랫폼 간 확장 가능한 메모리 특성화 툴. 시스템 및 소프트웨어의 성능 분석에 관한 IEEE 국제 심포지엄(IEEE International Symposium on Performance Analysis of Systems and Software, ISPASS) 회의록, 263-273페이지. 스웨덴 웁살라. 2016년 4월 17-19일. DOI: http://dx.doi.org/10.1109/ISPASS.2016.7482101

 

X-Mem 다운로드/설치


이 레슨에서는 X-Mem벤치마크를 다운로드하는 방법에 대해 설명합니다. Windows 및 Linux용으로 사전 구축된 바이너리가 있습니다. 이 실습에서는 Windows 가상 머신 내부의 X-Mem을 시연합니다.


 

X-Mem 다운로드 및 추출

 

X-Mem을 다운로드할 수 있는 여러 방법이 있지만 가장 손쉬운 방법은 http://nanocad-lab.github.io/X-Mem/에서 Windows용으로 사전 컴파일된 바이너리가 있는 Binaries (zip)(바이너리(zip)) 버튼을 클릭하는 것입니다. Linux를 사용하는 경우 또는 소스 파일을 수정하려는 경우 해당 링크를 클릭하십시오.

 

 

런타임 사전 요건

소프트웨어를 올바르게 실행하기 위한 몇 가지 런타임 사전 요건이 있습니다. 이러한 요건은 프로젝트 홈페이지(https://nanocad-lab.github.io/X-Mem)에서 이용 가능한 사전 컴파일된 바이너리에 대한 것입니다. 또한 이러한 요건은 실습 환경을 사용하여 이미 충족되었습니다.

하드웨어:

WINDOWS:

GNU/LINUX:

 

 

설치

Windows에서 X-Mem을 실행하는 데 필요한 파일은 해당 실행 파일인 xmem-win-.exe입니다(GNU/Linux의 경우 xmem-linux-). 앞에서 설명한 사전 설치된 시스템 사전 요건 외의 다른 종속성은 없습니다.

 

X-Mem 실행



 

Performance Lab 모듈 변환기 실행

 

주 콘솔의 바탕 화면에 있는 Performance Lab MS 바로 가기를 두 번 클릭합니다.

 

 

모듈 7 실행

 

Module 7(모듈 7) 아래 Start(시작) 버튼을 클릭합니다.

참고: 원격 데스크톱 창이 표시될 때까지 실습을 진행하지 마십시오.

 

 

원격 데스크톱 위치 변경

 

스크립트는 두 대의 Windows 가상 머신에 대한 원격 데스크톱 연결을 엽니다. 그러나 둘 모두 표시되도록 해야 합니다. 원격 데스크톱 창의 제목 표시줄을 드래그합니다.

  1. perf-worker-01a를 왼쪽에 배치합니다(화면에 표시된 바와 같이).
  2. perf-worker-01b를 오른쪽에 배치합니다(화면에 표시된 바와 같이).
  3. perf-worker-01a4개의 vCPU가 있습니다.
  4. perf-worker-01b에는 1개의 vCPU만 있습니다.
  5. 두 가상 머신 모두에 2GB(2047MB) RAM이 있습니다.

5번을 감안할 때 이러한 두 가상 머신의 메모리 성능이 동일해야 한다고 생각할 수 있습니다.  다음에 나오는 것처럼 X-Mem은 여러 작업자 스레드를 실행해 동시에 여러 CPU를 연습하여 추가 vCPU로 확장성을 높일 수 있습니다.

 

 

X-Mem 명령줄 옵션

명령줄 옵션 목적
-j
벤치마크에서 사용할 작업자 스레드 수입니다.
NOTE: vCPU 수보다 더 클 수 없습니다.
-n
반복할 실행 횟수로, 일관성을 보장하는 데 도움이 됩니다(결과는 변동성이 크지 않아야 함).
-t
처리량 벤치마크 모드입니다(지연 시간 벤치마크 모드에 대한 -l과 다름).
-R
메모리 읽기 기반 패턴을 사용합니다.
-W
메모리 쓰기 기반 패턴을 사용합니다.

다음은 이 실습에서 사용할 몇 가지 명령줄 옵션에 대한 요약입니다. 그러나 X-Mem에는 실행 방법을 사용자 지정할 수 있는 옵션이 더 많이 있습니다.

 

 

X-Mem 명령줄 도움말

 

perf-worker-01b 원격 데스크톱 창에서 다음을 수행합니다.

  1. 명령 프롬프트 작업 표시줄 아이콘을 클릭합니다.
  2. xmem -h(h는 도움말을 나타냄) 명령을 입력하고 Enter 키를 누릅니다.
  3. 창이 크지 않지만 도움말 텍스트가 많이 있으므로 위쪽 화살표 또는 스크롤바를 사용해 다시 위로 스크롤하여 X-Mem의 다양한 옵션을 모두 표시합니다.

보시는 것처럼 X-Mem에는 수많은 옵션이 있습니다. 이 실습에서 활용할 몇 가지 옵션을 살펴보겠습니다.

 

 

perf-worker-01b에서 X-Mem 처리량(2개 작업) 실행(실패)

 

이전 단계에서 perf-worker-01b에 명령 프롬프트 창이 이미 열려 있어야 합니다. 그렇지 않은 경우 작업 표시줄에서 명령 프롬프트 아이콘을 클릭합니다.

몇 가지 명령줄 매개 변수, 즉 메모리 처리량을 테스트하기 위한 -t와 두 개의 작업자 스레드를 실행하기 위한 -j2를 사용하여 X-Mem을 실행해 보겠습니다.

  1. xmem -t -j2를 입력하고 Enter 키를 누릅니다.
  2. 출력이 다음과 같이 표시되어야 합니다.
ERROR: Number of worker threads may not exceed the number of logical CPUs (1)

이는 이 가상 머신에 가상 CPU가 1개만 있으므로 예상됩니다.  

 

 

perf-worker-01a에서 X-Mem 처리량(2개 작업) 실행(통과)

 

이제 perf-worker-01b에서 실패한 것과 정확하게 동일한 X-Mem 명령을 perf-worker-01a에서 실행합니다.

  1. perf-worker-01a 원격 데스크톱 창을 선택합니다.
  2. 작업 표시줄에서 명령 프롬프트 아이콘을 클릭합니다.
  3. xmem -t -j2 명령을 입력하고 Enter 키를 누릅니다.
  4. 이 명령이 이 가상 머신에서 벤치마크를 어떻게 성공적으로 실행하는지 확인합니다.

이 가상 머신에는 4개의 가상 CPU가 있으므로 이 명령은 이 가상 머신에서 성공적으로 실행되었습니다(따라서 -j3 또는 -j4도 사용 가능). 다음으로는 결과에 대해 좀 더 자세히 살펴보겠습니다.

 

 

X-Mem 처리량 결과(2개 작업) 검토

 

명령 프롬프트에서 스크롤바를 사용하여 다시 위로 스크롤하고 결과를 확인합니다.

  1. 첫 번째 벤치마크 처리량 테스트인 Test #1TRead/Write Mode: read가 표시됩니다. -j2를 지정했으므로 2개의 작업자 스레드를 실행한 것으로 출력됩니다.
    이 예에서 결과는 90664.66 MB/s(또는 90.664 GB/s)입니다. Hands-on Lab 환경(많은 다른 워크로드가 실행되는 위치)의 공유 리소스에 따라 성능이 다를 수 있습니다.
  2. 두 번째 벤치마크 처리량 테스트인 Test #2TRead/Write Mode: write가 표시됩니다. -j2를 지정했으므로 2개의 작업자 스레드를 실행한 것으로 출력됩니다.
    이 예에서 결과는 44113.39 MB/s(또는 44.11 GB/s)입니다. Hands-on Lab 환경(많은 다른 워크로드가 실행되는 위치)의 공유 리소스에 따라 성능이 다를 수 있습니다.

두 번째 테스트의 처리량이 첫 번째 테스트의 처리량보다 더 낮은(이 경우 약 절반) 이유는 무엇입니까? 읽기는 쓰기보다 거의 항상 더 많은 비용이 소요됩니다. 이는 메모리/RAM 뿐만 아니라 디스크 스토리지 I/O와 같은 다른 하위 시스템에도 마찬가지입니다.

 

 

perf-worker-01a에서 X-Mem 읽기 처리량(4개 작업) 실행

 

perf-worker-01a에서 X-Mem 명령줄 옵션을 사용자 지정해보겠습니다.

  1. perf-worker-01a 원격 데스크톱 창의 명령 프롬프트에 초점이 맞춰져 있는지 확인합니다.
  2. xmem -t -R -j4 -n5 명령을 입력하고 Enter 키를 누릅니다.
  3. 화면에 표시된 것처럼 *** RESULTS*** 제목 아래 결과가 나열됩니다.

사용된 명령줄이 다르므로 벤치마크가 다르게 실행된 것을 알 수 있습니다. 다음은 각 옵션에 대한 설명입니다.

 

 

X-Mem 처리량 결과(4개 작업) 검토

 

명령 프롬프트에서 스크롤바를 사용하여 다시 위로 스크롤하고 결과를 확인합니다. 이 예에서 결과는 일관적으로 대략 170,000MB/sec(170 GB/sec)입니다.  -j4를 지정했으므로 4개 작업자 스레드를 실행했고, 따라서 2개 작업자 스레드를 실행했을 때보다 메모리 성능이 더 높습니다.  참고: Hands-on Lab 환경의 특성상 결과가 이 예와 다를 수 있습니다.

화면에 표시된 것처럼 멀티스레드 애플리케이션인 경우 vCPU를 추가하면 잠재적으로 가상 머신의 메모리 성능이 향상될 수 있습니다.

 

 

원격 데스크톱 창 닫기

 

  1. perf-worker-01a 원격 데스크톱 창을 닫습니다.
  2. perf-worker-01b 원격 데스크톱 창을 닫습니다.

 

결론 및 정리



 

모듈 7 중지

 

주 콘솔의 모듈 변환기 창에서 Stop(중지)을 클릭합니다.

 

 

핵심 사항

이 실습에서는 X-Mem이 유연한 메모리 벤치마크 툴이라는 사실을 확인했습니다. 이를 사용하면 다음을 수행할 수 있습니다.

호스트 및 가상 머신에서 최적의 메모리 성능을 실현하도록 이 툴을 다운로드하여 사용자 환경에서 실행할 수 있습니다.

 

 

결론

이것으로 모듈 7, X-Mem을 사용한 메모리 성능을 마치겠습니다. 이 모듈이 유익한 시간이 되었기를 바랍니다. 완료되면 설문조사를 작성해 주십시오.

 

모듈 8 - 스토리지 성능 및 문제 해결(30분)

스토리지 성능 문제 해결 소개


vSphere 배포에서 성능 문제의 약 90%는 일반적으로 어떤 방법으로든 스토리지와 관련이 있습니다. 지난 몇 년 동안 스토리지 성능을 개선하기 위해 스토리지 기술에서 상당한 발전이 있었습니다. 다음 사항에 대해 알고 있어야 합니다.

제대로 설계된 환경에서는 스토리지 fabric 기술 간에 성능의 차이가 없습니다. 제대로 설계된 NFS, iSCSI 또는 Fibre Channel 구현은 다른 구현과 거의 동일하게 작동합니다.

상호 연결 기능의 개선에도 불구하고 성능 한도는 여전히 미디어 자체에 영향을 미치고 있습니다. 실제로 GSS(글로벌 지원 서비스 - VMware 지원)에서 확인한 바에 따르면 구성과 관련이 없는 스토리지 성능 사례의 90%가 미디어와 관련이 있습니다. 몇 가지 기억해야 할 사항은 다음과 같습니다.

지정된 모든 디스크에서 총 IOPS 수에 대한 기본 규칙은 다음과 같습니다.

지정된 디스크 수로 달성할 수 있는 IOPS 수는 다음 공식을 통해 알 수 있습니다.

이 테스트에서는 스토리지 성능 저하를 식별하는 몇 가지 방법과 워크로드 밸런싱에 VMware Storage DRS를 사용하여 성능 저하 문제를 해결하는 방법을 시연합니다. 첫 번째 단계는 시연할 수 있는 환경을 준비하는 것입니다.


 

Performance Lab 모듈 변환기 실행

 

주 콘솔의 바탕 화면에 있는 Performance Lab MS 바로 가기를 두 번 클릭합니다.

 

 

모듈 8 실행

 

Module 8(모듈 8) 아래 Start (시작) 버튼을 클릭합니다. 스크립트는 가상 머신을 구성 및 시작하고, IOmeter를 사용하여 스토리지 워크로드를 실행합니다.

스크립트를 완료하는 데 최대 5분이 걸릴 수 있습니다. 스크립트가 실행되는 동안 잠시 시간을 내어 다음 단계를 읽고 스토리지 지연 시간에 대해 파악하십시오.

 

스토리지 I/O 경합



 

디스크 I/O 지연 시간

 

스토리지 성능 문제를 생각할 때 가장 큰 문제는 일반적으로 지연 시간이므로, 스토리지 스택을 살펴보고 스토리지 스택에 있는 계층과 지연 시간이 발생할 수 있는 위치를 파악해야 합니다.

최상위 계층에는 게스트 운영 체제에서 실행 중인 애플리케이션이 있습니다. 이는 지연 시간에 대해 가장 중요하게 생각하는 공간입니다. 애플리케이션에 발생하는 총 지연 시간으로, 여기에는 게스트 OS, VMKernel 가상화 계층 및 물리적 하드웨어를 포함하는 전체 스토리지 스택의 지연 시간이 포함됩니다.

ESXi는 ESXi 가상화 계층 위의 계층이므로 애플리케이션 지연 시간이 표시되지 않습니다.

ESXi에는 esxtop 및 vCenter에서 보고되는 3개의 주요 지연 시간이 표시됩니다.  

최상단은 ESXi가 감지할 수 있는 총 지연 시간인 GAVG 또는 게스트 평균 지연 시간입니다.  

이는 애플리케이션에 발생하는 총 지연 시간을 말하는 것은 아닙니다. 실제로 애플리케이션에 발생하는 GAVG(ESX에 표시되는 총 지연 시간)와 실제 지연 시간을 비교하면 게스트 OS가 스토리지 스택에 추가하는 지연 시간을 확인할 수 있고 이를 통해 게스트 OS가 잘못 구성되어 있는지 또는 성능 문제를 초래하는지 알 수 있습니다. 예를 들어, ESX가 10ms의 GAVG를 보고하지만 게스트 OS의 애플리케이션 또는 Perfmon이 30ms의 스토리지 지연 시간을 보고하는 경우, 이는 20ms의 지연 시간이 게스트 OS 계층에 발생한다는 것을 의미합니다. 따라서 게스트 OS의 스토리지 정보를 기반으로 디버깅해야 합니다.

이제 GAVG가 2개의 주요 구성 요소인 KAVG와 DAVG로 구성됩니다. DAVG는 기본적으로 드라이버 HBA 및 스토리지 어레이의 기기에 사용되는 시간을 말하고 KAVG는 ESXi 커널에 사용되는 시간(및 추가되는 커널에 사용되는 시간)을 말합니다.  

KAVG는 실제로 산출된 측정지표로 ESXi는 KAVG를 계산하지 않습니다. ESXi는 다음 공식을 사용하여 KAVG를 계산합니다.

총 지연 시간 – DAVG = KAVG.

VMKernel은 IO를 처리하는 데 매우 효과적이므로, IO가 실제로 커널 또는 KAVG에서 대기해야 하는 시간이 크지 않아야 하고, 따라서 KAVG는 제대로 구성된/실행 중인 환경에서 0이어야 합니다. KAVG가 0이 아니면 IO가 VMKernel 내부의 커널 대기열에 고립되어 있을 가능성이 있습니다. 따라서 대부분 KAVG는 OAVG 또는 대기열 평균 지연 시간( IO가 스택 아래로 이동할 수 있도록 더 낮은 대기열의 슬롯을 확보하기 위해 대기열에 고립되어 있는 시간)과 동일합니다.

 

 

IOmeter에서 보고한 스토리지 성능 보기

 

스토리지 스크립트가 완료되면 두 개의 IOmeter 창이 표시되어야 하고 두 개의 스토리지 워크로드가 실행 중이어야 합니다.

스토리지 워크로드는 perf-worker-02a와 perf-worker-03a 모두에서 시작됩니다. 워크로드가 안정화되는 데 몇 분이 소요되고 성능 수치는 두 가상 머신에 대해 거의 동일해집니다. 디스크를 테스트하는 이러한 가상 머신은 동일한 데이터스토어를 공유하고 해당 데이터스토어는 포화 상태가 됩니다.

성능은 IOmeter GUI에 다음과 같이 표시됩니다.

지연 시간(Average I/O Response Time(평균 I/O 응답 시간)), 약 6ms.  

낮은 IOPS(Total I/O per Second(초당 총 I/O)), 약 160IOPS

낮은 처리량(Total MBs per Second(초당 총 MB)), 약 2.7MBPS

부인: ESXi 호스트 서버도 가상 머신에도 실행되는 완전히 가상화된 환경에서 이 실습을 실행하므로 물리 디스크 스핀들을 개별 데이터스토어에 할당할 수 없습니다. 따라서 스크린샷의 성능 수치는 실습이 실행 중인 클라우드 환경의 실제 로드에 따라 달라집니다.

 

 

perf-worker-03a 선택

 

  1. "perf-worker-03a"를 선택합니다.

 

 

vCenter에서 스토리지 성능 측정지표 보기

 

  1. "Monitor"(모니터)를 선택합니다.
  2. "Performance"(성능)를 선택합니다.
  3. "Advanced"(고급)를 선택합니다.
  4. "Chart Options"(차트 옵션)를 클릭합니다.

 

 

성능 측정지표 선택

 

  1. "Virtual disk"(가상 디스크)를 선택합니다.
  2. "scsi0:1" 선택합니다.
  3. "Select counters for this chart"(이 차트에 대한 카운터 선택) 아래에서 "None"(없음)을 클릭합니다.
  4. "Write latency"(쓰기 지연 시간) 및 "Write rate"(쓰기 속도)를 선택합니다.
  5. "OK"(확인)를 클릭합니다.

IOmeter가 워크로드를 생성하기 위해 사용하는 디스크는 scsi0:1 또는 게스트 내부의 sdb입니다.

 

 

vCenter에서 스토리지 성능 측정지표 보기

 

perf-worker-02a에 대해 성능 차트 구성을 반복하고 성능이 거의 perf-worker-03a와 동일한지 확인합니다.

지침: 기기 지연 시간이 20ms보다 크면 성능이 애플리케이션에 영향을 줄 수 있습니다.

이 테스트를 위해 프라이빗 데이터스토어를 생성한 방법으로 인해 지연 시간 수치가 매우 낮은 양호한 상태입니다. Scsi0:1은 perf-worker-03a와 동일한 ESXi 호스트에서 실행 중인 perf-worker-04a(DatastoreA)의 RAMdisk를 기반으로 iSCSI 데이터스토어에 위치합니다. 따라서 완전히 가상화된 환경의 지연 시간은 매우 낮습니다.

vSphere는 스토리지 성능을 관리 및 제어하는 데 도움이 되는 여러 가지 스토리지 기능을 제공합니다.

Storage DRS를 구성하여 이 경합 문제를 해결해 보겠습니다.

 

스토리지 클러스터 및 Storage DRS


데이터스토어 클러스터는 공유 리소스 및 공유 관리 인터페이스가 있는 데이터스토어들의 집합체입니다. 클러스터가 호스트의 일부인 것처럼 데이터스토어 클러스터는 데이터스토어의 일루입니다. 데이터스토어 클러스터를 생성할 경우, vSphere Storage DRS를 사용하여 스토리지 리소스를 관리할 수 있습니다.

하나의 데이터스토어 클러스터에 데이터스토어를 추가하면 데이터스토어의 리소스는 데이터스토어 클러스터의 리소스의 일부가 됩니다. 호스트 클러스터와 마찬가지로 데이터스토어 클러스터를 사용하여 스토리지 리소스를 집계하면 데이터베이스 클러스터 수준에서 리소스 할당 정책을 지원할 수 있습니다. 다음 리소스 관리 기능도 데이터스토어 클러스터에 따라 사용 가능합니다.

공간 활용 로드 밸런싱 공간 사용에 대한 임계값을 설정할 수 있습니다. 데이터스토어의 공간 사용이 임계값을 초과하는 경우 Storage DRS가 권장 사항을 생성하거나 Storage vMotion 마이그레이션을 수행하여 데이터스토어 클러스터 전반에서 공간 사용의 균형을 유지합니다.

I/O 지연 시간 로드 밸런싱 병목 현상을 방지하기 위해 I/O 지연 시간 임계값을 설정할 수 있습니다. 데이터스토어의 I/O 지연 시간이 임계값을 초과하는 경우 Storage DRS가 권장 사항을 생성하거나 Storage vMotion 마이그레이션을 수행하여 높은 I/O 로드를 완화합니다. I/O 지연 시간 로드 밸런싱 사용에 관한 권장 사항을 받으려면 스토리지 벤더에 문의하십시오.

반선호도 규칙 가상 머신 디스크에 대한 반선호도 규칙을 생성할 수 있습니다. 예를 들어, 특정 가상 머신의 가상 디스크는 다른 데이터스토어에 있어야 합니다. 기본적으로, 가상 머신에 대한 모든 가상 디스크는 같은 데이터스토어에 배치됩니다.


 

데이터스토어 뷰로 변경

 

  1. 아이콘을 클릭하여 스토리지 뷰로 변경합니다.
  2. vcsa-01a.corp.local 아래에서 RegionA01을 클릭합니다.

 

 

데이터스토어 클러스터 생성

 

  1. ACTIONS(작업)를 클릭합니다.
  2. Storage(스토리지)로 이동합니다.
  3. New Datastore Cluster...(새 데이터스토어 클러스터...)를 클릭합니다

 

 

데이터스토어 이름 지정

 

이 실습에서는 대부분의 기본 설정을 수용합니다.

  1. 데이터스토어 클러스터의 이름을 지정할 수 있지만 기본 이름인 DatastoreCluster로 그대로 둡니다.
  2. NEXT(다음)를 클릭합니다.

 

 

Storage DRS 자동화 지정

 

  1. No Automation (Manual Mode)(자동화 없음(수동 모드))를 선택합니다.
  2. NEXT(다음)를 클릭합니다.

 

 

Storage DRS 런타임 설정 지정

 

  1. 슬라이더를 왼쪽 끝까지 이동하여 Utilized space(사용된 공간) 임계값을 50%로 지정합니다.
  2. NEXT(다음)를 클릭합니다.

HOL은 중첩된 가상 환경이므로 높은 지연 시간을 안정적인 방법으로 시연하는 것이 쉽지 않습니다. 따라서 로드 밸런싱을 시연하기 위해 I/O 지연 시간을 사용하지 않습니다. 스토리지 클러스터 불균형을 8시간마다 확인하는 것이 기본이지면 최소 60분으로 변경할 수 있습니다.

 

 

클러스터 및 호스트 선택

 

  1. RegionA01-COMP01을 선택하여 실습 클러스터를 선택합니다.
  2. NEXT(다음)를 클릭합니다.

 

 

데이터스토어 선택

 

  1. DatastoreADatastoreB를 선택합니다.
  2. NEXT(다음)를 클릭합니다.

 

 

완료 준비

 

FINISH(마침)를 클릭하여 데이터스토어 클러스터를 생성합니다.

 

 

Storage DRS 실행

 

Storage DRS(SDRS)를 마이그레이션할 가상 머신의 이름을 기록합니다.

  1. DatastoreCluster를 선택합니다.
  2. Monitor(모니터) 탭을 선택합니다.
  3. Storage DRS 아래에서 Recommendations(권장 사항)를 선택합니다.
  4. RUN STORAGE DRS NOW(지금 Storage DRS 실행)를 클릭합니다.
  5. APPLY RECOMMENDATIONS(권장 사항 적용)를 클릭합니다.

SDRS 권장 사항은 DatastoreA에서 DatastoreB로 워크로드 중 하나를 이동하는 것입니다. 권장 사항은 용량을 기반으로 만들어집니다. SDRS는 8시간 이상 성능 데이터를 수집한 후에만 성능을 기반으로 스토리지를 이동합니다. 워크로드가 최근에 시작되었으므로 SDRS는 추가 데이터가 수집될 때까지 성능을 기반으로 워크로드의 균형을 유지하라는 권장하지 않습니다.

 

 

Storage DRS 구성

 

  1. Configure(구성)를 선택합니다.
  2. Storage DRS를 선택합니다.
  3. 드롭다운 화살표를 선택하여 구성할 수 있는 다양한 SDRS 설정을 관찰합니다.

이전 제한 사항의 일부를 없애기 위해 다양한 개선 사항이 Storage DRS에 도입되었습니다.

이러한 모든 개선 사항에는 공통적으로 VASA 2.0이 필요합니다. 이를 사용하려면 스토리지 벤더에게 업데이트된 스토리지 제공자가 있어야 합니다.

 

 

마이그레이션된 가상 머신 선택

 

  1. 아이콘을 클릭하여 호스트 및 클러스터 뷰로 돌아갑니다.
  2. Storage DRS를 사용하여 마이그레이션된 가상 머신을 선택합니다. 이 예에서는 perf-worker-03a입니다.

 

 

처리량 증가 및 지연 시간 감소

 

  1. "Monitor"(모니터) 탭을 선택합니다.
  2. "Performance"(성능)를 선택합니다.
  3. "Advanced"(고급)를 선택합니다.

이제 이 모듈의 앞부분에서 생성한 성능 차트가 표시되어야 합니다.

가상 머신이 동일한 데이터스토어를 공유했을 때보다 처리량이 얼마나 증가했고 지연 시간이 얼마나 감소했는지(녹색 화살표) 확인합니다.

 

 

IOmeter GUI로 돌아가서 성능 미리보기

 

Iometer 작업자로 돌아가서 성능 증가 및 지연 시간 감소에 대해 보고한 내용을 확인합니다.

Iometer에 이러한 높은 수치가 표시되려면 약 10분 정도 소요됩니다. 이는 이 실습에서 스토리지 성능이 제한적으로 조절되는 방식 때문입니다. 다음 방법으로 직접 시도해 볼 수 있습니다.

  1. "Stop 기호"를 클릭하고 약 30초 동안 기다립니다.
  2. "녹색 플래그"(테스트 시작)를 클릭하여 두 작업자를 다시 시작합니다(그림의 화살표 참조).

워크로드가 급증했다가 몇 분 이내에 더 높은 성능 수준에서 안정화되어야 합니다.

 

 

Iometer 워크로드 중지

 

워크로드를 중지합니다.

  1. Iometer GUI에서 "Stop 기호" 버튼을 누릅니다.
  2. "X"를 눌러 GUI를 종료합니다.
  3. Iometer GUI에서 "Stop 기호" 버튼을 누릅니다.
  4. "X"를 눌러 GUI를 종료합니다.

 

결론 및 정리


이것으로 모듈 8, 스토리지 성능 및 문제 해결을 마치겠습니다. 이 모듈이 유익한 시간이 되었기를 바랍니다. 완료되면 설문조사를 작성해 주십시오.


 

모듈 8 중지

 

주 콘솔의 모듈 변환기 창에서 Module 8(모듈 8) 아래 Stop(중지)을 클릭합니다.

 

 

핵심 사항

이 실습에서는 스토리지의 규모를 공간 및 성능과 관련하여 올바르게 산정하는 것이 왜 중요한지 살펴봤습니다. 또한 두 개의 스토리지 집약적인 순차적 워크로드가 동일한 스핀들을 공유할 때 성능이 크게 영향을 받을 수도 있다는 것을 확인했습니다. 가능하면 워크로드를 분리된 상태로 유지합니다. 즉, 순차적 워크로드(다른 스핀들/LUN 사용)를 무작위 워크로드와 분리합니다.

일반적으로 스토리지 지연 시간을 가능하면 20ms 이하로 유지하고 빈번하게 발생하는 60ms 이상으로의 지연 시간 급증을 모니터링하는 것을 목적으로 합니다. 지연 시간이 급증하면 성능에 문제를 야기할 수 있으므로 추가 조사가 필요합니다.

지침: vSphere 관점에서 볼 때, 대부분의 애플리케이션에 대해 하나의 대규모 데이터스토어를 사용하는 것과 여러 개의 소규모 데이터스토어를 사용하는 것이 성능에 달리 영향을 미치지 않습니다. 하지만 여러 개의 LUN을 사용하는 것보다 하나의 대규모 LUN을 사용하는 것이 스토리지 어레이에 의존되며 대부분의 스토리지 어레이는 단일 LUN 구성보다 멀티 LUN 구성에서 더 성능이 우수합니다.

지침: 가상화된 환경에 대한 스토리지의 규모를 산정하고 조절하려면 스토리지 벤더의 모범 사례와 규모 산정 지침을 따르십시오.

 

모듈 9 - 네트워크 성능, 기본 개념 및 문제 해결(15분)

네트워크 성능 소개


Wikipedia에서 정의한 대로 네트워크 성능은 고객의 관점에서 통신 제품의 서비스 품질을 말합니다.

다음 측정지표가 중요하게 고려됩니다.

다음 모듈에서는 사용자 환경에서 유사한 문제가 발생할 경우 이를 해결할 수 있도록 몇 가지 네트워크 관련 문제를 모니터링하고 해결하는 방법을 살펴볼 것입니다.


 

Performance Lab 모듈 변환기 실행

 

이 모듈을 시작하려면 주 콘솔의 바탕 화면에 있는 Performance Lab MS 바로 가기를 두 번 클릭합니다.

 

 

모듈 9 시작

 

Module 9(모듈 9) 아래 Start(시작) 버튼을 클릭합니다.

 

 

Google Chrome 열기

 

작업 표시줄에 있는 Google Chrome 아이콘을 클릭합니다.

 

 

vSphere Client 로그인

 

Login(로그인) 버튼을 클릭하여 vSphere Client를 엽니다.

 

성능 차트를 사용하여 네트워크 활동 모니터링


네트워크 경합은 여러 가상 머신이 동일한 "파이프"(가상 네트워크 및/또는 물리적 네트워크)에 액세스할 때와 이용 가능한 대역폭이 충분하지 않을 때 발생할 수 있습니다.

실습 환경에서는 네트워크를 포화시키는 것이 가능하지 않습니다(지체 없이 실습을 이용하기를 권장). 따라서 이 모듈에서는 네트워크 로드를 생성하는 데 주력하고 사용자 환경에서 네트워크 문제가 의심되는 경우 네트워크 성능 차트에서 살펴봐야 할 부분에 대해 알아볼 것입니다.

참고: 실습 환경의 변동성으로 인해 화면의 결과와 다를 수 있습니다.


 

perf-worker-02a 네트워크 성능 차트

 

  1. ESXi 호스트 esx-01a.corp.local에 있는 perf-worker-02a 가상 머신을 선택합니다.
  2. Monitor(모니터) 탭을 선택합니다.
  3. 목록에서 Performance(성능)를 선택한 다음 Advanced (고급) 옵션을 선택합니다.
  4. 팝업 차트 아이콘을 클릭합니다.

 

 

차트 옵션 선택

 

Chart Options(차트 옵션)를 클릭하여 차트로 기록할 네트워크 측정지표를 선택합니다.

 

  1. Network(네트워크) 하위 시스템을 선택합니다.
  2. Packets received(수신된 패킷), Packets transmitted (전송된 패킷) 및 Usage(사용량)(화면에 없음) 카운터를 선택합니다.
  3. perf-worker-02a만 선택되었는지 확인합니다(다른 객체 선택 취소).
  4. OK(확인)를 클릭합니다.

 

 

차트 출력 모니터링

 

소요된 시간에 따라 네트워크 로드 테스트가 완료되었을 수 있습니다. 실행된 네트워크 로드와 완료된 네트워크 로드를 계속 볼 수 있어야 합니다.

  1. 여기에서는 perf-worker-02a의 네트워크 로드를 그래픽 표현으로 볼 수 있습니다.
  2. 여기에서는 이전 단계에서 선택한 카운터(Packets received(수신된 패킷), Packets transmitted(전송된 패킷), KBps 단위의 Usage(사용량))와 그 실시간 값을 볼 수 있습니다.

다음은 살펴봐야 하는 사항에 대한 몇 가지 조언입니다.

이제 호스트로 이동하여 가상 머신 또는 호스트 수준 문제인지 알아보겠습니다.

 

 

esx-01a.corp.local 호스트 선택

 

  1. esx-01a.corp.local 호스트를 선택합니다.
  2. Monitor(모니터) 탭을 선택합니다.
  3. 목록에서 Performance (성능)를 선택한 다음 Advanced(고급)를 선택합니다.
  4. 팝업 차트 아이콘을 선택합니다.

 

 

차트 옵션 선택

 

Chart Options(차트 옵션)를 클릭하여 차트로 기록할 네트워크 측정지표를 선택합니다.

 

 

차트 출력 모니터링

 

  1. 호스트에 손실된 패킷이 있는지 확인합니다.

이 예에서는 호스트 수준에서 손실된 패킷이 없습니다. 이는 호스트의 NIC에 병목 현상이 없음을 나타냅니다.
참고: 실습 환경의 조건에 따라 다른 결과가 나타날 수 있습니다.

 

결론 및 정리


이것으로 모듈 9, 네트워크 성능, 기본 개념 및 문제 해결을 마치겠습니다. 이 모듈이 유익한 시간이 되었기를 바랍니다. 완료되면 설문조사를 작성해 주십시오.


 

모듈 9 중지

 

주 콘솔에서 Module 9(모듈 9) 아래 Stop(중지) 버튼을 클릭합니다.

 

 

핵심 사항

이 실습에서는 vSphere Client의 기본 성능 차트를 사용하여 가상 머신 수준과 ESXi 호스트 수준 모두에서 네트워킹 문제를 진단하는 방법을 살펴봤습니다.

네트워킹 성능 문제를 해결하는 다른 방법도 있습니다.

네트워크 성능 문제 해결에 대해 자세히 알아보려면 다음 VMware 기술 자료 문서를 참조하십시오.
"Troubleshooting network performance issues in a vSphere environment"(vSphere 환경의 네트워크 성능 문제 해결): http://kb.vmware.com/kb/1004087  

 

모듈 10 - 고급 성능 향상 기능: 지연 시간 민감도 설정(45분)

지연 시간 민감도 소개


'지연 시간 민감도' 기능은 가상화에 의해 발생할 수 있는 지연 시간의 주요 원인을 해결하기 위해 개발되었습니다. 아 기능은 가상 머신당 기준으로 응답 시간 및 지터를 프로그래밍 방식으로 줄여서 민감한 워크로드가 물리적 리소스에만 액세스하고 세분화된 수준으로 리소스 경합을 방지할 수 있도록 고안되었습니다. 이는 가상화 계층을 우회하여 오버헤드를 줄이는 방식으로 수행됩니다. 지연 시간 민감도를 SR-IOV(Single Root I/O Virtualization)와 같은 패스스루 메커니즘과 함께 사용할 때 더 우수한 성능을 실현할 수 있습니다.

이 기능은 가상 머신당 기준으로 설정되므로 정상 가상 머신과 지연 시간에 민감한 워크로드 가상 머신을 혼합하여 단일 vSphere 호스트에서 실행할 수 있습니다.


 

사용해야 하는 대상

지연 시간 민감도 기능은 특수 사용 사례, 즉 매우 낮은 지연 시간을 요구하는 워크로드에만 사용할 수 있습니다. 이 기능을 사용하도록 설정하기 전에 워크로드가 이 기능을 통해 이익을 얻을 수 있는지 판단하는 것이 매우 중요합니다. 지연 시간 민감도는 리소스 공유가 적기 때문에 증가한 CPU 및 메모리 비용과 증가한 전원 소비를 절충하여 매우 낮은 네트워크 지연 시간 성능을 제공합니다.

"지연 시간이 높은 민감한 애플리케이션"이란 수십 마이크로초의 네트워크 지연 시간매우 낮은 지터를 요구하는 애플리케이션을 의미합니다. 지연 시간에 매우 민감한 주식 시장 거래 애플리케이션을 예로 들 수 있습니다. 지연 시간이 발생하면 수백만 달러의 이익을 볼 수도 있고 손실을 볼 수도 있습니다.

VMware의 지연 시간 민감도 기능을 사용하기로 결정하기 전에 필요한 비용-이익 분석을 수행하여 이 기능이 필요한지 알아보십시오. 명확한 목적 없이 이 기능을 사용하기로 선택하면 호스트 CPU 사용률 증가, 전원 소비 증가로 이어질 수 있고 호스트에서 실행 중인 다른 가상 머신의 성능에 불필요한 영향을 미칠 수 있습니다.

 

 

사용하지 않아야 하는 대상

지연 시간 민감도를 사용할지 여부를 선택할 때 사용할 수 있기 때문에 반드시 사용해야 하는 것은 아니라는 점을 염두에 두어야 합니다. 지연 시간 민감도 기능은 네트워크 지연 시간을 줄여줍니다. 지연 시간 민감도는 특히 지연 시간이 네트워크 이외에 스토리지나 지원 시간의 다른 원인에 의해 영향을 받는 경우 애플리케이션 지연 시간을 줄여주지 않습니다.

지연 시간 민감도 기능은 CPU가 언더커밋된 환경에서 사용하도록 설정해야 합니다. 지연 시간 민감도가 High(높음)로 설정된 가상 머신에는 호스트의 물리적 CPU에 독점적으로 액세스할 수 있는 권한이 부여됩니다. 다시 말해 지연 시간에 민감한 가상 머신은 더 이상 인접 가상 머신과 CPU를 공유할 수 없습니다.

일반적으로, 지연 시간 민감도 기능을 사용하는 가상 머신은 지연 시간에 민감한 가상 머신이 NUMA 노드만 차지하도록 vCPU 수가 호스트의 소켓당 코어 수보다 적어야 합니다.

지연 시간 민감도 기능이 사용자 환경과 관련이 없는 경우 다른 모듈을 선택하십시오.

 

 

CPU 액세스에 대한 변경 사항

vCenter에서 지연 시간 민감도가 'High'(높음)로 설정된 가상 머신에는 실행해야 하는 물리적 코어에 독점적으로 액세스할 수 있는 권한이 부여됩니다. 이를 독점적 선호도라고 합니다. 이러한 코어는 지연 시간에 민감한 가상 머신에만 예약되므로 가상 머신에 대한 CPU 접근성이 형상되고 L1 및 L2 캐시 오염이 감소하여 다른 가상 머신을 동일한 코어에 멀티플렉싱할 수 있습니다. 가상 머신의 전원이 켜지면 각 vCPU가 특정 물리적 CPU에 할당되고 해당 CPU에 그대로 남게 됩니다.

지연 시간에 민감한 가상 머신의 vCPU가 유효 상태이면 ESXi도 물리적 CPU를 활성 상태로 유지하기 위해 정지 동작을 변경합니다. 이렇게 하면 가상 머신이 다시 활성 상태가 되었을 때 다시 시작 지연 시간이 감소합니다.

 

 

가상 NIC 인터럽트 병합에 대한 변경 사항

가상 NIC(vNIC)는 VMkernel과 게스트 운영 체제 간에 네트워크 패킷을 교환하는 가상 기기입니다. 교환은 일반적으로 게스트 OS에 대한 인터럽트 또는 VMkernel로의 게스트 OS 호출에 의해 트리거되며, 두 작업 모두 비용이 많이 듭니다. vSphere에서 기본적으로 사용 설정되어 있는 가상 NIC 인터럽트 병합은 인터럽트를 트리거하기 전에 일정 시간 동안 패킷을 보류하여(패킷의 통합 또는 "병합") CPU 오버헤드를 줄이려고 시도합니다. 이로 인해 하이퍼바이저가 가상 머신을 더 자주 다시 시작합니다.

'High'(높음) 지연 시간 민감도를 사용 설정하면 가상 NIC 병합이 해제되므로 패킷이 송수신되는 시점과 CPU가 패킷을 처리하기 위해 중단되는 시점 사이에 지연 시간이 감소합니다.   일반적으로 병합은 처리량이 높을 때 바람직한 방법이지만(CPU가 자주 중단되지 않도록 하기 위해), 네트워크 지연 시간 및 지터를 발생시킬 수 있습니다.

병합을 해제하면 지연 시간은 감소할 수 있지만 CPU 사용률이 증가하고 그에 따라 전원 사용도 증가할 수 있습니다. 따라서 이 옵션은 패킷 속도가 낮고 CPU 여유 공간이 충분한 환경에서만 사용해야 합니다.

직접 사용해 볼 준비가 되었습니까? 이 실습의 Hands-on Lab 부분을 시작하겠습니다.

 

 

바탕 화면 오른쪽 하단에서 실습 상태 확인

 

시작 절차가 모두 완료되어 실습을 시작할 준비가 되었는지 확인합니다. "Ready"(준비) 상태가 아니면 몇 분 더 기다려야 합니다. 5분 후에도 "Ready"(준비) 상태로 바뀌지 않으면 도움을 요청하십시오.

 

 

Performance Lab 모듈 변환기 실행

 

주 콘솔의 바탕 화면에 있는 Performance Lab MS 바로 가기를 두 번 클릭합니다.

 

 

모듈 10 시작

 

Module 10(모듈 10) 아래 Start(시작) 버튼을 클릭합니다.

 

 

가상 머신 통계 수집기: CPU 사용이 많은 워크로드 시작

 

몇 분 후에 스크립트가 완료되면 “VM Stats Collector”(가상 머신 통계 수집기) 애플리케이션이 가동되는 것을 볼 수 있습니다. 1분 이내에 각 유틸리티가 스크립트가 perf-worker-05a 가상 머신과 perf-worker-06a 가상 머신에서 CPU 사용이 많은 애플리케이션을 시작하고 이 CPU 사용이 많은 워크로드의 벤치마크 결과를 수집합니다. perf-worker-05a 가상 머신과 perf-worker-06a 가상 머신은 호스트에서 높은 CPU 수요를 생성하므로 지연 시간 민감도 기능을 시연하는 데 도움이 됩니다.

중요 참고 사항: 실험실 환경의 로드 변경으로 인해 실제 값은 스크린샷에 표시된 값과 다를 수 있습니다.

 

 

Chrome 열기

 

작업 표시줄에서 Chrome 아이콘을 클릭합니다.

 

 

vCenter 로그인

 

자격 증명이 미리 입력되어 있으므로 Login(로그인) 버튼을 클릭합니다.

 

 

호스트 및 클러스터 선택

 

 

지연 시간 민감도 설정이 성능에 미치는 영향


이 섹션에서는 지연 시간 민감도 설정이 네트워크 지연 시간에 미치는 영향을 살펴볼 것입니다.


 

ESX 호스트 선택

 

실습이 실행되는 환경은 다른 클라우드를 사용하므로 지속적이지 않습니다. 따라서 중첩된 ESX 호스트에서 특정 CPU 주파수(GHz)를 확인하십시오.

  1. vSphere Client의 호스트 목록에서 esx-02a.corp.local을 선택합니다.
  2. Summary(요약) 탭을 선택했는지 확인합니다.
  3. Processor(프로세서) 속도를 기록합니다(이 경우 2.80GHz).

향후 단계에서 이를 참조해야 합니다.

 

 

perf-worker-04a 편집

 

perf-worker-04a 가상 머신을 사용하여 지연 시간 민감도 기능을 시연할 것입니다. 'High'(높음) 지연 시간 민감도 설정이 네트워크 지연 시간에 어떤 영향을 미치는지 확인하기 위해 지연 시간 민감도가 'Normal'(보통)로 설정된 perf-worker-04a와 지연 시간 민감도가 'High'(높음)로 설정된 동일한 가상 머신 간의 네트워크 성능을 비교할 것입니다.

지연 시간 민감도 기능이 'High'(높음)로 설정되면 두 가지 가상 머신 리소스 요구 사항이 있습니다. 최적의 성능을 위해 100% 메모리 예약 및 100% CPU 예약이 필요합니다.

공정한 비교를 위해 지연 시간 민감도 설정이 'Normal'(보통)인 가상 머신과 지연 시간 민감도 설정이 'High'(높음)인 가상 머신 모두 리소스 예약을 동일하므로 유일한 차이점은 'High'(높음) 지연 시간 민감도 설정입니다.

먼저 지연 시간 민감도가 "Normal"(보통)로 설정된 perf-worker-04a 가상 머신에 대한 리소스 할당을 생성합니다.

  1. perf-worker-04a를 선택합니다. 이 가상 머신은 esx-02a.corp.local에 있습니다.
  2. Actions(작업)를 클릭합니다.
  3. Edit Settings(설정 편집)를 선택합니다.

 

 

최대값으로 CPU 예약 설정

 

  1. CPU를 확장합니다.
  2. 이전 단계에서 기록해 둔 CPU 속도에 따라 Reservation(예약) 값을 나열된 Maximum(최대값)에 가깝지만 이보다 낮은 값으로 설정합니다.
    예를 들어, CPU 속도가 2.80GHz이면 이 속도를 2750MHz로 설정합니다. 가상 머신을 시작할 수 있으려면 정격 속도보다 약간 낮아야 합니다.

이렇게 하면 가상 머신에 100%에 가까운 CPU 예약이 설정됩니다. 가상 머신의 지연 시간 민감도 설정이 'High'(높음)일 때 이 CPU 예약은 독점적 선호도를 지원하므로 1개의 물리적 CPU가 지연 시간 민감도 설정이 'High'(높음)인 가상 머신 vCPU에만 사용하도록 예약됩니다.

일반적으로 Maximum(최대값) 예약을 선택해야 하지만, 완전히 가상화된 환경에서는 CPU 속도에 잘못된 값이 나열될 수 있습니다. 따라서 기본 하드웨어에 따라 수동으로 설정합니다.

 

 

메모리 예약 설정

 

Edit Settings(설정 편집) 페이지에서 다음을 수행합니다.

  1. CPU를 클릭하여 CPU 뷰를 축소합니다.
  2. Memory(메모리)를 클릭하여 메모리 뷰를 확장합니다.
  3. Reserve all guest memory (All locked)(모든 게스트 메모리 예약(모두 잠김)) 확인란을 선택합니다.

이렇게 하면 가상 머신에 100% 메모리 예약이 설정됩니다.

이제 지연 시간 민감도 설정이 'Normal'(보통)인 가상 머신에서 네트워크 성능을 테스트해 보겠습니다. 나중에 가상 머신의 지연 시간 민감도를 'High'(높음)로 변경하면 100% 메모리 예약 덕분에 가상 머신에서 필요로 하는 모든 메모리가 가상 머신을 실행하는 프로세스 가까이 위치하게 됩니다. 가상 머신의 지연 시간 민감도 설정이 'High'(높음)이고 메모리 예약이 100%가 아닌 경우 전원이 켜지지 않습니다.

 

 

지연 시간 민감도가 'Normal'(보통)인지 확인

 

Edit Settings(설정 편집) 페이지에서 다음을 수행합니다.

  1. VM Options(가상 머신 옵션) 탭을 클릭합니다.
  2. 스크롤 막대를 사용하여 Advanced(고급)가 표시될 때까지 아래로 스크롤합니다.
  3. Advanced(고급)를 클릭하여 이 섹션을 확장합니다.
  4. 스크롤 막대를 사용하여 Latency Sensitivity(지연 시간 민감도)가 표시될 때까지 아래로 스크롤합니다.
  5. 지연 시간 민감도가 Normal(보통)인지 확인합니다.
  6. OK(확인)를 클릭합니다.

 

 

perf-worker-04a 전원 켜기

 

  1. perf-worker-04a를 선택합니다.
  2. Actions(작업)를 선택합니다.
  3. Power(전원) 및 Power On(전원 켜기)을 선택합니다.

 

 

esx-02a 호스트 CPU 사용량 모니터링

 

  1. esx-02a.corp.local을 선택합니다.
  2. Monitor(모니터)를 선택합니다.
  3. Performance(성능)를 선택한 다음 Advanced (고급)를 선택합니다.
  4. 팝업 차트를 클릭합니다(화면 해상도가 너무 낮아서 범례를 읽을 수 없으므로).

 

  1. esx-02a CPU 사용량100% 또는 그에 근접한 것을 알 수 있습니다. 이는 모든 가상 머신이 호스트에서 최대 CPU를 소비하고 있음을 나타냅니다.

지연 시간에 민감한 가상 머신이 있는 환경은 일반적으로 CPU가 언더커밋된 상태여야 하지만, CPU에 대한 수요를 생성하면 지연 시간 민감도가 'Normal'(보통)인 네트워크 성능과 지연 시간 민감도가 'High'(높음)인 네트워크 성능 간의 차이를 볼 수 있습니다.

perf-worker-03a 가상 머신이 네트워크 성능 테스트 대상으로 사용됩니다.

 

 

리소스 할당 모니터링

 

  1. perf-worker-04a를 선택합니다.
  2. Monitor(모니터)를 선택합니다.
  3. Utilization(사용률)을 선택합니다.

지연 시간 민감도 설정이 'Normal'(보통)인 가상 머신에 대한 리소스 할당에는 총 CPU 및 메모리 예약의 일부만 활성인 것으로 표시됩니다. 가상 머신이 부팅 중인 경우 화면의 값과 다를 수 있습니다.

 

 

PuTTY 창 열기

 

작업 표시줄에서 PuTTY 아이콘을 클릭합니다.

 

 

SSH를 통해 perf-worker-04a에 연결

 

  1. perf-worker-04a를 선택합니다.
  2. Open(열기)을 클릭합니다.

 

 

지연 시간 민감도 설정이 'Normal'(보통)인 가상 머신에서 네트워크 지연 시간 테스트

 

명령줄에 다음을 입력합니다.

ping -f -w 1 192.168.100.153 

Enter 키를 누릅니다.

명령이 완료될 때까지 기다렸다가 이 명령을 총 3회 실행합니다. 두 번째와 세 번째 실행할 때 위쪽 화살표를 눌러 마지막에 입력한 명령을 검색할 수 있습니다.

Ping은 매우 간단한 네트워크 워크로드로, 네트워크 패킷이 대상 가상 머신에 전송되고 가상 머신에서 다시 반송되는 왕복 시간(RTT)을 측정합니다. esx-02a.corp.local에 위치하는 perf-worker-04a 가상 머신은 esx-01a.corp.local에 위치하는 perf-worker-03a을 IP 주소 192.168.100.153으로 ping합니다. 1초 동안 perf-worker-04a가 연속해서 ping 요청을 보냅니다. Ping은 요청이 커널에서 처리되고 운영 체제의 애플리케이션 계층에 액세스하지 않아도 되므로 낮은 수준의 이상적인 네트워크 테스트입니다.

지연 시간 민감도 설정이 'Normal'(보통)인 가상 머신에서 네트워크 지연 시간 및 처리량 테스트를 완료했습니다. 나중에 참조할 수 있도록 이 PuTTY 창을 닫지 마십시오. 이제 가상 머신의 지연 시간 민감도 설정을 'high'(높음)로 변경해 보겠습니다.

 

 

perf-worker-04a 가상 머신 종료

 

가상 머신에 지연 시간 민감도 기능을 사용 설정하려면 먼저 가상 머신의 전원을 꺼야 합니다. 가상 머신의 전원이 켜진 상태에서도 이 설정을 변경할 수는 있지만 가상 머신의 전원을 껐다가 다시 켤 때까지 완전히 적용되지 않습니다.

  1. perf-worker-04a를 선택합니다.
  2. Actions(작업)를 선택합니다.
  3. Power(전원)를 클릭한 다음 Shut Down Guest OS (게스트 OS 종료)를 클릭합니다.

 

 

게스트 종료 확인

 

Yes(예)를 클릭합니다.

perf-worker-04a가 종료될 때까지 기다립니다.

 

 

perf-worker-04a 설정 편집

 

perf-worker-04a 가상 머신을 사용하여 지연 시간 민감도 기능을 시연할 것입니다. 'High' 지연 시간 민감도 설정이 네트워크 지연 시간에 어떤 영향을 미치는지 확인하기 위해 이 설정이 Normal(보통)로 설정된 상태와 High로 설정된 상태에서 네트워크 성능을 비교할 것입니다.

지연 시간 민감도 기능이 'High'(높음)로 설정되면 두 가지 가상 머신 리소스 요구 사항이 있습니다. 최적의 성능을 위해 100% 메모리 예약 및 100% CPU 예약이 필요합니다.

공정한 비교를 위해 지연 시간 민감도 설정이 'Normal'(보통)인 가상 머신과 지연 시간 민감도 설정이 'High'(높음)인 가상 머신 모두 리소스 예약을 동일하므로 유일한 차이점은 'High'(높음) 지연 시간 민감도 설정입니다.

먼저 지연 시간 민감도가 "Normal"(보통)(기본 설정)로 설정된 perf-worker-04a 가상 머신에 대한 리소스 할당을 생성합니다.

  1. perf-worker-04a를 클릭합니다.
  2. Actions(작업)를 클릭합니다.
  3. Edit Settings...(설정 편집...)를 클릭합니다.

 

 

지연 시간 민감도를 'High'(높음)로 설정

 

  1. VM Options(가상 머신 옵션)를 선택합니다.
  2. 아래로 스크롤합니다.
  3. Advanced(고급)를 확장합니다.
  4. 아래로 스크롤합니다.
  5. High(높음)를 선택합니다.
  6. OK(확인)를 클릭합니다.

 

 

perf-worker-04a 전원 켜기

 

  1. perf-worker-04a를 선택합니다.
  2. Actions(작업)를 선택합니다.
  3. Power(전원) 및 Power On(전원 켜기)을 선택합니다.

 

 

리소스 할당 모니터링

 

  1. "Monitor"(모니터) 탭을 선택합니다.
  2. "Utilization"(사용률)을 선택합니다.

이 이미지의 상단에는 지연 시간 민감도 설정이 'High'(높음)인 가상 머신이 유휴 상태인 경우에도 CPU 및 프라이빗 메모리가 100% 활성인 것을 알 수 있습니다. 이를 앞에서 살펴본 지연 시간 민감도 설정이 'Normal'(보통)인 가상 머신의 리소스 할당과 비교해 보십시오. 총 CPU 및 메모리 예약의 일부만 활성인 것으로 표시됩니다. 활성 CPU 및 메모리가 증가한 이유는 지연 시간 민감도를 'High'(높음)로 설정했기 때문입니다.

'High'(높음) 지연 시간 민감도가 100% CPU 예약으로 설정된 이 환경에서는 차이점을 볼 수 없지만 호스트 CPU는 가상 머신의 vCPU를 호스팅하는 물리적 코어의 100% 사용률을 보여줄 것입니다. 이는 실습 환경에서 독점적 선호도의 일반적인 결과로 가상 머신이 유휴 상태일 때도 발생합니다. 많은 Intel 프로세서에서 vCPU를 호스팅하는 물리적 CPU는 vCPU가 유휴 상태일 때 유휴 상태이지만, 다른 vCPU에서는 계속 이용할 수 없을 것입니다.

 

 

가상 머신 통계 수집기 모니터링

 

perf-worker-04a에 대한 지연 시간 민감도를 'High'(높음)로 설정하기 전에는 CPU 작업자의 벤치마크 점수가 동일했습니다. 현재는 한 CPU 작업자의 점수가 더 낮습니다. 위의 예에서 볼 수 있듯이 perf-worker-06a의 점수가 낮습니다. 실습에서는 perf-worker-05a 또는 perf-worker-06a의 점수가 낮은 것으로 나타날 수 있습니다. 이는 perf-worker-04a가 perf-worker-06a의 CPU 주기 액세스에 영향을 미쳐서 CPU 벤치마크 점수가 낮아진 것입니다.

이제 지연 시간 민감도 설정이 'High'(높음)인 가상 머신에서 네트워크 지연 시간을 테스트해 보겠습니다.

 

 

PuTTY 창 열기

 

작업 표시줄에서 PuTTY 아이콘을 클릭합니다.

 

 

SSH를 통해 perf-worker-04a에 연결

 

  1. perf-worker-04a를 선택합니다.
  2. Open(열기)을 클릭합니다.

 

 

지연 시간 민감도 설정이 'High'(높은)인 가상 머신에서 네트워크 지연 시간 테스트

 

명령줄에서 다음 명령을 실행합니다.

ping -f -w 1 192.168.100.153

앞에서 한 것과 마찬가지로 명령이 완료될 때까지 기다렸다가 이 명령을 총 3회 실행합니다.

우선 지연 시간 민감도 설정을 다시 기본값으로 설정한 후에 결과를 살펴보겠습니다.

 

 

네트워크 지연 시간 테스트 비교

 

작업 표시줄에서 PuTTY 아이콘을 클릭하여 두 PuTTY 창을 앞으로 가져온 후 지연 시간 민감도 설정이 Nomal(보통)인 가상 머신의 창을 상단에 표시하고 지연 시간 민감도 설정이 High(높음)인 가상 머신의 창을 하단에 표시합니다.

힌트: 두 창의 하단에 타임스탬프가 있어야 합니다.

루트의 브로드캐스트 메시지(타임스탬프): 가장 오래된 타임스탬프가 보통 지연 시간 민감도 가상 머신입니다. 이 창을 상단에 배치하고 다른 창을 하단에 배치하십시오.

이제 성능 결과를 자세히 살펴보겠습니다.

중요 참고 사항: 실험실 환경의 로드 변경으로 인해 실제 값은 여기에 표시된 값과 다를 수 있습니다.

완료된 ping 테스트는 1초 내에 가능한 많은 ping 요청을 원격 가상 머신에 전송합니다("연속 ping"). 한 ping 요청이 반환되면 바로 다른 요청이 전송됩니다. ping 명령은 테스트당 네 개의 통계를 출력합니다.

이 가운데 최소 지연 시간과 최대 지연 시간에 가장 관심이 있습니다.

'eyeballing'에서 지연 시간 민감도가 'Normal'(보통)로 설정된 가상 머신과 지연 시간 민감도가 'High'(높음)로 설정된 가상 머신 간의 숫자 차이를 통해 차이를 확인할 수 있습니다. 녹색 괄호 안의 숫자에서 지연 시간 민감도가 'High'(높음)로 설정된 가상 머신의 편차가 더 낮은 것은 '지터'가 더 낮다는 의미입니다. 이는 공유되는 가상화된 테스트 환경이므로 이러한 성능 결과가 지연 시간 민감도 설정이 실제 환경에 미치는 영향을 시사하는 것은 아닙니다. 이는 데모 목적으로만 사용됩니다.

이러한 숫자는 같은 조건에서 리소스 할당이 동일한 가상 머신에서 가져온 것입니다. 둘 간의 유일한 차이는 지연 시간 민감도 설정이 하나는 'Normal'(일반)이고 다른 하나는 'High'(높음)라는 점입니다.

 

 

가상 머신 통계 수집기 창 닫기

 

작업 표시줄에서 .NET 아이콘을 클릭하여 VM Stats Collectors(가상 머신 통계 수집기)를 앞으로 가져옵니다.

네트워크 테스트가 완료되었습니다. 각 창의 X를 사용하여 창을 닫으십시오.

 

 

열려 있는 PuTTY 창 닫기

 

열려 있는 PuTTY 창을 닫습니다.

 

결론 및 정리


이것으로 모듈 10, 고급 성능 향상 기능: 지연 시간 민감도 설정을 마치겠습니다. 이 모듈이 유익한 시간이 되었기를 바랍니다. 완료되면 설문조사를 작성해 주십시오.


 

모듈 10 중지

 

주 콘솔의 모듈 창에서 Module 10(모듈 10) 아래 Stop(중지)을 클릭합니다.

 

 

핵심 사항

지연 시간 민감도 설정은 구성이 용이하지만 애플리케이션이 'High'(높음) 지연 시간 민감도의 정의에 부합하는지 확인해야 합니다.

다음과 같이 검토하십시오.

1. 전언이 꺼진 가상 머신에서 지연 시간에 민감한 가상 머신에 대해 100% 메모리 예약을 설정합니다.

2. 환경이 허용하는 경우 예약된 MHz가 CPU의 주파수와 동일하도록 지연 시간에 민감한 가상 머신에 대해 100% CPU 예약을 설정합니다.

3. 가상 머신의 Advanced Settings(고급 설정)에서 Latency Sensitivity(지연 시간 민감도)를 High(높음)로 설정합니다.

vSphere에서 지연 시간에 민감한 애플리케이션을 실행하는 방법에 대해 자세히 알아보려면 다음 백서를 참조하십시오.

http://www.vmware.com/files/pdf/techpaper/VMW-Tuning-Latency-Sensitive-Workloads.pdf  

http://www.vmware.com/files/pdf/techpaper/latency-sensitive-perf-vsphere55.pdf

 

모듈 11 - 고급 성능 툴: esxtop CLI 소개(30분)

esxtop 소개


vSphere 환경에서 성능을 모니터링하고 진단하는 툴에는 여러 가지가 있습니다. 그러나 다른 툴 또는 방법을 통해 이미 확인된 성능 문제를 진단하고 추가 조사하기 위해서는 esxtop을 사용하는 것이 가장 좋습니다. esxtop은 장기적으로 진단을 모니터링하도록 고안된 툴은 아니지만 정해진 기간 동안 특정 문제 또는 특성 호스트의 가상 머신을 심층 조사하거나 모니터링하는 데 적합합니다.

약 30분이 소요되는 이 실습에서는 esxtop을 사용하여 CPU, 메모리, 스토리지 및 네트워크의 성능 문제 해결에 대해 자세히 살펴볼 것입니다. 이 모듈의 목적은 esxtop의 다양한 뷰를 소개하고 각 뷰에서 다양한 로드를 제공하는 것입니다. 즉, esxtop 자체에 대해 자세히 알아보는 것이 아니라 사용자 사용에서 직접 사용할 수 있도록 이 툴에 익숙해지는 것입니다.

esxtop의 각 측정지표에 대해 자세히 알아보고 그 의미를 살펴보려면 본 모듈 뒷부분에 나와 있는 링크를 참조하시기 바랍니다.

전체 vSphere 환경의 일상적인 성능 모니터링의 경우 vRealize Operations(vROPs)가 전체 가상 인프라를 모니터링하는 데 사용할 수 있는 강력한 툴입니다. 여기에는 개괄적인 대시보드 뷰와 기본 제공되는 인텔리전스가 통합되어 있어서 데이터를 분석하고 가능한 문제를 파악할 수 있습니다. 또한 이 Hands-on Lab을 마치면 일상적인 모니터링에 대해 더 잘 이해할 수 있도록 다른 vRealize Hands-on Lab도 살펴보시기 바랍니다.


esxtop CPU 기능 표시


Esxtop은 호스트 및 가상 머신 수준에서 성능의 거의 모든 측면에 관한 성능 문제를 진단하는 데 사용할 수 있습니다. 이 섹션에서는 esxtop을 대화형 모드로 사용하여 CPU 성능을 확인하는 방법을 단계별로 제공합니다.


 

PowerShell 창 열기

 

작업 표시줄에 있는 "Windows PowerShell" 아이콘을 클릭합니다.

 

 

가상 머신에서 CPU 로드 시작

 

다음을 입력합니다.

.\StartCPUTest2.ps1

Enter 키를 누릅니다. 계속하려면 RDP 세션이 나타날 때까지 기다리십시오.  

 

 

PuTTY 열기

 

 

 

SSH를 통해 esx-01a에 연결

 

  1. esx-01a.corp.local 호스트를 선택합니다.
  2. Open(열기)을 클릭합니다.

 

 

esxtop 시작

 

  1. ESXi 셸에서 다음을 입력합니다.
esxtop

Enter 키를 누릅니다.

2.     최대한 많은 정보를 볼 수 있도록 최대화 아이콘을 클릭합니다.

 

 

CPU 뷰 선택

 

esxtop을 시작한 경우 기본적으로 CPU 뷰가 표시됩니다. 다른 화면이 표시되는 경우 "c"를 누르면 이 뷰로 돌아옵니다.

f를 눌러 이 뷰를 필터링해 보겠습니다(일부 필드 삭제).

f

 

 

표시된 필드 필터링

 

화면 공간이 충분하지 않으므로 IDGID 필드를 삭제해 보겠습니다(필터링).

다음 문자를 입력하면 됩니다(참고: 대소문자를 구분하므로 대문자로 입력해야 함).

AB

A: 및 B: 옆의 "*"가 사라져야 합니다. Enter 키를 누릅니다.

 

 

가상 머신만 필터링

 

기본적으로 이 화면에는 가상 머신과 ESXi 호스트 프로세스에 대한 성능 카운터가 표시됩니다.

가상 머신을 제외한 모든 것을 필터링해 보겠습니다.  그러려면 대문자 "V"를 입력하십시오.

V

 

 

가상 머신 로드 모니터링

 

두 작업자 가상 머신 perf-worker-01aperf-worker-01b:에서 로드를 모니터링합니다.

  1. 두 가상 머신 모두 100% 사용률(%USED)로(또는 그에 가깝게) 실행해야 합니다.
    그렇지 않을 경우 CPU 워크로드가 시작될 때까지 기다립니다.
  2. 모니터링해야 하는 또 다른 중요한 측정지표는 %RDY(CPU 준비)입니다.  이 측정지표는 바로 실행 가능하지만 CPU 스케줄러의 승인을 기다려야 하는 시간 비율입니다.  이 측정지표는 vCPU당 최대 100%까지 상승할 수 있습니다. 즉, 2개의 vCPU를 사용할 경우 최대값이 200%입니다.  이 값은 vCPU당 5% 미만으로 유지하는 것이 좋지만 항상 애플리케이션에 따라 다릅니다.

    작업자 가상 머신에서 vCPU당 5% 임계값 이상으로 상승하는지 확인하십시오.  esxtop을 즉시 새로 고침하려면
    스페이스 바를 클릭하십시오.

 

 

Google Chrome 열기

 

Google Chrome 아이콘을 클릭하여 웹 브라우저를 엽니다.

 

 

vSphere Client 로그인

 

Login (로그인) 버튼을 클릭하여 vSphere Client에 로그인합니다.

 

 

perf-worker-01a 설정 편집

 

perf-worker-01a가 어떻게 구성되는지 알아보겠습니다.

  1. esx-01a.corp.local에 호스팅된 perf-worker-01a를 클릭합니다.
  2. Actions(작업) 드롭다운을 클릭합니다.
  3. Edit Settings…(설정 편집...)를 클릭합니다.

 

 

perf-worker-01a에 vCPU 추가

 

CPU Hot Add가 사용하도록 설정되어 있으므로 가상 머신이 실행 중일 때 다른 vCPU를 추가할 수 있습니다.

  1. CPU 드롭다운을 확장합니다.
  2. CPU2로 변경합니다.
  3. OK(확인)를 클릭하여 저장합니다.

 

 

perf-worker-01b 설정 편집

 

perf-worker-01b에 가상 CPU를 추가하고 성능을 개선해 보겠습니다.

  1. perf-worker-01b 가상 머신을 마우스 오른쪽 버튼으로 클릭합니다.
  2. Edit Settings…(설정 편집...)를 클릭합니다.

 

 

perf-worker-01b에 vCPU 추가

 

  1. vCPU에 2를 선택합니다.
  2. "OK"(확인)를 클릭합니다.

 

 

esxtop/PuTTY로 돌아가기

 

변경 사항을 확인하려면 작업 표시줄에서 esx-01a.corp.local을 클릭하여 PuTTY(esxtop) 창으로 돌아가서 합니다.

 

 

%USED 및 %RDY 모니터링

 

이제 각 가상 머신에 vCPU가 추가되었으므로 위의 스크린샷과 같은 결과가 표시되어야 합니다.

 

 

%USED 및 %RDY 모니터링(계속)

 

몇 분 후 CPU 벤치마크가 추가 vCPU를 사용하기 시작하고 %RDY도 더 증가합니다. 이는 시스템에서의 CPU 경합 및 SMP 스케줄링(%CSTP 증가) 때문입니다. ESXi 호스트는 2개의 활성 가상 머신 전반에 4개의 vCPU가 있는데, 각각에서 2개의 vCPU를 100% 실행하려고 시도하면서 리소스를 확보하려는 경합이 발생합니다. ESXi 호스트는 실행하기 위해 CPU 리소스도 필요한데, 이는 CPU 경합을 초래합니다.

 

esxtop 메모리 기능 표시


Esxtop은 호스트 및 가상 머신 수준에서 성능의 거의 모든 측면에 관한 성능 문제를 진단하는 데 사용할 수 있습니다. 이 섹션에서는 esxtop을 대화형 모드로 사용하여 메모리 성능을 확인하는 방법을 단계별로 제공합니다.


 

PowerShell 창 열기(필요한 경우)

 

작업 표시줄에서 Windows PowerShell 아이콘을 클릭하여 명령 프롬프트를 엽니다.

참고: 이미 열려 있는 경우 해당 창으로 전환하기만 하면 됩니다.

 

 

실습 재설정

 

다음을 입력합니다.

.\StopLabVMs.ps1

Enter 키를 누릅니다. 이렇게 하면 실습이 기본 설정으로 재설정됩니다.

 

 

메모리 테스트 시작

 

PowerShell 창에서 다음을 입력합니다.

.\StartMemoryTest.ps1

Enter 키를 눌러 메모리 로드를 시작합니다.

스크립트가 실행 중일 때 다음 단계를 진행할 수 있지만, 메모리 로드가 중단될 수 있으므로 모든 창을 닫지 마십시오.

 

 

esxtop 메모리 뷰 선택

 

PuTTY 창에서 다음을 입력합니다.

m

메모리 뷰가 표시됩니다.

 

 

올바른 필드 선택

 

다음을 입력합니다.

f

이용 가능한 카운터 목록이 표시됩니다.

화면 공간이 충분하지 않으므로 2개 카운터의 ID 및 그룹 ID를 삭제합니다.

다음(대문자)을 누릅니다.

B
H
J

Enter 키를 눌러 esxtop 페이지로 돌아갑니다.

 

 

가상 머신만 표시

 

이 화면에는 가상 머신과 ESXi 호스트 프로세스에 대한 성능 카운터가 표시됩니다.

가상 머신에 해당하는 값만 표시됩니다.

다음(대문자)을 누릅니다.

V

 

 

경합 없는 메모리 로드 모니터링

 

작업자 가상 머신의 로드가 시작되면 esxtop 창 상단에 표시되어야 합니다.

여기서 살펴볼 측정지표는 다음과 같습니다.

MCTL:

Balloon 드라이버의 설치 여부를 보여줍니다. 설치되어 있지 않은 경우 먼저 해결하는 것이 좋습니다.

MCTLSZ:

Balloon 드라이버가 얼마나 확장되어 있는지를 보여줍니다. 얼마나 많은 메모리를 운영 체제에서 가져왔는지를 보여줍니다. 이는 0이어야 합니다.

SWCUR:

얼마나 많은 가상 머신이 스와핑되었는지를 보여줍니다. 이는 0이어야 하지만, 마지막 카운터에 문제가 없는 경우 괜찮습니다.

SWR/S:

스왑 파일에서 얼마나 많은 읽기가 진행되는지를 보여줍니다.

SWW/S:

스왑 파일에서 얼마나 많은 쓰기가 진행되는지를 보여줍니다.

실습에 따라 모든 카운터에 문제가 없어야 합니다. 하지만 중첩된 실습의 특성상 무엇이 표시될지는 모릅니다. 따라서 문제가 없는지 직접 확인해 보시기 바랍니다.

 

 

perf-worker-04a 전원 켜기

 

  1. "perf-worker-04a"를 마우스 오른쪽 버튼으로 클릭합니다.
  2. "Power"(전원)를 선택합니다.
  3. "Power On"(전원 켜기)을 클릭합니다.

 

 

경합 중인 메모리 로드 모니터링

 

이제 ESXi 호스트에서 메모리 경합을 생성했으므로 다음을 볼 수 있습니다.

  1. perf-worker-02a 및 03a가 각각 약 400MB로 매우 증가합니다.
  2. perf-worker-02a, 03a 및 04a가 디스크로 스와핑합니다. 이는 이 환경에서 너무 많은 메모리 부담이 너무 많다는 것을 나타냅니다.

 

 

작업자에서 로드 중지

 

  1. 2개의 가상 머신 통계 수집기 창을 닫아서 로그 스크립트를 시작한 후 표시된 작업자에서 로드를 중지합니다.

 

esxtop 스토리지 기능 표시


Esxtop은 호스트 및 가상 머신 수준에서 성능의 거의 모든 측면에 관한 성능 문제를 진단하는 데 사용할 수 있습니다. 이 섹션에서는 esxtop을 대화형 모드로 사용하여 스토리지 성능을 확인하는 방법을 단계별로 제공합니다.


 

PowerShell 창 열기(필요한 경우)

 

작업 표시줄에서 Windows PowerShell 아이콘을 클릭하여 명령 프롬프트를 엽니다.

참고: 이미 열려 있는 경우 해당 창으로 전환하기만 하면 됩니다.

 

 

실습 재설정

 

다음을 입력합니다.

.\StopLabVMs.ps1

Enter 키를 누릅니다. 이렇게 하면 실습이 기본 설정으로 재설정됩니다.

 

 

스토리지 테스트 시작

 

PowerShell 창에서 다음을 입력합니다.

.\StartStorageTest.ps1 

Enter 키를 눌러 실습을 시작합니다.

실습을 준비하는 데 약 5분이 소요됩니다. 스크립트가 완료되는 동안 다른 단계를 계속 진행하십시오.

스크립트를 시작한 후 화면에 표시되는 모든 창을 닫지 않아야 합니다.

 

 

다양한 뷰

 

스토리지를 esxtop에서 볼 때 선택할 수 있는 다양한 옵션이 있습니다.

Esxtop는 스토리지 통계를 세 개 화면으로 보여줍니다.

그 외

이 모듈에서는 가상 머신 화면에 대해 집중적으로 살펴볼 것입니다.

Putty 창에서 다음(소문자)을 입력합니다.

v

스토리지 뷰가 표시됩니다.

 

 

올바른 필드 선택

 

다음을 입력합니다.

f

이용 가능한 카운터 목록이 표시됩니다.

이 경우 모든 카운터는 vscsi id로 추가됩니다.

모든 카운터를 위한 공간이 충분하므로 다음(대문자)을 눌러 원하는 만큼 추가합니다.

A

완료되면 Enter 키를 누릅니다.

 

 

가상 머신에서 IOmeter 로드 시작

 

본 실습을 시작할 때 실행된 StartStorageTest.ps1 스크립트를 이제 완료하고 데스크톱에 이와 같은 2개의 IOmeter 창이 표시되어야 합니다.

표시되지 않는 경우 다음을 실행합니다.

\StartStorageTest.ps1 

다시 완료될 때까지 기다립니다.

 

 

가상 머신 로드 모니터링

 

이 실습에서는 4개의 가상 머신이 실행 중입니다.

2개는 IOmeter 워크로드를 실행 중이고 다른 2개는 RAM 디스크를 사용하는 iSCSI 스토리지 대상입니다. RAM 디스크를 스토리지 대상으로 사용하므로 디스크 I/O를 생성하지 않습니다.

여기서 살펴볼 측정지표는 다음과 같습니다.

CMDS/S:

초당 총 명령 수로, 모니터링되는 기기 또는 가상 머신으로 전송되거나 해당 기기 또는 가상 머신에서 발생하는 IOPS(초당 입출력 작업) 및 기타 SCSI 명령(예: SCSI 예약, 잠금, 벤더 문자열 요청, 단위 주의 명령 등)이 포함됩니다.

대부분의 경우 많은 메타데이터 작업(예: SCSI 예약)이 있는 경우가 아니라면 CMDS/s = IOPS입니다.

LAT/rd 및 LAT/wr:

가상 머신에 표시되는 평균 응답 시간 또는 읽기 및 쓰기 IO를 나타냅니다.

이 경우 현재 IO 미터 로드를 수행하고 있는 작업자 가상 머신(perf-worker-02a 및 03a)에 CMD/s 값이 높게 표시되어 많은 IO가 생성되고 있음을 나타내야 합니다.

또한 쓰기 작업만 수행하므로 LAT/wr 값도 높아야 합니다.

Hands-on Lab의 특성상 실제 수치는 화면과 다를 수 있습니다.

 

 

기기 또는 커널 지연 시간

 

다음을 누릅니다.

d

기기 뷰로 이동합니다.

여기에서 스토리지 워크로드가 소프트에어 iSCSI 어댑터인 기기 vmhba33에 있다는 것을 알 수 있습니다. DAVG(기기 지연 시간) 및 KAVG(커널 지연 시간)를 살펴보십시오. DAVG는 25ms 미만이어야 하고 커널에 의해 야기된 지연 시간인 KAVG는 매우 낮아서 항상 2ms 미만이어야 합니다.

이 예에서는 지연 시간이 수용할 수 있는 값 범위 내에 있습니다.

 

 

작업자에서 로드 중지

 

두 IOmeter 작업자를 모두 닫습니다.

  1. 완료되면 "STOP"(중지)을 클릭하여 IOmeter 워크로드를 중지합니다.
  2. 오른쪽 상단의 X를 클릭하여 창을 닫습니다.

 

esxtop 네트워크 기능 표시


Esxtop은 호스트 및 가상 머신 수준에서 성능의 거의 모든 측면에 관한 성능 문제를 진단하는 데 사용할 수 있습니다. 이 섹션에서는 esxtop을 대화형 모드로 사용하여 네트워크 성능을 확인하는 방법을 단계별로 제공합니다.


 

PowerShell 창 열기(필요한 경우)

 

작업 표시줄에서 Windows PowerShell 아이콘을 클릭하여 명령 프롬프트를 엽니다.

참고: 이미 열려 있는 경우 해당 창으로 전환하기만 하면 됩니다.

 

 

실습 재설정

 

다음을 입력합니다.

.\StopLabVMs.ps1

Enter 키를 누릅니다. 이렇게 하면 실습이 기본 설정으로 재설정됩니다.  

 

 

네트워크 테스트 시작

 

PowerShell 창에서 다음을 입력합니다.

 .\StartNetTest.ps1

Enter 키를 누릅니다.

스크립트가 실행되는 동안 몇 분이 소요되므로 다음 단계를 계속 진행하십시오.

 

 

네트워크 뷰 선택

 

PuTTY 창에서 다음을 입력합니다.

n

네트워킹 뷰가 표시됩니다.

 

 

올바른 필드 선택

 

다음을 입력합니다.

f

이용 가능한 카운터 목록이 표시됩니다.

화면 공간이 충분하지 않으므로 2개 카운터 PORT-ID 및 DNAME을 삭제합니다.

다음(대문자)을 누릅니다.

A
F

완료되면 Enter 키를 누릅니다.

 

 

로드 모니터링

 

측정지표를 모니터링합니다.

Hands-on Lab이 실행 중인 환경의 로드로 인해 결과가 화면과 다를 수 있습니다.

화면이 자동으로 업데이트되지만 다음을 눌러 새고 고침해야 합니다.

space

여기서 살펴볼 측정지표는 다음과 같습니다.

%DRPTX%DRPRX

이는 각각 전송된 패키지와 수신된 패키지의 손실된 비율(%)입니다.

이 수치가 증가하면 네트워크 활용도가 높다는 것을 나타낼 수 있습니다.

첫 번째 단계에서 실행한 StartNetTest.ps1 스크립트는 가상 머신을 시작한 후 2분 동안 기다린 다음에 5분 동안 네트워크 로드를 실행합니다.

속도에 따라 이 단계에 도달하는 데 7분 이상 소요된 경우 로드가 표시되지 않을 수 있습니다.

 

 

네트워크 로드 다시 시작

 

다시 5분 동안 네트워크 로드를 시작하려면 PowerCLI 창으로 돌아갑니다.

PowerShell에서 다음을 입력합니다.

 .\StartupNetLoad.bat

Enter 키를 누릅니다.

이제 네트워크 로드가 5분 동안 실행됩니다. 기다리는 동안 esxtop을 자세히 살펴볼 수 있습니다.

 

 

네트워크 워크로드 완료

 

앞에서 설명한 대로, 로드는 자체적으로 중지됩니다. PowerShell 창에 "Network load complete"(네트워크 로드 완료)라고 표시되면 추가 로드가 생성되지 않습니다.

 

결론 및 정리



 

핵심 사항

이 실습에서는 esxtop을 사용하여 CPU, 메모리, 스토리지 및 네트워크 뷰에서 로드를 모니터링하는 방법을 살펴봤습니다.

그러나 esxtop의 기능에 대해 아주 간략하게만 살펴본 것입니다.

esxtop에 대해 자세히 알아보려면 다음 문서를 참조하십시오.

 

 

 

절차 정리

이 실습의 나머지 부분에 사용할 리소스를 확보하기 위해 사용된 가상 머신을 종료하고 이 구성을 재설정해야 합니다.

 

 

PowerShell 창 열기(필요한 경우)

 

작업 표시줄에서 Windows PowerShell 아이콘을 클릭하여 명령 프롬프트를 엽니다.

참고: 이미 열려 있는 경우 해당 창으로 전환하기만 하면 됩니다.

 

 

실습 재설정

 

다음을 입력합니다.

.\StopLabVMs.ps1

Enter 키를 누릅니다. 이렇게 하면 실습이 기본 설정으로 재설정됩니다. 이제 다른 모듈로 이동할 수 있습니다.

 

 

결론

이것으로 모듈 11, 고급 성능 툴: esxtop CLI 소개을 마치겠습니다. 이 모듈이 유익한 시간이 되었기를 바랍니다. 완료되면 설문조사를 작성해 주십시오.

 

결론

VMware Hands-on Lab에 참여해 주셔서 감사합니다. http://hol.vmware.com/ 에서 더 많은 온라인 실습을 체험하시기 바랍니다.

실습 SKU: HOL-1904-01-SDC

버전: 20190122-181551