Performance Folks, Look What I Found! - Vdbench

Hi Friends,

I wanted to share with you a cool new performance testing tool I found.  As you may know I'm a big fan of IOmeter, it's easy to install, simple to use and gives good results.  But there were always a few things I wish it did.  For instance, what if I wanted to test compression ratio and deduplication capabilities on an array?  Also, IOmeter is great if you want to do a fire hose data blasting, but what if I want to set the IO rate?  How about writing and reading to raw devices vs. something that already has a file system on it?

I give you Vdbench.  Click on the Vdbench link to get it from the Oracle website.  It's a text based tool that is very easy to set up and has a TON of options to it.  It has so many options that I have just barely scratched the surface.  I'm doing some Windows filesystem testing right now, so I thought I would share some of the configurations I'm using to test the performance on my Nimble array.

So first off, after you download the tool, you need to install it.  How do you do that?  Unzip it.  That's it.  That's it?!  Yep, that's it.  What's great is you can run it on Windows, Unix, Linux, Mac, etc.  So you don't have to have different tools for different operating systems, pretty cool right?

Yeah, I was pretty surprised too!

Like I said earlier, you can write to a filesystem or to the raw device which is pretty cool.  In the following example I created three drives, put NTFS on them and I'm varying the IO rate.

compratio=2.0,dedupratio=5,dedupunit=4k
sd=sd1,lun=n:\test1.txt,threads=32,size=50g
sd=sd2,lun=o:\test2.txt,threads=32,size=50g
sd=sd3,lun=p:\test3.txt,threads=32,size=50g
wd=wd1,sd=(sd1,sd2,sd3),xfersize=4k,rdpct=25,seekpct=100,openflags=directio
rd=run1,wd=wd1,iorate=(250,500,750,1000,max),elapsed=600,interval=5

Okay, this is where I like IOmeter better since it has a GUI.  I know, boo, hiss, GUI's suck, but I've really grown to like GUI's.  :-)  

Yeah yeah, laugh it up!  :-)


With Vdbench everything is CLI, so get your propeller hats on!  You create a configuration file and when you run Vdbench you reference that file, like the one I have above.  Let me break it down for you.

1.  compratio=2.0,dedupratio=5,dedupunit=4k
By default Vdbench writes non-compressible, non dedupable data.  Normally that's fine, but what if you want to test the compression and deduplication capabilities of your array?  Well that's where this line comes in.  Here I've got a compression ratio of 2:1, a dedupe ratio of 5:1 and the size of the data block that dedup tries to match with existing data, here I'm using 4k.

2.  sd=sd1,lun=n:\test1.txt,threads=32,size=50g
     sd=sd2,lun=o:\test2.txt,threads=32,size=50g
     sd=sd3,lun=p:\test3.txt,threads=32,size=50g
SD is your Storage Definition.  This can be either physical, logical, or a file system.  Here I'm pointing to a drive that already has a file system on it and telling Vdbench to create a 50gig file on each drive with a maximum concurrent I/O of 32 to each SD.

3.  wd=wd1,sd=(sd1,sd2,sd3),xfersize=4k,rdpct=25,seekpct=100,openflags=directio
WD is your workload definition and you just need to specify a variable since you can run multiple things with Vdbench.  Here I only have one workload.  I'm calling my storage devices with SD, my blocksize is 4k, I'm selecting a 25% read and 75% write workload, 100% random seek and using direct IO and no buffering.

4.   rd=run1,wd=wd1,iorate=(250,500,750,1000,max),elapsed=600,interval=5
RD is your run definition and you specify a name, similar to the above two variables.  Here I'm calling my workload definition 1.  Now this is really neat.  Here I'm specifying my IOPs and I'm selecting a varied run.  First I start out at 250, then step up to 500, next 750, 1000 and finally turn the fire hose on at full blast to see what the array can do at full throttle.  The neat thing about this is if you want to see how your array performs with specific IOPs you can.  Okay, **I** think its cool...  Next I'm running for a total of 600 seconds and reporting back to the screen every 5 seconds.

As I said earlier, I'm just scratching the surface of the tool and there's a TON more you can do with it.

As I learn more about the tool and run more performance tests I'll share it with you!

Until Next Time!
-Brain

Cleaning Up Replicas, Virtual Desktops, Composer & ADAM Databases, AHHHH!!

Hi Friends,

I'm doing a bunch of testing with VMware Horizon with View using Linked Clones and I'm creating, deleting, creating, deleting, creating, deleting, well, you get the point.  Inevitably with so much creating and deleting I get stuck desktops....  What is a "stuck" desktop?  Well, it's a desktop that you tell Horizon do delete and it thinks and thinks and thinks, but no deleting happens.  Lousy rotten clone, I'll show you who's boss!!!

So I go into vCenter right click those suckers and delete them!  Ha Ha!  I'm the boss of you clones!!

