- 论坛徽章:
- 0
|
正在研究此问题，搜索到此贴，但又未详细讲清楚，恰好又个鸟语贴解答了，贴上
http://forums.hds.com/index.php? ... msearch__1#entry208
Here is a brief description of how the various replication technologies work. This info is also in the product manuals that are available to our customers.
Disclaimer - I apologize if this information is 'widely' known by the user group, is by no means the definitive answer and applies to USP/NSC lines. I am new to Universal Replicator so the info may be less than optimal.
Couple terms to note: (Perhaps an FAQ on terms can be created)
PVOL - Primary Volume in a replication pair (usually the production LUN/LDEV)
SVOL - Secondary Volume or target in a replication pair (a Shadow Image or TrueCopy target LDEV)
MCU - Primary subsystem where production data resides (TC & UR)
RCU - Remote subsystem where the recovery data resides (TC & UR)
TC - TrueCopy (array to array replication)
SI - Shadow Image (LUN to LUN replication within an array)
UR - Universal Replicator (array to array replication)
JNL - Journal Group (used in UR), a parity group designated as such
ack - acknowledgement
Sidefile - area of cache on the USP/NSC that is used to store pending updates for replication
TrueCopy Sync - When a change in a track takes place at the MCU, the entire track is sent over the wire to the RCU. The RCU sends an ack to the MCU once it has updated the relevant SVOL. (It is unclear to me if an ack back to the MCU takes place once the data has been committed to disk at the RCU, or only written to cache at the RCU). Once the MCU has received an ack that a track has been committed by the RCU, the MCU sends an ack to the host that the write has been completed.
TrueCopy Async - When a change in a track takes place at the MCU, the track is marked dirty in cache, a timestamp is added to the changed track data - together called a record set - and kept in Sidefile at the MCU. The host is given an immediate ack once the write data has been committed to the MCU cache. The array keeps track of the pending record sets in sidefile and attempts to send over the waiting record sets at its first opportunity. Once the RCU receives the recordsets it places them into its sidefile. It then commits the writes in order of timestamps. I believe the MCU is able to reclaim the used sidefile slots once it has received an ack from the RCU that the recordset was successfully received. The data is not sent in a batch process but on a continual basis. For a properly sized TC Async environment (including bandwidth and cache) you should see very little if any sidefile usage. The timestamping allows the record sets to be sent over the wire and received in an out-of-order fashion. However the RCU commits the writes to disk based on the timestamp. Thus if you have a low quality link which drops a lot of packets, you can see a high level of re-tries and buildup in sidefile at the RCU as it awaits the relevant recordsets.
Universal Replicator - When a change in a track takes place at the MCU, the track is marked dirty in cache, a timestamp is added to the changed track data - together called a record set - and kept in JNL at the MCU. The host is given an immediate ack once the write data has been committed to the MCU cache. The RCU continually asks the MCU for JNL data - this is the pull of UR vs. push of TC - the MCU sends over the JNL data, RCU updates its JNL group and sends an ack to the MCU. This offloads some replication mgmt from the MCU to the RCU. However, just like TC, UR must have, an adequate number of ports, properly sized link(s), JNL and cache to function optimally. |
|
免费注册
发表于 2009-03-12 05:22
