Code Place 운영 중 PostgreSQL 볼륨이 정상적으로 연결되지 않는 문제가 있었다. 상위에서는 DB가 실행되지 않는 문제처럼 보였지만, Kubernetes 이벤트를 보면 mount 실패가 기록되어 있었고, Longhorn에서는 share-manager 상태도 좋지 않았다.
처음에는 Longhorn 자체 문제처럼 보였다. 그런데 로그를 따라가다 보니 already mounted or mount point busy, ext4 관련 메시지, AppArmor 로그, multipathd 간섭 가능성까지 함께 확인해야 했다.
이 글은 Longhorn 볼륨 마운트 실패를 Kubernetes와 Longhorn 화면에서 멈추지 않고, 리눅스 장치 관리 레이어까지 내려가며 확인한 기록이다.
처음 보인 문제
처음 눈에 들어온 것은 mount 관련 오류였다.
already mounted or mount point busyformat of disk failed- ext4 장치가 이미 사용 중이라는 메시지
- Longhorn share-manager가 정상적으로 올라오지 못하는 상태
- AppArmor denial처럼 보이는 로그
이 메시지들은 한 번에 같은 원인을 가리키는 것처럼 보이지 않았다. 어떤 것은 Kubernetes mount 문제처럼 보였고, 어떤 것은 파일시스템 문제처럼 보였고, 어떤 것은 보안 정책 문제처럼 보였다.
하지만 공통적으로 걸린 것은 하나였다. Longhorn이 기대한 방식으로 장치를 잡고 mount해야 하는데, 시스템은 그 장치가 이미 사용 중이거나 제대로 준비되지 않았다고 보고 있었다.
원인을 확인한 과정
처음에는 Longhorn UI에서 볼륨 상태와 replica 상태를 먼저 봤다. Longhorn을 쓰고 있으니 당연한 접근이었다. 그런데 Longhorn 화면만 보고는 설명되지 않는 부분이 있었다.
PVC는 존재했고, 볼륨도 어떤 상태로든 잡혀 있었다. 그런데 워크로드는 그 볼륨을 정상적으로 쓰지 못했다. Longhorn에서 보이는 상태와 실제 Pod가 mount하는 과정 사이에 간격이 있었다.
이때부터는 Longhorn 자체 상태뿐 아니라 Kubernetes 이벤트와 노드 로그를 함께 확인해야 했다. 스토리지 문제는 오퍼레이터 화면에서 끝나지 않는 경우가 많았다.
mount busy에서 먼저 본 것
already mounted or mount point busy는 단순해 보이지만, 실제로는 여러 가능성을 포함한다.
- 이전 mount가 제대로 정리되지 않았는가
- 같은 장치를 다른 프로세스가 잡고 있는가
- share-manager가 기대한 경로와 실제 mount 상태가 어긋났는가
- 노드에서 장치 이름이나 링크가 예상과 다르게 잡혔는가
처음에는 이전 mount 흔적이나 Longhorn 프로세스 상태를 의심했다. 하지만 같은 증상이 반복되면서, 단순히 mount point만 지워서 해결할 수 있는 문제가 아닐 수 있다고 봤다.
중요한 것은 "왜 busy로 보이는가"였다. Kubernetes 이벤트의 한 줄을 해결 대상으로 보기보다, 그 메시지가 발생한 아래 장치 상태를 확인해야 했다.
ext4 메시지에서 걸린 부분
포맷 실패나 ext4 관련 메시지도 함께 보였다. 이 메시지만 보면 파일시스템 손상이나 포맷 실패 자체를 먼저 의심하게 된다.
하지만 이번에는 ext4가 문제의 시작이라기보다, 이미 다른 계층에서 장치를 사용 중으로 점유하고 있어서 포맷이나 mount가 실패하는 흐름에 더 가까워 보였다.
여기서 확인 방향이 바뀌었다. "ext4가 왜 실패했지"보다 "ext4가 접근하려는 장치를 누가 이미 사용하고 있지"를 먼저 확인하기 시작했다.
share-manager와 AppArmor 로그
Longhorn에서 share-manager는 RWX 볼륨 처리에 중요하다. 이 컴포넌트가 정상적으로 올라오지 못하면, 상위 워크로드는 볼륨을 정상적으로 연결하지 못한다.
그런데 share-manager 실패도 원인이라기보다 결과일 수 있었다. share-manager가 장치를 mount하려고 했지만, 그 장치가 이미 busy 상태거나 시스템 레벨에서 다르게 잡혀 있으면 share-manager도 실패한다.
AppArmor denial이나 ptrace 관련 메시지도 함께 보였다. 보안 정책 관련 로그는 눈에 띄지만, 전체 흐름을 기준으로 보면 ext4 in use나 mount busy 같은 증상을 더 잘 설명하는 것은 장치 점유 상태였다.
장애를 볼 때는 눈에 띄는 로그와 실제 증상을 가장 많이 설명하는 로그를 구분해야 했다.
해결 방안
결국 확인해야 할 질문은 하나였다. "시스템이 이 장치를 이미 사용 중이라고 판단하는 이유가 무엇인가"였다.
Longhorn이 기대하는 방식과 별개로, 시스템 레벨에서 다른 컴포넌트가 장치를 관리하고 있다면 이런 일이 생길 수 있다. 이 지점에서 떠오른 후보 중 하나가 multipathd였다.
multipathd는 여러 경로를 가진 스토리지 장치를 관리하는 프로세스인데, 환경에 따라 Longhorn이 다뤄야 할 장치를 건드리거나 간섭할 수 있었다. 이 계층을 확인하면서 mount busy, ext4 in use, 포맷 실패 같은 메시지들이 조금씩 같은 원인 후보로 연결되기 시작했다.
정리한 기준
이 일을 겪은 뒤 스토리지 장애를 확인하는 방식도 달라졌다. 예전에는 Longhorn이나 Kubernetes 이벤트 메시지를 중심으로 문제를 해석했다면, 이제는 그 아래에서 실제 장치가 어떤 상태인지까지 함께 확인한다.
특히 아래 기준을 정리했다.
- PVC나 Volume이 있다고 해서 실제로 쓸 수 있다는 뜻은 아니다.
- Longhorn 문제처럼 보여도 시작점은 리눅스 장치 관리 레이어일 수 있다.
- mount 실패를 보면 오퍼레이터만 보지 않고, 노드와 장치 상태도 함께 확인해야 한다.
비슷한 mount 실패를 볼 때는 Kubernetes 이벤트, Longhorn 볼륨 상태, 노드 장치 상태, 시스템 레벨 장치 관리 프로세스 순서로 확인한다.
마무리
이번 일은 스토리지 장애를 확인하는 방식을 바꿨다. 예전에는 Longhorn이나 Kubernetes에서 보이는 메시지를 중심으로 판단했다면, 지금은 그 아래 장치가 실제로 어떤 상태인지까지 함께 확인한다.
마운트 실패와 포맷 실패, share-manager 이상은 각각 따로 보면 관련 없는 메시지처럼 보였다. 하지만 장치가 시스템 레벨에서 이미 사용 중으로 인식되고 있다는 관점에서 보니, 흩어져 있던 메시지가 하나의 원인 후보로 이어졌다.