VMware, 메모리 문제, 그리고 MA

Bookmark and Share

VMware/vSphere 5.5를 기반으로 한 가상 인프라 환경을 운영하던 중에 발생한, HP, VMware, 메모리 사용 등과 관련된 매우 기분 좋지 않은 현상에 대한 기록이다.

사건의 경위

모든 사건이라는 게… 배경이 있기 마련이다. 그럴만한 배경.

배경

이번 사건은 다음과 같은 조건 속에서 일어난 사건이다.
(사건과 직접적으로 관련된 조건 들)

  • 문제가 발생한 서버의 하드웨어는 HP DL380p Gen8 이다.
  • 문제가 발생한 서버의 vOS는 VMware vSphere 5.5 이다.
  • vSphere는 HP OEM 버전으로 설치되었으며, 이 버전에는 HP 서버에 특화된 일부 유틸리티나 드라이버가 포함되어 있다.

그리고,

  • 나는 매우 게으른 시스템 운영자이다. 내 서버들을 날마다 꼼꼼히 살피지는 않는다.
  • 바쁘다는 핑계로, 내가 사용하는 기술들의 동향이나 보고된 문제점에 대하여 주기적인 확인을 하지 않는다.

사건!

가상환경에 새로 VM을 올리는 작업을 위해 vSphere Client를 이용하여 문제의 환경에 접속하였고, 다음과 같은 작업을 진행하려 했다.

  • ISO를 DataStore에 Host에 scp 전송 시도: 실패
  • Host 상태 확인을 위해 ssh 접속 시도: 실패
  • vSphere Client에서 신규 VM의 전원 On: 실패
  • Host 재기동에 앞서 VM Migration 시도: 실패

그리고 이 모든 작업의 실패 뒤에는, 예를 들어 다음과 같은, 메모리와 관련된 오류 메시지를 볼 수 있었다.

vmware-hp-memory--00.png

이렇게 메모리 부족으로 VM을 시작할 수 없다라던가,

vmware-hp-memory--02.png

Migration이나 HA Failover를 할 수 없다는 둥…

해결

확인을 해보니, 이것이 HP OEM 버전에 포함된 "hp-ams", Agentless Management Service 라는 모듈에 의해 발생하는 문제라는 보고가 있고, 나의 환경이나 문제와 일치하는 듯 보여, 가상환경을 구성하는 두 대의 서버 중 한 대에만 일단 개선된 모듈을 설치했다. (이미 업데이트가 나온 지 9개월 쯤 된 모양이다. 맨 아래에 링크를 달았다.)

업데이트 설치

다음과 같은 절차에 따라 업데이트를 설치했다.

VM 종료 및 Host 재시작

업데이트를 위해서는 ssh 접속이 필요한데, Host 내부적으로 메모리 할당이 불가능한 상황이다 보니 ssh 접속이 불가능했다. 뿐만 아니라, 가상머신을 새로 띄우는 것(vMotion도 결국, 받아주는 쪽 입장에서는 새로 띄우는 것이니)이 불가능한 상황이어서, 모든 VM을 끄고 작업을 하였다.

실 서비스 운영 상태의 가상환경이었다면 어쩔 뻔 했나?

모듈 재설치

먼저, HP Site에서 내려받은 개선 패키지를 Host에 scp로 업로드한 후,
다음과 같은 명령으로 설치 상태와 버전을 확인한 후, 업데이트 설치를 하였다.

# esxcli software vib list |grep hp-
hp-ams                         550.10.0.0-18.1198610                  Hewlett-Packard  PartnerSupported  2014-08-02
<...>
hp-esxi-fc-enablement          550.2.1.8-1198610                      Hewlett-Packard  PartnerSupported  2014-08-02
hp-smx-provider                550.03.06.00.23-1198610                Hewlett-Packard  VMwareAccepted    2014-08-02
<...>

이렇게 설치된 버전(문제의 버전이 바로 저 10.0.0)을 확인하고,

