Man this has been a busy couple months. I have a whole different blog post about VMworld and the MADNESS. But suffice to say I have been busy. So busy in fact that I didn’t really have time to work on the new Celerra UBER VSA until this week. Which also happens to be a week vacation for me.
Now for a normal 9-5 kind of guy, working a little bit on your vacation is ok. Some people frown, some people smile and approve. But, on the vSpecialists this is a big "no-no". So because of my strong desire to get this awesome piece of virtual goodness in your hands I have risked the smack down from my teammates and managers for working on it during my vacation. I shall likely be banned from a console for a bit so remember me when you are checking out the UBER cool new Unisphere interface.
And so I am excited to announce the release of the Celerra UBER VSA version 3.
I got quite a bit of new features as well as the new code/management interface you have been hearing about. Here is the list of changes and additions:
- DART is now 188.8.131.52
- Unisphere management console (rocks!)
- The Celerra VSA is now 64 bit! This means you can throw RAM at it for bigger setups and it will use it. Over 8GB becomes less beneficial without code changes to simulation services. Future updates will fix this from the Celerra VSA engineering teams.
- The biggest and most difficult change to construct is that the configuration is now adaptive depending on the virtual machine setup. This version is now intelligent in seeing how many resources you have given it.
- The new Celerra UBER VSA uses this intelligence to now allow *Thin* mode. If you give the VSA under 2GB of RAM it will automatically size the memory limits, processes, and management interface settings to allow it to run with as low as 1024MB of RAM. You won’t do replication or host a ton of VM’s but you can use this mode to host a few and fully demonstrate/test the new Unisphere interface on even a 2GB laptop.
- The new VSA also uses this intelligence to automatically allow the configuration of single or dual Data Mover version based on the memory assigned. If you give the VSA more than 4GB of memory you will be given the option to enable an additional Data Mover for use as a standby or load balancing experimentation. This means this single appliance can be a small lightweight NFS unit at 1024MB of RAM or can be a 2 Data Mover powerhouse at 8GB of RAM. All automatically configured on first boot through the wizard.
- Automatic VMDK/Storage additions have been adjusted for new 64 bit OS. This means this still works. Shutoff the VM, add VMDK(s), turn on and you have more space. Automagic
- Since automagic is so cool, I have changed the Data Mover Ethernet binding to be automatic also. The VM starts with 1 interface for management and 1 interface for the Data Movers. If you want more for the DM(s), just shutoff the VM, add NIC cards (up to 6 additional), and turn back on. It will automatically bind the Data Mover (yes it works with the 2 DM mode also) to the new interfaces and virtual slots. Just go back into Unisphere and assign away. This allows scale up for the bigger 2 Data Mover 8GB of RAM versions easily.
- Configuration is now Perl/Bash based instead of just Bash to keep things cleaner and slicker and allow for some coolness later on 😉
- NTP from the configuration portion of the wizard works correctly. It sets both the Control Station and all Data Movers and enables NTP as a running service. Make sure your NTP server is valid.
So let’s summarize:
- New Unisphere
- 64 Bit
- Automatic sizing
- Thin Mode
- Optional 2 Data Mover mode
- Automatic Data Mover Ethernet adding (along with fixed Storage [VMDK] adding)
- NTP works now
Just my opinion but this my favorite version yet. Even without one single piece of my code this version is faster than the last.
Couple things to note:
Adding an extra Data Mover can extend the setup time up to 5-10 minutes depending on your hardware. I will speed this up in the future but for now this is a one-time penalty for being Data Mover greedy. Also remember to give it the extra RAM/vCPU before turning it on the first time.
You cannot change the number of Data Movers without redeploying a new version. Once it is born with two heads it stays that way. Same thing with the Thin mode. Once it is deployed Thin, adding more RAM will not refactor the VSA.
Thin mode (< 2GB of RAM) will still incur some mild swapping the closer to 1024MB you get. If you have a laptop with an SSD putting the first drive on it will almost completely negate any noticeable slowdown with mild loads.
From now on Eth0 is the management interface. This corresponds to NIC1 in your VM. Every other interface after is for the Data Movers and will start at CGE0 and increment. So NIC2 is Eth1 is CGE0 (per DM) inside Unisphere and NIC3 is Eth3 is CGE1 inside Unisphere. Pretty easy…
Now that this is 64 bit you can no longer run it inside a virtual ESX(i) inside Workstation 7. It has to be run directly on ESX(i) or Workstation 7.
Now get to downloading… (***UPDATE links below are the updated 3.2 version fixing 3.0/3.1 bugs. ****) – LINK
Ton of work, ton of lost brain cells so pretty please comment and provide feedback. I am releasing videos on how to configure very soon and maybe a surprise or two. If there is something you would like to see please leave it in the comments below.