Storage Performance Benchmarker 0.3 – DISKSPD option!

With this, I’m happy to announce the new release of the “Storage Performance Benchmarker“! The previous version was heavily relying on “SQLIO”, where this version offers you the ability to choose between “DISKSPD” (default) and “SQLIO”. The output will still be aggregated in the same manner towards the backend web interface, though the individual output locally will be in the format of the relative output.

Parameters added ;

• -TestMethod : Either “DISKSPD” or “SQLIO”, depending on your preference
• -TestWarmup : The warmup time used if you use “DISKSPD”

If you have any suggestions/comments, feel free to let me know!

TLC Nand : The demise of enterprise spinning disks?

Last week during the Dell Tech Summit I got the privilege of seeing the plans they have for the future in terms of storage. One of the aspects (which I am allowed to disclose) is the usage of the new “3D XPoint” / “TLC Nand” technology in their storage lines. The technology has a lot of potential when you take a deeper look at it… Here I must say, that when I take a look at the pricing range the products will be inserted, then I really wonder what the purpose of the 15k spinning disks will be. Even, if the technology will get optimized a bit further, which will result in price drops, then I even wonder if the 10k disks will also have entered the list of endangered species!

Eventually, it is my personal opinion that the 7,2k disks will become the mainstream storage for data that is infrequently accessed and that other data will be classified between several grades of SSD disks. This will mean that there will even be tiering between different classifications of SSD disks! Where the final resting location of the data will be the slow 7,2k spinning disks. And if more technology advances will be made that will make the SSD disks even more dense, than the ones I have currently seen in the roadmap, then we might even wonder if the spinning disks in general have become endangered (in enterprise context!).

Lingo Explained : Lombardi Time

Personally, I am someone who is always on time. A disaster must have struck down upon us before I am late to anything. I would rather sit in my car for an hour as I am way too early for a meeting, than to be a minute late. This week I learned that there is a term that follows the same belief!

Vince Lombardi was the head coach of Greenbay Packers. He ran a disciplined regime and introduced something that later became known as “Lombardi Time” ;

Lombardi expected his players and coaches to be 15 minutes early to meetings and practices. Not on time — 15 minutes early. If they weren’t, he considered them “late.” Thus, it came to be called Lombardi time.

A fun fact ; The clock above the entrance of the Greenbay Packers their stadium runs 15 minutes early… 
So next time we have a meeting together, show up on Lombardi time. I’ll be there!

Network virtualization ; Do I go for NVGRE or VXLAN with vNext?

With Windows 2016 / vNext the network virtualization has made a fundamental change… In 2012 Microsoft only supported its own NVGRE protocol. With the upcoming release, Microsoft will support both NVGRE and VXLAN! It even goes so far that VXLAN will be the default protocol. So in terms of VHS vs Betamax, we can conclude that Microsoft has decided that the market is more in favor of VXLAN.
  
What does that mean for organizations that have already implementee NVGRE? Both protocols will be supported by the typical Mellanox of Chelsio adapters in terms of translations. The HNV (Hyper-V Network Virtualization) will also support both simultaneously. Though if you are looking to start a new implementation, it is best to go for VXLAN now!

Windows Storage Performance Benchmarking : a predefined set of benchmarks & analytics!

Introduction
A while ago we were looking into a way to benchmark storage performance on Windows systems. This started out with the objective to see how Storage Spaces held up under certain configurations and eventually moved towards us benchmarking existing OnPremise workloads to Azure deployments. For this we created a wrapper script for SQLIO that was heavily based upon previous work from both Jose Baretto & Mikael Nystrom. Adaptations were made to make it a bit more clean in code and to have a back-end for visualization purposes. At this point, I feel that the tool has a certain level of maturity that it can be publically shared for everyone to use.

Storage Performance Benchmarker Script
The first component is the “Storage Performance Benchmarker Script“, which you can download from the following location ; https://bitbucket.org/kvaes/storage-performance-benchmarker

I won’t be quoting all the options/parameters, as the BitBucket page clearly describes this. By default it will do a “quick test” (-QuickTest true). This will trigger one run (with 16 outstanding IO) for four scenario’s ; LargeIO Read, SmallIO Read, LargeIO Write & SmallIO Write.

The difference between the “Read” & “Write” part will be clear I presume… 🙂 The difference between the “LargeIO” & “SmallIO” reside in the block size (8Kbyte for SmallIO, 512Kbyte for LargeIO) and the access method (Random for SmallIO & Sequential for LargeIO). The tests are foreseen to mimmick a typical database behaviour (SmallIO) and a large datastore / backup workload (LargeIO). When doing an “extended test” (-QuickTest false), a multitude of runs will be foreseen to benchmark different “Outstanding IO” scenario’s.

Website Backend
You can choose not to send the information (-TestShareBenchmarks false) and the information will not be sent to the backend server. Then you will only have the csv output, as the backend system is used to parse the information into charts for you ; Example.

By default, your information will be shown publically, though you can choose to have a private link (-Private true) and even have the link emailed to you (-Email you@domain.tld).

On the backend, you will have the option to see individual test scenarios (-TestScenario *identifying name*) and to compare all scenarios against each other.

For each benchmark scenario, you will see the following graphs ;

• MB/s : The throughput measured in MB/s. This is often the metric people know… Though be aware that the MB/s is realised by multiplying the IO/s times the block size. So the “SmallIO” test will show a smaller throughput compared to the “LargeIO”, though the processing power (IOPS or IO/s) of the “SmallIO” may sometimes be even better on certain systems.
  
• IO/S : This is the number of IOPS measured during the test. This provides you with an insight into the amount requests a system can handle concurrently. The higher the number, the better… To provide assistance, marker zones were added o indicate what other systems typically reach. This to provide you with an insight about what is to be expected or to which you can reference.
  
• Latency : This is the latency that was measured in milliseconds. Marker zones are added to this chart to indicate what is to be considered a healthy, risk or bad zone.
  

The X-axis will show the difference between different “Outstanding IO” situations ;

Number of outstanding I/O requests per thread. When attempting to determine the capacity of a given volume or set of volumes, start with a reasonable number for this and increase until disk saturation is reached (that is, latency starts to increase without an additional increase in throughput or IOPs). Common values for this are 8, 16, 32, 64, and 128. Keep in mind that this setting is the number of outstanding I/Os per thread. (Source)