Production Ready OpenStack - Recipes for Successful Environments

4.5 (2 reviews total)
By Arthur Berezin
    What do you get with a Packt Subscription?

  • Instant access to this title and 7,500+ eBooks & Videos
  • Constantly updated with 100+ new titles each month
  • Breadth and depth in over 1,000+ technologies
  1. Introduction to OpenStack and its Deployment Using Packages

About this book

OpenStack is the most popular open source cloud platform used by organizations building internal private clouds and by public cloud providers. OpenStack is designed in a fully distributed architecture to provide Infrastructure as a Service, allowing us to maintain a massively scalable cloud infrastructure. OpenStack is developed by a vibrant community of open source developers who come from the largest software companies in the world.

The book provides a comprehensive and practical guide to the multiple uses cases and configurations that OpenStack supports. This book simplifies the learning process by guiding you through how to install OpenStack in a single controller configuration.

The book goes deeper into deploying OpenStack in a highly available configuration. You’ll then configure Keystone Identity Services using LDAP, Active Directory, or the MySQL identity provider and configure a caching layer and SSL. After that, you will configure storage back-end providers for Glance and Cinder, which will include Ceph, NFS, Swift, and local storage. Then you will configure the Neutron networking service with provider network VLANs, and tenant network VXLAN and GRE.

Also, you will configure Nova’s Hypervisor with KVM, and QEMU emulation, and you will configure Nova’s scheduler filters and weights. Finally, you will configure Horizon to use Apache HTTPD and SSL, and you will customize the dashboard’s appearance.

Publication date:
October 2015
Publisher
Packt
Pages
210
ISBN
9781783986903

 

Chapter 1. Introduction to OpenStack and its Deployment Using Packages

In this chapter, we will cover the following:

  • Configuring host prerequisites

  • Installing MariaDB database

  • Installing RabbitMQ

  • Installing Keystone – Identity service

  • Generating and configuring tokens PKIs

  • Installing Glance – images service

  • Installing Nova – Compute service

  • Installing Neutron networking service

  • Configuring Neutron network node

  • Configuring compute node for Neutron

  • Installing Horizon – web user interface dashboard

 

Introduction


OpenStack is a cloud operating system software that allows running and managing Infrastructure as a Service (IaaS) clouds on the standard commodity hardware. OpenStack is not an operating system of its own, which manages bare metal hardware machines, is a stack of open source software projects. The projects run on top of Linux operating system. The projects usually consist of several components that run as Linux services on top of the operating system.

OpenStack lets users to rapidly deploy instances of virtual machines or Linux containers on the fly, which run different kinds of workloads that serve public online services or deployed privately on company's premise. In some cases, workloads can run both on private environment, and on a public cloud, creating a hybrid model cloud.

OpenStack has a modular architecture. Projects are constructed of functional components. Each project has several components that are responsible for project's sole functionality. An API component exposes its capabilities, functionalities, and objects it manages via standard HTTP Restful API, so it can be consumed as a service by other services and users.

The components are responsible for managing and maintaining services, and the actual implementation of the services leverage exciting technologies such as backend drivers.

Basically, OpenStack is an upper layer management system that leverages existing underlying technologies and presents a standard API layer for services to interconnect and interact.

The computing industry and information technology, in particular, made a major progress in the past 20 year moving toward distributed systems that use common standards. OpenStack is another step forward, introducing a new standard for technologies that were progressing separately in the past two decades, to interconnect in an industry standard manner.

OpenStack projects and components

OpenStack environment consists of projects that provide their functionality as services. Each project is designed to provide a specific function. The core projects are the required services in most OpenStack environments, and in most use cases, an OpenStack environment cannot run without them. Additional projects are optional and provide value and add or fulfill certain functionalities for the cloud.

Core services

Core services provided by OpenStack projects are as follows:

  • Nova compute service, which launches virtual machines.

  • Glance serves operating system template images to Nova.

  • Keystone authenticates and authorizes commands and requests.

  • Neutron is the project that provides networking for the instances as a service. Older releases used Nova-network service to provide networking connectivity to the instance, which is a part of the Nova project, but efforts are made to deprecate Nova-network in favor of Neutron.

Optional services

Optional services provide additional functionality but are not considered as necessary in every OpenStack environment:

  • Horizon is the web user interface dashboard

  • Cinder project provides block storage services

  • Swift provides object storage services

  • Ceilometer provides monitoring and telemetry services for billing and chargeback

  • Heat is OpenStack's orchestration layer

  • Trove provides database services for instances

  • Zaqar provides messaging as a service capability for instances

  • Sahara is a project that delivers Hadoop as a service

The complete list of additional projects is growing rapidly, and every new release has several new projects.

All services use a database service, usually MariaDB to store persistent data, and use a message broker for service inner communication, most commonly, RabbitMQ server.

To better understand this design concept, let's take one project to explore this. Nova is a project that manages the compute resources. Basically, Nova is responsible for launching and managing instances for virtual machines. Nova is implemented via several components such as Linux services. Nova-Compute Linux service is responsible for launching the VM instances. It does not implement a virtualization technology hypervisor, rather it uses a virtualization technology as a supportive backend mechanism, kernel-based virtual machine (KVM) with the libvirt driver in most cases, to launch KVM instances.

Nova API Linux service exposes Nova's capabilities via RESTful API and allows launching new instances, using standard RESTful API calls. To launch new instances, Nova needs a base image to boot from, and Nova makes an API call to Glance, which is the project responsible for serving images.

Architectural layouts

OpenStack consists of several core projects—Nova for compute, Glance for images, Cinder for block storage, Keystone for Identity, Neutron for networking, and additional optional services. Each project exposes all its capabilities via RESTful API. The services inner-communicate over RESTful API calls, so when a service requires resources from another service, it makes a RESTful API call to query services' capabilities, list its resources, or call for a certain action.

Every OpenStack project consists of several components. Each component fulfills a certain functionality or performs a certain task. The components are standard POSIX Linux services, which use a message broker server for inner component communication of that project, using RabbitMQ in most cases. The services save their persistent data and objects states in a database.

All OpenStack services use this modular design. Each services has a component that is responsible to receive API calls, and other components are responsible for performing actions, for example, launching a virtual machine or creating a volume, weighing filters and scheduling, or other tasks that are part of project's functionality.

This design makes OpenStack highly modular; the components of each project can be installed on separate hosts while inner communicating via the message broker. There's no single permutation that fits all use cases OpenStack is used for, but there are a few commonly used layouts. Some layouts are easier for management, some focus on scaling compute resources, other layouts focus on scaling object storage, each with its own benefits and drawbacks.

All-In-One layout

In all-in-one layout, all OpenStack's services and components, including the database, message broker, and Nova-Compute service are installed on a single host. All-in-one layout is mostly used for testing OpenStack or while running proof of concept environments to evaluate functionality. While Nova-Compute nodes can be added for additional compute scalability, this layout introduces risks when using a single node as management plane, storage pool, and compute.

Controller-Neutron-computes layout

In Controller computes layout, all API services and components responsible for OpenStack management are deployed on a node, named OpenStack controller node. This includes Keystone Identity, Glance for instance images, Cinder block device, Neutron networking, Nova management, Horizon dashboard, message broker, and database services. All networking services are installed on Neutron Network Node—L3 Agent, Open vSwitch (L2) Agent, DHCP agent, and metadata service. Compute Nodes run Nova-Compute services that are responsible for running the instances as shown in the following chart:

This layout allows the compute resources to scale out to multiple nodes while keeping all management and all API components on a single control plane. The controller is easy to maintain and manage as all API interfaces are on a single node. Neutron network node manages the all layer 2 and layer 3 networks, virtual subnets, and all virtual routers. It is also responsible for routing traffic to external networks, which are not managed by Neutron.

Custom-distributed layout

Typically, large-scale environments run under heavy loads, along with running large amount of instances and handling large amount of simultaneous API calls. To handle such high loads, it is possible to deploy the services in a distributed layout, where every service is installed on its own dedicated node, and every node can individually scale out to additional nodes according to the load of each component. In the following diagram, all services are distributed based on core functionality. All Nova management services are installed on dedicated nodes:

Choosing a deployment method

Project Tuskar aims to become the standard way to deploy and OpenStack environments. While the project started to gain momentum in recent release cycles, the need to deploy OpenStack in a standard predictable manner existed from OpenStacks early days. This need brought various deployment tools to use.

Manual deployment from packages

OpenStack project's source code is available on GitHub, while the different distributions compile the source code and ship it as packaged, RPMs for Red Hat bases operating systems, and .deb files for Ubuntu-based systems. One way to deploy OpenStack is to install distribution packages based on a chosen deployed layout and manually configure all services and components needed for fully operational OpenStack environment. This manual process is fairly complex and requires being familiar with all basic configurations needed for OpenStack to function.

This chapter focuses on packages' deployment and manual configuration of the services, as this is a good practice to become familiar with all the basic configurations and getting ready for more advanced OpenStack configurations.

Configuration management tools (Puppet, Chef, Ansible)

Configuring OpenStack services manually is a complex task, that requires editing lots of files and configuring lots of depending services, as such, it is a very error-prone process. A common way to automate this process is to use configuration management tools, such as Puppet, Chef, or Ansible, for installing OpenStack packages and automate all the configuration needed for OpenStack to operate. There's a large community, developing open source Puppet modules and Chef cookbooks to deploy OpenStack, which are available on GitHub.

