Craft your data stores with VM storage performance in mind
Proper storage performance requires a systems approach. Discover the different elements at play, such as the queues, SCSI disks and ESXi hosts, and how to optimize your data stores.
Inadequate storage performance can affect the deployment and functionality of your applications, which can, in turn, affect the viability of the business those applications serve. With a clear understanding of how storage affects VM functionality, you can effectively design your data stores for maximum performance.
Performance design requires a systems approach. Various elements work together to deliver storage performance, and errors at any level can severely limit the achievable performance. As part of the vSphere team, you usually have control over VM virtual hardware configuration and the vSphere data store layout, but you don't often get to dictate the configuration of the application or the storage infrastructure.
You'll find queues at each level. Longer queues enable more throughput until it saturates an upstream queue. When you need high-performance storage, you should work closely with the storage team to design the platform from end to end.
Plan VM storage performance
Each virtual SCSI adapter in your VMs has a queue, and the system allows for up to four virtual adapters. Each SCSI adapter can have, at most, 15 SCSI disks attached, although they usually have only one or two. So how many disks and SCSI controllers should you use? That depends on your application requirements.
The boot disk goes on the first controller, and you typically use a second disk and SCSI controller for data. If your VM has modest storage performance, you can stop there and keep it simple with a single data disk. However, if you need high storage performance, then you should provision more disks and spread them across SCSI controllers. You can separate the database files from the log files just like you did on a physical server.
Design data stores with performance in mind
One data store is almost never enough; you usually need multiple data stores, but fewer than the number of VMs you have. Modest performance VMs can share a data store; you might put six to 12 modest VMs on a single data store, but just don't put all of one kind of VM on the same data store.
You'll be in a world of hurt if you keep all your Windows domain controllers on a single data store. The data store might become saturated and slow, and if you accidentally delete it, you won't have any of the necessary controllers left. Try not to place more than 12 VMs on a data store because they all share the queues and performance of the data store, and all of them will suffer if the queues become saturated.
Usually, VMs share data stores with other VMs, but high-performance VMs that need multiple disks and multiple SCSI controllers also need multiple data stores. In certain cases, a single critical VM will have its own data store and, on rare occasions, one VM might need multiple data stores.
ESXi hosts and storage performance
Performance is just as important as capacity when it comes to data store design on vSphere.
ESXi contains hundreds of thousands of IOPS per data store and around a million IOPS per ESXi server. Getting anywhere close to those numbers is beyond the scope of this discussion and would require working closely with your storage team.
You must tune the queue depths of ESXi storage controllers and the way that ESXi uses storage multi-pathing. If you have more moderate needs, a few tens of thousands of IOPS and default settings will probably be perfect. Make sure your ESXi server has some spare CPU capacity to serve those operations. Also, ensure that your storage network is fast enough -- 8 GB Fibre Channel or 10 GB Ethernet are usually the acceptable minimums.
Avoid excessive VM spread
Avoid having every VM spread across multiple data stores. This pattern creates data stores that hold only the boot disks, data stores with just disks for paging files, and data stores for the application data. Each VM uses at least one data store from each category, and every data store has a part of, for example, a couple dozen VMs. In this scenario, a single saturated data store affects every VM that uses it.
However, with that same couple dozen VMs, you can store about six VMs per data store, with every complete VM living inside one data store. This creates a much smaller blast radius for an overloaded data store.
Performance is just as important as capacity when it comes to data store design on vSphere. Managing storage performance always comes back to matching your application requirements with the infrastructure layers underneath the application.
