종종 데비안 기반의 안정적인 애플리케이션 기반의 설치는 일반적으로 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가 과도하게 구성되었습니다.