[dm-devel] path group failback

[egoggin at emc.com]

On Monday, March 13, 2006 12:18 PM, Christophe Varoqui wrote

> > > In such a scenario, wouldn't the priorizer catch priority 
> changes ?
> > 
> > No, not necessarily, and certainly not for CLARiiON.  None of these
> > 3 use cases involves changing which path group is the 
> highest priority
> > path group so each path in the 2 groups continue to have the same
> > priority as before the externally initiated change of the 
> active path
> > group.  For each use case, only the identity of the active 
> path group
> > has been changed.
> > 
> I guess the priorizer *should* catch priority changes ...

> > > 
> > > ie, paths to owning SP are heavier than paths to not owning SP, so
> > > changing the owning SP in navisphere would shuffle the path group
> > > priorites.
> > 
> > CLARiiON path priority is dependent solely on 2 factors -- (1) the
> > path must be active (or ghost) and (2) the path must connect to its
> > logical unit's "default" (not necessarily active) owning service
> > processor.
> > 
> > > 
> > > If it is the case I would imagine the failback target to be the
> > > externally designated one, which seems right.
> > 
> > No.  The CLARiiON's highest priority path group is defined to be
> > the default owning service processor instead of the active service
> > processor (they may or may not be the same at any given instant)
> > in order to maintain the manually established distribution of
> > logical units across the 2 service processors.
> > 
> Would it be unreasonable to teach the prioritizer about this case ?

This will be difficult if not unreasonable.  We don't want to blindly
have the priority follow the currently active path group.  Doing so
will eliminate the ability to maintain the statically assigned balance
of logical units to SCSI targets.  I find it difficult to believe that
the CLARiiON is the only case of this issue given the 5 active/passive
arrays listed in libmultipath/hwtable.c that have both priority based
path group membership and immediate path group failback configured.

Ideally we would be able to differentiate an externally initiated path
group switch from an internal one.  This will be difficult without
some kernel changes to the EMC hardware handler and more involved changes
to multipathd which I wanted to avoid proposing.

The prioritizer interface does not facilitate state maintenance which
I think would be needed to make an intelligent decision about what to
do.  This would be state like path active/failed state for each path
and the total number of paths and path groups for each mapped device.
Since multipathd already tracks this state, it seems reasonable to have
this logic enforced within a path group failback mode -- especially if
it is an issue common to other arrays in addition to CLARiiON.