Skip to content

Update cluster-deployment-options.md #159

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
noctarius merged 2 commits into from
Jun 18, 2026
Merged

Update cluster-deployment-options.md #159

Changes from all commits
Commits
Show all changes
2 commits
Select commit Hold shift + click to select a range
8dcba31
Update cluster-deployment-options.md
schmidt-scaled Jun 18, 2026
3692b5f
Improved language and clarity
noctarius Jun 18, 2026
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
65 changes: 24 additions & 41 deletions docs/deployments/cluster-deployment-options.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -3,17 +3,17 @@ title: Cluster Deployment Options
description: "Cluster Deployment Options: The following options can be set when creating a cluster. This applies to both plain linux and kubernetes deployments."
---

The following options can be set when creating a cluster. This applies to both plain linux and kubernetes deployments.
The following options can be set when creating a cluster. This applies to both plain Linux and Kubernetes deployments.
Most cannot be changed later on, so careful planning is recommended.

### ```--enable-node-affinity```

As long as a node is not full (out of capacity), the first chunk
of data is always stored on the local node (the node to which the volume is attached).
This reduces network traffic and latency - accelerating particularly the read - but may lead to an
inequal distribution of capacity within the cluster. Generally, using node affinity accelerates
As long as a node is not full (out of capacity), the first chunk
of data is always stored on the local node (the node to which the volume is attached).
This reduces network traffic and latency, particularly for reads, but may lead to an
uneven distribution of capacity within the cluster. Generally, using node affinity accelerates
reads, but leads to higher variability in performance across nodes in the cluster.
It is recommended on shared networks and networks below 100gb/s.
It is recommended particularly for 1+1 EC schemas.

### ```--data-chunks-per-stripe, --parity-chunks-per-stripe```

Expand All @@ -22,63 +22,46 @@ once at cluster creation and applies to all volumes in the cluster. It cannot be

### ```--cap-warn, --cap-crit```

Warning and critical limits for overall cluster utilization. The warning
limit will just cause issuance of warnings in the event log if exceeded, the "critical" limit will
place the cluster into read-only mode. For large clusters, 99% of "critical" limit is ok, for small
clusters (less than 50TB) better use 97%.
Warning and critical limits for overall cluster utilization. If the warning
limit is exceeded, warnings will be issued in the event log. If the "critical" limit is exceeded,
the cluster will be placed into read-only mode. For large clusters, a 99% "critical" limit is OK. For small
clusters (less than 50 TB), 97% is better.

### ```--prov-cap-warn, --prov-cap-crit```

Warning and critical limits for over-provisioning. Exceeding
these limits will cause entries in the cluster log. If the critical limit is exceeded,
these limits will cause entries in the cluster log. If the critical limit is exceeded,
new volumes cannot be provisioned and volumes cannot be enlarged. A limit of 500% is typical.

### ```--log-del-interval```

Number of days by which logs are retained. Log storage can grow significantly and it is recommended to keep logs for not longer than one week.
Number of days for which logs are retained. Log storage can grow significantly, and it is recommended not to keep logs
for longer than one week. This is only relevant if the observability stack is deployed.

### ```--metrics-retention-period```

Number of days by which the io statistics and other metrics are retained. The amount of data per day is significant, typically limit to a few days or a week.
Number of days for which the I/O statistics and other metrics are retained. The amount of data per day is significant,
so retention should typically be limited to a few days or a week.

### ```--contact-point```

This is a webhook endpoint for alerting (critical events such as storage nodes becoming unreachable)
This is a webhook endpoint for alerting on critical events such as storage nodes becoming unreachable.
This is only relevant if the observability stack is deployed.

### ```--fabric```

Choose tcp, rdma or both. If both fabrics are chosen, volumes can connect to the cluster
using both options (defined per volume or storage class), but the cluster internally uses rdma.
Choose `tcp`, `rdma`, or both. If both fabrics are chosen, volumes can connect to the cluster
using either option (defined per volume or storage class), but the cluster internally uses `rdma`.

### ```--qpair-count```

The default amount of queue pairs (sockets) per volume for an initiator (host) to connect to the
The default number of queue pairs (sockets) per volume for an initiator (host) to connect to the
target (server). More queue pairs per volume increase concurrency and volume performance, but require more
server resources (ram, cpu) and thus limit the total amount of volumes per storage node. The default is 3.
If you need few, very performant volumes, increase the amount, if you need a large amount of less performant
volumes decrease it. More than 12 parallel connections have limited impact on overall performance. Also, the
server resources (RAM, CPU) and thus limit the total number of volumes per storage node. The default is 3.
If you need a few very performant volumes, increase the amount. If you need a large number of less performant
volumes, decrease it. More than 12 parallel connections have limited impact on overall performance. Also, the
host requires at least one core per queue pair.

### ```--host-sec```

Path to a JSON file with NVMe-oF host security configuration. This enables DH-HMAC-CHAP authentication for NVMe-oF
connections cluster-wide. The JSON file specifies the allowed digest algorithms and Diffie-Hellman groups.

```json title="Example: host-security-config.json"
{
"params": {
"dhchap_digests": ["sha256", "sha384"],
"dhchap_dhgroups": ["ffdhe4096", "ffdhe2048"]
}
}
```

Supported digests: `sha256`, `sha384`, `sha512`

Supported DH groups: `null`, `ffdhe2048`, `ffdhe3072`, `ffdhe4096`, `ffdhe6144`, `ffdhe8192`

For more information, see [NVMe-oF Security](../architecture/concepts/nvmf-security.md).

### ```--use-backup```

Path to a JSON file with S3 or S3-compatible (MinIO) backup configuration. This enables snapshot-based backup and
Expand Down Expand Up @@ -114,4 +97,4 @@ For more information on backup operations, see [Backup and Recovery](../usage/ba

### ```--name```

A human-readable name for the cluster
A human-readable name for the cluster.
Loading