> > We have this configuration: > > NodeA is located in DataCenterA. NodeB is located in > (geographically separate) DataCenterB. > > DataCenterA is connected to DataCenterB through 4 redundant > gigabit links (two physically separate Corosync rings). > > Both nodes reach the Internet through (geographically > separate) DataCenterC. > > Is it possible to prevent cluster partition (or drbd split > brain) if the links between DataCenterA and DataCenterB go > down, but at least one node can still communicate with > DataCenterC? Note that we have no equipment at DataCenterC, > but we can ping stuff in it and through it. > > Ideally, I would like to prevent a secondary node from going > primary if it cannot communicate with DataCenterC. >
After further reflection, I think this is what I want to accomplish. 1. Failover should never be automatically triggered by loss of heartbeat. If the secondary loses communication with the primary, either because the link between them goes down or the primary itself crashes or loses power, the secondary should wait for a manual command to become primary. The secondary should only become primary as a result of manual intervention, such as an admin stopping HA services on the primary or issuing a 'crm node standby' on it. 2. The secondary should refuse to become primary even if manually ordered to do so if it cannot communcate with DataCenterC. --Eric Disclaimer - January 30, 2013 This email and any files transmitted with it are confidential and intended solely for 'General Linux-HA mailing list'. If you are not the named addressee you should not disseminate, distribute, copy or alter this email. Any views or opinions presented in this email are solely those of the author and might not represent those of Physicians' Managed Care or Physician Select Management. Warning: Although Physicians' Managed Care or Physician Select Management has taken reasonable precautions to ensure no viruses are present in this email, the company cannot accept responsibility for any loss or damage arising from the use of this email or attachments. This disclaimer was added by Policy Patrol: http://www.policypatrol.com/ _______________________________________________ Linux-HA mailing list [email protected] http://lists.linux-ha.org/mailman/listinfo/linux-ha See also: http://linux-ha.org/ReportingProblems
