00. CMP Pre-Test Reconnaissance Handbook — 개요와 정찰 철학

0. 이 핸드북이 무엇인가

0.1 한 줄 정의

이 핸드북은 CMP(Cloud Management Platform) 테스트팀이 클러스터에 손대기 전에 환경을 읽어내고, 손댄 후에 환경을 복구하기 위한 정찰(Reconnaissance) 절차서다.

CMP 테스트의 본질은 두 가지 질문에 답하는 일이다.

CMP가 호출한 API가 Proxmox 클러스터의 실제 상태를 의도대로 변경했는가
그 변경이 다른 자원·다른 노드·다른 사용자에게 의도치 않은 부작용(Side Effect)을 만들지 않았는가

이 두 질문에 대답하려면 테스터는 변경 전 상태를 정확히 알고 있어야 한다. 알지 못한 채 테스트를 시작하면, 사고가 났을 때 그것이 CMP의 결함인지, 환경의 원래 상태인지, 다른 테스터의 작업 흔적인지 구별할 방법이 없다. 그 결과는 결함 보고서의 신뢰도 붕괴, 재현 시나리오 부재, 운영팀과의 책임 공방으로 이어진다.

본 핸드북은 그 사고 패턴을 사전에 차단하기 위한 도구다.

0.2 누구를 위한 책인가

다음 세 부류의 독자를 상정한다.

신규 테스터: 클러스터 환경에 처음 진입하여 어디부터 살펴봐야 할지 모르는 인원. 본 챕터부터 순서대로 정독하면 클러스터의 전반적 구조와 정찰 절차를 한 번에 익힐 수 있도록 구성한다.
반복 테스터: 매일 또는 매 테스트 사이클마다 환경 점검이 필요한 인원. 챕터 09(사전 점검 체크리스트)와 각 챕터의 §3(비정상 패턴) 위주로 운용한다.
사고 대응자: 클러스터에 이상이 발생했을 때 원인 추적이 필요한 인원. 챕터 07(로그 시스템 해부)을 진입점으로 삼고, 영역별 챕터의 §3을 참조한다.

0.3 이 핸드북이 다루지 않는 것

다음 영역은 의도적으로 본 핸드북의 범위에서 제외한다. 별도의 자료 또는 사내 문서로 다룬다.

CMP 자체의 내부 구현, 아키텍처, API 명세
Proxmox VE의 기본 운영(설치, 업그레이드, 일반적 운영 절차)
TrueNAS의 단독 운영
테스트 케이스의 작성 방법론과 결함 관리 프로세스

본 핸드북은 CMP와 Proxmox 클러스터의 경계면에서 일어나는 일, 그 중에서도 테스트 행위의 안전성과 재현성에 초점을 둔다.

1. 본 핸드북이 전제하는 환경

본 핸드북은 특정 클러스터를 대상으로 작성된 살아있는 문서다. 일반론이 아니라, 아래에 명시한 클러스터의 현재 모습을 기준으로 모든 정찰 절차와 위험 신호를 정의한다. 환경이 바뀌면 본문도 갱신되어야 한다.

1.1 5노드 Proxmox 클러스터 — `pve-cl01`

수집 시각(2026-04-23 15:24 KST) 기준으로 다음과 같은 구성이다.

항목	값
클러스터 이름	`pve-cl01`
Proxmox VE 버전	9.1.1 (커널 6.17.2-1-pve)
클러스터 설정 버전	5
노드 수	5
노드 이름	`pve-nd01`, `pve-nd02`, `pve-nd03`, `pve-nd04`, `pve-nd05`
Quorum	Quorate (3 / 5)
Corosync Transport	knet
Secure auth	on
Corosync Ring 수	2 (ring0, ring1) — `link_mode: passive`

pvecm status의 핵심 출력:

markdown

Cluster information
-------------------
Name:             pve-cl01
Config Version:   5
Transport:        knet
Secure auth:      on

Quorum information
------------------
Nodes:            5
Node ID:          0x00000005
Ring ID:          1.11b
Quorate:          Yes

Votequorum information
----------------------
Expected votes:   5
Highest expected: 5
Total votes:      5
Quorum:           3
Flags:            Quorate

Membership information
----------------------
    Nodeid      Votes Name
0x00000001          1 10.99.20.11
0x00000002          1 10.99.20.12
0x00000003          1 10.99.20.13
0x00000004          1 10.99.20.14
0x00000005          1 10.99.20.15 (local)

읽어내야 할 핵심:

모든 5노드가 quorate 상태다. 이 시점에 클러스터 자체는 정상이다.
**Membership에 표시되는 IP는 10.99.20.0/24**다. 이것이 corosync ring0가 사용하는 평면이다. 즉 노드의 관리(Management) IP가 아니라 클러스터 통신 전용 평면의 IP가 멤버십 식별자가 된다. 이 차이를 신입 테스터가 헷갈리는 경우가 잦다. 본 핸드북에서 노드를 지칭할 때는 가급적 노드명(pve-ndNN)을 쓰고, IP가 필요한 경우 어느 평면의 IP인지 명시한다.
**Ring ID 1.11b**는 클러스터 멤버십이 일정 횟수 재구성을 거쳤지만 현재 안정적으로 quorate임을 의미한다. Ring ID의 의미와 변천 추적은 챕터 01(클러스터 정찰)에서 다룬다.

1.2 IP 평면 분리 매트릭스

각 노드는 4개의 IP 평면을 갖는다. 5노드 모두에서 hostname -I로 수집한 결과:

markdown

=== pve-nd01 ===  10.99.20.11 10.99.10.11 10.99.40.11 10.99.30.11
=== pve-nd02 ===  10.99.20.12 10.99.10.12 10.99.40.12 10.99.30.12
=== pve-nd03 ===  10.99.20.13 10.99.10.13 10.99.40.13 10.99.30.13
=== pve-nd04 ===  10.99.20.14 10.99.10.14 10.99.40.14 10.99.30.14
=== pve-nd05 ===  10.99.20.15 10.99.10.15 10.99.40.15 10.99.30.15

5노드 모두 동일한 평면 구성을 가진다. 마지막 옥텟이 노드 번호와 일관되게 매핑된다(11~15). 이는 IP 할당 시 의도적으로 노드 번호를 인덱스로 사용했음을 의미하며, 인지 부담이 작은 잘 설계된 명명 규칙이다.

핸드북 표준 평면 매트릭스로 정리:

평면	대역	용도	출처
mgmt	`10.99.10.0/24`	Web UI(8006), SSH, CMP API 호출 진입점	`/etc/pve/.members`의 `ip` 필드
corosync0	`10.99.20.0/24`	클러스터 통신 ring0 (1순위)	`/etc/pve/corosync.conf`의 `ring0_addr`
corosync1	`10.99.30.0/24`	클러스터 통신 ring1 (백업) + storage	`/etc/pve/corosync.conf`의 `ring1_addr`
vm	`10.99.40.0/24`	VM 게스트 트래픽 + PBS	노드 H/W 인터페이스 인벤토리(추정)

여기에서 결정적 판독이 하나 나온다. corosync ring1이 사용하는 10.99.30.0/24 대역은 동시에 storage 트래픽이 흐르는 평면이다. /etc/pve/storage.cfg의 거의 모든 NFS/iSCSI 항목이 10.99.30.16 포털을 향하고 있다(§1.3 참조). 즉 ring1과 storage가 같은 L2 평면을 공유한다.

link_mode: passive 덕분에 평소에는 ring0만 활성이고 ring1은 idle 상태이므로 직접적인 충돌은 발생하지 않는다. 그러나 ring0가 어떤 이유로 다운되면 ring1이 즉시 활성화되며, 그 순간부터는 코로싱크 토큰이 NFS·iSCSI 대용량 트래픽 사이를 비집고 흘러야 한다. 이 상황에서는 corosync 토큰 타임아웃이 발생하기 쉽고, 결과는 잘못된 노드 fence 또는 정족수 손실로 이어질 수 있다.

