Chapter 5. Deploying the OpenStack Services

Contents

5.1. Barclamp
5.2. Deploying the Database
5.3. Deploying Keystone
5.4. Deploying Swift (optional)
5.5. Deploying Ceph (optional, unsupported)
5.6. Deploying Glance
5.7. Deploying Nova
5.8. Deploying the Nova Dashboard
5.9. How to Proceed

Once the nodes are installed and configured you can start deploying the OpenStack services in order to finalize the installation. The services need to be deployed in a given order, because they depend on one another. Deployment is done from the Crowbar Web interface through recipes, so-called Barclamps.

The services controlling the cloud (including storage management and control services) need to be installed on the Controller Node. However, you may not use your Controller Node as a compute or storage host. Here is a list with services that may not be installed on the Controller Node: Swift-storage, Ceph-store, Nova-multi-compute. These services need to be installed on dedicated nodes.

The OpenStack services need to be deployed in the following order. For general instructions on how to edit and deploy Barclamp, refer to Section 5.1, “Barclamp”. Deploying Swift and Ceph is optional; all other services must be deployed.

  1. Deploying the Database

  2. Deploying Keystone

  3. Deploying Swift (optional)

  4. Deploying Ceph (optional, unsupported)

    [Important]Ceph not Supported

    As of SUSE Cloud 1.0, Ceph is not officially supported but rather included as a technical preview, so using Nova Volume instead is recommended.

  5. Deploying Glance

5.1. Barclamp

The OpenStack services are automatically installed on the nodes by using so-called Barclamps—a set of recipes, templates, and installation instructions. All existing Barclamps can be accessed from the Crowbar Web interface by clicking on Barclamps. To edit a Barclamp, proceed as follows:

  1. Open a browser and point it to the Crowbar Web interface available at port 3000 of the Administration Server, for example http://192.168.124.10:3000/. Log in as user crowbar. The password defaults to crowbar, if you have not changed it.

    Click Barclamps to open the All Barclamps menu. Alternatively you may filter the list to Crowbar or OpenStack Barclamps by choosing the respective option from Barclamps. The Crowbar Barclamps contain general recipes for setting up and configuring all nodes, while the OpenStack are dedicated to OpenStack service deployment and configuration.

  2. Click a Barclamp's name. You can either Create a proposal or Edit an existing one.

    When creating a new proposal, give it a meaningful name and description. You can create several proposals, for example, for testing purposes, but only one at a time can be deployed.

    Most OpenStack Barclamps consist of two sections: the Attributes section lets you change the configuration, and the Node Deployment section lets you choose onto which nodes to deploy the Barclamp.

  3. To edit the Attributes section, change the values via the Web form. Alternatively you can directly edit the configuration file by clicking Raw.

    [Warning]Raw Mode

    Only use the Raw mode in case an option cannot be changed via Web form. Raw mode does not perform any syntax checks.

    If you switch between Raw mode and Web form (Custom mode), make sure to Save your changes before switching, otherwise they will be lost.

    In the Node Deployment section of the OpenStack Barclamp you can drag and drop nodes from the Available Nodes column to the desired role. You need to drop the node onto the role name. Do not drop a node onto the input field—this is rather used to filter the list of Available Nodes!

    One or more nodes are usually automatically pre-selected for available roles. If this pre-selection does not meet your requirements, remove it before dragging new nodes to the role. To remove a node from a role, click the respective Remove icon.

  4. To save and deploy your edits, click Apply. To just save your changes without deploying them, click Save. To remove the complete proposal, click Delete. A proposal that already has been deployed can only be deleted manually, see Section 5.1.1, “Deactivate a Proposal that Already has been Deployed” for details.

    If you deploy a proposal onto a node where a previous one is still active, the new proposal will overwrite the old one.

    [Note]Wait Until a Proposal has been Deployed

    Deploying a proposal might take some time (up to several minutes). It is strongly recommended to always wait until you see the note Successfully applied the proposal before proceeding on to the next proposal.

