On mar, 2005-08-02 at 15:07 -0400, goggin, edward wrote:
> On Tue, 02 Aug 2005 09:37:14 -0500
> "Christopher C. Weis" <ccweis@xxxxxxxxx> wrote
>
> > I have a multipath SAN environment with storage controllers that are
> > active/active. However, the controllers are not active/active at the
> > LUN-level without a performance penalty, meaning if two
> > servers want to
> > see the same LUN (as in a clustered filesystem environment), they both
> > need to be using the same controller. I'm trying to figure
> > out a way to
> > statically "order" the paths so that I can copy a config to all of the
> > nodes using the CFS.
> >
> > >From what I've read, in a single-server environment with controllers
> > such as the ones I'm dealing with, the path_grouping_policy should be
> > set to "group_by_serial", which should work fine, but in a clustered
> > environment, I need to be sure that the path ordering is the same.
> >
> > Are there any path_selectors, other than round-robin, that might
> > accomplish this? Any other ideas?
> >
>
> One was is to configure each multipath to have two groups with one group
> having a higher priority than the other based on whether the path accesses
> the fast path controller. The assignment of the highest priority path group
> is non deterministic when using the "group_by_serial" path grouping policy.
>
> Seems like you want to use the "group_by_priority" path grouping policy and
> create and get_priority executable which when invoked will return a 1 for
> fast path and 0 for slow path. See the code for mpath_prio_emc, the
> get_priority executable for the EMC CLARiiON array in
> multipath-tools/path_priority/pp_emc/pp_emc.c.
>
Yes, also note "group_by_priority" path grouping policy may be overkill
for the context. PG produced by "group_by_serial" can be sorted with an
adequate prioritizer too.
Does this mean that "group_by_serial" utilizes a "default_prio_callout" program/script as well, or is there another callout (or something totally different that I'm missing)?
Thx.
~Chris