PackStack

PackStack is a utility that uses Puppet modules to deploy OpenStack on multiple preinstalled nodes automatically. It requires neither Puppet skills nor being familiar with OpenStack configuration. Installing OpenStack using PackStack is fairly simple; all it reacquires is to execute a single command #packstack --gen-answer-file to generate an answers file that desires the deployment layout and to initiate deployment run with #packstack --answer-file=/path/to/packstack_answers.txt.

Foreman with Staypuft plugin

The project Staypuft is an OpenStack deployment tool, which is based on Foreman, a robust and mature life cycle management tool. Staypuft includes a user interface designed specifically to deploy OpenStack and uses supporting Puppet modules. It also includes a discovery tool to easily add and deploy new hardware, and it can deploy the controller node with high availability configuration for production use.

Staypuft makes it easy to install OpenStack, with lower learning curve than managing Puppet modules manually, and it is more robust than using Packstack. Chapter 2, Deploying OpenStack Using Staypuft OpenStack Installer, will describe how to install a new OpenStack environment using Staypuft.

Deploying OpenStack from packages

This chapter covers the manual installation of OpenStack from RDO distribution packages and the manual configuration of all basic OpenStack services. As mentioned earlier, manually installing OpenStack is not the optimal way to set up an OpenStack environment, as it involves numerous manual steps that are not easily reproducible and very error-prone, but the manual process is a great way to get familiar with all OpenStack internal components.

The following diagram describes a high-level design of most OpenStack services and outlines the steps needed for configuring an OpenStack service:

Basic OpenStack service configuration will include configuring the service to use Keystone as authentication strategy, authenticating and authorizing incoming API calls, a database connection in which the service will store metadata about the objects it manages, and the message broker, which the Linux services use to inner communicate.

The most important, and usually the most complex, part is to configure the service to use a backend for its core functionality, for example, Nova, which launches virtual machines, can use libvirtd as a backend services provider that actually launches KVM virtual machines on the local Linux node. Another good example is Keystone that can be configured to use Lightweight Directory Access Protocol (LDAP) server as a backend to store user credentials instead of storing user credentials in the SQL database.

Environment setup

Over the course of this chapter, we will install and configure OpenStack using RDO distribution packages of kilo release, on top of CentOS 7.0 Linux operating system. We will deploy controller-Neutron-computes layout with a single controller node, one Neutron network node, and one compute node, additional compute nodes can be easily added to the environment following the same steps to install the compute node.

Environment details

  • Operating system: CentOS 7.0 or newer

  • OpenStack distribution: RDO kilo release

  • Architecture layout: controller-Neutron-computes

Every service that we install and configure while following this chapter will require its own database user account, and a Keystone user account. It is highly recommended for security reasons to choose a unique password for each account. For ease of deployment, it is recommended to maintain a password list as in the following table:

Database accounts

Password

root

password

keystone_db_user

keystone_db_password

glance_db_user

keystone_db_password

...

...

Keystone accounts

Password

glance

glance

neutron

neutron

...

...

Physical network topology

This chapter focuses on the controller-Neutron-computes topology layout. Before starting the installation of packages, we need to ensure that network interfaces are correctly wired and configured.

All nodes in our environment use eth0 as a management interface; the controller node exposes OpenStack's APIs via eth0. Neutron network node and compute nodes use eth1 for tenant's network; Neutron uses the tenant's network to route traffic between instances. Neutron network node uses eth2 for routing traffic from instances to the public network, which could be organization's IT network or publicly accessible network, as shown in the following diagram:

Note

Neutron service configuration in this chapter and Chapter 7, Neutron Networking Service, Neutron software defined network service will further discuss the creation of bridges needed for Neutron br-int and br-ex.

All hostnames should be resolvable on to their management network IP addresses.

Role

Host Name

NICs

Controller node

controller

eth0 Management 10.10.0.1/24

Neutron network node

neutron

eth0 Management 10.10.0.2/24

eth1 Tenant's Internal 10.20.0.2/24

eth2 Public not set

Compute node

compute1

eth0 Management 10.10.0.3/24

eth1 Tenant's Internal 10.20.0.3/24

Note

Running NetworkManager service in a Neutron networking environment is not recommended, and this might cause conflicts with Neutron networking.

 

Configuring hosts prerequisites


Every host running OpenStack services should have the following prerequisite configurations to successfully deploy OpenStack.

Getting ready

To successfully install OpenStack, every host needs to follow a few steps for the configuration. Every host needs to configure RDO yum repository from which we are going to install OpenStack packages. This can be done by manually configuring yum repository /etc/yum.repos.d/OpenStack.repo or installing them directly from RDO repository.

In addition, every node needs to enable firewalld service, enable SELinux and install OpenStack SELinux policies, enable and configure NTP, and also install the OpenStack utils package.

How to do it...

Perform the following steps to install and configure OpenStack prerequisites:

Yum repositories

To install OpenStack RDO distribution, we need to add RDO's yum repository on all nodes and epel, yum repository for additional needed packages:

  1. Install yum-plugin-priorities packages, which enables repositories management in yum:

    # yum install yum-plugin-priorities -y
    
  2. Install rdo-release package, which configures RDO repos in /etc/yum.repos.d:

    # yum install -y https://rdoproject.org/repos/rdo-release.rpm
    
  3. Install epel repository package, which configures epel repos in /etc/yum.repos.d:

    # yum install -y epel-release
    

Firewall service

The default netfilter firewalld service in CentOS 7.0 is firewall. For security reasons, we need to make sure that firewalld service is running and enabled, so it is started after reboot:

  1. Start firewalld service as follows:

    # systemctl start firewalld.service
    
  2. Enable firewalld service, as follows, so that it's started after host reboot as well:

    # systemctl enable firewalld.service
    

Note

Throughout this book, we will open ports needed for OpenStack to operate using the firewalld-cmd command.

openstack-utils Package

openstack-utils package brings utilities that ease OpenStack configuration and management of OpenStack services. openstack-utils includes the following utilities:

  • /usr/bin/openstack-config: Manipulates OpenStack configuration files

  • /usr/bin/openstack-db: Creates databases for OpenStack services

  • /usr/bin/openstack-service: Control-enabled OpenStack services

  • /usr/bin/openstack-status: Show status overview of installed OpenStack

Install openstack-utils package:

# yum install openstack-utils

SELinux

It is highly recommended to ensure that SELinux is enabled and in an enforcing state. the package openstack-selinux adds SELinux policy modules for OpenStack services.

  1. Ensure that SELinux is enforcing, and run the getenforce command as follows:

    # getenforce 
    

    The output should say SELinux is enforcing

  2. Install openstack-selinux package:

    # yum install openstack-selinux
    

NTP

OpenStack services are deployed over multiple nodes. For services' successful synchronization, all nodes running OpenStack need to have a synchronized system clock, and NTP service can be used for this:

  1. Install ntpd package as follows:

    # yum install ntp
    
  2. Start and enable ntpd as follows:

    # systemctl start ntpd
    # systemctl enable ntpd
    
 

Installing MariaDB database


Most OpenStack projects and their components keep their persistent data and objects' status in a database. MySQL and MariaDB are the most used and tested databases with OpenStack. In our case, and in the most commonly deployed layout, controller-Neutron-compute, the database is installed on the controller node.

Run the following commands on the controller node!

How to do it...

Proceed with the following steps:

  1. Install MaridaDB packages as follows:

    [[email protected] ~]# yum install mariadb-galera-server
    

    Yum might deploy additional packages after resolving MariaDB's dependencies. A successful installation should output as follows:

    Installed:
      mariadb-galera-server.x86_64 1:5.5.37-7.el7ost
    
    Dependency Installed:
      mariadb.x86_64 1:5.5.37-1.el7_0
      mariadb-galera-common.x86_64 1:5.5.37-7.el7ost
      mariadb-libs.x86_64 1:5.5.37-1.el7_0
      perl-DBD-MySQL.x86_64 0:4.023-5.el7
    Complete!
  2. Start MariaDB database service using systemctl command as a root:

    [[email protected] ~]# systemctl start mariadb.service
    

    If no output is returned, this means the command is completed successfully.

  3. Enable it, so it starts automatically after reboot:

    [[email protected] ~]# systemctl enable mariadb.service
    

    MariaDB maintains its own user accounts and passwords; root is the default administrative user name account that MariaDB uses. We should change the default password for the root account as keeping the default password is a major security treat.

  4. Change the database root password as follows, where new_password is the password we want to set:

    [[email protected] ~]# mysqladmin -u root password new_password
    

    Keep this in the passwords' list; we will need to create databases for the services we will deploy in the following parts of the chapter.

There's more...

Almost all components require access to the database; hence, we should keep port 3306 open for new connections on the controller node:

[[email protected] ~]# firewall-cmd --add-port=3306/tcp --permanent
 

Installing RabbitMQ


OpenStack uses a message broker for components to inner communicate. Red Hat-based operating systems (for example, RHEL, CentOS, and Fedora) can run RabbitMQ or QPID message brokers. Both provide roughly similar performance, but as RabbitMQ is more widely used message broker with OpenStack, we are going use it as a message broker for our OpenStack environment.

