DataCore & VMWare Storage VMotion - Solving Troublesome Migration Problems

An interesting day in the life story...submitted today from one of the DataCore Technical Account Managers in the UK...

March always presents an interesting time in local government; the end of the financial year sees the opportunity for the IT managers to get the projects that they've always wanted to do out of the way. This was no different for a large hospital system client that I visited this morning. They have purchased DataCore and were at the stage of the project that most IT Managers dread... Attempting to calculate the downtime and risk of the implementation of a brand new SAN environment.

Lists of application servers had been drawn up, tiers had been assigned, timescales were mooted and several small conversations were taking place amongst the people involved as to what needed to go first and what could be coped without when. The migration was to move from CX300 hardware to a DataCore SANsymphony environment housed upon large storage servers. Initially a 2 node configuration, with a primary production SAN and a DR SAN housed 8 miles away at the sister hospital, the purpose of the project was to provide an initial DR strategy and Storage expansion for a virtualised environment, culminating in the implementation of a Microsoft Sharepoint environment to improve the efficiency and end user experience within the PCT.

So after about 15 minutes of discussion I asked what version of ESX they were on... 3.0.1 came the reply. This quickly turned into a discussion regarding the upgrade path of VMWare from 3.0.1 to 3.5 and when the ease of this became apparent the solution became a no-brainer. Use Storage VMotion! By provisioning the DataCore Virtual Volumes to the ESX hosts as datastores, we can then Storage VMotion from one datastore to the other! There will be NO downtime at all! Having gone through the idea in a little more detail it became obvious that it was watertight and what was a potentially awkward, convoluted meeting with tight schedules became an easy discussion about just how flexible the solution was.

The icing was the cake was the point at which we decided that we could "chuck a 4GB HBA into the storage server" for the time that the 3rd node is to be implemented... "It'll just mean we can bang it in without any downtime again..." was the final comment on the matter.