고객사에서 다급하게 연락이 왔어요. Nutanix 클러스터에서 디스크에 불이 들어왔다며 당장 교체해달라고 RMA 신청을 하였습니다. Prism 웹 콘솔 화면을 띄워보니 정말로 다이어그램 뷰에 디스크 하나가 시뻘겋게 에러를 뿜어내고 있었어요. 보통 이런 상황이면 바로 하드웨어 벤더에 불량 판정서를 보내고 새 파트를 받아서 끼워 넣는 게 국룰이죠. 저도 처음엔 당연히 미디어 자체의 물리적 고장이라고 생각했어요. 찬찬히 dmesg와 하데스(Hades) 로그를 뜯어보니 뭔가 이상한 낌새가 보이기 시작했습니다. 멀쩡한 디스크를 고장으로 오판해서 교체할 뻔했던 아찔한 경험, 오늘 그 전말을 낱낱이 공유해 드릴게요.
에러 현상: Stargate의 오해와 디스크 오프라인
가장 먼저 확인해야 할 건 CVM(Controller VM)이 이 디스크를 물리적으로 아예 못 찾고 있는지, 아니면 찾긴 하는데 파티션 구조가 꼬인 건지 확실하게 선을 긋는 일이에요. 뉴타닉스 환경에서 스토리지 I/O를 담당하는 Stargate 서비스는 굉장히 예민해요. 디스크가 1시간 내에 3번만 통신 지연이나 오프라인 상태로 떨어지면 가차 없이 클러스터에서 쫓아내고 심각한 에러를 띄워버리죠. 디스크 자체가 죽은 게 아니라 단순히 찰나의 연결 불량이었어도 프리즘에는 똑같이 빨간불이 들어오거든요. 일단 SSH로 문제가 발생한 CVM에 붙어서 현재 운영체제 레벨에서 디스크 인식이 어떻게 되고 있는지 세 가지 명령어를 연달아 날려봤어요.
nutanix@CVM$ list_disks
nutanix@CVM$ lsscsi
nutanix@CVM$ sudo smartctl -H /dev/sdX
명령어 창에 결과가 후루룩 떨어지는데, 여기서 주목해야 할 건
lsscsi 명령어의 출력값이에요. 이 명령어는 단순히 디스크 목록을
보여주는 걸 넘어서 [2:0:4:0] 같은 형태로 SCSI 버스와 타겟 경로를
정확히 찍어주거든요. 이 경로가 정상적으로 보인다는 건 호스트 서버의 컨트롤러가
디스크의 존재 자체는 명확하게 인지하고 있다는 뜻이에요. 만약 경로 자체가 안
보인다면 케이블이나 백플레인 쪽을 의심해야겠죠.
존재를 확인했으니 이제 건강 상태를 체크할 차례예요. 연달아 입력한
smartctl 명령어 뒤에 붙는 -H 옵션은 디스크 내부의
하드웨어 헬스 체크 상태가 Passed인지 Failed인지 아주 직관적으로 알려주는
강력한 파라미터예요. 여기서 Failed가 뜨면 마음 편하게 디스크 물리 배드 문제로
단정 짓고 RMA를 부르면 돼요. 놀랍게도 제 명령어 실행 결과는 허무할 정도로
깔끔한 'Passed'가 나왔어요. 디스크 미디어 자체는 아무 잘못이 없었던 거죠. 이쯤
되면 시야를 넓혀서 디스크와 메인보드를 이어주는 길목, 즉 SAS 어댑터(HBA) 쪽의
장난질을 의심해봐야 해요.
원인 분석: 공식 문서에는 없는 실무 HBA 점검 꿀팁
디스크 고장이 아니라면 SAS 컨트롤러에서 디스크를 제대로 인식하지 못해 무수한 I/O 에러가 쏟아졌을 확률이 아주 높아요. 이럴 때 현장에 나가는 엔지니어들이 무조건 쳐보는 비장의 무기가 하나 있어요. 바로 LSI 컨트롤러의 물리적 링크 상태를 점검하는 전용 명령어예요. 공식 매뉴얼에서는 종종 dmesg를 먼저 보라고 가이드하지만 바쁜 현장 실무에서는 아래 명령어가 훨씬 직접적이고 원인을 찾기 쉽거든요.
nutanix@CVM$ sudo /home/nutanix/cluster/lib/lsi-sas/lsiutil -a 12,0,0 20
이 엄청나게 긴 명령어는 LSI SAS HBA 어댑터의 상태를 밑바닥 물리 계층부터
점검하는 전용 유틸리티를 강제로 실행하는 구문이에요. 뒤에 붙는 파라미터
12,0,0은 서버에 꽂힌 첫 번째 HBA 컨트롤러의 물리적 포트(PHY) 상태
정보를 화면에 띄우라는 구체적인 지시어 역할을 해요. 그리고 맨 끝에 붙은
20은 불필요한 대화형 메뉴 진입 과정을 묻지도 따지지도 않고
건너뛰어 곧바로 결과를 출력하겠다는 스킵 옵션이죠.
이 명령어를 엔터 치는 순간 각 포트별로 통신 에러 카운트가 몇 개나 쌓였는지, 물리적 링크가 정상적으로 Up 상태를 유지하고 있는지 리스트업이 쫙 돼요. 제 화면을 확인해 보니 유독 문제의 디스크가 꽂힌 특정 슬롯에서만 엄청난 숫자의 PHY 에러 카운트가 미친 듯이 올라가고 있었어요. 디스크는 계속해서 데이터를 보내고 싶은데 컨트롤러로 넘어가는 버스 길목이 끊겼다 붙었다를 반복하며 심각한 통신 불량이 났던 거예요.
 |
