Re: [Veritas-ha] LLT heartbeat redundancy

2009-05-14 Thread Sandeep Agarwal (MTV)
This is not a recommended practice under Windows.
 
However, if NIC Teaming underneath can provide 1 MAC address and device
to LLT then this would work. Hasn't been tested and is not supported by
Symantec though.

-Original Message-
From: andreas.lundg...@steria.se
[mailto:andreas.lundg...@steria.se] 
Sent: Wednesday, May 13, 2009 9:39 AM
To: Sandeep Agarwal (MTV)
Cc: im...@inter.net.il; veritas-ha@mailman.eng.auburn.edu
Subject: Re: [Veritas-ha] LLT heartbeat redundancy



Since I seem to be about the only windows user of vcs in the
world ;-) I wonder a bit about this - I was under the impression this
was not recommended practice in a windows VCS environment, but it would
be supported according to these mails?

/a

Sent from a p990i

 Reply Header 
Subject: Re: [Veritas-ha] LLT heartbeat redundancy
Author: "Sandeep Agarwal (MTV)"
Date: 2009 May 13th 18:23

LLT does support Layer 2 link aggregation and can work over
trunks/bonds/aggregated links as long as a single device is presented to
it:
Linux - Bonding
Solaris - Sun Trunking (now link aggregation/dladm in Solaris
10)
HPUX - Auto Port Aggregation
AIX - Etherchannel

IPMP is at Layer 3 and Bonding and the others are at Layer 2 -
hence we can't compare the two. It would be better to compare Sun
Trunking and Linux Bonding.

-Original Message-
From: veritas-ha-boun...@mailman.eng.auburn.edu
[mailto:veritas-ha-boun...@mailman.eng.auburn.edu] On Behalf Of Imri
Zvik
Sent: Wednesday, May 13, 2009 2:38 AM
To: veritas-ha@mailman.eng.auburn.edu
    Subject: Re: [Veritas-ha] LLT heartbeat redundancy

On Wednesday 13 May 2009 06:04:38 John Cronin wrote:
> Getting slightly off topic, but still somewhat relevant.
>
> Linux has many flavors of Ethernet bonding. To be sure, link
> aggregation resulting in increased bandwidth is generally
supported on a single switch.
> However, Linux does have an active-passive bonding that is
> specifically intended for HA solutions. AIX has a similar
> configuration with the unfortunate name of EtherChannel
Network Backup
> Interface - it does NOT rely on Cisco EtherChannel to work.
Both of these create a "virtual NIC"
> that hides the complexity, making the interface group appear
to be a
> single NIC. You don't need a bunch of switch link aggregation
magic
> (802.11ad or
> EtherChannel) to implement active-passive NIC failover in this
manner.
>
> In my experience, both Linux and AIX Ethernet bonding are
easier to
> use than Sun IPMP, and they also are far more reliable. I have
a lot
> of experience with all three of these, and in my opinion IPMP
is the
> worst - I have experienced many "false failures" with IPMP,
and I have
> had to do a bunch of silliness with static routes to make it
work in
> certain environments (prior to the new link based IPMP - but
it has
> issues of its own too). I wish Sun wou




This email originates from Steria AB, Box 544, SE-182 15
Danderyd, Sweden, +46 8 622 42 00, http://www.steria.se. This email and
any attachments may contain confidential/intellectual property/copyright
information and is only for the use of the addressee(s). You are
prohibited from copying, forwarding, disclosing, saving or otherwise
using it in any way if you are not the addressee(s) or responsible for
delivery. If you receive this email by mistake, please advise the sender
and cancel it immediately. Steria may monitor the content of emails
within its network to ensure compliance with its policies and
procedures. Any email is susceptible to alteration and its integrity
cannot be assured. Steria shall not be liable if the message is altered,
modified, falsified, or even edited.


___
Veritas-ha maillist  -  Veritas-ha@mailman.eng.auburn.edu
http://mailman.eng.auburn.edu/mailman/listinfo/veritas-ha


Re: [Veritas-ha] LLT heartbeat redundancy

2009-05-13 Thread Andreas . Lundgren

Since I seem to be about the only windows user of vcs in the world ;-) I
wonder a bit about this - I was under the impression this was not
recommended practice in a windows VCS environment, but it would be
supported according to these mails?

/a

Sent from  a p990i

 Reply Header 
Subject:Re: [Veritas-ha] LLT heartbeat redundancy
Author: "Sandeep Agarwal (MTV)"
Date:   2009 May 13th 18:23

LLT does support Layer 2 link aggregation and can work over
trunks/bonds/aggregated links  as long as a single device is presented to
it:
Linux - Bonding
Solaris - Sun Trunking (now link aggregation/dladm in Solaris 10)
HPUX - Auto Port Aggregation
AIX - Etherchannel

IPMP is at Layer 3 and Bonding and the others are at Layer 2 - hence we
can't compare the two. It would be better to compare Sun Trunking and Linux
Bonding.

-Original Message-
From: veritas-ha-boun...@mailman.eng.auburn.edu
[mailto:veritas-ha-boun...@mailman.eng.auburn.edu] On Behalf Of Imri Zvik
Sent: Wednesday, May 13, 2009 2:38 AM
To: veritas-ha@mailman.eng.auburn.edu
Subject: Re: [Veritas-ha] LLT heartbeat redundancy

On Wednesday 13 May 2009 06:04:38 John Cronin wrote:
> Getting slightly off topic, but still somewhat relevant.
>
> Linux has many flavors of Ethernet bonding.  To be sure, link
> aggregation resulting in increased bandwidth is generally supported on a
single switch.
> However, Linux does have an active-passive bonding that is
> specifically intended for HA solutions.  AIX has a similar
> configuration with the unfortunate name of EtherChannel Network Backup
> Interface - it does NOT rely on Cisco EtherChannel to work.  Both of
these create a "virtual NIC"
> that hides the complexity, making the interface group appear to be a
> single NIC. You don't need a bunch of switch link aggregation magic
> (802.11ad or
> EtherChannel) to implement active-passive NIC failover in this manner.
>
> In my experience, both Linux and AIX Ethernet bonding are easier to
> use than Sun IPMP, and they also are far more reliable.  I have a lot
> of experience with all three of these, and in my opinion IPMP is the
> worst - I have experienced many "false failures" with IPMP, and I have
> had to do a bunch of silliness with static routes to make it work in
> certain environments (prior to the new link based IPMP - but it has
> issues of its own too).  I wish Sun wou

This email originates from Steria AB, Box 544, SE-182 15  Danderyd, Sweden, +46 
8 622 42 00, http://www.steria.se. This email and any attachments may contain 
confidential/intellectual property/copyright information and is only for the 
use of the addressee(s). You are prohibited from copying, forwarding, 
disclosing, saving or otherwise using it in any way if you are not the 
addressee(s) or responsible for delivery. If you receive this email by mistake, 
please advise the sender and cancel it immediately. Steria may monitor the 
content of emails within its network to ensure compliance with its policies and 
procedures. Any email is susceptible to alteration and its integrity cannot be 
assured. Steria shall not be liable if the message is altered, modified, 
falsified, or even edited.
___
Veritas-ha maillist  -  Veritas-ha@mailman.eng.auburn.edu
http://mailman.eng.auburn.edu/mailman/listinfo/veritas-ha


Re: [Veritas-ha] LLT heartbeat redundancy

2009-05-13 Thread Sandeep Agarwal (MTV)
LLT does support Layer 2 link aggregation and can work over 
trunks/bonds/aggregated links  as long as a single device is presented to it:
Linux - Bonding
Solaris - Sun Trunking (now link aggregation/dladm in Solaris 10)
HPUX - Auto Port Aggregation
AIX - Etherchannel

