top of page
Search
Writer's pictureJoseph Noga

Prove me wrong!

Before cloud computing was mainstream, system engineers were required to plan compute, network and storage requirements for the system they were responsible for delivering. Engineers who have been in the game or have been burned, do not trust spec sheets or sales reps, so a validation process needs to be carried out prior to putting the equipment into service, as a CYA if you know what I mean. Of all the tools in my IT toolkit, I would always return to one tool in particular, why because like any well-built tool it makes the job much easier and expedient.


This tool developed by Microsoft is designed to stress the disk subsystem that will be serving as the storage to the computers connecting to it. The tool, JetStress, although initially meant for testing Microsoft Exchange environments provides a useful benchmark on the performance of the underlying disk system. JetStress mimics an Exchange database, by creating dummy databases across a number of servers and then carrying out various operations such as read, write, update and delete. This is nice for Exchange but what does this have to do with cloud computing? Well when you buy cloud resources and tiers of storage, you are “guaranteed” a specific level of IOPS (In / Out Operations per Second) and the only way to really see if you are getting the guaranteed IOPS is to run a tool to generate IO to the level you are paying for. Jetstress is configurable in a way where you can dial in the number of IOPS that are to be spread across a bank of test servers to validate the storage service level agreement.


Multiple test scenarios can be ran, but I typically pick a disk performance test, as this profile is a mix of read and write operations, reflective of what you will see in a production environment.

Once the test is finished, you are presented with an html report of the performance output, Perfmon counters and the peace of mind that the cloud providers disk subsystem will not be a bottleneck in your deployment. Contrarily if the subsystem is a bottleneck, the failed test parameters are highlighted in the report and can be used to help your cloud provider remedy the situation.


Now as time goes on and requirements change, you can rerun the test with the same or modified parameters to re validate your storage and make sure you are getting what you are paying for!


If a cloud provider claims they are giving you what you paid for and you do not feel the level of performance is up to your standard, by all means prove them wrong!


Stay well and as always if you would like to learn more about Komodo Cloud, please reach out and contact us!


Joseph Noga

CTO of Komodo Cloud

42 views0 comments

Recent Posts

See All

Comments


Commenting has been turned off.
bottom of page