UPDATE! The community will be go into read-only on April 19, 8am Pacific in preparation for migration on April 21. Read more.
UPDATE! The community will be go into read-only on April 19, 8am Pacific in preparation for migration on April 21.Read more.
Absent Member.
Absent Member.
3538 views

Heartbeat VLAN

I'm getting ready to install an OES 11 cluster(3 node). Reading through the docs there is a section about creating a VLAN for the heartbeat:

"Use a dedicated VLAN (virtual local area network) for each cluster.

The cluster protocol is non-routable, so you cannot direct communications to specific IP addresses. Using a VLAN for the cluster nodes provides a protected environment for the heartbeat process and ensures that heartbeat packets are exchanged only between the nodes of a given cluster.

When using a VLAN, no foreign host can interfere with the heartbeat. For example, it avoids broadcast storms that slow traffic and can result in false split-brain situations."

I saw a comment from kjhurni saying that he wouldn't follow those rules in this thread: http://forums.novell.com/novell/novell-product-discussion-forums/open-enterprise-server/oes-linux/oes-l-administration/433543-requirement-open-enterprise-server-cluster-environment.html

I'd rather not have another VLAN just for the heartbeat. The cluster nodes are VMs in our VMWare environment. We just have a server vlan with less than 30 servers with no expectation for it to get above 50 at any point. What are the general thoughts about this?


Thanks in advance.

Labels (1)
0 Likes
6 Replies
Knowledge Partner Knowledge Partner
Knowledge Partner

In article <imc.5es03b@no-mx.forums.novell.com>, Imc wrote:
> I'd rather not have another VLAN just for the heartbeat. The cluster
> nodes are VMs in our VMWare environment. We just have a server vlan
> with less than 30 servers with no expectation for it to get above 50 at
> any point. What are the general thoughts about this?
>

I've generally not bothered with a separate VLAN in similar sized
systems. At that scale, the risks of the added complexity appears to me
to outweigh the risks of the heartbeat not getting through.
To keep from hitting problems, I do make sure I characterize the network
with some packet captures and try to keep the subnet the servers is on is
a clean as possible, especially in terms of controlling the broadcasts
(do you really need all those protocols on all those ports/devices?).


Andy Konecny
KonecnyConsulting.ca in Toronto
------------------------------------------------------------------------
Andy's Profile: http://forums.novell.com/member.php?userid=75037


___
“i’ve sworn an oath of solitude til the blight is purged from these lands”
Andy of Konecny Consulting in Toronto
Knowledge Partner Profile
If you find a post helpful, click the Like button below. Thanks!
0 Likes
Absent Member.
Absent Member.

konecnya;2203741 wrote:
In article <imc.5es03b@no-mx.forums.novell.com>, Imc wrote:
> I'd rather not have another VLAN just for the heartbeat. The cluster
> nodes are VMs in our VMWare environment. We just have a server vlan
> with less than 30 servers with no expectation for it to get above 50 at
> any point. What are the general thoughts about this?
>



I've generally not bothered with a separate VLAN in similar sized
systems. At that scale, the risks of the added complexity appears to me
to outweigh the risks of the heartbeat not getting through.
To keep from hitting problems, I do make sure I characterize the network
with some packet captures and try to keep the subnet the servers is on is
a clean as possible, especially in terms of controlling the broadcasts
(do you really need all those protocols on all those ports/devices?).


Andy Konecny
KonecnyConsulting.ca in Toronto
------------------------------------------------------------------------
Andy's Profile: View Profile: konecnya - Novell - NetIQ - SUSE


Thanks for the response Andy. I've got a 3 node netware cluster on the same subnet and I haven't ran into any heartbeat issues with it, but with OES Linux cluster not being exactly the same thing, I thought I'd ask.

I'm not sure if you're a leafs fan, but if you are, good luck with JVR. He has to potential to be a 70 point guy if he is motivated and can stay healthy.

