|
|
|
Valued Member
      
Group: General Forum Members
Last Login: Friday, June 10, 2011 2:04 PM
Points: 65,
Visits: 67
|
|
|
|
|
|
SSCarpal Tunnel
       
Group: General Forum Members
Last Login: Today @ 6:03 AM
Points: 4,786,
Visits: 1,335
|
|
The article can be a base for further research work. Otherwise it is good. :)
|
|
|
|
|
Keeper of the Duck
Group: Moderators
Last Login: Wednesday, May 08, 2013 5:14 AM
Points: 6,583,
Visits: 1,787
|
|
|
|
|
|
Valued Member
      
Group: General Forum Members
Last Login: Friday, June 10, 2011 2:04 PM
Points: 65,
Visits: 67
|
|
I agree follow-on article(s) should be added.
As to the unexpected fail-over, it may indicate that there is a problem/situation in the cluster causing the is-alive check giving false alarm. Usually there could be a problem with the private (team) heart-beat, or the system was in a heavy load, which timed out the is-alive connections during the time span specified. And obviously event logs and the cluster log should be examined for further findings. The automatic failover configuration itself doesn't cause the problem but is a reaction to the is-alive's result. And as a result, the failover was unexpected because of the false alarm. This is a bad example for choosing the automatic failover option. In this case, either resolve the false alarm issue, or disable the automatic fail-over option should be done. This article simply laid out different options and the expecting behaviors along the triggering flow to help people design a proper failover scheme to fit their own needs.
|
|
|
|
|
Keeper of the Duck
Group: Moderators
Last Login: Wednesday, May 08, 2013 5:14 AM
Points: 6,583,
Visits: 1,787
|
|
Richard Lu (3/26/2008) I agree follow-on article(s) should be added.
As to the unexpected fail-over, it may indicate that there is a problem/situation in the cluster causing the is-alive check giving false alarm. Usually there could be a problem with the private (team) heart-beat, or the system was in a heavy load, which timed out the is-alive connections during the time span specified. And obviously event logs and the cluster log should be examined for further findings. The automatic failover configuration itself doesn't cause the problem but is a reaction to the is-alive's result. And as a result, the failover was unexpected because of the false alarm. This is a bad example for choosing the automatic failover option. In this case, either resolve the false alarm issue, or disable the automatic fail-over option should be done. This article simply laid out different options and the expecting behaviors along the triggering flow to help people design a proper failover scheme to fit their own needs.
Exactly. We're on the same wavelength on this one. Going through these possibilities and explaining what's up and why they trigger the fail-over is something I find myself spending a lot of time discussing with folks I'm bringing up to speed on clustering. Good articles in this area would help a lot. :)
K. Brian Kelley, CISA, MCSE, Security+, MVP - SQL Server Regular Columnist (Security), SQLServerCentral.com Author of Introduction to SQL Server: Basic Skills for Any SQL Server User | Professional Development blog | Technical Blog | LinkedIn | Twitter
|
|
|
|
|
Grasshopper
      
Group: General Forum Members
Last Login: Monday, April 22, 2013 11:35 AM
Points: 10,
Visits: 273
|
|
|
|
|