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

Re: [dm-devel] RE: dm-devel Digest, Vol 18, Issue 2

On 8/2/05, christophe varoqui <christophe varoqui free fr> wrote:
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 gmail com> 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)?



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