40,79 €
The Fourth Edition of the industry-acclaimed OpenStack Cloud Computing Cookbook, from four recognized experts, updated to the latest OpenStack build including Cinder, Nova, and Neutron.
This is the fourth edition of the industry-acclaimed OpenStack Cloud Computing Cookbook, created by four recognized OpenStack experts. It has now been updated to work with the latest OpenStack builds, using tools and processes based on their collective and vast OpenStack experience.
OpenStack Open Source Cloud software is one of the most used cloud infrastructures to support a wide variety of use cases, from software development to big data analysis. It is developed by a thriving community of individual developers from around the globe and backed by most of the leading players in the cloud space today. We make it simple to implement, massively scalable, and able to store a large pool of data and networking resources. OpenStack has a strong ecosystem that helps you provision your cloud storage needs. Add OpenStack's enterprise features to reduce the cost of your business.
This book will begin by showing you the steps to build up an OpenStack private cloud environment using Ansible. You'll then discover the uses of cloud services such as the identity service, image service, and compute service. You'll dive into Neutron, the OpenStack Networking service, and get your hands dirty with configuring networks, routers, load balancers, and more.
You’ll then gather more expert knowledge on OpenStack cloud computing by managing your cloud's security and migration. After that, we delve into OpenStack Object storage and you’ll see how to manage servers and work with objects, cluster, and storage functionalities. Finally, you will learn about OpenStack dashboard, Ansible, Keystone, and other interesting topics.
This book is written for cloud system engineers, system administrators, and technical architects who are moving from a virtualized environment to cloud environments. This book assumes that you are familiar with cloud computing platforms, and have knowledge of virtualization, networking, and managing Linux environments.
Kevin Jackson: Kevin Jackson is married and has three children. He is an IT professional with over 20 years of experience, working with businesses and enterprises of all sizes at Rackspace, as an OpenStack and private cloud specialist. Kevin has been working with OpenStack since the fist release, and he has extensive experience of various flavors of Linux, Unix, and hosting environments. Kevin authored the fist edition of this book, and coauthored the second and third editions. Kevin also coauthored OpenStack Architecture Design Guide, OpenStack Foundation, during a 5-day book sprint in California. He also regularly speaks at OpenStack community events. Cody Bunch: Cody Bunch is a principal architect in the Rackspace Private Cloud group, based out of San Antonio, Texas. Cody has been working with OpenStack since early 2012, coauthored the second edition of this book, and also coauthored OpenStack Security Guide, OpenStack Foundation. Cody has extensive experience with virtualized and cloud environments in variously sized enterprises and hosting environments. Egle Sigler: Egle Sigler is an OpenStack Foundation board member and a principal architect in the Rackspace Private Cloud group, based out of San Antonio, Texas. Egle holds an MS degree in computer science. She started her career as a software developer and still has a soft spot for all the people who write, test, and deploy code, since she has had the chance to do all of these tasks throughout her career. Egle dreams about a day when writing, testing, and deploying code will be a seamless and easy process—bug and frustration free for all. Egle believes that knowledge should be shared and has tried to do this by writing this book, giving talks and workshops at conferences, and blogging. James Denton: James Denton is a principal architect at Rackspace with over 15 years of experience in systems administration and networking. He has a bachelor’s degree in Business Management with a focus in Computer Information Systems from Texas State University in San Marcos, Texas. He is currently focused on OpenStack operations and support within the Rackspace Private Cloud team. James is the author of the Learning OpenStack Networking (Neutron), first and second editions, as well as OpenStack Networking Essentials both by Packt Publishing.Sie lesen das E-Book in den Legimi-Apps auf:
Seitenzahl: 366
Veröffentlichungsjahr: 2018
Copyright © 2018 Packt Publishing
All rights reserved. No part of this book may be reproduced, stored in a retrieval system, or transmitted in any form or by any means, without the prior written permission of the publisher, except in the case of brief quotations embedded in critical articles or reviews.
Every effort has been made in the preparation of this book to ensure the accuracy of the information presented. However, the information contained in this book is sold without warranty, either express or implied. Neither the authors, nor Packt Publishing or its dealers and distributors, will be held liable for any damages caused or alleged to have been caused directly or indirectly by this book.
Packt Publishing has endeavored to provide trademark information about all of the companies and products mentioned in this book by the appropriate use of capitals. However, Packt Publishing cannot guarantee the accuracy of this information.
Commissioning Editor: Dominic Shakeshaft
Acquisition Editor: Dominic Shakeshaft
Project Editor: Radhika Atitkar
Technical Editor: Nidhisha Shetty
Proofreader: Tom Jacob
Indexer: Pratik Shirodkar
Graphics: Tania Dutta
Production Coordinator: Arvindkumar Gupta
First published: September 2012
Second edition: October 2013
Third edition: August 2015
Fourth edition: January 2018
Production reference: 2230118
Published by Packt Publishing Ltd.
Livery Place
35 Livery Street
Birmingham B3 2PB, UK.
ISBN 978-1-78839-876-3
www.packtpub.com
To my mum, who is stronger than cancer
--Kevin JacksonTo Kevin’s mum, who is stronger than cancer
--Cody BunchTo Kevin’s mum, who is stronger than cancer
--Egle Siglermapt.io
Mapt is an online digital library that gives you full access to over 5,000 books and videos as well as industry leading tools to help you plan your personal development and advance your career. For more information, please visit our website.
Did you know that Packt offers eBook versions of every book published, with PDF and ePub files available? You can upgrade to the eBook version at www.PacktPub.com, and as a print book customer, you are entitled to a discount on the eBook copy. For more details, get in touch with us at <[email protected]>.
At www.PacktPub.com, you can also read a collection of free technical articles, sign up for a range of free newsletters, and receive exclusive discounts and offers on Packt books and eBooks.
Kevin Jackson is married and has three children. He is an IT professional with over 20 years of experience, working with businesses and enterprises of all sizes at Rackspace, as an OpenStack and private cloud specialist. Kevin has been working with OpenStack since the first release, and he has extensive experience of various flavors of Linux, Unix, and hosting environments. Kevin authored the first edition of this book, and coauthored the second and third editions. Kevin also coauthored OpenStack Architecture Design Guide, OpenStack Foundation, during a 5-day book sprint in California. He also regularly speaks at OpenStack community events.
Cody Bunch is a principal architect in the Rackspace Private Cloud group, based out of San Antonio, Texas. Cody has been working with OpenStack since early 2012, coauthored the second edition of this book, and also coauthored OpenStack Security Guide, OpenStack Foundation. Cody has extensive experience with virtualized and cloud environments in variously sized enterprises and hosting environments.
Egle Sigler is an OpenStack Foundation board member and a principal architect in the Rackspace Private Cloud group, based out of San Antonio, Texas. Egle holds an MS degree in computer science. She started her career as a software developer and still has a soft spot for all the people who write, test, and deploy code, since she has had the chance to do all of these tasks throughout her career. Egle dreams about a day when writing, testing, and deploying code will be a seamless and easy process—bug and frustration free for all. Egle believes that knowledge should be shared and has tried to do this by writing this book, giving talks and workshops at conferences, and blogging.
I would like to thank my husband and daughter for their unwavering support and love. Roy and Elena, you make everything better! I ask for forgiveness from my friends and family, who didn’t get to talk to me very much while I was working on this book.
OpenStack developers, quality engineers, operators, users, and documentation writers, thank you all for making OpenStack better each day!
Kevin, Cody, and James, thank you for bringing me along on this adventure! I cannot believe how much quality work was put into this book.
Technical reviewers, thank you for volunteering hundreds of hours to review everything.
Reviewers and editors from Packt, thank you for your prompt communication and constant feedback. Rackers, thank you for your advice and guidance. Lastly, thanks to Rackspace for supporting my writing endeavors.
James Denton is a principal architect at Rackspace with over 15 years of experience in systems administration and networking. He has a bachelor’s degree in Business Management with a focus in Computer Information Systems from Texas State University in San Marcos, Texas. He is currently focused on OpenStack operations and support within the Rackspace Private Cloud team. James is the author of the Learning OpenStack Networking (Neutron), first and second editions, as well as OpenStack Networking Essentials both by Packt Publishing.
I’d like to thank my wife, Amanda, for providing time, encouragement, and patience throughout the writing of this book. I would also like to thank my team at Rackspace for providing valuable feedback and experience.
Without NASA, Rackspace, and countless other contributors to OpenStack, none of this would have been possible. To the developers, operators, and users of OpenStack I say, "Thank you!"
Christian Ashby has a broad range of experience working with the architecture of Cloud environments - with every definition from "someone else’s data center" to serverless / no-ops public cloud and PaaS environments. With a background in large IT outsourcing designing scale-up compute and storage solutions, Christian has been focusing more and more on Cloud architectures and assisting his customers find their route to the Cloud and modern IT practices. OpenStack has always been one of the components of this customer journey, and Christian is pleased to see it move deeper into the Enterprise space with later releases, and hopes that this trend continues.
I would like to thank Kevin Jackson for recommending me to review the book; it’s been a good experience and it’s been great working with the team.
Stefano Canepa is an information and communication technology professional with more then 20 years of various experiences. Stefano’s main interest now is cloud computing with a special focus on OpenStack, its management, and centralized logging solutions. He started working as system administrator in one of the first internet service providers established in Italy. At that time, it was natural to install applications you needed from source code, so he learnt programming on Unix. He started looking after Windows systems and, at his new company, Stefano was involved in the deployment and administration of a huge network of Windows NT computers spread all over Italy. He continued his career moving to network design and testing. He then turned into a full time software developer, and for a while Stefano wrote applications to control medical devices. He moved to a new company and switched to write railways’ centralized traffic control GUI applications. After that experience, Stefano was hired as the system software engineer to manage clouds in a team of professionals coming from all over the world.
Ricky Donato is an NFV/SDN solutions architect, with a passion for open source and an unhealthy love for Costa coffee. In his 23 years in the industry, his technical experience has covered networking design, development, network security, and OpenStack.
Geoff Higginbottom is an OpenStack specialist architect at Rackspace, where he is responsible for designing OpenStack Clouds for customers. Prior to Rackspace, Geoff was the technical cofounder, CTO, and cloud architect at a boutique cloud consultancy, where he designed numerous public and private cloud deployments. Geoff’s technical career started with real-time computer systems while serving in the Royal Navy as a computer engineer in the 90s, and it has now spanned to almost every facet of IT. Geoff is a keen sailor, scuba diver, motorcyclist, and amateur photographer, and his ambition is to one day sail around the world!
Andrew McCrae works as a software developer at Rackspace, in the Rackspace Private Cloud team, working specifically on Ceph storage solutions. He was the project technical lead for the OpenStack-Ansible project for the Ocata and Pike cycles. Andy began his career in 2007 at Rackspace, as a Linux systems administrator, after completing a masters in Engineering, majoring Computer Science at University College London (UCL). Andy specializes in distributed storage, specifically Swift (OpenStack Object Storage), and Ceph, as well as in deployment automation using tools such as Ansible and Chef. He was previously a core reviewer on the Chef-OpenStack project. Andy was also a reviewer on the third edition of OpenStack Cloud Computing Cookbook, Packt Publishing.
Wojciech Sciesinski is an IT professional with 15 years of experience in a broad range of technologies, namely Microsoft Windows, Microsoft Exchange Server, PowerShell, Linux, automation, virtualization, and cloud-related tools, and roles, particularly, a support engineer, architect, and developer. Wojciech is curious about new things, especially when they are open source and complicated enough to not be boring.
If you’re interested in becoming an author for Packt, please visit authors.packtpub.com and apply today. We have worked with thousands of developers and tech professionals, just like you, helping them share their insight with the global tech community. You can make a general application, apply for a specific hot topic that we are recruiting an author for, or submit your own idea.
OpenStack is the open source software for building public and private clouds, and privately hosted software-defined infrastructure services. It is a global open source success and is developed and supported by thousands of people around the globe and backed by leading players in the cloud space today. This book is specifically designed to quickly help you get up to speed with OpenStack and give you the confidence and understanding to roll it out into your own datacenters. This book covers an installation of OpenStack using Ansible, into your datacenters, in addition to providing steps for running under so that you can quickly gain the knowledge needed to install and operate OpenStack today. This book has been written by four principal level OpenStack engineers and architects from Rackspace, and it covers a wide range of topics that help you install and configure your OpenStack environments. This book will guide you in the following things:
This book gives you clear, step-by-step instructions to install and run your own private cloud successfully. It is full of practical and applicable recipes that enable you to use the latest capabilities of OpenStack and implement them.
This book is aimed at system administrators and technical architects moving from a virtualized environment to cloud environments who are familiar with cloud computing platforms. Knowledge of virtualization and managing Linux environments is expected. Prior knowledge or experience of OpenStack is not required, although beneficial.
Chapter 1, Installing OpenStack with Ansible, walks you through a practical installation of OpenStack using OpenStack-Ansible.
Chapter 2, The OpenStack Client, shows you how to install the tools needed to operate OpenStack, as well as providing a quick reference to commonly used commands.
Chapter 3, Keystone – OpenStack Identity Service, explains how to use Keystone to configure and maintain services and projects within OpenStack.
Chapter 4, Neutron – OpenStack Networking, covers the introduction and use of the software-defined networking service and its plugins.
Chapter 5, Nova – OpenStack Compute, works through a number of examples of running and operating virtual machine instances to run your applications.
Chapter 6, Glance – OpenStack Image Service, explores the use of the machine images that are used to spawn instances.
Chapter 7, Cinder – OpenStack Block Storage, presents how to work with block storage volumes to attach to your instances.
Chapter 8, Swift – OpenStack Object Storage, depicts how to use the highly available and redundant object storage service.
Chapter 9, OpenStack Orchestration Using Heat and Ansible, discusses how to begin orchestrating your workloads within OpenStack using both Heat and Ansible.
Chapter 10, Using OpenStack Dashboard, shows you how to navigate the Horizon user-interface dashboard.
To use this book, you will need access to computers or servers that have hardware virtualization capabilities. Familiarity of Linux and accessing Linux servers using SSH is expected.
To set up the lab environment described at the end of Chapter 1, Installing OpenStack with Ansible, you will need to install and use Oracle’s VirtualBox and Vagrant. You can access details of how to set up your computer using VirtualBox and Vagrant by visiting https://github.com/OpenStackCookbook/vagrant-openstack.
There are additional recipes to get you started with the lab environment available at http://www.openstackcookbook.com. Refer to this website for information on installation of supporting software such as MariaDB/MySQL. More information can be found at http://bit.ly/OpenStackCookbookPreReqs.
You can download the example code files for this book from your account at http://www.packtpub.com. If you purchased this book elsewhere, you can visit http://www.packtpub.com/support and register to have the files emailed directly to you.
You can download the code files by following these steps:
Once the file is downloaded, make sure that you unzip or extract the folder using the latest version of one of these:
The code bundle for the book is also hosted on GitHub at https://github.com/PacktPublishing/OpenStack-Cloud-Computing-Cookbook-Fourth-Edition. We also have other code bundles from our rich catalog of books and videos available at https://github.com/PacktPublishing/. Check them out!
We also provide a PDF file that has color images of the screenshots/diagrams used in this book. You can download it here: https://www.packtpub.com/sites/default/files/downloads/OpenStackCloudComputingCookbookFourthEdition_ColorImages.pdf.
There are a number of text conventions used throughout this book.
CodeInText: Indicates code words in text, database table names, folder names, filenames, file extensions, pathnames, dummy URLs, user input, and Twitter handles. Here is an example: Configuration of the host’s networking, on a Ubuntu system, is performed by editing the /etc/network/interfaces file.A block of code is set as follows:
When we wish to draw your attention to a particular part of a code block, the relevant lines or items are set in bold:
Any command-line input or output is written as follows:
Bold: Indicates a new term, an important word, or words that you see on the screen, for example, in menus or dialog boxes, also appear in the text like this. Here is an example: "Next choose Advanced system settings from the menu on the left."
Warnings or important notes appear in a box like this.
Tips and tricks appear like this.
In this book, you will find several headings that appear frequently (Getting ready, How to do it..., How it works..., There’s more..., and See also).
To give clear instructions on how to complete a recipe, use these sections as follows:
This section tells you what to expect in the recipe and describes how to set up any software or any preliminary settings required for the recipe.
This section contains the steps required to follow the recipe.
This section usually consists of a detailed explanation of what happened in the previous section.
This section consists of additional information about the recipe in order to make you more knowledgeable about the recipe.
This section provides helpful links to other useful information for the recipe.
Feedback from our readers is always welcome.
General feedback: Email <[email protected]> and mention the book’s title in the subject of your message. If you have questions about any aspect of this book, please email us at <[email protected]>.
Errata: Although we have taken every care to ensure the accuracy of our content, mistakes do happen. If you have found a mistake in this book we would be grateful if you would report this to us. Please visit, http://www.packtpub.com/submit-errata, selecting your book, clicking on the Errata Submission Form link, and entering the details.
Piracy: If you come across any illegal copies of our works in any form on the Internet, we would be grateful if you would provide us with the location address or website name. Please contact us at [email protected] with a link to the material.
If you are interested in becoming an author: If there is a topic that you have expertise in and you are interested in either writing or contributing to a book, please visit http://authors.packtpub.com.
Please leave a review. Once you have read and used this book, why not leave a review on the site that you purchased it from? Potential readers can then see and use your unbiased opinion to make purchase decisions, we at Packt can understand what you think about our products, and our authors can see your feedback on their book. Thank you!
For more information about Packt, please visit packtpub.com.
In this chapter, we will cover the following topics:
OpenStack is a suite of projects that combine into a software-defined environment to be consumed using cloud friendly tools and techniques. The popular open source software allows users to easily consume compute, network, and storage resources that have been traditionally controlled by disparate methods and tools by various teams in IT departments, big and small. While consistency of APIs can be achieved between versions of OpenStack, an administrator is free to choose which features of OpenStack to install, and as such there is no single method or architecture to install the software. This flexibility can lead to confusion when choosing how to deploy OpenStack. That said, it is universally agreed that the services that the end users interact with—the OpenStack services, supporting software (such as the databases), and APIs—must be highly available.
A very popular method for installing OpenStack is the OpenStack-Ansible project (https://github.com/openstack/openstack-ansible). This method of installation allows an administrator to define highly available controllers together with arrays of compute and storage, and through the use of Ansible, deploy OpenStack in a very consistent way with a small amount of dependencies. Ansible is a tool that allows for system configuration and management that operates over standard SSH connections. Ansible itself has very few dependencies, and as it uses SSH to communicate, most Linux distributions and networks are well-catered for when it comes to using this tool. It is also very popular with many system administrators around the globe, so installing OpenStack on top of what they already know lowers the barrier to entry for setting up a cloud environment for their enterprise users.
OpenStack can be architected in any number of ways; OpenStack-Ansible doesn't address the architecture problem directly: users are free to define any number of controller services (such as Horizon, Neutron Server, Nova Server, and MySQL). Through experience at Rackspace and feedback from users, a popular architecture is defined, which is shown here:
Figure 1: Recommended OpenStack architecture used in this book
As shown in the preceding diagram (Figure 1), there are a few concepts to first understand. These are described as follows.
The controllers (also referred to as infrastructure or infra nodes) run the heart of the OpenStack services and are the only servers exposed (via load balanced pools) to your end users. The controllers run the API services, such as Nova API, Keystone API, and Neutron API, as well as the core supporting services such as MariaDB for the database required to run OpenStack, and RabbitMQ for messaging. It is this reason why, in a production setting, these servers are set up as highly available as required. This means that these are deployed as clusters behind (highly available) load balancers, starting with a minimum of 3 in the cluster. Using odd numbers starting from 3 allows clusters to lose a single server without and affecting service and still remain with quorum (minimum numbers of votes needed). This means that when the unhealthy server comes back online, the data can be replicated from the remaining 2 servers (which are, between them, consistent), thus ensuring data consistency.
Networking is recommended to be highly resilient, so ensure that Linux has been configured to bond or aggregate the network interfaces so that in the event of a faulty switch port, or broken cable, your services remain available. An example networking configuration for Ubuntu can be found in Appendix A.
These are the servers that run the hypervisor or container service that OpenStack schedules workloads to when a user requests a Nova resource (such as a virtual machine). These are not too dissimilar to hosts running a hypervisor, such as ESXi or Hyper-V, and OpenStack Compute servers can be configured in a very similar way, optionally using shared storage. However, most installations of OpenStack forgo the need for the use of shared storage in the architecture. This small detail of not using shared storage, which implies the virtual machines run from the hard disks of the compute host itself, can have a large impact on the users of your OpenStack environment when it comes to discussing the resiliency of the applications in that environment. An environment set up like this pushes most of the responsibility for application uptime to developers, which gives the greatest flexibility of a long-term cloud strategy. When an application relies on the underlying infrastructure to be 100% available, the gravity imposed by the infrastructure ties applications to specific data center technology to keep it running. However, OpenStack can be configured to introduce shared storage such as Ceph (http://ceph.com/) to allow for operational features such as live-migration (the ability to move running instances from one hypervisor to another with no downtime), allowing enterprise users move their applications to a cloud environment in a very safe way. These concepts will be discussed in more detail in later chapters on compute and storage. As such, the reference architecture for a compute node is to expect virtual machines to run locally on the hard drives in the server itself.
With regard to networking, like the controllers, the network must also be configured to be highly available. A compute node that has no network available might be very secure, but it would be equally useless to a cloud environment! Configure bonded interfaces in the same way as the controllers. Further information for configuring bonded interfaces under Ubuntu can be found in Appendix A.
Storage in OpenStack refers to block storage and object storage. Block storage (providing LUNs or hard drives to virtual machines) is provided by the Cinder service, while object storage (API driven object or blobs of storage) is provided by Swift or Ceph. Swift and Ceph manage each individual drive in a server designated as an object storage node, very much like a RAID card manages individual drives in a typical server. Each drive is an independent entity that Swift or Ceph uses to write data to. For example, if a storage node has 24 x 2.5in SAS disks in, Swift or Ceph will be configured to write to any one of those 24 disks. Cinder, however, can use a multitude of backends to store data. For example, Cinder can be configured to communicate with third-party vendors such as NetApp or Solidfire arrays, or it can be configured to talk to Sheepdog or Ceph, as well as the simplest of services such as LVM. In fact, OpenStack can be configured in such a way that Cinder uses multiple backends so that a user is able to choose the storage applicable to the service they require. This gives great flexibility to both end users and operators as it means workloads can be targeted at specific backends suitable for that workload or storage requirement.
This book briefly covers Ceph as the backend storage engine for Cinder. Ceph is a very popular, highly available open source storage service. Ceph has its own disk requirements to give the best performance. Each of the Ceph storage nodes in the preceding diagram are referred to as Ceph OSDs (Ceph Object Storage Daemons). We recommend starting with 5 of these nodes, although this is not a hard and fast rule. Performance tuning of Ceph is beyond the scope of this book, but at a minimum, we would highly recommend having SSDs for Ceph journaling and either SSD or SAS drives for the OSDs (the physical storage units).
The differences between a Swift node and a Ceph node in this architecture are very minimal. Both require an interface (bonded for resilience) for replication of data in the storage cluster, as well as an interface (bonded for resilience) used for data reads and writes from the client or service consuming the storage.
The primary difference is the recommendation to use SSDs (or NVMe) as the journaling disks.
The end users of the OpenStack environment expect services to be highly available, and OpenStack provides REST API services to all of its features. This makes the REST API services very suitable for placing behind a load balancer. In most deployments, load balancers would usually be highly available hardware appliances such as F5. For the purpose of this book, we will be using HAProxy. The premise behind this is the same though—to ensure that the services are available so your end users can continue working in the event of a failed controller node.
Operating installing System: Ubuntu 16.04 x86_64
For a physical installation, the following will be needed:
Tip: Setting up a physical home lab? Ensure you have a managed switch so that interfaces can have VLANs tagged.
Installation of OpenStack using an orchestration and configuration tool such as Ansible performs a lot of tasks that would otherwise have to be undertaken manually. However, we can only use an orchestration tool if the servers we are deploying to are configured in a consistent way and described to Ansible.
The following section will describe a typical server setup that uses two sets of active/passive bonded interfaces for use by OpenStack. Ensure that these are cabled appropriately.
We assume that the following physical network cards are installed in each of the servers; adjust them to suit your environment:
We assume that the host network is currently using p2p1. The host network is the basic network that each of the servers currently resides on, and it allows you to access each one over SSH. It is assumed that this network also has a default gateway configured, and allows internet access. There should be no other networks required at this point as the servers are currently unconfigured and are not running OpenStack services.
At the end of this section, we will have created the following bonded interfaces:
We will have created the following VLAN tagged interfaces:
And the following bridges: