이전의 Snapshot 에 이은 두번째 내용입니다. 다른것도 있지만, 한껀식 옮겨적겠습니다.
vCenter Service 가 갑자기 죽는다던지 하는 경우가 많은데요, 상당수의 경우가 Disk 공간으로 인한 이슈가 꽤 있습니다.
제목에는 VCSA 만 적혀있지만 실제로는 윈도우 vCenter 에서도 많이 발생하는 편입니다.
Disk Space Issue
보통 Disk Space 로 인한 경우는 아래 두가지 경우가 많습니다.
- /storage/log 디렉토리가 풀 나는 경우 (KB 2143565)
- Root Partition 이 풀 나는 경우 – Audit.log 파일 로테이션 이슈 (KB 2149278)
그리고 SEAT 공간 이슈가 있죠. SEAT 란 무엇이냐, Statistics, Events, Alarms and Task 를 의미합니다.
이것은 Database 공간의 문제라고 볼 수 있죠. 주로 단시간에 많은 이벤트가 발생하는 경우 발생합니다. (port flapping 등)
이슈 확인하는 방법
최근의 vCenter 에서는 UI 상으로도 확인이 가능합니다.
그리고 vCenter 6.5 에서는 SEAT 데이터에 대해서 “Database Health” 알람이 정의되어 있고,
vCenter 6.7 에서는 “Disk Exhaustion” 에 대한 알람이 정의되어 있습니다. vCenter 설치시에 여러개의 디스크를 생성하는데, 다른 디스크 공간에 대해서도 알람이 정의되어 있습니다.
vCenter 6.7 의 경우는 VAMI 에서도 확인할 수 있습니다. (KB 57829)
SEAT Data
UI 나 VAMI 외에는, VCSA shell 로 접속해서 확인할 수 있습니다. (df -h)
/storage/log 데이터의 경우 확인해보면 vCenter 로그번들로 풀차는 경우가 많습니다. 만약 그렇지 않다면, GSS 로 콜을 하세요!
SEAT 데이터의 경우, vCenter 6.5 이전버전에서는 Retention 날짜가 기본적으로 180 days 였습니다. 그래서 이벤트가 많이 발생하는 경우에 SEAT data 가 많이 증가하게 되어 발생하는 경우가 많습니다. 6.7 에서는 30 days 로 변경되어서, 아마 왠만하면 발생하지 않을 것으로 생각됩니다. 그외에도 Burst Event Filter (vCenter 6.7U1 부터) 가 생겨서 동일하거나 유사한 이벤트가 많이 발생하는 경우 발생하는 메세지수를 줄여줍니다.)
SEAT 공간에 이슈가 있을 경우에는 KB 2110031 을 참조하여서 오래된 데이터의 클린업을 진행해주시면 됩니다.
지난 5일간의 데이터만 남기겠다 라고 하는 경우는 위 KB 에 첨부되어있는 스크립트를 다운받고, 아래와 같이 실행해주시면 됩니다.
/opt/vmware/vpostgres/current/bin/psql -U vCenter-Server-database-user -v TaskMaxAgeInDays=5 -v EventMaxAgeInDays=5 -v StatMaxAgeInDays=5 -d database-name -t -q -f download-path/2110031_Postgres_task_event_stat.sql
공간이슈에 대해서 사이즈를 늘리것도 방법이고, 조치가 간단한 편이지만, 위의 내용을 먼저 한번 확인해보시고 그뒤에 늘리는 것을 권장합니다. 그외에도 180 days 로 설정되어있는 Retention 기간을 줄이는 것도 한가지 방법입니다.
- vCenter 6.5 / 6.7 – KB 2145603
- vCenter 6.0 – KB 2126276
6.7 U1 이전버전에서는 vPostgres DB 접속을 해서 가장 많이 발생하는 이벤트 빈도수를 확인할 수 있습니다.
- vCenter 6.0
SELECT COUNT(EVENT_ID) AS NUMEVENTS, EVENT_TYPE, USERNAME FROM VPX_EVENT GROUP BY EVENT_TYPE, USERNAME ORDER BY NUMEVENTS DESC LIMIT 10;
- vCenter 6.5/6.7
SELECT COUNT(EVENT_ID) AS NUMEVENTS, EVENT_TYPE, USERNAME FROM VPXV_EVENT_ALL GROUP BY EVENT_TYPE, USERNAME ORDER BY NUMEVENTS DESC LIMIT 10;
아래 예제에서는 반복된 로그인 실패로 인해 메세지가 많이 발생하는 경우입니다.
혹시나, PowerCLI 스크립트등이 잘못된 로그인 크리덴셜 정보를 가지고 도는게 있지 않는지 확인해볼필요가 있겠습니다.
여기까지 입니다.