| SAS Controller Error 확인 |
위 화면처럼 특정 어댑터의 PHY 넘버에서만 Link Down이 발생하거나 에러 수치가 치솟는다면 미디어 불량이 아닌 통신 불량으로 확정 지을 수 있어요.
장애 원인 판별 기준표
| 장애 증상 | 점검 명령어 | 출력 상태 | 원인 판별 및 대처 방안 |
|---|---|---|---|
| 디스크 아예 인식 불가 | list_disks | 해당 슬롯 빈칸 | HBA 컨트롤러 또는 백플레인 불량 의심 |
| S.M.A.R.T 점검 실패 | smartctl -H /dev/sdX | Failed 출력 | 디스크 물리적 손상 (즉시 RMA 대상) |
| 간헐적 링크 통신 에러 | lsiutil (옵션 12) | Link Down / 카운트 증가 | 섀시 트레이 접촉 불량 (재장착 필요) |
현장 노하우: 디스크 오판 교체의 숨겨진 리스크와 안전한 해결
단순 통신 불량을 디스크 물리 고장으로 오판해서 무작정 새 디스크로 교체해 버리면 엄청난 후폭풍을 맞을 수 있어요. Nutanix 같은 HCI 환경에서 디스크가 교체되면 클러스터는 즉시 데이터 정합성을 맞추기 위해 대규모 백그라운드 리빌딩(Rebuilding) 작업을 시작하거든요. 이 과정에서 불필요한 네트워크 I/O가 폭주하고 정상적으로 서비스 중인 다른 가상머신들의 성능까지 뚝 떨어뜨리는 민폐를 끼치게 돼요. 멀쩡한 부품 하나 잘못 갈았다가 클러스터 전체에 극심한 스트레스를 주는 꼴이죠. 엔지니어의 정확한 트러블슈팅이 이래서 중요해요.
이제 명확한 원인을 알았으니 노드 셧다운 같은 거창한 작업 없이 빠르게 손을 쓸 차례죠. 이런 식의 간헐적 통신 불량은 십중팔구 물리적인 접촉 불량에서 시작돼요. 슬롯 내부에 먼지가 끼었거나 쿨링팬 진동 때문에 핀이 미세하게 어긋났을 확률이 높아요. 하드웨어 담당 엔지니어 분과 상의해서 문제의 디스크 깡통(트레이)을 완전히 빼냈어요. 에어건으로 섀시 슬롯 안쪽 먼지를 가볍게 날려주고 커넥터 핀 상태를 육안으로 살핀 다음, 다시 딸깍 소리가 날 때까지 꽉 밀어 넣는 재장착(Reseat) 작업을 현장에서 바로 진행했어요.
nutanix@CVM$ sudo /home/nutanix/cluster/lib/lsi-sas/lsiutil -a 13,0,0 20
nutanix@CVM$ sleep 10
nutanix@CVM$ sudo /home/nutanix/cluster/lib/lsi-sas/lsiutil -a 12,0,0 20
디스크를 힘주어 재장착한 뒤에 가장 먼저 챙겨야 할 일은 이전에 누적되어 있던
찝찝한 에러 카운트를 싹 날려버리고 처음부터 다시 관찰하는 작업이에요. 방금
쳤던 명령어 중 파라미터를 13,0,0으로 슬쩍 바꾸면 기존 물리
계층(PHY)의 에러 카운트를 완전히 숫자 0으로 초기화해줘요. 이전 불량 상태의
찌꺼기 기록을 지우는 셈이죠.
그런 다음 리눅스 sleep 10 명령어로 10초 정도 컨트롤러가 디스크를
다시 꽉 물고 정상적으로 링크를 맺어 통신할 수 있는 시간적 여유를 줍니다. 10초
뒤에 다시 12,0,0 파라미터를 줘서 현재 상태를 꼼꼼하게
모니터링해보는 거죠. 디스크를 다시 끼우고 카운터를 리셋한 뒤 3번 연속 상태를
찍어봐도 더 이상 야속한 에러 카운트가 올라가지 않았어요. 콘솔 화면에 'Link Up,
No Errors' 상태를 아주 짱짱하게 유지하더라고요. 하마터면 애먼 디스크를
교체하느라 며칠을 날리고 운영 서버 성능까지 갉아먹을 뻔했는데, 명령어 몇 줄과
간단한 물리적 조치로 깔끔하게 장애를 해결했습니다.
0 댓글