|
| 1 | +# Longhorn (LH) Knowledge Base |
| 2 | + |
| 3 | +### Can LH be used for critical services (e.g., Databases)? |
| 4 | + |
| 5 | +No (as of now). , we should not use it for volumes of critical services. |
| 6 | + |
| 7 | +As of now, we should avoid using LH for critical services. Instead, we should rely on easier-to-maintain solutions (e.g., application-level replication [Postgres Operators], S3, etc.). Once we get hands-on experience, extensive monitoring and ability to scale LH, we can consider using it for critical services. |
| 8 | + |
| 9 | +LH uses networking to keep replicas in sync, and IO-heavy workloads may easily overload it, leading to unpredictable consequences. Until we can extensively monitor LH and scale it properly on demand, it should not be used for critical or IO-heavy services. |
| 10 | + |
| 11 | +### How does LH decide which node's disk to use as storage? |
| 12 | + |
| 13 | +It depends on the configuration. There are three possibilities: |
| 14 | +* https://longhorn.io/kb/tip-only-use-storage-on-a-set-of-nodes/ |
| 15 | + |
| 16 | +When using the `Create Default Disk on Labeled Nodes` option, it relies on the `node.longhorn.io/create-default-disk` Kubernetes node label. |
| 17 | + |
| 18 | +Source: https://longhorn.io/docs/1.8.1/nodes-and-volumes/nodes/default-disk-and-node-config/#customizing-default-disks-for-new-nodes |
| 19 | + |
| 20 | +### Will LH pick up storage from a newly added node? |
| 21 | + |
| 22 | +By default, LH will use storage on all nodes (including newly created ones) where it runs. If `createDefaultDiskLabeledNodes` is configured, it will depend on the label of the node. |
| 23 | + |
| 24 | +Source: |
| 25 | +* https://longhorn.io/kb/tip-only-use-storage-on-a-set-of-nodes/ |
| 26 | +* https://longhorn.io/docs/1.8.1/nodes-and-volumes/nodes/default-disk-and-node-config/#customizing-default-disks-for-new-nodes |
| 27 | + |
| 28 | +### Can workloads be run on nodes where LH is not installed? |
| 29 | + |
| 30 | +Workloads can run on nodes without LH as long as LH is not restricted to specific nodes via the `nodeSelector` or `systemManagedComponentsNodeSelector` settings. If LH is configured to run on specific nodes, workloads can only run on those nodes. |
| 31 | + |
| 32 | +Note: There is an [ongoing bug](https://github.com/longhorn/longhorn/discussions/7312#discussioncomment-13030581) where LH will raise warnings when workloads run on nodes without LH. However, it will still function correctly. |
| 33 | + |
| 34 | +Source: https://longhorn.io/kb/tip-only-use-storage-on-a-set-of-nodes/ |
| 35 | + |
| 36 | +### Adding new volumes to (PVs that rely on) LH |
| 37 | + |
| 38 | +Monitor carefully whether LH is capable of handling new volumes. Test the new volume under load (when many read/write operations occur) and ensure LH does not fail due to insufficient resource capacities (e.g., network or CPU). You can also consider LH's performance section from this Readme. |
| 39 | + |
| 40 | +LH's minimum recommended resource requirements: |
| 41 | +* https://longhorn.io/docs/1.8.1/best-practices/#minimum-recommended-hardware |
| 42 | + |
| 43 | +### LH's performance / resources |
| 44 | + |
| 45 | +Insights into LH's performance: |
| 46 | +* https://longhorn.io/blog/performance-scalability-report-aug-2020/ |
| 47 | +* https://github.com/longhorn/longhorn/wiki/Performance-Benchmark |
| 48 | + |
| 49 | +Resource requirements: |
| 50 | +* https://github.com/longhorn/longhorn/issues/1691 |
0 commit comments