How to do it...

  1. Install RabbitMQ from the yum repository:

    Run the following commands on the controller node!

     [[email protected] ~]# yum install rabbitmq-server -y
    

    RabbitMQ is written in erlang and will probably bring some erlang dependency packages along.

  2. To start the RabbitMQ Linux services, start a service named rabbitmq-server:

    [[email protected] ~]# systemctl start rabbitmq-server.service
    
  3. Now enable it, to make sure that it starts on a system reboot:

    [[email protected] ~]# systemctl enable rabbitmq-server.service
    

There's more...

RabbitMQ maintains its own user accounts and passwords. By default, the user name guest is created with the default password guest. As it is a major security concern to keep default password, we should change this password. We can use the command rabbitmqctl to change guest's account password:

[[email protected] ~]# rabbitmqctl change_password guest guest_password
Changing password for user "guest" ...
...done.

We need to allow other services to be able to access the message broker over the firewall using firewall-cmd command:

[[email protected] ~]# firewall-cmd --add-port=5672/tcp --permanent
success
 

Installing Keystone – Identity service


Keystone project provides Identity as a service for all OpenStack services and components. It is recommended to authenticate users and authorize access of OpenStack components. For Example, if a user would like to launch a new instance, Keystone is responsible for making sure that the user account, which issued the instance launch command, is a known authenticated user account and the account has permissions to launch the instance.

Keystone also provides a services catalog, which OpenStack serves, users and other services can query Keystone for the services of a particular OpenStack environment. For each service, Keystone returns an endpoint, which is a network-accessible URL from where users and services can access a certain service.

In this chapter, we are going to configure Keystone to use MariaDB as the backend data store provides, which is the most common configuration. Keystone can also use user account details on an LDAP server or Microsoft Active Directory, which will be covered in Chapter 4, Keystone Identity Service.

Getting Ready

Before installing and configuring Keystone, we need to prepare a database for Keystone to use, configure it's user's permissions, and open needed firewall ports, so other nodes would be able to communicate with it. Keystone is usually installed on the controller node as part of OpenStack's control plane.

Run the following commands on the controller node!

Create Keystone database

  1. To create a database for Keystone, use MySQL command to access the MariaDB instance, This will ask you to type the password you selected for the MariaDB root user:

    [[email protected] ~]# mysql -u root -p
    
  2. Create a database named keystone:

    MariaDB [(none)]> CREATE DATABASE keystone;
    
  3. Create a user account named keystone with the selected password instead of 'my_keystone_db_password':

    MariaDB [(none)]> GRANT ALL ON keystone.* TO 'keystone'@'%' IDENTIFIED BY 'my_keystone_db_password';
    
  4. Grant access for keystone user account to the keystone database:

    MariaDB [(none)]> GRANT ALL ON keystone.* TO 'keystone'@'localhost' IDENTIFIED BY 'my_keystone_db_password';
    
  5. Flush database privileges to ensure that they are effective immediately:

    MariaDB [(none)]> FLUSH PRIVILEGES;
    
  6. At this point, you can exit the MySQL client:

    MariaDB [(none)]> quit
    

Open Keystone service firewall ports

Keystone service uses port 5000 for public access and port 35357 for administration.

[[email protected] ~]# firewall-cmd --add-port=5000/tcp --permanent
[[email protected] ~]# firewall-cmd --add-port=35357/tcp --permanent

How to do it...

Proceed with the following steps:

Install service packages

By now, all OpenStack's prerequisites, including a database service and a message broker, should be installed and configured, and this is the first OpenStack service we install. First, we need to install, configure, enable, and start the package.

Install keystone package using yum command as follows:

[[email protected] ~]# yum install -y openstack-keystone

This will also install Python supporting packages and additional packages for more advanced backend configurations.

Configure database connection

Keystone's database connection string is set in /etc/keystone/keystone.conf; we can use the #openstack-config command to configure the connection string.

  1. Run the openstack-config command with your chosen keystone database user details and database IP address:

    [[email protected] ~]# openstack-config --set /etc/keystone/keystone.conf    sql connection mysql://keystone:'my_keystone_db_password'@10.10.0.1/keystone
    
  2. After the database is configured, we can create the Keystone database tables using db_sync command:

    [[email protected] ~]# su keystone -s /bin/sh -c "keystone-manage db_sync"
    

    Note

    To make sure that the Keystone database is populated successfully, verify the Keystone database exists using MySql command #mysql -u root -p -e 'show databases;' which provides database's root account password.

Keystone service basic configuration

Before starting the Keystone service, we need to make some initial service configurations for it to start properly.

Configure administrative token

Keystone can use a token by which it will identify the administrative user:

  1. Set a custom token or use openssl command to generate a random token:

    [[email protected] ~]# export SERVICE_TOKEN=$(openssl rand -hex 10)
    
  2. Store the token in a file for use in the next steps:

    [[email protected] ~]# echo $SERVICE_TOKEN > ~/keystone_admin_token
    

    We need to configure Keystone to use the token we created, we can manually edit the Keystone configuration file /etc/keystone/keystone.conf and manually remove comment mark # next to admin_token or we can use the command openstack-config to set the needed property.

    Note

    openstack-config command is provided by # yum install openstack-utils.

  3. Use openstack-config command to configure service_token parameter as follows:

    [[email protected] ~]# openstack-config --set /etc/keystone/keystone.conf DEFAULT admin_token $SERVICE_TOKEN
    
 

Generating and configuring tokens PKIs


Keystone uses cryptographically signed tokens with a private key and is matched against x509 certificate with a public key. Chapter 4, Keystone Identity Service discusses more advanced configurations. In this chapter, we use keystone-manage pki_setup command to generate PKI key pairs and to configure Keystone to use it.

How to do it…

Proceed with the following steps:

  1. Generate PKI keys using keystone-manage pki_setup command:

    [[email protected] ~]# keystone-manage pki_setup --keystone-user keystone --keystone-group keystone
    

    Note

    In keystone-manage pki_setup, we use Keystone Linux user and group accounts, which were created when openstack-keystone package was installed.

  2. Change ownership of the generated PKI files:

    [[email protected] ~]# chown -R keystone:keystone /var/log/keystone /etc/keystone/ssl/
    
  3. Configure Keystone service to use the generated PKI files:

    [[email protected] ~]# openstack-config --set /etc/keystone/keystone.conf  signing token_format PKI
    [[email protected] ~]# openstack-config --set /etc/keystone/keystone.conf  signing certfile /etc/keystone/ssl/certs/signing_cert.pem
    [[email protected] ~]# openstack-config --set /etc/keystone/keystone.conf  signing keyfile /etc/keystone/ssl/private/signing_key.pem
    [[email protected] ~]# openstack-config --set /etc/keystone/keystone.conf  signing ca_certs /etc/keystone/ssl/certs/ca.pem
    [[email protected] ~]# openstack-config --set /etc/keystone/keystone.conf  signing key_size 1024
    [[email protected] ~]# openstack-config --set /etc/keystone/keystone.conf  signing valid_days 3650
    [[email protected] ~]# openstack-config --set /etc/keystone/keystone.conf  signing ca_password None
    

Starting and enabling service

At this point, Keystone is configured and readily run as follows:

[[email protected] ~]# systemctl start openstack-keystone

Enable Keystone to start after system reboot:

[[email protected] ~]# systemctl enable openstack-keystone

Configuring Keystone endpoints

We need to configure a Keystone service endpoint for other services to operate properly:

  1. Set the SERVICE_TOKEN environment parameter using the keystone_admin_token we generated on basic Keystone configuration step:

    [[email protected] ~]# export SERVICE_TOKEN=`cat ~/keystone_admin_token`
    
  2. Set the SERVICE_ENDPOINT environment parameter with Keystone's endpoint URL using your controller's IP address:

    [[email protected] ~]# export SERVICE_ENDPOINT="http://10.10.0.1:35357/v2.0"
    
  3. Create a Keystone service entry:

    [[email protected] ~]# keystone service-create --name=keystone --type=identity --description="Keystone Identity service"
    

    An output of a successful execution should look similar to the following, with a different unique ID:

    +-------------+----------------------------------+
    |   Property  |              Value               |
    +-------------+----------------------------------+
    | description |    Keystone Identity service     |
    |   enabled   |               True               |
    |      id     | 1fa0e426e1ba464d95d16c6df0899047 |
    |     name    |             keystone             |
    |     type    |             identity             |
    +-------------+----------------------------------+

    The endpoint-create command allows us to set a different IP addresses that are accessible from public and from internal sources. At this point, we may use our controller's management NIC IP to access Keystone endpoint.

  4. Create Keystone service endpoint using keystone endpoint-create command:

    [[email protected] ~]# keystone endpoint-create  --service keystone --publicurl 'http://10.10.0.1:5000/v2.0' --adminurl 'http://10.10.0.1:35357/v2.0'--internalurl 'http://10.10.0.1:5000/v2.0'
    
  5. Create services tenant:

    [[email protected] ~(keystone_admin)]# keystone tenant-create --name services --description "Services Tenant"
    