[Warning]Barclamp Deployment Failure

In case the deployment of a Barclamp fails, make sure to fix the reason that has caused the failure and deploy the Barclamp again. Refer to the respective troubleshooting section at Section 6.1.2, “OpenStack Node Deployment” for help. A deployment failure may leave your node in an inconsistent state.

5.1.1. Deactivate a Proposal that Already has been Deployed

To finally deactivate a proposal that already has been deployed, you first need to Deactivate it in the Crowbar Web interface. Run the following commands as root on the Administration Server afterwards:

P_NAME="proposal_name_to_delete"
SERVICE="service_name"
crowbar $SERVICE proposal delete $P_NAME
crowbar $SERVICE delete $P_NAME

proposal_name_to_delete needs to be replaced by the name of the proposal you want to delete. service_name needs to be replaced by one of the following strings representing the OpenStack services: ceph, database, glance, keystone, nova_dashboard, nova, swift.

5.2. Deploying the Database

The very first service that needs to be deployed is the Database. The database service is used by all other services. It must be installed on the Controller Node.

SUSE Cloud only supports PostgreSQL as an SQL Engine, so this value must not be changed.

5.3. Deploying Keystone

Keystone is another core component that is used by all other OpenStack services. It provides authentication and authorization services. Keystone needs to be installed on the Controller Node. You can configure the following parameters of this Barclamp:

SQL Engine

Must be set to PostgreSQL/MySQL. This is the default.

SQL Instance

Name of the proposal you deployed in the previous step (see Section 5.2, “Deploying the Database”). The default value should be correct.

Default Tenant

Tenant for the users. Do not change the default value of openstack.

Regular User/Administrator Username/Password

Username and password for the regular user and the administrator. Both accounts can be used to log in to the SUSE Cloud Dashboard to manage Keystone users and access.

Administrator Token (long-lived)

The permanent administrator token (random string).

Administrator Token Expiration

Expiration Date for the administrator token. Must be entered in the form YYYY-MM-DDTHH:MM, e.g. 2015-03-31T12:00.

Security Attributes

When sticking with the default value HTTP, public communication will not be encrypted. Choose HTTPS to use SSL for encryption and specify the path to the certificate files. Note that you need to create and copy the certificate prior to deploying Keystone, see Section 4.3.3, “Enabling SSL” for instructions.

5.4. Deploying Swift (optional)

Swift adds an object storage service to SUSE Cloud that lets you store single files such as images or snapshots. It offers high data security by storing the data redundantly on a pool of Storage Nodes—therefore Swift needs to be installed on at least two dedicated nodes.

It is recommended not to change the defaults in the Barclamp proposal, unless you know exactly what you requir. However you should change the Cluster Admin Password. If you plan to change the Zone value, it is important to know that you need at least as many Storage Nodes as Zones.

The Swift service consists of three different roles:

Swift-ring-compute

The ring maintains the information about the location of objects, replicas, and devices. It can be compared to an index, that is used by various OpenStack services to look up the physical location of objects. Swift-ring-compute must only be installed on a single node; it is recommended to use the Controller Node.

Swift-proxy-acct

The Swift proxy server takes care of routing requests to Swift. Installing a single instance of Swift-proxy-acct on the Controller Node is recommended.

Swift-storage

The virtual object storage service. Install this role on all dedicated Swift Storage Nodes (at least two), but not on any other node.

[Warning]Swift-storage Needs Dedicated Machines

Never install the Swift-storage service on a node that runs other OpenStack services.

5.5. Deploying Ceph (optional, unsupported)

Ceph adds a redundant block storage service to SUSE Cloud. It lets you store persistent devices that can be mounted from instances. It offers high data security by storing the data redundantly on a pool of Storage Nodes—therefore Ceph needs to be installed on at least two dedicated nodes.

For more information on the Ceph project, vist http://ceph.com/.

