Skip to content

Latest commit

 

History

22 Commits

Folders and files

NameName
Last commit message
Last commit date
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 

Repository files navigation

kt66 — AI데이터센터 운영 교육 인프라

학생 1인당 서버 1대에 미니 AI데이터센터를 통째로 세운다. 망분리된 인프라, 가상 시설 계통(전력·냉방·소방·물리보안), GPU 추론 서비스, 그리고 각 층에서 일하는 근무자 에이전트까지 한 스택에 들어간다. 15주 교육과정(구축 → 운영 → 대응·자동화)의 실습 무대다.

베이스는 el34다. kt88 이 아니다. el34 에는 관리 포털(portal/), 에이전트 하네스(bastion/), 자동 채점·시나리오 주입 (assessor/)이 이미 있고 단일 호스트 구성이라 1인 1대 배정과 맞는다. kt88 은 3대 macvlan 확장판이라 이 용도에는 불필요한 복잡도가 된다. 다만 GPU 서버를 엔드포인트로 붙이는 방식은 kt88 의 접근을 이어받는다(아래 GPU 존).

el34 에서 무엇을 뺐고 무엇을 더했나

뺀 것 — 메모리를 크게 먹고 이 과정에 필요 없는 것들.

제거 사유
docker-compose.misp.yml TI 플랫폼. 보안 심화용이라 DC 운영 과정에 불필요
docker-compose.opencti.yml 〃 (단독으로 수 GB)
docker-compose.sysmon.yml + sysmon/ Windows 엔드포인트 계측용
Windows 엔드포인트 KVM + 수 GB 이미지. el34 에서도 보류 상태였다
docker-compose.ollama.yml 추론은 GPU 서버(DGX Spark)에서 돈다. 로컬 중복 불필요
docker-compose.override.yaml 특정 호스트 전용 오버라이드. 9200 포트를 열어 충돌을 낸다

더한 것

추가 내용
agents/ 런타임 중립 근무자 에이전트 스펙 + agentctl 렌더러
GPU 존 DGX Spark 를 WireGuard 로 랩 세그먼트에 편입
4층 물리 모델 시설 계통 + 층별 자산 배치 (시각화 UI 의 데이터 모델)
envsim/ 환경 시뮬레이터 — 시설은 가상, 부하는 실측
noc/ 관제 화면 — 건물·층·존·근무자·고장 주입이 한 페이지 안에
scenarios/ 시나리오 34종 선언 + validate.py (주입 대상이 자산 대장에 실재하는지 대조)
injector/ 고장 주입기 — IT 계통 38종(시스템·스토리지·네트워크·보안·부하)

층과 존 — 직교한다

층(floor)은 물리 배치, 존(zone)은 네트워크 보안등급이다. 같은 층 랙에 다른 존이 섞일 수 있고, 같은 존이 여러 층에 걸칠 수 있다. 이 어긋남 자체가 교보재다 — 물리적으로 옆자리인데 논리적으로 다른 망이라는 것을, 시각화 UI 에서 두 뷰를 겹쳐 보며 체감한다.

┌─ 4F  운영층 (NOC/SOC)  ────── 권한: mgmt / 망: dmz·ext·ot ───┐
│  ITSM · CMDB · portal · Wazuh 대시보드 · 런북                 │
│  근무자: 서비스데스크 · SOC분석가 · 운영리드 · 감사인            │
│  ▶ W4 자산/텔레메트리 · W6 ITSM · W8 중간평가                  │
│    W14 컴플라이언스 · W15 에이전트 자동화                      │
└──────────────────────────────────────────────────────────────┘
┌─ 3F  AI 전산실 (GPU Zone)  ────────────────── zone: app ─────┐
│  DGX Spark · 오픈모델 서빙(Ollama) · 추론 SLA · GPU 쿼터       │
│  근무자: GPU/플랫폼 엔지니어                                   │
│  ▶ W3 AI 워크로드 편입 · W7 쿼터·용량 · W12 GPU 장애           │
│  ※ 랙당 전력밀도가 다른 층의 5~10배 — 1F 와 직접 연동          │
└──────────────────────────────────────────────────────────────┘
┌─ 2F  일반 전산실 (Core/Service)  ──── zone: dmz / int / pipe ┐
│  fw · ips · web(WAF) · 취약 웹앱 6종 · SIEM · 백업             │
│  근무자: 네트워크 엔지니어 · 시스템/스토리지 엔지니어            │
│  ▶ W2 인프라 배포 · W9 변경관리 · W10 백업 · W11 보안운영       │
└──────────────────────────────────────────────────────────────┘
┌─ 1F  시설·보안층 (전부 가상)  ─────────────── zone: ot ──────┐
│  수전·UPS·PDU │ 냉동기·CRAC·핫/콜드아일 │ 소방 │ 출입·CCTV    │
│  근무자: 시설 담당 · 물리보안                                  │
│  ▶ W1 전력밀도·냉방 · W5 환경 모델링 · W13 환경 장애           │
└──────────────────────────────────────────────────────────────┘

        의존 방향: 1F ──▶ 2F/3F ──▶ 4F   (단방향)

