The modern data centre is a very different place from a decade or so ago. Rather than running one or two applications per box, its racks of servers are hosting entire virtual infrastructures as part of private or hybrid clouds. But that doesn’t mean you don’t need to understand the hardware you’re running to best target virtual machines and applications.
Most virtual machine management tools allow you to target VMs at specific hardware, so even if you are treating your data centre as a compute and storage fabric you can put the most demanding applications and services on appropriate systems. As infrastructure and applications continue to separate from each other, the role of the infrastructure operations team becomes more, not less, important.
So how do you get that picture of your hardware? Most benchmarking tools are focused on desktops, and where they do offer server support are not optimised for server workloads. You need to be sure that you’re getting the promised performance and that your hardware can meet the service-level agreements you have with the rest of the business. That becomes even more important when you’re rolling out technologies like Azure Stack HCI, which aims to offer cloud-like performance on off-the-shelf hardware.
Understanding storage performance
One of the most important components of a modern server is its storage. Bottlenecks here, either in read and write speeds or in available bandwidth, can severely impact applications. Users don’t want to wait for data to load, or for modal save dialogs to block them from getting on with work. Your SLAs depend on disk performance, on latency, throughput, and IOPs.
You’re probably familiar with CrystalDiskMark, a popular disk-benchmarking tool. It’s used to evaluate hardware, showing how both hard drives and SSDs handle different patterns of reads and writes. However, the patterns it uses are fixed, and while they give a good picture of how a disk might work in a consumer system, they cannot simulate more complex workloads, like those you might find in a virtual infrastructure running a series of different applications.
What most people don’t know, however, that under CrystalDiskMark’s smart graphical frontend is a Microsoft command line tool. DISKSPD is a free, open-source tool for benchmarking drives with a customisable set of workloads. It’s surprisingly configurable, with a set of command line options that allow you to build scripts that can run a series of tests on both desktop and server operating systems. With source code on GitHub, it’s possible to modify the code and build your own custom versions, perhaps as part of an automated hardware verification system to classify every new drive that comes into your business.
Unlike CrystalDiskMark, DISKSPD allows you to make your own synthetic workloads, simulating the reads and writes an application would make in normal operation (and allowing you to test heavy loads that might not occur regularly).
Getting started with DISKSPD
Getting started is easy enough; you can download DISKSPD from GitHub and set it up directly. Alternatively, Microsoft provides a set of instructions for installing it remotely using PowerShell — a useful alternative if you’re benchmarking a cluster of Windows Server Core systems that may not have a browser or a UI beyond a command line. This last option is a good one to use if you’re evaluating hardware that’s being used for Azure Stack HCI. Microsoft provides a single short URL that always points to the latest release version.
The DISKSPD file contains 64-bit, 32-bit, and ARM versions. In most cases you’ll want to use the 64-bit amd64 version, unless you’re working with an older server release. However, Microsoft’s modern server OS is 64-bit, just like desktop Windows 10.
SEE: The future of work: Tools and strategies for the digital workplace (free PDF) (TechRepublic)
Start by running DISKSPD from the Windows command line, either using the familiar cmd or the more modern PowerShell. There’s no installer, so either use the full path of the install directory to launch the tool, or navigate to it and run it from wherever it’s installed. DISPSPD has an impressive set of configuration parameters, so it’s well worth spending time with its GitHub documentation wiki.
Tests can be run against different targets — regular files, named partitions, or physical devices. In practice, it’s best to work with a target file to test how a disk works with an application. Alternatively, new drives can be tested before they’re partitioned and formatted using the physical device ID to get the drives’ raw behaviour. You can use a partition as a target, but it’s not recommended as you’re either testing it as if it were a raw drive or working with a filesystem, in which case the two other options are likely to be most appropriate.
Building and running DISKSPD tests
Building a test requires stringing together a selection of parameters. These make it an extremely powerful tool, and it’s well worth experimenting before you build and deploy a test. The default test is 10 seconds long, but you can adjust the duration, with warm-up time allowances as well as cool-downs for multi-system tests. DISKSPD has a lot of very low-level options — for example, managing both OS-level and hardware caching.
At the heart of a test is how files are created and written, such as testing random or sequential writes. You can even change the size of blocks being written, with the option to tune the percentage of writes versus reads, allowing you to simulate the expected balance of operations from your applications. Other options allow you to set processor affinity and the number of threads used, with threads working against different targets. You can provide your own test files, using sample outputs from your applications, or to automatically create samples. There’s even the option to use events to synchronise tests between different instances of DISKSPD, to simulate multiple applications running at the same time on the same hardware.
If you’re planning on building and running a complex series of tests, you don’t need to build separate command line calls. Instead, you can construct XML configuration files for each test, avoiding the risk of typos and errors. Microsoft provides hints and samples for various common workloads, including transactional operations and business analytics. You can use these to characterise the operations used by common line-of-business applications and apply the right tests for your planned suite of apps and services.
SEE: Hardware inventory policy (TechRepublic Premium)
Results are delivered in a text file, with per-thread and pre-target statistics. You can see the bytes written and read, the bandwidth used, and the IOPs of the tasks. There’s an option of seeing latency for reads and writes, as well as processor information. It’s worth using tools like Excel to process and display DISKSPD results, especially if you’re interested in getting a statistical analysis of the results from different types of write.
DSKSPD is a powerful tool, and much more capable than the familiar consumer-level CrystalDiskMark. However, like all powerful tools, getting the most out of it takes time. You need to be able to construct the right tests for your workload, interpreting the results to help design and deploy disk arrays and servers in a cluster or an Azure Stack HCI system. Detailed results like these allow you to show that hardware and infrastructure meets planned SLAs or if further investment is needed.
You’ll also be able to field any complaints from the application team, suggesting they examine their code rather than pointing the finger at your hardware!