rackspace.com/cloud/private

(1)

(2)

Rackspace Private Cloud Installation Guide

v4 (2014-11-21)

(3)

1. Preface

1.1. About Rackspace Private Cloud

Rackspace Private Cloud is a set of tools that allow you to quickly install an OpenStack pri-vate cloud, configured as recommended by Rackspace OpenStack specialists.

Rackspace Private Cloud uses Chef to create an OpenStack cluster on Ubuntu, CentOS, or Red Hat Enterprise Linux. The installation scripts provide a familiar approach for Linux sys-tem administrators, and can be updated easily without downloading and installing a new ISO.

Note

This is the Rackspace Private Cloud v4 Installation Guide. The Rackspace Private Cloud v9 Installation Guide is available at http://docs.rackspace.com/

rpc/api/v9/bk-rpc-installation/content/rpc-com-mon-front.html

1.2. Rackspace Private Cloud configuration

Rackspace Private Cloud v4.1.5 installs OpenStack Grizzly, which contains these compo-nents:

• Compute (nova) • Image Service (glance) • Dashboard (horizon) • Identity (keystone)

• Virtual Network (neutron)

Rackspace Private Cloud v4.2.2 installs OpenStack Havana, which contains these compo-nents:

• Compute (nova) • Image Service (glance) • Dashboard (horizon) • Identity (keystone)

• Virtual Network (neutron) • Metering (ceilometer)

Object Storage (swift) is also available in the Rackspace Private Cloud Object Storage offer-ing.

(5)

1.3. Rackspace Private Cloud support

Rackspace offers 365x24x7 support for Rackspace Private Cloud. If you are interested in purchasing Escalation Support or Core Support for your cloud, or taking advantage of our training offerings, contact us at: <[email protected]>.

You can also visit the Rackspace Private Cloud community forums. The forum is open to all Rackspace Private Cloud users and is moderated and maintained by Rackspace personnel and OpenStack specialists:

https://community.rackspace.com/products/f/45

For any other information regarding your Rackspace Private Cloud, refer to the Rackspace Private Cloud release notes.

(6)

2. Installation prerequisites

This chapter lists the prerequisites for installing a cluster with the Rackspace Private Cloud tools. Rackspace recommends that you review this chapter in detail before attempting the installation.

2.1. Preparing for the installation

You need the following information for the installation: • The nova network address in CIDR format.

• The nova network bridge, such as br100 or eth0. This will be used as the VM bridge on compute nodes. The default value is usually acceptable. This bridge will be created by No-va as necessary and does not need to be manually configured.

• The public network address in CIDR format. This is where public API services, such as the public Keystone endpoint and the dashboard, will run. An IP address from this network should be configured on all hosts in the Nova cluster.

• The public network interface, such as eth0 or eth1. This is the network interface that is connected to the public network on compute nodes. In a nova-network configuration, compute nodes with instance traffic NAT out from this interface unless a specific floating IP address has been assigned to that instance.

• The management network address in CIDR format. This network is used for communica-tion among services such as monitoring and syslog. This is the same as your Nova public network if you do not want to separate service traffic.

• The VM network CIDR range. This is the range from which IP addresses will be automat-ically assigned to VMs. An address from this network will be visible from within your in-stance on eth0. This network should be dedicated to OpenStack and not shared with oth-er soth-ervices.

• The network interface of the VM network for the compute notes (such as eth1). • The name of the Nova cluster. This should be unique and composed of alphanumeric

characters, hyphens (-), or underscores (_).

• The name of the default availability zone. Rackspace recommends using nova as the

de-fault.

• For nova-network configurations, an optional NAT exclusion CIDR range or ranges for networks configured with a DMZ. A comma-separated list of CIDR network ranges that will be excluded from NAT rules. This enables direct communication to and from in-stances from other network ranges without the use of floating IPs.

2.2. Hardware requirements

Rackspace Private Cloud has been tested in deployment with a physical device for each of the following nodes:

(7)

• A Chef server

• An OpenStack Nova Controller node

• Additional physical machines with OpenStack Nova compute nodes as required

2.2.1. Chef server requirements

Rackspace recommends that the Chef server hardware meet the following requirements: • 4 GB RAM

• 50 GB disk space

• Dual socket CPU with dual core

2.2.2. Cluster node requirements

Each node in the cluster will have chef-client installed on it. The hardware requirements vary depending on the purpose of the node. Each device should support VT-x. This table outlines the detailed requirements:

Node Type Requirements

Nova Controller • 16 GB RAM • 144 GB disk space

• Dual socket CPU with dual core, or single socket quad core

Nova Compute • 32 GB RAM • 144 GB disk space

• Dual socket CPU with dual core, or single socket quad core

CPU overcommit is set at 16:1 VCPUs to cores, and memory overcommit is set to 1.5:1. Each physical core can support up to 16 virtual cores; for example, one dual-core processor can support up to 32 virtual cores. If you require more virtual cores, add additional physical nodes to your configuration.

For a list of Private Cloud certified devices, refer to Private Cloud Certified Devices - Com-pute.

2.3. Software requirements

This table lists the operating systems on which Rackspace Private Cloud has been tested.

Operating System Tested Rackspace Private Cloud Version

Ubuntu 12.04 All versions Ubuntu 12.10 and later None

CentOS 6.3 v4.0.0 and earlier CentOS 6.4 v4.1.2 and later Red Hat Enterprise Linux 6.0 None

It is possible to install Rackspace Private Cloud on untested OSes, however this can cause unexpected issues.

(8)

If you require the Controller and Networking nodes with OpenStack Networking,

Rackspace recommends that you use Rackspace Private Cloud v4.2.2 or later with CentOS 6.4 or Ubuntu 12.04.

Note

Rackspace Private Cloud only supports kernel

kernel-2.6.32-358.123.2.openstack.el6.x86_64.

2.4. Proxy considerations

When installing Rackspace Private Cloud, please ensure none of your nodes are behind a proxy. If they are behind a proxy, review this section before proceeding with the installa-tion.

Procedure 2.1. Configuring proxy environment settings on the nodes

1. You must make your proxy settings available to the entire OS on each node by config-uring /etc/environment as follows:

$ /etc/environment http_proxy=http://<yourProxyURL>:<port> https_proxy=http://<yourProxyURL>:<port> ftp_proxy=http://<yourProxyURL>:<port> no_proxy=<localhost>,<node1> ,<node2>

2. Replace node1 and node2 with the hostnames of your nodes.

In all cases, no_proxy is required and must contain a localhost entry. If local-host is missing, the Omnibus Chef Server installation will fail. We recommend that you

set as many variables as you can as installation methods can change over time. Ubuntu requires at least http_proxy and no_proxy to be set.

CentOS requires at least http_proxy, https_proxy, and no_proxy for yum

pack-ages and key updates.

3. The nodes must also have root configured to retain the following environment vari-ables:

Defaults env_keep += "http_proxy https_proxy ftp_proxy no_proxy"

On Ubuntu, this can be put in a file in /etc/sudoers.d. On CentOS, ensure that

your version loads files in /etc/sudoers.d before adding this variable.

4. Verify that the proxy settings are correct by running the env command as both the un-privileged and root users.

(9)

This command will output a list of environment variables for the current user. If your proxy settings have been set correctly, then the http_proxy, https_proxy, ftp_proxy, and no_proxy settings will appear in the list.

2.5. High Availability

Rackspace Private Cloud has the ability to implement support for high availability (HA) for all Nova service components and APIs. Rackspace Private Cloud can also implement HA sup-port for Glance, Keystone, Cinder, RabbitMQ and MySQL. The scheduler High Availability functionality is powered by Keepalived and HAProxy.

Note

High availability requires that you allocate a virtual IP (VIP) for each compo-nent. For more information, see Section 3.3.7, “Controller node high availabili-ty” [14].

Rackspace Private Cloud uses the following methods to implement HA in your cluster: • MySQL master-master replication and active-passive failover: MySQL is installed

on both controller nodes, and master-master replication is configured between the nodes. Keepalived manages connections to the two nodes, so that only one node re-ceives reads/write requests at any one time.

• RabbitMQ active/passive failover: RabbitMQ is installed on both controller

nodes. Keepalived manages connections to the two nodes, so that only one node is ac-tive at any one time.

• API load balancing: All services that are stateless and can be load balanced (essentially all the APIs and a few others) are installed on both controller nodes. HAProxy is then in-stalled on both nodes, and Keepalived manages connections to HAProxy, which makes HAProxy itself HA. Keystone endpoints and all API access go through Keepalived.

2.6. Availability zones