IPMP is at Layer 3 and Bonding and the others are at Layer 2 - hence we can't 
compare the two. It would be better to compare Sun Trunking and Linux Bonding.  

-Original Message-
From: veritas-ha-boun...@mailman.eng.auburn.edu 
[mailto:veritas-ha-boun...@mailman.eng.auburn.edu] On Behalf Of Imri Zvik
Sent: Wednesday, May 13, 2009 2:38 AM
To: veritas-ha@mailman.eng.auburn.edu
Subject: Re: [Veritas-ha] LLT heartbeat redundancy

On Wednesday 13 May 2009 06:04:38 John Cronin wrote:
> Getting slightly off topic, but still somewhat relevant.
>
> Linux has many flavors of Ethernet bonding.  To be sure, link 
> aggregation resulting in increased bandwidth is generally supported on a 
> single switch.
> However, Linux does have an active-passive bonding that is 
> specifically intended for HA solutions.  AIX has a similar 
> configuration with the unfortunate name of EtherChannel Network Backup 
> Interface - it does NOT rely on Cisco EtherChannel to work.  Both of these 
> create a "virtual NIC"
> that hides the complexity, making the interface group appear to be a 
> single NIC. You don't need a bunch of switch link aggregation magic 
> (802.11ad or
> EtherChannel) to implement active-passive NIC failover in this manner.
>
> In my experience, both Linux and AIX Ethernet bonding are easier to 
> use than Sun IPMP, and they also are far more reliable.  I have a lot 
> of experience with all three of these, and in my opinion IPMP is the 
> worst - I have experienced many "false failures" with IPMP, and I have 
> had to do a bunch of silliness with static routes to make it work in 
> certain environments (prior to the new link based IPMP - but it has 
> issues of its own too).  I wish Sun would add an active-passive 
> capability to their new link aggregation capability (dladm) that works 
> across switches.  If they did that, they would have the same 
> capabilities as Linux and AIX network bonding, with similar ease of 
> use.  It should be fairly trivial to implement.
>
> The one advantage that IPMP has in active-active mode (e.g. NOT link 
> based) is that it can detect IP connectivity issues (via ping - not 
> just Ethernet link detection) on all NICs in an interface group.  
> However, it is usually issues with the IP connectivity checking that 
> cause all my problems with IPMP, and I would gladly trade it for a 
> simple link based virtual solution that looks like a single link to me.

The linux bonding driver can do ARP test, in order to detect uplink failures.
This is not a layer 3 check, but in most solutions and configurations, it is a 
suitbale replacment.

>
> I have never used Linux Ethernet bonding or AIX Etherchannel Network 
> Backup Interface for VCS heartbeats, but I am pretty certain they 
> would both work fine.  That said, I am not sure they would provide any 
> significant benefit over a "traditional" VCS heartbeat network 
> configuration, using the same number of "real" NICs.

The benefit is that with such bonding method, you can survive the failure 
scenario I've described in my first email :)

It is a fact Symantec understands that, as they are trying to solve it 
internally in LLT :)

>
> --
> John Cronin
___
Veritas-ha maillist  -  Veritas-ha@mailman.eng.auburn.edu 
http://mailman.eng.auburn.edu/mailman/listinfo/veritas-ha
___
Veritas-ha maillist  -  Veritas-ha@mailman.eng.auburn.edu
http://mailman.eng.auburn.edu/mailman/listinfo/veritas-ha


Re: [Veritas-ha] LLT heartbeat redundancy

2009-05-13 Thread Imri Zvik
On Wednesday 13 May 2009 06:04:38 John Cronin wrote:
> Getting slightly off topic, but still somewhat relevant.
>
> Linux has many flavors of Ethernet bonding.  To be sure, link aggregation
> resulting in increased bandwidth is generally supported on a single switch.
> However, Linux does have an active-passive bonding that is specifically
> intended for HA solutions.  AIX has a similar configuration with the
> unfortunate name of EtherChannel Network Backup Interface - it does NOT
> rely on Cisco EtherChannel to work.  Both of these create a "virtual NIC"
> that hides the complexity, making the interface group appear to be a single
> NIC. You don't need a bunch of switch link aggregation magic (802.11ad or
> EtherChannel) to implement active-passive NIC failover in this manner.
>
> In my experience, both Linux and AIX Ethernet bonding are easier to use
> than Sun IPMP, and they also are far more reliable.  I have a lot of
> experience with all three of these, and in my opinion IPMP is the worst - I
> have experienced many "false failures" with IPMP, and I have had to do a
> bunch of silliness with static routes to make it work in certain
> environments (prior to the new link based IPMP - but it has issues of its
> own too).  I wish Sun would add an active-passive capability to their new
> link aggregation capability (dladm) that works across switches.  If they
> did that, they would have the same capabilities as Linux and AIX network
> bonding, with similar ease of use.  It should be fairly trivial to
> implement.
>
> The one advantage that IPMP has in active-active mode (e.g. NOT link based)
> is that it can detect IP connectivity issues (via ping - not just Ethernet
> link detection) on all NICs in an interface group.  However, it is usually
> issues with the IP connectivity checking that cause all my problems with
> IPMP, and I would gladly trade it for a simple link based virtual solution
> that looks like a single link to me.

The linux bonding driver can do ARP test, in order to detect uplink failures.
This is not a layer 3 check, but in most solutions and configurations, it is a 
suitbale replacment.

>
> I have never used Linux Ethernet bonding or AIX Etherchannel Network Backup
> Interface for VCS heartbeats, but I am pretty certain they would both work
> fine.  That said, I am not sure they would provide any significant benefit
> over a "traditional" VCS heartbeat network configuration, using the same
> number of "real" NICs.

The benefit is that with such bonding method, you can survive the failure 
scenario I've described in my first email :)

It is a fact Symantec understands that, as they are trying to solve it 
internally in LLT :)

>
> --
> John Cronin
___
Veritas-ha maillist  -  Veritas-ha@mailman.eng.auburn.edu
http://mailman.eng.auburn.edu/mailman/listinfo/veritas-ha


Re: [Veritas-ha] LLT heartbeat redundancy

2009-05-13 Thread Imri Zvik
On Thursday 07 May 2009 14:11:02 John Cronin wrote:
> On thing to consider - don't you want to know when you lose a heartbeat
> link?  I know the lost link will be noted in /var/log/messages or wherever
> your syslog configuration indicates, but I would want it in my VCS logs
> somewhere too.

Of course - But this messages appears during normal operations - i.e. when the 
two links are active and working. Veritas says that when the heartbeat links 
are not isolated, this is the result. This whole thread is about the new 
feature that allows HB links to be not-isolated, in order to allow full mesh.

>
> Also, are you using one or two bonded pairs?  In other words, do you still
> have two private heartbeats?  If you are using a single pair, are you also
> using a low-priority heartbeat on your "real" network?

We are talking about 2 physical connections, not bonded, and the low-priority 
link is irrelevant. If you will read my original question, you'll understand 
the problem in the current design of the HB links.

>
> Also, are you using I/O fencing to protect your data?

No, I/O fencing is not supported for Veritas Cluster File System for Oracle 
RAC, but this is also irrelevant, please read my original question.

>
> The reason I ask is this - what is going to happen if/when you lose one
> link, then a few days later you lose the other link?  The answer is that
> BOTH of your servers will decide they are the only survivors, and they will
> BOTH attempt to bring your storage online and start the application.  If
> you don't have I/O fencing enabled, this will most likely lead to data
> corruption - time to start looking for the backups.
>
> By default, in the "normal" VCS heartbeat configuration, if you lose one
> heartbeat link, and then more than 16 seconds elapse, you go into a
> "jeopardy" state.  If you then lose the other heartbeat link, the service
> groups are "Autodisabled", to prevent a network induced split brain
> condition from causing data corruption.