이 위험은 **챕터 01(클러스터 정찰)과 챕터 05(네트워크 정찰)**에서 본격적으로 진단·완화 방안을 다룬다. 본 챕터에서는 "이런 위험이 환경에 내재해 있다"는 사실을 등록만 한다.

1.3 백엔드 인프라 분포 — TrueNAS·PBS·평면 매핑

/etc/pve/storage.cfg에서 외부 인프라의 위치가 드러난다. 단순히 IP만 나열하면 의미가 보이지 않으므로, 어느 평면을 통해 어느 인프라에 접근하는가를 매트릭스로 정리한다.

인프라	IP	평면	노출 서비스	비고
TrueNAS (관리)	`10.99.10.16`	mgmt	Web GUI, NFS(일부), CIFS	테스터의 GUI 접속 진입점
TrueNAS (데이터)	`10.99.30.16`	storage(=ring1)	iSCSI, NFS(주력)	모든 iSCSI와 대부분의 NFS 트래픽
Proxmox Backup Server	`10.99.40.100`	vm	PBS Datastore `pve-nd06-pbs`	VM 게스트 평면에 위치 — 의외성 있음

판독 1 — TrueNAS는 단일 어플라이언스이며 두 평면에 동시 노출된다. mgmt 평면(.10.16)으로는 Web GUI와 일부 NFS·CIFS, storage 평면(.30.16)으로는 iSCSI와 주력 NFS가 노출된다. 같은 머신이지만 서비스가 평면별로 다르게 배치되어 있다는 사실 자체가 NFS/iSCSI 트래픽 부하 분산 의도를 시사한다. 다만 일관성이 완전하지 않다 — 일부 NFS export(nfs-test-testerE, nfs-test-testerD)는 mgmt 평면을 통해 마운트되도록 설정되어 있어, 이들 NFS 트래픽이 mgmt 트래픽과 경합한다. 이 불일치는 챕터 04에서 본격 다룬다.

판독 2 — TrueNAS 내부 ZFS pool 이름은 pve-nd06-zfs로 추정된다. NFS export path가 모두 /mnt/pve-nd06-zfs/...로 시작하기 때문이다. 이 이름은 클러스터 노드 명명 규칙(pve-ndNN)과 형태가 유사하지만 nd06은 클러스터 멤버십에 존재하지 않는다(pvecm nodes에 없음). 즉 6번 노드가 따로 존재하는 것이 아니라 단순히 ZFS pool의 명명일 가능성이 높다. 정확한 사실은 TrueNAS 콘솔에서 확인이 필요하며, 본 챕터에서는 추정으로 표기한다.

판독 3 — PBS의 평면 위치가 의외다. 10.99.40.100은 VM 게스트 트래픽 평면이다. 백업 트래픽이 게스트 트래픽 평면을 공유한다면, VM 부하가 큰 시점에 백업 작업이 게스트 네트워크에 영향을 주거나 그 반대 영향을 받을 수 있다. 이 점은 챕터 04와 챕터 06(가상 자원 인벤토리)에서 백업 잡 일정과 대역폭 제한을 다룰 때 다시 짚는다.

판독 4 — 모든 백엔드 인프라가 단일 ZFS pool에 수렴한다. NFS, iSCSI, PBS의 datastore 모두가 결국 TrueNAS 내부의 동일 ZFS pool을 기반으로 한다(추정). 이는 단일 장애점(Single Point of Failure)이며, ZFS pool에 문제가 생기면 클러스터의 모든 외부 스토리지가 동시에 영향을 받는다. 챕터 04에서 이 구조의 위험과 완화 방안을 다룬다.

🕐 환경 변화 기록 (2026-04-24 오전 추가)
본 챕터 작성 시점(2026-04-23 오후)에는 TrueNAS가 pve-nd06 단일 어플라이언스였다. 2026-04-24 오전, 테스트팀과 개발팀의 데이터 격리를 위해 두 번째 TrueNAS 어플라이언스 pve-nd07이 추가되었다. 상세 구조와 영향은 챕터 03 §2에서 다룬다.
핸드북의 각 챕터는 그 시점의 정찰 결과를 담은 스냅샷으로 보존되며, 환경 변화는 본 스탬프처럼 별도 표기로 추적된다. 소급 본문 수정은 원칙상 수행하지 않는다 — "정찰 당시 사실"과 "현재 사실"을 분리해야 두 시점의 변화 자체가 분석 대상이 될 수 있기 때문이다.

1.4 데이터 수집 출처에 관한 메모

본 챕터에 인용된 모든 명령 출력은 pve-nd05 단일 노드에서 2026-04-23 15:11~15:24(KST) 사이에 두 차례 수집되었다. 5노드 전체에서 비교 수집한 결과가 아니다.

이 점은 다음 챕터에서 명확히 보완된다. 클러스터 정찰의 원칙 중 하나는 **"한 노드에서 수집한 정보를 클러스터 전체의 사실로 단정하지 않는다"**다. 동일 명령을 5노드 각각에서 돌려 비교해야 진짜 사실이 보인다. 본 챕터는 시리즈 도입부의 환경 묘사에 한정된 출력을 사용한다.

다만 5노드 일괄 SSH 점검 결과는 본 챕터에서도 활용된다(§2.4, §2.6). 이는 "한 노드에서 다른 노드를 원격 점검한" 데이터이므로 클러스터 전체의 단편을 보여줄 수 있다.

2. 정찰 데이터 첫 판독 — 무엇이 보이는가

핸드북 본격 작성 전 환경 정찰을 두 차례 실행한 결과, 다음 7가지 신호가 식별되었다. 각각은 후속 챕터에서 본격 다루지만, 본 챕터에서는 **"왜 이 핸드북이 지금 필요한가"**를 정당화하는 근거로 일괄 제시한다.

신호의 분류 기준은 다음과 같다.

[정상]: 현재 안정적이며, 본 챕터에서는 기록만 한다
[참고]: 비정상은 아니지만 핸드북 사용자가 인지해야 할 환경 특성
[주의]: 즉각적 위험은 아니지만 방치 시 위험으로 전환 가능
[위험]: 사고 가능성이 명확히 존재, 완화 또는 정비 필요
[해소]: 정찰 과정에서 발견되어 즉시 정비된 항목 — 핸드북 사용의 첫 사례

2.1 [정상] 정족수와 클러스터 가용성

5/5 노드 모두 online이며 quorum=3에 vote=5로 안정적이다. 클러스터 자체의 자체 회복력은 정상 동작 중임을 시사한다. 다만 다음 §2.2부터의 신호들이 누적되면 향후 노드 한 대가 추가로 빠질 때 정족수 위기가 발생할 수 있다.

2.2 [위험] 자원 네이밍의 카오스 — 격리 합의 부재의 흔적

/etc/pve/storage.cfg에 정의된 스토리지 항목 중 사용자 ID 또는 날짜가 prefix/suffix로 들어간 자원이 다음과 같이 식별된다.

추정 작성자	자원 명	비고
`testerA`	`truenas-iscsi-testerA`, `cmptest-iscsi-window-testerA`, `cmptest-window-lvm-testerA`, `cmptest-truenas-iscsi-filebrowser-testerA`, `cmptest-lvm-filebrowser-testerA`	5건 (iSCSI/LVM 다수)
`testerB`	`iscsi-test-lvm-testerB`, `lvm-test-testerB`, `smb-test-testerB`, `pbs-test-testerB`, `zfs-over-iscsi-test-testerB`, `zfs-over-iscsi-test-testerB-2`, `nfs-test-testerB`	7건 (다양한 타입)
`testerC`	`iscsi-test-testerC`, `lvm-test-testerC`, `nfs-test-testerC`	3건
`testerD`	`nfs-test-testerD`	1건
`testerE`	`nfs-test-testerE`	1건 (자원명에 날짜 형태 0420 포함 — 작성자 미상)

