EMC CX500I Configuration Guide - Page 73

What Is MirrorView?, MirrorView Example

Page 73 highlights

Data Replication and Data Mobility Software What Is MirrorView? EMC MirrorView is storage-system-based software that maintains a copy of an image of a logical unit (LUN) at separate locations. The images are far enough apart to provide for disaster recovery, that is, to let one image continue if a serious accident or natural disaster disables the other. The production image (the one mirrored) is called the primary image; the copy of the image is called the secondary image. The primary image is connected to a server called the production host. The secondary image is maintained by a separate storage system that can be a stand-alone storage system or connected to its own server. Since the same management station must manage both storage systems, you can use it to promote the secondary image if the primary image becomes inaccessible. An optional write intent log keeps track of writes that may not yet be recorded in one or more of a mirror's images. Using the write intent log provides the maximum protection against having to do a full resynchronization. MirrorView also supports protocols that let you use FC/IP to send mirrored data over extended distances. MirrorView Example Figure 4-3 shows two sites and a primary and secondary image that includes the database of three LUNs. Each server has a path to each SP on each storage system through each fabric. If a failure occurs in a path, then the storage-system software may switch to the path through the other SP (transparent to any applications). The server sends a write request to an SP in Storage System 1, which then writes data to the local LUN and mirrors the data on Storage System 2. The mirroring is synchronous, so that Storage System 2 always contains all data modifications that are acknowledged by Storage System 1 to the production host. The server sends a write request to an SP in Storage System 1, which writes data to its image while sending it to the corresponding SP in Storage System 2. Storage System 2 then writes the data to its image. What Is MirrorView? 4-11

  • 1
  • 2
  • 3
  • 4
  • 5
  • 6
  • 7
  • 8
  • 9
  • 10
  • 11
  • 12
  • 13
  • 14
  • 15
  • 16
  • 17
  • 18
  • 19
  • 20
  • 21
  • 22
  • 23
  • 24
  • 25
  • 26
  • 27
  • 28
  • 29
  • 30
  • 31
  • 32
  • 33
  • 34
  • 35
  • 36
  • 37
  • 38
  • 39
  • 40
  • 41
  • 42
  • 43
  • 44
  • 45
  • 46
  • 47
  • 48
  • 49
  • 50
  • 51
  • 52
  • 53
  • 54
  • 55
  • 56
  • 57
  • 58
  • 59
  • 60
  • 61
  • 62
  • 63
  • 64
  • 65
  • 66
  • 67
  • 68
  • 69
  • 70
  • 71
  • 72
  • 73
  • 74
  • 75
  • 76
  • 77
  • 78
  • 79
  • 80
  • 81
  • 82
  • 83
  • 84
  • 85
  • 86
  • 87
  • 88
  • 89
  • 90
  • 91
  • 92
  • 93
  • 94
  • 95
  • 96
  • 97
  • 98
  • 99
  • 100
  • 101
  • 102
  • 103
  • 104
  • 105
  • 106
  • 107
  • 108
  • 109
  • 110
  • 111
  • 112
  • 113
  • 114
  • 115
  • 116
  • 117
  • 118
  • 119
  • 120
  • 121
  • 122
  • 123
  • 124
  • 125
  • 126
  • 127
  • 128
  • 129
  • 130
  • 131
  • 132
  • 133
  • 134
  • 135
  • 136
  • 137
  • 138
  • 139
  • 140
  • 141
  • 142

What Is MirrorView?
4-11
Data Replication and Data Mobility Software
What Is MirrorView?
EMC MirrorView is storage-system-based software that maintains a
copy of an image of a logical unit (LUN) at separate locations. The
images are far enough apart to provide for disaster recovery, that is,
to let one image continue if a serious accident or natural disaster
disables the other.
The production image (the one mirrored) is called the primary image;
the copy of the image is called the secondary image
.
The primary
image is connected to a server called the production host. The
secondary image is maintained by a separate storage system that can
be a stand-alone storage system or connected to its own server. Since
the same management station must manage both storage systems,
you can use it to promote the secondary image if the primary image
becomes inaccessible.
An optional write intent log keeps track of writes that may not yet be
recorded in one or more of a mirror’s images. Using the write intent
log provides the maximum protection against having to do a full
resynchronization.
MirrorView also supports protocols that let you use FC/IP to send
mirrored data over extended distances.
MirrorView Example
Figure 4-3 shows two sites and a primary and secondary image that
includes the database of three LUNs.
Each server has a path to each SP on each storage system through
each fabric. If a failure occurs in a path, then the storage-system
software may switch to the path through the other SP (transparent to
any applications).
The server sends a write request to an SP in Storage System 1, which
then writes data to the local LUN and mirrors the data on Storage
System 2. The mirroring is synchronous, so that Storage System 2
always contains all data modifications that are acknowledged by
Storage System 1 to the production host.
The server sends a write request to an SP in Storage System 1, which
writes data to its image while sending it to the corresponding SP in
Storage System 2. Storage System 2 then writes the data to its image.