___
Veritas-ha maillist  -  Veritas-ha@mailman.eng.auburn.edu
http://mailman.eng.auburn.edu/mailman/listinfo/veritas-ha


Re: [Veritas-ha] LLT heartbeat redundancy

2009-05-13 Thread Imri Zvik
On Wednesday 13 May 2009 05:27:00 Hudes, Dana wrote:
> I don't care what tricks Linux plays or what they call it. From a
> network perspective, true bonding requires connection to the same
> switch/router and is done at the link layer. You don't have 2 IP
> interfaces, you have one. The bits go out round-robin. It requires
> support by the link partner/peer (i.e., you could do it with multiple
> crossover connections between two hosts which have the appropriate
> drivers).

No, you have 2 interfaces, and the IP binding jumps from one interface to the 
other. This is very much different than how other modern operating systems 
works (FreeBSD, Linux etc.) - They present a logical interface which hides 
the underlying interfaces, and therefore let you configure a consistent name 
in the application which requires to know the name of the interface (LLT, for 
example).


>
> Solaris IPMP supports both active/active and active/passive (at least as
> of Solaris 10).
>
> http://docs.sun.com/app/docs/doc/816-4554/eobra?l=en&a=view&q=ipmp

I know how IPMP works, and we use it quite a lot, but IPMP cannot help me 
solve the failure scenario I've described in my first post.

>
> Note that you can configure multiple VLANs into an IPMP group on one
> interface. This doesn't give you any failover/failback capability: if
> the link peer goes away, your link is down.
>
> With active/active, you can have IPMP load spreading. This is only
> effective with multiple IP destinations (even if those multiple IP
> destinations are logical interfaces on one NIC on one host).
>
> IPMP groups are strictly the same media type but you can (and I have)
> have a copper 100baseT port in the same group as a 1000baseF port:
> they're both Ethernet. This does not work to backup an ATM interface
> with an Ethernet interface etc. (I'm not sure if you could backup a LANE
> interface with a classical IP-over-ATM interface and I haven't any ATM
> switches to try it with these days).
>
> Since this is an IP-level redundancy and LLT doesn't use IP it's not
> going to help VCS.
>
> IPMP is a replacement / successor to Sun Enterprise Alternate Pathing
> (and is incompatible with it). In short, AP was for the Enterprise 1
> only and provided a means of rerouting the connection to an HBA (whether
> for storage or network). It is replaced by IPMP and MPXIO (which is
> better than Veritas DMP but only in Solaris 10+).
>
> Bonding isn't really something I expect to see in an Ethernet
> environment but perhaps that's because I used to do it in an ATM
> environment years ago. I'll have to look into what modern Ethernet LANs
> do in this regard.

Bonding (read - failover link aggregation) really helps HA solutions, and 
from "smarter" implementations of said feature, LLT can benefit a lot.
___
Veritas-ha maillist  -  Veritas-ha@mailman.eng.auburn.edu
http://mailman.eng.auburn.edu/mailman/listinfo/veritas-ha


Re: [Veritas-ha] LLT heartbeat redundancy

2009-05-12 Thread John Cronin
Getting slightly off topic, but still somewhat relevant.

Linux has many flavors of Ethernet bonding.  To be sure, link aggregation
resulting in increased bandwidth is generally supported on a single switch.
However, Linux does have an active-passive bonding that is specifically
intended for HA solutions.  AIX has a similar configuration with the
unfortunate name of EtherChannel Network Backup Interface - it does NOT rely
on Cisco EtherChannel to work.  Both of these create a "virtual NIC" that
hides the complexity, making the interface group appear to be a single NIC.
You don't need a bunch of switch link aggregation magic (802.11ad or
EtherChannel) to implement active-passive NIC failover in this manner.

In my experience, both Linux and AIX Ethernet bonding are easier to use than
Sun IPMP, and they also are far more reliable.  I have a lot of experience
with all three of these, and in my opinion IPMP is the worst - I have
experienced many "false failures" with IPMP, and I have had to do a bunch of
silliness with static routes to make it work in certain environments (prior
to the new link based IPMP - but it has issues of its own too).  I wish Sun
would add an active-passive capability to their new link aggregation
capability (dladm) that works across switches.  If they did that, they would
have the same capabilities as Linux and AIX network bonding, with similar
ease of use.  It should be fairly trivial to implement.

The one advantage that IPMP has in active-active mode (e.g. NOT link based)
is that it can detect IP connectivity issues (via ping - not just Ethernet
link detection) on all NICs in an interface group.  However, it is usually
issues with the IP connectivity checking that cause all my problems with
IPMP, and I would gladly trade it for a simple link based virtual solution
that looks like a single link to me.

I have never used Linux Ethernet bonding or AIX Etherchannel Network Backup
Interface for VCS heartbeats, but I am pretty certain they would both work
fine.  That said, I am not sure they would provide any significant benefit
over a "traditional" VCS heartbeat network configuration, using the same
number of "real" NICs.

-- 
John Cronin

On Tue, May 12, 2009 at 10:27 PM, Hudes, Dana  wrote:

> I don't care what tricks Linux plays or what they call it. From a
> network perspective, true bonding requires connection to the same
> switch/router and is done at the link layer. You don't have 2 IP
> interfaces, you have one. The bits go out round-robin. It requires
> support by the link partner/peer (i.e., you could do it with multiple
> crossover connections between two hosts which have the appropriate
> drivers).
>
> Solaris IPMP supports both active/active and active/passive (at least as
> of Solaris 10).
>
> http://docs.sun.com/app/docs/doc/816-4554/eobra?l=en&a=view&q=ipmp
>
> Note that you can configure multiple VLANs into an IPMP group on one
> interface. This doesn't give you any failover/failback capability: if
> the link peer goes away, your link is down.
>
> With active/active, you can have IPMP load spreading. This is only
> effective with multiple IP destinations (even if those multiple IP
> destinations are logical interfaces on one NIC on one host).
>
> IPMP groups are strictly the same media type but you can (and I have)
> have a copper 100baseT port in the same group as a 1000baseF port:
> they're both Ethernet. This does not work to backup an ATM interface
> with an Ethernet interface etc. (I'm not sure if you could backup a LANE
> interface with a classical IP-over-ATM interface and I haven't any ATM
> switches to try it with these days).
>
> Since this is an IP-level redundancy and LLT doesn't use IP it's not
> going to help VCS.
>
> IPMP is a replacement / successor to Sun Enterprise Alternate Pathing
> (and is incompatible with it). In short, AP was for the Enterprise 1
> only and provided a means of rerouting the connection to an HBA (whether
> for storage or network). It is replaced by IPMP and MPXIO (which is
> better than Veritas DMP but only in Solaris 10+).
>
> Bonding isn't really something I expect to see in an Ethernet
> environment but perhaps that's because I used to do it in an ATM
> environment years ago. I'll have to look into what modern Ethernet LANs
> do in this regard.
>
>
> =
> Dana Hudes
> UNIX and Imaging group
> NYC-HRA MIS
> +1 718 510 8586
> Nextel:  172*26*16684
> =
>
> -Original Message-
> From: Imri Zvik [mailto:im...@inter.net.il]
> Sent: Tuesday, May 12, 2009 9:54 PM
> To: Hudes, Dana; veritas-ha@mailman.eng.auburn.edu
> Subject: RE: [Veritas-ha] LLT heartbeat redundancy
>
> Hi Dana,
>
> We were talking about L

