Building a Flexible Openstack* Cloud from the Ground Up
Total Page:16
File Type:pdf, Size:1020Kb
WHITE PAPER Building a Flexible OpenStack* Cloud from the Ground Up Contributors This paper describes the process of designing and building a flexible Dr . Yih Leong Sun OpenStack* environment that takes advantage of Intel® platform features Senior Software Cloud Architect, and supports open-ended customer requirements. It outlines steps taken at Intel OTC the Intel Open Source Technology Center to create a lab cloud that supports Michael Kadera OpenStack development. Cloud and Data Center Manager, Intel OTC A well-designed OpenStack environment must not only meet the present needs of the developers and end users it supports but also offer the flexibility John Geier and scalability to satisfy future requirements as broadly as possible. It follows Cloud & Data Center Engineer, that, while balancing those factors with budget limitations and other practical Intel OTC constraints is vital, the common practice of starting the design process with a Table of Contents budget discussion is not ideal. Defining Requirements and Instead, it is a best practice to begin by identifying what the cloud needs to do and Constraints for the Architecture . 1 creating a preliminary design to meet those needs. Once that work is complete, Planning for Growth of the practical limitations can be thoroughly identified and accommodated as the design Environment . 3 is refined and finalized. This focus helps preserve meeting the present and future Entry Stage . 3 capabilities needed from the environment as the core priority of the process. Intermediate Stage . 3 Enterprise Stage . 3 Establishing the A well-designed, flexible cloud provides long-term support for end users and Rack-Level Design . 4 their applications as their needs evolve. Just as the business it supports is Specifying Requirements dynamic and ever-shifting, an OpenStack environment must be able to adapt against Available Resources . 4 to the need for ongoing change. Per-Rack Power Usage . 4 Rack Density . 4 Refinements to the Rack-Level Defining Requirements and Constraints for the Architecture Design . 4 Identifying core design requirements begins by establishing what users will need Compute Resources . 5 to accomplish using the OpenStack environment being built. Some examples of Management Resources . 5 the types of capabilities to be supported by the compute, storage, and network Networking Resources . 5 infrastructure are illustrated in Figure 1. At this stage, designers must consider Providing a Flexible beyond the known applications to be hosted on the system, including factors such Lab Topology . 6 as runtimes, data access, and services for identity and asset management. As usage Compute Flexibility . 6 scenarios are outlined, interlocking sets of requirements are typically revealed. Storage Flexibility . 6 For example, one aspect of service monitoring relates to charging for usage, Network Flexibility . 6 if applicable, including chargeback to other business units within a company Deployment Mechanisms . 6 or billing to external users. Depending on the details of these arrangements, they may have implications with regard to Sarbanes-Oxley or other regulatory Design Best Practices for Flexible OpenStack Clouds . 6 frameworks. Data access, export restrictions, and privacy regulations may also Compute Best Practices . 6 Storage Best Practices . 7 Network Best Practices . 7 Deployment and Management Best Practices . 7 Conclusion . 7 Building a Flexible OpenStack* Cloud from the Ground Up 2 impact multi-tenancy strategies, resulting in the logical or physical partitioning of users and data to remain compliant. Compliance efforts, in turn, will impact mechanisms for how users, applications, and systems access specific resources and how rights that govern that access are established and maintained. Additional aspects of gathering requirements Desktops Cloud Servers Smartphones include the following: • Devices and external systems to be supported, including clients such as PCs, smartphones, and endpoints on the Internet of Things, as well as cloud-based resources and enterprise back-end systems. Tablets IoT Devices Laptops • Data and infrastructure interoperability, including functionality related to analytics and interactions between public and internal big data resources. Devices • Orchestration of resources and operational management, maintaining optimal functioning of both physical and virtual resources, including facilitating end-user support for break- fix and adds, moves, and changes. Making this process more complex, each of these factors must take into account not only current needs but also Monitoring Content Finance Communications projections for the future. In the case of the lab cloud at the Intel Open Source Technology Center, the purpose was to support internal developers and architects globally as they write, test, and Asset push OpenStack code upstream to the community at large. Identity Data Runtime Management In this sense, Intel’s production environment can be a downstream consumer of the work done in this lab and by Capabilities other contributors. The corresponding goals of this work are to enhance the growth and stability of OpenStack for the enterprise, making the use of cloud resources as simple and effective as possible. The lab-cloud development effort also includes work to enable enterprise capabilities such as rolling upgrades, bare metal provisioning, and service plane high availability Compute Storage Network (HA), as well as Intel® platform capabilities such as trusted compute pools, Intel® AES New Instructions, Intel® Advanced Infrastructure Vector Extensions 2, and single-root I/O virtualization. In addition, design projects such as the Intel® Power Thermal Figure 1 . Example requirements for the architecture. Aware Solution help foster efficient management strategies for the data center based on the latest platforms. The lab environment also supports enablement for cloud-related technologies such as the Data Plane Development Kit (DPDK), Open vSwitch*, and OpenDaylight*. This effort is part of Intel’s ongoing commitment to expanding its participation in OpenStack and related projects. Because the user base for this lab environment is global, the ability to make changes to the environment’s configuration remotely on demand is critical. To avoid the need for physically moving cables and equipment to support ongoing project-specific changes, the team established that capabilities such as KVM/PDU over IP, Intelligent Platform Management Interface (IPMI), managed switches, and software-defined infrastructure must play a significant role in the solution. Building a Flexible OpenStack* Cloud from the Ground Up 3 Planning for Growth of the Environment The design of an OpenStack environment must be based on a scalable rack design that allows both the cloud’s capacity and its corresponding features and capabilities to grow over time. This progression also corresponds to the reality of budget limitations, which may significantly limit what an organization is able to build in the early stages of an OpenStack deployment. Nevertheless, fiscal soundness requires that the initial design consider the long-term lifespan of the environment, which may be considered in a three-stage model, as illustrated in Figure 2. Enterprise Intermediate Entry Multiple Availability Zones Scale Single Single Availability Zone Availability Zone Minimal Dual Rolling Upgrades Provisioning Availability Zones Single Availability Zone High Availability Rolling Upgrades Enhanced Scalability Core Functionality Operational High Availability Flexible Software-Defined Netowork and Storage Figure 2 . Growth phases of the solution. Entry Stage Testing of operational HA allows for improving the efficiency of patching and other updates to the system by minimizing A rudimentary deployment of OpenStack at the entry the delay associated with moving virtual machines (VMs) stage includes initial provisioning and getting core cloud around when taking physical nodes offline. Optimizing this functionality in place, typically in a single rack comprising a functionality before the environment becomes too large can single availability zone. One could consider this a “minimum generate significant savings later. viable cloud,” meaning the minimal set of capabilities required to deliver basic cloud capabilities while remaining fully extensible and scalable for long-term evolution and Enterprise Stage growth. The physical infrastructure of this relatively simple As the OpenStack environment continues to grow, it implementation serves as a building block that can be may encompass a large number of racks, each typically used as a template for additional racks as they are added patterned after the design established in the entry stage. later. To support user needs, failover testing for HA may be The environment may become significantly more complex undertaken at this stage. at this stage, extending to multiple availability zones or regions. Availability zones can be used to divide a compute Intermediate Stage deployment into multiple logical groups that provide redundancy at the power supply or network layer; regions An expansion of the initial OpenStack rollout uses multiple provide a more discrete separation across multiple sites. racks and establishes the scalability of services the Refinements to support for rolling upgrades play a significant environment offers. This may include the fundamental use role in ensuring that the data plane and control plane remain of a secondary availability zone, including the intentional