But my smug demeanor is rapidly deflated when I go back into Horizon and see the desktops are still stuck at "deleting" as well as "missing".  ARGH!!!

AND.... I have a Linked Clone Replica(s) stuck in vCenter.  I think those are protected from removal or deletion by vCenter.  So, you not only have desktops stuck in purgatory, but you also have a replica(s) that can't be removed either.

Okay, so what the heck to do you do?  Well, there's lots of articles on the Internet, and there's different approaches.  The first thing is you have to do is determine is this production, or is this an environment that can be trashed a little or a lot?  Since I'm working in a lab environment, I can trash it, but I'd hate to have to rebuild EVERYTHING!!  So I thought I'd show you how to clean up your environment if it's NOT production.

WARNING - I suggest taking a backup before you try any of this as it IS destructive.  If you destroy your environment, I'm not responsible, so please don't blame me!! 

WARNING - Remember, these procedures are NOT for production, and if this is dev/test, but you've got lots of stuff you want to keep in your Composer database, move along, this is not the solution you're looking for....

Okay, so you've got a bit of a mess on your hands.  You've got a bunch of "deleting(missing)" desktops, replica(s) that won't go away and you just wish it would all go away.  Maybe into a cornfield??

Like I said, there's lots of articles out there, but I wanted to show you a destructive way to clean everything up so you can get moving quickly if you don't have anything worth saving.

1.  Clean up your ADAM database to get rid of the "deleting(missing)" desktops in Horizon.

This step is pretty easy.  Follow this VMware KB to open your ADAM database on your Horizon with View Connection Server.  This is the server that has the Horizon web administrative tool on it.  The only thing to watch out for is if you're using Remote Desktop. I had trouble connecting to the ADAM database using domain administrator and Remote Desktop.  The article tells you to use a user with elevated privileges, but it didn't work for me, so I consoled into the server using vCenter and that worked. Use the first part of this VMware KB to find and delete the desktops in the ADAM database once it's been opened.


2.  Clean the View Composer Database.

All those "deleting(missing)" desktops are gone!  You're good to go right?  Not so fast Mr.!  The Composer database still has all of those desktop references in it.

There's another section in that last KB about cleaning up your Composer database and I'd recommend following it if this is not a dev/test environment that you can trash.

So here's what I do.  Log onto your Composer server and de-install Composer.  Next log onto your SQL Server that has your Composer database and delete that database.  I told you this is destructive!!

3.  Get rid of the replica(s) from vCenter.

Okay, another method that I don't recommend if this is not a sandbox environment.  Log into vCenter and browse the datastores that the Linked Clones and replica(s) are using.  Delete all of the Linked Clone and replica folders of the machines you want to get rid of.  Don't just delete everything!  :-)

You'll notice you can't remove or delete the replica from inside vCenter, so we have to go to the ESXi server the replica(s) lives on.

Find out what ESXi server the replica is living on and log into the GUI of that ESXi server.

You'll notice from here you CAN remove the replica now.  HURRAY!

Remove the replica from inventory, but you'll notice it's STILL in vCenter and listed as orphaned.  Never fear, we'll get rid of that sucker!  Go back to vCenter, put the ESXi server into maintenance mode, disconnect and remove it from inventory.  Wo, wo, wo wo!!!  Isn't this a bit extreme?  Yes, yes it is.  But remember this is a quick and dirty way to get rid of the replica(s).  Add the ESXi server back into inventory, exit maintenance mode and you'll notice the replica is gone!!  Is this the best way to get rid of replicas?  Probably not, and I'm guessing it's not a best practice from VMware either so use at your own risk.  Big thanks to mwpreston.net for demonstrating this method of removing stuck replicas.

4.  Create your Composer Database.
If you remember we deleted our Composer Database earlier and it's time to create a new one.  I suggest using the same name so you don't have to change ODBC connections.  Give it the same permissions it had before too.

5.  Re-install Composer.
Go back to your Composer machine and make sure your ODBC connection still works.  When you're sure the connection is good, re-install Composer and point to the newly created database with the same name.

6.  Some last cleanup.
We're good now right?  Well....  Maybe....  I've had some trouble with the Composer connection in the VMware Horizon View Administrator tool after I've de-installed and re-installed.  The secure certificates didn't want to work anymore and the connection from the administrator tool wouldn't connect to Composer anymore.  I think this is because I de-installed and re-installed Composer, but who knows for sure.  :-)

The easiest thing is to go into the View Configuration > Servers and delete your vCenter Server connection from inside the View Administrator.  When you re-add it, add your Composer again and it should connect okay now.  Remember to make sure the Domain connection is working too when you add your Composer connections.  You'll probably have to re-enter it when you click on the Verify Server Information button.

Well that should do it.  Everything should be working and you've got a crisp clean Composer database.

-Until Next Time
Brain