VC Profiles - can they be exported/imported

[The Brit]

I am running OpenVMS (8.3-1H1) on bl860c itanium blades (8) in c7000 enclosures (3). Two of my enclosures are designated as Production and are located in my primary data center. Each of these enclosures contains 2 bl860c blades and the 4 blades in these two enclosures comprise an OpenVMS cluster. VC profiles have been created for all 4 blades (nodes).

The third enclosure is in my secondary data center, (3 miles away). This enclosure contains 4 bl860c blades, also running OpenVMS 8.3-1H1. These 4 blades are used for development.

Our DR strategy (in the event that the Primary DC is destroyed or unusable) revolves around discarding Development, and bringing up the Production cluster on these 4 blades.

With this in mind, the simplest recovery would be if I could take my Production Profiles and apply them to the blades in the Secondary DC.

I cannot find anyway to export, or import profiles from one enclosure to another. Is there a way to do this??

I am aware that Enterprise VCM is coming and will allow the stacking of enclosures, and hence the moving of profiles between enclosures which are in the same domain, bu I'm not sure if this will extend to remote enclosures (although I dont see why it wouldnt if the normal 1GB uplink ports can be used to stack)

Anyway, I would be interested in any information or suggestions about how I could impliment my "simplest way" option.

thanks

Dave.

[karim h]

Dave,
Your question is a bit vague.. assuming Production is unavailable, the production profiles will be using WWNs that are zoned to your production storage array (assuming you're using a SAN), so bringing those profiles up at the secondary site would be pointless, as the server wouldn't be able to access the storage at the primary site - it is potentially inaccessible or destroyed.

Are you utilising any form of storage mirroring between your primary and secondary DCs?

One way you might do it is to (im making alot of assumptions here)

1) Boot your OpenVMS systems from SAN, use Direct attached storage for nothing but pagefiles
2) Have your SAN engineer setup asynchrous or synchronous (realtime) mirroring of the servers' storage at a LUN level to your storage array at DR (assuming you have one)
3) Create DR profiles on your C7000 Virtual Connect infrastructure at your secondary site.
4) Zone those DR profiles WWNs into your secondary site array that contains the mirror-replicated images of the production systems.
5) Configure the DR host (mirror) storage on the array at the secondary site

If a disaster occurs, break the storage mirror and promote the LUNs to the DR Blades at your secondary site. Then swap over the VC profile from DEV to the newly create DR profile and switch the server blade on.

[The Brit]

Hi Karim,
Actually, the question is very clear.

Is it possible to export/import VC Profiles?

You are sliding the issue sideways into an area which was not part of the original posting, and is actually irrelevant. OpenVMS does host based synchronous mirroring (called "Volume Shadowing"), and in our case, we have a synchronous copy of our production data at the remote site. Also, our SAN fabrics span both sites (via SAN gateways).

So the loss of the production DC does not affect the data at the remote site, and all I need to do is point the data to the Blades in the secondary DC and I am good to go (put very simply). So in this situation, if I can impose the VC WWIDs onto the recovery blades, and the SAN volumes are already presented to these WWIDs, then recovery is relatively simple (in principle).

This is why I would like to be able to export my production profiles.

Dave.

[The Brit]

Karim,
I should add that I agree that the solution that you suggest in (3), (4) and (5) would probably work, and I may be forced to resort to that ultimately. Obviously it would be much nicer to copy the production profiles.

A more desperate solution that I considered would be to set up the remote enclosures the same as Production, and then in the event of a failure I could just impose the Production VC Configuration on the Remote enclosure. Of course that would then affect all blades in the enclosure. That would be the recovery of last resort

Thanks anyway for your comments.

Dave

[karim h · Accepted solution]

Thanks for your comments.

I was looking into a chassis export/import process some time ago when I was designing disaster recovery capability for an investment bank.

I implemented the solution described above and it has since been tested and proven in a full site failure/loss of site scenario. When designing a DR solution, it's important to remember that you design it in such a way that it can actually be tested. The frequency of tests (dictated through external/internal audit requirements) and the testing window of opportunity are important considerations for the DR technical design that are OFTEN overlooked

Anyway, to get back to your question:
The method I am proposing has some distinct advantages over an import/export process

1) Seperate DR profiles give you the ability to selectively invoke DR for an individual system or group of systems - in contrast importing the production chassis is an "all or nothing" process
2) Point 1, less interruption to other systems within the chassis if you only need to recover an individual service - some of your DEV environment could remain online.
3) Assuming you do at least an annual DR test, there is some inherent risk associated with destroying the configuration of an entire chassis, only to have to recreate it after the test - what if the recreation fails? The method I described doesn't require radical configuration changes, it only requires you to swap the profiles over (which I do with a VC CLI script)
4) You can use the DR profiles for other things: For major application upgrades - I can snapshot (at the array) the mirrored storage, switch on a point in time copy of the production system, perform the upgrade in a true replica of production to see if it is going to work or fail, before you do the real thing..

With that said, its not perfect. Theres overheads on the storage and fabric levels - DR VC profiles will need to be zoned into your SAN environment. Other than that though, its not a bad solution.

Hope some of that information was helpful. You may even find that my suggestion is the simplest, it just needs a little bit of prep work to be done.

[Terri Harris]

Virtual Connect Server Profiles are dependent on the configuration of the VC Ethernet Network setup & the VC FC SAN Setup. So there is no option in Virtual Connect to export or import just the Server Profiles.
There is the option (as you probably already know) to export a VC Domain (VC Backup) and Import the domain (including into a new enclosure) with the VC Restore command.
Since the virtual MAC & pWWNs addresses would carry over, you would never want to import into a new enclosure unless the old enclosure will not be put back as-is.
Would this solution work?

[The Brit]

Thanks for your comments Terri.

I guess my point is this;

Here at my location I run OpenVMS, and I have a SAN which covers both of my DC's. I use Host-based Volume shadowing to keep a copy of my data in my remote site, and in case you are not familiar with this product, it is effectively host-based, synchronous mirroring. The Network also spans both locations.


Because my SAN based storage is presented to Virtual WWIDs (stored in the Profile), a catastrophic failure of DC1 could be dealt with simply by transfering the profile, with the virtual WWIDs and HW Addresses to the server in my remote location. The only area where I see possible problems would be if the remote enclosure was using the same block of virtual wwids and HW addresses, i.e. a conflict would be possible. However, if all enclosures are using different blocks of wwids and hw addresses, then the conflict cannot occur.

If there is some other potential problem associated with moving profiles between enclosures, it would be good to know about it. If not, I think the export/import option should be made available (even if it is under an "Advanced Options" Tab, surrounded by as many totally scary and frightening warnings as are considered necessary, to ensure that it is only used by people who (feel that they) really understand what they are doing.

As was mentioned earlier, the problems of moving a whole VC configuration from one enclosure to another (unless a great amount of planning was done) is likely to create more problems than it would resolve.

Perhaps these issues will be resolved with the arrival of the "Enterprise VC Domain Manager" which I believe is currently under Beta test. However it will only solve our problem if we can stack enclosures in different buildings (probably using a dedicated uplink set).

Anyway, thanks for your comments. If it ever happens then great. Until then I will probably go the route described by Karim.

Dave.

PS Terri, did you see my questions about VC FW version 2.00 in another thread.

[The Brit]

I guess the simple answer is no. I will just have to resort to an alternative solution.

thanks guys

Dave.