docs: capture PD future-state architecture
This commit is contained in:
Fizzlepoof
297
docs/planning/PD_FUTURE_STATE_ARCHITECTURE.md
Normal file
297
docs/planning/PD_FUTURE_STATE_ARCHITECTURE.md
Normal file
@@ -0,0 +1,297 @@
|
||||
# PD Future-State Architecture Plan
|
||||
|
||||
Status: proposed target state for the next major PD rebuild and Serenity retirement.
|
||||
|
||||
## Goal
|
||||
|
||||
Turn PD into the long-term primary homelab platform while keeping enough separation for resilience and cybersecurity lab work.
|
||||
|
||||
This plan assumes:
|
||||
- PD is rebuilt on the HL15 Beast ASRock platform
|
||||
- Serenity is temporary and will be retired after its storage is adopted into PD
|
||||
- John will add a second HDD ZFS pool using 5-6 new 20TB+ drives
|
||||
- A few SSDs may be added for appdata, databases, scratch, and cache tiers
|
||||
- Cybersecurity VMs may live on PD, but only inside a tightly segmented lab lane
|
||||
|
||||
## Recommended platform model
|
||||
|
||||
### Keep PD on bare-metal TrueNAS Scale
|
||||
|
||||
Recommended role:
|
||||
- primary NAS
|
||||
- primary production Docker/app host
|
||||
- primary shared database host
|
||||
- primary media host
|
||||
- primary identity/control-plane host
|
||||
- primary DNS source node
|
||||
- primary AI host if the 4090 lands here
|
||||
- limited, disciplined VM host for cybersecurity lab work
|
||||
|
||||
Do not treat PD as an unrestricted cyber range.
|
||||
Production remains the first-class role.
|
||||
|
||||
## Hardware direction
|
||||
|
||||
### Minimum build worth doing
|
||||
- HL15 Beast ASRock build
|
||||
- EPYC 7282
|
||||
- 64GB RAM
|
||||
- RM1000x if no 4090 is going in immediately
|
||||
|
||||
### Preferred long-term build
|
||||
- HL15 Beast ASRock build
|
||||
- EPYC 7452
|
||||
- 128GB RAM preferred if PD will carry production plus multiple security VMs
|
||||
- HX1500i if PD is likely to receive the 4090
|
||||
|
||||
### Why the base model is not recommended
|
||||
The 7252 + 16GB base build is too small for the intended role once PD becomes:
|
||||
- primary ZFS host
|
||||
- primary app host
|
||||
- primary DB host
|
||||
- future ARR/qbit host after pool migration
|
||||
- possible AI host
|
||||
- bounded cybersecurity VM host
|
||||
|
||||
## Storage model
|
||||
|
||||
### HDD pools
|
||||
PD should end up with at least two major HDD-backed data classes:
|
||||
|
||||
1. Imported Serenity capacity
|
||||
- absorb the current Serenity storage role
|
||||
- preserve large media/archive capacity
|
||||
|
||||
2. New HDD ZFS pool
|
||||
- 5-6 x 20TB+ drives
|
||||
- use for future bulk media, archives, backup targets, and growth
|
||||
|
||||
Exact vdev shape should be chosen when the final drive count is locked, but the high-level operating model should be:
|
||||
- one bulk pool for high-capacity household data
|
||||
- one or more fast SSD-backed tiers for apps, DBs, and VM-heavy workloads
|
||||
|
||||
### SSD / NVMe role split
|
||||
Use SSD/NVMe for:
|
||||
- Docker root
|
||||
- shared PostgreSQL / MariaDB / Redis data
|
||||
- write-heavy appdata
|
||||
- VM disks for cyber lab systems
|
||||
- AI model cache
|
||||
- transcode/temp/scratch
|
||||
|
||||
Use HDD pools for:
|
||||
- media libraries
|
||||
- document archives
|
||||
- backups
|
||||
- long-term storage
|
||||
- lower-IO datasets
|
||||
|
||||
## Host role layout
|
||||
|
||||
### PD = production core
|
||||
PD should eventually own:
|
||||
- ZFS/NAS duties
|
||||
- production Docker stack
|
||||
- shared databases
|
||||
- media stack
|
||||
- household/productivity stack
|
||||
- Authentik / identity stack
|
||||
- monitoring/control plane
|
||||
- primary Technitium node
|
||||
- ARR/qbit stack after storage cutover
|
||||
- AI primary if the 4090 lands here
|
||||
- controlled cyber lab VMs
|
||||
|
||||
### N.O.M.A.D. = secondary trusted platform
|
||||
Keep NOMAD for:
|
||||
- offline knowledge / Project NOMAD
|
||||
- game servers
|
||||
- backup Technitium resolver
|
||||
- small bounded utility workloads
|
||||
|
||||
NOMAD should not become a second general-purpose production host.
|
||||
|
||||
### Rocinante = optional AI specialist
|
||||
If PD gets the 4090:
|
||||
- Rocinante becomes optional
|
||||
- can remain an overflow / experimental inference box
|
||||
- can later be repurposed or retired
|
||||
|
||||
If PD does not get the 4090:
|
||||
- Rocinante stays the heavy inference box
|
||||
- PD remains the production/NAS core
|
||||
|
||||
### Serenity = transition-only
|
||||
Near-term:
|
||||
- current storage owner
|
||||
- current torrent locality host
|
||||
- current reranker host
|
||||
- backup Technitium node
|
||||
|
||||
End-state:
|
||||
- storage role moved into PD
|
||||
- remaining services drained or moved
|
||||
- host retired
|
||||
|
||||
## Service placement target
|
||||
|
||||
### Keep on PD long-term
|
||||
Infrastructure / control plane:
|
||||
- Gitea
|
||||
- Homepage
|
||||
- Uptime Kuma
|
||||
- Gotify
|
||||
- RackPeek
|
||||
- Traefik / Pangolin-side internal ingress
|
||||
- Authentik
|
||||
- shared PostgreSQL / MariaDB / Redis
|
||||
- monitoring stack
|
||||
|
||||
Household / productivity:
|
||||
- Paperless
|
||||
- Immich
|
||||
- Karakeep
|
||||
- n8n
|
||||
- KitchenOwl
|
||||
- DoneTick
|
||||
- Qui
|
||||
|
||||
Media / library:
|
||||
- Plex
|
||||
- Tautulli
|
||||
- Audiobookshelf
|
||||
- Calibre-Web
|
||||
- Seerr
|
||||
- RomM
|
||||
- GameVault
|
||||
- Wizarr
|
||||
- Shelfmark
|
||||
- Notifiarr
|
||||
|
||||
AI / search:
|
||||
- LiteLLM
|
||||
- OpenWebUI
|
||||
- Qdrant
|
||||
- SearXNG
|
||||
- Ollama light tier
|
||||
- primary heavy inference too if the 4090 lands on PD
|
||||
- reranker after Serenity is retired
|
||||
|
||||
Torrent/media ingestion after storage cutover:
|
||||
- qBittorrent
|
||||
- qbit_manage
|
||||
- Gluetun
|
||||
- unpackerr
|
||||
- Sonarr / Sonarr-anime
|
||||
- Radarr
|
||||
- Lidarr
|
||||
- Readarr / Readarr-epub
|
||||
- Prowlarr
|
||||
- Bazarr
|
||||
- autobrr
|
||||
|
||||
### Keep off PD long-term
|
||||
NOMAD:
|
||||
- Project NOMAD stack
|
||||
- Pelican / Wings / game servers
|
||||
- backup Technitium resolver
|
||||
|
||||
Optional elsewhere:
|
||||
- heavy inference on Rocinante if PD does not get the 4090
|
||||
- high-risk security experiments on a future dedicated lab node if the school/lab workload outgrows PD-hosted segmented VMs
|
||||
|
||||
## Cybersecurity VM model on PD
|
||||
|
||||
### This is acceptable on PD
|
||||
- Windows Server / AD lab VMs
|
||||
- Windows client VMs
|
||||
- Linux practice VMs
|
||||
- Wazuh / SIEM learning stack
|
||||
- Kali or similar coursework boxes
|
||||
- isolated vulnerable targets for coursework
|
||||
- patch/test environments
|
||||
|
||||
### This should remain tightly bounded
|
||||
- scanning labs
|
||||
- IDS/packet-capture experiments
|
||||
- exploit practice
|
||||
- intentionally vulnerable targets
|
||||
|
||||
These may run on PD only when:
|
||||
- placed on a dedicated lab VLAN
|
||||
- firewalled from production by default
|
||||
- resource-limited
|
||||
- treated as disposable
|
||||
|
||||
### This should ideally not live on PD
|
||||
- malware detonation
|
||||
- unknown or sketchy offensive tooling
|
||||
- random public PoCs with unclear trust
|
||||
- anything that could meaningfully threaten production storage or family services
|
||||
|
||||
## Network / VLAN recommendation for the lab lane
|
||||
|
||||
Create or preserve a dedicated lab/security lane with these rules:
|
||||
- separate VLAN / subnet from production lanes
|
||||
- default-deny from lab to production
|
||||
- allow only explicit admin paths from trusted management devices
|
||||
- allow outbound internet as needed for updates/labs
|
||||
- allow tightly scoped DNS/NTP/logging paths
|
||||
- keep identity trust boundaries explicit rather than automatic
|
||||
|
||||
Suggested policy posture:
|
||||
- Lab -> PD production apps: deny by default
|
||||
- Lab -> shared DNS: allow
|
||||
- Lab -> internet: allow with logging
|
||||
- Trusted admin devices -> lab: explicit allow
|
||||
- Lab -> management interfaces: explicit deny unless specifically required
|
||||
|
||||
## Phased roadmap
|
||||
|
||||
### Phase 1: document and reduce Serenity sprawl now
|
||||
- document current host roles and future-state design
|
||||
- classify Serenity services into keep / move / retire
|
||||
- move low-risk non-storage-tied apps off Serenity first
|
||||
|
||||
### Phase 2: build upgraded PD
|
||||
- install TrueNAS Scale on the new PD hardware
|
||||
- stand up SSD tiers for apps/DBs/VMs
|
||||
- add the new HDD pool
|
||||
- validate networking, Docker, GPU, and backup posture
|
||||
|
||||
### Phase 3: move production services into the new PD layout
|
||||
- migrate any remaining general-purpose apps off Serenity
|
||||
- relocate databases/appdata onto the intended SSD tier
|
||||
- validate ingress, monitoring, and DNS roles
|
||||
|
||||
### Phase 4: move the storage-dependent torrent/media automation stack
|
||||
- after the storage move design is finalized, move qbit + ARR locality to PD
|
||||
- keep path locality on the box that owns the disks
|
||||
- then remove the old Serenity-locality requirement
|
||||
|
||||
### Phase 5: move or redesign the remaining special cases
|
||||
- move reranker onto PD if AI core lands there
|
||||
- redesign backup DNS so Serenity is no longer required
|
||||
- preserve at least one off-PD Technitium node on NOMAD
|
||||
|
||||
### Phase 6: retire Serenity
|
||||
- verify pool adoption is complete
|
||||
- verify services are drained
|
||||
- confirm backups and DNS redundancy still work
|
||||
- power down and retire Serenity
|
||||
|
||||
## Architecture principles
|
||||
|
||||
1. PD becomes the production center of gravity.
|
||||
2. NOMAD stays a separate trusted failure domain.
|
||||
3. Rocinante is optional and should justify its existence.
|
||||
4. Serenity should be designed out of the future state.
|
||||
5. The cybersecurity lab lane can share PD hardware, but not PD trust boundaries.
|
||||
6. Production stability beats hypervisor sprawl.
|
||||
|
||||
## Immediate implications for current cleanup work
|
||||
|
||||
For the current Serenity Docker review, the guiding rule is:
|
||||
- remove obvious sprawl from Serenity now
|
||||
- do not over-optimize the final placement around Serenity permanence
|
||||
- remember that once PD directly owns the storage, the qbit/ARR locality argument flips to PD
|
||||
Reference in New Issue
Block a user