이 목록에서 다음을 읽어낼 수 있다.

테스터별 자원 prefix는 자생적으로 형성되었다. 합의된 명명 규칙은 아니지만 사실상의 관행이 자리잡고 있다. 핸드북이 표준 명명 규칙을 정의할 때 이 관행을 존중하면 도입 마찰을 줄일 수 있다.
자원 풀(Pool) 분리는 이뤄지지 않았다. 모든 자원이 datacenter 단위에 평탄(flat)하게 떠 있다. 어느 자원이 어느 테스터의 작업물인지 확인하려면 이름을 일일이 읽어야 한다.
비활성 자원 다수 존재. disable 플래그가 붙은 자원(smb-test-testerB, lvm-test-testerB, zfs-over-iscsi-test-testerB, zfs-over-iscsi-test-testerB-2)이 정리되지 않은 채 누적되어 있다. 누가 언제 왜 비활성화했는지 추적할 메타데이터가 없다.
노드 제약(nodes 필드)이 자원마다 들쭉날쭉. 어떤 자원은 5노드 모두에 등록(pve-nd01..pve-nd05), 어떤 자원은 단일 노드(pve-nd05만), 어떤 자원은 노드 제약 자체가 없다(전 노드 자동 노출). 이 불일치 자체가 충돌 잠재력이다.
PBS 중복 등록. 동일한 PBS 서버(10.99.40.100 / datastore pve-nd06-pbs)가 두 항목으로 등록되어 있다(pve-pbs01, pbs-test-testerB). 같은 fingerprint, 같은 datastore를 두 이름으로 보는 상태다. 어느 한쪽을 정리해야 하지만 사용 중일 가능성이 있어 단순 삭제는 위험하다.

이 상태는 격리 합의가 한 번도 이뤄진 적이 없는 환경의 전형이다. 본 핸드북이 챕터 08(위험 매트릭스 & 격리)에서 가장 우선적으로 정비를 권고할 영역이다.

2.3 [위험] Corosync Ring1과 Storage 평면의 공유

/etc/pve/corosync.conf 내 노드별 ring 주소를 추출하면 다음과 같다.

ini

node {
  name: pve-nd05
  nodeid: 5
  quorum_votes: 1
  ring0_addr: 10.99.20.15   ← corosync 전용 평면
  ring1_addr: 10.99.30.15   ← storage 평면 공유
}

/etc/pve/storage.cfg의 모든 NFS/iSCSI 항목 중 다수가 10.99.30.16을 server/portal로 가지므로, ring1이 흐르는 L2 평면에 storage 트래픽이 흐른다는 것은 사실이다.

totem 블록의 link_mode: passive는 ring0가 살아있는 동안 ring1을 휴면 상태로 유지하므로 평시에는 충돌이 없다. 그러나 ring0 장애 시점부터는 corosync가 storage 트래픽과 같은 평면에서 토큰을 주고받게 되며, 이 시점에 토큰 타임아웃이 빈발할 수 있다.

기존 학습 시리즈 07-troubleshooting.md §8.5에서 다룬 KNET 토큰 타임아웃 케이스와 동일한 패턴이 발생할 가능성이 있으며, 본 핸드북 챕터 01에서 ring 가용성 모니터링과 fallback 시점 식별 방법을 다룬다.

2.4 [해소] 노드 간 SSH 호스트네임 해석 정비 — 핸드북 사용 첫 사례

본 핸드북 작성을 위한 1차 정찰 시점(2026-04-23 15:11)에서 5노드 일괄 SSH 점검을 시도한 결과는 다음과 같았다.

markdown

=== pve-nd01 ===
ssh: Could not resolve hostname pve-nd01: Name or service not known
=== pve-nd02 ===
ssh: Could not resolve hostname pve-nd02: Name or service not known
=== pve-nd03 ===
ssh: Could not resolve hostname pve-nd03: Name or service not known
=== pve-nd04 ===
pve-nd04.corp.local
10.99.20.14 10.99.10.14 10.99.40.14 10.99.30.14
=== pve-nd05 ===
pve-nd05.corp.local
10.99.20.15 10.99.10.15 10.99.40.15 10.99.30.15

원인은 pve-nd05의 /etc/hosts에서 즉시 드러났다.

markdown

127.0.0.1 localhost.localdomain localhost
10.99.10.15 pve-nd05.corp.local pve-nd05
10.99.10.14 pve-nd04

pve-nd01, pve-nd02, pve-nd03이 등록되어 있지 않았다. 클러스터 자체의 corosync 통신은 IP 직접 지정으로 구성되어 영향이 없지만, SSH·Replication·Live Migration·pvecm 기반 일부 작업은 hostname resolution에 의존한다. 이 상태에서 라이브 마이그레이션을 시도하면 실패하며, ZFS Replication도 구성 즉시 SYNCING 상태에 멈춘다.

정비 절차

핸드북 1차 판독 직후 다음 절차로 정비가 수행되었다.

bash

# pve-nd05의 /etc/hosts에 누락된 노드 3개 추가
cat >> /etc/hosts <<'EOF'
10.99.10.13 pve-nd03
10.99.10.12 pve-nd02
10.99.10.11 pve-nd01
EOF

정비 후 검증

2차 정찰(2026-04-23 15:24)에서 5노드 일괄 SSH가 모두 성공함을 확인했다.

markdown

=== pve-nd01 ===
Warning: Permanently added 'pve-nd01' (ED25519) to the list of known hosts.
pve-nd01.corp.local
10.99.20.11 10.99.10.11 10.99.40.11 10.99.30.11
 15:24:22 up 34 days,  6:00, 11 users,  load average: 0.43, 0.32, 0.33
=== pve-nd02 ===
Warning: Permanently added 'pve-nd02' (ED25519) to the list of known hosts.
pve-nd02.corp.local
10.99.20.12 10.99.10.12 10.99.40.12 10.99.30.12
 15:24:22 up 48 days, 23:44,  6 users,  load average: 0.72, 0.74, 0.75
=== pve-nd03 ===
Warning: Permanently added 'pve-nd03' (ED25519) to the list of known hosts.
pve-nd03.corp.local
10.99.20.13 10.99.10.13 10.99.40.13 10.99.30.13
 15:24:22 up 48 days, 23:43,  6 users,  load average: 0.21, 0.23, 0.23
=== pve-nd04 ===
pve-nd04.corp.local
10.99.20.14 10.99.10.14 10.99.40.14 10.99.30.14
 15:24:23 up 16 days,  6:42,  5 users,  load average: 0.36, 0.27, 0.27
=== pve-nd05 ===
pve-nd05.corp.local
10.99.20.15 10.99.10.15 10.99.40.15 10.99.30.15
 15:24:23 up  4:05,  6 users,  load average: 0.11, 0.16, 0.17

잔여 정비 항목

이 정비는 pve-nd05 단일 노드에서만 수행되었다. 본 핸드북이 권고하는 완전한 정비는 다음과 같다.

