rackspace.com/cloud/private

Transcription

1 rackspace.com/cloud/private

2 Rackspace Private Cloud ( ) Copyright 2014 Rackspace All rights reserved. This guide is intended to assist Rackspace customers in downloading and installing Rackspace Private Cloud, powered by OpenStack. The document is for informational purposes only and is provided AS IS. RACKSPACE MAKES NO REPRESENTATIONS OR WARRANTIES OF ANY KIND, EXPRESS OR IMPLIED, AS TO THE ACCURACY OR COMPLETENESS OF THE CONTENTS OF THIS DOCUMENT AND RESERVES THE RIGHT TO MAKE CHANGES TO SPECIFICATIONS AND PRODUCT/SERVICES DESCRIPTION AT ANY TIME WITHOUT NOTICE. RACKSPACE SERVICES OFFERINGS ARE SUBJECT TO CHANGE WITHOUT NOTICE. USERS MUST TAKE FULL RESPONSIBILITY FOR APPLICATION OF ANY SERVICES MENTIONED HEREIN. EXCEPT AS SET FORTH IN RACKSPACE GENERAL TERMS AND CONDITIONS AND/OR CLOUD TERMS OF SERVICE, RACKSPACE ASSUMES NO LIABILITY WHATSOEVER, AND DISCLAIMS ANY EXPRESS OR IMPLIED WARRANTY, RELATING TO ITS SERVICES INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTY OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE, AND NONINFRINGEMENT. Except as expressly provided in any written license agreement from Rackspace, the furnishing of this document does not give you any license to patents, trademarks, copyrights, or other intellectual property. Rackspace, Rackspace logo, Fanatical Support, and OpenCenter are either registered trademarks or trademarks of Rackspace US, Inc. in the United States and/or other countries. OpenStack is either a registered trademark or trademark of the OpenStack Foundation in the United States and/or other countries. Third-party trademarks and tradenames appearing in this document are the property of their respective owners. Such third-party trademarks have been printed in caps or initial caps and are used for referential purposes only. We do not intend our use or display of other companies tradenames, trademarks, or service marks to imply a relationship with, or endorsement or sponsorship of us by, these other companies. ii

3 Table of Contents 1. Overview Intended Audience Document Change History Additional Resources Contact Rackspace About Rackspace Private Cloud What is Rackspace Private Cloud? The Rackspace Private Cloud configuration Supported OpenStack features Unsupported OpenStack features Rackspace Private Cloud support Rackspace Private Cloud installation prerequisites and concepts Hardware requirements Chef server requirements Cluster node requirements Software requirements Internet requirements Network requirements Networking in Rackspace Private Cloud cookbooks Preparing for the installation Instance access considerations in nova-network Proxy considerations Configuring proxy environment settings on the nodes Testing proxy settings High availability Availability zones Installing OpenStack with Rackspace Private Cloud tools Prepare the nodes Install Chef server, cookbooks, and chef-client Install Chef server Install Rackspace Private Cloud Cookbooks Install chef-client Installing OpenStack Overview of the configuration Create an environment Define network attributes Set the node environments Add a controller node Controller node high availability Add a compute node Troubleshooting the installation Configuring OpenStack Networking OpenStack Networking concepts Network types Namespaces Metadata OVS bridges OpenStack Networking and high availability iii

4 5.2. OpenStack Networking prerequisites Configuring OpenStack Networking Networking infrastructure Editing the override attributes for Networking Apply the network role Interface Configurations Creating a network Creating a subnet Configuring L3 routers Configuring Load Balancing as a Service (LBaaS) Configuring Firewall as a Service (FWaaS) Configuring VPN as a Service (VPNaaS) Installing a new cluster With OpenStack Networking Troubleshooting OpenStack Networking RPCDaemon RPCDaemon overview RPCDaemon operation RPCDaemon configuration Command line options OpenStack metering OpenStack metering implementation In Rackspace Private Cloud Using OpenStack metering OpenStack Orchestration Installing Orchestration Using Orchestration Accessing the cloud Accessing the controller node Accessing the dashboard Using your logo in the OpenStack dashboard OpenStack client utilities Viewing and setting environment variables Creating an instance in the cloud Image management Uploading AMI images Converting VMDK Linux images Network management Create a project Generate an SSH keypair Update the default security group Create an instance File injection best practice Accessing the instance Logging in to the instance Accessing the instance by SSH Managing floating IP addresses What's next? OpenStack Image Storage Local File Storage Rackspace cloud files Swift storage Glossary of terms iv

