Here is some basic information about the cluster setup/configuration,
hopefully this is not too much extraneous information. Just as hopefully,
I hope that I've provided enough information. If not, please let me know
and I will rectify that.
Version Info:
OS: CentOS 6.4
Kernel (current): 2.6.32-358.6.2.el6.x86_64
Pacemaker: 1.1.8-7.el6
Corosync: 1.4.1-15.el6_4
CRMSH: 1.2.5-55.4
Hardware Info:
Six (6) 'Class A' systems (more cores, more RAM)
Six (6) 'Class B' systems (less cores, less RAM)
Panasas shared storage system
Resources Info:
A. Cluster Main Server
B. Cluster FTP Server
C. Custom Processing Segmenter Node
D. Custom Processing Master Node
E., F., G., H. Custom Processing Compute Nodes [1-4]
I was hoping someone could give me some guidance about setting up
constraints appropriately and effectively. Here are the guidelines/goals:
1. As much as possible resources should not be moved, high
stickiness, modified as necessary of course by the issues below.
2. No resource should run on any system where another resource is
already running (* see #5 for caveat/problem/issue).
3. Resources A, B, C should *prefer* to run on 'Class B' systems,
but can run on 'Class A' systems if necessary.
a. When a 'Class B' system becomes available though,
resource should migrate to it if on a 'Class A' system already, exception
to #1 above.
4. Resources D.-H. should *prefer* to run on 'Class A' systems,
but can run on 'Class B' systems if necessary.
a. When a 'Class A' system becomes available though,
resource should migrate to it if on a 'Class B' system already, exception
to #1 above. Resource D should have priority, resources E-H have equal
priority to each other, for such a move.
5. If Resource D fails, or otherwise needs to be moved to another
node, and all other nodes are currently in use (#2 above), then at
least one of resources E-H needs to be stopped (preferably the highest
numbered one, i.e. H, G, F, E) so that resource D can be started on that
node.
6. Assuming a minimum quorum situation (7 of 12 nodes present),
priority of resources is as listed, i.e. A-H. This should mean that
resource H is not launched due to lack of available nodes, while other
resources should be launched successfully.
7. If at all possible, I would like avoid tying resources E-H to
resource D - i.e. if D fails, I don't want to shut down E-H. However
given the issue in #5 above, I'm not sure if it's possible to avoid that.
The situation as described above is significantly more complicated than
the examples presented in the various documents, and I'm having difficulty
in designing the implementation plan for all of them. While I can see
bits and pieces of the setup, i.e. setting up a series of colocation
constraints for all of the various A-H combinations for #2, I can't see
how to implement the necessary work for #5 to ensure that resource D is
able to run as long as the cluster has a quorum. I'm also assuming
(dangerous as that is) at the moment that there is no way to group a set
of nodes together and use that group for a location constraint, i.e. what
needs to be done for #3 and #4 above, but rather than I'm going to have to
provide a node-resource ranking statement for each, i.e. instead of 14
statements (7 resources, 2 'classes' of nodes) I will instead have to have
84 statements (7 resources, 12 nodes) for location constraints. If that's
wrong, please let me know. I could really use some help in getting this
all designed out, with the appropriate statements necessary for
configuring the cluster, for the guidelines above.
If someone could help walk me through this, it would be substantially
helpful to me and you'd have my immense gratitude.
Tony
--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
_______________________________________________
Linux-HA mailing list
[email protected]
http://lists.linux-ha.org/mailman/listinfo/linux-ha
See also: http://linux-ha.org/ReportingProblems
