Category Archives: 실전 팁 시리즈

oVirt/RHEV 실전에 유용한 정보를 공유하는 곳입니다.

실전 활용팁, KVM 가상화에서 CPU의 HyperThread 기능을 사용할 것인가?

실전 활용팁, KVM 가상화에서 CPU의 HyperThread 기능을 사용할 것인가?
Best Practice, HyperThread feature CPU provides is helpful for KVM virtualization?

가상화 플랫폼에서는 CPU를 포함한 모든 하드웨어 자원이 그야말로 가상화 되기 때문에 컴퓨팅 자원에 대한 수량을 산정하는게 쉽지는 않습니다. 과연 vCPU를 하나의 독립적인 CPU 자원으로 산정해야 하느냐하는 부분과 vCPU 2개가 물리 CPU 1개보다 나은 결과를 가져오는가 하는 등의 이슈도 남아있지요. 그렇더라도 아직까지는 vCPU 수로 컴퓨팅 파워는 산정하는 분위기 인거 같습니다.

vCPU 산정에서 빼놓을 수 없는것이 바로 물리 CPU Socket의 수, 물리 CPU의 Core 수, 그리고 HyperThread(이하 HT) 기능의 활용 여부등일겁니다. 기본적으로 여러 가상머신이 동시에 실행되는 환경이기 때문에 특별히 CPU isolation 과 pinning을 하지 않는한 어차피 vCPU : CPU가 1:1 대응은 어렵습니다. 다만 한가지 지켜져야 할 부분은 “성능상의 이점이 없기 때문에” 개별 가상머신의 vCPU 수는 호스트의 물리적인 CPU 수와 같거나 작아야 한다는 것입니다.

예를 들어, 물리적인 CPU가 32개라면 단일 가상머신에 할당할 최대 vCPU수는 32개 또는 이하여야 한다는 말입니다. (논리적으로는 그 이상도 가능하지만 장점이 없죠)

여기서 고민은 그럼 물리적인 CPU에 HT 기능을 사용해야하는가일텐데요, 답변은 No 그리고 Yes 입니다.

No)  HT의 경우 태생적 특징으로 인해 실제로 물리 Core만큼의 성능을 제공해주지 않습니다. HT의 경우 Workload에 따라 상당한 편차를 가져오지만 대체로 15~30% 성능 개선이 있다고 알려져 있습니다. 즉 총 16 Core 시스템의 경우 HT 활성화시 최대 21(16 * 130%)개의 CPU 성능을 보인다고 생각하면 되겠습니다. 여기서 사용자와 관리자(또는 Automation system)에게 오해를 줄 수 있습니다. HT 활성화시 이들은 CPU가 32개라고 생각하고 Allocation 해줄 가능성이 높은데 이게 Overall Performance에 역효과를 가져올 수 있다는 것 입니다. 추가적으로 Interrupt가 많은 환경에서 HT가 큰 도움을 주지 않는다고 합니다. 따라서 대량의 KVM 가상화를 구현하는 환경에서는 Production 기준 HT 비활성화를 권장합니다.

Yes) 그렇다고 항상 No는 아닙니다. 만약 가상머신내 Workload가 CPU intensive하거나 SMP 환경에 맞춰 개발된 경우라면 HT 활성화가 더 좋은 결과를 가져올 수 있습니다. HPC workload나 Big-Data 등 대량의 데이터 처리 솔루션등이 실행되는 경우라면 HT가 도움을 줄 수 있습니다.

따라서 자신의 Workload를 파악하고 그에 맞춰 HT 활성화를 고민하시면 되겠습니다. 물론 위 내용은 여러 정보를 바탕으로 한 제 개인 의견이므로 참고용으로만 삼으시기 바랍니다.

Advertisements

실전 활용팁, 이렇게 구축 하시면 안 돼요!

실전 활용팁, 이렇게 구축 하시면 안 돼요!
Best Practice, Bad architectures we have to avoid in Production.

정말 오랜만에 돌아왔습니다.