Re: [Veritas-ha] LLT heartbeat redundancy

2009-05-12 Thread Hudes, Dana
I don't care what tricks Linux plays or what they call it. From a
network perspective, true bonding requires connection to the same
switch/router and is done at the link layer. You don't have 2 IP
interfaces, you have one. The bits go out round-robin. It requires
support by the link partner/peer (i.e., you could do it with multiple
crossover connections between two hosts which have the appropriate
drivers).

Solaris IPMP supports both active/active and active/passive (at least as
of Solaris 10).

http://docs.sun.com/app/docs/doc/816-4554/eobra?l=en&a=view&q=ipmp

Note that you can configure multiple VLANs into an IPMP group on one
interface. This doesn't give you any failover/failback capability: if
the link peer goes away, your link is down.

With active/active, you can have IPMP load spreading. This is only
effective with multiple IP destinations (even if those multiple IP
destinations are logical interfaces on one NIC on one host). 

IPMP groups are strictly the same media type but you can (and I have)
have a copper 100baseT port in the same group as a 1000baseF port:
they're both Ethernet. This does not work to backup an ATM interface
with an Ethernet interface etc. (I'm not sure if you could backup a LANE
interface with a classical IP-over-ATM interface and I haven't any ATM
switches to try it with these days).

Since this is an IP-level redundancy and LLT doesn't use IP it's not
going to help VCS.

IPMP is a replacement / successor to Sun Enterprise Alternate Pathing
(and is incompatible with it). In short, AP was for the Enterprise 1
only and provided a means of rerouting the connection to an HBA (whether
for storage or network). It is replaced by IPMP and MPXIO (which is
better than Veritas DMP but only in Solaris 10+).

Bonding isn't really something I expect to see in an Ethernet
environment but perhaps that's because I used to do it in an ATM
environment years ago. I'll have to look into what modern Ethernet LANs
do in this regard.


=
Dana Hudes
UNIX and Imaging group
NYC-HRA MIS
+1 718 510 8586
Nextel:  172*26*16684
=

-Original Message-
From: Imri Zvik [mailto:im...@inter.net.il] 
Sent: Tuesday, May 12, 2009 9:54 PM
To: Hudes, Dana; veritas-ha@mailman.eng.auburn.edu
Subject: RE: [Veritas-ha] LLT heartbeat redundancy

Hi Dana,

We were talking about Linux bonding compared to Solaris IPMP.
While Solaris link aggregation (apparently) cannot do active/backup,
Linux
can, and therefore in Linux you can put each link on a separate switch
(http://www.kernel.org/pub/linux/kernel/people/marcelo/linux-2.4/Documen
tati
on/networking/bonding.txt).
The whole point of the discussion was how to take the level of
redundancy
you get for LLT in Linux by using bonding to Solaris by using pure LLT
level
solution instead of counting on OS specific solutions (As IPMP doesn't
actually create a logical interface, LLT cannot use it).


-Original Message-
From: Hudes, Dana [mailto:hud...@hra.nyc.gov] 
Sent: Tuesday, May 12, 2009 11:28 PM
To: veritas-ha@mailman.eng.auburn.edu
Subject: Re: [Veritas-ha] LLT heartbeat redundancy

Bonding is combining multiple links into one virtual circuit. It isn't
usually visible to the OS. IPMP is a bit different. While the result is
similar, it's a question of at what level of the tcp/ip stack the
combination is done. Bonding is at the media (MAC) layer from an IP
perspective (though the OSI model breaks the layers down differently).
IPMP is at the network layer. 

If the combined connections have individual IP addresses, that's
multi-path not bonding. 

There are implications here beyond clustering, including the switch and
the router as well as how the increase in bandwidth (if both links are
active at once) is achieved.  More usual is the use of IPMP to provide
standby links: each link has its own IP address and there is an IPMP IP
address. Remote hosts use the IPMP address. Often, you will have a
primary link which is higher speed / larger bandwidth than the secondary
(e.g. gigabit primary and 100 megabit secondary).

If you are bonding you must go to the same switch with both links. This
provides protection, in the form of degradation of capacity, against
port failure on either end of a given path or cable failure of a given
path. It does not protect you against switch failure.

IPMP, when done properly, has two paths each going to a separate switch.
This protects against everything that bonding does while also protecting
against switch failure. In the case of switch failure, the standby port
becomes active and ARP answers for the virtual IP on that port. The
routing protocol, which hopefully is OSPF, quickly redirects the traffic
to the new port and you don't even lose your TCP connection due to
retransmit (some UDP packets inevitably are lost; an application
protocol may have it's own retransmit timer but that's not UDP's
bus

Re: [Veritas-ha] LLT heartbeat redundancy

2009-05-12 Thread Imri Zvik
Hi Dana,

We were talking about Linux bonding compared to Solaris IPMP.
While Solaris link aggregation (apparently) cannot do active/backup, Linux
can, and therefore in Linux you can put each link on a separate switch
(http://www.kernel.org/pub/linux/kernel/people/marcelo/linux-2.4/Documentati
on/networking/bonding.txt).
The whole point of the discussion was how to take the level of redundancy
you get for LLT in Linux by using bonding to Solaris by using pure LLT level
solution instead of counting on OS specific solutions (As IPMP doesn't
actually create a logical interface, LLT cannot use it).


-Original Message-
From: Hudes, Dana [mailto:hud...@hra.nyc.gov] 
Sent: Tuesday, May 12, 2009 11:28 PM
To: veritas-ha@mailman.eng.auburn.edu
Subject: Re: [Veritas-ha] LLT heartbeat redundancy

Bonding is combining multiple links into one virtual circuit. It isn't
usually visible to the OS. IPMP is a bit different. While the result is
similar, it's a question of at what level of the tcp/ip stack the
combination is done. Bonding is at the media (MAC) layer from an IP
perspective (though the OSI model breaks the layers down differently).
IPMP is at the network layer. 

If the combined connections have individual IP addresses, that's
multi-path not bonding. 

There are implications here beyond clustering, including the switch and
the router as well as how the increase in bandwidth (if both links are
active at once) is achieved.  More usual is the use of IPMP to provide
standby links: each link has its own IP address and there is an IPMP IP
address. Remote hosts use the IPMP address. Often, you will have a
primary link which is higher speed / larger bandwidth than the secondary
(e.g. gigabit primary and 100 megabit secondary).

If you are bonding you must go to the same switch with both links. This
provides protection, in the form of degradation of capacity, against
port failure on either end of a given path or cable failure of a given
path. It does not protect you against switch failure.

IPMP, when done properly, has two paths each going to a separate switch.
This protects against everything that bonding does while also protecting
against switch failure. In the case of switch failure, the standby port
becomes active and ARP answers for the virtual IP on that port. The
routing protocol, which hopefully is OSPF, quickly redirects the traffic
to the new port and you don't even lose your TCP connection due to
retransmit (some UDP packets inevitably are lost; an application
protocol may have it's own retransmit timer but that's not UDP's
business).



=
Dana Hudes
UNIX and Imaging group
NYC-HRA MIS
+1 718 510 8586
Nextel:  172*26*16684
=

-Original Message-
From: veritas-ha-boun...@mailman.eng.auburn.edu
[mailto:veritas-ha-boun...@mailman.eng.auburn.edu] On Behalf Of Imri
Zvik
Sent: Sunday, May 03, 2009 12:18 PM
To: Jim Senicka
Cc: veritas-ha@mailman.eng.auburn.edu
Subject: Re: [Veritas-ha] LLT heartbeat redundancy

On Sunday 03 May 2009 19:03:16 Jim Senicka wrote:
> This is not a limitation, as you had two independent failures. Bonding
> would remove the ability to discriminate between a link and a node
> failure.

I didn't understand this one - With bonding I can maintain full mesh 
topology - No matter which one of the links fails, if a node still has
at 
least one active link, LLT will still be able to see all the other
nodes. 
This achieves greater HA than without the bonding.


> My feeling is in the scenario you describe, VCS is operating properly,
> and it is not a limitation.

Of course it is operating properly - that's how it was designed to work
:)
I'm just saying that the cluster could be more redundant if it wasn't
designed 
that way :)