Availability zones enable you to manage and isolate different nodes within the environ-ment. For example, you may want to isolate different sets of compute nodes to provide dif-ferent resources to customers. If one availability zone experiences downtime, other zones in the cluster are not affected.

When you create a Nova cluster, it is created with a default availability zone, and all com-pute nodes are assigned to that zone. You can create additional availability zones within the cluster as needed.

(10)

3. Installation

This chapter discusses the process for installing an OpenStack environment with the Rackspace Private Cloud cookbooks. For networking, these instructions only apply to the default nova-network configuration.

For information about OpenStack Networking (Neutron) see the Rackspace Private Cloud Networking Guide .

For information about upgrading between Rackspace Private Cloud versions, refer to the Rackspace Private Cloud Upgrade Guide.

The installation process involves the following stages: • Preparing the nodes

• Installing Chef server, the Rackspace Private Cloud cookbooks, and chef-client • Creating a Chef environment and defining attributes

• Setting the node environments

• Applying the controller and compute roles to the nodes

Note

Before you begin, Rackspace recommends that you review Installation prereq-uisites to ensure that you have completed all necessary preparations for the in-stallation process.

3.1. Node preparation

Before you begin, ensure that the OS is up-to-date on the nodes and that an administrative user with the same user name is configured across all nodes in your environment.

3.2. Chef server and cookbooks

Your environment must have a Chef server, the latest versions of the Rackspace Private Cloud cookbooks, and chef-client on each node within the environment. You must install the Chef server node first. chef-client will be installed as part of the node bootstrapping process.

Installation is performed via a curl command, which launches an installation script. The script downloads the packages from GitHub, and uses the packages to install the compo-nents. You can review the scripts in the GitHub repository at the following link https:// github.com/rcbops/support-tools/tree/master/chef-install.

Before you begin, ensure that curl is available, or install it with apt-get install -y curl on Ubuntu or yum install curl on CentOS.

(11)

3.2.1. Chef server installation

To ensure correct server installation, the devices configured as OpenStack cluster nodes on ports 443 and 80 should be able to access the Chef Server device. On distributions running iptables, you will need to enable access on these ports.

By default, the script installs Chef 11.0.8 with a set of randomly generated passwords, and also installs a Knife configuration that is set up for the root user.

The following variables are added to your environment: • CHEF_SERVER_VERSION: defaults to 11.0.8

• CHEF_URL: defaults to https://<hostURL>:443

• CHEF_UNIX_USER: the user for which the Knife configuration is set; defaults to root.

• A set of randomly generated passwords: • CHEF_WEBUI_PASSWORD

• CHEF_AMQP_PASSWORD • CHEF_POSTGRESQL_PASSWORD • CHEF_POSTGRESQL_RO_PASSWORD

Procedure 3.1. To install the Chef server

1. Log in to the device that will be the Chef server and download the install-chef-server.sh script. Run the script:

# curl -s -O https://raw.githubusercontent.com/rcbops/support-tools/ master/chef-install/install-chef-server.sh \

# bash install-chef-server.sh

2. Source the environment file to enable the knife command.

# source /root/.bash_profile

3. Run the following command to ensure that knife is working correctly.

# knife client list

If the command runs successfully, the installation is complete. If the installation fails, you will need to log out of the server and log in again to re-source the environment.

(12)

3.2.2. Rackspace Private Cloud cookbook installation

The Rackspace Private Cloud cookbooks are set up as Git submodules and are hosted at http://github.com/rcbops/chef-cookbooks, with individual cookbook reposito-ries at http://github.com/rcbops-cookbooks.

You can also download the cookbooks from the rcbops GitHub repository without the script. The following procedure describes the download process for the full suite, but you can also download individual cookbook repositories, such as the Nova repository, at https://github.com/rcbops-cookbooks/nova.

Procedure 3.2. To download and install cookbooks from GitHub

1. Log into your Chef server, or on a workstation that has knife access to the Chef server. 2. Verify that the knife.rb configuration file contains the correct cookbook_path

set-ting.

3. Use git clone to download the cookbooks.

# git clone https://github.com/rcbops/chef-cookbooks.git

4. Navigate to the chef-cookbooks directory.

# cd chef-cookbooks

5. Check out the desired version of the cookbooks. The current versions are v4.2.2 and v4.1.3.

# git checkout <version> # git submodule init # git submodule sync # git submodule update

6. Upload the cookbooks to the Chef server.

# knife cookbook upload -a -o cookbooks

