Showing posts with label heartbeat. Show all posts
Showing posts with label heartbeat. Show all posts

Thursday, March 29, 2012

Cluster Switch Hardware

New to clustering and wanted to know if anyone had any hardware suggestions
with regard to the dedicated switch for the heartbeat network.
Initially this will be a 2 node Active/Active cluster hosting SQL Server
connected to a SAN. I do expect to add at least another set of clustered
hosts or two before year's end.
We typically use all Cisco equipment.
Suggestions?
"john d" <johnd@.discussions.microsoft.com> wrote in message
news:D9FCFA8C-13FB-4A7C-9E88-9573BEF9C047@.microsoft.com...
> New to clustering and wanted to know if anyone had any hardware
> suggestions
> with regard to the dedicated switch for the heartbeat network.
Anything will work for you. I, personally, prefer dumb hubs. That way Bucky
can misconfigure it and hose up my heartbeat network.
Russ Kaufmann
MVP - Windows Server - Clustering
ClusterHelp.com, a Microsoft Certified Gold Partner
Web http://www.clusterhelp.com
Blog http://msmvps.com/clusterhelp
The next ClusterHelp classes are:
Denver starting Feb 12th
NYC starting Feb 19th
|||I agree with Russ. The bandwith requirements for the heartbeat are really
low. I wish I could get some old co-ax NICS and just run a single cable
instead of an active device.
Geoff N. Hiten
Senior Database Administrator
Microsoft SQL Server MVP
"Russ Kaufmann [MVP]" <russ@.clusterhelp.com> wrote in message
news:erF4iczOHHA.4280@.TK2MSFTNGP02.phx.gbl...
> "john d" <johnd@.discussions.microsoft.com> wrote in message
> news:D9FCFA8C-13FB-4A7C-9E88-9573BEF9C047@.microsoft.com...
> Anything will work for you. I, personally, prefer dumb hubs. That way
> Bucky can misconfigure it and hose up my heartbeat network.
>
> --
> Russ Kaufmann
> MVP - Windows Server - Clustering
> ClusterHelp.com, a Microsoft Certified Gold Partner
> Web http://www.clusterhelp.com
> Blog http://msmvps.com/clusterhelp
> The next ClusterHelp classes are:
> Denver starting Feb 12th
> NYC starting Feb 19th
>
|||Geoff/Russ - Thanks for your input. Glad I didn't already go out and buy a
switch.
"Geoff N. Hiten" wrote:

> I agree with Russ. The bandwith requirements for the heartbeat are really
> low. I wish I could get some old co-ax NICS and just run a single cable
> instead of an active device.
> --
> Geoff N. Hiten
> Senior Database Administrator
> Microsoft SQL Server MVP
>
> "Russ Kaufmann [MVP]" <russ@.clusterhelp.com> wrote in message
> news:erF4iczOHHA.4280@.TK2MSFTNGP02.phx.gbl...
>
|||For a 2-node system, we typically use just a network cross-over cable. If
you expand this cluster for additional nodes, the heartbeat uses multi-cast
to communicate (Win2K3); so, you will definitely want to isolate this
network from the others, either by constructing a physical interconnect
between the servers or through a larger corporate switch interconnect and
the use of VLANs.
Regardless, unless you also duplicate the hardware, this network will also
represent a Single Point of Failure. If you are unfamiliar with this term,
you should learn it. It is the single most important concept with regards
to Highly Available systems.
In this case, you must provide multiple network paths between the servers.
In addition to the dedicated heartbeat network, we typically allow the
public network to also transport cluster heartbeat communications. In
Cluster Administrator, on the cluster object, you can specify the network
priority for cluster communications, but also include the secondary network
as a fail-safe.
Sincerely,
Anthony Thomas

"john d" <johnd@.discussions.microsoft.com> wrote in message
news:DC09A8BC-4126-4002-B526-401B90D2A1DB@.microsoft.com...
> Geoff/Russ - Thanks for your input. Glad I didn't already go out and buy
a[vbcol=seagreen]
> switch.
>
> "Geoff N. Hiten" wrote:
really[vbcol=seagreen]

Sunday, March 25, 2012

Cluster Lan Interface

We have a SQL Fail-Over Cluster with on Lan Interface and One Heartbeat
Interface. The Lan Interface (NIC) on our active node went down so our
clients could not access the server. Since the services and the Heartbeatr
interface did not go down the passive node did not failover and take control
of the Cluster automatically. We had to force the passive cluster to
failover. Is there anyway we can prevent this from happening in the future ?Hi
Have you had a look at
http://support.microsoft.com/default.aspx?scid=kb;en-us;242600?
If you have Media Sense Disabled, the cluster will not fail over.
Regards
Mike
"ejcs@.noemail.nospam.com" wrote:
> We have a SQL Fail-Over Cluster with on Lan Interface and One Heartbeat
> Interface. The Lan Interface (NIC) on our active node went down so our
> clients could not access the server. Since the services and the Heartbeatr
> interface did not go down the passive node did not failover and take control
> of the Cluster automatically. We had to force the passive cluster to
> failover. Is there anyway we can prevent this from happening in the future ?|||Hi,
I wanted to post a quick note to see if you would like additional
assistance or information regarding Mike's suggestions on this particular
issue. Have you tried the method described in KB:Q242600, does this resolve
your problem?
Please feel free to let me know if there is anything more I could do to
help on this issue and we appreciate your patience and look forward to
hearing from you!
Sincerely yours,
Michael Cheng
Online Partner Support Specialist
Partner Support Group
Microsoft Global Technical Support Center
---
Get Secure! - http://www.microsoft.com/security
This posting is provided "as is" with no warranties and confers no rights.
Please reply to newsgroups only, many thanks!|||I thought I would post this here in case somebody else has this problem.
Incidentally, the link above to the KB article doesn't work: here it is
again:
http://tinyurl.com/4kt2f
A common expectation of a virtual SQL running on a MS cluster is that
link failure on the active node NIC will result in a failover.
Examples: loose cable, kicked cable, failed switch or switch module.
However, this will not cause a failover to the passive node
"Simply removing the network cable from the client network adapter does
not constitute an adapter failure."
http://support.microsoft.com/kb/176320
I'm currently exploring a different issue for a client which if I find
a solution for I will post here.
Scenario: 2 cluster active/passive MS cluster running SQL 2000
Enterprise. Public NICS are mixed mode, Private NIC is internal
heartbeat only.
Symptons:
- unplugging public NIC cable from passive node will cause interface to
dissapear from Cluster Admin
- unplugging public NIC cable from active node will cause both public
NICs to become unavailable in Cluster Admin
- unplugging BOTH public NICs will cause public NIC of active to
RE-APPEAR and be normal!
Anyway, I'll post more if I find a solution...
JasonX
---
Posted via http://www.mcse.ms
---
View this thread: http://www.mcse.ms/message1175343.html|||Erratim: sorry the link from the second poster does work... didn't
realise it was truncating the display.
Also, when both cables are pulled from the public NICs the status is
unreachable, not unavailable :)
JasonX
---
Posted via http://www.mcse.ms
---
View this thread: http://www.mcse.ms/message1175343.html|||As a conclusion to this post, my issue related to the
DisableDHCPMediaSense in the Windows Registry.
The active node had this set. Nobody set this value, so it seems to
have been set by the system at some point.
Check MS KB on this issue if you have a cluster that won't failover
when the network cable or switch goes down.
JasonX
---
Posted via http://www.mcse.ms
---
View this thread: http://www.mcse.ms/message1175343.html