So last time I showed you how to smoke your tires, flex your muscles, and grunt like a real man!
(Image borrowed from Google)
There's a time and place to strut your stuff, but well, unfortunately there's reality. I know, I know reality isn't as much fun as 0-60 times, but it's where most of us live. Most of the time we're more concerned with reliability, gas mileage and if there's a place to put the stroller.
In performance testing it's cool to show how fast your array can go, but what about day to day stuff? Are your customers going to be have to go get coffee, breakfast, go for a walk, and THAN be able to login into their desktop or are they going to be shocked how fast they can start working in the morning?
There's lots of really cool tools out there that can help simulate workload, but I'm a VDI guy so you're stuck reading about VDI. :-) This is a complicated system we're working on here. We've got our storage, compute, network, virtualization and application layers all to contend with. For those of you that know me, you know I love watches and clocks. Particularly mechanical pieces. There's so many little cogs, gears, springs and levers and they ALL have to be working or nothing works. It's crazy frustrating when things aren't working, but when they do it's a perfectly choreographed mechanical dance.
(Image borrowed from Google)
You can think of your VDI infrastructure in the same way. If something isn't appropriately sized or doesn't work quite right, the entire system may fail. Sizing is a blog for another day, but what about simulation? Before a watchmaker lets a piece leave his or her shop, they test the movement to make sure it runs AND keeps time. So how do we test our VDI environment to make sure it runs and will keep our users happy?
I'd like to introduce you to a very cool tool called Login VSI. This product does just that, it simulates users logging in, using their desktops, taking breaks, all sorts of great stuff! Let's take a brief tour of what this cool tool can do for you.
Login VSI works very closely with your AD environment. It creates a customized script for your environment, generates the number of users you want to simulate and does all of the tough AD stuff for you.
The Launchers are machines that act as well, launchers. From the management machine the launchers are connected too and begin calling up the VDI client software, simulating users logging into the environment.
Data servers are where your Login VSI bits lives. The cool thing is you install Login VSI in a Windows share, allowing easy access to the binaries, logs, etc.
Configure Scenario is very cool. This is where you select what kind of user workload you want run, how many, how long the whole process will take, etc.
Here I'm running 10 "knowledgeworker" profiles.
Configure connection is how and what you're connecting too. This is simulating a user launching some sort of client and logging into their desktop. It's quite cool to watch because you're not just logging into a desktop, programs are launched, emails and documents are typed and web sites are browsed. Here you can see the command line method to kick off a Horizon View client session and have users login.
You can customize like crazy or you can take the defaults. The end product is a score called the VSImax. Because VDI isn't just logins or steady state, Login VSI takes all of the variables and produces a number based upon response times, system saturation and the maximum active session/desktop capacity. Basically, it'll tell you how far you can push your environment. If you run a test and don't reach the VSImax, you know you still have resources to add more desktops and users to the scenario.
Enough yacking, let's kick one of these suckers off!
So here we've got a "knowledgeworker" workload with 100 desktops and 10 launchers to handle the connections.
Here we can see the 100 desktops working away. The cool thing is Login VSI simulates workload the way humans work. Most people don't work 8 hour straight, they work a bit, take a break, look at the web, work a bit, take lunch etc. So having a constant stream of the same IOPs wouldn't really be realistic. Here from the Nimble GUI you can see peaks and valleys of both read and write workloads being generated by the test. We've got low latency which will give our users the response time they demand and if you take a look at the last graph, most of the data is in cache which will speed up the user experience even more since transactions aren't having to go to spinning disks as often.
Okay, gotta show at least one burn out! The new 2015 Dodge, 707 horsepower, Challenger Hellcat! OH YEAH!!!
(Image borrowed from Google)
Reality can wait a little while!
Until Next Time!
-Brain
No comments:
Post a Comment