The “Cloud” Need Not Be A Commodity

CipherSpace has a heritage of providing managed ICT infrastructure and services to clients who need customized “enterprise-quality” solutions on small to medium-sized business scales. Historically this demanded versatility, so that we could both provide each client with the right solutions for them and also with the expertise and judgment to guide them in the choice of their best solutions. As a consequence, we have used many approaches to virtualization over the years: FreeBSD Jails, Parallels, VMWare ESX/ESXi, Citrix XenServer, and Linux KVM, as well as working with others in non-production testing and evaluation. Because we have diverse clients with services in technically close proximity to each other, security has always been a critical focus of our work. We also have a strong preference for open source software, based not only on the obvious cost advantage but also for its adaptability and more transparent (and historically better) security. We’re not OSS purists in any sense, but openness is an important feature of many solutions we offer, as is the availability of commercial support for critical instances of critical tools, both for ourselves and our customers.

It became clear to us in 2011 that “Cloud” architectures were maturing in a way which made it imperative for us to create our own suite of solutions that would serve our clients differently and better than what they could get from the commodity sector. Our experience with proprietary virtualization platforms and the nature of their management tools made OpenNebula’s openness and use of securable management interfaces (Linux CLI tools and Sunstone) very attractive. Also, at that time the nominally “open” alternatives to OpenNebula we considered viable were effectively controlled by vendors with competing and conflicting interests, while OpenNebula was clearly taking an ecumenical approach to hypervisors and storage technologies. This remains one of its most appealing features. Another is the Sunstone web administration interface, which is easily protected behind a HTTPS proxy so that it can be safely exposed to clients and our own global staff without the VPN acrobatics we deemed necessary to protect our prior virtualization platform management tools.

When The Standard VDC Is Enough: A Customer Example

Sunstone’s default set of views and OpenNebula’s standard ACL set defining its “Virtual Data Center” model were ideal for this client, a software developer with a complex application architected for “Cloud” deployment: instantiate more VMs from the same few templates and non-persistent images, and they automatically find their peers on the same private subnet and spread the load, which comes across the Internet from around the world through a virtual load balancer that is part of their VDC. They are currently only using resources from one of our OpenNebula Zones in Europe, but we anticipate their expansion to require resources in other zones in the near future as their customers are global. We set up and maintain their infrastructure (including system images with their software & configurations loaded) for 3 distinct but operationally identical environments (Test, QA/Demo, and Production) in a single VDC drawing resources from a cluster also utilized for other customers. We also handle their routine operations at the OpenNebula level because we have the needed staffing & knowledge of OpenNebula. The VDC model allows us to assign tasks for each environment in a compartmentalized fashion, since each one is owned by a different low-privilege user in the VDC’s group. Because the OpenNebula cluster that the VDC uses is much larger than the quotas or actual demands of the client’s environments and is shared with other clients’ environments, all the flexibility and cost efficiency of the “Cloud” model are preserved, without exposing multiple clients’ systems (or even existence) to each other. If the client had an operations staff, we could hand off operations to them without needing to restructure the security.

Extending OpenNebula: Customized Private (virtual) DCs

Although it isn’t entirely consistent with the “Cloud” concept, some clients want more than the OpenNebula standard VDC provides: committed hosts reserved exclusively for their use. This is easy enough to do by creating an OpenNebula cluster of hosts and other resources all owned by the VDC’s administrative user and group, not usable by any others. We call this a “Private (virtual) Data Center” (PvDC) because it reserves physical resources for one client while it remains part of our OpenNebula platform: more private, less purely virtual. The standard VDC model leaves a problem for the PvDC: visibility. Clients who buy reserved hosts need to *SEE* them. The standard VDC ACLs and Sunstone views don’t offer that, so to give PvDC customers a functional (and secure) user experience we’ve added ACLs and created a custom Sunstone view so they can see and run what they’ve paid for without showing them functionality or resources they can’t use. Because it’s a derivative of the standard VDC, this model can extend across multiple OpenNebula Zones, giving clients virtual federated private Zones of their own within ours. The PvDC adds perceived value to customers over a VDC, where they are left to trust blindly in our resource management for contingencies like hardware failures, host OS updates, and maintaining standby capacity. However, it also provides them concrete value over running their own isolated OpenNebula Zone because we can rapidly add hosts to their cluster for added capacity and swap hosts in and out for system maintenance.

The PvDC In Action: A Customer Example

Our first PvDC in full production operation was (and still is) a long-term customer, originally hosted in our FreeBSD ‘jail’ environment and later on XenServer VMs running CentOS. They wanted to convert their public application from a stack of services on a single VM to a more flexible modular architecture spread across multiple VMs and split up their internal services from a single VM into many, allowing them an isolated test environment more closely matching production. Because they have skilled DevOps staff eager for deeper control over their systems and had a history of sharply punctuated growth in resource demands, they were the ideal candidates for our PvDC solution. Our initial assessment of their existing architecture suggested that a 2-host PvDC solution would been an ideal fit and allow the customer to move towards a micro-services architecture, moving from 2 VMs to 12. Soon after initial deployment it became clear that performance under peak loads would benefit from adding a third host to the PvDC, a simple matter of adding a spare host to their cluster. Being able to respond to such capacity-related issues by adding hosts in minutes instead of days and to advise and assist their DevOps staff rather than do their jobs has helped preserve a positive relationship.

High-Functioning Openness In Operation

Open-source software like OpenNebula can fall short of the OSS conceptual ideal in a myriad of different ways. In some cases, openness itself is problematic; as with sausage and law, the making of software can be disturbing to watch closely. Nothing is perfect. However, I think that how we’ve been able to adapt OpenNebula at CipherSpace to meet clients’ desires and requirements for “partly cloudy” services demonstrates its true openness in operation. With the flexibility provided by the OpenNebula platform, we were able to create a valuably different solution in the PvDC model with nearly all our effort in the conceptual development of what we wanted to offer and the testing of small adaptations of OpenNebula. This accessibility to non-developers of actually using its openness is a feature of OpenNebula which is not present in all OSS and whose absence is usually only noticed after one has used a tool long enough to see what it just barely cannot do.