ESXi 호스트가 데이터 저장소를 마운트하지 못해 붉은색 에러 팝업이 떠 있는 스크린샷을 보신적 있으신가요? 정말 멘붕 오겠죠 ? 오늘은 Nutanix 메트로 구성에서 발생한 APD(All Paths Down) 이슈에 대해 이야기해 볼께요.
죽어도 안 붙는 데이터 저장소, 원인이 대체 뭐야?
멀쩡히 돌아가던 메트로 클러스터에서 사이트 A가 죽고 사이트 B로 넘어가는 긴박한 상황, 한 번쯤 겪어보셨나요? 이때 하필 사이트 A의 호스트가 APD(All Paths Down) 상태에서 재부팅까지 되어버리면 상황은 아주 복잡해집니다. 사이트를 다시 원복해도 이 호스트만 데이터 저장소를 못 잡고 헤맵니다.
사실 하이퍼바이저 입장에선 억울할 수도 있어요. 재부팅될 때 APD(All Paths Down) 설정이 뇌리에 박혀버린 건데, 경로가 다시 살아나도 "응, 나 옛날에 경로 끊겼었어"라며 그 기억을 안 지우는 겁니다. 수동으로 마운트하려고 하면 'Bad parameter' 같은 성의 없는 에러만 툭 던지고 마니까 엔지니어는 미치고 팔짝 뛸 노릇이죠.
 |
| APD(All Paths Down) 발생하는 메세지 예시 화면 |
새벽 3시, 등줄기를 타고 흐르는 식은땀과 메트로 클러스터의 배신
장애 발생 시 새벽에 전화 받고 고객사 담당자랑 팀장님 카톡 불날 때, 땀 뻘뻘 흘리며 vCenter만 쳐다보는 그 심정 아시나요? 아, 머릿속이 하얘집니다. 메트로 액티브-스탠바이 구조에서 사이트가 쪼개질 때 스플릿 브레인(Split-brain)을 막으려고 호스트는 데이터를 지키기 위해 I/O를 완전히 멈춰버려요. 그게 바로 APD(All Paths Down)상태입니다.
근데 그 상태에서 호스트가 리부팅된다? 뇌는 멈췄는데 몸만 다시 깨어난 격이죠. 시스템은 안전을 위해 기존에 끊어졌던 스토리지 경로의 상태를 그대로 쥐고 일어납니다. 이게 바로 우리를 미치게 만드는 논리적 마운트 꼬임의 핵심이에요.
이 경험을 통해 알게 된 [APD 마운트 오류] 꿀팁
- 로그가 답이다: vmkernel.log를 열어서 "NFS status: Bad parameter"가 찍혔는지부터 보세요. 이게 보이면 100%입니다.
- 유령 데이터 저장소:
esxcli storage nfs list에는 없는데, 추가하려고 하면 "이미 있다"고 나옵니다. 호스트 내부에 알수없는 가비지값이 남은 거예요.- 동기화 우선: 명령어를 치기 전에 반드시 보호 도메인(PD) 상태가 'Enabled(Synced)'인지 확인하세요. 안 그러면 시간 낭비입니다.
로그에 찍힌 'Bad parameter', 이게 스모킹 건입니다
호스트에 SSH로 붙어서 로그를 슥 훑어보세요. StorageApdHandler가
APD 핸들을 생성했다가 해제했다가 난리를 치는데, 결국 마지막엔
Got error 22 from mount call이라는 메시지를 남깁니다. 이게 바로
하이퍼바이저가 논리적으로 꼬였다는 확실한 증거구요.
재밌는 건 이겁니다. esxcli storage nfs add 명령어를 날리면 "이미
그 레이블이 존재한다"고 에러가 나거든요? 근데 정작 리스트를 뽑아보면 해당
저장소는 보이지도 않아요. 존재하는데 존재하지 않는, 그야말로 양자역학 같은
상황인 거죠. 영화 인터스텔라가 생각 나네요..
실전! 이 지옥에서 살아남는 3단계 탈출 로직
이럴 땐 그냥 깔끔하게 지우고 다시 만드는 게 답입니다. 복잡하게 생각하지 마세요. 아래 순서대로만 따라 하면 여러분도 '갓지니어' 소리 듣습니다. ㅋ
1단계: 가짜 찌꺼기 강제 제거
리스트에는 안 보이지만, 호스트가 붙들고 있는 찌꺼기를 강제로 날려야 합니다. 아래 명령어를 쓰세요.
esxcli storage nfs remove -v <컨테이너_이름>
2단계: 깨끗하게 다시 마운트
이제 다시 연결해 줄 시간입니다. IP 주소랑 경로를 정확히 입력하는 게 포인트입니다.
esxcli storage nfs add -H <스토리지_IP> -s /<컨테이너_이름> -v <컨테이너_이름>
3단계: 정상 작동 확인
마지막으로 리스트를 다시 뽑아보세요. Accessible이 'true'로 바뀌고 Mounted가 'true'로 떴다면 상황 종료입니다.
근데 여기서 진짜 중요한 게 하나 있어요. 사이트 B에서 사이트 A로 보호 도메인을 다시 활성화했을 때, 반드시 동기화(Sync)가 끝날 때까지 기다려야 합니다. 성질 급하게 마운트 명령어부터 날리면 "콘솔 경로를 가져올 수 없다"는 또 다른 에러를 만나게 될 테니까요.
아무리 지우고 붙여도 안 된다고? 네트워크 스택을 털어보자
가끔 위 3단계 명령어 콤보를 먹여도 꼼짝 안 하는 악질적인 케이스가 숨어 있습니다. 이때는 스토리지 네트워크 통신 자체가 꼬였거나 리부팅되면서 날아갔을 확률이 높아요. 무작정 명령어만 다시 치지 마세요.
바로 vmkping -s 8972 -d -I vmkX <스토리지_IP>를 날려서
통신이 되는지부터 확인하세요. 특히 점보 프레임(MTU 9000) 세팅이 리부팅되면서
기본값으로 롤백되진 않았는지 무조건 체크해야 합니다. 스토리지 통신이
단절됐는데 껍데기만 붙이려고 삽질을 두 번 할 필요는 없으니까요.
엔지니어의 직관: 왜 자동 복구가 안 될까?
어떤 분들은 "왜 이런 걸 수동으로 해줘야 하느냐"고 묻습니다. VMware와 Nutanix의 메트로 가용성 구조가 얽히면서 발생하는 일종의 예외 상황인 거죠. 경로가 완전히 죽은 상태에서 재부팅이라는 강수를 뒀으니, 호스트 입장에서도 안전을 위해 마운트를 막아두는 방어 기제가 작동한 셈이죠.
초보 엔지니어라면 당황해서 호스트를 또 재부팅하거나 vCenter를 들쑤시곤 하는데, 그러지 마세요. 그냥 CLI로 찌꺼기 지우고 다시 붙이는 게 가장 빠르고 확실합니다. 이 방법 하나면 적어도 밤새도록 로그만 보다가 퇴근 못 하는 불상사는 막을 수 있습니다.
개개인 마다 겪는 상황이 다 다르기 때문에 정답은 없습니다. 하지만, 그래도 직관은 생기겠죠? 많은 분들에게 도움 되길 바래요. 고객사에 계약이 되어 있다면 바로 CaseOpen 진행 해도 되구요.
본인에게 유리한 방법으로 진행해 보세요. 그럼 이만 !~
0 댓글