Virtual Machine Memory Configuration

SQL Server에서 가장 중요한 시스템 리소스 중 하나는 메모리입니다. SQL Server 데이터베이스 엔진의 메모리 리소스가 부족하면 Windows Server가 메모리를 디스크로 페이징하도록 유도하여 메모리 액세스보다 상당히 느린 디스크 I/O 활동이 증가하게 됩니다[44]. 하이퍼바이저 메모리 리소스가 충분하지 않으면 메모리 경합이 발생하여 SQL Server 성능에 상당한 영향을 미칩니다.

SQL Server 배포가 가상화되면 하이퍼바이저는 게스트 운영 체제의 자체 메모리 관리 하위 시스템을 간섭하지 않고 게스트 OS를 알지 못한 채 가상 메모리 관리를 수행합니다[45].

게스트 OS는 연속적인 제로 기반 주소 지정이 가능한 물리적 메모리 공간을 보게 됩니다. 각 VM이 사용하는 서버의 기본 머신 메모리는 반드시 연속적일 필요는 없습니다.

그림 48. 가상 메모리, 게스트 메모리 및 물리적 메모리 간의 메모리 매핑

메모리 크기 조정 고려 사항

메모리 크기 조정 고려 사항은 다음과 같습니다:

  • VM 간 메모리 경합을 방지하기 위해 성능을 설계할 때는 ESXi 호스트 수준에서 메모리를 과도하게 커밋하지 않도록 합니다(HostMem >= VM 메모리 합계 - 오버헤드). 즉, 물리적 서버에 256GB의 RAM이 있는 경우 메모리 오버헤드도 고려하여 해당 서버에 상주하는 가상 머신에 이보다 많은 양을 할당하지 마십시오.
  • SQL Server를 실행하는 VM의 크기 결정을 위해 성능 메트릭을 수집할 때는 이 작업에 SQL Server의 기본 메트릭 쿼리 도구(DMV)를 사용하는 것을 고려하십시오. 메모리 소비/사용률과 관련하여 sys.dm_os_process_memory 카운터가 가장 정확한 보고를 제공합니다. SQL Server 메모리 관리 작업은 SQLOS 내부에 자체적으로 포함되어 있기 때문에 SQL DMV 카운터는 vSphere 카운터(“메모리 사용량”, “메모리 활성” 등) 또는 Windows 작업 관리자 메트릭에서 제공하는 것보다 이러한 메트릭에 대해 더 신뢰할 수 있고 권위 있는 측정값을 제공합니다.
  • VM에 메모리를 할당할 때 SQL Server 버전 관련 메모리 제한을 고려하십시오. 예를 들어, SQL Server 2017 Standard 에디션은 인스턴스당 최대 128GB 메모리를 지원하는 반면, SQL Server 2022 Enterprise 에디션의 관계형 데이터베이스 최대 메모리 용량은 524PB에 달합니다.
  • 운영상의 필요에 따라 “불균형 NUMA” 메모리 구성을 생성해야 하는 경우(구성된 메모리의 양이 단일 NUMA 노드 내에서 사용할 수 있는 양을 초과하는 반면 할당된 vCPU의 수는 NUMA 노드 내에 맞는 경우) 관리자는 할당된 메모리 크기를 수용하기에 충분한 가상 NUMA 노드를 보유하도록 VM을 사전에 구성할 것을 권장합니다.

메모리 오버헤드[46]

가상 머신의 전원을 켜려면 일정량의 사용 가능한 오버헤드 메모리가 필요합니다. 이 오버헤드의 양을 알고 있어야 합니다. 가상 머신에 필요한 오버헤드 메모리의 양은 vCPU 수 및 메모리 할당, 디바이스 수 및 유형, 모니터가 사용 중인 실행 모드, 가상 머신의 하드웨어 버전 등 여러 가지 요인에 따라 달라집니다.

사용 중인 vSphere의 버전도 필요한 메모리 양에 영향을 줄 수 있습니다. ESXi는 가상 머신에 필요한 오버헤드 메모리의 양을 자동으로 계산합니다. 특정 구성에 필요한 오버헤드 메모리의 양을 확인하려면 먼저 해당 가상 머신의 전원을 켭니다. vmware.log 파일을 확인합니다.

가상 머신의 전원이 켜지면 필요한 오버헤드 메모리의 양이 로그에 기록됩니다. 로그에서 “VMMEM"을 검색하여 가상 머신을 위해 예약된 초기 오버헤드 메모리의 정확한 양을 확인합니다.

메모리 예약

