Rolling Upgrades for OpenStack * Clouds

white paper Rolling Upgrades for OpenStack* Clouds Executive Summary In just five years, OpenStack* software has expanded and matured to become today...
Author: Pauline Fox
73 downloads 0 Views 221KB Size
white paper

Rolling Upgrades for OpenStack* Clouds Executive Summary In just five years, OpenStack* software has expanded and matured to become today’s leading open-source cloud platform. More than 1,200 organizations, including Fortune 500 leaders, such as eBay, PayPal, Walmart, Walt Disney Corporation, and Time Warner,1 are now using an OpenStack private or hybrid cloud to orchestrate pools of compute, storage, and networking resources and to deliver elastically scalable IT services to their end-users through self-service portals. An OpenStack cloud consists of a collection of interoperable software modules that operate in tandem to deliver desired cloud services. As the number of software modules has grown, upgrading an OpenStack cloud has become a challenge, requiring careful planning and execution to minimize disruption to production environments. Intel is working with the OpenStack software development community to resolve this issue by enabling simple, fast, rolling upgrades for OpenStack cloud services. Helpful changes have already been made to the OpenStack software release model, and a number of complementary technology enhancements are underway that will enable cloud operators to upgrade each OpenStack software module independently. The ability to perform rolling upgrades offers significant value for the organizations that are using OpenStack software. As the functionality of the cloud platform continues to grow, they will be able to integrate new features faster and with greater flexibility based on their specific requirements, without disrupting production environments. This white paper discusses the enhancements that have already been implemented, and others that are underway, to enable quick, incremental upgrades with little or no downtime. It also provides an estimated timeline that can help organizations understand when they can reasonably expect to be able to conduct rolling upgrades in their own OpenStack cloud environments.

Authors

Contributors

Malini Bhandaru Cloud Architect, Open Source Technology Center (OTC), Intel Software and Services Group (Intel SSG) Arek Chylinski Engineering Manager, Software-Defined Infrastructure (SDI), Intel Data Center Group (Intel DCG) Michal Jastrzebski Senior Cloud Software Engineer, SDI, Intel DCG Krishnan Raghuram Cloud Marketing Lead, OTC, Intel SSG Rob Shiveley Cloud Marketing Manager, OTC, Intel SSG

Grzegorz Grasza Software Engineer, Intel Cloud Platforms Group, Intel DCG Dave Chen Software Engineer, OTC, Intel SSG Isaku Yamahata Cloud Network Architect, OTC, Intel SSG

Rolling Upgrades for OpenStack* Clouds

Table of Contents Executive Summary . . . . . . . . . . . . . . 1 OpenStack Growth Brings New Challenges. . . . . . . . . . . . 2 “Big Tent” Approach Helps Both Developers and Operators. . . 3 Providing Support for Rolling, Incremental Upgrades. . . . . . . . . . . . 3 Cross-Version Software Interoperability Through Versioned Objects. . . . . . . . . . . . . . 4 Enhanced Neutron Stability for Reliable Restarts. . . . . . . . . . . . 4 Fast, Incremental Upgrades Through Containerized Deployments. . . . . . . . . . . . . . . . . . . 5 Stronger Cloud Security with Clear Linux and Clear Containers. . . . . . . . . . . . . . . 6 Projected Timeline for Rolling Upgrade Support. . . . . . . . . 7 Conclusion. . . . . . . . . . . . . . . . . . . . . . . 7

2

OpenStack Growth Brings New Challenges Ever since it was first kicked off as an open-source project in 2010, the OpenStack software development community has followed a six-month release cadence for the entire OpenStack cloud platform. These integrated releases have typically occurred in April and October, followed by an OpenStack Conference and Design Summit where gaps and new capabilities have been discussed and prioritized for the next release. This model has served the OpenStack community well. Timely planning and quick resolution of urgent issues has allowed development teams to expand and mature the platform quickly. However, there are now dozens of OpenStack software projects, all evolving to support the diverse needs of more than 1,200 user organizations. Delivering these projects as an integrated, tested, and documented cloud platform on a regular, six-month release cycle is not practical. Coordinating and aligning development efforts based on