5 1. Overview Rackspace has developed a fast, no-charge, and easy way to deploy a Rackspace Private Cloud powered by OpenStack in any data center. This method is suitable for anyone who wants to install a stable, tested, and supportable OpenStack private cloud, and can be used for all scenarios from initial evaluations to production deployments. Two versions are available: Rackspace Private Cloud is based on the OpenStack Havana code base, Rackspace Private Cloud v4.1.3 is based on the OpenStack Grizzly code base Intended Audience This guide is intended for anyone who wants to deploy an OpenStack powered cloud that has been tested and optimized by the OpenStack experts at Rackspace. This document includes an overview of Rackspace Private Cloud and instructions for downloading and deploying Rackspace Private Cloud in the data center of your choice. To use the product and this document, you should have prior knowledge of OpenStack and cloud computing, and basic Linux administration skills Document Change History This version of the guide replaces and obsoletes all previous versions. The most recent changes are described in the following table: Revision Date March 17, 2014 December 18, 2013 November 13, 2013 September 12, 2013 July 31, 2013 July 24, 2013 July 16, 2013 June 25, 2013 April 8, 2013 March 20, 2013 March 6, 2013 November 15, 2012 August 15, 2012 Summary of Changes Rackspace Private Cloud Limited Availability release. Rackspace Private Cloud v4.2.1 Release. Rackspace Private Cloud v4.2.0 Early Access Release. Rackspace Private Cloud v4.1.2 updates. Updates to network override attributes. Updates to HA VIPs. RabbitMQ v4.1.0 to v4.1.2 upgrade instructions. OpenStack Networking on CentOS 6.4. Added information about a known issue with Neutron and Red Hat Enterprise Linux/ CentOS. HA Controller instructions updated. OpenStack Networking concepts and structures updated and placed in separate chapter. Release of Rackspace Private Cloud v Minor edits and corrections. Package update: Change to install command, updated information about HA. Release of Rackspace Private Cloud v3.0. Release of Rackspace Private Cloud v2.0. Added information about Folsom implementation, OpenStack Block Storage, changing the Horizon dashboard, proxy settings, changing rate limits, updating the cookbooks, and configuring OpenStack Image Storage to use Rackspace Cloud Files. Release of Rackspace Private Cloud v1.0. 1

6 1.3. Additional Resources 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 1.4. Contact Rackspace For more information about sales and support, send an to <opencloudinfo@rackspace.com>. If you have feedback about the product and the documentation, send and to <RPCFeedback@rackspace.com>. For the documentation, you can also leave a comment at the Knowledge Center. For more troubleshooting information and user discussion, you can also inquire at the Rackspace Private Cloud Support Forum at products/f/45 2

7 2. About Rackspace Private Cloud This chapter describes the Rackspace Private Cloud configuration and support offerings What is Rackspace Private Cloud? Rackspace offers a tool set that enables users to quickly deploy a private cloud OpenStack cluster configured according to the recommendations of Rackspace OpenStack specialists. Previous versions of Rackspace Private Cloud were packaged in an ISO that contained a full Ubuntu OS and a Chef server running on a virtual machine. Although the ISO was a convenient and simple package, it did not allow large deployments. The user also had no choice of host operating system and Chef server running on a virtual machine was resourceintensive. Rackspace Private Cloud v4.0.0 and later can now be deployed with a Chef-based approach that enables users to create an OpenStack cluster on Ubuntu, CentOS, or Red Hat Enterprise Linux. This version uses installation scripts, which creates a more traditional application experience for the Linux system administrator. It also offers a framework that is capable of being updated without downloading and deploying a whole new ISO The Rackspace Private Cloud configuration The following table lists the OpenStack versions and components supported by the current releases of Rackspace Private Cloud. v4.1.3 OpenStack Grizzly X OpenStack Havana X Compute (Nova) X X Image Service (Glance) X X Dashboard (Horizon) X X Identity (Keystone) X X Virtual Network (Neutron) X X Metering (Ceilometer) X Object Storage (Swift) is available in the Rackspace Private Cloud Object Storage offering. 3

