Know Your Virtual Workloads: Block Size & Workload Shift

To properly design and optimize your data center, it's important to understand various workload characteristics, how they change over time, and how they impact application performance. I've identified the top six things you should know about your virtualized workloads.

In my last post, I looked at two characteristics of your VMs that are traditionally overlooked in the data center: the different effects that reads and writes have on VMs, and how different access patterns impact performance. Failure to recognize and appropriately measure these things can adversely impact application performance and lead to high IT costs.

In this post, I'll address two other characteristics that are equally important: block sizes and workloads.

#3: Block size matters

In the quest to hunt down and resolve VM performance issues, administrators often require metrics related to CPU, memory, and storage. However, this data can be difficult to get in a virtual infrastructure. Block sizes are a prime example of a metric that has a dramatic impact on storage performance, and varies heavily based on application, OS, and workload. Yet, it is largely invisible to common management systems. This lack of visibility is one of the key reasons why block sizes are misunderstood and overlooked by virtualization, network, and storage administrators alike.

In the context of storage I/O, a block is simply a chunk of data in the form of a single unit, transmitted in a data stream. Block “size” refers to the payload size of a single unit, whether it be a read or a write. Throughput is the result of the I/Os per second (IOPS) and the block size for each I/O being sent or received. Applications, and the operating systems they run on, generate a wide, ever-changing mix of block sizes based on the characteristics of the application and the workloads being serviced. Reads and writes are often delivered using different block sizes as well.

Because block sizes have different effects on storage systems, visibility into this metric is critical. For instance, a 256K block has 64 times the payload of a 4K block, and takes substantially more effort for every component of the storage stack to satisfy the I/O request. The storage fabric, the protocol, the processing overhead on the HBAs, the switches, the storage controllers, and the storage media are all affected. With the adoption of flash in the data center, visibility into block sizes is more important than ever, since flash can often struggle with larger block sizes.

Traditional management tools for the hypervisor, such as vCenter, do not expose this type of data. Monitoring tools that hook into vCenter statistics cannot see this data, either. Storage arrays might be able to provide some limited understanding of block sizes, but the information is often oversimplified, limiting its use. For a truly prescriptive approach to storage design, optimization, and troubleshooting, one needs proper visibility to block sizes across the entire data center, yet at a granular enough level to understand the nature of individual workloads.

#4: Workloads are constantly shifting

Performance metrics are the window that provides visibility into how workloads are behaving. The quality of the data provided to an administrator is the result of not only how it is measured, but how often it is measured. When we consider that most important metrics related to these systems are very dynamic and bursty in nature, the rate at which data is sampled becomes critical.

Let's take storage I/O latency as an example. Brief but recurring spikes of latency can impact all VMs that live on the infrastructure. An existing solution may not be able to properly illustrate those spikes because of lengthy polling intervals. Furthermore, when a solution assembles those data points across a timeline, it may average them out as it renders the data, devaluing the information even further.

These problems aren't be limited to analyzing latency. Perhaps you are trying to determine the peak IOPS of a single workload, or across an environment. If a solution only samples the data once every 5 or 10 minutes, how can it possibly capture those peaks that might be stifling the storage system? In data center infrastructures, milliseconds matter.

Workloads change constantly based on what the applications are being asked to do. Read requests versus write requests, access patterns, block size distributions, and data access frequency are just a few variables that fluctuate. All of these play a part in how capable your environment can satisfy the demands your VMs. An ideal solution would allow an administrator to properly see how these metrics are affecting the performance of the VM and the other VMs that live in the infrastructure.

In our next, and final part in this series, we will be looking at two more characteristics of your VMs that may very well be undermining your ability to deliver optimal performance of services in your environment. Stay tuned!