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

실전 활용팁, 이렇게 구축 하시면 안 돼요!
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를 사용하는게 좋습니다.

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