Keystone administrator account

  1. Create an administrative account within Keystone:

    [[email protected] ~]# keystone user-create --name admin --pass password
    
  2. Create the admin role:

    [[email protected] ~]# keystone role-create --name admin
    
  3. Create an admin tenant:

    [[email protected] ~]# keystone tenant-create --name admin
    
  4. Add an admin roles to the admin user with the admin tenant:

    [[email protected] ~]# keystone user-role-add --user admin --role admin --tenant admin
    
  5. Create keystonerc_admin file with the following content:

    [[email protected] ~]# cat ~/keystonerc_admin 
    export OS_USERNAME=admin
    export OS_TENANT_NAME=admin
    export OS_PASSWORD=password
    export OS_AUTH_URL=http://10.10.0.1:35357/v2.0/
    export PS1='[\[email protected]\h \W(keystone_admin)]\$ '
    
  6. To load the environment variables, run source command:

    [[email protected] ~]# source keystonerc_admin 
    

Keystone user account

We may also create an unprivileged user account that has no administration permissions on our newly created OpenStack environment:

  1. Create the user account in Keystone:

    [[email protected] ~(keystone_admin)]# keystone user-create --name USER --pass password
    
  2. Create a new tenant:

    [[email protected] ~(keystone_admin)]# keystone tenant-create --name TENANT
    
  3. Assign the user account to the newly created tenant:

    [[email protected] ~(keystone_admin)]# keystone user-role-add --user USER --role _member_ --tenant TENANT
    
  4. Create keystonerc_user file with the following content:

    [[email protected] ~(keystone_admin)]# cat ~/keystonerc_user
    export OS_USERNAME=USER
    export OS_TENANT_NAME=TENANT
    export OS_PASSWORD=password
    export OS_AUTH_URL=http://10.10.0.1:5000/v2.0/
    export PS1='[\[email protected]\h \W(keystone_user)]\$ '
    

There's more…

If installation and configuration of Keystone service was successful, Keystone should be operational, and we execute a keystone command to verify that it is operational.

Verify successful installation

Use the command #tenant-list to list the existing tenants:

[[email protected] ~(keystone_admin)]# keystone tenant-list

The output of successful tenant creation should look like this:

+----------------------------------+----------+---------+
|                id                |   name   | enabled |
+----------------------------------+----------+---------+
| a5b7bf37d1b646cb8ec0eb35481204c4 |  admin   |   True  |
| fafb926db0674ad9a34552dc05ac3a18 | services |   True  |
+----------------------------------+----------+---------+
 

Installing Glance – images service


Glance images service provides services that allow us to store and retrieve operating system disk images to launch instances from. In our example, environment Glance service is installed on the controller node. Glance service consists of two services: Glance API, which is responsible for all API interactions, and glance-registry, which manages image database registry. Each has a configuration file under /etc/glance/.

Getting ready

Before configuring Glance, we need to create a database for it and grant the needed database credentials. We need to create user account for Glance in the Keystone user registry for Glance to be able to authenticate against Keystone. Finally, we will need to open appropriate firewall ports.

Create database

Use MySQL command with root a account to create the Glance database:

[[email protected] ~(keystone_admin)]# mysql -u root -p
  1. Create Glance database:

    MariaDB [(none)]> CREATE DATABASE glance_db;
    
  2. Create Glance database user account and grant access permissions, where my_glance_db_password is your password:

    MariaDB [(none)]> GRANT ALL ON glance_db.* TO 
    'glance_db_user'@'%' IDENTIFIED BY 'my_glance_db_password';
    MariaDB [(none)]> GRANT ALL ON glance.* TO 'glance_db'@'localhost' IDENTIFIED BY 'my_glance_db_password';
    
  3. Flush all changes:

    MariaDB [(none)]> FLUSH PRIVILEGES;
    
  4. At this point, we can quit the MariaDB client:

    MariaDB [(none)]> quit
    
  5. Create Glance tables:

    [[email protected] glance(keystone_admin)]# glance-manage db_sync
    

Create Glance service credentials and endpoint in Keystone

Gain Keystone admin privileges to create Glance service account in Keystone:

[[email protected] ~]# source keystonerc_admin
  1. Create a Keystone user account for Glance:

    [[email protected] ~(keystone_admin)]# keystone user-create --name glance --pass glance_password
    
  2. Add an admin role to the glance user and services tenants:

    [[email protected] ~(keystone_admin)]# keystone user-role-add --user glance --role admin --tenant services
    
  3. Create a glance service:

    [[email protected] ~(keystone_admin)]# keystone service-create --name glance --type image --description "Glance Image Service"
    
  4. Create an endpoint for glance service:

    [[email protected] ~(keystone_admin)]# keystone endpoint-create --service glance --publicurl "http://10.10.0.1:9292" --adminurl "http://10.10.0.1:9292" --internalurl "http://10.10.0.1:9292"
    

Open service firewall ports

  1. Set Glance to use port 9292, edit /etc/glance/glance-api.conf with following lines:

    bind_host = 10.10.0.1
    bind_port = 9292
    
  2. Add a firewall rule:

    [[email protected] ~(keystone_admin)]# firewall-cmd --permanent --add-port=9292/tcp
    

Install service packages

Install Glance service packages using yum command:

[[email protected] ~]# yum install -y openstack-glance

Service configuration

At this point, all prerequisites for Glance should be ready and we can go ahead and configure Glance. We need to set its database connection, configure Glance to use RabbitMQ, and configure Glances authentication strategy to use Keystone.

How to do it...

Follow these steps to configure Glance image service:

Configure database connection

  1. Set the connection string for glance-api:

    [[email protected] ~(keystone_admin)]# openstack-config --set /etc/glance/glance-api.conf    DEFAULT sql_connection mysql://glance_db_user:[email protected]/glance_db
    
  2. Set connection string for glance-registry:

    [[email protected] ~(keystone_admin)]# openstack-config --set /etc/glance/glance-registry.conf DEFAULT sql_connection mysql://glance_db_user:[email protected]/glance_db
    
  3. Configure the message broker using openstack-config command:

    # openstack-config --set /etc/glance/glance-api.conf DEFAULT \rpc_backend rabbit
    # openstack-config --set /etc/glance/glance-api.conf DEFAULT \rabbit_host 10.10.0.1
    # openstack-config --set /etc/glance/glance-api.conf DEFAULT \rabbit_userid guest
    # openstack-config --set /etc/glance/glance-api.conf DEFAULT \rabbit_password guest_password
    

Configure Glance service

  1. Configure Glance to use Keystone as an authentication method:

    [[email protected] ~(keystone_admin)]# openstack-config --set /etc/glance/glance-api.conf paste_deploy flavor keystone
    [[email protected] ~(keystone_admin)]# openstack-config --set /etc/glance/glance-api.conf  keystone_authtoken auth_host 10.10.0.1
    [[email protected] ~(keystone_admin)]# openstack-config --set /etc/glance/glance-api.conf  keystone_authtoken auth_port 35357
    [[email protected] ~(keystone_admin)]# openstack-config --set /etc/glance/glance-api.conf  keystone_authtoken auth_protocol http
    [[email protected] ~(keystone_admin)]# openstack-config --set /etc/glance/glance-api.conf keystone_authtoken admin_tenant_name services
    [[email protected] ~(keystone_admin)]# openstack-config --set /etc/glance/glance-api.conf  keystone_authtoken admin_user glance
    [[email protected] ~(keystone_admin)]# openstack-config --set /etc/glance/glance-api.conf  keystone_authtoken admin_password glance_password
    
  2. Now configure glance-registry to use Keystone for authentication:

    [[email protected] ~(keystone_admin)]# openstack-config --set /etc/glance/glance-registry.conf   paste_deploy flavor keystone
    [[email protected] ~(keystone_admin)]# openstack-config --set /etc/glance/glance-registry.conf   keystone_authtoken auth_host 192.168.200.258
    [[email protected] ~(keystone_admin)]# openstack-config --set /etc/glance/glance-registry.conf  keystone_authtoken auth_port 35357   
    [[email protected] ~(keystone_admin)]# openstack-config --set /etc/glance/glance-registry.conf  keystone_authtoken auth_protocol http
    [[email protected] ~(keystone_admin)]# openstack-config --set /etc/glance/glance-registry.conf  keystone_authtoken admin_tenant_name services
    [[email protected] ~(keystone_admin)]# openstack-config --set /etc/glance/glance-registry.conf  keystone_authtoken admin_user glance
    [[email protected] ~(keystone_admin)]# openstack-config --set /etc/glance/glance-registry.conf  keystone_authtoken admin_password password
    

    Note

    By default, Glance will store images as files in a local directory /var/lib/glance/images/, so this configuration is not needed at this point.

  3. Start and enable the service:

    [[email protected] ~]# systemctl start openstack-glance-api
    [[email protected] ~]# systemctl start openstack-glance-registry
    

There's more…

If the installation and configuration was successful, we can upload our fist image to Glance registry. CirrOS Linux image is a good candidate as it is extremely small in size and functional enough to test most OpenStack's functionalities.

Verify successful installation

If glance was successfully installed and configured, we may upload our fist image.

  1. First, download a CirrOS image to the controller node:

    [[email protected] glance(keystone_admin)]# wget  http://download.cirros-cloud.net/0.3.4/cirros-0.3.4-x86_64-disk.img
    Then, upload the image to Glance registry using glance image-create command:
    [[email protected] glance(keystone_admin)]# glance image-create--name="cirros-0.3.2-x86_64" --disk-format=qcow2 --container-format=bare --is-public=true -–file cirros-0.3.2-x86_64-disk.img
    
  2. List all glance images using glance image-list command:

    [[email protected] glance(keystone_admin)]# glance image-list
    If the upload of the image was successful, the Cirros image will appear in the list.
    
 

