A Hidden Gem in Compellent
As you might well know I’m in the process of doing a multi site SAN replacement project to modernize the infrastructure at a non disclosed organization. The purpose is to have a modern, feature reach, reliable and affordable storage solution that can provide the Windows Server 2012 roll out with modern features (ODX, SMI-S, …).
One of the nifty things you can do with a Compellent SAN is migrations from LUNs of the old SAN to the Compellent SAN with absolute minimal downtime. For us this has proven a real good way of migrating away from 2 HP EVA 8000 SANs to our new DELL Compellent environment. We use it to migrate file servers, Exchange 2010 DAG Member servers (zero downtime), Hyper-V clusters, SQL Servers, etc. It’s nothing less than a hidden gem not enough people are aware off and it comes with the SAN. I was told that it was hard & not worth the effort by some … well clearly they never used and as such don’t know it. Or they work for competitors and want to keep this hidden 
.
The Process
You have to set up the zoning on all SANs involved to all fabrics. This needs to be done right of course but I won’t be discussing this here. I want to focus on the process of what you can do. This is not a comprehensive how to. It depends on your environment and I can’t write you a migration manual without digging into that. And I can’t do that for free anyway. I need to eat & pay bills as well
Basically you add your target Compellent SAN as a host to your legacy SAN (in our case HP EVA 8000) with an operating system type of “Unknown”. This will provide us with a path to expose EVA LUNs to our Compellent SAN.
Depending on what server LUNs you are migrating this is when you might have some short downtime for that LUN. If you have shared nothing storage like in an Exchange 2010 or a SQL Server 2012 DAG you can do this without any downtime at all.
Stop any IO to the LUN if you can (suspend copies, shut down data bases, virtual machines) and take CSVs or disks offline. Do what is needed to prevent any application and data issue, this varies.
What we then do is we unpresent the LUN of a server on the legacy SAN.
After a rescan of the disks on the server you’ll see that disk/LUN disappear.
This same LUN we then present to the Compellent host we added above.
We then “Scan for Disks” in the Compellent Controller GUI. This will detect the LUN as an unassigned disk. That unassigned disk can be mapped to an “External Device” which we name after the LUN to keep things clear (“Classify Disk as External Device” in the picture below).
Then we right click that External Device and choose to “Restore Volume from External Device”.
This kicks off replication from the EVA LUN mapped to the Compellent target LUN. We can now map that replica to the host as you can see in this picture.
After this rescan the disks on the server and voila, the server sees the LUN again. Bring the disk/CSV back online and you’re good to go.
All the downtime you’ll have is at a well defined moment in time that you choose. You can do this one LUN at the time or multiple LUNs at once. Just don’t over do it with the number of concurrent migrations. Keep an eye on the CPU usage of your controllers.
After the replication has completed the Compellent SAN will transparently map the destination LUN to the server and remove the mapping for the replica.
The next step is that the mirror is reversed. That means that while this replica exists the data written to the Compellent LUN is also mirrored to the old SAN LUN until you break the mirror.
Once you decide you’re done replicating and don’t want to keep both LUNs in sync anymore, you break the mirror.
You delete the remaining replica disk and you release the external disk.
Now you unpresent the LUN from the Compellent host on your old SAN.
After a rescan your disks will be shown as down in unassigned disks and you can delete them there. This completes the clean up after a LUN migration.
Conclusion
When set up properly it works very well. Sure it takes some experimenting to deal with some intricacies, but once you figure all that out you’re good to go and are ready to deal with any hiccups that might occur. The main take away is that this provides for minimal downtime at a moment that you choose. You get this out of the box with your Compellent. That’s a pretty good deal I say!
So as you can see this particular environment will be ready for Windows Server 2012 & Hyper-V. Life is good!
But it can be fixed. The root cause for this I do not know but it is driver related. The same thing happened in the release candidate. But now things are easier to fix. Navigate to the Intel Site to download their freshly released driver for the X520 series on Windows Server 2012 and install it (you don’t need to install the extra software with Advanced Network Services => native Windows NIC teaming has arrived). After that the flapping will be gone.
. They have been very helpful in all this as have been al the Microsoft employees who’ve answered and discussed all the questions/ideas we threw at them. I would like to thank all of them for their time, their patience and the opportunities given to us. I can offer those guys & galls just one reward: the fact that from day one we are taking this in production and gradually will do so for all our infrastructure systems and so on. It’s a no brainer when you’ve worked with the RC and seen what Windows Server 2012 can do. And no, I’m not forgetting Windows 8. SMB 3.0 & Direct Access and Windows to go alone make that a sweet proposition, but I got those bits already.
). After some initial tests these will be taken into service and that last feedback will provide us with the go or no go for the rest of our infrastructure. The speed & completeness of our move depends partially on how fast System Center 2012 SP1 brings support for Windows Server 2012.