a common timeline generates overhead and inefficiencies that can cause project teams to delay the introduction of valuable new features and capabilities. As the number of projects grows, this strategy also places untenable demands on the peopled who are taxed with maintaining the integrity of each release. Integrated releases create a different set of challenges for the businesses that are using the OpenStack cloud platform. Since all of the integrated modules must be upgraded at the same time, moving to a new release is a complex process that requires careful planning. Services must be scaled down during an upgrade and temporarily halted to launch new cloud services. Critical workloads must be migrated to a temporary environment while the OpenStack cloud is upgraded, and then reinstated on the upgraded environment. Because of this complexity, operators have typically skipped one or more releases before doing an upgrade, which has delayed the integration of new capabilities that might otherwise deliver immediate value.

Rolling Upgrades for OpenStack* Clouds

“Big Tent” Approach Helps Both Developers and Operators To help address these challenges, the OpenStack software development community has adopted a Big Tent approach to releasing new software versions. Although many project teams will continue to work toward the regular, six-month release cycle, this is no longer required. Instead, the developers in each project have control over their own timelines and release schedules. They also assume responsibility for documenting, testing, and validating their new software versions against the current versions of other relevant software modules. This decentralization will help to avoid bottlenecks in the release process as the number of projects continues to increase. The Big Tent release model will make it easier for the OpenStack software development community to maintain its rapid rate of innovation. The OpenStack Technical Committee can accept and support more new projects, without creating unnecessary divisions between core projects that are included as part of an integrated release and ancillary projects that are not. All accepted projects can now be treated as first-class citizens. The Big Tent model is not only a good strategy for OpenStack software developers, but also for businesses that are implementing or upgrading an

3

OpenStack cloud. In combination with the technology innovations discussed in the following sections of this paper, the Big Tent model will help to eliminate the need for “forklift” upgrades. Operators will be able to deploy customized clouds with ease by selecting their preferred modules, and then adding or upgrading modules incrementally and at any time, with little or no downtime. As a result, they will be better able to take advantage of the flexibility and rapid innovation that are such key advantages of the OpenStack cloud platform. For more information about the Big Tent release model, watch this video, which was filmed in May 2015 at the OpenStack Summit in Vancouver: https://www.openstack.org/summit/ vancouver-2015/summit-videos/ presentation/the-big-tent-alook-at-the-new-openstackprojects-governance

Providing Support for Rolling, Incremental Upgrades Intel is working with the OpenStack community to integrate a number of underlying technologies that are needed to fully enable rolling upgrades in OpenStack clouds. Some of these technologies are included in the Kilo release, which became available in April of 2015. Others are targeted for the Liberty release, which is scheduled for October 2015, and still others for the follow-on Mitaka release.

The new technologies and capabilities include: • Cross-version interoperability, so that OpenStack software modules can communicate with each other regardless of their versions. • Enhanced Neutron (network) stability to ensure that connectivity for virtual machines does not break when services are restarted following upgrades. • Containerized OpenStack Deployments in which each OpenStack software module, including all its required libraries, are hosted in a Linux* container. This will help to eliminate library dependency issues that can complicate upgrades. It will also accelerate the speed with which new services can be launched, potentially reducing the downtime required for cloud upgrades to near zero. • Service Tags for OpenStack Software Modules to help users quickly determine the value, viability, and upgradeability of each module. Service tags will include information such as the release model, the expected longevity, the update frequency, the base kit for deployment, and whether the software module has been approved by the OpenStack Technical Committee.

Rolling Upgrades for OpenStack* Clouds

4