0 Likes
Knowledge Partner Knowledge Partner
Knowledge Partner

imc;2203763 wrote:
Thanks for the response Andy. I've got a 3 node netware cluster on the same subnet and I haven't ran into any heartbeat issues with it, but with OES Linux cluster not being exactly the same thing, I thought I'd ask.

I'm not sure if you're a leafs fan, but if you are, good luck with JVR. He has to potential to be a 70 point guy if he is motivated and can stay healthy.


My old:
Novel's Guide to Storage Area Networks and Novell Cluster Services (Payne & Wipfel) had a section in there about a major caveat with a dedicated heartbeat:

If the LAN segment assigned to the cluster resource (but not the VLAN) goes down, then the cluster will happily think everything's up and running (because the HEARTBEAT is up).

I opened an SR a few months ago to re-verify this is still the case with OES2 SP3 NCS, and NTS checked with backline and verified that the above scenario is still applicable.

So that's why I don't usually like to do a dedicated heartbeat VLAN with NCS.
0 Likes
Absent Member.
Absent Member.

kjhurni;2203796 wrote:
My old:
Novel's Guide to Storage Area Networks and Novell Cluster Services (Payne & Wipfel) had a section in there about a major caveat with a dedicated heartbeat:

If the LAN segment assigned to the cluster resource (but not the VLAN) goes down, then the cluster will happily think everything's up and running (because the HEARTBEAT is up).

I opened an SR a few months ago to re-verify this is still the case with OES2 SP3 NCS, and NTS checked with backline and verified that the above scenario is still applicable.

So that's why I don't usually like to do a dedicated heartbeat VLAN with NCS.


That's more than good enough for me. Thanks for the confirmation.

0 Likes
Knowledge Partner Knowledge Partner
Knowledge Partner

In article <imc.5es5nb@no-mx.forums.novell.com>, Imc wrote:
> I've got a 3 node netware cluster on the
> same subnet and I haven't ran into any heartbeat issues with it, but
> with OES Linux cluster not being exactly the same thing, I thought I'd
> ask.


Your welcome.
I've not seen any difference in the heartbeats between the NCS on NetWare
vs SLES from a casual look at the packets, so I wouldn't expect any
differences from that level. Just know your typical traffic, and if you
start getting poison pills, check that the traffic hasn't changed.

My wife is the hockey fan, so I'll just occasionally pop in and cheer for
the team other than whom she is cheering for <weg>, unless we are talking
about the Canadian National team, then I'll pay attention.


Andy Konecny
KonecnyConsulting.ca in Toronto
------------------------------------------------------------------------
Andy's Profile: http://forums.novell.com/member.php?userid=75037


___
“i’ve sworn an oath of solitude til the blight is purged from these lands”
Andy of Konecny Consulting in Toronto
Knowledge Partner Profile
If you find a post helpful, click the Like button below. Thanks!
0 Likes
Cadet 1st Class Cadet 1st Class
Cadet 1st Class

I am of the opinion that a node which cannot communicate with clients live SHOULD be ejected from the cluster. That is because I am more interested in real clients being able to access resources than making the cluster, for the clusters's sake, happy. I use the same network used for client traffic. If you are concerned about latency or priority, implement QoS on the interconnecting network and your heartbeats will not compete with client traffic, but fail when the transport fails - which is what you want.

-- Bob
0 Likes
The opinions expressed above are the personal opinions of the authors, not of Micro Focus. By using this site, you accept the Terms of Use and Rules of Participation. Certain versions of content ("Material") accessible here may contain branding from Hewlett-Packard Company (now HP Inc.) and Hewlett Packard Enterprise Company. As of September 1, 2017, the Material is now offered by Micro Focus, a separately owned and operated company. Any reference to the HP and Hewlett Packard Enterprise/HPE marks is historical in nature, and the HP and Hewlett Packard Enterprise/HPE marks are the property of their respective owners.