[Important]Ceph not Supported

As of SUSE Cloud 1.0, Ceph is not officially supported but rather included as a technical preview, so using Nova Volume instead is recommended.

The Ceph Barclamp only has one configuration option: telling Ceph which devices to use on the nodes. Edit the Barclamp in Raw and search for the following lines

  "devices": [
   
  ],

Add a comma-separated list of devices that should be used by Ceph. For example:

  "devices": [
    "/dev/sdb", "/dev/sdc", "/dev/sdd"
  ],
[Important]Devices

Not all of the devices used for Ceph need to exist on all nodes. All devices from a node matching the list will be used. They must not be mounted prior to deploying Ceph. Any data stored on these devices will be lost.

The Ceph service consists of three different roles:

Ceph-mon-master

Master cluster monitor daemon for the Ceph distributed file system. Ceph-mon-master must only be installed on a single node; it is recommended to use the Controller Node.

Ceph-mon

Cluster monitor daemon for the Ceph distributed file system. Ceph-mon needs to be installed on two or four Storage Nodes.

[Important]Number of Ceph Monitor Nodes

In addition to the node running the Ceph-mon-master service an additional two or four nodes also need to run the Ceph-mon service. The sum of the Ceph-mon-master and the Ceph-mon nodes must always be an odd number (either three or five).

Nodes running Ceph-mon cannot be deleted or temporarily be disabled.

Ceph-store

The virtual block storage service. Install this role on all dedicated Ceph Storage Nodes (at least two), but not on any other node.

[Warning]Ceph-store Needs Dedicated Machines

Never deploy Ceph-store on a node that runs other non-Ceph OpenStack services. The only service that may be deployed together with it is Ceph-mon.

Deploying Ceph requires to perform the steps in a given order:

  1. Edit the Barclamp proposal to specify the devices to be used by Ceph as described above.

  2. Drag and drop a node (for example, the Controller Node) to the Ceph-mon-master role.

  3. Drag and drop two or four nodes to the Ceph-mon role. Note that the maximum number of Ceph-mon nodes cannot exceed four and that the sum of Ceph-mon-master and Ceph-mon nodes must be odd.

  4. Drag and drop all dedicated Ceph Storage Nodes to the Ceph-store (at least two). You may also use the nodes with the Ceph-mon roles, but not the Ceph-mon-master node (you can add that one later).

  5. Click Apply to deploy your proposal. This can take some time.

  6. If you also want to use the Ceph-mon-master as a Storage Node, drag and drop it to the Ceph-store role and click Apply again. Note that it is not recommended to use the Controller Node for non-management purposes such as storage or compute.

5.6. Deploying Glance

Glance provides discovery, registration, and delivery services for virtual disk images. An image is needed to start an instance—it is its pre-installed root-partition. All images you want to use in your cloud to boot instances from, are provided by Glance.

Glance should be deployed onto the Controller Node. There are a lot of options to configure Glance. The most important ones are explained below—for a complete reference refer to http://github.com/dellcloudedge/crowbar/wiki/Glance--barclamp.

Image Store Directory

Directory in which all images uploaded to Glance are stored. If you want to put the images onto a separate partition or volume, you need to mount this partition or volume on the Controller Node prior to deploying the Glance proposal (see Section 4.3.1, “ Providing a Volume or Separate Partition for the Glance Image Repository ”). Specify the mount point of the partition or volume here.

Security Attributes

When sticking with the default value HTTP, public communication will not be encrypted. Choose HTTPS to use SSL for encryption and specify the path to the certificate files. Note that you need to create and copy the certificate prior to deploying Glance, see Section 4.3.3, “Enabling SSL” for instructions.

API/Registry Bind to All Addresses

Set these two options to true to enable users to upload images to Glance. If unset, only the operator will be able to upload images.

Caching

Enable and configure image caching in this section. By default, image caching is disabled. Learn more about Glance's caching feature at http://docs.openstack.org/developer/glance/cache.html.

