말도 많고 탈도 많은 Hyper-v : 그 두번째 이야기

 

Micorosoft 의 개발자라고 하면, 슈퍼 개발자들이 우글우글할 것이다. 실제로도 그렇고, DBMS, OS 등의 걸출한 제품을 볼 때 정말 그들이 동일하게 손 발이 달린 인간인가 싶은 생각이 들 때도 많다.

 

하지만, 자질만큼이나 중요한 것이 경험이라는 요소이다. VMWare 를 처음 만들 때, MS 개발자들 입장에서 보기에는 웃기지도 않는 제품이었을 수 있다. 하지만, 이제는 많이 달라져 버렸다. EMC 에 인수되면서 Windows, Linux 등의 인텔 머신 가상화 하면 단연 VMware 다.

 

더 중요한 문제는 VMWare 에서는 생기지 않거나 한참 이전에 해결된 문제가 Hyper-v 에서는 발생하고 있다는 것이다. 대표적인 문제가 매모리 과다 사용시에 발생하는 BSOD 문제고, 더 큰 문제는 Network 사용량이 집중될 때 발생하는 netwokr 불통 문제다.

즉, 스스로에게 ping 은 되지만, default gateway 로도 ping 이 되지 않는 상황이 발생한다. 더 황당한 점은 시스템에 이벤트 및 어떠한 증거도 남지 않는 다는 것이다.

 따라서 해당 문제가 발생한 경우 모니터링으로 해결하는 수 밖에 없다.
 모니터링을 통하여 덤프 및 IO 자료를 수집하는 것이다.

 BSOD의 경우 해당 시점에 전체적인 불통이 발생하게 되므로 정확한 시점을 추적하거나 해당 시점의 장애 예방을 위한 Data 수집에 문제가 없다. 이 의미는 한번 발생하면 재발 방지를 위해 추가적인 data 수집이 필요없다는 것이다.

 

아직 대부분의 사람들이 모르고 있겠지만, Hyper-v 상의 guest OS 에 네트워크의 세션이 과도하게 많이 발생하는 경우 시스템의 network 가 외부로 단절되는 현상이 있다. 즉, 스스로에게 ping 은 되지만, default gateway 로도 ping 이 되지 않는 상황이 발생한다. 더 황당한 점은 시스템에 이벤트 및 어떠한 증거도 남지 않는 다는 것이다.

 따라서 해당 문제가 발생한 경우 모니터링으로 해결하는 수 밖에 없다.
 모니터링을 통하여 덤프 및 IO 자료를 수집하는 것이다.

 그것이 제대로 된 자료라면 그 때부터 분석이 시작된다. 유감스럽게도 그 분석 자체도 아직은 국내의 기술진으로 수행되는 것이 아닌 듯 하다.
 현재 내부적으로 패치가 작성되고 있는 것으로 보인다.
 R2 가 안전되려면 적어도 다음 서비스 팩이 나온 이후라야 할 것 같다.

 IT 정책 결정자로서 가상화를 고려하고 있다면, 최소한 다음 버젼의 서비스 팩이 나오기 이전까지는 약간 도입의 시기를 고려해 봄직하다.