이 배치의 값어치는 의존이 단방향이라는 데 있다. 아래층 장애는 위로 번지고 위층 장애는 국소적이다. 그래서 13주차 "환경 이상 → 시스템 장애 연쇄" 가 별도 장치 없이 구조에서 성립한다 — 1F 냉동기를 죽이면 3F GPU 가 스로틀링되고, 추론 SLA 가 깨지고, 4F 에 티켓이 생긴다.

존 체계

시안·타 제품의 Zone 0~3 을 빌려오지 않았다. kt66 의 실제 세그먼트가 곧 존이다. trust 는 "밖에서 얼마나 쉽게 닿는가"이지 "얼마나 중요한가"가 아니다 — 학생이 가장 자주 뒤집어 생각하는 지점이라 그렇게 정의했다. 정의는 envsim/assets.yamlzones: 하나뿐이고, 시뮬레이터·관제 화면·CMDB·시나리오가 전부 그것을 읽는다.

대역 trust 성격
ext 10.20.30.0/24 L0 인터넷 접점 · 공격자 단말 · 점프 호스트 진입
pipe 10.20.31.0/24 L1 fw ↔ ips 사이. 통과 트래픽만 있고 붙어 사는 서비스는 없다
dmz 10.20.32.0/24 L2 WAF · SIEM · 관리 포털
int 10.20.40.0/24 L3 업무 앱 백엔드. WAF 를 거치지 않으면 도달 불가
app 10.20.50.0/24 L3 GPU 존. 터널 너머 DGX Spark 도 이 존의 정식 구성원이다
ot 10.20.60.0/24 L3 · 격리 전력·냉방·소방·출입. ips 가 tcp/8000·ICMP 만 통과시킨다
mgmt L2 · 논리 kt66 에 별도 관리망은 없다. 권한 경계이지 망 경계가 아니다

mgmt 를 진짜 세그먼트로 만들지 않은 것은 게으름이 아니다. 관리 포털이 dmz 에 있으면서 관리 도구라는 어긋남을 감추지 않는 쪽을 골랐다. 관제 화면은 자산마다 zone(실제 붙어 있는 세그먼트)과 logical_zone(권한)을 따로 보여준다 — 1주차에 학생이 직접 부딪혀야 하는 지점이다.

존 사이를 건너는 길은 이것뿐이고, 우회로가 없다는 것이 이 랩의 핵심 성질이다.

ext ──fw──▶ pipe ──ips──▶ dmz ──web(WAF)──▶ int
              │
              ├──ips──▶ app   (터널 구간도 여기를 지난다)
              └──ips──▶ ot    (tcp/8000 · ICMP 만)

네트워크

el34 의 4-tier 를 그대로 계승한다. 패킷 흐름은 불변이다: attacker → fw → ips → web → 앱

대역 용도
ext 10.20.30.0/24 외부 — 공격자·bastion
pipe 10.20.31.0/24 fw ↔ ips 내부 회선
dmz 10.20.32.0/24 2F web(WAF) · SIEM · portal
int 10.20.40.0/24 2F 취약 웹앱 (외부 노출 없음)
app 10.20.50.0/24 3F GPU 존 — DGX Spark (WireGuard)

취약 웹앱은 web 의 Apache vhost 리버스 프록시로만 도달한다. 외부에서 직접 갈 수 없다.

GPU 존 — 왜 WireGuard 인가

DGX Spark 는 공인 IP(별도 회선)에 있고 랩 호스트는 NAT 뒤에 있다. 그래서

  • macvlan 불가 — 같은 L2 가 아니다
  • 단순 L3 라우팅 불가 — 랩 호스트가 인바운드를 못 받는다 (Wazuh 에이전트는 매니저로 나가는 방향인데, 그 목적지가 NAT 안이다)

