가상화 메모리 계획 프로젝트에서 얻은 교훈

스프레드시트가 더 이상 도움이 되지 않는 날

기억은 거짓말을 합니다.

여기서는 클라이언트 이름보다 혼합 가상화 환경, 12개 호스트, 286개 VM, 목표 N+1 자세, 클러스터에 7.1TB의 RAM이 필요하다고 주장한 계획 시트(정상 상태 원격 측정에서 시작 스파이크, 게스트 캐시 폭증, 아무도 언급하고 싶지 않은 관리 오버헤드를 분리하면 4.2TB에 가까운 라이브 압력이 나타났음에도 불구하고)와 같은 패턴이 더 중요하므로 익명화된 조합을 사용했습니다. 익숙한 이야기인가요?

프로젝트를 망친 것은 첫날의 RAM 부족이 아니었습니다. 잘못된 프레임워크였습니다. 팀은 구성된 vRAM을 수요로 취급하고, 장애 조치를 각주로 처리하고, 조달을 기술 테스트가 아닌 마케팅 형용사처럼 취급했습니다. 저는 이 영화를 너무 많이 봤고, 항상 같은 방식으로 끝이 납니다. 긴급 재구성, 보기 흉한 유지 관리 창, 재무 담당자가 원래 메모리 계획이 왜 수백 기가바이트가 부족했는지 묻는 장면이죠.

작업 세트가 항상 베니티 RAM을 능가합니다.

VMware 메모리 관리가 허술하게 허용되지 않습니다.

세 가지 어려운 단어. 활성 메모리 측정.

Broadcom의 현재 vSphere 설명서에서는 여전히 결합된 메모리 오버 커밋에 대해 작업 메모리 풋프린트 호스트 메모리를 초과하는 가상 머신의 비율은 올바른 정신 모델이며, 많은 팀이 “할당된 총 RAM”이 “부하가 걸린 상태에서 실제로 닿는 공간”보다 Excel로 내보내기 쉽기 때문에 편리하게 무시하는 모델입니다. 운영자가 진실한 수치보다 더 쉬운 수치를 계속 선택하는 이유는 무엇일까요?

따라서 ServerDimm에서 가장 좋은 내부 점프는 다음과 같습니다. 가상화 호스트에 실제로 필요한 메모리는 얼마나 되나요?, 는 보기에는 좋지만 쓸모없는 vRAM 총계 대신 작업 설정 수학, 호스트 예비 공간 및 장애 조치 헤드룸으로 독자를 밀어붙이기 때문입니다. 그런 다음 설계가 구매로 이어집니다, 구매 전 서버 메모리 호환성을 확인하는 방법 를 클릭하는 것이 올바른 두 번째 클릭입니다. 이것이 바로 용량 계획에서 실제 자재 명세서까지 가는 길이며, 가상의 빌드가 아닙니다.

Hyper-V 동적 메모리는 한 가지 문제를 해결하고 게으름을 피우면 또 다른 문제를 일으킵니다.

부팅 동작이 중요합니다.

Microsoft의 자체 문서에 따르면 Hyper-V 동적 메모리는 시작 RAM과 최소 RAM을 분리하고, 시작 후 회수할 수 있으며, 사용 가능한 물리적 메모리가 없고 회수할 수 없는 경우에만 임시 재시작 브리지로 스마트 페이징을 사용하며, 스마트 페이징은 디스크에 의존하고 디스크가 메모리보다 느리기 때문에 성능이 저하될 수 있다고 경고하고 있습니다. 그렇다면 왜 사람들은 여전히 재시작 시 수요와 정상 상태 수요가 같은 것처럼 프로덕션 클러스터의 크기를 조정할까요?

Hyper-V가 많은 환경에서의 제 규칙은 잔인할 정도로 간단합니다: VM이 부팅하는 데 필요한 것, 실행하는 데 필요한 것, 새벽 2시 7분에 호스트 하나가 사라졌을 때 클러스터에 필요한 것을 계획합니다. 이 세 가지는 서로 다른 숫자이며, 이를 하나의 숫자인 것처럼 생각하면 RAM을 너무 많이 구입하거나 부족하게 구입하게 됩니다.

