- Community Home
- >
- Servers and Operating Systems
- >
- Operating Systems
- >
- Operating System - Linux
- >
- cluster Redhat parameter question
Categories
Company
Local Language
Forums
Discussions
Forums
- Data Protection and Retention
- Entry Storage Systems
- Legacy
- Midrange and Enterprise Storage
- Storage Networking
- HPE Nimble Storage
Discussions
Discussions
Discussions
Forums
Discussions
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
- BladeSystem Infrastructure and Application Solutions
- Appliance Servers
- Alpha Servers
- BackOffice Products
- Internet Products
- HPE 9000 and HPE e3000 Servers
- Networking
- Netservers
- Secure OS Software for Linux
- Server Management (Insight Manager 7)
- Windows Server 2003
- Operating System - Tru64 Unix
- ProLiant Deployment and Provisioning
- Linux-Based Community / Regional
- Microsoft System Center Integration
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Community
Resources
Forums
Blogs
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
09-23-2011 02:52 AM - edited 09-23-2011 03:12 AM
09-23-2011 02:52 AM - edited 09-23-2011 03:12 AM
cluster Redhat parameter question
Hi,
i have a redhat cluster with a failover domain configured in this way:
<failoverdomain name="SERVICE" nofailback="1" ordered="1" restricted="0">
<failoverdomainnode name="node1-priv" priority="2"/>
<failoverdomainnode name="node2-priv" priority="1"/>
</failoverdomain>
as you can see there are both parameter: nofailback and ordered.
So this configuration can generated some conflicts? the no failback option setted to "1" means that the resource in that failover domain can't return on the previus node after a failover.
The ordered parameter setted to "1" means that there are a preferred server for the resource.
but i don't know if these parameters can live together.
Regards,
Stefano Peccenini
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
09-24-2011 01:37 AM
09-24-2011 01:37 AM
Re: cluster Redhat parameter question
Yes, the "nofailback=1" and "ordered=1" options can live together. There is no conflict.
- "ordered=1" means the cluster will use the node priority values on the failoverdomainnode lines whenever it needs to determine where to failover/failback a service to.
- With "nofailback=1", when a service that uses this failover doman has failed over from node2-priv to node1-priv, the cluster won't automatically move the service back to node2-priv as soon as it is functional again. The service would stay on node1-priv until commanded to move, or until node1-priv fails. If node2-priv had failed and then been fixed, and then node1-priv failed while the service was running on it, the service would automatically failover to the highest-priority available node, i.e. node2-priv.
- The "restricted=0" option means that if you add a third node to your cluster (e.g. node3-priv), the service would be allowed to failover to it if and only if both node1-priv and node2-priv had failed. With "restricted=1", the service would be restricted to node1-priv or node2-priv only: it would never failover to node3-priv.
The "nofailback=1" setting can be useful if your service takes a long time to start up and you get an intermittent fault (e.g. a network problem) on node2-priv. With "nofailback=0", the service would move back and forth between the nodes, spending most of its time either starting up or shutting down instead of staying on the failover node and doing useful work there. "nofailback=1" makes the service keep running on node1-priv (unless it fails too) until someone can diagnose and fix the problem and verify that it stays fixed.