scroll direction
state 0 0

5 reasons you should switch storage

Fact: if more than 50 percent of your data center’s applications are virtualized, you need VM-aware storage.

Fact: if you’re on LUNs and volumes, your storage is not VM-aware storage.

Fact: if you have virtualized applications, but they’re running on LUNs or volumes, you should switch storage.

Run through just five questions with us and see if your storage is up to snuff. Because if it isn’t, then your virtualized applications won’t be, either.

KEY TAKEAWAYS
Only VM-aware storage can find and solve the root cause of latency, set QoS per VM, and replicate individual VMs.
Conventional storage wastes time and energy, whether it's with "real-time analytics" that are actually correlation-based, or waiting for entire LUNs to backup from recovery.
It may sound unbelievable, but VM-aware storage makes things so easy, you can do things like replicate VMs in just a few clicks.

Do you have real-time, VM-level analytics?

Our distinguished competition often claims that their physical storage offers “real-time analytics,” which means it takes a real-ly long time for those analytics to show up. And you can forget about VM-level analytics—with physical storage, you get averages and aggregates, so if you have 200 VMs, you only see the average performance for all 200 VMs, rather than performance per VM.

That’s like saying the average net worth of people in a room is a million bucks, just because Bill Gates stopped by

Can you operate on the VM level?

Say you want to replicate a VM on your physical storage array. You can! But you also have to replicate all the other VMs on the same LUN or volume. And snapshots? Hope you don’t mind snapshotting the rest of the volume, too. There’s no way around it—software-based storage operations are slow and storage-inefficient, and impact your host CPU and network negatively.

It’s like picking up your kid from school, only you have to pick up her entire class, too. You wouldn’t work on that level—why work on the array level? Go VM-aware to operate on the VM level.

Can you adjust QoS on the VM level?

Trying to manage quality of service on your conventional array is like trying to manage a thousand cars on the highway. It’s first-in, first-out—an I/O traffic jam that precludes micromanagement.

VM-level storage lets you queue per VM and per vDisk—and shows you visual guidance on how and when to throttle IOPS for each individual VM. Plus, you can establish service level tiers and guarantee performance to your customers. You get immediate feedback on latency and contention impact, without waiting for a car accident to happen.

Can you automate your operations on the VM level?

“I don’t mind the average-based, hour-late analytics, and I love waiting for entire LUNs to backup from recovery!” … said no one ever. Look, if your storage isn’t VM-aware, you’re spending a lot of time doing manual labor. Just compare your methods for something as simple as setting VM1 to replicate to Site2 every hour:

If you’re interested in virtualization and cloud, it’s no contest: you want to operate at the VM level. VMs are your units of management, and they’re the units your customers consume. Working on LUNs and volumes with traditional storage management wastes your time. And time is money.

Do you have a VM-level filesystem?

Don’t believe everything you read—while hyperconverged and VVol can hide the complexities of your (decidedly non-VM-level) filesystem, they still run on LUNs and volumes. That means they work under the same limits you’ve always labored under—whether that’s noisy neighbors and contention or just the inherent unpredictability of conventional storage.

VM-aware storage has a VM-level filesystem. It doesn’t just list VMs and VMDKs—it sees them and is able to manage them individually. It isn’t optimized for LUNs or volumes—it’s optimized for VMs and offers predictable VM performance. It doesn’t schedule I/O at a LUN or volume level—it schedules I/O at a VM-level, with VM-level isolation.