요즘 oVirt/RHEV 구축 사례를 심심치 않게 듣게 되는데요, 이전 포스팅에서 몇가지 권장 아키텍처를 말씀드리긴 했지만 몇가지 우려스러운 아키텍처가 있어 이번 활용팁을 쓰게 되었습니다. 물론 비즈니스 니즈나 제약조건등에 따라 불가피하게 선택한 경우겠지만 가능하면 피해야 할 구현을 말씀드리고자 합니다.

1) oVirt/RHEV 3.1 이전 버전 사용
oVirt 가장 최신 버전은 3.5, RHEV도 가장 최신 버전은 3.4가 나와 있습니다. 최신 버전이 나왔다는 의미는 당연히 기능적인 개선도 있지만 많은 버그와 알려진 문제점들이 해소되었다는 이야기지요. 기 구축된 환경도 업그레이드를 고려하는데 신규 구축에 굳이 옛날 버전을 사용할 필요는 없을 것 입니다. 특히 3.1 이전 버전이라면 강력하게 3.4 이후 버전을 선택하시길 권해드립니다. RHEV도 3.5 베타가 나온만큼 현재 도입 계획중이시라면 3.5를 고려하세요.

2) Local storage domain 사용
oVirt/RHEV는 Local Storage Domain(하이퍼바이저의 local disk 사용)도 지원하고 있습니다. 다만 Local Storage Domain의 경우 Datacenter 1 : Clsuter 1 : Hypervisor 1로만 구축 가능하기 때문에 oVirt/RHEV를 도입하는 취지와 맞지도 않거니와 많은 좋은 기능들을 사용할 수 없다는 단점이 있습니다. Local Storage Domain의 사용은 PoC나 테스트를 위한 기능이라는거 잊지 마세요.

3) 1 storage domain size == 1 virtual machine size
1개 스토리지 도메인당 1개의 가상머신를 설치하고 용량도 거의 비슷하게 구축하게 되면 Snapshot, Template등의 기능을 사용하지 못할뿐만 아니라 결과적으로 가상머신내 복구 불가한 장애 발생 시에 시간이 오래걸리는 재설치 또는 사전에 Export 해 두었던 가상머신의 Import외에는 선택 방법이 없습니다. 오늘을 살지만 내일도 살아야 하니 아키텍처는 좀 더 유연하게 설계하는 것이 좋겠죠?
 
4) 100 Mbit oVirt/RHEV management network 사용
소규모라면 100 Mbit도 받아들일만 하지만 최소 1 Gbit network bandwidth는 할당해주셔야 됩니다. 요즘 100 Mbit 쓰는데가 어디있나 싶지만 management network라고 해서 쉽게 생각하시고 남는 NIC를 사용하는 경우도 있고, 1 Gbit이라도 migration network 분리 없이 management network를 공용으로 사용하는 경우까지 포함됩니다. oVirt/RHEV는 management network를 통해서 주기적으로 하이퍼바이저의 상태 정보, 가상머신 정보등을 갱신하기 때문에 하이퍼바이저나 가상머신 수가 증가될 경우 생각보다 많은 대여폭이 필요할 수 있습니다.
추가적으로 oVirt/RHEV 플랫폼은 OpenStack과 같이 비교적 lifecycle이 짧은 workload뿐만 아니라 lifecycle이 긴 전통적인 workload도 서비스해야 하기 때문에 Live-migration 수요가 지속적으로 발생합니다. 따라서 아키텍처 설계시에 Migration network의 분리도 반드시 고려되어야 합니다.

5) 1 Gbit storage network 사용
가상머신의 부하의 상당수는 당연히 Storage에서 옵니다. 일반적으로 기업이나 기관에서 도입하실 때에는 전용 광라인에 충분한 대여폭을 가진 FCP/iSCSI등을 사용하시지만 간혹 비용적인 부담으로 인해 낮은 대여폭을 가진 NFS, iSCSI, Glusterfs등을 사용하는 경우가 있습니다. Bonding으로 성능 개선을 계획하시겠지만 생각보다 쉽게 원하는 성능을 얻기 어렵습니다. Storage network는 10 Gbit 이상으로 가시는 것을 권해드리며 최소 8 Gbit는 확보해주세요.

