[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

[dm-devel] RE: Is there a grand plan for FC failover?



> -----Original Message-----
> From: James Bottomley [mailto:James Bottomley SteelEye com]
> Sent: Thursday, January 29, 2004 10:06 AM
> To: Philip R. Auld
> Cc: Smart, James; 'Patrick Mansfield'; Simon Kelley; SCSI 
> Mailing List;
> dm-devel sistina com
> Subject: Re: Is there a grand plan for FC failover?
> 
> 
> On Thu, 2004-01-29 at 09:49, Philip R. Auld wrote:
> > It needs to be known to the pathing layer if you've got 
> load balancing. 
> > It has to know which path has the reservation and only use that one.
> 
> Well, yes, but your multiple active path implementation just collapsed
> back down to single path in the face of reservations, so it would
> probably be better simply to use failover in the face of reservations
> and clustering.

Why do you imply that you're down to a single path ? With multiple port
devices, and the T10 unclarity on multiport support, simple reservations
didn't bring you down to the single port access you are describing. Some
devices may have implemented it this way, but the standard didn't say they
had to or even that they should.

And this picture changes significantly with the use of Persistent
Reservations and the use of keys.


> 
> For the single path case, something like the HP MSA/EVA arrays simply
> throw away reservations on path switch over. 

Depends on the reservation type. Simple Reservations, yes. Persistent
Reservations, no.

> This allows the user level
> watchdog code to reassert them in a cluster down the new 
> path.  However,
> there are array that will do a path switchover and then return
> reservation conflict to everyone (including the taking node).  These
> arrays will need some type of special handling.
> 
> James
> 

Although the management of the reservation/keys in user space is functional,
given that reservations are used as a last firewall for babbling adapters
under failure, you want to reinstate or move the firewall as quickly as
possible - which is sometimes at odds with going out to userland to do so.

-- James S



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]