Red Hat Blog를 보다가 관심 가는 글이 보여서 AI번역+약간 교정해 보았습니다.
출처: https://developers.redhat.com/articles/2025/07/14/live-migrating-vms-openshift-virtualization
Red Hat OpenShift Virtualization을 사용하면 조직이 통합된 쿠버네티스 기반 플랫폼에서 컨테이너와 함께 가상 머신을 실행하고 관리할 수 있습니다. OpenShift Virtualization은 VM을 클라우드 네이티브 환경에 통합하여 운영을 간소화하는 동시에 고가용성, 성능 및 보안을 보장합니다. 따라서 데이터 처리, 고급 분석 및 운영 전반의 원활한 통합을 지원하는 인메모리 데이터베이스인 SAP HANA와 같은 비즈니스 크리티컬 애플리케이션을 실행하는 데 완벽한 선택입니다.
SAP HANA의 실시간 분석 기능은 신속한 의사 결정을 지원하여 기업이 시장 변화에 신속하게 대응하고 새로운 기회를 포착할 수 있도록 지원합니다. 현대 기업의 IT 스택에서 중요한 역할을 하는 만큼, 중단은 비즈니스 운영에 막대한 영향을 미칠 수 있습니다. 지속적인 가용성과 최소한의 중단이라는 이러한 요구 사항을 충족하기 위해 OpenShift Virtualization은 라이브 마이그레이션이라는 기능을 지원합니다. 라이브 마이그레이션을 통해 가상 머신은 다운타임 없이 호스트 간에 이동할 수 있으며, 원활한 유지 관리, 워크로드 분산 및 사전 예방적 장애 방지가 가능합니다.
1TB 규모의 대규모 가상 머신에서 실행되는 SAP HANA 워크로드가 OpenShift에서 안정적으로 작동하는지 시연합니다. BWH(BW/4HANA SAP Business Warehouse for HANA)를 사용하여 테스트를 진행했는데, 마이그레이션 중 시스템에 상당한 부하가 발생했습니다.
SAP는 현재 OpenShift Virtualization에서 SAP HANA를 운영 워크로드에 실행하는 것을 지원하지 않습니다. 하지만 개발 및 QA 시스템에서는 문제없으며, 고객은 모든 워크로드에 대해 Red Hat의 전폭적인 지원을 받을 수 있습니다.
데이터 손실 없는 라이브 마이그레이션
우리의 테스트는 모든 시나리오에서 매우 안정적인 라이브 마이그레이션을 보여주었습니다.
- 유휴 및 냉각 시나리오(1단계)와 2단계, 3단계에서 데이터 손실이나 손상 없이 라이브 마이그레이션이 성공적으로 완료되었습니다.
- 고부하 BWH 조건(사용 중 시나리오, 1단계)에서는 대부분의 경우 더티 페이지가 대량으로 존재하더라도 마이그레이션이 예상대로 진행되었습니다. 마이그레이션이 완료되지 않는 극단적인 경우에는 VM 및 데이터 무결성(손상이나 손실 인스턴스 없음)을 유지하면서 작업이 안전하게 취소되었습니다.
이제 우리가 어떻게 이런 결과를 얻었는지 살펴보겠습니다.
환경 설정 및 최적화
1TB 메모리 가상 머신의 마이그레이션 테스트를 지원하기 위해 먼저 OpenShift Virtualization 4.17 환경을 구축했습니다. 이 환경에는 대용량 메모리 구성(1GB 대용량 페이지)을 갖춘 두 개의 워커 노드와 여러 개의 공유 스토리지 볼륨이 포함되어 있어 가상 머신이 높은 메모리와 높은 I/O 부하에서도 작동할 수 있도록 보장합니다.
이 문서 의 단계에 따라 OpenShift Virtualization 환경에 SAP HANA 워크로드를 배포했습니다. 이 프로세스에는 Ansible 컬렉션 redhat.sap_infrastructure의 sap_hypervisor_node_preconfigure 및 sap_vm_provision 역할을 사용하여 SAP 시스템 요구 사항에 맞게 노드 및 게스트 설정을 조정하는 작업이 포함됩니다. HANA 및 Netweaver와 같은 SAP 워크로드를 설치하기 위해 redhat.sap_install 컬렉션의 역할이 사용되었습니다.
대규모 가상 머신의 라이브 마이그레이션에 필요한 네트워크 대역폭을 처리하기 위해 OpenShift 노드에 100Gbps 네트워크 카드를 추가하고 이를 라이브 마이그레이션을 위한 전용 백업 네트워크로 구성했습니다.
하드웨어 정보:
BareMetal machines as worker node: CPU model: Intel(R) Xeon(R) Platinum 8276L CPU @ 2.20GHz (Cascade Lake) Sockets: 8 Memory: 12 TB Network card: Intel Corporation Ethernet Connection X722 for 1GbE - for connection to cluster Mellanox ConnectX-5 for 100Gb - for connection to NFS server Mellanox ConnectX-5 for 100Gb - for migration BareMetal machine as controller: CPU model: Intel(R) Xeon(R) Silver 4216 CPU @ 2.10GHz Memory: 128 GB NFS server: Storage: 10TB ssd
버전 정보:
OpenShift: 4.17.15 OpenShift Virtualization: 4.17.15 Guest operating system: RHEL 9.4 HANA database: 2.00.081.00.1733303410 NetWeaver: 7.5
그림 1은 우리 실험에 사용된 네트워크 토폴로지를 보여줍니다.
그림 1: 실험에 사용된 네트워크 토폴로지의 표현.
SAP HANA 벤치마크 워크로드(BWH) 벤치마크 테스트
SAP HANA의 BWH는 대량 데이터 로드 및 고부하 조건에서 인메모리 데이터베이스 시스템의 성능을 검증하는 표준화된 테스트입니다. 이 테스트에서 SAP HANA는 대규모 데이터 로드 및 처리를 수행하며, 이는 높은 CPU 및 메모리 리소스를 요구합니다. 본 테스트의 목표는 BWH 프로세스 중에 가상 머신의 라이브 마이그레이션을 성공적으로 수행할 수 있는지 확인하는 것이었습니다.
라이브 마이그레이션 테스트
BWH 프로세스는 세 단계로 나뉘며, 각 단계와 시나리오에서 라이브 마이그레이션 테스트를 수행했습니다.
1단계: 데이터 로드 단계
데이터 로드 단계에서는 여러 데이터 세트(한 데이터 세트에는 약 13억 개의 레코드가 포함되어 있음)를 로드하고 다양한 로드 조건에서 라이브 마이그레이션을 테스트합니다. 이 단계에는 다음 세 가지 시나리오가 포함됩니다.
- 유휴 시나리오: 이 시나리오에서는 데이터 세트 로딩을 완료한 후 데이터베이스가 유휴 상태입니다. CPU 및 메모리 부하가 낮으므로 라이브 마이그레이션이 성공적으로 완료될 것입니다.
- 바쁜 시나리오: 이 시나리오에서는 두 번째 데이터 세트를 로드하는데, 가상 머신의 CPU 및 메모리 부하가 급격히 증가하여 시스템에 높은 부하가 발생합니다. 생성된 더티 페이지 수가 많기 때문에 이 기간 동안 라이브 마이그레이션 프로세스가 수렴하기 어려운 경우가 많지만, 더티 페이지를 푸시할 수 있을 만큼 충분한 대역폭이 확보된다면 성공적으로 완료될 것입니다. 네트워크 속도가 페이지 더티 속도를 따라잡을 만큼 충분하지 않으면 특정 시간 초과 후 마이그레이션이 취소될 수 있습니다.
- 냉각 시나리오: 데이터 로딩이 완료된 후 시스템은 냉각 단계에 진입하여 CPU 부하가 감소하지만 메모리는 거의 완전히(약 99%) 사용됩니다. 이 단계에서는 라이브 마이그레이션이 오류 없이 완료될 수 있어야 합니다.
2단계: 쿼리 실행(전체) 단계
이 단계에서는 데이터 로드 후 쿼리 작업 중 가상 머신의 성능을 테스트하는 데 중점을 둡니다. 가상 머신은 지속적인 부하를 받고 리소스 사용률이 높습니다. 쿼리가 성공적으로 완료되고 결과에 오류가 없는지 확인해야 합니다.
3단계: 쿼리 실행(런타임) 단계
이 단계에서는 가상 머신이 실제 워크로드를 실행하고 리소스 사용률이 최고조에 달합니다. 모든 쿼리 작업이 실행 중이고 CPU 및 메모리 사용량이 최대치에 도달합니다. 이 시점에서 데이터 오류나 가상 머신 손상 없이 이러한 고부하 조건에서 쿼리를 성공적으로 완료할 수 있는지 확인합니다.
기술적 과제 및 이슈
이 테스트에서 가장 큰 기술적 과제는 데이터베이스 데이터의 무결성을 보장하는 것이었습니다. SAP HANA BWH 벤치마크 테스트에서는 I/O 부하가 매우 높습니다. SAP HANA 데이터베이스의 성능을 최적화하기 위해 게스트에 1GB 메모리의 대용량 페이지를 구성했습니다. 그러나 이는 한 비트만 변경되더라도 전체 페이지가 변경되기 때문에 마이그레이션 프로세스를 복잡하게 만듭니다.
이러한 더티 페이지는 라이브 마이그레이션 중에 동기화 및 처리되어야 하며, 특히 부하가 높은 상황에서는 빠른 속도로 생성됩니다. 라이브 마이그레이션 중에 더티 페이지가 빠르게 누적되면 지정된 시간 내에 마이그레이션 작업을 완료하지 못하는 경우가 많습니다.
이 문제를 해결하기 위해 다음과 같은 최적화를 구현했습니다.
- CPU, 메모리 최적화: 게스트 구성에서 전용 리소스 옵션이 활성화되어 있고 작업자 노드에 “cpumanager=true” 레이블이 설정되어 있는지 확인할 수 있습니다. 전용 리소스를 사용하면 가상 머신의 성능과 지연 시간 예측의 정확도를 향상시킬 수 있습니다(그림 2).
그림 2: “전용 리소스로 예약된 작업 부하” 링크를 클릭하여 전용 리소스 옵션을 활성화합니다.
- 네트워크 최적화 : 마이그레이션 중 충분한 네트워크 대역폭을 확보하기 위해 OpenShift 워커 노드 사이에 라이브 마이그레이션 트래픽 전용 보조 네트워크를 추가하여 네트워크를 최적화했습니다. 또한, 네트워크의 MTU (최대 전송 단위)를 9000으로 설정하여 특히 대용량 데이터 패킷 전송 시 네트워크 효율성을 크게 향상시켰습니다. 이를 통해 패킷 분할 및 재조립 오버헤드를 줄여 마이그레이션 프로세스의 전송 속도와 안정성을 향상시켰습니다.
보조 네트워크의 구성은 다음과 같습니다.
apiVersion: "k8s.cni.cncf.io/v1"
kind: NetworkAttachmentDefinition
metadata:
name: my-secondary-network
namespace: openshift-cnv
spec:
config: '{
"cniVersion": "0.3.1",
"name": "migration-bridge",
"type": "macvlan",
"master": "eth1",
"mode": "bridge",
"ipam": {
"type": "whereabouts",
"range": "10.200.5.0/24"
}
}'네트워크 설정은 hyperconverged 구성.
apiVersion: hco.kubevirt.io/v1beta1
kind: HyperConverged
metadata:
name: kubevirt-hyperconverged
namespace: openshift-cnv
spec:
liveMigrationConfig:
completionTimeoutPerGiB: 800
network: my-secondary-network
parallelMigrationsPerCluster: 5
parallelOutboundMigrationsPerNode: 2
progressTimeout: 150
# ...
- 스토리지 최적화: 이 경우 테스트 환경에서는 외부 스토리지 인프라 부족으로 인해 로컬 공유 스토리지에 NFS-CSI 드라이버를 사용했습니다. (이는 테스트 최적화 구현으로, 운영 환경에는 적합하지 않습니다.) SAP HANA의 고성능 요구 사항을 충족하기 위해 모든 데이터 로그와 프로그램 파일은 공유 스토리지에 저장되어 여러 노드가 데이터에 액세스하고 처리할 수 있도록 함으로써 마이그레이션 중 데이터 일관성과 고가용성을 보장합니다. 특히, 공유 스토리지는 SSD 하드웨어에 위치하여 고속 데이터 읽기/쓰기 성능을 보장합니다.
- 가상 머신 최적화: 리소스 활용도를 극대화하고 성능 손실을 최소화하기 위해 다음과 같이 가상 머신의 리소스 할당을 최적화했습니다.
- 고부하 조건에서 메모리 접근 효율성을 개선하기 위해 커널 인수에서
IOMMU활성화합니다 . - SAP HANA BWH 워크로드의 높은 메모리 요구 사항을 고려하여 가상 머신의 메모리를 1TB로 설정하고 1GB의 대용량 페이지를 사용했습니다.
- 게스트에서 Ansible
sap-hana-rhv-guest역할을 적용하면 SAP HANA에 맞춰 조정됩니다.
조정된 설정 내용은 다음과 같습니다.
- 고부하 조건에서 메모리 접근 효율성을 개선하기 위해 커널 인수에서
[main] summary=Optimize for SAP HANA [cpu] force_latency=cstate.id:3|70 governor=performance energy_perf_bias=performance min_perf_pct=100 [vm] transparent_hugepages=never [sysctl] kernel.sem = 32000 1024000000 500 32000 kernel.numa_balancing = 0 kernel.sched_min_granularity_ns = 3000000 kernel.sched_wakeup_granularity_ns = 4000000 vm.dirty_ratio = 40 vm.dirty_background_ratio = 10 vm.swappiness = 10
라이브 마이그레이션을 위한 핵심 기술
이 테스트에서는 고부하 환경에서도 라이브 마이그레이션이 안정적으로 실행될 수 있도록 몇 가지 핵심 기술을 사용했습니다.
- Pre-copy: 이 기술은 실행 중인 VM을 타겟 노드로 전환하기 전에 VM의 메모리를 타겟 노드에 복사합니다. SAP HANA가 과부하 상태에서 실행되는 특성상 마이그레이션 중에 많은 메모리 페이지가 변경되고 무효화(또는 변경)됩니다. 따라서 이러한 페이지를 다시 복사해야 하며, 이는 반복적인 프로세스입니다.
- Multi-fd: 다중 fd를 통해 여러 스트림을 통해 네트워크를 통해 데이터를 전송함으로써 마이그레이션 중 데이터 전송 속도를 크게 향상시켰습니다. 이를 통해 더티 페이지가 생성되는 동안에도 라이브 마이그레이션을 통해 데이터를 빠르게 전송할 수 있으므로, 마이그레이션 프로세스가 I/O 부하의 영향을 받지 않고 완료될 수 있습니다. 다중 fd는 네트워크 대역폭 활용도를 극대화하는 데 도움이 됩니다. 물론, 환경에 충분한 전용 대역폭을 확보하는 것도 마찬가지로 중요합니다. 높은 대역폭과 다중 fd의 조합은 마이그레이션 성공 가능성을 높여줍니다.
테스트 결과 및 검증
BWH 결과 로그 파일을 분석하여 오류를 확인했습니다. 오류가 없는 실행만 성공으로 간주했습니다.
OpenShift Virtualization의 라이브 마이그레이션 결과 스크린샷은 다음과 같습니다. VirtualMachine 세부 정보의 메트릭 페이지에서 확인할 수 있습니다(그림 3).
그림 3: 메트릭 탭 그림 4는 트랜잭션 SE38의 SAP HANA BWH 쿼리 실행 결과를 보여줍니다. 결과를 확인하고 오류가 없는지 확인하세요.
그림 4: SAP HANA BWH 쿼리 실행 스크린샷.
다음은 무엇입니까?
SAP HANA BWH 벤치마크 테스트 중 라이브 마이그레이션 검증을 통해 OpenShift Virtualization이 성능 저하 없이 가상 머신을 성공적으로 라이브 마이그레이션할 수 있으며, 데이터 무결성에도 영향을 미치지 않음을 입증했습니다. 참고: 이는 감사 결과가 아닙니다. 이 결과는 엔터프라이즈 애플리케이션 가상화 플랫폼으로서 OpenShift Virtualization의 안정성과 높은 가용성을 입증합니다.
향후에는 3TB, 6TB, 12TB 가상 머신에서 유사한 테스트를 수행하여 더 큰 메모리 규모에서 OpenShift 가상화 성능을 검증할 예정입니다.
자세한 내용을 알아보려면 Red Hat OpenShift Virtualization 제품 페이지를 방문하세요 .
