Start a Conversation

Unsolved

This post is more than 5 years old

3444

May 25th, 2018 11:00

VPLEX METRO BREAK & RECOVER

Dear Friends,

I need some help here. I have a setup where I have two VPLEX boxes in Metro configuration with each VPLEX having base storage XIO. Distributed virtual volumes are presented to hosts connected to each of the VPLEX boxes with underlying extents being mirrored.

I have these VPLEX boxes in the same building just a few meters away from each other and hence Metro configuration has no value in case if entire building collapses.

I need to figure out the DR plan and I was thinking to break the metro config, lift and shift one VPLEX with XIO to a datacenter that is 100 miles apart, establish a communication over IP WAN instead of FC, getting the VPLEXs in metro config again. I needed high level inputs on how I can achieve this.

Can above be done without any impact to production ?

Is there any knowledge article which list down the steps to achieve what i need ?

Any information on this will be highly appreciated.

Thank you !!

Regards,

Yuvik

286 Posts

May 30th, 2018 09:00

Is it possible to keep FC between the buildings? We cannot swap the FC wan modules to IP on a configured system

13 Posts

May 30th, 2018 11:00

Hello Ankur,

Thank you for your reply.

It all depends on the cost to keep FC between the DCs since we are talking about 100 miles of distance here however assuming that we keep FC connections, what would be the steps to achieve what we need without impacting the production.

Thanks & Regards,

Yuvik

May 31st, 2018 07:00

Hi Yuvik,

I think the sawp from FC to IP can be done with RPQ. It would need downtime for both the clusters before it could be moved to a different site. Because it would require the directors to be rebooted for the change in port roles and layout and will require the directors to be down when replacing the Modules.

Thanks,

Sathya

286 Posts

May 31st, 2018 08:00

For a configured system this is not allowed in the field. A RPQ would be the way to go to get an official answer, but it would require a reset of the vplex which is disruptive.

As you will be shutting down a vplex you will lose the logging volume ability to do an incremental sync. You could move the workload to the primary site (cluster-1), make sure the detach rules are set to winner cluster-1. Shut down cluster-2 and move it..then bring it back up.

If you want to make it more "clean" you could convert every distributed volume to a local. Then do the move, then establish the remote mirror

I made a video on how to take a DR1 and reduce it to a local

Reduce a VPLEX DR1 to a VPLEX local non-disruptively - YouTube

13 Posts

June 6th, 2018 02:00

Hello Sathya & Ankur,

Thank you for your inputs !!

Hello Ankur,

Your explanation makes sense. This is what I was referring to. I will see the video and will get back if I have any further queries.

However, I wanted to confirm if there are any constraints or dependencies with respect to Latency, existing hardware or software versions ?

For example, I had heard that for a Metro configuration latency should be less than 5ms?  So, can the solution work on an IP WAN link instead ?

Thanks & Regards,

Yuvik

286 Posts

June 6th, 2018 04:00

Please look at the support matrix. It will list the latency requirements. It will list what latency requirements are for the applications. It can range from 5ms to 10ms. It can be done via FC or IP. Remember we cannot switch between FC and IP without major disruption.

No Events found!

Top