Storage pools and replication

Define block-storage capacity, replica placement, and failure handling.

Storage pools group devices and define how Infra places block-volume replicas. A storage policy selects a pool, replica count, failure-domain requirements, and supported volume features.

Pool typesCopy link

A replicated pool maintains block copies on separate eligible storage locations. Its policy determines replica count and required node, rack, or zone separation. Use it when a workload needs persistent data accessible from another compute node.

A local pool keeps blocks on one node without another live storage replica. Use it for disposable data or an application with independent replication. Losing that node's disk can destroy the volume; a completed independent backup is needed to recover data not replicated by the application.

Create a poolCopy link

Under Storage → Pools → Create pool, select healthy storage nodes and dedicated devices. Review disk identities before initializing them. Device initialization overwrites existing contents and is blocked when Infra records an active pool membership.

Set host and device reserves so rebuilding replicas does not exhaust usable space. Pool capacity reflects replica overhead; three replicas consume storage on three eligible locations, in addition to metadata and reserve requirements.

Storage policiesCopy link

A policy defines replica count and whether replicas must span nodes, racks, or zones. Required placement cannot be weakened automatically. A three-zone policy requires three eligible zones with sufficient capacity.

New volumes reserve their required placement under the selected policy. Existing volumes keep their policy revision until an explicit policy change operation validates and applies a new layout. Policy changes can require substantial data copying and temporary additional capacity.

Degraded replicasCopy link

When a replica is unavailable, volume health identifies missing locations and whether writes can continue under the policy's write requirement. The replica repair workflow distinguishes missing, stale, and copying replicas. Infra rebuilds missing replicas onto eligible capacity when the source data is available.

Do not remove a surviving replica to clear an alert. If the write requirement cannot be met, writes are unavailable until redundancy is restored or an approved recovery procedure selects authoritative data. Forced recovery can discard unreplicated changes and requires a reviewed data-loss decision.

Remove a storage nodeCopy link

Use the Storage pool API evacuation operations for the selected pool:

1. Request an evacuation preview with node_id. Read its volume and snapshot dependencies, required destinations, and temporary-capacity estimate.
2. Add eligible capacity if the preview reports a shortfall. Destinations must satisfy each volume's required failure domains.
3. Submit the reviewed preview_id, pool ETag, and idempotency key to start evacuation. This restricts device admission before copying begins.
4. Follow the returned parent operation and its replica-copy results. Under Volume → Replicas, confirm each required replica is healthy outside the node.
5. Use the device-removal operation for each device. A device_in_use response lists remaining dependencies; resolve those before physical removal.
6. Continue with node maintenance or retirement.

Compute drain alone does not evacuate storage. If a host has both roles, complete both procedures before shutdown.

Capacity and monitoringCopy link

Observe physical free space, reserved capacity, rebuild backlog, device errors, and replication latency. Snapshot retention can consume pool capacity after a volume is deleted. Set alerts before reaching the pool's reserve boundary; a full pool can prevent writes and block replica repair.

Use Volumes for attachments and expansion, Snapshots for recovery points, and Disaster recovery when live replicas are unavailable.