7. Apply the updated roles.

# knife role from file roles/*rb

3.3. Installing OpenStack

This section demonstrates a typical Rackspace Private Cloud installation, and includes addi-tional information about customizing or modifying your installation.

(13)

3.3.1. Overview of the configuration

When your configure your Rackspace Private Cloud environment with the Rackspace Pri-vate Cloud cookbooks, the cookbooks will configure a specific set of components into your environment:

• One or two controller nodes that host central services: RabbitMQ, MySQL, and the Hori-zon Dashboard.

• One or more Compute nodes that host Virtual Machines.

• One networking node. You may have a standalone networking node set up if you are us-ing OpenStack Networkus-ing. Networkus-ing roles can also be applied to the Controller node.

Configuration

The Rackspace Private Cloud Cookbooks create a custom OpenStack installation that has been designed by Rackspace:

• MySQL is set up as the database for all OpenStack Services, including Nova, Glance, and Neutron.

• The VRRP provides high availability. • HAproxy provides load balancing. • KVM is used for the hypervisor.

• The network is a flat High Availability network, such as nova-network, or can be Neu-tron-controlled.

3.3.2. Create an environment

The first step is to create an environment on the Chef server. In this example, the knife en-vironment create command is used to create an environment called private-cloud. The

-d flag is used to add a description of the environment.

# knife environment create private-cloud -d "Rackspace Private Cloud OpenStack Environment"

This creates a JSON environment file, which can be directly edited to add attributes specific to your configuration. To edit the environment, run the knife environment edit command:

# knife environment edit private-cloud

This will open a text editor where the environment settings can be modified and override attributes added.

3.3.3. Define network attributes

You must now add a set of override attributes to define the nova, public, and management networks in your environment.

(14)

Note

This information is for configuring nova-network, which is what a Rackspace Private Cloud environment uses by default. If you want to use OpenStack Net-working, see the Networking Guide.

To define override attributes, you will need to run the knife environment edit command. Add a networking section, and substitute your own network information.

The v4.2.2 and v4.1.5 cookbooks use hash syntax to define network attributes. The

syntax is as follows: "override_attributes": { "nova": { "network": { "public_interface": "<publicInterface>" }, "networks": { "public": { "label": "public", "bridge_dev": "<VMNetworkInterface>", "dns2": "8.8.4.4", "ipv4_cidr": "<VMNetworkCIDR>", "bridge": "<networkBridge>", "dns1": "8.8.8.8" } } }, "mysql": { "allow_remote_root": true, "root_network_acl": "%" }, "osops_networks": { "nova": "<novaNetworkCIDR>", "public": "<publicNetworkCIDR>", "management": "<managementNetworkCIDR>" } }

(15)

The following example shows an environment configuration in which all three networks are folded onto a single physical network. This network has an IP address in the 192.0.2.0/24 range. All internal services, API endpoints, and monitoring and management functions run over this network. VMs are brought up on a 198.51.100.0/24 network on eth1, connected to a bridge called br100. "override_attributes": { "nova": { "network": { "public_interface": "br100" }, "networks": { "public": { "label": "public", "bridge_dev": "eth1", "dns2": "8.8.4.4", "ipv4_cidr": "198.51.100.0/24", "bridge": "br100", "dns1": "8.8.8.8" } } }, "mysql": { "allow_remote_root": true, "root_network_acl": "%" }, "osops_networks": { "nova": "192.0.2.0/24", "public": "192.0.2.0/24", "management": "192.0.2.0/24" } }

3.3.4. Installing Chef client

All of the nodes in your OpenStack cluster need to have chef-client installed and configured to communicate with the Chef server. This can be most easily accomplished with the knife

bootstrap command. The nodes on which the OpenStack Object Storage cluster will be

configured should be able to access the Chef server on ports 443 and 80. This will not work if you are behind an HTTP proxy.

Each client node must have a resolvable hostname. If the hostname cannot resolve, the nodes will not be able to check in properly.

Procedure 3.3. Bootstrapping nodes to the Chef server

1. Log in to the Chef server as root.

2. Generate an ssh key with the ssh-keygen command. Accept the defaults when prompted.

3. Use the knife bootstrap command to bootstrap the nodes to the Chef server. This command installs chef-client on the target node. It allows the node to communicate with the server. You will specify the name of the environment, the user name that will be associated with the ssh key, and the IP address of the node.

