 |
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.
|
|
|
|
|
