0. 이 챕터의 정찰 목적
챕터 01은 클러스터라는 단일 단위의 동기성·정족수를 다뤘다. 본 챕터는 클러스터를 구성하는 5개 개별 노드 각각의 정체를 밝힌다. 같은 버전의 Proxmox를 돌리는 노드라도 다음 차원에서 얼마든지 달라질 수 있다.
- 하드웨어 스펙 (CPU 모델·메모리·NUMA 토폴로지)
- 실제 부하 분포와 부하의 원인
- 시간 동기화 reference의 일관성
- 부팅 이력과 안정성
- 노드 역할의 비대칭성 (jump host, HA 매스터, 전담 노드 등)
이 정보 없이 CMP 테스트를 시작하면 다음 사고가 반복적으로 발생한다.
- 한 노드에서는 작동하는 테스트가 다른 노드에서 실패한다 — 그게 CMP 결함인지 노드 차이인지 모른다
- 특정 노드에 작업이 쏠려 다른 노드는 놀고 있는데 쏠린 노드는 타임아웃 난다
- 노드별 시계 편차로 로그 시계열 상관 분석이 무너진다
- Crash 이력을 모르고 테스트를 시작하다가 과거 장애의 재발을 결함으로 오보고한다
본 챕터는 이 네 사고 유형을 예방하기 위한 노드 단위 사전 지식을 제공한다.
본 챕터는 챕터 00~01에서 미결로 남은 다음 항목을 직접 처리한다.
- 챕터 00 §2.5에서 등록된 chrony 외부 NTP 의존 리스크 — 5노드 비교로 구체화
- 챕터 00 §2.6 / 01 §2.5에서 추적 중이던 nd02 상시 부하 원인
- 챕터 00 §2.7에서 식별된 nd01 사용자 집중 (jump host 정황)
- 챕터 01 §2.5에서 식별된 nd05 reboot 정상성 검증
- 챕터 00·01에서 단편적으로 드러난 CMP의 분산 구조
1. 개념 — 본문 이해에 필요한 최소 배경
1.1 Load Average와 CPU Utilization의 차이
uptime이 보여주는 load average는 실행 대기(runnable) + 비동기 I/O 대기(uninterruptible) 상태 프로세스 수의 지수 이동 평균이다. 퍼센트가 아니다. 16 CPU 노드에서 load 1.0이면 CPU 전체의 약 6%를 사용하는 셈. 16 CPU 노드에서 load 16.0이 되어야 100% 사용이다.
본 환경의 5노드 모두 16 CPU이므로 load average 해석은 다음 기준을 사용한다.
| load | 해석 |
|---|---|
| 0.3 | 정상 idle |
| 0.7 | 가벼운 백그라운드 부하 |
| 1.0 | 단일 CPU 완전 점유 또는 다중 CPU 분산 |
| 4.0 | 4 CPU 분량 부하 |
| 16.0 | 전체 CPU 포화 |
| 20+ | Oversubscribed, 응답성 저하 가능 |
%CPU in ps -eo pcpu는 다르다. 이는 단일 CPU 기준 점유율로 최대 100을 초과할 수 있다 (다중 스레드 프로세스가 여러 CPU를 동시에 쓰면). ps --sort=-pcpu의 결과를 해석할 때는 100 이상이 정상 범위임을 기억한다.
1.2 NUMA (Non-Uniform Memory Access)
멀티 소켓 CPU 서버에서는 각 소켓에 로컬 메모리가 붙어 있고, 다른 소켓의 메모리에 접근하려면 소켓 간 인터커넥트(AMD Infinity Fabric, Intel QPI/UPI)를 거친다. 로컬 접근과 원격 접근의 레이턴시가 달라 같은 노드 내에서도 VM이 배치된 NUMA 노드에 따라 성능이 달라진다.
본 환경은 5노드 모두 단일 소켓 + 단일 NUMA 노드(§2.4 참조). 즉 NUMA 이슈는 없다. 이는 다행이다. 다중 NUMA 환경이라면 VM의 vCPU·메모리 배치 전략이 테스트 변수에 추가된다. 본 환경에서는 이 변수가 0으로 고정된다.
1.3 KSM (Kernel Samepage Merging)
커널이 서로 다른 VM의 동일 내용 메모리 페이지를 자동 병합하여 메모리 사용량을 줄이는 기능. 본 환경에서는 5노드 모두 ksm run: 0 — 비활성 상태. 메모리 압박이 발생하면 Proxmox가 자동으로 활성화하도록 기본 설정되어 있다(ksmtuned 데몬). 현재는 압박 수준에 도달하지 않았다는 의미.
1.4 wtmpdb의 crash 태그 — 컨텍스트 의존 의미
last reboot 명령은 wtmpdb(Debian Trixie 이후 wtmp 대체)에서 부팅 이력을 읽는다. 각 엔트리에 still running / 2026-XX-XX / crash 중 하나의 태그가 붙는다.
still running: 현재 부팅 세션- 구체적 시각: 다음 부팅 직전까지 정상 운영, 그 시각에
shutdown또는reboot명령으로 graceful 종료 crash: graceful shutdown 로그 없이 다음 부팅이 시작됨
여기서 중요한 판독 원칙이 하나 있다. crash 태그는 "비의도적 장애"를 의미하지 않는다. graceful shutdown 로그가 안 남은 모든 종료가 여기에 걸린다. 다음 경우 모두 crash로 기록된다.
- 실제 커널 패닉 또는 하드웨어 장애
- 정전 / 전원 케이블 분리
- 물리 전원 버튼을 눌러 강제 종료 (테스트 목적 포함)
echo b > /proc/sysrq-trigger같은 즉시 재부팅- 가상화 환경에서 하이퍼바이저가 VM을 강제 종료
즉 crash 태그의 해석은 환경 컨텍스트에 의존한다. 본 환경에서 nd05의 4/15~4/17 사이 3건의 crash는 실제 장애가 아니라 개발팀의 HA 페일오버 시험을 위한 의도된 강제 종료다(§2.8에서 확인). 로그 태그 하나로 자동 결론을 내리지 않는다는 원칙이 여기서 나온다.
1.5 노드별 %CPU 100을 순간 찍는 프로세스의 해석
ps --sort=-pcpu 결과에서 ELAPSED 0초 전후의 프로세스가 %CPU 100을 찍는 경우가 자주 관찰된다. 본 환경 §2.5 nd03에서 python3 /sbin/ifquery -a -c -o json이 이 패턴으로 잡혔다.
이는 샘플링 순간 해당 프로세스가 시작된 직후였음을 의미한다. %CPU 계산은 (프로세스 CPU 시간) / (프로세스 경과 시간)인데, 경과 시간이 0.01초 수준이면 분모가 작아 100을 쉽게 찍는다. 프로세스 자체가 실제로 무거운지는 ELAPSED가 충분히 쌓인 후 재측정해야 판단 가능. 본 챕터에서는 이런 프로세스를 **"순간 snapshot artifact"**로 분류하고, 실 의심 프로세스와 구분한다.
1.6 CMP의 분산 실행 구조
본 환경의 CMP는 5노드 모두에서 동일 JAR를 실행하는 분산 구조다(§2.6에서 확인). 이 구조의 테스트 상 함의는 다음과 같다.
- 테스터가 CMP에 API를 던질 때, 어느 노드의 CMP 인스턴스가 요청을 받는지에 따라 동작이 달라질 수 있다
- 특정 노드의 CMP만 장애 상태에 빠져도 다른 노드 경유 시 정상 응답받을 수 있어 결함 재현이 어려워진다
- 5노드 인스턴스 간 상태 동기 메커니즘(Redis? DB? 또는 stateless?)이 테스트 설계의 변수가 된다
세부는 챕터 06(가상 자원 인벤토리)에서 다루고, 본 챕터에서는 분산 사실만 등록한다.
2. 정찰 명령과 출력 해석
본 절의 모든 출력은 2026-04-23 ~ 2026-04-24 걸쳐 5노드에서 수집. 수집 시점에 따른 개별 차이는 각 서브섹션에서 명시한다.
2.1 하드웨어 일관성 — 5노드 완전 동일 (lscpu + dmidecode)
CPU 모델과 메인보드를 5노드 비교한 결과.
######## [5노드 공통] CPU ########
Architecture: x86_64
Model name: AMD Ryzen 7 8700G w/ Radeon 780M Graphics
CPU(s): 16
Thread(s) per core: 2
Core(s) per socket: 8
Socket(s): 1
CPU max MHz: 5177.3589
CPU min MHz: 422.6420
Virtualization: AMD-V
######## [5노드 공통] DMI ########
manufacturer: Gigabyte Technology Co., Ltd.
product: B850 AORUS ELITE WIFI7
bios-version: F6
bios-date: 07/16/2025매트릭스 (5노드별 수집):
| 항목 | nd01 | nd02 | nd03 | nd04 | nd05 |
|---|---|---|---|---|---|
| CPU 모델 | AMD Ryzen 7 8700G | 동일 | 동일 | 동일 | 동일 |
| CPU 개수 | 16 (8 core × 2 thread) | 동일 | 동일 | 동일 | 동일 |
| CPU 최대 MHz | 5177.3589 | 동일 | 동일 | 동일 | 동일 |
| 메인보드 | Gigabyte B850 AORUS ELITE WIFI7 | 동일 | 동일 | 동일 | 동일 |
| BIOS 버전 | F6 (2025-07-16) | 동일 | 동일 | 동일 | 동일 |
완벽한 H/W 일관성. 5노드가 동일 로트에서 동일 BIOS로 셋업되었음이 확실. 이 사실이 CMP 테스트에 주는 의미:
- 노드 간 성능 차이가 H/W에서 기인할 가능성이 0에 가깝다. 벤치마크 결과 차이가 있다면 소프트웨어 또는 부하 상태 차이에서 기인.
- 특정 CPU flag 기반 기능 테스트에 5노드 모두 동일 조건. 예: AMD-V, SVM 등 가상화 기능은 5노드 모두 제공.
- BIOS 업데이트는 5노드 일괄 작업 — 한 노드만 업데이트하면 환경 비일관성 발생. BIOS 작업은 본 테스트팀 범위 외이므로 운영팀에 일괄 적용을 위임.
2.2 메모리와 KSM — 노드별 사용량 편차
free -h 결과를 5노드 정리:
| 노드 | Total | Used | Free | Buff/Cache | Available | Swap |
|---|---|---|---|---|---|---|
| pve-nd01 | 30Gi | 8.8Gi | 13Gi | 8.9Gi | 21Gi | 0B |
| pve-nd02 | 30Gi | 6.8Gi | 16Gi | 7.8Gi | 23Gi | 0B |
| pve-nd03 | 30Gi | 15Gi | 2.2Gi | 13Gi | 14Gi | 0B |
| pve-nd04 | 30Gi | 19Gi | 2.7Gi | 8.6Gi | 10Gi | 0B |
| pve-nd05 | 30Gi | 11Gi | 19Gi | 719Mi | 19Gi | 0B |
KSM: 5노드 모두 run: 0, pages_sharing: 0. 비활성.
읽어내야 할 판독 여럿.
판독 1 — nd03·nd04의 실제 부하 집중: 메모리 관점에서 nd03(used 15Gi, available 14Gi)과 nd04(used 19Gi, available 10Gi)가 가장 많이 점유되어 있다. HA 자원 수(챕터 01 §2.8)와는 다른 그림이다. HA 자원 수는 nd01 2건, nd03 2건, nd04 1건, nd05 2건이지만 실제 메모리 부하는 nd03·nd04가 압도적이다. 이유: 큰 VM(100002 8GiB, 106 8GiB, 113 4GiB, 100020 4GiB 등 — §2.5 참조)이 이 두 노드에 배치되어 있기 때문. "HA 자원 수"와 "실제 부하"는 다른 지표라는 교훈. CMP에서 노드 선택 UI를 구현할 때 어느 지표를 기반으로 할지가 설계 결정 포인트.
판독 2 — nd05의 buff/cache 부족 (719Mi): 다른 노드가 7~13Gi의 buff/cache를 가진 것에 비해 1/10 수준. 원인은 uptime 단순 부족(챕터 01 §2.5의 4시간 uptime). 파일시스템 캐시가 누적되지 않은 상태. 시간 지나면 정상화. 비정상 신호 아님.
판독 3 — Swap 0: 5노드 모두 swap 파티션이 없다. 메모리 압박 시 OOM Killer가 즉시 발동한다. ZFS가 기본 파일시스템이라 메모리의 상당 부분을 ARC로 쓰는 환경에서 swap 부재는 의도된 설계다(ZFS는 swap과 상성이 나쁨). 단 VM 오버프로비저닝 시 OOM 발생 위험이 상대적으로 높아진다. 이 영향은 챕터 03(디스크·스토리지) 및 챕터 06(가상 자원 인벤토리)에서 메모리 오버커밋 정책과 함께 다룬다.
판독 4 — KSM 비활성 상태의 함의: ksmtuned는 물리 메모리의 80% 사용 시 자동 활성화되도록 Proxmox가 기본 설정한다. 본 환경은 아직 그 임계점에 도달하지 않음. 단 nd04는 63% 사용 중이라 임계점에 가까워지고 있다. CMP가 nd04에 VM을 추가 배치하면 KSM이 자동 켜지고, 그 시점부터 메모리 사용량 표시가 실측과 달라진다(공유 페이지를 어떻게 카운트할지에 따라). 이는 챕터 06에서 CMP의 메모리 사용량 표시 정합성 검증 시 반드시 고려할 변수.
2.3 NUMA — 5노드 모두 단일 NUMA 노드
######## [5노드 공통] NUMA ########
NUMA node(s): 1
NUMA node0 CPU(s): 0-15NUMA가 테스트 변수에 추가되지 않는다. 단일 소켓 데스크톱급 CPU(AMD Ryzen 7 8700G)의 결과. 이는 다음을 의미.
- VM vCPU pinning, 메모리 NUMA affinity 같은 고급 튜닝은 테스트 범위 밖
- 그럼에도 CMP가 VM 생성 시 NUMA 관련 파라미터를 UI에 노출한다면, 이를 설정해도 본 환경에서는 실질 효과가 없음
- 미래에 하드웨어 업그레이드로 멀티 소켓 환경이 되면 이 문제가 부활. 본 챕터는 그 전환 시점까지 유효
2.4 부하 베이스라인 (vmstat 1 5)
5초간 1초 간격 샘플. CPU 사용률 컬럼(us/sy/id/wa)만 요약.
| 노드 | us (user) | sy (system) | id (idle) | wa (iowait) | 관찰 |
|---|---|---|---|---|---|
| pve-nd01 | 0~1% | 0~1% | 96~99% | 0% | idle, iowait 없음 |
| pve-nd02 | 1~3% | 2~4% | 91~96% | 0% | sy 2~4% 지속 (다른 노드의 2~4배) |
| pve-nd03 | 0~1% | 0% | 99~100% | 0% | 가장 idle |
| pve-nd04 | 0~1% | 0~2% | 96~100% | 0% | iowait 최대 0% |
| pve-nd05 | 0% | 0% | 99~100% | 0~1% | iowait 1초 발생 (정상 변동) |
nd02의 sy 2~4% 지속이 눈에 띈다. sy는 커널 모드 CPU 시간 — 시스템 콜, 인터럽트 처리, 컨텍스트 스위치 등. VM 112의 61.6% CPU가 대부분 유저 모드로 동작할 텐데도 커널 모드 비중이 이상하게 높은 것은, VM 112의 워크로드가 시스템 콜을 빈번하게 유발하는 타입(I/O bound, 스레드 대량 생성 등)임을 시사. 원인 식별은 §2.5에서 완결.
2.5 CPU 점유 프로세스 해부 — 5노드 각각 (ps --sort=-pcpu)
이 데이터가 본 챕터에서 가장 풍부한 통찰을 담고 있다. 5노드 각각의 최상위 프로세스를 표로 정리.
nd01 상위 프로세스
| PID | %CPU | %MEM | ELAPSED | CMD 핵심 |
|---|---|---|---|---|
| 3352014 | 6.9% | 1.7% | 3:51 | VM 102 (56-test-testerB-clone) — 방금 생성된 VM |
| 2502 | 6.5% | 6.3% | 34d 23h | VM 100 (100-PBS) — 34일 연속 |
| 3340548 | 3.3% | 1.7% | 16:33 | cmp.jar (CMP 분산 인스턴스) |
| 2441362 | 2.1% | 0.4% | 16h | pvestatd |
| 1543 | 1.5% | 0.5% | 34d 23h | corosync |
| 2196706 | 0.5% | 6.9% | 21h | VM 100002 (61-docker-registry) |
nd02 상위 프로세스 — 이 노드가 §0의 미스터리 해결의 핵심
| PID | %CPU | %MEM | ELAPSED | CMD 핵심 |
|---|---|---|---|---|
| 197526 | 61.6% | 0.1% | 3d 7h | VM 112 (112-test-vm) — 이게 nd02 부하의 정체 |
| 2728538 | 1.8% | 0.3% | 16h | pvestatd |
| 3534677 | 1.6% | 1.6% | 16:24 | cmp.jar |
| 258851 | 1.3% | 0.6% | 48d 23h | corosync |
| 337842 | 0.2% | 9.6% | 48d 17h | VM 700 (50-test-ubuntu) — 메모리 최대 점유 |
VM 112의 정체: -cpu qemu64,+aes,enforce,... + 2 vCPU + 2048 MiB + local zvol. 3일 7시간 연속 61.6% 점유. 챕터 00 §2.7부터 추적한 nd02 load 0.74의 단일 원인이 확정되었다. VM 112 내부에 비정상 상태의 워크로드(무한 루프, 방치된 stress 테스트, 또는 의도한 부하 생성 도구)가 있다.
왜 HA로 관리되지 않는가: VM 112의 디스크가 local zvol(/dev/zvol/rpool/data/vm-112-*). Shared storage가 아니라 마이그레이션 불가 → HA 부적합. 의도된 로컬 스토리지 VM.
처분 결정: VM 112 작성자 미상. "억지로 지울 수 없음"이 사용자 판단(L2 × R3 격자 — 작성자 미상이면 데이터 손실 리스크 불명). 챕터 06(가상 자원 인벤토리)에서 모든 미상 자원의 일괄 확인·합의 프로세스의 일부로 처리. 본 챕터는 원인 식별 완료, 처분 보류 상태로 등록.
nd03 상위 프로세스
| PID | %CPU | %MEM | ELAPSED | CMD 핵심 |
|---|---|---|---|---|
| 2690073 | 100% | 0.0% | 0초 | 순간 snapshot artifact (§1.5 참조 — python3 /sbin/ifquery -a -c -o json) |
| 1839582 | 2.5% | 0.4% | 16h | pvestatd |
| 218973 | 1.4% | 0.6% | 48d 23h | corosync |
| 2675954 | 1.2% | 1.2% | 16:15 | cmp.jar |
| 129443 | 1.2% | 5.3% | 7d 19h | VM 802 (802-test-tmp, migrate 상태) |
| 3306912 | 0.7% | 10.0% | 3d 15h | VM 100010 (64-HAProxy01) |
ifquery 100% 건은 §1.5에서 다룬 순간 artifact. 실제 부하 원인 아님. 단 ifquery가 호출된 이유는 흥미롭다 — PVE가 network 설정 검증 시 주기적으로 이를 호출한다. 5노드 중 nd03에서만 샘플링 순간에 걸렸을 뿐이며, 다른 노드에서도 같은 주기로 실행된다. 챕터 05(네트워크)에서 이 호출 주기가 챕터 00 §2.3 ring1+storage 충돌 위험과 어떤 관계에 있는지 검토.
VM 802의 명령줄 끝에 -incoming unix:/run/qemu-server/802.migrate -S가 붙어있다. 이 VM은 마이그레이션 대상 상태로 7일 19시간 정지 중. 누군가 마이그레이션을 시작했다가 중단하고 방치한 상태다. 챕터 06 추적 대상.
nd04 상위 프로세스
| PID | %CPU | %MEM | ELAPSED | CMD 핵심 |
|---|---|---|---|---|
| 3258357 | 9.7% | 13.0% | 2d 17h | VM 113 (52-monitoring) — nd04 메모리 최대 |
| 926243 | 2.0% | 0.3% | 16h | pvestatd |
| 1468 | 1.6% | 0.5% | 17d | corosync |
| 2491431 | 1.3% | 26.3% | 3d 15h | VM 106 (58-CICD) — nd04 메모리 최대 |
| 1707946 | 1.1% | 1.1% | 16:06 | cmp.jar |
| 2697880 | 0.7% | 12.5% | 3d 9h | VM 100020 (67-Prom01) |
VM 106이 단일 VM으로 노드 메모리의 26.3% (약 7.9Gi) 사용. 챕터 01 §2.8에서 확인된 HA 자원 vm:106 (started)이 여기. nd04의 메모리 압박은 이 VM 하나가 주원인.
nd05 상위 프로세스
| PID | %CPU | %MEM | ELAPSED | CMD 핵심 |
|---|---|---|---|---|
| 277340 | 2.8% | 0.4% | 16h | pvestatd |
| 250500 | 2.5% | 11.1% | 17h | VM 10031001 (73-Grafana01) |
| 197137 | 1.8% | 3.3% | 17h | VM 9502 (9502-test-vm) |
| 1722 | 1.5% | 0.5% | 21h | corosync |
| 1129437 | 1.3% | 1.2% | 15:57 | cmp.jar |
최근 reboot(챕터 01 §7)로 ELAPSED가 모두 짧음. 비정상 점유 프로세스 없음. 정상 복귀.
CPU 점유 분석 — cmp.jar의 위치
5노드 모두 cmp.jar가 %CPU 상위 10위 안에 존재. 특히 흥미로운 건 ELAPSED가 15~16분으로 5노드 모두 비슷하다는 점. 이는 약 16분 전 누군가 CMP 서버를 5노드 일괄 재시작했음을 시사. 테스터의 설정 변경 반영 또는 자동화의 흔적. 챕터 06에서 CMP 재시작 절차가 어떻게 설계되어 있는지 확인.
VM 112의 부하 증명 — 5노드 맥락에서
nd02 VM 112의 61.6% CPU는 다른 노드의 어떤 VM도 보이지 않는 수준이다. 비교:
| VM | 노드 | %CPU | 상태 평가 |
|---|---|---|---|
| VM 112 | nd02 | 61.6% | 이상. 3일 연속 60% 초과 |
| VM 113 | nd04 | 9.7% | 정상 운영 수준 |
| VM 100 (PBS) | nd01 | 6.5% | 34일 연속이지만 PBS는 부하 타입이 다름 |
| VM 102 | nd01 | 6.9% | 방금 생성됨(3:51), 부팅 중일 수 있음 |
| 기타 모든 VM | <5% | 정상 |
VM 112는 명백한 이상치. 다른 어떤 VM도 이 수준의 지속 부하를 내지 않는다. 챕터 06 인계.
2.6 CMP의 5노드 분산 구조 확인
5노드 top CPU에서 동일 패턴:
java -jar /CmpData/apps/cmp/libs/cmp.jar --spring.profiles.active=prd5노드에서 모두 관찰됨 + 동일 경로(/CmpData/apps/cmp/libs/cmp.jar) + 동일 프로파일(prd). 추가 확인:
- 포트 18080: 사용자 인지. PVE 8006과 분리되어 서비스 평면이 설계상 격리됨.
- 5노드 동일 코드 실행: HA 관리 대상 아님(
ha-manager status에 CMP 관련 없음 — 챕터 01 §2.8). 각 노드의 systemd 또는 수동 기동으로 독립 운영. prd프로파일이 테스트 환경에서 사용: 개발 후기 단계 통합 검증 단계이거나, 프로파일 명명이 개발팀 관행(예:prd를 "파이프라인 마지막 단계" 의미로 사용)일 가능성. 본 챕터에서는 사실만 등록하고, 챕터 06에서 CMP 기동 설정 파일(application-prd.yml?) 확인.
이 발견은 챕터 00부터 "CMP 호스트 위치 미상"으로 남아있던 항목을 해소한다. CMP는 단일 호스트가 아니라 5노드 모두에 분산된 동일 인스턴스. 테스터가 던지는 API는 5개 인스턴스 중 하나로 라우팅된다(라우팅 메커니즘은 챕터 05 네트워크에서 추적).
이 분산 구조가 테스트에 주는 의미:
- 요청 라우팅 비결정성: 같은 API를 두 번 던졌을 때 다른 인스턴스가 처리할 수 있다. 결함 재현이 "무작위"로 보일 수 있다.
- 인스턴스 간 상태 공유 메커니즘 확인 필요: 5개 JVM이 각자 메모리를 갖는데, 공통 상태는 외부 DB/Redis/pmxcfs를 통하는가? 챕터 06에서 확인.
- 단일 노드 장애 시 CMP의 가용성: 1/5 인스턴스 다운이 서비스에 영향을 주는지. 이는 STN 시나리오의 핵심 검증 항목.
2.7 시간 동기화 — 5노드 NTP reference 산개
chronyc tracking 5노드 비교:
| 노드 | Reference ID | Reference IP/Host | Stratum | Last offset | RMS offset |
|---|---|---|---|---|---|
| pve-nd01 | AABBCCDD | ntp-kr-1.example.net | 3 | -239 μs | 302 μs |
| pve-nd02 | CCDDEEFF | ntp-external-1.example.net | 4 | +13 μs | 202 μs |
| pve-nd03 | AABBCCDD | ntp-kr-1.example.net | 3 | +184 μs | 312 μs |
| pve-nd04 | CCDDEEFF | ntp-external-1.example.net | 4 | -99 μs | 208 μs |
| pve-nd05 | EEFF0011 | ipv4.ntp3.example.com | 3 | +236 μs | 480 μs |
3개 다른 NTP 서버를 보고 있다:
ntp-kr-1.example.net(stratum 3) — nd01, nd03 (국내 IP 대역으로 추정)ntp-external-1.example.net(stratum 4) — nd02, nd04 (해외 IP로 추정)ipv4.ntp3.example.com(stratum 3) — nd05 (도메인 기반 외부 NTP)
chronyc sources -v 5노드 모두에서 공통 후보로 등장하는 서버: mail.example-corp.com(nd01, nd02, nd03의 source 목록). 이 서버가 모든 노드의 후보에는 있으나 best source로는 선택되지 않은 서버.
현재 시계 정확도는 모두 우수(최대 500μs 이하 오차). 문제 없는 수준. 그러나 다음 시나리오에서 문제 발생 가능:
| 시나리오 | 영향 |
|---|---|
| 외부 NTP 서버 하나가 다운 | 그 서버를 보는 노드 2~3개가 동시에 재동기화 시도, 다른 서버로 fallback |
| 외부 네트워크 단절 | 5노드 모두 시계가 각자 drift 시작, 차이 누적 |
| 2026-04-23 이후 3개 서버 중 하나가 stratum 증가 | 후보 서버 순위 변동, 일부 노드가 다른 서버로 자동 전환 |
각 시나리오에서 5노드의 시계가 서로 다른 방향으로 drift 가능. 로그 시계열 비교(챕터 07)에 직접 영향. 특히 STN(시나리오 통합 테스트) 중 외부망이 끊기면 사고 원인 분석이 무너진다.
권장 정비(운영팀 인계): 사내 NTP 서버 1대 도입 후 5노드 모두 이를 1순위 참조하게 설정. 사내 서버가 외부 stratum-2 서버를 참조. 이 구조가 본 환경에 가장 적합. 본 테스트팀 범위 밖이므로 운영팀에 권고.
2.8 부팅 이력 분석 — 5노드 last reboot + journalctl --list-boots
5노드 부팅 이력 매트릭스.
nd01 — 2 reboot
still running: 2026-03-20T09:23:37 (현재 세션)
before: 2026-03-05T15:24:57 (crash)
before: 2026-03-05T15:05:49 → 15:12:50 (7분 세션)3/5에 셋업 직후 7분 가동, graceful shutdown 없이 종료, 다시 부팅하여 15일 가동 후 3/20에 다시 재부팅. 현재 세션은 34일째.
nd02 — 1 reboot (셋업 직후 단 한 번)
still running: 2026-03-05T15:39:37 (현재 세션, 49일째)
before: 2026-03-05T15:23:13 → 15:23:36 (23초 세션)셋업 직후 23초만 돌고 재부팅한 이후 49일간 무재부팅. 본 클러스터에서 가장 오래된 uptime.
nd03 — 1 reboot (셋업 직후 단 한 번, journalctl --list-boots에 기록)
still running: 2026-03-05T15:41:19 (현재 세션, 49일째)
before: 2026-03-05T15:28:05 (crash)journalctl --list-boots는 2개 부팅 기록만 보임. nd02와 동일하게 셋업 직후 1회, 그 후 49일 무재부팅. 커널 패치 한 번도 안 받은 상태.
nd04 — 3 reboot
still running: 2026-04-07T08:41:54 (현재 세션, 16일째)
before: 2026-03-05T15:22:28 → 2026-04-06T20:05:24 (32일 세션)
before: 2026-03-05T15:10:12 → 15:11:00 (48초 세션)4/7 reboot은 정확히 4/6 20:05에 graceful shutdown 후 다음날 아침 기동. 계획된 재부팅.
nd05 — 10+ reboot (압도적으로 많음)
still running: 2026-04-23T11:18:33 (다비의 의도된 reboot)
before: 2026-04-17T11:03:30 → 2026-04-23T11:15:24 (6일)
before: 2026-04-17T10:02:17 (crash)
before: 2026-04-16T14:47:46 (crash)
before: 2026-04-16T10:04:15 (crash)
journalctl --list-boots: 10개 부팅 기록 (4/15~4/23)단기간 반복 reboot 패턴. 4/15~4/17 3일간 6회 부팅, crash 3회. 이는 평소 기준으로 보면 즉시 중단 신호에 해당한다.
crash 태그의 재해석 (§1.4 참조)
사용자 인지: 테스트 팀 합류(2026-04-20) 이전 시점. 4/15~4/17은 개발팀이 HA 페일오버 시험을 위해 의도적으로 강제 종료한 것. 과장님이 4/23 다비의 nd05 실수 reboot을 격려하며 "그런 테스트도 계속 진행해봐야 한다"고 발언한 맥락과 일치.
따라서 nd05의 4/15~4/17 crash 3건은 실제 장애가 아니라 의도된 HA 페일오버 시험의 흔적. §1.4의 원칙 적용: 로그 태그는 환경 컨텍스트 없이는 자동 해석하지 않는다.
핸드북 원칙 박제: 본 환경에서는 crash 태그를 자동으로 의심하지 않는다. 단 다음 경우에는 여전히 의심 신호로 처리.
- 테스트 팀 합류 이후(2026-04-20+) 발생한
crash: 개발팀 시험 시점이 아니므로 의도 검증 필요 - 하루 3회 이상
crash가 연속 발생: HA 페일오버 시험은 보통 간격을 두고 수행 crash후 재부팅이 5분 이내에 바로 이어짐: 자동 재기동 패턴으로 watchdog 등이 작동한 신호
이 3가지 보조 조건을 §3 의심 패턴에 반영.
부팅 이력 요약 — 클러스터 안정성 평가
| 노드 | 현재 uptime | 총 부팅 수 (wtmpdb) | 평가 |
|---|---|---|---|
| nd01 | 34일 | 3 | 안정 |
| nd02 | 49일 | 2 | 장기 무재부팅 — 커널 미패치 |
| nd03 | 49일 | 2 | 장기 무재부팅 — 커널 미패치 |
| nd04 | 16일 | 3 | 안정 |
| nd05 | 4시간 | 10+ | 의도된 반복 reboot (HA 시험) |
nd02와 nd03은 49일간 무재부팅 상태. 현재 커널 6.17.2-1-pve이며, 이 커널 이후 출시된 보안 패치가 누적되어 있을 가능성. CVE 노출 여부 평가 필요. 챕터 08 (위험 매트릭스) 인계.
2.9 PVE 패키지 버전 일관성
5노드 모두 동일.
proxmox-ve: 9.1.0 (running kernel: 6.17.2-1-pve)
pve-manager: 9.1.1
proxmox-kernel-helper: 9.0.4
proxmox-kernel-6.17.2-1-pve-signed: 6.17.2-1
pve-qemu-kvm: 10.1.2-3
libpve-cluster-perl: 9.0.7
amd64-microcode: 3.20250311.15노드 완전 일치. CMP 테스트 중 버전 차이로 인한 비일관성 가능성 0. 이 상태를 유지해야 한다. 단일 노드 업데이트(예: apt install)를 절대 금지하는 원칙을 챕터 08에 박는다.
2.10 시스템 파티션 사용량
| 노드 | / (Root) | /var/lib/vz | /var/log | 평가 |
|---|---|---|---|---|
| pve-nd01 | 5.3G/199G (3%) | 26G/218G (12%) | 위와 동일 | 여유 충분 |
| pve-nd02 | 4.1G/219G (2%) | 31M/215G (1%) | 위와 동일 | local storage 거의 미사용 |
| pve-nd03 | 8.1G/209G (4%) | 6.8G/207G (4%) | 위와 동일 | |
| pve-nd04 | 12G/208G (6%) | 16G/212G (8%) | 위와 동일 | |
| pve-nd05 | 4.5G/211G (3%) | 2.4G/209G (2%) | 위와 동일 |
모든 노드 root/vz 여유 충분. 단기간 내 디스크 풀 우려 없음. 챕터 03(디스크)에서 본격 다룸.
2.11 크론과 systemd 타이머 — 노드별 자동 작업 분포
5노드 /etc/crontab + /etc/cron.d/ 완전 동일. 시스템 기본 작업만 있음(run-parts via anacron).
/etc/cron.d/:
e2scrub_all(ext4 정기 정합성 검사)vzdump(VM 백업)zfsutils-linux(ZFS 유지보수)
systemd list-timers: 5노드 모두 10개 타이머 active. 모두 시스템 기본 타이머. 사용자 정의 타이머 0개.
판독: 테스터가 만든 정기 작업이 시스템 수준에는 없다. CMP 또는 VM 내부의 작업은 별개. 본 챕터 범위에서는 노드 OS 수준의 cron/timer는 5노드 완전 동일하며 특이 사항 없음.
3. 출력의 비정상 패턴과 조기 경보
3.1 정상 패턴 — 본 환경의 베이스라인
다음이 모두 만족되면 노드 수준 정상.
[정상 1] load average 1/5/15분 모두 <1.5 (16 CPU 노드 기준)
[정상 2] vmstat의 `id` 90% 이상 (VM 부하에 따라 변동 허용)
[정상 3] %MEM × VM 수의 합이 호스트 메모리의 80% 미만 (KSM 자동 활성화 임계)
[정상 4] dmesg에 error/warn 없음 (또는 알려진 무해 경고만)
[정상 5] journalctl --list-boots가 직전 1개월간 예상된 reboot 이벤트와 일치
[정상 6] chrony Last offset | <5000 μs (5 ms)
[정상 7] systemctl is-active corosync pve-cluster pvedaemon pveproxy pvestatd 모두 active3.2 의심 패턴
| # | 의심 출력 | 추정 원인 | 즉시 확인 |
|---|---|---|---|
| 1 | load average 1분 평균 > 5m 평균의 2배 | 갑작스런 부하 증가 | ps --sort=-pcpu 상위 10 |
| 2 | 특정 VM의 %CPU가 3일 이상 50% 초과 지속 | VM 112 사례. 내부 비정상 워크로드 또는 방치된 stress 도구 | VM 작성자 식별, 내부 프로세스 점검 |
| 3 | vmstat wa 컬럼이 20% 초과 지속 | I/O 병목 | iostat, zpool iostat으로 원인 디스크 식별 |
| 4 | 호스트 메모리 available < 10% | 메모리 압박, OOM 리스크 | 큰 VM 식별 후 이동/정지 |
| 5 | KSM pages_sharing > 0 관찰됨 | 메모리 압박으로 KSM 자동 활성화됨 | 메모리 사용 패턴 변화 추적 |
| 6 | chrony Last offset > 10,000 μs (10 ms) | NTP 동기화 실패 또는 drift | 상위 NTP 서버 접근성 확인 |
| 7 | chrony Reference가 노드마다 제각각 (현재 상태) | 외부 NTP 의존 + 사내 NTP 부재 | 본 환경 현상태. 운영팀 권고 |
| 8 | last reboot에서 테스트 팀 합류 이후 crash 연속 3회 | 실제 장애 (개발팀 시험 시점 아님) | dmesg에서 패닉/OOM 흔적, 하드웨어 SMART |
| 9 | 노드 uptime이 클러스터 평균의 1/10 미만 | 반복 재부팅 중 | journalctl --list-boots 기록, 각 부팅 사이클 로그 조사 |
| 10 | cmp.jar 프로세스가 특정 노드에만 없음 | 해당 노드 CMP 인스턴스 장애 | 그 노드로 던지는 CMP API만 실패 |
3.3 즉시 중단 신호
다음 패턴은 자기 테스트를 즉시 중단하고 책임자에게 보고한다.
신호 A: OOM Killer 활성 흔적
journalctl --since '1 hour ago' | grep -iE 'oom-killer|out of memory'이 grep에 결과가 있으면 커널이 메모리 부족으로 프로세스를 강제 종료한 상태. 특정 VM이 이미 죽었을 수 있으며, 현재 테스트의 상태가 신뢰할 수 없다.
신호 B: 디스크 풀 임박
df -h / /var/lib/vz | awk 'NR>1 && $5+0 > 90'/ 또는 /var/lib/vz 사용률 90% 초과 시 출력. 이 시점에 PVE는 쓰기 실패 가능 상태. pmxcfs가 read-only 전환, 클러스터 전체 영향.
신호 C: 커널 패닉 / Crash 반복
last reboot -n 10 --time-format iso | grep -c crash최근 10회 부팅 중 crash 3회 이상 + 테스트 팀 합류 이후 시점 + reboot 간격 1시간 이내 → 실제 하드웨어 장애 가능성.
4. 이 영역의 CMP 테스트 대분류와 시나리오
본 영역(노드 정찰)이 직접적으로 검증할 수 있는 CMP 테스트 시나리오.
4.1 CRUD 기능 검증
시나리오 4.1.1 — 노드 정보 조회 API의 정합성
CMP UI에서 표시하는 노드 정보가 PVE 실제 상태와 일치하는지.
- 검증 진입점:
pvesh get /nodes/{node}/status - 사전 정찰: §2.1 (H/W 스펙)
- 검증 항목:
- CPU 모델, 코어 수
- 총 메모리, available 메모리
- uptime
- load average
시나리오 4.1.2 — 노드별 VM 통계의 정합성
노드당 running VM 수, 총 vCPU 할당, 총 메모리 할당이 CMP와 PVE에서 일치하는가.
- 검증:
qm list결과 vs CMP 노드 상세 화면 - 사전 정찰: §2.5 (CPU 점유 프로세스로 VM 식별)
- 특이 케이스: VM 112처럼 비정상 점유 VM도 목록에 포함되는가 (그래야 정상)
4.2 스테이징 워크플로우
본 환경의 CMP는 노드 수준 스테이징 기능 없음(PVE 껍데기 성격). 해당 시나리오 없음.
4.3 위험 시나리오·에러 처리
시나리오 4.3.1 — 노드 과부하 상태에서의 VM 생성
nd02처럼 이미 특정 VM이 60% CPU를 점유한 상태에서 추가 VM 생성 요청. CMP가 부하 상태를 인지하고 대안 노드를 제안하는지.
- 사전 정찰: §2.4, §2.5
- 기대 동작: 부하 낮은 노드(nd03 또는 nd05) 자동 제안
- 결함 시나리오: 무조건 요청 노드에 생성 시도, nd02의 기존 VM 성능 저하 유발
시나리오 4.3.2 — 메모리 부족 노드에 VM 배치 시도
nd04(available 10Gi)에 메모리 16Gi VM 생성 요청. 거부되어야 한다.
- 사전 정찰: §2.2
- 기대 동작: 명확한 에러 (메모리 부족)
- 결함 시나리오: 생성은 시작하고 실제 부팅 시 OOM 발생
시나리오 4.3.3 — CMP 인스턴스 일부 다운 상태에서의 API 호출
5노드 중 1노드의 CMP만 정지시킨 상태에서 API 호출. 요청 라우팅이 자동 fallback 하는가.
- 사전 정찰: §2.6 (CMP 분산 구조 확인)
- 기대 동작: 다른 4개 인스턴스로 라우팅, 무중단
- 결함 시나리오: 특정 노드의 CMP로 고정 라우팅되어 timeout
4.4 클러스터 일관성
시나리오 4.4.1 — 노드 부하 표시의 5노드 실시간 일관성
CMP가 표시하는 노드 load average가 5노드 uptime 명령과 일치하는가. 특히 nd02의 비정상 부하가 즉시 보이는가.
- 사전 정찰: §2.4
- 검증: CMP UI와 5노드
uptime동시 캡처, 각 값의 차이 < 1분
시나리오 4.4.2 — CMP 인스턴스 간 상태 동기화
nd01 CMP에서 수행한 변경이 nd02 CMP에서 조회 시 즉시 반영되는가. 만약 두 인스턴스가 외부 DB를 공유하지 않고 독립 상태라면, "동기화 시간"을 측정.
- 사전 정찰: §2.6
- 관련 메커니즘: 챕터 06에서 확인 필요
5. 정찰 ↔ 테스트 단계 역방향 매핑
다른 챕터의 테스트가 본 영역의 정찰에 의존하는 케이스.
| 수행하려는 테스트 액션 | 선행 정찰 (본 챕터) | 추가 선행 정찰 |
|---|---|---|
| VM 생성 (챕터 06) | §2.2 목표 노드 메모리 여유 | 챕터 04 storage 여유 |
| VM 마이그레이션 (챕터 06) | §2.5 Source/Target 노드 부하 | 챕터 01 정족수 |
| VM 부하 생성 테스트 (챕터 06) | §2.4 현재 load 베이스라인 | — |
| 노드 reboot (챕터 02) | §2.8 직전 reboot 이력 | 챕터 01 정족수 |
| 로그 시계열 비교 (챕터 07) | §2.7 chrony 동기 상태 | — |
| CMP 부하 테스트 | §2.6 CMP 5노드 분산 상태 | 챕터 05 라우팅 |
6. 정찰 결과를 산출물로 정리하는 양식
본 챕터 결과는 다음 산출물로 정리.
6.1 산출물 — 노드 베이스라인 카드 (매주 갱신)
# 노드 베이스라인 카드 — YYYY-MM-DD HH:MM
## 5노드 H/W 스펙 (변동 시에만 갱신)
(5노드 동일 — AMD Ryzen 7 8700G 16 CPU 30 GiB ...)
## 5노드 실시간 부하 (수집 시점 HH:MM)
| 노드 | load (1m) | %Mem used | HA 자원 | cmp.jar elapsed | 상위 1 CPU 프로세스 |
| ---- | --------- | --------- | ------- | --------------- | ------------------- |
| ... |
## 5노드 시간 동기화
| 노드 | NTP ref | Last offset | 동기 상태 |
## 최근 24시간 부팅/종료 이벤트
- 있으면 나열
## 이상 프로세스 (3일 연속 50%+)
- VM 112 (nd02) — 처분 보류
## 잔여 정비 / 추적
- (해당 항목)6.2 산출물 — 노드 이상 상태 보고서 (이상 식별 시)
# 노드 이상 보고서 — YYYY-MM-DD HH:MM
## 이상 트리거
- (§3.2 또는 §3.3의 어느 패턴)
## 확인된 사실
- (수집 명령 출력)
## 영향 범위
- 영향받은 노드/VM/자원
## 처분 방안 제안
- (격자 L×R 평가 포함)
## 작성자 동의 필요 사항
- (R2+ 작업의 경우)7. 본 챕터에서 발견된 잔여 정비·추적 항목
| # | 발견 항목 | 인계 챕터 | 우선순위 | 상태 |
|---|---|---|---|---|
| 1 | VM 112 (nd02, 3일 연속 61.6% CPU) — 작성자 미상 | 챕터 06 | P1 — 확인 필요 | 원인 식별 완료, 처분 보류 |
| 2 | VM 802 (nd03, 마이그레이션 중단 상태로 7일 방치) | 챕터 06 | P2 | 챕터 06에서 추적 |
| 3 | nd02·nd03 49일 무재부팅 (커널 패치 미적용) | 챕터 08 | P1 | 위험 매트릭스 항목 |
| 4 | chrony 5노드 reference 3개 서버로 산개 | 운영팀 인계 | P2 | 사내 NTP 도입 권고 |
| 5 | CMP 5노드 분산 구조 + prd 프로파일 사용 의도 | 챕터 06 | P2 | 기동 설정 확인 필요 |
| 6 | CMP 인스턴스 약 16분 전 일괄 재시작 흔적 | 챕터 06 | P3 | 재시작 절차 확인 |
| 7 | nd04 메모리 63% 사용 (KSM 자동 활성화 임계 근접) | 챕터 06 | P2 | KSM 활성화 시점 모니터링 |
| 8 | CMP /CmpData/apps/cmp/libs/cmp.jar 5노드 동일 경로 | 챕터 06 | P3 | CMP 배포 구조 확인 |
| 9 | 외부 NTP 3개 서버 산개 | 챕터 00 §8.4 이미 등록 | — | 중복 등록, 사실 확정 완료 |
7.1 VM 112 취급 원칙
본 챕터 §2.5에서 VM 112 원인 식별 완료. 다음 원칙을 적용한다.
- 처분 절대 금지 (현 시점): 작성자 미상 상태에서 삭제는 L2 × R3 격자. 사용자 합의 없는 정리 금지.
- 지속 관찰 대상 등록: 매주 §6.1 베이스라인 카드에 VM 112 상태 기록. CPU %가 급변하면 즉시 챕터 06 추적 트리거.
- 챕터 06에서 일괄 합의: 자원 인벤토리 작성 시 "미상 자원" 리스트의 최상위에 VM 112를 둠. 5명 테스터 + 개발팀 합의 절차로 처리.
- CMP 테스트 시 주의: VM 112가 점유한 nd02에 테스트 VM을 추가 배치하지 않음. nd02는 당분간 "포화 노드"로 간주.
부록 A. 명령 치트 시트
# === 30초 내 노드 1차 체크 (5노드 일괄) ===
NODES="pve-nd01 pve-nd02 pve-nd03 pve-nd04 pve-nd05"
for n in $NODES; do
echo "--- [$n] ---"
ssh "$n" "uptime; free -h | grep Mem; ps -eo pcpu --sort=-pcpu --no-headers | head -1"
done
# === nd02 같은 의심 노드 딥다이브 ===
ssh pve-nd02 "ps -eo pid,user,pcpu,pmem,etime,cmd --sort=-pcpu | head -5"
# === 5노드 chrony 정렬 상태 ===
for n in $NODES; do
echo -n "$n: "
ssh "$n" "chronyc tracking | grep -E 'Reference ID|Last offset' | tr '\n' ' '"
echo ""
done
# === 5노드 cmp.jar 상태 ===
for n in $NODES; do
ssh "$n" "pgrep -af cmp.jar | head -1"
done
# === VM 112 점유 시간 추이 관찰 ===
ssh pve-nd02 "while :; do date; ps -p 197526 -o %cpu,etime,cmd --no-headers; sleep 60; done"부록 B. 다음 챕터로의 인계
| 본 챕터 발견 | 챕터 03 (디스크) 처리 |
|---|---|
| Swap 0 + ZFS ARC 고려 | ARC 크기 모니터링 전략 |
| nd04 메모리 압박 | 디스크 I/O와 메모리 연관 분석 |
| 본 챕터 발견 | 챕터 04 (스토리지) 처리 |
|---|---|
| VM 112 local zvol 디스크 | Local storage의 마이그레이션 제약 |
| VM 802 마이그레이션 중단 | 마이그레이션 실패 시 정리 절차 |
| 본 챕터 발견 | 챕터 05 (네트워크) 처리 |
|---|---|
| CMP 5노드 분산, 포트 18080 | 요청 라우팅 메커니즘 확인 |
| nd03 ifquery 샘플 | 네트워크 검증 주기 |
| 본 챕터 발견 | 챕터 06 (가상 자원) 처리 |
|---|---|
| VM 112 (미상, 부하 이상) | 최우선 조사 대상 |
| VM 802 (마이그레이션 중단) | 정리 |
CMP prd 프로파일 | 기동 설정 확인 |
| cmp.jar 일괄 재시작 흔적 | 배포/재시작 절차 |
| 본 챕터 발견 | 챕터 07 (로그) 처리 |
|---|---|
| chrony 3 reference 산개 | 로그 시계열 상관 분석 시 주의 |
| wtmpdb crash 태그 컨텍스트 해석 | 로그 태그 해석 원칙 |
| 본 챕터 발견 | 챕터 08 (위험 매트릭스) 처리 |
|---|---|
| nd02·nd03 49일 무재부팅 | 커널 패치 적용 위험 |
| VM 112 처분 보류 원칙 | 미상 자원 일반 취급 |
부록 C. 참고 자료
| 주제 | URL |
|---|---|
| AMD Ryzen 7 8700G 스펙 | https://www.amd.com/en/products/processors/desktops/ryzen/8000-series/amd-ryzen-7-8700g.html |
| Linux Load Average | https://www.brendangregg.com/blog/2017-08-08/linux-load-averages.html |
| KSM (Kernel Samepage Merging) | https://pve.proxmox.com/wiki/Memory_deduplication |
| chrony | https://chrony-project.org/documentation.html |
| wtmpdb (Debian Trixie) | https://github.com/thkukuk/wtmpdb |
| Proxmox NUMA | https://pve.proxmox.com/wiki/Manual:_qm.conf#_numa |
다음 챕터:
03-disk-reconnaissance.md— 5노드 physical disks, ZFS pool 구조, LVM, thin pool 사용률을 해부한다. 본 챕터에서 식별된 메모리 압박 및 swap 부재가 디스크 layer에서 어떻게 완화 또는 악화되는지 연결한다.