8 The following diagram shows a typical Rackspace Private Cloud Mass Compute reference architecture in which instances reside directly on the Compute nodes. More information about Rackspace Private Cloud reference architectures can be found on the Common Rackspace Private Cloud reference architectures page Supported OpenStack features Rackspace supports features such as floating IP address management, security groups, availability zones, and the python command line clients. The following OpenStack features and configurations are supported: Separated plane configurations NFS and iscsi file storage as backing stores for VM storage VNC Proxy KVM hypervisor Nova Multi Scheduler instead of Filter Schedule Keystone integrated authentication Glance integrated image service Horizon dashboard Cirros, Ubuntu 12.04, and CentOS/RHEL guest instances, to the extent that they can be booted and pinged Single metadata server running on each device Cloud management through OpenStack APIs High availability for all Nova service components and APIs, Cinder, and Keystone, as well as the scheduler, RabbitMQ, and MySQL. Cinder block storage service, documented in Rackspace Private Cloud: OpenStack Block Storage Swift object storage service, available as the Rackspace Private Cloud Object Storage offering. 4

9 Rackspace Private Cloud also supports the use of Rackspace Cloud Files as a back end for OpenStack Image Storage Unsupported OpenStack features The following OpenStack features are not supported: Nova object store Nova volumes Clustered file system solutions Xen and other hypervisors Centralized metadata servers Contents of guest instances after a successful boot Any other OpenStack project, extension, or configuration not explicitly listed as a supported feature or installed component. Rackspace Private Cloud is an evolving product and will continue to be developed and enhanced Rackspace Private Cloud support Rackspace Private Cloud is offered primarily as a "do it yourself" package, at no charge. You can also access the Rackspace Private Cloud Support Forum, at the following URL: The forum is open to all Rackspace Private Cloud users and is moderated and maintained by Rackspace personnel and OpenStack specialists. Rackspace offers 365x24x7 support for Rackspace Private Cloud. If you are interested in purchasing Rackspace Private Cloud Escalation Support or Core Support, or you plan to install on more than 20 nodes, send an to <opencloudinfo@rackspace.com>. 5

10 3. Rackspace Private Cloud installation prerequisites and concepts 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 Hardware requirements Rackspace has tested Rackspace Private Cloud deployment with a physical device for each of the following nodes: A Chef server An OpenStack Nova Controller node Additional physical machines with OpenStack Nova Compute nodes as required If you have different requirements for your environment, contact Rackspace 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 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. Refer to the following table for detailed requirements. Node Type Nova Controller Nova Compute Requirements 16 GB RAM 144 GB disk space Dual socket CPU with dual core, or single socket quad core 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. 6

11 For a list of Private Cloud certified devices, refer to Private Cloud Certified Devices - Compute Software requirements The following table lists the operating systems on which Rackspace Private Cloud has been tested. Operating System Ubuntu Ubuntu and later CentOS 6.3 CentOS 6.4 CentOS 6.5 Red Hat Enterprise Linux 6.0 Tested Rackspace Private Cloud Version All versions None v4.0.0 and earlier v4.1.2 and later and later None It is possible to install Rackspace Private Cloud on untested OSes, but this may cause unexpected issues. If you require OpenStack Networking, Rackspace recommends that you use Rackspace Private Cloud or later with CentOS 6.4 or Ubuntu for the Controller and Networking nodes. The following Ubuntu kernels have been tested: linux-image generic linux-image generic kernel openstack.el6.x86_ Internet requirements Internet access is required to complete the installation, so ensure that the devices that you use have internet access to download the installation files Network requirements A network deployed with the Rackspace Private Cloud cookbooks uses nova-network by default, but OpenStack Networking (Neutron, formerly Quantum) can be manually enabled. For proof-of-concept and demonstration purposes, nova-network will be adequate, but if you intend to build a production cluster and require software-defined networking for any reason, you should use OpenStack Networking, which is designed as a replacement for nova-network. If you want to use OpenStack Networking for your private cloud, you will have to specify it in your Chef environment and configure the nodes appropriately. See Configuring OpenStack Networking for detailed information about OpenStack Networking concepts and instructions for configuring OpenStack Networking in your environment. 7

