Skip to main content

Storage

EmberNet's storage layer, Cinder, gives your workloads resilient, replicated block storage at the edge, and gives you a single dashboard view of capacity, volume health, and backups across every cluster you operate.

You don't need to know how Cinder works underneath to use it. The Storage view surfaces what matters: how full you are, which volumes are healthy, and whether your backups are landing.

The Storage view​

Open Storage from the dashboard. For the selected cluster or tenant it shows:

  • Capacity: how much of your storage is actually used versus provisioned, sourced from real on-disk usage rather than nominal volume sizes.
  • Volume health: a live count of healthy volumes versus those degraded or rebuilding.
  • Scheduling guardrail: whether any disk has run out of room to place new or rebuilt replicas.
  • Backups: recent backups and their targets.

Volumes and replicas​

Every volume keeps multiple replicas on different nodes, so the loss of a single node or disk doesn't lose your data. A volume's health reflects how many of its configured replicas are currently good:

StateMeaning
HealthyAll configured replicas are up.
DegradedServing data, but with fewer healthy replicas than configured, so another failure would risk data loss. Cinder rebuilds automatically once there's somewhere to place the replica.
FaultedNo usable replicas; the volume cannot serve data. Restore from backup.

A degraded volume raises a Storage alert. The most common cause is a volume configured for more replicas than there are storage nodes to hold them. A three-replica volume on a two-node cluster can never be fully healthy. Match the replica count to your node count, or add a node.

Capacity and the scheduling guardrail​

Cinder will keep accepting writes right up until a disk is full, at which point it can no longer place a rebuilt replica, which is the exact moment you most need the headroom. EmberNet watches for this and raises a capacity guardrail alert before you get there, based on two thresholds:

  • Over-provisioning: how far total requested storage may exceed physical capacity.
  • Minimum available: how much free space each disk must keep in reserve.

When a disk breaches the guardrail, add capacity, raise the over-provisioning allowance, or free space. See expanding capacity.

Backups​

Cinder can back volumes up to an external backup target:

TargetNotes
S3 / S3-compatibleAWS S3 or any S3-compatible object store (endpoint, bucket, region, credentials).
Azure BlobAn Azure storage account and container.
NFSAn NFS export.
CinderSiloEmberNet's own S3-compatible object store, offered as a managed backup target if you'd rather not run one. See Cinder.

When you configure a target, EmberNet verifies it immediately, confirming the bucket or container exists and the credentials are accepted, rather than failing silently the first time a backup runs. Configure targets under Storage → Backup Target.

Expanding capacity​

When a node's disk is the limiting factor, add storage without downtime by attaching an additional data disk to the node and registering it as a second Cinder disk, never by resizing the OS disk, which requires a reboot. New and rebuilt replicas can then schedule onto the added space, and degraded volumes recover on their own.

Next steps​