Red Hat 6 Deploying OpenStack: Learning Environments (Manual Setup) OpenStack Platform User guide

1. Created an Administrator role named ad mi n (refer to Section 3.7, “ Create an Administrator

Deploying O penSt ack: Learning Environment s (Manual Set up)

In this procedure, you will:

1. Create the swi ft user, who has the ad mi n role in the servi ces tenant.

2. Create the swi ft service entry and assign it an endpoint.

In order to proceed, you should have already performed the following (using the Identity service):

2. Created the servi ces tenant (refer to

service users. For more information, refer to Section 3.9, “ Create the Services Tenant” .

for instructions)

Note

The Deploying OpenStack: Learning Environments (Manual Set Up) guide uses one tenant for all

You can perform this procedure from your Identity service server or on any machine where you've copied the keysto nerc_ad mi n file (which contains administrator credentials) and the keyst o n e command-line utility is installed.

Pro ced u re 4 .2. Co n f ig u rin g t h e O b ject St o rag e Service t o au t h en t icat e t h ro u g h t h e

Id en t it y Service

1. Set up the shell to access Keystone as the admin user:

# so urce ~ /keysto nerc_ad mi n

2. Create the swi ft user and set its password by replacing PASSWORD with your chosen password:

# keysto ne user-create --name swi ft --pass PASSWORD

3. Add the swi ft user to the servi ces tenant with the ad mi n role:

# keysto ne user-ro l e-ad d --user swi ft --ro l e ad mi n --tenant

servi ces

4. Create the swi ft Object Storage service entry:

# keysto ne servi ce-create --name swi ft --type o bject-sto re \

--d escri pti o n "Swi ft Sto rag e Servi ce"

5. Create the swi ft endpoint entry:

# keysto ne end po i nt-create \

--servi ce swi ft \

--publ i curl "http: //IP: 80 80 /v1/AUT H_\%(tenant_i d )s" \

--ad mi nurl "http: //IP: 80 80 /v1" \

--i nternal url "http: //IP: 80 80 /v1/AUT H_\%(tenant_i d )s"

⁠Chapt er 4 . O penSt ack O bject St orage Service Inst allat ion

Replace IP with the IP address or fully qualified domain name of the system hosting the

Object Storage Proxy service.

You have configured the Identity service to work with the Object Storage service.

4 .6.2. Configure t he Object St orage Service St orage Nodes

The Object Storage Service stores objects on the filesystem, usually on a number of connected physical storage devices. All of the devices which will be used for object storage must be formatted

ext4 or XFS, and mounted under the /srv/no d e/ directory. All of the services that will run on a given node must be enabled, and their ports opened.

While you can run the proxy service alongside the other services, the proxy service is not covered in this procedure.

Pro ced u re 4 .3. Co n f ig u rin g t h e O b ject St o rag e Service st o rag e n o d es

1. Format your devices using the ext4 or XFS filesystem. Make sure that xattrs are enabled.

2. Add your devices to the /etc/fstab file to ensure that they are mounted under /srv/no d e/ at boot time.

Use the bl ki d command to find your device's unique ID, and mount the device using its unique ID.

Note

If using ext4 , ensure that extended attributes are enabled by mounting the filesystem with the user_xattr option. (In XFS, extended attributes are enabled by default.)

3. Configure the firewall to open the TCP ports used by each service running on each node.

By default, the account service uses port 6202, the container service uses port 6201, and the object service uses port 6200.

a. Open the /etc/sysco nfi g /i ptabl es file in a text editor.

b. Add an INP UT rule allowing TCP traffic on the ports used by the account, container, and object service. The new rule must appear before any reject-wi th i cmp-

ho st-pro hi bi ted rule.

-A INPUT -p tcp -m multiport --dports 6200,6201,6202,873 -j

ACCEPT c. Save the changes to the /etc/sysco nfi g /i ptabl es file.

d. Restart the i ptabl es service for the firewall changes to take effect.

# servi ce i ptabl es restart

4. Change the owner of the contents of /srv/no d e/ to swi ft: swi ft with the cho wn command.

# cho wn -R swi ft: swi ft /srv/no d e/

Deploying O penSt ack: Learning Environment s (Manual Set up)

5. Set the SELi nux context correctly for all directories under /srv/no d e/ with the resto rco n command.

# resto reco n -R /srv

6. Use the o penstack-co nfi g command to add a hash prefix (swift_hash_path_prefix) to your /etc/swi ft/swi ft. co nf:

# o penstack-co nfi g --set /etc/swi ft/swi ft. co nf swi ft-hash

swi ft_hash_path_prefi x \

$(o penssl rand -hex 10 )

7. Use the o penstack-co nfi g command to add a hash suffix (swift_hash_path_suffix) to your

/etc/swi ft/swi ft. co nf:

# o penstack-co nfi g --set /etc/swi ft/swi ft. co nf swi ft-hash

swi ft_hash_path_suffi x \

$(o penssl rand -hex 10 )

These details are required for finding and placing data on all of your nodes. Back

/etc/swi ft/swi ft. co nf up.

8. Use the o penstack-co nfi g command to set the IP address your storage services will listen on. Run these commands for every service on every node in your Object Storage cluster.

# o penstack-co nfi g --set /etc/swi ft/o bject-server. co nf \

D EFAULT bi nd _i p node_ip_address

# o penstack-co nfi g --set /etc/swi ft/acco unt-server. co nf \

D EFAULT bi nd _i p node_ip_address

# o penstack-co nfi g --set /etc/swi ft/co ntai ner-server. co nf \

D EFAULT bi nd _i p node_ip_address

The D EFAULT argument specifies the D EFAULT section of the service configuration file.

Replace node_ip_address with the IP address of the node you are configuring.

9. Copy /etc/swi ft/swi ft. co nf from the node you are currently configuring, to all of your

Object Storage Service nodes.

Important

The /etc/swi ft/swi ft. co nf file must be identical on all of your Object Storage

Service nodes.

10. Start the services which will run on your node.

# servi ce o penstack-swi ft-acco unt start

# servi ce o penstack-swi ft-co ntai ner start

# servi ce o penstack-swi ft-o bject start

11. Use the chkco nfi g command to make sure the services automatically start at boot time.

⁠Chapt er 4 . O penSt ack O bject St orage Service Inst allat ion

# chkco nfi g o penstack-swi ft-acco unt o n

# chkco nfi g o penstack-swi ft-co ntai ner o n

# chkco nfi g o penstack-swi ft-o bject o n

All of the devices that your node will provide as object storage are formatted and mounted under

/srv/no d e/. Any service running on the node has been enabled, and any ports used by services on the node have been opened.

4 .6.3. Configure t he Object St orage Service Proxy Service

The Object Storage proxy service determines to which node g ets and puts are directed.

Although you can run the account, container, and object services alongside the proxy service, only the proxy service is covered in the following procedure.

Note

Because the SSL capability built into the Object Storage service is intended primarily for testing, it is not recommended for use in production. In a production cluster, Red Hat recommends that you use the load balancer to terminate SSL connections.

Pro ced u re 4 .4 . Co n f ig u rin g t h e O b ject St o rag e Service p ro xy service

1. Update the configuration file for the proxy server with the correct authentication details for the appropriate service user:

# o penstack-co nfi g --set /etc/swi ft/pro xy-server. co nf \

fi l ter: authto ken auth_ho st IP

# o penstack-co nfi g --set /etc/swi ft/pro xy-server. co nf \

fi l ter: authto ken ad mi n_tenant_name services

# o penstack-co nfi g --set /etc/swi ft/pro xy-server. co nf \

fi l ter: authto ken ad mi n_user swift

# o penstack-co nfi g --set /etc/swi ft/pro xy-server. co nf \

fi l ter: authto ken ad mi n_passwo rd PASSWORD

Where:

IP - The IP address or host name of the Identity server.

services - The name of the tenant that was created for the use of the Object Storage service

(previous examples set this to servi ces).

swift - The name of the service user that was created for the Object Storage service

(previous examples set this to swi ft).

PASSWORD - The password associated with the service user.

2. Start the memcached and o penstack-swi ft-pro xy services using the servi ce command:

# servi ce memcached start

# servi ce o penstack-swi ft-pro xy start

Deploying O penSt ack: Learning Environment s (Manual Set up)

3. Enable the memcached and o penstack-swi ft-pro xy services permanently using the

chkco nfi g command:

# chkco nfi g memcached o n

# chkco nfi g o penstack-swi ft-pro xy o n

4. Allow incoming connections to the Swift proxy server by adding this firewall rule to the

/etc/sysco nfi g /i ptabl es configuration file:

-A INPUT -p tcp -m multiport --dports 8080 -j ACCEPT

Important

This rule allows communication from all remote hosts to the system hosting the Swift proxy on port 80 80 . For information regarding the creation of more restrictive firewall rules refer to the Red Hat Enterprise Linux Security Guide from the following link: https://access.redhat.com/site/documentation/en-US/Red_Hat_Enterprise_Linux/

5. Use the servi ce command to restart the i ptabl es service for the new rule to take effect:

# servi ce i ptabl es save

# servi ce i ptabl es restart

The Object Storage Service proxy service is now listening for HTTP put and get requests on port

8080, and directing them to the appropriate nodes.

4 .6.4 . Object St orage Service Rings

Rings determine where data is stored in a cluster of storage nodes. Ring files are generated using the

swif t - rin g - b u ild er tool. Three ring files are required, one each for the o b ject , co n t ain er, and

acco u n t services.

Each storage device in a cluster is divided into partitions, with a recommended minimum of 100 partitions per device. Each partition is physically a directory on disk. A configurable number of bits from the MD5 hash of the filesystem path to the partition directory, known as the partition power, is used as a partition index for the device. The partition count of a cluster that has 1000 devices, where each device has 100 partitions on it, is 100 000.

The partition count is used to calculate the partition power, where 2 to the partition power is the partition count. If the partition power is a fraction, it is rounded up. If the partition count is 100 000, the part power is 17 (16.610 rounded up). This can be expressed mathematically as: 2 ^ partition power = partition count.

4 .6.5. Build Object St orage Service Ring Files

Three ring files need to be created: one to track the objects stored by the Object Storage Service, one to track the containers in which objects are placed, and one to track which accounts can access which containers. The ring files are used to deduce where a particular piece of data is stored.

Ring files are generated using four possible parameters: partition power, replica count, zone, and the amount of time that must pass between partition reassignments.

⁠Chapt er 4 . O penSt ack O bject St orage Service Inst allat ion

T ab le 4 .1. Paramet ers u sed wh en b u ild in g rin g f iles

Rin g File Paramet er

part_power

Descrip t io n

2 ^ partition power = partition count.

The partition is rounded up after calculation.

replica_count min_part_hours zone

The number of times that your data will be replicated in the cluster.

Minimum number of hours before a partition can be moved. This parameter increases availability of data by not moving more than one copy of a given data item within that min_part_hours amount of time.

Used when adding devices to rings (optional).

Z ones are a flexible abstraction, where each zone should be separated from other zones as possible in your deployment. You can use a zone to represent sites, cabinet, nodes, or even devices.

Pro ced u re 4 .5. Bu ild in g O b ject St o rag e service rin g f iles

1. Use the swi ft-ri ng -bui l d er command to build one ring for each service. Provide a builder file, a partition power, a replica count, and the minimum hours between partition re-

assignment:

# swi ft-ri ng -bui l d er /etc/swi ft/o bject. bui l d er create part_power

replica_count min_part_hours

# swi ft-ri ng -bui l d er /etc/swi ft/co ntai ner. bui l d er create

part_power replica_count min_part_hours

# swi ft-ri ng -bui l d er /etc/swi ft/acco unt. bui l d er create part_power

replica_count min_part_hours

2. When the rings are created, add devices to the account ring.

# swi ft-ri ng -bui l d er /etc/swi ft/acco unt. bui l d er ad d

zX-SERVICE_IP: 6 20 2/dev_mountpt part_count

Where:

X is the corresponding integer of a specified zone (for example, z1 would correspond to

Z one One).

SERVICE_IP is the IP on which the account, container, and object services should listen.

This IP should match the bi nd _i p value set during the configuration of the Object

Storage service Storage Nodes.

dev_mountpt is the /srv/no d e subdirectory under which your device is mounted.

part_count is the partition count you used to calculate your partition power.

For example, if:

The account, container, and object services are configured to listen on 10 . 6 4 . 115. 4 4 on Z one One,

Deploying O penSt ack: Learning Environment s (Manual Set up)

Your device is mounted on /srv/no d e/acco unts, and

You wish to set a partition count of 100.

Then run:

# swi ft-ri ng -bui l d er /etc/swi ft/acco unt. bui l d er ad d z1-

10 . 6 4 . 115. 4 4 : 6 20 2/acco unts 10 0

Note

Repeat this step for each device (on each node in the cluster) you want added to the ring.

3. In a similar fashion, add devices to both containers and objects rings:

# swi ft-ri ng -bui l d er /etc/swi ft/co ntai ner. bui l d er ad d

zX-SERVICE_IP: 6 20 1/dev_mountpt part_count

# swi ft-ri ng -bui l d er /etc/swi ft/o bject. bui l d er ad d

zX-SERVICE_IP: 6 20 0 /dev_mountpt part_count

Replace the variables herein with the same ones used in the previous step.

Note

Repeat these commands for each device (on each node in the cluster) you want added to the ring.

4. Distribute the partitions across the devices in the ring using the swi ft-ri ng -bui l d er command's rebal ance argument.

# swi ft-ri ng -bui l d er /etc/swi ft/acco unt. bui l d er rebal ance

# swi ft-ri ng -bui l d er /etc/swi ft/co ntai ner. bui l d er rebal ance

# swi ft-ri ng -bui l d er /etc/swi ft/o bject. bui l d er rebal ance

5. Check to see that you now have 3 ring files in the directory /etc/swi ft. The command:

# l s /etc/swi ft/*g z should reveal:

/etc/swift/account.ring.gz /etc/swift/container.ring.gz

/etc/swift/object.ring.gz

6. Start the o penstack-swi ft-pro xy service:

# servi ce o penstack-swi ft-pro xy start

⁠Chapt er 4 . O penSt ack O bject St orage Service Inst allat ion

7. Ensure that all files in the /etc/swi ft/ directory including those that you have just created are owned by the ro o t user and swi ft group.

Important

All mount points must be owned by ro o t; all roots of mounted file systems must be owned by swi ft. Before running the following command, ensure that all devices are already mounted and owned by ro o t.

# cho wn -R ro o t: swi ft /etc/swi ft

8. Copy each ring builder file to each node in the cluster, storing them under /etc/swi ft/.

# scp /etc/swift/*.gz node_ip_address:/etc/swift

You have created rings for each of the services that require them. You have used the builder files to distribute partitions across the nodes in your cluster, and have copied the ring builder files themselves to each node in the cluster.

4 .7. Validat e t he Object St orage Service Inst allat ion

After installing and configuring the Block Storage service, perform the following steps to validate it:

Pro ced u re 4 .6 . Valid at in g t h e O b ject St o rag e Service in st allat io n

1. On your proxy server node, use the o penstack-co nfi g command to turn on debug level logging:

# o penstack-co nfi g --set /etc/swi ft/pro xy-server. co nf D EFAULT

l o g _l evel d ebug

2. Set up the shell to access Keystone as the admin user:

$ so urce ~ /keysto nerc_ad mi n

3. Use the swi ft list to make sure you can connect to your proxy server:

$ swi ft l i st

Message from syslogd@ example-swift-01 at Jun 14 02:46:00 ...

135 proxy-server Server reports support for api versions: v3.0, v2.0

4. Use the swi ft command to upload some files to your Object Storage Service nodes

$ head -c 10 24 /d ev/urand o m > d ata1. fi l e ; swi ft upl o ad c1

d ata1. fi l e

$ head -c 10 24 /d ev/urand o m > d ata2. fi l e ; swi ft upl o ad c1

d ata2. fi l e

$ head -c 10 24 /d ev/urand o m > d ata3. fi l e ; swi ft upl o ad c1

d ata3. fi l e

Deploying O penSt ack: Learning Environment s (Manual Set up)

5. Use the swi ft command to take a listing of the objects held in your Object Storage Service cluster.

$ swi ft l i st

$ swi ft l i st c1 data1.file

data2.file

data3.file

You have now uploaded 3 files into 1 container. If you check the other storage devices, you will find more . d ata files, depending on your replica count.

$ fi nd /srv/no d e/ -type f -name "*d ata"

⁠Chapt er 5. O penSt ack Image Service Inst allat ion

Chapter 5. OpenStack Image Service Installation

5.1. Image Service Requirement s

To install the Image service, you must have access to:

MariaDB database server root credentials and IP address

Identity service administrator credentials and endpoint URL

If using the OpenStack Object Storage service as the storage backend, you will also need to know

the service's endpoint public URL. This endpoint is configured as part of Section 4.6.1, “ Create the

Object Storage Service Identity Records” .

5.2. Inst all t he Image Service Packages

The OpenStack Image service requires the following packages:

openstack-glance

Provides the OpenStack Image service.

openstack-utils

Provides supporting utilities to assist with a number of tasks including the editing of configuration files.

openstack-selinux

Provides OpenStack specific SELinux policy modules.

To install all of the above packages, execute the following command while logged in as the ro o t user.

# yum i nstal l -y o penstack-g l ance o penstack-uti l s o penstack-sel i nux

The OpenStack Image service is now installed and ready to be configured.

5.3. Creat e t he Image Service Dat abase

In this procedure, the database and database user that will be used by the Image service will be created. These steps must be performed while logged in to the database server as the ro o t user (or as a user with suitable access: create d b, create user, g rant permi ssi o ns).

Pro ced u re 5.1. Creat in g t h e Imag e Service d at ab ase

1. Connect to the database service using the mysq l command.

# mysq l -u ro o t -p

2. Create the g l ance database.

mysq l > CREATE DATABASE glance;

Deploying O penSt ack: Learning Environment s (Manual Set up)

3. Create a g l ance database user and grant it access to the g l ance database.

mysq l > GRANT ALL ON glance.* TO 'glance'@ '%' IDENTIFIED BY

'PASSWORD';

mysq l > GRANT ALL ON glance.* TO 'glance'@ 'localhost' IDENTIFIED

BY 'PASSWORD';

Replace PASSWORD with a secure password that will be used to authenticate with the database server as this user.

4. Flush the database privileges to ensure that they take effect immediately.

mysq l > FLUSH PRIVILEGES;

5. Exit the mysq l client.

mysq l > quit

The Image Service database has been created. The database will be populated during service configuration.

5.4 . Configuring t he Image Service

5.4 .1. Configurat ion Overview

To configure the Image service, the following must be completed:

Configure TLS/SSL.

Configure the Identity service for Image service authentication (create database entries, set connection strings, and update configuration files).

Configure the disk-image storage backend (this guide uses the Object Storage service).

Configure the firewall for Image service access.

Populate the Image service database.

5.4 .2. Creat e t he Image Ident it y Records

This section outlines the steps for creating and configuring Identity service records required by the

Image service.

1. Create the g l ance user, who has the ad mi n role in the servi ces tenant.

2. Create the g l ance service entry and assign it an endpoint.

These entries assist other OpenStack services attempting to locate and access the volume functionality provided by the Image service.

In order to proceed, you should have already performed the following (through the Identity service):

1. Created an Administrator role named ad mi n (refer to Section 3.7, “ Create an Administrator

⁠Chapt er 5. O penSt ack Image Service Inst allat ion

2. Created the servi ces tenant (refer to

service users. For more information, refer to Section 3.9, “ Create the Services Tenant” .

for instructions)

Note

The Deploying OpenStack: Learning Environments (Manual Set Up) guide uses one tenant for all

You can perform this procedure from your Identity service host or on any machine where you've copied the keysto nerc_ad mi n file (which contains administrator credentials) and the keyst o n e command-line utility is installed.

Pro ced u re 5.2. Co n f ig u rin g t h e Imag e Service t o au t h en t icat e t h ro u g h t h e Id en t it y

Service

1. Authenticate as the administrator of the Identity service by running the so urce command on the keysto nerc_ad mi n file:

# so urce ~ /keysto nerc_ad mi n

2. Create a user named g l ance for the Image Service to use:

# keysto ne user-create --name g l ance --pass PASSWORD

+----------+----------------------------------+

| Property | Value |

+----------+----------------------------------+

| email | |

| enabled | True |

| id | 8091eaf121b641bf84ce73c49269d2d1 |

| name | glance |

| tenantId | |

+----------+----------------------------------+

Replace PASSWORD with a secure password that will be used by the Image Service when authenticating with the Identity service.

3. Use the keysto ne user-ro l e-ad d command to link the g l ance user and the ad mi n role together within the context of the servi ces tenant:

# keysto ne user-ro l e-ad d --user g l ance --ro l e ad mi n --tenant

servi ces

4. Create the g l ance service entry:

# keysto ne servi ce-create --name g l ance \

--type i mag e \

--d escri pti o n "G l ance Imag e Servi ce"

+-------------+----------------------------------+

| Property | Value |

+-------------+----------------------------------+

| description | Glance Image Service |

Deploying O penSt ack: Learning Environment s (Manual Set up)

| id | 7461b83f96bd497d852fb1b85d7037be |

| name | glance |

| type | image |

+-------------+----------------------------------+

5. Create the g l ance endpoint entry:

# keysto ne end po i nt-create \

--servi ce g l ance \

--publ i curl "http: //IP: 9 29 2" \

--ad mi nurl "http: //IP: 9 29 2" \

--i nternal url "http: //IP: 9 29 2"

Replace IP with the IP address or host name of the system hosting the Image Service.

All supporting Identity service entries required by the Image Service have been created.

5.4 .3. Configure t he Image Service Dat abase Connect ion

The database connection string used by the Image service is defined in the

/etc/g l ance/g l ance-api . co nf and /etc/g l ance/g l ance-reg i stry. co nf files. It must be updated to point to a valid database server before starting the service.

All commands in this procedure must be run while logged in as the ro o t user on the server hosting the Image service.

Pro ced u re 5.3. Co n f ig u rin g t h e Imag e Service SQ L d at ab ase co n n ect io n

1. Use the o penstack-co nfi g command to set the value of the sq l _co nnecti o n configuration key in the /etc/g l ance/g l ance-api . co nf file.

# o penstack-co nfi g --set /etc/g l ance/g l ance-api . co nf \

D EFAULT sq l _co nnecti o n mysq l : //USER: PASS@ IP/DB

Replace:

USER with the database user name the Image service is to use, usually g l ance.

PASS with the password of the chosen database user.

IP with the IP address or host name of the database server.

DB with the name of the database that has been created for use by the Image service, usually g l ance.

2. Use the o penstack-co nfi g command to set the value of the sq l _co nnecti o n configuration key in the /etc/g l ance/g l ance-reg i stry. co nf file.

# o penstack-co nfi g --set /etc/g l ance/g l ance-reg i stry. co nf \

D EFAULT sq l _co nnecti o n mysq l : //USER: PASS@ IP/DB

Replace the placeholder values USER, PASS, IP, and DB with the same values used in the previous step.

⁠Chapt er 5. O penSt ack Image Service Inst allat ion

Important

The IP address or host name specified in the connection configuration key must match the IP address or host name to which the glance database user was granted access when creating the glance database. Moreover, if the database is hosted locally and you granted permissions to 'localhost' when creating the glance database, you must enter 'localhost'.

The database connection string has been set and will be used by the Image service.

5.4 .4 . Configure Image Service Aut hent icat ion

To update the Image configuration files for Identity usage, execute the following commands as the

ro o t user on each node hosting the Image service:

Pro ced u re 5.4 . Co n f ig u rin g t h e Imag e Service t o au t h en t icat e t h ro u g h t h e Id en t it y

Service

1. Configure the g l ance-api service:

# o penstack-co nfi g --set /etc/g l ance/g l ance-api . co nf \

paste_d epl o y fl avo r keysto ne

# o penstack-co nfi g --set /etc/g l ance/g l ance-api . co nf \

keysto ne_authto ken auth_ho st IP

# o penstack-co nfi g --set /etc/g l ance/g l ance-api . co nf \

keysto ne_authto ken auth_po rt 35357

# o penstack-co nfi g --set /etc/g l ance/g l ance-api . co nf \

keysto ne_authto ken auth_pro to co l http

# o penstack-co nfi g --set /etc/g l ance/g l ance-api . co nf \

keysto ne_authto ken ad mi n_tenant_name services

# o penstack-co nfi g --set /etc/g l ance/g l ance-api . co nf \

keysto ne_authto ken ad mi n_user glance

# o penstack-co nfi g --set /etc/g l ance/g l ance-api . co nf \

keysto ne_authto ken ad mi n_passwo rd PASSWORD

2. Configure the g l ance-reg i stry service:

# o penstack-co nfi g --set /etc/g l ance/g l ance-reg i stry. co nf \

paste_d epl o y fl avo r keysto ne

# o penstack-co nfi g --set /etc/g l ance/g l ance-reg i stry. co nf \

keysto ne_authto ken auth_ho st IP

# o penstack-co nfi g --set /etc/g l ance/g l ance-reg i stry. co nf \

keysto ne_authto ken auth_po rt 35357

# o penstack-co nfi g --set /etc/g l ance/g l ance-reg i stry. co nf \

keysto ne_authto ken auth_pro to co l http

# o penstack-co nfi g --set /etc/g l ance/g l ance-reg i stry. co nf \

keysto ne_authto ken ad mi n_tenant_name services

# o penstack-co nfi g --set /etc/g l ance/g l ance-reg i stry. co nf \

keysto ne_authto ken ad mi n_user glance

# o penstack-co nfi g --set /etc/g l ance/g l ance-reg i stry. co nf \

keysto ne_authto ken ad mi n_passwo rd PASSWORD where:

Deploying O penSt ack: Learning Environment s (Manual Set up)

IP - The IP address or host name of the Identity server.

services - The name of the tenant that was created for the use of the Image service (previous examples set this to servi ces).

glance - The name of the service user that was created for the Image service (previous examples set this to g l ance).

PASSWORD - The password associated with the service user.

5.4 .5. Using t he Object St orage Service for Image St orage

By default, the Image service uses the local file system (fi l e) for its storage backend. However, either of the following storage backends can be used to store uploaded disk images:

fi l e - Local file system of the Image server (/var/l i b/g l ance/i mag es/ directory)

swi ft - OpenStack Object Storage service

Note

The configuration procedure below uses the o penstack-co nfi g command. However, the

/etc/g l ance/g l ance-api . co nf file can also be manually updated. If manually updating the file:

1. Ensure that the d efaul t_sto re parameter is set to the correct backend (for example,

'd efaul t_sto re= rbd ').

2. Update the parameters in that backend's section (for example, under 'R BD Sto re

O pti o ns').

To change the configuration to use the Object Storage service, execute the following steps as the

ro o t user:

1. Set the d efaul t_sto re configuration key to swi ft:

# o penstack-co nfi g --set /etc/g l ance/g l ance-api . co nf \

D EFAULT d efaul t_sto re swi ft

2. Set the swi ft_sto re_auth_ad d ress configuration key to the public endpoint for the

Identity service:

# o penstack-co nfi g --set /etc/g l ance/g l ance-api . co nf \

D EFAULT swi ft_sto re_auth_ad d ress http: //IP: 50 0 0 /v2. 0 /

3. Add the container for storing images in the Object Storage Service:

# o penstack-co nfi g --set /etc/g l ance/g l ance-api . co nf \

D EFAULT swi ft_sto re_create_co ntai ner_o n_put T rue

4. Set the swi ft_sto re_user configuration key to contain the tenant and user to use for authentication in the format TENANT:USER:

⁠Chapt er 5. O penSt ack Image Service Inst allat ion

# o penstack-co nfi g --set /etc/g l ance/g l ance-api . co nf \

D EFAULT swi ft_sto re_user servi ces: swift

If you followed the instructions in this guide to deploy Object Storage, these values must be replaced with the servi ces tenant and the swi ft user respectively (as shown in the command example above).

If you did not follow the instructions in this guide to deploy Object Storage, these values must be replaced with the appropriate Object Storage tenant and user for your environment.

5. Set the swi ft_sto re_key configuration key to the password of the user to be used for authentication (that is, the password that was set for the swi ft user when deploying the

Object Storage service.

# o penstack-co nfi g --set /etc/g l ance/g l ance-api . co nf \

D EFAULT swi ft_sto re_key PASSWORD

5.4 .6. Configure t he Firewall t o Allow Image Service T raffic

The Image Service should be accessible over the network through port 9 29 2.

To allow this, the Image service should be configured to recognize the 9292 port, and the firewall on the system hosting the image storage service should also allow network traffic on the port. All steps in this procedure must be run while logged in to the server hosting the image storage service as the

ro o t user.

Pro ced u re 5.5. Co n f ig u rin g t h e f irewall t o allo w Imag e Service t raf f ic

1. Open the /etc/g l ance/g l ance-api . co nf file in a text editor, and remove any comment characters preceding the following parameters: bind_host = 0.0.0.0

bind_port = 9292

2. Open the /etc/sysco nfi g /i ptabl es file in a text editor.

3. Add an INPUT rule allowing TCP traffic on port 9 29 2 to the file. The new rule must appear before any INPUT rules that REJECT traffic.

-A INPUT -p tcp -m multiport --dports 9292 -j ACCEPT

4. Save the changes to the /etc/sysco nfi g /i ptabl es file.

5. Restart the i ptabl es service to ensure that the change takes effect.

# servi ce i ptabl es restart

The firewall is now configured to allow incoming connections to the Image Service on port 9 29 2.

5.4 .7. Configure Rabbit MQ Message Broker Set t ings for t he Image Service

Deploying O penSt ack: Learning Environment s (Manual Set up)

As of Red Hat Enterprise Linux OpenStack Platform 5, RabbitMQ replaces QPid as the default (and recommended) message broker. The RabbitMQ messaging service is provided by the rabbitmq-server package.

Pro ced u re 5.6 . Co n f ig u rin g t h e Imag e Service ( g lan ce) t o u se t h e Rab b it MQ messag e b ro ker

1. Log in as ro o t to the Image Service node.

2. In g l ance-api . co nf of that system, set RabbitMQ as the notifier:

# o penstack-co nfi g --set /etc/g l ance/g l ance-api . co nf \

D EFAULT no ti fi cati o n_d ri ver messag i ng

3. Set the name of the RabbitMQ host. Replace rabbi tmq -ho stname with the name of the

RabbitMQ host:

# o penstack-co nfi g --set /etc/g l ance/g l ance-api . co nf \

D EFAULT rabbi t_ho st RABBITMQ_HOST

Replace RABBITMQ_HOST with the IP address or host name of the message broker.

4. Set the message broker port to 56 72:

# o penstack-co nfi g --set /etc/g l ance/g l ance-api . co nf \

D EFAULT rabbi t_po rt 56 72

5. Set the RabbitMQ username and password created for the Image Service:

# o penstack-co nfi g --set /etc/g l ance/g l ance-api . co nf \

D EFAULT rabbi t_useri d g l ance

# o penstack-co nfi g --set /etc/g l ance/g l ance-api . co nf \

D EFAULT rabbi t_passwo rd GLANCE_PASS

Where g l ance and GLANCE_PASS are the RabbitMQ username and password created for

the Image Service (in Section 2.4.2, “ Install and Configure the RabbitMQ Message Broker”

6. In Section 2.4.2.1, “ Launch the RabbitMQ Message Broker” , we gave the g l ance user

read/write permissions to all resources -- specifically, through the virtual host /. Configure the

Image Service to connect to this virtual host:

# o penstack-co nfi g --set /etc/g l ance/g l ance-api . co nf \

D EFAULT rabbi t_vi rtual _ho st /

5.4 .8. Configure t he Image Service t o Use SSL

Use the following options in the g l ance-api . co nf file to configure SSL.

T ab le 5.1. SSL o p t io n s f o r Imag e Service

⁠Chapt er 5. O penSt ack Image Service Inst allat ion

Co n f ig u rat io n

O p t io n cert_fi l e key_fi l e ca_fi l e

Descrip t io n

Path to certificate file to use when starting API server securely.

Path to private key file to use when starting API server securely.

Path to CA certificate file to use to verify connecting clients.

5.4 .9. Populat e t he Image Service Dat abase

You can populate the Image Service database after you have successfully configured the Image

Service database connection string (refer to Section 5.4.3, “ Configure the Image Service Database

Connection” ).

Pro ced u re 5.7. Po p u lat in g t h e Imag e Service d at ab ase

1. Log in to the system hosting the Image service.

2. Use the su command to switch to the g l ance user.

# su g l ance -s /bi n/sh

3. Run the g l ance-manag e d b_sync command to initialize and populate the database identified in /etc/g l ance/g l ance-api . co nf and /etc/g l ance/g l ance-

reg i stry. co nf.

# g l ance-manag e d b_sync

The Image service database has been initialized and populated.

5.4 .10. Enable Image Loading T hrough t he Local File Syst em

By default, the Image service provides images to instances using the HTTP protocol. That is, image data is transmitted from the image store to the local disk of the Compute node using HTTP.

This process is typical for most deployments where the Image and Compute services are installed on different hosts.

Note

You can use direct image access even if Image and Compute services are not installed on the same hosts, but are sharing a shared file system. The only requirement in this case would be to have the file system mounted in the same location.

In deployments where both services are installed on the same host (and, consequently, share the same file system), it is more efficient to skip the HTTP steps altogether. Instead, you will need to configure both Image and Compute services to send and receive images using the local file system.

To do this:

Pro ced u re 5.8. Co n f ig u rin g Imag e an d Co mp u t e services t o sen d /receive imag es t h ro u g h t h e lo cal f ile syst em

Deploying O penSt ack: Learning Environment s (Manual Set up)

Important

The Image file system metadata to be generated for this procedure will only apply to new images. Any existing images will not use this metadata.

1. Create a JSON document that exposes the Image file system metadata required by

o penstack-no va-co mpute.

2. Configure the Image service to use the JSON document.

3. Configure o penstack-no va-co mpute to use the file system metadata provided by the

Image service.

Note

If both Image and Compute services are hosted on different nodes, you can emulate local file system sharing through Gluster.

The following sections describe this in more detail.

5 .4 .1 0 .1 . Co nfigure File Syst e m Sharing Acro ss Diffe re nt Im age and Co m put e

No de s

If both the Image and Compute services are hosted on different nodes, you can still enable them to share images locally. To do so, you will have to use Gluster (Red Hat Storage shares).

With this configuration, both Image and Compute services will have to share the same Gluster volume. For this, the same volume must be mounted on their respective nodes. Doing so will allow both services to access the same volume locally, thereby allowing image loading through local file system.

This configuration requires that you:

1. Install and configure the packages required for Gluster on the nodes hosting Image and

Compute services.

2. Create the GlusterFS volume to be shared by both Image and Compute services.

3. Mount the GlusterFS volume on the Image and Compute service nodes.

Note

For instructions on this procedure, refer to the latest version of the Configuring Red Hat

OpenStack with Red Hat Storage guide available from: https://access.redhat.com/site/documentation/en-US/Red_Hat_Storage/

Once you have configured the GlusterFS volume and mounted it on the Image service node, you will also have to configure the Compute service node to use the mounted Gluster volume. To do so:

Pro ced u re 5.9 . Co n f ig u rin g t h e Co mp u t e service n o d e t o u se a mo u n t ed G lu st er vo lu me

⁠Chapt er 5. O penSt ack Image Service Inst allat ion

1. Log in to the Compute service node.

2. From there, install the packages required for Gluster:

# yum i nstal l -y g l usterfs g l usterfs-fuse

3. Ensure that the drivers required to load the Gluster volume are enabled. To do so: a. Open the /etc/no va/no va. co nf configuration file.

b. Search for the Li bvi rt handlers for remote volumes (specifically,

vo l ume_d ri vers). The value for this parameter should be a comma-delimited list of drivers for different types of volumes.

c. Depending on your Compute service deployment, the vo l ume_d ri vers may already be enabled (as in, uncommented). If so, ensure that the Gluster volume driver (namely

g l usterfs= no va. vi rt. l i bvi rt. vo l ume. Li bvi rtG l usterfsVo l umeD ri ver

is also listed.

If the vo l ume_d ri vers parameter is disabled or is not listed, edit the file accordingly.

4. Configure the Compute service to use the mounted Gluster volume:

# o penstack-co nfi g --set /etc/no va/no va-co nf \

D EFAULT g l usterfs_mo unt_po i nt_base GLUSTER_MOUNT

Replace GLUSTER_MOUNT with the directory where the Gluster volume is mounted.

5. Restart the Compute service.

# servi ce o penstack-no va-co mpute restart

After completing these procedures, both Image and Compute services can now emulate accessing the same file system as if it were a local file system. You can then enable image loading through the local file system as normal.

5 .4 .1 0 .2 . Co nfigure t he Im age Se rvice t o Pro vide Im age s T hro ugh t he Lo cal File

Syst e m

In order to enable image loading through the local file system (as opposed to HTTP), the Image service needs to first expose its local file-system metadata to the o penstack-no va-co mpute service. To do so:

Pro ced u re 5.10. Co n f ig u rin g t h e Imag e service t o exp o se lo cal f ile syst em met ad at a t o t h e Co mp u t e service

1. Determine the mount point of the file system used by the Image service:

# d f

Filesystem 1K-blocks Used Available Use% Mounted on

/dev/sda3 51475068 10905752 37947876 23% / devtmpfs 2005504 0 2005504 0% /dev tmpfs 2013248 668 2012580 1% /dev/shm

Deploying O penSt ack: Learning Environment s (Manual Set up)

For example, if the Image service uses the /d ev/sd a3 file system, then its corresponding mount point is /.

2. Create a unique ID for the mount point using:

# uui d g en

ad5517ae-533b-409f-b472-d82f91f41773

Note the output of the uui d g en, as this will be used in the next step.

3. Create a file with the . jso n extension.

4. Open the file and add the following information:

{

"id": "UID",

"mountpoint": "MOUNTPT"

}

Where:

UID is the unique ID created in the previous step.

MOUNTPT is the mount point of the Image service's file system (as determined in the first step).

5. Configure the Image service to use this JSON file:

# o penstack-co nfi g --set /etc/g l ance/g l ance-api . co nf \

D EFAULT sho w_mul ti pl e_l o cati o ns T rue

# o penstack-co nfi g --set /etc/g l ance/g l ance-api . co nf \

D EFAULT fi l esystem_sto re_metad ata_fi l e JSON_PATH

Replace JSON_PATH with the full path to the JSON file.

6. Restart the Image service (if already running).

# servi ce o penstack-g l ance-reg i stry restart

# servi ce o penstack-g l ance-api restart

Important

The Image file-system metadata generated for this procedure only applies to new images. Any image that exists (that is, prior to this procedure) will not use this metadata.

5 .4 .1 0 .3. Co nfigure t he Co m put e Se rvice t o Use Lo cal File Syst e m Me t adat a

After configuring the Image Service to expose local file system metadata (as part of Section 5.4.10.2,

“ Configure the Image Service to Provide Images Through the Local File System” ), you can then

configure the Compute service to use this metadata. Doing so allows o penstack-no va-co mpute to load images from the local file system.

⁠Chapt er 5. O penSt ack Image Service Inst allat ion

To do so:

Pro ced u re 5.11. Co n f ig u rin g t h e Co mp u t e service t o u se f ile syst em met ad at a p ro vid ed b y t h e Imag e Service

1. Configure o penstack-no va-co mpute to enable the use of direct URLs that have the

fi l e: // scheme:

# o penstack-co nfi g --set /etc/no va/no va. co nf \

D EFAULT al l o wed _d i rect_url _schemes fi l e

2. Create an entry for the Image service's file system:

# o penstack-co nfi g --set /etc/no va/no va. co nf \

i mag e_fi l e_url fi l esystems FSENTRY

Replace FSENTRY with the name you wish to assign to the Image service's file system.

3. Open the . jso n file used by the Image service to expose its local file system metadata. The information in this file will be used in the next step.

4. Associate the entry created in the previous step to the file system metadata exposed by the

Image service:

# o penstack-co nfi g --set /etc/no va/no va. co nf \

i mag e_fi l e_url : FSENTRY i d UID

# o penstack-co nfi g --set /etc/no va/no va. co nf \

i mag e_fi l e_url : FSENTRY mo untpo i nt MOUNTPT

Where:

UID is the unique ID used by the Image service. In the . jso n file used by the Image service, the UID is the "i d ": value.

MOUNTPT is the mount point used by the Image service's file system. In the . jso n file used by the Image service, the MOUNTPT is the "mo untpo i nt": value.

5.5. Launch t he Image API and Regist ry Services

Now that Glance has been configured, start the g l ance-api and g l ance-reg i stry services as the ro o t user:

# servi ce o penstack-g l ance-reg i stry start

# servi ce o penstack-g l ance-api start

# chkco nfi g o penstack-g l ance-reg i stry o n

# chkco nfi g o penstack-g l ance-api o n

5.6. Validat e t he Image Service Inst allat ion

5.6.1. Obt ain a T est Disk Image

Deploying O penSt ack: Learning Environment s (Manual Set up)

A disk image can be downloaded from Red Hat, which can be used as a test in the import of images

into the Image service (see Section 5.6.3, “ Upload a Disk Image” ).

A new image is provided with each minor Red Hat Enterprise Linux 6 release, and is available in the download section of the Red Hat Enterprise Linux 6 Server channel: https://rhn.redhat.com/rhn/software/channel/downloads/Download.do?cid=16952

The wg et command below uses an example URL.

# mkd i r /tmp/i mag es

# cd /tmp/i mag es

# wg et -c -O rhel -6 -server-x86 _6 4 -d i sc1. i so "https: //co ntent-

web. rhn. red hat. co m/rhn/i so s/xxxx/rhel -6 -server-x86 _6 4 d i sc1. i so xxxxxxxx"

5.6.2. Build a Cust om Virt ual Machine Image

Red Hat Enterprise Linux OpenStack Platform includes Oz, a set of libraries and utilities for performing automated operating system installations with limited input from the user. Oz is also useful for building virtual machine images that can be uploaded to the Image service and used to launch virtual machine instances.

Template Description Language (TDL) Files - Oz accepts input in the form of XML-based TDL files, which describe the operating system being installed, the installation media's source, and any additional packages or customization changes that must be applied to the image.

vi rt-sysprep - It is also recommended that the vi rt-sysprep command is run on Linux-based virtual machine images prior to uploading them to the Image service. The vi rt-sysprep command re-initializes a disk image in preparation for use in a virtual environment. Default operations include the removal of SSH keys, removal of persistent MAC addresses, and removal of user accounts.

The vi rt-sysprep command is provided by the libguestfs-tools package.

Important

Oz makes use of the d efaul t Libvirt network. It is recommended that you do not build images using Oz on a system that is running either the no va-netwo rk service or any of the

OpenStack Networking components.

Pro ced u re 5.12. Bu ild in g Imag es u sin g O z

1. Use the yum command to install the oz and libguestfs-tools packages.

# yum i nstal l -y o z l i bg uestfs-to o l s

2. Download the Red Hat Enterprise Linux 6 Server installation DVD ISO file.

Although Oz supports the use of network-based installation media, in this procedure a Red

Hat Enterprise Linux 6 DVD ISO will be used.

3. Use a text editor to create a TDL file for use with Oz. The following example displays the syntax for a basic TDL file.

⁠Chapt er 5. O penSt ack Image Service Inst allat ion

Examp le 5.1. T DL File

The template below can be used to create a Red Hat Enterprise Linux 6 disk image. In particular, note the use of the ro o tpw element to set the password for the ro o t user and the i so element to set the path to the DVD ISO.

<description> Red Hat 6.6 x86_64 template </description>

<os>

PASSWORD

</rootpw>

<iso>

file:///home/user/rhel-server-6.6-x86_64-dvd.iso

</iso>

</install>

</os>

<command name = 'console' > sed -i 's/ rhgb//g' /boot/grub/grub.conf

sed -i 's/ quiet//g' /boot/grub/grub.conf

sed -i 's/ console=tty0 / console=ttyS0,115200n8 console=tty0 /g'

/boot/grub/grub.conf

</command>

</commands>

</template>

4. Run the o z-i nstal l command to build an image:

# o z-i nstal l -u -d 3 TDL_FILE

Syntax:

-u ensures any required customization changes to the image are applied after guest operating installation.

-d 3 enables the display of errors, warnings, and informational messages.

TDL_FILE provides the path to your TDL file.

By default, Oz stores the resultant image in the /var/l i b/l i bvi rt/i mag es/ directory.

This location is configurable by editing the /etc/o z/o z. cfg configuration file.

5. Run the vi rt-sysprep command on the image to re-initialize it in preparation for upload to the Image service. Replace FILE with the path to the disk image.

# vi rt-sysprep --ad d FILE

Refer to the vi rt-sysprep manual page by running the man vi rt-sysprep command for information on enabling and disabling specific operations.

You have successfully created a Red Hat Enterprise Linux based image that is ready to be added to the Image service.

Deploying O penSt ack: Learning Environment s (Manual Set up)

Note

The Red Hat Enterprise Linux OpenStack Platform 5 release included the Disk Imag e

Bu ild er as a Technology Preview. This tool provides automation to build RAM disks and disk images for deploying instances through OpenStack. While users and operators can manually script or put together RAM disks and disk images, automation makes customization and testing easier.

For more information on the support scope for features marked as technology previews, refer to https://access.redhat.com/support/offerings/techpreview/ .

5.6.3. Upload a Disk Image

To launch instances based on images stored in the Image service, you must first upload one or more images into the Image service.

To carry out this procedure, you must already have created or downloaded images suitable for use in the OpenStack environment. For more information, refer to:

Section 5.6.1, “ Obtain a Test Disk Image”

Section 5.6.2, “ Build a Custom Virtual Machine Image”

Important

It is recommended that the vi rt-sysprep command be run on all Linux-based virtual machine images prior to uploading them to the Image service. The vi rt-sysprep command re-initializes a disk image in preparation for use in a virtual environment. Default operations include the removal of SSH keys, removal of persistent MAC addresses, and removal of user accounts.

The vi rt-sysprep command is provided by the Red Hat Enterprise Linux libguestfs-tools package. As the ro o t user, execute:

# yum i nstal l -y l i bg uestfs-to o l s

# vi rt-sysprep --ad d FILE

For information on enabling and disabling specific operations, refer to the command's manual page by executing:

# man vi rt-sysprep

To upload an image to the Image service:

1. Set the environment variables used for authenticating with the Identity service by loading them from the keysto nerc file associated with your user (an administrative account is not required):

# so urce ~/keystonerc_userName

⁠Chapt er 5. O penSt ack Image Service Inst allat ion

2. Use the g l ance i mag e-create command to import your disk image:

# g l ance i mag e-create --name "NAME" \

--i s-publ i c IS_PUBLIC \

--d i sk-fo rmat DISK_FORMAT \

--co ntai ner-fo rmat CONTAINER_FORMAT \

--fi l e IMAGE

Where:

NAME = The name by which users will refer to the disk image.

IS_PUBLIC = Either true or fal se:

true - All users will be able to view and use the image.

fal se - Only administrators will be able to view and use the image.

DISK_FORMAT = The disk image's format. Valid values include: aki , ami , ari , i so ,

q co w2, raw, vd i , vhd , and vmd k.

If the format of the virtual machine disk image is unknown, use the q emu-i mg i nfo command to try and identify it.

Examp le 5.2. Usin g q emu-i mg i nfo

In the following example, the q emu-i mg i nfo is used to determine the format of a disk image stored in the file . /R HEL6 6 . i mg .

# q emu-i mg i nfo . /R HEL6 6 . i mg image: ./RHEL66.img

file format: q co w2 virtual size: 5.0G (5368709120 bytes) disk size: 136K cluster_size: 65536

CONTAINER_FORMAT = The container format of the image. The container format is bare unless the image is packaged in a file format such as o vf or ami that includes additional metadata related to the image.

IMAGE = The local path to the image file (for uploading).

For more information about the g l ance i mag e-create syntax, execute:

# g l ance hel p i mag e-create

Deploying O penSt ack: Learning Environment s (Manual Set up)

Note

If the image being uploaded is not locally accessible but is available using a remote

URL, provide the URL using the --l o cati o n parameter instead of using the --fi l e parameter.

However, unless you also specify the --co py-fro m argument, the Image service will not copy the image into the object store. Instead, the image will be accessed remotely each time it is required.

Examp le 5.3. Up lo ad in g an Imag e t o t h e Imag e service

In this example the q co w2 format image in the file named R HEL6 6 . i mg is uploaded to the

Image service. It is created in the service as a publicly accessible image named R HEL

6 . 6 .

# g l ance i mag e-create --name "R HEL 6 . 6 " --i s-publ i c true --

d i sk-fo rmat q co w2 \

--co ntai ner-fo rmat bare \

--fi l e R HEL6 6 . i mg

+------------------+--------------------------------------+

| Property | Value |

+------------------+--------------------------------------+

| checksum | 2f81976cae15c16ef0010c51e3a6c163 |

| container_format | bare |

| created_at | 2013-01-25T14:45:48 |

| deleted | False |

| deleted_at | None |

| disk_format | qcow2 |

| id | 0ce782c6-0d3e-41df-8fd5-39cd80b31cd9 |

| is_public | True |

| min_disk | 0 |

| min_ram | 0 |

| name | RHEL 6.6 |

| owner | b1414433c021436f97e9e1e4c214a710 |

| protected | False |

| size | 25165824 |

| status | active |

| updated_at | 2013-01-25T14:45:50 |

+------------------+--------------------------------------+

3. To verify that your image was successfully uploaded, use the g l ance i mag e-l i st command:

# g l ance i mag e-l i st

+--------------+----------+-------------+------------------+------

----+--------+

| Status |

+--------------+----------+-------------+------------------+------

----+--------+

⁠Chapt er 5. O penSt ack Image Service Inst allat ion

| 0ce782c6-... | RHEL 6.6 | qcow2 | bare

|213581824 | active |

+--------------+----------+-------------+------------------+------

----+--------+

To view detailed information about an uploaded image, execute the g l ance i mag e-sho w command using the image's identifier:

# g l ance i mag e-sho w 0ce782c6-0d3e-41df-8fd5-39cd80b31cd9

+------------------+--------------------------------------+

| Property | Value |

+------------------+--------------------------------------+

| checksum | 2f81976cae15c16ef0010c51e3a6c163 |

| container_format | bare |

| created_at | 2013-01-25T14:45:48 |

| deleted | False |

| disk_format | qcow2 |

| id | 0ce782c6-0d3e-41df-8fd5-39cd80b31cd9 |

| is_public | True |

| min_disk | 0 |

| min_ram | 0 |

| name | RHEL 6.6 |

| owner | b1414433c021436f97e9e1e4c214a710 |

| protected | False |

| size | 25165824 |

| status | active |

| updated_at | 2013-01-25T14:45:50 |

+------------------+--------------------------------------+

You have successfully uploaded a disk image to the Image service. This disk image can now be used as the basis for launching virtual machine instances in your OpenStack environment.

Deploying O penSt ack: Learning Environment s (Manual Set up)

Chapter 6. OpenStack Block Storage Installation

6.1. Block St orage Inst allat ion Overview

Block storage functionality is provided in OpenStack by three separate services collectively referred to as the Block Storage service or ci nd er. The three services are:

T h e API service ( o penstack-ci nd er-api )

The API service provides a HTTP endpoint for block storage requests. When an incoming request is received the API verifies identity requirements are met and translates the request into a message denoting the required block storage actions. The message is then sent to the message broker for processing by the other Block Storage services.

T h e sch ed u ler service ( o penstack-ci nd er-sched ul er)

The scheduler service reads requests from the message queue and determines on which block storage host the request must be actioned. The scheduler then communicates with the volume service on the selected host to process the request.

T h e vo lu me service ( o penstack-ci nd er-vo l ume)

The volume service manages the interaction with the block storage devices. As requests come in from the scheduler, the volume service creates, modifies, and removes volumes as required.

Although the three services can be co-located in a production environment, it is more common to deploy many instances of the volume service with one or more instances of the API and scheduler services managing them.

Fig u re 6 .1. Blo ck St o rag e Arch it ect u re

Deploying the Block Storage service is made up of three major phases:

⁠Chapt er 6 . O penSt ack Block St orage Inst allat ion

Prep arin g f o r Blo ck St o rag e In st allat io n

Steps that must be performed before installing any of the Block Storage services. These procedures include the creation of identity records, the database, and a database user.

Co mmo n Blo ck St o rag e Co n f ig u rat io n

Steps that are common to all of the Block Storage services and as such must be performed on all block storage nodes in the environment. These procedures include configuring the services to refer to the correct database and message broker. Additionally, they include the initialization and population of the database which must only be performed once but can be performed from any of the block storage systems.

Vo lu me Service Sp ecif ic Co n f ig u rat io n

Steps that are specific to systems that will be hosting the volume service and as such require direct access to block storage devices.

6.2. Block St orage Prerequisit e Configurat ion

6.2.1. Creat e t he Block St orage Dat abase

In this procedure the database and database user that will be used by the Block Storage services will be created. These steps must be performed while logged in to the database server as the ro o t user.

Pro ced u re 6 .1. Creat in g t h e d at ab ase t o b e u sed b y Blo ck St o rag e Services

1. Connect to the database service using the mysq l command.

# mysq l -u ro o t -p

2. Create the ci nd er database.

mysq l > CREATE DATABASE cinder;

3. Create a ci nd er database user and grant it access to the ci nd er database.

mysq l > GRANT ALL ON cinder.* TO 'cinder'@ '%' IDENTIFIED BY

'PASSWORD';

mysq l > GRANT ALL ON cinder.* TO 'cinder'@ 'localhost' IDENTIFIED

BY 'PASSWORD';

Replace PASSWORD with a secure password that will be used to authenticate with the database server as this user.

4. Flush the database privileges to ensure that they take effect immediately.

mysq l > FLUSH PRIVILEGES;

5. Exit the mysq l client.

mysq l > quit

Deploying O penSt ack: Learning Environment s (Manual Set up)

The block storage database has been created. The database will be populated during service configuration.

6.2.2. Creat e t he Block St orage Service Ident it y Records

The steps outlined in this procedure cover the creation of Identity records to support the Block

Storage service:

1. Create the ci nd er user, who has the ad mi n role in the servi ces tenant.

2. Create the ci nd er service entry and assign it an endpoint.

These entries provide authentication for the Block Storage services, and guide other OpenStack services attempting to locate and access the volume functionality provided by Block Storage.

In order to proceed, you should have already performed the following (through the Identity service):

1. Created an Administrator role named ad mi n (refer to Section 3.7, “ Create an Administrator

2. Created the servi ces tenant (refer to

service users. For more information, refer to Section 3.9, “ Create the Services Tenant” .

for instructions)

Note

The Deploying OpenStack: Learning Environments (Manual Set Up) guide uses one tenant for all

You can perform the following procedure from your Identity service host or on any machine where you've copied the keysto nerc_ad mi n file (which contains administrator credentials) and the

keyst o n e command-line utility is installed.

Pro ced u re 6 .2. Creat in g Id en t it y reco rd s f o r t h e Blo ck St o rag e service

1. Authenticate as the administrator of the Identity service by running the so urce command on the keysto nerc_ad mi n file containing the required credentials.

# so urce ~ /keysto nerc_ad mi n

2. Create a user named ci nd er for the Block Storage service to use.

# keysto ne user-create --name ci nd er --pass PASSWORD

+----------+----------------------------------+

| Property | Value |

+----------+----------------------------------+

| email | |

| enabled | True |

| id | e1765f70da1b4432b54ced060139b46a |

| name | cinder |

| tenantId | |

+----------+----------------------------------+

Replace PASSWORD with a secure password that will be used by the Block Storage service when authenticating with the Identity service.

⁠Chapt er 6 . O penSt ack Block St orage Inst allat ion

3. Use the keysto ne user-ro l e-ad d command to link the ci nd er user, ad mi n role, and

servi ces tenant together:

# keysto ne user-ro l e-ad d --user ci nd er --ro l e ad mi n --tenant

servi ces

4. Create the ci nd er service entry:

# keysto ne servi ce-create --name ci nd er \

--type vo l ume \

--d escri pti o n "C i nd er Vo l ume Servi ce"

+-------------+----------------------------------+

| Property | Value |

+-------------+----------------------------------+

| description | Cinder Volume Service |

| id | dfde7878671e484c9e581a3eb9b63e66 |

| name | cinder |

| type | volume |

+-------------+----------------------------------+

5. Create the ci nd er endpoint entry.

# keysto ne end po i nt-create \

--servi ce ci nd er \

--publ i curl "http: //IP: 8776 /v1/\%(tenant_i d )s" \

--ad mi nurl "http: //IP: 8776 /v1/\%(tenant_i d )s" \

--i nternal url "http: //IP: 8776 /v1/\%(tenant_i d )s"

Replace IP with the IP address or host name of the system that will be hosting the Block

Storage service API (o penstack-ci nd er-api ).

Important

If you intend to install and run multiple instances of the API service then you must repeat this step for the IP address or host name of each instance.

All supporting Identity service entries required by the Block Storage services have been created.

6.3. Common Block St orage Configurat ion

6.3.1. Inst all t he Block St orage Service Packages

The OpenStack Block Storage service requires the following packages:

openstack-cinder

Provides the Block Storage services and associated configuration files.

openstack-utils

Provides supporting utilities to assist with a number of tasks including the editing of configuration files.

Deploying O penSt ack: Learning Environment s (Manual Set up)

openstack-selinux

Provides OpenStack specific SELinux policy modules.

To install all of the above packages, execute the following command while logged in as the ro o t user:

# yum i nstal l -y o penstack-ci nd er o penstack-uti l s o penstack-sel i nux

The Block Storage services are now installed and ready to be configured.

6.3.2. Configure Block St orage Service Aut hent icat ion

The Block Storage service must be explicitly configured to use the Identity service for authentication.

Follow the steps listed in this procedure to configure this.

All steps listed in this procedure must be performed on each system hosting Block Storage services while logged in as the ro o t user.

Pro ced u re 6 .3. Co n f ig u rin g t h e Blo ck St o rag e Service t o au t h en t icat e t h ro u g h t h e

Id en t it y Service

1. Set the authentication strategy (auth_strateg y) configuration key to keysto ne using the

o penstack-co nfi g command.

# o penstack-co nfi g --set /etc/ci nd er/ci nd er. co nf \

D EFAULT auth_strateg y keysto ne

2. Set the authentication host (auth_ho st) configuration key to the IP address or host name of the Identity server.

# o penstack-co nfi g --set /etc/ci nd er/ci nd er. co nf \

keysto ne_authto ken auth_ho st IP

Replace IP with the IP address or host name of the Identity server.

3. Set the administration tenant name (ad mi n_tenant_name) configuration key to the name of the tenant that was created for the use of the Block Storage service. In this guide, examples use services.

# o penstack-co nfi g --set /etc/ci nd er/ci nd er. co nf \

keysto ne_authto ken ad mi n_tenant_name services

4. Set the administration user name (ad mi n_user) configuration key to the name of the user that was created for the use of the Block Storage service. In this guide, examples use cinder.

# o penstack-co nfi g --set /etc/ci nd er/ci nd er. co nf \

keysto ne_authto ken ad mi n_user cinder

5. Set the administration password (ad mi n_passwo rd ) configuration key to the password that is associated with the user specified in the previous step.

# o penstack-co nfi g --set /etc/ci nd er/ci nd er. co nf \

keysto ne_authto ken ad mi n_passwo rd PASSWORD

⁠Chapt er 6 . O penSt ack Block St orage Inst allat ion

The authentication keys used by the Block Storage services have been set and will be used when the services are started.

6.3.3. Configure t he Block St orage Service t o Use SSL

Use the following options in the ci nd er. co nf file to configure SSL.

T ab le 6 .1. SSL o p t io n s f o r Blo ck St o rag e

Co n f ig u rat io n

O p t io n

Descrip t io n backl o g

Number of backlog requests to configure the socket with.

tcp_keepi d l e

Sets the value of TCP_KEEPIDLE in seconds for each server socket.

ssl _ca_fi l e

CA certificate file to use to verify connecting clients.

ssl _cert_fi l e

Certificate file to use when starting the server securely.

ssl _key_fi l e

Private key file to use when starting the server securely.

6.3.4 . Configure Rabbit MQ Message Broker Set t ings for t he Block St orage

Service

This section assumes that you have already configured a RabbitMQ message broker. For more information, refer to:

Section 2.4.2, “ Install and Configure the RabbitMQ Message Broker”

Section 2.4.1, “ Configure the Firewall for Message Broker Traffic”

Section 2.4.2.1, “ Launch the RabbitMQ Message Broker”

Pro ced u re 6 .4 . Co n f ig u rin g t h e Blo ck St o rag e service t o u se t h e Rab b it MQ messag e b ro ker

1. Log in as ro o t to the system hosting the Block Storage services.

2. In /etc/ci nd er/ci nd er. co nf, set RabbitMQ as the RPC back end.

# o penstack-co nfi g --set /etc/ci nd er/ci nd er. co nf \

D EFAULT rpc_backend ci nd er. o penstack. co mmo n. rpc. i mpl _ko mbu

3. Set the Block Storage service to connect to the RabbitMQ host:

# o penstack-co nfi g --set /etc/ci nd er/ci nd er. co nf \

D EFAULT rabbi t_ho st RABBITMQ_HOST

Replace RABBITMQ_HOST with the IP address or host name of the message broker.

4. Set the message broker port to 56 72:

# o penstack-co nfi g --set /etc/ci nd er/ci nd er. co nf \

Deploying O penSt ack: Learning Environment s (Manual Set up)

D EFAULT rabbi t_po rt 56 72

5. Set the RabbitMQ username and password created for the Block Storage service:

# o penstack-co nfi g --set /etc/ci nd er/ci nd er. co nf \

D EFAULT rabbi t_useri d ci nd er

# o penstack-co nfi g --set /etc/ci nd er/ci nd er. co nf \

D EFAULT rabbi t_passwo rd CINDER_PASS

Where ci nd er and CINDER_PASS are the RabbitMQ username and password created for

Block Storage (in Section 2.4.2, “ Install and Configure the RabbitMQ Message Broker”

6. In Section 2.4.2.1, “ Launch the RabbitMQ Message Broker” , we gave the ci nd er user

read/write permissions to all resources -- specifically, through the virtual host /. Configure the

Block Storage service to connect to this virtual host:

# o penstack-co nfi g --set /etc/ci nd er/ci nd er. co nf \

D EFAULT rabbi t_vi rtual _ho st /

6 .3.4 .1 . Enable SSL Co m m unicat io n Be t we e n Blo ck St o rage Se rvice and Me ssage

Bro ke r

If you enabled SSL on the message broker, you will also have to configure the Block Storage service

accordingly. For this, you will need the exported client certificates and key file. See Section 2.4.2.3,

“ Export an SSL Certificate for Clients” for instructions on how to export these files.

Once you have the necessary certificates and key, run the following commands to enable SSL communication with the message broker:

# o penstack-co nfi g --set /etc/ci nd er/ci nd er. co nf \

D EFAULT rabbi t_use_ssl T rue

# o penstack-co nfi g --set /etc/ci nd er/ci nd er. co nf \

D EFAULT ko mbu_ssl _certfi l e /path/to/client.crt

# o penstack-co nfi g --set /etc/ci nd er/ci nd er. co nf \

D EFAULT ko mbu_ssl _keyfi l e /path/to/clientkeyfile.key

Where:

/path/to/client.crt is the absolute path to the exported client certificate.

/path/to/clientkeyfile.key is the absolute path to the exported client key file.

If your certificates were signed by a third-party Certificate Authority (CA), then you will also need to run the following command:

# o penstack-co nfi g --set /etc/ci nd er/ci nd er. co nf \

D EFAULT ko mbu_ssl _ca_certs /path/to/ca.crt

Replace /path/to/ca.crt with the absolute path to the CA file provided by the third-party CA (see

Section 2.4.2.2, “ Enable SSL on the RabbitMQ Message Broker”

for more information).

6.3.5. Configure t he Block St orage Service Dat abase Connect ion

⁠Chapt er 6 . O penSt ack Block St orage Inst allat ion

The database connection string used by the Block Storage services (the value of the

sq l _co nnecti o n configuration key) is defined in the /etc/ci nd er/ci nd er. co nf file. The string must be updated to point to a valid database server before starting the service.

The following command must be executed as the ro o t user on each system hosting Block Storage services:

# o penstack-co nfi g --set /etc/ci nd er/ci nd er. co nf \

D EFAULT sq l _co nnecti o n mysq l : //USER: PASS@ IP/DB

Replace:

USER with the database user name the Block Storage services are to use, usually ci nd er.

PASS with the password of the chosen database user.

IP with the IP address or host name of the database server.

DB with the name of the database that has been created for use by the Block Storage services, usually ci nd er.

Important

The IP address or host name specified in the connection configuration key must match the IP address or host name to which the cinder database user was granted access when creating the cinder database. Moreover, if the database is hosted locally and you granted permissions to 'localhost' when creating the cinder database, you must enter 'localhost'.

The database connection string has been set and will be used by the Block Storage services.

6.3.6. Configure t he Firewall t o Allow Block St orage Service T raffic

Systems attempting to use the functionality provided by the Block Storage services access it over the network using ports 326 0 and 8776 .

To allow this the firewall on the system hosting the Block Storage service must be altered to allow network traffic on these ports. All steps in this procedure must be run on each system hosting Block

Storage services while logged in as the ro o t user.

Pro ced u re 6 .5. Co n f ig u rin g t h e f irewall t o allo w Blo ck St o rag e Service t raf f ic

1. Open the /etc/sysco nfi g /i ptabl es file in a text editor.

2. Add an INPUT rule allowing TCP traffic on ports 326 0 and 8776 to the file. The new rule must appear before any INPUT rules that REJECT traffic.

-A INPUT -p tcp -m multiport --dports 3260,8776 -j ACCEPT

3. Save the changes to the /etc/sysco nfi g /i ptabl es file.

4. Restart the i ptabl es service to ensure that the change takes effect.

# servi ce i ptabl es restart

Deploying O penSt ack: Learning Environment s (Manual Set up)

The firewall is now configured to allow incoming connections to the Block Storage service on ports

326 0 and 8776 .

6.3.7. Populat e t he Block St orage Dat abase

You can populate the Block Storage database after you have successfully configured the Block

Storage service database connection string (refer to Section 6.3.5, “ Configure the Block Storage

Service Database Connection” ).

Important

This procedure only needs to be followed once to initialize and populate the database. You do not need to perform these steps again when adding additional systems hosting Block Storage services.

Pro ced u re 6 .6 . Po p u lat in g t h e Blo ck St o rag e Service d at ab ase

1. Log in to the system hosting one of the Block Storage services.

2. Use the su command to switch to the ci nd er user.

# su ci nd er -s /bi n/sh

3. Run the ci nd er-manag e d b sync command to initialize and populate the database identified in /etc/ci nd er/ci nd er. co nf.

$ ci nd er-manag e d b sync

The Block Storage service database has been initialized and populated.

6.3.8. Increase t he T hroughput of t he Block St orage API Service

By default, the Block Storage API service (o penstack-ci nd er-api ) runs in one process. This limits the number of API requests that the Block Storage service can process at any given time. In a production environment, you should increase the Block Storage API throughput by allowing

o penstack-ci nd er-api to run in as many processes as the machine capacity allows.

Red Hat Enterprise Linux OpenStack Platform 5 adds a new Block Storage API service option to address this, namely osapi_volume_workers. This option allows you to specify the number of API service workers (or OS processes) to launch for o penstack-ci nd er-api .

To set this option, run the following command on the o penstack-ci nd er-api host:

# o penstack-co nfi g --set /etc/ci nd er/ci nd er. co nf \

D EFAULT o sapi _vo l ume_wo rkers CORES

Replace CORES with the number of CPU cores/threads on a machine.

6.4 . Volume Service Configurat ion

6.4 .1. Block St orage Driver Support

⁠Chapt er 6 . O penSt ack Block St orage Inst allat ion

The volume service (o penstack-ci nd er-vo l ume) requires access to suitable block storage. As such, Red Hat Enterprise Linux OpenStack Platform provides volume drivers for several supported block storage types. These types include:

LVM/iSCSI

ThinLVM

NFS

NetAPP NFS

Red Hat Storage (Gluster)

Dell EqualLogic

For more detailed information on configuring volume drivers for the Block Storage service, refer to the

Volume Drivers section of the Red Hat Enterprise Linux OpenStack Platform Configuration Reference Guide.

For instructions on how to set up an NFS or GlusterFS back end, refer to the Manage volumes section of the Red Hat Enterprise Linux OpenStack Platform Cloud Administration Guide.

Both documents are available from the following link: https://access.redhat.com/site/documentation/en-US/Red_Hat_Enterprise_Linux_OpenStack_Platform

For instructions on how to set up an LVM back end, refer to Section 6.4.2, “ Configure OpenStack

Block Storage to use an LVM Storage Back End” .

6.4 .2. Configure OpenSt ack Block St orage t o use an LVM St orage Back End

The o penstack-ci nd er-vo l ume service is able to make use of a volume group attached directly to the server on which the service runs. This volume group must be created exclusively for use by the

Block Storage service and the configuration updated to point to the name of the volume group.

The following steps must be performed while logged into the system hosting the o penstack-

ci nd er-vo l ume service as the ro o t user:

Pro ced u re 6 .7. Co n f ig u rin g o p en st ack- cin d er- vo lu me t o u se LVM st o rag e as a b ack en d

1. Use the pvcreate command to create a physical volume.

# pvcreate DEVICE

Physical volume "DEVICE" successfully created

Replace DEVICE with the path to a valid, unused, device. For example:

# pvcreate /d ev/sd X

2. Use the vg create command to create a volume group.

# vg create cinder-volumes DEVICE

Volume group "cinder-volumes" successfully created

Replace DEVICE with the path to the device used when creating the physical volume.

Optionally replace cinder-volumes with an alternative name for the new volume group.

3. Set the vo l ume_g ro up configuration key to the name of the newly created volume group.

Deploying O penSt ack: Learning Environment s (Manual Set up)

# o penstack-co nfi g --set /etc/ci nd er/ci nd er. co nf \

D EFAULT vo l ume_g ro up cinder-volumes

The name provided must match the name of the volume group created in the previous step.

4. Ensure that the correct volume driver for accessing LVM storage is in use by setting the

vo l ume_d ri ver configuration key to

ci nd er. vo l ume. d ri vers. l vm. LVMISC SID ri ver.

# o penstack-co nfi g --set /etc/ci nd er/ci nd er. co nf \

D EFAULT vo l ume_d ri ver ci nd er. vo l ume. d ri vers. l vm. LVMISC SID ri ver

The o penstack-ci nd er-vo l ume service has been configured to use LVM storage.

6.4 .3. Configure SCSI T arget Daemon

The volume storage service uses a SCSI target daemon for mounting storage. A SCSI target daemon must be installed on each system hosting an instance of the volume service. Red Hat Enterprise Linux

6.7 and 7.2 use different SCSI target daemons.

Pro ced u re 6 .8. Co n f ig u re a SCSI t arg et d aemo n f o r Red Hat En t erp rise Lin u x 7.2

This procedure must be performed on each system hosting an instance of the volume service.

1. Log in as the ro o t user.

2. Install the targetcli package.

# yum i nstal l targ etcl i

3. Launch the targ et daemon and configure it to start at boot time.

# systemctl start targ et

# systemctl enabl e targ et

4. Configure the volume service to use the l i o ad m iSCSI target user-land tool.

# o penstack-co nfi g --set /etc/ci nd er/ci nd er. co nf \

D EFAULT i scsi _hel per l i o ad m

5. Set the correct IP address on which the iSCSI daemon should listen (ISCSIIP).

# o penstack-co nfi g --set /etc/ci nd er/ci nd er. co nf \

D EFAULT i scsi _i p_ad d ress ISCSIIP

6.5. Launch t he Block St orage Services

To bring up the Block Storage functionality at least one instance of each of the three services must be started:

The API service (o penstack-ci nd er-api ).

The scheduler service (o penstack-ci nd er-sched ul er).

⁠Chapt er 6 . O penSt ack Block St orage Inst allat ion

The volume service (o penstack-ci nd er-vo l ume).

The services do not need to be located on the same system, but must be configured to communicate using the same message broker and database instance. Once the services are running, the API will accept incoming volume requests, the scheduler will assign them as appropriate, and the volume service will action them.

Pro ced u re 6 .9 . Lau n ch in g Blo ck St o rag e Services

1. St art in g t h e API Service

a. Use the servi ce command to start the API service (o penstack-ci nd er-api ).

# servi ce o penstack-ci nd er-api start b. Use the chkco nfi g command to enable the API service permanently (o penstack-

ci nd er-api ).

# chkco nfi g o penstack-ci nd er-api o n

2. St art in g t h e Sch ed u ler Service

a. Use the servi ce command to start the scheduler (o penstack-ci nd er-

sched ul er).

# servi ce o penstack-ci nd er-sched ul er start b. Use the chkco nfi g command to enable the scheduler permanently (o penstack-

ci nd er-sched ul er).

# chkco nfi g o penstack-ci nd er-sched ul er o n

3. St art in g t h e Vo lu me Service

a. Use the servi ce command to start the volume service (o penstack-ci nd er-

vo l ume).

# servi ce o penstack-ci nd er-vo l ume start b. Use the servi ce command to start the The SCSI target daemon (tg td ).

# servi ce tg td start c. Use the chkco nfi g command to enable the volume service permanently

(o penstack-ci nd er-vo l ume).

Deploying O penSt ack: Learning Environment s (Manual Set up)

# chkco nfi g o penstack-ci nd er-vo l ume o n d. Use the chkco nfi g command to enable the SCSI target daemon permanently

(tg td ).

# chkco nfi g tg td o n

The volume service is running and ready to begin allocating volumes as they are requested.

6.6. Validat e t he Block St orage Service Inst allat ion

This procedure lists steps for validating that the block storage installation is complete and ready for use.

Pro ced u re 6 .10. Valid at in g t h e Blo ck St o rag e Service in st allat io n

1. T est in g Lo cally

The steps outlined in this section of the procedure must be performed while logged in to the server hosting the block storage API service as the ro o t user or a user with access to a

keysto nerc_ad mi n file containing the credentials of the OpenStack administrator. Transfer the keysto nerc_ad mi n file to the system before proceeding.

a. Run the so urce command on the keysto nerc_ad mi n file to populate the environment variables used for identifying and authenticating the user.

# so urce ~ /keysto nerc_ad mi n b. Run the ci nd er l i st command and verify that no errors are returned.

# ci nd er l i st c. Run the ci nd er create command to create a volume.

# ci nd er create SIZE

Replace SIZE with the size of the volume to create in Gigabytes (GB).

d. Run the ci nd er d el ete command to remove the volume.

# ci nd er d el ete ID

Replace ID with the identifier returned when the volume was created.

2. T est in g Remo t ely

The steps outlined in this section of the procedure must be performed while logged in to a system other than the server hosting the block storage API service. Transfer the

keysto nerc_ad mi n file to the system before proceeding.

a. Install the python-cinderclient package using the yum command. You will need to authenticate as the ro o t user for this step.

⁠Chapt er 6 . O penSt ack Block St orage Inst allat ion

# yum i nstal l -y pytho n-ci nd ercl i ent b. Run the so urce command on the keysto nerc_ad mi n file to populate the environment variables used for identifying and authenticating the user.

$ so urce ~ /keysto nerc_ad mi n c. Run the ci nd er l i st command and verify that no errors are returned.

$ ci nd er l i st d. Run the ci nd er create command to create a volume.

$ ci nd er create SIZE

Replace SIZE with the size of the volume to create in Gigabytes (GB).

e. Run the ci nd er d el ete command to remove the volume.

$ ci nd er d el ete ID

Replace ID with the identifier returned when the volume was created.

Deploying O penSt ack: Learning Environment s (Manual Set up)

Chapter 7. OpenStack Networking Service Installation

7.1. OpenSt ack Net working Inst allat ion Overview

7.1.1. OpenSt ack Net working Archit ect ure

OpenStack Networking provides cloud administrators with flexibility in deciding which individual services should run on which physical systems. All service daemons can be run on a single physical host for evaluation purposes. Alternatively each service can have its own physical host or even be replicated across multiple hosts for redundancy.

This chapter focuses on an architecture that combines the role of cloud controller with that of the network host while allowing for multiple compute nodes on which virtual machine instances run. The

OpenStack Networking services deployed on the cloud controller in this chapter may also be deployed on a separate network host entirely. This is recommended for environments where it is expected that significant amounts of network traffic will need to be routed from virtual machine instances to external networks.

Examp le n et wo rk d iag ram

The placement of OpenStack Networking services and agents can vary depending on requirements.

This diagram is an example of a common deployment model, utilizing a dedicated OpenStack

Networking node and tenant networks:

Two Compute nodes run the Open vSwitch (ovs-agent), and one OpenStack Networking node performs the network functions: L3 routing, DHCP, NAT, including services such as FWaaS and

LBaaS. The Compute nodes have two physical network cards each, one for tenant traffic, and another for management connectivity. The OpenStack Networking node has a third network card specifically for provider traffic:

Fig u re 7.1. Examp le n et wo rk d iag ram

⁠Chapt er 7 . O penSt ack Net working Service Inst allat ion

7.1.2. OpenSt ack Net working API

OpenStack Networking provides a powerful API to define the network connectivity and addressing used by devices from other services, such as OpenStack Compute.

The OpenStack Compute API has a virtual server abstraction to describe compute resources.

Similarly, the OpenStack Networking API has virtual network, subnet, and port abstraction layers to describe network resources. In more detail:

Net wo rk

An isolated L2 segment, analogous to VLAN in the physical networking world.

Su b n et

A block of v4 or v6 IP addresses and associated configuration state.

Po rt

A connection point for attaching a single device, such as the NIC of a virtual server, to a virtual network. Also describes the associated network configuration, such as the MAC and

IP addresses to be used on that port.

You can configure rich network topologies by creating and configuring networks and subnets, and then instructing other OpenStack services like OpenStack Compute to attach virtual devices to ports on these networks. In particular, OpenStack Networking supports each tenant having multiple private networks, and allows tenants to choose their own IP addressing scheme, even if those IP addresses overlap with those used by other tenants. This enables very advanced cloud networking use cases, such as building multi-tiered web applications and allowing applications to be migrated to the cloud without changing IP addresses.

Even if a cloud administrator does not intend to expose the above capabilities to tenants directly, the

OpenStack Networking API can be very useful for administrative purposes. The API provides significantly more flexibility for the cloud administrator when customizing network offerings.

7.1.3. OpenSt ack Net working API Ext ensions

The OpenStack Networking API allows plug-ins to provide extensions to enable additional networking functional not available in the core API itself.

Pro vid er Net wo rks

Provider networks allow the creation of virtual networks that map directly to networks in the physical data center. This allows the administrator to give tenants direct access to a public network such as the Internet or to integrate with existing VLANs in the physical networking environment that have a defined meaning or purpose.

When the provider extension is enabled OpenStack Networking users with administrative privileges are able to see additional provider attributes on all virtual networks. In addition such users have the ability to specify provider attributes when creating new provider networks.

Both the Open vSwitch and Linux Bridge plug-ins support the provider networks extension.

Layer 3 ( L3) Ro u t in g an d Net wo rk Ad d ress T ran slat io n ( NAT )

The L3 routing API extensions provides abstract L3 routers that API users are able to dynamically provision and configure. These routers are able to connect to one or more

Layer 2 (L2) OpenStack Networking controlled networks. Additionally the routers are able to

Deploying O penSt ack: Learning Environment s (Manual Set up)

provide a gateway that connects one or more private L2 networks to an common public or external network such as the Internet.

The L3 router provides basic NAT capabilities on gateway ports that connect the router to external networks. The router supports floating IP addresses which give a static mapping between a public IP address on the external network and the private IP address on one of the L2 networks attached to the router.

This allows the selective exposure of compute instances to systems on an external public network. Floating IP addresses are also able to be reallocated to different OpenStack

Networking ports as necessary.

Secu rit y G ro u p s

Security groups and rules filter the type and direction of network traffic sent to a given network port. This provides an additional layer of security to complement any firewall rules present on the Compute instance. The security group is a container object with one or more security rules. A single security group can manage traffic to multiple compute instances.

Ports created for floating IP addresses, OpenStack Networking LBaaS VIPs, router interfaces, and instances are associated with a security group. If none is specified, then the port is associated with the d efaul t security group. By default, this group will drop all inbound traffic and allow all outbound traffic. Additional security rules can be added to the

d efaul t security group to modify its behavior or new security groups can be created as necessary.

The Open vSwitch, Linux Bridge, VMware NSX, NEC, and Ryu networking plug-ins currently support security groups.

Note

Unlike Compute security groups, OpenStack Networking security groups are applied on a per port basis rather than on a per instance basis.

7.1.4 . OpenSt ack Net working Plug-ins

The original OpenStack Compute network implementation assumed a basic networking model where all network isolation was performed through the use of Linux VLANs and firewalls. OpenStack

Networking introduces the concept of a plug-in, which is a pluggable back-end implementation of the

OpenStack Networking API. A plug-in can use a variety of technologies to implement the logical API requests. Some OpenStack Networking plug-ins might use basic Linux VLANs and firewalls, while others might use more advanced technologies, such as L2-in-L3 tunneling or OpenFlow, to provide similar benefits.

Plug-ins for these network technologies are currently tested and supported for use with Red Hat

Enterprise Linux OpenStack Platform:

Open vSwitch (openstack-neutron-openvswitch)

Linux Bridge (openstack-neutron-linuxbridge)

Other plug-ins that are also packaged and available include:

Cisco (openstack-neutron-cisco)

NEC OpenFlow (openstack-neutron-nec)

⁠Chapt er 7 . O penSt ack Net working Service Inst allat ion

VMware (openstack-neutron-vmware)

Ryu (openstack-neutron-ryu)

Plug-ins enable the cloud administrator to weigh different options and decide which networking technology is right for the deployment.

7.1.5. VMware NSX Int egrat ion

OpenStack Networking uses the NSX plugin for Networking to integrate with an existing VMware vCenter deployment. When installed on the network nodes, the NSX plugin enables a NSX controller to centrally manage configuration settings and push them to managed network nodes. Network nodes are considered managed when they're added as hypervisors to the NSX controller.

The diagram below depicts an example NSX deployment and illustrates the route inter-VM traffic takes between separate Compute nodes. Note the placement of the VMware NSX plugin and the

neutro n-server service on the network node. The NSX controller features centrally with a green line to the network node to indicate the management relationship:

Fig u re 7.2. VMware NSX o verview

7.1.6. Open vSwit ch Overview

Open vSwitch is a software-defined networking (SDN) virtual switch designed to supersede the heritage

Linux software bridge. It provides switching services to virtualized networks with support for industry standard NetFlow, OpenFlow, and sFlow. Open vSwitch is also able to integrate with physical switches due to its support for the layer 2 features STP, LACP, and 802.1Q VLAN tagging.

Open vSwitch tunneling is supported with Open vSwitch version 1.11.0-1.el6 or later. Refer to the table below for specific kernel requirements:

Deploying O penSt ack: Learning Environment s (Manual Set up)

Feat u re

GRE Tunneling

VXLAN Tunneling

Kern el Req u iremen t

2.6.32-358.118.1.openstack.el6 or later

2.6.32-358.123.4.openstack.el6 or later

7.1.7. Modular Layer 2 (ML2) Overview

ML2 is the new OpenStack Networking core plug-in introduced in OpenStack's Havana release.

Superseding the previous model of singular plug-ins, ML2's modular design enables the concurrent operation of mixed network technologies. The monolithic Open vSwitch and linuxbridge plug-ins have been deprecated and will be removed in a future release; their functionality has instead been reimplemented as ML2 mechanisms.

Note

ML2 is the default OpenStack Networking plug-in, with Open vSwitch configured as the default mechanism driver.

T h e req u iremen t b eh in d ML2

Previously, OpenStack Networking deployments were only able to use the plug-in that had been selected at implementation time. For example, a deployment running the Open vSwitch plug-in was only able to use Open vSwitch exclusively; it wasn't possible to simultaneously run another plug-in such as linuxbridge. This was found to be a limitation in environments with heterogeneous requirements.

ML2 n et wo rk t yp es

Multiple network segment types can be operated concurrently. In addition, these network segments can interconnect using ML2's support for multi-segmented networks. Ports are automatically bound to the segment with connectivity; it is not necessary to bind them to a specific segment. Depending on the mechanism driver, ML2 supports the following network segment types: flat

GRE local

VLAN

VXLAN

The various Type drivers are enabled in the ML2 section of the ml 2_co nf. i ni file:

[ml2] type_drivers = local,flat,vlan,gre,vxlan

ML2 Mech an isms

Plug-ins have been reimplemented as mechanisms with a common code base. This approach enables code reuse and eliminates much of the complexity around code maintenance and testing.

Supported mechanism drivers currently include:

Arista

⁠Chapt er 7 . O penSt ack Net working Service Inst allat ion

Cisco

Nexus

Hyper-V Agent

L2 Population

Linuxbridge Agent

Open vSwitch Agent

Tail-f NCS

The various mechanism drivers are enabled in the ML2 section of the ml 2_co nf. i ni file:

[ml2] mechanism_drivers = openvswitch,linuxbridge,l2population

7.1.8. Choose a Net work Back-end

The Red Hat Enterprise Linux OpenStack Platform offers two distinctly different networking backends: Nova networking and OpenStack Networking (neutron). Nova networking has been deprecated in the OpenStack technology roadmap, but still remains currently available. OpenStack Networking is considered the core software-defined networking (SDN) component of OpenStack's forwardlooking roadmap and is under active development.

It is important to consider that there is currently no migration path between Nova networking and

OpenStack Networking. This would impact an operator's plan to deploy Nova networking with the intention of upgrading to OpenStack Networking at a later date. At present, any attempt to switch between these technologies would need to be performed manually, and would likely require planned outages.

Ch o o se O p en St ack Net wo rkin g ( n eu t ro n )

If yo u req u ire an o verlay n et wo rk so lu t io n : OpenStack Networking supports GRE or VXLAN tunneling for virtual machine traffic isolation. With GRE or VXLAN, no VLAN configuration is required on the network fabric and the only requirement from the physical network is to provide IP connectivity between the nodes. Furthermore, VXLAN or GRE allows a theoretical scale limit of 16 million unique IDs which is far beyond the 4094 limitation of 802.1q VLAN ID. Nova networking bases the network segregation on 802.1q VLANs and does not support tunneling with GRE or

VXLAN.

If yo u req u ire o verlap p in g IP ad d resses b et ween t en an t s: OpenStack Networking uses the network namespace capabilities in the Linux kernel, which allows different tenants to use the same subnet range (e.g. 192.168.1/24) on the same Compute node without any risk of overlap or interference. This is suited for large multi-tenancy deployments. By comparison, Nova networking offers flat topologies that must remain mindful of subnets used by all tenants.

If yo u req u ire a Red Hat - cert if ied t h ird - p art y O p en St ack Net wo rkin g p lu g - in : By default, Red Hat Enterprise OpenStack Platform 6 uses the open source ML2 core plug-in with the

Open vSwitch (OVS) mechanism driver. Based on the physical network fabric and other network requirements, third-party OpenStack Networking plug-ins can be deployed instead of the default

ML2/Open vSwitch driver due to the pluggable architecture of OpenStack Networking. Red Hat is

Deploying O penSt ack: Learning Environment s (Manual Set up)

constantly working to enhance our Partner Certification Program to certify more OpenStack

Networking plugins against Red Hat Enterprise OpenStack Platform. You can learn more about our Certification Program and the certified OpenStack Networking plug-ins at http://marketplace.redhat.com.

If yo u req u ire VPN- as- a- service ( VPNaaS) , Firewall- as- a- service ( FWaaS) , o r Lo ad -

Balan cin g - as- a- service ( LBaaS) : These network services are only available in OpenStack

Networking and are not available for Nova networking. The dashboard allows tenants to manage these services with no need for administrator intervention.

Ch o o se No va n et wo rkin g

If yo u r d ep lo ymen t req u ires f lat ( u n t ag g ed ) o r VLAN ( 802.1q t ag g ed ) n et wo rkin g :This implies scalabilty requirements (theoretical scale limit of 4094 VLAN IDs, where in practice physical switches tend to support a much lower number) as well as management and provisioning requirements. Specific configuration is necessary on the physical network to trunk the required set of VLANs between the nodes.

If yo u r d ep lo ymen t d o es n o t req u ire o verlap p in g IP ad d resses b et ween t en an t s: This is usually suitable only for small, private deployments.

If yo u d o n o t n eed a so f t ware- d ef in ed n et wo rkin g ( SDN) so lu t io n , o r t h e ab ilit y t o in t eract wit h t h e p h ysical n et wo rk f ab ric.

If yo u d o n o t n eed self - service VPN, Firewall, o r Lo ad - Balan cin g services.

7.1.9. Configure t he L2 Populat ion mechanism driver

The L2 Population driver enables broadcast, multicast, and unicast traffic to scale out on large overlay networks. By default, Open vSwitch GRE and VXLAN replicate broadcasts to every agent, including those that do not host the destination network. This design requires the acceptance of significant network and processing overhead. The alternative design introduced by the L2

Population driver implements a partial mesh for ARP resolution and MAC learning traffic. This traffic is sent only to the necessary agent by encapsulating it as a targeted unicast.

Enable the L2 population driver by adding it to the list of mechanism drivers. You also need to have at least one tunneling driver enabled; either GRE, VXLAN, or both. Add the appropriate configuration options to the ml 2_co nf. i ni file:

[ml2] type_drivers = local,flat,vlan,gre,vxlan mechanism_drivers = openvswitch,linuxbridge,l2population

Enable L2 population in the o vs_neutro n_pl ug i n. i ni file. This must be enabled on each node running the L2 agent:

[agent] l2_population = True

7.1.10. OpenSt ack Net working Agent s

As well as the OpenStack Networking service and the installed plug-in a number of components combine to provide networking functionality in the OpenStack environment.

L3 Ag en t

100

⁠Chapt er 7 . O penSt ack Net working Service Inst allat ion

The L3 agent is part of the openstack-neutron package. It acts as an abstract L3 router that can connect to and provide gateway services for multiple L2 networks.

The nodes on which the L3 agent is to be hosted must not have a manually configured IP address on a network interface that is connected to an external network. Instead there must be a range of IP addresses from the external network that are available for use by

OpenStack Networking. These IP addresses will be assigned to the routers that provide the link between the internal and external networks.

The range selected must be large enough to provide a unique IP address for each router in the deployment as well as each desired floating IP.

DHCP Ag en t

The OpenStack Networking DHCP agent is capable of allocating IP addresses to virtual machines running on the network. If the agent is enabled and running when a subnet is created then by default that subnet has DHCP enabled.

Plu g - in Ag en t

Many of the OpenStack Networking plug-ins, including Open vSwitch and Linux Bridge, utilize their own agent. The plug-in specific agent runs on each node that manages data packets. This includes all compute nodes as well as nodes running the dedicated agents

neutro n-d hcp-ag ent and neutro n-l 3-ag ent.

7.1.11. T enant and Provider net works

The following diagram presents an overview of the tenant and provider network types, and illustrates how they interact within the overall OpenStack Networking topology:

T en an t n et wo rks

Tenant networks are created by users for connectivity within projects; they are fully isolated by default and are not shared with other projects. OpenStack Networking supports a range of tenant network types:

101

Deploying O penSt ack: Learning Environment s (Manual Set up)

Flat

All instances reside on the same network, which can also be shared with the hosts. No

VLAN tagging or other network segregation takes place.

Lo cal

Instances reside on the local Compute host and are effectively isolated from any external networks.

VLAN

OpenStack Networking allows users to create multiple provider or tenant networks using

VLAN IDs (802.1Q tagged) that correspond to VLANs present in the physical network. This allows instances to communicate with each other across the environment. They can also communicate with dedicated servers, firewalls, load balancers and other network infrastructure on the same layer 2 VLAN.

VXLAN/G RE

VXLAN and GRE use network overlays to support private communication between instances. An OpenStack Networking router is required to enable traffic to traverse outside of the GRE or VXLAN tenant network. A router is also required to connect directly-connected tenant networks with external networks, including the Internet; the router provides the ability to connect to instances directly from an external network using floating IP addresses.

Pro vid er n et wo rks

Provider networks are created by the OpenStack administrator and map directly to an existing physical network in the data center. Useful network types in this category are flat (untagged) and

VLAN (802.1Q tagged). It is possible to allow provider networks to be shared among tenants as part of the network creation process.

7.1.12. Mult iple Net works on a Single Node

Multiple external networks can now be operated on a single OpenStack Networking node running either the ML2 Open vSwitch mechanism driver, or the deprecated Open vSwitch plug-in.

Pro ced u re 7.1. Creat e mu lt ip le Pro vid er n et wo rks

1. Create an Open vSwitch bridge, which will provide connectivity to the new external network using eth1:

# o vs-vsctl ad d -br br-eth1

# o vs-vsctl ad d -po rt br-eth1 eth1

# i p l i nk set eth1 up

2. The bridge and router interfaces are automatically mapped by the L3 agent, by relaying any physnet-to-bridge mappings created in

/etc/neutro n/pl ug i ns/o penvswi tch/o vs_neutro n_pl ug i n. i ni . For example, in tunneling mode, the L3 agent will patch br-i nt to the external bridges, and set the external q router interfaces on br-i nt. Enable this behavior in /etc/neutro n/l 3_ag ent. i ni , by setting the options below as empty values:

102

⁠Chapt er 7 . O penSt ack Net working Service Inst allat ion

gateway_external_network_id = external_network_bridge =

On the OpenStack Networking nodes, edit o vs_neutro n_pl ug i n. i ni to map the physical networks to the corresponding external bridges.

bridge_mappings = physnet1:br-ex,physnet2:br-eth1

Restart the L3 agent and Open vSwitch agent services for the changes to take effect:

# servi ce neutro n-l 3-ag ent restart

# servi ce neutro n-o penvswi tch-ag ent restart

The following steps demonstrate the creation of two external networks on the same

OpenStack Networking node. Ensure the l 3_ag ent. i ni configuration is present before proceeding.

3. Create the new Provider network physnet1, and the related topology:

# neutro n net-create ext_net --pro vi d er: netwo rk_type fl at --

pro vi d er: physi cal _netwo rk physnet1 --ro uter: external = T rue

# neutro n subnet-create ext_net --g ateway 172. 16 . 0 . 1

172. 16 . 0 . 0 /24 -- --enabl e_d hcp= Fal se

# neutro n ro uter-create ro uter1

# neutro n ro uter-g ateway-set ro uter1 ext_net

# neutro n net-create pri vnet

# neutro n subnet-create pri vnet --g ateway 19 2. 16 8. 123. 1

19 2. 16 8. 123. 0 /24 --name pri vnet_subnet

# neutro n ro uter-i nterface-ad d ro uter1 pri vnet_subnet

4. Create the new Provider network physnet2, and the related topology:

# neutro n net-create ext_net2 --pro vi d er: netwo rk_type fl at --

pro vi d er: physi cal _netwo rk physnet2 --ro uter: external = T rue

# neutro n subnet-create ext_net2 --al l o cati o n-po o l

start= 19 2. 16 8. 1. 20 0 ,end = 19 2. 16 8. 1. 222 --g ateway= 19 2. 16 8. 1. 1 -enabl e_d hcp= Fal se 19 2. 16 8. 1. 0 /24

# neutro n ro uter-create ro uter2

103

Deploying O penSt ack: Learning Environment s (Manual Set up)

# neutro n ro uter-g ateway-set ro uter2 ext_net2

# neutro n net-create pri vnet2

# neutro n subnet-create pri vnet2 --g ateway 19 2. 16 8. 125. 1

19 2. 16 8. 125. 0 /24 --name pri vnet2_subnet

# neutro n ro uter-i nterface-ad d ro uter2 pri vnet2_subnet

7.1.13. Recommended OpenSt ack Net working Deployment

OpenStack Networking provides an extreme amount of flexibility when deploying networking in support of a compute environment. As a result, the exact layout of a deployment will depend on a combination of expected workloads, expected scale, and available hardware.

Fig u re 7.3. Dep lo ymen t Arch it ect u re

For demonstration purposes, this chapter concentrates on a OpenStack Networking deployment that consists of these types of nodes:

Service No d e

The service node exposes the OpenStack Networking API to clients and handles incoming requests before forwarding them to a message queue to be actioned by the other nodes.

The service node hosts both the OpenStack Networking service itself and the active

OpenStack Networking plug-in.

In environments that use controller nodes to host the client-facing APIs and schedulers for all services, the controller node would also fulfil the role of service node as it is applied in this chapter.

104

⁠Chapt er 7 . O penSt ack Net working Service Inst allat ion

Net wo rk No d e

The network node handles the majority of the OpenStack Networking workload. It hosts the

DHCP agent, the Layer 3 (L3) agent, the Layer 2 (L2) Agent, and the metadata proxy. In addition to plug-ins that require an agent, it runs an instance of the plug-in agent (as do all other systems that handle data packets in an environment where such plug-ins are in use).

Both the Open vSwitch and Linux Bridge plug-ins include an agent.

Co mp u t e No d e

The Compute hosts run the Compute instances themselves. To connect Compute instances to the OpenStack Networking services, Compute nodes must also run the L2 agent. Like all other systems that handle data packets it must also run an instance of the plug-in agent.

This deployment type and division of responsibilities is made only as a suggestion. Other divisions are equally valid, in particular in some environments the network and service nodes may be combined.

Warning

Environments that have been configured to use nova-network, either using the packstack utility or manually, can be reconfigured to use OpenStack Networking. This is however currently n o t recommended for environments where Compute instances have already been created and configured to use nova-network. If you wish to proceed with such a conversion, stop the o penstack-no va-netwo rk service on each Compute node first; to do so, run:

# servi ce o penstack-no va-netwo rk sto p

You must also disable the o penstack-no va-netwo rk service permanently on each node using the chkco nfi g command:

# chkco nfi g o penstack-no va-netwo rk o ff

Important

When running 2 or more active controller nodes, do not run no va-co nso l eauth on more than one node. Running more than one instance of no va-co nso l eauth causes a conflict between nodes with regard to token requests which may cause errors.

7.1.14 . Kernel Requirement s

Nodes that handle OpenStack Networking traffic require a Red Hat Enterprise Linux kernel that supports the use of network namespaces. In addition, the Open vSwitch plug-in requires kernel version 2. 6 . 32-4 31. el 6 . x86 _6 4 or later.

The default kernel included in supported Red Hat Enterprise Linux versions fulfills both requirements.

Previous Red Hat Enterprise Linux OpenStack Platform releases required manually installing and booting to a custom Red Hat Enterprise Linux kernel that supported network namespaces and other

OpenStack features. As of this release, doing so is no longer required. All OpenStack Networking requirements are now built into the default kernel of supported Red Hat Enterprise Linux versions.

105

Deploying O penSt ack: Learning Environment s (Manual Set up)

7.2. Net working Prerequisit e Configurat ion

7.2.1. Configure OpenSt ack Net working Aut hent icat ion

This section outlines the steps for creating and configuring Identity service records required by the

OpenStack Networking service.

1. Create the neutro n user, who has the ad mi n role in the servi ces tenant.

2. Create the neutro n service entry and assign it an endpoint.

These entries will assist other OpenStack services attempting to locate and access the network functionality provided by the OpenStack Networking service. In order to proceed, you should have already performed the following (through the Identity service):

1. Created an Administrator role named ad mi n (refer to Section 3.7, “ Create an Administrator

2. Created the servi ces tenant (refer to

service users. For more information, refer to Section 3.9, “ Create the Services Tenant” .

for instructions)

Note

The Deploying OpenStack: Learning Environments (Manual Set Up) guide uses one tenant for all

You can perform the following procedure from your Identity service host or on any machine where you've copied the keysto nerc_ad mi n file (which contains administrator credentials) and the

keyst o n e command-line utility is installed.

Pro ced u re 7.2. Co n f ig u rin g O p en St ack Net wo rkin g t o au t h en t icat e t h ro u g h t h e

Id en t it y Service

1. Authenticate as the administrator of the Identity service by running the so urce command on the keysto nerc_ad mi n file containing the required credentials:

# so urce ~ /keysto nerc_ad mi n

2. Create a user named neutro n for the OpenStack Networking service to use:

# keysto ne user-create --name neutro n --pass PASSWORD

+----------+----------------------------------+

| Property | Value |

+----------+----------------------------------+

| email | |

| enabled | True |

| id | 1df18bcd14404fa9ad954f9d5eb163bc |

| name | neutron |

| tenantId | |

+----------+----------------------------------+

Replace PASSWORD with a secure password that will be used by the OpenStack Networking service when authenticating with the Identity service.

106

⁠Chapt er 7 . O penSt ack Net working Service Inst allat ion

3. Use the keysto ne user-ro l e-ad d command to link the neutro n user, ad mi n role, and

servi ces tenant together:

# keysto ne user-ro l e-ad d --user neutro n --ro l e ad mi n --tenant

servi ces

4. Create the neutro n service entry:

# keysto ne servi ce-create --name neutro n \

--type netwo rk \

--d escri pti o n "O penStack Netwo rki ng Servi ce"

+-------------+----------------------------------+

| Property | Value |

+-------------+----------------------------------+

| description | OpenStack Networking Service |

| id | 134e815915f442f89c39d2769e278f9b |

| name | neutron |

| type | network |

+-------------+----------------------------------+

5. Create the netwo rk endpoint entry:

# keysto ne end po i nt-create --servi ce-i d SER VIC E_ID \

--servi ce neutro n \

--publ i curl "http: //IP: 9 6 9 6 " \

--ad mi nurl "http: //IP: 9 6 9 6 " \

--i nternal url "http: //IP: 9 6 9 6 "

Replace SERVICE_ID with the service identifier from the previous step, and replace IP with the

IP address or host name of the system that will be acting as the network node.

All supporting Identity service entries required by the OpenStack Networking service have been created.

7.3. Common Net working Configurat ion

7.3.1. Disable Net work Manager

OpenStack Networking currently does not work on systems that have the Network Manager service enabled.

Follow the steps listed in this procedure while logged in as the ro o t user on each system in the environment that will handle network traffic. This includes the system that will host the OpenStack

Networking service, all network nodes, and all compute nodes.

These steps determine the state of the Netwo rkManag er service, disable it from running, and replace it with the standard network service:

Pro ced u re 7.3. Disab lin g t h e Net wo rk Man ag er service

1. Verify Network Manager is currently enabled:

# systemctl status Netwo rkManag er. servi ce | g rep Acti ve:

107

Deploying O penSt ack: Learning Environment s (Manual Set up)

A. The system displays an error if the Network Manager service is not currently installed: error reading information on service NetworkManager: No such file or directory

If this error is displayed then no further action is required to disable the Network Manager service.

B. The system displays Acti ve: acti ve (runni ng ) if Network Manager is running, or

Acti ve: i nacti ve (d ead ) if it is not.

For example, if Network Manager is active:

Active: active (running) since Thu 2014-06-26 19:34:00 EDT; 2s ago

If Network Manager is inactive, then no further action is required.

2. If Network Manager is running, then you must first stop it and then disable it:

# systemctl sto p Netwo rkManag er. servi ce

# systemctl d i sabl e Netwo rkManag er. servi ce

3. Open each interface configuration file on the system in a text editor. Interface configuration files are found in the /etc/sysco nfi g /netwo rk-scri pts/ directory and have names of the form i fcfg -X where X is replaced by the name of the interface. Valid interface names include eth0 , p1p5, and em1.

In each file ensure that the NM_C O NT R O LLED configuration key is set to no and the O NBO O T configuration key is set to yes. Add these keys manually if they do not already exist in each file.

NM_CONTROLLED=no

ONBOOT=yes

This action ensures that the standard network service will take control of the interfaces and automatically activate them on boot.

4. Ensure that the standard network service is started using the systemctl command:

# systemctl start netwo rk. servi ce

5. Ensure the network service is enabled:

# systemctl enabl e netwo rk. servi ce

The Network Manager service is disabled. The standard network service is enabled and configured to control the required network interfaces.

7.3.2. Disable firewalld

Disable the firewalld service for Compute and OpenStack Networking nodes running Red Hat

Enterprise Linux 7.2, and replace with iptables.

108

⁠Chapt er 7 . O penSt ack Net working Service Inst allat ion

Pro ced u re 7.4 . Disab le t h e f irewalld service

1. Install the iptables service:

# yum i nstal l i ptabl es-servi ces

2. Review the iptables rules defined in /etc/sysco nfi g /i ptabl es

Note

You can review your current firewalld configuration by running the fi rewal l -cmd command.

# fi rewal l -cmd --l i st-al l

3. Once satisfied with the iptables rules, disable firewalld:

# systemctl d i sabl e fi rewal l d . servi ce

4. Stop the firewalld service and start iptables:

# systemctl sto p fi rewal l d . servi ce; systemctl start i ptabl es;

systemctl start i p6 tabl es

5. Permanently enable the iptables services:

# systemctl enabl e i ptabl es

# systemctl enabl e i p6 tabl es

The firewalld service has been disabled, and the iptables service has been enabled and configured to start on boot.

7.3.3. Inst all t he OpenSt ack Net working Service Packages

The OpenStack Networking service requires the following packages:

openstack-neutron

Provides the OpenStack Networking service and associated configuration files.

openstack-neutron-PLUGIN

Provides an OpenStack Networking plug-in. Replace PLUGIN with one of the recommended plug-ins (o penvswi tch and l i nuxbri d g e).

openstack-utils

Provides supporting utilities to assist with a number of tasks including the editing of configuration files.

openstack-selinux

109

Deploying O penSt ack: Learning Environment s (Manual Set up)

Provides OpenStack specific SELinux policy modules.

The packages must be installed on all systems that will handle network traffic. This includes the

OpenStack Networking service node, all network nodes, and all Compute nodes.

To install all of the above packages, execute the following command while logged in as the ro o t user:

# yum i nstal l -y o penstack-neutro n \

o penstack-neutro n-PLUGIN \

o penstack-uti l s \

o penstack-sel i nux

Replace PLUGIN with o penvswi tch or l i nuxbri d g e (determines which plug-in is installed).

The OpenStack Networking services are installed and ready to be configured.

7.3.4 . Configure t he Firewall t o Allow OpenSt ack Net working T raffic

Remote systems requiring integration with the OpenStack Networking service will need to be granted access to T C P port 9 6 9 6 .

All steps in this procedure must be run while logged in to the server hosting the OpenStack

Networking service as the ro o t user.

Pro ced u re 7.5. Co n f ig u rin g t h e f irewall t o allo w O p en St ack Net wo rkin g t raf f ic

1. Open the /etc/sysco nfi g /i ptabl es file in a text editor.

2. Add an INPUT rule allowing TCP traffic on port 9 6 9 6 to the file. The new rule must appear before any INPUT rules that REJECT traffic.

-A INPUT -p tcp -m multiport --dports 9696 -j ACCEPT

3. Save the changes to the /etc/sysco nfi g /i ptabl es file.

4. Restart the i ptabl es service to ensure that the change takes effect.

# servi ce i ptabl es restart

The firewall is now configured to allow incoming connections to the OpenStack Networking service on port 9 6 9 6 .

7.4 . Configure t he Net working Service

7.4 .1. Configure OpenSt ack Net working Service Aut hent icat ion

The OpenStack Networking service must be explicitly configured to use the Identity service for authentication. To accomplish this, perform the following procedure on the network node while logged in as ro o t on the DHCP agent's host:

Pro ced u re 7.6 . Co n f ig u rin g t h e O p en St ack Net wo rkin g Service t o au t h en t icat e t h ro u g h t h e Id en t it y Service

110

⁠Chapt er 7 . O penSt ack Net working Service Inst allat ion

1. Set the authentication strategy (auth_strateg y) configuration key to keysto ne using the

o penstack-co nfi g command.

# o penstack-co nfi g --set /etc/neutro n/neutro n. co nf \

D EFAULT auth_strateg y keysto ne

2. Set the authentication host (auth_ho st configuration key) to the IP address or host name of the Identity server.

# o penstack-co nfi g --set /etc/neutro n/neutro n. co nf \

keysto ne_authto ken auth_ho st IP

Replace IP with the IP address or host name of the Identity server.

3. Set the administration tenant name (ad mi n_tenant_name) configuration key to the name of the tenant that was created for the use of the OpenStack Networking service. Examples in this guide use services.

# o penstack-co nfi g --set /etc/neutro n/neutro n. co nf \

keysto ne_authto ken ad mi n_tenant_name services

4. Set the administration user name (ad mi n_user) configuration key to the name of the user that was created for the use of the OpenStack Networking services. Examples in this guide use neutron.

# o penstack-co nfi g --set /etc/neutro n/neutro n. co nf \

keysto ne_authto ken ad mi n_user neutron

5. Set the administration password (ad mi n_passwo rd ) configuration key to the password that is associated with the user specified in the previous step.

# o penstack-co nfi g --set /etc/neutro n/neutro n. co nf \

keysto ne_authto ken ad mi n_passwo rd PASSWORD

The authentication keys used by the OpenStack Networking service have been set and will be used when the services are started.

7.4 .2. Configure Rabbit MQ Message Broker Set t ings for t he Net working

Service

As of Red Hat Enterprise Linux OpenStack Platform 5, RabbitMQ replaces Qpid as the default (and recommended) message broker. The RabbitMQ messaging service is provided by the rabbitmq-server package.

This section assumes that you have already configured a RabbitMQ message broker. For more information, refer to:

Section 2.4.2, “ Install and Configure the RabbitMQ Message Broker”

Section 2.4.1, “ Configure the Firewall for Message Broker Traffic”

Section 2.4.2.1, “ Launch the RabbitMQ Message Broker”

111

Deploying O penSt ack: Learning Environment s (Manual Set up)

Pro ced u re 7.7. Co n f ig u rin g t h e O p en St ack Net wo rkin g service t o u se t h e Rab b it MQ messag e b ro ker

Perform these steps on all Red Hat Enterprise Linux OpenStack Platform nodes.

1. In /etc/neutro n/neutro n. co nf, set RabbitMQ as the RPC back end.

# o penstack-co nfi g --set /etc/neutro n/neutro n. co nf \

D EFAULT rpc_backend neutro n. o penstack. co mmo n. rpc. i mpl _ko mbu

2. Set the neutro n-server service to connect to the RabbitMQ host:

# o penstack-co nfi g --set /etc/neutro n/neutro n. co nf \

D EFAULT rabbi t_ho st RABBITMQ_HOST

Replace RABBITMQ_HOST with the IP address or host name of the message broker.

3. Set the message broker port to 56 72:

# o penstack-co nfi g --set /etc/neutro n/neutro n. co nf \

D EFAULT rabbi t_po rt 56 72

4. Set the RabbitMQ username and password created for the OpenStack Networking service:

# o penstack-co nfi g --set /etc/neutro n/neutro n. co nf \

D EFAULT rabbi t_useri d neutro n

# o penstack-co nfi g --set /etc/neutro n/neutro n. co nf \

D EFAULT rabbi t_passwo rd NEUTRON_PASS

Where neutro n and NEUTRON_PASS are the RabbitMQ username and password created for

OpenStack Networking (in Section 2.4.2, “ Install and Configure the RabbitMQ Message

Broker” ).

5. In Section 2.4.2.1, “ Launch the RabbitMQ Message Broker” , we gave the neutro n user

read/write permissions to all resources -- specifically, through the virtual host /. Configure the

Networking service to connect to this virtual host:

# o penstack-co nfi g --set /etc/neutro n/neutro n. co nf \

D EFAULT rabbi t_vi rtual _ho st /

7 .4 .2 .1 . Enable SSL Co m m unicat io n Be t we e n t he Ope nSt ack Ne t wo rking Se rvice and Me ssage Bro ke r

If you enabled SSL on the message broker, you will also have to configure the OpenStack

Networking service accordingly. For this, you will need the exported client certificates and key file.

See

Section 2.4.2.3, “ Export an SSL Certificate for Clients”

for instructions on how to export these files.

Once you have the necessary certificates and key, run the following commands to enable SSL communication with the message broker:

# o penstack-co nfi g --set /etc/neutro n/neutro n. co nf \

D EFAULT rabbi t_use_ssl T rue

112

⁠Chapt er 7 . O penSt ack Net working Service Inst allat ion

# o penstack-co nfi g --set /etc/neutro n/neutro n. co nf \

D EFAULT ko mbu_ssl _certfi l e /path/to/client.crt

# o penstack-co nfi g --set /etc/neutro n/neutro n. co nf \

D EFAULT ko mbu_ssl _keyfi l e /path/to/clientkeyfile.key

Where:

/path/to/client.crt is the absolute path to the exported client certificate.

/path/to/clientkeyfile.key is the absolute path to the exported client key file.

If your certificates were signed by a third-party Certificate Authority (CA), then you will also need to run the following command:

# o penstack-co nfi g --set /etc/neutro n/neutro n. co nf \

D EFAULT ko mbu_ssl _ca_certs /path/to/ca.crt

Replace /path/to/ca.crt with the absolute path to the CA file provided by the third-party CA (see

Section 2.4.2.2, “ Enable SSL on the RabbitMQ Message Broker”

for more information).

7.4 .3. Set t he OpenSt ack Net working Service Plug-in

Additional configuration settings must be applied to enable the desired plug-in. Below are the procedures for enabling the ML2, Open vSwitch (OVS), and Linux Bridge plug-ins.

Note

The monolithic Open vSwitch and linuxbridge plug-ins have been deprecated and will be removed in a future release; their functionality has instead been re-implemented as ML2 mechanisms.

OpenStack Networking plug-ins can be referenced in neutro n. co nf by their nominated short names, instead of their lengthy class names. For example: core_plugin = neutron.plugins.ml2.plugin:Ml2Plugin will become: core_plugin = ml2

Note

Take care not to introduce errant whitespace characters, as these could result in parse errors.

T ab le 7.1. co re_p lu g in

Sh o rt n ame

bigswitch brocade

Class n ame

neutron.plugins.bigswitch.plugin:NeutronRestProxyV2 neutron.plugins.brocade.NeutronPlugin:BrocadePluginV2

113

Deploying O penSt ack: Learning Environment s (Manual Set up)

Sh o rt n ame

cisco embrane hyperv linuxbridge midonet ml2 mlnx nec openvswitch plumgrid ryu vmware

Class n ame

neutron.plugins.cisco.network_plugin:PluginV2 neutron.plugins.embrane.plugins.embrane_ovs_plugin:EmbraneOvsPlugin neutron.plugins.hyperv.hyperv_neutron_plugin:HyperVNeutronPlugin neutron.plugins.linuxbridge.lb_neutron_plugin:LinuxBridgePluginV2 neutron.plugins.midonet.plugin:MidonetPluginV2 neutron.plugins.ml2.plugin:Ml2Plugin neutron.plugins.mlnx.mlnx_plugin:MellanoxEswitchPlugin neutron.plugins.nec.nec_plugin:NECPluginV2 neutron.plugins.openvswitch.ovs_neutron_plugin:OVSNeutronPluginV2 neutron.plugins.plumgrid.plumgrid_plugin.plumgrid_plugin:NeutronPluginPLU

MgridV2 neutron.plugins.ryu.ryu_neutron_plugin:RyuNeutronPluginV2 neutron.plugins.vmware.plugin:NsxPlugin

The servi ce_pl ug i ns option accepts a comma-delimited list of multiple service plugins.

T ab le 7.2. service_p lu g in s

Sh o rt n ame

dummy router firewall lbaas metering

Class n ame

neutron.tests.unit.dummy_plugin:DummyServicePlugin neutron.services.l3_router.l3_router_plugin:L3RouterPlugin neutron.services.firewall.fwaas_plugin:FirewallPlugin neutron.services.loadbalancer.plugin:LoadBalancerPlugin neutron.services.metering.metering_plugin:MeteringPlugin

Pro ced u re 7.8. En ab lin g t h e ML2 p lu g - in

Follow these steps on the node running the neutro n-server service.

1. Install the openstack-neutron-ml2 package:

# yum i nstal l o penstack-neutro n-ml 2

2. Create a symbolic link to direct OpenStack Networking to the ML2 config file ml 2_co nf. i ni :

# l n -s /etc/neutro n/pl ug i ns/ml 2/ml 2_co nf. i ni

/etc/neutro n/pl ug i n. i ni

3. Add the appropriate configuration options to the ml 2_co nf. i ni file. Available options are

listed below. Refer to Section 7.1.7, “ Modular Layer 2 (ML2) Overview” for further information

on these settings.

[ml2] type_drivers = local,flat,vlan,gre,vxlan mechanism_drivers = openvswitch,linuxbridge,l2population

[agent] l2_population = True

4. Enable the ML2 plug-in and L3 router in the neutro n. co nf file:

114

⁠Chapt er 7 . O penSt ack Net working Service Inst allat ion

core_plugin = neutron.plugins.ml2.plugin.Ml2Plugin

service_plugins = neutron.services.l3_router.l3_router_plugin.L3RouterPlugin

5. Refer to Section 7.4.7, “ Create the OpenStack Networking Database” to configure the ML2

database.

6. Restart the OpenStack Networking service:

# servi ce neutro n-server restart

Pro ced u re 7.9 . En ab lin g t h e O p en vSwit ch p lu g - in

Follow these steps on the node running the neutro n-server service.

Note

The monolithic Open vSwitch plug-in has been deprecated and will be removed in a future release; its functionality has instead been re-implemented as a ML2 mechanism.

1. Create a symbolic link between the /etc/neutro n/pl ug i n. i ni path referred to by the

OpenStack Networking service and the plug-in specific configuration file.

# l n -s /etc/neutro n/pl ug i ns/o penvswi tch/o vs_neutro n_pl ug i n. i ni

/etc/neutro n/pl ug i n. i ni

2. Update the value of the tenant_netwo rk_type configuration key in the

/etc/neutro n/pl ug i n. i ni file to refer to the type of network that must be used for tenant networks. Supported values are g re, l o cal , vl an, and vxl an.

The default is l o cal but this is not recommended for real deployments.

Open vSwitch Tunneling allows virtual machines across multiple hosts to share a single layer 2 network. GRE and VXLAN tunnels are supported for encapsulating traffic between

Open vSwitch endpoints on each host. Ensure that MTUs are an appropriate size from endto-end, including those on the virtual machines.

# o penstack-co nfi g --set /etc/neutro n/pl ug i n. i ni \

O VS tenant_netwo rk_type TYPE

Replace TYPE with the type chosen tenant network type.

3. If fl at or vl an networking was chosen, the value of the netwo rk_vl an_rang es configuration key must also be set. This configuration key maps physical networks to VLAN ranges.

Mappings are of the form NAME:START:END where NAME is replaced by the name of the physical network, START is replaced by the VLAN identifier that starts the range, and END is replaced by the replaced by the VLAN identifier that ends the range.

# o penstack-co nfi g --set /etc/neutro n/pl ug i n. i ni \

O VS netwo rk_vl an_rang es NAME: START: END

115

Deploying O penSt ack: Learning Environment s (Manual Set up)

Multiple ranges can be specified using a comma separated list, for example: physnet1:1000:2999,physnet2:3000:3999

4. Update the value of the co re_pl ug i n configuration key in the

/etc/neutro n/neutro n. co nf file to refer to the Open vSwitch plug-in.

# o penstack-co nfi g --set /etc/neutro n/neutro n. co nf \

D EFAULT co re_pl ug i n \

neutro n. pl ug i ns. o penvswi tch. o vs_neutro n_pl ug i n. O VSNeutro nP l ug i nV

If you are using a Linux Bridge plug-in, perform the following procedure instead:

Pro ced u re 7.10. En ab lin g t h e Lin u x Brid g e p lu g - in

Follow these steps on the node running the neutro n-server service.

Note

The monolithic linuxbridge plug-in has been deprecated and will be removed in a future release; its functionality has instead been re-implemented as a ML2 mechanism.

1. Create a symbolic link between the /etc/neutro n/pl ug i n. i ni path referred to by the

OpenStack Networking service and the plug-in specific configuration file.

# l n -s /etc/neutro n/pl ug i ns/l i nuxbri d g e/l i nuxbri d g e_co nf. i ni \

/etc/neutro n/pl ug i n. i ni

2. Update the value of the tenant_netwo rk_type configuration key in the

/etc/neutro n/pl ug i n. i ni file to refer to the type of network that must be used for tenant networks. Supported values are fl at, vl an, and l o cal .

The default is l o cal but this is not recommended for real deployments.

# o penstack-co nfi g --set /etc/neutro n/pl ug i n. i ni \

VLAN tenant_netwo rk_type TYPE

Replace TYPE with the type chosen tenant network type.

3. If fl at or vl an networking was chosen, the value of the netwo rk_vl an_rang es configuration key must also be set. This configuration key maps physical networks to VLAN ranges.

# o penstack-co nfi g --set /etc/neutro n/pl ug i n. i ni \

LINUX_BR ID G E netwo rk_vl an_rang es NAME: START: END

116

⁠Chapt er 7 . O penSt ack Net working Service Inst allat ion

Multiple ranges can be specified using a comma separated list, for example: physnet1:1000:2999,physnet2:3000:3999

4. Update the value of the co re_pl ug i n configuration key in the

/etc/neutro n/neutro n. co nf file to refer to the Linux Bridge plug-in.

# o penstack-co nfi g --set /etc/neutro n/neutro n. co nf \

D EFAULT co re_pl ug i n \

neutro n. pl ug i ns. l i nuxbri d g e. l b_neutro n_pl ug i n. Li nuxBri d g eP l ug i n

7.4 .4 . VXLAN and GRE t unnels

Overlay links enable instances in different networks to communicate with each other by tunneling traffic through the underlying network. G R E and VXLAN are two supported tunnel encapsulation technologies:

G R E is an established encapsulation technology, with general acceptance in the industry. The GRE headers (RFC 2784 and 2890) perform encapsulation of Layer 2 frames.

VXLAN was submitted to the IETF in 2011 and is expected to become the default standard for multitenant cloud-scale networks. VXLAN uses UDP encapsulation and random values in the UDP source port, resulting in automatic equal-cost load balancing in every switch device that uses a 5tuple hash calculation to load balance. This allows VXLAN-encapsulated traffic to be load balanced by compatible physical network hardware.

T ab le 7.3. VXLAN an d G RE co mp ariso n

Feat u re

Segmentation

Theoretical scale limit

Transport

Filtering

Protocol overhead

VXLAN

24-bit VNI (VXLAN Network

Identifier)

16 million unique IDs

UDP (default port 4789)

VXLAN uses UDP with a wellknown destination port; firewalls and switch/router ACLs can be tailored to block only

VXLAN traffic.

50 bytes over IPv4 (8 bytes

VXLAN header, 20 bytes IPv4 header, 8 bytes UDP header, 14 bytes Ethernet).

G RE

Uses different Tunnel IDs

16 million unique IDs

IP Protocol 47

Firewalls and layer 3 switches and routers with ACLs will typically not parse deeply enough into the GRE header to distinguish tunnel traffic types; all GRE would need to be blocked indiscriminately.

42 bytes over IPv4 (8 bytes

GRE header, 20 bytes IPv4 header, 14 bytes Ethernet).

117

Deploying O penSt ack: Learning Environment s (Manual Set up)

Feat u re

Handling unknown destination packets, broadcasts, and multicast

IETF specification

VXLAN

VXLAN uses IP multicast to manage flooding from these traffic types. Ideally, one logical

Layer 2 network (VNI) is associated with one multicast group address on the physical network. This requires end-toend IP multicast support on the physical data center network.

http://tools.ietf.org/html/draftmahalingam-dutt-dcops-vxlan-

G RE

GRE has no built-in protocol mechanism to address these.

This type of traffic is simply replicated to all nodes.

http://tools.ietf.org/html/rfc2784.

html

Note

To avoid packet fragmentation, it is recommended to increase the MTU at the vSwitch and on all physical network devices that the VXLAN or GRE traffic will traverse.

7.4 .5. Configure Open vSwit ch t unneling

Tunneling encapsulates network traffic between physical OpenStack Networking hosts and allows

VLANs to span multiple physical hosts. Instances communicate as if they share the same layer 2 network. Open vSwitch supports tunneling with the VXLAN and GRE encapsulation protocols.

Fig u re 7.4 . Examp le VXLAN t u n n el

This diagram shows two instances running on separate hosts connected by a VXLAN tunnel. The required physical and virtual components are also illustrated. The following procedure creates a

VXLAN or GRE tunnel between two Open vSwitches running on separate OpenStack Networking

118

⁠Chapt er 7 . O penSt ack Net working Service Inst allat ion

hosts:

Pro ced u re 7.11. Examp le t u n n el co n f ig u rat io n

1. Create a virtual bridge named OVS-BR0 on each participating host: ovs-vsctl add-br OVS-BR0

2. Create a tunnel to link the OVS-BR0 virtual bridges. Run the ovs-vsctl command on HOST1 to create the tunnel and link it to the bridge on HOST2:

G RE t u n n el co mman d :

ovs-vsctl add-port OVS-BR0 gre1 -- set Interface gre1 type=gre options:remote_ip=192.168.1.11

VXLAN t u n n el co mman d :

ovs-vsctl add-port OVS-BR0 vxlan1 -- set Interface vxlan1 type=vxlan options:remote_ip=192.168.1.11

3. Run the ovs-vsctl command on HOST2 to create the tunnel and link it to the bridge on

HOST1.

G RE t u n n el co mman d :

ovs-vsctl add-port OVS-BR0 gre1 -- set Interface gre1 type=gre options:remote_ip=192.168.1.10

VXLAN t u n n el co mman d :

ovs-vsctl add-port OVS-BR0 vxlan1 -- set Interface vxlan1 type=vxlan options:remote_ip=192.168.1.10

Successful completion of these steps results in the two instances sharing a layer 2 network.

7.4 .6. Configure t he OpenSt ack Net working Service Dat abase Connect ion

The database connection string used by the OpenStack Networking service is defined in the

/etc/neutro n/pl ug i n. i ni file. It must be updated to point to a valid database server before starting the service.

Pro ced u re 7.12. Co n f ig u rin g t h e O p en St ack Net wo rkin g SQ L d at ab ase co n n ect io n

Use the o penstack-co nfi g command to set the value of the co nnecti o n configuration key.

# o penstack-co nfi g --set /etc/neutro n/pl ug i n. i ni \

D AT ABASE sq l _co nnecti o n mysq l : //USER: PASS@ IP/DB

Replace:

USER with the database user name the OpenStack Networking service is to use, See

Section 7.4.7, “ Create the OpenStack Networking Database”

for recommended database naming conventions.

119

Deploying O penSt ack: Learning Environment s (Manual Set up)

PASS with the password of the chosen database user.

IP with the IP address or host name of the database server.

DB with the name of the database that will be created for use by the OpenStack Networking service (o vs_neutro n is used as the example in the upcoming "Creating the OpenStack

Networking Database" section).

Important

The IP address or host name specified in the connection configuration key must match the

IP address or host name to which the neutron database user was granted access when creating the neutron database. Moreover, if the database is hosted locally and you granted permissions to 'localhost' when creating the neutron database, you must enter 'localhost'.

7.4 .7. Creat e t he OpenSt ack Net working Dat abase

In this procedure the database and database user that will be used by the OpenStack Networking service will be created. These steps must be performed while logged in to the database server as the

ro o t user, and prior to starting the neutro n-server service.

Pro ced u re 7.13. Creat in g t h e O p en St ack Net wo rkin g d at ab ase

1. Connect to the database service using the mysq l command.

# mysq l -u ro o t -p

2. Create the database. If you intend to use the:

ML2 plug-in, the recommended database name is neutro n_ml 2

Open vSwitch plug-in, the recommended database name is o vs_neutro n.

Linux Bridge plug-in, the recommended database name is neutro n_l i nux_bri d g e.

This example creates the ML2 neutro n_ml 2 database.

mysq l > CREATE DATABASE neutron_ml2 character set utf8;

3. Create a neutro n database user and grant it access to the neutro n_ml 2 database.

mysq l > GRANT ALL ON neutron_ml2.* TO 'neutron'@ '%' IDENTIFIED BY

'PASSWORD';

mysq l > GRANT ALL ON neutron_ml2.* TO 'neutron'@ 'localhost'

IDENTIFIED BY 'PASSWORD';

4. Flush the database privileges to ensure that they take effect immediately.

mysq l > FLUSH PRIVILEGES;

5. Exit the mysq l client.

120

⁠Chapt er 7 . O penSt ack Net working Service Inst allat ion

mysq l > quit

6. Run the neutro n-d b-manag e command:

# neutro n-d b-manag e --co nfi g -fi l e /usr/share/neutro n/neutro n-

d i st. co nf \

--co nfi g -fi l e /etc/neutro n/neutro n. co nf --co nfi g -fi l e

/etc/neutro n/pl ug i n. i ni upg rad e head

The OpenStack Networking database neutro n_ml 2 has been created. The database will be populated during service configuration.

See

Section 7.4.6, “ Configure the OpenStack Networking Service Database Connection” to configure

OpenStack Networking to use the newly created database.

See

Section 7.4.3, “ Set the OpenStack Networking Service Plug-in”

for plug-in selection and configuration.

7.4 .8. Launch t he OpenSt ack Net working Service

Once the required settings are configured, you can now launch the OpenStack Networking service

(neutro n) using the servi ce command:

# servi ce neutro n-server start

Enable the OpenStack Networking service permanently using the chkco nfi g command.

# chkco nfi g neutro n-server o n

The OpenStack Networking service is configured and running. Further action is however required to configure and run the various networking agents that are also fundamental to providing networking functionality.

Important

By default, OpenStack Networking does not enforce Classless Inter-Domain Routing (CIDR) checking of IP addresses. This is to maintain backwards compatibility with previous releases.

If you require such checks set the value of the fo rce_g ateway_o n_subnet configuration key to T rue in the /etc/neutro n/neutro n. co nf file.

7.5. Configure t he DHCP Agent

Follow the steps listed in this procedure to configure the DHCP Agent. All steps listed in this procedure must be performed on the network node while logged in as the ro o t user on the system hosting the DHCP agent.

Pro ced u re 7.14 . Co n f ig u rin g t h e DHCP Ag en t

1. Co n f ig u rin g Au t h en t icat io n

The DHCP agent must be explicitly configured to use the Identity service for authentication.

121

Deploying O penSt ack: Learning Environment s (Manual Set up)

a. Set the authentication strategy (auth_strateg y) configuration key to keysto ne using the o penstack-co nfi g command.

# o penstack-co nfi g --set /etc/neutro n/d hcp_ag ent. i ni \

D EFAULT auth_strateg y keysto ne b. Set the authentication host (auth_ho st configuration key) to the IP address or host name of the Identity server.

# o penstack-co nfi g --set /etc/neutro n/d hcp_ag ent. i ni \

keysto ne_authto ken auth_ho st IP

Replace IP with the IP address or host name of the Identity server.

c. Set the administration tenant name (ad mi n_tenant_name) configuration key to the name of the tenant that was created for the use of the OpenStack Networking services.

Examples in this guide use services.

# o penstack-co nfi g --set /etc/neutro n/d hcp_ag ent. i ni \

keysto ne_authto ken ad mi n_tenant_name services d. Set the administration user name (ad mi n_user) configuration key to the name of the user that was created for the use of the OpenStack Networking services. Examples in this guide use neutron.

# o penstack-co nfi g --set /etc/neutro n/d hcp_ag ent. i ni \

keysto ne_authto ken ad mi n_user neutron e. Set the administration password (ad mi n_passwo rd ) configuration key to the password that is associated with the user specified in the previous step.

# o penstack-co nfi g --set /etc/neutro n/d hcp_ag ent. i ni \

keysto ne_authto ken ad mi n_passwo rd PASSWORD

2. Co n f ig u rin g t h e In t erf ace Driver

Set the value of the i nterface_d ri ver configuration key in the

/etc/neutro n/d hcp_ag ent. i ni file based on the OpenStack Networking plug-in being used. Execute only the configuration step that applies to the plug-in used in your environment.

A. O p en vSwit ch In t erf ace Driver

# o penstack-co nfi g --set /etc/neutro n/d hcp_ag ent. i ni \

D EFAULT i nterface_d ri ver

neutro n. ag ent. l i nux. i nterface. O VSInterfaceD ri ver

B. Lin u x Brid g e In t erf ace Driver

# o penstack-co nfi g --set /etc/neutro n/d hcp_ag ent. i ni \

D EFAULT i nterface_d ri ver

neutro n. ag ent. l i nux. i nterface. Bri d g eInterfaceD ri ver

122

⁠Chapt er 7 . O penSt ack Net working Service Inst allat ion

3. St art in g t h e DHCP Ag en t a. Use the servi ce command to start the neutro n-d hcp-ag ent service.

# servi ce neutro n-d hcp-ag ent start b. Use the chkco nfi g command to ensure that the neutro n-d hcp-ag ent service will be started automatically in the future.

# chkco nfi g neutro n-d hcp-ag ent o n

The DHCP agent has been configured and started.

7.6. Creat e an Ext ernal Net work

OpenStack networking provides two mechanisms for connecting the Layer 3 (L3) agent to an external network. The first, attaching it to an external bridge (br-ex) directly, is only supported when the

Open vSwitch plug-in is in use. The second method, which is supported by both the Open vSwitch plug-in and the Linux Bridge plug-in, is to use an external provider network.

To use an external provider network it is first necessary to create one. Follow the steps outlined in this procedure while logged in to a system with the OpenStack networking client - provided by the

python-neutronclient package installed. You must also have access to a keysto nerc_ad mi n file containing the authentication details of the OpenStack administrative user.

Take note of the unique identifiers generated by the steps listed in this procedure. These identifiers will be required when configuring the L3 agent.

Pro ced u re 7.15. Creat in g an d co n f ig u rin g an ext ern al n et wo rk

1. Use the so urce command to load the credentials of the administrative user.

$ so urce ~/keystonerc_admin

2. Use the net-create action of the neutro n command line client to create a new provider network.

$ neutro n net-create EXTERNAL_NAME \

--ro uter: external T rue \

--pro vi d er: netwo rk_type TYPE \

--pro vi d er: physi cal _netwo rk PHYSNET \

--pro vi d er: seg mentati o n_i d VLAN_TAG

Replace these strings with the appropriate values for your environment:

Replace EXTERNAL_NAME with a name for the new external network provider.

Replace PHYSNET with a name for the physical network. This is not applicable if you intend to use a local network type. PHYSNET must match one of the values defined under

bri d g e_mappi ng s in the /etc/neutro n/pl ug i n. i ni file.

Replace TYPE with the type of provider network you wish to use. Supported values are

fl at (for flat networks), vl an (for VLAN networks), and l o cal (for local networks).

123

Deploying O penSt ack: Learning Environment s (Manual Set up)

Replace VLAN_TAG with the VLAN tag that will be used to identify network traffic. The VLAN tag specified must have been defined by the network administrator.

If the netwo rk_type was set to a value other than vl an then this parameter is not required.

Take note of the unique external network identifier returned, this will be required in subsequent steps.

3. Use the subnet-create action of the command line client to create a new subnet for the new external provider network.

$ neutro n subnet-create --g ateway GATEWAY \

--al l o cati o n-po o l start= IP_RANGE_START,end = IP_RANGE_END \

--d i sabl e-d hcp EXTERNAL_NAME EXTERNAL_CIDR

Replace these strings with the appropriate values for your environment:

Replace GATEWAY with the IP address or hostname of the system that is to act as the gateway for the new subnet.

Replace IP_RANGE_START with the IP address that denotes the start of the range of IP addresses within the new subnet that floating IP addresses will be allocated from.

Replace IP_RANGE_END with the IP address that denotes the end of the range of IP addresses within the new subnet that floating IP addresses will be allocated from.

Replace EXTERNAL_NAME with the name of the external network the subnet is to be associated with. This must match the name that was provided to the net-create action in the previous step.

Replace EXTERNAL_CIDR with the Classless Inter-Domain Routing (CIDR) representation of the block of IP addresses the subnet represents. An example would be

19 2. 16 8. 10 0 . 0 /24 .

Take note of the unique subnet identifier returned, this will be required in subsequent steps.

Important

The IP address used to replace the string GATEWAY mu st be within the block of IP addresses specified in place of the EXTERNAL_CIDR string but outside of the block of

IP addresses specified by the range started by IP_RANGE_START and ended by

IP_RANGE_END.

The block of IP addresses specified by the range started by IP_RANGE_START and ended by IP_RANGE_END mu st also fall within the block of IP addresses specified by

EXTERNAL_CIDR.

124

4. Use the ro uter-create action of the neutro n command line client to create a new router.

$ neutro n ro uter-create NAME

Replace NAME with the name to give the new router. Take note of the unique router identifier returned, this will be required in subsequent steps.

⁠Chapt er 7 . O penSt ack Net working Service Inst allat ion

5. Use the ro uter-g ateway-set action of the neutro n command line client to link the newly created router to the external provider network.

$ neutro n ro uter-g ateway-set ROUTER NETWORK

Replace ROUTER with the unique identifier of the router, replace NETWORK with the unique identifier of the external provider network.

6. Use the ro uter-i nterface-ad d action of the neutro n command line client to link the newly created router to each private network subnet.

$ neutro n ro uter-i nterface-ad d ROUTER SUBNET

Replace ROUTER with the unique identifier of the router, replace SUBNET with the unique identifier of a private network subnet. Perform this step for each existing private network subnet to which you wish to link the router.

An external provider network has been created. Use the unique identifier of the router when configuring the L3 agent.

7.7. Configuring t he Plug-in Agent

7.7.1. Configure t he Open vSwit ch Plug-in Agent

If you have not yet enabled the Open vSwitch plug-in, see Section 7.4.3, “ Set the OpenStack

Networking Service Plug-in” .

The Open vSwitch plug-in has a corresponding agent. When the Open vSwitch plug-in is in use all nodes in the environment that handle data packets must have the agent installed and configured.

This includes all compute nodes and systems hosting the dedicated DHCP and L3 agents.

Note

Open vSwitch support for TCP segmentation offload (TSO) and Generic Segmentation Offload

(GSO) to VXLAN and GRE is enabled by default.

Pro ced u re 7.16 . Co n f ig u rin g t h e O p en vSwit ch Plu g - in Ag en t

1. Confirm that the openvswitch package is installed. This is normally installed as a dependency of the neutron-plugin-openvswitch package.

# rpm -q a | g rep o penvswi tch openvswitch-1.10.0-1.el6.x86_64

openstack-neutron-openvswitch-2013.1-3.el6.noarc

2. Start the o penvswi tch service.

# servi ce o penvswi tch start

3. Enable the o penvswi tch service permanently.

125

Deploying O penSt ack: Learning Environment s (Manual Set up)

# chkco nfi g o penvswi tch o n

4. Each host running the Open vSwitch agent also requires an Open vSwitch bridge named br-

i nt. This bridge is used for private network traffic. Use the o vs-vsctl command to create this bridge before starting the agent.

# o vs-vsctl ad d -br br-i nt

Warning

The br-i nt bridge is required for the agent to function correctly. Once created do not remove or otherwise modify the br-i nt bridge.

126

5. Ensure that the br-i nt device persists on reboot by creating a

/etc/sysco nfi g /netwo rk-scri pts/i fcfg -br-i nt file with these contents:

DEVICE=br-int

DEVICETYPE=ovs

TYPE=OVSBridge

ONBOOT=yes

BOOTPROTO=none

6. Set the value of the bri d g e_mappi ng s configuration key. This configuration key must contain a list of physical networks and the network bridges associated with them.

The format for each entry in the comma separated list is:

PHYSNET:BRIDGE

Where PHYSNET is replaced with the name of a physical network, and BRIDGE is replaced by the name of the network bridge.

The physical network must have been defined in the netwo rk_vl an_rang es configuration variable on the OpenStack Networking server.

# o penstack-co nfi g --set /etc/neutro n/pl ug i n. i ni \

O VS bri d g e_mappi ng s MAPPINGS

Replace MAPPINGS with the physical network to bridge mappings.

7. Use the servi ce command to start the neutro n-o penvswi tch-ag ent service.

# servi ce neutro n-o penvswi tch-ag ent start

8. Use the chkco nfi g command to ensure that the neutro n-o penvswi tch-ag ent service is started automatically in the future.

# chkco nfi g neutro n-o penvswi tch-ag ent o n

9. Use the chkco nfi g command to ensure that the neutro n-o vs-cl eanup service is started automatically on boot. When started at boot time this service ensures that the OpenStack

Networking agents maintain full control over the creation and management of tap devices.

⁠Chapt er 7 . O penSt ack Net working Service Inst allat ion

# chkco nfi g neutro n-o vs-cl eanup o n

The networking configuration has been updated to use the Open vSwitch plug-in.

7.7.2. Configure t he Linux Bridge Plug-in Agent

The Linux Bridge plug-in has a corresponding agent. When the Linux Bridge plug-in is in use all nodes in the environment that handle data packets must have the agent installed and configured.

This includes all compute nodes and systems hosting the dedicated DHCP and L3 agents.

Pro ced u re 7.17. Co n f ig u rin g t h e Lin u x Brid g e p lu g - in ag en t

1. Set the value of the physi cal _i nterface_mappi ng s configuration key. This configuration key must contain a list of physical networks and the VLAN ranges associated with them that are available for allocation to tenant networks.

The format for each entry in the comma separated list is:

PHYSNET:VLAN_START:VLAN_END

Where PHYSNET is replaced with the name of a physical network, VLAN_START is replaced by an identifier indicating the start of the VLAN range, and VLAN_END is replaced by an identifier indicating the end of the VLAN range.

The physical networks must have been defined in the netwo rk_vl an_rang es configuration variable on the OpenStack Networking server.

# o penstack-co nfi g --set /etc/neutro n/pl ug i n. i ni \

LINUX_BR ID G E physi cal _i nterface_mappi ng s MAPPINGS

Replace MAPPINGS with the physical network to VLAN range mappings.

2. Use the servi ce command to start the neutro n-l i nuxbri d g e-ag ent service.

# servi ce neutro n-l i nuxbri d g e-ag ent start

3. Use the chkco nfi g command to ensure that the neutro n-l i nuxbri d g e-ag ent service is started automatically in the future.

# chkco nfi g neutro n-l i nuxbri d g e-ag ent o n

The networking configuration has been updated to use the Linux Bridge plug-in.

7.8. Configure t he L3 Agent

Follow the steps listed in this procedure to configure the L3 agent. All steps listed in this procedure must be performed on the network node while logged in as the ro o t user.

Pro ced u re 7.18. Co n f ig u rin g t h e L3 Ag en t

1. Co n f ig u rin g Au t h en t icat io n

127

Deploying O penSt ack: Learning Environment s (Manual Set up)

a. Set the authentication strategy (auth_strateg y) configuration key to keysto ne using the o penstack-co nfi g command.

# o penstack-co nfi g --set /etc/neutro n/metad ata_ag ent. i ni \

D EFAULT auth_strateg y keysto ne b. Set the authentication host (auth_ho st) configuration key to the IP address or host name of the Identity server.

# o penstack-co nfi g --set /etc/neutro n/metad ata_ag ent. i ni \

keysto ne_authto ken auth_ho st IP

Replace IP with the IP address or host name of the Identity server.

c. Set the administration tenant name (ad mi n_tenant_name) configuration key to the name of the tenant that was created for the use of the OpenStack Networking services.

Examples in this guide use services.

# o penstack-co nfi g --set /etc/neutro n/metad ata_ag ent. i ni \

keysto ne_authto ken ad mi n_passwo rd PASSWORD

Note

When used in ad mi n_passwo rd , the $ and " " (space-bar) special characters must be properly escaped. Escape the $ in co mpl ex$passwo rd with a second $ to become co mpl ex$$passwo rd . Escape the " " (space-bar) char with quotation marks: co mpl ex passwo rd becomes "co mpl ex passwo rd ".

2. Co n f ig u rin g t h e In t erf ace Driver

Set the value of the i nterface_d ri ver configuration key in the

/etc/neutro n/l 3_ag ent. i ni file based on the OpenStack Networking plug-in being used. Execute only the configuration step that applies to the plug-in used in your environment.

A. O p en vSwit ch In t erf ace Driver

128

⁠Chapt er 7 . O penSt ack Net working Service Inst allat ion

# o penstack-co nfi g --set /etc/neutro n/l 3_ag ent. i ni \

D EFAULT i nterface_d ri ver

neutro n. ag ent. l i nux. i nterface. O VSInterfaceD ri ver

B. Lin u x Brid g e In t erf ace Driver

# o penstack-co nfi g --set /etc/neutro n/l 3_ag ent. i ni \

D EFAULT i nterface_d ri ver

neutro n. ag ent. l i nux. i nterface. Bri d g eInterfaceD ri ver

3. Co n f ig u rin g Ext ern al Net wo rk Access

The L3 agent connects to external networks using either an external bridge or an external provider network. When using the Open vSwitch plug-in either approach is supported. When using the Linux Bridge plug-in only the use of an external provider network is supported.

Choose the approach that is most appropriate for the environment.

A. Usin g an Ext ern al Brid g e

To use an external bridge you must create and configure it. Finally the OpenStack

Networking configuration must be updated to use it. This must be done on each system hosting an instance of the L3 agent.

a. Use the o vs-vsctl command to create the external bridge named br-ex.

# o vs-vsctl ad d -br br-ex b. Ensure that the br-ex device persists on reboot by creating a

/etc/sysco nfi g /netwo rk-scri pts/i fcfg -br-ex file with these contents:

DEVICE=br-ex

DEVICETYPE=ovs

TYPE=OVSBridge

ONBOOT=yes

BOOTPROTO=none c. Ensure that the value of the external _netwo rk_bri d g e configuration key in the

/etc/neutro n/l 3_ag ent. i ni file is br-ex. This ensures that the L3 agent will use the external bridge.

# o penstack-co nfi g --set /etc/neutro n/l 3_ag ent. i ni \

D EFAULT external _netwo rk_bri d g e br-ex

B. Usin g a Pro vid er Net wo rk

To connect the L3 agent to external networks using a provider network you must first have created the provider network. You must also have created a subnet and router to associate with it. The unique identifier of the router will be required to complete these steps.

The value of the external _netwo rk_bri d g e configuration key in the

/etc/neutro n/l 3_ag ent. i ni file must be blank. This ensures that the L3 agent does not attempt to use an external bridge.

129

Deploying O penSt ack: Learning Environment s (Manual Set up)

# o penstack-co nfi g --set /etc/neutro n/l 3_ag ent. i ni \

D EFAULT external _netwo rk_bri d g e ""

4. St art in g t h e L3 Ag en t a. Use the servi ce command to start the neutro n-l 3-ag ent service.

# servi ce neutro n-l 3-ag ent start b. Use the chkco nfi g command to ensure that the neutro n-l 3-ag ent service will be started automatically in the future.

# chkco nfi g neutro n-l 3-ag ent o n

5. St art in g t h e Met ad at a Ag en t

The OpenStack Networking metadata agent allows virtual machine instances to communicate with the compute metadata service. It runs on the same hosts as the Layer 3 (L3) agent.

a. Use the servi ce command to start the neutro n-metad ata-ag ent service.

# servi ce neutro n-metad ata-ag ent start b. Use the chkco nfi g command to ensure that the neutro n-metad ata-ag ent service will be started automatically in the future.

# chkco nfi g neutro n-metad ata-ag ent o n

The L3 agent has been configured and started.

6. En ab le least ro u t er sch ed u lin g

The leastrouter scheduler enumerates L3 Agent router assignment, and consequently schedules the router to the L3 Agent with the fewest routers. This differs from the

ChanceScheduler behavior, which randomly selects from the candidate pool of L3 Agents.

Enable the leastrouter scheduler by changing the ro uter_sched ul er_d ri ver option in the

neutro n. co nf file: router_scheduler_driver=neutron.scheduler.l3_agent_scheduler.LeastR

outersScheduler

The router is scheduled once connected to a network. Unschedule the router using the

neutro n command:

# neutro n l 3-ag ent-ro uter-remo ve [l 3 no d e] [ro uter]

Assign the router with using the neutro n command:

# neutro n l 3-ag ent-ro uter-ad d [l 3 no d e] [ro uter]

7.9. Validat e t he OpenSt ack Net working Inst allat ion

130

⁠Chapt er 7 . O penSt ack Net working Service Inst allat ion

To begin using OpenStack Networking it is necessary to deploy networking components to compute nodes. Initial networks and routers must also be defined. It is however possible to perform basic sanity checking of the OpenStack Networking deployment by following the steps outline in this procedure.

Pro ced u re 7.19 . Valid at in g t h e O p en St ack Net wo rkin g in st allat io n

1. All No d es a. Verify that the customized Red Hat Enterprise Linux kernel intended for use with Red

Hat Enterprise Linux OpenStack Platform is running:

$ uname --kernel -rel ease

2.6.32-358.6.2.o penstack.el6.x86_64

If the kernel release value returned does not contain the string o penstack then update the kernel and reboot the system.

b. Ensure that the installed IP utilities support network namespaces:

$ i p netns

If an error indicating that the argument is not recognised or supported is returned then update the system using yum.

2. Service No d es a. Ensure that the neutro n-server service is running:

$ o penstack-status | g rep neutro n-server neutron-server: active

3. Net wo rk No d es

Ensure that the following services are running:

DHCP agent (neutro n-d hcp-ag ent)

L3 agent (neutro n-l 3-ag ent)

Plug-in agent, if applicable (neutro n-o penvswi tch-ag ent or neutro n-

l i nuxbri d g e-ag ent)

Metadata agent (neutro n-metad ata-ag ent)

To do so, run:

# o penstack-status | g rep SERVICENAME

Replace SERVICENAME with the appropriate service name. For example, to check whether the

L3 agent is running:

# o penstack-status | g rep neutro n-l 3-ag ent

131

Deploying O penSt ack: Learning Environment s (Manual Set up)

All required services on the service and network nodes are operational. Proceed to deploy some compute nodes, define networks, and define routers to begin using OpenStack Networking.

7.9.1. T roubleshoot OpenSt ack Net working Issues

This section discusses the different commands you can use and procedures you can follow to troubleshoot the OpenStack Networking service issues.

Deb u g g in g Net wo rkin g Device

Use the i p a command to display all the physical and virtual devices.

Use the o vs-vsctl sho w command to display the interfaces and bridges in a virtual switch.

Use the o vs-d pctl sho w command to show datapaths on the switch.

T rackin g Net wo rkin g Packet s

Use the tcpd ump command to see where packets are not getting through.

# tcpdump -n -i INTERFACE -e -w FILENAME

Replace INTERFACE with the name of the network interface to see where the packets are not getting through. The interface name can be the name of the bridge or host Ethernet device.

The -e flag ensures that the link-level header is dumped (in which the vlan tag will appear).

The -w flag is optional. You can use it only if you want to write the output to a file. If not, the output is written to the standard output (std o ut).

For more information about tcpd ump, refer to its manual page by running man

tcpd ump.

Deb u g g in g Net wo rk Namesp aces

Use the i p netns l i st command to list all known network namespaces.

Use the i p netns exec command to show routing tables inside specific namespaces.

# ip netns exec NAMESPACE_ID bash

# route -n

Start the i p netns exec command in a bash shell so that subsequent commands can be invoked without the i p netns exec command.

132

⁠Chapt er 8 . O penSt ack Comput e Service Inst allat ion

Chapter 8. OpenStack Compute Service Installation

8.1. Comput e Service Requirement s

8.1.1. Check for Hardware Virt ualiz at ion Support

The OpenStack Compute Service requires hardware virtualization support and certain kernel modules. Follow this procedure to determine whether your system has hardware virtualization support and the correct kernel modules available.

All steps listed must be performed while logged into the system as the ro o t user.

Pro ced u re 8.1. Verif yin g h ard ware virt u aliz at io n su p p o rt

1. Use the g rep command to check for the presence of the svm or vmx CPU extensions by inspecting the /pro c/cpui nfo file generated by the kernel:

# g rep -E ' svm| vmx' /pro c/cpui nfo

If any output is shown after running this command then the CPU is hardware virtualization capable and the functionality is enabled in the system BIOS.

2. Use the l smo d command to list the loaded kernel modules and verify that the kvm modules are loaded:

# l smo d | g rep kvm

If the output includes kvm_i ntel or kvm_amd then the kvm hardware virtualization modules are loaded and your kernel meets the module requirements for the OpenStack Compute

Service.

This completes the required checks to ensure hardware virtualization support is available and enabled, and that you have the correct kernel modules loaded.

If the checks indicated that either hardware virtualization support or the required kernel modules are not available or not enabled then you must take action to either find a system that does have the required hardware virtualization support and modules, or enable it on the system that failed the checks.

8.2. Inst all a Comput e VNC Proxy

8.2.1. Inst all t he Comput e VNC Proxy Packages

The VNC proxy is available to users of the Compute service. Two types of VNC proxy server packages are available. The openstack-nova-novncproxy package provides VNC support to instances through a web browser (using Websockets), while the openstack-nova-console package provides access to instances through a traditional VNC client (through the o penstack-no va-xvpvncpro xy service).

The console authentication service, also provided by the openstack-nova-console package, is used to authenticate the VNC connections. Typically the console authentication service and the proxy utilities are installed on the same host as the Compute API service.

The following steps must be performed while logged in as the ro o t user.

133

Deploying O penSt ack: Learning Environment s (Manual Set up)

Pro ced u re 8.2. In st allin g t h e Co mp u t e VNC p ro xy p ackag es

Install the VNC proxy utilities and the console authentication service:

A. Install the openstack-nova-novncproxy package using the yum command:

# yum i nstal l -y o penstack-no va-no vncpro xy

B. Install the openstack-nova-console package using the yum command:

# yum i nstal l -y o penstack-no va-co nso l e

The VNC proxy packages and the console authentication service are now installed and ready for configuration.

8.2.2. Configure t he Firewall t o Allow Comput e VNC Proxy T raffic

The node that hosts VNC access to instances must be configured to allow VNC traffic through its firewall. By default, the o penstack-no va-no vncpro xy service listens on TCP port 6080 and the

o penstack-no va-xvpvncpro xy service listens on TCP port 6081.

The following procedure allows traffic on TCP port 6080 to traverse through the firewall for use by the

openstack-nova-novncproxy package:

The following steps must be performed while logged in as the ro o t user.

Pro ced u re 8.3. Co n f ig u rin g t h e f irewall t o allo w Co mp u t e VNC p ro xy t raf f ic

1. Edit the /etc/sysco nfi g /i ptabl es file and add the following on a new line underneath the -A INPUT -i lo -j ACCEPT line and before any -A INPUT -j REJECT rules:

-A INPUT -m state --state NEW -m tcp -p tcp --dport 6080 -j ACCEPT

2. Save the file and exit the editor.

Similarly, when using the o penstack-no va-xvpvncpro xy service, enable traffic on TCP port

6081 with the following on a new line in the same location:

-A INPUT -m state --state NEW -m tcp -p tcp --dport 6081 -j ACCEPT

Once the file has been edited with the new firewall rule or rules, run the following commands as the

ro o t user to apply the changes:

# service iptables restart

# iptables-save

The firewall is now configured to allow VNC proxy traffic.

8.2.3. Configure t he VNC Proxy Service

VNC access to instances is available over a web browser or with a traditional VNC client. The

/etc/no va/no va. co nf file holds the following VNC options:

134

⁠Chapt er 8 . O penSt ack Comput e Service Inst allat ion

vnc_enabled - Default is true.

vncserver_listen - The IP address to which VNC services will bind.

vncserver_proxyclient_address - The IP address of the compute host used by proxies to connect to instances.

novncproxy_base_url - The browser address where clients connect to instance.

novncproxy_port - The port listening for browser VNC connections. Default is 6080.

xvpvncproxy_port - The port to bind for traditional VNC clients. Default is 6081.

As the ro o t user, use the servi ce command to start the console authentication service:

# servi ce o penstack-no va-co nso l eauth start

Use the chkco nfi g command to permanently enable the service:

# chkco nfi g o penstack-no va-co nso l eauth o n

As the ro o t user, use the servi ce command on the nova node to start the browser-based service:

# servi ce o penstack-no va-no vncpro xy start

Use the chkco nfi g command to permanently enable the service:

# chkco nfi g o penstack-no va-no vncpro xy o n

To control access to the VNC service that uses a traditional client (non browser-based), substitute

openstack-nova-xvpvncproxy into the previous commands.

8.2.4 . Configure Live Migrat ion

Red Hat Enterpise Linux OpenStack Platform supports live migration using either shared storage migration or block migration. The following sections provide general prerequisites for both types. For detailed configuration steps for both types, see "Migrate a Live (running) Instance" .

8 .2 .4 .1 . Ge ne ral Re quire m e nt s

General requirements for migration include:

Access to the cloud environment on the command line as an administrator (all steps in this procedure are carried out on the command line). To execute commands, first load the user's authentication variables:

# so urce ~ /keysto nerc_ad mi n

Both source and destination nodes must be located in the same subnet, and have the same processor type.

All compute servers (controller and nodes) must be able to perform name resolution with each other.

135

Deploying O penSt ack: Learning Environment s (Manual Set up)

The UID and GID of the Compute service and libvirt users must be identical between compute nodes.

The compute nodes must be using KVM with libvirt.

8 .2 .4 .2 . Mult ipat hing Re quire m e nt s

When migrating an instance with multipathing configured, you need to ensure consistent multipath device naming between the source and destination nodes. The migration will fail if the instance cannot resolve multipath device names in the destination node.

You can ensure consistent multipath device naming by forcing both source and destination nodes to use device WWIDs. To do this, disable user-friendly names and restart mul ti pathd by running these commands on both source and destination nodes:

# mpathco nf --enabl e --user_fri end l y_names n

# servi ce mul ti pathd restart

For more information, see Consistent Multipath Device Names in a Cluster from the DM Multipath guide.

8.2.5. Access Inst ances wit h t he Comput e VNC Proxy

Browse to the novncproxy_base_url URL provided in the /etc/no va/no va. co nf file to access instance consoles.

The following image shows VNC access to a Fedora Linux instance with a web browser. It is provided only as an example, and settings such as IP addresses will be different in your environment.

136

⁠Chapt er 8 . O penSt ack Comput e Service Inst allat ion

Fig u re 8.1. VNC in st an ce access

8.3. Inst all a Comput e Node

8.3.1. Creat e t he Comput e Service Dat abase

The following procedure creates the database and database user used by the Compute service.

These steps must be performed while logged in to the database server as the ro o t user.

Pro ced u re 8.4 . Creat in g t h e Co mp u t e Service d at ab ase

1. Connect to the database service using the mysq l command.

# mysq l -u ro o t -p

2. Create the no va database.

mysq l > CREATE DATABASE nova;

3. Create a no va database user and grant it access to the no va database.

mysq l > GRANT ALL ON nova.* TO 'nova'@ '%' IDENTIFIED BY

'PASSWORD';

137

Deploying O penSt ack: Learning Environment s (Manual Set up)

mysq l > GRANT ALL ON nova.* TO 'nova'@ 'localhost' IDENTIFIED BY

'PASSWORD';

Replace PASSWORD with a secure password that will be used to authenticate with the database server as this user.

4. Flush the database privileges to ensure that they take effect immediately.

mysq l > FLUSH PRIVILEGES;

5. Exit the mysq l client.

mysq l > quit

The Compute database has been created. The database will be populated during service configuration.

8.3.2. Configure Comput e Service Aut hent icat ion

This section outlines the steps for creating and configuring Identity service records required by the

Compute service.

1. Create the co mpute user, who has the ad mi n role in the servi ces tenant.

2. Create the co mpute service entry and assign it an endpoint.

These entries will assist other OpenStack services attempting to locate and access the functionality provided by the Compute service. In order to proceed, you should have already performed the following (through the Identity service):

1. Created an Administrator role named ad mi n (refer to Section 3.7, “ Create an Administrator

2. Created the servi ces tenant (refer to

service users. For more information, refer to Section 3.9, “ Create the Services Tenant” .

for instructions)

Note

The Deploying OpenStack: Learning Environments (Manual Set Up) guide uses one tenant for all

You can perform the following procedure from your Identity service host or on any machine where you've copied the keysto nerc_ad mi n file (which contains administrator credentials) and the

keyst o n e command-line utility is installed.

Pro ced u re 8.5. Co n f ig u rin g t h e Co mp u t e Service t o au t h en t icat e t h ro u g h t h e Id en t it y

Service

1. Authenticate as the administrator of the Identity service by running the so urce command on the keysto nerc_ad mi n file containing the required credentials:

# so urce ~ /keysto nerc_ad mi n

138

⁠Chapt er 8 . O penSt ack Comput e Service Inst allat ion

2. Create a user named co mpute for the OpenStack Compute service to use:

# keysto ne user-create --name co mpute --pass PASSWORD

+----------+----------------------------------+

| Property | Value |

+----------+----------------------------------+

| email | |

| enabled | True |

| id | 96cd855e5bfe471ce4066794bbafb615 |

| name | compute |

| tenantId | |

+----------+----------------------------------+

Replace PASSWORD with a secure password that will be used by the Compute service when authenticating against the Identity service.

3. Use the keysto ne user-ro l e-ad d command to link the co mpute user, ad mi n role, and

servi ces tenant together:

# keysto ne user-ro l e-ad d --user co mpute --ro l e ad mi n --tenant

servi ces

4. Create the co mpute service entry:

# keysto ne servi ce-create --name co mpute \

--type co mpute \

--d escri pti o n "O penStack C o mpute Servi ce"

+-------------+----------------------------------+

| Property | Value |

+-------------+----------------------------------+

| description | OpenStack Compute Service |

| id | 8dea97f5ee254b309c1792d2bd821e59 |

| name | compute |

| type | compute |

+-------------+----------------------------------+

5. Create the co mpute endpoint entry:

# keysto ne end po i nt-create \

--servi ce co mpute

--publ i curl "http: //IP: 8774 /v2/\%(tenant_i d )s" \

--ad mi nurl "http: //IP: 8774 /v2/\%(tenant_i d )s" \

--i nternal url "http: //IP: 8774 /v2/\%(tenant_i d )s"

Replace IP with the IP address or host name of the system that will be acting as the compute node.

All supporting Identity service entries required by the OpenStack Compute service have been created.

8.3.3. Inst all t he Comput e Service Packages

The OpenStack Compute services are provided the following packages:

openstack-nova-api

139

Deploying O penSt ack: Learning Environment s (Manual Set up)

Provides the OpenStack Compute API service. At least one node in the environment must host an instance of the API service. This must be the node pointed to by the Identity service endpoint definition for the Compute service.

openstack-nova-compute

Provides the OpenStack Compute service.

openstack-nova-conductor

Provides the Compute conductor service. The conductor handles database requests made by Compute nodes, ensuring that individual Compute nodes do not require direct database access. At least one node in each environment must act as a Compute conductor.

openstack-nova-scheduler

Provides the Compute scheduler service. The scheduler handles scheduling of requests made to the API across the available Compute resources. At least one node in each environment must act as a Compute scheduler.

python-cinderclient

Provides client utilities for accessing storage managed by the OpenStack Block Storage service. This package is not required if you do not intend to attach block storage volumes to your instances or you intend to manage such volumes using a service other than the

OpenStack Block Storage service.

To install the above packages, execute the following command while logged in as the ro o t user:

# yum i nstal l -y o penstack-no va-api o penstack-no va-co mpute \

o penstack-no va-co nd ucto r o penstack-no va-sched ul er \

pytho n-ci nd ercl i ent

Note

In the command presented here, all Compute service packages are installed on a single node.

In a production deployment, Red Hat recommends that the API, conductor, and scheduler services be installed on a separate controller node or on separate nodes entirely. The

Compute service itself must be installed on each node that is expected to host virtual machine instances.

The Compute service package is now installed.

8.3.4 . Configure t he Comput e Service t o Use SSL

Use the following options in the no va. co nf file to configure SSL.

T ab le 8.1. SSL o p t io n s f o r Co mp u t e

Co n f ig u rat io n

O p t io n enabl ed _ssl _a pi s ssl _ca_fi l e

Descrip t io n

A list of APIs with enabled SSL.

CA certificate file to use to verify connecting clients.

14 0

⁠Chapt er 8 . O penSt ack Comput e Service Inst allat ion

Co n f ig u rat io n

O p t io n

Descrip t io n ssl _cert_fi l e

SSL certificate of API server.

ssl _key_fi l e

SSL private key of API server.

tcp_keepi d l e

Sets the value of TCP_KEEPIDLE in seconds for each server socket. Defaults to 600.

8.3.5. Configure t he Comput e Service

8 .3.5 .1 . Co nfigure Co m put e Se rvice Aut he nt icat io n

The Compute service must be explicitly configured to use the Identity service for authentication.

Follow the steps listed in this procedure to configure this.

All steps listed in this procedure must be performed on each system hosting Compute services while logged in as the ro o t user.

Pro ced u re 8.6 . Co n f ig u rin g t h e Co mp u t e Service t o au t h en t icat e t h ro u g h t h e Id en t it y

Service

1. Set the authentication strategy (auth_strateg y) configuration key to keysto ne using the

o penstack-co nfi g command.

# o penstack-co nfi g --set /etc/no va/no va. co nf \

D EFAULT auth_strateg y keysto ne

2. Set the authentication host (auth_ho st) configuration key to the IP address or host name of the Identity server.

# o penstack-co nfi g --set /etc/no va/api -paste. i ni \

fi l ter: authto ken auth_ho st IP

Replace IP with the IP address or host name of the Identity server.

3. Set the administration tenant name (ad mi n_tenant_name) configuration key to the name of the tenant that was created for the use of the Compute service. In this guide, examples use

services.

# o penstack-co nfi g --set /etc/no va/api -paste. i ni \

fi l ter: authto ken ad mi n_tenant_name services

4. Set the administration user name (ad mi n_user) configuration key to the name of the user that was created for the use of the Compute service. In this guide, examples use compute.

# o penstack-co nfi g --set /etc/no va/api -paste. i ni \

fi l ter: authto ken ad mi n_user compute

5. Set the administration password (ad mi n_passwo rd ) configuration key to the password that is associated with the user specified in the previous step.

# o penstack-co nfi g --set /etc/no va/api -paste. i ni \

fi l ter: authto ken ad mi n_passwo rd PASSWORD

14 1

Deploying O penSt ack: Learning Environment s (Manual Set up)

The authentication keys used by the Compute services have been set and will be used when the services are started.

8 .3.5 .2 . Co nfigure t he Co m put e Se rvice Dat abase Co nne ct io n

The database connection string used by the Compute service is defined in the

/etc/no va/no va. co nf file. It must be updated to point to a valid database server before starting the service.

The database connection string only needs to be set on nodes that will be hosting the conductor service (o penstack-no va-co nd ucto r). Compute nodes communicate with the conductor using the messaging infrastructure, the conductor in turn orchestrates communication with the database.

As a result individual compute nodes do not require direct access to the database. This procedure only needs to be followed on nodes that will host the conductor service. There must be at least one instance of the conductor service in any compute environment.

All commands in this procedure must be run while logged in as the ro o t user on the server hosting the Compute service.

Pro ced u re 8.7. Co n f ig u rin g t h e Co mp u t e Service SQ L d at ab ase co n n ect io n

Use the o penstack-co nfi g command to set the value of the sq l _co nnecti o n configuration key.

# o penstack-co nfi g --set /etc/no va/no va. co nf \

D EFAULT sq l _co nnecti o n mysq l : //USER: PASS@ IP/DB

Replace:

USER with the database user name the Compute service is to use, usually no va.

PASS with the password of the chosen database user.

IP with the IP address or host name of the database server.

DB with the name of the database that has been created for use by the compute, usually no va.

Important

The IP address or host name specified in the connection configuration key must match the IP address or host name to which the nova database user was granted access when creating the nova database. Moreover, if the database is hosted locally and you granted permissions to

'localhost' when creating the nova database, you must enter 'localhost'.

The database connection string has been set and will be used by the Compute service.

8 .3.5 .3. Co nfigure Rabbit MQ Me ssage Bro ke r Se t t ings fo r t he Co m put e Se rvice

This section assumes that you have already configured a RabbitMQ message broker. For more information, refer to:

14 2

⁠Chapt er 8 . O penSt ack Comput e Service Inst allat ion

Section 2.4.2, “ Install and Configure the RabbitMQ Message Broker”

Section 2.4.1, “ Configure the Firewall for Message Broker Traffic”

Section 2.4.2.1, “ Launch the RabbitMQ Message Broker”

Pro ced u re 8.8. Co n f ig u rin g t h e Co mp u t e service t o u se t h e Rab b it MQ messag e b ro ker

Perform the following steps as ro o t on the Compute controller, and all Compute nodes.

1. In /etc/no va/no va. co nf of that system, set RabbitMQ as the RPC back end.

# o penstack-co nfi g --set /etc/no va/no va. co nf \

D EFAULT rpc_backend rabbi t

2. Set the Compute service to connect to the RabbitMQ host:

# o penstack-co nfi g --set /etc/no va/no va. co nf \

D EFAULT rabbi t_ho st RABBITMQ_HOST

Replace RABBITMQ_HOST with the IP address or host name of the message broker.

3. Set the message broker port to 56 72:

# o penstack-co nfi g --set /etc/no va/no va. co nf \

D EFAULT rabbi t_po rt 56 72

4. Set the RabbitMQ username and password created for the Compute service:

# o penstack-co nfi g --set /etc/no va/no va. co nf \

D EFAULT rabbi t_useri d no va

# o penstack-co nfi g --set /etc/no va/no va. co nf \

D EFAULT rabbi t_passwo rd NOVA_PASS

Where no va and NOVA_PASS are the RabbitMQ username and password created for

Compute (in

Section 2.4.2, “ Install and Configure the RabbitMQ Message Broker” ).

5. In Section 2.4.2.1, “ Launch the RabbitMQ Message Broker” , we gave the no va user read/write

permissions to all resources -- specifically, through the virtual host /. Configure the Compute service to connect to this virtual host:

# o penstack-co nfi g --set /etc/no va/no va. co nf \

D EFAULT rabbi t_vi rtual _ho st /

8.3.5.3.1. En ab le SSL Co mmu n icat io n Bet ween Co mp u t e Service an d Messag e Bro ker

If you enabled SSL on the message broker, you will also have to configure the Compute service

accordingly. For this, you will need the exported client certificates and key file. See Section 2.4.2.3,

“ Export an SSL Certificate for Clients” for instructions on how to export these files.

Once you have the necessary certificates and key, run the following commands to enable SSL communication with the message broker:

14 3

Deploying O penSt ack: Learning Environment s (Manual Set up)

# o penstack-co nfi g --set /etc/no va/no va. co nf \

D EFAULT rabbi t_use_ssl T rue

# o penstack-co nfi g --set /etc/no va/no va. co nf \

D EFAULT ko mbu_ssl _certfi l e /path/to/client.crt

# o penstack-co nfi g --set /etc/no va/no va. co nf \

D EFAULT ko mbu_ssl _keyfi l e /path/to/clientkeyfile.key

Where:

/path/to/client.crt is the absolute path to the exported client certificate.

/path/to/clientkeyfile.key is the absolute path to the exported client key file.

If your certificates were signed by a third-party Certificate Authority (CA), then you will also need to run the following command:

# o penstack-co nfi g --set /etc/no va/no va. co nf \

D EFAULT ko mbu_ssl _ca_certs /path/to/ca.crt

Replace /path/to/ca.crt with the absolute path to the CA file provided by the third-party CA (see

Section 2.4.2.2, “ Enable SSL on the RabbitMQ Message Broker”

for more information).

8 .3.5 .4 . Co nfigure Re so urce Ove rco m m it m e nt

OpenStack supports overcommitting of CPU and memory resources on compute nodes.

Overcommitting is a technique of allocating more virtualized CPUs and/or memory than there are physical resources.

Important

Overcommitting increases the amount of instances you are able to run, but reduces instance performance.

CPU and memory overcommit settings are represented as a ratio. OpenStack uses the following ratios by default:

Default CPU overcommit ratio - 16

Default memory overcommit ratio - 1.5

These default settings have the following implications:

The default CPU overcommit ratio of 16 means that up to 16 virtual cores can be assigned to a node for each physical core.

The default memory overcommit ratio of 1.5 means that instances can be assigned to a physical node if the total instance memory usage is less than 1.5 times the amount of physical memory available.

Use the cpu_al l o cati o n_rati o and ram_al l o cati o n_rati o directives in

/etc/no va/no va. co nf to change these default settings.

8 .3.5 .5 . Re se rve Ho st Re so urce s

You can reserve host memory and disk resources as always available to OpenStack. To prevent a

14 4

⁠Chapt er 8 . O penSt ack Comput e Service Inst allat ion

given amount of memory and disk resources from being considered as available to be allocated for usage by virtual machines, edit the following directives in /etc/no va/no va. co nf:

reserved _ho st_memo ry_mb - Defaults to 512MB.

reserved _ho st_d i sk_mb - Defaults to 0MB.

8 .3.5 .6 . Co nfigure Co m put e Ne t wo rking

8.3.5.6 .1. Co mp u t e Net wo rkin g O verview

Unlike Nova-only deployments, when OpenStack Networking is in use, the no va-netwo rk service

mu st not run. Instead all network related decisions are delegated to the OpenStack Networking

Service.

Therefore, it is very important that you refer to this guide when configuring networking, rather than relying on Nova networking documentation or past experience with Nova networking. In particular, using CLI tools like no va-manag e and no va to manage networks or IP addressing, including both fixed and floating IPs, is not supported with OpenStack Networking.

Important

It is strongly recommended that you uninstall no va-netwo rk and reboot any physical nodes that were running no va-netwo rk before using these nodes to run OpenStack Network.

Problems can arise from inadvertently running the no va-netwo rk process while using

OpenStack Networking service; for example, a previously running no va-netwo rk could push down stale firewall rules.

8.3.5.6 .2. Up d at e t h e Co mp u t e Co n f ig u rat io n

Each time a Compute instance is provisioned or deprovisioned, the service communicates with

OpenStack Networking through its API. To facilitate this connection, it is necessary to configure each

Compute node with the connection and authentication details outlined in this procedure.

These steps must be performed on each Compute node while logged in as the ro o t user.

Pro ced u re 8.9 . Up d at in g t h e co n n ect io n an d au t h en t icat io n set t in g s o f Co mp u t e n o d es

1. Modify the netwo rk_api _cl ass configuration key to indicate that the OpenStack

Networking service is in use.

# o penstack-co nfi g --set /etc/no va/no va. co nf \

D EFAULT netwo rk_api _cl ass no va. netwo rk. neutro nv2. api . AP I

2. Set the value of the neutro n_url configuration key to point to the endpoint of the

OpenStack Networking API.

# o penstack-co nfi g --set /etc/no va/no va. co nf \

D EFAULT neutro n_url http: //IP: 9 6 9 6 /

Replace IP with the IP address or host name of the server hosting the API of the OpenStack

Networking service.

14 5

Deploying O penSt ack: Learning Environment s (Manual Set up)

3. Set the value of the neutro n_ad mi n_tenant_name configuration key to the name of the tenant used by the OpenStack Networking service. Examples in this guide use services.

# o penstack-co nfi g --set /etc/no va/no va. co nf \

D EFAULT neutro n_ad mi n_tenant_name services

4. Set the value of the neutro n_ad mi n_username configuration key to the name of the administrative user for the OpenStack Networking service. Examples in this guide use neutron.

# o penstack-co nfi g --set /etc/no va/no va. co nf \

D EFAULT neutro n_ad mi n_username neutron

5. Set the value of the neutro n_ad mi n_passwo rd configuration key to the password associated with the administrative user for the OpenStack Networking service.

# o penstack-co nfi g --set /etc/no va/no va. co nf \

D EFAULT neutro n_ad mi n_passwo rd PASSWORD

6. Set the value of the neutro n_ad mi n_auth_url configuration key to the URL associated with the Identity service endpoint.

# o penstack-co nfi g --set /etc/no va/no va. co nf \

D EFAULT neutro n_ad mi n_auth_url http: //IP: 35357/v2. 0

Replace IP with the IP address or host name of the Identity service endpoint.

7. Set the value of the securi ty_g ro up_api configuration key to neutro n.

# o penstack-co nfi g --set /etc/no va/no va. co nf \

D EFAULT securi ty_g ro up_api neutro n

This enables the use of OpenStack Networking security groups.

8. Set the value of the fi rewal l _d ri ver configuration key to

no va. vi rt. fi rewal l . No o pFi rewal l D ri ver.

# o penstack-co nfi g --set /etc/no va/no va. co nf \

D EFAULT fi rewal l _d ri ver no va. vi rt. fi rewal l . No o pFi rewal l D ri ver

This mu st be done when OpenStack Networking security groups are in use.

The configuration has been updated and the Compute service will use OpenStack Networking when it is next started.

8.3.5.6 .3. Co n f ig u re t h e L2 Ag en t

Each compute node must run an instance of the Layer 2 (L2) agent appropriate to the networking plug-in that is in use.

Section 7.7.1, “ Configure the Open vSwitch Plug-in Agent”

Section 7.7.2, “ Configure the Linux Bridge Plug-in Agent”

8.3.5.6 .4 . Co n f ig u re Virt u al In t erf ace Plu g g in g

14 6

⁠Chapt er 8 . O penSt ack Comput e Service Inst allat ion

When no va-co mpute creates an instance, it must 'plug' each of the vNIC associated with the instance into a OpenStack Networking controlled virtual switch. Compute must also inform the virtual switch of the OpenStack Networking port identifier associated with each vNIC.

A generic virtual interface driver, no va. vi rt. l i bvi rt. vi f. Li bvi rtG eneri cVIFD ri ver, is provided in Red Hat Enterprise Linux OpenStack Platform. This driver relies on OpenStack

Networking being able to return the type of virtual interface binding required. The following plug-ins support this operation:

Linux Bridge

Open vSwitch

NEC

BigSwitch

CloudBase Hyper-V

Brocade

To use the generic driver, execute the o penstack-co nfi g command to set the value of the

vi f_d ri ver configuration key appropriately:

# o penstack-co nfi g --set /etc/no va/no va. co nf \

l i bvi rt vi f_d ri ver \

no va. vi rt. l i bvi rt. vi f. Li bvi rtG eneri cVIFD ri ver

Important

Considerations for Open vSwitch and Linux Bridge deployments:

If running Open vSwitch with security groups enabled, use the Open vSwitch specific driver, no va. vi rt. l i bvi rt. vi f. Li bvi rtHybri d O VSBri d g eD ri ver, instead of the generic driver.

For Linux Bridge environments, you must add the following to the

/etc/l i bvi rt/q emu. co nf file to ensure that the virtual machine launches properly: user = "root" group = "root" cgroup_device_acl = [

"/dev/null", "/dev/full", "/dev/zero",

"/dev/random", "/dev/urandom",

"/dev/ptmx", "/dev/kvm", "/dev/kqemu",

"/dev/rtc", "/dev/hpet", "/dev/net/tun",

]

8 .3.5 .7 . Co nfigure t he Fire wall t o Allo w Co m put e Se rvice T raffic

Connections to virtual machine consoles, whether direct or through the proxy, are received on ports

59 0 0 to 59 9 9 .

14 7

Deploying O penSt ack: Learning Environment s (Manual Set up)

To allow this, the firewall on the service node must be configured to allow network traffic on these ports. Log in as the ro o t user to the server hosting the Compute service and perform the following procedure:

Pro ced u re 8.10. Co n f ig u rin g t h e f irewall t o allo w Co mp u t e Service t raf f ic

1. Open the /etc/sysco nfi g /i ptabl es file in a text editor.

2. Add an INPUT rule allowing TCP traffic on ports in the ranges 59 0 0 to 59 9 9 by adding the following line to the file.

-A INPUT -p tcp -m multiport --dports 5900:5999 -j ACCEPT

The new rule must appear before any INPUT rules that REJECT traffic.

3. Save the changes to the /etc/sysco nfi g /i ptabl es file.

4. Restart the i ptabl es service to ensure that the change takes effect.

# servi ce i ptabl es restart

The firewall is now configured to allow incoming connections to the Compute services. Repeat this process for each compute node.

8.3.6. Populat e t he Comput e Service Dat abase

You can populate the Compute Service database after you have successfully configured the

Compute Service database connection string (refer to Section 8.3.5.2, “ Configure the Compute

Service Database Connection” ).

Pro ced u re 8.11. Po p u lat in g t h e Co mp u t e Service d at ab ase

1. Log in to a system hosting an instance of the o penstack-no va-co nd ucto r service.

2. Use the su command to switch to the no va user.

# su no va -s /bi n/sh

3. Run the no va-manag e d b sync command to initialize and populate the database identified in /etc/no va/no va. co nf.

$ no va-manag e d b sync

The Compute service database has been initialized and populated.

8.3.7. Launch t he Comput e Services

14 8

Important

This procedure only needs to be followed once to initialize and populate the database. You do not need to perform these steps again when adding additional systems hosting Compute services.

⁠Chapt er 8 . O penSt ack Comput e Service Inst allat ion

Pro ced u re 8.12. Lau n ch in g Co mp u t e services

1. St art in g t h e Messag e Bu s Service

Libvirt requires that the messag ebus service be enabled and running.

a. Use the servi ce command to start the messag ebus service.

# servi ce messag ebus start b. Use the chkco nfi g command to enable the messag ebus service permanently.

# chkco nfi g messag ebus o n

2. St art in g t h e Lib virt d Service

The Compute service requires that the l i bvi rtd service be enabled and running.

a. Use the servi ce command to start the l i bvi rtd service.

# servi ce l i bvi rtd start b. Use the chkco nfi g command to enable the l i bvi rtd service permanently.

# chkco nfi g l i bvi rtd o n

3. St art in g t h e API Service

Start the API service on each system that will be hosting an instance of it. Note that each API instance should either have its own endpoint defined in the Identity service database or be pointed to by a load balancer that is acting as the endpoint.

a. Use the servi ce command to start the o penstack-no va-api service.

# servi ce o penstack-no va-api start b. Use the chkco nfi g command to enable the o penstack-no va-api service permanently.

# chkco nfi g o penstack-no va-api o n

4. St art in g t h e Sch ed u ler

Start the scheduler on each system that will be hosting an instance of it.

a. Use the servi ce command to start the o penstack-no va-sched ul er service.

# servi ce o penstack-no va-sched ul er start b. Use the chkco nfi g command to enable the o penstack-no va-sched ul er service permanently.

# chkco nfi g o penstack-no va-sched ul er o n

14 9

Deploying O penSt ack: Learning Environment s (Manual Set up)

5. St art in g t h e Co n d u ct o r

The conductor is intended to minimize or eliminate the need for Compute nodes to access the database directly. Compute nodes instead communicate with the conductor through a message broker and the conductor handles database access.

Start the conductor on each system that is intended to host an instance of it. Note that it is recommended that this service is not run on each and every Compute node as this eliminates the security benefits of restricting direct database access from the Compute nodes.

a. Use the servi ce command to start the o penstack-no va-co nd ucto r service.

# servi ce o penstack-no va-co nd ucto r start b. Use the chkco nfi g command to enable the o penstack-no va-co nd ucto r service permanently.

# chkco nfi g o penstack-no va-co nd ucto r o n

6. St art in g t h e Co mp u t e Service

Start the Compute service on every system that is intended to host virtual machine instances.

a. Use the servi ce command to start the o penstack-no va-co mpute service.

# servi ce o penstack-no va-co mpute start b. Use the chkco nfi g command to enable the o penstack-no va-co mpute service permanently.

# chkco nfi g o penstack-no va-co mpute o n

7. St art in g O p t io n al Services

Depending on environment configuration you may also need to start these services:

o penstack-no va-cert

The X509 certificate service, required if you intend to use the EC2 API to the

Compute service.

Note

If you intend to use the EC2 API to the Compute service, you need to set the options in the no va. co nf configuration file. For more information, see

Configuring the EC2 API section in the Red Hat Enterprise Linux OpenStack

Platform Configuration Reference Guide. This document is available from the following link: https://access.redhat.com/site/documentation/en-

US/Red_Hat_Enterprise_Linux_OpenStack_Platform

o penstack-no va-netwo rk

150

⁠Chapt er 8 . O penSt ack Comput e Service Inst allat ion

The Nova networking service. Note that you mu st not start this service if you have installed and configured, or intend to install and configure, OpenStack Networking.

o penstack-no va-o bjectsto re

The Nova object storage service. It is recommended that the OpenStack Object

Storage service (Swift) is used for new deployments.

The Compute services have been started and are ready to accept virtual machine instance requests.

151

Deploying O penSt ack: Learning Environment s (Manual Set up)

Chapter 9. OpenStack Orchestration Installation

9.1. Inst all t he Orchest rat ion Service Packages

The OpenStack Orchestration service requires the following packages:

openstack-heat-api

Provides the OpenStack-native REST API to the heat Engine.

openstack-heat-api-cfn

Provides the AWS CloudFormation-compatible API to the heat Engine.

openstack-heat-common

Provides components common to all heat services.

openstack-heat-engine

Provides the OpenStack API for launching templates and submitting events back to the API.

openstack-heat-api-cloudwatch

Provides the AWS CloudWatch-compatible API to the heat Engine.

heat-cfntools

Provides the tools required on heat-provisioned cloud instances.

python-heatclient

Provides a Python API and command-line script, both of which make up a client for the

OpenStack heat API.

openstack-utils

Provides supporting utilities to assist with a number of tasks including the editing of configuration files.

To install these required packages, run the following command as the ro o t user:

# yum i nstal l -y o penstack-heat-* pytho n-heatcl i ent o penstack-uti l s

9.2. Configure t he Orchest rat ion Service

To configure the Orchestration service, you will need to:

Configure a database for the Orchestration service.

Bind each Orchestration API service to a corresponding IP address.

Create and configure the Orchestration service Identity records.

Configure how Orchestration services authenticate with the Identity service.

The following sections describe each procedure in detail.

152

⁠Chapt er 9 . O penSt ack O rchest rat ion Inst allat ion

9.2.1. Configure t he Orchest rat ion Service Dat abase Connect ion

The OpenStack Orchestration service requires a database in order to work. The database connection settings used by this service are configured in /etc/heat/heat. co nf.

After using the MariaDB ro o t account to automatically create the required databases, the

Orchestration service will use its own MariaDB account (specifically, heat) to use those databases.

Note

In order to connect to the MariaDB database, create a database, and configure those database, you will need the password of the MariaDB database ro o t account.

The following procedure illustrates this in more detail:

Pro ced u re 9 .1. Co n f ig u rin g t h e O rch est rat io n service SQ L d at ab ase co n n ect io n

1. Connect to the database service as ro o t using the mysq l utility.

# mysq l -u ro o t -p

2. After logging in, create the heat database:

mysq l > C R EAT E D AT ABASE heat;

3. Create a database user named heat and grant that user access to the newly-created heat database:

mysq l > G R ANT ALL O N heat. * T O ' heat' @ ' %' ID ENT IFIED BY

' HEATPW' ;

mysq l > G R ANT ALL O N heat. * T O ' heat' @ ' l o cal ho st' ID ENT IFIED BY

' HEATPW' ;

Replace HEATPW with a secure password that the heat user should use to authenticate to the database server.

4. Flush the database privileges to ensure that they take effect immediately:

mysq l > FLUSH P R IVILEG ES;

5. Exit the mysq l utility:

mysq l > q ui t

6. Update the database connection string used by heat with the HEATPW used earlier:

# o penstack-co nfi g --set /etc/heat/heat. co nf \

D EFAULT sq l _co nnecti o n mysq l : //heat: HEATPW@ MARIADBHOST/heat

Where:

HEATPW is the password set earlier for the heat account.

153

Deploying O penSt ack: Learning Environment s (Manual Set up)

MARIADBHOST is the IP address or hostname of the MariaDB database server

(l o cal ho st if it is on the same host).

7. As the heat user, sync the database using the h eat - man ag e utility:

# runuser -s /bi n/sh heat -c "heat-manag e d b_sync"

9.2.2. Rest rict t he Bind Addresses of each Orchest rat ion API Service

After configuring the database, set the bi nd _ho st setting of each Orchestration API service. This setting controls which IP address a service should use for incoming connections.

The /etc/heat/heat. co nf configuration file contains a section for each Orchestration API service. the bi nd _ho st should be set in each one, as in:

# o penstack-co nfi g --set /etc/heat/heat. co nf

heat_api bi nd _ho st IP

# o penstack-co nfi g --set /etc/heat/heat. co nf

heat_api _cfn bi nd _ho st IP

# o penstack-co nfi g --set /etc/heat/heat. co nf

heat_api _cl o ud watch bi nd _ho st IP

Replace each IP with the address that the corresponding API should use.

9.2.3. Creat e t he Orchest rat ion Service Ident it y Records

In this procedure, you will:

1. Create the heat user, who has the ad mi n role in the servi ces tenant.

2. Create the heat service entry and assign it an endpoint.

In order to proceed, you should have already performed the following (through the Identity service):

1. Created an Administrator role named ad mi n (refer to Section 3.7, “ Create an Administrator

2. Created the servi ces tenant (refer to

service users. For more information, refer to Section 3.9, “ Create the Services Tenant” .

for instructions)

Note

The Deploying OpenStack: Learning Environments (Manual Set Up) guide uses one tenant for all

Pro ced u re 9 .2. Creat in g Id en t it y reco rd s f o r t h e O rch est rat io n service

154

⁠Chapt er 9 . O penSt ack O rchest rat ion Inst allat ion

1. Set up the shell to access Keystone as the ad mi n user:

# so urce ~ /keysto nerc_ad mi n

2. Create a heat user in keysto ne:

# keysto ne user-create \

--name= heat \

--pass= SERVICE_PASSWORD \

Replace SERVICE_PASSWORD with the password the Orchestration service should use when authenticating with the Identity service.

3. Establish the relationship between the Orchestration service, the servi ces tenant, and

ad mi n role:

# keysto ne user-ro l e-ad d --user heat \

--ro l e ad mi n \

--tenant servi ces \

4. Create Identity service entries for Orchestration and Cloud Formation:

# keysto ne servi ce-create --name heat \

--type o rchestrati o n

# keysto ne servi ce-create --name heat-cfn \

--type cl o ud fo rmati o n

Once the heat and heat-cfn services are created, note their respective IDs. These will be used later.

5. Create service endpoint entries for both heat and heat-cfn services:

# keysto ne end po i nt-create \

--servi ce heat-cfn \

--publ i curl "HEAT_CFN_IP: 80 0 0 /v1" \

--ad mi nurl "HEAT_CFN_IP: 80 0 0 /v1" \

--i nternal url "HEAT_CFN_IP: 80 0 0 /v1"

# keysto ne end po i nt-create \

--servi ce heat \

--publ i curl "HEAT_IP: 80 0 4 /v1/%(tenant_i d )s" \

--ad mi nurl "HEAT_IP: 80 0 4 /v1/%(tenant_i d )s" \

--i nternal url "HEAT_IP: 80 0 4 /v1/%(tenant_i d )s"

Where:

HEAT_CFN_IP is the IP or host name of the system hosting the heat-cfn service.

HEAT_IP is the IP or host name of the system hosting the heat service.

155

Deploying O penSt ack: Learning Environment s (Manual Set up)

Important

Include the http: // prefix for HEAT_CFN_IP and HEAT_IP values.

9 .2 .3.1 . Cre at e t he Re quire d Ide nt it y Do m ain fo r t he Orche st rat io n Se rvice

As of Red Hat Enterprise Linux OpenStack Platform 5, the Orchestration service now requires its own

Identity domain. The use of Identity domains provides a framework through which users can be created, associated with credentials deployed inside instances owned by heat stacks.

The use of a separate domain allows for separation between the instances and the user deploying the stack. This, in turn, allows regular users without administrative rights to deploy heat stacks that require such credentials.

Note

At present, the creation of Identity service domains is only supported on Red Hat Enterprise

Linux 7.2. As such, if you wish to set up the heat domain for an OpenStack service installed on Red Hat Enterprise Linux 6.6, you will have to do so from a Red Hat Enterprise Linux 7.2

host. From there, you can specify the Red Hat Enterprise Linux 6.6 host on which to set up the domain.

Pro ced u re 9 .3. Creat in g an Id en t it y service d o main f o r t h e O rch est rat io n service

1. Obtain the administrative token used by the Identity service. This token is the value of the

ad mi n_to ken configuration key in the /etc/keysto ne/keysto ne. co nf file of the Identity server:

# cat /etc/keysto ne/keysto ne. co nf | g rep ad mi n_to ken

admin_token = 0292d404a88c4f269383ff28a3839ab4

The administrative token (in this example, 0292d404a88c4f269383ff28a3839ab4) will be used later to perform all actions requiring administrative credentials.

2. Install the python-openstackclient package on the Red Hat Enterprise Linux 7.2 host you will use to create and configure the domain.

# yum i nstal l pytho n-o penstackcl i ent

Run the rest of the steps in this procedure from that Red Hat Enterprise Linux 7.2 host.

3. Create the heat domain.

# o penstack --o s-to ken ADMIN_TOKEN --o s-url = IDENTITY_IP: 50 0 0 /v3 \

--o s-i d enti ty-api -versi o n= 3 d o mai n create heat \

--d escri pti o n "O wns users and pro jects created by heat"

Where:

ADMIN_TOKEN is the administrative token obtained earlier

(0292d404a88c4f269383ff28a3839ab4 from the first step's example).

156

⁠Chapt er 9 . O penSt ack O rchest rat ion Inst allat ion

IDENTITY_IP is the IP or host name of the Identity server. The IDENTITY_IP can be a Red

Hat Enterprise Linux 6.6 host, even if you are running the command from a Red Hat

Enterprise Linux 7.2 host.

This command should return the domain ID of the newly created heat domain. This ID

(HEAT_DOMAIN_ID) will be used in the next step.

4. Create a user named heat_d o mai n_ad mi n that can have administrative rights within the

heat domain:

# o penstack --o s-to ken ADMIN_TOKEN --o s-url = IDENTITY_IP: 50 0 0 /v3 \

--o s-i d enti ty-api -versi o n= 3 user create heat_d o mai n_ad mi n \

--passwo rd DOMAIN_PASSWORD \

--d o mai n HEAT_DOMAIN_ID

--d escri pti o n "Manag es users and pro jects created by heat"

Replace DOMAIN_PASSWORD with a secure password for this user. This command should return a user ID (DOMAIN_ADMIN_ID), which will be used in the next step.

5. Grant the user created in the previous step administrative rights within the heat domain:

# o penstack --o s-to ken ADMIN_TOKEN --o s-url = IDENTITY_IP: 50 0 0 /v3 \

--o s-i d enti ty-api -versi o n= 3 ro l e ad d --user DOMAIN_ADMIN_ID \

--d o mai n HEAT_DOMAIN_ID ad mi n

After setting up the heat domain and user, you can now configure the Orchestration service to use them. To do so, run the following commands on the server hosting the heat services:

# o penstack-co nfi g --set /etc/heat/heat. co nf \

D EFAULT stack_d o mai n_ad mi n_passwo rd DOMAIN_PASSWORD

# o penstack-co nfi g --set /etc/heat/heat. co nf \

D EFAULT stack_d o mai n_ad mi n heat_d o mai n_ad mi n

# o penstack-co nfi g --set /etc/heat/heat. co nf \

D EFAULT stack_user_d o mai n HEAT_DOMAIN_ID

9.2.4 . Configure Orchest rat ion Service Aut hent icat ion

After creating and configuring the required Orchestration service users and roles (namely, Identity records), configure the Orchestration service to authenticate with the Identity service. Doing so involves setting the required Identity tokens for the heat-api , heat-api -cfn, and heat-api -

cl o ud watch services. These services use the token settings configured in /etc/heat/heat. co nf.

Pro ced u re 9 .4 . Co n f ig u rin g t h e O rch est rat io n service t o au t h en t icat e t h ro u g h t h e

Id en t it y service

1. Set the Orchestration services to authenticate as the correct tenant:

# o penstack-co nfi g --set /etc/heat/heat. co nf \

keysto ne_authto ken ad mi n_tenant_name services

157

Deploying O penSt ack: Learning Environment s (Manual Set up)

Where services is the name of the tenant created for the use of the Orchestration service.

Examples in this guide use services.

2. Set the Orchestration services to authenticate using the heat administration user account:

# o penstack-co nfi g --set /etc/heat/heat. co nf \

keysto ne_authto ken ad mi n_user heat

3. Set the Orchestration services to use the correct heat administration user account password:

# o penstack-co nfi g --set /etc/heat/heat. co nf \

keysto ne_authto ken ad mi n_passwo rd SERVICE_PASSWORD

Where SERVICE_PASSWORD is the password set during the creation of the heat user.

4. Set the correct Identity service host that the Orchestration services should use:

# o penstack-co nfi g --set /etc/heat/heat. co nf \

keysto ne_authto ken servi ce_ho st KEYSTONE_HOST

# o penstack-co nfi g --set /etc/heat/heat. co nf \

keysto ne_authto ken auth_ho st KEYSTONE_HOST

# o penstack-co nfi g --set /etc/heat/heat. co nf \

keysto ne_authto ken auth_uri http: //KEYSTONE_HOST: 35357/v2. 0 \

# o penstack-co nfi g --set /etc/heat/heat. co nf \

keysto ne_authto ken keysto ne_ec2_uri

http: //KEYSTONE_HOST: 35357/v2. 0

Where KEYSTONE_HOST is the hostname of the Identity service. If the Identity service is hosted on the same system, use 127. 0 . 0 . 1.

5. Configure the heat-api -cfn and heat-api -cl o ud watch service hostnames to which

VMs should connect.

# o penstack-co nfi g --set /etc/heat/heat. co nf \

D EFAULT heat_metad ata_server_url HEAT_CFN_HOST: 80 0 0

# o penstack-co nfi g --set /etc/heat/heat. co nf \

D EFAULT heat_wai tco nd i ti o n_server_url

HEAT_CFN_HOST: 80 0 0 /v1/wai tco nd i ti o n

# o penstack-co nfi g --set /etc/heat/heat. co nf \

D EFAULT heat_watch_server_url HEAT_CLOUDWATCH_HOST: 80 0 3

Where:

HEAT_CFN_HOST is the IP or hostname of the system hosting the heat-api -cfn service.

HEAT_CLOUDWATCH_HOST is the IP or hostname of the system hosting the heat-api -

cl o ud watch service.

158

⁠Chapt er 9 . O penSt ack O rchest rat ion Inst allat ion

Important

Even if all services are hosted on the same system, do not use 127. 0 . 0 . 1 for either service hostname. This IP address would refer to the local host of each VM, and would therefore prevent the VM from reaching the actual service.

6. Application templates use wait conditions and signaling for orchestration. You will need to define the Identity role for users that will receive progress data. By default, this role is

heat_stack_user.

# o penstack-co nfi g --set /etc/heat/heat. co nf \

D EFAULT heat_stack_user_ro l e heat_stack_user

9.2.5. Configure Rabbit MQ Message Broker Set t ings for t he Orchest rat ion

Service

This section assumes that you have already configured a RabbitMQ message broker. For more information, refer to:

Section 2.4.2, “ Install and Configure the RabbitMQ Message Broker”

Section 2.4.1, “ Configure the Firewall for Message Broker Traffic”

Section 2.4.2.1, “ Launch the RabbitMQ Message Broker”

Pro ced u re 9 .5. Co n f ig u rin g t h e O rch est rat io n service t o u se t h e Rab b it MQ messag e b ro ker

1. Log in as ro o t to the Orchestration controller node.

2. In /etc/heat/heat. co nf of that system, set RabbitMQ as the RPC back end.

# o penstack-co nfi g --set /etc/heat/heat. co nf \

D EFAULT rpc_backend heat. o penstack. co mmo n. rpc. i mpl _ko mbu

3. Set the Orchestration service to connect to the RabbitMQ host:

# o penstack-co nfi g --set /etc/heat/heat. co nf \

D EFAULT rabbi t_ho st RABBITMQ_HOST

Replace RABBITMQ_HOST with the IP address or host name of the message broker.

4. Set the message broker port to 56 72:

# o penstack-co nfi g --set /etc/heat/heat. co nf \

D EFAULT rabbi t_po rt 56 72

159

Deploying O penSt ack: Learning Environment s (Manual Set up)

5. Set the RabbitMQ username and password created for the Orchestration service:

# o penstack-co nfi g --set /etc/heat/heat. co nf \

D EFAULT rabbi t_useri d heat

# o penstack-co nfi g --set /etc/heat/heat. co nf \

D EFAULT rabbi t_passwo rd HEAT_PASS

Where heat and HEAT_PASS are the RabbitMQ username and password created for

Orchestration (in

Section 2.4.2, “ Install and Configure the RabbitMQ Message Broker” ).

6. In Section 2.4.2.1, “ Launch the RabbitMQ Message Broker” , we gave the heat user read/write

permissions to all resources -- specifically, through the virtual host /. Configure the

Orchestration service to connect to this virtual host:

# o penstack-co nfi g --set /etc/heat/heat. co nf \

D EFAULT rabbi t_vi rtual _ho st /

9 .2 .5 .1 . Enable SSL Co m m unicat io n Be t we e n Orche st rat io n Se rvice and Me ssage

Bro ke r

If you enabled SSL on the message broker, you will also have to configure the Orchestration service

accordingly. For this, you will need the exported client certificates and key file. See Section 2.4.2.3,

“ Export an SSL Certificate for Clients” for instructions on how to export these files.

Once you have the necessary certificates and key, run the following commands to enable SSL communication with the message broker:

# o penstack-co nfi g --set /etc/heat/heat. co nf \

D EFAULT rabbi t_use_ssl T rue

# o penstack-co nfi g --set /etc/heat/heat. co nf \

D EFAULT ko mbu_ssl _certfi l e /path/to/client.crt

# o penstack-co nfi g --set /etc/heat/heat. co nf \

D EFAULT ko mbu_ssl _keyfi l e /path/to/clientkeyfile.key

Where:

/path/to/client.crt is the absolute path to the exported client certificate.

/path/to/clientkeyfile.key is the absolute path to the exported client key file.

If your certificates were signed by a third-party Certificate Authority (CA), then you will also need to run the following command:

# o penstack-co nfi g --set /etc/heat/heat. co nf \

D EFAULT ko mbu_ssl _ca_certs /path/to/ca.crt

Replace /path/to/ca.crt with the absolute path to the CA file provided by the third-party CA (see

Section 2.4.2.2, “ Enable SSL on the RabbitMQ Message Broker”

for more information).

9.3. Launch t he Orchest rat ion Service

Once the required settings are configured, you can now launch the services that consist of the

Orchestration service:

160

⁠Chapt er 9 . O penSt ack O rchest rat ion Inst allat ion o penstack-heat-api o penstack-heat-api -cfn o penstack-heat-api -cl o ud watch o penstack-heat-eng i ne

To do so for each service:

# servi ce SERVICENAME start

Then, configure each service to launch automatically at boot:

# chkco nfi g SERVICENAME o n

Replace SERVICENAME with the corresponding name of each Orchestration service.

9.4 . Deploy a St ack Using Orchest rat ion T emplat es

The Orchestration engine uses templates (defined as . templ ate files) to launch instances, IPs, volumes, or other types of stacks. The h eat utility is a command-line interface that allows you to create, configure, and launch stacks.

Note

The openstack-heat-templates package provides sample templates that you can use to test core

Orchestration features. It also contains template-related scripts and conversion tools. To install this package, run the following command as ro o t:

# yum i nstal l -y o penstack-heat-templ ates

Some Orchestration templates launch instances that require access to o penstack-heat-api -cfn.

Such instances will need to be able to communicate with the o penstack-heat-api -cl o ud watch and o penstack-heat-api -cfn services. The IPs and ports used by these services are the values set in the /etc/heat/heat. co nf as heat_metad ata_server_url and

heat_watch_server_url (refer to

Section 9.2.4, “ Configure Orchestration Service Authentication”

for details).

To allow access to these services, you may need to configure your firewall accordingly. Specifically, you will need to open the ports used by the o penstack-heat-api -cl o ud watch (8003) and

o penstack-heat-api -cfn (8000). To do so, perform the following tasks as ro o t:

Pro ced u re 9 .6 . Co n f ig u rin g t h e f irewall f o r O rch est rat io n services t raf f ic

1. Open the /etc/sysco nfi g /i ptabl es file in a text editor.

2. Configure the firewall to allow TCP traffic on ports 80 0 3 and 80 0 0 . To do so, add the following INP UT rules to /etc/sysco nfi g /i ptabl es:

-A INPUT -i BR -p tcp --dport 8003 -j ACCEPT

161

Deploying O penSt ack: Learning Environment s (Manual Set up)

-A INPUT -i BR -p tcp --dport 8000 -j ACCEPT

Replace BR with the interface of the bridge used by your instances (as in, the instances launched from Orchestration templates).

Note

Do not include the -i BR parameter in the INP UT rules if: you are not using no va-netwo rk, or the Orchestration service and no va-co mpute are not hosted on the same server.

3. Save the changes to the /etc/sysco nfi g /i ptabl es file.

4. Restart the i ptabl es service for the firewall changes to take effect.

# servi ce i ptabl es restart

To use h eat to launch an application:

# heat stack-create STACKNAME \

--templ ate-fi l e= PATH_TEMPLATE \

--parameters= "PARAMETERS"

Where:

STACKNAME is the name you wish to assign to the stack. This name will appear when you run the

heat stack-l i st command.

PATH_TEMPLATE is the path to your . templ ate file.

PARAMETERS is a semicolon-delimeted list of stack creation parameters you wish to use.

Supported parameters are defined in the template file itself.

For example, to launch a stack named myappl i cati o n using the template file

/ho me/user/myappl i cati o n. templ ate with specific database login parameters:

# heat stack-create myappl i cati o n \

--templ ate-fi l e= /ho me/user/myappl i cati o n. templ ate \

--parameters= "D BUsername= ro o t;D BP asswo rd = P ASSWO R D "

9.5. Int egrat e T elemet ry and Orchest rat ion Services

The Orchestration service can also use the Telemetry service (and its alarms) in monitoring the resource usage of stacks created using the heat stack-create command. To enable this, the

Orchestration service must be installed and configured accordingly (see Section 12.2, “ Overview of

Telemetry Service Deployment” for more information) .

Telemetry service alarms are used by the autoscaling feature. This feature allows the Orchestration service to automatically create stacks when the usage of a specific resource reaches a certain level.

To allow Orchestration to use Telemetry alarms, the following line must be uncommented in/added to the reso urce_reg i stry section of /etc/heat/envi ro nment. d /d efaul t. yaml :

162

⁠Chapt er 9 . O penSt ack O rchest rat ion Inst allat ion

"AWS::CloudWatch::Alarm":

"file:///etc/heat/templates/AWS_CloudWatch_Alarm.yaml"

163

Deploying O penSt ack: Learning Environment s (Manual Set up)

Chapter 10. Dashboard Installation

10.1. Dashboard Service Requirement s

The system hosting the dashboard service must have:

The following already installed: httpd , mo d _wsg i , and mo d _ssl (for security purposes).

A connection to the Identity service, as well as to the other OpenStack API services (OpenStack

Compute, Block Storage, Object Storage, Image, and Networking services).

The installer must know the URL of the Identity service endpoint.

Note

To install mo d _wsg i , httpd , and mo d _ssl , execute as root:

# yum i nstal l -y mo d _wsg i httpd mo d _ssl

10.2. Inst all t he Dashboard Packages

The steps in this procedure install the packages required by the OpenStack dashboard service.

Note

The dashboard service uses a configurable backend session store. This installation uses memcached as the session store. However, other options do exist. For more details, refer to

Session Storage Options.

The only required package is:

openstack-dashboard

Provides the OpenStack dashboard service.

If using memcached, the following must also be installed:

memcached

Memory-object caching system, which speeds up dynamic web applications by alleviating database load.

python-memcached

Python interface to the memcached daemon.

This installation must be performed while logged in as the ro o t user.

1. Install the memcached object caching system:

# yum i nstal l -y memcached pytho n-memcached

164

⁠Chapt er 1 0 . Dashboard Inst allat ion

2. Install the dashboard package:

# yum i nstal l -y o penstack-d ashbo ard

The OpenStack dashboard service is installed and ready to be configured.

10.3. Launch t he Apache Web Service

Because the dashboard is a Django (Python) web application, it is hosted by the httpd service. To start the service, execute the following commands as the ro o t user:

1. To start the servi ce, execute on the command line:

# servi ce httpd start

2. To ensure that the httpd service starts automatically in the future, execute:

# chkco nfi g httpd o n

3. You can confirm that httpd is running by executing:

# servi ce --status-al l | g rep httpd

10.4 . Configure t he Dashboard

10.4 .1. Configure Connect ions and Logging

Before users connect to the dashboard for the first time, the following must be configured in the

/etc/o penstack-d ashbo ard /l o cal _setti ng s file (sample files are available in the

Configuration Reference Guide at https://access.redhat.com/site/documentation/en-

US/Red_Hat_Enterprise_Linux_OpenStack_Platform ):

Note

Update the following changes as a root user.

1. Allowed hosts - Set the ALLO WED _HO ST S parameter with a comma-seperated list of host/domain names that the application can serve. For example:

ALLOWED_HOSTS = ['horizon.example.com', 'localhost',

'192.168.20.254', ]

2. Cache Backend - As the ro o t user, update the C AC HES settings with the memcached values:

SESSION_ENGINE = 'django.contrib.sessions.backends.cache'

CACHES = {

'default': {

'BACKEND' :

165

Deploying O penSt ack: Learning Environment s (Manual Set up)

'django.core.cache.backends.memcached.MemcachedCache',

'LOCATION' : 'memcacheURL:port',

}

Where:

memcacheUR L is the host on which memcache was installed

po rt is the value from the P O R T parameter in the /etc/sysco nfi g /memcached file.

3. Dashboard Host - Specify the host URL for your OpenStack Identity service endpoint. For example:

O P ENST AC K_KEY ST O NE_UR L= "127. 0 . 0 . 1"

4. Time Z one - To change the dashboard's timezone, update the following (the time zone can also be changed using the dashboard GUI):

T IME_ZO NE= "UT C "

5. To ensure the configuration changes take effect, restart the Apache web server.

Note

The HO R IZO N_C O NFIG dictionary contains all the settings for the Dashboard. Whether or not a service is in the dashboard depends on the Service Catalog configuration in the Identity service. For a full listing, refer to http://docs.openstack.org/developer/horizon/topics/settings.html

(Horizon Settings and

Configuration).

Note

It is recommended that you use d jang o -secure module to ensure that most of the best practices and modern browser protection mechanisms are enabled. For more infomation http://django-secure.readthedocs.org/en/latest/ (django-secure).

10.4 .2. Configure t he Dashboard t o Use HT T PS

Although the default installation uses a non-encrypted channel (HTTP), it is possible to enable SSL support for the OpenStack dashboard. Use the following steps for enable HTTPS (switch out the example domain 'openstack.example.com' for that of your current setup):

1. Edit the /etc/o penstack-d ashbo ard /l o cal _setti ng s file, and uncomment the following parameters:

SECURE_PROXY_SSL_HEADER = ('HTTP_X_FORWARDED_PROTOCOL', 'https')

CSRF_COOKIE_SECURE = True

SESSION_COOKIE_SECURE = True

The latter two settings instruct the browser to only send dashboard cookies over HTTPS

166

⁠Chapt er 1 0 . Dashboard Inst allat ion

connections, ensuring that sessions will not work over HTTP.

2. Edit the /etc/httpd /co nf/httpd . co nf file, and add the following line:

NameVirtualHost *:443

3. Edit the /etc/httpd /co nf. d /o penstack-d ashbo ard . co nf file, and replace the 'Before' section with 'After':

Before:

WSGIDaemonProcess dashboard

WSGIProcessGroup dashboard

WSGISocketPrefix run/wsgi

WSGIScriptAlias /dashboard /usr/share/openstackdashboard/openstack_dashboard/wsgi/django.wsgi

Alias /static /usr/share/openstack-dashboard/static/

SetOutputFilter DEFLATE

# Make sure proxies donât deliver the wrong content

Header append Vary User-Agent env=!dont-vary

</IfModule>

Order allow,deny

Allow from all

</Directory>

ExpiresActive On

ExpiresDefault "access 6 month"

</IfModule>

SetOutputFilter DEFLATE

</IfModule>

Order allow,deny

Allow from all

</Directory>

RedirectMatch permanent ^/$ https://xxx.xxx.xxx.xxx:443/dashboard

After:

WSGIDaemonProcess dashboard

WSGIProcessGroup dashboard

WSGISocketPrefix run/wsgi

LoadModule ssl_module modules/mod_ssl.so

ServerName openstack.example.com

RedirectPermanent / https://openstack.example.com/

167

Deploying O penSt ack: Learning Environment s (Manual Set up)

</VirtualHost>

ServerName openstack.example.com

SSLEngine On

SSLCertificateFile /etc/httpd/SSL/openstack.example.com.crt

SSLCACertificateFile /etc/httpd/SSL/openstack.example.com.crt

SSLCertificateKeyFile /etc/httpd/SSL/openstack.example.com.key

SetEnvIf User-Agent ".*MSIE.*" nokeepalive ssl-unclean-shutdown

WSGIScriptAlias / /usr/share/openstackdashboard/openstack_dashboard/wsgi/django.wsgi

WSGIDaemonProcess horizon user=apache group=apache processes=3 threads=10

RedirectPermanent /dashboard https://openstack.example.com

Alias /static /usr/share/openstack-dashboard/static/

Order allow,deny

Allow from all

</Directory>

</VirtualHost>

ExpiresActive On

ExpiresDefault "access 6 month"

</IfModule>

SetOutputFilter DEFLATE

</IfModule>

Order allow,deny

Allow from all

</Directory>

RedirectMatch permanent ^/$ /dashboard/

In the 'After' configuration, Apache listens on port 443 and redirects all non-secured requests to the HTTPs protocol. The <Vi rtual Ho st *: 4 4 3> section defines the required options for this protocol, including private key, public key, and certificates.

4. As the ro o t user, restart Apache and memcached:

# servi ce httpd restart

# servi ce memcached restart

When using the HTTP version of the dashboard (through the browser), the user should be redirected to the HTTPs version of the page.

10.4 .3. Configure t he Dashboard t o Use Keyst one v3 Aut hent icat ion

In rare cases, when having many or all services enabled all at once, it may be required to include the following configuration settings for logging in to the dashboard, especially when using keystone v3 authentication.

168

⁠Chapt er 1 0 . Dashboard Inst allat ion

1. In /usr/share/openstack-dashboard/openstack_dashboard/settings.py add the following configuration:

DATABASES =

{

'default':

{

'ENGINE': 'django.db.backends.mysql',

'NAME': 'horizondb',

'USER': ' User Name' ,

'PASSWORD': ' P asswo rd ' ,

'HOST': 'localhost',

}

2. In the same file, change SESSION_ENGINE to:

SESSION_ENGINE = 'django.contrib.sessions.backends.cached_db'

3. Connect to the database service using the mysql command, replacing USER with the user name by which to connect. The USER must be a ro o t user (or at least as a user with the correct permission: create d b).

# mysq l -u USER -p

4. Create the Horizon database.

mysql > create database horizondb;

5. Exit the mysql client.

mysql > exit

6. Change to the openstack_dashboard directory and sync the database using:

# cd /usr/share/openstack-dashboard/openstack_dashboard

$ ./manage.py syncdb

You do not need to create a superuser, so answer 'n' to the question.

7. Restart Apache http server. For Red Hat Enterprise Linux:

#service httpd restart

10.4 .4 . Change dashboard's default role

By default, the dashboard service uses the Identity role named _member_ which is created automatically by Identity. This is adequate for regular users.

If you choose to create a different role and wish to set dashboard to use this role, you must create this role in the Identity service prior to using the dashboard, then configure dashboard to use it.

169

Deploying O penSt ack: Learning Environment s (Manual Set up)

1. Log in to the system on which your keysto nerc_ad mi n file resides and authenticate as the

Identity administrator:

# so urce ~/keystonerc_admin

2. Use the keysto ne ro l e-create command to create the new role:

# keysto ne ro l e-create --name NEW_ROLE

+----------+----------------------------------+

| Property | Value |

+----------+----------------------------------+

| id | 8261ac4eabcc4da4b01610dbad6c038a |

| name | NEW_ROLE |

+----------+----------------------------------+

Replace NEW_ROLE with the name that you wish to give to the role.

3. To configure the dashboard service to use a role other than the default _member_ role, change the value of the O P ENST AC K_KEY ST O NE_D EFAULT _R O LE configuration key, which is stored in:

/etc/o penstack-d ashbo ard /l o cal _setti ng s

4. Restart the httpd service for the change to take effect.

10.4 .5. Configure SELinux

SELinux is a security feature of Red Hat Enterprise Linux, which provides access control. Possible status values are Enforcing, Permissive, and Disabled. If SELinux is configured in 'Enforcing' mode, you must modify the SELinux policy to allow connections from the httpd service to the Identity server.

This is also recommended if SELinux is configured in 'Permissive' mode.

1. Use the g etenfo rce command to check the status of SELinux on the system:

# getenforce

2. If the resulting value is 'Enforcing' or 'Permissive', use the setsebo o l command as the ro o t user to allow httpd -Identity service connections:

# setsebool -P httpd_can_network_connect on

170

⁠Chapt er 1 0 . Dashboard Inst allat ion

Note

You can also view the status of SELinux using:

# sestatus

SELinux status: enabled

SELinuxfs mount: /selinux

Current mode: permissive

Mode from config file: enforcing

Policy version: 24

Policy from config file: targeted

For more information, refer to the Red Hat Enterprise Linux SELinux Users and Administrators

Guide at the following link: https://access.redhat.com/site/documentation/en-US/Red_Hat_Enterprise_Linux/

10.4 .6. Configure t he dashboard firewall

To allow users to connect to the dashboard, you must configure the system firewall to allow connections. The httpd service, and the dashboard, support both HTTP and HTTPS connections.

Note

To protect authentication credentials and other data, it is highly recommended that you only enable HTTPS connections.

Execute the following as the ro o t user:

Pro ced u re 10.1. Co n f ig u rin g t h e f irewall t o allo w d ash b o ard t raf f ic

1. Edit the /etc/sysco nfi g /i ptabl es configuration file:

Allow incoming connections using just HTTPS by adding this firewall rule to the file:

-A INPUT -p tcp --dport 443 -j ACCEPT

Allow incoming connections using both HTTP and HTTPS by adding this firewall rule to the file:

-A INPUT -p tcp -m multiport --dports 80,443 -j ACCEPT

2. Restart the iptables service for the changes to take effect.

# servi ce i ptabl es restart

171

Deploying O penSt ack: Learning Environment s (Manual Set up)

Important

These rules allow communication from all remote hosts to the system running the dashboard service on ports 80 or 443. For information regarding the creation of more restrictive firewall rules, refer to the Red Hat Enterprise Linux Security Guide at the following link: https://access.redhat.com/site/documentation/en-US/Red_Hat_Enterprise_Linux/

10.4 .7. Session St orage Opt ions

1 0 .4 .7 .1 . Co nfigure Lo cal Me m o ry Cache Se ssio n St o rage

Local memory storage is the quickest and easiest session backend to set up, because it has no external dependencies. However, it does have two significant drawbacks:

No shared storage across processes or workers.

No persistence after a process terminates.

The local memory backend is enabled as the default for the dashboard service solely because it has no dependencies. However, it is not recommended for production use, or even for serious development work.

To use local memory for storage, include the following in the /etc/o penstack-

d ashbo ard /l o cal _setti ng s file:

SESSION_ENGINE = 'django.contrib.sessions.backends.cache'

CACHES = {

'default': {

'BACKEND': 'django.core.cache.backends.locmem.LocMemCache'

}

1 0 .4 .7 .2 . Co nfigure Me m cache d Se ssio n St o rage

External caching using an application such as memcached offers persistence and shared storage, and can be very useful for small-scale deployment and/or development. The Dashboard installation process in this guide recommends the use of memcached for external caching (for configuration details, refer to Configuring Connections and Logging).

However, for distributed and high-availability scenarios, memcached has inherent problems which are beyond the scope of this documentation. Memcached is an extremely fast and efficient cache backend for cases where it fits the deployment need, but it’s not appropriate for all scenarios.

1 0 .4 .7 .3. Co nfigure Dat abase Se ssio n St o rage

Database-backed sessions are scalable (using an appropriate database strategy), persistent, and can be made high-concurrency and highly-available. The downside to this approach is that database-backed sessions are one of the slower session storages, and incur a high overhead under heavy usage. Proper configuration of your database deployment can also be a substantial undertaking and is far beyond the scope of this documentation.

172

⁠Chapt er 1 0 . Dashboard Inst allat ion

To enable database session storage, follow the below steps as the ro o t user to initialize the database and configure it for use:

1. Start the MariaDB command-line client, by executing:

# mysq l -u ro o t -p

2. Specify the MariaDB root user's password when prompted.

3. Create the d ash database:

mysq l > C R EAT E D AT ABASE d ash;

4. Create a MariaDB user for the newly-created dash database who has full control of the database.

mysq l > G R ANT ALL O N d ash. * T O ' d ash' @ ' %' ID ENT IFIED BY

' PASSWORD' ;

mysq l > G R ANT ALL O N d ash. * T O ' d ash' @ ' l o cal ho st' ID ENT IFIED BY

' PASSWORD' ;

Replace PASSWORD with a secure password for the new database user to authenticate with.

5. Enter quit at the mysq l > prompt to exit the MariaDB client.

6. In the /etc/o penstack-d ashbo ard /l o cal _setti ng s file, change the following options to refer to the new MariaDB database:

SESSION_ENGINE = 'django.contrib.sessions.backends.cached_db'

DATABASES = {

'default': {

# Database configuration here

'ENGINE': 'django.db.backends.mysql',

'NAME': 'dash',

'USER': 'dash',

'PASSWORD': 'PASSWORD',

'HOST': 'HOST',

'default-character-set': 'utf8'

}

Replace PASSWORD with the password of the d ash database user and replace HOST with the IP address or fully qualified domain name of the database server.

7. Populate the new database by executing:

# cd /usr/share/o penstack-d ashbo ard

# pytho n manag e. py syncd b

Note: You will be asked to create an admin account; this is not required.

As a result, the following should be displayed:

Installing custom SQL ...

173

Deploying O penSt ack: Learning Environment s (Manual Set up)

Installing indexes ...

DEBUG:django.db.backends:(0.008) CREATE INDEX

`django_session_c25c2c28` ON

`django_session` (`expire_date`);; args=()

No fixtures found.

8. Restart Apache to pick up the default site and symbolic link settings:

# servi ce httpd restart

9. Restart the o penstack-no va-api service to ensure the API server can connect to the dashboard and to avoid an error displayed in the dashboard.

# servi ce o penstack-no va-api restart

1 0 .4 .7 .4 . Co nfigure Cache d Dat abase Se ssio n St o rage

To mitigate the performance issues of database queries, Django’s cached _d b sessi o n backend can be used, which utilizes both the database and caching infrastructure to perform write-through caching and efficient retrieval.

Enable this hybrid setting by configuring both your database and cache as discussed above and then using:

SESSIO N_ENG INE = "d jang o . co ntri b. sessi o ns. backend s. cached _d b"

1 0 .4 .7 .5 . Co nfigure Co o kie s Se ssio n St o rage

The cookies-session backend avoids server load and scaling problems because it stores session data in a cookie, which is stored by the user’s browser. The backend uses a cryptographic signing technique, together with the SECRET_KEY, to ensure session data is not tampered with during transport (this is not the same as encryption, session data is still readable by an attacker).

Advantages:

Does not require additional dependencies or infrastructure overhead.

Scales indefinitely as long as the quantity of session data being stored fits into a normal cookie.

Disadvantages:

Places session data into storage on the user’s machine and transports it over the wire.

Limits the quantity of session data which can be stored.

Note

For a thorough discussion of the security implications of this session backend, please read the Django documentation on cookie-based sessions: https://docs.djangoproject.com/en/dev/topics/http/sessions/#s-using-cookie-based-sessions

174

⁠Chapt er 1 0 . Dashboard Inst allat ion

To enable cookie-session storage:

1. In the /etc/o penstack-d ashbo ard /l o cal _setti ng s file, set:

SESSIO N_ENG INE =

"d jang o . co ntri b. sessi o ns. backend s. si g ned _co o ki es"

2. Add a randomly-generated SEC R ET _KEY to the project by executing on the command line:

$ d jang o -ad mi n. py startpro ject

Note

The SEC R ET _KEY is a text string, which can be specified manually or automatically generated (as in this procedure). You will just need to ensure that the key is unique

(that is, does not match any other password on the machine).

10.5. Validat e Dashboard Inst allat ion

After the dashboard has been successfully installed and configured, you can access the user interface with your web browser. Replace HOSTNAME with the host name or IP address of the server on which you installed the Dashboard service:

HTTPS https://HOSTNAME/dashboard/

HTTP http://HOSTNAME/dashboard/

When prompted, log in using the credentials of your OpenStack user. For information on creating an

OpenStack user, refer to Section 3.8, “ Create a Regular User Account” .

175

Deploying O penSt ack: Learning Environment s (Manual Set up)

Fig u re 10.1. Dash b o ard Lo g in Screen

10.5.1. OpenSt ack Dashboard - Admin T ab

The Ad mi n tab provides an interface where the administrators can view usage and manage instances, volumes, flavors, images, projects, users, services, and quotas.

Note

The Ad mi n tab is only displayed in the main window if you have logged in as an administrator.

176

⁠Chapt er 1 0 . Dashboard Inst allat ion

Fig u re 10.2. Dash b o ard - Ad min T ab

You can access the following options available in the Ad mi n tab.

T ab le 10.1. Syst em Pan el

Paramet er Name

O vervi ew

R eso urce Usag e

Hypervi so rs

Ho st Ag g reg ates

Instances

Vo l umes

Fl avo rs

Imag es

Netwo rks

R o uters

Descrip t io n

View basic reports.

Use the following tabs to view the following usages:

D ai l y R epo rt - View the daily report.

Stats - View the statistics of all resources.

View the hypervisor summary.

View, create, and edit host aggregates. View the list of availability zones.

View, pause, resume, suspend, migrate, soft or hard reboot, and delete running instances that belong to users of some, but not all, projects. Also, view the log for an instance or access an instance using the console.

View, create, edit, and delete volumes, and volume types.

View, create, edit, view extra specs for, and delete flavors. Flavors are the virtual hardware templates in OpenStack.

View, create, edit properties for, and delete custom images.

View, create, edit properties for, and delete networks.

View, create, edit properties for, and delete routers.

177

Deploying O penSt ack: Learning Environment s (Manual Set up)

Paramet er Name

System Info

Descrip t io n

Contains the following tabs:

Servi ces - View a list of the services.

C o mpute Servi ces - View a list of all Compute services.

Netwo rk Ag ents - View the network agents.

D efaul t Q uo tas - View default quota values. Quotas are hardcoded in OpenStack Compute and define the maximum allowable size and number of resources.

T ab le 10.2. Id en t it y Pan el

Paramet er Name

P ro jects

Users

Descrip t io n

View, create, assign users to, remove users from, and delete projects.

View, create, enable, disable, and delete users.

10.5.2. OpenSt ack Dashboard - Project T ab

The Project tab provides an interface for viewing and managing the resources of a project. Select a project from the C UR R ENT P R O JEC T drop-down list on the top right side to view and manage resources in that project.

The P ro ject tab displays the details of the selected project.

178

⁠Chapt er 1 0 . Dashboard Inst allat ion

Fig u re 10.3. Dash b o ard - Pro ject T ab

Access the following tabs:

T ab le 10.3. Co mp u t e

Paramet er Name

O vervi ew

Instances

Vo l umes

Imag es

Descrip t io n

View reports for the project.

View, launch, create a snapshot from, stop, pause, or reboot instances, or connect to them through the console.

Use the following tabs to complete these tasks:

Vo l umes - View, create, edit, and delete volumes.

Vo l ume Snapsho ts - View, create, edit, and delete volume snapshots.

View images, instance snapshots, and volume snapshots created project users, and any images that are publicly available. Create, edit, and delete images, and launch instances from images and snapshots.

179

Deploying O penSt ack: Learning Environment s (Manual Set up)

Paramet er Name

Access & Securi ty

Descrip t io n

Use these tabs to complete these tasks:

Securi ty G ro ups tab- View, create, edit, and delete security groups, and security group rules.

Keypai rs tab- View, create, edit, and import keypairs, and delete keypairs.

Fl o ati ng IP s tab- Allocate an IP address to or release it from a project.

AP I Access tab- View API endpoints.

T ab le 10.4 . Net wo rk

Paramet er Name

Netwo rk T o po l o g y

Netwo rks

R o uters

Descrip t io n

View the interactive topology of the network.

Create and manage public and private networks.

Create and manage subnets.

T ab le 10.5. O b ject St o re

Paramet er Name

C o ntai ners

Descrip t io n

Create and manage storage containers. A container is a storage compartment for your data and provides a way for you to organize your data. It is similar to the concept as a Linux file directory but cannot be nested.

T ab le 10.6 . O rch est rat io n

Paramet er Name

Stacks

Descrip t io n

Orchestrate multiple composite cloud applications using templates, through both an OpenStack-native REST API and a

CloudFormation-compatible Query API.

10.5.3. OpenSt ack Dashboard - Red Hat Access T ab

Red Hat Access tab gives you the option to sign in to the Red Hat Customer Portal and search for articles and solutions.

180

⁠Chapt er 1 0 . Dashboard Inst allat ion

Fig u re 10.4 . Red Hat Access T ab

This tab contains a Lo g option that you can use to check the console log file for your instances and the Suppo rt option to check for support cases for issues. You can also use this to open new support cases using the O pen a New Suppo rt C ase button.

10.6. T roubleshoot Dashboard Inst allat ion Issues

10.6.1. No Net works or Rout ers T ab Appears in t he Dashboard

The Netwo rks and R o uters tabs only appear in the dashboard when the environment is configured to use OpenStack Networking. In particular note that by default the PackStack utility currently deploys Nova Networking and as such in environments deployed in this manner the tab will not be visible.

If OpenStack Networking is deployed in the environment but the tabs still do not appear ensure that the service endpoints are defined correctly in the Identity service, that the firewall is allowing access to the endpoints, and that the services are running.

10.6.2. Dashboard Report s ERROR When Launching Inst ances

When using the dashboard to launch instances if the operation fails, a generic ER R O R message is displayed. Determining the actual cause of the failure requires the use of the command line tools.

Use the no va l i st to locate the unique identifier of the instance. Then use this identifier as an argument to the no va sho w command. One of the items returned will be the error condition. The most common value is No Val i d Ho st.

181

Deploying O penSt ack: Learning Environment s (Manual Set up)

This error indicates that no valid host was found with enough available resources to host the instance. To work around this issue, consider choosing a smaller instance size or increasing the overcommit allowances for your environment.

Note

To host a given instance, the compute node must have not only available CPU and RAM resources but also enough disk space for the ephemeral storage associated with the instance.

182

⁠Chapt er 1 1 . O penSt ack Dat a Processing Inst allat ion

Chapter 11. OpenStack Data Processing Installation

11.1. Inst all t he OpenSt ack Dat a Processing Service Packages

On the server hosting the OpenStack Data Processing service, install the openstack-sahara package:

# yum i nstal l o penstack-sahara

This package provides the OpenStack Data Processing CLI clients (sah ara and sah ara- d b -

man ag e) and the o penstack-sahara-api service.

11.2. Configure t he Dat a Processing Service

To configure the Data Processing service (Sahara), you will need to:

Configure the OpenStack Data Processing database connection.

Configure the OpenStack Data Processing API server to authenticate with the Identity service.

Configure the firewall to allow service traffic for OpenStack Data Processing (through port 8386 ).

The following sections describe each step in greater detail.

11.2.1. Configure t he OpenSt ack Dat a Processing Dat abase Connect ion

The database connection URL used by the OpenStack Data Processing service is defined in the

/etc/sahara/sahara. co nf file. This URL must be set to point to a valid database server before launching the OpenStack Data Processing API server (o penstack-sahara-api ). Typically, if a database already exists for OpenStack Data Processing you would set the database connection

URL using the following command:

# o penstack-co nfi g --set /etc/sahara/sahara. co nf \

d atabase co nnecti o n DB_TYPE: //USER: PASS@ IP/sahara

Where:

DB_TYPE is the type of the database server (for example, mysq l ).

USER and PASS are the username and password required by the OpenStack Data Processing service to log on to the database server. Supply these credentials only when required by the database server (for example, when the database server is hosted on another system or node).

IP is the IP address/hostname of the system hosting the database server.

If you have not created a database yet for OpenStack Data Processing, perform the following steps instead:

Pro ced u re 11.1. Creat in g an d co n f ig u rin g a d at ab ase f o r O p en St ack Dat a Pro cessin g

If you are installing the OpenStack Data Processing service for testing purposes, create the database on the same server hosting the o penstack-sahara-api service. The following instructions show how to do this on MariaDB, which is the default database used by most

OpenStack components.

183

Deploying O penSt ack: Learning Environment s (Manual Set up)

1. From the command line, log on to the database as an administrator:

# mysq l -u ro o t -p

2. Create the sahara database.

mysq l > CREATE DATABASE sahara;

3. Create a sahara database user and grant it access to the sahara database.

Mari aD B > GRANT ALL ON sahara.* TO 'sahara'@ '%' IDENTIFIED BY

'PASSWORD';

Mari aD B > GRANT ALL ON sahara.* TO 'sahara'@ 'localhost' IDENTIFIED

BY 'PASSWORD';

Replace PASSWORD with a secure password that will be used to authenticate with the database server as this user.

4. Exit the mysq l client.

mysq l > quit

5. On the system hosting the OpenStack Data Processing service, set the database connection

URL to the new database:

# o penstack-co nfi g --set /etc/sahara/sahara. co nf \

d atabase co nnecti o n mysq l : //sahara: PASSWORD@ IP/sahara

6. Use the sahara-d b-manag e client to configure the schema of the sahara database:

# sahara-d b-manag e --co nfi g -fi l e /etc/sahara/sahara. co nf upg rad e

head

INFO [alembic.migration] Context impl MySQLImpl.

INFO [alembic.migration] Will assume non-transactional DDL.

INFO [alembic.migration] Running upgrade None -> 001, Icehouse release

INFO [alembic.migration] Running upgrade 001 -> 002, placeholder

INFO [alembic.migration] Running upgrade 002 -> 003, placeholder

INFO [alembic.migration] Running upgrade 003 -> 004, placeholder

INFO [alembic.migration] Running upgrade 004 -> 005, placeholder

INFO [alembic.migration] Running upgrade 005 -> 006, placeholder

INFO [alembic.migration] Running upgrade 006 -> 007, convert clusters.status_description to LongText

INFO [alembic.migration] Running upgrade 007 -> 008, add security_groups field to node groups

INFO [alembic.migration] Running upgrade 008 -> 009, add rollback info to cluster

INFO [alembic.migration] Running upgrade 009 -> 010, add auto_security_groups flag to node group

INFO [alembic.migration] Running upgrade 010 -> 011, add Sahara settings info to cluster

184

⁠Chapt er 1 1 . O penSt ack Dat a Processing Inst allat ion

11.2.2. Creat e t he OpenSt ack Dat a Processing Service Ident it y Records

This section assumes that you have already created an administrator account and servi ces tenant. For more information, refer to:

Section 3.7, “ Create an Administrator Account”

1. Created an Administrator role named ad mi n (refer to Section 3.7, “ Create an Administrator

In this procedure, you will:

1. Create the sahara user, who has the ad mi n role in the servi ces tenant.

2. Create the sahara service entry and assign it an endpoint.

In order to proceed, you should have already performed the following (using the Identity service):

2. Created the servi ces tenant (refer to

service users. For more information, refer to Section 3.9, “ Create the Services Tenant” .

for instructions)

Note

The Deploying OpenStack: Learning Environments (Manual Set Up) guide uses one tenant for all

Pro ced u re 11.2. Co n f ig u rin g t h e O p en St ack Dat a Pro cessin g service t o au t h en t icat e t h ro u g h t h e Id en t it y Service

1. Set up the shell to access Keystone as the admin user:

# so urce ~ /keysto nerc_ad mi n

2. Create the sahara user and set its password by replacing PASSWORD with your chosen password:

# keysto ne user-create --name sahara --pass PASSWORD

3. Add the sahara user to the servi ces tenant with the ad mi n role:

# keysto ne user-ro l e-ad d --user sahara --ro l e ad mi n --tenant

servi ces

4. Create the sahara system item:

# keysto ne servi ce-create --name= sahara --type= d ata_pro cessi ng --

d escri pti o n= "O penStack D ata P ro cessi ng "

185

Deploying O penSt ack: Learning Environment s (Manual Set up)

5. Create the sahara endpoint entry:

# keysto ne end po i nt-create \

--servi ce sahara \

--publ i curl "http: //SAHARA_HOST: 8386 /v1. 1/%(tenant_i d )s" \

--ad mi nurl "http: //SAHARA_HOST: 8386 /v1. 1/%(tenant_i d )s" \

--i nternal url "http: //SAHARA_HOST: 8386 /v1. 1/%(tenant_i d )s"

Replace SAHARA_HOST with the IP address or fully qualified domain name of the system hosting the OpenStack Data Processing service.

Note

By default, the endpoint is created in the default region, reg i o nO ne. This is a casesensitive value.

If you need to specify a different region when creating an endpoint, use the --region argument to provide it. In particular, if you are manually installing OpenStack Data

Processing in an OpenStack environment deployed through Packstack, specify the region as R eg i o nO ne (as in, --region RegionOne).

See

Section 3.6.1, “ Service Regions” for more information.

You have now configured the Identity service to work with the OpenStack Data Processing service.

11.2.3. Configure OpenSt ack Dat a Processing Aut hent icat ion

After creating and configuring the required OpenStack Data Processing service users and roles

(namely, Identity records), configure the OpenStack Data Processing API server (o penstack-

sahara-api ) to authenticate with the Identity service. Doing so involves setting the required Identity credentials in the /etc/sahara/sahara. co nf configuration file.

To configure the required Identity credentials for the OpenStack Data Processing API server, perform the following procedure.

Pro ced u re 11.3. Co n f ig u rin g t h e O p en St ack Dat a Pro cessin g API server t o au t h en t icat e t h ro u g h t h e Id en t it y service

1. First, set the OpenStack Data Processing API to connect to the Identity API service:

# o penstack-co nfi g --set /etc/sahara/sahara. co nf \

keysto ne_authto ken auth_uri

http: //KEYSTONE_HOST: PUBLICPORT/v2. 0 /

# o penstack-co nfi g --set /etc/sahara/sahara. co nf \

keysto ne_authto ken i d enti ty_uri http: //KEYSTONE_HOST: ADMINPORT

Where:

KEYSTONE_HOST is the IP address of the Identity API host.

PUBLICPORT is the port used for the Identity API service public endpoint.

ADMINPORT is the port used for the Identity API service admin endpoint (typically 35357).

186

⁠Chapt er 1 1 . O penSt ack Dat a Processing Inst allat ion

See

Section 3.6, “ Create the Identity Service Endpoint”

for more details on setting up the

Identity API service endpoints.

2. Set the OpenStack Data Processing service to authenticate as the correct tenant:

# o penstack-co nfi g --set /etc/sahara/sahara. co nf \

keysto ne_authto ken ad mi n_tenant_name services

Where services is the name of the tenant created for the use of the OpenStack Data

Processing service. Examples in this guide use services.

3. Set the OpenStack Data Processing API server to authenticate using the sahara administration user account:

# o penstack-co nfi g --set /etc/sahara/sahara. co nf \

keysto ne_authto ken ad mi n_user sahara

4. Set the OpenStack Data Processing API server to use the correct sahara administration user account password:

# o penstack-co nfi g --set /etc/sahara/sahara. co nf \

keysto ne_authto ken ad mi n_passwo rd SERVICE_PASSWORD

Where SERVICE_PASSWORD is the password set during the creation of the sahara user.

11.2.4 . Configure t he Firewall t o Allow OpenSt ack Dat a Processing Service

T raffic

OpenStack Data Processing uses port 8386 . As such, Red Hat Enterprise Linux should be configured to allow traffic on this port.

To do so, perform the following steps as the ro o t user.

Pro ced u re 11.4 . Co n f ig u rin g t h e f irewall t o allo w O p en St ack Dat a Pro cessin g t raf f ic

1. Open the /etc/sysco nfi g /i ptabl es file in a text editor.

2. Add an INPUT rule allowing TCP traffic on port 8386 to the file. The new rule must appear before any INPUT rules that REJECT traffic.

-A INPUT -p tcp -m multiport --dports 8386 -j ACCEPT

3. Save the changes to the /etc/sysco nfi g /i ptabl es file.

4. Restart the i ptabl es service to ensure that the change takes effect.

# servi ce i ptabl es restart

The firewall is now configured to allow incoming connections to the OpenStack Data Processing service on port 8386 .

11.3. Configure and Launch t he OpenSt ack Dat a Processing Service

187

Deploying O penSt ack: Learning Environment s (Manual Set up)

If your OpenStack deployment uses OpenStack Networking (neutro n), then you must configure the

OpenStack Data Processing service accordingly. To do so, run:

# o penstack-co nfi g --set /etc/sahara/sahara. co nf \

D EFAULT use_neutro n true

To launch OpenStack Data Processing, run the following command on the server hosting it:

# systemctl start o penstack-sahara-al l

Then, configure the service to start at boot:

# systemctl enabl e o penstack-sahara-al l

188

⁠Part III. Set Up t he O penSt ack Monit oring

⁠Part III. Set Up the OpenStack Monitoring

189

Deploying O penSt ack: Learning Environment s (Manual Set up)

Chapter 12. OpenStack Telemetry Installation

12.1. T elemet ry Service Overview

The Telemetry service provides user-level usage data for OpenStack-based clouds, which can be used for customer billing, system monitoring, or alerts. Data can be collected by notifications sent by existing OpenStack components (for example, usage events emitted from Compute) or by polling the infrastructure (for example, libvirt).

Telemetry includes a storage daemon that communicates with authenticated agents through a trusted messaging system, to collect and aggregate data. Additionally, the service uses a plug-in system, which makes it easy to add new monitors.

T ab le 12.1. T elemet ry service co mp o n en t s

Co mp o n en t

ceilometer-agent-compute ceilometer-agent-central ceilometer-collector ceilometer-notification

MongoDB database

API Server

RabbitMQ server

(rabbi tmq -server)

Descrip t io n

An agent that runs on each Compute node to poll for resource utilization statistics.

An agent that runs on a central management server to poll for utilization statistics about resources not tied to instances or

Compute nodes.

An agent that runs on one or more central management servers to monitor the message queues. Notification messages are processed and turned into Telemetry messages, and sent back out on to the message bus using the appropriate topic. Telemetry messages are written to the data store without modification.

An agent that pushes metrics to the collector service from various

OpenStack services.

For collected usage data from collector agents. Only the collector agents and the API server have access to the database.

Runs on one or more central management servers to provide access to data in the database.

Provides the AMQP message queue. This server (also used by Block

Storage) handles the OpenStack transaction management, including queuing, distribution, security, management, clustering, and federation. Messaging becomes especially important when an

OpenStack deployment is scaled and its services are running on multiple machines.

T elemet ry service d ep en d en cies

Each no va-co mpute node must have a cei l o meter-co mpute agent deployed and running.

All nodes running the cei l o meter-api service must have firewall rules granting appropriate access.

The cei l o meter-central -ag ent cannot currently be horizontally scaled, so only a single instance of this service should be running at any given moment.

You can choose where to locate the additional Telemetry agents, as all intra-agent communication is either based on AMQP or REST calls to the cei l o meter-api service; as is the case for the cei l o meter-al arm-eval uato r service.

12.2. Overview of T elemet ry Service Deployment

190

⁠Chapt er 1 2 . O penSt ack T elemet ry Inst allat ion

The OpenStack Telemetry service is composed of an API server, three openstack-ceilometer agents, and two alarm services. The API Server (provided by the openstack-ceilometer-api) runs on one or more central management servers to provide access to the back-end repository.

Note

At present, mo ng o d is the only back-end repository supported by the Telemetry service.

The three Telemetry agents (and their respective packages) are:

Central agent (provided by openstack-ceilometer-central): runs on a central management server to poll public REST APIs for utilization statistics about resources that are not visible (either through notifications or from the hypervisor layer)

Collector (provided by openstack-ceilometer-collector): runs on one or more central management servers to receive notifications on resource usage. The Collector also parses resource usage statistics and saves them as datapoints in the Telemetry store.

Compute agent (provided by openstack-ceilometer-compute): runs on each Compute service node to poll for instance utilization statistics. You must install and configure the Compute service first before installing the openstack-ceilometer-compute on any node.

The two alarm services (and their respective packages) that comprise the rest of the Telemetry service are:

Evaluator (provided by ceilometer-alarm-evaluator): triggers state transitions on alarms.

Notifier (provided by ceilometer-alarm-notifier): executes required actions when alarms are triggered.

You can deploy the API Server, Central agent, data store service, and Collector on different hosts. In addition, each Compute node must also have a Compute agent installed; this agent gathers detailed usage metrics on instances running on the Compute node.

Each of these components must have the following settings configured:

Authentication, as in Identity service tokens and Telemetry secret

Database connection URL, for connecting to the Telemetry store

The authentication settings (for example, Identity credentials) and database connection string for these components are all configured in /etc/cei l o meter/cei l o meter. co nf. As such, components deployed on the same host will share the same settings.

Conversely, if Telemetry components are deployed on multiple hosts then you will have to replicate any authentication changes to these hosts. To do so, you can copy the

/etc/cei l o meter/cei l o meter. co nf file across hosts after applying the new settings.

Once the Telemetry service (as in, all of its components, wherever each is hosted) is deployed and configured, you will need to configure each monitored service (Image, Networking, Object Storage,

Block Storage, and each Compute node) to submit data to the Telemetry service. The related settings are configured in each service's configuration file.

12.3. Inst all t he T elemet ry Service Packages

The OpenStack Telemetry service requires the following packages:

191

Deploying O penSt ack: Learning Environment s (Manual Set up)

mongodb-server

Provides the MongoDB database server. The Telemetry service uses mo ng o d b as its backend data repository.

openstack-ceilometer-api

Provides the cei l o meter API Server.

openstack-ceilometer-central

Provides the Central cei l o meter agent.

openstack-ceilometer-collector

Provides the cei l o meter Collector agent.

openstack-ceilometer-common

Provides components common to all cei l o meter services.

openstack-ceilometer-compute

Provides the cei l o meter agent that should run on each Compute node.

openstack-ceilometer-alarm

Provides the cei l o meter alarm notification and evaluation services.

openstack-ceilometer-notification

Provides the Notification agent. This agent provides metrics to the Collector agent from different OpenStack services.

python-ceilometer

Provides the cei l o meter python library.

python-ceilometerclient

Provides the cei l o meter command-line tool and a Python API (specifically, the

cei l o metercl i ent module).

To install these required packages on the same host, run the following command as the ro o t user:

# yum i nstal l -y mo ng o d b-server o penstack-cei l o meter-* pytho n-

cei l o meter pytho n-cei l o metercl i ent

You can deploy the API Server, Central agent, data store service, and Collector on different hosts. In this case, log in to a host and install the corresponding package of the component you wish to deploy there:

# yum i nstal l -y PACKAGE

Replace PACKAGE with the corresponding package of the component you wish to install on the host.

All nodes hosting services that you wish to monitor with the Telemetry services must also have the

python-ceilometer and python-ceilometerclient packages installed (see Section 12.9, “ Configure

Monitored Services” for more information).

12.4 . Creat e t he T elemet ry Ident it y Records

192

⁠Chapt er 1 2 . O penSt ack T elemet ry Inst allat ion

12.4 . Creat e t he T elemet ry Ident it y Records

In this section, you will:

1. Create the cei l o meter user, who has the R esel l erAd mi n role in the servi ces tenant.

2. Create the cei l o meter service entry and assign it an endpoint.

In order to proceed, you need to have already completed the following steps:

1. Created an Administrator role named ad mi n (refer to Section 3.7, “ Create an Administrator

2. Created the servi ces tenant (refer to

service users. For more information, refer to Section 3.9, “ Create the Services Tenant” .

for instructions)

Note

The Deploying OpenStack: Learning Environments (Manual Set Up) guide uses one tenant for all

Section 3.7, “ Create an Administrator Account” .

Pro ced u re 12.1. Creat in g Id en t it y reco rd s f o r t h e T elemet ry service

1. Set up the shell to access Keystone as the admin user:

# so urce ~ /keysto nerc_ad mi n

2. Create a cei l o meter user using the following command:

# keysto ne user-create --name= cei l o meter \

--pass= SERVICE_PASSWORD \

--emai l = CEILOMETER_EMAIL

Where:

SERVICE_PASSWORD is the password the Telemetry service should use when authenticating with the Identity service.

CEILOMETER_EMAIL is the email address used by the Telemetry service.

3. Create a R esel l erAd mi n role:

# keysto ne ro l e-create --name= R esel l erAd mi n

4. Establish the relationship between the Telemetry service, the servi ces tenant, and

R esel l erAd mi n role:

# keysto ne user-ro l e-ad d --user cei l o meter \

--ro l e R esel l erAd mi n \

--tenant servi ces

193

Deploying O penSt ack: Learning Environment s (Manual Set up)

5. Establish the relationship between the Telemetry service, the servi ces tenant, and ad mi n role:

# keysto ne user-ro l e-ad d --user cei l o meter \

--ro l e ad mi n \

--tenant servi ces

6. Create the cei l o meter service entry:

# keysto ne servi ce-create --name= cei l o meter \

--type= meteri ng \

--d escri pti o n= "O penStack T el emetry Servi ce"

+-------------+----------------------------------+

| Property | Value |

+-------------+----------------------------------+

| description | OpenStack Telemetry Service |

| id | a511aea8bc126 4 6 4 1f4 d ff1d b38751br |

| name | ceilometer |

| type | metering |

+-------------+----------------------------------+

7. Create the cei l o meter endpoint entry:

# keysto ne end po i nt-create \

--servi ce cei l o meter \

--publ i curl "IP: 8777" \

--ad mi nurl "IP: 8777" \

--i nternal url "IP: 8777"

Replace IP with the IP address or host name of the system hosting the Telemetry service.

Note

By default, the endpoint is created in the default region, reg i o nO ne. This is a casesensitive value.

If you need to specify a different region when creating an endpoint, use the --region argument to provide it. In particular, if you are manually installing the Telemetry service in an OpenStack environment deployed through Packstack, specify the region as

R eg i o nO ne (as in, --region RegionOne).

See

Section 3.6.1, “ Service Regions” for more information.

12.5. Configure T elemet ry Service Aut hent icat ion

After creating and configuring the required Telemetry service users and roles (namely, Identity records), configure the Telemetry API service (o penstack-cei l o meter-api ) to authenticate with the Identity service. Doing so involves setting the required Identity credentials in the

/etc/cei l o meter/cei l o meter. co nf configuration file.

194

⁠Chapt er 1 2 . O penSt ack T elemet ry Inst allat ion

To configure the required Identity credentials for the Telemetry API service, perform the following procedure.

Pro ced u re 12.2. Co n f ig u rin g t h e T elemet ry service t o au t h en t icat e t h ro u g h t h e Id en t it y service

1. Set the Telemetry service's authentication host (auth_ho st) configuration key:

# o penstack-co nfi g --set /etc/cei l o meter/cei l o meter. co nf \

keysto ne_authto ken auth_ho st KEYSTONE_HOST

Replace KEYSTONE_HOST with the IP address or host name of the Identity server.

2. Set the Telemetry service's authentication port (auth_po rt) configuration key:

# o penstack-co nfi g --set /etc/cei l o meter/cei l o meter. co nf \

keysto ne_authto ken auth_po rt PORT

Replace PORT with the authentication port used by the Identity server.

3. Set the Telemetry service to use the http protocol for authenticating:

# o penstack-co nfi g --set /etc/cei l o meter/cei l o meter. co nf \

keysto ne_authto ken auth_pro to co l PORT

4. Set the Telemetry service to authenticate as the correct tenant:

# o penstack-co nfi g --set /etc/cei l o meter/cei l o meter. co nf \

keysto ne_authto ken ad mi n_tenant_name services

Where services is the name of the tenant created for the use of the Telemetry service. Examples in this guide use services.

5. Set the Telemetry service to authenticate using the cei l o meter administration user account:

# o penstack-co nfi g --set /etc/cei l o meter/cei l o meter. co nf \

keysto ne_authto ken ad mi n_user cei l o meter

6. Set the Telemetry service to use the correct cei l o meter administration user account password:

# o penstack-co nfi g --set /etc/cei l o meter/cei l o meter. co nf \

keysto ne_authto ken ad mi n_passwo rd SERVICE_PASSWORD

Where SERVICE_PASSWORD is the password set during the creation of the cei l o meter user.

7. Set the Telemetry secret. This is a string used to help secure communication between all components of the Telemetry service across multiple hosts (for example, between the Collector agent and a Compute node agent). To set the Telemetry secret:

# o penstack-co nfi g --set /etc/cei l o meter/cei l o meter. co nf \

publ i sher_rpc meteri ng _secret SECRET

195

Deploying O penSt ack: Learning Environment s (Manual Set up)

Replace SECRET with the string that all Telemetry service components should use to sign and verify messages that are sent or received over AMQP.

After configuring the credentials of the Telemetry API service, configure the service endpoints to be used by the Central agent, Compute agents, and Alarm Evaluator. To do so, run the following commands on each host where these components are deployed:

# o penstack-co nfi g --set /etc/cei l o meter/cei l o meter. co nf \

D EFAULT o s_auth_url http: //IP: 35357/v2. 0

# o penstack-co nfi g --set /etc/cei l o meter/cei l o meter. co nf \

D EFAULT o s_username cei l o meter

# o penstack-co nfi g --set /etc/cei l o meter/cei l o meter. co nf \

D EFAULT o s_tenant_name servi ces

# o penstack-co nfi g --set /etc/cei l o meter/cei l o meter. co nf \

D EFAULT o s_passwo rd SERVICE_PASSWORD

Where:

IP is the IP address or host name of the Identity server.

SERVICE_PASSWORD is the password set during the creation of the cei l o meter user.

12.6. Configure t he MongoDB Back-End and Creat e t he T elemet ry

Dat abase

The Telemetry service uses MongoDB as its back-end data repository. As such, you will need to start the mo ng o d service.

Before doing so, you may want to configure mo ng o d to run with the --smal l fi l es parameter. This parameter configures MongoDB to use a smaller default data file and journal size. With this,

MongoDB will limit the size of each data file, creating and writing to a new one when it reaches

512MB.

You can configure mo ng o d to run with this parameter using /etc/sysco nfi g /mo ng o d . To do so, specify --smal l fi l es in the O P T IO NS section of /etc/sysco nfi g /mo ng o d , as in:

OPTIONS="--smallfiles /etc/mongodb.conf"

MongoDB will use all parameters specified in the O P T IO NS section when mo ng o d launches. To start the MongoDB service:

# servi ce mo ng o d start

After configuring and launching the MongoDB back-end, create a suitable MongoDB database for the Telemetry service:

# mo ng o --ho st MONGOHOST --eval ' db = db.getSiblingDB("ceilometer"); db.addUser({user: "ceilometer",

pwd: "MONGOPASS",

roles: [ "readWrite", "dbAdmin" ]})'

196

⁠Chapt er 1 2 . O penSt ack T elemet ry Inst allat ion

This command will create the MongoDB database for the Telemetry service, along with a database user named cei l o meter (whose corresponding password is MONGOPASS). Replace MONGOHOST with the IP address/hostname of the system hosting the MongoDB database.

12.6.1. Configure t he T elemet ry Dat abase Connect ion

The database connection URL used by the Telemetry service is defined in the

/etc/cei l o meter/cei l o meter. co nf file. This URL must be set to point to a valid database server before launching the Telemetry API service (o penstack-cei l o meter-api ), Notification agent (o penstack-cei l o meter-no ti fi cati o n) and Collector agent (o penstack-

cei l o meter-co l l ecto r). The Telemetry service uses this database server as its back-end data repository; by default, the Telemetry service uses MongoDB.

To set the database connection string, run the following command as the ro o t user on the system hosting the o penstack-cei l o meter-api and o penstack-cei l o meter-co l l ecto r services:

# o penstack-co nfi g --set /etc/cei l o meter/cei l o meter. co nf \

d atabase co nnecti o n

mo ng o d b: //cei l o meter: MONGOPASS@ MONGOHOST/cei l o meter

Where:

MONGOPASS is the password of the cei l o meter user, required by the Telemetry service to log on to the database server. Supply these credentials only when required by the database server

(for example, when the database server is hosted on another system or node).

MONGOHOST is the IP address/hostname and port of the system hosting the database server.

Note

This assumes that you created a MongoDB database user named cei l o meter with the

password MONGOPASS, as instructed in Section 12.6, “ Configure the MongoDB Back-End and Create the Telemetry Database” .

If MongoDB is hosted locally on the same host, the required database connection string would be: mongodb://localhost:27017/ceilometer

As in:

# o penstack-co nfi g --set /etc/cei l o meter/cei l o meter. co nf \

d atabase co nnecti o n mo ng o d b: //l o cal ho st: 270 17/cei l o meter

12.7. Configure Rabbit MQ Message Broker Set t ings for t he T elemet ry

Service

This section assumes that you have already configured a RabbitMQ message broker. For more information, refer to:

197

Deploying O penSt ack: Learning Environment s (Manual Set up)