WireGuard 는 NAT 를 통과하며 양방향 L3 를 만든다. DGX Spark 가 10.20.50.10 을 정식으로 갖고 그 트래픽이 fw/ips 를 지나므로, "모든 트래픽은 보안장비를 지난다"는 성질이 유지된다.

DGX Spark 는 aarch64(GB10)다. Wazuh 에이전트는 arm64 패키지가 4.10.x 부터 제공되므로 매니저(amd64 4.10.0)와 버전이 맞는다.

근무자 에이전트 — 런타임을 고른다

bastion 하나에 묶지 않는다. 페르소나는 중립 스펙으로 한 번 쓰고, 어댑터가 각 런타임으로 렌더한다. agents/roster.yaml 에서 페르소나마다 런타임을 지정한다.

cd agents
./agentctl list                        # 명단 + 층·존·런타임·자율성
./agentctl runtime soc-analyst hermes  # 런타임 교체
./agentctl render --all                # 각 런타임 형식으로 렌더
./agentctl diff facility-engineer      # 두 런타임 결과 비교 (W15 실습)
bastion Hermes Agent Claude Code
루프/스케줄 없음 cron/
메모리 KG(sqlite) memories/ + state.db
샌드박스 docker exec sandboxes/
다중 페르소나 하네스 있음 단일 subagent
외부 연동 자체 API hermes acp

12주(다역할 인시던트 대응)는 bastion 하네스가, 15주(루프 엔지니어링)는 Hermes 의 cron·메모리가 유리하다. 그래서 둘 다 둔다. 자세히는 agents/README.md.

배포

git clone https://github.com/mrgrit/kt66 && cd kt66
sudo ./kt66.sh install     # docker + daemon.json (최초 1회)
sudo ./kt66.sh up          # 16 컨테이너

수동으로 할 경우(호스트 systemd 를 건드리지 않는다):

cp .env.example .env && echo "WEB_HOST_IP=<이 서버 IP>" >> .env
ssh-keygen -t ed25519 -f keys/id_rsa -N ""
sudo ./kt66-hostip.sh                                   # 내부 GUI 용 dummy IF
sudo docker compose -f docker-compose.yaml up -d --build
sudo ./kt66-net.sh                                      # 인터-브리지 체인 글루

docker compose-f docker-compose.yaml명시한다. 생략하면 compose 가 같은 디렉터리의 override 파일을 자동 병합한다.

접속

내부 GUI 를 어느 인터페이스에 열지는 .envINT_HOST_IP 한 줄이 정한다.

192.168.136.145 (기본) el34 에서 물려받은 dummy NIC(NOARP, 어떤 케이블에도 안 붙어 있다). 이 호스트의 브라우저에서만 열린다 — 강의실 LAN 에서 SIEM·보안 콘솔이 안 보인다
서버의 실제 LAN IP 원격·강의실에서 열린다. 대신 SIEM·보안 콘솔까지 전부 노출된다

INT_HOST_IP 를 바꾼 뒤 fw ips web wazuh-dashboard portal envsim noc 을 재기동한다.

위치 주소 내용
관제 화면(NOC) http://${INT_HOST_IP}:8020/ 여기서 시작한다 — 건물·층·자산·근무자·고장 주입
관리 포털 http://${INT_HOST_IP}:8000/ 대시보드
SIEM https://${INT_HOST_IP}:5601/ Wazuh (HTTPS 다)
콘솔 GUI http://${INT_HOST_IP}:8081~8083/ nft / suricata / modsec
envsim API http://${INT_HOST_IP}:8010/ 환경 시뮬레이터(시설 10종)
injector API http://${INT_HOST_IP}:8030/ 고장 주입기(IT 38종)
웹 진입 (학생) http://${WEB_HOST_IP}/ , :8001~:8007 랜딩 + 취약 웹앱 6종 + AICompanion
bastion SSH ssh ccc@${WEB_HOST_IP} -p 2204 점프 호스트

격리를 유지한 채 원격에서 보려면 SSH 터널을 쓴다.

ssh -L 8020:192.168.136.145:8020 -L 5601:192.168.136.145:5601 ccc@<서버 LAN IP>

검증된 동작

x86_64 / Ubuntu 22.04 / i9-12900K·31GB 에서 실측.

