- Community Home
- >
- Servers and Operating Systems
- >
- Operating Systems
- >
- Operating System - OpenVMS
- >
- Re: Shadow set merge after crash
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
тАО01-13-2011 11:49 AM
тАО01-13-2011 11:49 AM
Shadow set merge after crash
$ show shadow dsa30
DSA30: Volume Label: ORACLE
Virtual Unit State: Steady State
Enhanced Shadowing Features in use:
Host-Based Minimerge (HBMM)
VU Timeout Value 3600 VU Site Value 0
Copy/Merge Priority 5000 Mini Merge Enabled
Recovery Delay Per Served Member 30
Merge Delay Factor 200 Delay Threshold 200
HBMM Policy
HBMM Reset Threshold: 1000000
HBMM Master lists:
Up to any 2 nodes in the cluster - Multiuse: 0
Modified blocks since bitmap creation: 13081
Device $1$DKC0 Master Member
Read Cost 2 Site 0
Member Timeout 120
Device $1$DKB300
Read Cost 2 Site 0
Member Timeout 120
What can I do to improve (reduce) the merge time?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО01-13-2011 12:36 PM
тАО01-13-2011 12:36 PM
Re: Shadow set merge after crash
Dan
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО01-13-2011 02:04 PM
тАО01-13-2011 02:04 PM
Re: Shadow set merge after crash
Any messages in the log?
Since shadow copies are direct block-for-block copies, the number of blocks in use is not directly relevant to how long the copy takes.
If the volumes do not need to be fully available to 36GB, it may pay to reorganize storage so the entire volume is not shadowed (and then use SET VOLUME) to increase the size of the volumes as needed. This is somewhat different spin on the techniques I spoke of in "Migrating OpenVMS Storage Environments without Interruption or Disruption" at the 2007 HP Enterprise Technology Symposium (see http://www.rlgsc.com/hptechnologyforum/2007/1512.html).
- Bob Gezelter, http://www.rlgsc.com
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО01-13-2011 02:29 PM
тАО01-13-2011 02:29 PM
Re: Shadow set merge after crash
From the operator.log
%%%%%%%%%%% OPCOM 13-JAN-2011 09:54:30.79 %%%%%%%%%%% Message from user SYSTEM on SADS20 %SHADOW_SERVER-I-SSRVBEGMRG, BEGINNING merge operation on _DSA30: at LBN: 0, I/O size: 127 blocks,
%%%%%%%%%%% OPCOM 13-JAN-2011 09:54:30.79 %%%%%%%%%%% Message from user SYSTEM on SADS20 -SHADOW_SERVER-I-SSRVINIMRG, ID number: 38000045, Threshold 200, Factor 200.
Then of course the notice of the completion.
Interesting idea, only use part of the disk and expand as needed...
Kevin
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО01-13-2011 02:39 PM
тАО01-13-2011 02:39 PM
Re: Shadow set merge after crash
Full merges take a long time. Typically much longer than a straight copy. I notice that you have Mini Merge enabled, and wonder why it wasn't used. How many nodes crashed, and how did you recover?
Please check your configuration to make sure you're allowing all optimisations.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО01-13-2011 03:08 PM
тАО01-13-2011 03:08 PM
Re: Shadow set merge after crash
The system is a stand alone server, the drives are on separate controllers.
I'm not sure what you mean by "make sure you're allowing all optimisations".
Kevin
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО01-13-2011 03:43 PM
тАО01-13-2011 03:43 PM
Re: Shadow set merge after crash
SET
SHADOW
/ENABLE
/ENABLE=HBMM
Note: This qualifier applies to HBMM operations only. If you specify any non-HBMM qualifiers with this one, the command will fail.
Enables host-based minimerge (HBMM) on the specified shadow set or across the entire cluster if an applicable HBMM policy exists. To learn more about HBMM policies and their application, see the HP Volume Shadowing for OpenVMS manual.
HBMM is the only supported value for /ENABLE, and it must be included.
------------------------------------------
Host Based Mini Merge is an optimisation which bypasses the need for a full merge under some circumstances. If it's used it can drammatically reduce merge times (ie: your objective). However, there are quite a few conditions which need to be met before HBMM can be used.
See the Shadowing manual, and in particular, the section in Chapter 1 labelled "HBMM Configuration Requirements" and all of Chapter 8 "Host-Based Minimerge (HBMM)".
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО01-13-2011 03:52 PM
тАО01-13-2011 03:52 PM
Re: Shadow set merge after crash
HBMM is enabled, the formating was lost on the original post above.
Enhanced Shadowing Features in use:
Host-Based Minimerge (HBMM)
Thanks
Kevin
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО01-13-2011 04:10 PM
тАО01-13-2011 04:10 PM
Re: Shadow set merge after crash
---
HBMM requires the use of at least a two-node cluster. In other words, while you may have HBMM enabled, the bitmap that's being created to track writes is useless. If you have a spare Alpha or IA64 system gathering dust (and a cluster license), I'd boot it up, form a two-node cluster, and give HBMM a shot. In general, HBMM merges will complete in seconds, or a few minutes at most (depending on various parameters, but HBMM merges are quite quick).
This assumes some storage that is directly-attached to both systems; if the MSCP-serving node crashes, then the remaining node can't access the device(s), and can't merge.
-- Rob
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО01-13-2011 04:14 PM
тАО01-13-2011 04:14 PM