🔴 vSAN에 빨간불이 떴다 — ESXi 디스크 1개 갈아끼운 하루

🔴 vSAN에 빨간불이 떴다 — ESXi 디스크 1개 갈아끼운 하루

한 줄 요약 3노드 하이브리드 vSAN에서 용량 디스크 1개가 사망. 데이터는 멀쩡했고, RAID 0의 함정만 피하면 20분이면 끝나는 작업이었다.

 

평화로운 오후였습니다.

 

습관처럼 vSphere Client를 열었는데, 익숙한 초록색 체크 사이로 빨간 동그라미 하나가 보였습니다.

 

심장이 한 번 쿵 하죠. vSAN에 빨간불이면 "스토리지"에 문제가 있다는 뜻이니까요.

 

화면을 보니 이렇습니다.

 

 

디스크	계층	용량	상태
Local HP Disk (naa...66c58d...)	캐시 (플래시)	447.10 GB	정상 ✅
Local HP Disk (naa...5e3fbc...)	용량 (HDD)	1.09 TB	정상 ✅
Absent vSAN Disk	용량 (HDD)	0.00 B	비활성 또는 오류 ❌

용량이 0.00 B. 이름도 없습니다.

디스크 하나가 조용히 세상을 떠났습니다. 😇

📸 실제 vSphere 화면(구성 → vSAN → 디스크 관리)을 캡처해 두셨다면 여기에 함께 올리면 좋습니다.

 

 

우리 클러스터는 이렇게 생겼습니다

• 3노드 하이브리드 vSAN (SSD 캐시 + HDD 용량)
• 호스트당 디스크 그룹 4개 × (캐시 1 + 용량 2) = 12개
• 전체 36개, 온디스크 포맷 버전 7
• 서버: HPE, 컨트롤러 Smart Array P840ar (Slot 0, Embedded)

여기서 중요한 포인트. 3노드입니다.

FTT=1(장애 허용 1)에서 3노드는 복제본 2개 + 감시(witness) 1개를 세 호스트에 딱 맞춰 나눠 놓습니다. 여유 호스트가 1도 없다는 뜻이죠. 4노드 이상이면 한 대 빠져도 숨 쉴 구석이 있는데, 3노드는 그런 거 없습니다.

그래서 더더욱 — 침착해야 합니다.

 

😰 1단계: 손대기 전에, 숨부터 쉬자

장애 상황에서 제일 위험한 건 디스크 고장이 아니라 당황한 관리자의 손가락입니다.

뭔가를 지우거나 재부팅하기 전에 딱 두 가지만 확인합니다.

# 접근 불가능한 데이터가 있는가?  ← 제일 중요
esxcli vsan debug object list | grep -i inaccessible

# vSAN이 스스로 복구 중인가?
esxcli vsan debug resync list

결과는 이랬습니다.

# inaccessible → 아무것도 안 나옴 ✅

# resync list
Group UUID       Object UUID      Component UUID   To Host   GB Left To Resync  Intent
15d77265-...     bbff7265-...     0bfdb96a-...     kup-com2  85.45              Compliance

해석:

• inaccessible 0건 → 데이터 손실 없음. VM들은 아무것도 모른 채 잘 돌고 있습니다
• resync 85.45 GB 진행 중 → vSAN이 이미 알아서 복구 중

죽은 디스크에 있던 조각을, 같은 호스트의 다른 디스크 그룹으로 다시 만들고 있던 겁니다. 3노드라 다른 호스트로는 못 보내거든요. (복제본 배치 규칙상 그렇습니다)

💡 알아두면 좋은 것 vSAN은 디스크가 사라져도 기본 60분(VSAN.ClomRepairDelay)을 기다렸다가 재구축을 시작합니다. "잠깐 빠진 걸 수도 있잖아?" 하고 기다려주는 거죠. 참 신중한 녀석입니다.

 

여기서 중요한 마음가짐 하나.

재동기화가 끝날 때까지 다른 호스트는 건드리지 않습니다. 재부팅도, 유지 보수 모드도 안 됩니다. 3노드에서 한 대가 더 빠지면 그때는 진짜 큰일 납니다.

 

🔍 2단계: 범인 수배 — vdq -q

이제 어느 디스크가 사라졌는지 특정합니다.

vdq -q

{
   "Name"     : "",
   "VSANUUID" : "52e12612-2d6c-8eaa-db9a-c5c062807f92",
   "State"    : "In-use for VSAN",
   "IsPDL"    : "1",
   "Size(MB)" : "0",
}

IsPDL: 1 — PDL은 Permanent Device Loss, 즉 영구 장치 손실입니다.

이름도 비었고 크기도 0. vSAN은 이 디스크가 있었다는 기억(UUID)만 들고 있는 상태입니다. 아까 GUI에서 본 Absent vSAN Disk의 UUID와 정확히 일치하죠.

 

