VDI 환경에서 AV Storm을 경험하다. 본문
제가 사내 IT 업무를 책임지고 수행하면서 계획했던 많은 일들과 시도한 것들 중에서 현재 제일 보람을 느끼고 잘했다고 생각하는 것 중 하나가 바로 데스크탑가상화입니다. 특히나 당사는 항공과 관련된 일로 잦은 해외 출장과 서울사무소 외 기타 외부에서의 업무처리가 많으면서 더욱 더 큰 효용을 보고 있습니다.
여기에서 데스크탑가상화의 장점을 일일이 다 설명하기는 어려울 것 같구요. 그리고, 그런 자료는 제가 아니더라도 구글링을 통해서 충분히 검색이 가능하다고 보여지네요. 나중에 시간이 나면 한 번 정리해서 올리도록 하겠습니다. 늘 생각은 하고 있지만 그게 잘 되지 않아서...
VDI(데스크톱가상화)를 도입하고 나서 제일 큰 어려운 점은 사용자들의 인식 개선입니다.아무래도 가상화 환경이다 보니 PC에서 직접 작업하는 것 보다는 처리 속도나 응답 속도 면에서 조금 더 느릴 수 있습니다. 그렇지만 그것이 업무를 수행하는데 있어 불편할 정도는 아닌데...일단 사용자들은 기존에 사용하던 PC와 동일하기를 바라고 있습니다. 사실 VDI 사용하면서 얻게 될 효용은 처리 속도나 응답 속도에 있는 것이 아니라 다른 곳에 있는데 말이죠.
그리고, 중앙 서버 자원을 사용한다는 것 때문에 자신이 PC에서 하는 행위들이 모니터링되지 않을까? 하는 염려도 있습니다. 이러한 이유 때문에 VDI를 사용하면서 사소한 문제점이 발생하거나 트집꺼리라도 생기면 일단 VDI 때문이다. VDI 불편하다는 얘기들을 쉽게 내 뱉습니다.
저희 회사에서 2014년도부터 사업관리/정보화/임원 분들을 통해서 우선적으로 1차로 적용해서 사용을 해보고, 크게 문제가 없다고 판단이 되어져, 2015년에도 2차 확대 적용을 수행하여 현재는 전체 사내 PC의 30% 정도가 VDI로 전환되어졌습니다. 사용자의 환경도 대부분 Zero Client 환경이구요. 처음에는 작은 문제들이 몇 몇 발생했습니다. 그럴 때 마다 사용자들은 모든 문제가 VDI 환경 때문이라 생각을 했죠.
그런데, 저희가 지금까지 확인된 문제점 중에서 VDI라서 안된다고 했던 모든 것들을 다 해결했습니다. 실제는 VDI가 문제가 아니라 프로그램과의 호환성이나 Zero Client 기기의 문제, 또는 PCoIP 프로토콜의 문제 등... 대부분 발견된 문제는 환경 설정 값을 조정하거나 펌웨어를 업데이트 하거나 해서 다 해결했습니다.
참, 한 가지 VDI에서 해결하지 못한 것이 있습니다. 당사에서 Skype 환경에서 화상회의 시스템을 구축했는데, USB 기반의 외부기기 연결을 통해 영상과 음성을 처리하는데, Zero Client에 해당 기기를 붙였을 때 인식을 하지 못합니다. 그래서 회의실에는 VDI가 아닌 PC를 사용하고 있습니다. 그 하나 말고는 다 해결한 것 같네요.
암튼 그렇게 VDI를 잘 이용하고 있고, 사용하고 있는데 최근에 VDI 사용자가 점진적으로 증가하면서 일과 중에 VDI 사용자들에서 속도저하 문제와 응답지연 문제가 간헐적으로 반복해서 발생하는 것이었습니다.
처음 관리업체 담당자와 협조하에 원인을 분석결과 View의 블랙아웃 설정값 때문인줄 알고 블랙아웃 작업을 일과 시간 외에 수행할 수 있도록 조정을 하였습니다. 설정된 내용은 아래와 같습니다.
참고로 블랙아웃 시간이란... VDI를 사용하게 되면 공유스토리지를 통해서 다수의 사용자가 접속하여 파일을 읽고/쓰는 등의 행위를 하기 때문에 스토리지가 어수슨하게 되겠죠. 그래서 PC의 디스크 조각모음과 같은 작업을 통해서 사용자지 않는 공간은 회수하고 파일을 정리하여 속도를 개선하는 작업을 수행하는데... 그러한 작업 시 시스템 리소스와 함께 스토리지 I/O latency가 발생하게 되는데 이를 피하기 위해 블랙아웃 시간을 설정하여 해당 시간을 피하도록 설정할 수 있습니다
문제는 당사 정규근무 시간인 평일 08:00-17:00을 블랙아웃 시간으로 설정하여, 해당 시간을 피해서 스토리지 가속 재성 및 VM 공간회수 작업을 수행하도록 했었는데, 당사에서 문제가 된 시점이 화요일 저녁 7시(19:00)경에 몇 차례 반복적으로 나타나 해당 블랙아웃 설정을 원인으로 보고 위 그림과 같이 블랙아웃 시간을 조정하였습니다.
평일(월, 화, 수, 목, 금) 08:00~22:00, 토요일 08:00~17:00
이제는 같은 증상이 나타나지 않아야 되는데... 제가 회사가 아닌 밖에 있을 때 오후 시간대에 같은 증상이 또 나타났다고 담당자로부터 연락이 왔었습니다.
그래서, 다른 원인을 찾고자 모니터링한 결과 최근에 사내 그룹웨어를 개발하면서 개발서버를 추가로 5대 올렸는데 해당 서버가 가상화기반에서 같은 RAID안에 구성된 스토리지를 사용하면서 발생된 문제점이 아닐까 해서 추적을 했는데, 그 문제도 아닌 것으로 판명이 났습니다.
결국 추가적으로 Log 정보를 분석한 결과 매 시간 30분 단위로 스토리지 I/O에 대한 latency가 발생하는 것으로 확인이 되었고, 매 시간 30분 단위로 주기적으로 실행되는 patch 작업이 뭐가 있을까 추적해 보니, 바로 Anti-Virus Vaccine의 DB 업데이트가 문제가 되었습니다.
아래 그림과 같이 당사 AV의 중앙통제센터에서 확인한 결과 저장소 업데이트(중앙 관리 서버)를 완료한 후 클라이언트들의 DB 업데이트 작업이 수행되어지도록 설정이 되어 있습니다.
그래서, 중앙 관리 서버는 언제 업데이트를 수행했는지 Log를 확인해 보니 매시간 단위로 업데이트 작업을 수행하되 대체적으로 업데이트가 완료된 시점이 매 25, 26, 27. 28분 중에서 완료가 되었습니다. 추리를 해 보면 중앙 서버가 업데이트 된 직후인 30분경에 클라이언트의 DB 업데이트 작업이 수행이 되었던 것입니다.
이 때 PC 환경의 사용자는 각 PC에서 부하가 걸리기 때문에 I/O latency가 분산되어져서 각 개인은 크게 속도 저하를 느끼지 못하나 VDI 사용자들은 각 VM에서 I/O latency가 발생되는 것이 결국의 VDI를 운영하는 Hypervisor 단에 부하가 걸리기 때문에 전체 사용자의 속도가 늦어지는 현상이 발생하였던 것입니다.
이렇게 추론이 되어지고 나서 AV 통제센터의 로그와 Hypervisor의 로그를 분석해 보닌 내용이 일치함을 확인하였습니다. 원인을 찾았으면 아래와 같이 AV DB 업데이트 작업도 일과 시간이 아닌 출근전 새벽 5시에 수행하도록 해 놓고(당사는 VDI의 Boot Storm을 피하고 사용자가 VDI 호출 시 빠른 응답을 위해 사용자가 VDI의 VM을 Off 하더라도 5분 후 자동으로 On이 되도록 설정) 3시간(일과 시작 시간인 8시)동안 업데이트가 완료되지 않으면 중단하도록 설정하였습니다.
이후 이 문제가 정상적으로 조치되었는지 확인 및 검증을 위해 log를 분석해 보니, 실제로 매일 새벽 5시에 VDI 환경의 exsi 호소트에서 I/O latency 이슈가 발생되었음을 확인할 수 있었습니다. 근본적으로 latency 발생 자체를 없애지는 못했지만, 불가피한 작업이기 때문에 작업 시간을 일과외 시간으로 조정하여 문제점을 해결할 수 있었습니다.
혹시나 해서 그 이전 일 며칠 분의 로그를 확인해보니 다른 시간대는 발생치 않고 매일 새벽 5시경에 발생한 것을 확인할 수 있었습니다.
일단 문제점은 조치되었습니다.
그러나 근본적인 해결책은 아닙니다. 그렇다고 VDI 사용자의 AV에 대한 DB 업데이트를 수행하지 않을 경우 발생될 수 있는 보안 Risk를 무시할 수 없습니다.
예전에 vForum 참가 시나 보안관련 세미나 참석 시 VDI 환경 전용 AV 제품이 있었는데, 당시는 필요성을 느끼지 못했는데, 이제서야 왜 그런 제품이 나왔는지 알 수 있는 좋은 경험이었습니다. VDI 환경 전용 AV 제품들은 Hypervisor 단에서 작동되기 때문에 개별 Client에서 수행되는 것이 아니라 서버단에서 발생되는 이벤트를 감시하기 때문에 하나의 관리 시스템만 업데이트 작업을 수행하기 때문에 이 문제를 피할 수 있으리라 예상이 됩니다.
금년도 AV 계약 체결 시는 이점을 반영하여 VDI 전용 백신도 도입해야 할 것 같습니다. 이상 저의 VDI 환경에서의 AV Storm에 대한 경험기였습니다.