vSphere 교육-RAM이 너무 많은 VM 구성의 단점은 무엇입니까?

VMware 메모리 관리는 까다로운 밸런싱 작업 인 것 같습니다. 클러스터 RAM, 리소스 풀, VMware 관리 기술 (TPS, 벌룬, 호스트 스와핑), 게스트 내 RAM 활용, 스와핑, 예약, 공유 및 제한에는 많은 변수가 있습니다.

클라이언트가 전용 vSphere 클러스터 리소스를 사용하는 상황에 처해 있습니다. 그러나 실제 하드웨어에있는 것처럼 가상 시스템을 구성하고 있습니다. 이는 표준 VM 빌드에 4 개의 vCPU와 16GB 이상의 RAM이있을 수 있음을 의미합니다. 나는 소규모 (1 vCPU, 최소 RAM)를 시작하여 실제 사용을 확인하고 필요에 따라 조정하는 학교에서 왔습니다. 불행히도 많은 공급 업체 요구 사항과 가상화에 익숙하지 않은 사람들이 필요한 것보다 더 많은 리소스를 요구합니다. 저는이 결정의 영향을 정량화하고 싶습니다.

"문제점"클러스터의 일부 예

리소스 풀 요약-약 4 : 1 오버 커밋 된 것으로 보입니다. 많은 양의 풍선 RAM이 있습니다.

리소스 할당-최악의 경우 할당 열에는 이러한 VM이 제한된 조건에서 구성된 RAM의 50 % 미만에 액세스 할 수 있음이 표시됩니다.

위 목록에서 최상위 VM의 실시간 메모리 사용률 그래프입니다. 4 개의 vCPU 및 64GB RAM이 할당되었습니다. 평균 9GB 미만입니다.

동일한 VM의 요약

• vSphere 환경에서 리소스를 초과 커밋 및 구성 (특히 RAM)하면 어떤 단점이 있습니까?

• VM이 더 적은 RAM에서 실행될 수 있다고 가정하면 실제로 필요한 것보다 더 많은 RAM으로 가상 시스템을 구성하는 데 오버 헤드가 있다고 말하는 것이 공정 합니까?

• 님의 반론 무엇입니까 "VM이 RAM 16GB의 할당했다,하지만 최대 4GB 사용하는 경우, 문제가 무엇은? "? 예를 들어 고객에게 VM이 실제 하드웨어와 동일하지 않다는 교육을 받아야 합니까?

• RAM 사용량을 측정하는 데 사용해야하는 특정 메트릭 "활성"대 시간의 피크를 추적합니까? "소비"를보고 있습니까?

업데이트 : vCenter Operations Manager 를 사용 하여이 환경을 프로파일 링하고 위에 나열된 클러스터 통계에 대해 자세히 알아 봅니다. 일이 확실히 오버 커밋하는 동안, VM은 실제로 그렇게 실제 (작은) 메모리 풋 프린트가 클러스터 / 호스트 수준에서 메모리 경합을 보여줍니다 불필요한 RAM과 overconfigured ...

필자의 의견은 OS 수준 캐싱을 위해 약간의 버퍼로 VM의 크기를 실제로 조정해야한다는 것입니다. 무지 나 공급 업체의 "요구 사항"을 초과 커밋하면 여기에 제시된 상황이 발생합니다. 성능에 영향을 미치므로 메모리 벌룬은 모든 경우에 나쁜 것처럼 보이므로 올바른 크기로 조정하면이를 방지 할 수 있습니다.

업데이트 2 : 이러한 VM 중 일부가 다음과 같이 충돌하기 시작합니다.

kernel:BUG: soft lockup - CPU#1 stuck for 71s! 

VMware는이를 과도한 메모리 초과 커밋 의 증상으로 설명합니다 . 그래서 나는 그것이 질문에 대한 대답이라고 생각합니다.

vCops "대형 가상 머신"보고서 ...

vCops "재생 가능한 폐기물"그래프 ...

vSphere의 메모리 관리는 꽤 괜찮지 만 사용되는 용어는 종종 많은 혼란을 야기합니다.

일반적으로 메모리 초과 커밋은 이러한 유형의 문제를 정확하게 생성하므로 피해야합니다. 그러나 피할 수없는 경우가 있으므로 미리 양해 바랍니다.

vSphere 환경에서 초과 커밋 및 초과 구성 리소스 (특히 RAM)의 단점은 무엇입니까?

과도하게 커밋하는 리소스의 주요 단점은 경합이 발생하면 호스트가 각 VM에 필요한 RAM을 제공하기 위해 장면 뒤에서 풍선, 스왑 또는 지능적으로 예약 / 복제해야한다는 것입니다.

풍선 도움말의 경우 vSphere는 선택한 VM 내에 RAM의 "풍선"을 부풀린 다음 풍선이있는 RAM을 필요한 게스트에게 제공합니다. 이것은 실제로 "나쁜"것은 아닙니다-VM이 서로의 RAM을 훔치고 있기 때문에 디스크 스왑이 진행되지 않습니다-그러나 RAM의 원으로 VM의 RAM 사용량을 분석하는 데 잘못 경고가 발생하고 메트릭이 왜곡 될 수 있습니다 OS에서 "사용 중"이라는 것만으로 "풍선"으로 표시되지 않습니다.

