May 17, 2012

Celerra VSA – UBER : Smaller, Faster, Easier, Geekier

**** Go here for new version of UBER VSA ****

Have you tried the EMC Celerra VSA before? If so, then forget everything you experienced. If not, then welcome and let me introduce you to easiest way to test enterprise-level features with NAS and virtualization.

I won’t go through the history or the advantages of the Celerra VSA because Chad Sakac does a much better job here, and here.

I am a greenhorn at the EMC vSpecialist team. I have just barely three notches on my belt (if notches represent months). So everything is new to me. I am constantly bothering my direct manager with questions like: “Why do we do that?” or “How did this come about?”. This is because I am looking at everything and trying to understand the why behind it all. And this is part of the reason I ended up diving under the hood of the Celerra VSA; to find out what made it tick and why it wouldn’t tick faster.

But first a quick background story: over the last month or so I have been doing my first tour of duty. I did my first customer presentation to a huge company (very near the top of the Fortune 500 list). I got involved in a proof of concept at another major client near Washington D.C. And I even got involved in helping design labs for VMware Tech Summit and major demos for EMCWorld (more on that after the big day). I have never been surrounded by such a quantity of talented (and cool) people or challenged like this before in my life. Needless to say I am loving every minute of it.

During this first tour I had the opportunity to install the Celerra VSA for the first time. And I will be honest: I was disappointed in it. I don’t like things that take so long. One of the reasons I write in so many scripting/development languages is because I hate repetition. So even before I started setting up my first VSA, I looked at the manual which, while VERY well-written, was way above my tolerance for length. Then and there I made it a personal goal to cut those steps down to as few as possible.

But, back to my first time to build…
An interesting thing happened the first time I did it. It was faster, way faster. In fact the Senior guy who I was assisting took a look to check my work and was sure they were broken. In his words: “It is too fast, it must not be actually doing anything.” But, after a little testing he confirmed that it was working perfectly and quickly. He asked me: “What did you do?”. I looked at him, blinked, and said: “I have no idea…”

I tend to venture off the beaten path in a lot of things. Evidently me skipping around trying to figure *why* each step needed to be done (for my future script) resulted in me fixing an issue. Problem was I had no earthly idea what I did or how.

So fast forward to now- I have spent the last good chunk of April figuring out the how and why of the Celerra VSA. I’ve not only figured out the speed tweak steps. But also I discovered memory improvements, boot speed improvements, and even finished a complete automation of the configuration process.

So in summary here are the new features of what I have dubbed the Celerra VSA –UBER Edition:

1. Completely automated install: On first boot a configuration wizard will ask a few questions and automatically reboot. On second boot everything is configured and ready to use. Also configuration takes care of ALL identity issues with generating MAC addresses. Average run through from first boot to complete is <2 minutes for me.

2. Much, much, much faster. You have to try it to see it. No, seriously it evens runs great on my Core Duo.

3. Low memory requirements: It will now run with 1024 MB of RAM (it is set this way by default). If you need to setup replication it may need more but will use much more efficiently.

4. You should not need to login to the console for anything. All configurations can be done through the Control Station web console (hint: Tools -> Wizards).

******* WARNING *******

Do NOT run a Celerra VSA on ESX on VMware Workstation. You will always get horrible performance this way. On a laptop or desktop use it directly on VMware Workstation 7 with the workstation version. On a server compatible with ESX(i) 4u1 use the OVA version.

************************

The Celerra VSA – Uber comes in two versions:

1.       Celerra VSA – UBER for ESX (OVA) (download link)

2.       Celerra VSA – UBER for Workstation/Fusion (ZIP) (download link)

I am not going to lie; this was at least 40-50 hours of late night work trying to reverse engineer something I never used as a customer. It was difficult and damaging to my ego in many spots. So I ask one simple favor from you. Try it out…

Obviously I think I made something pretty darn cool. But, what do you think? If you see an issue or have a suggestion please post a comment letting me know. I am curious what others notice and if they see the same improvements I do.

