INTRODUCTION
In a clustered Strategy Intelligence Server environment, subscriptions are load balanced across all nodes of the cluster, whether they are created using a time-based schedule or an event-based schedule.
For additional details on time and event based schedules in a clustered environment, refer to the following Strategy Knowledge Base Documents:
KB30775: How are time-based and event-based schedules executed in a clustered MicroStrategy Server 9.x and 10.x environment?
Subscriptions are load balanced based on the number of jobs created. To understand how the process works in a clustered Strategy Intelligence Server environment, a list of scenarios are discussed below. The scenarios are based on the following assumptions:
Scenario 1: Subscription S1 is created with report R1 for user group G1:
Result: When the event is triggered, report jobs for all users in G1 will be executed on one node only.
Scenario 2: Subscription S1 is created with report R1 for both user groups G1 and G2:
Result: When the event is triggered, report jobs for G1 will execute on one node (Node A for example) while report jobs for G2 will execute on the other node (NodeB for example).
Scenario 3: Subscriptions S1 is created with report R1 for user group G1. Subscription S2 is created with report R2 for user group G2.
Result: When the event is triggered, report jobs for subscription S1 will be executed on one node (NodeA for example) while report jobs for subscription S2 will be executed on the other node (NodeB for example). As a result, user sessions from G1 will appear on Node A and user sessions from G2 will appear on Node B.
Scenario 4: Subscriptions S1 is created with report R1 for user groups G1 and G2. Subscription S2 is created with report R2 for user groups G1 and G2.
Result: When the event is triggered, there will be a total of 20 report jobs created in this case. 5 report jobs for G1 executing R1 in one node (NodeA for example); 5 report jobs for G2 executing R1 in another node (NodeB for example). Another 5 report jobs for G1 executing R2 in one node (NodeA for example), and 5 report jobs for G2 executing R2 in another node (NodeB for example).
However, user connections from user groups G1 and G2 (total 10 user connections) will exist on both Node A's and Node B's user connection monitor. This is working as designed. User connections cannot be shared across nodes in a cluster.
Scenario 5: Subscription S1 is created with report R1 for 10 individual users that make up user groups G1 and G2.
Result: Since the load balance factor is 1:1, the total number of users will be broken evenly. so the number of jobs created will be 2, one for each set of 5 users. As a result S1 for fthe first 5 users will execute on Node A and S1 for the other 5 users will execute on Node B.
Scenario 6: Subscription S1 is created with report R1 for user groups G1, Subscription S2 is created with report R1 for user groups G2:
Result: When the event is triggered, report jobs for G1 will execute on one node (Node A for example) while report jobs for G2 will execute on the other node (NodeB for example).
Note: User connections from Strategy scheduler are disconnected only after the scheduler timeout has reached. This setting can be changed via Strategy Intelligence Server Configuration as seen below:
If subscriptions are sequentially executed before the scheduler timeout has reached, the cached user connections will be re-used.
