2012.09.20

IDG 블로그 | 왜 가상화가 모니터링 시스템을 붕괴시키는가

Paul Venezia | InfoWorld
필자는 현재 관리하고 있는 것들과 관련해서 무슨 일이 일어나고 있는지는 알고 싶어하고, 그래서 대규모 모니터링 인프라를 지지하는 사람 중 하나이다. 실제로 필자는 IT 인프라 구성요소를 모니터링하고 관리하고 추적하기 위한 코드를 기억할 수도 없을 만큼 많이 작성했다. 아직도 많은 사람들이 필자가 몇 년 전에 작성한, 그래서 실제로는 잊어버린 플러그인이나 코드에 대한 이메일을 보내오기도 한다.
 
이런 노력의 상당수는 UPS에서부터 PDU, 에어컨, 서버, 스위치, 파이어월 등 고정된 모든 IT 장비를 모니터링하기 위한 것이다. 최근까지도 이들 코드는 한 가지 특징을 함께 가지고 있었다. 바로 이들 코드가 동일한 IP 주소를 사용해 동일한 하드웨어 상에서 구동되는 동일한 데이터센터 내에 적용됐다는 것이다. 하지만 오늘날에는 전력과 냉각 장비를 제외하고는 이런 가정을 하는 것은 위험하다.
 
완전히 모듈화된 데이터센터를 지향하고 있는 한편으로, 이런 인프라를 모니터링하고 유지보수하는 것이 과거처럼 단순하지 않다는 것도 알게 된 것이다. 여러 대의 서버로 구성된 전체 애플리케이션 스택이 이 데이터센터에서 저 데이터센터로 옮겨질 수 있기 때문에, 이에 맞춰 이들을 추적하고 모니터링을 조정해야 한다. 애플리케이션 성능이나 네트워크 지연이 변하고 치솟으면, 과연 이것이 실제 문제인지 아니면 모니터링을 수행하는 시스템이 갑자기 대상으로부터 논리적으로 멀리 떨어지게 된 것인지를 파악해야 한다. 물리 호스트의 네트워크 접속이 끊어져 없어졌는지 파악해야 할 필요도 있다. 물론 문제가 아닐 수도 있다.
 
만약 실제 문제가 발생한 것이라면, 그 사실을 즉각적으로 알아야 한다. 따라서 시스템이 이런 변화를 알려줄 수 있도록 자동화해야 할 필요가 있다.
 
이런 새로운 현실은 오랫동안 사용해 온 모니터링 시스템에 적지 않은 부담을 주고 있다. 상용 솔루션이든 오픈소스이든, 이들은 일시적이고 언제든지 대체될 수 있는 인프라 요소에 맞춰 설계된 것이 아니다. 이들 모니터링 시스템의 목적은 모든 것이 원래의 좋은 상태 그대로 유지되고, 변화가 생기면 경고를 보내줄 수 있도록 하는 것이었다. 하지만 이제는 부정적인 변화로 보이는 것이 실제로는 정상인지 아닌지를 판단할 수 있는 중간 계층을 두어야만 한다.
 
대표적인 예가 VM웨어의 DPM(Dynamic Power Management)이다. DPM을 설정해 활성화시킬 때, v센터는 가용 자원이 현재의 활용 수준을 초과하는지 확인하려 하고, 자동으로 당시 시점에서 불필요다고 간주되는 ESXi 호스트를 다운시켜 버린다. 그리고 워크로드가 증가하면 DPM이 이들 호스트를 켜고, DRS(Dynamic Resource Scheduling)가 워크로드를 분산시켜 준다. 이 기능은 데이터센터의 전력과 냉각 비용을 절감해 주는 동시에 컴퓨팅 용량을 필요에 따라 가용한 상태로 만들어준다.
 
하지만, 기존의 모니터링 시스템을 이들 호스트에 연결하려 한다면, 모니터링 플랫폼에서 ESXi 호스트가 사라질 수 있고, 그런 사실이 경고를 필요로 하는 문제가 아니라는 것을 받아들이지 않는 한 많은 문제에 부딪히게 될 것이다. 다른 한편으로, 만약 가동중인 호스트에 문제가 잇으면, 경고가 발생해야 한다. 하지만 DPM의 동작 과정에서는 호스트가 자동으로 다운되면서 경고를 보낼 수 있다. 이 시점에서 많은 외부 모니터링 시스템에게는 호스트 모니터링을 포기하고 이 부하를 v센터로 옮기는 것이 가장 쉬운 방법이 된다.
 