Installing Nova – Compute service


Nova-Compute service implements the compute service, which is the main part of an IaaS cloud. Nova is responsible for launching and managing instance of virtual machines. The compute service scales horizontally on standard hardware.

Getting ready

In our environment, we deploy a Controller/Computes layout. In the first step, we need to configure management services on the controller node and only then to add compute nodes to the environment. On the controller node, first we need to prepare the database, create a Keystone account, then open the needed firewall ports.

Run the following steps on the controller node!

Create database

  1. Access the database instance using MySQL command:

    [[email protected] ~]# mysql -u root -p
    
  2. Create Nova database:

    MariaDB [(none)]> CREATE DATABASE nova_db;
    
  3. Create Nova credentials and allow access:

    MariaDB [(none)]> GRANT ALL PRIVILEGES ON nova_db.* TO 'nova_db_user'@'localhost' IDENTIFIED BY 'nova_db_password';
    MariaDB [(none)]> GRANT ALL PRIVILEGES ON nova_db.* TO 'nova_db_user'@'%' IDENTIFIED BY 'nova_db_password';
    
  4. Create Nova database tables:

    [[email protected] ~]# su -s /bin/sh -c "nova-manage db sync" nova
    

Create Keystone service credentials and endpoint

  1. Create Nova service account in Keystone:

    [[email protected] ~]# keystone user-create --name=nova --pass=nova_password
    [[email protected] ~]# keystone user-role-add --user=nova --tenant=services --role=admin
    
  2. Create an endpoint for Nova

    [[email protected] ~]# keystone endpoint-create --service=nova--publicurl=http://10.10.0.1:8774/v2/%\(tenant_id\) |--internalurl=http://10.10.0.1:8774/v2/%\(tenant_id\s --adminurl=http://10.10.0.1:8774/v2/%\(tenant_id\)s
    

Open service firewall ports

  1. Add firewall rules:

    [[email protected] ~]# firewall-cmd --permanent --add-port=8774/tcp
    [[email protected] ~]# firewall-cmd --permanent --add-port=6080/tcp
    [[email protected] ~]# firewall-cmd --permanent --add-port=6081/tcp
    [[email protected] ~]# firewall-cmd --permanent --add-port=5900-5999/tcp
    
  2. Reload firewall rules to take effect:

    [[email protected] ~]# firewall-cmd --reload
    

Install service packages

Install service packages using yum command:

[[email protected] ~]# yum install -y openstack-nova-api openstack-nova-cert openstack-nova-conductor  openstack-nova-console openstack-nova-novncproxy penstack-nova-scheduler python-novaclient

How to do it...

Follow these steps to configure Nova-Compute service:

Configure database connection

Using openstack-config command, we need to set the connection to the database:

[[email protected] ~]# openstack-config --set /etc/nova/nova.conf database connection mysql://nova_db_user:[email protected]/nova_db
[[email protected] ~]# su -s /bin/sh -c "nova-manage db sync" nova

Configure message broker

Set connection to RabbitMQ message broker:

[[email protected] ~]# openstack-config --set /etc/nova/nova.conf DEFAULT rpc_backend rabbit
[[email protected] ~]# openstack-config --set /etc/nova/nova.conf DEFAULT rabbit_host 10.10.0.1

Configure service

  1. Set local IP address of the controller:

    # openstack-config --set /etc/nova/nova.conf DEFAULT my_ip 10.10.0.1
    # openstack-config --set /etc/nova/nova.conf DEFAULT vncserver_listen 10.10.0.1
    # openstack-config --set /etc/nova/nova.conf DEFAULT vncserver_proxyclient_address 10.10.0.1
    
  2. Configure Keystone as an authentication method:

    # openstack-config --set /etc/nova/nova.conf DEFAULT auth_strategy keystone
    # openstack-config --set /etc/nova/nova.conf keystone_authtoken auth_uri http://10.10.0.1:5000
    # openstack-config --set /etc/nova/nova.conf keystone_authtoken auth_host 10.10.0.1
    # openstack-config --set /etc/nova/nova.conf keystone_authtoken auth_protocol http
    # openstack-config --set /etc/nova/nova.conf keystone_authtoken auth_port 35357
    # openstack-config --set /etc/nova/nova.conf keystone_authtoken admin_user nova
    # openstack-config --set /etc/nova/nova.conf keystone_authtoken admin_tenant_name services
    # openstack-config --set /etc/nova/nova.conf keystone_authtoken admin_password nova_password
    

Start and enable Service

Using systemctl command, we can start and enable the service so that it starts after reboot:

[[email protected] ~]# systemctl start openstack-nova-api
[[email protected] ~]# systemctl start openstack-nova-cert
[[email protected] ~]# systemctl start openstack-nova-consoleauth
[[email protected] ~]# systemctl start openstack-nova-scheduler
[[email protected] ~]# systemctl start openstack-nova-conductor
[[email protected] ~]# systemctl start openstack-nova-novncproxy
[[email protected] ~]# systemctl enable openstack-nova-api
[[email protected] ~]# systemctl enable openstack-nova-cert
[[email protected] ~]# systemctl enable openstack-nova-consoleauth
[[email protected] ~]# systemctl enable openstack-nova-scheduler
[[email protected] ~]# systemctl enable openstack-nova-conductor
[[email protected] ~]# systemctl enable openstack-nova-novncproxy

Verify successful installation

On successful Nova installation and configuration, you should be able to execute this:

[[email protected] ~(keystone_admin)]# nova image-list
+-------------------+---------------------+--------+--------+
| ID                | Name                | Status | Server |
+-------------------+---------------------+--------+--------+
| eb9c6911-...      | cirros-0.3.2-x86_64 | ACTIVE |        |
+-------------------+---------------------+--------+--------+

After the controller node is successfully installed and configured, we may add additional compute nodes to the OpenStack environment.

Configure compute nodes

Now we can proceed and configure the compute services on the compute node.

Run the following steps on the compute node!

Install service packages

Using yum command, install Nova-Compute package:

# yum install openstack-nova-compute

Configure database connection

Configure the Nova database connection:

[[email protected] ~]# openstack-config --set /etc/nova/nova.conf database connection mysql://nova_db_user:[email protected]/nova_db

Configure message broker

Configure Nova to access the message broker:

[[email protected] ~]# openstack-config --set /etc/nova/nova.conf DEFAULT rpc_backend rabbit
[[email protected] ~]# openstack-config --set /etc/nova/nova.conf DEFAULT rabbit_host 10.10.0.1

Configure service

  1. Edit /etc/nova/nova.conf for the compute node to use Keystone authentication:

    [[email protected] ~]# openstack-config --set /etc/nova/nova.conf DEFAULT auth_strategy keystone
    [[email protected] ~]# openstack-config --set /etc/nova/nova.conf keystone_authtoken auth_uri http://controller:5000
    [[email protected] ~]# openstack-config --set /etc/nova/nova.conf keystone_authtoken auth_host controller
    [[email protected] ~]# openstack-config --set /etc/nova/nova.conf keystone_authtoken auth_protocol http
    [[email protected] ~]# openstack-config --set /etc/nova/nova.conf keystone_authtoken auth_port 35357
    [[email protected] ~]# openstack-config --set /etc/nova/nova.conf keystone_authtoken admin_user nova
    [[email protected] ~]# openstack-config --set /etc/nova/nova.conf keystone_authtoken admin_tenant_name service
    [[email protected] ~]# openstack-config --set /etc/nova/nova.conf keystone_authtoken admin_password nova_password
    
  2. Configure the remote console for instances terminal access:

    [[email protected] ~]# openstack-config --set /etc/nova/nova.conf
    DEFAULT my_ip 192.168.200.159
    [[email protected] ~]# openstack-config --set /etc/nova/nova.conf
    DEFAULT vnc_enabled True
    [[email protected] ~]# openstack-config --set /etc/nova/nova.conf DE
    \FAULT vncserver_listen 0.0.0.0
    [[email protected] ~]# openstack-config --set /etc/nova/nova.conf DEFAULT vncserver_proxyclient_address 192.168.200.159
    [[email protected] ~]# openstack-config --set /etc/nova/nova.conf \DEFAULT novncproxy_base_url http://controller:6080/vnc_auto.html
    
  3. Configure which glance service to use to retrieve images:

    [[email protected] ~]# openstack-config --set /etc/nova/nova.conf DEFAULT glance_host controller
    

    Note

    If you are installing the compute node on a virtual machine, configure Nova to the user QEMU emulation instated of the default KVM backend. To configure QEMU, run the following command:

    [[email protected] ~]# openstack-config --set /etc/nova/nova.conf libvirt virt_type qemu

Start and enable Service

Using systemctl command, start and enable the service:

[[email protected] ~]# systemctl start libvirtd
[[email protected] ~]# systemctl start openstack-nova-compute
[[email protected] ~]# systemctl enable libvirtd
[[email protected] ~]# systemctl enable openstack-nova-compute
 

Installing Neutron – networking service