6) 2 TB vRAM, 8 TB vDisk 사용
실제 이런 경우까지는 없겠지만 이론적으로 oVirt/RHEV에서 하나의 가상머신에 2 TB 메모리와 8 TB 디스크를 할당해줄 수 있습니다. 하지만 이렇게 큰 하드웨어 리소스가 필요한 서비스라면 물리적인 서버를 적극 추천하겠습니다. 메모리건 디스크건 단일 가상머신에 수백 GB~수TB 단위는 좀 아닌거 같습니다. 불가피하게 사용해야만 하는 경우에는 물론 사용하실 수 있습니다.

7) 가상머신내 Bonding 사용
가상머신에 2개의 vNIC를 할당하고 이를 다시 Bonding으로 묶는 것은 불필요한 작업입니다. 성능 개선이나 SPoF를 대비하고자 한다면 하이퍼바이저 수준에서 Bonding 처리하는게 맞습니다. 가상머신내에서는 목적별로 하나의 vNIC를 사용하는게 좋습니다.

혹시 이러한 아키텍처가 여러분께서 생각하고 계셨던 것은 아니시지요? 만약 다른 특이한 아키텍처를 목격하셨다면 공유 부탁드립니다.

실전 활용팁, 라이브 마이그레이션시 가상머신 CPU 사용량 변화

Best Practice, vCPU utilization change while live-migration

얼마전에 라이브 마이그레이션에 대해 살펴보았는데요, 라이브 마이그레이션시에 가상머신 내의 CPU 사용률이 10~15% 정도 증가하는 현상이 발견되었습니다. 아무런 작업도 수행되지 않는데 이상했지요.

라이브 마이그레이션을 수행하면서 가상머신내에서는 vmstat 명령어를 통해 지속적으로 측정하도록 한 결과, ‘st’ 필드가 10~15%정도 거의 정확히 사용률이 증가한만큼 올라간 것을 확인하였습니다. 즉 vCPU의 CPU cycle을 라이브마이그레이션을 위해 Host 차원에서 소진하면서(Steal time: st) 그만큼 증가한 것으로 측정된 것으로 생각됩니다.

그래서 Steal time에 대해 좀 알아봤는데요, 예상한대로였습니다.

“Steal time is the percentage of time a virtual CPU waits for a real CPU while the hypervisor is servicing another virtual processor.” — http://blog.scoutapp.com/articles/2013/07/25/understanding-cpu-steal-time-when-should-you-be-worried

혹시 운영중에 이런 현상을 목격하시더라도 놀라지 마세요.

실전 활용팁, 라이브 마이그레이션 준비

Best Practice, live-migration prerequisites

oVirt/RHEV의 강점 중 하나가 online 상에서 가상머신을 서로 다른 ovirt-node(하이퍼바이저, 호스트)로 라이브 마이그레이션이 가능하다는 점 입니다. 서비스의 지속성 관점에서 매우 중요한 기능인데요, 실시간으로 서비스 중단 없이 호스트간에 이동이 가능한만큼 몇가지 조건을 만족시켜줘야 합니다.

* 용어 안내

  • Source 호스트 : 라이브 마이그레이션 대상 가상머신이 실행중인 호스트
  • Destination 호스트 : 실행중인 가상머신이 옮겨갈 대상 호스트

* 라이브 마이그레이션을 위한 조건

  1. Source, Destination 호스트가 모두 동일한 oVirt Cluster 소속, 동일한 CPU 호환성을 가져야 함 (Intel/AMD 벤더 및 CPU microarchitecture – Nehalem, SandyBridge 등)
  2. Source, Destination 호스트가 모두 Up 상태
  3. Source, Destination 호스트의 oVirt/RHEV Management Network 또는 Migration Network(3.3 이후)를 통해 접근 가능
  4. 대상 가상머신이 사용하는 oVirt/RHEV 스토리지 도메인에 Source, Destination 호스트가 모두 접근 가능
  5. Destination 호스트에 대상 가상머신 실행에 필요한 충분한 여유 메모리
  6. Source, Destination 호스트간 DNS 또는 /etc/hosts에 host명 resolve 필요
  7. 대상 가상머신에 ISO 이미지가 mount되어 있거나 attach 되면 안됨
  8. oVirt/RHEV 3.1-> oVirt/RHEV 3.0 라이브 마이그레이션은 지원하지 않음

