Operations

The default OpenStack hypervisor is open source Kernel-based Virtual Machine (KVM). While KVM hypervisor may be an attractive option for Greenfield, public-cloud-like enterprise cloud deployments for Brownfield OpenStack deployments that support traditional enterprise hypervisors, such as VMWare ESX and IBM’s PowerVM and z/VM, are likely to be critical. 

KVM hypervisor may be an attractive option for Greenfield, public-cloud-like enterprise cloud deployments. For Brownfield, OpenStack deployments that target to augment the capabilities of the existing system infrastructures, support for enterprise hypervisors, such as VMWare ESX and IBM’s PowerVM and z/VM, are likely to be critical. 

VMWare and Mirantis have announced their intent to provide enterprise-class support for OpenStack services. This solution will permit enterprise customers to enable a cloud-like delivery model based on OpenStack sitting on top of vSphere-managed virtualized servers.

When it comes to IBM hypervisors, the IBM SmartCloud Orchestrator (SCO) product offers OpenStack layer for PowerVM and z/VM. In this IBM offering, OpenStack distributions are extended with value-add, enterprise-level features and complemented with a pattern (template)-driven deployment engine; e.g., IWD component and a full-scale, global orchestration engine based on BPM software from IBM (formerly Lombardi). Additionally, IBM changed a number of default products used by OpenStack. The publicly available OpenStack distribution utilizes RabbitMQ as a default queue and MySQL database while IBM uses Apache Qpid and DB2 LUW. SCO version 2.3 released in October 2013 is based on an OpenStack release codenamed Grizzly and offers support for PowerVM. The product will offer support for all hypervisors, including z/VM, based on an OpenStack Icehouse release coming later in 2014. 

We discussed various workload characteristics at the beginning of this article, but realistically, complex business software systems often consist of different types of workloads. Some components of the system may have a scale-out type of architecture while others can scale only vertically and require high availability on the infrastructure level. IBM’s System z servers offer efficient support for both types of workload (scale-out and scale-up) with its z/VM and z/OS virtualization, which adds considerable value to Brownfield OpenStack deployment efforts. If the qualities we’re after are scalability, resource pooling and reliability on the infrastructure-level (remember, we’re talking about private clouds here), then System z servers engineered for multilayer reliability and serviceability and built-in redundancy fit the bill nicely. Scale-out workloads designed to withstand hardware failures don’t require the reliability of the System z server, but additional benefits of consolidation, which can be differentiators for complex enterprise applications, need to be taken into consideration as well.   

There are some prerequisites to enabling SmartCloud Orchestrator/OpenStack support for z/VM. On the z/VM side, it requires z/VM on 6.3 level. On the SmartCloud Orchestrator side, enabling high availability of SmartCloud Orchestrator 2.3 components involves VMWare vSphere High Availability (HA) cluster. VMWare vSphere HA cluster, shared storage and vMotion-enabled network are required to keep individual VM instances with specific SmartCloud services up and running (see Figure 3).

 

IBM System z servers are high-end systems, topping the charts of enterprise-grade hardware. The IBM System z virtualization platform for Linux offers massive horizontal scalability and is capable of hosting thousands of virtual machines on a single server. The control plane for System z cloud management must scale accordingly. Further focus on scalability and high availability would likely be welcome additions in subsequent SCO releases. Having a distributed, elastic architecture for each individual service within the cloud management control plane would help ensure that the individual services have sufficient capacity to meet the increasing demand. Correspondingly, it would be beneficial to have an option to install SmartCloud Orchestrator on Linux on z/VM.

Conclusion
Private enterprise clouds don’t have to be extensions of virtualization strategies. Following a workload-centered approach and pulling together balanced, optimized, end-to-end solutions that leverage both a public cloud model as well as a cloud-enabled model based on enterprise-grade hardware may be a compelling strategy that provides tangible benefits to enterprise customers. 

Resources
• “Four Common Approaches to Private Cloud” by Lauren Nelson at http://blogs.forrester.com/lauren_nelson/13-10-28-four_common_approaches_to_private_cloud_0 
• “Technology Overview for Cloud-Enabled System Infrastructure” by Lydia Leong at https://www.gartner.com/doc/2256515/technology-overview-cloudenabled-infrastructure.
• OpenStack Design Tenets at https://wiki.openstack.org/wiki/BasicDesignTenets.

 

Additional Information
OpenStack Design Tenets


1. Scalability and elasticity are our main goals.
2. Any feature that limits our main goals must be optional.
3. Everything should be asynchronous. If you can’t do something asynchronously, see #2.
4. All required components must be horizontally scalable.
5. Always use shared nothing (SN) architecture or sharding.
6. If you can’t use SN, see #2.
7. Distribute everything—especially logic. Move logic to where state naturally exists.
8. Accept eventual consistency and use it where it’s appropriate.

4 Pages