Neutron networking service is responsible for the creation and management of layer 2 networks, layer 3 subnets, routers, and services, such as firewalls, VPNs, and DNS. Neutron service is constructed of Neutron-server service, which serves the Neutron API and interacts with the Neutron components since we deploy controller-Neutron-compute layout that we need to install and configure neutron-server and Modular Layer 2 (ML2) plugin on the controller node. Then, we will configure layer 3, DHCP, and metadata services on the Neutron network node. We will configure the compute node to use Neutron networking services.

Getting ready

Before configuring Neutron services, we need to create a Database that will hold Neutron's objects, a Keystone endpoint for Neutron, open the needed firewall ports, and install all needed Neutron packages on the controller, Neutron network node, and on compute nodes.

Run the following commands on the controller node!

Create database

  1. Access the database instance using MySQL command with the root user account:

    [[email protected] ~]# mysql -u root -p
    
  2. Create a new database for Neutron called neutron:

    MariaDB [(none)]> CREATE DATABASE neutron;
    
  3. Create a database user account named neutron_db_user with the password neutron_db_password and grant access to the newly created database:

    MariaDB [(none)]> GRANT ALL PRIVILEGES ON neutron.* TO 'neutron_user_db'@'localhost' IDENTIFIED BY 'neutron_db_password';
    MariaDB [(none)]> GRANT ALL PRIVILEGES ON neutron.* TO 'neutron_user_db'@'%' IDENTIFIED BY 'neutron_db_password';
    

Create Keystone service credentials and endpoint

Keep in mind that for using Keystone command, we need to source Keystone environment parameters with admin credentials: # source ~/keystonerc_admin.

[[email protected] ~(keystone_admin)]# keystone user-create --name neutron --pass password
[[email protected] ~(keystone_admin)]# keystone user-role-add --user neutron --tenant services --role admin
[[email protected] ~(keystone_admin)]# keystone service-create --name neutron --type network --description "OpenStack Networking"

Create a new endpoint for Neutron in Keystone services catalog:

[[email protected] ~(keystone_admin)]# keystone endpoint-create \--service neutron \--publicurl http://controller:9696 \--adminurl http://controller:9696 \--internalurl http://controller:9696

Open service firewall ports

Add firewall rule to open TCP port 9696:

[[email protected] ~]# firewall-cmd --permanent --add-port=9696/tcp
[[email protected] ~]# firewall-cmd --reload

Install service packages

Install Neutron server and ML2 plugin packages on the controller:

[[email protected] ~]# yum install -y openstack-neutron openstack-neutron-ml2 

How to do it…

We start by configuring Neutron server service on the controller node. We will configure Neutron to access the database and message broker. Then, we will configure Neutron to use Keystone, as it's an authentication strategy. We will use ML2 driver backend and configure Neutron to use it. Finally, we will configure Nova service to use Neutron and ML2 plugin as networking services.

Configure database connection

Use OpenStack configure command to configure the connection string to the database:

[[email protected] ~]# openstack-config --set /etc/neutron/neutron.conf database connection mysql://neutron_db_user:[email protected]/neutron_db

Configure message broker

Configure Neutron to use RabbitMQ message broker:

Tip

Remember to change 10.10.0.1 to your controller management IP.

[[email protected] ~]# openstack-config --set /etc/neutron/neutron.conf DEFAULT rpc_backend rabbit
[[email protected] ~]# openstack-config --set /etc/neutron/neutron.conf DEFAULT rabbit_host 10.10.0.1

Configure Neutron service

  1. Configure Neutron to use Keystone as an authentication strategy:

    [[email protected] ~]# openstack-config --set /etc/neutron/neutron.conf DEFAULT \auth_strategy keystone
    [[email protected] ~]# openstack-config --set /etc/neutron/neutron.conf keystone_authtoken \auth_uri http://controller:5000
    [[email protected] ~]# openstack-config --set /etc/neutron/neutron.conf keystone_authtoken \auth_host controller
    [[email protected] ~]# openstack-config --set /etc/neutron/neutron.conf keystone_authtoken \auth_protocol http
    [[email protected] ~]# openstack-config --set /etc/neutron/neutron.conf keystone_authtoken \auth_port 35357
    [[email protected] ~]# openstack-config --set /etc/neutron/neutron.conf keystone_authtoken \admin_tenant_name services
    [[email protected] ~]# openstack-config --set /etc/neutron/neutron.conf keystone_authtoken \admin_user neutron
    [[email protected] ~]# openstack-config --set /etc/neutron/neutron.conf keystone_authtoken \admin_password password
    
  2. Configure Neutron to synchronize networking topology changes with Nova:

    [[email protected] ~]# openstack-config --set /etc/neutron/neutron.conf DEFAULT \notify_nova_on_port_status_changes True
    [[email protected] ~]# openstack-config --set /etc/neutron/neutron.conf DEFAULT \notify_nova_on_port_data_changes True
    [[email protected] ~]# openstack-config --set /etc/neutron/neutron.conf DEFAULT \nova_url http://controller:8774/v2
    [[email protected] ~]# openstack-config --set /etc/neutron/neutron.conf DEFAULT \nova_admin_username nova
    [[email protected] ~]# openstack-config --set /etc/neutron/neutron.conf DEFAULT \nova_admin_tenant_id $(keystone tenant-list | awk '/ services / { print $2 }')
    [[email protected] ~]# openstack-config --set /etc/neutron/neutron.conf DEFAULT \nova_admin_password passowrd
    [[email protected] ~]# openstack-config --set /etc/neutron/neutron.conf DEFAULT \nova_admin_auth_url http://controller:35357/v2.0
    
  3. Now configure Neutron to use ML2 Neutron plugin:

    [[email protected] ~]# openstack-config --set /etc/neutron/neutron.conf DEFAULT \core_plugin ml2
    [[email protected] ~]# openstack-config --set /etc/neutron/neutron.conf DEFAULT \service_plugins router
    
  4. Configure ML2 plugin to use Open vSwitch agent with GRE segregation for virtual networks for instances:

    [[email protected] ~]# openstack-config --set /etc/neutron/plugins/ml2/ml2_conf.ini ml2 \type_drivers gre
    [[email protected] ~]# openstack-config --set /etc/neutron/plugins/ml2/ml2_conf.ini ml2 \tenant_network_types gre
    [[email protected] ~]# openstack-config --set /etc/neutron/plugins/ml2/ml2_conf.ini ml2 \mechanism_drivers openvswitch
    [[email protected] ~]# openstack-config --set /etc/neutron/plugins/ml2/ml2_conf.ini ml2_type_gre \tunnel_id_ranges 1:1000
    [[email protected] ~]# openstack-config --set /etc/neutron/plugins/ml2/ml2_conf.ini securitygroup \firewall_driver neutron.agent.linux.iptables_firewall.OVSHybridIptablesFirewallDriver
    [[email protected] ~]# openstack-config --set /etc/neutron/plugins/ml2/ml2_conf.ini securitygroup \enable_security_group True
    
  5. Once Neutron and ML2 are configured, we need to configure Nova to use Neutron as its networking provider:

    [[email protected] ~]# openstack-config --set /etc/nova/nova.conf DEFAULT network_api_class nova.network.neutronv2.api.API
    [[email protected] ~]# openstack-config --set /etc/nova/nova.conf DEFAULT neutron_url http://controller:9696
    [[email protected] ~]# openstack-config --set /etc/nova/nova.conf DEFAULT neutron_auth_strategy keystone
    [[email protected] ~]# openstack-config --set /etc/nova/nova.conf DEFAULT neutron_admin_tenant_name service
    [[email protected] ~]# openstack-config --set /etc/nova/nova.conf DEFAULT neutron_admin_username neutron
    [[email protected] ~]# openstack-config --set /etc/nova/nova.conf DEFAULT neutron_admin_password NEUTRON_PASS
    [[email protected] ~]# openstack-config --set /etc/nova/nova.conf DEFAULT neutron_admin_auth_url http://controller:35357/v2.0
    [[email protected] ~]# openstack-config --set /etc/nova/nova.conf DEFAULT linuxnet_interface_driver nova.network.linux_net.LinuxOVSInterfaceDriver
    [[email protected] ~]# openstack-config --set /etc/nova/nova.conf DEFAULT firewall_driver nova.virt.firewall.NoopFirewallDriver
    [[email protected] ~]# openstack-config --set /etc/nova/nova.conf DEFAULT security_group_api neutron
    
  6. Since we are using ML2 Neutron plugin, we need to add a symbolic link associated with ML2 and Neutron plugin as follows:

    [[email protected] ~]# ln -s plugins/ml2/ml2_conf.ini /etc/neutron/plugin.ini
    
  7. Prepare Nova to use Neutron metadata service:

    [[email protected] ~]# openstack-config --set /etc/nova/nova.conf DEFAULT service_neutron_metadata_proxy true
    [[email protected] ~]# openstack-config --set /etc/nova/nova.conf DEFAULT neutron_metadata_proxy_shared_secret SHARED_SECRET
    

Start and enable service

  1. If Nova services are running, we need to restart them:

    [[email protected] ~]# systemctl restart openstack-nova-api
    [[email protected] ~]# systemctl restart openstack-nova-scheduler
    [[email protected] ~]# systemctl restart openstack-nova-conductor
    
  2. At this point, we can start and enable Neutron-server service:

    [[email protected] ~]# systemctl start neutron-server
    [[email protected] ~]# systemctl enable neutron-server
    

    This concludes configuring Neutron server on the controller node, now we can configure Neutron network node.

 