5노드 모두의 /etc/hosts에 동일한 5노드 매핑 적용. 현재는 pve-nd05에서 다른 4노드를 보는 방향만 정비된 상태이며, 다른 4노드가 서로를 어떻게 보는지는 미확인이다. 챕터 01에서 5노드 /etc/hosts 일괄 비교 명령을 다룬다.
DNS 서버 운영 여부 검토. 노드 5대 규모에서는 /etc/hosts 동기화로 충분하지만, 향후 노드가 추가되거나 외부 시스템(PBS, TrueNAS, CMP 호스트)과의 통신이 hostname 기반으로 확장되면 사내 DNS 운영이 필요해진다.
Ansible 또는 pmxcfs 활용한 /etc/hosts 자동 동기화 메커니즘 도입 검토. 클러스터의 어느 노드에서 /etc/hosts를 수정하더라도 모든 노드에 동일하게 반영되도록 한다. pmxcfs를 직접 활용하기는 어렵지만, hosts 파일을 /etc/pve/에 두고 /etc/hosts로 심볼릭 링크하는 패턴이 일부 환경에서 사용된다.

이 사례는 핸드북의 사용 방식을 보여주는 첫 본보기다. 정찰 → 발견 → 정비 → 검증의 사이클이 한 챕터 안에서 완결된다. 본 핸드북의 모든 챕터가 이 사이클을 사용자에게 강제한다.

2.5 [주의] 시간 동기화의 외부 의존

chronyc tracking 출력 일부:

markdown

Reference ID    : AABBCCDD (ipv4.ntp3.example.com)
Stratum         : 3
System time     : 0.000048155 seconds slow of NTP time
Last offset     : -0.000036566 seconds
Frequency       : 4.739 ppm slow
Leap status     : Normal

현재 시점의 시간 정확도(48μs slow)는 우수하다. 그러나 reference가 외부 NTP 서버(ntp3.example.com)다. 사내 NTP 서버를 거치지 않고 인터넷 외부로 직접 나간다.

이 구조의 리스크:

사외망 차단 시점에 시간 동기화가 점진적으로 어긋난다
5노드가 모두 외부 NTP를 직접 보면, 외부 서버의 일시적 응답 지연이 5노드 동시에 영향을 준다
노드별 reference NTP가 다를 경우 시계가 어긋날 수 있고, 클러스터 로그 상관관계 분석이 무너진다 (특히 챕터 07의 로그 시계열 비교에 직접 영향)

5노드 모두의 chrony 설정 비교는 챕터 02(노드 정찰)에서 다룬다.

2.6 [참고] 노드별 uptime 분포 — 점진적 운영의 흔적

5노드 일괄 점검 결과 uptime 분포가 4개 그룹으로 갈라진다.

노드	uptime	추정 마지막 부팅 시점	동시 SSH 사용자
pve-nd01	34일 6시간	약 2026-03-20	11명
pve-nd02	48일 23시간 44분	약 2026-03-05	6명
pve-nd03	48일 23시간 43분	약 2026-03-05 (nd02와 동시)	6명
pve-nd04	16일 6시간 42분	약 2026-04-07	5명
pve-nd05	4시간 5분	약 2026-04-23 11:19	6명

이 분포에서 두 가지를 읽을 수 있다.

판독 1 — 클러스터 초기 셋업 시점은 약 49일 전(2026-03-05 전후)으로 추정된다. nd02와 nd03이 거의 동시에 부팅된 흔적은 두 노드가 같은 셋업 사이클에서 함께 올라왔다는 것을 시사한다. 이후 nd01(34일 전), nd04(16일 전), nd05(4시간 전)는 별개의 reboot 이벤트를 겪었다.

판독 2 — pve-nd05의 4시간 uptime은 본 핸드북 작성자(다비)가 직접 수행한 의도된 재부팅이다. 정전이나 커널 패닉 같은 비정상 이벤트가 아니다. 회사 서버랙에서 물리 전원 버튼을 눌러 재기동한 결과다. 다른 노드의 단기 uptime을 발견했을 때는 원인이 의도된 재부팅인지 / 커널 패닉으로 인한 자동 재기동인지 / Fence에 의한 강제 재기동인지를 구분해야 한다. 이 구분 절차는 챕터 02 §3, 챕터 07 §4에서 본격 다룬다.

2.7 [참고] 노드별 부하 분포 — 작업 집중도의 단서

uptime 출력의 load average와 동시 SSH 사용자 수를 함께 보면 노드별 작업 집중도가 드러난다.

노드	load average (1m, 5m, 15m)	SSH 사용자	추정 사용 양상
pve-nd01	0.43, 0.32, 0.33	11명	가장 인기 있는 진입 노드
pve-nd02	0.72, 0.74, 0.75	6명	지속적인 백그라운드 부하 존재
pve-nd03	0.21, 0.23, 0.23	6명	가장 한가함
pve-nd04	0.36, 0.27, 0.27	5명	평균적
pve-nd05	0.11, 0.16, 0.17	6명	막 부팅된 직후라 부하 누적 안 됨

판독:

pve-nd02의 지속적 부하(0.72/0.74/0.75)는 다른 노드 평균(0.3 전후) 대비 약 2배다. 1분/5분/15분 평균이 거의 같다는 점에서 일시적 spike가 아닌 상시 백그라운드 작업이 돌고 있을 가능성이 높다. 어떤 VM 또는 어떤 cron 작업이 점유하는지는 챕터 02·06에서 추적한다.
pve-nd01의 11명 동시 SSH 사용자는 다른 노드(5~6명) 대비 두 배다. 5명의 테스터가 각자 평균 1~2개의 SSH 세션을 유지한다고 가정해도 nd01에 사실상 모든 테스터가 접속해 있는 상황이다. nd01이 사실상의 진입 노드(jump host) 역할을 하고 있을 가능성이 있다.

이 두 사실은 CMP 테스트 부하 분산이 균형 있게 이뤄지지 않고 있다는 정황 증거다. 챕터 02에서 본격 분석한다. 본 챕터에서는 정황만 기록한다.

3. 정찰 철학 — Blast Radius와 Reversibility

본 핸드북의 모든 정찰 절차와 위험 평가는 두 개의 축 위에 서 있다. 이 두 축을 머릿속에 박지 않은 채 핸드북을 사용하면, 명령어 카탈로그 이상의 가치를 끌어내기 어렵다.

3.1 Blast Radius — 영향 반경

어떤 액션이 일으킬 수 있는 충격이 어디까지 번지는가의 척도다. 다섯 단계로 구분한다.

등급	영향 범위	예시 액션
L1	자기 사용자의 자원 한정	자기 풀 안의 신규 VM 생성, 자기 풀의 VM 시작/정지
L2	자기 사용자가 점유한 노드 한정	자기 풀의 VM 마이그레이션, 자기 풀의 스냅샷 생성
L3	단일 노드 전체에 영향	노드 단일 reboot, 노드의 storage 마운트 변경
L4	클러스터 전체에 영향	`/etc/pve/storage.cfg` 수정, 새 스토리지 정의 추가
L5	외부 시스템 또는 비가역 영향	TrueNAS zVol 삭제, corosync.conf 변경, `pvecm delnode`

CMP를 통한 모든 액션은 API가 결국 어느 등급의 작업을 일으키는가를 사전에 추정할 수 있어야 한다. CMP UI에서 "삭제" 버튼이 L1 작업으로 보이지만 실제로는 L5의 zVol 삭제까지 연쇄적으로 일으키는 경우가 흔하다. 이 연쇄를 추적하지 않으면 결함 보고서의 영향도 평가가 불가능해진다.

3.2 Reversibility — 가역성

한 액션을 되돌릴 수 있는가의 척도다. 네 단계로 구분한다.

등급	회복성	예시
R1	즉시 되돌릴 수 있음 (단순 setting 변경)	VM 메모리 크기 변경, NIC 모델 교체
R2	백업·스냅샷이 있으면 되돌릴 수 있음	VM 디스크 변경, OS 설정 변경
R3	별도 자원의 복구 절차가 필요함 (시간·노력 소요)	잘못 삭제한 VM 복원, 잘못 변경한 storage 복구
R4	되돌릴 수 없음 (물리적 또는 정보 이론적으로 비가역)	`qm template` 변환, `qm rollback`, zVol 삭제