KVM이 과도하게 커밋되면 당황하게 됩니다.

Linux는 모든 것을 기억합니다.

Red Hat의 문서는 이 부분에 대해 이례적으로 직접적으로 설명합니다: KVM 게스트는 영구적으로 전용 물리적 RAM 블록을 얻지 못하고, 호스트는 필요에 따라 메모리를 할당하며, 오버 커밋에는 머신 자체를 지원할 수 있는 충분한 스왑 및 호스트 메모리가 필요하며, Red Hat은 오버 커밋이 다음과 같다고 단호하게 말합니다. not 일반적인 메모리 부족에 대한 이상적인 해결책입니다. 이는 미묘한 공급업체의 언어가 아닙니다. 그것은 경고 라벨입니다. 왜 그렇게 많은 팀이 여전히 오버커밋을 비즈니스 모델로 취급하고 있을까요?

다음은 더 많은 팀이 단일 DIMM을 구입하기 전에 구축했으면 하는 표입니다:

계획 바로 가기	미팅의 모습	프로덕션에서 실제로 중요한 것	내 평결
구성된 vRAM의 합계	“가상 머신이 7TB에 달하기 때문에 7TB가 필요합니다.”	관찰된 작업 세트, 호스트 예약, 재시작 동작, N+1 헤드룸	나쁜 수학
평균 사용률만	“메모리는 62%를 넘지 않습니다”	재부팅, 패치, 백업, 장애 조치 및 시끄러운 이웃이 있는 동안 피크가 발생합니다.	거짓 위안
기본적으로 오버 커밋	“하이퍼바이저가 나중에 회수할 수 있습니다”	매립은 정상이 아닌 드문 경우여야 합니다.	계획이 아닌 비상 쿠션
가장 저렴한 호환 모듈	“동일한 용량, 더 낮은 단가”	검증, 토폴로지, 모듈 클래스, 추적성, 보증 경로	나중에 비싸게
스피드 스티커 집착	“5600 MT/s이므로 보장됩니다.”	플랫폼, 인구, 채널 균형에 따른 실제 훈련 속도	일반적으로 잘못 알려진 오해

그리고 예, 이것이 바로 ServerDimm 내부 클러스터 주변의 서버 메모리에 대한 품질 테스트 및 보증 지원 그리고 구매 전 서버 메모리 호환성을 확인하는 방법 가 독자를 무작위 제품 페이지로 몰아넣는 것보다 이 글에 더 잘 어울립니다. 유효성 검사 단계에서 죽는 메모리 계획은 애초에 좋은 계획이 아니었습니다.

잘못된 메모리 계획으로 인해 비용이 더 많이 들었습니다.

이제 전원이 켜집니다.

그리고 로렌스 버클리 국립연구소의 2024년 미국 데이터 센터 에너지 사용량 보고서 는 미국 데이터 센터가 176 TWh 2023년 또는 4.4% 의 미국 전체 전력 사용량을 차지하며 대략적으로 325 ~ 580 TWh 2028년까지 6.7% ~ 12.0% 를 차지합니다. “안전을 위해” 메모리를 오버사이징하는 것은 예전에는 게으른 일이었습니다. 이제는 게으르고 비용이 많이 듭니다. 아직도 RAM 계획이 진공 상태라고 생각하는 사람이 있을까요?

다운타임은 여전히 예산을 낭비합니다.

에 따르면 2024 가동 시간 연구소 가동 중단 분석, 54% 의 응답자가 가장 최근의 심각한 정전으로 인해 다음과 같은 비용이 발생했다고 답했습니다. $100,000, 16% 보다 더 많은 비용이 들었다고 말했습니다. $1 백만, 그리고 5명 중 4명은 더 나은 관리, 프로세스 또는 구성으로 최근의 심각한 서비스 중단을 예방할 수 있었다고 답했습니다. 누군가 얇은 메모리 버퍼가 “효율적”이라고 말할 때 생각나는 수치입니다. 누구에게 효율적일까요?

그리고 플랫폼 경제학은 더 추악해졌습니다.

