Hi, ryan,
you can configure things like this with Limits and Prerequisites, where Limits is an attribute to a node and Prerequisites is an attribute to a service group. Limits are hard borders what must not crossed, so you cannot "overcommit" any node by use of Limits and Prerequisites.
Looks like this:
system node1 (
Limits = { Applications=1 }
)
system node2 (
Limits = { Applications=1 }
)
...
system noden (
Limits = { Applications=1 }
)
group app1 (
SystemList = { node1, node2,... noden }
AutoStartList = { node1 }
Prerequisites = { Applications=1 }
)
group app2 (
SystemList = { node2, node3,...node1, noden }
AutoStartList = { node2 }
Prerequisites = { Applications=1 }
)
.....
group appn-1 (
SystemList = { noden-1, node1, node2, ... noden }
AutoStartList = { noden-1 }
Prerequisites = { Applications=1 }
)
You have n nodes and n-1 applications (service groups). Now in start time all service groups can start as long as you have at least that many nodes as you have service groups.
If one node is left this node is the failover target to the first failover. Then also the Limits for that node are fully used, so if now another failover should take place it cannot, because there is no node left with any Limits called Applications but the service group need 1 Applications free on a possible failover target. The failover will fail, this service will not failover until there is another node with 1 Applications free.
And here all nodes with no active service group on it can be the next failover taget, you don't need to reconfigure the cluster.
You can refine this strategy with service group dependencies so that your more important servie groups can push aside some not that important ones...
Weak point in this solution: if all your "free failover targets" are eaten up by failures no failover will occur until you bring back the target nodes back into the cluster. (Or, as i said, you use service group dependencies.)
Is that what you want to do? Pls. let me know....
Best regards
Roger