(16)

For a single controller node:

# knife bootstrap -E <environmentName> -i .ssh/id_rsa_private \ --sudo -x <sshUserName> <nodeIPAddress>

4. After you have completed the bootstrap process on each node, you must add the IP address and host name of the Chef server to the /etc/hosts file on each node. Log

into the first client node and open /etc/hosts with your preferred text editor.

5. Add a line with the Chef server's IP address and host name in the following format:

<chefServerIPAddress> <chefServerHostName>

6. Save the file.

7. Repeat steps 5-6 for each node in the environment.

3.3.5. Adding a controller node

The controller node must be installed before any compute nodes are added. Until the con-troller node chef-client run is complete, the endpoint information will not be pushed back to the Chef server, and the Compute nodes will be unable to locate or connect to infras-tructure services.

A device with the ha-controller1 role assigned will include all core OpenStack services

and should be used even in non-HA environments. For more information about HA, see Controller Node High Availability.

Before you begin this procedure, please ensure you are logged in to the Chef server, and have installed chef-client on the device, as described in Section 3.3.4, “Installing Chef

client” [12].

Procedure 3.4. To install a single controller node

1. Add the ha-controller1 role to the target node's run list.

# knife node run_list add <deviceHostname> 'role[ha-controller1]'

2. Log in to the target node via ssh. 3. Run chef-client on the node.

It will take chef-client several minutes to complete the installation tasks. Chef client will pro-vide output to help you monitor the progress of the installation.

3.3.6. Adding a Compute node

(17)

Procedure 3.5. To install a single Compute node

1. Add the single-compute role to the target node's run list.

# knife node run_list add <deviceHostname> 'role[single-compute]'

2. Log in to the target node via ssh. 3. Run chef-client on the node.

It will take chef-client several minutes to complete the installation tasks. Chef client will pro-vide output to help you monitor the progress of the installation.

Repeat this process on each Compute node. You will also need to run chef-client on each existing Compute node when additional Compute nodes are added.

3.3.7. Controller node high availability

By creating two controller nodes in the environment and applying the ha-controller

roles to them, you can create a pair of controller nodes that provide HA with VRRP and monitored by keepalived. Each service has a VIP of its own, and failover occurs on a ser-vice-by-service basis. Refer to High Availability Concepts for more information about High Availability configuration.

Before you configure HA in your environment, you must allocate IP addresses for the MySQL, RabbitMQ, and haproxy VIPs on an interface available to both controller nodes. You will then add the VIPs to the override attributes.

Note

