고밀도 가상화 프로젝트에서 흔히 발생하는 메모리 업그레이드 실수

더러운 비밀: 대부분의 가상화 메모리 계획은 허구입니다.

수학부터 시작하세요.

가상화 메모리 업그레이드는 활성 메모리, 호스트 오버헤드, NUMA 동작, 재시작 압력, HA 장애 복구 예약 및 DIMM 인구 규칙을 측정한 후 시작해야 하지만, 여전히 팀에서 “VM 수 × 할당된 RAM”을 곱하고 불안한 20%를 더한 후 이를 엔지니어링이라고 부르는 것을 봅니다.

스마트 인프라 팀이 양동이를 채우듯 메모리를 계속 구매하는 이유는 무엇일까요?

할당된 메모리는 객관적으로 느껴집니다. 그렇지 않습니다. 64GB가 할당된 VM은 정상 업무 시간에는 18GB, 월말 보고 시에는 42GB, 패치 재부팅 폭주 시에는 58GB가 실제로 필요할 수 있습니다. 30개의 VM을 실행하는 호스트는 스프레드시트 신뢰도에 신경 쓰지 않습니다. 작업 세트, 압축, 벌룬, 호스트 스와핑, 그리고 실패한 노드가 새벽 2시 17분에 생존 노드에 압력을 가하는지 여부에 신경을 씁니다.

이것이 바로 고밀도 가상화 메모리 프로젝트가 잘못되는 부분입니다. RAM이 신비해서가 아닙니다. 사람들이 단순하다고 생각하기 때문입니다.

그리고 업타임 인스티튜트 글로벌 데이터 센터 설문조사 2024 에 따르면 지난 3년 동안 531개 사업자가 서비스 중단을 경험했으며, 최근 심각한 서비스 중단을 경험한 응답자 중 541개 사업자가 100만 달러 이상의 비용이 들었다고 답해 5명 중 1명은 100만 달러 이상의 비용이 들었다고 답했습니다. 이것이 바로 “메모리만 더 추가하면 된다”는 재정적 배경입니다. 클러스터에 ERP, SQL Server, Oracle, VDI, Kubernetes 노드, 백업 프록시, 도메인 서비스가 포함된 경우 잘못된 계획은 기술적으로 큰 골칫거리가 됩니다.

그래서 여기에 제 의견이 있습니다: 메모리 업그레이드는 일반적으로 프로젝트가 아닙니다. 이 프로젝트는 다음 장애 이벤트가 용량 모델의 거짓을 드러내지 않을 것임을 증명하고 있습니다.

모듈을 구매하기 전에 기준선이 필요한 경우 ServerDimm의 가이드를 참조하세요. 가상화 호스트에 실제로 필요한 메모리 양 는 할당된 원시 용량이 아닌 Hyper-V 시동 RAM, VMware 작업 세트 동작 및 오버 커밋 제한을 중심으로 질문을 구성하기 때문에 내부적으로 적합한 솔루션입니다.

실수 1: 할당된 VM RAM을 실제 수요로 취급하기

잘못된 수학이 퍼집니다.

고밀도 호스트 계획을 검토할 때 첫 번째 위험 신호는 모든 VM이 구성된 메모리를 영구적으로 소비하는 것처럼 취급되는 용량 테이블입니다. 이 방법은 일부 워크로드를 과장하고 버스트 위험을 과소평가하며 재시작 압력을 숨기고 재무팀이 실제로는 위안이 되는 허구를 생성했을 때 심각한 예측을 생성했다고 생각하게 만들기 때문입니다.

모든 VM이 서류상으로만 “적절한 크기”라면 어떻게 될까요?

VM 메모리 용량 계획은 이러한 숫자를 분리해야 합니다:

계획 지표	실제 의미	가상화 메모리 업그레이드가 중요한 이유
할당된 메모리	VM에 구성된 최대 게스트 RAM	한도에는 유용하지만 구매 결정에는 충분하지 않습니다.
활성 메모리	워크로드가 실제로 영향을 미치는 메모리	실제 밀도 계획을 위한 최적의 출발점
사용된 메모리	현재 VM이 보유한 호스트 메모리	게스트 캐시 및 유휴 할당을 포함할 수 있습니다.
시동 메모리	부팅 또는 서비스 초기화에 필요한 RAM	Hyper-V 동적 메모리 및 VDI 풀에 특히 중요
장애 조치 예약	호스트 손실 후 필요한 RAM	대부분의 팀이 은근히 부족한 자금
하이퍼바이저 오버헤드	ESXi, Hyper-V, 관리 에이전트, 드라이버 및 VM 메타데이터에서 사용하는 메모리	VM당 소규모, 규모에 따른 고통
스왑 또는 페이징 압력	디스크 백업 메모리 부족 시 동작	일반적으로 클러스터가 거짓말을 하고 있다는 첫 번째 징후는 다음과 같습니다.

