HP P6000 Continuous Access Implementation Guide (T3680-96431, August 2012)

If tunnel thrash occurs, perform the following tasks to resolve the situation and return to normal
operation:
• Check all switches and routers to determine if there are high volumes of packet loss.
• Ensure that all switches and routers are configured correctly.
• Contact your service provider to determine if the circuit routing has been changed.
• Determine if tunnel thrash only occurs during periods of peak activity. If it does, the circuit
may be oversubscribed and you may need to increase the bandwidth.
Tunnel thrash can occur during normalization in a configuration with two separate IP paths (two
fabric or six fabric). During normalization, the process may detect high latency on the link being
used but low latency on the unused link. This can cause the normalization process to switch to the
unused link. This pattern can repeat itself, causing thrashing. To avoid this situation, disable one
link until the normalization is complete.
NOTE: An informational event is generated when a tunnel opens or closes. Excessive numbers
of these events is an indication of tunnel thrashing, which may lead to DR group forced logging
to maintain host accessibility.
Planning for DR group write history logs
The DR group write history log is a virtual disk that stores a DR group's host write data. The log is
created when you create the DR group. Once the log is created, it cannot be moved. You must
plan for the additional disk capacity required for each DR group write history log. For more
information on DR group log size, see “DR group write history log size” (page 43).
NOTE:
• You must plan for the consumption of additional capacity before implementing HP P6000
Continuous Access. If insufficient capacity is encountered, the request to enable asynchronous
replication will fail. This need for sufficient capacity applies to both the source and destination
arrays.
• In all write modes, the DR group write history log is structured as Vraid1, which consumes
twice the capacity requested for the log. Although Vraid1 consumes more capacity, it provides
the highest level of protection for the log content.
• A portion of the write history log is used for metadata. On the EVA3000/5000 and
EVA4x00/6x00/8x00, 3.125% of the log is reserved for metadata. On the EVA4400,
EVA6400/8400, and the P6300/P6500, 6.24% of the log is reserved.
Logging in synchronous or basic asynchronous mode
In synchronous mode or basic asynchronous mode, the DR group write history log stores data
when replication to the destination DR group is stopped because the destination DR group is
unavailable or suspended. This process is called logging. When replication resumes, the contents
of the log are sent to the destination virtual disks in the DR group. This process of sending I/Os
contained in the write history log to the destination array is called merging. Because the data is
written to the destination in the order that it was written to the log, merging maintains an
I/O-consistent copy of the DR group's data at the destination.
Logging in enhanced asynchronous mode
In enhanced asynchronous mode, the DR group write history log acts as a buffer and stores the
data until it can be replicated. The consumption of the additional capacity required for the log
should not be viewed as missing capacity—it is capacity used to create the log.
If necessary, you can reclaim allocated log disk space from a DR group in enhanced asynchronous
mode. You must first change the write mode to synchronous and then use the log control feature
42 Planning the array configuration