Architecture Design Guide
Total Page:16
File Type:pdf, Size:1020Kb
Architecture Design Guide Release Version: 15.0.0 OpenStack contributors Jun 18, 2017 CONTENTS Abstract 2 Contents 3 Conventions ............................................. 3 Architecture requirements ...................................... 3 Design ................................................ 16 Use cases ............................................... 55 Appendix ............................................... 68 Index 106 i Architecture Design Guide (Release Version: 15.0.0) Note: This guide is a work in progress. Contributions are welcome. CONTENTS 1 ABSTRACT The Architecture Design Guide provides information on planning and designing an OpenStack cloud. It explains core concepts, cloud architecture design requirements, and the design criteria of key components and services in an OpenStack cloud. The guide also describes five common cloud use cases. Before reading this book, we recommend: • Prior knowledge of cloud architecture and principles. • Linux and virtualization experience. • A basic understanding of networking principles and protocols. For information about deploying and operating OpenStack, see the Installation Tutorials and Guides, Deploy- ment Guides, and the OpenStack Operations Guide. 2 CONTENTS Conventions The OpenStack documentation uses several typesetting conventions. Notices Notices take these forms: Note: A comment with additional information that explains a part of the text. Important: Something you must be aware of before proceeding. Tip: An extra but helpful piece of practical advice. Caution: Helpful information that prevents the user from making mistakes. Warning: Critical information about the risk of data loss or security issues. Command prompts $ command Any user, including the root user, can run commands that are prefixed with the $ prompt. # command The root user must run commands that are prefixed with the # prompt. You can also prefix these commands with the sudo command, if available, to run them. Architecture requirements This chapter describes the enterprise and operational factors that impacts the design of an OpenStack cloud. 3 Architecture Design Guide (Release Version: 15.0.0) Enterprise requirements The following sections describe business, usage, and performance considerations for customers which will impact cloud architecture design. Cost Financial factors are a primary concern for any organization. Cost considerations may influence the type of cloud that you build. For example, a general purpose cloud is unlikely to be the most cost-effective environment for specialized applications. Unless business needs dictate that cost is a critical factor, cost should not be the sole consideration when choosing or designing a cloud. As a general guideline, increasing the complexity of a cloud architecture increases the cost of building and maintaining it. For example, a hybrid or multi-site cloud architecture involving multiple vendors and technical architectures may require higher setup and operational costs because of the need for more sophisticated orches- tration and brokerage tools than in other architectures. However, overall operational costs might be lower by virtue of using a cloud brokerage tool to deploy the workloads to the most cost effective platform. Consider the following costs categories when designing a cloud: • Compute resources • Networking resources • Replication • Storage • Management • Operational costs It is also important to consider how costs will increase as your cloud scales. Choices that have a negligible impact in small systems may considerably increase costs in large systems. In these cases, it is important to min- imize capital expenditure (CapEx) at all layers of the stack. Operators of massively scalable OpenStack clouds require the use of dependable commodity hardware and freely available open source software components to reduce deployment costs and operational expenses. Initiatives like Open Compute (more information available in the Open Compute Project) provide additional information. Time-to-market The ability to deliver services or products within a flexible time frame is a common business factor when building a cloud. Allowing users to self-provision and gain access to compute, network, and storage resources on-demand may decrease time-to-market for new products and applications. You must balance the time required to build a new cloud platform against the time saved by migrating users away from legacy platforms. In some cases, existing infrastructure may influence your architecture choices. For example, using multiple cloud platforms may be a good option when there is an existing investment in several applications, as it could be faster to tie the investments together rather than migrating the components and refactoring them to a single platform. 4 Architecture requirements Architecture Design Guide (Release Version: 15.0.0) Revenue opportunity Revenue opportunities vary based on the intent and use case of the cloud. The requirements of a commer- cial, customer-facing product are often very different from an internal, private cloud. You must consider what features make your design most attractive to your users. Capacity planning and scalability Capacity and the placement of workloads are key design considerations for clouds. A long-term capacity plan for these designs must incorporate growth over time to prevent permanent consumption of more expensive external clouds. To avoid this scenario, account for future applications’ capacity requirements and plan growth appropriately. It is difficult to predict the amount of load a particular application might incur if the number of users fluctuates, or the application experiences an unexpected increase in use. It is possible to define application requirements in terms of vCPU, RAM, bandwidth, or other resources and plan appropriately. However, other clouds might not use the same meter or even the same oversubscription rates. Oversubscription is a method to emulate more capacity than may physically be present. For example, a physical hypervisor node with 32 GB RAM may host 24 instances, each provisioned with 2 GB RAM. As long as all 24 instances do not concurrently use 2 full gigabytes, this arrangement works well. However, some hosts take oversubscription to extremes and, as a result, performance can be inconsistent. If at all possible, determine what the oversubscription rates of each host are and plan capacity accordingly. Performance Performance is a critical consideration when designing any cloud, and becomes increasingly important as size and complexity grow. While single-site, private clouds can be closely controlled, multi-site and hybrid deploy- ments require more careful planning to reduce problems such as network latency between sites. For example, you should consider the time required to run a workload in different clouds and methods for reducing this time. This may require moving data closer to applications or applications closer to the data they process, and grouping functionality so that connections that require low latency take place over a single cloud rather than spanning clouds. This may also require a CMP that can determine which cloud can most efficiently run which types of workloads. Using native OpenStack tools can help improve performance. For example, you can use Telemetry to measure performance and the Orchestration service (heat) to react to changes in demand. Note: Orchestration requires special client configurations to integrate with Amazon Web Services. For other types of clouds, use CMP features. Cloud resource deployment The cloud user expects repeatable, dependable, and deterministic processes for launching and deploying cloud resources. You could deliver this through a web-based interface or pub- licly available API endpoints. All appropriate options for requesting cloud resources must be available through some type of user interface, a command-line interface (CLI), or API endpoints. Consumption model Cloud users expect a fully self-service and on-demand consumption model. When an OpenStack cloud reaches the massively scalable size, expect consumption as a service in each and every way. Architecture requirements 5 Architecture Design Guide (Release Version: 15.0.0) • Everything must be capable of automation. For example, everything from compute hardware, storage hardware, networking hardware, to the installation and configuration of the supporting software. Manual processes are impractical in a massively scalable OpenStack design architecture. • Massively scalable OpenStack clouds require extensive metering and monitoring functionality to maximize the operational efficiency by keeping the operator informed about the status and state of the infrastructure. This includes full scale metering of the hardware and software status. A corresponding framework of logging and alerting is also required to store and enable operations to act on the meters provided by the metering and monitoring solutions. The cloud operator also needs a solution that uses the data provided by the metering and monitoring solution to provide capacity planning and capacity trending analysis. Location For many use cases the proximity of the user to their workloads has a direct influence on the per- formance of the application and therefore should be taken into consideration in the design. Certain ap- plications require zero to minimal latency that can only be achieved by deploying the cloud in multiple locations. These locations could be in different data centers, cities, countries or geographical