애플리케이션에 대한 VMware 성능 요구 사항을 VMware 관리자에게 설명하는 방법은 무엇입니까?

종종 데비안 기반의 안정적인 애플리케이션 기반의 설치는 일반적으로 VMware ESXi에서 가상 머신에서 실행됩니다. 일반적으로 가상화 환경에 대한 가시성이나 영향을받지 않으며 VMware vCenter 클라이언트 또는 이와 동등한 제품에 액세스 할 수 없습니다. 여기서는 VMware가 가장 일반적이기 때문에 VMware에 중점을 둡니다.

우리는 :

• 고객에게 VMware 관리자에게 알리십시오. 성능 기준 X, Y 및 Z를 충족하는 경우 VMware ESX 환경과 같은 애플리케이션을 실행할 수 있습니다.
• 실행중인 시스템에서도 기준 X, Y 및 Z가 실제로 지속적으로 (예 : 지금도 ) 충족되는지 확인할 수 있습니다 (응용 프로그램을 중지하고 벤치 마크를 실행할 수 없으며 초기 벤치 마크로는 충분하지 않습니다. 가상 환경은 시간이 지남에 따라 변경됩니다).
• 기준 X, Y 및 Z가 충족되면 만족스러운 성능으로 응용 프로그램을 실행할 수있는 적절한 가상 HW 리소스를 갖게 될 것입니다.

이제 X, Y 및 Z는 무엇입니까?

우리는 성능 문제가있을 때 문제가 애플리케이션이 아니라 가상화 환경에 있다는 것을 몇 번이고 보았습니다. 예를 들어 다른 가상 머신은 디스크가 실제로 저장되어있는 수많은 CPU, 메모리 또는 SAN을 사용하므로 애플리케이션 이외의 용도로 많이 사용됩니다. 현재이를 증명하거나 반증 할 방법이 없습니다.

이론적으로 때로는 응용 프로그램이 느릴 수도 있습니다 ... ;-)

성능 문제의 근본 원인 인 가상 환경 또는 애플리케이션을 어떻게 결정합니까?

CPU, 메모리 및 DISK I / O의 성능 문제에는 일반적으로 3 가지 영역이 있습니다.

CPU

예를 들어 VMware에서 관리자는 MHz로 표현 된 Reservation and Limit를 지정할 수 있지만 예를 들어 한 ESX 호스트의 512MHz가 다른 ESX 호스트의 512MHz와 정확히 동일하거나 완전히 다른 ESX 클러스터에 있습니까?

그리고 우리가 실제로 그것을 얻었는지 어떻게 측정합니까? 애플리케이션이 실행되는 동안 4 개의 CPU에서 CPU 사용률이 212 %임을 알 수 있습니다. 애플리케이션이 많은 작업을 수행하거나 동일한 호스트의 다른 VM이 CPU를 많이 사용하는 작업을 실행하고 모든 CPU를 사용하기 때문입니까?

기억 (풍선?)

예를 들어 16GB RAM을 요청하면 종종 구성되지만 벌룬으로 인해 실제로 4GB 만 가져오고 놀랍게도 응용 프로그램의 성능이 저하됩니다.

VMware 도구에 현재 풍선 도움말에 대해 문의 할 수 있지만 종종 풍선 모양이 틀리거나 최소한 부정확하다는 것을 알았습니다. 우리는 OS가 16GB의 총 RAM이 있다고 생각하는 예를 보았습니다. 모든 프로세스의 상주 메모리 (RSS)의 합은 4GB RAM이지만 VMware 도구에서 풍선이 없다고 말할 때에도 2GB의 RAM이 없습니다. -(

또한 공유 RAM이 쉽게있을 수 있으므로 RSS를 함께 추가하는 것은 유효하지 않습니다. 따라서 모든 프로세스에서 RSS를 빼서 사용 가능한 RAM의 양을 측정하여 신뢰할 수있는 열기를 감지 할 수는 없습니다. 벌룬의 경우를 감지 할 수 있지만 벌룬이 적용되지만이 방법으로 감지 할 수없는 다른 경우가 있습니다.

디스크 I / O

시간이 지남에 따라 디스크 읽기 및 쓰기 수, 읽고 쓴 바이트 수 및 IO 대기 %를 그래프로 나타낼 수 있습니다. 그러나 이것이 디스크 I / O의 정확한 그림을 제공할까요? 모든 CPU를 사용하는 다른 VM에서 비트 코인 채굴자가 실행되는 경우 기본 SAN이 정확히 동일한 성능을 제공하더라도 CPU 리소스가 다운되어 IO 대기 (IO 대기)하기 때문에 IO 대기 %가 증가한다고 상상합니다 ( % 단위로 측정 ) 증가합니다.

요약하면, VMware 관리자와 같이 어떤 언어를 이식성 있고 측정 가능한 방식으로 설명 할 수 있습니까?

• 진심으로, 대부분의 VMware 관리자는이 점에 능숙하지 않습니다. 리소스 관리에 대한 이해 부족, 종종 Linux 지식 (도움이 없음) 및 시간 대역폭 부족. 대부분의 사내 관리자는 깊은 가상화 지식을 유지하는 데 어려움을 겪고 있습니다.

• 다행히 읽을 수있는 책이 있습니다 !

• 대부분의 VMware 환경은 좋지 않습니다. 열악한 클러스터 설계, 잘못된 리소스 계획 , 하위 표준 스토리지 (예 : Synology NAS), 잘못 구성된 HA, 모니터링 또는 패치 없음.

• 조직으로서의 VMware는 우리에게 실패합니다. 특히 최신 정보를 유포하고 모범 사례를 홍보하는 데 특히 나쁩니다. 일반적인 질문에 대한 기본 검색은 프로세스와 설계가 시간이 지남에 따라 변경되었다는 사실에도 불구하고 2009 및 이전 버전의 VMware에서 결과를 생성합니다.

이 모든 것이 당신에게 불리하게 작용할 것입니다.

솔루션의 실제 요구 사항을 결정해야합니다. 어플라이언스에 2 vCPU, 8GB RAM 및 500 IOP 스토리지 성능 이 필요하다는 것을 정확하게 알 수 있다면 나와 같은 사람에게 먼 길을 갈 것입니다.

다른 접근법은 건강하거나 이상적인 환경을 관찰하고 거기에서 지표를 추정하는 것입니다.

특정 배포와 관련된 문제를 설명했습니다. 문제와 병목 현상은 무엇입니까?

적절한 크기의 VM의 예 :

300 명의 사용자 조직을위한 Exchange 서버

• 6 주간의 워크로드 / 스트레스 히트 맵과 시간이 있습니다.
• 6 개의 vCPU는 스파이크를위한 버퍼 공간이있는 스트레스 영역을 유지합니다.
• 32GB RAM은 우리를 스트레스 값보다 높게 유지하지만 실제로 필요한 것보다 부당한 것은 아닙니다.

• 몇 GB의 RAM과 vCPU를 회수 할 수 있지만이 모든 것이 효율적인 VM입니다.
• 이상적인 조건에서 이러한 유형의 애플리케이션 모니터링을 얻는 것이 좋습니다.

VM 리소스 모니터링의 예

좋은 점 :-VM의 크기가 적당합니다. -클러스터에서 CPU가 오버 커밋되었지만 경쟁이 일어나지 않았습니다.

나쁜 것 :

• VM은 구성된 모든 RAM을 얻지 못합니다.
• VM이 이미 RAM을 교체하고 있습니다.
• CPU가 과도하게 구성되었습니다.