* 대표적 라이브 마이그레이션 실패 사례

  • ISO 파일을 마운트 한 상태에서 시도 ==> umount, detach 후 재시도
  • 오래된 vdsm, libvirt 버전 사용 ==> 가능한 3.2 이후 최신 버전 사용 (3.4 권장)
  • 라이브 마이그레이션에 사용되는 네트워크 대여폭 부족에 따른 취소 ==> 대여폭 확보, 또는 3.3 이후 버전에서는 별도의 live-migration network 분리
  • 가상머신의 높은 부하로 인해 주어진 시간내 마이그레이션을 성공할 수 없는 경우 취소 ==> 부하가 줄었을 때 재시도, 또는 vdsm 설정에서” migration_downtime” 값을 늘린 후 재시도
  • RHEL 5.7 이전 버전에서 시스템 패닉 발생 ==> nmi_watchdog=0 커널 옵션 추가

 

참고 자료 : https://access.redhat.com/site/documentation/en-US/Red_Hat_Enterprise_Virtualization/3.4/html/Administration_Guide/Live_migration_prerequisites.html

실전 활용팁, 업무별 oVirt Guest 권장 디스크 유형

Best Practice, recommended virtual disk type in oVirt by workload

oVirt에서는 다음과 같이 2가지 가상머신 디스크 유형을 지원하고 있습니다. Thin Provision의 경우 디스크 공간을 절약할 수 있는 반면 단점도 있기 때문에 적합한 workload에 대한 신중한 선택이 필요합니다.

1) Preallocated 방식

  • DB, FTP, WAS 등 I/O가 비교적 많은 가상머신
  • 최초 생성후 장기간 운영되는 전통적 서버용 가상머신
  • 정기적인 백업등이 수행되는 중요 업무 환경
  • 공간 효율성보다 시스템 성능이 중시되는 서비스 환경

2) Thin Provision 방식

  • 데스크톱 등 생성 후 I/O가 비교적 적은 가상머신
  • 필요에 따라 생성되어 단기간 사용되고 사라지는 VDI용 가상머신
  • 클라우드 환경이 고려된 scale-out형 서비스
  • 공간의 효율성이 시스템 성능보다 중시되는 서비스 환경

oVirt/RHEV를 작은 규모의 클라우드 플랫폼으로 사용하는 경우가 아니고, 서버 가상화 관점에서만 본다면 Preallocated를 선택하는 것이 좋습니다.

실전 활용팁, 사이징

객관적인 근거없이 믿도 끝도 없이 개인의 감(?)으로 산정된 oVirt/RHEV 사이징을 공개합니다.

oVirt/RHEV 환경에서 소수의 하이퍼바이저와 가상머신을 가진 경우라면, 요즘 성능 좋은 단독 서버에 ovirt-engine(RHEV Manager)를 설치해 쓰는게 컴퓨팅 자원 낭비라고 생각될 수도 있습니다. 여기서 소수라고 함은 수대~수십대의 하이퍼바이저와 1백개 미만의 가상머신정도로 해두죠.

그러나, 계속해서 하이퍼바이저와 가상머신이 추가되는 환경이라면 ovirt-engine의 부하가 점차 증가함을 알 수 있습니다. 그도 그럴 것이 ovirt-engine은 주기적으로 모든 하이퍼바이저와 가상머신의 상태정보를 받아 기록하고 또 추적하기 때문입니다.

특히 Backend DB인 PostgreSQL 서버의 부하가 특히 병목이 될 수 있는데요, 추가적인 튜닝으로 일부 개선을 시킬 수 있으나, 이때부터 낭비라고 생각했던 하드웨어 스펙에 따라 전체적인 성능이 좌우됩니다.

수일에서 수주에 걸친 업무 및 부하 분석이 동반되는 Sizing과는 전혀 관계없이, 감에 의존한 사이징 정보는 다음과 같습니다. (자세한 내용은 전문가와의 상담을 권장합니다.) 참고로 oVirt/RHEV 3.3부터는 처리 성능이 대폭 개선되었습니다만 다음 정보는 3.2 기준입니다.