Several of these technologies are discussed in more detail below. Cross-Version Software Interoperability through Versioned Objects To enable simple, granular software upgrades, the various OpenStack software modules must be able to communicate with each other, regardless of their versions. One of the layers where incompatibility can cause problems is the remote procedure call (RPC) communication interface. The goal of the oslo.versionedobjects library2 is to provide versioning and translation for resources that are passed over RPC. If an older service receives a newer resource that it doesn’t understand, the service can request a backport to a version that it

does understand. If a newer service receives an older resource, it can run the resource in compatibility mode. The oslo.versionedobjects library was first developed in the Nova (compute) project and was merged into the Juno release of OpenStack software. The incubated solution was then pulled out to the Oslo project to be consumed by other OpenStack services. Versioned objects can be implemented for projects that, like Nova, have a central service, such as nova-conductor, that is able to backport resources (Figure 1). For projects that lack such a service, a compatibility feature is being implemented so the sending service does the translation itself, rather than requiring on-demand backporting.

Enhanced Neutron Stability for Reliable Restarts Neutron has multiple plugins that can be used to extend network functionality. One of the most popular is Open vSwitch, which is used to create and manage logical networks in OpenStack clouds. In addition to the Open vSwitch plugin, an Open vSwitch agent is installed in individual compute nodes to manage traffic flows. Intel is working to ensure that IT organizations can upgrade these agents as needed, without risking network downtime for the affected virtual machines.

Figure 1. OpenStack* Communication Scenario

Resource v2 (1) nova-api (v2)

Request

nova-conductor (v2)

Resource translation request (2)

nova-compute (v1)

Resource v1 (3)

Figure 1. The oslo.versionedobjects library allows newer and older versions of OpenStack* software modules to communicate with each other. For example, if a newer version of nova-conductor passes a resource to an older version of nova-compute (step 1), nova compute can request a resource translation (step 2). Nova-conductor than translates and returns a resource that the older version of nova-compute can understand (step 3).

Rolling Upgrades for OpenStack* Clouds