# esxcli software vib update -v file:///x/hp-ams-550.10.1.0-32.1198610.vib
Installation Result
   Message: The update completed successfully, but the system needs to be rebooted for the changes to be effective.
   Reboot Required: true
   VIBs Installed: Hewlett-Packard_bootbank_hp-ams_550.10.1.0-32.1198610
   VIBs Removed: Hewlett-Packard_bootbank_hp-ams_550.10.0.0-18.1198610
   VIBs Skipped:

재기동이 필요한 모듈의 경우, 위와 같이 "Reboot Required: true"와 같은 출력이 있다. 아마도, 해당 서비스만 재시작하면 될 듯 하지만…

그냥 재시작.

문제점

이 사건에는 다음과 같은 문제점들이 있다.

나의 문제

왜, 항상 내가 사용하는 제품의 문제와 변화에 대하여 귀를 기울이고 있지 않는 것인가?

제품 릴리즈

돈을 받고 제품을 제공하는 입장에서는 해당 제품이 가질 수 있는 잠재적 문제를 포함하여 충분한 양의 시험을 거친 후 제품을 제공해야 한다. 바꿔 말하면, 릴리즈가 잦은 제품은 프로세스에 문제가 있는 것이다. 지가 무슨 오픈소스야?

최소한, 치명적일 수 있고 흔히 발생하는 유형의 문제점에 대해서는 점검 항목을 정의하여 Q/A 시험이 아닌 Code Level에서 사전 점검을 하여야 한다. Software 개발이 그런 것이다. 보통, Memory Leak의 경우, 충분한 Code Review나 Profiling을 통하여 거의 100% 사전에 잡는 것이 가능할 터인데, 이건 성의의 문제다.

알려진 문제의 보고

왜 M/A 계약을 하는 것일까? 단지 사후 대응? 그것이 그렇게(그 돈 만큼) 의미 있는 일일까? 최소한 M/A라면 최초 고객에게서 발생한 문제점들에 대해서 아직 거기까지 가지 않은 다른 고객들에게 예방책을 알려야 하는 것 아닌가?

그렇게 되면 제품 이미지에 타격이 가는 것인가? 하도 문제가 많아서?

대책

뭔가, 유사 상황이 발생했을 때, 그것을 (사전) 감지하기 위한 조치가 필요하다. 그래서,

업데이트 거부

이 가상환경을 구성하는 두 대의 Host 중, 한 대는 VM 서비스 수량을 거의 빈 상태로 유지하되, 업데이트를 하지 않았다. 대신, 나중에 이와 유사한 메모리 문제의 징후를 찾을 만한 지점/조건을 찾기 위한 임시/수동 모니터링을 걸어보려고 한다.

주기 시험

그건 그렇고, 일단 사건이 발생한 것이라도 알아야 하겠다. 처음에는 Host 내부나 그 쪽에서 fork()이 발생할 만한 동작을 주기적으로 일으켜 사건을 감지하는 방안을 생각해봤는데, 그렇게 되면 사건 발생 이후에 fork()이 되지 않으니… 통보도 거의 불가능하지 않을까?

그래서 일단, 다음과 같이 vCenter에서 주기 작업을 걸어봤다. 실질적으로 VM이 기동할 수 없는 상황이 되면, 그것이 HA 동작 실패 등의 장애로 이어지기 전에, 최단 시간 내에 조치가 가능할 것이라는 가정 하에…

  • 내용은 없는 바보 VM 생성
  • 그 VM을 켜고 끄는 작업 생성
  • 결과 확인
vmware-hp-memory--04.png

위와 같은 내용으로 작업을 생성하여, 최종적으로…

vmware-hp-memory--05.png

이렇게 각 Host에 대하여 켜고 끄는 작업을 설정. 그리고,

vmware-hp-memory--06.png

이렇게 정상적인 상황과 비정상적인 상황에 대한 로그를 확인할 수 있다. (물론 메일 Alert도 오고…)

참고자료

공식 개선 공고

Bookmark and Share


따로 명시하지 않는 한에서 이 사이트의 모든 콘텐츠는 다음의 라이선스를 따릅니다: Creative Commons Attribution-NonCommercial 3.0 License