12 Networking in Rackspace Private Cloud cookbooks The cookbooks are built on the following assumptions: The IP addresses of the infrastructure are fixed. Binding endpoints for the services are best described by the networks to which they are connected. The cookbooks contain definitions for three general networks and what services bind to them. When you install a private cloud and configure the networking, you must specify pre-existing, working networks with addresses already configured on the hosts. They are defined by CIDR range, and any network interface with an address within the named CIDR range is assumed to be included in that network. The CIDRs must be provisioned by your hosting provider or yourself. You can specify the same CIDR for multiple networks. All three networks can use the same CIDR, but this is not recommended in production environments. The following table lists the networks and the services that bind to the IP address within each of these general networks. Network nova Services keystone-admin-api nova-xvpvnc-proxy nova-novnc-proxy public nova-novnc-server graphite-api keystone-service-api glance-api glance-registry nova-api nova-ec2-admin nova-ec2-public nova-volume neutron-api cinder-api ceilometer-api horizon-dash management horizon-dash_ssl graphite-statsd graphite-carbon-line-receiver graphite-carbon-pickle-receiver graphite-carbon-cache-query 8

13 Network Services memcached collectd mysql keystone-internal-api glance-admin-api glance-internal-api nova-internal-api nova-admin-api cinder-internal-api cinder-admin-api cinder-volume ceilometer-internal-api ceilometer-admin-api ceilometer-central The configuration allows you to have either multiple interfaces or VLAN-separated subinterfaces. You can create VLAN-tagged interfaces both in the nova-network configuration (with Linux bridges) or in Neutron (with OVS). Single-NIC deployment also possible. Both multi- and single-nic configurations are described in Configuring OpenStack Networking 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 Nova 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 (Internet/WAN) 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 communication among services such as monitoring and syslog. This may be 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 automatically assigned to VMs. An address from this network will be visible from within your instance on eth0. This network should be dedicated to OpenStack and not shared with other services. 9

14 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 default. 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 instances from other network ranges without the use of floating IPs Instance access considerations in nova-network In a nova-network configuration, by default, the instances that you create in the OpenStack cluster can be publicly accessed via NAT only by assigning floating IP addresses to them. Before you assign a floating IP address to an instance, you must have a pool of addresses to choose from. Your network security team must provision an address range and assign it to your environment. These addresses need to be publicly accessible. Floating IP addresses are not specified during the installation process; once the Controller node is operational, you can add them with the nova-manage floating create --ip_range command. Refer to "Managing Floating IP Addresses". You can also make the instances accessible to other hosts in the network by default by configuring the cloud with a network DMZ. The network DMZ range cannot be the same as the nova network range. Specifying a DMZ enables NAT-free network traffic between the virtual machine instances and resources outside of the nova fixed network. For example, if the nova fixed network is /16 and you specify a DMZ of /12, any devices or hosts in that range will be able to communicate with the instances on the nova fixed network. 10

15 To use the DMZ, you must have at least two NICs on the deployment servers. One NIC must be dedicated to the VM instances Proxy considerations In general, the Rackspace Private Cloud installation instructions assume that none of your nodes are behind a proxy. If they are behind a proxy, review this section before proceeding with the installation. Rackspace has not yet tested a hybrid environment where some nodes are behind the proxy and others are not Configuring proxy environment settings on the nodes You must make your proxy settings available to the entire OS on each node by configuring /etc/environment as follows: $ /etc/environment http_proxy= https_proxy= ftp_proxy= no_proxy=<localhost>,<node1>,<node2> Replace node1 and node2 with the hostnames of your nodes. In all cases, no_proxy is required and must contain a localhost entry. If localhost is missing, the Omnibus Chef Server installation will fail. Ubuntu requires http_proxy and no_proxy at a minimum. CentOS requires http_proxy, https_proxy, and no_proxy for yum packages and key updates. However, because installation methods might change over time, Rackspace recommends that you set as many variables as you can. 11