Configuring Neutron network node


After we have configured Neutron-server on the controller node, we can proceed and configure the network server that is responsible for routing and connecting the OpenStack environment to the public network.

How to do it...

Neutron network node runs the networking services layer 2 management agent, DHCP service, L3 management agent, and metadata services agent. We will install and configure Neutron network node services to use the ML2 plugin.

Run the following commands on Neutron network node!

  1. Enable IP forwarding and reverse path filtering, edit /etc/sysctl.conf to contain the following:

    net.ipv4.ip_forward=1
    net.ipv4.conf.all.rp_filter=0
    net.ipv4.conf.default.rp_filter=0
    

    and apply the new settings:

    [[email protected] ~]# sysctl -p
    
  2. Then install the needed packages:

    [[email protected] ~]# yum install openstack-neutron openstack-neutron-ml2   openstack-neutron-openvswitch
    

Configure message broker

Configure Neutron to use RabbitMQ message broker of the controller:

Note

Remember to change 10.10.0.1 to your controller management IP.

[[email protected] ~]# openstack-config --set /etc/neutron/neutron.conf DEFAULT rpc_backend rabbit
[[email protected] ~]# openstack-config --set /etc/neutron/neutron.conf DEFAULT rabbit_host 10.10.0.1

Configure Neutron service

  1. Configure Neutron to use Keystone as an authentication strategy:

    [[email protected] ~]# openstack-config --set /etc/neutron/neutron.conf DEFAULT \  auth_strategy keystone
    [[email protected] ~]# openstack-config --set /etc/neutron/neutron.conf keystone_authtoken auth_uri http://controller:5000
    [[email protected] ~]# openstack-config --set /etc/neutron/neutron.conf keystone_authtoken auth_host controller
    [[email protected] ~]# openstack-config --set /etc/neutron/neutron.conf keystone_authtoken auth_protocol http
    [[email protected] ~]# openstack-config --set /etc/neutron/neutron.conf keystone_authtoken auth_port 35357
    [[email protected] ~]# openstack-config --set /etc/neutron/neutron.conf keystone_authtoken admin_tenant_name services
    [[email protected] ~]# openstack-config --set /etc/neutron/neutron.conf keystone_authtoken admin_user neutron
    [[email protected] ~]# openstack-config --set /etc/neutron/neutron.conf keystone_authtoken admin_password password
    
  2. Configure Neutron to use the ML2 Neutron plugin:

    [[email protected] ~]# openstack-config --set /etc/neutron/neutron.conf DEFAULT core_plugin ml2
    [[email protected] ~]# openstack-config --set /etc/neutron/neutron.conf DEFAULT service_plugins router
    
  3. Configure Layer 3 agent that provides routing services for instances:

    [[email protected] ~]# openstack-config --set /etc/neutron/l3_agent.ini DEFAULT interface_driver neutron.agent.linux.interface.OVSInterfaceDriver
    [[email protected] ~]# openstack-config --set /etc/neutron/l3_agent.ini DEFAULT use_namespaces True
    
  4. Configure the DHCP agent, which provides DHCP services for instances:

    [[email protected] ~]# openstack-config --set /etc/neutron/dhcp_agent.ini DEFAULT interface_driver neutron.agent.linux.interface.OVSInterfaceDriver
    [[email protected] ~]# openstack-config --set /etc/neutron/dhcp_agent.ini DEFAULT dhcp_driver neutron.agent.linux.dhcp.Dnsmasq
    [[email protected] ~]# openstack-config --set /etc/neutron/dhcp_agent.ini DEFAULT use_namespaces True
    
  5. Configure instances Metadata service:

    [[email protected] ~]# openstack-config --set /etc/neutron/metadata_agent.ini DEFAULT \auth_url http://controller:5000/v2.0
    [[email protected] ~]# openstack-config --set /etc/neutron/metadata_agent.ini DEFAULT \auth_region regionOne
    [[email protected] ~]# openstack-config --set /etc/neutron/metadata_agent.ini DEFAULT \admin_tenant_name services
    [[email protected] ~]# openstack-config --set /etc/neutron/metadata_agent.ini DEFAULT \admin_user neutron
    [[email protected] ~]# openstack-config --set /etc/neutron/metadata_agent.ini DEFAULT \admin_password password
    [[email protected] ~]# openstack-config --set /etc/neutron/metadata_agent.ini DEFAULT \nova_metadata_ip controller
    [[email protected] ~]# openstack-config --set /etc/neutron/metadata_agent.ini DEFAULT \metadata_proxy_shared_secret SHARED_SECRET
    
  6. Configure the ML2 plugin to use GRE tunneling segregation:

    [[email protected] ~]# openstack-config --set /etc/neutron/plugins/ml2/ml2_conf.ini ml2 \type_drivers gre
    [[email protected] ~]# openstack-config --set /etc/neutron/plugins/ml2/ml2_conf.ini ml2 \tenant_network_types gre
    [[email protected] ~]# openstack-config --set /etc/neutron/plugins/ml2/ml2_conf.ini ml2 \mechanism_drivers openvswitch
    [[email protected] ~]# openstack-config --set /etc/neutron/plugins/ml2/ml2_conf.ini ml2_type_gre \tunnel_id_ranges 1:1000
    [[email protected] ~]# openstack-config --set /etc/neutron/plugins/ml2/ml2_conf.ini ovs \local_ip 10.20.0.2
    [[email protected] ~]# openstack-config --set /etc/neutron/plugins/ml2/ml2_conf.ini ovs \tunnel_type gre
    [[email protected] ~]# openstack-config --set /etc/neutron/plugins/ml2/ml2_conf.ini ovs \enable_tunneling True
    [[email protected] ~]# openstack-config --set /etc/neutron/plugins/ml2/ml2_conf.ini securitygroup \firewall_driver neutron.agent.linux.iptables_firewall.OVSHybridIptablesFirewallDriver
    [[email protected] ~]# openstack-config --set /etc/neutron/plugins/ml2/ml2_conf.ini securitygroup \enable_security_group True
    
  7. Create bridges for Neutron layer 2 and Neutron layer 3 agents. First, start the Open vSwitch service:

    [[email protected] ~]# systemctl start openvswitch
    [[email protected] ~]# systemctl enable openvswitch
    
  8. Create a bridge for instances' inner-commutation:

    [[email protected] ~]# ovs-vsctl add-br br-int
    
  9. Create a bridge that the instance will use for communication with public networks:

    [[email protected] ~]# ovs-vsctl add-br br-ex
    
  10. Bind the external bridge with the NIC used for external communication:

    [[email protected] ~]# ovs-vsctl add-port br-ex eth2
    
  11. Create symbolic link for ML2 Neutron plugin:

    [[email protected] ~]# ln -s plugins/ml2/ml2_conf.ini /etc/neutron/plugin.ini
    

Start and enable service

  1. At this point, we can start and enable L2 Open vSwitch agent, L3 agent, HDCP agent, and metadata agent services:

    [[email protected] ~]# systemctl start neutron-openvswitch-agent
    [[email protected] ~]# systemctl start neutron-l3-agent
    [[email protected] ~]# systemctl start neutron-dhcp-agent
    [[email protected] ~]# systemctl start neutron-metadata-agent
    [[email protected] ~]# systemctl enable neutron-openvswitch-agent
    [[email protected] ~]# systemctl enable neutron-l3-agent
    [[email protected] ~]# systemctl enable neutron-dhcp-agent
    [[email protected] ~]# systemctl enable neutron-metadata-agent
    
  2. This concludes configuring Neutron network node. Now we can configure the Nova-Compute nodes to use Neutron networking.

 

Configuring compute node for Neutron


After we have configured the Neutron network node, we can go ahead and configure our compute nodes to use Neutron networking service.

How to do it...

When the controller and Neutron network node are ready, we can configure Nova-Compute node to use Neutron for networking. We will configure Neutron access to the message broker. Then, we will configure Neutron to use ML2 plugin with GRE tunneling segmentation.

Run the following commands on compute1!

  1. Disable reverse path filtering, Edit /etc/sysctl.conf to contain the following:

    net.ipv4.conf.all.rp_filter=0
    net.ipv4.conf.default.rp_filter=0
    and apply the new configuration:
    [[email protected] ~]# sysctl -p
    
  2. Install the Neutron ML2 and Open vSwitch packages:

    [[email protected] ~]# yum install -y openstack-neutron-ml2 openstack-neutron-openvswitch
    

Configure message broker

Configure Neutron to use RabbitMQ message broker of the controller:

Tip

Remember to change 10.10.0.1 to your controller management IP.

[[email protected] ~]# openstack-config --set /etc/neutron/neutron.conf DEFAULT rpc_backend rabbit
[[email protected] ~]# openstack-config --set /etc/neutron/neutron.conf DEFAULT rabbit_host 10.10.0.1

