Skip to main content

🧭 UPS Authority Map — Full Infrastructure Power & Shutdown Topology

🎯 Objective

Document the exact power domains, UPS hardware, and shutdown authority flow in the home‑lab infrastructure.

This entry reflects the real deployed architecture and prevents ambiguity about:

  • Which UPS powers what

  • Which device is authoritative

  • Shutdown order during extended outages

⚡ Power Domain Overview

Your infrastructure is intentionally segmented into three independent UPS domains.

This is deliberate resilience design — not redundancy by accident.

🟢 Domain 1 — Network & ISP Continuity Layer

UPS: APC BR650MI Back‑UPS Pro 650VA

Devices powered:

  • Gigaclear ONT

  • Main Router

Purpose:

  • Maintain ISP connectivity

  • Keep LAN routing active

  • Allow orchestration signals to propagate

Design goal:

Keep the network alive long enough for graceful shutdown instructions to complete.

🔵 Domain 2 — Storage & LAN Infrastructure Layer

UPS: APC BR900MI Back‑UPS Pro 900VA (Storage Domain)

Devices powered:

  • Synology DS220+ (Primary NAS – Server role)

  • Synology DS224+ (Secondary NAS – Client role, one‑way sync target)

  • Network Switch

  • Wi‑Fi Range Extender

NAS Shutdown Model

The NAS systems are independent from Pi NUT orchestration.

They rely on:

  • Synology built‑in UPS handling

  • Direct USB signalling from UPS to DS220+

  • LAN communication from DS220+ → DS224+

Shutdown sequence inside this domain:


Power loss detected
├─> DS224+ receives shutdown signal via LAN
├─> DS224+ shuts down
├─> DS220+ shuts down last

This ensures storage integrity and preserves the primary NAS control logic.

🟣 Domain 3 — Compute & Orchestration Layer

UPS: APC BR900MI Back‑UPS Pro 900VA (Compute Domain)

Devices powered:

  • Pi NUT (orchestrator)

  • Start9 Node #1

  • Start9 Node #2

  • Raspberry Pi (Monero node)

Communication

  • Pi NUT communicates over Wi‑Fi

  • All other appliances are hard‑wired to the router

🧠 Authority Model

Only the Pi NUT in this domain is responsible for:

  • Monitoring UPS battery runtime

  • Triggering shutdown when runtime falls below threshold

  • Ensuring correct shutdown order

  • Shutting itself down last

The NAS domain is intentionally autonomous.

🔻 Extended Outage Shutdown Flow (Full System)


Mains power lost

Domain 1 (ISP + Router) remains powered
Domain 2 (NAS domain) remains powered
Domain 3 (Compute domain) remains powered

Battery runtime decreases...

If Compute UPS runtime threshold reached:
├─> Start9 Node #1 shuts down
├─> Start9 Node #2 shuts down
├─> Monero Pi shuts down
├─> Pi NUT shuts down last

If Storage UPS runtime threshold reached:
├─> DS224+ shuts down (via DS220+ instruction)
├─> DS220+ shuts down last

Network domain outlives compute long enough for orchestration.

UPS units cut output when batteries are depleted.

🎯 Design Intent (Professional Resilience Model)

This architecture mirrors enterprise practice:

  1. Storage independent from compute orchestration

  2. Network survives long enough for control messages

  3. Compute nodes die before controllers

  4. Controllers die before infrastructure

Benefits:

  • No single point of orchestration failure

  • Storage integrity protected

  • Predictable shutdown tiers

  • LAN continuity preserved during grace window

🚑 Failure Containment Logic

If Pi NUT fails:

  • NAS still shuts down safely (independent UPS + Synology logic)

If NAS UPS fails:

  • Compute shutdown unaffected

If ISP UPS fails:

  • LAN still functional internally

This layered approach prevents cascading failure.

🧩 Key Insight

This is not just “backup power.”

It is a tiered power governance model:

  • Domain‑segmented

  • Authority‑aware

  • Graceful‑first

  • Failure‑contained

 

No comments to display

Back to top