항목 결과
컨테이너 16개 전부 기동
체인 attacker → 10.20.30.1(fw) → 10.20.31.2(ips) → 10.20.32.80(web)
웹 진입 랜딩 200 / juice 200 / DVWA 302 / 자체 취약앱 4종 200
내부 GUI portal 200 · nft 200 · suricata 200 · modsec 200
SIEM wazuh-control 데몬 10개 running
인덱서 _cluster/health = green
대시보드 https://…:5601 → 302 (로그인)
빌드 시간 최초 8분 26초 (캐시 적중 시 20초)

GPU 존 — DGX Spark(spark-1397, GB10/aarch64, 119GB 통합메모리) 실측.

항목 결과
터널 WireGuard 핸드셰이크 성립, 양방향 전송
GPU 존 체인 attacker → 10.20.30.1(fw) → 10.20.31.2(ips) → 10.20.50.2(gpu-gw) → 10.20.50.10(DGX)
RTT 랩 ↔ DGX 약 3ms
역방향 DGX → 랩 web HTTP 200, siem·ips 도달
추론 랩에서 10.20.50.10:11434/v1/chat/completionsHTTP 200 (22.3초)
모델 11종 조회 (solar:100b 62GB · EXAONE-4.5-33B · qwen3.6:35b 등)
자산 편입 Wazuh 에이전트 dgx-spark-01 (ID 004) Active, v4.10.4 arm64
DGX 기본 경로 보존 — 랩 대역만 터널, 인터넷은 자기 회선

환경 시뮬레이터 — 시설은 가상이지만 사용률은 실측이다(컨테이너 CPU + GPU 상태).

항목 결과
ENV-01 CRAC 정지 해당 아일 냉방 0kW, 온도 상승 개시, L10 항온항습기 정지
ENV-03 수전 상실 + 발전기 실패 L10 UPS 배터리 전환 · L13 발전기 기동 실패, 배터리 분당 1.13% 감소
부하 차단 판단 그룹별 kW · 차단 시 영향 · 끊었을 때 잔여 분 산출, 차단 반영 확인
SIEM 연동 경보가 syslog 로 Wazuh 매니저에 전달 — 환경 이상이 시스템 알림과 같은 화면에

전력은 대표 데이터센터 규모로 환산한다. 실제 랩은 1.5kW 남짓이라 "총 38kW 중 학습 job 18kW 를 끊을 것인가" 같은 판단 실습이 성립하지 않는다. 환산을 숨기지 않으려고 measured_kw(실측 원값)를 API 에 함께 노출한다. 환산의 입력인 사용률은 실측이므로, 3F 에 진짜 부하를 걸면 온도가 진짜로 오른다.

환경 시뮬레이터 APIhttp://192.168.136.145:8010

엔드포인트 용도
GET /state 층·아일 온습도, 전력, 경보, 부하 분석 전부 (UI 가 폴링)
GET /assets 자산 대장 원본 — 배치도 데이터 모델이자 CMDB 기준
GET /shed 부하 그룹별 소비 + 차단 시 영향 + 끊었을 때 잔여 시간
POST /inject?fault=&target= 강사용 고장 주입 (10종)
POST /shed?group= 부하 차단 — ENV-03 에서 학생이 내리는 판단
POST /timescale?value= 시간 배속 (0.1~120). 열 시나리오를 한 교시 안에 전개시킨다
POST /reset 전부 원복

수집 루프는 컨테이너 stats 를 one-shot 으로 동시에 받는다. stream=false 기본 동작은 docker 가 1초 간격 표본 두 개를 뜰 때까지 기다리므로, 자산 20개를 순차로 돌면 한 틱이 40초에 가까워지고 UPS 잔여 시간이 화면에서 멈춘 것처럼 보인다. 차분은 시뮬레이터가 직접 하므로 docker 가 기다려 줄 이유가 없다. envsim 은 ot 다리에서 ips 를 거쳐 GPU 존을 폴링한다 — 우회로를 뚫는 게 아니라 시설망 → GPU 존 트래픽도 검사 지점을 지나게 만드는 쪽이다.

관제 화면 (NOC)

http://${INT_HOST_IP}:8020/수업은 여기서 시작하고 여기서 끝난다.

규칙 1 — 화면은 상태를 만들지 않는다

전력·온도·경보는 전부 envsim 이 계산한 값을 그대로 그린다. 화면이 스스로 보간하거나 다듬기 시작하면 학생이 보는 숫자와 SIEM 에 남는 숫자가 갈라지고, 그 순간 교보재가 아니라 장식이 된다. noc/ 가 하는 일은 합성(envsim + roster + docker.sock) · 치환(${INT_HOST}) · 중계(주입/차단)뿐이다.

