Top 10 things all new Simplivity admins must know

Simplivity_logo

First off, PLEASE don’t take these as a negative view toward the product. That is not the intent here.  These are simply some things I have learned that I feel should be shared.   Simplivity has become the fastest growing infrastructure company to achieve a valuation of over $1 Billion, EVER.   And I really am blown away by their product.  There is still no better or cheaper way to give yourself a hyper-converged infrastructure. I will leave all that for a more thorough review later.  But based on my experience, these are things you need to know if you’re thinking making the plunge in to Simplivity.

–Update:
I replaced an item on the list regarding advertised usable memory.  Simplivity has fixed this.

  1. Use the Simplivity tab in the vSphere client for correct datastore usage stats. The hosts see the raw capacity of the disks, not the capacity of the datastore.  This actually makes sense considering the host is also a node in the datastore, but will cause some initial confusion.
  2. The OmniCubes CAN be put in to maintenance mode, but… If vMotion and DRS are enabled, the VMs WILL evacuate.  All except for the OVC.  You MUST shut down the OVC VM prior to entering maintenance mode.  It will yell at you for doing so,  warning that you shouldn’t shut it down, but that’s the only way.
  3. The vCenter appliance is NOT supported.  This is probably to be expected with all their customizations.  There are APIs missing from the appliance that Simplivity needs.
  4. vCenter MUST be run outside of the OmniCube Federation.  The shared storage requires a witness or the Arbiter.  And because of SSO, you might want to also run your domain controller outside of the federation.
  5. Do not install vCenter using the Simple Install.  Take the time and install it correctly.  A simple install will prevent the use of Linked Mode.
  6. Understand the difference between a VMware Clone and a Simplivity Clone. With a VMware clone, VMware is copying the files, while Simplivity simply modifies the metadata for the data blocks.  The VMware clone is still your only way to clone to other (non-omnicube) datastores and your only way to customize during the clone.
  7. You don’t need a 10Gb switch if you only have two OmniCubes.  You can directly connect two cubes at 10Gb.
  8. You must use the vSphere thick client to manage the Simplivity stuff.   Those of you who want to use the web client exclusively like VMware recommends, can’t.  The Simplivity plugin only works with the thick client.  This hasn’t changed in vSphere 6.0 though they say it’s coming.  
  9. Come up with a plan to back up your data OFF of the federation. Simplivity calls what they have “backups.”  Yes you can back up your data and restore it if needed.  All it’s doing is adding a little more meta data to those de-duped bits.  And it backs it up to itself.  Not so cool if your entire federation goes up in smoke or those deduped bits get corrupted.  This can be great in larger geographically separated federations. Then it’s awesome.   But even then think of it as more of a belt and suspenders approach.  Use your usual backup tools, Veeam or CLI scripts to get that data off the OmniCubes.
  10. Upgrades…  They still haven’t refined their upgrade process.  Upgrading from vSphere 5.1 to 5.5 was a lengthy process. Each OmniCube (we upgraded two) had to be manually upgraded by a Simplivity technician.  Even simple patches work the same way. For larger environments this would dissuade people from applying updates.  Lets hope some Heart Bleed style exploit doesn’t need to be patched in a hurry.  Though they tell me that with more than two cubes this process is a little faster. Indications are that future updates wont be any different.  The good news is that you can still migrate VMs to another cube during these upgrades and thus no VM downtime is required.  I fully expect that Simplivity will continue to improve in this area. With the explosive growth they are seeing, this kind of update \ patch model is not scalable.