Linstor Controller placement relative to CloudStack Management Server

[anirudh09041]

I am designing a private cloud on Apache CloudStack 4.22 with KVM hypervisors and planning to use LINSTOR as the primary storage provider.

We are having multi-node management server setup.

Where should we place the linstor controller to achieve HA ??

[starkmarkus]

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:

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.