규칙 2 — 3D 장면 안에 글자를 넣지 않는다

이 화면을 한 번 갈아엎은 이유다. 아이소메트릭 좌표가 겹치면 글자도 겹치고, 나중에 그린 물건이 앞서 그린 글자를 덮는다. 그래서 층위를 나눴다.

층위 역할
장면(SVG) 모양과 색으로만 읽힌다. 글자 0개. 설비는 이름표 대신 픽셀 아이콘으로 구분한다
라벨층 장면 위에 마지막으로 얹는다. 서로 겹치면 밀어내고 지시선을 긋는다. 화면 배율과 무관하게 항상 같은 크기 — 장면과 같이 확대되면 글자가 장면을 덮는다
툴팁 커서를 따라다니며 전부 말해 준다. HTML 이라 절대 가려지지 않는다
레일·리프트 이름과 수치의 본진

화면 구성

영역 내용
리프트(좌) 층 이동. 층마다 온도·전력·존·경보등을 한 줄로 — 고개를 안 돌려도 어느 층이 아픈지 보인다
건물 뷰 4개 층을 대각으로 엇갈려 쌓는다. 존은 바닥의 색 구역 + 모서리 브래킷, 존 경계에는 게이트(fw·ips·web)가 선다
층 뷰 존 영역 · 게이트 · 핫/콜드 아일 · 랙 · 케이블 트레이 · 배전 모선 · 근무자 데스크
HUD(상) 전력 · UPS · 최고 온도 · 경보 · 가동 자산 · 근무자. 심각 경보가 뜨면 화면 가장자리가 붉게 맥동한다
레일(우) 전력 / 존 / 근무자 / 경보 / 로그
UPS 절체 패널 배터리로 넘어가면 자동으로 뜬다. 그룹별 소비 · 차단 시 영향 · 끊었을 때 잔여 분
강사 패널 고장 10종 주입/해제 + 시간 배속 + 전체 리셋

부피가 큰 설비(CRAC·발전기·UPS·냉동기)는 전부 벽면에 붙였다. 앞줄(x+y 가 큰 쪽)에 세우면 뒤의 랙과 자산을 통째로 가린다. 물건은 그리는 순서가 곧 앞뒤이므로 깊이순으로 정렬해 한 번에 붙인다 — 섹션별로 그리면 화면이 배치를 거짓말한다.

시간 배속이 필요한 이유. 유휴 랩은 발열이 12kW 남짓이라 냉동기를 죽여도 분당 0.2°C 밖에 안 오른다. 열 시나리오는 강사가 ×10 이상으로 당겨야 한 교시 안에 전개된다. 반대로 ENV-03(UPS 절체)은 "몇 분 안에 무엇을 끌 것인가" 가 실습의 본체이므로 ×1 로 둔다. 배속이 걸리면 상단에 시간 ×N 이 뜬다 — 화면의 시간과 벽시계가 다르다는 사실을 숨기지 않는다.

