ESXi 6.7 호스트 스토리지 "위험" 경고 대응기 — Smart Array P840, 그리고 RAID 0 14개의 함정

ESXi 6.7 호스트 스토리지 "위험" 경고 대응기 — Smart Array P840, 그리고 RAID 0 14개의 함정

- HPE ProLiant DL380 Gen9 + VMware ESXi 6.7 환경에서 발생한 SSD 장애를 진단하고 정리한 기록입니다. 단순한 디스크 교체 건인 줄 알았는데, 확인해 보니 훨씬 더 근본적인 구성 문제가 숨어 있었습니다.

 

환경

항목 내용

서버	HPE ProLiant DL380 Gen9
BIOS	HP P89
하이퍼바이저	VMware ESXi 6.7
RAID 컨트롤러	HPE Smart Array P840 (Slot 3, FW 7.00)
캐시	4GB (BBWC 3.2GB), Read 10% / Write 90%
드라이버	nhpsa 67.0072.0.149
디스크	480GB SATA SSD ×6, 1.2TB SAS HDD ×8 (총 14본)

 

1. 증상 — vCenter 하드웨어 상태에 경고 발생

vCenter의 모니터 → 하드웨어 상태 화면에서 호스트가 경고 상태로 표시되기 시작했습니다.

1개의 경고 및 0개의 주의 (71개의 센서)

ID        센서                            상태    읽기   SEL 항목   범주
0.4.6.82  Disk or Disk Bay 6 C4 P1I Bay 3  ⚠ 경고   67      4       Storage

행을 펼치니 SEL(System Event Log) 항목이 4건 쌓여 있었습니다.

Assert + Drive Slot Drive Fault        08-18 07:56:13
Assert + Drive Slot In Failed Array    08-18 07:56:13
Assert + Drive Slot In Failed Array    08-18 08:54:48
Assert + Drive Slot In Failed Array    08-18 13:29:15

센서 이름 읽는 법

HPE의 센서 명명 규칙을 알면 위치를 바로 특정할 수 있습니다.

• P1I → Port 1I (컨트롤러 내부 포트 1I)
• Bay 3 → 해당 케이지의 3번 물리 슬롯

그리고 두 이벤트의 의미는 이렇게 갈립니다.

• Drive Fault → 해당 물리 디스크 자체의 하드웨어 고장 판정
• In Failed Array → 그 디스크가 속한 논리 드라이브(어레이)가 정상 범위를 벗어남

두 개가 같은 슬롯에서 동시에 떴다는 건, 센서 오탐이 아니라 실제 디스크 장애일 가능성이 매우 높다는 뜻입니다. 게다가 발생 시각이 8월 18일 오전이고 확인 시점이 8월 19일이니, 하루 넘게 방치된 상태였습니다.

 

2. ssacli로 실제 어레이 상태 확인

vCenter의 하드웨어 상태 화면은 IPMI 센서를 통해 보는 간접 정보라, RAID 레벨이나 논리 드라이브의 실제 상태까지는 알려주지 않습니다. 컨트롤러에 직접 물어봐야 합니다.

ESXi 6.7에는 HPE 커스텀 이미지 기준으로 ssacli가 포함되어 있습니다.

/opt/smartstorageadmin/ssacli/bin/ssacli ctrl all show config detail

구버전 환경이라면 /opt/hp/hpssacli/bin/hpssacli 경로일 수 있습니다.

범인 확인

출력 중 문제의 부분입니다.

Array: K
   Interface Type: SATA Drive
   Status: Failed Physical Drive
   Warning: One of the drives on this array have failed or has been removed.

   Logical Drive: 11
      Size: 447.10 GB
      Fault Tolerance: 0
      Status: Failed

   physicaldrive 1I:2:3
      Port: 1I   Box: 2   Bay: 3
      Status: Failed
      Last Failure Reason: No failure
      Size: 0 GB
      Interface Type: SATA Drive
      Logical/Physical Block Size: 0/0

여기서 눈여겨볼 지점이 세 개 있습니다.

① Size: 0 GB / Block Size: 0/0 정상 디스크라면 용량과 블록 크기가 나와야 합니다. 0으로 나온다는 건 컨트롤러가 디스크의 아이덴티티 정보조차 못 읽고 있다는 뜻입니다.

② Interface Type: SATA Drive 같은 박스의 다른 SSD들은 모두 Solid State SATA로 인식됩니다. 이 디스크만 일반 SATA Drive로 떨어졌다는 건, SSD로 식별되기 전 단계에서 링크가 끊겼다는 신호입니다.