If you are upgrading your environment from an older configuration in which VIP virtual router ID (vrid) and networks were not defined, you will have to remove the keepalived configurations in /etc/keepalived/conf.d/*

and run chef-client before adding the VIP vrid and network definitions to override_attributes.

3.3.7.1. Havana VIP attribute blocks

These attribute blocks define which VIPs are associated with which service, and they also define the vrid and network for each VIP. The neutron-api VIP only needs to be specified if you are deploying OpenStack Networking.

(18)

The following example shows the attributes for a v4.2.2 (Havana) VIP configuration where the RabbitMQ VIP is 192.0.2.51, the HAProxy VIP is 192.0.2.52, and the MySQL VIP is 192.0.2.53: "override_attributes": { "vips": { "rabbitmq-queue": "192.0.2.51", "ceilometer-api": "192.0.2.52", "ceilometer-central-agent": "192.0.2.52", "cinder-api": "192.0.2.52", "glance-api": "192.0.2.52", "glance-registry": "192.0.2.52", "heat-api": "192.0.2.52", "heat-api-cfn": "192.0.2.52", "heat-api-cloudwatch": "192.0.2.52", "horizon-dash": "192.0.2.52", "horizon-dash_ssl": "192.0.2.52", "keystone-admin-api": "192.0.2.52", "keystone-internal-api": "192.0.2.52", "keystone-service-api": "192.0.2.52", "nova-api": "192.0.2.52", "nova-api-metadata": "192.0.2.52", "nova-ec2-public": "192.0.2.52", "nova-novnc-proxy": "192.0.2.52", "nova-xvpvnc-proxy": "192.0.2.52", "swift-proxy": "192.0.2.52", "neutron-api": "192.0.2.52", "mysql-db": "192.0.2.53", "config": { "192.0.2.51": { "vrid": 1, "network": "public" }, "192.0.2.52": { "vrid": 2, "network": "public" }, "192.0.2.53": { "vrid": 3, "network": "public" } } } }

3.3.7.2. Grizzly VIP attribute blocks

These attribute blocks define which VIPs are associated with which service, and they al-so define the virtual router ID (vrid) and network for each VIP. The quantum-api VIP only needs to be specified if you are deploying OpenStack Networking.

(19)

The following example shows the attributes for a v4.1.n (Grizzly) VIP configuration where the RabbitMQ VIP is 192.0.2.51, the HAProxy VIP is 192.0.2.52, and the MySQL VIP is 192.0.2.53: "override_attributes": { "vips": { "rabbitmq-queue": "192.0.2.51", "cinder-api": "192.0.2.52", "glance-api": "192.0.2.52", "glance-registry": "192.0.2.52", "horizon-dash": "192.0.2.52", "horizon-dash_ssl": "192.0.2.52", "keystone-admin-api": "192.0.2.52", "keystone-internal-api": "192.0.2.52", "keystone-service-api": "192.0.2.52", "nova-api": "192.0.2.52", "nova-ec2-public": "192.0.2.52", "nova-novnc-proxy": "192.0.2.52", "nova-xvpvnc-proxy": "192.0.2.52", "swift-proxy": "192.0.2.52", "quantum-api": "192.0.2.52", "mysql-db": "192.0.2.53", "config": { "192.0.2.51": { "vrid": 1, "network": "public" }, "192.0.2.52": { "vrid": 2, "network": "public" }, "192.0.2.53": { "vrid": 3, "network": "public" } } } }

3.3.7.3. Installing a pair of High Availability Controller nodes

Follow this procedure to edit your environment file and apply the HA controller roles to your controller nodes.

Procedure 3.6. To install a pair of High Availability controller nodes

1. Open the environment file for editing.

# knife environment edit <yourEnvironmentName>

(20)

3. Add the VIP information to the override_attributes.

• If you are deploying a v4.2.2 Havana environment, refer to Havana VIP attributes. • If you are deploying a v4.1.n Grizzly environment, refer to Grizzly VIP attributes. 4. On the first controller node, add the ha-controller1 role.

5. On the second controller node, add the ha-controller2 role.

6. Run chef-client on the first controller node. 7. Run chef-client on the second controller node. 8. Run chef-client on the first controller node again.

3.3.8. Troubleshooting the installation

If the installation is unsuccessful, it can be a result of one of the following issues:

• The node does not have access to the internet. The installation process requires internet access to download installation files. Ensure that the address for the nodes provides ac-cess, and that the proxy information entered is correct. You should also ensure that the nodes have access to a DNS server.

• Your network firewall is preventing internet access. Ensure the IP address that you assign to the Controller is available through the network firewall.

For more troubleshooting information and user discussion, you can also inquire at the Rackspace Private Cloud Support Forum at the following URL:

(21)

4. Integration with OpenStack

Rackspace Private Cloud v4.2.2 offers full OpenStack Metering (Ceilometer) support, includ-ing access to OpenStack statistics through the Horizon dashboard.

4.1. OpenStack metering

The Rackspace Private Cloud Metering implementation is based on a MySQL framework and uses SQL Alchemy. For more information about the parameters involved in this imple-mentation, refer to the OpenStack documentation on Metering configuration options. For a list of database backends and what they support, refer to the OpenStack documentation on choosing a database backend for metering.

Procedure 4.1. Using OpenStack metering

1. Metering statistics are available through the Horizon dashboard. When you log in to the dashboard as the admin user, click on the Resource Usage tab to view the

statis-tics.

2. The following information is available:

• Global Disk Usage: Provides an average of the last 30 days of disk usage, broken down by tenant/project.

• Global Network Traffic Usage: Provides an average of the last 30 days of network traffic usage, broken down by tenant/project.

• Statistics: Provides a graphic represenation of all resources. You can view the usage for individual services, over a range of periods from the last day up to the last year. For more information about Metering, refer to the Ceilometer developer documentation, maintained by OpenStack.

4.2. OpenStack Orchestration

Rackspace Private Cloud v4.2.2 offers a technology preview of OpenStack Orchestration (Heat) implementation, which enables you to manage infrastructure and applications with-in OpenStack clouds.

Note

Rackspace Private Cloud Support does not currently support technology pre-view features. They are not recommended for Rackspace Private Cloud produc-tion environments, and are included for experienced OpenStack users only. OpenStack Orchestration is a service that orchestrates cloud applications onto cloud re-sources using the OpenStack Heat Orchestration Syntax (HOT) template format through an OpenStack ReST API. OpenStack Orchestration also provides compatibility with the AWS CloudFormation template format. More information about Orchestration is available on the OpenStack wiki at https://wiki.openstack.org/wiki/Heat.

(22)

The Rackspace Private Cloud implementation of Orchestration includes the following com-ponents:

• The standard Heat API • The heat-api-cfn API

• The CloudWatch API, which enables metric collection

4.2.1. Installing Orchestration

OpenStack Orchestration is not included in the default controller and all-in-one installa-tions, but you can add Orchestration to your private cloud at any time by applying the

heat-all role to your controller node.

Procedure 4.2. To install OpenStack Orchestration

1. Log into the Chef server or a device that has knife access on the Chef server. 2. Add the heat-all role to the controller node's run list.

# knife node run_list add <deviceHostname> 'role[heat-all]'

3. Log on to the controller node via ssh.

4. Run chef-client on the controller node. It will take chef-client several minutes to com-plete the installation tasks. Chef client will provide output to help you monitor the progress of the installation.

4.2.2. Using Orchestration

OpenStack Orchestration is accessible through the Horizon dashboard and through the command line interface.

Generally, Orchestration interaction through the command line interface provides im-proved error handling and user interaction. Refer to the Heat commands chapter of the OpenStack End User Guide for documentation of the heat client.

The Orchestration page is accessed through the Project tab of the navigation bar. A repos-itory of templates is maintained at https://github.com/openstack/heat-tem-plates; enabling you to develop your own for your environment. When a template is launched, it will create a stack of one or more instances, which can be configured to run ap-plications.

Follow this procedure to launch a stack from a URL, a template file, or by entering template information directly through the Horizon dashboard.

Procedure 4.3. To launch OpenStack Orchestration

1. On the Orchestration page, click the Launch Stack button in the upper right corner of the screen. The Select Template dialog opens.

(23)

2. Select the Template Source and enter the source information: • URL: Enter the URL where the template is located.

• File: Browse to the location of the template file on your workstation. • Direct Input: Enter the template code in the Template Data field.

3. You are prompted to enter information that the template requires to launch the stack. The exact information will vary depending on the template.

4. Click Launch Template.

When the stack is complete, it will appear in the Stacks list. Any instances that have been created by the template will appear on the Instances page.

Click on a stack name to view the following information:

• A network topology diagram. Resources in a healthy state are displayed in green, and those experiencing issues are displayed in red.

• Detailed information about the stack and its parameters.

• A list of resources being used by the stack, as well as detailed information about the re-sources.

(24)

5. Storage

The Glance cookbook used for Rackspace Private Cloud supports OpenStack Image storage in the local file system, in OpenStack Object Storage (Swift), and in Rackspace Cloud Files.

Note

If you change the image storage location from Swift to Cloud Files (or vice ver-sa), you must manually export and import the images.

5.1. Local File Storage

By default, OpenStack Image stores the image files locally on the controller node, and as long as you're using local file storage, you will not have to make any changes to your con-figuration. In the event that you need to switch from a different storage method to the lo-cal file system, follow these steps.

Procedure 5.1. To configure local image storage

1. Log into the controller node with root access and open your preferred text editor and use knife to open the environment file for editing. Add this line:

# knife environment edit <environmentFile>

2. Add the following attributes to the environment.

"glance": { "api": { "default_store": "file" }, "images": [ "cirros" ], "image_upload": true }

3. Run chef-client to commit the change.

# chef-client

(25)

5.2. Rackspace cloud files

To use Rackspace Cloud Files for image storage, you must have an account. To sign up, visit the Rackspace Cloud Files website.

Procedure 5.2. To configure Rackspace Cloud Files image storage

1. Log into the controller node with root access and use the following command to ob-tain your Cloud Files tenant ID:

# curl -s -X POST https://identity.api.rackspacecloud.com/v2.0/tokens \ -d '{"auth": {"passwordCredentials": {"<cloudFilesUsername>": "", \ "password": "<cloudFilesPassword>"}}}' \

-H "Content-type: application/json" | python -mjson.tool | \ grep "tenantId.*Mosso" | head -1

The output of this command is displayed on the screen. Copy and save the tenant ID. 2. Open your preferred text editor and use knife to open the environment file for editing.

Add this line:

3. Add the following attributes to the environment, using the tenant ID that you ob-tained in Step 2 and your Cloud Files username and password.

"glance": { "api": { "default_store": "swift", "swift_store_user": "<cloudFilesTenant_ID:<cloudFilesUsername>", "swift_store_key": "<cloudFilesPassword>", "swift_store_auth_version": "2", "swift_store_auth_address": "https://identity.api.rackspacecloud.com/ v2.0" }, "images": [ "cirros" ], "image_upload": true },

# chef-client

(26)

5.3. Swift storage

To use Swift storage, you must have a Swift cluster configured in your environment. For more about creating and configuring a Swift cluster, see Rackspace Private Cloud Open-Stack Object Storage Installation.

Procedure 5.3. To configure Swift image storage

1. Log into the controller node with root access and open your preferred text editor and use knife to open the environment file for editing. Add this line:

2. Add the following attributes to the environment.

"glance": { "api": { "default_store": "swift" }, "images": [ "cirros" ], "image_upload": true }

# chef-client

(27)

6. Additional resources

These additional resources are designed help you learn more about the Rackspace Private Cloud Software and OpenStack.

• If you are an advanced user and are comfortable with APIs, the OpenStack API documen-tation is available in the OpenStack API Documentation library.

•OpenStack API Quick Start

•Programming OpenStack Compute API •OpenStack Compute Developer Guide •Rackspace Private Cloud Knowledge Center •OpenStack Manuals

•OpenStack API Reference

•OpenStack - Nova Developer Documentation •OpenStack - Glance Developer Documentation •OpenStack - Keystone Developer Documentation •OpenStack - Horizon Developer Documentation •OpenStack - Cinder Developer Documentation

6.1. Document Change History

This version replaces and obsoletes all previous versions. The most recent set of changes are listed in the following table:

Revision Date Summary of Changes

September 25, 2014 • Rackspace Private Cloud v9 Software General Availability release August 28, 2014 • Rackspace Private Cloud v9 Software Limited Availability release

rackspace.com/cloud/private

Rackspace Private Cloud Installation Guide

Table of Contents

1. Preface

1.1. About Rackspace Private Cloud

Note

1.2. Rackspace Private Cloud configuration

1.3. Rackspace Private Cloud support

2. Installation prerequisites

2.1. Preparing for the installation

2.2. Hardware requirements

2.2.1. Chef server requirements

2.2.2. Cluster node requirements

2.3. Software requirements

Note

2.4. Proxy considerations

Procedure 2.1. Configuring proxy environment settings on the nodes

2.5. High Availability

Note

2.6. Availability zones

3. Installation

Note

3.1. Node preparation

3.2. Chef server and cookbooks

3.2.1. Chef server installation

Procedure 3.1. To install the Chef server

3.2.2. Rackspace Private Cloud cookbook installation

Procedure 3.2. To download and install cookbooks from GitHub

3.3. Installing OpenStack

3.3.1. Overview of the configuration

Configuration

3.3.2. Create an environment

3.3.3. Define network attributes

Note

3.3.4. Installing Chef client

Procedure 3.3. Bootstrapping nodes to the Chef server

3.3.5. Adding a controller node

Procedure 3.4. To install a single controller node

3.3.6. Adding a Compute node

Procedure 3.5. To install a single Compute node

3.3.7. Controller node high availability

Note

3.3.7.1. Havana VIP attribute blocks

3.3.7.2. Grizzly VIP attribute blocks

3.3.7.3. Installing a pair of High Availability Controller nodes

Procedure 3.6. To install a pair of High Availability controller nodes

3.3.8. Troubleshooting the installation

4. Integration with OpenStack

4.1. OpenStack metering

Procedure 4.1. Using OpenStack metering

4.2. OpenStack Orchestration

Note

4.2.1. Installing Orchestration

Procedure 4.2. To install OpenStack Orchestration

4.2.2. Using Orchestration

Procedure 4.3. To launch OpenStack Orchestration

5. Storage

Note

5.1. Local File Storage

Procedure 5.1. To configure local image storage

5.2. Rackspace cloud files

Procedure 5.2. To configure Rackspace Cloud Files image storage

5.3. Swift storage

Procedure 5.3. To configure Swift image storage

6. Additional resources

6.1. Document Change History