물리 서버 한 대를 하드웨어와 운영체제와 컨테이너까지 전체 점검했다. 저장 장치 상태를 보려고 흔히 쓰는 ssacli ctrl slot=0 pd all show 를 쳤더니 실패했다.
Table of contents
Open Table of contents
원인 — 기본값을 가정한 슬롯
ssacli ctrl all show 로 컨트롤러 목록부터 조회하니 슬롯 표기가 0 이 아니라 Embedded 가 붙은 형태였다. 그 표기를 그대로 넣으니 조회가 됐다.
임베디드 컨트롤러는 확장 슬롯이 아니라 보드에 붙어 있어서 표기가 다르다. 기본값으로 가정하지 말고 목록부터 봐야 했다.
제약 — 없는 진단 필드
디스크 상태는 나왔는데 정보가 빈약했다. Status 와 Temperature 뿐이고 Reallocated_Sector_Ct 나 Power_On_Hours 같은 것이 없었다.
이 컨트롤러가 임베디드 소프트 RAID 라 smartctl -a 가 보여 주는 상세 진단 필드를 안 넘겨주기 때문이었다. smartctl(8) 매뉴얼대로 -a 는 건강 상태와 속성과 오류 로그를 전부 찍지만 그것은 디스크가 컨트롤러 뒤에서 보일 때 얘기다. 디스크 노후 판정을 그 두 값으로 하려던 계획이 성립하지 않았다.
판단 기준 — 남은 것으로 세운 기준
두 가지 방법이 있었는데 컨트롤러를 우회해 smartctl -d 로 디스크에 직접 붙어 보는 것과 남은 것으로 기준을 세우는 것이다. 뒤쪽을 골랐다. 이유는 소프트 RAID 아래에서는 우회 경로도 같은 값만 돌려주는 것을 시험으로 확인해서다. 대신 노후 판정의 정밀도가 떨어지는 것을 감수했다. Predictive Failure 경고의 유무와 Temperature 둘로만 판정한다.
한계를 인정하고 그 안에서 기준을 세운 것이다. 판정 기준을 데이터에 맞추지 않으면 매번 없는 값을 찾게 된다.
지표가 된 팬 회전율
점검하면서 ipmitool sensor 로 팬 상태도 봤는데 회전율이 낮았고 그것이 조용하다는 뜻이었다. 이 서버 재설치의 목표가 바로 그것이었다.
드라이브 온도를 읽을 수 있으면 팬이 필요한 만큼만 돈다. 못 읽으면 펌웨어가 안전하게 최대로 돌린다. 그래서 팬 회전율이 목표 상태가 유지되고 있는지의 지표가 되고 팬이 갑자기 최대로 돌면 하드웨어 고장보다 먼저 온도 미판독을 의심하는 순서를 정했다.
주의 — 장비별 사실의 기록
컨테이너 상태를 보려다 docker ps --format 의 특정 형식이 지원되지 않는 것도 만났다. 이 호스트의 docker --version 이 낮아서였고 같은 명령이 호스트마다 다르게 동작한다는 뜻이다.
이 호스트의 서비스 중에 클러스터 다른 노드의 서비스와 이름이 같은 것도 있었다. 별개 인스턴스이므로 상태를 혼동하면 엉뚱한 결론이 난다. 점검 하나에서 나온 다섯은 전부 이 장비는 이렇다는 사실이지 일반 지식이 아니라서 장비 이름과 함께 MACHINES.md 에 남겼다.
정리
- 컨트롤러 슬롯 같은 표기는
ctrl all show목록부터 확인한다 - 기본값을 가정하고 명령을 치지 않는다
- 임베디드 컨트롤러는 상세 진단 필드를 안 노출할 수 있다
- 없는 데이터는 만들 수 없으니 있는 것으로 기준을 세운다
- 팬 회전율이 온도 판독 상태의 지표가 된다
- 팬이 급등하면 고장보다 먼저 온도 미판독을 의심한다
- 같은 명령이 호스트 버전에 따라 다르게 동작한다
- 장비별 사실은 그 장비 이름과 함께 기록한다