16 The nodes must also have sudo configured to retain the following environment variables: Defaults env_keep += "http_proxy https_proxy ftp_proxy no_proxy" In Ubuntu, this can be put in a file in /etc/sudoers.d. In CentOS, ensure that your version loads files in /etc/sudoers.d before adding this variable. 12

17 Testing proxy settings You can verify that the proxy settings are correct by logging in and running env and sudo env. You should see the configured http_proxy, https_proxy, ftp_proxy, and no_proxy settings in the output, as in the following example. $ env TERM=screen-256color SHELL=/bin/bash SSH_CLIENT=<ssh-url> SSH_TTY=/dev/pts/0 LC_ALL=en_US http_proxy=<yourproxyurl>:<port> ftp_proxy=<yourproxyurl>:<port> USER=admin PATH=/usr/local/sbin PWD=/home/admin LANG=en_US.UTF-8 https_proxy=<yourproxyurl>:<port> SHLVL=1 HOME=/home/admin no_proxy=localhost,chef-server,client1 LOGNAME=admin SSH_CONNECTION=<sshConnectionInformation> LC_CTYPE=en_US.UTF-8 LESSOPEN= /usr/bin/lesspipe %s LESSCLOSE=/usr/bin/lesspipe %s %s _=/usr/bin/env $ sudo env TERM=screen-256color LC_ALL=en_US http_proxy=<yourproxyurl>:<port> ftp_proxy=<yourproxyurl>:<port> PATH=/usr/local/sbin LANG=en_US.UTF-8 https_proxy=<yourproxyurl>:<port> HOME=/home/admin no_proxy=localhost,chef-server,client1 LC_CTYPE=en_US.UTF-8 SHELL=/bin/bash LOGNAME=root USER=root USERNAME=root MAIL=/var/mail/root SUDO_COMMAND=/usr/bin/env SUDO_USER=admin SUDO_UID=1000 SUDO_GID= High availability Rackspace Private Cloud has the ability to implement support for high availability (HA) for all Nova service components and APIs, Cinder, and Keystone, and Glance, as well as the scheduler, RabbitMQ, and MySQL. HA functionality is powered by Keepalived and HAProxy. 13

18 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 receives 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 active 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 installed on both nodes, and Keepalived manages connections to HAProxy, which makes HAProxy itself HA. Keystone endpoints and all API access go through Keepalived Availability zones Availability zones enable you to manage and isolate different nodes within the environment. For example, you might want to isolate different sets of Compute nodes to provide different 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 Compute nodes are assigned to that zone. You can create additional availability zones within the cluster as needed. 14

19 4. Installing OpenStack with Rackspace Private Cloud tools 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, formerly Quantum) see Configuring OpenStack Networking. For information about upgrading between Rackspace Private Cloud versions, refer to the Rackspace Private Cloud Upgrade. 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 Prerequisites and Concepts to ensure that you have completed all necessary preparations for the installation process Prepare the nodes Before you begin, ensure that the OS is up-to-date on the nodes. Log in to each node and run the appropriate update for the OS and the package manager. You should also have an administrative user (such as admin) with the same user name configured across all nodes that will be part of your environment Install Chef server, cookbooks, and chef-client 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. Installation is performed via a curl command that launches an installation script. The script downloads the packages from GitHub and uses the packages to install the components. You can review the scripts in the GitHub repository at the following link 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. 15

20 Install Chef server The Chef server should be a device that is accessible by the devices that will be configured as OpenStack cluster nodes on ports 443 and 80. On distros running iptables, you may need to enable access on these ports. By default, the script installs Chef 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 CHEF_URL: defaults to 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 4.1. To install the Chef server 1. Log in to the device that will be the Chef server and download and run the installchef-server.sh script. # curl -s -O \ # 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 it does not run successfully, you may need to log out of the server and log in again to re-source the environment. 16

