실전 활용팁, 사이징

객관적인 근거없이 믿도 끝도 없이 개인의 감(?)으로 산정된 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 3.4의 새로운 기능 #4. ovirt-image-repository

oVirt 3.4를 설치했을 때 특징으로는 External Provider 항목에 기본적으로 oVirt 프로젝트에서 제공하는 OpenStack Glance Image Repository가 등록되어 있다는 점입니다.

해당 Repository로부터 Pre-configured OS Image를 Import해서 사용할 수 있어 편리하기도 하고 OpenStack과의 통합을 바로 맛볼 수 있어 좋은 경험인 것 같습니다. 프로젝트에서 얼마만큼의 부하를 견딜 수 있을지 모르겠지만 Public oVirt Image Repository로서 괜찮은 시도인 것 같습니다.

“With 3.4, oVirt engine comes pre-configured with a public Glance instance managed by the oVirt project. We’ll tap this resource to launch our first VM.

From the storage tab, you should see an “ovirt-image-repository” entry next to a little OpenStack logo. Clicking on this domain will bring up a menu of images available in this repository.” – http://community.redhat.com/blog/2014/03/up-and-running-with-ovirt-3-4/

oVirt/RHEV 3.4의 새로운 기능 #3. Multiple Storage Domains 지원

oVirt/RHEV 3.4’s new feature #3. Multiple Storage Domains

그동안의 기초 시리즈를 통해 oVirt 논리적 아키텍처에서 가장 큰 구성 단위가 Data Center라는 것을 아실 것입니다. Data Center를 구성할 때 고려해야할 가장 큰 요소는 해당 Data Center에서 사용할 Storage 유형(FCP, iSCSI, NFS, GlusterFS, PosixFS)인데, 그동안 하나의 Data Center에서는 오직 하나의 Storage Type만 사용할 수 있었습니다. 즉, 구성시 iSCSI만 사용하도록 했다면 해당 Data Center내의 모든 가상 자원은 iSCSI 스토리지만을 사용해야 했습니다.

3.4부터는 하나의 Data Center내에서도 여러 Storage Type을 사용할 수 있게 되었습니다. 단언컨데 3.4에서 가장 획기적인 개선사항으로 보이는 이 기능을 활용하면, 운영용/백업용, 주요 업무용/보조 업무용 Storage Domain을 구분하여 사용할 수 있으며, 향후 확장성이나 비용 측면에서도 절감이 가능할 것으로 생각됩니다.

아직 이 부분에 대해서 테스트를 진행하기 전이라서 얼마만큼 손쉽게 사용할 수 있는지는 모르겠지만, 기대되는 기능임은 분명하네요.

http://www.ovirt.org/Features/MultipleStorageDomains

oVirt/RHEV 3.4의 새로운 기능 #2. Portal 낮은 해상도 지원

oVirt/RHEV 3.4’s new feature #2. Lower Resolution Support

1차 oVirt Korea 모임에서 oVirt 데모하면서 직접 경험했고 또 말씀드렸던 부분인데 그동안 oVirt Admin Portal, User Portal 사이트가 1024×768 이하 모니터에서는 일부 UI가 깨지거나 겹쳐져 보이는 문제가 있었습니다. 800×600이야 그럴수도 있겠다 싶지만 1024×768의 경우 oVirt Engine을 가상머신에서 테스트용도로 사용할때 많이 사용하는 해상도이다보니 아쉬움이 큰 부분이였습니다.

3.4에서는 이제 1024×768 또는 그보다 낮은 해상도에서도 정상적으로 사용할 수 있도록 개선되었습니다. 작은 화면에 따른 사용의 불편함은 어쩔수 없더라도 UI가 깨지거나 겹쳐지는 문제가 해소된만큼 낮은 해상도의 빔 프로젝터를 사용한 데모도 원할해지게 되었습니다.

http://www.ovirt.org/Features/Design/LowerResolutionSupport

oVirt/RHEV 3.4의 새로운 기능 #1. Predictable vNIC Order

oVirt/RHEV 3.4’s new feature #1. Predictable vNIC Order

oVirt 3.4가 릴리즈되었으니 이제 3.4 기능을 좀 살펴볼까요? (아직 3.3도 다 소개되지 않았는데… ) 3.4에 큼직큼직한 변화가 있긴 했지만 당장 눈에 띄는건 오히려 작은 기능들이네요.

그동안 oVirt/RHEV에서 Guest OS에 다수의 vNIC를 할당하고 부팅하면, Guest에서 vNIC에 대한 eth0, eth1,…. ethX 순서가 임의로 지정되어 나타났었습니다. 일반적으로는 HWADDR과 udev등으로 최초 설정하고나면 문제가 없지만, 계속해서 신규 VM을 생성하는 경우에는 좀 번거로운 뒷작업이 필요했었습니다.

이는 oVirt/RHEV에서는 MAC order를 따르고, libvirt에서는 PCI order를 따르도록 되어있어 Guest OS에 따라 Ordering 결과도 달랐기 때문입니다. 3.4에서는 MAC 주소를 vNIC를 생성할때가 아니라 VM이 실행될때 할당하도록 하여 이러한 문제를 해소하고 NIC 순서를 예측가능하도록(Predictable vNIC Order) 개선하였습니다.

그동안 개인적으로 카오스 상태여서 업데이트를 못하고 있었는데요, 회원분들께서도 침묵을 지켜시고 계셔서…분위기 다운되면 안되겠다 싶어 올립니다.

http://www.ovirt.org/Feature/Predictable_vNIC_Order

실전 활용팁, 스토리지

* 재앙의 시작

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가 발생하더라도 피해 규모를 줄이는게 도움이 됩니다.

실전 활용 팁, 서버 하드웨어

개인적인 경험상 oVirt과 같은 다수의 범용서버로 구성되는 인프라 구축시에는 블레이드형 서버보다는 랙형 서버가 효과적이고 또 장애확산으로부터 좀 더 자유롭습니다. OpenStack도 마찬가지일것으로 예상되는데요, 블레이드 서버의 펌웨어의 좋은 기능들이 이런 환경에서는 오히려 역효과를 주는거 같습니다.