GitHub user starkmarkus added a comment to the discussion: Linstor Controller
placement relative to CloudStack Management Server
I would treat the LINSTOR controller as a separate storage control-plane
component, not as something that is automatically made HA just because
CloudStack Management Server is deployed in HA.
CloudStack Management Server HA and LINSTOR Controller HA are two different
things:
```text
CloudStack Management Servers -> CloudStack API / orchestration HA
LINSTOR Controller -> LINSTOR storage control-plane HA
LINSTOR Satellites -> storage/data-plane on KVM/storage nodes
```
For CloudStack, the important thing is that the LINSTOR primary storage
configuration points to a stable LINSTOR controller API endpoint. If that
endpoint disappears, existing DRBD-backed volumes may keep running, but
CloudStack/LINSTOR operations that need the controller — create volume, delete
volume, attach, detach, snapshot, migration orchestration, etc. — will be
affected.
So I would not put “one LINSTOR controller on each CloudStack management
server” and assume that is enough by itself. Multiple installed controller
services do not automatically give you an active/active controller. LINSTOR
controller HA normally needs a proper HA design around the controller
database/state and a stable endpoint/failover mechanism.
The usual placement options are:
1. Dedicated LINSTOR controller HA nodes
Best separation. Run the LINSTOR controller/control-plane on dedicated
nodes, expose a stable VIP/DNS/API endpoint to CloudStack, and run LINSTOR
satellites on the KVM/storage nodes.
2. Co-located on CloudStack management nodes
Possible, but only if you still configure LINSTOR controller HA properly.
In that case, treat the CloudStack management nodes as shared control-plane
nodes, but do not rely on CloudStack HA alone to fail over LINSTOR.
3. Controller on one storage/KVM node only
Simple for labs, not ideal for production. If that node or controller
service is down, new LINSTOR operations from CloudStack will fail until the
controller is restored.
For a production CloudStack + KVM + LINSTOR setup, I would aim for:
- 3+ KVM/LINSTOR satellite nodes for storage quorum
- LINSTOR controller reachable via stable API endpoint
- controller HA handled separately from CloudStack MS HA
- CloudStack primary storage configured against that stable LINSTOR endpoint
- separate/healthy network for DRBD replication traffic if possible
If you co-locate the controller on management servers, I would still make sure:
- only one controller is active at a time
- failover is automatic or at least well documented
- the LINSTOR database/state is protected
- CloudStack always talks to the same VIP/DNS name, not to a single node
hostname
- you test failure of the active controller before going live
So the short answer is: place the LINSTOR controller where it can be made
highly available independently, and present CloudStack with one stable LINSTOR
API endpoint. Co-locating it with CloudStack management servers can be
acceptable, but it is not HA by itself.
GitHub link:
https://github.com/apache/cloudstack/discussions/13466#discussioncomment-17396989
----
This is an automatically sent email for [email protected].
To unsubscribe, please send an email to: [email protected]