2024년 4월, 브로드컴의 VMware 라이선스 변경에 대한 EU의 조사에 대한 로이터 통신의 보도, 는 비즈니스 사용자와 업계 단체의 불만이 제기된 후 도입되었습니다. 저는 메모리 계획만으로 라이선스 문제를 해결한다고 주장하는 것이 아닙니다. 소프트웨어 경제성이 현미경으로 들여다보는 또 다른 항목이 되면서 부실한 호스트 설계에 대한 여지가 줄어들었다는 말입니다. 운영이나 재무 측면에서 방어할 수 없는 메모리 계획을 세우는 이유는 무엇일까요?

조달은 좋은 디자인이 죽어가는 곳입니다.

가격 필터를 능가하는 호환성

이 부분은 지루합니다.

서버딤의 더 스마트한 내부 움직임은 “RAM이 더 필요합니다”에서 바로 쇼핑 카테고리로 이동하는 것이 아니라 독자를 다음과 같은 경로로 라우팅하기 때문에 프로젝트를 절약하는 부분이기도 합니다. 구매 전 서버 메모리 호환성을 확인하는 방법 를 통해 서버 메모리에 대한 품질 테스트 및 보증 지원, 에서 이미 사양 검토, 모듈 클래스 확인, 시스템 매칭 및 판매 후 지원에 의존하고 있습니다. 잘못된 PO를 막을 수 있는 유일한 단계를 건너뛰는 이유는 무엇일까요?

부품 번호는 서류 작업이 아닙니다.

라벨을 읽습니다.

구매자가 OEM 라벨과 모듈의 실제 제조업체 식별을 계속 혼동하는 경우 올바른 내부 앵커는 다음과 같습니다. OEM 부품 번호와 DRAM 제조업체 부품 번호 비교, 이 사이트가 조달 속기와 기술적 진실을 분리하는 화려하지는 않지만 꼭 필요한 작업을 수행하기 때문입니다. 저는 이 말도 안 되는 문제로 며칠을 허비하는 팀들을 보아왔는데, 항상 “하지만 리셀러가 일치한다고 했어요.”라는 말만 되풀이하곤 합니다. 언제부터 “말했다”가 검증 방법이 되었나요?

DDR4와 DDR5는 분위기가 아닌 플랫폼의 결정입니다.

새로 고침 주기를 낭만적으로 생각하지 마세요.

클러스터가 오래되고 유지 관리가 많은 자산인 경우, DDR4 서버 메모리 사용 밀도, 모듈 크기, 더 긴 런웨이가 더 중요하다면 실용적인 대화입니다, DDR5 서버 메모리 사용 및 관련 DDR4와 DDR5 서버 메모리 비교: 선택 방법 가이드가 더 나은 내부 브랜치입니다. ServerDimm의 라이브 카테고리 페이지에는 이미 64GB, 96GB, 128GB급 DDR5 옵션과 함께 주력 DDR4 부품이 표시되어 있는데, 이는 가상화 팀이 용량 모델을 호스트 수용 계획으로 변환할 때 필요한 세부 사항입니다. “미래를 대비한” 허울 좋은 말보다 더 솔직한 구매 대화가 아닐까요?

첫날부터 다르게 행동할 것

저는 작게 시작하죠.

설치된 메모리가 더 작아지는 것이 아니라 가정이 더 작아집니다: 90일간의 실제 원격 측정을 가져오고, 시작 메모리와 런타임 메모리를 분리하고, 게스트 수요에 대해 이야기하기 전에 호스트 오버헤드를 예약하고, 프로젝트 팀에서 하드웨어 견적을 승인하기 전에 호스트 장애, 유지 관리 주기, 비정상적인 재시작 파동을 한 번 모델링하도록 합니다.

그러면 더 엄격해지겠죠.

정확한 플랫폼 규칙, 정확한 모듈 클래스, 정확한 부품 번호 로직에 계획을 잠근 다음 다음 항목에 대해 소싱 경로를 압력 테스트합니다. 구매 전 서버 메모리 호환성을 확인하는 방법, OEM 부품 번호와 DRAM 제조업체 부품 번호 비교, 및 서버 메모리에 대한 품질 테스트 및 보증 지원. 제 경험상 대부분의 “메모리 용량” 실패는 실제로는 규율의 실패입니다.

