0. 본 챕터의 성격 — 협의 의제 챕터
본 챕터는 다른 챕터와 성격이 다르다. 현 시점에서 우리 테스트팀 단독으로 결론 내릴 수 없는 영역을 다루기 때문이다. 1~3장과 5~7장의 정찰에서 식별된 스토리지 관련 항목 중, 다음 조건에 해당하는 것이 본 챕터로 모인다.
- 격자 L3 이상: 단일 노드 또는 클러스터 전체 영향
- 격자 R3 이상: 부분 가역 또는 비가역
- 타 테스터 자원 또는 공유 자원: 우리 팀 단독 판단 금지
이 조건들은 챕터 08 §1.3에서 이미 "합의 필수" 영역으로 분류된 것과 일치한다. 챕터 04는 그 합의가 진행될 회의의 사전 준비 문서.
0.1 협의 회의 기본 정보 (예정)
| 항목 | 값 |
|---|---|
| 협의 일자 | 2026-04-27 (예정) |
| 협의 형태 | 개발팀 + 우리 팀, 필요 시 운영팀 합류 |
| 예상 소요 | 60분 |
| 산출물 | 본 챕터의 §3 의제별 결정 + 후속 수행 책임 분배 |
| 성공 기준 | P0 5건 중 P0-B(CMP 라우팅) + P0-D(testerA 영역) 결정 |
0.2 본 챕터의 갱신 흐름
[현 상태] 1차 작성 — 협의 의제 챕터 (status: agenda-pending-meeting)
↓ 협의 회의 수행
↓
[2026-04-27] 협의 결과 수령 후 본 챕터 대폭 개정
↓
[차후] "스토리지 자원 관리 정책" 챕터로 재작성
↓ status: active
↓
[갱신] 신규 스토리지 등록 시 본 챕터 정책 참조따라서 본 챕터의 1차 작성본은 협의 후 대부분 폐기 또는 흡수될 것을 전제로 한다. 본 챕터를 일반 챕터처럼 정착된 정책으로 인용하지 않도록 주의.
0.3 본 챕터가 통합하는 미결 항목
| 출처 | 항목 | 본 챕터 § |
|---|---|---|
| 챕터 03 §2.6 | NFS alias chaos — testerC 데이터가 testerB 이름 경로 | §3.2 의제 2 |
| 챕터 03 §2.7.4 | nd07 NFS 마운트 평면 이전 | §3.4 의제 4 |
| 챕터 03 §2.4.3 | ARC c_max 1 GiB 튜닝 주체·근거 | §3.5 의제 5 |
| 챕터 03 §2.5.4 | 빈 VG vg, lvm-test-testerC | §3.6 의제 6 |
| 챕터 05 §2.7 | CMP 요청 nd01 집중 — 라우팅 설계 의도 | §3.1 의제 1 |
| 챕터 05 §2.10 | iSCSI mgmt 평면 세션 (nd02·nd04) | §3.4 의제 4 |
| 챕터 06 §2.13 | ciuser 회사 정보 노출 — CMP 프로비저닝 정책 | §3.7 의제 7 |
| 챕터 06 §2.7 | VM 112 작성자 추적 — admin01 동시 확인 | §3.8 의제 8 |
| 챕터 06 §2.8 | VM 802 마이그레이션 중단 처분 | §3.8 의제 8 |
| 챕터 07 §2.5 | admin01@pve 공용 계정 사용 정황 | §3.9 의제 9 |
| 챕터 07 §2.5 | test_yhkim@pve 신규 사용자 | §3.9 의제 9 |
| WorkLog 2026-04-24 §5 | iSCSI 유령 LUN — testerA 영역 정리 | §3.3 의제 3 |
총 12건. 회의 60분 안에 모두 다룰 수 없으므로 §2에서 우선순위 분류.
1. 회의 진행 가이드
1.1 회의 운영 원칙
- 각 의제는 우리 팀이 사전 작성한 §3의 구조 그대로: 배경 → 질문 → 우리 팀 제안 → 결정 필요 시점
- 결정은 회의에서 내릴 것: 추후 확정으로 미루지 않는다 (P0 항목은 STN 일정상 여유 없음)
- 결정 안 되면 분기 시나리오 명시: "타팀 답변 보류 시 우리 팀이 어떻게 진행할지" 명시
- 회의록은 본 챕터에 직접 추가: §4가 회의 후 채워질 자리
1.2 회의 시간 분배 제안 (60분)
| 시간 | 의제 | 비고 |
|---|---|---|
| 5분 | 회의 개요 + 우선순위 합의 | §2 검토 |
| 25분 | P0 의제 (3건) | 의제 1, 2, 3 |
| 20분 | P1 의제 (3건) | 의제 4, 5, 8 |
| 5분 | P2 이하 의제 일괄 처리 | 의제 6, 7, 9 |
| 5분 | 후속 책임 분배 + 다음 회의 일정 | §4 작성 |
P1·P2 의제 중 회의 중에 결론이 안 나는 항목은 후속 비동기 처리 (Slack 또는 별도 단독 회의).
1.3 회의 전 사전 공유
본 챕터를 회의 24시간 전 참석자에게 공유. 사전 검토 완료 가정 하에 회의를 효율적으로 진행. 우리 팀이 의제별로 이미 제안을 갖고 있다는 사실을 알림으로써 회의가 "토론"이 아닌 "결정"의 자리가 되도록 유도.
2. 의제 우선순위
2.1 P0 (회의 핵심 — 결정 못 하면 STN 지연 또는 결과 왜곡)
| # | 의제 | 격자 | 결정 시점 |
|---|---|---|---|
| 1 | CMP 요청 라우팅 설계 의도 | L4×R1 | 회의 종료 |
| 2 | NFS alias chaos 매핑 정리 책임 | L2×R4 | 회의 종료 |
| 3 | iSCSI 유령 LUN testerA 영역 정리 | L3×R2 | 회의 또는 testerA 응답 즉시 |
2.2 P1 (회의에서 합의 후 후속 실행)
| # | 의제 | 격자 | 결정 시점 |
|---|---|---|---|
| 4 | NFS·iSCSI 평면 이전 (mgmt → storage) | L3×R2 | 회의 + 후속 |
| 5 | ARC c_max 1 GiB 튜닝 정책 합의 | L3×R2 | 회의 |
| 8 | VM 112·802 처분 결정 | L2×R3 | 회의 (admin01 참석 가정) |
2.3 P2 (시간 허용 시)
| # | 의제 | 격자 | 결정 시점 |
|---|---|---|---|
| 6 | 빈 VG vg, lvm-test-testerC 정리 | L2×R3 | 회의 또는 비동기 |
| 7 | ciuser 회사명 파생값 정책 | L3×R2 | CMP 프로비저닝 단계에서 |
| 9 | 공용 관리자 계정 admin01 + 신규 test_yhkim | L3×R2 | 회의 |
3. 의제 상세
3.1 의제 1 — CMP 요청 라우팅 설계 의도 (P0)
배경
챕터 02 §2.6에서 5노드 모두에 cmp.jar가 실행 중임을 확인. 챕터 05 §2.7에서 실제 ESTAB 연결은 nd01에 9건, 나머지 4노드에 각 1건(자기 자신)뿐임을 확인. 5노드 분산 실행이라는 외형과 nd01 단일 처리라는 실제가 모순.
chapter 02: 5 nodes × cmp.jar process → "분산 실행"
chapter 05: nd01 ESTAB 9, others 1 → "nd01 집중"이 모순은 다음 세 가능성 중 하나로 해석된다.
(a) 의도된 active-passive 설계 (nd01이 active, 나머지는 standby) (b) 분산 의도가 있으나 로드밸런서 미구현 (c) 테스터들이 임의로 nd01 IP를 하드코딩하여 사용
우리 팀에게 미치는 영향
- STN 시나리오 4.4의 "5노드 분산 처리 검증"이 의미를 잃을 수 있음: 분산 자체가 없다면 검증 대상 자체가 부재
- nd01 장애 시 CMP 서비스 전면 중단 (HA 효과 없음)
- 테스트 결과의 노드 편향 (모든 요청이 nd01-local에서 처리됨)
개발팀에게 던질 질문
- CMP의 5노드 실행은 (a)/(b)/(c) 중 어느 것에 해당하는가?
- 분산 의도가 있다면, 로드밸런서·DNS RR·CMP 내부 라우팅 중 어느 메커니즘이 계획되어 있나?
- 현재 nd01 집중이 (b) 또는 (c)라면, STN 전 분산이 활성화되는가, 아니면 STN 후 별도 작업인가?
- CMP가 요청 처리 노드를 응답 헤더 또는 UI에 표시하는가? 디버깅 시 추적 가능한가?
우리 팀의 제안 분기
제안 A — 분산이 설계 의도이고 STN 전 활성화 가능 → 활성화 후 챕터 05 §2.7 패턴이 사라지는지 재검증
제안 B — 분산이 설계 의도이나 STN 전 활성화 불가 → STN 중 수동 분산 검증 (챕터 08 §4.3 — 각 테스터가 다른 노드 IP로 접속). 단, 상태 일관성 크로스 체크 필요 (5노드 CMP가 같은 상태를 보고 있는지)
제안 C — active-passive 설계 (nd01 단독 처리) → HA 설계를 active-passive로 명문화. STN 시나리오에서 "분산 처리 검증" 제외, 대신 "nd01 장애 시 다른 노드로 페일오버" 시나리오 수립 → standby 노드의 cmp.jar는 자원 낭비이므로 standby 인스턴스는 정지하거나 systemd unit으로 stopped 상태 유지가 더 정상적
제안 D — 테스터 임의 사용 (구현 미완) → CMP 프로젝트 일정에 분산 또는 active-passive 정책 명문화를 우선순위 P0로 등재
결정 필요 시점
STN 전 (3일 이내). 결정 안 되면 STN 시나리오 4.4 자체를 보류해야 함.
후속 (회의 후 갱신 자리)
[ ] 답변 수령: ___
[ ] 채택 제안: A / B / C / D
[ ] 후속 작업: ___
[ ] 담당: ___
[ ] 기한: ___3.2 의제 2 — NFS alias chaos 매핑 정리 책임 (P0)
배경
챕터 03 §2.7.1에서 발견. 5노드의 NFS 마운트 alias가 작성자와 일치하지 않음.
| storage.cfg ID | 실제 마운트 경로 | 실 사용자 | 의제 |
|---|---|---|---|
nfs-test-testerB | /mnt/pve/nfs-test-testerB/ | testerC | 이름과 사용자 불일치 |
nfs-test-testerC | /mnt/pve/nfs-test-testerC/ | testerD | 이름과 사용자 불일치 |
nfs-test-testerD | /mnt/pve/nfs-test-testerD/ | (불명) | 추적 필요 |
nfs-test-testerE | /mnt/pve/nfs-test-testerE/ | (자원명에 0420만, 작성자 미상) | 추적 필요 |
위험
- 누군가
pvesm remove nfs-test-testerB를 단독 실행하는 순간, 실제로는 testerC의 데이터 마운트 경로가 사라진다 - L2×R4 영역 (단일 자원 변경 + 비가역 가능)
- 잘못된 매핑 상태에서 STN 진입 시 누구든 트리거 가능
개발팀·운영팀에게 던질 질문
- 이 매핑을 현 상태로 운영하면서 정리하지 않는 것이 가능한가? 또는 STN 전에 정리해야 하는가?
- 정리한다면 책임은 우리 팀(테스트팀)인가, 운영팀인가?
- 정리 방법:
- (a) 이름을 실 사용자에 맞게 일괄 rename (별칭만 변경, 데이터 보존)
- (b) 새 이름으로 추가 마운트 후 기존 alias 삭제 (마운트 경로 변경)
- (c) 현 상태 유지 + 각 테스터에게 매핑표 명시 공유 (실제 데이터 변경 없음)
우리 팀의 제안
제안 (c) — 현 상태 유지 + 매핑표 명시 공유:
근거:
- (a)는 storage.cfg 편집 (L3×R2). 회의 합의 필요한데 일정 빠듯
- (b)는 데이터 마이그레이션 발생 (L3×R3). STN 전 시간 부족
- (c)는 실제 변경 없음 — 매핑표만 우리 팀이 만들고 Slack 채널 pinned. 즉시 가능
- STN 후 (a) 또는 (b)로 정식 정리
(c)의 구체 실행:
- 우리 팀이 매핑표 1페이지 작성 (이미 챕터 03 §2.7.1에 있음)
- Slack 전체 채널에 pinned + 회의 직후 공유
- 매핑표를 가공하여
pvesm remove명령 차단 안내문도 pinned
결정 필요 시점
회의 종료 (회의 직후 즉시 매핑표 공유 가능해야 함).
후속
[ ] 채택 제안: a / b / c
[ ] 매핑표 공유 (제안 c 채택 시): Slack 링크 ___
[ ] 후속 정리 일정 (제안 a/b 채택 시): ___3.3 의제 3 — iSCSI 유령 LUN testerA 영역 정리 (P0)
배경
챕터 03 §2.1.2 + 챕터 07 §2.4 + WorkLog 2026-04-24 §5에서 추적.
5노드 iSCSI 에러 45만 건/일. 원인 진단은 WorkLog 2026-04-24-iscsi-multi-storage-provisioning §4·§5에서 완료. 본 의제에서는 testerA 영역의 정리에 대한 동의 확보만 다룬다.
testerA의 고아 자원:
- truenas-iscsi-testerA (storage.cfg에 등록됨, target은 TrueNAS에 없음)
- cmptest-iscsi-window-testerA (동일)
- cmptest-truenas-iscsi-filebrowser-testerA (동일)이 3건이 5노드의 iscsid에서 매초 재접속 시도를 유발.
우리 팀의 제안 분기
제안 A — testerA 직접 정리 동의 후 우리 팀 대행:
- testerA가 자기 자원이 더 이상 필요 없음을 확인
- 우리 팀이
pvesm remove3건 +iscsiadm -o delete5노드 정리 - 격자 L3×R3 (storage.cfg 편집 + 노드별 initiator DB 변경)
제안 B — testerA 본인 정리:
- testerA에게 정리 요청 + WorkLog §5.3 명령 가이드 제공
- testerA가 직접 수행 후 결과 확인
제안 C — 임시 우회 (testerA 응답 보류 시):
pvesm set --disable3건 (storage 비활성화)- iscsid 재접속은 멈추되 storage.cfg에는 남음 (R2 — 가역)
- testerA 응답 도착 후 실제 삭제 수행
회의 시점에 고려할 변수
- testerA가 회의 참석 가능한가?
- testerA 응답을 회의 전에 받을 수 있나? (Slack 사전 질의 효과)
결정 분기
[testerA 회의 참석] → 제안 A 즉시 합의 + 회의 후 수행
[testerA 미참석, Slack 응답 있음] → 제안 A 또는 B
[testerA 응답 보류] → 제안 C (임시) + 응답 대기 후 정식 정리결정 필요 시점
회의 종료 또는 testerA 응답 즉시.
후속
[ ] testerA 회의 참석: yes / no
[ ] testerA 응답 상태: 수령 / 보류
[ ] 채택 제안: A / B / C
[ ] 수행 일시: ___
[ ] 수행자: ___
[ ] STN 전 ERROR 레이트 재측정 결과: ___3.4 의제 4 — NFS·iSCSI 평면 이전 (mgmt → storage) (P1)
배경
챕터 03 §2.7.3에서 NFS 마운트가 mgmt 평면(10.99.10.X)으로 흐르는 사례 발견. 챕터 05 §2.10에서 iSCSI 세션도 동일 패턴.
| 노드 | NFS mgmt 평면 마운트 | iSCSI mgmt 평면 세션 |
|---|---|---|
| nd02 | (해당 시 발견) | 1건 (.10.16:3260) |
| nd04 | (해당 시 발견) | 1건 (.10.16:3260) |
| nd07 신규 | 마운트 자체가 mgmt 경유 | — |
평면 분리 설계가 trắng tự thiết kế nhưng vận hành phá vỡ 상태. 단어가 헷갈렸네 — "설계는 분리, 운영은 혼용" 상태.
위험
- mgmt 평면 트래픽 잠식 → Web UI·SSH 응답 저하 가능
- nd02 100 Mbps 링크 사고와 결합되면 nd02 mgmt 평면이 추가 부하로 마비
- nd07의 mgmt 경유 NFS는 storage IP가 활성화되어 있는데도 사용되지 않는 자원 낭비
우리 팀의 제안
제안 A — 일괄 이전 (개발팀·운영팀 협조):
- 영향 VM의 NFS 마운트 경로 일시 unmount → storage 평면 IP로 재마운트
- iSCSI 세션 logout → storage 평면 IP로 다시 login
- 격자 L3×R2
제안 B — 점진 이전 (신규부터):
- 기존 평면 혼용 자원은 그대로 두고
- 신규 등록 시 storage 평면 IP만 사용 규약 합의
- 시간이 지나면서 자연 정리
결정 시점
회의 또는 후속.
후속
[ ] 채택 제안: A / B
[ ] 영향 자원 목록: ___
[ ] 이전 일정: ___3.5 의제 5 — ARC c_max 1 GiB 튜닝 정책 (P1)
배경
챕터 03 §2.4.3에서 발견. 5노드 모두 ZFS ARC c_max가 1073741824 (1 GiB)로 명시 튜닝됨. Proxmox 기본값은 시스템 메모리의 50%인데, 본 환경(노드당 30 GiB)에서는 기본값 ≈ 15 GiB. 즉 수동으로 1/15로 축소.
이 튜닝의 가능한 근거:
- CMP가 RAM을 많이 쓰므로 ARC를 줄여 게스트 메모리 확보
- 과거 ARC 메모리 압박 사고 발생 후 보수적 설정
- TrueNAS가 별도로 캐싱하므로 PVE 측 ARC 최소화
- 누군가
/etc/modprobe.d/zfs.conf에 박았는데 근거를 모름
챕터 07 §2.11에서 OOM Killer 0건 확인. 즉 현재 운영에서는 안전. 하지만:
- 효과적이라는 사실 ≠ 근거가 맞다는 사실
- 향후 변경 필요 시 기준점이 없음
개발팀에게 던질 질문
- 본 튜닝의 결정 시점·결정자·근거 문서가 어디에 있나?
- 1 GiB 값은 고정 정책인가, 검토 가능한가?
- STN 중 ARC 메모리 압박 신호 발생 시 누가 조정 권한을 갖나?
우리 팀의 제안
제안 A — 현 정책 유지 + 근거 문서화:
- 1 GiB 유지
- 근거를 핸드북 챕터 04 또는 별도 정책 문서에 명시
- 변경 권한자 명시
제안 B — 값 자체 재검토:
- 1 GiB가 너무 보수적일 수 있음. 4~8 GiB로 상향 후 모니터링
- ARC hit ratio 측정 기반 결정
결정 시점
회의 + 후속 모니터링.
후속
[ ] 결정자 확인: ___
[ ] 근거 확인: ___
[ ] 채택 제안: A / B
[ ] 변경 권한: ___3.6 의제 6 — 빈 VG vg, lvm-test-testerC 정리 (P2)
배경
챕터 03 §2.5.4에서 발견. 빈 LVM Volume Group 2개:
VG 'vg': 0 LV — 누구의 것인지 미상
VG 'lvm-test-testerC': 0 LV — testerC 작성 추정 (이름 기준)우리 팀의 제안
lvm-test-testerC: testerC에게 확인 후 본인이 정리 (Slack 1건)vg: 개발팀 또는 운영팀 확인 (이름이 너무 generic해서 origin 추적 어려움)
결정 시점
회의 또는 비동기.
3.7 의제 7 — ciuser 회사 정보 노출 (P2)
배경
챕터 06 §2.13. cloud-init ciuser 값이 사내 도메인 파생어로 다수 VM에 박힘. CMP가 자동 프로비저닝하는 VM도 동일 패턴 가능.
우리 팀의 제안
- CMP 프로비저닝 시 ciuser 기본값을 **일반명(
ubuntu,admin,cmp-user)**으로 변경 - 기존 VM은 소급하지 않음 (운영 영향)
결정 시점
CMP 개발 단계에서 반영. 회의에서는 요청만 전달.
3.8 의제 8 — VM 112·802 처분 (P1)
배경
- VM 112: 챕터 06 §2.7. 작성자 미상 + 3일 고부하 + Slack 질의 24시간 응답 대기
- VM 802: 챕터 06 §2.8 + 챕터 07 §2.6. admin01이 마이그레이션 시도 후 8일 방치
우리 팀의 제안
VM 112:
- 회의에서 admin01 또는 개발팀에게 "이거 누구 거?" 직접 질의
- 응답 있으면 즉시 처분 또는 보존 결정
- 응답 없으면 추가 24시간 대기 후 처분 보류 유지 (절대 단독 삭제 금지)
VM 802:
- 챕터 07 §2.6의 로그 모순(admin01이 OK로 종료했으나 incoming 잔존)을 admin01에게 확인 요청
- admin01 동의 후
qm stop 802 --force(프로세스만 종료, 디스크 보존) - 디스크 보존 상태에서 추가 분석 → 이후 정식 처분
결정 시점
회의 (admin01 참석 가정).
3.9 의제 9 — 공용 관리자 계정 + 신규 사용자 (P2)
배경
- admin01@pve: 챕터 07 §2.5. 다수 사용자가 공유 사용 정황. 감사 추적 불가
- test_yhkim@pve: 챕터 07 §2.5. userMemories에 없는 신규 계정. 신원 미확인
우리 팀의 제안
- admin01 사용 현황 확인. 누가 언제 어떤 작업에 쓰는지 매핑 필요
- 장기적으로 공용 계정 폐기 + 각자 개인 계정 사용 권고
- test_yhkim의 정체 확인 (새 테스터인가, 보조 계정인가)
- 신규 테스터라면 챕터 10 §12 온보딩 체크리스트 시작 권고
결정 시점
회의 + 후속.
4. 회의 결과 기록 (회의 후 채워지는 자리)
4.1 의제별 결정
| # | 의제 | 채택 제안 | 후속 담당 | 기한 |
|---|---|---|---|---|
| 1 | CMP 라우팅 | |||
| 2 | NFS alias | |||
| 3 | iSCSI testerA | |||
| 4 | 평면 이전 | |||
| 5 | ARC 튜닝 | |||
| 6 | 빈 VG | |||
| 7 | ciuser | |||
| 8 | VM 112·802 | |||
| 9 | 공용 계정 |
4.2 회의 후 본 챕터 갱신 작업
회의 24시간 내 수행:
- [ ] 본 챕터 §3 의제별 §"후속" 섹션 업데이트
- [ ] §4.1 표 완성
- [ ] 본 챕터 status를
agenda-pending-meeting→meeting-completed로 변경 - [ ] 새 챕터 04 작성 — "스토리지 자원 관리 정책": 본 챕터의 결정 사항을 정책 문서로 재구성. 본 1차 작성본은 갱신 이력으로 보존.
4.3 다음 회의 일정 (필요 시)
- 다음 회의 일자: ___
- 의제: 본 회의에서 결론 보류된 항목
5. 본 챕터의 한계
5.1 본 챕터는 정찰 챕터가 아니다
01~03·05~07이 정찰·해부 중심이었다면, 본 챕터는 거버넌스(governance) 영역. 다른 챕터처럼:
- §2 정찰 명령과 출력 해석 — 없음 (이미 다른 챕터에 있음)
- §3 출력의 비정상 패턴 — 없음 (해석은 다른 챕터 인용으로 대체)
- §4 이 영역의 CMP 테스트 시나리오 — 없음 (정책 합의 이전 단계)
본 챕터는 다른 챕터들과 구조 자체가 다르다. 1차 작성 후 회의 결과를 반영해서 재작성될 때 정상 챕터 구조로 변환된다.
5.2 회의 결과에 따른 챕터 04 분기
회의 결과에 따라 본 챕터의 운명이 달라진다.
시나리오 A — 결정 완료:
- §4 회의 결과 기록
- 본 챕터를 폐기하고 새 챕터 04 "스토리지 자원 관리 정책" 작성
- 본 1차 작성본은
04-storage-resource-management.agenda.md로 보존 (히스토리)
시나리오 B — 결정 보류:
- 본 챕터 status를
meeting-1-completed-pending-decision로 변경 - 다음 회의까지 본 챕터 유지
- 결정 완료 후 시나리오 A 절차
시나리오 C — 회의 무산 또는 합의 실패:
- 본 챕터 status를
meeting-blocked로 변경 - 우리 팀 단독 진행 가능 항목만 추출 → 별도 WorkLog로 처리
- 합의 가능 시점까지 챕터 04는 본 1차 작성본 상태 유지
6. 본 챕터에서 발견된 항목
본 챕터는 새 정찰을 하지 않았으므로 새로 발견된 항목은 없다. 다만 1~7장에서 흩어진 12건을 의제 9건으로 통합·우선순위화한 자체가 산출물.
부록 A. 회의 자료 1페이지 요약 (회의 직전 출력용)
╔══════════════════════════════════════════════════════════════════════╗
║ ║
║ 스토리지·운영 협의 회의 — 의제 요약 (1페이지) ║
║ ║
╠══════════════════════════════════════════════════════════════════════╣
║ ║
║ P0 (회의 핵심) ║
║ ───────────────────────────────────────────── ║
║ 1. CMP 라우팅 설계 의도 (5노드 분산? nd01 단독?) ║
║ 2. NFS alias chaos 매핑 정리 책임 ║
║ 3. iSCSI 유령 LUN testerA 영역 정리 ║
║ ║
║ P1 (합의 후 후속) ║
║ ───────────────────────────────────────────── ║
║ 4. NFS·iSCSI 평면 이전 (mgmt → storage) ║
║ 5. ARC c_max 1 GiB 튜닝 정책 ║
║ 8. VM 112·802 처분 ║
║ ║
║ P2 (시간 허용 시) ║
║ ───────────────────────────────────────────── ║
║ 6. 빈 VG `vg`, `lvm-test-testerC` ║
║ 7. ciuser 회사명 파생값 정책 ║
║ 9. admin01 공용 계정 + test_yhkim 신규 사용자 ║
║ ║
╠══════════════════════════════════════════════════════════════════════╣
║ ║
║ 성공 기준: P0 3건 결정 + P1 3건 후속 책임 분배 ║
║ 소요 예상: 60분 ║
║ ║
╚══════════════════════════════════════════════════════════════════════╝부록 B. 의제별 사전 참조
| 의제 | 본 핸드북 참조 | WorkLog 참조 |
|---|---|---|
| 1 | 챕터 02 §2.6, 챕터 05 §2.7 | — |
| 2 | 챕터 03 §2.7.1 | — |
| 3 | 챕터 03 §2.1.2, 챕터 07 §2.4 | 2026-04-24 §5 |
| 4 | 챕터 03 §2.7.3, 챕터 05 §2.10 | — |
| 5 | 챕터 03 §2.4.3 | — |
| 6 | 챕터 03 §2.5.4 | — |
| 7 | 챕터 06 §2.13 | — |
| 8 | 챕터 06 §2.7·§2.8, 챕터 07 §2.6 | — |
| 9 | 챕터 07 §2.5 | — |
상태: 본 챕터는
agenda-pending-meeting상태이다. 회의 후 본 챕터는 대폭 개정되어 "스토리지 자원 관리 정책"으로 재작성된다. 1차 작성본은 핸드북의 회의 의제 형식 챕터의 첫 사례로 보존 가치가 있다.