1748000 Members
4579 Online
108757 Solutions
New Discussion юеВ

Re: HBMM Experience

 
SOLVED
Go to solution
Ken Fairfield
Occasional Advisor

Re: HBMM Experience

In response to Rob's question, yes, I've been testing the priority stuff quite a bit. You should have seen two questions sent to support by Brent Murphy (which I "fed" to him).

The priority settings really do what you say, thanks! :-) But it took a bit of learning to find that (a) the priorities are node-specific so they need to be set on each node independently, (b) you can't set a priority on a shadow set before it's mounted, and (c) you need to do a Set Shadow/Evaluate=Resources after setting the priorities, e.g., during boot, if you want the shadow sets to merge and/or copy according to the (new) priority settings.

We also found that shadow copies are _not_ processed ahead of full-merges as the documentation says, _unless_ the associated shadow set is given a higher priority than the pending full merges. We are unable to tell whether the documenation is wrong (or incomplete), or whether the implemenation is not quite right (VMS731_HBMM-V0100 ... the -V0200 kit was too late for us).
Jan van den Ende
Honored Contributor

Re: HBMM Experience

Robert,

Reading Ken's remarks I would strongly suggest that every effort is given to getting the documentation SYNCHRONIZED to the software!

Now finally SCSI Minimerge sees the light in the form of HBMM.
But you will probably understand that HBMM will be most interesting to sites that are the most sensitive to disruption. Those disruptions can equally well arise from failing software, as from GOOD software that is USED WRONG. And that would be all the more painfull if the software is used according the documentation, where THAT is wrong!

And, YES, we would like the get it in by yesterday, but we MUST be sure we understand what CAN and what CAN NOT be done to mould it to our wishes, before we dare.

PLEASE, have the documentation right as well!!


... reading this back it feel it sounds a bit harsher then I intended to, but the essence still stands.

And, of course, I owe and enormous THANK YOU to those who finally got it working!
I have been informed of some bits and pieces of the hurdles that had to be taken, and everyone that took part in getting it done should receive a big bonus if I had a vote in that!

Once more, thanks, and I hope to be able to implement HBMM soon!


Jan
Don't rust yours pelled jacker to fine doll missed aches.
Robert Brooks_1
Honored Contributor

Re: HBMM Experience

I'll attempt to address the points raised
individually - thanks for the feedback.

>Aren't the SET SHADOW DSAn/PRIORITY = n and >the SHADOW_REC_DLY features only available >after the HBMM patch is installed?
Yes, this is part of the HBMM kit.
I didn't mean to imply otherwise. My point was
that while the main focus of our work was on
minimerge in and of itself, the prioritization
stuff is (I think) pretty interesting and was wondering if anyone had explored that aspect of the kit


>The priority settings really do what you >say, thanks! :-) But it took a bit of >learning to find that (a) the priorities are >node-specific so they need to be set on each >node independently, (b) you can't set a >priority on a shadow set before it's >mounted, and (c) you need to do a Set >Shadow/Evaluate=Resources after setting the >priorities, e.g., during boot, if you want >the shadow sets to merge and/or copy >according to the (new) priority settings.

Hmmmm. I thought that a), b), and c) were
well-documented -- sorry it was not clear
on all three of those cases.


>We also found that shadow copies are _not_ >processed ahead of full-merges as the >documentation says, _unless_ the associated >shadow set is given a higher priority than >the pending full merges. We are unable to >tell whether the documenation is wrong (or >incomplete)

Yes, uh, well, uh, this was somewhat of
a surprise to us earlier this week :-(
We *do* go into pretty good detail about the
prioritization stuff and the minimerge/full copy/full merge hierarchy, but that hierarchy
is only enforced per shadow-set, not per
system or per-cluster. This was an unfortunate discovery.

What *does* happen across the cluster
correctly is that all minimerges are done
independant of priority. A 2nd pass is made
to process any other work (full copy, full merge) -- this second pass is done in priority
order. Of course, what we really need to
do is perform the 2nd pass, picking up
only full copies (and any late-arriving
minimerges), and then perform a 3rd pass
over the shadowsets, performing any work
that needs to be done in priority order.

This prospective 3rd pass will *not* be part
of the soon-to-be-released V7.3-2 kit; this
is just my musing about a better way to go
about picking up what recovery operations
need to be done in the correct order.

>or whether the implemenation is not quite >right
Well, it's an engineering problem no
matter what, since we largely write the documentation (tech writers clean it up, but
the technical accuracy is on our shoulders).

Having said that, I'd say the implementation
is not quite correct.

>Reading Ken's remarks I would strongly >suggest that every effort is given to >getting the documentation SYNCHRONIZED to >the software!

>PLEASE, have the documentation right as >well!!

You may find this hard to believe, but we
actually spend an amazing amount of time
on the documentation. In fact, we spent
so much time that when discrepancies like this crop up, we're all a bit embarrassed.

I hope that the examples we've added for
HBMM policy manipulation take away some
of the confusion you'll likely first have
when you see the syntax required for
HBMM policy creation and use.

>... reading this back it feel it sounds a >bit harsher then I intended to, but the >essence still stands.
We've been a lot harder on ourselves
internally that you have been here . . . :-)
Wim Van den Wyngaert
Honored Contributor

Re: HBMM Experience

Just curious ...

How are you testers testing if the shadow set is consistent, t.i. that all disks contain the same info after copy/merge is complete ? One of the patches on HBMCopy solved such a problem, but I found no tool to check it.

May be the shadowing masters would like to check this threat too.
http://forums1.itrc.hp.com/service/forums/questionanswer.do?threadId=666457

Wim
Wim
Volker Halle
Honored Contributor

Re: HBMM Experience

Wim,

there is ANAL/DISK/SHADOW, which does exactly this: compare all blocks on all members for identical contents. This is a new feature in V7.3-2.

Volker.
Wim Van den Wyngaert
Honored Contributor

Re: HBMM Experience

Thanks. But I'm stuck on 7.3.

Wim
Wim
Ian Miller.
Honored Contributor

Re: HBMM Experience

there was an old tool that the CSC had which would do a block compare of shadow set members. Parhaps you could get this from your local support centre.
____________________
Purely Personal Opinion
Fodil ATTAR
Frequent Advisor
Solution

Re: HBMM Experience

Hi Jack,

We have experienced troubles on nodes which had HBMM-V0100 & SHADOW-V0200 Patches Clusters crashs.

It has been Strongly recommended to pass ASAP the dynamic parameter WBM_MSG_UPPER from 100 to 1 000 000 on all nodes which receive theses two patches.

Anyway Mini merge efficiency is astonishing.

Fodil,
We must become the change we want to see cf. GHANDI
Jack Trachtman
Super Advisor

Re: HBMM Experience

Does anyone have additional information on Fodill's experience?
Fodil ATTAR
Frequent Advisor

Re: HBMM Experience

Hi,

Some more informations about context.

Separate groups of clusters using SAN Devices

1rst GS1280 (Galaxy) all in VMS 7.3-1
2nd GS160 & alpha 4000 all in VMS 7.3-1

Fodil.
We must become the change we want to see cf. GHANDI