News Stay informed about the latest enterprise technology news and product updates.

Virtualized applications and storage don't always mesh

Legacy storage technology wasn't designed to support multiple virtualized applications competing for simultaneous I/O. Tintri's Dan Florea explains how to get from mess to mesh.

This is the first in a series of stories previewing sessions of importance to cloud application developers at the Cloud Expo conference, which takes place June 7 to 9 at the Javits Center in New York.

Dan Florea is a director of product management at Tintri, a maker of virtual machine storage for virtualized applications. He heads the Mountain View, Calif., company's OpenStack business. His session, "Bridging the Gap Between Cloud Applications and Storage," is scheduled for Tuesday, June 7 at 1:55 p.m. In it, he looks at virtualized clouds and the need for scalability and agility that conventional, volume-based storage systems were never designed to provide. He spoke with SearchCloudApplications about some of these issues.

How was storage defined before cloud and virtualized applications?

Dan Florea, director of product management at Tintri Dan Florea

Dan Florea: We started with applications being tied to a physical server. A database would run on its own physical server with direct-attached storage. Later, this was followed by a shareable storage area network. To share that storage, a logical unit number (LUN) would be allocated to each physical server. Each app was a physical server, and each server had access to its own storage; a one-to-one mapping of server to storage.

How do virtualized applications and cloud change storage allocation?

Florea: With virtualization and cloud -- and even worse with containers -- each physical server is broken up into multiple applications, where each virtual machine (VM) represents an application. All of those VMs are running on the same physical server. That breaks the LUN concept. Instead of each application getting access to its own physical storage space or a logical partition that belongs to that application, instead, you have VMs sharing that storage. Storage architecture worked well when apps were run one per physical server, but storage has not adapted to a world with VMs and containers.

What is the impact?

Florea: When you don't map VMs to their own storage, you run into the problem of the I/O blender effect [where simultaneous input/output requests from applications on multiple VMs are processed in a random and unpredictable way, leading to performance degradation]. If you have one server running two apps that share the same storage, the app that has a lot of I/O activity can block the other one. If you are running in a multistack, multi-tenant environment, one tenant could be running a database that is affecting other apps. The problem is that IT doesn't have tools to deal with this, and IT lacks visibility to see the situation at the VM level.

Developers will notice unpredictable app performance when running on a legacy storage device.
Dan Floreadirector of OpenStack product management, Tintri

How does OpenStack impact storage from a developer perspective?

Florea: In some ways, developers don't care about any of this. Their daily job is to create apps, maybe virtualized applications, and they are not going to care about what the underlying OpenStack driver is calling. But developers will notice unpredictable app performance when running on a legacy storage device. If you are running in [an] OpenStack multi-tenant environment, it could be some other tenant running a database application on that same shared storage; it could be impacting your application and you can't normally see that or have control. The underlying storage is not designed for a virtualized environment. Performance problems could be blamed on the application and the developer who created it, but that would not be correct.

What will you be demonstrating as an approach to this widespread problem?

Florea: Tintri has products to see all of this and manage it. Our mission is to make storage simpler. With virtualized applications, we move storage away from being structured around physical workloads. You plug in our appliance and assign the entire box to the OpenStack instance or VMware. Everything goes on that same storage device. There's no carving of LUNs and no tuning. The box takes care of all the performance guarantees.

Next Steps

Learn how the I/O blender effect causes storage woes

What tools are best for deploying virtualized apps?

Learn the five basics of LUN storage management

Dig Deeper on Cloud application development and deployment

PRO+

Content

Find more PRO+ content and other member only offers, here.

Join the conversation

1 comment

Send me notifications when other members comment.

By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy

Please create a username to comment.

How do you deal with performance problems created by the collision of virtualized applications and legacy storage architectures?
Cancel

-ADS BY GOOGLE

SearchAWS

TheServerSide

SearchFinancialApplications

SearchBusinessAnalytics

SearchCRM

SearchSalesforce

Close