R4 액션은 테스트 전 반드시 사전 백업과 명시적 확인 절차가 필요하다. CMP가 R4 액션을 호출하는 API를 단일 클릭 버튼으로 노출했다면 그것 자체가 결함이다.

3.3 격자 매트릭스 — 위험도 합산

Blast Radius × Reversibility를 곱하면 5×4 = 20개의 셀이 만들어진다. 본 핸드북은 이 격자 위에 모든 정찰 액션과 테스트 액션을 분류한다.

markdown

Reversibility →   R1        R2        R3        R4
Blast Radius ↓
L1                안전     안전     주의     주의
L2                안전     안전     주의     위험
L3                주의     주의     위험     금지
L4                주의     위험     금지     금지
L5                위험     금지     금지     절대금지

이 격자는 절대 기준이 아니라 출발점이다. 챕터 08(위험 매트릭스)에서 본 클러스터 환경에 맞춰 셀별 구체적 액션 목록을 채운다. 본 챕터에서는 사고방식만 도입한다.

3.4 두 축의 적용 사례

본 환경에서 다음 액션을 격자에 올려보자.

테스트 풀 안의 신규 VM 생성: L1 × R2 → 안전. 디스크는 별도 자원으로 만들어지므로 잘못되어도 격리되며, vzdump 백업으로 R2 회복 가능.
/etc/pve/storage.cfg에 새 NFS 항목 추가: L4 × R1 → 위험. 클러스터 전체에 즉시 전파되며, 항목 자체는 텍스트 한 줄이지만 잘못 작성하면 5노드 모두의 pvestatd가 영향받는다.
TrueNAS zVol 삭제: L5 × R4 → 절대금지. 본 핸드북은 TrueNAS 측 자원에 대한 직접 변경을 테스트팀이 수행하지 않는다는 원칙을 권고한다.
disable 처리된 stale 자원 정리 (예: lvm-test-testerB): L4 × R3 → 금지. storage.cfg에서 단순히 줄을 지우면 L4 변경이 발생하며, 만약 그 자원에 누군가 데이터를 남겨놓았다면 R3 복구가 필요하다. 정리 작업은 작성자 본인의 명시적 동의 없이는 금지한다.

4. 본 핸드북이 다루는 CMP 테스트 대분류

CMP 테스트는 다양한 형태를 가질 수 있으나, 본 핸드북은 다음 4개 대분류로 모든 시나리오를 묶는다. 이 분류는 챕터 01부터 10까지 공통으로 적용되며, 각 챕터의 §4에서 해당 영역에 특화된 시나리오를 이 4분류에 따라 풀어낸다.

4.1 CRUD 기능 검증

CMP의 가장 기본적이고 회귀 검증(Regression) 성격이 강한 영역이다.

6개 NIC 타입 각각의 생성/수정/삭제가 PVE CLI(/etc/network/interfaces)와 일치하게 들어가는지
VM 생성 API가 호출하는 파라미터가 qm create의 옵션과 의미상 일치하는지
스토리지 등록 API가 /etc/pve/storage.cfg에 정확한 형식으로 항목을 추가하는지

이 분류의 시나리오는 결과가 명백한 입력·출력 매핑이다. 결과 비교만 정확히 하면 결함 여부 판정이 직관적이다. 다만 검증의 진입점이 PVE CLI나 설정 파일이라는 사실을 잊으면 안 된다. CMP UI에 표시된 결과만 보고 "성공"을 판정하면, CMP 내부 캐시가 거짓 정보를 보여주는 결함을 놓친다.

4.2 스테이징 워크플로우(Staging Workflow)

CMP 특유의 검증 영역이며 가장 결함 발견율이 높다.

변경사항을 일단 스테이징에 쌓고, 적용 버튼으로 일괄 반영하는 패턴의 정합성
되돌리기(Revert) 시 부분 적용 상태 처리
적용 도중 실패 발생 시의 롤백
다중 사용자가 동시에 같은 자원을 변경할 때의 충돌 처리

이 분류는 PVE 자체에는 없는 추상화이므로 PVE CLI 결과와의 일치 여부만으로는 검증할 수 없다. CMP 내부 상태 머신과 PVE 실제 상태의 동시 추적이 필요하다. 챕터 07(로그 시스템)에서 두 레이어의 로그를 동기화하여 보는 방법을 다룬다.

4.3 위험 시나리오·에러 처리

품질 테스트의 진짜 알맹이로 분류되는 영역이다.

활성 본드(Bond) 슬레이브 변경 시도
마지막 관리 인터페이스(mgmt NIC) 삭제 시도
잘못된 VLAN ID(0 또는 4095 초과) 입력
OVS 패키지 미설치 상태에서 OVS 브릿지 생성 요청
자원 명 충돌
외부 의존성 단절 상태에서의 작업 요청 (TrueNAS 다운, NTP 끊김)

이 분류는 의도적으로 "실패해야 할 작업"을 만들어 CMP가 어떻게 실패하는가를 관찰한다. 좋은 실패는 명확한 에러 메시지와 함께 환경에 자취를 남기지 않는다. 나쁜 실패는 부분적인 자취(orphan resource)를 남기거나, 무응답 상태에 머물거나, 거짓 성공을 보고한다.

위험 시나리오 테스트는 사전 정찰의 정확도가 가장 중요한 영역이다. 자기가 만들지 않은 자원을 잘못 파괴할 위험이 가장 높기 때문이다. 본 핸드북의 거의 모든 챕터가 이 분류의 사전 정찰을 직간접적으로 지원한다.

4.4 클러스터 일관성

CMP의 다중 노드 관리 능력에 특화된 영역이다.

한 노드에서 일어난 변경이 다른 노드의 상태 표시에 어떻게 동기화되는지
노드 다운/복구 시 CMP가 표시하는 자원 상태와 실제 PVE 상태의 정합성
HA 페일오버 발생 시 CMP가 자동으로 자원 위치를 갱신하는지
클러스터 전반의 자원 통계(CPU 합계, 메모리 합계)가 실제와 일치하는지

이 분류는 단일 노드 검증으로는 절대 잡을 수 없는 결함을 다룬다. 정찰 측면에서는 반드시 5노드 동시 비교가 전제되어야 한다.

4.5 4분류 × 챕터 인덱스

각 영역(챕터)에서 위 4분류가 어떻게 구체화되는지의 미리보기 인덱스를 제공한다. 핸드북 사용자는 자기가 하려는 테스트의 분야와 성격을 두 축으로 식별한 뒤 해당 셀의 챕터·절을 펼쳐 본다.

영역 \ 분류	4.1 CRUD	4.2 스테이징	4.3 위험 시나리오	4.4 클러스터 일관성
01 클러스터	노드 추가/제거 API	코로싱크 설정 변경	정족수 손실 유도	멤버십 표시 동기화
02 노드	노드 옵션 변경	노드 시간 설정 일괄 적용	노드 reboot/shutdown	노드별 자원 합계 정확성
03 디스크	디스크 추가·제거	디스크 일괄 변경	활성 LV 삭제 시도	디스크 사용량 동기화
04 스토리지	storage CRUD	스토리지 일괄 등록	마운트 실패 시 처리	shared 스토리지 노드별 표시
05 네트워크	NIC/Bridge/VLAN/Bond CRUD	적용/되돌리기	활성 슬레이브 변경	노드별 NIC 정보 동기화
06 가상 자원	VM/CT CRUD	VM 일괄 생성	운영 VM 잘못 종료	자원 위치 추적 정확성
07 로그	로그 조회 API	(해당 없음)	로그 폭주 시 표시 한계	노드별 로그 통합 검색
08 위험 매트릭스	(해당 없음)	(해당 없음)	모든 위험 시나리오의 출처	격리 정책의 노드 간 일관성
09 사전 점검	체크리스트 자동화	(해당 없음)	중단 신호 자동 감지	5노드 동시 점검
10 산출물 템플릿	(해당 없음)	(해당 없음)	(해당 없음)	산출물 클러스터 전반 반영