* 단일 ovirt-engine(RHEV Manager)당 최대 Sizing

  •  150 호스트 + 1200대 가상머신 (small VM) –> cloud-like workload
  •   150 호스트 + 600대 가상머신 (medium VM)
  •   150 호스트 + 400대 가상머신 (large VM) –> Traditional workload

따라서 10,000대 작은 규모의 가상머신을 운영하는 규모라면 9개정도의 ovirt-engine(RHEV Manager) 환경을 구축해볼 수 있습니다. 이들을 API와 적절한 네트워크 설계를 통해 연동 하는 것도 가능하지요. 다만 oVirt의 경우 OpenStack과 달리 애초에 Scale out에 초점을 맞춘 아키텍처는 아닙니다. 따라서 Cloud-like workload나 Scale out이 중요한 환경에 최적의 플랫폼은 아니라는 점은 반드시 고려되어야 하겠습니다.

* 조건에 따른 적절한 선택

  •  기존 물리 서버의 가상화 또는 중소규모의 클라우드라면 oVirt
  • 클라우드 서비스 또는 대규모 클라이드 환경을 목표로 한다면 OpenStack
  • 하드웨어 종속적 기능이 요구되거나 성능이 중시되는 환경이라면 가상화보다는 Docker와 같은 Contaner

실전 활용팁, 스토리지

* 재앙의 시작

oVirt/RHEV 사용 및 운영에서 가장 골치아픈 부분이 스토리지 관련 부분입니다. 스토리지쪽은 다수의 하이퍼바이저가 공유하고 동시에 사용하기 때문에 장애나 문제 발생 시 그 영향도가 단일 시스템을 넘어서기 때문입니다. 더욱이 한번 구축을 해 놓은 이후부터는 쉽게 변경하기 어려운 측면도 있습니다.

따라서 가능하면 아키텍처를 그리는 단계에서부터 신중하게 종류(NFS, iSCSI, FCP, GlusterFS)를 선택하고, 용량을 산정하고, 구축해야 향후 발생할지 모를 재앙(?)으로부터 가상 데이터센터를 보호할 수 있습니다.

* 새로운 희망

다행스러운 점은 oVirt/RHEV 3.4부터는 여러 종류의 스토리지를 함께 사용할 수 있어서 유연성이 증가했다는 부분이고, 더불어 관리 비용도 감소될 수 있겠네요. 게다가 3.2부터 GlusterFS가 추가되면서 파일기반의 VM Image 변환이 되어 iSCSI/FCP를 사용했을 때 Block device를 묶기 위해 사용된 LVM의 한계도 피할 수 있게 되었습니다. (물론 LVM의 장점도 무척 많지만 말입니다)

* 스토리지 유형 선택 팁

당연히 성능이 중요하고, 규모가 상대적으로 적으며(Manager당 수십대의 하이퍼바이저 수준), 부하가 예측되며 아키텍처 변화가 적은 환경에서는 iSCSI/FCP가 선호될 것입니다. 만약 규모가 크고(Manager당 백대 이상의 하이퍼바이저 수준), 부하가 예상되지 않는 경우라면 GlusterFS를 기본으로 하고 경우에 따라 다른 스토리지 유형도 섞어서 쓰는 전략이 필요할 것 입니다.

* iSCSI/FCP 구축 팁

마지막으로 iSCSI/FCP에 기반한다면, 다른 인프라와 공유하지 않는 oVirt/RHEV 전용의 스토리지를 사용하는게 혹시 있을지 모를 스토리지 단의 Human fault의 피해를 줄일 수 있으며(스토리지 엔니지어의 실수로 막대한 결과를 초래한 사례가 있었습니다.), oVirt/RHEV의 스토리지 도메인당 여러 LUN을 묶기보다는 큰 LUN으로 구성하는게 좋습니다. 더불어 업무 등급별 스토리지 도메인를 나누어서, 하나의 스토리지 도메인에 Fault가 발생하더라도 피해 규모를 줄이는게 도움이 됩니다.