VMware의 자체 vSphere 8.0 성능 지침에 따르면 ESXi는 페이지 공유, 볼루닝, 메모리 압축, 호스트 캐시로 스왑 및 일반 스왑을 사용할 수 있지만 일반 호스트 수준 스왑으로 활성 메모리 페이지를 이동할 정도로 메모리를 과도하게 커밋하는 것에 대해 경고하고 있습니다. 이 문장은 모든 가상화 메모리 업그레이드 승인에 인쇄되어야 합니다.

일부 관리자는 오버 커밋 비율을 좋아한다는 것을 알고 있습니다. 좋습니다. 하지만 워크로드 구성이 파일 서버와 도메인 컨트롤러에서 SQL Server, Redis, Elasticsearch, Citrix 및 Windows 11 VDI로 변경된 경우 “작년에 4:1이 효과가 있었다”는 것은 전략이 될 수 없습니다. 워크로드 정체성이 없는 비율은 숫자놀음에 불과합니다.

실수 2: 하이퍼바이저 트릭이 물리적 RAM을 대체할 수 있다고 믿기

오버 커밋은 자유롭게 느껴집니다.

그러나 VMware 메모리 관리 및 Hyper-V 메모리 최적화는 마법이 아니라 워크로드가 측정되고 게스트 툴이 정상이며 예약이 정상이고 관리자가 유휴 메모리를 회수하는 것과 느린 스토리지를 통해 활성 메모리를 강제 할당하는 것의 차이를 이해할 때 제대로 작동하는 압력 관리 시스템입니다.

프로덕션 SAN이 항상 비상 모드에서 실행될 수 있다고 가정하고 설계하시겠습니까?

Microsoft의 현재 Hyper-V 동적 메모리 설명서에 따르면 시작 RAM, 최소 RAM, 최대 RAM, 메모리 버퍼 및 메모리 무게가 모두 중요하며 스마트 페이징은 물리적 메모리를 사용할 수 없을 때 특정 재시작 조건에 대해 존재합니다. 또한 스마트 페이징은 디스크 액세스가 메모리 액세스보다 훨씬 느리기 때문에 VM 성능을 저하시킬 수 있다고 Microsoft는 언급합니다.

이것이 바로 함정입니다. 스마트 페이징은 다리입니다. 고속도로가 아닙니다.

Hyper-V에서 저는 팀이 밀도를 승인하기 전에 VM이 시동 RAM에서 부팅할 수 있고, 최소 RAM 근처에서 안전하게 정착하며, 스토리지 계층을 가짜 RAM으로 전환하지 않고 호스트 재시작 또는 장애 조치 이벤트에서 살아남는다는 세 가지 사항을 증명하기를 원합니다. VMware에서는 비즈니스 피크 전반에 걸쳐 활성 메모리, 사용된 메모리, 볼루닝, 압축, 호스트 스왑, 게스트 스왑, 예약 및 HA 허용 동작을 확인하고자 합니다.

불편한 질문은 “오늘 호스트가 실행될 수 있는가?”가 아닙니다. 백업, 패치, 로그인 폭풍, 보고 작업이 충돌하는 동안 클러스터가 노드 손실을 흡수할 수 있는가 하는 것입니다.

더 자세한 내부 참조를 원하시면 ServerDimm의 가상화 메모리 계획 프로젝트에서 얻은 교훈 동적 메모리, 스마트 페이징 및 오버커밋에 작동 제한이 필요한 이유를 설명할 때 사용합니다.

실수 3: DIMM 유형, 순위 및 슬롯 개수를 확인하기 전에 용량 구매하기

슬롯이 중요합니다.