I hope this helps someone out in their labs somewhere. Please drop a comment if it does.

.nick

****** Update ******

Here is a video on the installation process:

New Utility: Domain Group Expiration Tool

Typically Active Directory is managed using th...
Image via Wikipedia

I wrote this tool out a of this simple request:  Why can’t a user’s membership to a domain group expire like their domain accounts can?

At my current employer we frequently need to grant temporary access for a few hours or days to resources.  However, this functionality is not built into Active Directory by default. The issue is that when you grant someone temporary membership to a group there is a real problem about removing that membership. Temporary access is based on a human element instead of an automated process.

As an example, what if your Director of Development comes to you and wants you to grant access to a individual. He/She needs this person to have VC access for group of VMware servers while another person is out sick. So you grant them access, a week goes by and you forget. Now you have an extra user with access they should not have.

But if when you added that user to the group, what if  you could assign a day and time when they lose that access? You could set and forget. This would eliminate auditing and having to keep reminders on these requests.

This tool is two parts. A PHP front-end that is used for submitting requests and a VBS script on the back-end for processing, logging, and alerting on requests. This tool provides the following:

  • Granularity on expiration down to the minute
  • Email alerts to requester and user-defined list (ISO, Managers, admins, etc) for processed additions and removals
  • Request form auto populates with users and groups from domain (no typing)
  • Uses DHTLM Calendar for Date/Time picking

Instructions for installation are found inside the README.
You can find the tool here: Domain Group Expiration Tool

dget

If you found this useful or have questions drop me an email or post your comments here.

Dell Server LCD Update Script

So here is the back story on this idea/script:

I was at my VMware Fast-track class in Dallas when the instructors mentioned an interesting story. They said they knew of a IT shop that had a pretty strict policy on labeling their servers.  That was fine and good pre-virtualization. But after moving to a VMotion-enabled VMware cluster they had the problem of their servers not matching their labels. So did they change the policy? Nope, they got magnetic labels and had an admin run down to the server room every time they used VMotion. True?  Maybe, but it got me thinking.

Why not use the front panel LCD on newer Dell servers to list what VM‘s are residing on the host? I pitched the idea to the instructors and they thought it was spiffy. A couple months later I have finally given it a shot. I debated whether to try and write this in C but opted to use Bash because it is easier to implement and I am so rusty at C it isn’t funny(and I should be spending those hours on Powershell).

To start off here are the prereqs:

  1. Dell OpenManage installed and running on the ESX host (needed for ipmi drivers)
  2. ipmitool 1.8.10 installed (SCP over, ./configure, make, make install….)
  3. My lcd_update.sh script

I wrote the script to only use what was available on the ESX 3.5 host(besides prereqs). I place mine in the /root folder and put “/root/lcd_update >> /dev/null &” into my /etc/rc.d/rc.local file to make it start on boot.
If you prefer you can just start it manually with nohup.

The script is pretty simple. It takes inventory of what VM’s are running and lists them on the LCD using IPMI. It keeps a semaphore file in /etc to keep track (index) of what VM it listed last. The Dell LCD can only display 14 characters (unless someone out there figured something else out) so if your VM name is longer it will be truncated. Overall the effect is pretty slick and with the way it is timed it appears to be a scrolling marquee of server names. Also, if you host has no VM’s or there is a problem with vmware-cmd it will just list the ESX hostname (it will trim a FQDN).

I am sure major improvements can be made to this and I am planning on writing one for server health and hosts in maintenance mode. This is more of a ‘can it be done’ utility and my first *public* script for something VMware related.

***Update*** v .2

I changed the script to use vmware-vim-cmd instead of vmware-cmd.  This should give a list of VM names instead of just taking the name from the VMX file (incase they don’t match). Kudos to Duncan Epping’s post @ Yellow-Bricks which gave me the idea.

***Update***

Scott(@DellTechCenter) from www.delltechcenter.com has posted a video of the output: http://www.youtube.com/watch?v=Slm3MDMD7Dc