![]() |
![]() HP OpenVMS Systemsask the wizard |
![]() |
The Question is: How much system overhead is created when volume shadowing is turned on? The Answer is : There are various sorts of overhead -- of relevence to this case are the amount of system resources used (in this case, memory) and the amount of extra processing required to set up, to maintain, and to do I/O to a shadow set. For memory: Some non-paged pool is required for each shadow set -- a structure is created for each -- it's relatively small. Some system memory is required to contain the shadow driver -- for a rough estimate of this memory, see the on-disk size of the shadowing driver itself. Some additional system physical memory is required by the shadow server process. Some page file space is reserved. Some additional locks are created, and some additional SCS traffic is created to maintain those locks. For processing: Whenever you do an I/O operation, the operation is processed by the shadow driver before it is given to the member disk class drivers. The particular amount of additional overhead also depends on the read-write mix. For reads, the shadow driver picks one shadow set member and issues the read to that. So, there's a little bit of additional processing before the read gets to the member class driver. For writes, the shadow driver issues a write operation to *each* of the member drivers, and does not complete the I/O operation until *all* members have completed it. Thus, write I/O is only as fast as the slowest member -- if one member is at the end of a long communications link, this could be (relatively speaking) quite slow. And there's the additional processing required to do 2 or 3 I/Os in place of the one original I/O operation. Most of the time, you don't notice the additional I/O overhead, because the additional processing time is buried in the time it takes to actually access the disk surface. The real overhead comes when some error occurs, or when an unusual event occurs. The actual amount depends on what the event is, but here's a flavor of what may occur: 1) you add a new member to an existing shadow set. This will cause shadowing to initiate a copy from some other member to the new one. If the members are large, this will be a substantial amount of I/O as the copy proceeds (which may take many tens of minutes; even hours, depending on the amount of data to be moved, and the performance characteristics of the disks and systems involved). Note that this event may occur when you first create the shadow set. 2) some error occurs which causes shadowing to throw out a member. In this case, there is some SCS traffic, as the shadow drivers in each system accessing the shadow set communicate amongst themselves to decide which member to toss out. Then there is a mount verification process to ensure the remaining members still make up a consistent set. 3) some error occurs which causes shadowing to re-confirm the consistency of the shadow set. This causes shadow driver to put the set into mount verify, which causes additional I/O operations to each set member to determine if the shadow set is still consistent and safe to use. There can also be system overhead resulting from shadow copy operations. A shadow copy occurs when the shadow driver determines that the data from one volume must be duplicated onto another volume, such as when a new volume is added into a shadow set or when an existing shadow set volume has been removed from and then later added back into a shadow set.
|