불행하게도 v센터는 많은 모니터링 작업을 처리할 만큼 여유롭지 않다. 그리고 분명 v센터는 전통 네트워크 및 시스템 모니터링 솔루션과 같은 역량을 가지고 있지도 않다. VM웨어 v센터는 여전히 글로벌 경고를 설정할 좋은 방법을 내놓지 않고 있다. 모든 베테랑 VM웨어 관리자처럼 PowerCLI를 이용해 자동적으로 발생하는 경고를 설정하는 방법을 취할 수 있다. 하지만 너무 많은 것이 모호하고, 구체적이지 못하다.
 
그리고 v센터는 DPM과 같은 자체 동작에 대해 유사 알람을 많이 만들어내는 것으로 알려져 있기도 하다.
 
더 많은 가상화 인프라 요소를 이런 복잡한 환경에 추가하는 것은 문제를 더욱 복잡하게 만든다. 전용 서버 상에서 구동되는 공정한 서드파티 앱으로 하여금 가상화된 인프라를 감시하도록 하는 대신, 이 서비스가 v센터와 같은 단일 서버를 모니터링하고, 정작 다른 수많은 인프라 요소는 이 단일 서버가 책임을 지는 상황이 되는 것이다. 본질적으로 이는 자기 집 강아지에게 카펫에 오줌을 쌌냐고 물어보는 격이다. 그리고 얼마 후, 강아지가 거짓말을 했다는 것을 알고는 실망하는 것이다.
 
물론 v센터를 통해 모든 종류의 상세한 사항을 모니터링할 수 있다. 다양한 API와 CLI를 통합해 전체 구조에 가상화된 인프라의 운영에 대한 의미있는 통찰을 얻을 수도 있다. 하지만 여전히 단일 지점을 통해 모든 것을 점검한다는 사실은 변하지 않는다. 이 단일 지점은 많은 것들을 뒤에 남겨둘 수도 있고, 때로 진실을 이야기하지 않을 수도 있다.
 
이 문제에 대한 명확한 해답은 고정된 모니터링 시스템을 가상 환경에 맞추는 조화로운 노력이라고 할 수 있다. 앞으로 점점 더 많은 인프라가 가상화라는 게임에 깊숙이 빠져들 것이며, 업체와 오픈소스 전문가들은 이런 변화에 맞춰 솔루션을 다시 만들어 낼 것이다. 그때까지는 가능한 자주 직접 문제를 카펫을 점검하고, 때로 한두 번 카펫을 세탁하게 되더라도 너무 놀라지 않아야 할 것이다.  editor@itworld.co.kr



2012.09.20

IDG 블로그 | 왜 가상화가 모니터링 시스템을 붕괴시키는가

Paul Venezia | InfoWorld
필자는 현재 관리하고 있는 것들과 관련해서 무슨 일이 일어나고 있는지는 알고 싶어하고, 그래서 대규모 모니터링 인프라를 지지하는 사람 중 하나이다. 실제로 필자는 IT 인프라 구성요소를 모니터링하고 관리하고 추적하기 위한 코드를 기억할 수도 없을 만큼 많이 작성했다. 아직도 많은 사람들이 필자가 몇 년 전에 작성한, 그래서 실제로는 잊어버린 플러그인이나 코드에 대한 이메일을 보내오기도 한다.
 
이런 노력의 상당수는 UPS에서부터 PDU, 에어컨, 서버, 스위치, 파이어월 등 고정된 모든 IT 장비를 모니터링하기 위한 것이다. 최근까지도 이들 코드는 한 가지 특징을 함께 가지고 있었다. 바로 이들 코드가 동일한 IP 주소를 사용해 동일한 하드웨어 상에서 구동되는 동일한 데이터센터 내에 적용됐다는 것이다. 하지만 오늘날에는 전력과 냉각 장비를 제외하고는 이런 가정을 하는 것은 위험하다.
 
완전히 모듈화된 데이터센터를 지향하고 있는 한편으로, 이런 인프라를 모니터링하고 유지보수하는 것이 과거처럼 단순하지 않다는 것도 알게 된 것이다. 여러 대의 서버로 구성된 전체 애플리케이션 스택이 이 데이터센터에서 저 데이터센터로 옮겨질 수 있기 때문에, 이에 맞춰 이들을 추적하고 모니터링을 조정해야 한다. 애플리케이션 성능이나 네트워크 지연이 변하고 치솟으면, 과연 이것이 실제 문제인지 아니면 모니터링을 수행하는 시스템이 갑자기 대상으로부터 논리적으로 멀리 떨어지게 된 것인지를 파악해야 한다. 물리 호스트의 네트워크 접속이 끊어져 없어졌는지 파악해야 할 필요도 있다. 물론 문제가 아닐 수도 있다.
 
만약 실제 문제가 발생한 것이라면, 그 사실을 즉각적으로 알아야 한다. 따라서 시스템이 이런 변화를 알려줄 수 있도록 자동화해야 할 필요가 있다.
 
