I Just want to know if someone out there did a migration from HP EVAs to FAS6280.
Our Current configurations are
Two Datacenters witch some replicated data (35%)
Dual Fibre Channel Fabric.
Four HP EVA, two on each sites that replicate data
Clustering application (geo-cluster)
We are using HP proliant servers with Windows 2003-2008 configured with dual FC HBA
Our new configuration wil be 4x FAS6280, two on each sites.
We have some critical applications that need to be available 24x7. The main goal is to migrate without any down time, if it is possible, so if some of you went to this process it would be great to get some input or tips
Solved! See The Solution
8 REPLIES 8
Re: Storage Migration
2011-04-14 12:03 PM
Migration without ANY downtime is a big challenge but i recommend that you check the Viacom Systems FlexDM migration appliance and services http://www.vicom.com/pdf/2009-09-11-FlexDM-Service-Brief-100909c.pdf .Their systems allow data migration no-outage and it's simple to use.
However, small outages caused when changing hosts LUN from old system to new system (uninstalling/installing MPIO drivers, remove/add LUNS, changing WWN HBA's BIOS if SAN boot used, etc.).
You are also going to need to install the Host Attach Kits (or whatever the name is this year) from NetApp to get a supported configuration, which means you are going to have to boot to get the registry settings in place at some point as well...
If you really have applications that never can go down, then you probably are going to need something in front of the NetApps... or you will have the same problem in about 3 years... Almost hard to believe that anyone has 100% uptime apps on EVA's anyway... and the jump to the monster 6280's will be like going from a Prius to a Ferrari... 100% uptime systems probably should have been MetroClusters anyway... smaller systems, more redundance...
Re: Storage Migration
2011-04-20 03:13 AM
I have just finished a similar kind of a Project, we had to integrate the V3170 into their SAN Environment which had EVA8100 x 2.
The advantage i had, the Hosts Servers were HP Superdome running on HPUX.
We Connected Temporary Shelfs to the VSeries:
1. Created Volumes
2. Presented to the the Hosts (HPUX)
3. Did OS based mirroring - HPUX-MirrorDisk Software.
4. Did a vgreduce to remove the HP EVA Disks from the Volume Group, same for all the other VG's
5. Once the EVA was cleared up, Presented the Vdisks from the EVA to V-Series.
6. Again Created new Aggr & Volumes carved from the EVA Disks.
7. Used Data Motion - vol move to move the Volumes from Once Aggr to Another Online. " Did this for all the Volumes"
8. Finally removed the NetApp Shelfs.
All the above was done Online "There will be slight Preformance Degradation on both Servers / Storage"
Everything ruinning on the Virtualized EVA.
Installing NetApp Hosts kits, doesn't require any down time.
What type of Volume Manager do they use for the Windows Environment ?
How many Servers/Hosts are you looking to migrate ?
Well this is a very interesting way to do the migration
1. I have around 150 servers to migrate
2. I used the Native Windows Disk Management (diskmgmt.msc)
In regard to the Netapps Server Kit, I only find that it is needed for HyperV, is it madantory for windows servers and why?
Also I did some search on google and find a few thread, and most of them was talking about mirror process.
I don't see any problem for regular servers, but for Microsoft Dispersed Cluster Servers in an Active_Active configuration, were all the critical applications are seem to be a lot of management.
So the way i see it, and sorry for my lack of knowledge, on my regular servers I could
1. Create an Aggrete
2. Create a FlexVol volume
3. Present this volume to the server (using Brocade zoning so that the server can see both array)
4. Create a Mirror
5. When mirror is in sync, un present the EVA VDisk, and break the mirror
7. Migrated to another aggregate if needed it
For sure that will needed to be test,
Again thank you all for your input
Comparing HP-UX to Windows is a sort of apples and oranges comparison.
The fundamental reason for the reboot (even on OS's like Solaris) is to get the various disk time-out values that NetApp requires for a supported configuration enabled. Now it may very well be that the EVA settings are pretty similar, but if not, the first time you start doing upgrades on the NetApp and have the incumbant short stops in I/O from the storage system, you are going to lose disks and crash applications. It may very well be that HP-UX can do such kernel settings without reboot, but Windows relies on Registry settings that get imported at boot.
The Host Utilities are required for all operating systems as part of a supported configuration. You may very well get your migration completed without them, but things like upgrading the NetApp software (something that you probably will want to do at least once a year at least to get new features) is going to go terribly wrong because your disk time-outs may not be set to the required values. The values set by the Host Utilities may very well invalidate your supported EVA configuration as well, so there is a bit of a dance to get done here. Installing the Host Utilities as soon as possible after your migration would be probably the best possible compromise.
You might also want to reorganize your storage to take advantage of the additional features you get by using NetApp. Copying directly from a "dumb disk" system like the EVA to a NetApp will probably tie your hands for some more advanced features that NetApp can offer.
Make sure you read the chapter on Block Access Management before you proceed. One of the most important things to get right is the LUN type. This is a pretty essential part of getting the correct performance out of your LUN's. The names of the LUN types are NOT as simple as they seem (unless you are a HP-UX administrator and only have one type) and you probably should read up on what is recommended. It will mean a 15 to 20% performance hit if you get it wrong. As long as you are setting up the disks manually before you start mirroring, you shouldn't have problems. And exact block copy of the EVA storage would result in significant performance problems.
Reallocation (a sort of LUN defragmentation) is something that you also should familiarize yourself with or your performance will slowly degrade over time and you'll be the target of complaints and general abuse from your application people.
Like most things, the learning curve is a bit steep at the beginning, but it gets easier over time.