21 Install Rackspace Private Cloud Cookbooks The Rackspace Private Cloud cookbooks are set up as Git submodules and are hosted at individual cookbook repositories at 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 github.com/rcbops-cookbooks/nova. Procedure 4.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 setting. 3. Use git clone to download the cookbooks. # git clone 4. Navigate to the chef-cookbooks directory. # cd chef-cookbooks 5. Check out the desired version of the cookbooks. The current versions are and v # 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 Your Chef cookbooks are now up to date Install 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 eaily accomplished with the knife 17

22 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. Note that 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 4.3. To bootstrap notes 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 and allows it 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. 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. Repeat steps 3-6 for each node in the environment Installing OpenStack At this point, you have now created a configuration management system for your OpenStack cluster, based on Chef, and given Chef the ability to manage the nodes in the environment. You are now ready to use the Rackspace Private Cloud cookbooks to deploy OpenStack. This section demonstrates a typical OpenStack installation, and includes additional information about customizing or modifying your installation Overview of the configuration A typical OpenStack installation configured with Rackspace Private Cloud cookbooks consists of the following components: 18

23 One or two infrastructure controller nodes that host central services, such as rabbitmq, MySQL, and the Horizon dashboard. These nodes will be referred to as Controller nodes in this document. One or more servers that host virtual machines. These nodes will be referred to as Compute nodes. If you are using OpenStack Networking, you may have a standalone network node. Networking roles can also be applied to the Controller node. This is explained in detail in Configuring OpenStack Networking. The cookbooks are based on the following assumptions: All OpenStack services, such as Nova and Glance, use MySQL as their database. High availability is provided by VRRP. Load balancing is provided by haproxy. KVM is the hypervisor. The network will be flat HA as nova-network, or will be Neutron-controlled. More information is available at the Rackspace Private Cloud Reference Architectures page Create an environment The first step is to create an environment on the Chef server. In this example, the knife environment 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 an JSON environment file that 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 Define network attributes You must now add a set of override attributes to define the nova, public, and management networks in your environment. For more information about the information you need to configure networking, refer to Network Requirements. 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 Networking, see Configuring OpenStack Networking. 19

24 To define override attributes, you will need to run the knife environment edit command and add a networking section, substituting your network information. The and v4.1.3 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": " ", "ipv4_cidr": "<VMNetworkCIDR>", "bridge": "<networkbridge>", "dns1": " " } } }, "mysql": { "allow_remote_root": true, "root_network_acl": "%" }, "osops_networks": { "nova": "<novanetworkcidr>", "public": "<publicnetworkcidr>", "management": "<managementnetworkcidr>" } } 20

25 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 /24 range. All internal services, API endpoints, and monitoring and management functions run over this network. VMs are brought up on a /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": " ", "ipv4_cidr": " /24", "bridge": "br100", "dns1": " " } } }, "mysql": { "allow_remote_root": true, "root_network_acl": "%" }, "osops_networks": { "nova": " /24", "public": " /24", "management": " /24" } } Set the node environments To ensure that all changes are made correctly, you must now set the environments of the client nodes to match the node created on the Chef server. While logged on to the Chef server, run the following command: # knife exec -E 'nodes.transform("chef_environment:_default") \ { n n.chef_environment("<environmentnaame>") }' This command will update the environment on all nodes in the cluster. Be aware that if you have any non-openstack nodes in your cluster, their environments will be altered as well Add a controller node The Controller node (also known as an infrastructure node) must be installed before any Compute nodes are added. Until the Controller 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 infrastructure services. 21

26 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. Note Rackspace ONLY sells and supports a dual-controller architecture. Escalation and Core Support customers should always have dual-controller HA configurations. Users who install a single-controller cloud will not be supported by Rackspace Support. Contact your Rackspace Support representative for more information. This procedure assumes that you have already installed chef-client on the device, as described in Install Chef Client, and that you are logged in to the Chef server. Procedure 4.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 provide output to help you monitor the progress of the installation 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 service-by-service basis. Refer to High Availability Concepts for more information about HA 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 vrid and networks were not defined, you may 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. 22

