heartbeat options

[Sean OB_1]

Hello!

I have a client running a 2 node cluster. Currently the heart beat is through their network.

I want to set them up with a dedicated heartbeat and want to know the benefits/drawbacks of using a crossover connection for the dedicated heartbeat.

We will use the open network as an alternate heartbeat.

So what is the drawback of using a crossover instead of putting in a small hub between the two machines?

Also am I correct in assuming that the node will fail only when both heartbeats are lost? In otherwords, if the dedicated heartbeat is lost but the heartbeat over the open network is still available the node will not fail over?

TIA

Sean

[John Poff · Accepted solution]

Hi Sean,

We have small, two-node SG clusters running in remote locations, and we use crossover cables for the heartbeat LAN between the two nodes. The only drawback I can think of is that if for some reason you want to add another node to the cluster, you'll have to get a hub. Also, if you have to take down one node, you'll get the LAN disaster messages on the other node because the link has failed. For a simple two node cluster, the crossover cable works great. There is less chance of someone coming along and unplugging the hub, or grabbing it to use elsewhere.

You are correct about the heartbeats. I like having the dedicated heartbeat LAN so that you don't have to worry if the data LAN gets very busy and your heartbeats start getting lost in the shuffle.

JP

[Dirk Wiedemann]

Hi Sean,

There is now difference using a crossover connection or a hub.
And you are right: if you have redundant heartbeats the cluster only fails over if both heartbeats doesn't work.

regards
Dirk

[A. Clay Stephenson]

You are correct about the heartbeats. Your crossover cable will work just fine in a two-node cluster. I actually prefer to use a hub or a small switch for that network because you never know when you may need to add a new node to a cluster especially when you are replacing older equipment. I also have a thing for blinking lights and I want to know that I can see the heartbeats. As for anyone 'borrowing' one of my hubs or switches - that just ain't gonna happen - at least more than once. My baseball bat will deal with that. I really can't concieve of someone remove cables or hubs like that; I simply don't allow it.

If you do choose a crossover, make certain that this cable is well marked (different color?) and if you are actually doing the crossover at your patch panel make ceratin that that crossover cable is also VERY VISIBLE.

[melvyn burnard]

I have answered this same crossover cable a number of times in the forums, but will post the oficial document again for your reference:

Pros and Cons of using a Crossover cable with ServiceGuard


--------------------------------------------------------------------------------
We often get questions asking whether Crossover cables are supported for use in a ServiceGuard cluster. The short answer is YES, but there are some important issues that you should be aware of:

This solution only works in a two node cluster. There is no way to have a Standby LAN card when using a Crossover LAN cable.

When either LAN card fails, or the crossover cable is disconnected, both LAN cards go down. This is because the electrical signals necessary for the cards to determine that a valid LAN connection exists are not present. The result is that since both nodes appear to have a bad LAN card, ServiceGuard may TOC the wrong node. If a hub was used between the two LAN cards, then the hub would provide the electrical signals to the other card, allowing it to stay up.

On multi-speed cards, such as 10/100Base-T, the cards must negotiate which speed will be used when the system boots up. If only one system is booted and the remote system is down, then the negotiation will fail, and the card will not be enabled at all. So when the second node eventually comes up, it's LAN will also be down. If a hub is used, then the negotiation will succeed, so the LAN cards will come up at bootup, even if only one node is running.
It may be possible to force some multi-speed LAN cards to bypass the negotiation at bootup and to use a predetermined fixed speed. If this is possible, then would allow the two systems to boot up at different times and still use the Crossover cable connected LAN cards once they are both booted up.

Since both cards may go down when there is a failure when a Crossover cable is used, it can be difficult to determine where the problem lies. Another problem using Crossover cables is that if they are not properly labeled, they may accidently be used in situations where they will not work.
For the reasons listed above, HP does not recommend using Crossover cables for ServiceGuard configurations. However, they are still supported as long as you are willing to accept the above limitations. Using a Crossover cables is cheaper than using a hub, but it compromises the HA solution.

[Dietmar Konermann]

Hi, Sean!

Here is a statement from the ServiceGuard division. I think it's OK to share that information here for clarification.

Regards...
Dietmar.


---
Pros and Cons of using a Crossover cable with ServiceGuard

We often get questions asking whether Crossover cables are supported for use in a ServiceGuard cluster. The short answer is YES, but there are some important issues that you should be aware of:

This solution only works in a two node cluster. There is no way to have a Standby LAN card when using a Crossover LAN cable.

When either LAN card fails, or the crossover cable is disconnected, both LAN cards go down. This is because the electrical signals necessary for the cards to determine that a valid LAN connection exists are not present. The result is that since both nodes appear to have a bad LAN card, ServiceGuard may TOC the wrong node. If a hub was used between the two LAN cards, then the hub would provide the electrical signals to the other card, allowing it to stay up.

On multi-speed cards, such as 10/100Base-T, the cards must negotiate which speed will be used when the system boots up. If only one system is booted and the remote system is down, then the negotiation will fail, and the card will not be enabled at all. So when the second node eventually comes up, it's LAN will also be down. If a hub is used, then the negotiation will succeed, so the LAN cards will come up at bootup, even if only one node is running. It may be possible to force some multi-speed LAN cards to bypass the negotiation at bootup and to use a predetermined fixed speed. If this is possible, then would allow the two systems to boot up at different times and still use the Crossover cable connected LAN cards once they are both booted up.

Since both cards may go down when there is a failure when a Crossover cable is used, it can be difficult to determine where the problem lies. Another problem using Crossover cables is that if they are not properly labeled, they may accidently be used in situations where they will not work. For the reasons listed above, ACSL Support does not recommend using Crossover cables for ServiceGuard configurations. However, they are still supported as long as you are willing to accept the above limitations. Using a Crossover cables is cheaper than using a hub, but it compromises the HA solution.

[John Poff]

Clay,

I like your suggestion about the baseball bat. When used on hardware I like to call it, "percussive maintenance". When used on misbehaving sys admins, I like to call it "attitude adjustment". We have a saying here, "The beatings will continue until morale improves". ;)

My point was that my remote sites are really remote - I'm in North Carolina and my remote sites running SG are in Virginia, Iowa, Kentucky, and Oklahoma. Sometimes I need a really long baseball bat when those guys do something stupid! If they just see a LAN cable coming out of the 10Mb port going to the next box, they are less likely to unplug it. :)

(no points please, Sean, just a little off topic nonsense)

JP

[Dietmar Konermann]

Oops... Melvyn was obviously faster. :)