Code Place 운영 중 WAL 증가로 PostgreSQL 인스턴스와 Longhorn 볼륨 복구를 진행하던 중, PVC를 다시 살리는 과정에서 mount error가 발생했다. 전체 장애 흐름은 WAL 폭주 이후 Longhorn·CNPG 장애 복구기에서 다루고, 이 글에서는 그중 Longhorn 볼륨이 실제 노드에서 mount되지 않던 문제만 따로 정리한다.
처음에는 DB가 실행되지 않는 문제처럼 보였다. 하지만 Kubernetes 이벤트를 보면 mount 실패가 기록되어 있었고, Longhorn에서는 share-manager 상태도 좋지 않았다.
처음에는 Longhorn 자체 문제처럼 보였다. 그런데 로그를 따라가다 보니 already mounted or mount point busy, ext4 관련 메시지, AppArmor 로그, multipathd 간섭 가능성까지 함께 확인해야 했다.
이 글은 전체 복구 과정 중 mount error를 Kubernetes와 Longhorn 화면에서 멈추지 않고, 리눅스 장치 관리 쪽까지 내려가며 확인한 기록이다.
문제 상황
가장 먼저 눈에 띈 것은 mount 실패와 관련된 메시지였다.
already mounted or mount point busyformat of disk failed- 장치가 이미 사용 중이라는 ext4 관련 메시지
- Longhorn share-manager가 정상적으로 올라오지 않는 상태
- AppArmor deny처럼 보이는 로그
처음에는 이 메시지들이 모두 같은 원인을 가리키는 것처럼 보이지 않았다. 어떤 것은 Kubernetes mount 문제처럼 보였고, 어떤 것은 파일시스템 문제처럼 보였고, 어떤 것은 보안 정책 문제처럼 보였다.
하지만 공통점은 있었다. Longhorn은 특정 장치를 잡아서 mount하려고 하는데, 시스템은 이미 그 장치가 사용 중이거나 준비되지 않았다고 보고 있었다.
Longhorn UI 확인
처음에는 Longhorn UI에서 volume 상태와 replica 상태를 확인했다. Longhorn을 쓰고 있으니 당연히 가장 먼저 볼 곳이었다.
하지만 Longhorn UI만으로는 설명되지 않는 부분이 있었다.
PVC는 존재했고, Longhorn volume도 어떤 상태로든 존재했다. 그런데 워크로드는 그 볼륨을 정상적으로 사용할 수 없었다. Longhorn에서 보이는 상태와 실제 Pod가 volume을 attach/mount하는 과정 사이에 간격이 있었다.
이때부터는 Longhorn 상태만 볼 것이 아니라 Kubernetes 이벤트와 노드 로그를 함께 봐야 했다. 스토리지 문제는 오퍼레이터나 UI에서 보이는 상태만으로 끝나지 않는 경우가 있었다.
mount busy 확인
already mounted or mount point busy는 단순해 보이지만, 실제로는 여러 상황에서 나올 수 있다.
- 이전 mount가 정상적으로 정리되지 않았는가
- 다른 프로세스가 같은 장치를 잡고 있는가
- share-manager가 기대하는 경로와 실제 mount 상태가 다른가
- 노드에서 장치 이름이나 링크가 예상과 다르게 잡혔는가
처음에는 남아 있는 mount나 Longhorn 프로세스 상태를 의심했다. 하지만 같은 증상이 반복되자, 단순히 mount point 하나를 지우는 것으로 끝나는 문제가 아닐 수 있다고 봤다.
이때 봐야 했던 질문은 "왜 시스템은 이 장치를 busy 상태로 보는가"였다. Kubernetes 이벤트에 보이는 문구를 바로 고치려 하기보다, 그 아래의 장치 상태를 확인해야 했다.
ext4 메시지 확인
중간에 format of disk failed와 ext4 관련 메시지도 보였다. 이 메시지만 보면 파일시스템이 깨졌거나 포맷 과정 자체가 문제라고 생각하기 쉽다.
하지만 이번 상황에서는 ext4가 문제의 시작점이라기보다, 이미 장치가 다른 쪽에서 사용 중인 상태에서 뒤늦게 실패한 결과에 가까워 보였다.
그래서 질문을 바꿨다.
"왜 ext4가 실패했지?"보다 "ext4가 접근하려는 장치를 누가 이미 잡고 있지?"를 먼저 확인했다.
이렇게 보니 문제를 파일시스템 자체로만 몰고 가기보다, 노드의 장치 관리 상태를 함께 봐야 했다.
share-manager 상태 확인
Longhorn에서 RWX 볼륨을 다룰 때 share-manager는 필요한 구성 요소다. share-manager가 정상적으로 올라오지 않으면 그 위의 워크로드도 볼륨을 제대로 붙이지 못할 수 있다.
하지만 share-manager 실패 역시 원인일 수도 있고 결과일 수도 있었다. share-manager가 장치를 mount하려고 했는데, 그 장치가 이미 busy 상태이거나 시스템의 다른 프로세스가 건드리고 있다면 share-manager도 실패할 수 있다.
즉, share-manager가 실패했다고 해서 그 컴포넌트 자체만 의심하면 안 됐다. share-manager가 실패한 이유가 노드의 장치 상태에 있을 수도 있었다.
AppArmor 로그 확인
로그 중에는 AppArmor deny나 ptrace 관련 메시지처럼 보이는 것도 있었다. 이런 보안 관련 로그는 눈에 잘 띈다. 처음 보면 원인처럼 보이기 쉽다.
하지만 전체 흐름을 놓고 보면, 증상을 더 직접적으로 설명하는 메시지는 mount busy, ext4 in use, format failed 쪽이었다. AppArmor 로그는 확인할 필요는 있었지만, 이번 mount 실패의 중심 원인으로 바로 단정하기는 어려웠다.
장애를 볼 때는 눈에 띄는 로그와 증상을 실제로 설명하는 로그를 나눠서 봐야 했다.
multipathd 간섭 확인
결국 확인해야 했던 질문은 하나였다.
"왜 시스템은 이 장치를 이미 사용 중이라고 보는가?"
만약 Longhorn이 관리해야 하는 장치를 시스템의 다른 컴포넌트가 먼저 잡거나 다른 방식으로 관리하려고 하면 이런 문제가 생길 수 있다. 이때 후보로 본 것 중 하나가 multipathd였다.
multipathd는 여러 경로를 가진 스토리지 장치를 관리하는 프로세스다. 환경에 따라 Longhorn이 관리하려는 블록 장치를 건드리거나, Longhorn이 기대하는 방식과 다르게 장치를 인식하게 만들 수 있다.
이번 장애에서 처음부터 multipathd 하나만 원인이라고 단정한 것은 아니었다. 다만 mount busy, ext4 in use, format failed 같은 메시지를 함께 보면, Longhorn이 장치를 독점적으로 다루지 못하는 상황을 의심할 만했다.
그래서 Longhorn 쪽 상태만 보는 대신, 노드에서 장치를 누가 잡고 있는지, 어떤 프로세스가 관련되어 있는지, 시스템이 해당 장치를 어떤 상태로 보고 있는지까지 함께 확인했다.
multipathd 비활성화
최종적으로는 multipathd를 중지하고 비활성화한 뒤 mount 문제가 풀렸다.
이 조치는 단순히 노드를 재부팅해서 상태를 초기화한 것과는 다르다. Longhorn이 관리해야 하는 블록 장치를 multipathd가 함께 인식하거나 건드릴 가능성이 있었고, 그 결과 Longhorn 입장에서는 장치를 정상적으로 format/mount하지 못하는 상황이 생길 수 있었다.
그래서 문제를 단순히 "Longhorn mount가 실패했다"로만 보지 않고, 노드에서 해당 장치를 어떤 프로세스가 관리하고 있는지까지 확인했다. multipathd를 끈 뒤 mount가 진행되면서, 이번 문제는 Longhorn 자체보다는 노드의 장치 관리 프로세스와 충돌한 쪽에 더 가까워 보였다.
이 내용은 multipathd를 무조건 꺼야 한다는 결론이 아니다. Longhorn처럼 블록 장치를 직접 관리하는 스토리지 시스템을 사용할 때, 노드의 다른 장치 관리 프로세스가 같은 장치를 건드릴 수 있다는 점을 확인해야 한다는 것이다.
확인한 내용
이 일을 겪고 나서 스토리지 장애를 볼 때 확인하는 항목이 늘었다. 예전에는 Longhorn이나 Kubernetes 이벤트에 보이는 메시지를 중심으로 봤지만, 이제는 그 아래의 실제 장치 상태도 함께 확인하려고 한다.
확인한 내용은 이렇다.
- PVC나 Longhorn Volume이 존재한다고 해서 실제로 사용할 수 있다는 뜻은 아니다.
Bound상태와 실제 attach/mount 성공은 다르다.- mount 실패는 Kubernetes나 Longhorn UI만으로 설명되지 않을 수 있다.
mount busy가 보이면 노드에서 누가 장치를 잡고 있는지 확인해야 한다.- share-manager 실패는 원인일 수도 있고, 아래 장치 문제의 결과일 수도 있다.
- AppArmor처럼 눈에 띄는 로그가 있어도, 실제 증상을 설명하는 로그인지 따로 확인해야 한다.
- Longhorn이 관리해야 할 장치를
multipathd같은 시스템 프로세스가 건드릴 수 있는지 확인해야 한다.
비슷한 mount 실패를 다시 보면, Kubernetes 이벤트, Longhorn volume/share-manager 상태, 노드 장치 상태, 시스템 프로세스 순서로 확인하려고 한다.
정리
이번 문제는 Longhorn 화면에서 volume 상태만 봐서는 충분하지 않다는 것을 보여줬다. 위에서는 PostgreSQL 인스턴스가 뜨지 않는 문제처럼 보였고, 중간에서는 Longhorn mount 실패처럼 보였지만, 실제 확인은 노드의 장치 상태와 시스템 프로세스까지 내려가야 했다.
mount failure, format failure, share-manager 문제는 따로 보면 흩어진 메시지처럼 보였다. 하지만 multipathd가 Longhorn이 사용해야 할 장치에 간섭할 수 있다는 관점에서 다시 보니, mount busy, ext4 in use, format failed 같은 메시지가 하나의 흐름으로 연결됐다.
운영 장애를 볼 때는 어느 화면에서 에러가 보였는지만 보지 않고, 그 에러가 어느 단계에서 만들어졌는지도 확인해야 했다. 이번 문제는 Longhorn 화면에서 끝나는 문제가 아니라, 노드의 장치 관리 프로세스까지 내려가야 풀리는 문제였다.