307 lines
8.7 KiB
Markdown
307 lines
8.7 KiB
Markdown
# 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
|
|
|
|
### Move off Serenity early; does not need the storage cutover
|
|
- Wizarr -> PD or retire if no longer useful
|
|
- Hawser + dockersocket -> PD or retire as a pair
|
|
- netdata -> keep only where it still adds monitoring value
|
|
|
|
These are low-risk peel-off candidates because they are not part of the storage-local torrent/media locality lane.
|
|
|
|
## 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 (`Wizarr`, `Hawser` + `dockersocket`, and possibly `netdata`)
|
|
|
|
### 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
|
|
- keep `Newt`, `reranker`, and the off-PD Technitium node as explicit special cases until their redesign work is ready
|
|
|
|
### 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
|
|
- peel off the miscellaneous low-risk apps before touching the storage-locality lane
|
|
- 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
|