27 Havana VIP attribute blocks These attribute blocks define which VIPs are associated with which service, and they also define the virtual router ID (vrid) and network for each VIP. The neutron-api VIP only needs to be specified if you are deploying OpenStack Networking. The following example shows the attributes for a (Havana) VIP configuration where the RabbitMQ VIP is , the HAProxy VIP is , and the MySQL VIP is : "override_attributes": { "vips": { "rabbitmq-queue": " ", "ceilometer-api": " ", "ceilometer-central-agent": " ", "cinder-api": " ", "glance-api": " ", "glance-registry": " ", "heat-api": " ", "heat-api-cfn": " ", "heat-api-cloudwatch": " ", "horizon-dash": " ", "horizon-dash_ssl": " ", "keystone-admin-api": " ", "keystone-internal-api": " ", "keystone-service-api": " ", "nova-api": " ", "nova-api-metadata": " ", "nova-ec2-public": " ", "nova-novnc-proxy": " ", "nova-xvpvnc-proxy": " ", "swift-proxy": " ", "neutron-api": " ", "mysql-db": " ", } } "config": { " ": { "vrid": 1, "network": "public" }, " ": { "vrid": 2, "network": "public" }, " ": { "vrid": 3, "network": "public" } } 23

28 Grizzly VIP attribute blocks These attribute blocks define which VIPs are associated with which service, and they also 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. The following example shows the attributes for a v4.1.n (Grizzly) VIP configuration where the RabbitMQ VIP is , the HAProxy VIP is , and the MySQL VIP is : "override_attributes": { "vips": { "rabbitmq-queue": " ", "cinder-api": " ", "glance-api": " ", "glance-registry": " ", "horizon-dash": " ", "horizon-dash_ssl": " ", "keystone-admin-api": " ", "keystone-internal-api": " ", "keystone-service-api": " ", "nova-api": " ", "nova-ec2-public": " ", "nova-novnc-proxy": " ", "nova-xvpvnc-proxy": " ", "swift-proxy": " ", "quantum-api": " ", "mysql-db": " ", } } "config": { " ": { "vrid": 1, "network": "public" }, " ": { "vrid": 2, "network": "public" }, " ": { "vrid": 3, "network": "public" } } 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. 24

29 Procedure 4.5. To install a pair of High Availability controller nodes 1. Open the environment file for editing. # knife environment edit <yourenvironmentname> 2. Locate the override_attributes section. 3. Add the VIP information to the override_attributes. If you are deploying a 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. # knife node run_list add <devicehostname> 'role[ha-controller1]' 5. On the second Controller node, add the ha-controller2 role. # knife node run_list add <devicehostname> 'role[ha-controller2]' 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 Add a compute node The Compute nodes can be installed after the Controller node installation is complete. Procedure 4.6. 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 provide 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. 25

30 Troubleshooting the installation If the installation is unsuccessful, it may be due to one of the following issues. The node does not have access to the Internet. The installation process requires Internet access to download installation files, so ensure that the address for the nodes provides that access and that the proxy information that you 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: 26

