29,99 €
Mehr erfahren.
- Herausgeber: Packt Publishing
- Kategorie: Wissenschaft und neue Technologien
- Sprache: Englisch
Untangle the complexity of OpenStack clouds through this practical tutorial
About This Book
- Navigate through the complex jungle of components in OpenStack using practical instructions
- This book helps administrators, cloud engineers, and even developers to consolidate and control pools of compute, networking, and storage resources
- Learn to use the centralized dashboard and administration panel to monitor large-scale deployments
Who This Book Is For
This book is perfect for administrators, cloud engineers, and operators who want to get started with OpenStack, solve basic problems encountered during deployment, and get up to speed with the latest release of OpenStack. Familiarity with the Linux command line and experience with Linux system administration is expected.
What You Will Learn
- Brush up on the latest release, and how it affects the various components
- Install OpenStack using the Packstack and RDO Manager installation tool
- Learn to convert a computer node that supports Docker containers
- Implement Ceph Block Device images with OpenStack
- Create and allocate virtual networks, routers and IP addresses to OpenStack Tenants.
- Configuring and Launching a Docker container.
In Detail
OpenStack is a widely popular platform for cloud computing. Applications that are built for this platform are resilient to failure and convenient to scale. This book, an update to our extremely popular OpenStack Essentials (published in May 2015) will help you master not only the essential bits, but will also examine the new features of the latest OpenStack release - Mitaka; showcasing how to put them to work straight away.
This book begins with the installation and demonstration of the architecture. This book will tech you the core 8 topics of OpenStack. They are Keystone for Identity Management, Glance for Image management, Neutron for network management, Nova for instance management, Cinder for Block storage, Swift for Object storage, Ceilometer for Telemetry and Heat for Orchestration. Further more you will learn about launching and configuring Docker containers and also about scaling them horizontally. You will also learn about monitoring and Troubleshooting OpenStack.
Style and approach
This book offers step-by-step practical instructions to help you quickly navigate through the complexities of OpenStack
Sie lesen das E-Book in den Legimi-Apps auf:
Seitenzahl: 228
Veröffentlichungsjahr: 2016
Ähnliche
Table of Contents
OpenStack Essentials Second Edition
OpenStack Essentials Second Edition
Copyright © 2016 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 author, nor Packt Publishing, and its dealers and distributors will be held liable for any damages caused or alleged to be 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.
First published: May 2015
Second edition: August 2016
Production reference: 1240816
Published by Packt Publishing Ltd.
Livery Place
35 Livery Street
Birmingham B3 2PB, UK.
ISBN 978-1-78646-266-4
www.packtpub.com
Credits
Author
Dan Radez
Reviewer
Vinoth Kumar Selvaraj
Commissioning Editor
Kartikey Pandey
Acquisition Editor
Divya Poojari
Content Development Editor
Trusha Shriyan
Technical Editor
Nirant Carvalho
Copy Editors
Madhusudan Uchil
Safis Editing
Project Coordinator
Kinjal Bari
Proofreader
Safis Editing
Indexer
Hemangini Bari
Graphics
Kirk D'Penha
Production Coordinator
Shantanu N. Zagade
Cover Work
Shantanu N. Zagade
About the Author
Dan Radez joined the OpenStack community in 2012 in an operator role. His experience is focused on installing, maintaining, and integrating OpenStack clusters. He has been given the opportunity to internationally present OpenStack content to a range of audiences of varying expertise. In January 2015, Dan joined the OPNFV community and has been working to integrate RDO Manager with SDN controllers and the networking features necessary for NFV.
Dan's experience includes web application programming, systems release engineering, and virtualization product development. Most of these roles have had an open source community focus to them. In his spare time, Dan enjoys spending time with his wife and three boys, training for and racing triathlons, and tinkering with electronics projects.
About the Reviewer
Vinoth Kumar Selvaraj works as a DevOps engineer at CD Cloudenablers Pvt Ltd, a cloud technology startup based in Chennai, India.
He has also reviewed Openstack Cloud Security. Learning OpenStack High Availability, and Learning OpenStack (Video), all by Packt Publishing.
In his spare time, Vinoth blogs about OpenStack at his website, http://www.hellovinoth.com, and shares his thoughts via his Twitter handle, @vinoth6664.
I would like to thank my amma, appa, anna, and friends for their love and support.
My special thanks to our Cloudenablers team for giving me this opportunity and motivation to explore things.
www.PacktPub.com
eBooks, discount offers, and more
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. Get in touch with us at <[email protected]> for more details.
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.
https://www2.packtpub.com/books/subscription/packtlib
Do you need instant solutions to your IT questions? PacktLib is Packt's online digital book library. Here, you can search, access, and read Packt's entire library of books.
Why subscribe?
Preface
OpenStack is a widely popular cloud-computing platform. Each of the OpenStack components that will be covered in subsequent chapters will be discussed in this preface. This will give you a high-level overview of these components and how they work together.
This book offers step-by-step practical instructions to help you quickly navigate through the complexities of OpenStack. While the examples in this book are situational, it can also be used as a reference for Linux-related topics and commands. This book provides you with the ability to reference both troubleshooting steps and specific commands for resolving complex issues.
What this book covers
Chapter 1, RDO Installation, presents a standard installation and an advanced installation of the RDO distribution of OpenStack. A demonstration architecture will be defined, and step-by-step instructions will be given.
Chapter 2, Identity Management, talks about Keystone, which is the identity-management component of OpenStack. You will be introduced to basic username-password authentication and the structure of how Keystone manages users, roles, tenants, and services.
Chapter 3, Image Management , talks about Glance, which is the image-management component. The process flow of how images are built, added to the registry, and consumed in the cluster will be presented.
Chapter 4, Network Management, talks about Neutron, which is the network-management component. Neutron can create and allocate virtual networks, routers, and IP addresses to OpenStack tenants. There is system preparation that is necessary for the cluster to allow external connectivity for instances.
Chapter 5, Instance Management, talks about Nova, which is the instance-management component. It is in charge of keeping track of which resources are used on which hypervisors, scheduling new instances for launch, and gathering all the resources necessary for an instance launch.
Chapter 6, Block Storage, talks about Cinder, which is the block storage-management component. It creates volumes and presents them to the instances. This can be done with multiple storage engines.
Chapter 7, Object Storage, talks about Swift, which is the object storage-management component. It creates object containers and manages file objects in the containers. Swift can optionally be backed with storage engines other than the default Swift object storage engine.
Chapter 8, Telemetry, talks about Ceilometer, which is the telemetry and metering component. It monitors the cluster and collects statistics of the resources that are in use.
Chapter 9, Orchestration, talks about Heat, which is the orchestration component. It is able to launch multiple instances and coordinate exchanging information about the instances within a heat stack.
Chapter 10, Docker, talks about containerization, which has become a prominent part of cloud computing. I'll go through the steps it takes to convert a compute node to a compute node that can support Docker containers.
Chapter 11, Scaling Horizontally, tells you how add a compute node and configure HAProxy by simply installing a new node, telling it where the control services are, and starting compute services.
Chapter 12, Monitoring, shows you how to use Nagios to perform basic monitoring.
Chapter 13, Troubleshooting, discusses some of the common issues that will surface while running an OpenStack cluster and where to go to find out where the error messages have been recorded.
What you need for this book
While this book can be used by itself, you can benefit greatly by having a system with Red Hat Enterprise Linux available. The commands and resources discussed in this book are best learned when you have the ability to execute them on a test system. It is highly recommended you use Liberty software.
Who this book is for
This book is perfect for administrators, cloud engineers, and operators who want to get started with OpenStack, solve basic problems encountered during deployment, and get up to speed with the latest release of OpenStack. Familiarity with the Linux command line and experience with Linux system administration is expected.
Conventions
In this book, you will find a number of text styles that distinguish between different kinds of information. Here are some examples of these styles and an explanation of their meaning.
Code words in text, database table names, folder names, filenames, file extensions, pathnames, dummy URLs, user input, and Twitter handles are shown as follows: " In addition to the client package, you will also need the overcloudrc file from the undercloud."
A block of code is set as follows:
Any command-line input or output is written as follows:
New terms and important words are shown in bold. Words that you see on the screen, for example, in menus or dialog boxes, appear in the text like this: "Click on Create User, and you're ready to start using the user's login and the new project."
Note
Warnings or important notes appear in a box like this.
Tip
Tips and tricks appear like this.
Reader feedback
Feedback from our readers is always welcome. Let us know what you think about this book—what you liked or disliked. Reader feedback is important for us as it helps us develop titles that you will really get the most out of.
To send us general feedback, simply e-mail <[email protected]>, and mention the book's title in the subject of your message.
If there is a topic that you have expertise in and you are interested in either writing or contributing to a book, see our author guide at www.packtpub.com/authors.
Customer support
Now that you are the proud owner of a Packt book, we have a number of things to help you to get the most from your purchase.
Errata
Although we have taken every care to ensure the accuracy of our content, mistakes do happen. If you find a mistake in one of our books—maybe a mistake in the text or the code—we would be grateful if you could report this to us. By doing so, you can save other readers from frustration and help us improve subsequent versions of this book. If you find any errata, please report them by visiting http://www.packtpub.com/submit-errata, selecting your book, clicking on the Errata Submission Form link, and entering the details of your errata. Once your errata are verified, your submission will be accepted and the errata will be uploaded to our website or added to any list of existing errata under the Errata section of that title.
To view the previously submitted errata, go to https://www.packtpub.com/books/content/support and enter the name of the book in the search field. The required information will appear under the Errata section.
Piracy
Piracy of copyrighted material on the Internet is an ongoing problem across all media. At Packt, we take the protection of our copyright and licenses very seriously. If you come across any illegal copies of our works in any form on the Internet, please provide us with the location address or website name immediately so that we can pursue a remedy.
Please contact us at <[email protected]> with a link to the suspected pirated material.
We appreciate your help in protecting our authors and our ability to bring you valuable content.
Questions
If you have a problem with any aspect of this book, you can contact us at <[email protected]>, and we will do our best to address the problem.
Chapter 1. RDO Installation
OpenStack has a very modular design, and because of this design, there are lots of moving parts. It is overwhelming to start walking through installing and using OpenStack without understanding the internal architecture of the components that make up OpenStack. In this chapter, we'll look at these components. Each component in OpenStack manages a different resource that can be virtualized for the end user. Separating the management of each of the types of resources that can be virtualized into separate components makes the OpenStack architecture very modular. If a particular service or resource provided by a component is not required, then the component is optional to an OpenStack deployment. Once the components that make up OpenStack have been covered, we will discuss the configuration of a community-supported distribution of OpenStack called RDO.
OpenStack architecture
Let's start by outlining some simple categories to group these services into. Logically, the components of OpenStack are divided into three groups:
The control tier runs the Application Programming Interface (API) services, web interface, database, and message bus. The network tier runs network service agents for networking, and the compute tier is the virtualization hypervisor. It has services and agents to handle virtual machines. All of the components use a database and/or a message bus. The database can be MySQL, MariaDB, or PostgreSQL. The most popular message buses are RabbitMQ, Qpid, and ActiveMQ. For smaller deployments, the database and messaging services usually run on the control node, but they could have their own nodes if required.
In a simple multi-node deployment, the control and networking services are installed on one server and the compute services are installed onto another server. OpenStack could be installed on one node or more than two nodes, but a good baseline for being able to scale out later is to put control and network together and compute by itself. An OpenStack cluster can scale far beyond a few nodes, and we will look at scaling beyond this basic deployment in Chapter 11, Scaling Horizontally.
Now that a base logical architecture of OpenStack has been defined, let's look at what components make up this basic architecture. To do that, we'll first touch on the web interface and then work toward collecting the resources necessary to launch an instance. Finally, we will look at what components are available to add resources to a launched instance.
Dashboard
The OpenStack dashboard is the web interface component provided with OpenStack. You'll sometimes hear the terms dashboard and Horizon used interchangeably. Technically, they are not the same thing. This book will refer to the web interface as the dashboard. The team that develops the web interface maintains both the dashboard interface and the Horizon framework that the dashboard uses.
More important than getting these terms right is understanding the commitment that the team that maintains this code base has made to the OpenStack project. They have pledged to include support for all the officially accepted components that are included in OpenStack. Visit the OpenStack website (http://www.openstack.org/) to get an official list of OpenStack components.
The dashboard cannot do anything that the API cannot do. All the actions that are taken through the dashboard result in calls to the API to complete the task requested by the end user. Throughout this book, we will examine how to use the web interface and the API clients to execute tasks in an OpenStack cluster. Next, we will discuss both the dashboard and the underlying components that the dashboard makes calls to when creating OpenStack resources.
Keystone
Keystone is the identity management component. The first thing that needs to happen while connecting to an OpenStack deployment is authentication. In its most basic installation, Keystone will manage tenants, users, and roles and be a catalog of services and endpoints for all the components in the running cluster.
Everything in OpenStack must exist in a tenant. A tenant is simply a grouping of objects. Users, instances, and networks are examples of objects. They cannot exist outside of a tenant. Another name for a tenant is a project. On the command line, the term tenant is used. In the web interface, the term project is used.
Users must be granted a role in a tenant. It's important to understand this relationship between the user and a tenant via a role. In Chapter 2, Identity Management, we will look at how to create the user and tenant and how to associate the user with a role in a tenant. For now, understand that a user cannot log in to the cluster unless they are a member of a tenant. Even the administrator has a tenant. Even the users the OpenStack components use to communicate with each other have to be members of a tenant to be able to authenticate.
Keystone also keeps a catalog of services and endpoints of each of the OpenStack components in the cluster. This is advantageous because all of the components have different API endpoints. By registering them all with Keystone, an end user only needs to know the address of the Keystone server to interact with the cluster. When a call is made to connect to a component other than Keystone, the call will first have to be authenticated, so Keystone will be contacted regardless.
Within the communication to Keystone, the client also asks Keystone for the address of the component the user intended to connect to. This makes managing the endpoints easier. If all the endpoints were distributed to the end users, then it would be a complex process to distribute a change in one of the endpoints to all of the end users. By keeping the catalog of services and endpoints in Keystone, a change is easily distributed to end users as new requests are made to connect to the components.
By default, Keystone uses username/password authentication to request a token and the acquired tokens for subsequent requests. All the components in the cluster can use the token to verify the user and the user's access. Keystone can also be integrated into other common authentication systems instead of relying on the username and password authentication provided by Keystone. In Chapter 2, Identity Management, each of these resources will be explored. We'll walk through creating a user and a tenant and look at the service catalog.
Glance
Glance is the image management component. Once we're authenticated, there are a few resources that need to be available for an instance to launch. The first resource we'll look at is the disk image to launch from. Before a server is useful, it needs to have an operating system installed on it. This is a boilerplate task that cloud computing has streamlined by creating a registry of pre-installed disk images to boot from. Glance serves as this registry within an OpenStack deployment. In preparation for an instance to launch, a copy of a selected Glance image is first cached to the compute node where the instance is being launched. Then, a copy is made to the ephemeral disk location of the new instance. Subsequent instances launched on the same compute node using the same disk image will use the cached copy of the Glance image.
The images stored in Glance are sometimes called sealed-disk images. These images are disk images that have had the operating system installed but have had things such as the Secure Shell (SSH) host key and network device MAC addresses removed. This makes the disk images generic, so they can be reused and launched repeatedly without the running copies conflicting with each other. To do this, the host-specific information is provided or generated at boot. The provided information is passed in through a post-boot configuration facility called cloud-init.
Usually, these images are downloaded from distribution's download pages. If you search the Internet for your favorite distribution's name and cloud image, you will probably get a link to where to download a generic pre-built copy of a Glance image, also known as a cloud image.
The images can also be customized for special purposes beyond a base operating system installation. If there was a specific purpose for which an instance would be launched many times, then some of the repetitive configuration tasks could be performed ahead of time and built into the disk image. For example, if a disk image was intended to be used to build a cluster of web servers, it would make sense to install a web server package on the disk image before it was used to launch an instance. It would save time and bandwidth to do it once before it is registered with Glance instead of doing this package installation and configuration over and over each time a web server instance is booted.
There are quite a few ways to build these disk images. The simplest way is to do a virtual machine installation manually, make sure that the host-specific information is removed, and include cloud-init in the built image. Cloud-init is packaged in most major distributions; you should be able to simply add it to a package list. There are also tools to make this happen in a more autonomous fashion. Some of the more popular tools are virt-install, Oz, and appliance-creator. The most important thing about building a cloud image for OpenStack is to make sure that cloud-init is installed. Cloud-init is a script that should run post boot to connect back to the metadata service.
In Chapter 3, Image Management, when Glance is covered in greater detail, we will download a pre-built image and use it to demonstrate how Glance works.
Neutron
Neutron is the network management component. With Keystone, we're authenticated, and from Glance, a disk image will be provided. The next resource required for launch is a virtual network. Neutron is an API frontend (and a set of agents) that manages the Software Defined Networking (SDN) infrastructure for you. When an OpenStack deployment is using Neutron, it means that each of your tenants can create virtual isolated networks. Each of these isolated networks can be connected to virtual routers to create routes between the virtual networks. A virtual router can have an external gateway connected to it, and external access can be given to each instance by associating a floating IP on an external network with an instance. Neutron then puts all the configuration in place to route the traffic sent to the floating IP address through these virtual network resources into a launched instance. This is also called Networking as a Service (NaaS). NaaS is the capability to provide networks and network resources on demand via software.
By default, the OpenStack distribution we will install uses Open vSwitch to orchestrate the underlying virtualized networking infrastructure. Open vSwitch is a virtual managed switch. As long as the nodes in your cluster have simple connectivity to each other, Open vSwitch can be the infrastructure configured to isolate the virtual networks for the tenants in OpenStack. There are also many vendor plugins that would allow you to replace Open vSwitch with a physical managed switch to handle the virtual networks. Neutron even has the capability to use multiple plugins to manage multiple network appliances. As an example, Open vSwitch and a vendor's appliance could be used in parallel to manage virtual networks in an OpenStack deployment. This is a great example of how OpenStack is built to provide flexibility and choice to its users.
Networking is the most complex component of OpenStack to configure and maintain. This is because Neutron is built around core networking concepts. To successfully deploy Neutron, you need to understand these core concepts and how they interact with one another. In Chapter 4, Network Management, we'll spend time covering these concepts while building the Neutron infrastructure for an OpenStack deployment.
Nova
Nova is the instance management component. An authenticated user who has access to a Glance image and has created a network for an instance to live on is almost ready to tie all of this together and launch an instance. The last resources that are required are a key pair and a security group. A key pair is simply an SSH key pair. OpenStack will allow you to import your own key pair or generate one to use. When the instance is launched, the public key is placed in the authorized_keys file so that a password-less SSH connection can be made to the running instance.
Before that SSH connection can be made, the security groups have to be opened to allow the connection to be made. A security group is a firewall at the cloud infrastructure layer. The OpenStack distribution we'll use will have a default security group with rules to allow instances to communicate with each other within the same security group, but rules will have to be added for Internet Control Message Protocol (ICMP), SSH, and other connections to be made from outside the security group.
Once there's
