Repository navigation
docs: node sizing is cluster-level, not set by storage-node configure - #234
Merged
Merged
Conversation
Since 26.3, --max-subsys, --hugepages-mem and --vcpu-count are set on cluster create/add (maxSubsystemCount/vcpuCount on the StorageCluster), and storage-node configure no longer takes --max-subsys, --max-size or --cores-percentage; storage-node restart no longer takes --max-subsys. - talos.md: the huge-page calculator runs without --max-subsys and --cores-percentage; it sizes the host for the 75-subsystem ceiling and its default core layout, since the host does not know the cluster's values yet. - limits.md: the subsystem limit is set on cluster create and changed with cluster update --max-subsys (adopted on each node's next restart); values above 75 are rejected, not clamped. - hardware-requirements.md: the hyper-converged CPU share is configured as an absolute --vcpu-count / vcpuCount. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Contributor
|
🤖: Deployment available as https://docstest.simplyblock.io/docs-cluster-level-node-sizing |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Why
Since 26.3, a storage node's sizing is a cluster-wide setting. The 26.3 release notes already say so:
--max-subsys,--hugepages-memand--vcpu-countare set onsbctl cluster create/cluster add. In Kubernetes they'remaxSubsystemCountandvcpuCounton theStorageCluster.sbctl storage-node configureno longer takes--max-subsys,--max-sizeor--cores-percentage.sbctl storage-node restartno longer takes--max-subsys.Two pages still documented the old flags.
Changes
kubernetes/installation/talos.md: the huge-page calculator no longer passes--max-subsys, and--cores-percentageis gone from its list of inputs. A short paragraph explains why: before joining a cluster, the host can't know the cluster's values, so the calculator sizes for the 75-subsystem ceiling and the host's default core layout. That result is enough for any cluster setting (see thestorage-node__configurehandler in sbcli main). The example output uses placeholders instead of a number computed with the old flags.reference/limits.md, "Configured Subsystem Limit per Node":cluster create --max-subsys(ormaxSubsystemCountin Kubernetes).cluster update --max-subsys, and each node adopts the new value on its next restart.deployment-preparation/hardware-requirements.md: one paragraph explaining that the hyper-converged CPU share is configured as an absolute--vcpu-count/vcpuCount(8 in the page's example), and that a host with fewer than count + 1 vCPUs is refused.The CLI reference needs no change. It's generated from sbcli's
cli-reference.yaml, which already has the new flags.All
scripts/check-*.pychecks pass on the changed pages. The one remaining punctuation warning (Oxford comma) is on an existing line in hardware-requirements.md.🤖 Generated with Claude Code