0 0

Storage migration with VM Scale-Out: shrink hours to minutes

Storage migration with VM Scale-Out: shrink hours to minutes

Storage migration doesn't have to take hours. Slash all that wasted time with Tintri by offloading storage live migration.

  • KEY TAKEAWAYS
  • With traditional storage live migration, a.k.a. VMware Storage vMotion, storage migration is highly inefficient, taking hours to plan and migrate.
  • Tintri VM Scale-Out provides Tintri users with recommended actions and exact outcomes. All users have to do is hit "execute" to complete those actions.
  • With this release, you can use Tintri array offloading of storage live migration for both vSphere and Hyper-V.

You’re prepping for a new set of applications you need to support, so you're planning to migrate some VMs to a brand-new array you just bought for the capacity. The problem is, you don’t know which or how many VMs to migrate.

It’s not just the storage space your VMs use that’s important, but the performance they need as well. Some of these are 24x7 mission critical VMs—you can’t shut them down just to move them. Plus, you're using a conventional all-flash array with inline deduplication and compression: great for economics, not so much for moving VMs.

You could just move some VMs manually, but with traditional storage live migration (also known as VMware Storage vMotion), you need to consider:

  1. Which VMs should you move? You know you need to move a lot, but moving the right VMs could make hours or days of difference.
  2. How efficient can you be? Traditional storage vMotion involves the hypervisor host moving a lot of data. That can tie up CPU and memory on your servers and negatively impact production.
  3. How much data are you actually moving? Storage vMotion also reads every block in the logical VMs, even if the array is using deduplication and compression. So the amount of data that you need to move can be much larger than the space used on the array.
  4. How will this impact production? All that data needs to move across your storage network, taking resources away from production workloads
  5. What if the VMs are very busy with a high rate of data change? If the data changes anywhere close to the speed you can move, you'll end up spending even more time and moving even more data.

Seems inefficient, but it’s just the way we do things around here. What are a few hours of wasted time anyway?

Here at Tintri, we can offer a better way.

Plan with powerful machine learning insights

Let’s go back to the example I gave at the beginning of this post—except now, you’re on Tintri.

First, the fact that you needed that new array was no surprise. You’ve been anticipating it for months because you have a secret weapon: Tintri Analytics. Using the planning function, you simulated what the new applications would require regarding both capacity and performance.

The Tintri Analytics platform used millions of data points from real running applications in your environment. Then, with powerful machine learning algorithms powered by Elasticsearch, Apache Spark, and Amazon Machine Learning, it predicted up to 18 months into the future the needs of your applications.

You also factored in the growth of your existing applications, as well as arrays that need to be retired when they come off lease. Then, you let your CIO know with months to spare exactly what to budget.

With that, you made sure that 1) the perfect amount of Tintri all-flash storage would be ready before you deployed your applications, and 2) you had the data to back it up. Well done.

Showtime

You add the new array to your storage pool, and Tintri VM Scale-Out recommends you migrate some VMs to take advantage of the new capacity. You start deploying your new workloads and VM Scale-Out recommends more migrations, based on the historical performance of your applications and arrays. After approving the actions and outcomes of the recommendations, you hit “Execute.”

That starts Tintri’s storage migration process. Now, in our first story, this could have taken hours or even days. Your VMs would have had to be read in full logical size through the storage network, into and out of the hypervisor host, and then copied back in full to the new destination, even if the deduped and compressed VMs on the array was only 1/10 the logical size.

But with this release, you’re using Tintri array offloading of storage live migration for both vSphere and Hyper-V. Instead of moving an entire un-deduped and compressed disk twice through your storage network, the data moves straight from Tintri array to Tintri array, maintaining dedupe and compression with zero impact on the hypervisor host.

If you’re like most of our customers, you’ll experience 10X-30X dedupe and compression savings: a 90% data reduction, reducing hours and days to minutes. And all you had to do was hit “Execute.”

All done

I’ll be the first to admit that everyone says their product saves you time and money. After all, that’s what new technology is supposed to do. But with Tintri’s VM Scale-Out and array offloading, saving time and money isn’t a side effect: it’s the whole point.

You’re busy, and your business is booming. So today’s launch is all about respecting your business: slashing hours off your day so you can do the work that matters.

Raring to go? Check out our other launch blogs. Then ask your Tintri rep for a demo, or contact us directly. We promise to respect your time.

Chuck Dubuque / Aug 16, 2017

Chuck Dubuque joined Tintri in 2014. Prior to that, he was at Red Hat, where as director of product marketing f...more

Temporary_css