31 5. Configuring OpenStack Networking A network deployed with the Rackspace Private Cloud cookbooks uses nova-network by default, but OpenStack Networking (Neutron) can be manually enabled. This section discusses the concepts behind the Rackspace deployment of Neutron and provides instructions for configuring it in your cluster. Note When using OpenStack Networking (Neutron), Controller nodes with Networking features and standalone Networking nodes require namespace kernel features which are not available in the default kernel shipped with RHEL 6.4, CentOS 6.4, and older versions of these operating systems. More information about Neutron limitations is available in the OpenStack documentation, and more information about RedHat-derivative kernel limitations is provided in the RDO FAQ. If you require OpenStack Networking using these features, Rackspace recommends that you use Rackspace Private Cloud v with CentOS 6.4, or Ubuntu for the Controller and Networking nodes. On CentOS 6.4, after applying the single-network-node role to the device, you must reboot it to use the appropriate version of the CentOS 6.4 kernel OpenStack Networking concepts The Rackspace Private Cloud cookbooks deploy OpenStack Networking components on the Controller, Compute, and Network nodes in the following configuration: Controller node: hosts the Neutron server service, which provides the networking API and communicates with and tracks the agents. Network Node: DHCP agent: spawns and controls dnsmasq processes to provide leases to instances. This agent also spawns neutron-ns-metadata-proxy processes as part of the metadata system. Metadata agent: Provides a metadata proxy to the nova-api-metadata service. The neutron-ns-metadata-proxy direct traffic that they receive in their namespaces to the proxy. OVS plugin agent: Controls OVS network bridges and routes between them via patch, tunnel, or tap without requiring an external OpenFlow controller. L3 agent: performs L3 forwarding and NAT. Compute node: has an OVS plugin agent 27

32 Note Network types You can use the single-network-node role alone or in combination with the ha-controller1 or single-compute roles. The OpenStack Networking configuration provided by the Rackspace Private Cloud cookbooks allows you to choose between VLAN or GRE isolated networks, both providerand tenant-specific. From the provider side, an administrator can also create a flat network. The type of network that is used for private tenant networks is determined by the network_type attribute, which can be edited in the Chef override_attributes. This attribute sets both the default provider network type and the only type of network that tenants are able to create. Administrators can always create flat and VLAN networks. GRE networks of any type require the network_type to be set to gre Namespaces For each network you create, the Network node (or Controller node, if combined) will have a unique network namespace (netns) created by the DHCP and Metadata agents. The netns hosts an interface and IP addresses for dnsmasq and the neutron-ns-metadata-proxy. You can view the namespaces with the ip netns [list] command, and can interact with the namespaces with the ip netns exec <namespace> <command> command Metadata Not all networks or VMs need metadata access. Rackspace recommends that you use metadata if you are using a single network. If you need metadata, you will need to enable metadata route injection when creating a subnet. If you need to use a default route and provide instances with access to the metadata route, refer to Creating a Subnet for more information. Note that this approach will not provide metadata on cirros images. However, booting a cirros instance with nova boot --configdrive will bypass the metadata route requirement OVS bridges An OVS bridge for provider traffic is created and configured on the nodes where singlenetwork-node and single-compute are applied. Bridges are created, but physical interfaces are not added. An OVS bridge is not created on a Controller-only node. When creating networks, you can specify the type and properties, such as Flat vs. VLAN, Shared vs. Tenant, or Provider vs. Overlay. These properties identify and determine the behavior and resources of instances attached to the network. The cookbooks will create bridges for the configuration that you specify, although they do not add physical interfaces to provider bridges. For example, if you specify a network type of GRE, a br-tun tunnel bridge will be created to handle overlay traffic. 28

33 OpenStack Networking and high availability OpenStack Networking has been made HA as of Rackspace Private Cloud v 4.2.0, and has been tested on Ubuntu and CentOS 6.4. For an HA configuration, you must configure the OpenStack networking roles on the Controller node. Do not use a standalone Network node if you require OpenStack Networking to be HA. For more information about HA, refer to Controller Node High Availability OpenStack Networking prerequisites If you are using OpenStack Networking, you will have to specify it in your Chef environment. You should also have the following information: The Nova network CIDR The public network CIDR The management network CIDR The name of the Nova cluster The password for an OpenStack administrative user The nova, public, and management networks must be pre-existing, working networks with addresses already configured on the hosts. They are defined by CIDR range, and any network interface with an address within the named CIDR range is assumed to be included in that network. The CIDRs must be provisioned by your hosting provider or yourself. You can specify the same CIDR for multiple networks. All three networks can use the same CIDR, but this is not recommended in production environments. The following table lists the networks and the services that bind to the IP address within each of these general networks. Network nova Services keystone-admin-api nova-xvpvnc-proxy nova-novnc-proxy public nova-novnc-server graphite-api keystone-service-api glance-api glance-registry nova-api nova-ec2-admin nova-ec2-public nova-volume 29