디스크 개수를 세어보면 용량 HDD가 원래 8개인데 지금 7개. 딱 하나 비었습니다.

 

🕵️ 3단계: 현장 검증 — ssacli

ESXi는 "디스크가 사라졌다"까지만 압니다. 어느 베이에 꽂힌 어떤 녀석인지는 컨트롤러에 물어봐야 합니다.

HPE 서버니까 ssacli를 씁니다.

SSACLI=/opt/smartstorageadmin/ssacli/bin/ssacli
$SSACLI ctrl all show config

Array H (SAS,
   logicaldrive 9 (1.09 TB, RAID 0, Failed)
   physicaldrive 1I:3:1 (port 1I:box 3:bay 1, SAS HDD, 1.2 TB, Failed)

포트 1I / 박스 3 / 베이 1.

physicaldrive까지 Failed입니다. 진짜 하드웨어 고장이라는 뜻이죠. 논리 드라이브만 Failed이고 물리는 OK면 다른 원인을 의심해야 하는데, 이건 깔끔(?)하게 죽었습니다.

 

💡 4단계: 불 켜고 뽑기

서버실 가서 감으로 뽑으면 안 됩니다. 옆 디스크를 뽑는 순간 3노드 클러스터는 작별 인사를 합니다. 👋

LED를 켭니다.

$SSACLI ctrl slot=0 pd 1I:3:1 modify led=on

📸 서버 전면에서 LED가 켜진 베이를 찍은 실물 사진을 여기 넣으면 글이 훨씬 생생해집니다.

불 켜진 베이의 디스크를 뽑고, 새 1.2TB SAS HDD를 꽂습니다.

$SSACLI ctrl slot=0 pd 1I:3:1 modify led=off

끝! ...이면 좋겠지만, 아닙니다.

 

⚠️ 5단계: RAID 0의 배신

새 디스크를 꽂고 재스캔했는데 ESXi에 안 보입니다.

esxcli storage core adapter rescan -a
vdq -q
# ... 아무 변화 없음

왜일까요?

RAID 0에는 패리티가 없습니다. 그래서 컨트롤러가 재구축을 할 수가 없어요. 디스크를 새것으로 갈아 끼워도 논리 드라이브는 Failed 상태로 그대로 남습니다.

물리 디스크는 OK인데 논리 드라이브가 Failed. 이 조합이면 수동으로 논리 드라이브를 삭제하고 다시 만들어야 합니다.

# Failed 논리 드라이브 삭제
$SSACLI ctrl slot=0 ld 9 delete forced

# 새 디스크로 RAID 0 재생성
$SSACLI ctrl slot=0 create type=ld drives=1I:3:1 raid=0

# 확인 (새 LD 번호가 바뀔 수 있음)
$SSACLI ctrl slot=0 show config

🚨 진심으로 중요한 경고

create 명령의 drives= 에는 반드시 해당 디스크 하나만 지정하세요.

drives=all 이나 drives=allunassigned 같은 건 절대 쓰지 마세요.

실제로 다른 서버에서 이걸 잘못 써서, 정상 운영 중이던 vSAN 디스크들이 통째로 RAID 1 배열에 흡수된 사고가 있었습니다. 미러 재구축이 돌면서 live 데이터를 덮어쓰기 시작했죠. 다행히 3%에서 잡았고 다른 노드에 복제본이 있어서 살았지만, 식은땀 제대로 흘렸습니다.

한 글자 차이로 하루가 망합니다.

💡 팁: 배열을 삭제하면 배열 문자(A, B, C...)는 앞당겨지지만 논리 드라이브 번호는 그대로입니다. 그래서 항상 ld <번호>로 지정하는 게 안전합니다.

 

✅ 6단계: 디스크 그룹 복귀

재스캔하면 이제 보입니다.

esxcli storage core adapter rescan -a
vdq -q

{
   "Name"     : "naa.600508b1001c94475134e70623ba5426",
   "State"    : "Eligible for use by VSAN",
   "IsSSD"    : "0",
   "Size(MB)" : "1144609",
}

• Size(MB): 1144609 → 1.09TB, 규격 일치 ✅
• IsSSD: 0 → HDD, 하이브리드 용량 계층에 적합 ✅
• Eligible → 투입 가능 ✅

Eligible for use by VSAN. 이 글자가 이렇게 반가울 줄이야.

⚠️ 새 논리 드라이브는 naa ID가 완전히 달라집니다. 예전 ID 찾지 마세요. 없습니다.

 

이제 기존 디스크 그룹에 편입합니다. 여기가 핵심.

# 죽은 디스크의 흔적(PDL) 먼저 제거
esxcli vsan storage remove -u 52e12612-2d6c-8eaa-db9a-c5c062807f92 -m noAction

# 기존 그룹의 "캐시 디스크"를 -s 로 지정 → 새 그룹이 아니라 기존 그룹에 들어감
esxcli vsan storage add -s naa.600508b1001c66c58dfeef3cc22a6722 \
                        -d naa.600508b1001c94475134e70623ba5426

💡 가장 많이 하는 실수 새 디스크 그룹을 만들어 버리는 것. 그러면 쓸데없는 대규모 재동기화가 돌고 구성이 지저분해집니다.

-s에 기존 캐시 디스크를 지정하면 캐시는 재포맷되지 않고 용량 디스크만 그 그룹에 쏙 들어갑니다. esxcli 도움말에도 명시된 동작이에요.

💡 하이브리드 vs 올플래시 저희는 하이브리드라서 바로 넣으면 됩니다. 올플래시 환경이라면 용량 디스크도 SSD이기 때문에, 넣기 전에 반드시 태깅해야 합니다:

esxcli vsan storage tag add -d <디스크> -t capacityFlash

이거 빼먹으면 vSAN이 캐시용 플래시로 착각합니다.

 

🟢 7단계: 초록불

esxcli vsan storage list | grep -c "^naa"        # 12 나와야 정상
esxcli vsan storage list | grep -c "^Unknown"    # 0 나와야 정상
esxcli vsan debug resync list

디스크 그룹이 3/3 정상, 호스트 vSAN 상태도 정상. 빨간 동그라미가 사라졌습니다. 🎉

📸 복구 완료된 vSphere 디스크 관리 화면을 캡처해서 여기 넣으면 "비포 애프터"가 완성됩니다.

 

마지막으로 모니터 → vSAN → 개체 다시 동기화가 0이 될 때까지 기다립니다. 하이브리드는 HDD에 쓰는 작업이라 느립니다. 몇 시간 걸릴 수도 있어요. 커피 한 잔 하고 오세요. 아니면 퇴근하고 다음 날 확인해도 됩니다.

끝나면 상태 → 재검사 한 번 눌러주면 마무리.

 

📝 오늘의 교훈 5가지

1. 빨간불 ≠ 데이터 손실 먼저 inaccessible부터 확인하세요. 비어 있으면 숨 쉬어도 됩니다. vSAN은 생각보다 튼튼합니다.

2. 재동기화 중에는 아무것도 건드리지 않는다 특히 3노드. 한 대 더 빠지면 복구 불가입니다. 참는 게 일입니다.

3. RAID 0은 디스크만 갈아도 안 된다 논리 드라이브 삭제 → 재생성. 이 두 줄을 모르면 "분명 꽂았는데 왜 안 보이지?" 하며 한 시간 날립니다.

4. drives=all은 절대 금지 한 글자 차이로 운영 데이터가 날아갑니다. 명령 치기 전에 한 번 더 읽으세요.

5. 새 그룹 말고 기존 그룹에 추가 -s에 기존 캐시 디스크를 지정하는 것. 이거 하나가 핵심입니다.

 

🔧 전체 절차 한 장 요약

SSACLI=/opt/smartstorageadmin/ssacli/bin/ssacli

# ── 1. 상태 확인 (손대기 전 필수) ──
esxcli vsan debug object list | grep -i inaccessible
esxcli vsan debug resync list
esxcli vsan cluster get | grep "Member Count"
vdq -q

# ── 2. 고장 디스크 위치 확인 ──
$SSACLI ctrl all show config
$SSACLI ctrl slot=0 pd <port:box:bay> modify led=on

# ── 3. vSAN 에서 제거 ──
esxcli vsan storage remove -u <PDL_UUID> -m noAction

# ── 4. 물리 교체 후 논리 드라이브 재생성 ──
$SSACLI ctrl slot=0 ld <번호> delete forced
$SSACLI ctrl slot=0 create type=ld drives=<port:box:bay> raid=0   # drives=all 금지!

# ── 5. 재스캔 ──
esxcli storage core adapter rescan -a
vdq -q

# (파티션 잔재가 있다면)
partedUtil setptbl /vmfs/devices/disks/<새_naa> gpt

# (올플래시 환경만) capacityFlash 태깅
esxcli vsan storage tag add -d <새_naa> -t capacityFlash

# ── 6. 기존 디스크 그룹에 편입 ──
esxcli vsan storage add -s <기존_캐시_naa> -d <새_naa>

# ── 7. 검증 ──
esxcli vsan storage list | grep -E "^naa|In CMMDS"
esxcli vsan debug resync list

 

디스크는 언젠가 죽습니다. 그게 오늘이었을 뿐이죠.

 

중요한 건 죽었을 때 당황하지 않는 것입니다. 절차만 알면 커피 한 잔 시간이면 끝납니다. ☕

 

다음에 또 빨간불이 뜨면, 이 글을 열어보세요. (제가 그러려고 쓴 거거든요)