One of the most common discussions I have with prospects when discussing the scale and scope of their virtualized infrastructure, is the continual attempt to leverage a higher percentage of virtualized workloads. However, the question of which workloads to virtualize, and when, isn’t always the easiest to answer. Sure, there are many low-resource demands, small footprint applications that are easy to virtualize, but there are others that organizations are hesitant to even consider virtualizing. The conversation oftentimes goes something like this, “We are roughly 70% virtualized, which includes the majority of our web servers, file and print servers, and most application servers. Our databases, however, have remained physical.”
Well, why? What makes database servers so difficult, or scary, to virtualize? Well first and foremost, production database workloads can support many different applications, spread across multiple segments of an organization. Secondly, databases can often have very large footprints, and provide poor visibility for administrators to see what is the actual resource utilization of the database server. So until recently, the only choice has been to allocate more resources than necessary to these mission-critical workloads that support the business.
Extending the VMTurbo’s Market Abstraction to MySQL Database Servers
With VMTurbo’s 5.3 release, MySQL databases are now supported, adding another proof point to our mission of controlling any workload on any infrastructure at any time, anywhere. Our market abstractions make real-time control possible, preventing problems instead of reacting to them. Here’s how…
VMTurbo has the ability to target your virtual SQL, Oracle, and now, MySQL database servers, and even scope to a specific part of your infrastructure to find instances of these workloads.
By pulling in database specific metrics, VMTurbo can make intelligent recommendations to prevent resource contention points from ever occurring in the first place.
When you provide a database server as a target, VMTurbo discovers and manages the following resources:
- Transactions per second
- Response time
- Database Memory
- Storage devoted to Transaction Logs
VMTurbo’s market abstraction dictates that database server must sell Quality of Service (measured as transactions per second or response time) to the business, in order to earn revenue to buy resources (Database Memory, Connections, and Storage devoted to Transaction Logs) from the VM.
Likewise, VMs must sell resources to the applications they support in order to buy resources from the underlying infrastructure (host, network, storage, etc.). VMs, in this case, will resize vMEM and vCPU to ensure that its database servers run performantly.
As such, if DB Memory or connection capacity should be proactively resized to prevent a congestion point, VMTurbo will provide the appropriate recommendation to do so:
Reap the Full Benefits of Virtualized Database Server Workloads
It allows administrators to not only confidently manage, but control database instances, reaping the full benefits of virtualizing these workloads. Again, VMTurbo has the ability to define specific quality of service (QoS) targets, such as response time, transactions capacity, connection capacity, etc. For MySQL specifically, VMTurbo also takes into account the buffer pool hit rate, which is critical in managing actual memory usage, and preventing waste:
By extending control to MySQL, VMTurbo now supports three of the most popular database servers (SQL, MySQL, and Oracle), with NoSQL and Hadoop on the roadmap for the near future. Gaining a hook into the database server itself allows VMTurbo customers to scale DB instances at the speed of software, or increase efficiency to avoid excess licensing costs by staying as consolidated as possible. Database servers no longer need to be black boxes or resource hogs. With the VMTurbo platform they are merely another workload that can be controlled on any infrastructure at any time, anywhere.