Piszki Lab | EN

My case study in the clouds…

EMC MirrorView configuration on the EMC VNX arrays.

| 14 Comments

By building their own Disaster Recovery solutions often reach for solutions based on data replication between storage arrays. One such solution (let us add that the cheapest) is EMC MirrorView. It is a very simple and easy to set up service fully cooperating with VMware Site Recovery Manager (SRM). LUN replication can be done synchronously or asynchronously, in the framework of assimilation theory and terminology refer you to the StorageFreak blog where colleague Tomek exactly everything described. We will focus on MirrorView configuration directly on the VNX arrays, in my case are VNX 5200 and VNX 5300.

mi28

As part of preparations create connection through SAN between arrays. We combine ports described as MirroView, Port A-0 SPA in the first array to the port A-0 SPA on second array (and correspondingly SPB). Ports which will take place in replication can not be used in the hosts Storage Groups. If you are used these ports to communicate with the hosts, remove them from the Storage Group before connecting arrays (otherwise awaits us restart SP controllers and a lot of nasty messages).

mi27

After the storage connected, verify if seen correctly, go to the section Hosts -> Initiators.

VNX 5200:  mi1

VNX 5300: mi2

As you can see, the connection is set up correctly. To be able to perform Mirror operations, both arrays must know about yourself, be in the same domain or in two different Domains (local and remote).

mi3

This operation is carried out with a newer storage or higher-numbered firmware, in my case from the VNX 5200 I add VNX 5300 (the other way it will not work).

mi4

At this point, I have in VNX 5200 two domains, Local and Remote, for VNX 5300 is only the Local domain.

mi5

From the VNX 5200 can be managed simultaneously by both arrays seamlessly switching between them at the Unisphere client level.

mi8

Next, if you have not already have, we will create LUN for “write intent logs’. This log will help in reversing the array of problems that might occur during replication (something like transaction log). Sam LUN does not have to be big, the minimum requirement is 2GB, but we can not create it as part of Pool, this must be a RAID group. Additionally, these logs must be two, one for each SP. Under Storage-> Storage Configurations-> RAID Groups create two new groups and create new LUN.

mi20

Now under the Data Protection click on the “Configure Mirror Write Intent Log” and add our LUN. Write Intent Log is not necessary for replication, if you do not have spare disks from which we could create RAID group we can skip this step (its existence, however, increases safety).

mi21

Then we create a Reserved LUN Pool, RLP is used in the snapshots and to present the VMFS to ESXi during testing SRM. They are also necessary for asynchronous replication. Same LUN does not have to be big (this is dependent on the amount of changes in production volumes which to postpone between successive copy steps in asynchronous copy). I created three 512GB LUNs ( can not be Thin). Add them in the Data Protection-> Reserved LUN Pool.

mi14

Using VMware SRM can make switching in both directions, so a similar set of LUNs create for the second storage.

mi15

Now we move to set up replicas, create new LUN (or choose one) and from the menu choose “Create Remote Mirror”.

mi16

Depending on the distance, select whether it be a copy of synchronous (delay of no more than 10ms) or asynchronous (delay of no more than 200ms).

mi18

And so forth for each LUN. Now we go to the remote array and proceed to configure (create a LUN). After this operation, we return to the first array and check the LUN Mirrors if everything is ok (Active).

mi22

Select the LUN and click “Add Secondary”, previously prepared LUN on the remote array must be the same size as the source and can not be assigned to any Storage Groups.

mi23

At this point, we have defined mirror image of our volume (enable synchronization).

mi24

If you have more volumes that are subject to synchronization and additionally, these volumes will act as a single vSphere DRS cluster, you might want to combine these into one Mirror Consistency Group.

mi25

This ensures that all synchronized operations will be carried out simultaneously on all LUNs.

mi26

In addition, Consistency Groups translates directly into VMware SRM Protection Group. At this stage, the configuration MirrorView has been completed, the case described herein relates to replicate in one direction. It is also possible replication in both parties (Bi-Directional), the configuration is very similar. Of course, in the case of Bi-Directional talking about the replication of two different LUN sets of each array of one replicated to the second array (we have then the two active DC replicated to the other sites).

Rate this article:
[Total: 2 Average: 5]

Author: Piotr Pisz

Computer always, since I got a Commodore 64 at the end of primary school, through his beloved Amiga and Linux infinite number of consoles, until today, fully virtual day. Since 2001, Unix/Linux Systems Administrator, for seven years a faithful companion and protector of Solaris system, until his sad end. In the year 2011 came in the depths of virtualization, then smoothly ascended into the clouds and continues there today. Professionally working as Systems Architect in the Polish Security Printing Works.

14 Comments

Leave a Reply

Required fields are marked *.