Re: Is there a grand plan for FC failover?

Mike Christie
2004-01-28T22:38:05Z

Philip R. Auld wrote:
> Hi James,
> Thanks for the reply.
>
> Rumor has it that on Wed, Jan 28, 2004 at 10:57:29AM -0600 James Bottomley said:
>
>>On Wed, 2004-01-28 at 09:02, Philip R. Auld wrote:
>>
>>> 1) load balancing when possible: it's not enough to be just a
>>> failover mechanism.
>>
>>For first out, a failover target supplies most of the needs. Nothing
>>prevents an aggregation target being added later, but failover is
>>essential.
>
>
> Yes, failover is necessary, but not sufficient to make a decent multipath driver.
> I'm a little concerned by the "added later" part. Shouldn't it be designed in?

The DM multipath can do both. Unfortunately, some work still needs to be
done. For example, when doing load balancing how much IO to send down
each path is an issue that the DM maintainer had asked for feedback on.
Suggestions?

>
>>> 2) requiring a userspace program to execute for failover is
>>> problematic when it could be the root disk that needs
>>> failing over.
>>
>>Userspace is required for *configuration* not failover. The path
>>targets failover automatically as they see I/O down particular paths
>>timing out or failing. That being said, nothing prevents async
>>notifications via hotplug also triggering a failover (rather than having
>>to wait for timeout etc) but it's not required.
>>
>
>
> There was some discussion about vendor plugins to do proprietary failover
> when needed. Say to make a passive path active. My concern is that this be
> memory resident and that we not have to go to the disk for such things.
>
> If there is no need for that or it's done in such a way that it doesn't need
> the disk this won't be a problem then.
>

This is something both MD and DM multiapth are not yet fully prepared for.