③ Last Failure Reason: No failure 역설적인 문구지만, "실패 사유를 기록할 만큼의 통신도 못 했다"는 뜻으로 읽는 게 맞습니다. 순수 디스크 고장 외에 백플레인/커넥터 접촉 불량 가능성도 열어둬야 하는 대목입니다.

 

3. 진짜 문제 — 전 구성이 RAID 0이었다

여기서 이번 건의 성격이 완전히 달라졌습니다.

Fault Tolerance: 0

논리 드라이브 14개를 전부 훑어보니, 예외 없이 전부 Fault Tolerance: 0. 즉 물리 디스크 1개 = RAID 0 논리 드라이브 1개 구조로, 총 14개의 독립 RAID 0이 구성되어 있었습니다.

컨트롤러 헤더에는 이렇게 적혀 있습니다.

RAID 6 Status: Enabled

RAID 6 기능은 활성화만 되어 있고 실제로 쓰이지는 않고 있었습니다. 라이선스 문제가 아니라 구성 선택의 문제였던 셈입니다.

이게 왜 심각한가

RAID 0에는 패리티도 미러도 없습니다. 결과적으로:

• ❌ 리빌드 불가 — 새 디스크를 꽂아도 복구되지 않습니다
• ❌ 컨트롤러 레벨 데이터 복구 불가 — Logical Drive 11의 데이터는 그대로 소실
• ⚠️ 나머지 13개도 동일 구조 — 어느 것 하나가 죽어도 그 데이터는 그대로 손실

"디스크 하나 죽었으니 갈아 끼우면 되겠지"에서 "데이터스토어 하나가 통째로 날아갔다"로 상황 인식이 바뀌는 순간이었습니다.

 

4. 물리 디스크 개수 대조

혼란을 피하기 위해 실제 장착 개수를 대조해 봤습니다.

./ssacli ctrl slot=3 pd all show status

physicaldrive 2I:3:1 (port 2I:box 3:bay 1, 1.2 TB): OK
physicaldrive 2I:3:2 (port 2I:box 3:bay 2, 1.2 TB): OK
physicaldrive 2I:3:3 (port 2I:box 3:bay 3, 1.2 TB): OK
physicaldrive 2I:3:4 (port 2I:box 3:bay 4, 1.2 TB): OK
physicaldrive 2I:5:5 (port 2I:box 5:bay 5, 1.2 TB): OK
physicaldrive 2I:5:6 (port 2I:box 5:bay 6, 1.2 TB): OK
physicaldrive 2I:5:7 (port 2I:box 5:bay 7, 1.2 TB): OK
physicaldrive 2I:5:8 (port 2I:box 5:bay 8, 1.2 TB): OK
physicaldrive 1I:2:1 (port 1I:box 2:bay 1, 480 GB): OK
physicaldrive 1I:2:5 (port 1I:box 2:bay 5, 480 GB): OK
physicaldrive 1I:2:6 (port 1I:box 2:bay 6, 480 GB): OK
physicaldrive 1I:2:7 (port 1I:box 2:bay 7, 480 GB): OK
physicaldrive 1I:2:8 (port 1I:box 2:bay 8, 480 GB): OK

13개. 그런데 원래 구성은 14개입니다.

구분 정상 시 장애 후

480GB SATA SSD (447.10 GB)	6	5
1.2TB SAS HDD (1.09 TB)	8	8
합계	14	13
총 용량	약 11.35 TB	약 10.9 TB

여기서 얻은 교훈 하나

pd all show status 목록에는 장애 디스크가 아예 나오지 않습니다.

컨트롤러가 통신을 못 하는 디스크는 물리 인벤토리에서 통째로 빠집니다. 그래서 이 명령만 보면 "13개 다 정상인데 왜 경고가 뜨지?"라고 착각하기 쉽습니다.

장애 디스크는 show config detail의 어레이 소속 정보 안에서만 확인됩니다. 개수 대조를 할 때는 물리 디스크 목록이 아니라 논리 드라이브 개수를 기준으로 세는 게 정확합니다. 이 환경에서는 447.10 GB LD가 6개(9·10·11·12·13·14) 존재했으므로, SSD가 원래 6본이었음이 확정됩니다.

 

5. 조치

5-1. (먼저 시도했어야 할) 재장착

Last Failure Reason: No failure + Size: 0 GB 조합은 접촉 불량 가능성을 배제할 수 없습니다. 따라서 어레이를 지우기 전에 디스크를 뽑았다 다시 꽂아보는 게 정석입니다.