총 용량이 완벽해 보여도 서버 RAM 업그레이드가 실패할 수 있는 이유는 Dell PowerEdge, HPE ProLiant, Lenovo ThinkSystem, Cisco UCS 및 Supermicro 플랫폼 모두 전기, 채널, CPU 소켓, 속도, 순위 및 DIMM 유형 규칙을 적용하여 견적의 매력도와는 무관하게 적용하기 때문입니다.

구매자가 인구 지도를 알기 전에 여전히 “64GB 스틱을 더 달라”고 요청하는 이유는 무엇인가요?

솔직하게 말씀드리자면, 조달은 종종 너무 늦게 그리고 너무 적은 기술적 맥락으로 프로젝트에 참여하기 때문입니다. 공급업체가 요청을 받았을 때 구매자는 “호스트당 256GB 추가”를 원하는 것이지 “이 서버의 지원되는 CPU 소켓 2개에 걸쳐 32GB DDR4-3200 ECC RDIMM 2Rx4 모듈 8개”를 원하는 것이 아니기 때문입니다.”

그 차이가 전부입니다.

서버딤의 서버 메모리 모집단 순서 가이드 는 인구 순서가 중요하지 않기 때문에 여기서 유용합니다. 채널 균형, 인터리빙, 속도 훈련, CPU 대칭성, 호스트가 고밀도 가상화 노드처럼 실행되는지 아니면 불균형한 구성으로 절뚝거리는지 여부에 영향을 미칩니다.

Dell PowerEdge R740, HPE ProLiant DL380 Gen10, Lenovo ThinkSystem SR650과 같은 구형 호스트의 경우, 표준화된 DDR4 서버 메모리 소싱 경로 는 일반적으로 무작위 혼합 로트보다 더 합리적입니다. 4세대 인텔 제온 스케일러블, AMD EPYC 9004, 델 파워엣지 R760, HPE Gen11, 레노버 SR650 V3 등 최신 밀도 프로젝트의 경우, DDR5 서버 메모리 옵션 32GB, 64GB, 96GB, 128GB 모듈로 전환할 수 있습니다.

하지만 용량은 호환성이 아닙니다.

64GB DDR4 LRDIMM은 64GB DDR4 RDIMM을 대체할 수 없습니다. 2Rx4 모듈과 4Rx4 모듈은 플랫폼 지원 방식이 다를 수 있습니다. 3200 MT/s 모듈은 CPU, 채널 수, 혼합 속도 규칙에 따라 다운클럭될 수 있습니다. 그리고 예, ECC 동작이 중요합니다.

실수 4: 유지 관리 기간까지 장애 시나리오를 무시하기

희망은 값비싼 것입니다.

가장 깨끗한 가상화 메모리 업그레이드 계획도 모든 호스트가 온라인 상태를 유지하고, 모든 워크로드가 평균을 유지하며, 모든 재부팅이 정상적으로 이루어지고, 모든 VM이 지난 화요일의 모니터링 그래프처럼 작동한다고 가정하면 여전히 실패할 수 있습니다.

실제 데이터 센터와 비슷하게 들리나요?

2023년 Google Cloud us-central1 인시던트 보고서는 메모리 압박이 학문적인 주제가 아니라는 점을 상기시켜 줍니다. Google은 관리 플레인 롤아웃으로 인해 가상 네트워크 라우터 컨트롤러의 메모리가 예기치 않게 증가한 후 메모리 부족과 재시작이 반복되어 Compute Engine, GKE, Cloud SQL, Dataflow, Dataproc, VPC for ho 등 여러 제품에 영향을 미쳤다고 보고했습니다.

다른 환경. 같은 교훈.

메모리 압박은 종속성을 통해 확산됩니다. 메모리 스트레스를 받는 호스트는 VM의 속도를 저하시킬 수 있습니다. 느린 VM은 트랜잭션 시간을 늘릴 수 있습니다. 트랜잭션이 길어지면 데이터베이스 메모리 수요가 증가할 수 있습니다. 백업 작업이 업무 시간에 실행될 수 있습니다. 사용자 세션이 다시 연결될 수 있습니다. 모니터링에 불이 켜집니다. 그러면 누군가 “하지만 클러스터의 RAM이 충분합니다.”라고 말합니다.”

아니요, 판타지 상태에는 충분한 램이 있었습니다.

