Posted by mike on Sep 23, 2010 in VMware | 0 comments
So in my experience with the EVAs, I can say I have come across many challenges in finding good user experience documentation (outside of the normal pdf’s the HP machine churns out) and support. The HP forums have been somewhat helpful, but sifting through them, using their search or the googalizer, are less than user friendly. Good information at times to be had, but still overly difficult.
So it is with that preface that I arrive at discussing the SSSU: HP’s Storage Scripting System Utility. The premise of this utility is to allow command line access to an EVA. The idea is, at least from HP’s perspective, to use it for repetitious activities that would be otherwise tiresome in Command View. Additionally, you can also issue interactive commands like restarting a controller or changing mastership for disks between controllers manually. HP bundles the SSSU installer with Command View’s installer package. It carries the same versioning as Command View (so in my case, 9.1.0).
SSSU seems like a really great idea. I love the command line (being very partial to a bash shell 
), but SSSU isn’t a real CLI in that sense. The first round of trouble is in the output: SSSU generates XML based output that a human can’t simply open up and read. This throws out a simple way to grab information that would otherwise take a lot of time via CV. This posting is an overview of SSSU, and I will write a follow up post that goes more into depth on what you can do with the output to make it actually usable in conjunction with Microsoft’s Logparser tool. Sad I know. You can pony up big $ to get actual tools but hey, in tight times, stretching the imagination is better than stretching the wallet. I’ll also put up some of the scripts I use to gather data on disks and such (ex: easy way to track disk size and growth).
At this point, let’s get SSSU fired up and play around a bit. To launch, log into your CV server and run that fancy icon on the desktop. One quick gripe: no way for me to install this on my own laptop to just run and connect with. To get around that, I copy over from the CV install to my local machine the SSSU.exe file. It runs great and it’s just that less than 2 meg file. Upon launching it, you get to login.
You get three parts to a login:
You can login with a domain account without any issue, so you don’t have to create a whole separate user account list. One thing to note is that although you can fire up multiple SSSU windows to one array, you can only execute commands to it one at a time (serial baby!), so when one command is running in one window, your other windows would hang if you tried to execute a command).
After logging in, you are sitting at a default path, so to speak. That being that you have not selected your array.
Hitting ? and enter will list off all the commands available. This can also be used to find out what options each command has available.
Object names are case sensitive and are organized in a root tree system. Commands and objects with spaces in their names require double quotes. The first thing to do is select an EVA to work with, using the term select system.
You can flip around using the select system command. At this time there isn’t a way to issue group commands (outside of scripting, and even then it’s not a group command, in that sense).
Root Structure of Objects:
\Hosts
“\Disk Groups”
“\Virtual Disks”
\Hardware
Note that you can create objects (like folders) under all but \Hardware. Objects created are purely for human organization. The EVA doesn’t care if you have them or not (though if you do create them you need to be aware of the “path” to them.
A complete listing of the commands can be found in the SSSU reference doc, found here:
http://bizsupport1.austin.hp.com/bc/docs/support/SupportManual/c02493404/c02493404.pdf
This link is for the latest (I believe rolled into Command View 9.3) as of this date (9.23.2010).
My advice would be to look through the command reference to understand what the commands do. Listing them all out here in a blog post would be silly. And a lot of work, and I’m lazy, so….
As promised before, I will follow up this post with a more in-depth guide for where SSSU is handy and probably some more complaints on how it’s irritating. J
read more
Posted by mike on Aug 4, 2010 in VMware | 0 comments
Today I had the opportunity to attend the VMware seminar on virtualizing MS SQL and Exchange held in downtown Milwaukee at the Pfister Hotel. The topics covered an overview of some of what’s new in 4.1 (not really relevant, seemed a bit like filler?), then an overview of best practices for the esx(i) hosts in preparation for virtualizing Tier 1 MS apps (SQL and Exchange). This was then wrapped up by best practices and gotchas for SQL and Exchange.
Overall, and perhaps due to the time available, it felt like the presentation was a bit light in material. It did have some good insight into certain aspects of best practices for virtualization of each app, and did point us to the white papers / resource materials for further study. But it really was more like what you could get in a 2-3 page pdf attached to an email. When I asked a question regarding using two adapters and should they both be pvscsi (if the hosts supported such) or is there a specific use case for such, I was told “oh, yeah, use two adapters”. I felt like there was no interest in hearing my question, let alone even answering my question. Overall though the pdfs I pulled down are pretty useful and should be helpful as my company seems to understand that “it’s okay to virtualize when we move to Exchange 2010″. SQL is another battle entirely, but they’ll come around. The art of the food bribe is an essential part of my utility belt 
After the VMware presentation, Netapp (who was sponsoring this meeting) had an engineer or three onhand to give a general feature overview. It felt alot like the Compellent talk that was given at the recent Chicago VMUG. Brian and I were talking about this: we don’t really need a marketing effort by itself. Bring along a customer or two, one who will give both good and bad feedback regarding their product.
Bit of a side story: my company is allowing me to help guide them to purchasing a new dedicated VMware storage platform to get us off the icky EVAs. I’m eager as it’s basically going to be between Netapp and EMC. In fact we are being flown down by our VAR PDS to Netapp HQ for a meet and greet, plus executive briefing August 16-18. Maybe I’ll get lucky and meet Vaughn and get an autograph *laughs*
I’ll also be attending the VMware Support Day August 19th hosted by the Wisconsin VMUG. Looking forward to good conversation and copious amounts of pasta!
read more
Posted by mike on Jul 26, 2010 in VMware | 5 comments
The current issue I have come across in our HP storage environment is an issue with the storage controller cache battery modules. We had a module fail recently on one of our 8100 series EVAs. There can be up to four modules per controller. In our environment, we are using two modules per controller.
A healthy set of modules looks like this:
Now, for the EVA we have problems with, it looks like this:
This problem occurred after we had this particular module fail. We received a replacement from HP and swapped it out. However, after a few days, it was marked as failed again. Again we received a replacement from HP, and swapped it out. A few days later, same result. In contacting HP a third time, I explained what had occurred. In response, I received this notification:
This is just another somewhat oddball error that we deal with on a regular basis. Now, on to the fix! To restart the controller in question, first note as per Command View which controller is in question. In my case, it is Controller A (just follow the bang indicators)
A restart of the controller should be done during your change / maintenance window (all those years of ITIL ingrained in me!). To do so, you have a few choices.
The first is via Command View:
On the controller’s page, hit shutdown, then restart and the controller (A/B).
The second is via the SSSU utility (installs as part of the Command View install):
Restart controller A, but not its peer controller:
RESTART “\Hardware\Rack 1\Enclosure 7\Controller A” NOALL_PEERS
Note that when restarting the controller, if it is the master controller the vdisks will transfer to the other controller without any downtime. In my experience with the EVAs, they are a touchy lot. I prefer using the SSSU utility for a halfway decent command line interface. Pretty powerful too. I’ll be writing up a blog posting discussing good uses for SSSU in the future.
read more
Posted by mike on Jul 16, 2010 in VMware | 3 comments
So this is an error / issue we’ve had to live with for some time. It’s a bit strange to be sure. Essentially in Command View, the Disk Group occupancy is completely incorrect, and continues to grow. Yes, that’s right, I said grow. For some photo-visual enjoyment, here is what a NORMAL Disk Group looks like.
So as you can see, we have a total Capacity (which is correct and accurate), and the Occupancy. The information listed is correct, and it’s refreshing. Now, for the problematic Disk Group (and please ignore the name as it was before my time).
Here we see the correctly calculated Capacity, but lo! What’s this? What on earth is going on with that Occupancy? It seemingly continues to grow a bit here and there as we take snapshots of various. HP doesn’t know what’s wrong either. When we upgrade from Command View 9.0 to 9.1, it did not fix the issue either. The big problem here is that we have to figure out how much space is actually used since we’ll never get alerted. It is a pain. I can turn to Replication Solutions Manager to obtain the correct size by simply adding all the luns (easy way to view them, as opposed to Command View), so that’s the workaround. Not very satisfying if you consider how much money was spent on these beasts.
read more
Posted by mike on Jul 16, 2010 in VMware | 1 comment
This is a walkthrough for HP Command View for EVA. Part of my daily routine is to take a jaunt through CV, to check things over and look for alerts that I may not already be aware of.
Launched from the shortcut on the Windows host, or is accessible via a web browser at https://servername:2372
You are presented with the login screen:
It is here that you will also see the version number (down below). We have not yet upgraded this server to version 9.2 as we are building a VM to run Command View from and retire this physical box.
After login, you are greeted by the overview page. Here you will see all the EVAs listed, as well as the stats for your overall environment. The first thing of note is that two of my EVAs have bang lights on them, indicating something is amiss. I’ll investigate both as part of my next posting.
On the top right, there are some hyperlinks, your login id, and the ip of the Command View server. Most are self explanatory. Server Options provides for a place to enter license codes, setup RSM relationships, and a few other features. I seldom visit this page, so like once a year?
Moving right along, let’s take a look at a healthy EVA, in this case DS-SAN-2:
As you can see from the above, a healthy EVA has a number of folders beneath it. It breaks out into many subfolders. On the right hand side are the numbers. It would be here that you can get the logs for HP support (I’ll cover that in a separate blog post). You can see the current capacity level, view the Version level (this is the XCS code release running on the EVA. 6220 is the latest for the 8100 series). The left column is broken down like such:
Virtual Disks – this is where the luns (vdisks in EVA-speak) are listed. The folder structure is entirely man-made. That is to say, it’s for human organizational purposes (and plays an important role for setting up RSM jobs. More on that will be covered on a separate posting).
Hosts – here is where hosts are setup in Command View. You will provide the host’s OS, and it’s WWN’s for fiber cards. Hosts MUST be setup on every single EVA that you want to present disks from. Annoying, I know.
Disk Groups – these are comprised of physical disks. Best practice says to build these in multiples of 8, and of all the same speed and size. You can choose to not follow these and your performance will suck majorly. I’ve worked on rebuilding two of the 4 EVAs that had improperly constructed Disk Groups. It is PAINFUL to correct, but I’m glad I did. I will cover that also as a separate blog post. FYI: The ungrouped disks folder is for disks that have failed or been ungrouped on purpose. Ungrouping takes time as the EVA moves data from the drive to free it up to be removed or replaced.
Data Replication – it is here that you can create DR groups. This allows you to replicate (synchronous or asynchronously) between EVA arrays. A replication group is comprised of 1 or more vdisks. Sounding like a broken record, I will have a separate posting on replication.
Hardware – it is here that you can check out the status of the hardware. Both controllers are listed, as are all the disks. If there are hardware issues (per a bang light) then you can come here to find out why. The status of failed items is usually fairly straightforward and understandable as to what happened and what should be done.
read more