이 인덱스는 시리즈 작업이 진행되며 채워지고 정교화된다. 본 챕터 시점에서는 골격만 제시한다.

5. 핸드북의 공통 본문 구조 (v2)

챕터 01부터 10까지는 다음 8개 섹션 구조를 일관되게 따른다. 핸드북 사용자가 새로운 챕터를 펼쳤을 때 어디에 무엇이 있는지 즉시 알 수 있도록 하기 위함이다.

markdown

## 0. 이 챕터의 정찰 목적
   ─ 무엇을 알아내려 하는가
   ─ 왜 알아내야 하는가
   ─ 어느 챕터·어느 테스트와 연결되는가

## 1. 개념 — 본문 이해에 필요한 최소한의 배경
   ─ 신입 테스터가 §2의 명령 출력을 읽을 때 막히지 않을 수준의 사전 지식

## 2. 정찰 명령과 출력 해석
   2.1 명령 A
       ─ 명령 한 줄
       ─ 실제 출력 블록
       ─ 줄별 의미 풀이
       ─ "이 출력에서 끌어내야 할 정보 N가지"
   2.2 명령 B
   ...

## 3. 출력의 비정상 패턴과 조기 경보
   ─ 정상 출력 vs 의심 출력의 대조표
   ─ 즉시 멈춰야 할 신호

## 4. 이 영역의 CMP 테스트 대분류와 시나리오
   4.1 CRUD 기능 검증 — 시나리오 카탈로그 + 각 시나리오의 사전 정찰 매핑
   4.2 스테이징 워크플로우
   4.3 위험 시나리오·에러 처리
   4.4 클러스터 일관성

## 5. 정찰 ↔ 테스트 단계 역방향 매핑
   ─ "특정 액션을 하기 전에 §2의 어느 출력을 확인해야 하는가"
   ─ §4의 시나리오 카탈로그를 행위 기준으로 다시 묶음

## 6. 정찰 결과를 산출물로 정리하는 양식
   ─ 표·리스트·다이어그램 템플릿

## 부록: 명령 치트 시트 / 참고 자료 / 공식 문서 링크

5.1 §4와 §5의 분리 이유

§4는 "이 영역에서 가능한 모든 테스트의 카탈로그"이고, §5는 "특정 액션을 수행하기 전에 어떤 정찰이 선행되어야 하는가"의 역방향 매핑이다. 같은 데이터를 두 각도로 인덱싱한다.

신규 테스터는 §4를 펼쳐 "오늘 내가 할 수 있는 테스트가 뭔가"를 본다. 반복 테스터는 §5를 펼쳐 "지금 이 액션을 안전하게 하려면 무엇을 미리 봐야 하는가"를 본다. 동일 정보의 두 가지 진입점이 모두 책상 위에 있어야 핸드북이 살아있다.

5.2 §3의 위치와 무게

§3(비정상 패턴과 조기 경보)는 본 핸드북에서 가장 자주 펼쳐질 섹션이다. 사고는 정상 시점에 일어나지 않고 비정상 시점에 일어나며, 비정상의 첫 신호를 빠르게 인식하는가에 사고 확산 여부가 결정된다.

각 챕터의 §3은 다음 형식을 표준으로 한다.

markdown

### 정상 패턴
[명령] → [정상 출력 일부]
정상의 근거: ...

### 의심 패턴
[명령] → [의심 출력 일부]
원인 가설: ..., ..., ...
즉시 확인할 후속 명령: ...

### 즉시 중단 신호
[다음 출력이 보이면 자기 테스트를 즉시 중단하고 책임자에게 보고]

5.3 본 챕터(00)에서 표준 구조를 따르지 않은 이유

본 챕터는 시리즈의 메타 문서 성격이라 본문 구조를 표준대로 따르지 않는다. §4(테스트 대분류)는 카탈로그가 아니라 분류 정의로, §5는 후속 챕터 인덱스로 대체되었다. §3(비정상 패턴)은 §2(첫 판독) 안에 자연스럽게 녹여 분리하지 않았다. 챕터 01부터 표준 구조를 엄격히 적용한다.

6. 핸드북 사용 시나리오

핸드북은 책장에 꽂힌 채 읽히지 않으면 죽은 문서다. 누가 언제 어디를 펼치는지를 명시하여 사용 패턴을 강제한다.

6.1 신입 테스터의 첫날

본 챕터(00)부터 챕터 03까지를 정독한다. 그 후 챕터 09(사전 점검 체크리스트)를 한 번 따라 실행하며 본인 계정으로 클러스터에 직접 접근해 본다. 이 과정에서 막히는 부분은 즉시 선임 테스터에게 인계한다.

이 과정은 최소 반나절을 잡고, 절차를 단축하지 않는다. 단축하면 그날 만든 첫 번째 테스트 자원이 잘못된 위치에 잘못된 이름으로 만들어지고 그 자원이 일주일 후 누군가의 사고 원인이 된다. §2.2에서 본 자원 네이밍의 카오스가 바로 이 단축의 누적 결과다.

6.2 새로운 테스트 사이클의 시작

매주 월요일 또는 새 스프린트 시작일에 챕터 09의 사전 점검 체크리스트를 실행한다. 직전 사이클에서 남은 자원, 변경된 환경, 새로 발견된 위험을 식별하고, 본 사이클에 영향을 주지 않을 상태로 정리한 뒤 새 테스트를 시작한다.

5월 첫째주 시작될 시나리오 통합 테스트(STN, Scenario Integration Test)는 본 핸드북이 가장 무겁게 사용될 시점이다. 시나리오 통합 테스트는 단일 기능이 아닌 복수 기능의 연쇄 호출을 검증하며, 사전 환경 정찰 부재 시 결함과 환경 노이즈를 구별하지 못한다.

6.3 사고 발생 시

CMP가 예상과 다른 동작을 하거나, 클러스터에 이상 신호가 감지되었을 때:

자기 테스트를 즉시 중단한다 (가장 중요)
챕터 07(로그 시스템 해부)을 펼치고 사고 발생 시각 전후 5분의 로그를 5노드 전체에서 수집
영역별 챕터의 §3(비정상 패턴) 참조하여 패턴 매칭
사고 분류 후 책임자 보고
보고 시 챕터 10의 사고 보고서 양식을 사용

테스트 중단을 망설이지 말 것. 사고 확산보다 테스트 일정 손실이 항상 작다.

6.4 산출물 갱신 주기

본 핸드북과 챕터 10의 산출물(클러스터 위상도, 자원 인벤토리, 격리 정책)은 다음 시점에 갱신한다.

즉시 갱신: 노드 추가/제거, 스토리지 백엔드 변경, 네트워크 평면 재설계, CMP 메이저 버전 업데이트
월 1회 정기 갱신: 자원 인벤토리 전체, 비활성 자원 정리 결과, 명명 규칙 위반 사례 누적
사이클 시작 시 갱신: 격리 정책 (테스터 입출, 노드별 부하 분포 변화)

갱신되지 않은 산출물은 일주일 만에 거짓 정보가 되어 사용자를 오도한다. 갱신을 못 할 상황이라면 차라리 산출물에 "최종 갱신 시점"과 "갱신 책임자 부재"를 명시하여 불신을 강제한다.

7. 핸드북 작성·운영 사이클