Configure Neutron service

  1. Configure Neutron to use Keystone as an authentication strategy:

    [[email protected] ~]# openstack-config --set /etc/neutron/neutron.conf DEFAULTauth_strategy keystone
    [[email protected] ~]# openstack-config --set /etc/neutron/neutron.conf keystone_authtoken \auth_uri http://controller:5000
    [[email protected] ~]# openstack-config --set /etc/neutron/neutron.conf keystone_authtoken \auth_host controller
    [[email protected] ~]# openstack-config --set /etc/neutron/neutron.conf keystone_authtoken \auth_protocol http
    [[email protected] ~]# openstack-config --set /etc/neutron/neutron.conf keystone_authtoken \auth_port 35357
    [[email protected] ~]# openstack-config --set /etc/neutron/neutron.conf keystone_authtoken \admin_tenant_name services
    [[email protected] ~]# openstack-config --set /etc/neutron/neutron.conf keystone_authtoken \admin_user neutron
    [[email protected] ~]# openstack-config --set /etc/neutron/neutron.conf keystone_authtoken \admin_password password
    
  2. Now configure Neutron to use ML2 Neutron plugin:

    [[email protected] ~]# openstack-config --set /etc/neutron/neutron.conf DEFAULT core_plugin ml2
    [[email protected]compute1 ~]# openstack-config --set /etc/neutron/neutron.conf DEFAULT service_plugins router
    
  3. Configure the ML2 Plugin to use GRE tunneling segregation:

    [[email protected] ~]# openstack-config --set /etc/neutron/plugins/ml2/ml2_conf.ini ml2 \type_drivers gre
    [[email protected] ~]# openstack-config --set /etc/neutron/plugins/ml2/ml2_conf.ini ml2 \tenant_network_types gre
    [[email protected] ~]# openstack-config --set /etc/neutron/plugins/ml2/ml2_conf.ini ml2 \mechanism_drivers openvswitch
    [[email protected] ~]# openstack-config --set /etc/neutron/plugins/ml2/ml2_conf.ini ml2_type_gre \tunnel_id_ranges 1:1000
    [[email protected] ~]# openstack-config --set /etc/neutron/plugins/ml2/ml2_conf.ini ovs \local_ip 10.20.0.3
    [[email protected] ~]# openstack-config --set /etc/neutron/plugins/ml2/ml2_conf.ini ovs \tunnel_type gre
    [[email protected] ~]# openstack-config --set /etc/neutron/plugins/ml2/ml2_conf.ini ovs \enable_tunneling True
    [[email protected] ~]# openstack-config --set /etc/neutron/plugins/ml2/ml2_conf.ini securitygroup \firewall_driver neutron.agent.linux.iptables_firewall.OVSHybridIptablesFirewallDriver
    [[email protected] ~]# openstack-config --set /etc/neutron/plugins/ml2/ml2_conf.ini securitygroup \enable_security_group True
    
  4. Create bridges for Neutron layer 2 and Neutron layer 3 agents. First, start the enable vSwitch service:

    [[email protected] ~]# systemctl start openvswitch
    [[email protected] ~]# systemctl enable openvswitch
    
  5. After starting Open vSwitch service, we can create the needed bridge:

    [[email protected] ~]# ovs-vsctl add-br br-int
    
  6. Configure Nova to use Neutron Networking:

    [[email protected] ~]# openstack-config --set /etc/nova/nova.conf DEFAULT network_api_class nova.network.neutronv2.api.API
    [[email protected] ~]# openstack-config --set /etc/nova/nova.conf DEFAULT neutron_url http://controller:9696
    [[email protected] ~]# openstack-config --set /etc/nova/nova.conf DEFAULT neutron_auth_strategy keystone
    [[email protected] ~]# openstack-config --set /etc/nova/nova.conf DEFAULT neutron_admin_tenant_name service
    [[email protected] ~]# openstack-config --set /etc/nova/nova.conf DEFAULT neutron_admin_username neutron
    [[email protected] ~]# openstack-config --set /etc/nova/nova.conf DEFAULT neutron_admin_password NEUTRON_PASS
    [[email protected] ~]# openstack-config --set /etc/nova/nova.conf DEFAULT neutron_admin_auth_url http://controller:35357/v2.0
    [[email protected] ~]# openstack-config --set /etc/nova/nova.conf DEFAULT linuxnet_interface_driver nova.network.linux_net.LinuxOVSInterfaceDriver
    [[email protected] ~]# openstack-config --set /etc/nova/nova.conf DEFAULT firewall_driver nova.virt.firewall.NoopFirewallDriver
    [[email protected] ~]# openstack-config --set /etc/nova/nova.conf DEFAULT security_group_api neutron
    
  7. Create a symbolic link for ML2 Neutron plugin:

    [[email protected] ~]# ln -s plugins/ml2/ml2_conf.ini /etc/neutron/plugin.ini
    
  8. Restart the Nova-Compute service:

    [[email protected] ~]# systemctl restart openstack-nova-compute
    
  9. Start and enable Neutron Open vSwitch agent service:

    [[email protected] ~]# systemctl start neutron-openvswitch-agent
    [[email protected] ~]# systemctl enable neutron-openvswitch-agent
    

Creating Neutron networks

At this point, we should have the controller, Neutron network node, and compute1 configured for using Neutron networking. We can go ahead and create Neutron virtual networks needed for instances to be able to communicate with external public networks. We are going to create two layer 2 networks, one for the instances, and another to connect external networks.

Run the following commands on the controller node!

By default, networks are own and managed by the Admin user, under Admin tenant and shared for other tenants' use.

  1. Source Admin tenant credentials:

    [[email protected] ~]# source keystonerc_admin
    
  2. Create an external shared network:

    [[email protected] ~(keystone_admin)]# neutron net-create external-net --shared --router:external=True
    

    In this example, we allocate a range of IPs from our existing external physical network, 192.168.200.0/24 for instances to use when communicating with the Internet or with external hosts in the IT environment.

  3. Create a subnet in the newly created network:

    [[email protected] ~(keystone_admin)]# neutron subnet-create external-net --name ext-subnet --allocation-pool start=192.168.200.100,end=192.168.200.200 --disable-dhcp --gateway 192.168.200.1 192.168.200.0/24
    

    The IP range is ought to be routable by the external public network and not overlap with the existing configured networks. Chapter 7, Neutron Networking Service, will further discuss Neutron networks planning.

  4. Create a tenant network, which is an isolated network for instances to inner-communicate:

    [[email protected] ~(keystone_admin)]# neutron net-create tenant_net
    
    [[email protected] ~(keystone_admin)]# neutron subnet-create tenant_net --name tenant_net_subnet --gateway 192.168.1.1 192.168.1.0/24
    
    [[email protected] ~(keystone_admin)]# neutron router-create ext-router
    
    [[email protected] ~(keystone_admin)]# neutron router-interface-add ext-router tenant-subnet
    
    [[email protected] ~(keystone_admin)]# neutron router-gateway-set ext-router external-net
    
 

Installing Horizon – web user interface dashboard


Horizon dashboard service is the web user interface for users to consume OpenStack services and for administrator to manage and operate OpenStack.

Getting ready

Install packages needed for Horizon as follows:

[[email protected] ~]# yum install mod_wsgi openstack-dashboard
Use firewall-cmd command to open port 80:
[[email protected] ~]# firewall-cmd --permanent --add-port=80/tcp
[[email protected] ~]# firewall-cmd --reload
Configure SELinux:
# setsebool -P httpd_can_network_connect on

How to do it...

Perform the following steps to configure and enable the Horizon dashboard service:

  1. Edit /etc/openstack-dashboard/local_settings:

    ALLOWED_HOSTS = ['localhost', '*']
    OPENSTACK_HOST = "controller"
    
  2. Start and enable service. At this point, we can start and enable Neutron-server service:

    [[email protected] ~]# systemctl start httpd
    [[email protected] ~]# systemctl enable httpd
    

How it works...

Horizon is a Django-based web application, running on Apache HTTPD service, it interacts with all services' APIs to gather information from OpenStack's services and to create new resources.

There's more...

We can verify whether Horizon dashboard service was installed successfully after we completed configuring the service.

Verify successful installation

You can now access the dashboard via web browser at http://controller/dashb using the admin user account and password chosen during the admin account creation.

About the Author

  • Arthur Berezin

    Arthur Berezin is an active member of the OpenStack community and a hands-on OpenStacker since the early Essex release of OpenStack in 2012. During this time Arthur has built multiple production data centers based on OpenStack, helped dozens of organizations in planning their OpenStack environments, and in executing their software defined data center strategy. Prior to OpenStack, Arthur worked on KVM virtualization management project oVirt/RHEV and open source virtualization management technologies for production mission critical environments.

    Arthur is the Director of Product for Cloudify at GigaSpaces. He works on open-source and open-standard cloud application orchestration platform with cloud aware applications in mind that run natively on OpenStack and other private and public clouds. Prior to Cloudify, Arthur was a Senior Technical Product Manager for OpenStack at Red Hat, Product Owner of Keystone, Heat, Horizon, RHEL OpenStack Platform Installer (Foreman/Puppet based Project Staypuft), Packstack, and OpenStack High Availability.

    In the past 14 years, Arthur has served in various management and technical positions in the high-tech industry, including working as a founder and technical lead of a start up, a product line lead, Linux consultant, technical pre/post sales, and as a Linux Instructor, where he prepared students to pass the Red Hat Certified Engineer (RHCE) exams. You can find Arthur on Twitter as @ArthurBerezin or on his blog at www.Berezins.com.

    Browse publications by this author

Latest Reviews

(2 reviews total)
it helped me with my queries.
Production Ready OpenStack - Recipes for Successful Environments
Unlock this book and the full library FREE for 7 days
Start now