3.3 KiB
title, description, weight
| title | description | weight |
|---|---|---|
| Tiered storage model | Standardized storage taxonomy for service data. | 15 |
The framework enforces a standardized storage taxonomy. This ensures that every service has a predictable location for its data, which simplifies backup strategies and hardware allocation.
The storage taxonomy
Data is divided into three logical Tiers based on its performance requirements, lifecycle, and importance.
Tier 1: Configuration & Cache
Path: ${ROOT_NODE_DIR}/@tier1
- Contents: Config files, small SQLite databases, SSL certificates, application cache.
- Characteristics: Extremely high value, low to medium volume, requires low latency.
- Hardware: High-speed SSD storage, typically shared with the Operating System.
Tier 2: Application Data
Path: ${ROOT_NODE_DIR}/@tier2
- Contents: User uploads, large databases, persistent application state.
- Characteristics: High value, medium to high volume, requires high reliability.
- Hardware: Reliable HDD clusters, RAID arrays, or dedicated storage compute.
Tier 3: Transients & Bulk Media
Path: ${ROOT_NODE_DIR}/@tier3
- Contents: Logs, temporary files, bulk media (movies, music), and other non-critical large data.
- Characteristics: Low value, very high volume.
- Hardware: High-capacity HDDs optimized for continuous sequential write/read (e.g., WD Purple). Note that Tier 3 is too slow for cache.
Backup strategy
The framework does not enforce a specific backup strategy or provide a default implementation, allowing for complete node-specific flexibility. Operators are expected to implement their own backup logic.
Example: Restic backup
A common best practice is to use Restic for backups. For example, you might create an operator compose file to run Restic:
services:
restic:
image: restic/restic:0.18.1
container_name: operator-restic
volumes:
- ./@tier2/{project}/{service}/{data}:/data/@tier2/{project}/{service}/{data}:ro
- ./@tier1/{project}/{service}/{data}:/data/@tier1/{project}/{service}/{data}:ro
- ./@tier1/.operator/restic/cache:/var/restic-cache
environment:
RESTIC_REPOSITORY: "s3:example.com/bucket"
RESTIC_PASSWORD: ${RESTIC_PASSWORD}
# ... AWS/S3 credentials
network_mode: "host"
entrypoint: [ "restic" ]
user: "0:0"
Implementing the strategy
Operators can implement this strategy by defining a local action in .operator/local/scripts/actions/sync/tiers. The root dispatcher can then execute this script to trigger the backup, allowing for granular control over how data is persisted.
Justification
- Hardware optimization: By mapping tiers to specific hardware (SSDs for Tier 1, RAID for Tier 2, Purples for Tier 3), we optimize for both performance and cost.
- Selective backup: Separating transient logs and bulk media (Tier 3) from critical configs (Tier 1) prevents wasting expensive backup storage.
- Architectural clarity: Any operator can inspect a Node directory and immediately understand the storage requirements and priority of its contents.
See also: