Book Image

Mastering OpenStack - Second Edition

By : Omar Khedher, Chandan Dutta
Book Image

Mastering OpenStack - Second Edition

By: Omar Khedher, Chandan Dutta

Overview of this book

In this second edition, you will get to grips with the latest features of OpenStack. Starting with an overview of the OpenStack architecture, you'll see how to adopt the DevOps style of automation while deploying and operating in an OpenStack environment. We'll show you how to create your own OpenStack private cloud. Then you'll learn about various hypervisors and container technology supported by OpenStack. You'll get an understanding about the segregation of compute nodes based on reliability and availability needs. We'll cover various storage types in OpenStack and advanced networking aspects such as SDN and NFV. Next, you'll understand the OpenStack infrastructure from a cloud user point of view. Moving on, you'll develop troubleshooting skills, and get a comprehensive understanding of services such as high availability and failover in OpenStack. Finally, you will gain experience of running a centralized logging server and monitoring OpenStack services. The book will show you how to carry out performance tuning based on OpenStack service logs. You will be able to master OpenStack benchmarking and performance tuning. By the end of the book, you'll be ready to take steps to deploy and manage an OpenStack cloud with the latest open source technologies.
Table of Contents (13 chapters)

Two eyes are better than one eye

OpenStack produces tons of log files in a real production environment. It becomes harder for a cloud operating team to analyze and parse them by extracting data in each file using a combination of tail, grep, and perl tools. The more hosts you build, the more logs you have to manage. Growing a few paces should be companioned by a serious trace keeper. To overcome such a challenge, your log environment must evolve to become centralized. A good option can be by starting flowing logs in a dedicated rsyslog server. You may put in so much data and your log server start starving for larger storage capacity. Furthermore, archiving the former data will not be handy when you need to extract information for a particular context. Additionally, correlating logs data having different format (taking into consideration RabbitMQ and MySQL logs) with generated events might be even impossible. So...