Document Longhorn deployment guidance - #414
Conversation
Bumps [product-docs-common](https://github.com/rancher/product-docs-common) from `c5b3d01` to `fb66443`. - [Commits](rancher/product-docs-common@c5b3d01...fb66443) --- updated-dependencies: - dependency-name: product-docs-common dependency-version: fb6644346522bdefc897a9ad425d20ddf24d285e dependency-type: direct:production ... Signed-off-by: dependabot[bot] <support@github.com>
…duct-docs-common-fb66443 Bump product-docs-common from `c5b3d01` to `fb66443`
✅ Deploy Preview for suse-obs ready!
To edit notification comments on pull requests, go to your Netlify project configuration. |
Target the upcoming-release branch because the mixed StorageClass overrides and Kafka transaction-state migration have not shipped in a stable chart. Keep staging's shared documentation assets when resolving the submodule conflict.
Use two storage replicas as the default for both deployment modes, with three as an explicitly assessed alternative. Describe HDFS replication overhead without attributing customer data loss to the replica count alone. Gate mixed storage classes on the upcoming release and use the sanctioned release placeholder. Separate the Kafka data override from diagnostics and require actual topic replication verification because an upgrade can defer migration. Document optional PVC class exceptions, durable assistant state and application replication checks before maintenance.
Show how to describe all Kafka partitions and compare replica assignments with ISR membership. Include StorageClass examples for Collector claim templates and component transaction-log PVCs; remove the requested diagnostic-log explanation and redundant Kafka prerequisites.
Identify the affected HA profiles and verify only __transaction_state for this migration. Explain that Non-HA replication factor one is expected and retains durable storage. Remove the unused Collector PVC customization while retaining the component transaction-log example.
| This follows the https://longhorn.io/docs/latest/best-practices/#io-performance[Longhorn I/O performance best practices], which recommend two replicas for data availability with lower disk-space usage and less impact on system performance, especially for data-intensive applications. | ||
| After one replica-host failure, a two-replica volume has only one healthy copy until Longhorn completes the rebuild; do not continue maintenance while any volume is degraded. | ||
|
|
||
| Use three replicas when the required storage failure margin justifies the additional disk usage and replication traffic. |
There was a problem hiding this comment.
I'm not sure we should even include this. I don't know when I would say it is justified, for HA HDFS I would say it is never justified and will cause more problems than it solves.
Only for non-HA it could be reasonable, but even there it adds a lot of extra traffic and load that may cause more problems than it solves.
I would also not really know how one would validate all the things mentioned.
There was a problem hiding this comment.
The 3 replicas was removed including storageclass manifests
|
|
||
| === Kafka transaction-state replication in HA | ||
|
|
||
| This section applies to HA installations considering the optional one-replica Longhorn class for Kafka. |
There was a problem hiding this comment.
This entire section comes out of the blue. Why should the user worry about Kafka suddenly. There is also a reference to "The fix", but not what fix that is.
There was a problem hiding this comment.
Let's check this also with @craffit, but I think that the application can handle losing all data for this topic without big consequences. If that's indeed the case I would leave this section out entirely, it all is pretty complicated and scary.
There was a problem hiding this comment.
The fix is the increasing replicationFactor for one of the Kafka topics, prior the fix user should use "Durable" storage class. The whole section is just to cover this case...
There was a problem hiding this comment.
I replaced the fix with SUSE Observability {next-release-version}
|
|
||
| === Optional component transaction-log PVCs | ||
|
|
||
| Most component PVCs inherit `global.storageClass`, including AI Assistant SQLite storage. |
There was a problem hiding this comment.
I think for this one we can simply say that if this feature is enabled they could also go for transient. It is only used for debugging purposes (if at all).
| storageClass: longhorn-durable-2 | ||
| ---- | ||
|
|
||
| Choose this class according to the data's recovery requirements; using the transient class accepts loss of the stored data. |
There was a problem hiding this comment.
This is really overstating the importance of this data. A customer admin will have no clue how to decide this. So we might as well leave with the simple recommendation (either durable-2 or like my other comment suggests, transient).
| |`longhorn-application` | ||
| |1 | ||
| |Best effort | ||
| |HA installations only: Elasticsearch members, HDFS DataNodes, and ZooKeeper members with verified application replication and volume placement. Kafka has additional prerequisites below. Losing the volume loses that member and requires application-level recovery. |
There was a problem hiding this comment.
longhorn-ha-application or longhorn-ha-database?
There was a problem hiding this comment.
Did you deliberately leave ClickHouse out of the longhorn-application category? In 4000-HA mode it actually runs with 2 or 3 replicas and it could use the same 1 replica setup.
There was a problem hiding this comment.
Did you deliberately leave ClickHouse out of the longhorn-application category? In 4000-HA mode it actually runs with 2 or 3 replicas and it could use the same 1 replica setup.
Nop, I just missed it.
…es_openshift/longhorn.adoc Co-authored-by: rb3ckers <remco.beckers@suse.com>
Remove the three-replica alternative and recommend transient storage for optional component debugging logs. Rename the application-replicated class to longhorn-ha-database and include replicated ClickHouse, keeping single-replica profiles on durable storage.
3 participants
Document Longhorn installation and maintenance with two storage replicas by default, explicit HA recovery requirements, and separate Kafka replication checks.
Targets
staging: mixed StorageClass overrides and Kafka transaction-state migration require the upcoming release. Resolve{next-release-version}before promotion tomain.Tracking: https://github.com/StackVista/stackstate/issues/501
Validation: English-only Antora build passes with warnings treated as failures; navigation, link syntax, YAML examples and shell syntax pass.