From 8dcba314c62c85717c8da2735a2dbdc3f8e7a2e7 Mon Sep 17 00:00:00 2001 From: schmidt-scaled <82834682+schmidt-scaled@users.noreply.github.com> Date: Thu, 18 Jun 2026 15:53:34 +0300 Subject: [PATCH 1/2] Update cluster-deployment-options.md --- .../deployments/cluster-deployment-options.md | 28 ++++--------------- 1 file changed, 5 insertions(+), 23 deletions(-) diff --git a/docs/deployments/cluster-deployment-options.md b/docs/deployments/cluster-deployment-options.md index ad2e0b12..5992948d 100644 --- a/docs/deployments/cluster-deployment-options.md +++ b/docs/deployments/cluster-deployment-options.md @@ -13,7 +13,7 @@ of data is always stored on the local node (the node to which the volume is atta 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 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``` @@ -36,6 +36,7 @@ new volumes cannot be provisioned and volumes cannot be enlarged. A limit of 500 ### ```--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. +This is only relevant, if the observability stack is deployed. ### ```--metrics-retention-period``` @@ -43,7 +44,8 @@ Number of days by which the io statistics and other metrics are retained. The am ### ```--contact-point``` -This is a webhook endpoint for alerting (critical events such as storage nodes becoming unreachable) +This is a webhook endpoint for alerting (critical events such as storage nodes becoming unreachable). +This is only relevant, if the observability stack is deployed. ### ```--fabric``` @@ -59,26 +61,6 @@ If you need few, very performant volumes, increase the amount, if you need a lar 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 @@ -114,4 +96,4 @@ For more information on backup operations, see [Backup and Recovery](../usage/ba ### ```--name``` -A human-readable name for the cluster \ No newline at end of file +A human-readable name for the cluster From 3692b5f720eb26104c9267f49f267fbef6858e8e Mon Sep 17 00:00:00 2001 From: "Christoph Engelbert (noctarius)" Date: Thu, 18 Jun 2026 15:15:56 +0200 Subject: [PATCH 2/2] Improved language and clarity --- .../deployments/cluster-deployment-options.md | 45 ++++++++++--------- 1 file changed, 23 insertions(+), 22 deletions(-) diff --git a/docs/deployments/cluster-deployment-options.md b/docs/deployments/cluster-deployment-options.md index 5992948d..4bc2fba2 100644 --- a/docs/deployments/cluster-deployment-options.md +++ b/docs/deployments/cluster-deployment-options.md @@ -3,15 +3,15 @@ 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 particularly for 1+1 EC schemas. @@ -22,43 +22,44 @@ 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. -This is only relevant, if the observability stack is deployed. +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 only relevant, if the observability stack is deployed. +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. ### ```--use-backup``` @@ -96,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.