---
document_id: PLAI_RESILIENCE_NODE_ROLE_CANDIDATES
schema_version: 1
status: CANDIDATE_ONLY_NO_ACTIVATION
limited_control_plane_changes_applied: true
node_role_activated: false
---

# PC node 역할 배치 후보

> 2026-08-05 운영자 방향 정정: 아래 PC별 표는 초기 capability canary와 failure-domain 관찰 자료다. 특정 PC를 영구 standby server로 지정하는 production topology가 아니다. 최종 목표는 hostname allowlist 없이 적격 노드가 signed capability lease에 따라 storage, RPC, stateless service, recovery 역할을 동적으로 획득·반납하는 permissionless node pool이다. 상세 전환 기준은 `05-PERMISSIONLESS_SERVICE_NETWORK_KO.md`를 따른다.

## 판정

현재 fresh node 5대 중 4대는 canonical validator identity와 storage 역할을 이미 함께 가진다. validator PC에 public RPC, service write primary, backup key custody까지 더하지 않는다. 세 Ellia validator PC는 같은 관찰 egress를 공유하므로 세 대가 아니라 하나의 WAN failure domain으로 계산한다.

현재 fresh non-validator는 `ellia05` 한 대뿐이다. 운영자의 2026-08-05 진행 승인에 따라 현재 장치만 기존 exclusion에서 해제했고, 같은 PC 이름의 stale legacy device ID는 계속 제외했다. 최초 `1.4.64` canary 뒤 구형 `1.4.4` worker가 다시 heartbeat를 덮어쓰는 현상을 발견해 완료 판정을 보류했고, 같은 설치 경로의 legacy worker만 정리하는 `1.4.65-resilience-legacy-worker-retirement-single-install-locked`로 보정했다. 이후 세 후속 heartbeat 주기에서 `1.4.65`만 확인됐다. authenticated heartbeat에서 CPU, RAM, uptime, node volume 용량을 받았지만 이는 service/DB/RPC/recovery 역할 활성화 승인이 아니다. 운영자는 현재 정전 후 자동부팅 장치가 없어 수동 전원 복구가 필요하다고 확인했다. UPS, 물리 site와 ISP 독립성은 아직 미확인이다. service·DB·Redis·gateway를 서로 독립된 3개 노드로 배치할 증거도 아직 부족하다. `Ellis-test-main`은 마지막 heartbeat가 2026-07-31이고 old presync 상태가 남아 있어 fresh node로 계산하지 않는다.

역할 plan은 `config/resilienceNodeRoles.example.json`에 기록했으며 `activationAllowed=false`다.

## 권장 후보 순서

| node | 현재 역할 | 첫 후보 역할 | 이유 | 현재 gate |
|---|---|---|---|---|
| Ellia-Main-01 | storage + validator-1 | 추가 없음 | validator key와 consensus 역할 집중 방지 | 현 상태 유지 |
| Ellia-test-02 | storage + validator-2 | 추가 없음 | 같은 `PC_EGRESS_A` 집중 방지 | 현 상태 유지 |
| Ellia-test-03 | storage + validator-3 | 추가 없음 | 같은 `PC_EGRESS_A` 집중 방지 | 현 상태 유지 |
| WIN-I3J2KPSOOLB | storage + validator-4 | 추가 없음 | validator와 public/service/key custody 분리 | 현 상태 유지 |
| ellia05 | storage + authenticated inventory | encrypted backup archive 후보 | 4 logical CPU, 7.85GiB RAM, node volume 1.95TiB 중 1.95TiB free | 정전 후 수동 전원 복구, UPS/site/ISP와 custody 확인 필요 |
| Ellis-test-main | stale storage/presync | isolated restore rehearsal | 3TiB quota 기록, production traffic 불필요 | heartbeat 복구와 old presync 정리 계획 필요 |

`ellia05`의 두 번째 후보는 RPC full-node standby다. 현재 장치의 exclusion은 해제됐고 read-only inventory canary만 완료됐다. backup archive와 RPC를 동시에 먼저 활성화하지 않는다. 4 logical CPU와 약 7.85GiB RAM은 archive 후보 검토에는 사용할 수 있지만 RPC와 service 중첩을 승인하기에는 부족할 수 있다. backup restore proof를 우선 만들고 physical disk health·IO 여유가 입증된 뒤 역할 중첩을 검토한다.

`Ellis-test-main`을 service standby 후보로 사용할 수는 있지만, 먼저 stale registration과 presync process/data 상태를 읽기 전용으로 재확인해야 한다. validator로 승격하지 않으며 production DNS target으로도 사용하지 않는다.

## 아직 배치할 수 없는 역할

- Mongo secondary 2대: non-validator·독립 site·durable disk evidence 부족
- Redis replica/Sentinel 3대: 승인된 service/data node가 3대 미만
- Gateway B/C: 현재 gateway 5277이 Primary A에서 직접 route되지 않음
- Service standby B/C: worker fence와 restore proof가 없음
- 자동 endpoint failover: signed endpoint manifest와 fencing이 없음

## 역할 분리 원칙

1. validator private key 보유 PC는 public RPC를 제공하지 않는다.
2. backup ciphertext를 보관하는 PC에는 offline decryption private key를 두지 않는다.
3. service standby는 leader lease가 없으면 reward, settlement, proof, push, deletion, order auto-confirm을 시작하지 않는다.
4. Mongo voting member와 service write leader는 물리 site·전원·operator failure domain을 표로 확인한 뒤 배치한다.
5. 하나의 owner가 가진 여러 PC는 운영자 failure domain 관점에서 하나로 계산한다.
6. heartbeat가 stale이면 disk 여유가 많아도 자동 후보에서 제외한다.
7. 역할 활성화는 source 배포, process 시작, DB 연결, traffic 연결을 각각 별도 gate로 나눈다.

## 다음 실행 조건

실제 node 역할 배치는 다음 evidence를 받은 뒤 진행한다.

- 정전 후 수동 전원 복구를 반영한 RTO 예외 승인 또는 추후 자동 전원 복구 장치 설치
- UPS/site/ISP/maintenance owner 운영자 확인
- backup age recipient public key와 custody owner
- `ellia05` physical disk health와 recovery directory custody 확인
- `Ellis-test-main` fresh heartbeat와 old presync state 판정
- standby worker fence profile과 isolated restore 성공 evidence

2026-08-05에는 `ellia05` 한 대에만 signed/hash-bound PC Sync client canary를 전달했다. 이를 받기 위해 AISFOR와 AISFOR Chain API를 순차 재시작했고 두 서비스의 local health를 확인했다. rollout policy는 성공 직후 삭제됐다. service/RPC/validator 역할 시작, DB dump/write, DNS/public API 변경, operator signing, age key 생성, backup 전송은 수행하지 않았다.
