Shadow Merge

[Zahid Ghani]

Does any one know of good Strategy paper on on how to minimise the effect of Shadow Merging on a cluster. I have read all the Standard Manuals but there is not much help on trynig to reduce the Shadadow Merge time.
I have a 4-node Disaster Tolerant Cluster on VMS7.3-1. The two sites are linked via FDDI.
The storage is based on HSG80 multibus failover. I have looked at MAX_copy, Shadow Delay_factors but do not provide the sort of improvment I am looking for.
Do I have to wait for HSB Mini Merge When ever HP decide to release it...could be a long wait if Controller Based Mini merge release is anything to go by.

[Ian Miller.]

See this presentation by Keith Parris.

http://www2.openvms.org/kparris/s2003_volshad_perf.ppt

and other things on the same site
http://www2.openvms.org/kparris/

[Åge Rønning]

Minimerge is not there yet for FC Storage, But at least there is a schedule for Host-Based MiniMerge that will solve your problem and any other type of storage that is utilized in a Host-Based Volume Shadowing shadow set. You may expect to see this functionality in March-2004 for the OpenVMS V7.3-1 customer base. Support for OpenVMS V7.3-2 will be shortly thereafter.

Overview
The purpose of the Host-Based MiniMerge feature is to allow a "minimum" MERGE of only shadow set changes (rather than the currently-required "full" MERGE) when a member of an OpenVMS cluster is removed and re-introduced into a cluster. A similar capability exists today for CI-based storage, and this new "host-based" implementation will allow a MiniMerge to occur on any type of storage that is utilized in a Host-Based Volume Shadowing shadow set.

Technical Description
This implementation utilizes the "write bitmap" technology used for MiniCopy functionality today, to keep track of shadow set data changes while a shadowset member is temporarily removed from a shadowset. With MiniCopy, when a shadowset member is brought back in, Shadowing is able to copy only the changed areas of the disk, thus resulting in a much faster restoration of the shadow set member into the shadowset. By using similar â write bitmapâ technology to track the changes being made by each node in a cluster to the members of a shadowset, then at the time a node fails and leaves the cluster, it is possible to identify those specific areas on the shadowset that were being written to by the node at the time it failed. As such, where the failure might have resulted in data ending up different on different members of the shadowset, Shadowing can now merge just those areas which were in the process of being modified at the time the node failed (in a MiniMerge operation), rather than having to scan the entire disk looking for potential discrepancies caused by the nodeâ s failure (in a Full Merge oper

[Willem Grooters]

AFAIK, HSB minimerge is scheduled to be delevered in 7.3-2, end 2003. Got a brief explanation about this (and other enhancements (especially DCL!)) on the OpenVMS Tecnical Update Days last month. Worthwhile waiting for!

[Martin P.J. Zinser]

While the Mini Merge is certainly the way to go once we have it there are obviously two things that hurt doing a full merge

1.) Performance hit during the merge
2.) Risk exposure while the shadow sets are not yet merged

Depending on which of the two is bothering you most one can tweak the system to minimize it (but incurring more of the other problem at the same time)

[JKrucus]

I recently had ShadowMerge on four two member shadow sets that were progressing at 1.5% per hour, or about 60 or 70 hours to complete. HP told me to set a logical which adjusts how fast/slow the shadowmerge progresses, and it worked.

A high value is a fast merge and a low value is a slow merge. I tried 1000 with no effect. When I put in 5000 the last 40% of the merge completed in 10 minutes.

$ Define / System -
SHAD$MERGE_DELAY_FACTOR_DSA111 5000

This affects only shadow set dsa111. Set it on all cluster nodes. It takes 5 or 10 minutes to take effect. You can redefine it as often as you want to get the right speed. And you can deassign/system it when you are done. Don't exceed 10,000. The default value is 200 so go from there.

[Anton van Ruitenbeek]

In addition to JKrucus,

We use this logical to and set it to the highest possible value 100000.
Because we use a cluster (looks about what you are using multisite, double etc) and the merge process looks correctly in the lookup-table of logicals we set this logical in LNM$SYSCLUSTER_TABLE.
The reason is: Better have lower performance and fast back to disaster tolerant status then high performance and a (very) long time in a single point of failure.
We use the logical SHAD$MERGE_DALAY_FACTOR = 100000 !

AvR

[Wim Van den Wyngaert]

It all depends. We have a cluster with many workstations that boot from 1 disk of the 2 servers of the cluster. When there is a power failure all stations reboot. Since the system disk goes into merge, all IO done by the stations must me done twice (to each disk). But if the merge is going at high speed, most of the boots will fail due to ??? timeout ???. This because the disk is not answerring properly to the IO requests.

So, we slow down the merge process instead of speeding it up.

On the servers without stations, we slow down the shadow copy by putting max_copy on 1. And only 1 node of the cluster may perform a copy. This because critical portions of the applications must run in time to avoid business impact. And if multiple copies are active the delay for the application is simply to big.

[Zahid Ghani]

I had forgotten about this thread.
But like Michael had said it is a trade off between how fast you want merging to proceed and rest of system performance.

On slightly different topic -has anyone gone live with HBMM?