vSphere에서 사용할 수있는 다른 기능은 TPS (투명 페이지 공유)입니다. 이는 본질적으로 RAM 중복 제거입니다. vSphere는 할당 된 모든 RAM을 주기적으로 검색하여 중복 된 페이지를 찾습니다. 발견되면 중복 된 페이지를 중복 제거하고 비 웁니다.

살펴보세요 (PDF)은 vSphere의 메모리 관리 백서 특히 "ESXi를 메모리 매립"(8 페이지) - - 좀 더 깊이있는 설명이 필요합니다.

VM이 적은 RAM에서 실행될 수 있다고 가정하면 필요한 것보다 많은 RAM으로 가상 시스템을 구성하는 데 오버 헤드가 있다고 말하는 것이 타당한가요?

눈에 보이는 오버 헤드가 없다 - 당신이 16 GB의 호스트에 RAM 100GB의를 할당 할 수 있습니다 (그러나, 당신이 의미하지 않는다 해야 , 위의 이유로).

모든 VM에서 사용중인 총 메모리는 그래프에 표시된 "활성"곡선입니다. 물론 초과 커밋하려는 양을 계산할 때 해당 수치에만 의존해서는 안되지만 과거의 메트릭이있는 경우 실제 사용량을 기준으로 분석하고 해결할 수 있습니다.

"Active"와 "Consumed"RAM의 차이점은이 VMWare Community 스레드 에서 설명 합니다 .

반대 의견은 무엇입니까? "VM에 16GB의 RAM이 할당되었지만 4GB 만 사용하는 경우 문제는 무엇입니까?" ? 예를 들어 고객에게 교육을 받아야합니까?

이에 대한 짧은 대답은 그렇습니다 . 고객은 폐기 도구에 상관없이 항상 모범 사례를 교육 해야합니다 .

고객들은 원하는 것이 아니라 사용 하는 것에 따라 VM의 크기를 정해야합니다 . 많은 사람들 이 역사적으로 매일 2GB가 울리는 경우에도 16GB의 RAM 이 필요할 수 있기 때문에 VM을 과도하게 지정 합니다. vSphere 관리자는 자신에게 도전 할 지식, 지표 및 권한을 가지고 있으며 실제로 할당 한 RAM이 필요한지 묻습니다.

즉, vSphere의 메모리 관리를 신중하게 제어 된 오버 커밋 제한과 결합하면 실제로는 거의 문제가되지 않으며, 장기간 RAM이 부족할 가능성은 비교적 적습니다.

또한 자동화 된 vMotion ( VMware의 분산 리소스 예약 이라고 함 )은 기본적으로 VM의로드 밸런서입니다. 단일 VM이 리소스 호그가되는 경우 DRS는 VM을 마이그레이션하여 클러스터 리소스를 최대한 활용해야합니다.

RAM 사용량을 측정하는 데 사용해야하는 특정 메트릭 "활성"대 시간의 피크를 추적합니까?

위의 내용 중 대부분은 "액티브"RAM 사용량이어야하지만 오버 커밋 임계 값을 신중하게 정의하여 특정 비율에 도달 할 경우 ( 이는 괜찮은 예 이지만 약간 오래된 경우도 있습니다). 일반적으로 전체 클러스터 RAM의 120 % 이내를 유지하지만 어느 비율이 편안한 지 결정하는 것은 사용자의 몫입니다.

메모리 오버 커밋에 대한 몇 가지 좋은 기사 / 토론 :

• 프로덕션에서 메모리 오버 커밋? 예 예 예
• vSphere-오버 커밋 메모리?
• vSphere의 메모리 오버 커밋

Craig Watson의 탁월한 답변 외에도 다음을 추가하고 싶습니다.

VMware에서 초과 커밋 메모리는 의도적으로 수행해야하는 것이 아닙니다. 일반적으로 귀하 또는 귀하의 고객이 하드웨어를 과도하게 구독하고 있음을 보여줍니다.

오버 커밋하는 것이 유일한 선택 인 경우, 나는 강하게 당신이 우선 순위 규칙을 적용하는 것이 바람직합니다. 4GB 만 필요할 때 중요하지 않은 VM 16GB의 vRam을 제공하는 데 관심이있는 사람이라면 최소한 해당 VM을 낮은 리소스 풀에 배치하거나 낮은 우선 순위를 부여하십시오. 하이퍼 바이저에서 중요한 프로덕션 데이터베이스를 스왑 아웃하지 않으려 고합니다. 성능이 저하 될뿐만 아니라 백엔드 스토리지에 대한 I / O 대기열도 소모합니다.

초고속 스토리지 (FusionIO, Violin, 로컬 SSD 등)에서 실행중인 경우 스와핑은 큰 문제가되지 않지만 기존 SAN 스토리지에서는 결국 동일한 어레이 / 컨트롤러에 연결된 모든 단일 VM 및 호스트에 영향을 미칩니다.