outline-data Longhorn 스냅샷 250개 하드캡 초과 사건 기록 및 해결
- k3s 정기 점검 중 outline-data 볼륨 스냅샷 256개(하드캡 250 초과)로 critical-snapshot/critical-backup 신규 생성 실패 발견 - kubectl delete(webhook이 finalizer 유지)와 파드 재배포/재attach 둘 다 무효였음을 확인 후, Longhorn REST API snapshotPurge 반복 호출로 256 -> 58개 정상화 - 근본 원인(retain 정책이 왜 이 볼륨만 실패했는지)은 미확정으로 남김
This commit is contained in:
kaffa
100
history/2026-07-11-outline-data-snapshot-cap-exceeded.md
Normal file
100
history/2026-07-11-outline-data-snapshot-cap-exceeded.md
Normal file
@@ -0,0 +1,100 @@
|
||||
---
|
||||
date: 2026-07-11
|
||||
topic: outline-data 볼륨 Longhorn 스냅샷 250개 하드리밋 초과
|
||||
areas: [infra/platform/longhorn]
|
||||
---
|
||||
|
||||
# 2026-07-11 / outline-data 볼륨 snapshot count 하드리밋(250) 초과
|
||||
|
||||
## 배경
|
||||
|
||||
정기 k3s 상태 점검(kubectl events 확인) 중 발견:
|
||||
|
||||
```
|
||||
Warning Failed snapshot/critical-b8830e5f-... longhorn-snapshot-controller
|
||||
proxyServer=10.42.2.83:8501 destination=10.42.2.83:11000: failed to snapshot volume:
|
||||
rpc error: code = Unknown desc = snapshot count total is already too big: 250
|
||||
```
|
||||
|
||||
`outline/outline-data` PVC → Longhorn volume `pvc-c4bb2746-79f4-41ea-85fc-765cfc473b15` (attach node incus-hp2). 이 볼륨에 대해 `critical-snapshot`(매시 정각, retain 24) / `critical-backup`(6시간마다, retain 28) recurring job이 신규 스냅샷을 못 만드는 상태.
|
||||
|
||||
## 확인된 사실
|
||||
|
||||
### 1. outline-data만의 이상 급증 (다른 볼륨은 정상)
|
||||
|
||||
전체 25개 Longhorn 볼륨 스냅샷 개수 비교:
|
||||
|
||||
| 볼륨 | 스냅샷 수 |
|
||||
|---|---|
|
||||
| **pvc-c4bb2746 (outline-data)** | **256** |
|
||||
| pvc-b3ae6d0d 외 8개 | 55 |
|
||||
| pvc-e5f7459d | 42 |
|
||||
| pvc-573db32c 외 2개 | 38 |
|
||||
| pvc-7fcc0e0a | 31 |
|
||||
| pvc-f248b2d1 외 8개 | 30 |
|
||||
| pvc-405c0355 | 25 |
|
||||
| pvc-f4b8b3b4, pvc-c702c67d | 8 |
|
||||
|
||||
동일한 recurring-job-group(`critical`, `default`) 라벨을 가진 다른 볼륨들은 모두 8~55개 범위에서 retain 정책이 정상 작동 중. outline-data만 250 하드캡을 넘김. 가장 오래된 잔존 스냅샷은 2026-06-01 (약 40일 전) — 정상 볼륨이면 retain 24~28에 의해 진작 정리됐어야 할 나이.
|
||||
|
||||
### 2. Backup(R2 업로드)은 정상 — 문제는 순수 snapshot만
|
||||
|
||||
`kubectl get backups.longhorn.io` 로 확인: outline-data의 Backup CR은 10개 전부 `Completed`, retain(28) 이내. 즉 R2로의 실제 백업/정리는 문제 없음. 하드캡을 넘긴 건 스냅샷(로컬 체인) 쪽만.
|
||||
|
||||
### 3. (정정) `status.ownerID=""` 는 outline-data만의 특징이 아님
|
||||
|
||||
최초 가설: 이 볼륨 스냅샷들의 `ownerID` 가 비어있어 [[2026-05-02-longhorn-snapshot-purge-cron|2026-05-02 v1.11.1 ownerID-loss 회귀]]와 동일 패턴이라 추정했으나, **클러스터 전체 25개 볼륨 전 스냅샷을 재확인한 결과 ownerID="" 는 모든 볼륨에 공통**이었음 (outline-data 256개, 나머지 볼륨들도 각자의 전체 스냅샷 100%가 동일). 즉 이 값은 정상/이상을 가르는 신호가 아니었고 위 가설은 근거 없음 — 재발 원인을 ownerID 회귀와 동일시하지 말 것.
|
||||
|
||||
### 4. 수동 kubectl delete 시도 → 실제 삭제 안 됨 (outline-data에서 재현, 타 볼륨 미검증)
|
||||
|
||||
하드캡 해소를 위해 가장 오래된 226개(최근 30개만 남기고) `kubectl delete snapshots.longhorn.io` 실행:
|
||||
|
||||
- 즉시 삭제되지 않고 `metadata.deletionTimestamp` 만 설정, `finalizers: ["longhorn.io"]` 유지된 채 정지
|
||||
- 수 분 경과 후에도 199개가 `deletionTimestamp` 있음 + `status.markRemoved=false` 그대로 — engine 단에서 삭제 요청이 전혀 처리되지 않음
|
||||
- 전체 스냅샷 개수는 삭제 시도 전후 256개로 변화 없음 (실질적 정리 실패)
|
||||
- **볼륨 자체는 영향 없음**: `state=attached, robustness=healthy`, Outline pod/서비스 정상 (재시작 없음)
|
||||
- 이 "삭제해도 안 지워짐" 현상이 다른 정상 볼륨에서도 재현되는지는 검증 안 함 — outline-data만 시도했음
|
||||
|
||||
### 5. Outline 파드 삭제 → 볼륨 detach/reattach 시도 → 효과 없음 (반증됨)
|
||||
|
||||
가설: 파드를 삭제해 볼륨을 완전히 detach 시켰다가 재attach 시키면 engine이 새로 뜨면서 stuck 상태(199개 deletionTimestamp-고착)가 풀릴 수도 있다.
|
||||
|
||||
실행: `kubectl delete pod outline-5d9fd7c56-62f6t -n outline` → ReplicaSet이 새 파드를 다른 노드(incus-hp2 → **incus-kr1**)에 스케줄 → 볼륨이 완전히 새 노드로 재attach (`state=attached, robustness=healthy, node=incus-kr1`), 새 engine 프로세스로 교체됨. 파드는 정상 Running 복귀, Outline 서비스 중단 없음(수 초 이내).
|
||||
|
||||
**결과: 아무 변화 없음.**
|
||||
- 전체 스냅샷 개수: 재시도 전후 동일하게 256개
|
||||
- `deletionTimestamp` 있는 stuck 항목: 200개 그대로 (재attach로 처리 진행 안 됨, markRemoved 여전히 false)
|
||||
- 새로 뜬 engine 하에서도 `ownerID`는 256개 전부 빈 값 그대로
|
||||
|
||||
**결론: "볼륨 detach/reattach(=파드 재배포)로 리셋된다"는 가설은 틀렸다.** 문제는 노드/engine/instance-manager 레벨이 아니라 **longhorn-manager 컨트롤 플레인 쪽 상태**에 있는 것으로 보임 (레플리카·engine을 갈아치워도 CR 상의 stuck 상태가 그대로 유지되는 것이 그 근거). 향후 같은 시도 반복 불필요.
|
||||
|
||||
### 6. 해결: `snapshotPurge` API 반복 호출로 256개 → 58개 정상화
|
||||
|
||||
`kubectl delete`(finalizer 무력화됨)와 파드/노드 재attach(효과 없음) 둘 다 실패한 뒤, [[2026-05-02-longhorn-snapshot-purge-cron|2026-05-02 도입 기록]]에 나온 Longhorn REST API `snapshotPurge` 액션을 직접 호출:
|
||||
|
||||
```bash
|
||||
kubectl port-forward -n longhorn-system svc/longhorn-frontend 19500:80 &
|
||||
curl -s -X POST -H "Content-Type: application/json" -d '{}' \
|
||||
"http://127.0.0.1:19500/v1/volumes/pvc-c4bb2746-79f4-41ea-85fc-765cfc473b15?action=snapshotPurge"
|
||||
```
|
||||
|
||||
- 1회 호출마다 응답은 HTTP 200 + 볼륨 리소스 echo (액션 자체 결과값은 없고 트리거만 됨 — 비동기)
|
||||
- 약 8~10초 간격으로 **반복 호출**하니 매번 카운트가 점진적으로 감소: 256 → 225 → 209 → 200 → 192 → 181 → 169 → 145 → 130 → 103 → 90 → 74 → 67 → 59 → **58**
|
||||
- 총 약 20회 트리거, 5분 정도 소요
|
||||
- 최종 상태: 스냅샷 58개(다른 정상 볼륨과 같은 범위), `deletionTimestamp` 남은 것 3개(자연 정리 진행 중으로 추정), 볼륨 `state=attached/robustness=healthy`, Outline 파드 정상 Running, 서비스 중단 없음
|
||||
|
||||
**교훈**: 이 볼륨의 문제는 kubectl CR delete로는 못 풀리고(webhook이 finalizer 유지) engine 재시작(파드 재배포/재attach)으로도 안 풀렸다 — **오직 Longhorn 자체 `snapshotPurge` API를 반복 호출해야만 체인이 실제로 정리**됐다. 1회 호출은 충분하지 않고, 남은 개수가 줄어드는 걸 보면서 **여러 번 반복 호출**해야 완전히 정리됨(한 번에 전부 처리되는 게 아니라 매 호출마다 일부 chain만 병합·정리하는 것으로 보임).
|
||||
|
||||
## 후속 필요 (근본 원인은 여전히 미확정)
|
||||
|
||||
- **당장의 하드캡 문제는 해소됨** (58개, 여유 충분). critical-snapshot/critical-backup 재개 여부는 다음 스케줄(정각/6시간 단위)에 확인 필요
|
||||
- **근본 원인은 여전히 미확정**: 애초에 이 볼륨만 왜 retain 정책이 안 먹혀 256개까지 쌓였는지는 안 풀림. 재발 시 아래 순서로 대응:
|
||||
1. 먼저 이번에 검증된 `snapshotPurge` API 반복 호출 (가장 빠르고 효과 확인됨) — port-forward + curl 반복, 수 분 내 해결
|
||||
2. 재발 빈도가 잦으면 [[2026-05-02-longhorn-snapshot-purge-cron|보존된 longhorn-snapshot-purge 차트]]를 outline-data 대상으로 상시 cron화하는 것도 고려 (현재는 1회성 수동 대응으로 충분)
|
||||
3. Longhorn upstream에 v1.11.2에서의 신규 케이스로 문의/이슈 등록 검토 (근본 원인 규명 목적, 급하지 않음)
|
||||
|
||||
## 관련 문서
|
||||
|
||||
- [[../infra/platform/longhorn|longhorn]] — Longhorn 정본 문서
|
||||
- [[2026-05-02-longhorn-snapshot-purge-cron|2026-05-02 snapshot-purge cron 도입]] / [[2026-05-09-longhorn-snapshot-purge-cron-removal|2026-05-09 회수]] — 유사하나 별개로 판명된 과거 사건
|
||||
- [[../data/k3s-backup|k3s-backup]] — 백업/recurring job 구성
|
||||
@@ -1,6 +1,6 @@
|
||||
---
|
||||
title: Longhorn 분산 블록 스토리지
|
||||
updated: 2026-05-09
|
||||
updated: 2026-07-11
|
||||
tags: [infra, platform, longhorn, storage, k3s]
|
||||
---
|
||||
|
||||
@@ -104,6 +104,19 @@ kubectl get snapshots.longhorn.io -A -o json | jq '[.items[] | select(.status.ma
|
||||
|
||||
상세 도입 기록: [[../../history/2026-05-02-longhorn-snapshot-purge-cron|2026-05-02 도입]] / [[../../history/2026-05-07-longhorn-1-11-2-upgrade|2026-05-07 fix 적용]] / [[../../history/2026-05-09-longhorn-snapshot-purge-cron-removal|2026-05-09 회수]]
|
||||
|
||||
## 볼륨별 snapshot count 하드리밋(250) 초과 시 대응 (2026-07-11 사례)
|
||||
|
||||
`outline-data` (`pvc-c4bb2746-...`) 볼륨이 스냅샷 256개까지 쌓여 볼륨당 하드캡 250을 초과, `critical-snapshot`/`critical-backup` 신규 생성 실패한 사례 발생. 근본 원인(왜 이 볼륨만 retain 정책이 안 먹혔는지)은 미확정이나, **`kubectl delete`(admission webhook이 finalizer 재부착해 무효) 와 파드/노드 재attach(효과 없음) 둘 다 실패**하고, **Longhorn REST API `snapshotPurge` 액션을 반복 호출**해서만 정상화(256→58) 성공:
|
||||
|
||||
```bash
|
||||
kubectl port-forward -n longhorn-system svc/longhorn-frontend 19500:80 &
|
||||
# 8~10초 간격으로 여러 번 반복 (1회로는 부족, 스냅샷 개수 줄어드는 것 보며 반복)
|
||||
curl -s -X POST -H "Content-Type: application/json" -d '{}' \
|
||||
"http://127.0.0.1:19500/v1/volumes/<volume-name>?action=snapshotPurge"
|
||||
```
|
||||
|
||||
재발 시 이 방법을 먼저 시도할 것. 상세: [[../../history/2026-07-11-outline-data-snapshot-cap-exceeded|2026-07-11 history]]
|
||||
|
||||
## 업그레이드 절차 (표준)
|
||||
|
||||
minor skip 금지 — 한 단계씩 순차. 각 단계 공통:
|
||||
|
||||
Reference in New Issue
Block a user