> If you have issues with port or cable failures, add a low pri
connection
> on a third network.



___
Veritas-ha maillist  -  Veritas-ha@mailman.eng.auburn.edu
http://mailman.eng.auburn.edu/mailman/listinfo/veritas-ha
___
Veritas-ha maillist  -  Veritas-ha@mailman.eng.auburn.edu
http://mailman.eng.auburn.edu/mailman/listinfo/veritas-ha

___
Veritas-ha maillist  -  Veritas-ha@mailman.eng.auburn.edu
http://mailman.eng.auburn.edu/mailman/listinfo/veritas-ha


Re: [Veritas-ha] LLT heartbeat redundancy

2009-05-12 Thread Hudes, Dana
Bonding is combining multiple links into one virtual circuit. It isn't
usually visible to the OS. IPMP is a bit different. While the result is
similar, it's a question of at what level of the tcp/ip stack the
combination is done. Bonding is at the media (MAC) layer from an IP
perspective (though the OSI model breaks the layers down differently).
IPMP is at the network layer. 

If the combined connections have individual IP addresses, that's
multi-path not bonding. 

There are implications here beyond clustering, including the switch and
the router as well as how the increase in bandwidth (if both links are
active at once) is achieved.  More usual is the use of IPMP to provide
standby links: each link has its own IP address and there is an IPMP IP
address. Remote hosts use the IPMP address. Often, you will have a
primary link which is higher speed / larger bandwidth than the secondary
(e.g. gigabit primary and 100 megabit secondary).

If you are bonding you must go to the same switch with both links. This
provides protection, in the form of degradation of capacity, against
port failure on either end of a given path or cable failure of a given
path. It does not protect you against switch failure.

IPMP, when done properly, has two paths each going to a separate switch.
This protects against everything that bonding does while also protecting
against switch failure. In the case of switch failure, the standby port
becomes active and ARP answers for the virtual IP on that port. The
routing protocol, which hopefully is OSPF, quickly redirects the traffic
to the new port and you don't even lose your TCP connection due to
retransmit (some UDP packets inevitably are lost; an application
protocol may have it's own retransmit timer but that's not UDP's
business).



=
Dana Hudes
UNIX and Imaging group
NYC-HRA MIS
+1 718 510 8586
Nextel:  172*26*16684
=

-Original Message-
From: veritas-ha-boun...@mailman.eng.auburn.edu
[mailto:veritas-ha-boun...@mailman.eng.auburn.edu] On Behalf Of Imri
Zvik
Sent: Sunday, May 03, 2009 12:18 PM
To: Jim Senicka
Cc: veritas-ha@mailman.eng.auburn.edu
Subject: Re: [Veritas-ha] LLT heartbeat redundancy

On Sunday 03 May 2009 19:03:16 Jim Senicka wrote:
> This is not a limitation, as you had two independent failures. Bonding
> would remove the ability to discriminate between a link and a node
> failure.

I didn't understand this one - With bonding I can maintain full mesh 
topology - No matter which one of the links fails, if a node still has
at 
least one active link, LLT will still be able to see all the other
nodes. 
This achieves greater HA than without the bonding.


> My feeling is in the scenario you describe, VCS is operating properly,
> and it is not a limitation.

Of course it is operating properly - that's how it was designed to work
:)
I'm just saying that the cluster could be more redundant if it wasn't
designed 
that way :)

> If you have issues with port or cable failures, add a low pri
connection
> on a third network.



___
Veritas-ha maillist  -  Veritas-ha@mailman.eng.auburn.edu
http://mailman.eng.auburn.edu/mailman/listinfo/veritas-ha
___
Veritas-ha maillist  -  Veritas-ha@mailman.eng.auburn.edu
http://mailman.eng.auburn.edu/mailman/listinfo/veritas-ha


Re: [Veritas-ha] LLT heartbeat redundancy

2009-05-08 Thread Sandeep Agarwal (MTV)
Yes, the jeopardy detection etc has not changed.
 
We've just added support for this new type of topology in which the
various LLT links are interconnected (crosslinks).

-Original Message-
From: John Cronin [mailto:jsc3...@gmail.com] 
Sent: Friday, May 08, 2009 6:58 AM
To: Sandeep Agarwal (MTV)
Cc: Jim Senicka; Imri Zvik; veritas-ha@mailman.eng.auburn.edu
Subject: Re: [Veritas-ha] LLT heartbeat redundancy


This was certainly news to me.

In this full-mesh heartbeat network, do we still go into
jeopardy if the network links are lost relatively slowly (e.g. if one
link on a node is down for more than 16 seconds by default)?


On Sun, May 3, 2009 at 1:07 PM, Sandeep Agarwal (MTV)
 wrote:


From 5.0MP3 onwards we do support cross-links. In your
example if you
had a cable connecting sw1 and sw2 then the failure that
you described
would be handled and LLT would still have 1 valid link
between node 1
and node 4.


-Original Message-
From: veritas-ha-boun...@mailman.eng.auburn.edu

[mailto:veritas-ha-boun...@mailman.eng.auburn.edu] On
Behalf Of Jim
Senicka
Sent: Sunday, May 03, 2009 9:23 AM
To: Imri Zvik
Cc: veritas-ha@mailman.eng.auburn.edu
Subject: Re: [Veritas-ha] LLT heartbeat redundancy

LLT is designed to use "jeopardy" to detect the
difference between
single link fail and dual link fail in most situations.
Having a single
mesh may remove this capability.

Let me check on this with engineering and see if we have
any more up to
date recommendations


-Original Message-
From: veritas-ha-boun...@mailman.eng.auburn.edu
[mailto:veritas-ha-boun...@mailman.eng.auburn.edu] On
Behalf Of Imri
Zvik
Sent: Sunday, May 03, 2009 12:18 PM
To: Jim Senicka
Cc: veritas-ha@mailman.eng.auburn.edu
        Subject: Re: [Veritas-ha] LLT heartbeat redundancy

On Sunday 03 May 2009 19:03:16 Jim Senicka wrote:
> This is not a limitation, as you had two independent
failures. Bonding

> would remove the ability to discriminate between a
link and a node
> failure.

I didn't understand this one - With bonding I can
maintain full mesh
topology - No matter which one of the links fails, if a
node still has
at least one active link, LLT will still be able to see
all the other
nodes.
This achieves greater HA than without the bonding.


> My feeling is in the scenario you describe, VCS is
operating properly,

> and it is not a limitation.

Of course it is operating properly - that's how it was
designed to work
:)
I'm just saying that the cluster could be more redundant
if it wasn't
designed that way :)

> If you have issues with port or cable failures, add a
low pri
connection
> on a third network.



___
Veritas-ha maillist  -
Veritas-ha@mailman.eng.auburn.edu

http://mailman.eng.auburn.edu/mailman/listinfo/veritas-ha
___
Veritas-ha maillist  -
Veritas-ha@mailman.eng.auburn.edu