./ssacli ctrl slot=3 pd 1I:2:3 show detail          # 재인식 여부 확인
./ssacli ctrl slot=3 ld 11 modify reenable forced   # 논리 드라이브 재활성화

RAID 0이라도 멤버 디스크가 살아 돌아오면 reenable로 논리 드라이브를 되살릴 수 있는 경우가 있습니다. 이 시도는 어레이를 삭제하는 순간 영원히 불가능해집니다.

5-2. 어레이 삭제

재인식이 안 되면 실패한 어레이를 정리합니다.

./ssacli ctrl slot=3 array K delete forced

Warning: Deleting an array can cause other array letters to become renamed.
         E.g. Deleting array A from arrays A,B,C will result in two remaining
         arrays A,B ... not B,C

5-3. 어레이 문자 재배치 — 겁먹지 않아도 되는 이유

경고 문구대로 뒤쪽 어레이 문자가 한 칸씩 당겨집니다. 기존 L·M·N → K·L·M이 되고, 논리 드라이브 번호도 12·13·14 → 11·12·13으로 재번호될 수 있습니다.

처음 보면 "다른 데이터스토어까지 꼬이는 것 아닌가" 싶지만, ESXi에는 영향이 없습니다.

이유는 ESXi가 LD 번호가 아니라 Unique Identifier(NAA ID) 로 장치를 식별하기 때문입니다. 이 값은 논리 드라이브 자체에 기록되어 있어서 어레이 문자가 바뀌어도 변하지 않습니다.

./ssacli ctrl slot=3 ld all show detail | grep -E "Logical Drive:|Unique Identifier|Status"

삭제 전 기록해 둔 NAA ID와 대조해서 그대로면 정상입니다.

1I:2:1 → 600508b1001c****d83f56e36c194a5e
1I:2:5 → 600508b1001c****ed509519435d02e2
1I:2:6 → 600508b1001c****5168fee31c2bc366
1I:2:7 → 600508b1001c****df66a6e19bc567f5
1I:2:8 → 600508b1001c****b1be694a07b6f658

💡 어레이를 건드리기 전에는 반드시 ld all show detail 전체 출력을 저장해 두세요. 사후에 매핑을 대조할 유일한 근거입니다.

5-4. ESXi 쪽 잔여 장치 정리

죽은 장치가 PDL(Permanent Device Loss) 상태로 남아 있을 수 있습니다.

esxcli storage core device detached list
esxcli storage core device detached remove -d naa.600508b1001c****55f143a3108f6d1c
esxcli storage core adapter rescan --all

# 장치 개수 검증 — 13이 나와야 정상
esxcli storage core device list | grep -i "Display Name" | wc -l

vCenter에서 회색으로 남은 데이터스토어는 Unmount → Remove로 정리합니다.

5-5. 경보 해제

하드웨어를 고쳐도 vCenter 경고가 안 사라지는 경우가 많습니다. CIM 공급자 캐시에 남아 있기 때문입니다.

/etc/init.d/sfcbd-watchdog restart

이후 vCenter 하드웨어 상태에서 [새로 고침] → [센서 재설정]. iLO의 IML(Integrated Management Log) 도 별도로 클리어해야 SEL 항목이 완전히 사라집니다.

5-6. 신규 디스크 투입

동일 규격 SSD를 Bay 3에 장착한 뒤:

./ssacli ctrl slot=3 pd all show status                   # 1I:2:3 인식 확인
./ssacli ctrl slot=3 create type=ld drives=1I:2:3 raid=0

새 어레이는 맨 뒤 문자로 붙습니다. 이후 ESXi 재검색 → VMFS 데이터스토어 생성 → 백업 복구 순서입니다.

 

6. 덤으로 발견한 것들

장애 하나 파고들다 보면 늘 다른 게 같이 나옵니다.

⚠️ 컨트롤러 온도 87°C

Controller Temperature (C): 87
Cache Module Temperature (C): 57

vCenter 센서 목록에 Add-in Card 3 23-PCI 3 = 84도로 "정상" 표시되던 그 항목이 바로 이 P840입니다. 상태값이 정상이라고 안심할 수치는 아닙니다. 슬롯 주변 공기 흐름, 팬 상태, iLO 팬 정책(필요 시 Increased Cooling으로 상향)을 점검할 필요가 있습니다. 고온은 컨트롤러와 디스크 수명을 확실하게 갉아먹습니다.

⚠️ SSD 마모 — 다음 장애 예고

슬롯 가동시간 잔여 수명 예상 잔여일

1I:2:8	21,578h	52%	974일
1I:2:5	21,578h	61%	1,406일
1I:2:7	21,578h	84%	4,720일
1I:2:1	1,483h	89%	499일
1I:2:6	1,483h	89%	499일