본 핸드북은 한 번 만들어 끝나는 정적 문서가 아니라 테스트팀의 일상 운영과 맞물려 갱신되는 살아있는 자산이다. 작성·갱신 사이클을 명시한다.

7.1 챕터 단위 작성 사이클

각 챕터는 다음 5단계 사이클로 작성된다.

markdown

[1] 데이터 수집 명령 묶음 정의
    └ 명령으로 수집 가능한 것 + 환경 메타 정보 분리
[2] 5노드(또는 관련 노드) 전체에서 데이터 수집
    └ 단일 노드 수집 시 그 한계를 본문에 명시
[3] 수집 데이터 첫 판독 → 본문 작성
    └ 작성 중 추가 정보 필요 시 [1]로 회귀
[4] 챕터 본문 .md 파일 산출
[5] 시리즈 인덱스(본 챕터의 §4.5) 갱신 후 다음 챕터로

이 사이클은 본 챕터(00) 작성 과정에서 이미 한 번 완결되었다. §2.4의 [해소] 사례가 그 증거다.

7.2 산출물 디렉토리 구조 제안

본 핸드북 시리즈와 부속 산출물의 권장 디렉토리 구조:

markdown

cmp-pre-test-recon-handbook/
├── 00-handbook-overview.md           ← 본 문서
├── 01-cluster-reconnaissance.md
├── 02-node-reconnaissance.md
├── 03-disk-reconnaissance.md
├── 04-storage-reconnaissance.md
├── 05-network-reconnaissance.md
├── 06-virtual-resource-inventory.md
├── 07-log-system-anatomy.md
├── 08-risk-matrix-and-isolation.md
├── 09-pretest-checklist.md
├── 10-recon-output-template.md
├── artifacts/                         ← 정찰 산출물
│   ├── cluster-topology-2026-04-23.md
│   ├── resource-inventory-2026-04-23.md
│   ├── isolation-policy-v1.md
│   └── plane-matrix-v1.md
├── incidents/                         ← 사고 보고서
│   └── YYYY-MM-DD-사고요약.md
└── data-snapshots/                    ← 정찰 데이터 원본
    └── 2026-04-23-1524-pve-nd05.txt

산출물(artifacts)은 본문 챕터와 분리되어 시점별로 누적된다. 사고 보고서(incidents)는 사고 발생 시 챕터 10의 양식에 따라 작성되어 누적된다. 데이터 스냅샷(data-snapshots)은 명령 출력 원본을 시점·노드별로 보존하여 향후 비교 분석이 가능하게 한다.

7.3 핸드북 갱신 책임

본 핸드북의 갱신 책임은 다음과 같이 분배되도록 권고한다.

신규 챕터 작성·기존 챕터 구조 변경: 핸드북 작성 책임자(현재: 다비)
§2 첫 판독·§3 비정상 패턴 신규 항목 추가: 사고를 발견·해소한 모든 테스터
§7 산출물 갱신: 매 사이클 시작 시 사이클 책임 테스터
시리즈 인덱스(§4.5) 갱신: 챕터 추가·시나리오 추가 시점에 작성자

핸드북 갱신은 핸드북 본문 안에 절차로 박혀 있어야 강제된다. 회의 합의나 구두 약속으로는 일주일을 못 간다.

8. 우선 정비해야 할 환경 항목

본 핸드북 본격 운영 전 또는 1차 사이클 진행과 병행하여 다음 항목들의 정비를 권고한다. 우선순위 순.

8.1 [P0] 5노드 `/etc/hosts` 일괄 정비

§2.4에서 pve-nd05만 정비된 상태다. 다른 4노드의 /etc/hosts도 동일한 5노드 매핑을 갖도록 일괄 적용해야 한다.

권고 절차:

pve-nd05의 /etc/hosts 형태를 표준안으로 확정
Ansible playbook 또는 단순 shell 스크립트로 5노드에 일괄 배포
배포 후 5노드 모두에서 for n in pve-nd0{1..5}; do ssh $n hostname; done 양방향 점검

이 정비가 끝날 때까지 라이브 마이그레이션·ZFS Replication 같은 hostname 의존 작업은 시도하지 않는다.

8.2 [P0] 자원 명명 규칙·격리 정책 합의

§2.2의 자원 카오스 상태를 정리하기 위한 합의가 필요하다.

권고 합의 사항:

자원 prefix 표준화: 사용자 ID prefix({userid}-{purpose}-{type})를 핸드북 정식 컨벤션으로 채택. 자생적 관행을 그대로 표준화하면 도입 마찰이 작다.
VMID 대역 분배: 5명 테스터에 대해 1만 단위 대역 할당 (예: 110000~119999, 120000~129999...)
Pool 도입: pvesh create /pools 활용. 사용자별 Pool에 자기 자원을 명시적으로 등록하도록 강제.
CMP 자동 생성 자원 vs 수동 생성 자원의 명확한 식별: 태그(Tag) 또는 명명 prefix(auto-, manual-)로 구분.

이 합의는 챕터 08의 산출물로 정리된다. 본 챕터 시점에서는 합의 필요성만 등록한다.

8.3 [P1] 비활성 자원 정리

§2.2에서 식별된 disable 자원 목록(smb-test-testerB, lvm-test-testerB, zfs-over-iscsi-test-testerB, zfs-over-iscsi-test-testerB-2)에 대해 작성자 본인의 정리 동의를 받는다.

원칙: 본인 미동의 자원은 정리하지 않는다. §3.4에서 본 격자 매트릭스 기준 L4 × R3 = 금지에 해당한다.

PBS 중복 등록(pve-pbs01 vs pbs-test-testerB)도 동일 원칙으로 처리. 둘 중 어느 항목이 권한 정책 또는 prune-backup 정책에서 다른 의미를 갖는지 확인한 뒤 정리한다.

8.4 [P2] 시간 동기화 사내 NTP 도입 검토

§2.5의 외부 NTP 의존을 사내 NTP 서버 1대 도입으로 완화. 이는 핸드북 범위가 아니라 운영 인프라 영역이므로 운영팀에 인계.

8.5 [P2] 노드 부하 분산 검토

§2.7의 pve-nd02 상시 부하와 pve-nd01 사용자 집중을 챕터 02에서 본격 분석한 뒤 부하 분산 방안 도출.

부록 A. 본 챕터에서 인용된 정찰 데이터 원본 (요약)

본 챕터에 인용된 명령 출력의 원본은 data-snapshots/2026-04-23-1524-pve-nd05.txt에 보존되어 있다. 본 부록은 그 요약 색인이다.

명령	인용 위치	비고
`pvecm status`	§1.1	정족수와 멤버십 식별
`pvecm nodes`	§1.1, §2.1	노드명·노드ID 매핑
`cat /etc/pve/.members`	§1.1, §1.2	mgmt 평면 IP 출처
`cat /etc/hosts`	§2.4	hostname resolution 정비 전후 비교
`pveversion -v`	§1.1	9.1.1 / 커널 6.17.2-1-pve
`cat /etc/pve/corosync.conf`	§1.2, §2.3	ring0/ring1 IP, link_mode 식별
`cat /etc/pve/storage.cfg`	§1.3, §2.2	백엔드 인프라·자원 명명 분석
5노드 일괄 SSH 점검	§2.4, §2.6, §2.7	호스트네임 해석·uptime·load 분포
`chronyc tracking`	§2.5	NTP 동기화 상태

부록 B. 다음 챕터로의 인계

챕터 01(클러스터 정찰)에서 다룰 항목 중 본 챕터에서 인계된 것:

본 챕터 등록 신호	챕터 01에서의 처리
§1.1 Ring ID `1.11b`의 의미	corosync 멤버십 변천 추적, 정상 변천 vs 의심 변천 구분
§1.2 평면 매트릭스	5노드 모두에서 평면 일관성 검증 절차 (단일 노드 검증 한계 보완)
§2.1 정족수 모니터링	`corosync-quorumtool`, `corosync-cfgtool -s`의 본격 사용법
§2.3 ring1 + storage 충돌	ring 가용성 모니터링·fallback 시점 식별·완화 옵션
§2.4 잔여 정비 항목	5노드 `/etc/hosts` 일괄 비교 명령, DNS 도입 검토 시 고려사항
§2.7 부하 분포	노드별 corosync·pmxcfs 통신 부하의 정상 베이스라인 확립

부록 C. 참고 자료

주제	URL
Proxmox Cluster Manager 공식	https://pve.proxmox.com/wiki/Cluster_Manager
Proxmox Network Configuration 공식	https://pve.proxmox.com/wiki/Network_Configuration
Proxmox Storage 공식	https://pve.proxmox.com/pve-docs/pve-admin-guide.html#chapter_storage
Corosync 공식 문서	https://corosync.github.io/corosync/
Corosync `link_mode` 설명	https://manpages.debian.org/bookworm/corosync/corosync.conf.5.en.html
chrony 공식 문서	https://chrony-project.org/documentation.html
TrueNAS SCALE 공식	https://www.truenas.com/docs/scale/
본 시리즈 모태 학습 시리즈	`notes/linux/proxmox/06-references/07-troubleshooting.md`(KNET 토큰 타임아웃 사례 §8.5 등)

다음 챕터: 01-cluster-reconnaissance.md — 5노드 모두에서 corosync·pmxcfs·정족수의 정상 베이스라인을 확립하고, ring1+storage 충돌의 모니터링 방법을 도입한다.

data-snapshots

0. 이 핸드북이 무엇인가 ​

0.1 한 줄 정의 ​

0.2 누구를 위한 책인가 ​

0.3 이 핸드북이 다루지 않는 것 ​

1. 본 핸드북이 전제하는 환경 ​

1.1 5노드 Proxmox 클러스터 — pve-cl01 ​

1.2 IP 평면 분리 매트릭스 ​

1.3 백엔드 인프라 분포 — TrueNAS·PBS·평면 매핑 ​

1.4 데이터 수집 출처에 관한 메모 ​

2. 정찰 데이터 첫 판독 — 무엇이 보이는가 ​

2.1 [정상] 정족수와 클러스터 가용성 ​

2.2 [위험] 자원 네이밍의 카오스 — 격리 합의 부재의 흔적 ​

2.3 [위험] Corosync Ring1과 Storage 평면의 공유 ​

2.4 [해소] 노드 간 SSH 호스트네임 해석 정비 — 핸드북 사용 첫 사례 ​

정비 절차 ​

정비 후 검증 ​

잔여 정비 항목 ​

2.5 [주의] 시간 동기화의 외부 의존 ​

2.6 [참고] 노드별 uptime 분포 — 점진적 운영의 흔적 ​

2.7 [참고] 노드별 부하 분포 — 작업 집중도의 단서 ​

3. 정찰 철학 — Blast Radius와 Reversibility ​

3.1 Blast Radius — 영향 반경 ​

3.2 Reversibility — 가역성 ​

3.3 격자 매트릭스 — 위험도 합산 ​

3.4 두 축의 적용 사례 ​

4. 본 핸드북이 다루는 CMP 테스트 대분류 ​

4.1 CRUD 기능 검증 ​

4.2 스테이징 워크플로우(Staging Workflow) ​

4.3 위험 시나리오·에러 처리 ​

4.4 클러스터 일관성 ​

4.5 4분류 × 챕터 인덱스 ​

5. 핸드북의 공통 본문 구조 (v2) ​

5.1 §4와 §5의 분리 이유 ​

5.2 §3의 위치와 무게 ​

5.3 본 챕터(00)에서 표준 구조를 따르지 않은 이유 ​

6. 핸드북 사용 시나리오 ​

6.1 신입 테스터의 첫날 ​

6.2 새로운 테스트 사이클의 시작 ​

6.3 사고 발생 시 ​

6.4 산출물 갱신 주기 ​

7. 핸드북 작성·운영 사이클 ​

7.1 챕터 단위 작성 사이클 ​

7.2 산출물 디렉토리 구조 제안 ​

7.3 핸드북 갱신 책임 ​

8. 우선 정비해야 할 환경 항목 ​

8.1 [P0] 5노드 /etc/hosts 일괄 정비 ​

8.2 [P0] 자원 명명 규칙·격리 정책 합의 ​

8.3 [P1] 비활성 자원 정리 ​

8.4 [P2] 시간 동기화 사내 NTP 도입 검토 ​

8.5 [P2] 노드 부하 분산 검토 ​

부록 A. 본 챕터에서 인용된 정찰 데이터 원본 (요약) ​

부록 B. 다음 챕터로의 인계 ​

부록 C. 참고 자료 ​

0. 이 핸드북이 무엇인가

0.1 한 줄 정의

0.2 누구를 위한 책인가

0.3 이 핸드북이 다루지 않는 것

1. 본 핸드북이 전제하는 환경

1.1 5노드 Proxmox 클러스터 — `pve-cl01`

1.2 IP 평면 분리 매트릭스

1.3 백엔드 인프라 분포 — TrueNAS·PBS·평면 매핑

1.4 데이터 수집 출처에 관한 메모

2. 정찰 데이터 첫 판독 — 무엇이 보이는가

2.1 [정상] 정족수와 클러스터 가용성

2.2 [위험] 자원 네이밍의 카오스 — 격리 합의 부재의 흔적

2.3 [위험] Corosync Ring1과 Storage 평면의 공유

2.4 [해소] 노드 간 SSH 호스트네임 해석 정비 — 핸드북 사용 첫 사례

정비 절차

정비 후 검증

잔여 정비 항목

2.5 [주의] 시간 동기화의 외부 의존

2.6 [참고] 노드별 uptime 분포 — 점진적 운영의 흔적

2.7 [참고] 노드별 부하 분포 — 작업 집중도의 단서

3. 정찰 철학 — Blast Radius와 Reversibility

3.1 Blast Radius — 영향 반경

3.2 Reversibility — 가역성

3.3 격자 매트릭스 — 위험도 합산

3.4 두 축의 적용 사례

4. 본 핸드북이 다루는 CMP 테스트 대분류

4.1 CRUD 기능 검증

4.2 스테이징 워크플로우(Staging Workflow)

4.3 위험 시나리오·에러 처리

4.4 클러스터 일관성

4.5 4분류 × 챕터 인덱스

5. 핸드북의 공통 본문 구조 (v2)

5.1 §4와 §5의 분리 이유

5.2 §3의 위치와 무게

5.3 본 챕터(00)에서 표준 구조를 따르지 않은 이유

6. 핸드북 사용 시나리오

6.1 신입 테스터의 첫날

6.2 새로운 테스트 사이클의 시작

6.3 사고 발생 시

6.4 산출물 갱신 주기

7. 핸드북 작성·운영 사이클

7.1 챕터 단위 작성 사이클

7.2 산출물 디렉토리 구조 제안

7.3 핸드북 갱신 책임

8. 우선 정비해야 할 환경 항목

8.1 [P0] 5노드 `/etc/hosts` 일괄 정비

8.2 [P0] 자원 명명 규칙·격리 정책 합의

8.3 [P1] 비활성 자원 정리

8.4 [P2] 시간 동기화 사내 NTP 도입 검토

8.5 [P2] 노드 부하 분산 검토

부록 A. 본 챕터에서 인용된 정찰 데이터 원본 (요약)

부록 B. 다음 챕터로의 인계

부록 C. 참고 자료