http://mailman.eng.auburn.edu/mailman/listinfo/veritas-ha
___
Veritas-ha maillist  -
Veritas-ha@mailman.eng.auburn.edu

http://mailman.eng.auburn.edu/mailman/listinfo/veritas-ha



___
Veritas-ha maillist  -  Veritas-ha@mailman.eng.auburn.edu
http://mailman.eng.auburn.edu/mailman/listinfo/veritas-ha


Re: [Veritas-ha] LLT heartbeat redundancy

2009-05-08 Thread John Cronin
This was certainly news to me.

In this full-mesh heartbeat network, do we still go into jeopardy if the
network links are lost relatively slowly (e.g. if one link on a node is down
for more than 16 seconds by default)?

On Sun, May 3, 2009 at 1:07 PM, Sandeep Agarwal (MTV) <
sandeep_agarw...@symantec.com> wrote:

> From 5.0MP3 onwards we do support cross-links. In your example if you
> had a cable connecting sw1 and sw2 then the failure that you described
> would be handled and LLT would still have 1 valid link between node 1
> and node 4.
>
> -Original Message-
> From: veritas-ha-boun...@mailman.eng.auburn.edu
> [mailto:veritas-ha-boun...@mailman.eng.auburn.edu] On Behalf Of Jim
> Senicka
> Sent: Sunday, May 03, 2009 9:23 AM
> To: Imri Zvik
> Cc: veritas-ha@mailman.eng.auburn.edu
> Subject: Re: [Veritas-ha] LLT heartbeat redundancy
>
> LLT is designed to use "jeopardy" to detect the difference between
> single link fail and dual link fail in most situations. Having a single
> mesh may remove this capability.
>
> Let me check on this with engineering and see if we have any more up to
> date recommendations
>
>
> -Original Message-
> From: veritas-ha-boun...@mailman.eng.auburn.edu
> [mailto:veritas-ha-boun...@mailman.eng.auburn.edu] On Behalf Of Imri
> Zvik
> Sent: Sunday, May 03, 2009 12:18 PM
> To: Jim Senicka
> Cc: veritas-ha@mailman.eng.auburn.edu
> Subject: Re: [Veritas-ha] LLT heartbeat redundancy
>
> On Sunday 03 May 2009 19:03:16 Jim Senicka wrote:
> > This is not a limitation, as you had two independent failures. Bonding
>
> > would remove the ability to discriminate between a link and a node
> > failure.
>
> I didn't understand this one - With bonding I can maintain full mesh
> topology - No matter which one of the links fails, if a node still has
> at least one active link, LLT will still be able to see all the other
> nodes.
> This achieves greater HA than without the bonding.
>
>
> > My feeling is in the scenario you describe, VCS is operating properly,
>
> > and it is not a limitation.
>
> Of course it is operating properly - that's how it was designed to work
> :)
> I'm just saying that the cluster could be more redundant if it wasn't
> designed that way :)
>
> > If you have issues with port or cable failures, add a low pri
> connection
> > on a third network.
>
>
>
> ___
> Veritas-ha maillist  -  Veritas-ha@mailman.eng.auburn.edu
> http://mailman.eng.auburn.edu/mailman/listinfo/veritas-ha
> ___
> Veritas-ha maillist  -  Veritas-ha@mailman.eng.auburn.edu
> http://mailman.eng.auburn.edu/mailman/listinfo/veritas-ha
> ___
> Veritas-ha maillist  -  Veritas-ha@mailman.eng.auburn.edu
> http://mailman.eng.auburn.edu/mailman/listinfo/veritas-ha
>
___
Veritas-ha maillist  -  Veritas-ha@mailman.eng.auburn.edu
http://mailman.eng.auburn.edu/mailman/listinfo/veritas-ha


Re: [Veritas-ha] LLT heartbeat redundancy

2009-05-06 Thread Imri Zvik
On Wednesday 06 May 2009 19:49:27 Sandeep Agarwal (MTV) wrote:
> The lost hb messages are due to problems in Layer 2 connectivity.

When I transform the two links into a bonded interface, the lost hb messages 
goes away (even when I fail over the active NIC back and forth).

Is this new feature is supported (I.E. will the tech support support me if I 
will open a case regarding this feature)?


___
Veritas-ha maillist  -  Veritas-ha@mailman.eng.auburn.edu
http://mailman.eng.auburn.edu/mailman/listinfo/veritas-ha


Re: [Veritas-ha] LLT heartbeat redundancy

2009-05-06 Thread Sandeep Agarwal (MTV)
The lost hb messages are due to problems in Layer 2 connectivity.

In the cross-linked case as long as 1 link is up on each node LLT should
work fine (after a 2s glitch).

The llttab file is fine.

-Original Message-
From: Imri Zvik [mailto:im...@inter.net.il] 
Sent: Wednesday, May 06, 2009 1:44 AM
To: Sandeep Agarwal (MTV)
Cc: veritas-ha@mailman.eng.auburn.edu
Subject: Re: [Veritas-ha] LLT heartbeat redundancy


On Wednesday 06 May 2009 00:55:23 you wrote:
> Nothing to add to /etc/llttab
>
> If you have 50MP3 then it should work.

So considering the following llttab file:

set-node rac-node1
set-cluster 0
link eth2 eth-00:21:5e:1f:0b:b0 - ether - -
link eth3 eth-00:21:5e:1f:0b:b1 - ether - -

and that eth2 and eth3 are on the same layer2 subnet (i.e. "sees" each
other), 
I shouldn't get the lost hb messages?

___
Veritas-ha maillist  -  Veritas-ha@mailman.eng.auburn.edu
http://mailman.eng.auburn.edu/mailman/listinfo/veritas-ha


Re: [Veritas-ha] LLT heartbeat redundancy

2009-05-06 Thread Imri Zvik
On Wednesday 06 May 2009 00:55:23 you wrote:
> Nothing to add to /etc/llttab
>
> If you have 50MP3 then it should work.

So considering the following llttab file:

set-node rac-node1
set-cluster 0
link eth2 eth-00:21:5e:1f:0b:b0 - ether - -
link eth3 eth-00:21:5e:1f:0b:b1 - ether - -

and that eth2 and eth3 are on the same layer2 subnet (i.e. "sees" each other), 
I shouldn't get the lost hb messages?

___
Veritas-ha maillist  -  Veritas-ha@mailman.eng.auburn.edu
http://mailman.eng.auburn.edu/mailman/listinfo/veritas-ha


Re: [Veritas-ha] LLT heartbeat redundancy

2009-05-05 Thread Sandeep Agarwal (MTV)
Nothing to add to /etc/llttab

If you have 50MP3 then it should work.

-Original Message-
From: Imri Zvik [mailto:im...@inter.net.il] 
Sent: Monday, May 04, 2009 11:12 PM
To: Sandeep Agarwal (MTV)
Cc: veritas-ha@mailman.eng.auburn.edu
Subject: Re: [Veritas-ha] LLT heartbeat redundancy


On Monday 04 May 2009 23:51:54 Sandeep Agarwal (MTV) wrote:
> Unfortunately we don't have any "more" documentation for this feature.
>
> Basically, LLT works in the same way except now it can handle the 
> failure that you described and now we can connect the two switches 
> that the individual LLT links are configured on.

I tried that, but I still get the messages regarding the lost heartbeat
in the 
console.

Is there something I need to add in llttab?

___
Veritas-ha maillist  -  Veritas-ha@mailman.eng.auburn.edu
http://mailman.eng.auburn.edu/mailman/listinfo/veritas-ha


Re: [Veritas-ha] LLT heartbeat redundancy

