166 lines
11 KiB
HTML
166 lines
11 KiB
HTML
|
<?xml version="1.0" encoding="UTF-8"?>
|
||
|
|
<!DOCTYPE html
|
||
|
|
PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
|
||
|
|
<html lang="en-us" xml:lang="en-us">
|
||
|
|
<head>
|
||
|
|
<meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
|
||
|
|
<meta name="security" content="public" />
|
||
|
|
<meta name="Robots" content="index,follow" />
|
||
|
|
<meta http-equiv="PICS-Label" content='(PICS-1.1 "http://www.icra.org/ratingsv02.html" l gen true r (cz 1 lz 1 nz 1 oz 1 vz 1) "http://www.rsac.org/ratingsv01.html" l gen true r (n 0 s 0 v 0 l 0) "http://www.classify.org/safesurf/" l gen true r (SS~~000 1))' />
|
||
|
|
<meta name="DC.Type" content="topic" />
|
||
|
|
<meta name="DC.Title" content="How geographic mirroring works" />
|
||
|
|
<meta name="DC.Relation" scheme="URI" content="rzalygeographicmirror.htm" />
|
||
|
|
<meta name="copyright" content="(C) Copyright IBM Corporation 2002, 2006" />
|
||
|
|
<meta name="DC.Rights.Owner" content="(C) Copyright IBM Corporation 2002, 2006" />
|
||
|
|
<meta name="DC.Format" content="XHTML" />
|
||
|
|
<meta name="DC.Identifier" content="rzalygeoworks" />
|
||
|
|
<meta name="DC.Language" content="en-us" />
|
||
|
|
<!-- All rights reserved. Licensed Materials Property of IBM -->
|
||
|
|
<!-- US Government Users Restricted Rights -->
|
||
|
|
<!-- Use, duplication or disclosure restricted by -->
|
||
|
|
<!-- GSA ADP Schedule Contract with IBM Corp. -->
|
||
|
|
<link rel="stylesheet" type="text/css" href="./ibmdita.css" />
|
||
|
|
<link rel="stylesheet" type="text/css" href="./ic.css" />
|
||
|
|
<title>How geographic mirroring works</title>
|
||
|
|
</head>
|
||
|
|
<body id="rzalygeoworks"><a name="rzalygeoworks"><!-- --></a>
|
||
|
|
<!-- Java sync-link --><script language="Javascript" src="../rzahg/synch.js" type="text/javascript"></script>
|
||
|
|
<h1 class="topictitle1">How geographic mirroring works</h1>
|
||
|
|
<div><div class="section"><h4 class="sectiontitle">Configure</h4><p>The nodes participating in geographic
|
||
|
|
mirroring must be in the same cluster, the same device domain, and the same
|
||
|
|
cluster resource group. Before configuring geographic mirroring, you must
|
||
|
|
specify a site name and the TCP/IP address(es) for each node in the recovery
|
||
|
|
domain. If you have more than one node at a site, then the hardware (disk
|
||
|
|
units) you select for the disk pool must be switchable between the nodes at
|
||
|
|
the site. If you only have one node at a site, the hardware does not have
|
||
|
|
to be switchable and should be non-switchable (private). </p>
|
||
|
|
<p>See <a href="rzalyconfiguregeographic.htm">Configure geographic mirroring with dedicated independent disk pools</a> and <a href="rzalyconfigureswitchgeographic.htm">Configure geographic mirroring with switchable independent disk pools</a> for more information. </p>
|
||
|
|
<p>When geographic mirroring
|
||
|
|
is configured, the mirror copy has the same disk pool number and name as
|
||
|
|
the original disk pool, the production copy. Geographic mirroring is logical
|
||
|
|
mirroring, not physical mirroring. The two disk pools must have similar disk
|
||
|
|
capacities, but the mirror copy may have different numbers and types of disk
|
||
|
|
units as well as different types of disk protection.</p>
|
||
|
|
</div>
|
||
|
|
<div class="section"><h4 class="sectiontitle">Manage</h4><div class="p">After geographic mirroring is configured,
|
||
|
|
the production copy and mirror copy function as a unit. When the production
|
||
|
|
copy is made available, the mirror copy is brought to a state that allows
|
||
|
|
geographic mirroring to be performed. Synchronization occurs when you make
|
||
|
|
the disk pool available after you configure geographic mirroring. When geographic
|
||
|
|
mirroring is active, changes to the production copy data are transmitted to
|
||
|
|
the mirror copy across TCP/IP connections. Changes can be transmitted either
|
||
|
|
synchronously or asynchronously. <ul><li><span class="uicontrol">Synchronous mode</span>: The client waits until the operation
|
||
|
|
is complete to disk on both the source and target systems. The mirror copy
|
||
|
|
is always eligible to become the production copy, because the order of writes
|
||
|
|
is preserved on the mirror copy. It is recommended to try synchronous mode
|
||
|
|
first. If your performance remains acceptable, continue to use synchronous
|
||
|
|
mode. </li>
|
||
|
|
<li><span class="uicontrol">Asynchronous mode</span>: The client must wait only until
|
||
|
|
the operation is complete to disk on the source system and is received for
|
||
|
|
processing on the target system. However, synchronous mode is safer because
|
||
|
|
if the primary node fails or the production copy fails, the mirror copy can
|
||
|
|
become the production copy. In asynchronous mode, the pending updates must
|
||
|
|
be completed before the mirror copy can become the production copy.</li>
|
||
|
|
</ul>
|
||
|
|
</div>
|
||
|
|
<p>To maintain the data integrity of the mirror copy, the user cannot
|
||
|
|
access the mirror copy while geographic mirroring is being performed. The
|
||
|
|
user can detach the mirror copy to perform save operations, to create reports,
|
||
|
|
and to perform data mining. However, the mirror copy must be synchronized
|
||
|
|
with the production copy after it is reattached. </p>
|
||
|
|
</div>
|
||
|
|
<div class="section"><h4 class="sectiontitle">Tracking space </h4>To suspend geographic mirroring with
|
||
|
|
tracking, you set the tracking space when you configure geographic mirroring
|
||
|
|
or change geographic mirroring attributes. Tracking space is allocated in
|
||
|
|
the independent ASPs. The more tracking space you specify, the more changes
|
||
|
|
the system can track. The maximum tracking space allowed is approximately
|
||
|
|
1% of the independent ASPs capacity. </div>
|
||
|
|
<div class="section"><h4 class="sectiontitle">Suspend geographic mirroring with tracking</h4>If you suspend
|
||
|
|
with tracking, the system will attempt to track changes made to those disk
|
||
|
|
pools. This may reduce the synchronization process by performing partial synchronization
|
||
|
|
when you resume geographic mirroring. If tracking space is exhausted, then
|
||
|
|
when you resume geographic mirroring, complete synchronization is required.
|
||
|
|
<div class="note"><span class="notetitle">Note:</span> When you resume geographic mirroring, a complete synchronization can
|
||
|
|
be a lengthy process, anywhere from several hours to even longer. </div>
|
||
|
|
</div>
|
||
|
|
<div class="section"><h4 class="sectiontitle">Suspend without tracking </h4>If you suspend geographic
|
||
|
|
mirroring without tracking changes, then when you resume geographic mirroring,
|
||
|
|
a complete synchronization is required between the production and mirror copies.
|
||
|
|
If you suspend geographic mirroring and you do track changes, then only a
|
||
|
|
partial synchronization is required. Complete synchronization can be a very
|
||
|
|
lengthy process, anywhere from one hour, to several hours, to even longer.
|
||
|
|
The length of time it takes to synchronize is dependent on the number and
|
||
|
|
type of disk units as well as how many TCP/IP communication interfaces are
|
||
|
|
dedicated to geographic mirroring. </div>
|
||
|
|
<div class="section"><h4 class="sectiontitle">Synchronization</h4><p>The production copy can function
|
||
|
|
normally during synchronization, but performance might be negatively affected.
|
||
|
|
During synchronization, the contents of the mirror copy are unusable, and
|
||
|
|
it cannot become the production copy. If the independent disk pool is made
|
||
|
|
unavailable during the synchronization process, synchronization resumes where
|
||
|
|
it left off when the independent disk pool is made available again. Note that
|
||
|
|
the first % complete message (CP1095D), after resuming an interrupted synchronization,
|
||
|
|
shows 0%.</p>
|
||
|
|
</div>
|
||
|
|
<div class="section"><img src="./delta.gif" alt="Start of change" /><h4 class="sectiontitle">Synchronization type</h4>These are two types
|
||
|
|
of synchronization: <p>Full synchronization</p>
|
||
|
|
<ul><li>Indicates that a complete synchronization takes place. Changes to the
|
||
|
|
production copy are not tracked to apply to the synchronization.</li>
|
||
|
|
<li>Deletes all of the data on the mirror copy and copies all of the latest
|
||
|
|
data from the production copy to the mirror copy. </li>
|
||
|
|
</ul>
|
||
|
|
<p>Partial synchronization</p>
|
||
|
|
<ul><li>Indicates that changes to the production copy are tracked to apply to
|
||
|
|
the synchronization. This may shorten the synchronization time because a complete
|
||
|
|
synchronization is unnecessary.</li>
|
||
|
|
</ul>
|
||
|
|
<img src="./deltaend.gif" alt="End of change" /></div>
|
||
|
|
<div class="section"><h4 class="sectiontitle">Synchronization priority</h4><p>When
|
||
|
|
you set the attributes for geographic mirroring, you can set the synchronization
|
||
|
|
priority. If synchronization priority is set high, the system uses more resources
|
||
|
|
for synchronization, which results in a sooner completion time. The mirror
|
||
|
|
copy is eligible to become a production copy faster, so you are protected
|
||
|
|
sooner. However, high priority can cause degradation to your application.
|
||
|
|
It is recommended that you try high priority first, so you are protected as
|
||
|
|
soon as possible. If the degradation to your application performance is not
|
||
|
|
tolerable, then lower the priority.</p>
|
||
|
|
</div>
|
||
|
|
<div class="section"><h4 class="sectiontitle">Recovery timeout</h4><p>In addition to synchronization
|
||
|
|
priority, you can also set recovery time out. The recovery timeout specifies
|
||
|
|
how long your application can wait when geographic mirroring cannot be performed.
|
||
|
|
When an error, such as IP failure, prevents geographic mirroring, the source
|
||
|
|
system waits and retries for the specified recovery timeout before suspending
|
||
|
|
geographic mirroring which allows your application to continue. The trade-off
|
||
|
|
is between blocking your application or requiring synchronization after suspending
|
||
|
|
geographic mirroring. When your application is blocked for an extended time,
|
||
|
|
other jobs might also be blocked waiting for resources and locks owned by
|
||
|
|
the applications using the geographic mirrored disk pool. When geographic
|
||
|
|
mirroring is suspended, you no longer have the protection of
|
||
|
|
the mirror copy. If your application can tolerate a delay, it is recommended
|
||
|
|
to set recovery timeout from 2 to 5 minutes. If the volume of your data is
|
||
|
|
large (over a terabyte), consider a longer recovery timeout value to reduce
|
||
|
|
the possibility of suspending geographic mirroring. If mirroring is suspended
|
||
|
|
without tracking, the system performs a full synchronization. If geographic
|
||
|
|
mirroring is suspended with tracking, the system performs a partial synchronization. </p>
|
||
|
|
</div>
|
||
|
|
<div class="section"><h4 class="sectiontitle">System roles</h4><p>When
|
||
|
|
you <a href="rzalyconfiguregeographic.htm">configure</a> the
|
||
|
|
cluster for geographic mirroring, you have many options for defining the availability
|
||
|
|
and protection of the independent disk pool. When you create the switchable
|
||
|
|
hardware group, you list the order of the backup systems to which the independent
|
||
|
|
disk pool will failover or switch over. If the primary node switches to a
|
||
|
|
backup node at the same site, a hardware switch will occur. If the primary
|
||
|
|
node switches to the other site, the mirror copy on the backup node changes
|
||
|
|
roles to become the production copy. The old primary node becomes the new
|
||
|
|
backup node, and the production copy becomes the mirror copy. The new production
|
||
|
|
copy is now accessible for updates on the remote system. If the independent
|
||
|
|
disk pools are part of a disk pool group, all of the disk pools in the group
|
||
|
|
will switchover together. See <a href="rzalyexamplegeomirror.htm">Example: Independent disk pools with geographic mirroring</a>. </p>
|
||
|
|
</div>
|
||
|
|
</div>
|
||
|
|
<div>
|
||
|
|
<div class="familylinks">
|
||
|
|
<div class="parentlink"><strong>Parent topic:</strong> <a href="rzalygeographicmirror.htm">Geographic mirroring</a></div>
|
||
|
|
</div>
|
||
|
|
</div>
|
||
|
|
</body>
|
||
|
|
</html>
|