충분한 성능을 달성하는 것이 주요 목표인 경우 메모리 예약을 프로비저닝된 메모리와 동일하게 설정하는 것이 좋습니다. 이렇게 하면 벌루닝(ballooning) 또는 스왑이 발생할 가능성을 없애고 vSphere 클러스터에서 리소스 경합이 더 많이 발생하는 경우에도 가상 머신이 예약된 모든 메모리에 대한 독점적인 액세스 권한을 갖도록 보장할 수 있습니다.

VM에 프로비저닝할 메모리 양을 계산할 때는 다음 공식을 사용하십시오:

VM Memory = SQL Max Server Memory + ThreadStack + OS Mem + VM Overhead

ThreadStack = SQL Max Worker Threads * ThreadStackSize

ThreadStackSize = 1MB on x86
                = 2MB on x64   

OS Mem: 1GB for every 4 CPU Cores

SQL Server 메모리 성능 메트릭을 사용하고 데이터베이스 관리자와 협력하여 SQL Server 최대 서버 메모리 크기와 최대 작업자 스레드 수를 결정합니다.

그림 49. 메모리 예약 설정

  • 메모리 예약을 설정하면 vSphere vMotion이 제한될 수 있습니다. 대상 ESXi 호스트에 예약된 메모리 크기보다 크거나 예약되지 않은 메모리가 있는 경우에만 VM을 마이그레이션할 수 있습니다.
  • 모든 메모리를 예약하면 스왑 파일 생성이 비활성화되고 특히 할당된 메모리가 많은 VM과 호스트에서 실행되는 유일한 VM인 경우 디스크 공간을 절약할 수 있습니다.

“Reserve all guest memory” 확인란이 설정되어 있지 않은 경우 호스트 스왑 관련 카운터(스왑 인/아웃, 스왑)를 모니터링하는 것이 좋습니다. 스왑은 호스트가 VM에 물리적 메모리를 할당하기 위한 최후의 수단이며 혼잡 중에만 발생하지만, 스왑된 VM 메모리는 혼잡 상태가 사라지더라도 스왑된 상태로 유지됩니다. 예를 들어 확장 유지 관리 또는 재해 복구 중에 ESXi 호스트에 메모리 정체가 발생하고 모든 VM 메모리가 예약되지 않은 경우 호스트는 VM 메모리의 일부를 스왑합니다. 이 메모리는 자동으로 스왑 해제되지 않습니다. 스왑된 메모리가 확인되면 vMotion을 실행하고 VM을 종료한 후 전원을 켜거나 언스왑 명령[47]을 사용하여 스왑된 부분에 대한 물리적 메모리 백업을 회수하는 것이 좋습니다.

메모리 제한

VM과 VM이 호스팅하는 애플리케이션에 도움이 되는 메모리 예약과 달리 메모리 제한 설정은 VM이 할당된 리소스를 모두 사용하는 데 방해가 됩니다. 이는 제한이 VM의 컴퓨팅 리소스 권한에 대한 엄격한 상한이기 때문입니다. VM에 대한 제한을 생성하여 VM에 할당되는 CPU, 메모리 또는 스토리지 I/O 리소스의 양을 제한할 수 있습니다.

vSphere 관리자는 일반적으로 표준 운영 절차의 일부로 VM 템플릿에 제한을 설정합니다. 이는 불필요한 리소스 소비를 방지하기 위한 것입니다(일반적으로 테스트 배포 시나리오의 경우). 이 관행의 단점 중 하나는 관리자가 동일한 템플릿을 사용하여 제한에 지정된 것보다 더 많은 리소스가 필요한 미션 크리티컬 SQL Server 워크로드를 배포할 때 일반적으로 이 설정을 잊어버린다는 것입니다.

“Limit"은 다른 고려 사항보다 우선하기 때문에, 예를 들어 메모리 제한이 64GB인 VM은 그 이상의 리소스가 할당되더라도 64GB를 초과하는 리소스는 절대 받을 수 없습니다. VM의 메모리 500TB에 대해 전체 예약을 설정해도 해당 VM의 메모리 리소스에 64GB 제한이 있다는 사실은 변하지 않습니다.

관리자는 SQL Server 인스턴스를 실행하는 VM에 할당된 컴퓨팅 리소스에 제한을 설정하지 않는 것이 좋으며, 이러한 대용량 VM에서 성능 관련 문제를 해결할 때 항상 제한을 확인하는 것을 잊지 말아야 합니다. 리소스 소비를 제어하기 위해 제한을 사용하는 대신 적절한 벤치마킹 작업을 수행하여 VM의 크기를 적절하게 조정하는 데 필요한 적절한 리소스 양을 추정하는 것이 좋습니다.