2009-05-04 Thread Imri Zvik
On Monday 04 May 2009 23:51:54 Sandeep Agarwal (MTV) wrote:
> Unfortunately we don't have any "more" documentation for this feature.
>
> Basically, LLT works in the same way except now it can handle the
> failure that you described and now we can connect the two switches that
> the individual LLT links are configured on.

I tried that, but I still get the messages regarding the lost heartbeat in the 
console.

Is there something I need to add in llttab?

___
Veritas-ha maillist  -  Veritas-ha@mailman.eng.auburn.edu
http://mailman.eng.auburn.edu/mailman/listinfo/veritas-ha


Re: [Veritas-ha] LLT heartbeat redundancy

2009-05-04 Thread Sandeep Agarwal (MTV)
Unfortunately we don't have any "more" documentation for this feature.

Basically, LLT works in the same way except now it can handle the
failure that you described and now we can connect the two switches that
the individual LLT links are configured on.

-Original Message-
From: Imri Zvik [mailto:im...@inter.net.il] 
Sent: Sunday, May 03, 2009 11:26 PM
To: Sandeep Agarwal (MTV)
Cc: veritas-ha@mailman.eng.auburn.edu
Subject: Re: [Veritas-ha] LLT heartbeat redundancy


On Sunday 03 May 2009 20:07:29 Sandeep Agarwal (MTV) wrote:
> From 5.0MP3 onwards we do support cross-links. In your example if you 
> had a cable connecting sw1 and sw2 then the failure that you described

> would be handled and LLT would still have 1 valid link between node 1 
> and node 4.

Could you please point me to some more documention regarding this
feature?

Thanks!
 
___
Veritas-ha maillist  -  Veritas-ha@mailman.eng.auburn.edu
http://mailman.eng.auburn.edu/mailman/listinfo/veritas-ha


Re: [Veritas-ha] LLT heartbeat redundancy

2009-05-03 Thread Imri Zvik
On Sunday 03 May 2009 20:07:29 Sandeep Agarwal (MTV) wrote:
> From 5.0MP3 onwards we do support cross-links. In your example if you
> had a cable connecting sw1 and sw2 then the failure that you described
> would be handled and LLT would still have 1 valid link between node 1
> and node 4.

Could you please point me to some more documention regarding this feature?

Thanks!
 
___
Veritas-ha maillist  -  Veritas-ha@mailman.eng.auburn.edu
http://mailman.eng.auburn.edu/mailman/listinfo/veritas-ha


Re: [Veritas-ha] LLT heartbeat redundancy

2009-05-03 Thread Sandeep Agarwal (MTV)
Sun Cluster does not support this feature. 

-Original Message-
From: veritas-ha-boun...@mailman.eng.auburn.edu
[mailto:veritas-ha-boun...@mailman.eng.auburn.edu] On Behalf Of Sandeep
Agarwal (MTV)
Sent: Sunday, May 03, 2009 10:07 AM
To: Jim Senicka; Imri Zvik
Cc: veritas-ha@mailman.eng.auburn.edu
Subject: Re: [Veritas-ha] LLT heartbeat redundancy

>From 5.0MP3 onwards we do support cross-links. In your example if you
had a cable connecting sw1 and sw2 then the failure that you described
would be handled and LLT would still have 1 valid link between node 1
and node 4. 

-Original Message-
From: veritas-ha-boun...@mailman.eng.auburn.edu
[mailto:veritas-ha-boun...@mailman.eng.auburn.edu] On Behalf Of Jim
Senicka
Sent: Sunday, May 03, 2009 9:23 AM
To: Imri Zvik
Cc: veritas-ha@mailman.eng.auburn.edu
Subject: Re: [Veritas-ha] LLT heartbeat redundancy

LLT is designed to use "jeopardy" to detect the difference between
single link fail and dual link fail in most situations. Having a single
mesh may remove this capability.

Let me check on this with engineering and see if we have any more up to
date recommendations


-Original Message-
From: veritas-ha-boun...@mailman.eng.auburn.edu
[mailto:veritas-ha-boun...@mailman.eng.auburn.edu] On Behalf Of Imri
Zvik
Sent: Sunday, May 03, 2009 12:18 PM
To: Jim Senicka
Cc: veritas-ha@mailman.eng.auburn.edu
Subject: Re: [Veritas-ha] LLT heartbeat redundancy

On Sunday 03 May 2009 19:03:16 Jim Senicka wrote:
> This is not a limitation, as you had two independent failures. Bonding

> would remove the ability to discriminate between a link and a node 
> failure.

I didn't understand this one - With bonding I can maintain full mesh
topology - No matter which one of the links fails, if a node still has
at least one active link, LLT will still be able to see all the other
nodes. 
This achieves greater HA than without the bonding.


> My feeling is in the scenario you describe, VCS is operating properly,

> and it is not a limitation.

Of course it is operating properly - that's how it was designed to work
:)
I'm just saying that the cluster could be more redundant if it wasn't
designed that way :)

> If you have issues with port or cable failures, add a low pri
connection
> on a third network.



___
Veritas-ha maillist  -  Veritas-ha@mailman.eng.auburn.edu
http://mailman.eng.auburn.edu/mailman/listinfo/veritas-ha
___
Veritas-ha maillist  -  Veritas-ha@mailman.eng.auburn.edu
http://mailman.eng.auburn.edu/mailman/listinfo/veritas-ha
___
Veritas-ha maillist  -  Veritas-ha@mailman.eng.auburn.edu
http://mailman.eng.auburn.edu/mailman/listinfo/veritas-ha
___
Veritas-ha maillist  -  Veritas-ha@mailman.eng.auburn.edu
http://mailman.eng.auburn.edu/mailman/listinfo/veritas-ha


Re: [Veritas-ha] LLT heartbeat redundancy

2009-05-03 Thread Sandeep Agarwal (MTV)
>From 5.0MP3 onwards we do support cross-links. In your example if you
had a cable connecting sw1 and sw2 then the failure that you described
would be handled and LLT would still have 1 valid link between node 1
and node 4. 

-Original Message-
From: veritas-ha-boun...@mailman.eng.auburn.edu
[mailto:veritas-ha-boun...@mailman.eng.auburn.edu] On Behalf Of Jim
Senicka
Sent: Sunday, May 03, 2009 9:23 AM
To: Imri Zvik
Cc: veritas-ha@mailman.eng.auburn.edu
Subject: Re: [Veritas-ha] LLT heartbeat redundancy

LLT is designed to use "jeopardy" to detect the difference between
single link fail and dual link fail in most situations. Having a single
mesh may remove this capability.

Let me check on this with engineering and see if we have any more up to
date recommendations


-Original Message-
From: veritas-ha-boun...@mailman.eng.auburn.edu
[mailto:veritas-ha-boun...@mailman.eng.auburn.edu] On Behalf Of Imri
Zvik
Sent: Sunday, May 03, 2009 12:18 PM
To: Jim Senicka
Cc: veritas-ha@mailman.eng.auburn.edu
Subject: Re: [Veritas-ha] LLT heartbeat redundancy

On Sunday 03 May 2009 19:03:16 Jim Senicka wrote:
> This is not a limitation, as you had two independent failures. Bonding

> would remove the ability to discriminate between a link and a node 
> failure.

I didn't understand this one - With bonding I can maintain full mesh
topology - No matter which one of the links fails, if a node still has
at least one active link, LLT will still be able to see all the other
nodes. 
This achieves greater HA than without the bonding.


> My feeling is in the scenario you describe, VCS is operating properly,

> and it is not a limitation.

Of course it is operating properly - that's how it was designed to work
:)
I'm just saying that the cluster could be more redundant if it wasn't
designed that way :)

