OpenStack for Architects

Design production-ready private cloud infrastructure, 2nd Edition

Ben Silverman, Michael Solberg

• Editore: Packt Publishing
• Anno: 2018
• ISBN:
  9781788628150
• Edizione: 2
• Argomento: Informatica
• Categoria: Elaborazione di dati su cloud

Implement successful private clouds with OpenStackAbout This Book• Gain hands-on experience in designing a private cloud for all infrastructures• Create a robust virtual environment for your organization• Design, implement and deploy an OpenStack-based cloud based on the Queens releaseWho This Book Is ForOpenStack for Architects is for Cloud architects who are responsible to design and implement a private cloud with OpenStack. System engineers and enterprise architects will also find this book useful. Basic understanding of core OpenStack services, as well as some working experience of concepts, is recommended.What You Will Learn• Learn the overall structure of an OpenStack deployment• Craft an OpenStack deployment process which fits within your organization• Apply Agile Development methodologies to engineer and operate OpenStack clouds• Build a product roadmap for Infrastructure as a Service based on OpenStack• Make use of containers to increase the manageability and resiliency of applications running in and on OpenStack.• Use enterprise security guidelines for your OpenStack deploymentIn DetailOver the past six years, hundreds of organizations have successfully implemented Infrastructure as a Service (IaaS) platforms based on OpenStack. The huge amount of investment from these organizations, including industry giants such as IBM and HP, as well as open source leaders, such as Red Hat, Canonical, and SUSE, has led analysts to label OpenStack as the most important open source technology since the Linux operating system. Due to its ambitious scope, OpenStack is a complex and fast-evolving open source project that requires a diverse skill set to design and implement it.OpenStack for Architects leads you through the major decision points that you'll face while architecting an OpenStack private cloud for your organization. This book will address the recent changes made in the latest OpenStack release i.e Queens, and will also deal with advanced concepts such as containerization, NVF, and security. At each point, the authors offer you advice based on the experience they've gained from designing and leading successful OpenStack projects in a wide range of industries. Each chapter also includes lab material that gives you a chance to install and configure the technologies used to build production-quality OpenStack clouds. Most importantly, the book focuses on ensuring that your OpenStack project meets the needs of your organization, which will guarantee a successful rollout.Style and approachThis is practical, hands-on guide to implementing OpenStack clouds, where each topic is illustrated with real-world examples and then the technical points are proven in the lab. Conceptual chapters are written in discussion style to convey important concepts quickly and present decision points for choosing options.

Building to Operate

A lot of OpenStack administrators are familiar with more established virtualization platforms. They're familiar with preinstalled operations tools that will allow an administrator to simply point, click, and configure a fully robust infrastructure, monitoring the solution in minutes. Unfortunately, OpenStack is not quite that simple. This doesn't mean it's inferior, quite the contrary; it's very flexible, and allows administrators to choose their own tools and configure them in a way that best suits the needs of the company or organization.

In this chapter, we will discuss day-2 operations, or in other words, what happens after the OpenStack cloud has been built, tested, and is operationally ready. It is at this point that the cloud is ready to onboard production users and workloads.

This chapter sets out to achieve the following:

• A critical insight into what is really important to monitor in an OpenStack cloud.
• A set of best practices to implement in a monitoring system. We will provide some example specifications to get you started and allow you to adjust them to meet your enterprise operation needs.
• Recommendations based on real-life examples of how to do effective capacity planning in an elastic cloud environment such as OpenStack.
• A broad understanding of some of the tools used in OpenStack operations, both open source and commercial.
• Transfer knowledge about future OpenStack operations in regards to artificial intelligence, machine learning, and in multi-cloud environments.

Logging, monitoring, and alerting

One of the most important aspects of operating an OpenStack cloud is logging, monitoring, and alerting (LMA). Since OpenStack isn't your legacy bare-metal-based infrastructure platform, it requires a different approach. The traditional LMA methods tend to fall short when considering the scale and elasticity of an OpenStack environment. Additionally, the old binary methods of alerting this service is down, the resource is at 95%, or even filesystem full messages do not deliver the depth of operational information really required to know the health of an OpenStack cloud. Since a cloud is an amalgamation of resources that are shared across a platform, it is the different services that clouds provide for network, storage, and compute that determines health versus the individual health of the underlying hardware components. In a properly configured HA architecture, OpenStack can withstand multiple underlying failures of infrastructure and only experience a decrease in capacity versus a total outage.

There are many different tools to actually monitor log events and create alerts from the underlying systems running the OpenStack infrastructure. However, in this chapter, we will focus more on the architectural principles that will help you choose your logging, monitoring, and alerting tools.

No matter what is used to do the logging, monitoring, and alerting, from an architectural standpoint, the solution should:

• Provide real-time, or near real-time introspection and alerting of events in the OpenStack infrastructure control layer
• Support some sort of discovery and configuration management
• Be scalable to support production enterprise clouds
• Have the ability to self-monitor and be configurable as highly available

Logging

An essential source of operational data for an OpenStack cloud is log data. Not only are the logs of host operating systems available, but each OpenStack project running as a part of the control plane has a separate log.

While the logs, by default, are sent to syslog and some of their own logs, it's recommended that all logs be sent to syslog under the same syslog log level as a starting point and modified if needed. This recommendation provides the greatest flexibility moving forward.

The following is an example of a successful operation in an OpenStack log entry from nova-api.log:

2017-07-08 07:36:45.613 3474 INFO nova.osapi_compute.wsgi.server [req- b5ff3321-19cc-4ce8-af9c-0ed59ae21ac7 f32900acc09d4898b091b2caa4900112 6f0117ddd81b4dc78a8f4ce4dd5b04f5 - - -] 10.0.3.15 "GET /v2/6f0117ddd81b4dc78a8f4ce4dd5b04f5/flavors/1 HTTP/1.1" status: 200 len: 613 time: 0.1168451 

For security and analysis, all logs should be sent to a remote centralized syslog server. Ideally, this server will be where the log introspection, analytics, and cataloging will be done, and it should be hosted on a server with appropriate CPU and memory to support these workloads. Log introspection would be done on the content of the log entries as these logs can contain some, or all of the following (the example is based on the preceding log):

• Severity levels (INFO)
• The server that sent the log (10.0.3.15)
• The service that sent the log (nova.osapi_compute.wsgi.server)
• Metadata such as tenant_id and request_id (6f0117ddd81b4dc78a8f4ce4dd5b04f5 and req-b5ff3321-19cc-4ce8-af9c-0ed59ae21ac7)

Request IDs are an integral part of troubleshooting OpenStack issues. They are generated each time a request is made of an OpenStack service. There are two different types of request IDs, global request IDs, and local request IDs. The main difference is that local requ...