NIST의 SP 800-125A에서는 하이퍼바이저를 CPU/GPU, 메모리, 네트워크, 스토리지 등의 물리적 리소스를 가상화하면서 가상 머신 간의 액세스를 중재하고 격리를 유지하는 소프트웨어 계층으로 설명합니다. 이는 단순한 편의 계층이 아니라 심각한 제어 지점입니다. 메모리 계획이 실패하면 폭발 반경은 하나의 대형 가상 머신에 국한되지 않습니다.

고밀도 클러스터의 경우 장애 조치 수학을 기록해 두어야 합니다:

시나리오	게으른 계획 가정	더 나은 계획 질문
N+1 호스트 장애	나머지 호스트가 부하를 흡수합니다.	호스트 스와핑 없이 최대 활성 메모리와 재시작 압력을 흡수할 수 있나요?
패치 재부팅 웨이브	VM이 점진적으로 다시 시작됨	40%의 VDI 또는 애플리케이션 VM이 20분 이내에 재부팅되면 어떻게 되나요?
백업 창 겹침	예측 가능한 백업 프록시	스냅샷, 중복 제거, 압축 및 전송 중 메모리 사용량은 얼마인가요?
데이터베이스 보고 급증	평균 RAM이면 충분합니다.	월말 마감 시 95번째 백분위수 메모리 수요는 얼마인가요?
혼합 DIMM 확장	더 많은 GB는 더 많은 헤드룸과 같습니다.	새 레이아웃은 채널 밸런스와 지원 속도를 유지하나요?
HA 입학 관리	클러스터 정책으로 충분합니다.	새 메모리 프로필을 적용한 후 테스트해 본 사람이 있나요?

실수 5: 중고, 풀링 또는 혼합 로트 메모리를 순전히 가격 결정으로만 취급하기

저렴해도 괜찮습니다.

하지만 고밀도 가상화 프로젝트에서는 새 메모리인지, 테스트를 거친 중고 메모리인지보다는 로트 추적이 가능한지, 라벨이 명확한지, 부품 번호가 승인된 사양과 일치하는지, 모듈이 심사를 통과하는지, 공급업체가 롤아웃을 비난하는 연습으로 바꾸지 않고 장애를 교체할 수 있는지에 더 신경을 씁니다.

승인된 유일한 유지보수 기간 동안 호스트 세 대가 메모리 트레이닝에 실패한 후에도 가장 저렴한 DIMM이 여전히 저렴한가요?

저는 풀 메모리 테스트에 도덕적 반대는 없습니다. 많은 레거시 DDR4 확장 프로젝트에서 이것이 현실적인 해답입니다. 어려운 진실은 “중고”는 위험 범주가 아니라는 것입니다. 미검증이 위험 범주입니다.

가상화 메모리 업그레이드를 위해 구매하기 전에 다음이 필요합니다:

• 서버 모델 및 CPU 세대
• 슬롯별 현재 DIMM 맵
• 호스트 및 클러스터당 목표 용량
• RDIMM 또는 LRDIMM 확인
• DDR4 또는 DDR5 세대
• 2Rx4 또는 2Rx8과 같은 순위 및 조직
• 속도 목표(예: DDR4-2933, DDR4-3200, DDR5-4800 또는 DDR5-5600)
• ECC 요구 사항
• 일치하는 로트 기본 설정
• 보증 및 RMA 프로세스
• 제품군 출시 전 파일럿 호스트 테스트

서버딤의 ECC RDIMM 프로젝트를 위한 품질 및 보증 워크플로 는 구매 프로세스에 자연스럽게 포함됩니다. 사양 검토, 호환성 검증, 배송 전 테스트, RMA 처리는 클러스터가 프로덕션 VM을 호스팅할 때 “좋은 추가 기능'이 아닙니다.

실수 6: 모니터링을 변경하지 않고 메모리 업그레이드하기

고통을 조심하세요.

RAM을 추가하고 대시보드, 알림 및 용량 임계값을 동일하게 유지하면 사용자가 압박감을 느끼기 전에 팀이 이를 파악하는 능력이 향상되지 않고 클러스터의 상한선이 높아질 수 있습니다.

아무도 남용되는 것을 알아채지 못한다면 더 큰 메모리 풀이 무슨 소용이 있을까요?

가상화 메모리 업그레이드 후에는 이러한 신호를 중심으로 모니터링을 재설정합니다:

플랫폼 영역	다음 신호 보기	일반적으로 공개되는 내용
VMware vSphere	활성 메모리, 사용 메모리, 풍선효과, 압축, 호스트 스왑, 게스트 스왑, 예약	과도한 커밋이 통제되는지 무모한지 여부
Microsoft Hyper-V	동적 메모리 수요, 할당된 메모리, 압력, 시동 RAM, 최소 RAM, 스마트 페이징 이벤트	동적 메모리가 재시작 위험을 돕거나 숨기는지 여부
게스트 OS	페이지 파일 사용량, 주요 결함, 작업 세트, 캐시 압력	VM 자체의 크기가 작은지 여부
클러스터 HA	입장 제어, 장애 조치 예약, 재시작 시간, VM 우선 순위	호스트 장애로 인해 계획이 중단되는지 여부
하드웨어	ECC 이벤트, 수정된 오류, 수정되지 않은 오류, 메모리 트레이닝 로그	모듈 및 슬롯의 작동 여부
애플리케이션	SQL 버퍼 풀, JVM 힙, Redis 최대메모리, Elasticsearch 힙, Citrix 세션 밀도	워크로드 메모리 크기가 정직하게 설정되었는지 여부

2022년 5월에 발생한 구글 빅쿼리 사건은 또 다른 유용한 경고입니다. Google은 롤아웃으로 인해 BigQuery 컴퓨팅 노드에서 점차적으로 메모리를 소모하는 메모리 누수가 발생하여 여러 지역에서 쿼리 지연 시간과 장애가 발생했으며, 메모리 오류 탐지기 적용 범위를 개선하고 메모리 압박 시나리오를 모니터링하는 등 문제를 해결했다고 보고했습니다.

기억력 문제는 종종 천천히 찾아왔다가 갑자기 찾아오는 경우가 많다는 것이 전문적인 교훈입니다.

내가 실제로 서명할 업그레이드 체크리스트

다음은 고밀도 가상화 메모리 주문을 승인하기 전에 인프라, 조달 및 재무팀에 제시하는 짧은 버전입니다.

체크포인트	합격 기준	하드 장애 징후
워크로드 측정	30~90일간의 활성 메모리 및 피크 데이터	크기 조정에는 할당된 RAM만 사용됩니다.
장애 조치 모델	재시작 압력으로 모델링된 N+1 또는 N+2	“HA가 활성화됨”은 증거로 간주됩니다.
하이퍼바이저 동작	VMware 또는 Hyper-V 메모리 메커니즘 이해 및 모니터링	풍선, 압축 또는 스마트 페이징 무시됨
DIMM 호환성	서버 모델, CPU, 세대, RDIMM/LRDIMM, 순위 및 모집단 확인됨	견적에는 “64GB 서버 RAM”이라고만 표시되어 있습니다.”
파일럿 출시	제품군 배포 전에 테스트한 호스트 또는 소규모 클러스터 1개	한 번의 유지보수 웨이브에 설치된 모든 DIMM
모니터링 업데이트	용량 변경 후 수정된 알림	업그레이드 전과 동일한 임계값
공급업체 유효성 검사	부품 번호, 라벨, 테스트, 보증 및 교체 경로 확인	문서 없이 혼합 로트 도착

소싱의 경우 가장 안전한 내부 경로는 다음과 같이 시작하는 것입니다. 엔터프라이즈 및 데이터센터 업그레이드를 위한 대량 서버 RAM 공급 공급업체에게 막연한 용량 목표 대신 실제 플랫폼 맵을 보내야 합니다. 좋은 공급업체는 성가신 질문을 해야 합니다. 잘못된 공급업체는 신속하게 배송하고 팀이 압박감 속에서 실수를 발견할 수 있도록 합니다.

자주 묻는 질문

가상화 메모리 업그레이드란 무엇인가요?

가상화 메모리 업그레이드는 모든 가상 머신에 할당된 총 메모리 대신 활성 워크로드 수요, 하이퍼바이저 오버헤드, HA 페일오버 예비, DIMM 호환성 및 지원되는 슬롯 수를 기준으로 가상화 호스트의 서버 RAM을 계획적으로 확장 또는 교체하는 것입니다. 실제로는 호스트를 정기적인 스와핑이나 지원되지 않는 DIMM 레이아웃으로 밀어 넣지 않고도 통합, 재시작 안전성, 애플리케이션 지연 시간 및 장애 조치 동작을 개선할 수 있습니다.