5.7. Deploying Nova

Nova provides key services for managing the SUSE Cloud, sets up the Compute Nodes, and provides a block storage service that either makes use of Ceph (if deployed) or uses local disks. There are a lot of options to configure Nova. The most important ones are explained below—for a complete reference refer to https://github.com/dellcloudedge/crowbar/wiki/Nova--barclamp. You will also find details about Nova's network modes on that page.

Hypervisor

Choose between the KVM and Xen hypervisors (other available options are currently not supported by SUSE). As of SUSE Cloud 1.0 choosing more than one hypervisor is not supported.

Choose device for nova-volume storage volume group

In case you have not deployed Ceph, Nova Volume will use a single device on the contrnode; to provide block storage. Specify which device to use with this option. If Ceph has been deployed, it is used automatically and you will not be able to choose any disks here.

[Note]Nova Volume

Nova Volume only runs on the host onto which Nova-multi-controller is deployed. Make sure the chosen device is equipped with enough disk space (a RAID is strongly recommended). See Section 2.3.1, “Cloud Storage Services” for more information.

Security Attributes

When sticking with the default value HTTP, public communication will not be encrypted. Choose HTTPS to use SSL for encryption and specify the path to the certificate files. Note that you need to create and copy the certificate prior to deploying Nova, see Section 4.3.3, “Enabling SSL” for instructions.

noVNC Security Attributes

After having started an instance you can display its VNC console in the Nova Dashboard via browser using the noVNC implementation. By default this connection is not encrypted and can potentially be eavesdropped. To encrypt it, you can make use of SSL by setting noVNC via SSL to true. If you do not specify any additional certificates, the same ones as for Nova will be used.

The Nova service consists of two different roles:

Nova-multi-controller

Distributing and scheduling the instances is managed by the Nova-multi-controller. It also provides networking and messaging services. Nova-multi-controller needs to be installed on the Controller Node.

Nova-multi-compute

Provides the hypervisor (KVM or Xen) and tools needed to manage the instances. Nova-multi-compute needs to be installed on every Compute Node. The Compute Nodes are the workhorses of the cloud—each instance is started on a Compute Node.

5.8. Deploying the Nova Dashboard

The last service that needs to be deployed is the Nova Dashboard. It provides a Web interface for users to start and stop instances and for administrators to manage users, groups, roles, etc. Nova Dashboard should be installed on the Controller Node. The following attributes can be configured:

SQL Engine

Must be set to PostgreSQL/MySQL. This is the default.

SQL/Keystone Instance

Name of the proposal for Database and Keystone you deployed in the previous steps. The default value should be correct.

Disable SSL Certification Verification

Usually SSL certificates are checked for whether they have been signed by a trusted organization. Use this option to turn off checks. Useful in testing environments when using self-signed certificates. In production environments you should always use signed certificates and set this option to false (default).

Apache Attributes

When sticking with the default value HTTP equals true, public communication will not be encrypted. Set HTTPS to true to use SSL for encryption and specify the path to the certificate files. Note that you need to create and copy the certificate prior to deploying Nova Dashboard, see Section 4.3.3, “Enabling SSL” for instructions.

5.9. How to Proceed

With a successful deployment of the Nova Dashboard, the SUSE Cloud installation is finished. In order to be able to test your setup by starting an instance one last step remains to be done—uploading an image to the Glance service. Refer to Section “Managing Images” (Chapter 2, Using OpenStack Command Line Interfaces, ↑User Guide for Administrators) for instructions. Images for SUSE Cloud can be built in SUSE Studio—see this blog post for details: http://blog.susestudio.com/2012/10/kvm-build-format-suse-cloud-support.html.

Now you can hand over to the cloud administrator to set up users, roles, flavors, etc.— refer to the User Guide for Administrators (↑User Guide for Administrators) for details.


SUSE Cloud Deployment Guide 1.0