현재 상태

  • el34 → kt66 fork · 불필요 스택 제거 · 개명(116파일)
  • 16 컨테이너 기동 + 체인 검증
  • 근무자 에이전트 중립 스펙 + agentctl (bastion / hermes / claude)
  • GPU 존 — WireGuard 터널 + DGX Spark 편입 (10.20.50.10, Wazuh Active)
  • 환경 시뮬레이터 — 1F 시설 계통 + 경보 15종 + 부하 차단 판단
  • 존 체계 확정 (zones / zone_chainassets.yaml 단일 정의로)
  • 4층 관제 화면 (noc/) — 건물·층 뷰 · 접속 · UPS 판단 · 강사 패널
  • 시나리오 34종 → scenarios/*.yaml + 검증기 (주입 가능 19 · 일부 6 · 미구현 9)
  • 고장 주입기 48종 — 시설(OT) 10 + IT 38, 전 종목 주입→원복 왕복 검증
  • 채점 (assessor/provisioner 활성화)
  • 시나리오 planned 9종의 선결 과제 세 가지 — 3F 학습 워크로드(INC-06/DR-02/ENV-03ai-training), DGX GPU 지표 exporter(GPU-01/GPU-02), ITSM·백업 잡(INC-02/INC-08)
  • cascade 자동 발생 — 지금 실제로 연쇄하는 것은 ENV-03 하나뿐이다

README.el34-inherited.md 는 el34 원본 문서다 — 이관 과정 참고용으로만 남겨 둔다.

고장 주입 — 48종

강사 패널(관제 화면 우상단)에서 클릭 한 번으로 넣는다. 두 서비스가 나눠 갖는다.

영역 어디에 대표
시설 · 환경(OT) 10 envsim 수전 상실 · 발전기 기동 실패 · 냉동기 정지 · 연기 감지
시스템 · 프로세스 7 injector 정지 · SIGKILL · freeze · 재시작 루프 · CPU 기아 · OOM · 존 분리
스토리지 · 디스크 5 디스크 채움 · 주기적 쓰기 · 로그 폭주 · inode 소진 · 증적 훼손
네트워크 8 손실 · 지연 · 링크 플랩 · 대역 제한 · MTU 축소 · DNS · 블랙홀 · 포트 차단
보안 12 스캔 · SQLi · 무차별대입 · 유출 · C2 비컨 · 측면이동 · OT 탐침 · 무승인 룰 변경
부하 · 성능 6 CPU · IO · HTTP 폭주 · 백엔드 지연 · 추론 부하(DGX) · 커넥션 고갈

왜 두 서비스인가. envsim 은 물리 시뮬레이터이고 injector랩을 실제로 조작하는 서비스다. 물리 엔진에 docker.sock 쓰기 권한을 주면 역할이 뒤섞이고, 시뮬레이션 버그가 인프라를 망가뜨리는 경로가 생긴다. 강사는 그 구분을 알 필요가 없어서 관제 화면이 둘을 하나의 패널로 합친다.

안전장치

원복이 주입보다 중요하다 state 형은 짝이 되는 revert 를 갖고 TTL 이 지나면 자동으로 풀린다. 수업이 끝났는데 앞 조의 고장이 남아 있으면 다음 조는 존재하지 않는 장애를 쫓는다
화이트리스트만 카탈로그에 없는 id 는 실행되지 않고 임의 명령 입구가 없다. 대상도 주입마다 정해진 목록 안에서만
조종간은 못 끈다 관제 화면과 주입기 자신은 대상에서 제외
되돌릴 수 없는 것은 스냅샷 증적 삭제·인증서 만료처럼 '되돌리면 안 되는' 것이 교보재인 경우에도 원본을 떠 두고 강사가 복구할 수 있게 한다
기동 시 정리 앞 세션이 비정상 종료했을 수 있다 — 남은 netem·nft 테이블·배경 프로세스·paused 컨테이너를 걷어낸다

주입·해제는 syslog 로 SIEM 에 나간다. 강사의 조작도 사건이고, 학생이 보는 타임라인에 같이 남아야 상관분석이 성립한다.

검증

전 48종을 자동으로 훑어 주입 → 효과 확인 → 해제 → 원복 확인까지 돌렸다.

항목 결과
왕복 성공 38/38 (IT 계통) · 시설 10종은 envsim 절에서 별도 검증
proc_pause paused → 해제 후 running
net_delay tc qdisc … netem delay 400ms 확인 → 해제 후 noqueue
net_portblock tcp dport 8001 … drop 룰 생성 → 해제 후 테이블 0개
sec_otprobe ips ext->ot DROP 카운터 0 → 206
load_cpu envsim 실측 util 0.00 → 0.75 → 해제 후 0.00, 배경 프로세스 0개
보호 대상 kt66-noc 주입 시도 → 거부
대상 화이트리스트 허용되지 않은 대상 → 거부 + 가능 목록 안내

실측 사용률 정규화를 함께 고쳤다. d_total/d_sys 는 호스트 전체 대비 비율이라 24스레드 머신에서 코어 2개를 완전히 태워도 0.083 이 나왔다. 그 값으로는 "이 서버가 얼마나 부하를 받는가"를 말할 수 없어 부하 시나리오가 성립하지 않는다. 코어 수로 환산한 뒤 자산 1대의 상정 코어 수(CORES_PER_ASSET, 기본 4)로 나눈다.

About

AI데이터센터 운영 교육 인프라 — el34 기반. 망분리 + 가상 시설계통(전력·냉방·소방·물리보안) + GPU 추론 + 층별 근무자 에이전트(bastion/hermes/claude 선택)

Topics

Resources

Stars

0 stars

Watchers

0 watching

Forks

Releases

Packages

Contributors

Languages