VM 메모리 용량 계획이란 무엇인가요?

VM 메모리 용량 계획은 게스트 활성 메모리, 워크로드 피크, 시작 동작, 메모리 오버헤드, 캐시 패턴, NUMA 경계, 스왑 없이 호스트 장애를 견디는 데 필요한 예비 공간을 측정하여 호스트 또는 클러스터에 필요한 물리적 RAM의 양을 계산하는 프로세스입니다. 가장 강력한 요금제는 1일 스냅샷이나 VM 인벤토리 내보내기가 아닌 30일에서 90일간의 실제 성능 데이터를 사용합니다.

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

가상화 메모리 오버커밋은 할당된 모든 메모리가 활발하게 사용되지 않을 때 메모리 공유, 벌룬, 압축, 페이징 또는 스왑 동작에 의존하여 호스트가 물리적으로 보유한 것보다 많은 게스트 메모리를 VM에 할당하여 워크로드를 계속 실행하는 관행입니다. 측정된 환경에서는 안전할 수 있지만 활성 메모리, 장애 조치 예약 및 스토리지 지원 스왑 동작이 무시되면 무모해집니다.

가장 일반적인 서버 RAM 업그레이드 실수는 무엇인가요?

서버 RAM 업그레이드 실수는 예방 가능한 계획 오류로, 팀이 플랫폼 지원, RDIMM 대 LRDIMM 규칙, ECC 요구 사항, 순위 구조, CPU-소켓 대칭성, BIOS 제한, 슬롯 인구 순서, 실제 가상화 워크로드에 대한 검증 테스트를 확인하기 전에 용량을 구매할 때 발생하는 실수입니다. 최악의 실수는 프로덕션 서버에서 용량이 같은 두 모듈을 자동으로 교체할 수 있다고 가정하는 것입니다.

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

Hyper-V 동적 메모리는 지원되는 Windows Server 배포에서 부팅 후 유휴 또는 저부하 가상 머신이 호스트 메모리를 덜 사용할 수 있도록 시작 RAM, 최소 RAM, 최대 RAM, 버퍼 및 메모리 가중치 설정을 사용하여 런타임에 할당된 메모리를 변경하는 Microsoft의 가상 머신 메모리 관리 기능입니다. 스마트 페이징은 조정 및 모니터링 시 프로덕션 환경에서 안전하지만, 정상적인 운영 용량이 아닌 임시 재시작 지원으로 취급해야 합니다.

VMware 메모리 관리는 업그레이드 계획에 어떤 영향을 줍니까?

VMware 메모리 관리는 활성 및 소비된 메모리 지표, 예약, 공유, 제한, 벌룬, 압축, 스왑-호스트 캐시 및 호스트 스왑 동작을 사용하여 프로덕션 워크로드를 실행하는 고집적 클러스터에서 물리적 호스트 메모리 압력에 대한 VM 성능의 균형을 맞추는 ESXi 리소스 제어 시스템입니다. VMware 메모리 업그레이드는 구성된 VM 메모리뿐만 아니라 활성 작업 세트 및 HA 동작을 중심으로 계획해야 합니다.

DIMM 구매 전 다음 단계

용량 숫자만으로는 다음 가상화 메모리 업그레이드를 승인하지 마세요.

호스트 인벤토리 가져오기, 30~90일간의 메모리 메트릭 내보내기, 최대 워크로드 윈도우 식별, N+1 장애 모델링, VMware 또는 Hyper-V 메모리 동작 확인, 모든 DIMM 슬롯 매핑, 서버 모델, CPU 세대, 현재 메모리 레이아웃, 목표 용량, RDIMM/LRDIMM 유형, DDR4 또는 DDR5 세대, 순위, 속도, ECC 요구 사항, 수량 및 롤아웃 일정을 포함한 견적 요청하기 등의 작업을 수행합니다.

그런 다음 주문이 배송되기 전에 유효성을 검사할 수 있는 공급업체에 문의하세요.

고집적 VMware, Hyper-V, VDI, 데이터베이스 및 프라이빗 클라우드 환경의 경우, ServerDimm의 엔터프라이즈 서버 메모리 소싱 지원 유지 보수 기간 동안 호환성을 증명하기 전에 견적을 작성하십시오.

ite.