21,578시간(약 2.5년) 가동된 구형 배치와 1,483시간짜리 신규 배치가 섞여 있습니다. 이번에 죽은 Bay 3도 십중팔구 구형 배치였을 겁니다.

같은 시기에 투입된 디스크는 같은 시기에 죽습니다. 잔여 수명 50%대 디스크가 이미 두 개 있으니, 예비 디스크 확보는 선택이 아니라 필수입니다.

⚠️ 드라이브 인증 실패 — LED가 안 켜지는 디스크

physicaldrive 2I:5:8
   Drive Authentication Status: Not Authenticated.
                                Smart Array will not control drive LEDs.

정품 캐리어가 아니거나 인증 정보를 읽지 못하는 상태입니다. 문제는 이 디스크는 장애가 나도 전면 LED가 점등되지 않는다는 점입니다. 나중에 교체할 일이 생기면 육안 식별이 불가능하니, 물리 위치를 미리 문서화해 두는 편이 좋습니다.

 

7. 정리하며 — 이번 건에서 남는 것

① vCenter 하드웨어 상태는 시작점일 뿐입니다. IPMI 센서로 보는 간접 정보라 RAID 레벨도, 논리 드라이브 상태도 알려주지 않습니다. 스토리지 경고를 봤으면 반드시 ssacli로 컨트롤러에 직접 물어봐야 합니다.

② 파괴적 명령 전에 비파괴적 시도를 먼저. array delete는 되돌릴 수 없습니다. 재장착 → pd show detail → ld modify reenable 순서를 먼저 밟고, 그래도 안 되면 삭제하는 게 맞습니다. 이번엔 그 순서를 지키지 못했습니다.

③ 어레이를 건드리기 전에 show config detail을 통째로 저장하세요. NAA ID, 시리얼, 슬롯 매핑이 전부 들어 있습니다. 사후 검증의 유일한 근거이고, 저장하는 데 3초 걸립니다.

④ 가장 중요한 것 — "왜 RAID 0인가"를 물어야 합니다. 디스크 14개가 전부 무보호 상태로 돌아가고 있었고, 아무도 그걸 문제로 인식하지 않고 있었습니다. 성능을 위한 의도적 선택일 수도 있지만, 그렇다면 백업 정책이 그 위험을 온전히 감당하고 있는지가 반드시 함께 검증되어야 합니다.

RAID 6이 컨트롤러에서 이미 활성화되어 있으니, 최소한 SAS HDD 8본이라도 RAID 6 또는 RAID 10으로 재구성하는 것을 다음 정기 점검 과제로 잡아두려 합니다.

⑤ 하루를 놓쳤습니다. 8월 18일 오전 7시 56분에 발생한 장애를 8월 19일 오후에야 인지했습니다. 하드웨어 상태 경보를 vCenter Alarm이나 외부 모니터링으로 연동해 두지 않으면, 사람이 화면을 열어볼 때까지 아무 일도 일어나지 않습니다.

 

이번 건에서 사용한 명령어 모음

# ssacli 경로 (ESXi는 PATH에 없어 전체 경로 또는 ./ 사용)
cd /opt/smartstorageadmin/ssacli/bin

./ssacli ctrl all show config detail          # 전체 구성 — 가장 먼저 저장할 것
./ssacli ctrl slot=3 pd all show status       # 물리 디스크 상태 (장애 디스크는 안 나옴)
./ssacli ctrl slot=3 ld all show detail       # 논리 드라이브 + NAA ID
./ssacli ctrl slot=3 pd 1I:2:3 show detail    # 특정 디스크 상세

./ssacli ctrl slot=3 ld 11 modify reenable forced      # 복구 시도 (삭제 전에!)
./ssacli ctrl slot=3 array K delete forced             # 실패 어레이 삭제
./ssacli ctrl slot=3 create type=ld drives=1I:2:3 raid=0   # 신규 LD 생성

# ESXi 측
esxcli storage core device list
esxcli storage core device detached list
esxcli storage core device detached remove -d naa.xxxxxxxx
esxcli storage core adapter rescan --all
/etc/init.d/sfcbd-watchdog restart            # CIM 캐시 갱신 (경보 해제)

 

 

작성 기준: ESXi 6.7 / Smart Array P840 FW 7.00 / ssacli 기준. 환경에 따라 명령 경로와 옵션이 다를 수 있습니다. ⚠️ RAID 관련 명령은 데이터 손실을 유발할 수 있습니다. 반드시 현재 구성을 백업·기록한 뒤 진행하세요.