- Community Home
- >
- Servers and Operating Systems
- >
- Operating Systems
- >
- Operating System - OpenVMS
- >
- Re: HBMM Experience
Categories
Company
Local Language
Forums
Discussions
Forums
- Data Protection and Retention
- Entry Storage Systems
- Legacy
- Midrange and Enterprise Storage
- Storage Networking
- HPE Nimble Storage
Discussions
Discussions
Discussions
Forums
Forums
Discussions
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
- BladeSystem Infrastructure and Application Solutions
- Appliance Servers
- Alpha Servers
- BackOffice Products
- Internet Products
- HPE 9000 and HPE e3000 Servers
- Networking
- Netservers
- Secure OS Software for Linux
- Server Management (Insight Manager 7)
- Windows Server 2003
- Operating System - Tru64 Unix
- ProLiant Deployment and Provisioning
- Linux-Based Community / Regional
- Microsoft System Center Integration
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Community
Resources
Forums
Blogs
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО09-17-2004 11:51 AM
тАО09-17-2004 11:51 AM
Re: HBMM Experience
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).
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО09-17-2004 10:40 PM
тАО09-17-2004 10:40 PM
Re: HBMM Experience
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО09-18-2004 09:32 AM
тАО09-18-2004 09:32 AM
Re: HBMM Experience
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 . . . :-)
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО09-19-2004 10:19 PM
тАО09-19-2004 10:19 PM
Re: HBMM Experience
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО09-20-2004 02:38 AM
тАО09-20-2004 02:38 AM
Re: HBMM Experience
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО09-20-2004 02:40 AM
тАО09-20-2004 02:40 AM
Re: HBMM Experience
Wim
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО09-20-2004 08:58 PM
тАО09-20-2004 08:58 PM
Re: HBMM Experience
Purely Personal Opinion
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО09-20-2004 09:40 PM
тАО09-20-2004 09:40 PM
SolutionWe 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,
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО09-21-2004 03:32 AM
тАО09-21-2004 03:32 AM
Re: HBMM Experience
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО09-21-2004 03:56 AM
тАО09-21-2004 03:56 AM
Re: HBMM Experience
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.