> If you have issues with port or cable failures, add a low pri
connection
> on a third network.



___
Veritas-ha maillist  -  Veritas-ha@mailman.eng.auburn.edu
http://mailman.eng.auburn.edu/mailman/listinfo/veritas-ha
___
Veritas-ha maillist  -  Veritas-ha@mailman.eng.auburn.edu
http://mailman.eng.auburn.edu/mailman/listinfo/veritas-ha
___
Veritas-ha maillist  -  Veritas-ha@mailman.eng.auburn.edu
http://mailman.eng.auburn.edu/mailman/listinfo/veritas-ha


Re: [Veritas-ha] LLT heartbeat redundancy

2009-05-03 Thread Imri Zvik
On Sunday 03 May 2009 19:22:38 Jim Senicka wrote:
> Let me check on this with engineering and see if we have any more up to
> date recommendations

Thanks!

___
Veritas-ha maillist  -  Veritas-ha@mailman.eng.auburn.edu
http://mailman.eng.auburn.edu/mailman/listinfo/veritas-ha


Re: [Veritas-ha] LLT heartbeat redundancy

2009-05-03 Thread Jim Senicka
LLT is designed to use "jeopardy" to detect the difference between
single link fail and dual link fail in most situations. Having a single
mesh may remove this capability.

Let me check on this with engineering and see if we have any more up to
date recommendations


-Original Message-
From: veritas-ha-boun...@mailman.eng.auburn.edu
[mailto:veritas-ha-boun...@mailman.eng.auburn.edu] On Behalf Of Imri
Zvik
Sent: Sunday, May 03, 2009 12:18 PM
To: Jim Senicka
Cc: veritas-ha@mailman.eng.auburn.edu
Subject: Re: [Veritas-ha] LLT heartbeat redundancy

On Sunday 03 May 2009 19:03:16 Jim Senicka wrote:
> This is not a limitation, as you had two independent failures. Bonding
> would remove the ability to discriminate between a link and a node
> failure.

I didn't understand this one - With bonding I can maintain full mesh 
topology - No matter which one of the links fails, if a node still has
at 
least one active link, LLT will still be able to see all the other
nodes. 
This achieves greater HA than without the bonding.


> My feeling is in the scenario you describe, VCS is operating properly,
> and it is not a limitation.

Of course it is operating properly - that's how it was designed to work
:)
I'm just saying that the cluster could be more redundant if it wasn't
designed 
that way :)

> If you have issues with port or cable failures, add a low pri
connection
> on a third network.



___
Veritas-ha maillist  -  Veritas-ha@mailman.eng.auburn.edu
http://mailman.eng.auburn.edu/mailman/listinfo/veritas-ha
___
Veritas-ha maillist  -  Veritas-ha@mailman.eng.auburn.edu
http://mailman.eng.auburn.edu/mailman/listinfo/veritas-ha


Re: [Veritas-ha] LLT heartbeat redundancy

2009-05-03 Thread Imri Zvik
On Sunday 03 May 2009 19:03:16 Jim Senicka wrote:
> This is not a limitation, as you had two independent failures. Bonding
> would remove the ability to discriminate between a link and a node
> failure.

I didn't understand this one - With bonding I can maintain full mesh 
topology - No matter which one of the links fails, if a node still has at 
least one active link, LLT will still be able to see all the other nodes. 
This achieves greater HA than without the bonding.


> My feeling is in the scenario you describe, VCS is operating properly,
> and it is not a limitation.

Of course it is operating properly - that's how it was designed to work :)
I'm just saying that the cluster could be more redundant if it wasn't designed 
that way :)

> If you have issues with port or cable failures, add a low pri connection
> on a third network.



___
Veritas-ha maillist  -  Veritas-ha@mailman.eng.auburn.edu
http://mailman.eng.auburn.edu/mailman/listinfo/veritas-ha


Re: [Veritas-ha] LLT heartbeat redundancy

2009-05-03 Thread Jim Senicka
This is not a limitation, as you had two independent failures. Bonding
would remove the ability to discriminate between a link and a node
failure. 
My feeling is in the scenario you describe, VCS is operating properly,
and it is not a limitation.
If you have issues with port or cable failures, add a low pri connection
on a third network.


-Original Message-
From: Imri Zvik [mailto:im...@inter.net.il] 
Sent: Sunday, May 03, 2009 11:57 AM
To: Jim Senicka
Cc: veritas-ha@mailman.eng.auburn.edu
Subject: Re: [Veritas-ha] LLT heartbeat redundancy

On Sunday 03 May 2009 18:25:08 Jim Senicka wrote:
> You had 2 failures. No real way to design around that.
> GAB "visible" would prevent bad things from occurring.

Thank you for the fast response :)

Well, In linux I can use the bonding module to aggregate the interfaces
and 
work around this limitation. I've read in this discussion: 
http://www.mail-archive.com/veritas-ha@mailman.eng.auburn.edu/msg01016.h
tml
That since 5.0MP3 there is a cross-platform solution (I need this for
Solaris 
10). Do you happen to know more about this feature?

Thanks!

P.S.

Does anyone knows if Sun Cluster has the same limitation?

___
Veritas-ha maillist  -  Veritas-ha@mailman.eng.auburn.edu
http://mailman.eng.auburn.edu/mailman/listinfo/veritas-ha


Re: [Veritas-ha] LLT heartbeat redundancy

2009-05-03 Thread Imri Zvik
On Sunday 03 May 2009 18:25:08 Jim Senicka wrote:
> You had 2 failures. No real way to design around that.
> GAB "visible" would prevent bad things from occurring.

Thank you for the fast response :)

Well, In linux I can use the bonding module to aggregate the interfaces and 
work around this limitation. I've read in this discussion: 
http://www.mail-archive.com/veritas-ha@mailman.eng.auburn.edu/msg01016.html
That since 5.0MP3 there is a cross-platform solution (I need this for Solaris 
10). Do you happen to know more about this feature?

Thanks!

P.S.

Does anyone knows if Sun Cluster has the same limitation?

___
Veritas-ha maillist  -  Veritas-ha@mailman.eng.auburn.edu
http://mailman.eng.auburn.edu/mailman/listinfo/veritas-ha


Re: [Veritas-ha] LLT heartbeat redundancy

2009-05-03 Thread Jim Senicka
You had 2 failures. No real way to design around that.
GAB "visible" would prevent bad things from occurring.



-Original Message-
From: veritas-ha-boun...@mailman.eng.auburn.edu
[mailto:veritas-ha-boun...@mailman.eng.auburn.edu] On Behalf Of Imri
Zvik
Sent: Sunday, May 03, 2009 11:20 AM
To: veritas-ha@mailman.eng.auburn.edu
Subject: [Veritas-ha] LLT heartbeat redundancy

Hi,

As far as I understand the manuals, the LLT heartbeat links should be
isolated 
from each other. Now, consider the following scenario  - Node1 is
connected 
with two links, each one to a sperate switch. We will call them 
li...@node1@sw1 and li...@node1@sw2.
Node4 is also connected with 2 links: li...@node4@sw1 and
li...@node4@sw2.

Now, if Node1 lose li...@node1@sw1 and Node4 lose li...@node4@sw2, they
can no 
longer see each other, although they still have a valid heartbeat link.

Am I missing something? Is there a way around this issue?

-- imriz
___
Veritas-ha maillist  -  Veritas-ha@mailman.eng.auburn.edu
http://mailman.eng.auburn.edu/mailman/listinfo/veritas-ha
___
Veritas-ha maillist  -  Veritas-ha@mailman.eng.auburn.edu
http://mailman.eng.auburn.edu/mailman/listinfo/veritas-ha