그림 50. 메모리 제한 구성

Balloon 드라이버

ESXi 하이퍼바이저는 사용 중인 메모리와 여유 메모리에 대한 게스트 Windows Server 메모리 관리 테이블을 인식하지 못합니다. VM이 하이퍼바이저에 메모리를 요청할 때 ESXi는 해당 요청을 수용하기 위해 물리적 메모리 페이지를 할당합니다. 게스트 OS가 해당 페이지 사용을 중지하면 운영 체제의 사용 가능한 메모리 테이블에 해당 페이지를 기록하여 해제하지만 페이지에서 실제 데이터는 삭제하지 않습니다. ESXi 하이퍼바이저는 운영 체제의 사용 가능 및 사용 중인 테이블에 액세스할 수 없으므로 하이퍼바이저의 관점에서 해당 메모리 페이지가 여전히 사용 중일 수 있습니다. 하이퍼바이저 호스트에 메모리 압박이 발생하여 하이퍼바이저가 VM에서 일부 메모리를 회수해야 하는 경우, 하이퍼바이저는 벌룬 드라이버를 활용합니다. VMware Tools™[48]와 함께 설치되는 벌룬 드라이버는 게스트 OS에 대량의 메모리를 할당하도록 요청합니다. 게스트 OS는 여유 목록에서 메모리를 해제하거나 유휴 상태인 메모리를 해제합니다. 이렇게 하면 디스크에 페이징되는 메모리는 하이퍼바이저가 아닌 OS 알고리즘 및 요구 사항에 따라 결정됩니다. 메모리는 비례 점유율이 낮은 VM에서 회수되어 비례 점유율이 높은 VM에 할당됩니다. 이는 하이퍼바이저가 비례 공유 메커니즘이라는 사전 구성된 정책을 기반으로 VM에서 메모리를 회수하는 지능적인 방법입니다.

성능을 위해 SQL Server를 설계할 때 페이징이 발생할 가능성을 없애는 것이 목표입니다. VM의 메모리 예약을 프로비저닝된 메모리 크기로 설정하여 하이퍼바이저가 게스트 OS에서 메모리를 회수할 수 있는 기능을 비활성화합니다. 서비스 손실을 방지하기 위해 필요할 수 있는 코너 케이스를 위해 벌룬 드라이버를 설치한 상태로 두는 것이 좋습니다. 벌룬 드라이버가 필요할 수 있는 경우를 예로 들어 두 개의 호스트 장애에 대비하여 설계된 16개의 물리적 호스트로 구성된 vSphere 클러스터를 가정해 보겠습니다. 정전으로 인해 4개의 호스트에 장애가 발생하는 경우 클러스터에 장애가 발생한 VM의 전원을 켜는 데 필요한 리소스가 없을 수 있습니다. 이 경우 벌룬 드라이버는 게스트 운영 체제를 강제로 페이징하여 메모리를 회수할 수 있으므로 중요한 데이터베이스 서버가 비즈니스에 가장 방해가 적은 방식으로 계속 실행될 수 있습니다.

호스트와 VM 수준에서 풍선 메모리에 대한 모니터링을 구현하는 것이 좋습니다. vCenter Web Client의 “ballooned memory” 카운터를 사용하여 알람을 구성하거나 VMware Aria Operations와 같은 특수 툴을 사용할 수 있습니다.

  • 때때로 볼루닝을 Microsoft의 Hyper-V 동적 메모리 기능과 혼동하는 경우가 있습니다. 이 둘은 동일하지 않으며 SQL Server 배포에 대한 동적 메모리 비활성화에 대한 Microsoft의 권장 사항은 VMware 벌룬 드라이버에는 적용되지 않습니다.

메모리 핫 플러그

