가상화 호스트에 실제로 필요한 메모리는 얼마나 되나요?

그다지 많지는 않습니다. 많지도 적지도 않습니다.

솔직히 말씀드리자면, 가상화 호스트 메모리 요구 사항에 대한 일반적인 조언은 Microsoft, Red Hat, VMware 모두 메모리 매립, 시작 대 정상 상태 동작 또는 오버 커밋 메커니즘을 문서화하여 프로덕션에서 이러한 지름길을 신뢰할 수 없게 만드는데도 불구하고 구성된 VM RAM을 마치 라이브 메모리 요구 사항과 동일한 것으로 취급하기 때문에 엉성한 조언입니다. 왜 우리는 여전히 스프레드시트 합계를 현실과 동일시할까요?

가상화 호스트에는 호스트 예비, 하이퍼바이저 오버헤드, VM 작업 세트, 재시작, 장애 조치 또는 패치 윈도우를 위한 운영 헤드룸 등 4개의 버킷을 동시에 처리할 수 있는 충분한 물리적 RAM이 필요합니다. 프로비저닝된 게스트 메모리로만 크기를 정하는 것은 용량을 계획하는 것이 아니라 희망을 사는 것입니다.

중요한 숫자는 허울뿐인 vRAM이 아닌 작업 세트입니다.

먼저 세 단어입니다. 이제 추측하지 마세요.

Hyper-V는 시동 RAM, 최소 RAM, 최대 RAM 및 메모리 버퍼를 분리하는 반면, KVM은 게스트를 필요에 따라 메모리가 할당되는 Linux 프로세스로 취급하고 VMware는 VM의 작업 세트를 초과하는 메모리가 캐시 및 추가 오버헤드가 되는 경우가 많다고 명시적으로 경고하므로 16GB가 할당된 VM이 자동으로 16GB를 소비하는 것은 아닙니다. 유휴 캐시 페이지를 위해 실리콘을 구입하는 이유는 무엇입니까?

제 규칙은 간단하며, 마케팅 브로셔보다 더 신뢰합니다:
호스트 RAM = 호스트 예비 공간 + 하이퍼바이저/VM 오버헤드 + 정상 상태 VM 작업 세트 + 페일오버/재시작 헤드룸

그 공식은 지루합니다. 좋습니다. 노드가 재부팅되고 모든 “일시적인” 예외가 갑자기 문제가 되는 새벽 2시 13분에 클러스터를 유지하는 것은 지루한 일입니다. Microsoft는 Hyper-V가 관리 호스트 OS를 위해 메모리를 예약하고 재시작 시 스마트 페이징을 임시 브리지로만 사용한다고 언급하며, Red Hat은 메모리 오버커밋이 일반적인 메모리 부족에 대한 이상적인 해결책이 아니며 호스트 OS에 최대 4GB를 남겨두고 KVM 호스트에 최소 4GB의 스왑을 남겨두라는 기본 규칙을 발표했습니다.

ESXi, Hyper-V 및 KVM이 실제로 고려하는 사항

저는 가짜 동등성이 싫어요.

사람들은 ESXi, Hyper-V, KVM이 모두 “메모리를 같은 방식으로 처리”하는 것처럼 이야기하지만, 이는 게으른 운영자의 이야기입니다: Hyper-V는 시작, 최소, 최대 및 버퍼에 대한 동적 제어를 노출하고, KVM은 Linux 메모리 관리 및 스왑에 의존하며, VMware는 오버 커밋을 작업 공간 문제로 취급하고 압력이 높아지면 풍선처럼 매립하는 방식에 의존합니다. 같은 목표, 다른 고통.

플랫폼	공급업체 문서에서 말하는 내용	실제로 의미하는 바
VMware ESXi / vSphere	오버커밋은 VM의 작업 메모리 풋프린트가 호스트 메모리를 초과할 때 시작되며, VMware는 또한 작업 세트를 초과하여 할당된 메모리는 일반적으로 게스트 캐시로 전환되어 VM 오버헤드를 증가시킨다고 지적합니다.	할당된 총 vRAM만으로 크기를 정하지 마세요. 관찰된 활성 메모리를 기준으로 크기를 조정한 다음, 드물게 회수할 수 있는 공간을 일정하지 않게 유지합니다.
Microsoft Hyper-V	Hyper-V는 관리 OS를 위해 메모리를 예약하고 시작 RAM, 최소 RAM, 최대 RAM, 메모리 버퍼 및 스마트 페이징을 사용하여 런타임 압력과 재시작 안정성을 관리합니다.	부팅 요구 사항과 정상 상태 요구 사항을 분리하지 않으면 모든 VM의 크기가 영원히 커지게 됩니다.
KVM / Red Hat	게스트는 영구적으로 전용 물리적 블록을 얻지 못하며 Linux 호스트는 필요에 따라 메모리를 할당합니다. Red Hat은 오버커밋이 일반적인 메모리 부족에 대한 올바른 치료법이 아니며 호스트에 메모리와 스왑을 남겨두라고 조언합니다.	호스트를 보이지 않는 펌웨어가 아닌 살아있는 Linux 시스템처럼 취급하세요. 스왑이 계속 사용 중이면 사이징이 잘못된 것입니다.

