Data Center Migrations – It’s in the Plan (Part 2)

1 comment

This post is the second of a two- part series from Bill Peldzus, VP of GlassHouse Technologies, on how to manage and plan data center migrations. Last week, in Part One, he addressed the necessity of planning ahead for any data center changes (including adding new technology and physically moving a data center.) The first part of this series was published on Aug 19, and can be found at Data Center Migrations – It’s in the Plan.

Bill Peldzus is Vice President, GlassHouse Technologies.

Bill PeldzusBILL PELDZUS
GlassHouse Technologies

This week, I will cover the difference between “LAN away” and “WAN away” and V-2-V Copies as they relate to planning a data center migration.

A “LAN away” is Significantly Different Than a “WAN away” – Even if it’s Just Temporary

The impact of high-speed LAN connectivity versus lower-speed WAN connectivity [both latency and bandwidth] between both interdependent applications as well as user connectivity to those applications cannot be under-stated.  Far too many home-grown applications have always assumed that the applications talking together live are: 1) in the same data center and 2) the end-users are probably on a different floor in the same building or campus. This introduces many additional challenges to a migration project taking place over several weeks and/or months with things moving in stages. How long can any type of performance hit be tolerated?

While new agile application development seems to be addressing this more readily – especially in the new Internet-to-Everything and XXX-as-a-Service paradigm, that may not necessarily help in the migration of those handful of applications that are core to the business and been around for years. Get your application teams involved early and often. And be prepared for delays and push-backs.

Virtual-To-Virtual (V-2-V) Copies Rock, But Be Aware of the Constraints

If you’re lucky enough to have many of your applications on virtual infrastructures, and that means virtual in any and every sense, this is good news and really adds to the portfolio of options you have for migrations. I’m a big fan, especially when it comes to server virtualization, as V-2-V copies work well and really lessen the burden on both your IT and application teams – no reloads of OS, database, middleware, etc.

But as always, you need to understand the flip-side to all these benefits and plan accordingly. Let’s assume a straight-forward V-2-V copy/migration over a WAN to a new data center. To be considered:

  • Testing and validating needs to happen immediately after the migration, as the current-state server usually gets turned off post-migration. This level of effort and timing needs to be understood by the application and testing teams.
  • WAN transfer speeds must also be considered – especially for large data stores. If it’s over 300 GB, you may need to factor in V-2-Vs in days, not hours.
  • What’s the plan if a V-2-V “hiccups” during a migration?   Is it continue/re-start or start over? Those two are very different.
  • What’s the impact of parallelism? The plan may look great for 25 or 40 V-2-Vs over a weekend because each of the servers have 100 GB or less. But migrate them all together, and now those terabytes of data transfers just melted your WAN. And your schedule.

These are  just a few of the migration activities that proper planning can help to mitigate risk, properly gauge the true level of effort, and help your company successfully migrate according to plan. And finally, with all this said, start putting more effort into your migration plans, but also ensure you don’t lose sight of “A good plan today is better than a perfect plan tomorrow.”

Industry Perspectives is a content channel at Data Center Knowledge highlighting thought leadership in the data center arena. See our guidelines and submission process for information on participating. View previously published Industry Perspectives in our Knowledge Library.

Add Your Comments

  • (will not be published)

One Comment

  1. These are great insights, Bill. From my experience it is often not the WAN, or even the LAN that provides one of the biggest constraints, but all the way back to the server network card. If you're interested in discussing further, give me a call!