이런 새로운 현실은 오랫동안 사용해 온 모니터링 시스템에 적지 않은 부담을 주고 있다. 상용 솔루션이든 오픈소스이든, 이들은 일시적이고 언제든지 대체될 수 있는 인프라 요소에 맞춰 설계된 것이 아니다. 이들 모니터링 시스템의 목적은 모든 것이 원래의 좋은 상태 그대로 유지되고, 변화가 생기면 경고를 보내줄 수 있도록 하는 것이었다. 하지만 이제는 부정적인 변화로 보이는 것이 실제로는 정상인지 아닌지를 판단할 수 있는 중간 계층을 두어야만 한다.
 
대표적인 예가 VM웨어의 DPM(Dynamic Power Management)이다. DPM을 설정해 활성화시킬 때, v센터는 가용 자원이 현재의 활용 수준을 초과하는지 확인하려 하고, 자동으로 당시 시점에서 불필요다고 간주되는 ESXi 호스트를 다운시켜 버린다. 그리고 워크로드가 증가하면 DPM이 이들 호스트를 켜고, DRS(Dynamic Resource Scheduling)가 워크로드를 분산시켜 준다. 이 기능은 데이터센터의 전력과 냉각 비용을 절감해 주는 동시에 컴퓨팅 용량을 필요에 따라 가용한 상태로 만들어준다.
 
하지만, 기존의 모니터링 시스템을 이들 호스트에 연결하려 한다면, 모니터링 플랫폼에서 ESXi 호스트가 사라질 수 있고, 그런 사실이 경고를 필요로 하는 문제가 아니라는 것을 받아들이지 않는 한 많은 문제에 부딪히게 될 것이다. 다른 한편으로, 만약 가동중인 호스트에 문제가 잇으면, 경고가 발생해야 한다. 하지만 DPM의 동작 과정에서는 호스트가 자동으로 다운되면서 경고를 보낼 수 있다. 이 시점에서 많은 외부 모니터링 시스템에게는 호스트 모니터링을 포기하고 이 부하를 v센터로 옮기는 것이 가장 쉬운 방법이 된다.
 
불행하게도 v센터는 많은 모니터링 작업을 처리할 만큼 여유롭지 않다. 그리고 분명 v센터는 전통 네트워크 및 시스템 모니터링 솔루션과 같은 역량을 가지고 있지도 않다. VM웨어 v센터는 여전히 글로벌 경고를 설정할 좋은 방법을 내놓지 않고 있다. 모든 베테랑 VM웨어 관리자처럼 PowerCLI를 이용해 자동적으로 발생하는 경고를 설정하는 방법을 취할 수 있다. 하지만 너무 많은 것이 모호하고, 구체적이지 못하다.
 
그리고 v센터는 DPM과 같은 자체 동작에 대해 유사 알람을 많이 만들어내는 것으로 알려져 있기도 하다.
 
더 많은 가상화 인프라 요소를 이런 복잡한 환경에 추가하는 것은 문제를 더욱 복잡하게 만든다. 전용 서버 상에서 구동되는 공정한 서드파티 앱으로 하여금 가상화된 인프라를 감시하도록 하는 대신, 이 서비스가 v센터와 같은 단일 서버를 모니터링하고, 정작 다른 수많은 인프라 요소는 이 단일 서버가 책임을 지는 상황이 되는 것이다. 본질적으로 이는 자기 집 강아지에게 카펫에 오줌을 쌌냐고 물어보는 격이다. 그리고 얼마 후, 강아지가 거짓말을 했다는 것을 알고는 실망하는 것이다.
 
물론 v센터를 통해 모든 종류의 상세한 사항을 모니터링할 수 있다. 다양한 API와 CLI를 통합해 전체 구조에 가상화된 인프라의 운영에 대한 의미있는 통찰을 얻을 수도 있다. 하지만 여전히 단일 지점을 통해 모든 것을 점검한다는 사실은 변하지 않는다. 이 단일 지점은 많은 것들을 뒤에 남겨둘 수도 있고, 때로 진실을 이야기하지 않을 수도 있다.
 
이 문제에 대한 명확한 해답은 고정된 모니터링 시스템을 가상 환경에 맞추는 조화로운 노력이라고 할 수 있다. 앞으로 점점 더 많은 인프라가 가상화라는 게임에 깊숙이 빠져들 것이며, 업체와 오픈소스 전문가들은 이런 변화에 맞춰 솔루션을 다시 만들어 낼 것이다. 그때까지는 가능한 자주 직접 문제를 카펫을 점검하고, 때로 한두 번 카펫을 세탁하게 되더라도 너무 놀라지 않아야 할 것이다.  editor@itworld.co.kr

X