그렇다면 실질적인 시사점은 무엇일까요?

고집적 혼합 프로덕션 가상화를 실행하는 경우, 영웅적인 통합 비율을 자랑하는 호스트보다 실제 여유 헤드룸으로 순항하는 호스트를 보고 싶습니다. VMware의 자체 지침에 따르면 여유 공간이 존재하지만 그렇다고 해서 규모를 너무 빡빡하게 조정하여 풍선과 스왑이 일상화되어야 한다는 의미는 아닙니다. 이는 효율성이 아닙니다. 그것은 느린 동작 중단입니다.

2024년과 2025년에는 틀림의 대가가 더 심해집니다.

이제 비용이 많이 듭니다.

미국 에너지부에 따르면 데이터센터는 2014년 58TWh에서 2023년 176TWh로 증가하여 2023년 미국 전체 전력의 약 4.4%를 사용했으며, DOE는 2028년에는 325~580TWh, 즉 미국 전체 전력의 약 6.7%에서 12%로 증가할 수 있다고 말합니다. “안전을 위해” 호스트를 대형화하는 것은 더 이상 공짜가 아니며 전력, 냉각, 랙 밀도 및 조달 예산에 영향을 미칩니다.

그리고 다운타임은 여전히 잔인합니다.

그리고 업타임 인스티튜트 2024 가동 중단 분석 에 따르면 응답자의 54%는 가장 최근에 발생한 심각한 중단으로 인해 $100,000달러 이상의 비용이 들었다고 답했으며, 16%는 $100만 달러 이상의 비용이 들었다고 답했습니다. 또한 응답자 5명 중 4명은 관리, 프로세스 또는 구성이 개선되었다면 최근 심각한 중단을 예방할 수 있었다고 생각한다고 답한 것으로 나타났습니다. VM 호스트 메모리 요구 사항이 추측에 기반한 것이라면 용량 워크시트에서 몇 줄을 절약하기 위해 6~7개의 숫자를 가지고 도박을 하는 것과 같습니다. 현명한가요?

대부분의 정중한 블로그 게시물에서 피하는 라이선스 각도도 있습니다.

2024년 4월, 로이터 보도 EU 규제 당국이 비즈니스 사용자 및 무역 단체의 불만을 제기한 후 VMware 라이선스 변경에 대해 Broadcom에 의문을 제기한 바 있습니다. 메모리 크기 조정만으로 라이선스 문제를 해결할 수 있다고 말하는 것이 아닙니다. 플랫폼 경제성이 면밀히 검토되고 모든 추가 호스트 또는 새로 고침 주기가 일일이 검토되는 상황에서 허술한 메모리 계획은 방어하기 더욱 어렵다는 것입니다.

프로덕션에서 실제로 신뢰할 수 있는 사이징 모델

다음은 모델입니다.

호스트가 무중력인 척하는 것은 가상화에서 가장 멍청한 습관 중 하나이기 때문에 저는 호스트 예약부터 시작합니다. Hyper-V는 관리 OS를 위한 메모리를 명시적으로 유지하며, Red Hat은 KVM 호스트에 자체 RAM 및 스왑 예산이 필요하다고 명시적으로 말하므로 “VM에서 사용 가능”과 “섀시에 설치됨”을 동일시하지 않습니다.”

그런 다음 부팅 시간 드라마가 아닌 정상 상태의 수요를 살펴봅니다.

Hyper-V의 경우 이는 부팅 후 동적 메모리가 회수할 수 있는 낮은 정상 상태 메모리에서 시동 RAM을 분리하는 것을 의미하며, VMware의 경우 작업 세트가 실제로 활성화되어 있는지 또는 게스트가 캐시를 쌓아두고 있는지를 관찰하는 것을 의미합니다. KVM의 경우 오버커밋이 기술적으로는 작동할 수 있지만 스왑과 경합이 실제 작업을 시작할 때 나쁜 운영 습관이 될 수 있다는 사실을 존중하는 것을 의미합니다.

