There are a few of attributes that define cloud. Two of them, On-Demand Self Service and Rapid Elasticity, are the ones that are the most relevant to me. In a pure cloud environment, everything should be automatic and especially elastic. I’ve noticed that having these attributes in a cloud service is a standard nowadays, but it’s interesting how far they actually reach.
Let’s take an example. We have a vSphere environment with some VMs running on top of a storage array. Another array is brought to the environment. Now we want to introduce replication in the equation. No problem, let’s just implement the replication technology of our choice and be done with it. Wouldn’t it be cool if all of this happened in a cloud fashion, aka automatically? This is something that I’m working towards, but there’s a lot of steps to automate.
Something that can help in this scenario is EMC ViPR. With this product we can automate the process of protecting a LUN with continuous data protection with EMC RecoverPoint. ViPR will automate every task from creating the LUN on an array, configuring RecoverPoint settings and mounting the finished LUN to a host or a cluster. The only problem is that ViPR (and I’m guessing every orchestration product out there) expects to have the infrastructure implemented and ready to use. In a true cloud environment we might not have everything set up, because things cannot be predicted very well.
The beauty of software is that it’s not hardware ;). EMC has made a virtual version of RecoverPoint for VMware environments, and in fact there should be a lot of other products virtualized in the near future. When we utilize a virtual appliance, it can be deployed automatically through orchestration, on demand. This is not something that comes out-of-the-box, so there are a couple of issues with it. Firstly, the appliance is in OVF-format and secondly, the installation of the RecoverPoint appliance is done with a GUI based wizard.
Importing OVF automatically is a bit harder than it sounds. OVF was designed for the vSphere admin to use. Luckily, there’s a CLI based ovftool, that can be leveraged for automation with some tweaking. For the orchestration of all of this I used (obviously) the vCenter Orchestrator. If you want to spend some money, there is a neat commercial vCO plugin that can deploy OVFs automatically and also convert VMs to OVF. With a little effort, you can make your own ovf deployer using builtin vCO functionality.
vCO can easily run CLI commands on a local or remote server. With this functionality we can run the ovftool and deploy the RecoverPoint OVF to our vSphere environment. First we need to construct the proper command for ovftool so it can deploy the OVF successfully. I installed the ovftool on a separate VM, but it can be installed on the vCO appliance as well (or any other server for that matter). You can use ovftool in probe mode. It will instruct the user what kind of attributes we need for a certain OVF file for deployment. For RecoverPoint/VE, the ovftool command in vCO workflow is something like this:
cmd = "ovftool --datastore=" + datastore + " --diskMode=thin --name=" + vmName + " --ipAllocationPolicy=fixedPolicy ";
cmd += "--net:\"LAN Network\"=\""+lan+"\"" + " --net:\"WAN Network\"=\""+wan+"\"" + " --net:\"iSCSI1 Network\"=\""+iSCSI1+"\"";
cmd += " --net:\"iSCSI2 Network\"=\""+iSCSI2+"\"" + " --prop:ip=" + ipTemp + " --prop:dns=" + dns + " --prop:netmask=" + mask;
cmd += " --prop:gateway=" + gateway + " --acceptAllEulas --powerOn " + "/" + execFolder + "/" + ovaName + " vi://" + viUser + ":" + viPassword + "@" + vcenter;
cmd += "/" + datacenter + "/host/" + viCluster;
Not pretty, but it does the job. Now we just need a vCO workflow that will define the necessary attributes, make an SSH connection to the server and run the command above. If you want to use this for any other OVF, just run the ovftool against the OVF file and deduct the necessary command. The ovftool will tell you everything you need. The biggest issue with this approach is the clear text admin password that is required for deploying a VM. Nope, securestring cannot be used. Need to find a solution for this.. I think this approach could be used for a general automatic OVF deploying tool, since ovftool will return the needed attributes for a OVF. Lot’s of coding needed, obviously.
So that’s done, the RP/VE appliance can be automatically deployed using all VMware tools. Next step is to automate the configuration part. Think Expect.