자주 묻는 질문

가상화 용량 계획이란 무엇인가요?

가상화 용량 계획은 관찰된 워크로드 수요, 하이퍼바이저 오버헤드, 호스트 운영 체제 예약, 재시작 동작 및 장애 조치 목표를 결합하여 호스트 및 클러스터 리소스의 크기를 조정하는 분야이므로 인프라 팀은 프로비저닝된 vRAM 합계로 생성된 예쁜 숫자를 믿지 않고 실제 운영 환경에 맞는 충분한 RAM과 CPU를 구매합니다. 저는 스프레드시트 합계를 신뢰하는 것보다 원격 측정과 장애 모델링을 훨씬 더 신뢰합니다.

가상화에서 메모리 오버커밋이란 무엇인가요?

메모리 오버커밋은 게스트 머신에 할당된 총 메모리가 호스트에 설치된 물리적 RAM을 초과하는 가상화 기능으로, 작업 세트가 증가하여 호스트가 더 이상 활성 수요를 직접 충족할 수 없는 경우 하이퍼바이저 재생, 벌룬, 페이징 또는 스왑 관련 메커니즘을 통해 부족분을 처리할 수 있습니다. 이는 유용할 수 있지만 기본 설계 전략이 아닌 버퍼로 취급할 때만 유용합니다.

RAM을 초과 구매하지 않고 가상 머신의 메모리를 계획하려면 어떻게 해야 하나요?

가상 머신의 메모리를 계획하는 올바른 방법은 정상 상태의 활성 사용량을 측정하고, 시작 메모리와 런타임 메모리를 분리하고, 호스트 예비 공간을 추가하고, N+1 또는 유지 관리 헤드룸을 포함한 다음, 구매 주문이 출시되기 전에 정확한 서버 플랫폼과 비교하여 최종 모듈 토폴로지를 검증하는 것입니다. 이 접근 방식은 추측보다 느리고 재작업보다 훨씬 저렴합니다.

Hyper-V 동적 메모리는 프로덕션 환경에서 안전한가요?

Hyper-V 동적 메모리는 시작 RAM, 최소 RAM, 최대 RAM 및 버퍼 설정이 실제 부팅 및 워크로드 동작에 맞게 조정되는 경우 프로덕션 환경에서 안전한 메모리 관리 기능이지만, 팀이 스마트 페이징을 임시 재시작 브리지 대신 정상적인 작동 용량인 것처럼 가정하면 위험해집니다. 저는 프로덕션 환경에서 기꺼이 사용하지만 아무도 재시작 수학을 설명할 수 없을 때 즉시 불신하게 됩니다.

가상화 호스트에 DDR4 또는 DDR5를 사용해야 하나요?

성숙한 플랫폼과 비용에 민감한 유지보수 주기에 묶여 있는 가상화 호스트에는 DDR4가 더 나은 선택이며, 12개월 내에 호스트를 다시 재구축하지 않고 통합을 위해 고밀도 RDIMM, 더 많은 대역폭, 더 긴 런웨이가 필요한 최신 서버에는 DDR5가 더 나은 선택입니다. 플랫폼이 먼저 결정하고 예산은 두 번째로 고려해야 합니다.

다음 단계

추악한 감사를 하세요.

90일간의 호스트 메모리 원격 측정을 가져오고, 모든 중요 VM에 대한 시동 RAM 및 정상 상태 수요를 나열하고, 하나의 호스트 장애를 모델링한 다음, 그 결과를 다음과 같이 안내합니다. 가상화 호스트에 실제로 필요한 메모리는 얼마나 되나요?, 구매 전 서버 메모리 호환성을 확인하는 방법, 및 서버 메모리에 대한 품질 테스트 및 보증 지원 에 문의하세요. 숫자가 깨끗해지면 정확한 플랫폼, 용량 목표 및 선호하는 모듈 목록을 서버딤 연락처 페이지. 이것이 바로 희망 구매를 중단하고 실제로 생산에서 살아남을 수 있는 메모리 구매를 시작하는 방법입니다.