다음은 단일 DIMM을 구매하기 전에 사용하는 계획표입니다:

워크로드 패턴	먼저 계산할 항목	피해야 할 사항	내 편견
혼합 프로덕션 가상 머신	관찰된 활성 메모리, 호스트 예약 및 N+1 페일오버 헤드룸	구성된 vRAM 총합에 따른 크기 조정	보수적
Hyper-V 사용량이 많은 환경	시동 RAM과 최소 RAM 및 버퍼 동작 비교	부팅 시 메모리에서 모든 VM을 영원히 잠그기	보통
KVM 통합	호스트 RAM, 스왑, 실제 게스트 수요	초과 커밋을 용량 대신 처리하기	보수적
VDI/저부하 풀	런타임 수요 및 재시작 동작	재부팅 압력 하에서 유휴 상태는 무해한 것으로 가정	보통
메모리 사용량이 많은 데이터베이스	최대 커밋 메모리 및 HA 이벤트	풍선 또는 스왑으로 절약하기	증거가 있는 경우에만 공격적

제 의견은요? 호스트 장애 또는 롤링 유지 관리 이벤트로 인해 나머지 클러스터가 패닉 상태로 전환되지 않도록 충분한 여유 RAM을 남겨 두세요. 저는 재시작 폭풍으로 인해 스마트 페이징, 스와핑 또는 풍선이 전면에 등장한 이유를 설명하는 것보다 재정에 대한 통합 비율이 약간 낮다고 설명하는 편이 낫습니다.

하드웨어 선택은 사람들이 인정하는 것보다 더 많은 것을 변화시킵니다.

DIMM도 중요합니다.

GB당 비용이 여전히 적용되는 오래된 클러스터를 새로 고치는 경우, 다음과 같은 카탈로그를 사용하면 됩니다. DDR4 서버 메모리 사용 는 반짝이는 이론이 아닌 실용적인 대화입니다. 최신 호스트를 더 밀도 있게 구축하는 경우, DDR5 서버 메모리 가 더 현실적인 경로가 되고, ServerDimm의 실시간 카테고리 페이지에는 DDR5 쪽에 마이크론 64GB DDR5-5600 2RX4, SK하이닉스 128GB DDR5-4800 2S2RX4와 같은 구체적인 부품이 표시됩니다. 호스트 자재 명세서를 승인하기 전에 실제로 원하는 종류의 인벤토리 세부 정보입니다.

브랜드 선택은 종교가 아닙니다. 그것은 호환성과 공급입니다.

서버딤의 현재 사이트 구조는 구매 로직으로 쉽게 엮을 수 있습니다. DDR4 서버 메모리 반대 마이크론 서버 메모리 모듈 또는 삼성 서버 RAM 인벤토리, 에 표시되는 제품 조합에는 삼성 64GB DDR4-3200 2RX4 및 마이크론 16GB DDR5-4800 1RX8과 같은 부품이 포함됩니다. 즉, 이 사이트는 이미 세대, 밀도, 브랜드, 예비 풀이 실제로 실행하는 클러스터와 일치하는지 여부 등 가상화 팀이 해야 할 정확한 대화를 지원합니다.

그리고 테스트는 선택 사항이 아닙니다.

사이트의 서버 메모리에 대한 품질 테스트 및 보증 지원 페이지는 사양 검토, 시스템 매칭, 호환성 검증 및 판매 후 지원과 직접적으로 관련이 있기 때문에 이 글에서 절대 빼놓을 수 없는 몇 안 되는 내부 링크 중 하나입니다. 메모리 계획은 도착, 부팅, 유지보수 기간 동안 살아남는 모듈만큼이나 중요하기 때문입니다.

자주 묻는 질문

가상화 호스트 메모리 요구 사항은 무엇인가요?

가상화 호스트 메모리 요구 사항은 호스트가 하이퍼바이저, 호스트 운영 체제, 관리 서비스, VM 작업 세트, 재시작 오버헤드 및 안전 헤드룸을 실행하는 데 필요한 총 물리적 RAM으로, 일상적인 작업에 풍선, 스와핑 또는 임시 페이징 메커니즘을 강제하지 않고도 실행할 수 있는 용량입니다.

