At VMworld ’14 I managed to catch a few excellent sessions on EVO:RAIL including the deep dive session + Q&A that really explained the architecture that makes up the EVO:RAIL appliance. The EVO:RAIL appliance is only built by authorised vendors or as VMware call them QEPs (Qualified EVO:RAIL Partners) from a hardware specification that is determined by VMware.
Also the EVO:RAIL software/engine is provided to the QEPs for them to install and requires a built in hardware ID (also provided by the QEPs) in order for the engine to work correctly. This means currently that the EVO:RAIL appliance is a sealed environment that has only been designed to exist on pre-determined hardware and that anyone wanting to use any of this functionality on their pre-existing infrastructure will be unable to do so.
So what are the components of EVO:RAIL:
- QEP hardware (a 2U appliance that has four separate compute nodes)
- Loudmouth, a zeroconf daemon written in python that also detects the hardware ID
- EVO:RAIL engine that consists of python/bash scripts, a comprehensive UI and automation ability for deployment
- VCSA appliance (contains loudmouth, EVO:RAIL) this is pre-installed on one node in every appliance.
How is it built and how is it configured:
The idea is that a customer will speak to their account manager at a QEP place an order on a single SKU and provide some simple configuration details. The vendor then will pre-provision the four nodes with the EVO:RAIL version of vSphere, one of these nodes will be also provisioned with the VCSA appliance (also the EVO:RAIL version). The VCSA node will be configured with some IP addresses provided by the customer so that they can complete the configuration once the appliance has been racked. The EVO:RAIL engine combined with the loudmouth daemon will detect the remaining nodes in the appliance and allow them to be configured, the same goes for addition appliances (maximum 4) that are added.
This simplified UI that was crafted by Jehad Affoneh and provides a HTML5 + web sockets interface that provides real-time information for the end-user as they complete the EVO:RAIL configuration. Once the initial configuration (networking/passwords etc.) is complete the EVO engine will then handle the automation of the following tasks:
- vSphere instance configuration (hostnames, passwords, network configuration)
- Deploy and configure the VCSA (once complete add in the vSphere instances, and configure VSAN)
- Tidy up
- Re-direct user to the EVO:RAIL simplified interface for VM deployment.
The final screen that the user is presented with is the EVO:RAIL simplified interface, this is a “reduced functionality” user interface that allows people to complete simple tasks such as deploy a simple VM (from simplified pre-determined parameters such as sizing) or investigate the health of vSphere host. The “real” management interface i.e. vCenter is still there in the back ground and the EVO:RAIL interface still has to interact with it through the awful vCenter SOAP SDK (which hopefully will change in the next releases, thus requiring a re-write for the EVO engine).This vCenter can still be accessed through the URL on port 9443, direct with the infrastructure client or alternatively there is a small link in the EVO interface in the top right hand corner.
EVO:RAIL has been described by JP Morgan with – “EVO products could be an iPhone moment for enterprise use of cloud computing”. I see this in two ways:
Incredible simplification and ease of use, deployment of four nodes is meant to take no more that fifteen minutes. The simplified interface for VM deployments takes 3-4 clicks and your virtual machine is ready to use. The use of the LoudMouth service truly makes deployment plug and play as more capacity is added.
The walled garden, the comparison to the iPhone covers this point perfectly as this product is a closed off product and only available to authorised partners. There are some really clever design ideas here that could really be expanded on and back ported to the existing vSphere to provide some really great functionality.
- Large scale deployment with the use of the LoudMouth daemon for discovery
- Disaster recovery would be simplified again via the LoudMouth daemon advertising where virtual machines are located (in the event that vCenter doesn’t auto re-start after failure).
After speaking with the designer of the UI and sitting through the deep dive sessions there were a few design decisions or “short cuts” that had to be taken in order to get functionality to work, I decided to see what I could improve or at least imitate in my vSphere lab. To begin with I started with the zeroconf agent and how it could be implemented or improved upon, in EVO:RAIL this had to be written from scratch in python due to the development team not managing to get any pre-existing solution (which is understandable AVAHI is hideous and has dependencies on everything).
So I introduce “boaster” which is a tiny daemon written in C that handles simple mDNS service announcement, it’s only a PoC however I intend to add more functionality in the next few days. At the moment a vSphere hypervisor will advertise itself and it’s DHCP address to a bonjour browser or avahi-browse..
.. More to follow.