출처: https://www.credativ.de/en/blog/credativ-inside/evaluate-ksm-and-ballooning-features-in-proxmox-ve/
소개
Proxmox Virtual Environment(VE)는 강력한 오픈 소스 엔터프라이즈 가상화 플랫폼입니다. VE는 Kernel Samepage Merging (KSM) 및 메모리 벌루닝을 포함한 고급 Dynamic Memory Management 기능을 지원하여 메모리 사용량을 최적화하고 성능을 향상시킬 수 있습니다. 이 블로그 게시물에서는 Linux 가상 머신(VM)을 사용하여 Proxmox VE의 KSM 및 메모리 벌루닝 기능의 효과를 평가합니다. 테스트 환경을 위해 Proxmox VE 가 설치된 VM을 구성하고 , 테스트를 수행한 후 결과를 분석하여 이러한 기능이 가상화 환경에 어떤 이점을 제공하는지 살펴보겠습니다. 또한 KSM 활성화 시 발생하는 보안 문제와 특히 데이터베이스 환경에서 벌루닝을 사용할 때 발생할 수 있는 위험에 대해서도 알아보겠습니다.
KSM은 무엇인가요?
Kernel Samepage Merging (KSM)은 리눅스 커널의 메모리 중복 제거 기능으로, 서로 다른 프로세스에서 동일한 메모리 페이지를 찾아 하나의 페이지로 병합하여 메모리 사용량을 줄입니다. 특히 가상화 환경에서 여러 가상 머신(VM)이 유사하거나 동일한 데이터를 메모리에 저장할 수 있는 경우, 예를 들어 동일한 운영 체제나 애플리케이션을 실행할 때 유용합니다.
KSM(Kernel Samepage Merging)은 2009년 리눅스 커널 버전 2.6.32부터 도입되어 오랜 기간 사용되어 왔습니다. 하지만 개발자들은 6.x 커널에서 볼 수 있듯이 KSM에 새로운 기능을 지속적으로 추가해 왔습니다. KSM의 변경 사항은 다음 링크에서 확인할 수 있습니다: 커널 버전별 KSM 변경 내역 . 보시다시피, 커널 개발자들은 KSM의 기능을 더욱 향상시키기 위해 리눅스 커널에 끊임없이 새로운 기능을 추가하고 있습니다.
예를 들어, Proxmox VE에서 현재 사용되는 Linux 커널은 6.8.x 버전입니다. 이 버전은 새로 추가된 Smart Scan 기능을 지원하며, 이번 블로그 게시물에서 함께 테스트해 볼 예정입니다.
메모리 벌루닝이란 무엇인가요?
Memory Ballooning은 가상화 환경에서 가상 머신(VM)의 현재 요구 사항에 따라 메모리 할당을 동적으로 조정하는 기술입니다. 게스트 VM 내의 “balloon driver”는 사용되지 않는 메모리를 메모리 풀(“벌룬”)에 할당하여 하이퍼바이저가 필요에 따라 다른 VM에 메모리 리소스를 재할당할 수 있도록 합니다. 이는 호스트 시스템 전체의 메모리 사용을 최적화하여 메모리가 효율적으로 활용되고 유휴 VM에 낭비되지 않도록 합니다.
테스트 설정
Proxmox VE에서 KSM 및 메모리 벌루닝 기능을 평가하기 위해 16GB RAM을 제공하는 가상 머신 내에서 작동하는 단일 노드로 구성된 테스트 클러스터를 구축했습니다. 이 샘플 클러스터 위에 여러 Linux 게스트 가상 머신을 실행하여 KSM 및 메모리 벌루닝 기능을 시연합니다.
다음 그림은 테스트용 가상 머신 설정의 개요를 보여줍니다.
Proxmox VE 호스트:
- Proxmox VE 8.2를 설치하기 위한 가상 머신입니다.
- 8코어 vCPU
- 16GB RAM
- 200GB Virtio 스토리지
리눅스 게스트 VM 템플릿:
- Linux 게스트
- 2GB RAM
- Debian LXQt 데스크톱 설치
- 16GB Virtio 스토리지
리눅스 게스트 VM:
- 8개의 가상 머신, 템플릿에서 링크드 클론 생성
테스트를 수행합니다
저희는 두 가지 테스트를 수행합니다. 첫 번째는 KSM만 평가하는 테스트이고, 두 번째는 KSM을 사용하지 않고 메모리 벌루닝 현상을 테스트하는 테스트입니다.
KSM 테스트를 위한 게스트 VM 설정:
- 아래 그림에서 보시는 것처럼, 저희는 VM 템플릿에서 각각 2GB RAM을 가진 VM 8개를 복제했습니다.
각 VM은 벌루닝이 비활성화된 상태로 2GB RAM으로 구성되었습니다.
- 다음으로, 해당 8개의 가상 머신을 부팅하고 KSM을 활성화하지 않고 LXQt 데스크톱 자동 로그인으로 시작합니다. 여기서는 메모리 사용량을 줄이기 위한 메커니즘을 적용하기 전에 각 가상 머신이 사용하는 메모리 양을 확인하고자 합니다.
- 보시다시피, 8개의 가상 머신이 총 13154.1MB의 메모리를 사용하고 있습니다. 위 스크린샷은 저희 Proxmox VE 호스트에서 캡처한 것입니다.
- 호스트에서 명령어를 사용하여 KSM Smart Scan을 활성화하십시오.
# echo “scan-time” > /sys/kernel/mm/ksm/advisor_mode - KSM 실행을 활성화합니다.
# echo 1 > /sys/kernel/mm/ksm/run
KSM 스마트 스캔에 대한 관찰 결과
KSM Smart Scan 기능은 기존 ksmtuned 방식보다 효율적인 것으로 나타났습니다. 이전 시도에서 중복 제거에 실패한 페이지는 건너뛰도록 페이지 스캔을 최적화했기 때문입니다. 이는 페이지 스캔에 필요한 CPU 시간을 크게 줄여주며, 특히 시스템이 안정 상태 에 도달했을 때 유용합니다 . 테스트 결과, KSM 스마트 스캔은 ksmd가 시스템 리소스를 과도하게 사용하지 않는 것으로 보아 메모리 사용량을 최소화하면서 효율적인 스캔이 가능한 것으로 판단됩니다.
시험 결과
- KSM이 페이지를 스캔하고 병합하는 동안 잠시 후 사용 중인 메모리가 6770.1MiB로 줄어들었습니다.
- Proxmox VE 웹 UI에서도 KSM 공유 상태를 확인할 수 있습니다.
메모리 사용량이 크게 감소했습니다. KSM 작동 중 ksmd 의 CPU 사용량이 약간 증가했지만 , 가상 머신 성능 저하는 미미했습니다. 이는 KSM이 시스템에 과도한 부하를 주지 않고 효율적으로 작동함을 나타냅니다. 동일한 페이지를 병합함으로써 메모리 활용률이 향상되어 추가 하드웨어 없이 동일한 호스트에서 더 많은 가상 머신을 실행할 수 있게 되었습니다.
Windows VM에서의 Kernel Samepage Merging (KSM)
KSM은 리눅스 커널에 내장된 기능으로, 하이퍼바이저 수준에서 작동하며 모든 가상 머신의 메모리 페이지를 스캔하여 동일한 페이지를 하나의 공유 페이지로 병합합니다. 이 과정을 통해 가상 머신의 전체 메모리 사용량을 줄일 수 있습니다.
Windows VM의 경우 하이퍼바이저는 Linux VM과 유사하게 메모리를 처리하여 동일한 페이지를 식별하고 병합합니다. 즉, Proxmox VE 자체 가 Linux 기반이므로 Proxmox VE에서 실행되는 게스트 VM의 운영 체제와 관계없이 KSM 커널 기능을 활용하기 때문에 KSM의 이점은 Proxmox VE에서 실행되는 Windows VM에도 적용될 수 있습니다.
벌루닝 테스트를 위한 게스트 VM 설정:
다음으로, 다른 테스트를 통해 메모리 벌루닝을 살펴보겠습니다. Proxmox VE의 벌루닝 기능을 평가하기 위해, KSM 테스트에 사용되었던 Proxmox VE 환경을 다음과 같이 조정하여 사용하겠습니다.
- 가상 머신 3개만 남기고 나머지는 삭제하세요.
- 각 VM에서 벌루닝을 활성화하십시오.
- 각 가상 머신의 최소 메모리를 2048MB로, 최대 메모리를 5120MB로 설정하십시오
.
KSM을 비활성화하세요:
KSM을 수동으로 비활성화하려면 다음 명령을 실행하십시오.
# echo 2 > /sys/kernel/mm/ksm/run
다음 그림은 벌루닝 테스트 VM 설정의 개요를 보여줍니다.
메모리 벌루닝 덕분에 이제 각 VM에 사용 가능한 메모리가 더 많아졌을 것입니다. stress-ng를 사용하여 각 게스트 VM에 4GB의 메모리를 할당하고, 지정된 시간(초) 동안 할당된 메모리를 유지하도록 테스트해 보겠습니다.
$ stress-ng --vm-bytes 4G -m 1 –vm-hang <seconds>
–vm-hang <seconds> 옵션은 VM이 메모리 매핑 해제 전에 대기하는 시간을 초 단위로 지정합니다.
OOM-Killer!
Proxmox VE 호스트에서 OOM-killer가 작동하는 것을 확인했습니다.
호스트에서 OOM-killer가 트리거되는 것은 문제가 됩니다. 각 VM에 5GB의 메모리를 할당하면 과도한 오버커밋이 발생하여 호스트의 워크로드를 처리할 메모리가 부족해 OOM-killer가 활성화됩니다.
OOM-killer가 트리거되는 것은 항상 문제가 되지만, 호스트에서 트리거되는 경우는 게스트 VM 내부에서 트리거되는 경우보다 훨씬 더 심각합니다. 어떤 VM이 종료되고 강제로 종료되는지 알 수 없거나, 적어도 예측하기가 매우 어렵기 때문입니다.
메모리 벌루닝의 기본적인 목적 중 하나는 호스트 시스템에서 발생하는 OOM-killer를 방지하는 것입니다. 호스트 시스템에서 발생하는 OOM-killer는 특정 VM 내에서 발생하는 OOM-killer보다 더 큰 손상을 초래할 수 있기 때문입니다.
벌루닝 테스트를 위해 VM의 최대 메모리 구성을 줄이세요
메모리 과다 할당 문제를 해결하기 위해 각 VM의 최대 메모리 구성을 4GB로 줄여 보겠습니다.
- 각 가상 머신의 최대 메모리 설정을 4GB로 조정하십시오.
- 가상 머신 3개를 부팅합니다.
다음으로, 게스트 VM에서 stress-ng를 사용하여 3GB의 메모리를 할당한 다음 각 게스트 VM에서 CPU 사용 없이 지정된 시간 동안 대기하도록 하겠습니다 .
$ stress-ng--vm-bytes 3G -m 1 --vm-hang <seconds>
이것은 게스트 VM에서 실행되는 최상위 명령어입니다.
호스트의 메모리 사용량을 확인
stress-ng 테스트를 실행한 후 호스트의 메모리 사용량을 확인합니다.
호스트의 사용 가능한 메모리가 부족합니다. 메모리 할당을 시도하는 세 번째 가상 머신은 호스트의 제한된 리소스로 인해 CPU 사용률이 매우 높아집니다.
잠시 후, 벌루닝 드라이버가 호스트의 게스트 VM에서 메모리를 회수하기 시작하는 것을 확인할 수 있습니다. 각 VM의 RES(점유된 물리적 메모리) 가 감소했습니다.
이제 벌루닝 드라이버는 호스트에서 사용 가능한 여유 메모리를 늘리기 위해 각 게스트 VM에서 메모리를 회수합니다. 이 조치는 호스트의 작업 부하를 유지하는 데 도움이 되지만 메모리 할당량 감소로 인해 다른 모든 게스트 VM의 속도가 저하됩니다.
게스트 VM에 대한 벌루닝의 영향
속도가 느려진 가상 머신은 결국 워크로드를 유지하는 데 필요한 여유 메모리가 부족해집니다. 그 결과, 게스트 가상 머신 내부에서 OOM-killer가 실행됩니다.
모든 VM이 잠시 멈춘 후, OOM-killer가 작동하여 stress-ng 프로세스를 종료합니다. 그 후 VM은 정상 상태로 돌아오고 호스트에는 충분한 사용 가능한 메모리가 확보됩니다.
메모리 탈취는 언제 발생하나요?
메모리 스틸링이 언제 발생하는지 확인하기 위해 추가 테스트를 진행해 보겠습니다. 동일한 stress-ng 명령어를 사용하여 두 개의 가상 머신에 3GB의 메모리를 할당하겠습니다.
다음으로, 세 번째 가상 머신에 메모리를 점진적으로 할당하겠습니다. 512MB부터 시작하여 메모리 회수가 트리거될 때까지 512MB씩 점진적으로 추가합니다.
세 번째 가상 머신에 할당되는 메모리 양을 점진적으로 늘리면서 호스트의 메모리 사용량을 모니터링합니다.
호스트의 사용 가능한 여유 메모리가 2978.1MB(전체 메모리의 약 18.5%)에 도달했을 때 메모리 스틸링이 아직 발생하지 않는다는 것을 확인했습니다.
호스트의 사용 가능한 여유 메모리를 더욱 줄이기 위해 세 번째 VM에 메모리를 조금 더 할당해 보겠습니다. 호스트의 사용 가능한 여유 메모리가 전체 메모리의 약 15%에 도달하면 벌루닝 드라이버가 작동하여 게스트 VM에서 메모리를 가져오는 것을 확인했습니다.
이 시점에서 가상 머신에 할당된 메모리가 감소하고 CPU 사용량이 크게 증가하는 것을 확인할 수 있습니다.
메모리 탈취 과정은 호스트의 사용 가능한 여유 메모리가 전체 메모리의 20%에 다시 도달할 때까지 계속됩니다. 세 번째 가상 머신에서 할당된 메모리를 해제한 후, 호스트의 사용 가능한 여유 메모리가 전체 메모리의 20%에 도달하면 메모리 회수 과정이 중지되는 것을 확인했습니다.
벌루닝 시험 결과 시각화
아래 그림은 저희 실험에서 얻은 관찰 결과를 보여줍니다.
이 그림에서 다음과 같은 핵심 사항들을 확인할 수 있습니다.
- 호스트에 20% 이상의 여유 메모리가 있어야 합니다. 이는 각 가상 머신(VM)에 최대 4GB의 메모리가 할당되도록 구성된 초기 메모리 할당량입니다.
- 호스트에서 사용 가능한 메모리가 18.6%에 도달했습니다. 첫 번째 및 두 번째 가상 머신이 최대 4GB의 메모리를 모두 할당받았습니다. 세 번째 가상 머신에 대한 메모리 할당이 512MB부터 시작하여 512MB씩 점진적으로 증가합니다.
- 메모리 스틸링 발생 시점: 호스트의 사용 가능한 메모리가 전체 메모리의 약 15%까지 떨어지면 벌루닝 드라이버가 게스트 VM에서 메모리를 회수하기 시작합니다. 게스트 VM의 붉은색 표시는 벌루닝 드라이버가 메모리를 스틸하면서 CPU 사용량이 증가하여 게스트 VM의 성능에 영향을 미치는 것을 나타냅니다.
Windows 가상 머신의 메모리 벌루닝
메모리 벌루닝 기능은 Windows VirtIO 드라이버를 사용하면 Proxmox VE의 Windows VM에서도 작동합니다. 드라이버 ISO 파일은 Proxmox 위키 에서 찾 거나 VirtIO 드라이버 ISO 파일에서 직접 다운로드할 수 있습니다 .
리눅스 VM과 비교했을 때
Linux 가상 머신에서는 메모리 핫 플러그가 지원되어 벌루닝 드라이버가 활성화될 때 전체 메모리 용량이 동적으로 변경됩니다. 즉, Linux 가상 머신에서는 벌루닝 드라이버가 작동함에 따라 전체 메모리 할당량이 실시간으로 조정되는 것을 확인할 수 있습니다. Windows는 이와 같은 방식으로 메모리 핫 플러그를 지원하지 않습니다. 따라서 Windows 가상 머신에서는 전체 메모리 용량이 조정되는 것을 볼 수 없습니다. 대신 사용 중인 메모리 양이 증가하는 것을 확인할 수 있습니다. 이러한 차이에도 불구하고 최종 결과는 동일합니다. 벌루닝 드라이버가 메모리를 회수함에 따라 사용 가능한 여유 메모리가 줄어듭니다.
이 스크린샷은 벌루닝이 활성화되어 Windows VM 내부에서 메모리를 차지할 때 사용되는 메모리 양이 증가하는 것을 보여줍니다.
결과
Proxmox VE의 메모리 벌루닝은 가상 머신(VM) 간의 메모리 할당을 동적으로 관리하여 호스트의 전체 메모리 사용량을 최적화하는 강력한 기능입니다. 그러나 성능 저하를 방지하려면 메모리 회수를 유발하는 임계값을 이해하는 것이 중요합니다. 적절한 최소 메모리 제한을 설정하여 해당 임계값에 도달하면 더 이상 메모리를 가져가지 않도록 하는 것이 좋습니다. 이렇게 하면 게스트 VM의 안정성을 유지하고 OOM-killer가 게스트 VM 내부의 프로세스를 종료하는 것을 방지할 수 있습니다. 메모리 할당을 적절하게 설정하고, 주의 깊게 모니터링하고, 조정함으로써 안정적이고 효율적인 가상 환경을 구축할 수 있습니다.
보안 문제
KSM 활성화의 의미
Proxmox VE 위키의 커널 동일 페이지 병합(KSM) 문서 에 따르면 KSM의 영향에 대해 언급되어 있습니다. 연구원들은 이미 “Memory Deduplication as Threat to the Guest OS” , “Remote Memory-Deduplication Attacks” , 그리고 “New FFS Rowhammer Attack Hijacks Linux VMs” 등의 증거 자료를 제시했습니다 .
KSM은 모든 VM을 완벽하게 제어할 수 있는 경우에만 활성화해야 합니다. Proxmox VE를 호스팅 서비스 제공에 사용하는 경우 사용자 보호를 위해 KSM을 비활성화하는 것이 좋습니다. 또한, KSM 비활성화가 법적 요구 사항일 수 있으므로 해당 국가의 규정을 확인해야 합니다.
벌루닝 기능을 사용하는 데이터베이스 사용 시 위험 요소
메모리 벌루닝은 수요에 따라 가상 머신의 메모리 할당을 동적으로 조정합니다. 이 기능은 메모리 사용량 최적화에 유용하지만, 성능을 위해 사용 가능한 메모리에 크게 의존하는 PostgreSQL과 같은 데이터베이스에서 사용할 경우 특정 위험을 초래할 수 있습니다. 벌루닝 드라이버가 메모리를 너무 많이 회수하여 메모리 페이지가 과도하게 할당되면 OOM-Killer가 작동하여 메모리 부하가 높은 프로세스를 종료시킬 수 있습니다. 이때 메모리 사용량이 가장 높은 프로세스는 데이터베이스 자체일 가능성이 높습니다.
이 문제를 해결하려면 메모리 벌루닝이 비활성화된 VM에서 데이터베이스 서버를 실행하거나, 제어 권한이 없는 경우 게스트 VM 내부의 Linux 커널에서 오버커밋 정책을 비활성화 하는 것이 좋습니다.
결론
저희 테스트 결과, KSM과 메모리 벌루닝은 가상화 환경에서 메모리 사용량을 최적화하는 데 Proxmox VE에서 효과적인 기능임이 입증되었습니다. KSM은 동일한 페이지를 여러 VM에 병합하여 메모리 사용량을 크게 줄일 수 있으며, 메모리 벌루닝은 수요에 따라 메모리 할당을 동적으로 조정할 수 있도록 합니다.
Proxmox VE의 메모리 벌루닝은 가상 머신 간의 메모리 할당을 동적으로 관리하여 호스트의 전체 메모리 사용량을 최적화하는 강력한 기능입니다. 하지만 성능 저하를 방지하려면 메모리 회수를 유발하는 임계값을 이해하는 것이 중요합니다. 메모리 할당을 주의 깊게 모니터링하고 조정하면 안정적이고 효율적인 가상 환경을 구축할 수 있습니다.
이러한 기능들을 종합하면 가상화된 워크로드의 효율성과 성능을 향상시킬 수 있으므로 Proxmox VE는 기업 가상화를 위한 강력한 솔루션이 됩니다.
KSM과 메모리 벌루닝을 활용하면 조직은 리소스 활용률을 높이고 하드웨어 비용을 절감할 수 있습니다. 호스트와 모든 VM을 완벽하게 제어할 수 있다면 Proxmox VE에서 이러한 기능을 활성화하여 잠재적인 이점을 확인해 보세요.
이 글은 원래 앤드류 리가 작성했습니다.