Fast, Incremental Upgrades Through Containerized Deployments When upgrading an OpenStack service to the latest release, it is necessary to upgrade the required libraries for that service. However, many OpenStack services share a number of common libraries, which can force IT organizations to conduct “all or nothing” upgrades to ensure compatibility. Linux containers offer an ideal solution to these dependency issues by allowing each OpenStack service—including all its required libraries—to be deployed in a separate container.3 Linux containers deliver many of the benefits of virtual machines, but with greater agility and much lower overhead. A container can be launched in a fraction of a second, to dramatically shrink upgrade windows, and a single OS can support hundreds, even thousands, of containers. By launching each OpenStack service and its associated libraries in a separate container, administrators can ensure that each service can be upgraded quickly and independently, without disrupting other services. The basic technologies required to containerize applications have been included in the Linux kernel for several years, including namespaces for isolating processes and cgroups for managing resource allocation. The use of containers has gained a lot of momentum with the emergence of new tools, such as Docker*, Kubernetes*, and Mesosphere*, which can be used to orchestrate, manage, and rapidly scale containers. Intel is a sponsor of the Open Container Initiative (https://www. opencontainers.org/) and is working to extend and enhance container technology to provide more robust support for enterprise deployments.

5

Within the OpenStack cloud platform, the Kolla project4 will provide tools and resources for containerizing services and other workloads. The Kolla software module can be used with Ansible5 — a free software platform for automating infrastructure management—to simplify and accelerate setups and upgrades for an OpenStack cloud.6 With this deployment strategy, administrators will have a great deal of flexibility for deploying customized clouds and upgrading them incrementally and almost instantly. An operator could potentially use the same service implementation for years, upgrading each service separately, and only when new features and capabilities emerge that justify the upgrade. Even greater agility and value may ultimately be achieved by using the OpenStack TripleO project, which provides support for bare metal deployments and configuration management.7 Combining TripleO with Kolla containers and oslo. versionedobjects could make it exceptionally quick and easy to deploy largescale, production-ready, and upgradable OpenStack environments.

Launching each OpenStack service and its associated libraries in a separate container, administrators can ensure that each service can be upgraded quickly and independently, without disrupting other services.

Rolling Upgrades for OpenStack* Clouds

6

Increased isolation helps

Stronger Cloud Security with Clear Linux and Clear Containers

to make containers more

by malware or misbehaving virtual machines, without compromising the low overhead and ultra-fast launch times that are so important in many container usage models.

To help provide enterprise-class security for containers in OpenStack clouds and other environments, Intel launched the Clear Linux project with its associated Clear Containers technology (see www.clearlinux.org). Clear Containers use Intel® Virtualization Technology (Intel® VT) to provide more robust, silicon-enhanced isolation among containers (Figure 2). This increased isolation helps to make containers more resistant to attack

resistant to attack by malware or misbehaving virtual machines.

Although this capability is currently still in development, adoption by the Linux and OpenStack communities can be expected in the near future. To monitor ongoing developments, visit the container page of the Clear Linux project web site at: https://clearlinux.org/ features/clear-containers.

Figure 2. Clear Linux* and Clear Containers

Container A

Container B

Container C

App

App

App

Middleware

Middleware

Middleware

Linux* Kernel

Linux Kernel

Linux Kernel

Small, fastloading kernel

Intel® VT-x

Intel VT-x

Intel VT-x

Isolation through CPU enforced VT-x

Linux Host OS Server Hardware

Figure 2. Intel is working with the open-source community to deliver Clear Linux* and Clear Containers, which take advantage of Intel® Virtualization Technology (Intel® VT) to improve workload isolation and provide a better foundation for enterprise-class security.

Rolling Upgrades for OpenStack* Clouds

Projected Timeline for Rolling Upgrade Support Technical progress in any open-source project typically depends on the work of many individuals and organizations, and this is certainly true for OpenStack. It is therefore not possible to predict with certainty when new capabilities will be available. However, the following offers an informed projection of what is likely to be available in future OpenStack releases (Table 1).

7

also be addressed in this release. With these enhancements, it should be possible to implement rolling upgrades for Nova, although it will still be necessary to use libraries that are compatible with other deployed projects.

• Mitaka (release date not yet announced, but probably mid-2016): Expected enhancements for rolling upgrades include versioned objects support for Neutron (network), Cinder (volume storage), Heat (orchestration), Barbican (key management), and • Juno and Kilo (already released): Ceilometer/Aodh (utilization monitorKey enhancements for rolling upgrades ing and alarms). Although it is difficult include versioned objects support for to predict when the Kolla container Nova. Although these enhancements project will be fully tested and rewill not be fully enabled until the Liberty leased, it is reasonable to expect that it release, rolling upgrades for Nova can will also be completed and productioncurrently be supported using hard coded ready in time for the Mitaka release. mechanisms. With this addition, rolling upgrades can become the norm rather than the • Liberty (October 2015): Expected enexception for most core services in hancements for rolling upgrades include OpenStack cloud environments. completed versioned objects support for Nova and the integration of Magnum, • Beyond Mitaka: Development work is for container management. Magnum underway to deliver Clear Containers should include support for versioned technology, which will help to improve objects, so it will interoperate with future container isolation and security. It is versions. Neutron stability issues should still too early to forecast a timeline for

the adoption and integration of Clear Containers into the OpenStack cloud platform.

Conclusion The OpenStack cloud platform continues to evolve rapidly. The new Big Tent software release model will help to maintain this momentum as the number of interrelated software modules grows. To help organizations integrate new features and modules faster and more flexibly, Intel and the larger OpenStack software development community are implementing complementary enhancements in multiple OpenStack software modules. With the oslo.versionedobjects library and with the agility and security of Clear Containers, organizations will be able to deploy and upgrade OpenStack software modules quickly and independently, without disrupting production environments. This capability will help existing OpenStack users evolve their clouds more easily. It will also help to fuel even faster adoption of OpenStack cloud software, adding to the community of users and further increasing the rate and scope of innovation.

Table 1. OpenStack* Support for Rolling Upgrades (estimated availability for production cloudsa) OpenStack Cloud Platform Functionality Versioned Objects

Kilo (April 2015)

c

Liberty (October 2015)

Mitaka (Mid-year 2016b)

ü Nova (compute)

ü Neutron (network) ü Cinder (volume storage) ü Heat (orchestration) ü Barbican (key mgmt.) ü Ceilometer (monitoring)/Aodh (alarms)

ü Magnum (container mgmt.)

Neutron Stability

ü Stable virtual machine connections on restart

Containerization Container Security Rolling Upgrades Enabled For: • Completed

ü Kolla container project Clear Linux*/Clear Containers: In progress, release date unknown •N  ova (using hard coded mechanism, not versioned objects)

Nova (using versioned objects, common library versions required)

Most OpenStack cloud services: (Incremental rolling upgrades with little or no downtime)

ü Expected

 ll projections shown here are estimates only. As is true with any open-source project, OpenStack evolution and timelines depend on the work and decisions of many independent A individuals and organizations. Official release date not yet announced. C Glance (images), Keystone (identity), and Horizon (dashboard) do not require versioned objects in order to support rolling upgrades. a

b

Rolling Upgrades for OpenStack* Clouds

1. For more details about OpenStack* software adoption, including detailed case studies, visit the OpenStack Foundation web site at https://www.openstack.org/user-stories/. 2. For more information about the oslo.versiondobjects library, visit http://docs.openstack.org/developer/oslo.versionedobjects/. 3. For more information about Linux* containers and there use in OpenStack cloud environments, visit https://linuxcontainers.org/ and https://wiki.openstack.org/wiki/ContainersTeam. 4. For information about the OpenStack Kolla project, visit https://wiki.openstack.org/wiki/Kolla. 5. For more information about Ansible, visit http://www.ansible.com 6. For more information about using Ansible to deploy and manage OpenStack cloud solutions, visit http://www.ansible.com/openstack. 7. For more information about the OpenStack TripleO project, visit https://wiki.openstack.org/wiki/TripleO. Intel technologies, features and benefits depend on system configuration and may require enabled hardware, software or service activation. Performance varies depending on system configuration. No computer system can be absolutely secure. Check with your system manufacturer or retailer or learn more at intel.com. Intel’s compilers may or may not optimize to the same degree for non-Intel microprocessors for optimizations that are not unique to Intel microprocessors. These optimizations include SSE2, SSE3, and SSSE3 instruction sets and other optimizations. Intel does not guarantee the availability, functionality, or effectiveness of any optimization on microprocessors not manufactured by Intel. Microprocessor-dependent optimizations in this product are intended for use with Intel microprocessors. Certain optimizations not specific to Intel microarchitecture are reserved for Intel microprocessors. Please refer to the applicable product User and Reference Guides for more information regarding the specific instruction sets covered by this notice. Notice Revision #20110804 No license (express or implied, by estoppel or otherwise) to any intellectual property rights is granted by this document. Intel disclaims all express and implied warranties, including without limitation, the implied warranties of merchantability, fitness for a particular purpose, and non-infringement, as well as any warranty arising from course of performance, course of dealing, or usage in trade. This document contains information on products, services and/or processes in development. All information provided here is subject to change without notice. Contact your Intel representative to obtain the latest forecast, schedule, specifications and roadmaps. The products and services described may contain defects or errors known as errata which may cause deviations from published specifications. Current characterized errata are available on request. Copies of documents which have an order number and are referenced in this document may be obtained by calling 1-800-548-4725 or by visiting www.intel.com/design/literature.htm. Intel and the Intel logo are trademarks of Intel Corporation in the U.S. and/or other countries. *Other names and brands may be claimed as the property of others © 2015 Intel Corporation. 1015/RS/HBD/PDF 332177-001US