Elastic scaling
A cluster is rarely the same size forever. Clustron Zaris lets you add capacity while the cluster keeps serving, moving partitions to balance load and to keep every partition at its target replication factor. Removing capacity is also supported, but with an important limitation you must plan for: scale-in is not yet drain-safe.
The unit of scaling in supervisor mode is the Server — a machine running its manager on port 7801, not an individual node. In attach mode, the orchestrator scales nodes and the manager reconciles ownership.
Scaling out (adding capacity)
When you add a Server, every store grows onto it: the manager extends each store's definition with the new machine's PartitionsPerNode × ReplicationFactor nodes, propagates the updated definition across the workspace, and starts the new nodes. Because the total partition count is PartitionsPerNode × servers, the new Server also adds PartitionsPerNode partitions — the partition map expands, and existing segments reshard across the larger map so work spreads more evenly.
Scale-out is lossless: as the map expands, segments (and the keys inside them) are handed to their new owner without being dropped or rehashed, and clients transparently pick up the new partition map. Adding Servers increases both capacity (more memory across the cluster) and throughput (more nodes serving in parallel). You add a Server with Add-ZrServer -Address machine-d:7801; the new machine must be blank and reachable, and not already claimed by another workspace.
Scaling in (removing capacity)
Removing a Server with Remove-ZrServer gracefully stops the leaving machine's nodes so each partition fails over to a surviving replica, drops the machine from every store's definition, and shrinks the partition map. A replication-floor guard refuses the removal if it would leave fewer machines than a store's replication factor, because replicas must land on distinct machines.
However, shrinking the partition map evicts the partitions that are resharded away rather than migrating their keys to the remaining nodes. A data-plane drain is not yet implemented, so keys that lived only in the evicted partitions can be lost.
Scale-in is not drain-safe in this version. Remove-ZrServer refuses to run without -Force, because removing a Server can lose the keys in the evicted partitions. Before you remove a Server, quiesce writes and back up the affected stores, then re-run with -Force to acknowledge the risk. -Force also overrides the replication-floor guard, so use it deliberately. Scale-out via Add-ZrServer is lossless; scale-in is not.
How scaling looks in each deployment model
The table contrasts the two models. See Deployment models for the full picture.
| Supervisor mode | Attach mode | |
|---|---|---|
| Who scales | You, with Add-ZrServer / Remove-ZrServer | The orchestrator (Docker / Kubernetes replica count) |
| What moves | A whole Server (machine) and its share of every store | Individual node containers |
| Manager's part | Forks/drains nodes and rebalances | Adopts new nodes and reconciles ownership |
Either way, the web console shows each machine, whether it is reachable, and how many nodes it runs, plus the partition map shifting as the cluster rebalances.
Rebalancing in a nutshell
- Segments are the unit that moves. Rebalancing reassigns segments between nodes; keys ride along without being rehashed.
- Replicas stay spread. Placement keeps a partition's copies on distinct machines, so rebalancing never puts a primary and its replica on the same machine.
- Under-replicated is temporary. While copies are being rebuilt, affected partitions show as under-replicated until the target replication factor is restored.
Next steps
- Revisit how ownership and replicas work in Partitioning and replication.
- Watch rebalancing happen live in the Web console.
- Confirm the model you are running in Deployment models.