그렇기 때문에 할당된 총 게스트 메모리를 기본 사이징 수치로 사용하지 않습니다. 저는 관찰된 수요와 호스트 예비 공간에 유지 관리 및 장애 이벤트에 대비할 수 있는 충분한 여유 공간을 더하여 사용합니다.

가상화 호스트에 실제로 필요한 RAM 용량은 얼마나 되나요?

가상화 호스트는 단순히 모든 게스트에 할당된 총 구성 메모리를 일치시키는 것이 아니라 호스트의 자체 예약 메모리, VM의 라이브 메모리 풋프린트, 하이퍼바이저 오버헤드, 재시작, 장애 복구 및 버스트 조건에 대한 추가 용량을 처리할 수 있는 충분한 RAM이 실제로 필요합니다.

정답은 “호스트 OS가 필요로 하는 것보다 많고, 모든 게스트 베니티 번호의 합계보다 적으며, 매립이 정상이 될 정도로 타이트하지 않아야 합니다.”입니다. 이는 회피가 아닙니다. 정직한 엔지니어링입니다.

가상화에서 메모리 오버커밋은 안전한가요?

가상화에서 메모리 오버커밋은 게스트에 할당된 총 메모리가 물리적 호스트 RAM을 초과하도록 허용하는 플랫폼 기능이지만 실제 워크로드가 압력 임계값 이하로 유지되고 운영자가 재구축을 통합을 위한 기본 비즈니스 모델이 아닌 비상 쿠션으로 취급하는 경우에만 안전합니다.

저는 현실에서 오버 커밋을 통제된 완충 장치로 사용하며, 특히 혼합 또는 버스트 에스테이트에서는 더욱 그렇습니다. 하지만 저는 유능해 보이기 위해 스왑, 풍선, 스마트 페이징에 의존하는 생산 계획을 세우지는 않습니다.

ESXi 호스트 메모리 요구 사항, Hyper-V 호스트 메모리 요구 사항 및 KVM 호스트 메모리 요구 사항의 차이점은 무엇입니까?

ESXi 호스트 메모리 요구 사항은 작업 설정 압력 및 매립을 중심으로, Hyper-V 호스트 메모리 요구 사항은 시동 RAM, 최소 RAM, 최대 RAM, 버퍼 및 호스트 예약을 중심으로, KVM 호스트 메모리 요구 사항은 Linux 호스트 동작, 스왑 가용성 및 오버 커밋이 실제 부족을 가리고 있는지 여부에 따라 크게 달라집니다.

이러한 차이 때문에 세 플랫폼 모두에 하나의 크기 비율을 복사하여 붙여넣는 것은 일반적으로 좋지 않은 생각입니다. 문제 유형은 같지만 메모리 메커니즘이 다릅니다.

가상화 호스트용으로 DDR4 또는 DDR5를 구매해야 하나요?

가상화 호스트용 DDR4 또는 DDR5는 플랫폼 세대, 목표 밀도, 스페어 풀 전략 및 조달 경제성에 따라 선택해야 하며, 구형 설치 제품군에는 DDR4가 더 적합하고 고용량, 고속 모듈 가용성의 이점이 있는 최신 고집적 노드에는 DDR5가 더 적합합니다.

클러스터가 오래되었고 저렴하고 검증된 용량이 필요하다면 여전히 DDR4를 선택하는 것이 합리적입니다. 최신 하드웨어에서 고집적 통합을 추진하는 경우 일반적으로 DDR5를 선택하는 것이 좋습니다.

다음 단계

숫자를 실행합니다. 그런 다음 다시 실행합니다.

제가 이 글을 ServerDimm에 게시한다면 막연한 영감으로 끝내지 않을 것입니다. 독자들에게 현재 호스트 리저브를 감사하고, 실제 활성 VM 메모리를 구성된 vRAM과 비교하고, 실제로 필요한 N+1 또는 재시작 헤드룸을 결정한 다음, 그 결과를 라이브 인벤토리와 비교하여 가격을 책정하라고 말하고 싶습니다. DDR4 서버 메모리, DDR5 서버 메모리, 및 사이트의 품질 테스트 및 보증 지원 리소스를 확인합니다. 그런 다음 자재 명세서가 실제라면 바로 다음 단계로 넘어갑니다. 서버딤 팀에 문의 부품 번호, 목표 용량, 호스트 모델 세부 정보가 포함되어 있습니다. 이렇게 하면 “얼마나 많은 RAM이 필요한가요?”라는 질문을 조달과 생산에서 살아남을 수 있는 대답으로 바꿀 수 있습니다.