CPU 핫 플러그와 마찬가지로 메모리 핫 플러그를 사용하면 VM 관리자가 다운타임 없이 VM에 메모리를 추가할 수 있습니다. vSphere 6.5 이전에는 vNUMA가 활성화된 VM에서 메모리 핫 추가를 구성하면 항상 node0에 메모리가 추가되어 NUMA 불균형이 발생했습니다[49]. vSphere 6.0 이상에서는 메모리 핫 플러그를 사용하도록 설정하고 VM에 메모리를 추가할 때 메모리가 두 vNUMA 노드에 균등하게 추가되므로 더 많은 사용 사례에서 이 기능을 사용할 수 있습니다. VMware는 메모리 소비 패턴을 쉽고 정확하게 예측할 수 없는 경우에만 메모리 핫 플러그 기능을 사용할 것을 권장하며, 이는 vSphere 6.0 이상에서만 가능합니다. VM에 메모리를 추가한 후 인스턴스의 최대 메모리 설정이 설정되어 있는 경우 이를 늘립니다. 이 작업은 SQL Server의 대용량 메모리 페이지가 사용되어 서비스 재시작이 필요한 경우가 아니라면 서버를 재부팅하거나 SQL Server 서비스를 다시 시작하지 않고도 수행할 수 있습니다. CPU 핫 플러그와 마찬가지로 메모리 핫 플러그보다 권한 크기 조정에 의존하는 것이 좋습니다. 이 기능을 사용할지 여부는 사례별로 결정해야 하며 SQL Server를 배포하는 데 사용되는 VM 템플릿에서 구현해서는 안 됩니다.

그림 51. 메모리 핫 플러그 설정

Persistent Memory

Non-Volatile Memory(NVM)라고도 하는 Persistent Memory (PMem)는 정전 후에도 메모리 DIMM의 데이터를 유지할 수 있습니다. 이 기술 계층은 메모리의 성능과 기존 스토리지의 지속성을 제공합니다. PMem 지원은 vSphere 버전 6.7에 도입되었으며 현재 출시 중인 모든 버전의 Windows Server 및 이 기능을 지원하는 SQL Server 에디션에서 기본 PMem 지원과 결합하여 고부하 데이터베이스의 성능을 향상시킬 수 있습니다.

그림 52. PMem 포지셔닝

영구 메모리는 가상 머신에서 두 가지 모드로 사용할 수 있습니다. [50]

  • Virtual Persistent Memory(vPMem)[51] vPMem을 사용하면 메모리가 게스트 OS에 가상 NVDIMM으로 노출됩니다. 이를 통해 게스트 OS는 바이트 주소 지정이 가능한 랜덤 모드에서 PMem을 사용할 수 있습니다.
  • Virtual Persistent Memory Disk(vPMemDisk)를 사용하면 게스트 OS에서 가상 SCSI 장치로 메모리에 액세스할 수 있지만 가상 디스크는 PMem 데이터스토어에 저장됩니다.

두 모드 모두 SQL Server에 유용할 수 있습니다. Windows 2016 게스트 OS 및 SQL Server 2016 SP1 이상에서 작업할 때는 vPMem 사용을 고려하십시오. 이 조합의 경우, vPMem 디바이스가 Windows 게스트 OS에 노출된 후에는 스토리지 클래스 모듈로 감지되며 DAX 볼륨으로 포맷해야 합니다. SQL Server는 DAX 볼륨을 사용하여 DAX[52]로 구성된 SCM 볼륨에 추가 로그 파일을 배치하여 “tail-of-log-cache"을 활성화할 수 있습니다.

ALTER DATABASE <MyDB> ADD LOG FILE (NAME = <DAXlog>,
FILENAME = '<DAX 로그 파일에 대한 파일 경로>', SIZE = 20MB)

20MB의 PMem 공간만 필요하므로(SQL Server는 로그 버퍼를 저장하는 데 20MB만 사용)[53], 하나의 PMem 모듈을 동일한 호스트에서 실행되는 여러 VM 간에 효율적으로 공유할 수 있으므로 많은 소비자가 하나의 NVDIMM을 공유함으로써 비용을 크게 절감할 수 있습니다.

vPMemDisk 모드는 기존 스토리지 디바이스처럼 모든 버전의 Windows 게스트 OS/SQL 서버에서 사용할 수 있지만 레이턴시가 매우 짧습니다. 최근의 사용 사례는 SQL Server 백업 및 복원을 위한 vPMemDisk의 이점을 입증했습니다.[54]

참고: 이 글을 작성하는 시점을 기준으로 PMem 디바이스가 연결된 VM은 모드를 무시하고 vSphere HA에 의해 보호되지 않으므로 VM 수준 백업에서 제외해야 합니다. PMem이 연결된 VM의 vMotion은 지원됩니다(vPMem 모드 대상 호스트에는 물리적 NVDIMM이 있어야 함).

6.7에서 영구 메모리 기술을 완벽하게 지원하므로 SQL Server 성능 관점에서 볼 때 새 서버의 하드웨어 구성을 NVDIMM 디바이스로 개선하는 것이 매우 유리해 보입니다.