SUSE Cloud 3

Deployment Guide

Publication Date 05 May 2014

AuthorsTanja Roth, Frank Sundermeyer

Copyright © 2006–2014 Novell, Inc. and contributors. All rights reserved.

Licensed under the Apache License, Version 2.0 (the "License"); you may not use this file except in compliance with the License. You may obtain a copy of the License at http://www.apache.org/licenses/LICENSE-2.0 Unless required by applicable law or agreed to in writing, software distributed under the License is distributed on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the License for the specific language governing permissions and limitations under the License.

For Novell trademarks, see the Novell Trademark and Service Mark list http://www.novell.com/company/legal/trademarks/tmlist.html. All other third party trademarks are the property of their respective owners. A trademark symbol (®, ™ etc.) denotes a Novell trademark; an asterisk (*) denotes a third party trademark.

All information found in this book has been compiled with utmost attention to detail. However, this does not guarantee complete accuracy. Neither Novell, Inc., SUSE LINUX Products GmbH, the authors, nor the translators shall be held liable for possible errors or the consequences thereof.


Contents

About This Guide
1. Available Documentation
2. Feedback
3. Documentation Conventions
4. About the Making of This Manual
1. The SUSE Cloud Architecture
1.1. The Administration Server
1.2. The Control Node(s)
1.3. The Compute Nodes
1.4. The Storage Nodes
1.5. HA Setup
2. Considerations and Requirements
2.1. Network
2.2. Product and Update Repositories
2.3. Persistent Storage
2.4. SSL Encryption
2.5. Hardware Requirements
2.6. Software Requirements
2.7. High Availability
2.8. Summary: Considerations and Requirements
3. Installing and Configuring the Administration Server
3.1. Operating System Installation
3.2. Post-Installation Configuration
4. Installing the OpenStack Nodes
4.1. Preparations
4.2. Node Installation
4.3. Post-Installation Configuration
4.4. Editing Allocated Nodes
5. Deploying the OpenStack Services
5.1. Barclamps
5.2. Deploying Pacemaker (Optional, HA Setup Only)
5.3. Deploying the Database
5.4. Deploying Keystone
5.5. Deploying RabbitMQ
5.6. Deploying Ceph (optional, unsupported)
5.7. Deploying Swift (optional)
5.8. Deploying Glance
5.9. Deploying Cinder
5.10. Deploying Neutron
5.11. Deploying Nova
5.12. Deploying Horizon (OpenStack Dashboard)
5.13. Deploying Ceilometer
5.14. Deploying Heat
5.15. How to Proceed
6. SUSE Cloud Maintenance
6.1. Keeping the Nodes Up-to-date
6.2. Upgrading from SUSE Cloud 2.0 to SUSE Cloud 3
6.3. Upgrading to an HA Setup
6.4. Backing Up and Restoring the Administration Server
7. Troubleshooting and Support
7.1. FAQ
7.2. Support
A. Documentation Updates
A.1. April 21, 2014 (Maintenance Release SUSE Cloud 3)
A.2. February 17, 2014 (Initial Release SUSE Cloud 3)
A.3. September 25, 2013 (Maintenance Release SUSE Cloud 2.0)
A.4. September 11, 2013 (Initial Release SUSE Cloud 2.0)
B. Log Files
B.1. On the Administration Server
B.2. On All Other Crowbar Nodes
B.3. On the Control Node
B.4. On Compute Nodes
B.5. On Nodes with Ceph barclamp
C. Roles, Services and Start/Stop Scripts in SUSE Cloud
D. The Network Barclamp Template File
D.1. Editing network.json
D.2. Global Attributes
D.3. Interface Map
D.4. Network Conduits
D.5. Network Definitions
E. Setting up a Netboot Environment for Microsoft* Windows
E.1. Requirements
E.2. Providing a Hyper-V Netboot Environment
F. VMware vSphere Installation Instructions
F.1. Requirements
F.2. Preparing the VMware vCenter Server
F.3. Finishing the Nova Compute VMware node Installation
G. Using Cisco Nexus Switches with Neutron
G.1. Requirements
G.2. Deploying Neutron with the Cisco Plugin
Terminology

List of Figures

1.1. SUSE Cloud Infrastructure
2.1. SUSE Cloud Network: Overview
2.2. SUSE Cloud Network: Details
3.1. YaST Crowbar Setup: User Settings
3.2. YaST Crowbar Setup: Network Settings
3.3. YaST Crowbar Setup: Network Settings for the BMC Network
3.4. YaST Crowbar Setup: Network Settings for the Bastion Network
3.5. YaST Crowbar Setup: Repository Settings
3.6. Crowbar Web Interface: Initial State
4.1. Discovered Nodes
4.2. Grouping Nodes
4.3. Editing a Single Node
4.4. Bulk Editing Nodes
4.5. All Nodes Have Been Installed
4.6. SUSE Updater barclamp: Configuration
4.7. SUSE Updater barclamp: Node Deployment
4.8. SUSE Manager barclamp
4.9. NFS barclamp
4.10. Editing an NFS barclamp Proposal
4.11. The SSL Dialog
4.12. Node Information
5.1. The Pacemaker Barclamp
5.2. The Pacemaker Barclamp: Node deployment Example
5.3. Available Clusters in the Deployment Section
5.4. The Database Barclamp
5.5. The Keystone Barclamp
5.6. The SSL Dialog
5.7. The Keystone Barclamp: Raw Mode
5.8. The RabbitMQ Barclamp
5.9. The Ceph Barclamp
5.10. The Swift Barclamp
5.11. The Swift Barclamp: Node Deployment Example
5.12. The Glance Barclamp
5.13. The Cinder Barclamp
5.14. The Cinder Barclamp: Node Deployment Example
5.15. The Neutron Barclamp
5.16. The Neutron barclamp
5.17. The Nova Barclamp
5.18. The Nova Barclamp: Node Deployment Example with Three KVM Nodes
5.19. The Horizon Barclamp
5.20. The Ceilometer Barclamp
5.21. The Heat Barclamp
F.1. The Nova barclamp: VMware Configuration
G.1. The Neutron barclamp: Cisco Plugin

List of Tables

2.1. 192.168.124.0/24 (Admin/BMC) Network Address Allocation
2.2. 192.168.125/24 (Storage) Network Address Allocation
2.3. 192.168.123/24 (Private Network/nova-fixed) Network Address Allocation
2.4. 192.168.126/24 (Public Network nova-floating, public) Network Address Allocation
2.5. 192.168.130/24 (Software Defined Network) Network Address Allocation
3.1. Separate BMC Network Example Configuration
3.2. Example Addresses for a Bastion Network
3.3. SMT Repositories for SUSE Cloud
3.4. Additional SMT Repositories for an HA setup (optional)
3.5. Local Product Repositories for SUSE Cloud
3.6. Local Update Repositories for SUSE Cloud
3.7. Additional Local Update Repositories for an HA setup (optional)
C.1.

List of Examples

D.1. Changing the Network Interface Order on a Machine with four NICs
D.2. Network Modes for Different NIC Numbers
D.3. Network Modes for Certain Roles
D.4. Network Modes for Certain Machines
G.1. Exclusively Mapping nova-fixed to conduit intf1 in dual mode

About This Guide

SUSE® Cloud is an open source software solution that provides the fundamental capabilities to deploy and manage a cloud infrastructure based on SUSE Linux Enterprise. SUSE Cloud is powered by OpenStack, the leading community-driven, open source cloud infrastructure project. It seamlessly manages and provisions workloads across a heterogeneous cloud environment in a secure, compliant, and fully-supported manner. The product tightly integrates with other SUSE technologies and with the SUSE maintenance and support infrastructure.

In SUSE Cloud, there are several high-level user roles (or viewpoints) that we need to discriminate:

SUSE Cloud Operator

Installs and deploys SUSE Cloud, starting with bare-metal, then installing the operating system and the OpenStack components. For detailed information about the operator's tasks and how to solve them, refer to SUSE Cloud Deployment Guide.

SUSE Cloud Administrator

Manages projects, users, images, flavors, and quotas within SUSE Cloud. For detailed information about the administrator's tasks and how to solve them, refer to SUSE Cloud Admin User Guide.

SUSE Cloud User

End user who launches and manages instances, can create snapshots, and use volumes for persistent storage within SUSE Cloud. For detailed information about the user's tasks and how to solve them, refer to SUSE Cloud End User Guide.

This guide provides cloud operators with the information needed to deploy and maintain SUSE Cloud administrative units, the Administration Server, and the Control Node, as well as the Compute and Storage Nodes. The Administration Server provides all services needed to manage and deploy all other nodes in the cloud. The Control Node hosts all OpenStack services needed to operate virtual machines deployed on the Compute Nodes in the SUSE Cloud. Each virtual machine (instance) started in the cloud will be hosted on one of the Compute Nodes. Object storage is managed by the Storage Nodes.

Many chapters in this manual contain links to additional documentation resources. These include additional documentation that is available on the system as well as documentation available on the Internet.

For an overview of the documentation available for your product and the latest documentation updates, refer to http://www.suse.com/documentation/suse-cloud3.

1. Available Documentation

The following manuals are available for this product:

Deployment Guide

Gives an introduction to the SUSE® Cloud architecture, lists the requirements, and describes how to set up, deploy, and maintain the individual components. Also contains information about troubleshooting and support, as well as a glossary listing the most important terms and concepts for SUSE Cloud.

Admin User Guide (↑Admin User Guide)

Guides you through management of projects and users, images, flavors, quotas, and networks. Also describes how to migrate instances.

To complete these tasks, either use the graphical Web interface (based on OpenStack Dashboard, codename Horizon) or the OpenStack command line clients.

End User Guide (↑End User Guide)

Describes how to manage images, instances, networks, volumes, and track usage.

To complete these tasks, either use the graphical Web interface (based on OpenStack Dashboard, codename Horizon) or the OpenStack command line clients.

HTML versions of the product manuals can be found in the installed system under /usr/share/doc/manual. Additionally, you can access the product-specific manuals as well as upstream documentation from the Help links in the graphical Web interfaces. Find the latest documentation updates at http://www.suse.com/documentation where you can download the manuals for your product in multiple formats.

2. Feedback

Several feedback channels are available:

Bugs and Enhancement Requests

For services and support options available for your product, refer to http://www.suse.com/support/.

To report bugs for a product component, log in to the Novell Customer Center from http://www.suse.com/support/ and select My Support+Service Request.

User Comments

We want to hear your comments about and suggestions for this manual and the other documentation included with this product. Use the User Comments feature at the bottom of each page in the online documentation or go to http://www.suse.com/documentation/feedback.html and enter your comments there.

Mail

For feedback on the documentation of this product, you can also send a mail to doc-team@suse.de. Make sure to include the document title, the product version, and the publication date of the documentation. To report errors or suggest enhancements, provide a concise description of the problem and refer to the respective section number and page (or URL).

3. Documentation Conventions

The following typographical conventions are used in this manual:

  • /etc/passwd: directory names and file names

  • placeholder: replace placeholder with the actual value

  • PATH: the environment variable PATH

  • ls, --help: commands, options, and parameters

  • user: users or groups

  • Alt, Alt+F1: a key to press or a key combination; keys are shown in uppercase as on a keyboard

  • File, File+Save As: menu items, buttons

  • Dancing Penguins (Chapter Penguins, ↑Another Manual): This is a reference to a chapter in another manual.

4. About the Making of This Manual

This book is written in Novdoc, a subset of DocBook (see http://www.docbook.org). The XML source files were validated by xmllint, processed by xsltproc, and converted into XSL-FO using a customized version of Norman Walsh's stylesheets. The final PDF can be formatted through FOP from Apache or through XEP from RenderX. The authoring and publishing tools used to produce this manual are available in the package daps. The DocBook Authoring and Publishing Suite (DAPS) is developed as open source software. For more information, see http://daps.sf.net/.

Chapter 1. The SUSE Cloud Architecture

SUSE Cloud is a cloud infrastructure solution that can easily be deployed and managed. It offers a cloud management solution that helps organizations to centralize virtual machine deployment. SUSE Cloud 3 provides the following features:

  • Open source software that is based on the OpenStack Havana release.

  • Centralized resource tracking providing insight into activities and capacity of the cloud infrastructure for optimized automated deployment of services.

  • A self-service portal enabling end users to configure and deploy services as necessary, also offering the ability to track resource consumption (Horizon).

  • An image repository from which standardized, preconfigured virtual machines can be published (Glance).

  • Automated installation processes via Crowbar using pre-defined scripts for configuring and deploying the Control Node(s) as well as Compute and Storage Nodes.

  • Multi-tenant, role-based provisioning and access control for multiple departments and users within your organization.

  • APIs enabling the integration of third-party software, such as identity management and billing solutions.

SUSE Cloud is based on SUSE Linux Enterprise Server, OpenStack, Crowbar, and Chef. SUSE Linux Enterprise Server is used as the underlying operating system for all cloud infrastructure machines (also called nodes), whereas OpenStack, the cloud management layer, works as the Cloud Operating System. Crowbar and Chef are used to automatically deploy and manage the OpenStack nodes from a central Administration Server.

Figure 1.1. SUSE Cloud Infrastructure

SUSE Cloud Infrastructure

SUSE Cloud is deployed to four different types of machines:

  • one Administration Server for node deployment and management

  • one or more Control Nodes hosting the cloud management services

  • several Compute Nodes on which the instances are started

  • several Storage Nodes for block and object storage

1.1. The Administration Server

The Administration Server provides all services needed to manage and deploy all other nodes in the cloud. Most of these services are provided by the Crowbar tool that automates in conjunction with Chef all the required installation and configuration tasks. Among the services provided by the server are DHCP, DNS, NTP, PXE, TFTP.

The Administration Server also hosts the software repositories for SUSE Linux Enterprise Server and SUSE Cloud, since they are needed for node deployment. Optionally (if no other sources for the software repositories are available) it can also host the Subscription Management Tool (SMT), providing up-to-date repositories with updates and patches for all nodes.

1.2. The Control Node(s)

The Control Node(s) hosts all OpenStack services needed to orchestrate virtual machines deployed on the Compute Nodes in the SUSE Cloud. OpenStack on SUSE Cloud uses a PostgreSQL database, which is also hosted on the Control Node(s). The following OpenStack components and dependencies run on the Control Node(s):

  • PostgreSQL database

  • Image (Glance) for managing virtual images

  • Identity (Keystone), providing authentication and authorization for all OpenStack services

  • Networking (Neutron), providing networking as a service between interface devices managed by other OpenStack services

  • Block Storage (Cinder), providing block storage

  • OpenStack Dashboard (Horizon), providing the Dashboard, which is a user Web interface for the OpenStack services

  • Compute (Nova) management (Nova controller) including API and scheduler

  • Message broker (RabbitMQ)

  • Swift proxy server plus dispersion tools. Swift provides object storage.

  • Swift Ring

  • Ceph master cluster monitor

Being a central point in the SUSE Cloud architecture that runs a lot of services, a single Control Node can quickly become a performance bottleneck, especially in large SUSE Cloud deployments. It is possible to distribute the services listed above on more than one Control Node, up to a setup where each service runs on its own node.

Deploying certain parts of Networking (Neutron) on a distinct node is a general recommendation for production clouds. See Section 5.10, “Deploying Neutron” for details.

Hosting Identity (Keystone) on a distinct node enables you to separate authentication and authorization services from other cloud services for security reasons. Another good candidate to be hosted on a separate node is Block Storage (Cinder, particularly the cinder-volume role) when using local disks for storage. Deploying it on one or more separate node enables you to equip the node with storage and network hardware best suiting the service.

[Note]Moving Services in an Existing Setup

In case you plan to move a service in an already deployed SUSE Cloud from one Control Node to another, it is strongly recommended to shut down or save all instances before doing so (and restart them after having successfully re-deployed the services). Moving services also requires to stop them manually on the original Control Node.

1.3. The Compute Nodes

The Compute Nodes are the pool of machines on which the instances are running. These machines need to be equipped with a sufficient number of CPUs and enough RAM to start several instances. They also need to provide sufficient hard disk space, see Section 2.3.2.3, “Compute Nodes” for details. The Control Node effectively distributes instances within the pool of Compute Nodes and provides the necessary network resources. The OpenStack service Compute (Nova) runs on the Compute Nodes and provides means for setting up, starting, and stopping virtual machines.

SUSE Cloud supports several hypervisors such as Hyper-V, KVM, VMware vSphere or Xen. Each image that can be started with an instance is bound to one hypervisor. Each Compute Node can only run one hypervisor at a time. You can choose which hypervisor to run on which Compute Node when deploying the Nova barclamp.

1.4. The Storage Nodes

The Storage Nodes are the pool of machines providing object storage. SUSE Cloud offers two different types of storage: object and block storage. Object storage is provided by the OpenStack Swift component, while block storage is provided by Ceph. Deploying Swift is optional, Ceph is available as a technology preview.

1.5. HA Setup

A failure of components in SUSE Cloud can lead to system downtime and/or data loss. To prevent this, a maintenance update for SUSE Cloud 3 allows you to make all functions provided by the Control Node(s) highly available. During cloud deployment, you can set up High Availability (HA) cluster consisting of several nodes and assign certain roles to those clusters instead of assigning them to individual nodes. During cloud deployment, you can choose to apply certain roles to a High Availability (HA) cluster (consisting of several cluster nodes) instead of applying them to individual cloud nodes.

This includes especially the roles for data, services, and network running on the Control Node(s). With an HA setup, the cloud will continue to operate in case of an outage of one or more Control Nodes. This also includes the ability to start and stop VMs on the Compute Nodes, without loss of state.

For all HA-enabled roles, the respective functions are automatically handled by the clustering software SUSE Linux Enterprise High Availability Extension. The High Availability Extension uses the Pacemaker cluster stack with Pacemaker as cluster resource manager and Corosync/OpenAIS as messaging/infrastructure layer.

You can view the cluster status and configuration with the cluster management tools HA Web Konsole (Hawk), Pacemaker GUI, or the crm shell.

[Important]Do Not Change the Configuration

Use the cluster management tools only for viewing. All of the clustering configuration is done automatically via Crowbar and Chef. If you change anything via the cluster management tools you risk breaking the cluster. Changes done there may be reverted by the next run of Chef anyway.

A failure of the OpenStack infrastructure services (running on the Control Node) is the most crucial point of failure that can cause downtimes within the cloud. For more information on how to make those services highly-available and on how to avoid other potential points of failure in your cloud setup, refer to Section 2.7, “High Availability”.

Chapter 2. Considerations and Requirements

Abstract

Before deploying SUSE Cloud, there are a few requirements to be met and considerations to be made. Make sure to thoroughly read this chapter—some decisions need to be made before deploying SUSE Cloud, since you cannot change them afterwards.

2.1. Network

SUSE Cloud requires a complex network setup consisting of several networks that are configured during installation. These networks are for exclusive cloud usage. In order to access them from an existing network, a router is needed.

The network configuration on the nodes in the SUSE Cloud network is entirely controlled by Crowbar. Any network configuration not done with Crowbar (for example, with YaST) will automatically be overwritten. After the cloud is deployed, network settings cannot be changed anymore!

Figure 2.1. SUSE Cloud Network: Overview

SUSE Cloud Network: Overview

The following networks are pre-defined when setting up SUSE Cloud. The IP addresses listed are the default addresses and can be changed using the YaST Crowbar module (see Section 3.1.9, “Crowbar Setup”). It is also possible to completely customize the network setup. This requires to manually edit the network barclamp template. See Appendix D, The Network Barclamp Template File for detailed instructions.

Admin Network (192.168.124/24)

A private network to access the Administration Server and all nodes for administration purposes. The default setup lets you also access the BMC (Baseboard Management Controller) data via IPMI (Intelligent Platform Management Interface) from this network. If required, BMC access can be swapped to a separate network.

You have the following options for controlling access to this network:

  • do not allow access from the outside and keep the admin network completely separated

  • allow access to the Administration Server from a single network (for example, your company's administration network) via the bastion network option configured on an additional network card with a fixed IP address

  • allow access from one or more networks via a gateway

Storage Network (192.168.125/24)

Private, SUSE Cloud internal virtual network. This network is used by Ceph and Swift only. It should not be accessed by users.

Private Network (nova-fixed, 192.168.123/24)

Private, SUSE Cloud internal virtual network. This network is used for inter-instance communication and provides access to the outside world for the instances. The gateway required is also automatically provided by SUSE Cloud.

Public Network (nova-floating, public, 192.168.126/24)

The only public network provided by SUSE Cloud. You can access the Nova Dashboard as well as instances (provided they have been equipped with a floating IP) on this network. This network can only be accessed via a gateway, which needs to be provided externally. All SUSE Cloud users and administrators need to be able to access the public network.

Software Defined Network (os_sdn, 192.168.130/24)

Private, SUSE Cloud internal virtual network. This network is used when Neutron is configured to use openvswitch with GRE tunneling for the virtual networks. It should not be accessed by users.

[Warning]Protect Networks from External Access

For security reasons, protect the following networks from external access:

Especially traffic from the cloud instances must not be able to pass through these networks.

[Important]VLAN Settings

As of SUSE Cloud 3, using a VLAN for the admin network is only supported on a native/untagged VLAN. If you need VLAN support for the admin network, it must be handled at switch level.

When changing the network configuration with YaST or by editing /etc/crowbar/network.json you can define VLAN settings for each network. For the networks nova-fixed and nova-floating, however, special rules apply:

The use_vlan setting will be ignored. VLANs will only be used when deploying Neutron with openvswitch plus VLAN, with cisco plus VLAN, or with linuxbridges. If Neutron is deployed with one of these settings, you must specify correct VLAN IDs for both networks. The VLAN ID for the nova-floating network must match the one for the public network.

When deploying Compute Nodes with Microsoft Hyper-V or Windows Server, you must not use openvswitch with gre, but rather openvswitch with VLAN (recommended) or linuxbridge as a plugin for Neutron.

[Note]No IPv6 support

As of SUSE Cloud 3, IPv6 is not supported. This applies to the cloud internal networks as well as to the instances.

The following diagram shows the pre-defined SUSE Cloud network in more detail. It demonstrates how the OpenStack nodes and services use the different networks.

Figure 2.2. SUSE Cloud Network: Details

SUSE Cloud Network: Details

2.1.1. Network Address Allocation

The default networks set up in SUSE Cloud are class C networks with 256 IP addresses each. This limits the maximum number of instances that can be started simultaneously. Addresses within the networks are allocated as outlined in the following table. Use the YaST Crowbar module to customize (see Section 3.1.9, “Crowbar Setup”). The last address in the IP range of each network is always reserved as the broadcast address. This assignment cannot be changed.

[Note]Limitations of the Default Network Proposal

The default network proposal as described below limits the maximum number of Compute Nodes to 80, the maximum number of floating IP addresses to 61 and the maximum number of addresses in the nova_fixed network to 204.

To overcome these limitations you need to reconfigure the network setup by using appropriate network ranges. Do this by either using the YaST Crowbar module as described in Section 3.1.9, “Crowbar Setup” or by manually editing the network template file as described in Appendix D, The Network Barclamp Template File.

Table 2.1. 192.168.124.0/24 (Admin/BMC) Network Address Allocation

Function

Address

Remark

router

192.168.124.1

Provided externally.

admin

192.168.124.10 - 192.168.124.11

Fixed addresses reserved for the Administration Server.

dhcp

192.168.124.21 - 192.168.124.80

Address range reserved for node allocation/installation. Determines the maximum number of parallel allocations/installations.

host

192.168.124.81 - 192.168.124.160

Fixed addresses for the OpenStack nodes. Determines the maximum number of OpenStack nodes that can be deployed.

bmc vlan host

192.168.124.161

Fixed address for the BMC VLAN. Used to generate a VLAN tagged interface on the Administration Server that can access the BMC network. The BMC VLAN needs to be in the same ranges as BMC, and BMC needs to have VLAN enabled.

bmc host

192.168.124.162 - 192.168.124.240

Fixed addresses for the OpenStack nodes. Determines the maximum number of OpenStack nodes that can be deployed.

switch

192.168.124.241 - 192.168.124.250


Table 2.2. 192.168.125/24 (Storage) Network Address Allocation

Function

Address

Remark

host

192.168.125.10 - 192.168.125.239

Each Storage Node will get an address from this range.


Table 2.3. 192.168.123/24 (Private Network/nova-fixed) Network Address Allocation

Function

Address

Remark

router

192.168.123.1 - 192.168.123.49

dhcp

192.168.123.50 - 192.168.123.254

Address range for instances.


Table 2.4. 192.168.126/24 (Public Network nova-floating, public) Network Address Allocation

Function

Address

Remark

router

192.168.126.1

Provided externally.

public host

192.168.126.2 - 192.168.126.49

Public address range for external SUSE Cloud services such as the OpenStack Dashboard or the API.

floating host

192.168.126.129 - 192.168.126.191

Floating IP address range. Floating IPs can be manually assigned to a running instance to allow to access the guest from the outside. Determines the maximum number of instances that can concurrently be accessed from the outside.

The nova_floating network is set up with a netmask of 255.255.255.192, allowing a maximum number of 61 IP addresses. This range is pre-allocated by default and managed by Neutron.


Table 2.5. 192.168.130/24 (Software Defined Network) Network Address Allocation

Function

Address

Remark

host

192.168.130.10 - 192.168.130.254

If Neutron is configured with openvswitch and gre, each network node and all Compute Nodes will get an IP from this range.


[Note]Addresses for Additional Servers

Addresses not used in the ranges mentioned above, can be used to add additional servers with static addresses to SUSE Cloud. Such servers can be used to provide additional services. A SUSE Manager server inside SUSE Cloud, for example, needs to be configured using one of these addresses.

2.1.2. Network Modes

SUSE Cloud supports different network modes: single, dual, and teaming. As of SUSE Cloud 3 the networking mode is applied to all nodes as well as the Administration Server. That means that all machines need to meet the hardware requirements for the chosen mode. The network mode can be configured using the YaST Crowbar module (Section 3.1.9, “Crowbar Setup”). The network mode cannot be changed once the cloud is deployed.

Other, more flexible network mode setups can be configured by manually editing the Crowbar network configuration files. See Appendix D, The Network Barclamp Template File for more information. SUSE or a partner can assist you in creating a custom setup within the scope of a consulting services agreement (see http://www.suse.com/consulting/ for more information on SUSE consulting).

[Important]Teaming Network Mode is Required for HA

Teaming network mode is required for an HA setup of SUSE Cloud. If you are planning to move your cloud to an HA setup at a later point in time, make sure to deploy SUSE Cloud with teaming network mode from the beginning.

Otherwise a migration to an HA setup is not supported.

2.1.2.1. Single Network Mode

In single mode you just use one Ethernet card for all the traffic:

2.1.2.2. Dual Network Mode

Dual mode needs two Ethernet cards (on all nodes but Administration Server) and allows you to completely separate traffic to/from the Admin Network and to/from the public network:

2.1.2.3. Teaming Network Mode

Teaming mode is almost identical to single mode, except for the fact that you combine several Ethernet cards to a bond (network device bonding). Teaming mode needs two or more Ethernet cards.

2.1.3. Accessing the Administration Server via a Bastion Network

If you want to enable access to the Administration Server from another network, you can do so by providing an external gateway. This option offers maximum flexibility, but requires additional machines and may be less secure than you require. Therefore SUSE Cloud offers a second option for accessing the Administration Server: the bastion network. You only need a dedicated Ethernet card and a static IP address from the external network to set it up.

The bastion network setup enables you to log in to the Administration Server via SSH (see Section 2.1.3, “Accessing the Administration Server via a Bastion Network” for setup instructions). A direct login to other nodes in the cloud is not possible. However, the Administration Server can act as a jump host: To log in to a node, first log in to the Administration Server via SSH. From there, you can log in via SSH to other nodes.

2.1.4. DNS and Host Names

The Administration Server acts as a name server for all nodes in the cloud. If the admin node has access to the outside, then you can add additional name servers that will automatically be used to forward requests. If additional name servers are found on cloud deployment, the name server on the Administration Server will automatically be configured to forward requests for non-local records to those servers.

The Administration Server needs to be configured to have a fully qualified host name. This host name must not be changed after SUSE Cloud has been deployed. The OpenStack nodes will be named after their MAC address by default, but you can provide aliases, which are easier to remember when allocating the nodes. The aliases for the OpenStack nodes can be changed at any time. It is useful to have a list of MAC addresses and the intended use of the corresponding host at hand when deploying the OpenStack nodes.

2.2. Product and Update Repositories

In order to deploy SUSE Cloud and to be able to keep a running SUSE Cloud up-to-date, a total of seven software repositories is needed. This includes the static product repositories, which do not change over the product life cycle and the update repositories, which constantly change. The following repositories are needed:

SUSE Linux Enterprise Server 11 SP3 Product

The SUSE Linux Enterprise Server 11 SP3 product repository is a copy of the installation media (DVD1) for SUSE Linux Enterprise Server. As of SUSE Cloud 3 it is required to have it available locally on the Administration Server. This repository requires approximately 3.5 GB of hard disk space.

SUSE Cloud 3 Product (SLE-Cloud)

The SUSE Cloud 3 product repository is a copy of the installation media for SUSE Cloud. It can either be made available remote via HTTP or locally on the Administration Server. The latter is recommended, since it makes the setup of the Administration Server easier. This repository requires approximately 350 MB of hard disk space.

Cloud-PTF (SLE-Cloud-PTF)

A repository created automatically on the Administration Server upon the SUSE Cloud add-on product installation. It serves as a repository for Program Temporary Fixes (PTF) which are part of the SUSE support program.

SLES11-SP3-Pool and SUSE-Cloud-3-Pool

The SUSE Linux Enterprise Server and SUSE Cloud repositories containing all binary RPMs from the installation media, plus pattern information and support status metadata. These repositories are served from Novell Customer Center and need to be kept in sync with their sources. They can be made available remotely via an existing SMT or SUSE Manager server or locally on the Administration Server by installing a local SMT server, by mounting or synchronizing a remote directory or by copying them.

SLES11-SP3-Updates and SUSE-Cloud-3-Updates

These repositories contain maintenance updates to packages in the corresponding Pool repositories. These repositories are served from Novell Customer Center and need to be kept in sync with their sources. They can be made available remotely via an existing SMT or SUSE Manager server or locally on the Administration Server by installing a local SMT server, by mounting or syncing a remote directory or by regularly copying them.

Since the product repositories (for SUSE Linux Enterprise Server 11 SP3 and SUSE Cloud 3) do not change during the life cycle of a product they can be copied to the destination directory from the installation media. The update repositories however, need to be kept in sync with their sources, the Novell Customer Center. SUSE offers two products taking care of synchronizing repositories and making them available within your organization: SUSE Manager (http://www.suse.com/products/suse-manager/ and Subscription Management Tool (SMT, http://www.suse.com/solutions/tools/smt.html).

All repositories need to be served via http in order to be available for SUSE Cloud deployment. Repositories that are directly available on the Administration Server are made available by the Apache Web server running on the Administration Server. If your organization already uses SUSE Manager or SMT, you can use the repositories provided by these servers.

Making the repositories locally available on the Administration Server makes setting up the Administration Server more complicated, but has the advantage of a simple network setup within SUSE Cloud. It also allows you to seal off the SUSE Cloud network from other networks in your organization. Using a remote server as a source for the repositories has the advantage of using existing resources and services. It also makes setting up the Administration Server much easier, but requires a custom network setup for SUSE Cloud, since the Administration Server needs to be able to access the remote server.

Using a remote SMT Server

If you already run an SMT server within your organization, you can use it within SUSE Cloud. When using a remote SMT server, update repositories are served directly from the SMT server. Each node is configured with these repositories upon its initial setup.

The SMT server needs to be accessible from the Administration Server and all nodes in SUSE Cloud (via one or more gateways). Resolving the server's host name also needs to work.

Using a SUSE Manager Server

Each client that is managed by SUSE Manager needs to register with the SUSE Manager server. Therefore the SUSE Manager support can only be installed after the nodes have been deployed. In order to also be able to use repositories provided by SUSE Manager during node deployment, SUSE Linux Enterprise Server 11 SP3 must be set up for autoinstallation on the SUSE Manager server.

The server needs to be accessible from the Administration Server and all nodes in SUSE Cloud (via one or more gateways). Resolving the server's host name also needs to work.

Installing a Subscription Management Tool (SMT) Server on the Administration Server

The SMT server, a free add-on product for SUSE Linux Enterprise Server, regularly synchronizes repository data from Novell Customer Center with your local host. Installing the SMT server on the Administration Server is recommended if you do not have access to update repositories from elsewhere within your organization. This option requires the Administration Server to be able to access the Internet. Subscription Management Tool 11 SP3 is available for free from http://www.suse.com/solutions/tools/smt.html.

Sneakernet

If you choose to completely seal off your admin network from all other networks, you need to manually update the repositories from removable media. For this purpose copy the repositories from an existing SMT or SUSE Manager server to the removable media.

Utilizing Existing Repositories

If you can access existing repositories from within your company network from the Administration Server, you can either mount or sync these repositories from an existing SMT or SUSE Manager server to the required locations on the Administration Server.

2.3. Persistent Storage

When talking about persistent storage on SUSE Cloud, there are two completely different aspects to discuss: the block and object storage services SUSE Cloud offers on the one hand and the hardware related storage aspects on the different node types.

[Note]Persistent vs. Ephemeral Storage

Block and object storage are persistent storage models where files or images are stored until they are explicitly deleted. SUSE Cloud also offers ephemeral storage for images attached to instances. These ephemeral images only exist during the life of an instance and are deleted once the guest is terminated. See Section 2.3.2.3, “Compute Nodes” for more information.

2.3.1. Cloud Storage Services

As mentioned above, SUSE Cloud offers two different types of services for persistent storage: object and block storage. Object storage lets you upload and download files (similar to an FTP server), whereas a block storage provides mountable devices (similar to a hard-disk partition). Furthermore SUSE Cloud provides a repository to store the virtual disk images used to start instances.

Object Storage with Swift

The OpenStack object storage service is called Swift. The storage component of Swift (swift-storage) needs to be deployed on dedicated nodes where no other cloud services run. In order to be able to store the objects redundantly, it is required to deploy at least two Swift nodes. SUSE Cloud is configured to always use all unused disks on a node for storage.

Swift can optionally be used by Glance, the service that manages the images used to boot the instances. Offering object storage with Swift is optional.

Block Storage

Block storage on SUSE Cloud is provided by Cinder. Cinder can use a variety of storage backends, among them network storage solutions like NetApp or EMC. It is also possible to use local disks for block storage.

Alternatively, Cinder can use Ceph RBD as a backend. Ceph offers data security and speed by storing the devices redundantly on different servers. Ceph needs to be deployed on dedicated nodes where no other cloud services run. In order to be able to store the objects redundantly, it is required to deploy at least two Ceph nodes.

[Important]Deploying Ceph within SUSE Cloud is Not Supported

Ceph is included in SUSE Cloud 3 as a technology preview. You may use Ceph in test environments but it is not recommended for production.

The supported way to use Ceph for SUSE Cloud is to make use of an external Ceph cluster. See Section 4.3.4, “Using an Externally Managed Ceph Cluster” for more information and installation instructions.

The Glance Image Repository

Glance provides a catalog and repository for virtual disk images used to start the instances. Glance is installed on a Control Node. It either uses Swift or a directory on the Control Node to store the images. The image directory can either be a local directory or an NFS share.

2.3.2. Storage Hardware Requirements

Apart from sufficient disk space to install the SUSE Linux Enterprise Server operating system, each node in SUSE Cloud needs to store additional data. Requirements and recommendations for the various node types are listed below.

[Important]Choose a Hard Disk for the Operating System Installation

The operating system will always be installed on the first hard disk, the one that is recognized as /dev/sda. This is the disk that is listed first in the BIOS, the one from which the machine will boot. If you have nodes with a certain hard disk you want the operating system to be installed on, make sure it will be recognized as the first disk.

2.3.2.1. Administration Server

If you store the update repositories directly on the Administration Server (see Section 2.2, “Product and Update Repositories” for details), it is recommended to mount /srv to a separate partition or volume with a minimum of 30 GB space.

Log files from all nodes in SUSE Cloud are stored on the Administration Server under /var/log (see Section B.1, “On the Administration Server” for a complete list). Furthermore, the message service RabbitMQ requires 1 GB of free space in /var. Make sure sufficient space is available under /var.

2.3.2.2. Control Nodes

Depending on how the services are set up, Glance and Cinder may require additional disk space on the Control Node on which they are running. Glance may be configured to use a local directory, whereas Cinder may use a local image file for storage. For performance and scalability reasons this is only recommended for test setups. Make sure there is sufficient free disk space available if you use a local file for storage.

Cinder may be configured to use local disks for storage (configuration option raw). If you choose this setup, it is recommended to deploy the cinder-volume role to one or more dedicated Control Nodes equipped with several disks providing sufficient storage space. It may also be necessary to equip this node with two or more bonded network cards (requiring a special setup for this node, refer to Appendix D, The Network Barclamp Template File for details), since it will generate heavy network traffic.

2.3.2.3. Compute Nodes

Unless an instance is started via Boot from Volume, it is started with at least one disk—a copy of the image from which it has been started. Depending on the flavor you start, the instance may also have a second, so-called ephemeral disk. The size of the root disk depends on the image itself, while ephemeral disks are always created as sparse image files that grow (up to a defined size) when being filled. By default ephemeral disks have a size of 10 GB.

Both disks, root images and ephemeral disk, are directly bound to the instance and are deleted when the instance is terminated. Therefore these disks are bound to the Compute Node on which the instance has been started. The disks are created under /var/lib/nova on the Compute Node. Your Compute Nodes should be equipped with enough disk space to store the root images and ephemeral disks.

[Note]Ephemeral Disks vs. Block Storage

Do not confuse ephemeral disks with persistent block storage. In addition to an ephemeral disk, which is automatically provided with most instance flavors, you can optionally add a persistent storage device provided by Cinder. Ephemeral disks are deleted when the instance terminates, while persistent storage devices can be reused in another instance.

The maximum disk space required on a compute node depends on the available flavors. A flavor specifies the number of CPUs, as well as RAM and disk size of an instance. Several flavors ranging from tiny (1 CPU, 2512 MB RAM, no ephemeral disk) to xlarge (8 CPUs, 8 GB RAM, 10 GB ephemeral disk) are available by default. Adding custom flavors as well as editing and deleting existing flavors is also supported.

To calculate the minimum disk space needed on a compute node, you need to determine the highest "disk space to RAM" ratio from your flavors. Example:

Flavor small: 2 GB RAM, 100 GB ephemeral disk => 50 GB disk /1 GB RAM
Flavor large: 8 GB RAM, 200 GB ephemeral disk => 25 GB disk /1 GB RAM

So, 50 GB disk /1 GB RAM is the ratio that matters. If you multiply that value by the amount of RAM in GB available on your compute node, you have the minimum disk space required by ephemeral disks. Pad that value with sufficient space for the root disks plus a buffer that enables you to create flavors with a higher disk space to RAM ratio in the future.

[Warning]Overcommitting Disk Space

The scheduler that decides in which node an instance is started does not check for available disk space. If there is no disk space left on a compute node, this will not only cause data loss on the instances, but the compute node itself will also stop operating. Therefore you must make sure all compute nodes are equipped with enough hard disk space!

2.3.2.4. Storage Nodes

The block-storage service Ceph RBD and the object storage service Swift need to be deployed onto dedicated nodes—it is not possible to mix these services. Each storage service requires at least two machines (more are recommended) to be able to store data redundantly.

Each Ceph/Swift Storage Node needs at least two hard disks. The first one will be used for the operating system installation, while the others can be used for storage purposes. It is recommended to equip the storage nodes with as many disks as possible.

Using RAID on Swift storage nodes is not supported. Swift takes care of redundancy and replication on its own. Using RAID with Swift would also result in a huge performance penalty.

[Important]Deploying Ceph within SUSE Cloud is Not Supported

Ceph is included in SUSE Cloud 3 as a technology preview. You may use Ceph in test environments but it is not recommended for production.

The supported way to use Ceph for SUSE Cloud is to make use of an external Ceph cluster. See Section 4.3.4, “Using an Externally Managed Ceph Cluster” for more information and installation instructions.

2.4. SSL Encryption

Whenever non-public data travels over a network it needs to be encrypted. Encryption protects the integrity and confidentiality of data. Therefore you should enable SSL support when deploying SUSE Cloud to production (it is not enabled by default since it requires certificates to be provided). The following services (and their APIs if available) can make use of SSL:

  • Neutron

  • Keystone

  • Glance

  • Cinder

  • Nova

  • VNC

  • OpenStack Dashboard

Using SSL requires an SSL certificate either for each node on which the services that uses encryption run (services sharing a certificate) or, alternatively, a dedicated certificate for each service. A single certificate for the Control Node is the minimum requirement, where all services listed above are installed on the Control Node and are sharing the certificate.

Certificates must be signed by a trusted authority. Refer to http://www.suse.com/documentation/sles11/book_sle_admin/data/sec_apache2_ssl.html for instructions on how to create and sign them.

[Important]Host Names

Each SSL certificate is issued for a certain host name and, optionally, for alternative host names (via the AlternativeName option). Each publicly available node in SUSE Cloud has two host names—an internal and a public one. The SSL certificate needs to be issued for both names.

The internal name has the following scheme:

dMAC ADDRESS.FQDN

MAC ADDRESS is the MAC address of the interface used to PXE boot the machine with lowercase letters and colons replaced with dashes, for example 52-54-00-8e-ce-e3. FQDN is the fully qualified domain name. An example name looks like this:

d52-54-00-8e-ce-e3.example.com

Unless you have entered a custom Public Name for a client (see Section 4.2, “Node Installation” for details), the public name is the same as the internal name prefixed by public.:

public.d52-54-00-8e-ce-e3.example.com

To look up the node names open the Crowbar Web interface and click on a node name in the Node Dashboard. The names are listed as Full Name and Public Name.

2.5. Hardware Requirements

Precise hardware requirements can only be listed for the Administration Server and the OpenStack Control Node. The requirements of the OpenStack Compute and Storage Nodes depends on the number of concurrent instances and their virtual hardware equipment.

The minimum number of machines required for a SUSE Cloud setup is three: one Administration Server, one Control Node, and one Compute Node. In addition to that, a gateway providing access to the public network is required. Deploying storage requires additional nodes: at least two nodes for Swift and a minimum of four nodes for Ceph (technology preview only).

[Important]Physical Machines and Architecture

All SUSE Cloud nodes need to be physical machines. Although the Administration Server and the Control Node can be virtualized in test environments, this is not supported for production systems.

SUSE Cloud currently only runs on x86_64 hardware.

2.5.1. Administration Server

  • Architecture: x86_64

  • RAM: at least 2 GB, 4 GB recommended

  • Hard disk: at least 50 GB. It is recommended to put /srv on a separate partition with at least additional 30 GB of space, unless you mount the update repositories from another server (see Section 2.2, “Product and Update Repositories” for details).

  • Number of network cards: 1 for single and dual mode, 2 or more for team mode. Additional networks such as the bastion network and/or a separate BMC network each need an additional network card. See Section 2.1, “Network” for details.

2.5.2. Control Node

2.5.3. Compute Node

The Compute Nodes need to be equipped with a sufficient amount of RAM and CPUs, matching the numbers required by the maximum number of instances running concurrently. An instance started in SUSE Cloud cannot share resources from several physical nodes, but rather uses the resources of the node on which it was started. So if you offer a flavor (see Flavor for a definition) with 8 CPUs and 12 GB RAM, at least one of your nodes should be able to provide these resources.

See Section 2.3.2.3, “Compute Nodes” for storage requirements.

2.5.4. Storage Node

The Storage Nodes are sufficiently equipped with a single CPU and 1 or 2 GB of RAM. See Section 2.3.2.4, “Storage Nodes” for storage requirements.

2.6. Software Requirements

The following software requirements need to be met in order to install SUSE Cloud:

  • SUSE Linux Enterprise Server 11 SP3 installation media (ISO image, included in the SUSE Cloud Administration Server subscription)

  • Access to the SUSE Linux Enterprise Server 11 SP3 Update repositories

  • SUSE Cloud 3 installation media (ISO image)

  • Access to the SUSE Cloud 3 Update repositories

  • A SUSE/Novell account (for product registration and SMT setup). If you do not already have one, go to http://www.suse.com/login to create it.

  • Optional: Subscription Management Tool 11 SP3 installation media. A free download is available on http://www.novell.com/linux/smt/. See Section 2.2, “Product and Update Repositories”.

2.7. High Availability

Several components and services in SUSE Cloud can become single points of failure that may cause system downtime and/or data loss if they fail.

SUSE Cloud provides various mechanisms which can ensure that the crucial components and services are highly available. The following sections provide an overview of which components on each node you should consider to make highly available. For making the Control Node functions highly available, SUSE Cloud uses the cluster software SUSE Linux Enterprise High Availability Extension. Make sure to thoroughly read Section 2.7.5, “Cluster Requirements and Recommendations” that lists additional requirements with regard to that.

2.7.1. High Availability of the Administration Server

The Administration Server provides all services needed to manage and deploy all other nodes in the cloud. If the Administration Server is not available, new cloud nodes cannot be allocated, and you cannot add new roles to cloud nodes.

However, only two services on the Administration Server are single point of failures, without which the cloud cannot continue to run properly: DNS and NTP.

2.7.1.1. Administration Server—Avoiding Points of Failure

To avoid DNS and NTP as potential points of failure, deploy the roles dns-server and ntp-server to multiple nodes.

[Note]Access to External Network

If any configured DNS forwarder or NTP external server is not reachable through the admin network from these nodes, allocate an address in the public network for each node that has the dns-server and ntp-server roles:

crowbar network allocate_ip default `hostname -f` public host

That way, the nodes will be able to use the public gateway to reach the external servers. The change will only become effective after the next run of chef-client on the affected nodes.

2.7.1.2. Administration Server—Recovery

To minimize recovery time for the Administration Server, follow the backup and restore recommendations described in Section 6.4, “Backing Up and Restoring the Administration Server”.

2.7.2. High Availability of the Control Node(s)

The Control Node(s) usually run a variety of services without which the cloud would not be able to run properly.

2.7.2.1. Control Node(s)—Avoiding Points of Failure

To prevent the cloud from avoidable downtime in case one or more Control Nodes fail, SUSE Cloud offers you the choice to make the following roles highly available:

  • database-server (database barclamp)

  • keystone-server (keystone barclamp)

  • rabbitmq-server (rabbitmq barclamp)

  • swift-proxy (swift barclamp)

  • glance-server (glance barclamp)

  • cinder-controller (cinder barclamp)

  • neutron-server (neutron barclamp)

  • neutron-l3 (neutron barclamp)

  • nova-multi-controller (nova barclamp)

  • nova_dashboard-server (nova_dashboard barclamp)

  • ceilometer-server (ceilometer barclamp)

  • ceilometer-cagent (ceilometer barclamp)

  • heat-server (heat barclamp)

Instead of assigning these roles to individual cloud nodes, you can assign them to one or several High Availability clusters. SUSE Cloud will then use the Pacemaker cluster stack (shipped with the SUSE Linux Enterprise High Availability Extension) to manage the services and to fail them over to another Control Node in case one Control Node fails. For details on the Pacemaker cluster stack and the SUSE Linux Enterprise High Availability Extension 11 SP3, refer to the High Availability Guide, available at https://www.suse.com/documentation/sle_ha/. However, whereas SUSE Linux Enterprise High Availability Extension includes Linux Virtual Server as load-balancer, SUSE Cloud uses HAProxy for this purpose (http://haproxy.1wt.eu/).

[Note]Recommended Setup

Though it is possible to use the same cluster for all of the roles above, the recommended setup is to use three clusters and to deploy the roles as follows:

  • data cluster: database-server and rabbitmq-server

  • network cluster: neutron-l3 (as the neutron-l3 role may result in heavy network load and CPU impact)

  • services cluster: all other roles listed above (as they are related to API/schedulers)

[Important]Cluster Requirements and Recommendations

For setting up the clusters, some special requirements and recommendations apply. For details, refer to Section 2.7.5, “Cluster Requirements and Recommendations”.

2.7.2.2. Control Node(s)—Recovery

Recovery of the Control Node(s) is done automatically by the cluster software: if one Control Node fails, Pacemaker will fail over the services to another Control Node. If a failed Control Node is repaired and rebuilt via Crowbar, it will be automatically configured to join the cluster, at which point Pacemaker will have the option to fail services back if required.

2.7.3. High Availability of the Compute Node(s)

If a Compute Node fails, all VMs running on that node will go down, too. In that case, you can relaunch all instances that are hosted on the failed node if you use shared storage for /var/lib/nova/instances. For instructions on how to do so, see http://docs.openstack.org/trunk/openstack-ops/content/maintenance.html#compute_node_failures, section Compute Node Failures and Maintenance. In addition, you can use Heat to monitor VM instances and auto-restart them if required. For more information, see the following links:

2.7.3.1. Compute Node(s)—Recovery

A Compute Node can be recovered with the following steps:

  1. If required, install new hardware on the Compute Node.

  2. Reinstall the Compute Node from Crowbar via AutoYaST. For more information, refer to Section 4.4, “Editing Allocated Nodes”.

  3. Restart the instances that had been running on the failed Compute Node.

2.7.4. High Availability of the Storage Node(s)

SUSE Cloud offers two different types of storage that can be used for the Storage Nodes: object storage (provided by the OpenStack Swift component) and block storage (provided by Ceph).

Both already consider High Availability aspects by design, therefore it does not require much effort to make the storage highly available.

2.7.4.1. Swift—Avoiding Points of Failure

The OpenStack Object Storage replicates the data by design, provided the following requirements are met:

  • The option Replicas in the Swift barclamp is set to 3, the tested and recommended value.

  • The number of Storage Node must be greater than the value set in the Replicas option.

  1. To avoid single points of failure, assign the swift-storage role to multiple nodes.

  2. To make the API highly available, too, assign the swift-proxy role to a cluster instead of assigning it to a single Control Node. See Section 2.7.2.1, “Control Node(s)—Avoiding Points of Failure”. Other swift roles must not be deployed on a cluster.

2.7.4.2. Ceph—Avoiding Points of Failure

Ceph is a distributed storage solution that can provide High Availability.For High Availability redundant storage and monitors need to be configured in the Ceph cluster.

2.7.5. Cluster Requirements and Recommendations

When considering to set up one ore more High Availability clusters, refer to the chapter System Requirements listed in the High Availability Guide for SUSE Linux Enterprise High Availability Extension 11 SP3. The guide is available at https://www.suse.com/documentation/sle_ha/.

If you want to make the Control Node functions highly available, the requirements listed there also apply to SUSE Cloud. Note that by buying SUSE Cloud, you automatically get an entitlement for SUSE Linux Enterprise High Availability Extension.

Especially note the following requirements:

Number of Cluster Nodes

Each cluster must consist of at least two cluster nodes.

[Important]Odd Number of Cluster Nodes

It is strongly recommended to use an odd number of cluster nodes with a minimum of three nodes.

A cluster needs Quorum to keep services running. Therefore a three-node cluster can tolerate only failure of one node at a time, whereas a five-node cluster can tolerate failures of two nodes etc.

STONITH

The cluster software will shut down misbehaving nodes in a cluster to prevent them from causing trouble. This mechanism is referred to as fencing or STONITH.

[Important]No Support Without STONITH

A cluster without STONITH is not supported.

For a supported HA setup, ensure the following:

  • Each node in the High Availability cluster must have at least one STONITH device (usually a piece of hardware). We strongly recommend multiple STONITH devices per node, unless SBD is used.

  • The global cluster options stonith-enabled and startup-fencing must be set to true. These options are set automatically when deploying the Pacemaker barclamp. As soon as you change them, you will loose support.

  • When deploying the Pacemaker service, select a Configuration mode for STONITH that matches your setup. If your STONITH devices support the IPMI protocol, choosing the IPMI option is the easiest way to configure STONITH. Another alternative is SBD (STONITH Block Device). It provides a way to enable STONITHand fencing in clusters without external power switches, but it requires shared storage. For SBD requirements, see http://linux-ha.org/wiki/SBD_Fencing, section Requirements.

For more information, refer to the High Availability Guide, available at https://www.suse.com/documentation/sle_ha/. Especially read the following chapters: Configuration and Administration Basics, and Fencing and STONITH, Storage Protection.

Network Configuration
[Important]Redundant Communication Paths

For a supported HA setup, it is required to set up cluster communication via two or more redundant paths. For this purpose, use teaming network mode in your network setup. For details, see Section 2.1.2.3, “Teaming Network Mode”. At least two Ethernet cards per cluster node are required for network redundancy. It is advisable to use teaming network mode everywhere (not just between the cluster nodes) to ensure redundancy.

For more information, refer to the High Availability Guide, available at https://www.suse.com/documentation/sle_ha/. Especially read the following chapters: Network Device Bonding, and Installation and Basic Setup (section Defining the Communication Channels).

Storage Requirements

The following services require shared storage: database-server and rabbitmq-server. For this purpose, use either an external NFS share or DRBD.

If using an external NFS share, the following additional requirements are important:

If using DRDB, the following additional requirements are important:

  • Because of a DRBD limitation, the cluster used for database-server and rabbitmq-server is restricted to two nodes.

  • All nodes of the cluster that is used for database-server and rabbitmq-server must have an additional hard disk that will be used for DRBD. For more information on DRBD, see the DRBD chapter in the High Availability Guide, which is available at https://www.suse.com/documentation/sle_ha/.

When using SBD as STONITH device, additional requirements apply for the shared storage. For details, see http://linux-ha.org/wiki/SBD_Fencing, section Requirements.

2.7.6. For More Information

For a basic understanding and detailed information on the SUSE Linux Enterprise High Availability Extension 11 SP3 (including the Pacemaker cluster stack), read the High Availability Guide. It is available at https://www.suse.com/documentation/sle_ha/.

In addition to the chapters mentioned in Section 2.7.5, “Cluster Requirements and Recommendations”, especially the following chapters are recommended:

  • Product Overview

  • Configuration and Administration Basics

The High Availability Guide also provides comprehensive information about the cluster management tools which you can view and check the cluster status in SUSE Cloud. They can also be used to look up details like configuration of cluster resources or global cluster options. Read the following chapters for more information:

  • HA Web Konsole: Configuring and Managing Cluster Resources (Web Interface)

  • Pacemaker GUI: Configuring and Managing Cluster Resources (GUI)

  • crm.sh: Configuring and Managing Cluster Resources (Command Line)

2.8. Summary: Considerations and Requirements

As outlined above, there are some important considerations to be made before deploying SUSE Cloud. The following briefly summarizes what was discussed in detail in this chapter. Keep in mind that as of SUSE Cloud 3 it is not possible to change some aspects such as the network setup once SUSE Cloud is deployed!

Network

  • If you do not want to stick with the default networks and addresses, define custom networks and addresses. You need five different networks. If you need to separate the admin and the BMC network, a sixth network is required. See Section 2.1, “Network” for details. Networks that share interfaces need to be configured as VLANs.

  • The SUSE Cloud networks are completely isolated, therefore it is not required to use public IP addresses for them. A class C network as used in this documentation may not provide enough addresses for a cloud that is supposed to grow. You may alternatively choose addresses from a class B or A network.

  • Determine how to allocate addresses from your network. Make sure not to allocate IP addresses twice. See Section 2.1.1, “Network Address Allocation” for the default allocation scheme.

  • Define which network mode to use. Keep in mind that all machines within the cloud (including the Administration Server) will be set up with the chosen mode and therefore need to meet the hardware requirements. See Section 2.1.2, “Network Modes” for details.

  • Define how to access the admin and BMC network(s): no access from the outside (no action is required), via an external gateway (gateway needs to be provided), or via bastion network. See Section 2.1.3, “Accessing the Administration Server via a Bastion Network” for details.

  • Provide a gateway to access the public network (public, nova-floating).

  • Make sure the admin server's host name is correctly configured (hostname -f needs to return a fully qualified host name).

  • Prepare a list of MAC addresses and the intended use of the corresponding host for all OpenStack nodes.

Update Repositories

  • Depending on your network setup you have different options on how to provide up-to-date update repositories for SUSE Linux Enterprise Server and SUSE Cloud for SUSE Cloud deployment: using an existing SMT or SUSE Manager server, installing SMT on the Administration Server, synchronizing data with an existing repository, mounting remote repositories or using a Sneakernet. Choose the option that best matches your needs.

Storage

  • Decide whether you want to deploy the object storage service Swift. If so, you need to deploy at least two nodes with sufficient disk space exclusively dedicated to Swift.

  • Decide which back-end to use with Cinder. If using the raw back-end (local disks) it is strongly recommended to use a separate node equipped with several hard disks for deploying cinder-volume. If using Ceph, you need to deploy at least two nodes with sufficient disk space exclusively dedicated to it.

    [Important]Deploying Ceph within SUSE Cloud is Not Supported

    Ceph is included in SUSE Cloud 3 as a technology preview. You may use Ceph in test environments but it is not recommended for production.

    The supported way to use Ceph for SUSE Cloud is to make use of an external Ceph cluster. See Section 4.3.4, “Using an Externally Managed Ceph Cluster” for more information and installation instructions.

  • Make sure all Compute Nodes are equipped with sufficient hard disk space.

SSL Encryption

  • Decide whether to use different SSL certificates for the services and the API or whether to use a single certificate.

  • Get one or more SSL certificates certified by a trusted third party source.

Hardware and Software Requirements

  • Make sure the hardware requirements for the different node types are met.

  • Make sure to have all required software at hand.

Chapter 3. Installing and Configuring the Administration Server

Abstract

Deploying and installing SUSE Cloud is a multi-step process, starting by deploying a basic SUSE Linux Enterprise Server installation and the SUSE Cloud add-on product to the Administration Server. Now the product and update repositories need to be set up and the SUSE Cloud network needs to be configured. Next the Administration Server setup will be finished. After the Administration Server is ready, you can start deploying and configuring the OpenStack nodes. The complete node deployment is done automatically via Crowbar and Chef from the Administration Server. All you need to do is to boot the nodes using PXE and to deploy the OpenStack services to them.

Procedure 3.1. High Level Overview of the SUSE Cloud Installation

  1. Install SUSE Linux Enterprise Server 11 SP3 on the Administration Server with the add-on products Subscription Management Tool (optional) and SUSE Cloud. See below.

  2. After the Administration Server is set up, boot all nodes onto which the OpenStack components should be deployed using PXE and allocate them in the Crowbar Web interface to start the automatic SUSE Linux Enterprise Server installation. See Chapter 4, Installing the OpenStack Nodes.

  3. Configure and deploy the OpenStack services via the Crowbar Web interface or command line tools. See Chapter 5, Deploying the OpenStack Services.

  4. When all OpenStack services are up and running, SUSE Cloud is ready. The cloud administrator can now upload images to enable users to start deploying instances. See Admin User Guide (↑Admin User Guide).

In this chapter you will learn how to install and set up the Administration Server from bare-metal. As a result, the Administration Server will be ready to deploy OpenStack nodes and services. It will run on SUSE Linux Enterprise Server 11 SP3 and will include the add-on products SUSE Cloud and SMT. Installing the Administration Server involves the following basic steps:

3.1. Operating System Installation

Start the installation by booting from the SUSE Linux Enterprise Server 11 SP3 installation media.

[Note]Differences from the Default Installation Process

For an overview of a default SUSE Linux Enterprise Server installation, refer to the SUSE Linux Enterprise Server Installation Quick Start. Detailed installation instructions are available in the SUSE Linux Enterprise Server Deployment Guide. Both documents are available at http://www.suse.com/documentation/sles11/.

The following sections will only cover the differences from the default installation process.

3.1.1. Add-On Product Selection

SUSE Cloud is an add-on product to SUSE Linux Enterprise Server. Installing it during the SUSE Linux Enterprise Server installation is the easiest and recommended way to set up the Administration Server. If you are planning to set up an SMT server on the Administration Server as well, also install it in this step (SMT is an add-on product, too). Make sure to be able to access the installation media (DVD or ISO image) for all add-on products. Alternatively, install the add-on products after the SUSE Linux Enterprise Server installation.

[Note]SMT Server Installation

When not using an existing SMT or SUSE Manager server, installing an SMT server on the Administration Server is the easiest way to ensure that SUSE Cloud is provided with up-to-date update repositories for SUSE Linux Enterprise Server and SUSE Cloud. See Section 2.2, “Product and Update Repositories” for alternatives and background information.

[Note]SUSE Cloud Media Layout

SUSE Cloud is delivered on three DVDs. DVD #1 contains the installation data and is needed when installing SUSE Cloud. DVD #2 contains the source packages and DVD #3 contains the debuginfo packages.

On the Installation Mode screen, click Include Add-On products from Separate Media. Proceed with Next to the add-on product installation dialog. If you have direct access to the installation media (for example, via DVD or flash disk), skip the network installation dialog. Otherwise configure the network as described in Section 3.1.7, “Basic Network Configuration”. Add SUSE Cloud and SMT (optional) as add-on products and proceed with the installation. Consult the SUSE Linux Enterprise Server Deployment Guide at http://www.suse.com/documentation/sles11/book_sle_deployment/data/sec_i_yast2_inst_mode.html for detailed instructions.

3.1.2. Partitioning

Currently, Crowbar requires /opt to be writable. Apart from that, SUSE Cloud has no special requirements in regards of partitioning. However, it is recommended to create a separate partition or volume for /srv. /srv will host all update and product repositories for SUSE Linux Enterprise Server and SUSE Cloud. A size of at least 30 GB is required. Help on using the partitioning tool is available at http://www.suse.com/documentation/sles11/book_sle_deployment/data/sec_yast2_i_y2_part_expert.html.

3.1.3. Software Selection

Installing a minimal base system is sufficient to set up the Administration Server. The following patterns are the minimum requirement:

  • Base System

  • Minimal System (Appliances)

  • Subscription Management Tool (optional)

  • SUSE Cloud Admin Node

  • Web and LAMP Server (only needed when installing SMT)

3.1.4. Product Registration

Although you can also register your products at any time after the installation, it is recommended to register SUSE Linux Enterprise Server and SUSE Cloud now, because it will give you immediate access to the update channels. If you have installed the SMT add-on product, you must register your SUSE Linux Enterprise Server version at the Novell Customer Center now, otherwise you will not be able to configure the SMT server. You have received registration keys with the SUSE Cloud Administration Server subscription. See http://www.suse.com/documentation/sles11/book_sle_deployment/data/sec_i_yast2_conf.html for details on the Novell Customer Center registration.

[Note]SUSE Login Required

In order to register a product, you need to have a SUSE/Novell login. If you do not have such a login, create it at http://www.suse.com/login.

3.1.5. Online Update

A successful product registration will add update repositories for SUSE Linux Enterprise Server and all add-on products. After having successfully registered you will be asked to perform an online update, which will update the system and the add-on products. It is strongly recommended to perform the update at this point in time. If you choose to skip the update now, you must perform it later, before running the Cloud installation script.

3.1.6. CA Setup

Skip this step if you have not installed SMT add-on product. In case you have installed SMT you need to provide a certificate authority (CA). If you already have a CA certificate in your organization, import it. Otherwise generate all certificates in the Administration Server itself by accepting the YaST proposal. See http://www.suse.com/documentation/sles11/book_security/data/cha_security_yast_ca.html for more information.

If SMT is not installed, click on the CA Management link and choose to not set up a CA.

3.1.7. Basic Network Configuration

Only the first interface (eth0) on the Administration Server needs to be configured during the installation. Other interfaces will be automatically configured by the cloud installation script.

eth0 needs to be given a fixed IP address from the admin network—when sticking with the default network addresses this would be 192.168.124.10. The address you need to enter for the Default Gateway depends on whether you have provided an external gateway for the admin network (use the address of that gateway) or not (use xxx.xxx.xxx.1, for example, 192.168.124.1). Using a custom IP address or more than one network interfaces requires to adjust the Crowbar configuration in a later step as described in Section 3.1.9, “Crowbar Setup”.

If the Administration Server has access to the outside, you can add additional name servers that will automatically be used to forward requests. The Administration Server's name server will automatically be configured by the cloud installation script to forward requests for non-local records to those server(s).

You also need to assign a host name and a fully qualified domain name (FQDN) such as admin.cloud.example.com to eth0 (tab Hostname/DNS in the Network settings Dialog).

Last, the firewall needs to be disabled for all interfaces.

[Important]Administration Server Domain Name and Host name

Setting up the SUSE Cloud will also install a DNS server for all nodes in the cloud. The domain name you specify for the Administration Server will be used for the DNS zone. It is recommended to use a sub-domain such as cloud.example.com.

The host name and the FQDN need to be resolvable with hostname -f. Double-check whether /etc/hosts contains an appropriate entry for the Administration Server. It should look like the following:

192.168.124.10 admin.cloud.example.com admin

It is not possible to change the Administration Server host name or the FQDN after the cloud installation script has been run.

3.1.8. SMT Configuration

Skip this step if you have not installed the SMT add-on product. In case you have installed it, you will be asked to configure it. Configuring the SMT server requires you to have your mirroring credentials (user name and password) and your registration e-mail address at hand. To access them, log in to the Novell Customer Center at http://www.novell.com/center/. Get the mirror credentials by selecting My Products+Mirror Credentials in the left navigation. Obtain your registration e-mail address from My Profile+Login Profile.

Enter this data at the SMT Configuration Wizard Step 1/2 into the fields User, Password, and NCC E-mail Used for Registration. Accept the pre-filled defaults for the other text boxes. Make sure to Test the credentials.

In step two of the SMT configuration you need to enter a database password and specify an e-mail address for getting reports. Refer to http://www.suse.com/documentation/smt11/ for the complete SMT for SUSE Linux Enterprise 11 Guide.

3.1.9. Crowbar Setup

This YaST module enables you to configure all networks within the cloud, to set up additional repositories and to manage the Crowbar users. This module is automatically started when installing SUSE Cloud. To start it manually after the installation, either run yast crowbar or choose Miscellaneous+Crowbar in YaST.

3.1.9.1. User Settings

On this tab you can manage users for the Crowbar Web interface. The user crowbar (password crowbar) is preconfigured. Use the Add, Edit and Delete buttons to manage user accounts. Users configured here have no relations to existing system users on the Administration Server.

Figure 3.1. YaST Crowbar Setup: User Settings

YaST Crowbar Setup: User Settings

3.1.9.2. Networks

Use the Networks tab to change the default network setup (described in Section 2.1, “Network”). Change the IP address assignment for each network under Edit Ranges. You may also add a bridge (Add Bridge) or a VLAN (Use VLAN, VLAN ID) to a network. Only change the latter two settings if you really know what you require; sticking with the defaults is recommended.

Figure 3.2. YaST Crowbar Setup: Network Settings

YaST Crowbar Setup: Network Settings

[Important]VLAN Settings

As of SUSE Cloud 3, using a VLAN for the admin network is only supported on a native/untagged VLAN. If you need VLAN support for the admin network, it must be handled at switch level.

When changing the network configuration with YaST or by editing /etc/crowbar/network.json you can define VLAN settings for each network. For the networks nova-fixed and nova-floating, however, special rules apply:

The use_vlan setting will be ignored. VLANs will only be used when deploying Neutron with openvswitch plus VLAN, with cisco plus VLAN, or with linuxbridges. If Neutron is deployed with one of these settings, you must specify correct VLAN IDs for both networks. The VLAN ID for the nova-floating network must match the one for the public network.

When deploying Compute Nodes with Microsoft Hyper-V or Windows Server, you must not use openvswitch with gre, but rather openvswitch with VLAN (recommended) or linuxbridge as a plugin for Neutron.

[Warning] No Network Changes After Having Run the Cloud Installation Script

After you have run the cloud installation script, you cannot change the network setup anymore. If you did, you would need to completely set up the Administration Server again.

Other, more flexible network mode setups can be configured by manually editing the Crowbar network configuration files. See Appendix D, The Network Barclamp Template File for more information. SUSE or a partner can assist you in creating a custom setup within the scope of a consulting services agreement (see http://www.suse.com/consulting/ for more information on SUSE consulting).

3.1.9.2.1. Separating the Admin and the BMC Network

If you want to separate the admin and the BMC network, you must change the settings for the networks bmc and bmc_vlan. The bmc_vlan is used to generate a VLAN tagged interface on the Administration Server that can access the bmc network. The bmc_vlan needs to be in the same ranges as bmc, and bmc needs to have VLAN enabled.

Table 3.1. Separate BMC Network Example Configuration

bmc

bmc_vlan

Subnet

192.168.128.0

Netmask

255.255.255.0

Router

192.168.128.1

Broadcast

192.168.128.255

Host Range

192.168.128.10 - 192.168.128.100

192.168.128.101 - 192.168.128.101

VLAN

yes

VLAN ID

100

Bridge

no


Figure 3.3. YaST Crowbar Setup: Network Settings for the BMC Network

YaST Crowbar Setup: Network Settings for the BMC Network

3.1.9.3. Network Mode

On the Network Mode tab you can choose between single, dual, and team mode. When choosing team, you also need to set the Bonding Policy. See Section 2.1.2, “Network Modes” for details on SUSE Cloud and network modes. In-depth information about the Bonding Policy (also known as bonding modes) is available at https://www.kernel.org/doc/Documentation/networking/bonding.txt in section 2, Bonding Driver Options, under mode.

3.1.9.3.1. Setting Up a Bastion Network

The Network Mode tab of the YaST Crowbar module also lets you set up a Bastion network. As outlined in Section 2.1, “Network”, one way to access the Administration Server from a defined external network is via a Bastion network and a second network card (as opposed to providing an external gateway).

To set up the Bastion network, you need to have a static IP address for the Administration Server from the external network. The example configuration used below assumes that the external network from which to access the admin network has the following addresses. You need to adjust them according to your needs.

Table 3.2. Example Addresses for a Bastion Network

Subnet

10.10.1.0

Netmask

255.255.255.0

Broadcast

10.10.1.255

Gateway

10.10.1.1

Static Administration Server address

10.10.1.125


In addition to the values above, you need to enter the Physical Interface Mapping. With this value you specify the Ethernet card that is used for the bastion network. See Section D.4, “Network Conduits” for details on the syntax. The default value ?1g2 matches the second interface (eth1) of the system.

Figure 3.4. YaST Crowbar Setup: Network Settings for the Bastion Network

YaST Crowbar Setup: Network Settings for the Bastion Network

[Important]Accessing Nodes From Outside the Bastion Network

The example configuration from above allows to access SUSE Cloud nodes from within the bastion network. If you want to access nodes from outside the bastion network, you need to make the router for the bastion network the default router for the Administration Server. This is achieved by setting the value for the bastion network's Router preference entry to a lower value than the corresponding entry for the admin network. By default no router preference is set for the Administration Server—in this case, set the preference for the bastion network to 5.

If you use a Linux gateway between the outside and the bastion network, you also need to disable route verification (rp_filter) on the Administration Server. Do so by running the following command on the Administration Server:

echo 0 > /proc/sys/net/ipv4/conf/all/rp_filter

That command disables route verification for the current session, so the setting will not survive a reboot. Make it permanent by editing /etc/sysctl.conf and setting the value for net.ipv4.conf.all.rp_filter to 0.

[Warning] No Network Changes After Having Run the Cloud Installation Script

After you have run the cloud installation script, you cannot change the network setup anymore. If you did, you would need to completely set up the Administration Server again.

3.1.9.4. Repositories

Enter URLs to remote repositories on the Repositories tab. This is only necessary if you want to use repositories from an external SMT or SUSE Manager server rather than repositories local to the Administration Server. In the latter case you should not enter any URLs—empty values mean that the default values will be used. See Section 3.2.2, “Setting Up Repositories for Node Deployment” for in-depth information.

To change the URL for a repository, select an entry and enter the complete Repository URL. Activating Ask On Error will ensure that you will be informed, in case a repository will not be available during node deployment (otherwise errors will be silently ignored). See Section 2.2, “Product and Update Repositories” for an explanation of the Repository Names.

Figure 3.5. YaST Crowbar Setup: Repository Settings

YaST Crowbar Setup: Repository Settings

[Note]Configuring Custom Repositories

As of SUSE Cloud 3 it is not possible to configure external custom repositories with YaST. See Question: for manual configuration instructions.

3.2. Post-Installation Configuration

After the installation of the operating system and the add-on products has finished, you need to set up product and update repositories and, optionally, configure the bastion network. After the Administration Server host is fully configured, start the cloud installation script.

3.2.1. Setting up the SMT Repositories

If you are using an SMT server (locally or from another network), you need to configure it to mirror the update repositories needed for SUSE Cloud. Skip this step if you are not using an SMT server (but make sure the repositories listed at Section 2.2, “Product and Update Repositories” are available on the Administration Server).

The SMT server mirrors the update channels from the Novell Customer Center. In order to be able to access the SUSE Linux Enterprise Server and SUSE Cloud repositories, make sure to have registered both products in Novell Customer Center. Run the following commands as user root on the SMT server:

for REPO in SLES11-SP3-{Pool,Updates} SUSE-Cloud-3.0-{Pool,Updates}; do
  smt-repos $REPO sle-11-x86_64 -e
done
smt-mirror -L /var/log/smt/smt-mirror.log

For the optional HA setup you also need to mirror the High Availability repositories:

for REPO in SLE11-HAE-SP3-{Pool,Updates}; do
  smt-repos $REPO sle-11-x86_64 -e
done
smt-mirror -L /var/log/smt/smt-mirror_ha.log

The smt-repos command will add the list of repositories to the SMT server. The smt-mirror command will mirror them and download several GB of patches. This process may last up to several hours. A log file is written to /var/log/smt/smt-mirror.log. The following table lists all repositories and their file system location:

Table 3.3. SMT Repositories for SUSE Cloud

Repository

Directory

SLES11-SP3-Pool

/srv/www/htdocs/repo/$RCE/SLES11-SP3-Pool/sle-11-x86_64

SLES11-SP3-Updates

/srv/www/htdocs/repo/$RCE/SLES11-SP3-Updates/sle-11-x86_64

SUSE-Cloud-3-Pool

/srv/www/htdocs/repo/$RCE/SUSE-Cloud-3.0-Pool/sle-11-x86_64

SUSE-Cloud-3-Updates

/srv/www/htdocs/repo/$RCE/SUSE-Cloud-3.0-Updates/sle-11-x86_64


Table 3.4. Additional SMT Repositories for an HA setup (optional)

Repository

Directory

SLE11-HAE-SP3-Pool

/srv/www/htdocs/repo/$RCE/SLE11-HAE-SP3-Pool/sle-11-x86_64

SLE11-HAE-SP3-Updates

/srv/www/htdocs/repo/$RCE/SLE11-HAE-SP3-Updates/sle-11-x86_64


3.2.2. Setting Up Repositories for Node Deployment

In order to deploy the OpenStack nodes and to provide update repositories for them, product and update repositories for SUSE Linux Enterprise Server and SUSE Cloud must be configured. See Section 2.2, “Product and Update Repositories” for background information.

3.2.2.1. Product Repositories

The files in the product repositories for SUSE Linux Enterprise Server and SUSE Cloud do not change, therefore they do not need to be synced with a remote source. It is sufficient to either copy the data (from a remote host or the installation media) or mount the product repository from a remote server via NFS. Alternatively you may copy the iso images of DVD1 from both products to the admin node and loop mount them. Note that the data must be directly available from the local directories listed below. It is not possible to use links.

While the SUSE Linux Enterprise Server product repository must be made available locally, the SUSE Cloud repository may also be served via http from a remote host. However, copying the data (approximately 350 MB) to the Administration Server as described here, is recommended, since it does not require a custom network configuration for the Administration Server.

The following product repositories need to be available for SUSE Cloud deployment. Make sure to create these directories prior to copying or mounting the data:

Table 3.5. Local Product Repositories for SUSE Cloud

Repository

Directory

SLES11 SP3 Product

/srv/tftpboot/suse-11.3/install

Cloud 3 Product

/srv/tftpboot/repos/Cloud


3.2.2.1.1. Copying from the Installation Media

If copying, it is recommended to use rsync. If the installation data is located on a removable device, make sure to mount it first (for example, after inserting the DVD in the Administration Server and waiting for the device to become ready):

mount /dev/dvd /mnt
rsync -avP /mnt/ /srv/tftpboot/suse-11.3/install/
umount /mnt

Also make the contents of the SUSE Cloud product repository available at /srv/tftpboot/repos/Cloud/ the same way:

mount /dev/dvd /mnt
rsync -avP /mnt/ /srv/tftpboot/repos/Cloud/
umount /mnt
3.2.2.1.2. Copying from a Remote Host

If the SLES installation data is provided by a remote machine, log in to that machine and push the data to the Administration Server (which has the IP address 192.168.124.10 in the following example):

rsync -avPz /data/sles11sp3/ 192.168.124.10:/srv/tftpboot/suse-11.3/install/

Also make the contents of the SUSE Cloud product repository available at /srv/tftpboot/repos/Cloud/ the same way:

rsync -avPz /data/Cloud/ 192.168.124.10:/srv/tftpboot/repos/Cloud/
3.2.2.1.3. Mounting from an NFS Share

If the SLES installation data is provided via NFS by a remote machine, mount them as follows:

mount -t nfs nfs.example.com:/exports/SLES-11-SP3/x86_64/DVD1/ /srv/tftpboot/suse-11.3/install
mount -t nfs nfs.example.com:/exports/SUSE-CLOU/DVD1/ /srv/tftpboot/repos/Cloud

To automatically mount these directories either create entries in /etc/fstab or set up the automounter.

3.2.2.1.4. Mounting ISO Images

The product repositories can also be made available by copying the iso images of DVD1 to the Administration Server and mounting them:

mount -o loop /local/SLES-11-SP3-DVD-x86_64-DVD1.iso /srv/tftpboot/suse-11.3/install
mount -o loop /local/SUSE-CLOUD-3-DVD1.iso /srv/tftpboot/repos/Cloud

To automatically mount these directories either create entries in /etc/fstab or set up the automounter.

3.2.2.2. Update Repositories

Update repositories are already used when deploying the nodes that will build SUSE Cloud in order to ensure they are initially equipped with the latest software versions available. If you are using a remote SMT or SUSE Manager server, the update repositories from the remote server are used directly. In this case the repository URLs need to be added to the file /etc/crowbar/provisioner.json. If using repositories locally available, the Administration Server itself acts as the repository provider for all nodes. This requires to make them available in /srv/tftpboot/repos.

Table 3.6. Local Update Repositories for SUSE Cloud

Repository

Directory

SLES11-SP3-Pool

/srv/tftpboot/repos/SLES11-SP3-Pool

SLES11-SP3-Updates

/srv/tftpboot/repos/SLES11-SP3-Updates

SUSE-Cloud-3-Pool

/srv/tftpboot/repos/SUSE-Cloud-3-Pool

SUSE-Cloud-3-Updates

/srv/tftpboot/repos/SUSE-Cloud-3-Updates


Table 3.7.  Additional Local Update Repositories for an HA setup (optional)

Repository

Directory

SLE11-HAE-SP3-Pool

/srv/tftpboot/repos/SLE11-HAE-SP3-Pool

SLE11-HAE-SP3-Updates

/srv/tftpboot/repos/SLE11-HAE-SP3-Updates


3.2.2.2.1. Update Repositories Hosted on an SMT Server

An SMT server makes the SUSE update repositories available within your network by regularly synchronizing with the Novell Customer Center. To provide update repositories for SUSE Cloud, you can either use an existing SMT server from a network that can be accessed from the cloud, or install an SMT server on the Administration Server.

SMT Server installed on a Remote Host

In order to use repositories from a remote SMT server to deploy SUSE Cloud you first need to make sure the products SUSE Linux Enterprise Server 11 SP3 and Cloud 3 are registered and the corresponding channels are mirrored in SMT. Now you need to enter the repository URLs on the Repositories tab in the YaST Crowbar module as described in Section 3.1.9.4, “Repositories. A complete set of repository URLs is listed below. Note that you need to replace smt.example.com with the fully qualified host name of your SMT server.

http://smt.example.com/repo/\$RCE/SLES11-SP3-Pool/sle-11-x86_64/
http://smt.example.com/repo/\$RCE/SLES11-SP3-Updates/sle-11-x86_64/
http://smt.example.com/repo/\$RCE/SUSE-Cloud-3.0-Pool/sle-11-x86_64/
http://smt.example.com/repo/\$RCE/SUSE-Cloud-3.0-Updatessle-11-x86_64/

For the optional HA setup you also need the High Availability repositories:

http://smt.example.com/repo/\$RCE/SLE11-HAE-SP3-Pool/sle-11-x86_64/
http://smt.example.com/repo/\$RCE/SLE11-HAE-SP3-Updates/sle-11-x86_64/
SMT Server installed on the Administration Server

Link the repositories mirrored by SMT to /srv/tftpboot:

for REPO in SLES11-SP3-{Pool,Updates} SUSE-Cloud-3.0-{Pool,Updates}; do
  ln -s /srv/www/htdocs/repo/\$RCE/$REPO/sle-11-x86_64 /srv/tftpboot/repos/${REPO/.0/}
done

For the optional HA setup you also need the High Availability repositories:

for REPO in SLE11-HAE-SP3-{Pool,Updates}; do
  ln -s /srv/www/htdocs/repo/\$RCE/$REPO/sle-11-x86_64 /srv/tftpboot/repos/${REPO}/
done
3.2.2.2.2. Update Repositories Hosted on a SUSE Manager Server

In order to use repositories from SUSE Manager to deploy SUSE Cloud you first need to make sure the products SUSE Linux Enterprise Server 11 SP3 and SUSE Cloud 3 are registered and the corresponding channels are mirrored in SUSE Manager. By default SUSE Manager does not expose repositories for direct access. In order to be able to access them via https, you need to create a Distribution for auto-installation for the SUSE Linux Enterprise Server 11 SP3 (x86_64) Product on SUSE Manager. Instructions can be found at https://www.suse.com/documentation/suse_manager/book_susemanager_ref/data/book_susemanager_ref.html under the heading Creating Distribution for Autoinstallation. During the distribution setup you need to provide a Label for the distribution. This label will be part of the URL under which the repositories are available. It is recommended to choose a name consisting of characters that do not need to be URL-encoded, for example sles11-sp3-x86_64.

Creating a distribution for SUSE Linux Enterprise Server 11 SP3 not only makes the installation data and Update repositories for this product available, but also for all registered add-on products, including SUSE Cloud 3.

The repositories are available under the following URLs. manager.example.com needs to be replaced by the fully qualified host name of your SUSE Manager server and sles11-sp3-x86_64 needs to be replaced by the distribution label you specified when setting up the distribution for auto-installation. Note that the URLs are not browseable.

SLES11-SP3-Update

http://manager.example.com/ks/dist/child/sles11-sp3-updates-x86_64/sles11-sp3-x86_64/

SUSE-Cloud-3-Pool

http://manager.example.com/ks/dist/child/suse-cloud-3.0-pool-x86_64/sles11-sp3-x86_64/

SUSE-Cloud-3-Updates

http://manager.example.com/ks/dist/child/suse-cloud-3.0-updates-x86_64/sles11-sp3-x86_64/

For the optional HA setup you also need the High Availability repositories:

SLES11-SP3-HAE-Pool

http://manager.example.com/ks/dist/child/sle11-hae-sp3-pool-x86_64/sles11-sp3-x86_64/

SLES11-SP3-HAE-Updates

http://manager.example.com/ks/dist/child/sle11-hae-sp3-updates-x86_64/sles11-sp3-x86_64/

To make the repositories available for node deployment, you need to enter the repository URLs on the Repositories tab in the YaST Crowbar module as described in Section 3.1.9.4, “Repositories.

3.2.2.2.3. Update Repositories Hosted on a Remote Host

If the update repositories are hosted on a remote host that can be accessed from the Administration Server you can either mount them, for example via NFS, or regularly rsync them.

To NFS-mount the repositories from a remote host, either use the YaST NFS Client module or edit /etc/fstab. The local mount point should be /srv/tftpboot/repos/<REPOSITORY_NAME>.

To rsync the repositories from a remote host, create a daily cron job running the following command on the Administration Server. This command will pull the files from a host named host.example.com:

for REPO in SLES11-SP3-{Pool,Updates} SUSE-Cloud-3.0-{Pool,Updates}; do
  rsync -avPz host.example.com:/srv/www/htdocs/repo/\\\$RCE/$REPO/sle-11-x86_64/ \
  /srv/tftpboot/repos/${REPO/.0/}/
done

For the optional HA setup you also need the High Availability repositories:

for REPO in SLE11-HAE-SP3-{Pool,Updates}; do
  rsync -avPz host.example.com:/srv/www/htdocs/repo/\\\$RCE/$REPO/sle-11-x86_64/ \
  /srv/tftpboot/repos/${REPO}/
done

Alternatively you may set up the cron job on the remote host and push the files to the Administration Server (which has the IP address 192.168.124.10 in the following example):

for REPO in SLES11-SP3-{Pool,Updates} SUSE-Cloud-3.0-{Pool,Updates}; do
  rsync -avPz /srv/www/htdocs/repo/\\\$RCE/$REPO/sle-11-x86_64/ \
  192.168.124.10:/srv/tftpboot/repos/${REPO/.0/}/
done

And for the HA setup:

for REPO in SLE11-HAE-SP3-{Pool,Updates}; do
  rsync -avPz /srv/www/htdocs/repo/\\\$RCE/$REPO/sle-11-x86_64/ \
  192.168.124.10:/srv/tftpboot/repos/${REPO}/
done
[Note]Mind the Trailing Slash

The rsync command must be used with trailing slashes in the directory names as shown above. Otherwise rsync would copy the repositories into the wrong directory.

3.2.2.2.4. Update Repositories Hosted on Removable Media (Sneakernet)

If your admin network is isolated from other networks, you need to manually sync the update repositories from removable media. To do so you can either use rsync (see above for an example) or cp -axu. If copying from a SMT server, see Section 3.2.1, “Setting up the SMT Repositories” for a list of directories to copy.

3.2.3. Software Repository Sources on the Administration Server

Update repositories are not only required to deploy SUSE Cloud. The Administration Server itself also needs to be kept up-to-date and therefore needs to have a proper repository setup. In case you have registered SUSE Linux Enterprise Server and SUSE Cloud during the installation process, the Administration Server already has all required update repositories.

These repositories are served directly from Novell Customer Center. To avoid downloading the same patches twice or in case you want to cut off the Administration Server from the Internet, it makes sense to change this setup in a way that the repositories set up for SUSE Cloud deployment are also used on the Administration Server. To do so, you need to disable or delete all services. In a second step all SUSE Linux Enterprise Server and SUSE Cloud repositories need to be edited in order to point to the alternative sources. Editing the repository setup can either be done with Zypper or YaST. Note that changing the repository setup on the Administration Server is optional.

3.2.4. Custom Network Configuration

In case you need to adjust the pre-defined network setup of SUSE Cloud beyond the scope of changing IP address assignments (as described in Section 3.1.9, “Crowbar Setup”), you need to manually modify the network barclamp template. Refer to Appendix D, The Network Barclamp Template File for details.

3.2.5. Running the Cloud Installation Script

Before running the cloud installation script to finish the configuration of the Administration Server make sure to double-check the following items.

Final Check Points

  • Make sure the network configuration is correct. Run YaST+Crowbar to review/change the configuration. See Section 3.1.9, “Crowbar Setup” for further instructions.

    [Important]An HA Setup Requires Teaming Network Mode

    In case you are planning to make SUSE Cloud highly available upon the initial setup or at a later point in time, make sure to set up the network in teaming mode. Such a setup requires at least two network cards for each node.

  • Make sure hostname -f returns a fully qualified host name. See Section 3.1.7, “Basic Network Configuration” for further instructions.

  • Make sure all update and product repositories are available. See Section 3.2.2, “Setting Up Repositories for Node Deployment” for further instructions.

  • Make sure the operating system and SUSE Cloud are up-to-date and have the latest patches installed. Run zypper patch to install them.

Now everything is in place to finally configure the Administration Server. This is done by running the script install-suse-cloud. This command will install and configure Chef, and use it to complete the installation of Crowbar and all required barclamps. It will take several minutes to complete. If you are not using SUSE Manager to provide update repositories, run the following command:

screen install-suse-cloud

In case you are using SUSE Manager (as described in Section 3.2.2.2.2, “Update Repositories Hosted on a SUSE Manager Server”), you need to run the following command:

screen env REPOS_SKIP_CHECKS+=" SLES11-SP3-Pool" install-suse-cloud
[Important]Use a Terminal Multiplexer to run the Cloud Installation Script

Run the installation script install-suse-cloud inside of a terminal multiplexer like GNU Screen (provided by the screen package).

During the run of this script the network will be reconfigured. This may result in interrupting the script when being run from a network connection (like SSH). Using screen will continue running the script in a session to which you can reconnect via screen -r if you lose the connection.

install-suse-cloud will produce a lot of output that gets written to a log file located at /var/log/crowbar/install.log. Check this log file in case something goes wrong. You can run install-suse-cloud multiple times as long as you have not started to deploy the OpenStack services. It is also possible to run install-suse-cloud in verbose mode with the -v switch. It will show the same output that goes to the log file on STDOUT, too.

If the script has successfully finished, you will see a message telling you how to log in to the Crowbar Web interface.

[Warning] No Network Changes After Having Run the Cloud Installation Script

After you have run the cloud installation script, you cannot change the network setup anymore. If you did, you would need to completely set up the Administration Server again.

Figure 3.6. Crowbar Web Interface: Initial State

Crowbar Web Interface: Initial State

Chapter 4. Installing the OpenStack Nodes

The OpenStack nodes represent the actual cloud infrastructure. Node installation and service deployment is done automatically from the Administration Server. Before deploying the OpenStack services, you need to install SUSE Linux Enterprise Server on all nodes, except for the Compute Nodes running Windows (see Appendix E, Setting up a Netboot Environment for Microsoft* Windows for installation instructions) or VMware vSphere (see Appendix F, VMware vSphere Installation Instructions for installation instructions). In order to do so, each node needs to be PXE booted using the tftp server from the Administration Server. Afterwards you can allocate the nodes and trigger the operating system installation. There are three different types of nodes:

Control Node(s): One or more central management node(s) interacting with all other nodes.
Compute Nodes: The nodes on which the instances are started.
Storage Nodes: Nodes providing object or block storage.

4.1. Preparations

Meaningful Node names

Make a note of the MAC address and the purpose of each node (for example, controller, storage Ceph, storage Swift, compute). This will make deploying the OpenStack services a lot easier and less error-prone, since it enables you to assign meaningful names (aliases) to the nodes, which are otherwise listed with the MAC address by default.

BIOS Boot Settings

Make sure booting using PXE (booting from the network) is enabled and configured as the primary boot-option for each node. The nodes will boot twice from the network during the allocation and installation phase.

Custom Node Configuration

All nodes are installed using AutoYaST with the same configuration located at /opt/dell/chef/cookbooks/provisioner/templates/default/autoyast.xml.erb. If this configuration does not match your needs (for example if you need special third party drivers) you need to make adjustments to this file. An AutoYaST manual can be found at http://www.suse.com/documentation/sles11/book_autoyast/data/book_autoyast.html. Having changed the AutoYaST configuration file, you need to re-upload it to Chef, using the following command:

knife cookbook upload -o /opt/dell/chef/cookbooks/ provisioner
Direct root Login

By default, the root account on the nodes has no password assigned, so a direct root login is not possible. Logging in on the nodes as root is only possible via SSH public keys (for example, from the Administration Server).

If you want to allow direct root login, you can set a password via the Crowbar Provisioner barclamp before deploying the nodes. That password will be used for the root account on all OpenStack nodes. Using this method after the nodes are deployed is not possible. In that case you would need to log in to each node via SSH from the Administration Server and change the password manually with passwd.

Setting a root Password for the OpenStack Nodes

  1. Create an md5-hashed root-password, for example by using openssl passwd -1.

  2. 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 during the installation.

  3. Open the barclamp menu by clicking Barclamps+Crowbar. Click the Provisioner barclamp entry and Edit the Default proposal.

  4. Click Raw in the Attributes section to edit the configuration file.

  5. Add the following line to the end of the file before the last closing curly bracket:

    , "root_password_hash": "HASHED_PASSWORD"

    replacing "HASHED_PASSWORD" with the password you generated in the first step.

  6. Click Apply.

Preparing a Windows Netboot Environment

In case you plan to deploy Compute Nodes running either Microsoft Hyper-V Server or Windows Server 2012, you need to prepare a Windows Netboot Environment. Refer to Appendix E, Setting up a Netboot Environment for Microsoft* Windows for details.

4.2. Node Installation

To install a node, you need to boot it first using PXE. It will be booted with an image that enables the Administration Server to discover the node and make it available for installation. Once you have allocated the node, it will boot using PXE again and the automatic installation will start.

  1. Boot all nodes using PXE that you want to deploy. The nodes will boot into the SLEShammer image, which performs the initial hardware discovery.

    [Important]Limit the Number of Concurrent PXE Boots

    PXE Booting a large number nodes at the same time will cause heavy load on the TFTP server, because all nodes will request the boot image at the same time. It is recommended to boot the nodes time-delayed.

  2. 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 Nodes+Dashboard to open the Node Dashboard.

  3. Each node that has successfully booted will be listed as being in state Discovered, indicated by a yellow bullet. The nodes will be listed with their MAC address as a name. Wait until all nodes are listed as being Discovered before proceeding. In case a node does not report as being Discovered, it may need to be rebooted manually.

    Figure 4.1. Discovered Nodes

    Discovered Nodes

  4. Although this step is optional, it is recommended to properly group your nodes at this stage, since it lets you clearly arrange all nodes. Grouping the nodes by role would be one option, for example control, compute, object storage (Swift), and block storage (Ceph).

    1. Enter the name of a new group into the New Group text box and click Add Group.

    2. Drag and drop a node onto the title of the newly created group. Repeat this step for each node you want to put into the group.

      Figure 4.2. Grouping Nodes

      Grouping Nodes

  5. To allocate the nodes click on Nodes+Bulk Edit. If you prefer to allocate the nodes one-by-one, click a node's name followed by a click on Edit instead.

    Figure 4.3. Editing a Single Node

    Editing a Single Node

    [Important]Limit the Number of Concurrent Node Deployments

    Deploying a large number of nodes in bulk mode will cause heavy load on the Administration Server. The subsequent concurrent Chef client runs triggered by the nodes will require a lot of RAM on the Administration Server.

    Therefore it is recommended to limit the number of concurrent Allocations in bulk mode. The maximum number depends on the amount of RAM on the Administration Server—limiting concurrent deployments to five up to ten is recommended.

  6. Provide a meaningful Alias, Public Name and a Description for each node and check the Allocate box. If using the single node edit form, you can also specify the Intended Role for the node. This optional setting is used to make reasonable proposals for the barclamps.

    Normally Target Platform needs to be set to suse-11.3. If you plan to support Hyper-V in your cloud, you need to prepare the Windows netboot environment as described in Appendix E, Setting up a Netboot Environment for Microsoft* Windows. After that is done, set the Target Platform of the Compute Nodes that should run Windows to either Windows Server or HyperV Server. When specifying Windows Server you also need to add a valid License Key.

    [Tip]Alias Names

    Providing an alias name will change the default node names (MAC address) to the name you provided, making it easier to identify the node. Furthermore, this alias will also be used as a DNS CNAME for the node in the admin network. As a result, you will be able to access the node via this alias when, for example, logging in via SSH.

    [Tip]Public Names

    A node's Alias Name is resolved by the DNS server installed on the Administration Server and therefore only available within the cloud network. The OpenStack Dashboard or some APIs (keystone-server, glance-server, cinder-controller, neutron-server, nova-multi-controller, and swift-proxy) can be accessed from outside the SUSE Cloud network. In order to be able to access them by name, these names need to be resolved by a name server placed outside of the SUSE Cloud network. If you have created DNS entries for nodes, specify the name in the Public Name field.

    The Public Name is never used within the SUSE Cloud network. However, if you create an SSL certificate for a node that has a public name, this name must be added as an AlternativeName to the certificate (see Section 2.4, “SSL Encryption” for more information).

    Figure 4.4. Bulk Editing Nodes

    Bulk Editing Nodes

  7. Once you have filled in the data for all nodes, click Save. The nodes will reboot and commence the AutoYaST-based SUSE Linux Enterprise Server installation via a second PXE boot. Click Nodes+Dashboard to return to the Node Dashboard.

  8. Nodes that are being installed are listed with the status Installing (yellow/green bullet). Once the installation of a node has finished, it is listed as being Ready, indicated by a green bullet. Wait until all nodes are listed as being Ready before proceeding.

    Figure 4.5. All Nodes Have Been Installed

    All Nodes Have Been Installed

4.2.1. Converting Existing SLES 11 SP3 Machines Into SUSE Cloud Nodes

SUSE Cloud also allows to add existing machines installed with SLES 11 SP3 to the pool of nodes. This enables you to not only use spare machines for SUSE Cloud, but also offers an alternative way of provisioning and installing nodes (via SUSE Manager for example). A mandatory prerequisite is that the machine must run SLES 11 SP3.

It is also required that the machine is on the same network as the Administration Server, since it needs to communicate with this server. Since the Administration Server provides a DHCP server, it is recommended to configure the respective network device with DHCP. If using a static IP address, make sure it is not already used in the admin network (check the list of used IP addresses with the YaST Crowbar module as described in Section 3.1.9.2, “Networks).

Proceed as follows to convert an existing SLES 11 SP3 machine into a SUSE Cloud node:

  1. Download the crowbar_register script from the Administration Server at http://192.168.124.10:8091/suse-11.3/crowbar_register (replace the IP address with the IP address of your Administration Server using curl or wget).

  2. Make the crowbar_register script executable (chmod a+x crowbar_register).

  3. Run the crowbar_register script. If you have multiple network interfaces, the script tries to automatically detect the one that is connected to the admin network. You may also explicitly specify which network interface to use by using the --interface switch, for example crowbar_register --interface eth1.

  4. After the script has successfully run, the machine has been added to the pool of nodes in the SUSE Cloud and can be used as any other node from the pool.

4.3. Post-Installation Configuration

The following lists some optional configuration steps like configuring node updates, monitoring, access and SSL-enablement. You may entirely skip the following steps or perform any of them at a later stage.

4.3.1. Deploying Node Updates with the Updater barclamp

In order to keep the operating system and the SUSE Cloud software itself up-to-date on the nodes, you can either deploy the Updater barclamp or the SUSE Manager barclamp. While the latter requires access to a SUSE Manager server, the Updater barclamp uses Zypper to install updates and patches from repositories made available on the Administration Server.

The easiest way to provide the required repositories on the Administration Server is to set up an SMT server as described in Section 3.1.8, “SMT Configuration” and Section 3.2.1, “Setting up the SMT Repositories”. Alternatives to setting up an SMT server are described in Section 2.2, “Product and Update Repositories”.

The Updater barclamp lets you deploy updates that are available on the update repositories at the moment of deployment. Each time you deploy updates with this barclamp you can choose a different set of nodes to which the updates are deployed. This lets you exactly control where and when updates are deployed.

To deploy the Updater barclamp, proceed as follows. For general instructions on how to edit barclamp proposals refer to Section 5.1, “Barclamps”.

  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 during the installation.

  2. Open the barclamp menu by clicking Barclamps+Crowbar. Click the Updater barclamp entry and Create to open the proposal.

  3. Configure the barclamp by the following attributes. This configuration always applies to all nodes on which the barclamp is deployed. Creating individual configurations for certain nodes is not supported.

    Use zypper

    Define which Zypper subcommand to use for updating. patch will install all patches applying to the system from the configured update repositories that are available. update will update packages from all configured repositories (not just the update repositories) that have a higher version number than the installed packages. dist-upgrade replaces each package installed with the version from the repository and deletes packages not available in the repositories.

    Using patch is recommended.

    Enable GPG Checks

    If set to true (recommended), checks if packages are correctly signed.

    Automatically Agree With Licenses

    If set to true (recommended), Zypper automatically accepts third party licenses.

    Include Patches that need Reboots (Kernel)

    Installs patches that require a reboot (for example Kernel or glibc updates). Only set this option to true when you can safely reboot the affected nodes. Refer to Chapter 6, SUSE Cloud Maintenance for more information. Installing a new Kernel and not rebooting may result in an unstable system.

    Reboot Nodes if Needed

    Automatically reboots the system in case a patch requiring a reboot has been installed. Only set this option to true when you can safely reboot the affected nodes. Refer to Chapter 6, SUSE Cloud Maintenance for more information.

    Figure 4.6. SUSE Updater barclamp: Configuration

    SUSE Updater barclamp: Configuration

  4. Choose the nodes on which the Updater barclamp should be deployed in the Node Deployment section by dragging them to the Updater column.

    Figure 4.7. SUSE Updater barclamp: Node Deployment

    SUSE Updater barclamp: Node Deployment

zypper keeps track of the packages and patches it installs in /var/log/zypp/history. Review that log file on a node to find out which updates have been installed. A second log file recording debug information on the zypper runs can be found at /var/log/zypper.log on each node.

4.3.2.  Configuring Node Updates with the SUSE Manager Client barclamp

In order to keep the operating system and the SUSE Cloud software itself up-to-date on the nodes, you can either deploy SUSE Manager Client barclamp or the Updater barclamp. The latter uses Zypper to install updates and patches from repositories made available on the Administration Server.

To enable the SUSE Manager server to manage the SUSE Cloud nodes, the respective SUSE Cloud 3 channels (SUSE-Cloud-3-Pool, SUSE-Cloud-3-Updates) need to be available on the server. It also requires to generate an Activation Key for SUSE Cloud.

The SUSE Manager Client barclamp requires access to the SUSE Manager server from every node it is deployed to.

To deploy the SUSE Manager Client barclamp, proceed as follows. For general instructions on how to edit barclamp proposals refer to Section 5.1, “Barclamps”.

  1. Generate an Activation Key for SUSE Cloud on the SUSE Manager server. See the section Activation Keys at http://www.suse.com/documentation/suse_manager/book_susemanager_ref/data/s1-sm-systems.html for instructions).

  2. Download the package rhn-org-trusted-ssl-cert-VERSION-RELEASE.noarch.rpm from https://susemanager.example.com/pub/. VERSION and RELEASE may vary, ask the administrator of the SUSE Manager for the correct values. susemanager.example.com needs to be replaced by the address of your SUSE Manager server. Copy the file you downloaded to /opt/dell/chef/cookbooks/suse-manager-client/files/default/ssl-cert.rpm on the Administration Server. The package contains the SUSE Manager's CA SSL Public Certificate. The certificate installation has not been automated on purpose, because downloading the certificate manually enables you to check it before copying it.

  3. Re-install the barclamp by running the following command:

    /opt/dell/bin/barclamp_install.rb --rpm suse-manager-client
  4. 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 during the installation.

  5. Open the barclamp menu by clicking Barclamps+Crowbar. Click the SUSE Manager Client barclamp entry and Create to open the proposal.

  6. Configure the barclamp by the following attributes. This configuration always applies to all nodes on which the barclamp is deployed. Creating individual configurations for certain nodes is not supported.

    Activation Key

    Enter the SUSE Manager activation key for SUSE Cloud here. This key must have been generated on the SUSE Manager server.

    SUSE Manager Server Hostname

    Fully qualified host name of the SUSE Manager server. This name must be resolvable via the DNS server on the Administration Server.

  7. Choose the nodes on which the SUSE Manager barclamp should be deployed in the Node Deployment section by dragging them to the suse-manager-client column. It is recommended to deploy it on all nodes in the SUSE Cloud.

    Figure 4.8. SUSE Manager barclamp

    SUSE Manager barclamp

4.3.3. Mounting NFS Shares on a Node

The NFS barclamp allows you to mount NFS share from a remote host on nodes in the cloud. This feature can, for example, be used to provide an image repository for Glance. Note that all nodes which are to mount an NFS share must be able to reach the NFS server. This requires to manually adjust the network configuration.

To deploy the NFS barclamp, proceed as follows. For general instructions on how to edit barclamp proposals refer to Section 5.1, “Barclamps”.

  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 during the installation.

  2. Open the barclamp menu by clicking Barclamps+Crowbar. Click the NFS Client barclamp entry and Create to open the proposal.

  3. Configure the barclamp by the following attributes. Each set of attributes is used to mount a single NFS share.

    Name

    Unique name for the current configuration. This name is used in the Web interface only to distinguish between different shares.

    NFS Server

    Fully qualified host name or IP address of the NFS server.

    Export on Server

    Export name for the share on the NFS server.

    Mount Options

    Mount options that will be used on the node. See man 8 mount for general mount options and man 5 nfs for a list of NFS-specific options. Note that the general option nofail (do not report errors if device does not exist) is automatically set.

  4. Click Add after having filled in all attributes. If you want to mount more than one share, fill in the data for another NFS mount, otherwise click Save to save the data, or Apply to deploy the proposal. Note that you must always click Add before saving or applying the barclamp, otherwise the data that was entered will be lost.

    Figure 4.9. NFS barclamp

    NFS barclamp

  5. Go to the Node Deployment section and drag and drop all nodes, on which the NFS shares defined above should be mounted, to the nfs-client column. Click Apply to deploy the proposal.

    The NFS barclamp is the only barclamp that lets you create different proposals, enabling you to be able to mount different NFS shares on different nodes. Once you have created an NFS proposal, a special Edit is shown in the barclamp overview screen of the Crowbar Web interface. Click it to either Edit an existing proposal or Create a new one. Creating a new proposal requires to give it a unique name.

    Figure 4.10. Editing an NFS barclamp Proposal

    Editing an NFS barclamp Proposal

4.3.4. Using an Externally Managed Ceph Cluster

While deploying Ceph from within SUSE Cloud is only included as an unsupported technical preview, leveraging an external Ceph cluster is fully supported. Follow the instructions below to make use of the Ceph cluster in SUSE Cloud.

4.3.4.1. Requirements

Ceph Release

SUSE Cloud uses Ceph clients from the Ceph Dumpling release. Since other Ceph releases may not fully work with Dumpling clients, the external Ceph installation must run a Dumpling release, too. Other releases are not supported.

Network Configuration

The external ceph cluster needs to be connected to a separate VLAN, which is mapped to the SUSE Cloud storage VLAN (see Section 2.1, “Network” for more information).

4.3.4.2. Making Ceph Available on the SUSE Cloud Nodes

Ceph can be used from the KVM Compute Nodes and with Glance, Cinder. The following installation steps need to be executed on each node accessing Ceph:

[Important]Installation Workflow

The following steps need to be executed before the barclamps get deployed.

[Warning]Do not deploy the Ceph barclamp

If using an external Ceph cluster, you must not deploy the SUSE Cloud Ceph barclamp. An external and an internal Ceph cluster cannot be used together.

  1. Log in as user root to a machine in the Ceph cluster and generate keyring files for the Glance (optional, only needed when using Glance with Ceph/Rados) and Cinder users. The keyring file that will be generated for Cinder will also be used on the Compute Nodes. To do so, you need to specify pool names and user names for both services. The default names are:

    Glance

    Cinder

    User

    glance

    volumes

    Pool

    images

    volumes

    Make a note of user and pool names in case you do not use the default values—you will need this information later, when deploying Glance and Cinder.

    Create the keyring file with the following commands. Re-run the commands for Glance, too, if needed.

    1. Generate a key:

      ceph auth get-or-create-key client.USERNAME mon "allow r" \
      osd 'allow class-read object_prefix rbd_children, allow rwx \
      pool=POOLNAME'

      Replace USERNAME and POOLNAME with the respective values.

    2. Use the key to generate the keyring file /etc/ceph/ceph.client.USERNAME.keyring:

      ceph-authtool \
      /etc/ceph/ceph.client.USERNAME.keyring \
      --create-keyring --name=client.USERNAME> \
      --add-key=KEY

      Replace USERNAME with the respective value.

  2. Copy the Ceph configuration file ceph.conf (usually located in /etc/ceph) and the keyring file(s) generated in the previous step to a temporary location on the Administration Server, for example /root/tmp/.

  3. Log in to the Crowbar Web interface and check whether the nodes which should have access to the Ceph cluster already have an IP address from the storage network. Do so by going to the Dashboard and clicking the node name. An IP address should be listed for storage. Make a note of the Full name of each node that has no storage network IP address.

  4. Log in to the Administration Server as user root and run the following command for all nodes you noted down in the previous step:

    crowbar network allocate_ip "default" NODE "storage" "host"
    chef-client

    NODE needs to be replaced by the node's name.

  5. After having executed the command in the previous step for all affected nodes, run the command chef-client on the Administration Server.

  6. Log in to each affected node as user root. See Question: for instructions. On each node, do the following:

    1. Manually install nova, cinder (if using Ceph) and/or glance (if using Ceph) packages with the following commands:

      zypper in openstack-glance
      zypper in openstack-cinder
      zypper in openstack-nova
    2. Copy the ceph.conf file from the Administration Server to /etc/ceph:

      mkdir -p /etc/ceph
      scp root@admin:/root/tmp/ceph.conf /etc/ceph
      chmod 664 /etc/ceph/ceph.conf
    3. Copy the keyring file to /etc/ceph. The keyring file created for Cinder needs to be copied to the Control Node on which Cinder will be deployed as well as to all KVM nodes:

      scp root@admin:/root/tmp/ceph.client..volumes.keyring /etc/ceph
      chmod 640 /etc/ceph/ceph.client..volumes.keyring

      The keyring file created for Glance needs to be copied to the Control Node on which Glance will be deployed. For example:

      scp root@admin:/root/tmp/ceph.client.glance.keyring /etc/ceph
      chmod 640 /etc/ceph/ceph.client.glance.keyring
    4. Adjust the ownership of the keyring file as follows:

      Glance: chown root.openstack-glance /etc/ceph/ceph.volumes.keyring
      Cinder: chown root.openstack-cinder /etc/ceph/ceph.glance.keyring
      KVM Compute Nodes: chown root.openstack-nova /etc/ceph/ceph.volumes.keyring

4.3.5. Accessing the Nodes

The nodes can only be accessed via SSH from the Administration Server—it is not possible to connect to them from any other host in the network.

The root account on the nodes has no password assigned, therefore logging in to a node as root@node is only possible via SSH with key authentication. By default, you can only log in with the key of the root of the Administration Server (root@admin) via SSH only.

In case you have added additional users to the Administration Server and want to give them permission to log in to the nodes as well, you need to add these user's public SSH keys to root's authorized_keys file on all nodes. Proceed as follows:

Procedure 4.1. Copying SSH Keys to All Nodes

  1. If not already existing, generate an SSH key pair for the user that should be able to log in to the nodes with ssh-keygen. Alternatively copy an existing public key with ssh-copy-id. Refer to the respective man pages for more information.

  2. Log in to the Crowbar Web interface available at port 3000 of the Administration Server, for example http://192.168.124.10:3000/ (user name and default password: crowbar).

  3. Open the barclamp menu by clicking Barclamps+All Barclamps. Click the Provisioner barclamp entry and Edit the Default proposal.

  4. Copy and paste the public SSH key of the user into the Additional SSH Keys text box. If adding keys for multiple users, note that each key needs to be placed on a new line.

  5. Click Apply to deploy the keys and save your changes to the proposal.

4.3.6. Enabling SSL (optional)

In order to enable SSL to encrypt communication within the cloud (see Section 2.4, “SSL Encryption” for details), the respective certificates need to be available on the nodes running the encrypted services. An SSL certificate is at least required on the Control Node.

To make them available, copy them to the node. Each certificate consists of a pair of files the certificate file (for example, signing_cert.pem) and the key file (for example, signing_key.pem). If you use your own certificate authority (CA) for signing, you will also need a certificate file for the CA (for example, ca.pem). It is recommended to copy the files to the /etc directory using the directory structure outlined below. If you use a dedicated certificate for each service, create directories named after the services (for example, /etc/keystone). If sharing the certificates, use a directory such as /etc/cloud.

SSL Certificate File

/etc/cloud/ssl/certs/signing_cert.pem

SSL Key File

/etc/cloud/private/signing_key.pem

CA Certificates File

/etc/cloud/ssl/certs/ca.pem

Figure 4.11. The SSL Dialog

The SSL Dialog

4.4. Editing Allocated Nodes

All nodes that have been allocated can be decommissioned or re-installed. Click a node's name in the Node Dashboard to open a screen with the node details. The following options are available:

Reinstall

Triggers a reinstallation. The machine stays allocated.

Deallocate

Temporarily removes the node from the pool of nodes. After you reallocate the node it will take its former role. Useful for adding additional machines in times of high load or for decommissioning machines in times of low load.

Forget

Deletes a node from the pool. If you want to re-use this node again, it needs to be reallocated and re-installed from scratch.

Reboot

Reboots the node.

Shutdown

Shuts the node down.

Figure 4.12. Node Information

Node Information

[Warning]Editing Nodes in a Production System

When deallocating nodes that provide essential services, the complete cloud will become unusable. While it is uncritical to disable single storage nodes (provided you have not disabled redundancy) or single compute nodes, disabling Control Node(s) will cause major problems. It will either kill certain services (for example Swift) or, at worst (when deallocating the Control Node hosting Neutron) the complete cloud. You should also not disable nodes providing Ceph monitoring services or the nodes providing swift ring and proxy services.

Chapter 5. Deploying the OpenStack Services

After the nodes are installed and configured you can start deploying the OpenStack services to finalize the installation. The services need to be deployed in a given order, because they depend on one another. The Pacemaker service for an HA setup is the only exception from this rule—it can be setup at any time. However, when deploying SUSE Cloud from scratch, it is recommended to deploy the Pacemaker proposal(s) first. Deployment for all services 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 Control Node(s) (refer to Section 1.2, “The Control Node(s)” for more information). However, you may not use your Control Node(s) as a compute node or storage host for Swift or Ceph. Here is a list with services that may not be installed on the Control Node(s): swift-storage, Ceph-store, Nova-multi-compute. These services need to be installed on dedicated nodes.

When deploying an HA setup the controller nodes are replaced by one or more controller clusters consisting of at least two nodes (three are recommended). Setting up three separate clusters—for data, services, and networking—is recommended. See Section 2.7, “High Availability” for more information on requirements and recommendations for an HA setup.

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, “Barclamps”. Deploying Pacemaker (only needed for an HA setup), Swift and Ceph is optional; all other services must be deployed.

  1. Deploying Pacemaker (Optional, HA Setup Only)

  2. Deploying the Database

  3. Deploying Keystone

  4. Deploying RabbitMQ

  5. Deploying Ceph (optional, unsupported)

    [Important]Deploying Ceph within SUSE Cloud is Not Supported

    Ceph is included in SUSE Cloud 3 as a technology preview. You may use Ceph in test environments but it is not recommended for production.

    The supported way to use Ceph for SUSE Cloud is to make use of an external Ceph cluster. See Section 4.3.4, “Using an Externally Managed Ceph Cluster” for more information and installation instructions.

  6. Deploying Swift (optional)

  7. Deploying Glance

  8. Deploying Cinder

  9. Deploying Neutron

  10. Deploying Nova

  11. Deploying Horizon (OpenStack Dashboard)

5.1. Barclamps

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 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. You can either Create a proposal or Edit an existing one.

    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

    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 text box—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 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, “Delete 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 Q & A 7.1.2, “OpenStack Node Deployment” for help. A deployment failure may leave your node in an inconsistent state.

5.1.1. Delete a Proposal that Already has been Deployed

To delete a proposal that already has been deployed, you first need to Deactivate it in the Crowbar Web interface. Deactivating a proposal will remove software and services having been deployed by this proposal from the affected nodes. After a proposal has been deactivated, you can Delete it in the Crowbar Web interface and Create a new proposal from the barclamp overview.

5.2. Deploying Pacemaker (Optional, HA Setup Only)

By setting up one or more clusters by deploying Pacemaker, you can make the SUSE Cloud control controller functions highly available (see Section 2.7, “High Availability” for details). Since it is possible (and recommended) to deploy more than one cluster, a proposal needs to be created for each cluster.

Deploying Pacemaker is optional. In case you do not want to deploy it, skip this section and start the node deployment by deploying the database as described in Section 5.3, “Deploying the Database”.

[Note]Number of Cluster Nodes

To set up a cluster, at least two nodes are required. If setting up a cluster with replicated storage via DRBD (for example for a cluster for the database and RabbitMQ), exactly two nodes are required. For all other setups an odd number of nodes with a minimum of three nodes is strongly recommended. See Section 2.7.5, “Cluster Requirements and Recommendations” for more information.

To create a proposal, go to Barclamps+OpenStack and click Edit for the Pacemaker barclamp. A drop-down box where you can enter a name and a description for the proposal opens. Click Create to open the configuration screen for the proposal.

[Important]Proposal Name

The name you enter for the proposal will be used to generate host names for the virtual IPs of HAProxy. The name uses the following scheme:

NAME.cluster-PROPOSAL NAME.FQDN

When the proposal name is set to data, this results in, for example, controller.cluster-data.example.com.

The following options are configurable in the Pacemaker configuration screen:

Policy when cluster does not have quorum

Whenever communication fails between one or more nodes and the rest of the cluster a cluster partition occurs. The nodes of a cluster are split in partitions but are still active. They can only communicate with nodes in the same partition and are unaware of the separated nodes. The cluster partition that has the majority of nodes is defined to have quorum.

This configuration option defines what to do with the cluster partition(s) that do not have the quorum. See https://www.suse.com/documentation/sle_ha/book_sleha/data/sec_ha_configuration_basics_global.html, section Option no-quorum-policy for details.

The recommended setting is to choose Stop. However, Ignore is enforced for two-node clusters to ensure that the remaining node continues to operate normally in case the other node fails. For clusters using shared resources, choosing freeze may be used to ensure that these resources continue to be available.

Configuration mode for STONITH

Misbehaving nodes in a cluster are shut down to prevent it from causing trouble. This mechanism is referred to as STONITH (Shoot the other node in the head). STONITH can be configured in a variety of ways, refer to https://www.suse.com/documentation/sle_ha/book_sleha/data/cha_ha_fencing.html for details. The following configuration options exist:

Configured manually

STONITH will not be configured when deploying the barclamp. It needs to be configured manually as described in https://www.suse.com/documentation/sle_ha/book_sleha/data/sec_ha_fencing_config.html. For experts only.

Configured with IPMI data from the IPMI barclamp

Using this option automatically sets up STONITH with data received from the IPMI barclamp. Being able to use this option requires that IPMI is configured for all cluster nodes. This should be done by default, when deploying cloud. To check or change the IPMI deployment, go to Barclamps+Crowbar+IPMI+Edit. Also make sure the Enable BMC option is set to true on this barclamp.

[Important]STONITH Devices Must Support IPMI

In order to configure STONITH with the IPMI data, all STONITH devices must support IPMI. Problems with this setup may occur with IPMI implementations that are not strictly standards compliant. In this case it is recommended to set up STONITH with STONITH block devices (SBD).

Configured with STONITH Block Devices (SBD)

This option requires to manually set up shared storage and a watchdog on the cluster nodes before applying the proposal. Refer to https://www.suse.com/documentation/sle_ha/book_sleha/data/sec_ha_storage_protect_fencing.html for in-depth information and setup instructions. After the storage devices are partitioned and the watchdog is running, specify the block devices used for shared storage for each node. The paths to the block devices must be entered with the by-id path: /dev/disk/by-id/DEVICE.

Deploying the barclamp will automatically complete the SBD setup on the cluster nodes by starting the SBD daemon and configuring the fencing resource.

Configured with one shared resource for the whole cluster

All nodes will use the exact same configuration. Specify the Fencing Agent to use and enter Parameters for the agent.

To get a list of STONITH devices which are supported by the High Availability Extension, run the following command on an already installed cluster nodes: stonith -L. The list of parameters depends on the respective agent. To view a list of parameters use the following command: stonith -t agent -n.

Configured with one resource per node

All nodes in the cluster use the same Fencing Agent, but can be configured with different parameters. This setup is, for example, required when nodes are in different chassis and therefore need different ILO parameters.

To get a list of STONITH devices which are supported by the High Availability Extension, run the following command on an already installed cluster nodes: stonith -L. The list of parameters depends on the respective agent. To view a list of parameters use the following command: stonith -t agent -n.

Configured for nodes running in libvirt

Use this setting for completely virtualized test installations. This option is not supported.

Enable Mail Notifications

Get notified of cluster node failures via e-mail. If set to true, you need to specify which SMTP Server to use, a prefix for the mails' subject and sender and recipient addresses. Note that the SMTP server must be accessible by the cluster nodes.

Prepare Cluster for DRBD

Set up DRBD for replicated storage on the cluster. This option requires a two-node cluster with a spare hard disk for each node. The disks should have a minimum size of 100 GB. Using DRBD is recommended for making the database and RabbitMQ highly available. For other clusters, set this option to False.

Public name for public virtual IP

The public name is the host name that will be used instead of the generated public name (see Proposal Name) for the public virtual IP of HAProxy (when registering public endpoints, for instance). Any name specified here needs to be resolved by a name server placed outside of the SUSE Cloud network.

Password for hacluster user in Hawk

The password for the user hacluster. The default value is crowbar.

Setup non-web GUI

Pacemaker supports two GUIs to monitor the cluster status. A Web user interface that can be installed by deploying the hawk-server role (see below), and the Pacemaker GUI application. The latter can be installed on the cluster by setting this option to true. To access the GUI, log in to a cluster node with ssh -X as user hacluster and start crm_gui. Note that the GUI on SUSE Cloud should only be used to monitor the cluster status and not to change its configuration.

Figure 5.1. The Pacemaker Barclamp

The Pacemaker Barclamp

The Pacemaker service consists of two different roles. Deploying the hawk-server role is optional:

pacemaker-cluster-member

Deploy this role on all nodes that should become member of the cluster except for the one where pacemaker-cluster-founder is deployed.

hawk-server

Deploying this role is optional. If deployed, sets up the Hawk Web interface which lets you monitor the status of the cluster. The Web interface can be accessed via http://IP-ADDRESS:7630. Note that the GUI on SUSE Cloud can only be used to monitor the cluster status and not to change its configuration.

hawk-server may be deployed on at least one cluster node. It is recommended to deploy it on all cluster nodes.

Figure 5.2. The Pacemaker Barclamp: Node deployment Example

The Pacemaker Barclamp: Node deployment Example

After a cluster has been successfully deployed, it is listed under Available Clusters in the Deployment section and can be used for role deployment like a regular node.

[Warning]Deploying Roles on Single Cluster Nodes

When using clusters, roles from other barclamps must never be deployed to single nodes that are already part of a cluster. The only exceptions from this rule are the following roles:

  • Ceph-mon

  • cinder-volume

  • swift-proxy + swift-dispersion

  • swift-ring-compute

  • swift-storage

Figure 5.3. Available Clusters in the Deployment Section

Available Clusters in the Deployment Section

[Important]Service Management on the Cluster

After a role has been deployed on a cluster, its services are managed by the HA software. You must never ever manually start or stop an HA-managed service or configure it to start on boot (for example by running insserv for the service). Services may only be started or stopped by using the cluster management tools Hawk, the Pacemaker GUI or the crm shell. See https://www.suse.com/documentation/sle_ha/book_sleha/data/sec_ha_configuration_basics_resources.html for more information.

[Note]Testing the Cluster Setup

To check whether all cluster resources are running, either use the Hawk Web interface or run the command crm_mon -1r. If it is not the case, clean up the respective resource with crm resource cleanup RESOURCE , so it gets respawned.

Also make sure that STONITH correctly works before continuing with the SUSE Cloud setup. This is especially important when having chosen a STONITH configuration requiring manual setup. To test if STONITH works, log in to a node on the cluster and run the following command:

pkill -9 corosync

In case STONITH is correctly configured, the node will reboot.

Before testing on a production cluster, plan a maintenance window in case issues should arise.

5.3. Deploying the Database

The very first service that needs to be deployed is the Database. The database service is using PostgreSQL and is used by all other services. It must be installed on a Control Node. The Database can be made highly available by deploying it on a cluster.

The only attribute you may change is the maximum number of database connections (Global Connection Limit ). The default value should work in most cases—only change it for large deployments in case the log files show database connection failures.

Figure 5.4. The Database Barclamp

The Database Barclamp

5.3.1. HA Setup for the Database

To make the database highly available, deploy it on a cluster rather than on a single Control Node. This also makes it necessary to provide shared storage for the cluster that hosts the database data. This can either be achieved by setting up a cluster with DRBD support (see Section 5.2, “Deploying Pacemaker (Optional, HA Setup Only)”) or by using traditional shared storage like an NFS share. It is recommended to use a dedicated cluster to deploy the database together with RabbitMQ, since both services require shared storage.

Deploying the database on a cluster makes an additional High Availability section available in the Attributes section of the proposal. Configure the Storage Mode in this section. There are two options:

DRBD

This option requires a two-node cluster that has been set up with DRBD. Also specify the Size to Allocate for DRBD Device (in Gigabytes). The suggested value of 50 GB should be sufficient.

Shared Storage

Use a shared block device or an NFS mount for shared storage. Concordantly with the mount command, you need to specify three attributes: Name of Block Device or NFS Mount Specification (the mount point), the Filesystem Type and the Mount Options.

[Important]NFS Export Options for Shared Storage

An NFS share that is to be used as a shared storage for a cluster needs to be exported on the NFS server with the following options:

rw,async,insecure,no_subtree_check,no_root_squash

In case mounting the NFS share on the cluster nodes fails, change the export options and re-apply the proposal. Before doing so, however, you need to clean up the respective resources on the cluster nodes as described in https://www.suse.com/documentation/sle_ha/book_sleha/data/sec_ha_config_gui_manage.html.

5.4. 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 a Control Node. Keystone can be made highly available by deploying it on a cluster. You can configure the following parameters of this barclamp:

Algorithm for Token Generation

Set the algorithm used by Keystone to generate the tokens. It is strongly recommended to use PKI, since it will reduce network traffic.

Default Credentials: Default Tenant

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

Default Credentials: Regular User/Administrator User Name/Password

User name 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.

Figure 5.5. The Keystone Barclamp

The Keystone Barclamp

SSL Support: Protocol

When sticking with the default value HTTP, public communication will not be encrypted. Choose HTTPS to use SSL for encryption. See Section 2.4, “SSL Encryption” for background information and Section 4.3.6, “Enabling SSL (optional)” for installation instructions. The following additional configuration options will become available when choosing HTTPS:

Generate (self-signed) certificates

When set to true, self-signed certificates are automatically generated and copied to the correct locations. This setting is for testing purposes only and should never be used in production environments!

SSL Certificate File / SSL (Private) Key File

Location of the certificate key pair files.

SSL Certificate is insecure

Set this option to true when using self-signed certificates,in order to disable certificate checks. This setting is for testing purposes only and should never be used in production environments!

Require Client Certificate

Set this option to true when using your own certificate authority (CA) for signing. Having done so, you also need to specify a path to the CA Certificates File. If your certificates are signed by a trusted third party organization, Require Client Certificate should be set to false, since the official certificate authorities (CA) are already known by the system.

Figure 5.6. The SSL Dialog

The SSL Dialog

5.4.1. LDAP Authentication with Keystone

By default Keystone uses an SQL database back-end store for authentication. Alternatively, LDAP can be used. Using LDAP requires the Control Node on which Keystone is installed to be able to contact the LDAP server. See Appendix D, The Network Barclamp Template File for instructions on how to adjust the network setup.

To configure LDAP integration, you need to open the Keystone barclamp Attribute configuration in Raw mode. Search for the ldap section.

Figure 5.7. The Keystone Barclamp: Raw Mode

The Keystone Barclamp: Raw Mode

Adjust the settings according to your LDAP setup. The default configuration does not include all attributes that can be set—a complete list of options is available in the file /opt/dell/chef/data_bags/crowbar/bc-template-keystone.schema on the Administration Server (search for ldap). There are three types of attribute values: strings (for example, the value for url:"ldap://localhost"), bool (for example, the value for use_dumb_member: false) and integer for example, the value for page_size: 0). Attribute names and string values always need to be quoted with double quotes; bool and integer values must not be quoted.

[Important]Using LDAP over SSL (ldaps) is recommended

In a production environment, it is recommended to use LDAP over SSL (ldaps), otherwise passwords will be transferred as plain text.

5.4.2. HA Setup for Keystone

Making Keystone highly available requires no special configuration—it is sufficient to deploy it on a cluster.

5.5. Deploying RabbitMQ

The RabbitMQ messaging system enables services to communicate with the other nodes via Advanced Message Queue Protocol (AMQP). Deploying it is mandatory. RabbitMQ needs to be installed on a Control Node. RabbitMQ can be made highly available by deploying it on a cluster.It is recommended not to change the default values of the proposal's attributes.

Virtual Host

Name of the default virtual host to be created and used by the RabbitMQ server (default_vhost configuration option in rabbitmq.config).

Port

Port the RabbitMQ server listens on (tcp_listeners configuration option in rabbitmq.config).

User

RabbitMQ default user (default_user configuration option in rabbitmq.config).

Figure 5.8. The RabbitMQ Barclamp

The RabbitMQ Barclamp

5.5.1. HA Setup for RabbitMQ

To make RabbitMQ highly available, deploy it on a cluster rather than on a single Control Node. This also makes it necessary to provide shared storage for the cluster that hosts the RabbitMQ data. This can either be achieved by setting up a cluster with DRBD support (see Section 5.2, “Deploying Pacemaker (Optional, HA Setup Only)”) or by using traditional shared storage like an NFS share. It is recommended to use a dedicated cluster to deploy RabbitMq together with the database, since both services require shared storage.

Deploying RabbitMQ on a cluster makes an additional High Availability section available in the Attributes section of the proposal. Configure the Storage Mode in this section. There are two options:

DRBD

This option requires a two-node cluster that has been setup with DRBD. Also specify the Size to Allocate for DRBD Device (in Gigabytes). The suggested value of 50 GB should be sufficient.

Shared Storage

Use a shared block device or an NFS mount for shared storage. Concordantly with the mount command, you need to specify three attributes: Name of Block Device or NFS Mount Specification (the mount point), the Filesystem Type and the Mount Options.

[Important]NFS Export Options for Shared Storage

An NFS share that is to be used as a shared storage for a cluster needs to be exported on the NFS server with the following options:

rw,async,insecure,no_subtree_check,no_root_squash

In case mounting the NFS share on the cluster nodes fails, change the export options and re-apply the proposal. Before doing so, however, you need to clean up the respective resources on the cluster nodes as described in https://www.suse.com/documentation/sle_ha/book_sleha/data/sec_ha_config_gui_manage.html.

5.6. 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, visit http://ceph.com/.

[Important]Deploying Ceph within SUSE Cloud is Not Supported

Ceph is included in SUSE Cloud 3 as a technology preview. You may use Ceph in test environments but it is not recommended for production.

The supported way to use Ceph for SUSE Cloud is to make use of an external Ceph cluster. See Section 4.3.4, “Using an Externally Managed Ceph Cluster” for more information and installation instructions.

The Ceph barclamp only has one configuration option:

Disk Selection Method

Choose whether to only use the first available disk or all available disks. Available disks are all disks currently not used by the system. Note that one disk (usually /dev/sda) of every block storage node is already used for the operating system and is not available for Ceph.

The Ceph service consists of two different roles:

Ceph-mon

Cluster monitor daemon for the Ceph distributed file system. Ceph-mon needs to be installed on two, three, or four Storage Nodes. Deploying Ceph with only one or more than four monitor nodes will fail.

Nodes running Ceph-mon cannot be deleted or temporarily be disabled after SUSE Cloud is deployed.

Ceph-mon may be deployed on any Control Node and on dedicated Ceph-osd nodes.

Ceph-osd

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-osd Needs Dedicated Machines

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

Figure 5.9. The Ceph Barclamp

The Ceph Barclamp

5.6.1. HA Setup for Ceph

Ceph is HA-enabled by design, so there is no need for a special HA setup.

5.7. 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.

In order to be able to properly configure Swift it is important to understand how it places the data. Data is always stored redundantly within the hierarchy. The Swift hierarchy in SUSE Cloud is formed out of zones, nodes, hard disks, and logical partitions. Zones are physically separated clusters, for example different server rooms each with its own power supply and network segment. A failure of one zone must not affect another zone. The next level in the hierarchy are the individual Swift storage nodes (on which swift-storage has been deployed) followed by the hard disks. Logical partitions come last.

Swift automatically places three copies of each object on the highest hierarchy level possible. If three zones are available, the each copy of the object will be placed in a different zone. In a one zone setup with more than two nodes, the object copies will each be stored on a different node. In a one zone setup with two nodes, the copies will be distributed on different hard disks. If no other hierarchy element fits, logical partitions are used.

The following attributes can be set to configure Swift:

Allow Public Containers

Allows to enable public access to containers id set to true.

Zones

Number of zones (see above). If you do not have different independent installations of storage nodes, set the number of zones to 1.

Create 2^X Logical Partitions

Partition power. The number entered here is used to compute the number of logical partitions to be created in the cluster by using it as a power of 2 (2^X).

It is recommended to use a minimum of 100 partitions per disk. To measure the partition power for your setup, do the following: Multiply the number of disks from all Swift nodes with 100 and then round up to the nearest power of two. Keep in mind that the first disk of each node is not used by Swift, but rather for the operating system.

Example: 10 Swift nodes with 5 HDD each.  Four hard disks on each node are used for Swift, so there is a total of forty disks. Multiplied with 100 gives 4000. The nearest power of two, 4096, equals 2^12. So the partition power that needs to be entered is 12.

[Important]Value Cannot be Changed After the Proposal Has Been Deployed

Changing the number of logical partition after Swift has been deployed is not supported. Therefore the value for the partition power should be calculated from the maximum number of partitions this cloud installation is likely going to need at any point in time.

Minimum Hours before Partition is reassigned

This option sets the number of hours before a logical partition is considered for relocation. 24 is the recommended value.

Replicas

The number of copies generated for each object. Set this value to 3, the tested and recommended value.

Cluster Admin Password

The Swift administrator password.

Debug

Shows debugging output in the log files when set to true.

Figure 5.10. The Swift Barclamp

The Swift Barclamp

Apart from the general configuration described above, the Swift barclamp lets you also activate and configure Additional Middlewares. The features these middlewares provide can be used via the Swift command line client only. The Ratelimit and S3 middlewares certainly provide for the most interesting features, whereas it is recommended to only enable further middlewares for specific use-cases.

S3

Provides an S3 compatible API on top of Swift.

StaticWeb

Enables to serve container data as a static Web site with an index file and optional file listings. See http://docs.openstack.org/developer/swift/misc.html#module-swift.common.middleware.staticweb for details.

This middleware requires to set Allow Public Containers to true.

TempURL

Enables to create URLs to provide time limited access to objects. See http://docs.openstack.org/developer/swift/misc.html#module-swift.common.middleware.tempurl for details.

FormPOST

Enables to upload files to a container via Web form. See http://docs.openstack.org/developer/swift/misc.html#module-swift.common.middleware.formpost for details.

Domain Remap

Translates container and account parts of a domain to path parameters that the Swift proxy server understands. Can be used to create short URLs that are easy to remember, for example by rewriting home.tux.example.com/$ROOT/exampleuser;/home/myfile to home.tux.example.com/myfile. See http://docs.openstack.org/developer/swift/misc.html#module-swift.common.middleware.domain_remap for details.

Ratelimit

Ratelimit enables you to throttle resources such as requests per minute to provide denial of service protection. See http://docs.openstack.org/developer/swift/ratelimit.html for details.

The Swift service consists of four different roles. Deploying swift-dispersion is optional:

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.

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 a Control Node.

swift-proxy

The Swift proxy server takes care of routing requests to Swift. Installing a single instance of swift-proxy on a Control Node is recommended. The swift-proxy role can be made highly available by deploying it on a cluster.

swift-dispersion

Deploying swift-dispersion is optional. The Swift dispersion tools can be used to test the health of the cluster. It creates a heap of dummy objects (using 1% of the total space available). The state of these objects can be queried using the swift-dispersion-report query. swift-dispersion needs to be installed on a Control Node.

Figure 5.11. The Swift Barclamp: Node Deployment Example

The Swift Barclamp: Node Deployment Example

5.7.1. HA Setup for Swift

Swift replicates by design, so there is no need for a special HA setup. Make sure to fulfill the requirements listed in Section 2.7.4.1, “Swift—Avoiding Points of Failure ”.

5.8. 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 must be deployed onto a Control Node. Glance can be made highly available by deploying it on a cluster.

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/crowbar/crowbar/wiki/Glance--barclamp.

Notification Strategy

Glance notifications can be used for auditing and troubleshooting. By default they (Noop) are disabled. When choosing RabbitMQ, notifications are send to the RabbitMQ service.

Default Storage Backend

Choose whether to use Swift or Ceph (Rados) to store the images. If you have deployed neither of these services, the images can alternatively be stored in an image file on the Control Node (File). If you have deployed Swift, it is recommended to use it for Glance as well.

Image Storage: Image Store Directory

This option is only available when having chosen the file storage back-end. Specify the directory to host the image file. The directory specified here can also be an NFS share. See Section 4.3.3, “Mounting NFS Shares on a Node” for more information.

Image Storage: Swift Container

This option is only available when having chosen the Swift storage back-end. Sets the name of the container to use for the images in Swift.

Image Storage: RADOS User/RADOS Pool

This option is only available when having chosen the RADOS storage back-end. Specify a user name for the Cephx authentication and a Ceph pool name for the images here.

SSL Support: Protocol

Choose whether to encrypt public communication (HTTPS) or not (HTTP). If choosing HTTPS, refer to SSL Support: Protocol for configuration details.

API: Bind to All Addresses

Set this option 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.

Database: SQL Idle Timeout

Time after which idle database connections will be dropped.

Logging: Verbose

Shows debugging output in the log files when set to true.

Figure 5.12. The Glance Barclamp

The Glance Barclamp

5.8.1. HA Setup for Glance

Glance can be made highly available by deploying it on a cluster. It is also strongly recommended to do so for the image data, too. The recommended way to achieve this is to use Swift or an external Ceph cluster for the image repository. If using a directory on the node instead (file storage back-end), you should set up shared storage on the cluster for it.

5.9. Deploying Cinder

Cinder, the successor of Nova Volume, provides volume block storage. It adds persistent storage to an instance that will persist until deleted (contrary to ephemeral volumes that will only persist while the instance is running).

Cinder can provide volume storage by using a local file, one or more local disks, Ceph (RADOS) or network storage solutions from NetApp, EMC, or EqualLogic. Using a local file is not recommended for production systems for performance reasons.

The attributes that can be set to configure Cinder depend on the Type of Volume. The only general option is SSL Support: Protocol (see SSL Support: Protocol for configuration details).

Raw devices (local disks)

Disk-based Parameters

Disk Selection Method

Choose whether to only use the first available disk or all available disks. Available disks are all disks, currently not used by the system. Note that one disk (usually /dev/sda) of every block storage node is already used for the operating system and is not available for Cinder.

Name of Volume

Specify a name for the Cinder volume.

Local file

File-based Parameters

Volume File Name

Absolute path to the file to be used for block storage.

Maximum File Size

Maximum size of the volume file. Make sure not to overcommit the size, since it will result in data loss.

Name of Volume

Specify a name for the Cinder volume.

[Note]Using Local File for block storage

Using a file for block storage is not recommended for production systems, because of performance and data security reasons.

NetApp

NetApp Parameters

NetApp Driver Mode

SUSE Cloud can either use the 7-Mode direct driver or the direct driver for clustered data ONTAP via iSCSI or NFS. Choose the driver your NetApp is licensed for.

Server host name

The management IP address for the 7-Mode storage controller or the cluster management IP address for the clustered Data ONTAP.

Transport Type

Transport protocol for communicating with the storage controller or clustered Data ONTAP. Supported protocols are HTTP and HTTPS. Choose the protocol your NetApp is licensed for.

Server port

The 7-Mode controller/clustered Data ONTAP port to use for communication. Port 80 is usually used for HTTP, 443 for HTTPS.

User Name / Password

Login credentials for 7-Mode controller/clustered Data ONTAP management.

Storage Service to use while provisioning

Comma-separated list of NetApp volumes to be used for provisioning on 7-Mode controller. This option is used to restrict provisioning to the specified NetApp controller volumes. In case this option is not specified all NetApp controller volumes except the controller root volume are used for provisioning OpenStack volumes.

This setting only applies to the 7-Mode iSCSI direct diver.

The vFiler Unit Name if Using vFiler to Host OpenStack Volumes

The vFiler unit to be used for provisioning of OpenStack volumes. Use this only if using MultiStore®.

This setting only applies to the 7-Mode iSCSI direct diver.

EMC (EMC² Storage)

EMC Parameters

IP address of the ECOM server / Port of the ECOM server

IP address and Port of the ECOM server.

User Name / Password for accessing the ECOM server

Login credentials for the ECOM server.

Thin pool where user wants to create volume from

Only thin LUNs are supported by the plugin. Thin pools can be created using Unisphere for VMAX and VNX.

For more information on the EMC driver refer to the OpenStack documentation at http://docs.openstack.org/grizzly/openstack-block-storage/admin/content/emc-smis-iscsi-driver.html.

EqualLogic

EqualLogic support is only included as a technology preview and not supported.

Rados (Ceph)

RADOS Parameters

RADOS pool for Cinder volumes

Name of the pool used to store the Cinder volumes.

RADOS user for CephX authentication

Ceph user name.

Other driver (Ceph)

Lets you manually pick and configure a driver. Only use this option for testing purposes, it is not supported.

Figure 5.13. The Cinder Barclamp

The Cinder Barclamp

The Cinder service consists of two different roles:

cinder-controller

The Cinder controller provides the scheduler and the API. Installing cinder-controller on a Control Node is recommended.

cinder-volume

The virtual block storage service. It can be installed on a Control Node, but it's recommended to deploy it on one or more dedicated nodes supplied with sufficient networking capacity, since it will generate a lot of network traffic.

Figure 5.14. The Cinder Barclamp: Node Deployment Example

The Cinder Barclamp: Node Deployment Example

5.9.1. HA Setup for Cinder

While the cinder-controller role can be deployed on a cluster, deploying cinder-volume on a cluster is not supported. Therefore it is generally recommended to deploy cinder-volume on several nodes—this ensures the service continues to be available even when a node fails. In addition with Ceph or a network storage solution, such a setup minimizes the potential downtime.

In case using Ceph or a network storage is no option, you need to set up a shared storage directory (for example with NFS), mount it on all cinder volume nodes and use the Local File back-end with this shared directory. Using Raw Devices is not an option, since local disks cannot be shared.

5.10. Deploying Neutron

Neutron provides network connectivity between interface devices managed by other OpenStack services (most likely Nova). The service works by enabling users to create their own networks and then attach interfaces to them.

Neutron must be deployed on a Control Node. The following attributes can be set to configure Neutron:

DHCP Domain

Domain to use for building the host names.

Plugin

Choose the plugin to be used with Neutron. The linuxbridge plugin only supports VLANs in SUSE Cloud, whereas the openvswitch plugin supports GRE, VLAN and flat networks. The default plugin is openvswitch with gre.

[Important] Do not Use the Default with VMWare vSphere and Microsoft Hyper-V / Windows Server

If you plan to enable the VMWare vSphere support, you must not choose openvswitch, since it is not supported in this scenario.

The vmware option lets you use an existing VMWare NSX installation. Using this plugin is not a prerequisite for the VMWare vSphere hypervisor support. However, it is needed when wanting to have security groups supported on VMWare compute nodes.

SUSE Cloud also supports Cisco Nexus switches with the cisco plugin. See Appendix G, Using Cisco Nexus Switches with Neutron for setup instructions.

Mode

This option is only available when having chosen Plugin+openvswitch or Plugin+cisco. Set the network type to be set up by the plugin: gre (Generic Routing Encapsulation), flat or vlan.

[Note]openvswitch and VLANs

When using openvswitch with VLAN support, it is required to use different physical devices for the admin and the nova_fixed networks, so the network controller node needs at least two network cards.

VMWare NSX * / UUID of the NVP *

These options are only available when having chosen Plugin+vmware. The user you specify here (VMWare NSX Username and VMWare NSX Password) needs to be a user with administrator permissions on the NSX server.

Enter the IP address and the port number (IP-ADDRESS:PORT) of the controller API endpoint to VMWare NSX Controllers. If the port number is omitted, port 443 will be used. You may also enter multiple API endpoints (comma-separated), provided they all belong to the same controller cluster. When multiple API endpoints are specified, the plugin will load balance requests on the various API endpoints.

The UUIDs for the transport zone and the gateway service can be obtained from the NSX server. They will be used when networks are created.

Protocol

Choose whether to encrypt public communication (HTTPS) or not (HTTP). If choosing HTTPS, refer to SSL Support: Protocol for configuration details.

Figure 5.15. The Neutron Barclamp

The Neutron Barclamp

The Neutron service consists of two different roles:

neutron-server

neutron-server provides the scheduler and the API. It should be installed on a Control Node.

neutron-l3

This service runs the various agents that manage the network traffic of all the cloud instances. It acts as the DHCP and DNS server as well as a gateway for all cloud instances. It is recommend to deploy this role on a dedicated node supplied with sufficient network capacity.

Figure 5.16. The Neutron barclamp

The Neutron barclamp

5.10.1. HA Setup for Neutron

Neutron can be made highly available by deploying neutron-server and neutron-l3 on a cluster. While neutron-server may be deployed on a cluster shared with other services, it is strongly recommended to use a dedicated cluster solely for the neutron-l3 role.

If the network is configured to use openvswitch with VLAN support each node of the cluster neutron-l3 runs on needs at least four network cards (because two separate bonds, one for the nova_fixed and another one for the other networks, are needed).

5.11. Deploying Nova

Nova provides key services for managing the SUSE Cloud, sets up the Compute Nodes. SUSE Cloud currently supports KVM, Xen and Microsoft Hyper V and VMWare vSphere. The unsupported QEMU option is included to enable test setups with virtualized nodes. The following attributes can be configured for Nova:

Scheduler Options: Virtual RAM to Physical RAM allocation ratio

Set the overcommit ratio for RAM for instances on the Compute Nodes. A ratio of 1.0 means no overcommitment. Changing this value is not recommended.

Scheduler Options: Virtual CPU to Physical CPU allocation ratio

Set the overcommit ratio for CPUs for instances on the Compute Nodes. A ratio of 1.0 means no overcommitment.

Live Migration Support: Setup Shared Storage

Sets up a directory /var/lib/nova/instances on the Control Node on which nova-multi-controller and exports it via NFS to all compute nodes. This setup is required for live migration of Xen instances (but not for KVM) and can be used to provide central handling of instance data. Enabling this option is only recommended if Xen live migration is required—otherwise it should be disabled.

Live Migration Support: Enable Libvirt Migration

Allows to move KVM and Xen instances to a different Compute Node running the same hypervisor (cross hypervisor migrations are not supported). Useful when a Compute Node needs to be shut down or rebooted for maintenance or when the load of the Compute Node is very high. Instances can be moved while running (Live Migration).

[Warning]Libvirt Migration and Security

Enabling the libvirt migration option will open a TCP port on the Compute Nodes that allows to access to all instances from all machines in the admin network. Ensure that only authorized machines have access to the admin network when enabling this option.

KVM Options: Enable Kernel Samepage Merging

Kernel SamePage Merging (KSM) is a Linux Kernel feature which merges identical memory pages from multiple running processes into one memory region. Enabling it optimizes memory usage on the Compute Nodes when using the KVM hypervisor at the cost of slightly increasing CPU usage.

VMware vCenter Settings

Setting up VMware support is described in a separate section. See Appendix F, VMware vSphere Installation Instructions.

SSL Support: Protocol

Choose whether to encrypt public communication (HTTPS) or not (HTTP). If choosing HTTPS,refer to SSL Support: Protocol for configuration details.

SSL Support for noVNC: Protocol

After having started an instance you can display its VNC console in the OpenStack Dashboard (Horizon) via the browser using the noVNC implementation. By default this connection is not encrypted and can potentially be eavesdropped.

Enable encrypted communication for noVNC by choosing HTTPS. Refer to SSL Support: Protocol for configuration details.

Verbose

Shows debugging output in the log files when set to true.

Figure 5.17. The Nova Barclamp

The Nova Barclamp

The Nova service consists of six 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 a Control Node.

nova-multi-compute-hyperv / nova-multi-compute-kvm / nova-multi-compute-qemu / nova-multi-compute-vmware / nova-multi-compute-xen

Provides the hypervisors (Hyper-V, KVM, QEMU, VMware vSphere and Xen) and tools needed to manage the instances. Only one hypervisor can be deployed on a single compute node but you can use different hypervisors in your cloud by deploying different hypervisors to different Compute Nodes. A Nova-multi-compute role needs to be installed on every Compute Node. However, not all hypervisors need to be deployed.

Each image that will be made available in SUSE Cloud to start an instance is bound to a hypervisor. Each hypervisor can be deployed on multiple Compute Nodes (except for the VMWare vSphere role, see below). In a multi-hypervisor deployment you should make sure to deploy the nova-multi-compute roles in a way, that enough compute power is available for each hypervisor.

[Note]Re-assigning Hypervisors

Existing nova-multi-compute nodes can be changed in a productive SUSE Cloud without service interruption. You need to evacuate the node, re-assign a new nova-multi-compute role via the Nova barclamp and Apply the change. nova-multi-compute-vmware can only be deployed on a single node.

[Important]Deploying Hyper-V

nova-multi-compute-hyperv can only be deployed to Compute Nodes running either Microsoft Hyper-V Server or Windows Server 2012. Being able to set up such Compute Nodes requires to set up a netboot environment for Windows. Refer to Appendix E, Setting up a Netboot Environment for Microsoft* Windows for details.

The default password for Hyper-V Compute Nodes will be crowbar.

[Important]Deploying VMware vSphere (vmware)

VMware vSphere is not supported natively by SUSE Cloud—it rather delegates requests to an existing vCenter. It requires preparations at the vCenter and post install adjustments of the Compute Node. See Appendix F, VMware vSphere Installation Instructions for instructions. nova-multi-compute-vmware can only be deployed on a single Compute Node.

Figure 5.18.  The Nova Barclamp: Node Deployment Example with Three KVM Nodes

The Nova Barclamp: Node Deployment Example with Three KVM Nodes

5.11.1. HA Setup for Nova

Making Nova highly available requires no special configuration—it is sufficient to deploy it on a cluster.

As of SUSE Cloud 3 making Compute Nodes highly available is not supported. See Section 2.7.3, “High Availability of the Compute Node(s)” for additional information.

5.12. Deploying Horizon (OpenStack Dashboard)

The last service that needs to be deployed is Horizon, the OpenStack Dashboard. It provides a Web interface for users to start and stop instances and for administrators to manage users, groups, roles, etc. Horizon should be installed on a Control Node. To make Horizon highly available, deploy it on a cluster.

The following attributes can be configured:

Session Timeout

Timeout (in seconds) after which a user is been logged out automatically. The default value is set to 30 minutes (1800 seconds).

User Password Validation: Regular expression used for password validation

Specify a regular expression with which to check the password. The default expression (.{8,}) tests for a minimum length of 8 characters. The string you enter is interpreted as a Python regular expression (see http://docs.python.org/2.7/library/re.html#module-re for a reference).

User Password Validation: Text to display if the password does not pass validation

Error message that will be displayed in case the password validation fails.

SSL Support: Protocol

Choose whether to encrypt public communication (HTTPS) or not (HTTP). If choosing HTTPS, refer to SSL Support: Protocol for configuration details.

Figure 5.19. The Horizon Barclamp

The Horizon Barclamp

5.12.1. HA Setup for Horizon

Making Horizon highly available requires no special configuration—it is sufficient to deploy it on a cluster.

5.13. Deploying Ceilometer

Ceilometer collects CPU and networking data from SUSE Cloud. This data can be used by a billing system to enable customer billing. Deploying Ceilometer is optional.

For more information about Ceilometer refer to the OpenStack documentation at http://docs.openstack.org/developer/ceilometer/.

[Important]Ceilometer Restrictions

As of SUSE Cloud 3 data measuring is only supported for KVM and Xen instances. Other hypervisors and SUSE Cloud features such as object or block storage will not be measured.

The following attributes can be configured for Ceilometer:

Use MongoDB instead of standard database

Ceilometer collects a huge amount of data, which is written to a database. In a production system it is recommended to use a separate database for Ceilometer rather than the standard database that is also used by the other SUSE Cloud services. MongoDB is optimized to write a lot of data. As of SUSE Cloud 3 MongoDB is only included as a technology preview and not supported.

The Ceilometer service consists of four different roles:

ceilometer-server

The Ceilometer API server role. This role needs to be deployed on a Control Node. Ceilometer collects approximately 200 bytes of data per hour and instance. Unless you have a very huge number of instances, there is no need to install it on a dedicated node.

ceilometer-cagent

The central agent listens to the message bus to collect data. It needs to be deployed on a Control Node. It can be deployed on the same node as ceilometer-server.

ceilometer-agent

The compute agents collect data from the compute nodes. They need to be deployed on all KVM and Xen compute nodes in your cloud (other hypervisors are currently not supported).

ceilometer-swift-proxy-middleware

An agent collecting data from the Swift nodes. This role needs to be deployed on the same node as swift-proxy.

Figure 5.20. The Ceilometer Barclamp

The Ceilometer Barclamp

5.13.1. HA Setup for Ceilometer

Making Ceilometer highly available requires no special configuration—it is sufficient to deploy the roles ceilometer-server and ceilometer-cagenton a cluster.

5.14. Deploying Heat

Heat is a template-based orchestration engine that enables you to, for example, start workloads requiring multiple servers or to automatically restart instances if needed. It also brings auto-scaling to SUSE Cloud by automatically starting additional instances if certain criteria are met. For more information about Heat refer to the OpenStack documentation at http://docs.openstack.org/developer/heat/.

Heat should be deployed on a Control Node. To make Heat highly available, deploy it on a cluster.

The following attributes can be configured for Heat:

Setup Verbose Logging

Shows debugging output in the log files when set to true.

Figure 5.21. The Heat Barclamp

The Heat Barclamp

5.14.1. HA Setup for Heat

Making Heat highly available requires no special configuration—it is sufficient to deploy it on a cluster.

5.15. How to Proceed

With a successful deployment of the OpenStack 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 Clients, ↑Admin User Guide) 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 Admin User Guide (↑Admin User Guide) for details. The default credentials for the OpenStack Dashboard are user name admin and password crowbar.

Chapter 6. SUSE Cloud Maintenance

6.1. Keeping the Nodes Up-to-date

Keeping the nodes in SUSE Cloud up-to-date requires an appropriate setup of the update repositories (see Section 3.2.2.2, “Update Repositories” and the deployment of either the Updater barclamp (see Section 4.3.1, “Deploying Node Updates with the Updater barclamp”) or the SUSE Manager barclamp (see Section 4.3.2, “ Configuring Node Updates with the SUSE Manager Client barclamp ”.

If one of those barclamps is deployed, patches are installed on the nodes. Installing patches that do not require a reboot of a node does not come with any service interruption. In case a patch (for example a kernel update) requires a reboot after the installation, services running on the machine that is rebooted, will not be available within SUSE Cloud. Therefore it is strongly recommended to install those patches during a maintenance window.

[Note]No Maintenance Mode

As of SUSE Cloud 3 it is not possible to put SUSE Cloud into Maintenance Mode.

Consequences when Rebooting Nodes

Administration Server

While the Administration Server is offline, it is not possible to deploy new nodes. However, rebooting the Administration Server has no effect on starting instances or on instances already running.

Control Nodes

The consequences a reboot of a Control Node has, depends on the services running on that node:

Database, Keystone, RabbitMQ, Glance, Nova:  No new instances can be started.

Swift:  No object storage data is available. If Glance uses Swift, it will not be possible to start new instances.

Cinder, Ceph:  No block storage data is available.

Neutron:  No new instances can be started. On running instances the network will be unavailable.

Horizon.  Horizon will be unavailable. Starting and managing instances can be done with the command line tools.

Compute Nodes

Whenever a Compute Node is rebooted, all instances running on that particular node will be shut down and must be manually restarted. Therefore it is recommended to evacuate the node by migrating instances to another node, before rebooting it.

6.2. Upgrading from SUSE Cloud 2.0 to SUSE Cloud 3

Upgrading from SUSE Cloud 2.0 to SUSE Cloud 3 is supported, with the following manual steps. However, note that it will turn off the OpenStack cloud during the upgrade and it is not possible to downgrade back to SUSE Cloud 2.0 in case of a regression or problem. It is highly recommended to back up data before the upgrade. In case you also plan to make your setup highly available, also refer to Section 6.3, “Upgrading to an HA Setup”.

Prerequisites

[Important] Instance Running on HyperV Nodes will not survive an Upgrade

As of SUSE Cloud 3, HyperV Nodes need to be re-installed after the upgrade procedure. This re-installation will overwrite the instance's data and therefore they will be lost. KVM, VMWare and Xen instances are not affected.

Procedure 6.1.  Upgrading SUSE Cloud 2.0 to 3

  1. Make sure to subscribe to the SUSE Cloud 3 Pool and Update channels on the source that provides these channels for your SUSE Cloud installation (for example an SMT or SUSE Manager server).

    In case the channels are provided by an SMT server (either remote or on the Administration Server itself), refer to Section 3.2.1, “Setting up the SMT Repositories” for instructions on subscribing to the SUSE Cloud 3 channels.

  2. Update the SUSE Cloud product repository on the Administration Server. To do so, insert the SUSE Cloud 3 DVD and run the following commands:

    mount /dev/dvd /mnt
    rsync -avP --delete /mnt/ /srv/tftpboot/repos/Cloud/
    umount /mnt
  3. Update the SUSE Cloud repository links on the Administration Server.

    If you are using external URLs (for example from an external SMT or SUSE Manager server) for the SUSE Cloud 2.0 Pool and Update repositories, you need to update the file /etc/crowbar/provisioner.json. Open it in an editor and Search for the suse+autoyast+repos entry. Replace the URLs pointing to the SUSE Cloud 2.0 Pool and Update repositories with the ones pointing to version 3. Also change the name of these repositories to SUSE-Cloud-3-Pool and SUSE-Cloud-3-Updates, respectively.

    In case you are using an SMT server installed on the Administration Server, run the following commands to make the repositories available for SUSE Cloud:

    for REPO in SUSE-Cloud-3.0-{Pool,Updates}; do
    ln -s /srv/www/htdocs/repo/\$RCE/$REPO/sle-11-x86_64 /srv/tftpboot/repos/${REPO/.0/}
    done
  4. Now you need to replace the SUSE Cloud 2.0 Pool and Update repositories used by the Administration Server with the ones for version 3. Modify the repository configuration by running YaST+Software+Software Repositories on the Administration Server.

  5. Refresh the repositories and install the suse-cloud-upgrade package by running the following commands on the Administration Server:

    zypper refresh
    zypper install suse-cloud-upgrade
  6. Run suse-cloud-upgrade upgrade for the first time. It will completely shut down the OpenStack and the Crowbar Web interface. In case the command fails, contact the SUSE support (see Section 7.2, “Support” for more information). At this point of the upgrade workflow it is still possible to go back to version 2.0.

  7. Update all packages on the Administration Server by running zypper up. During the update process you will need to accept the SUSE Cloud 3 EULA.

  8. Run suse-cloud-upgrade upgrade for the second time. Now the Crowbar Web interface is available again. In case the command fails, contact the SUSE support (see Section 7.2, “Support” for more information). From this point in the installation workflow on it is no longer possible to go back to version 2.0.

  9. Go to the Crowbar Web interface and open Barclamps+Crowbar. Edit the Provisioner proposal and Apply it.

  10. Update packages on all nodes except the Administration Server as described in Section 4.3.1, “Deploying Node Updates with the Updater barclamp”. You should use the following configuration:

    Use zypper: update
    Enable GPG checks: true
    Automatically agree with licenses: true
  11. Reboot all nodes except the Administration Server. This can either be done manually or by running suse-cloud-upgrade reboot-nodes. Wait until all nodes are up and running again before proceeding.

  12. Go to the Crowbar Web interface and open Barclamps+Openstack. Open the barclamp one-by-one in the given order by clicking Edit and re-apply each proposal with Apply.

  13. In case you have deployed Microsoft HyperV nodes, you need to re-install them. Go to the Crowbar Web interface and open the Dashboard. For each HyperV node, click on its name and then on Reinstall.

After the upgrade procedure has been finished, SUSE Cloud should be up and running again. You may restart all suspended instances now.

6.3. Upgrading to an HA Setup

When making an existing SUSE Cloud deployment highly available by setting up HA clusters and moving roles to these clusters, there are a few issues to pay attention to. To make existing services highly available, proceed as follows. Note that moving to an HA setup cannot be done without SUSE Cloud service interruption, because it requires OpenStack services to be restarted.

[Important]Teaming Network Mode is Required for HA

Teaming network mode is required for an HA setup of SUSE Cloud. If you are planning to move your cloud to an HA setup at a later point in time, make sure to deploy SUSE Cloud with teaming network mode from the beginning.

Otherwise a migration to an HA setup is not supported.

  1. Make sure to have read the sections Section 1.5, “HA Setup” and Section 2.7, “High Availability” of this manual and taken any appropriate action.

  2. Make the HA repositories available on the Administration Server as described in Section 3.2, “Post-Installation Configuration”. Run the command chef-client afterwards.

  3. Set up your cluster(s) as described in Section 5.2, “Deploying Pacemaker (Optional, HA Setup Only)”.

  4. To move a particular role from a regular control node to a cluster, you need to stop the associated service(s) before re-deploying the role on a cluster:

    1. Log in to each node on which the role is deployed and stop its associated service(s) (a role can have multiple services). Do so by running the service's start/stop script with the stop argument, for example:

      rcopenstack-keystone stop

      See Appendix C, Roles, Services and Start/Stop Scripts in SUSE Cloud for a list of roles, services and start/stop scripts.

    2. The following roles need additional treatment:

      database-server (Database barclamp)
      1. Stop the database on the node the Database barclamp is deployed with the command:

        rcpostgresql stop
      2. Copy /var/lib/pgsql to a temporary location on the node, e.g.:

        cp -ax /var/lib/pgsql /tmp
      3. Redeploy the Database barclamp to the cluster. The original node may also be part of this cluster.

      4. Log in to a cluster node and run the following command to determine which cluster node runs the postgresql service:

        crm_mon -1
      5. Log in to the cluster node running postgresql.

      6. Stop the postgresql service:

        crm resource stop postgresql
      7. Copy the data backed up earlier to the cluster node:

        rsync -av --delete
        	   NODE_WITH_BACKUP:/tmp/pgsql/ /var/lib/pgsql/
      8. Restart the postgresql service:

        crm resource start postgresql

      Copy the content of /var/lib/pgsql/data/ from the original database node to the cluster node with DRBD or shared storage.

      keystone-server (Keystone barclamp)

      If using Keystone with PKI tokens, the PKI keys on all nodes need to be re-generated. This can be achieved by removing the contents of /var/cache/*/keystone-signing/ on the nodes. Use a command similar to the following on the Administration Server as root:

      for NODE in NODE1
      	 NODE2 NODE3; do
        ssh $NODE rm /var/cache/*/keystone-signing/*
      done
  5. Go to the barclamp featuring the role you want to move to the cluster. Remove the node the role is currently running on from the left side of the Deployment section and replace it with a cluster from the Available Clusters section. Then apply the proposal and verify that application succeeded via the Crowbar Web UI. You can also check the cluster status via Hawk, the Pacemaker GUI (hb_gui), or the crm / crm_mon CLI tools.

  6. Repeat these steps for all roles you want to move to cluster. See Section 2.7.2.1, “Control Node(s)—Avoiding Points of Failure” for a list of services with HA support.

[Important]SSL Certificates

Moving to an HA setup also requires to create SSL certificates for nodes in the cluster that run services using SSL. Certificates need to be issued for the generated names (see Proposal Name) as well as for all public names you have configured in the cluster.

[Important]Service Management on the Cluster

After a role has been deployed on a cluster, its services are managed by the HA software. You must never ever manually start or stop an HA-managed service or configure it to start on boot (for example by running insserv for the service). Services may only be started or stopped by using the cluster management tools Hawk, the Pacemaker GUI or the crm shell. See https://www.suse.com/documentation/sle_ha/book_sleha/data/sec_ha_configuration_basics_resources.html for more information.

6.4. Backing Up and Restoring the Administration Server

As an example of how to back up and restore the data on the Administration Server, a crowbar-backup script is shipped with the maintenance update for SUSE Cloud 3.

[Warning]No Support for crowbar-backup

The script serves as a functioning example of how to back up and restore an Administration Server. Using it in a production environment is not supported.

However, you can adjust the script to your specific setup or use it as a template to create your own backup and restore routine.

Find the latest updates for the script at https://github.com/SUSE-Cloud/cloud-tools.

The script is part of the crowbar package and is installed to /usr/sbin/crowbar-backup on the Administration Server. It is tailored to back up and restore the Administration Server of the respective SUSE Cloud version the script is shipped with. When calling the crowbar-backup script with the backup option, it will create a TAR archive with all configuration data that is needed to restore the Administration Server. For a list of available options and a short help text, run

./usr/sbin/crowbar-backup help

Example Commands for Using the Script

Creating a Backup
/usr/sbin/crowbar-backup backup [FILENAME]

Creates a TAR archive with all configuration data that is needed to restore the Administration Server. If you do not specify a FILENAME, the data is written to /tmp/backup-crowbar.tar.gz by default. Any services that need to be stopped for creating the backup will be stopped automatically and will be restarted afterwards by the script as needed.

Restoring a Backup From a TAR Archive
/usr/sbin/crowbar-backup restore [FILENAME]

Reads the configuration data for an Administration Server from the specified TAR archive and restores the data on the current Administration Server.

Cleaning Up the Administration Server
/usr/sbin/crowbar-backup cleanup

Stops services and deletes the configuration files on the Administration Server that are related to Crowbar.

Use only after you have created a backup of the Administration Server and only if you want to test the restoration process.

Wiping the Administration Server
/usr/sbin/crowbar-backup purge

Uninstalls all packages on the Administration Server that are related to Crowbar. Additionally, deletes all configuration files that are related to Crowbar.

Use only after you have created a backup of the Administration Server and only if you want to test the restoration process.

Chapter 7. Troubleshooting and Support

Find solutions for the most common pitfalls and technical details on how to create a support request for SUSE Cloud here.

7.1. FAQ

If your problem is not mentioned here, checking the log files on either the Administration Server or the OpenStack nodes may help. A list of log files is available at Appendix B, Log Files.

7.1.1. Admin Node Deployment

Question:

What to do when install-suse-cloud fails?

A:

Check the script's log file at /var/log/crowbar/install.log for error messages.

Question:

What to do if install-suse-cloud fails while deploying the IPMI/BMC network?

A:

As of SUSE Cloud 3, it is assumed that each machine can be accessed directly via IPMI/BMC. However, this is not the case on certain blade hardware, where several nodes are accessed via a common adapter. Such a hardware setup causes an error on deploying the IPMI/BMC network. You need to disable the IPMI deployment running the following command:

/opt/dell/bin/json-edit -r -a "attributes.ipmi.bmc_enable" \
-v "false" /opt/dell/chef/data_bags/crowbar/bc-template-ipmi.json

Re-run install-suse-cloud after having disabled the IPMI deployment.

Question:

Why am I not able to reach the Administration Server from outside the admin network via the bastion network?

A:

If route -n shows no gateway for the bastion network, make sure the value for the bastion network's "router_pref": entry in /etc/crowbar/network.json is set to a lower value than the "router_pref": entry for the admin network.

If the router preference is set correctly, route -n shows a gateway for the bastion network. In case the Administration Server is still not accessible via its admin network address (for example, 192.168.124.10), you need to disable route verification (rp_filter). Do so by running the following command on the Administration Server:

echo 0 > /proc/sys/net/ipv4/conf/all/rp_filter

If this setting solves the problem, make it permanent by editing /etc/sysctl.conf and setting the value for net.ipv4.conf.all.rp_filter to 0.

Question:

Can I change the host name of the Administration Server?

A:

No, after you have run install-suse-cloud you cannot change the host name anymore. Services like Crowbar, Chef, and the RabbitMQ will fail when having changed the host name.

Question:

What to do when browsing the Chef Web UI gives a Tampered with cookie error?

A:

You probably have an old cookie in your browser from a previous Chef installation on the same IP. Remove the cookie named _chef_server_session_id and try again.

Question:

How to make custom software repositories from an external server available for the nodes?

A:

Custom repositories need to be added manually to /etc/crowbar/provisioner.json (it is currently not possible to use the YaST Crowbar module for this purpose). To add a repository called my_custom_repo_1.0, from an SMT server, run the following command:

/opt/dell/bin/json-edit \
-a "attributes.provisioner.suse.autoyast.repos.my_custom_repo_1\.0.url \
-v "http://smt.example.com/repo/\$RCE/my_repos/x86_64/" \
/etc/crowbar/provisioner.json

Note that you need to escape . (period) in repository names like in my_custom_repo_1\.0!

Access errors to a repository are silently ignored by default. To ensure that you get notified of these errors, set the Ask On Error flag for the repository by running the following command:

/opt/dell/bin/json-edit -r \
-a "attributes.provisioner.suse.autoyast.repos.my_custom_repo_1\.0.ask_on_error" \
-v "true" /etc/crowbar/provisioner.json

7.1.2. OpenStack Node Deployment

Question:

How can I log in to a node as root?

A:

By default you cannot directly log in to a node as root, because the nodes were set up without a root password. You can only log in via SSH from the Administration Server. You should be able to log in to a node with ssh root@NAME where NAME is the name (alias) of the node.

If name resolution does not work, go to the Crowbar Web interface and open the Node Dashboard. Click on the name of the node and look for its admin (eth0) IP Address. Log in to that IP address via SSH as user root.

Question:

What to do if a node refuses to boot or boots into a previous installation?

A:

Make sure to change the boot order in the BIOS of the node, so that the first boot option is to boot from the network/boot using PXE.

Question:

What to do if a node hangs during hardware discovery after the very first PXE boot into the SLEShammer image?

A:

The root login is enabled at a very early state in discovery mode, so chances are high that you can log in for debugging purposes as described in Question:. If logging in as root does not work, you need to set the root password manually:

  1. Create a directory on the Administration Server named /updates/discovering-pre

    mkdir /updates/discovering-pre
  2. Create a hook script setpw.hook in the directory created in the previous step:

    cat > /updates/discovering-pre/setpw.hook <<EOF
    #!/bin/sh
    echo "linux" | passwd --stdin root
    EOF
  3. Make the script executable:

    chmod a+x  /updates/discovering-pre/setpw.hook

Question:

What to do when a deployed node fails to PXE boot with the following error message: Could not find kernel image: ../suse-11.3/install/boot/x86_64/loader/linux?

A:

The installation repository at /srv/tftpboot/suse-11.3/install on the Administration Server has not been set up correctly to contain the SUSE Linux Enterprise Server 11 SP3 installation media. Please review the instructions at Section 3.2.2, “Setting Up Repositories for Node Deployment”.

Question:

Why does my deployed node hang at Unpacking initramfs during PXE boot?

A:

The node probably does not have enough RAM. You need at least 2 GB RAM.

Question:

What to do if a node hangs at Executing AutoYast script: /var/adm/autoinstall/init.d/crowbar_join after the installation has been finished?

A:

Be patient—the AutoYaST script may take a while to finish. If it really hangs, log in to the node as root (see Question: for details). Check the log files at /var/log/crowbar/crowbar_join/* for errors.

If the node is in a state where login in from the Administration Server is not possible, you need to create a root password for it as described in Direct root Login. Now re-install the node by going to the node on the Crowbar Web interface and clicking Reinstall. After having been re-installed, the node will hang again, but now you will be able to log in and check the log files to find the cause.

Question:

Where to find more information when applying a barclamp proposal fails?

A:

Check the Chef client logs on the Administration Server located at /var/log/crowbar/chef-client/d*.log. Further information is available from the Chef client logs located on the node(s) affected by the proposal (/var/log/chef/client.log), and also from the logs of the service that failed to be deployed. Additional information may be gained from the Crowbar Web UI logs on the Administration Server. For a list of log file locations refer to Appendix B, Log Files.

Question:

I have installed a new hard disk on a node that was already deployed. Why is it ignored by Crowbar?

A:

When adding a new hard disk to a node that has already been deployed, it can take up to 15 minutes before the new disk is detected.

7.2. Support

Before contacting support to help you with a problem on SUSE Cloud, it is strongly recommended that you gather as much information about your system and the problem as possible. For this purpose, SUSE Cloud ships with a tool called supportconfig. It gathers system information such as the current kernel version being used, the hardware, RPM database, partitions, and other items. supportconfig also collects the most important log files, making it easier for the supporters to identify and solve your problem.

It is recommended to always run supportconfig on the Administration Server as well as on the Control Node. If a Compute Node or a Storage Node is part of the problem, run supportconfig on the affected node as well. For details on how to run supportconfig, please refer to http://www.suse.com/documentation/sles11/book_sle_admin/data/cha_adm_support.html.

7.2.1.  Applying PTFs (Program Temporary Fixes) Provided by the SUSE L3 Support

Under certain circumstances, the SUSE support may provide temporary fixes, the so-called PTFs, to customers with an L3 support contract. These PTFs are provided as RPM packages. To make them available on all nodes in SUSE Cloud, proceed as follows.

  1. Download the packages to a temporary location on the Administration Server.

  2. Move noarch packages (*.noarch.rpm) from the download location to /srv/tftpboot/repos/Cloud-PTF/rpm/noarch on the Administration Server.

  3. Move x86_64 packages (*.x86_64.rpm) from the download location to /srv/tftpboot/repos/Cloud-PTF/rpm/x86_64 on the Administration Server.

  4. Create or update the repository metadata:

    createrepo /srv/tftpboot/repos/Cloud-PTF
  5. Sign the repository metadata:

    gpg -a --detach-sign /srv/tftpboot/repos/Cloud-PTF/repodata/repomd.xml

    In case you are asked to overwrite the file, answer Yes.

  6. The repository is now set up and is available to all nodes in SUSE Cloud except for the Administration Server. In case the PTF also contains packages to be installed on the Administration Server, you need to make the repository available on the Administration Server as well:

    zypper ar -f /srv/tftpboot/repos/Cloud-PTF Cloud-PTF
  7. To deploy the updates, proceed as described in Section 4.3.1, “Deploying Node Updates with the Updater barclamp”. Alternatively, run zypper up manually on each node.

Appendix A. Documentation Updates

This chapter lists content changes for this document since the release of SUSE® Cloud 2.0.

This manual was updated on the following dates:

A.1. April 21, 2014 (Maintenance Release SUSE Cloud 3)

Included information on how to make SUSE Cloud highly available.

The following new sections have been added:

Various smaller additions and changes throughout the document. New terms have been added to Terminology.

A.2. February 17, 2014 (Initial Release SUSE Cloud 3)

Admin Node Installation
Node Installation
OpenStack Service Deployment
Maintenance
General
Bugfixes

A.3. September 25, 2013 (Maintenance Release SUSE Cloud 2.0)

OpenStack Service Deployment
Bugfixes

A.4. September 11, 2013 (Initial Release SUSE Cloud 2.0)

Admin Node Installation
Networking
Node Installation
OpenStack Service Deployment
Bugfixes

Appendix B. Log Files

Find a list of log files below, sorted according to the nodes where they can be found.

B.1. On the Administration Server

  • Crowbar Web Interface: /var/log/crowbar/production.log

  • Chef server: /var/log/chef/server.log

  • Chef expander: /var/log/chef/expander.log

  • Chef client (for the Administration Server only): /var/log/chef/client.log

  • Apache SOLR (Chef's search server): /var/log/chef/solr.log

  • HTTP (AutoYaST) installation server for provisioner barclamp: /var/log/apache2/provisioner-{access,error}_log

  • Default SUSE log files: /var/log/messages, /var/log/zypper.log etc.

  • Syslogs for all nodes: /var/log/nodes/*.log (these are collected via remote syslogging)

  • Log file from mirroring SMT repositories (optional): /var/log/smt/smt-mirror.log

  • Other client node log files saved on the Administration Server:

    • /var/log/crowbar/sledgehammer/d*.log: Initial Chef client run on nodes booted using PXE prior to discovery by Crowbar.

    • /var/log/crowbar/chef-client/d*.log: Output from Chef client when proposals are applied to nodes. This is the first place to look if a barclamp proposal fails to apply.

B.2. On All Other Crowbar Nodes

Logs for when the node registers with the Administration Server:

  • /var/log/crowbar/crowbar_join/errlog

  • /var/log/crowbar/crowbar_join/$TOPIC.{log,err}: STDOUT/STDERR from running commands associated with $TOPIC when the node joins the Crowbar cluster. $TOPIC can be:

    • zypper: package management activity

    • ifup: network configuration activity

    • Chef: Chef client activity

    • time: starting of ntp client

  • Chef client log: /var/log/chef/client.log

  • Default SUSE log files: /var/log/messages, /var/log/zypper.log etc.

B.3. On the Control Node

  • /var/log/keystone/keystone.log: OpenStack authentication, etc.

  • /var/log/rabbitmq/*: logs for RabbitMQ, used by OpenStack for handling message queues

  • /var/log/nova/: various logs relating to Nova services:

    • api.log

    • consoleauth.log

    • network.log

    • nova-manage.log

    • scheduler.log

    • volume.log

  • /var/log/apache2/openstack-dashboard-*: Logs for the OpenStack Dashboard

B.4. On Compute Nodes

/var/log/nova/: various logs relating to Nova services:

  • compute.log

  • nova-manage.log

B.5. On Nodes with Ceph barclamp

/var/log/ceph/*.log

Appendix C. Roles, Services and Start/Stop Scripts in SUSE Cloud

The following table lists all roles (as defined in the barclamps), theit associated services and the corresponding start/stop scripts. As of SUSE Cloud 3 this list is work in progress.

Table C.1. 

Role

Service

Start/Stop Script(s)

ceilometer-agent

ceilometer-cagent

ceilometer-server

ceilometer-swift-proxy-middleware

cinder-controller

openstack-cinder-api

rcopenstack-cinder-api

openstack-cinder-scheduler

rcopenstack-cinder-scheduler

cinder-volume

openstack-cinder-volume

rcopenstack-cinder-volume

database-server

postgresql

rcpostgresql

heat-server

keystone-server

keystone

rcopenstack-keystone

neutron-l3

neutron-server

openstack-neutron

rcopenstack-neutron

nova_dashboard-server

apache2

rcapache2

nova-multi-controller

nova-multi-compute-*

rabbitmq-server

rabbitmq

rcrabbitmq-server

swift-dispersion

swift-proxy

swift-proxy

rcopenstack-swift-proxy

memcached

rcmemcached

swift-ring-compute

swift-storage


Appendix D. The Network Barclamp Template File

The Crowbar network barclamp provides two functions for the system. The first is a common role to instantiate network interfaces on the Crowbar managed systems. The other function is address pool management. While the addresses can be managed with the YaST Crowbar module, complex network setups require to manually edit the network barclamp template file /etc/crowbar/network.json. This section explains the file in detail. Settings in this file are applied to all nodes in SUSE Cloud.

[Warning]No Network Changes After Having Run the Cloud Installation Script

After you have run the SUSE Cloud installation script, you cannot change the network setup anymore. If doing so, you would need to completely set up the Administration Server again.

The only exception from this rule is the interface map. This section can be changed at a later stage as well. See Section D.3, “Interface Map” for details.

D.1. Editing network.json

The network.json is located in /etc/crowbar/. To edit it, open it in an editor of your choice. The template has the following general structure:

{
   "attributes" : {
      "mode" : "value",
      "start_up_delay" : value,
      "teaming" : { "mode": value },1
      "network" : {
         "interface_map"2 : [
            ...
         ],
         "conduit_map"3 : [
            ...
         ],
         "networks"4 : {
            ...
         },
      }
   }
}

1

General attributes. Refer to Section D.2, “Global Attributes” for details.

2

Interface map section. Defines the order in which the physical network interfaces are to be used. Refer to Section D.3, “Interface Map” for details.

3

Network conduit section defining the network modes and the network interface usage. Refer to Section D.4, “Network Conduits” for details.

4

Network definition section. Refer to Section D.5, “Network Definitions” for details.

[Note]Order of Elements

The order in which the entries in the network.json file appear may differ from the one listed above. Use your editor's search function to find certain entries.

D.2. Global Attributes

The most important options to define in the global attributes section are the default values for the network and bonding modes. The following global attributes exist:

"start_up_delay" : 30,1
         "mode": "single",2
         "teaming" : { "mode" : 5 },3

1

Time (in seconds) the Chef-client waits for the network interfaces to become online before running into a time-out.

2

Network mode. Defines the configuration name (or name space) to be used from the conduit_map (see Section D.4, “Network Conduits”). This allows to define multiple configurations (single, dual, and team are preconfigured) and switch them by changing this parameter.

3

Default bonding mode. See https://www.kernel.org/doc/Documentation/networking/bonding.txt for a list of available modes.

[Warning]Bonding Mode 6 (balance-alb) not supported

Adaptive load balancing (balance-alb or 6) is not supported because of problems with bridges and openvswitch.

D.3. Interface Map

By default physical network interfaces are used in the order they appear under /sys/class/net/. In case you want to apply a different order, you need to create an interface map where you can specify a custom order of the bus IDs. Interface maps are created for specific hardware configurations and are applied to all machines matching this configuration.

            {
               "pattern" : "PowerEdge R610"1,
               "serial_number" : "0x02159F8E"2,
               "bus_order" : [3
                  "0000:00/0000:00:01",
                  "0000:00/0000:00:03"
               ]
            }

1

Hardware specific identifier. This identifier can be obtained by running the command dmidecode -s system-product-name on the machine you want to identify. You can log in to a node during the hardware discovery phase (when booting the SLEShammer image) via the Administration Server.

2

Additional hardware specific identifier. This identifier can be used in case two machines have the same value for pattern, but different interface maps are needed. Specifying this parameter is optional (it is not included in the default network.json file). The serial number of a machine can be obtained by running the command dmidecode -s system-serial-number on the machine you want to identify.

3

Bus IDs of the interfaces. The order in which they are listed here defines the order in which Chef addresses the interfaces. The IDs can be obtained by listing the contents of /sys/class/net/.

[Important]PXE Boot Interface must be Listed First

The physical interface used to PXE boot the node must always be listed first!

[Note]Interface Map Changes Allowed after Having Run the SUSE Cloud Installation Script

Contrary to all other sections in network.json, you can change interface maps after having executed the SUSE Cloud installation script. However, nodes that are already deployed and affected by these changes need to be deployed again. Therefore it is not recommended to make changes to the interface map that affect active nodes.

If you change the interface mappings after having run the SUSE Cloud installation script, you must not make your changes by editing network.json. You must rather use the Crowbar Web interface and open Barclamps+Crowbar+Network+Edit. Activate your changes by clicking Apply.

D.3.1. Interface Map Example

Example D.1. Changing the Network Interface Order on a Machine with four NICs

  1. Get the machine identifier by running the following command on the machine to which the map should be applied:

    ~ # dmidecode -s system-product-name
    AS 2003R
    

    The resulting string needs to be entered on the pattern line of the map. It is interpreted as a Ruby regular expression (see http://www.ruby-doc.org/core-2.0/Regexp.html for a reference). Unless the pattern starts with ^ and ends with $ a substring match is performed against the name return from the above commands.

  2. List the interface devices in /sys/class/net to get the current order and the bus ID of each interface:

    ~ # ls -lgG /sys/class/net/ | grep eth
    lrwxrwxrwx 1 0 Jun 19 08:43 eth0 -> ../../devices/pci0000:00/0000:00:1c.0/0000:09:00.0/net/eth0
    lrwxrwxrwx 1 0 Jun 19 08:43 eth1 -> ../../devices/pci0000:00/0000:00:1c.0/0000:09:00.1/net/eth1
    lrwxrwxrwx 1 0 Jun 19 08:43 eth2 -> ../../devices/pci0000:00/0000:00:1c.0/0000:09:00.2/net/eth2
    lrwxrwxrwx 1 0 Jun 19 08:43 eth3 -> ../../devices/pci0000:00/0000:00:1c.0/0000:09:00.3/net/eth3
    

    The bus ID is included in the path of the link target—it is the following string: ../../devices/pciBUS ID/net/eth0

  3. Create an interface map with the bus ID listed in the order the interfaces should be used. Keep in mind that the interface from which the node is booted using PXE must be listed first. In the following example the default interface order has been changed to eth0, eth2, eth1 and eth3.

                {
                   "pattern" : "AS 2003R",
                   "bus_order" : [
                      "0000:00/0000:00:1c.0/0000:09:00.0",
                      "0000:00/0000:00:1c.0/0000:09:00.2",
                      "0000:00/0000:00:1c.0/0000:09:00.1",
                      "0000:00/0000:00:1c.0/0000:09:00.3"
                   ]
                } 

D.4. Network Conduits

Network conduits define mappings for logical interfaces—one or more physical interfaces bonded together. Each conduit can be identified by a unique name, the pattern. This pattern is also referred to as Network Mode in this document.

Several network modes are already pre-defined. The most important ones are:

single: Only use the first interface for all networks. VLANs will be added on top of this single interface.
dual: Use the first interface as the admin interface and the second one for all other networks. VLANs will be added on top of the second interface.
team: Bond first two interfaces. VLANs will be added on top of the bond.

See Section 2.1.2, “Network Modes” for detailed descriptions. Apart from these modes a fallback mode ".*/.*/.*" is also pre-defined—it is applied in case no other mode matches the one specified in the global attributes section. These modes can be adjusted according to your needs. It is also possible to define a custom mode.

The mode name that is specified with mode in the global attributes section is deployed on all nodes in SUSE Cloud. It is not possible to use a different mode for a certain node. However, you can define sub modes with the same name that only match machines with a certain number of physical network interfaces or machines with certain roles (all Compute Nodes for example).

         "conduit_map" : [
         ...
            {
               "pattern" : "team/.*/.*"1,
               "conduit_list" : {
                  "intf2"2 : {
                     "if_list" : ["1g1","1g2"]3,
                     "team_mode" : 54
                  },
                  "intf1" : {
                     "if_list" : ["1g1","1g2"],
                     "team_mode" : 5
                  },
                  "intf0" : {
                     "if_list" : ["1g1","1g2"],
                     "team_mode" : 5
                  }
               }
            },
         ...
         ],

1

This line contains the pattern definition for a mode. The value for pattern must have the following form:

mode_name/number_of_nics/node_role

It is interpreted as a Ruby regular expression (see http://www.ruby-doc.org/core-2.0/Regexp.html for a reference).

mode_name

Name of the network mode. This string is used to reference the mode from the general attributes section.

number_of_nics

Normally it is not possible to apply different network modes to different roles—you can only specify one mode in the global attributes section. However, it does not make sense to apply a network mode that bonds three interfaces on a machine with only two physical network interfaces. This option enables you to create modes for nodes with a given number of interfaces.

node_role

This part of the pattern lets you create matches for a certain node role. This enables you to create network modes for certain roles, for example the Compute Nodes (role: nova-multi-compute) or the Swift nodes (role: swift-storage). See Example D.3, “Network Modes for Certain Roles” for the full list of roles.

2

The logical network interface definition. Each conduit list must contain at least one such definition. This line defines the name of the logical interface. This identifier must be unique and will also be referenced in the network definition section. It is recommended to stick with the pre-defined naming scheme with intf0 for Interface 0, intf1 for Interface 1, etc. If you change the name (not recommended), you also need to change all references in the network definition section.

3

This line maps one or more physical interfaces to the logical interface. Each entry represents a physical interface. If more than one entry exists, the interfaces are bonded—either with the mode defined in the team_mode attribute of this conduit section or, if that is not present by the globally defined teaming attribute.

The physical interfaces definition needs to fit the following pattern:

[Quantifier][Speed][Interface Number]

Valid examples are +1g2, 10g1 or ?1g2.

Quantifier

Specifying the quantifier is optional. The following values may be entered:

+: at least the speed specified afterwards (specified value or higher)
-: at most the speed specified afterwards (specified value or lower)
?: any speed (speed specified afterwards is ignored)

If no quantifier is specified, the exact speed specified is used.

Speed

Specifying the interface speed is mandatory (even if using the ? quantifier). The following values may be entered:

10m: 10 Mbit
100m: 100 Mbit
1g: 1 Gbit
10g: 10 Gbit
Order

Position in the interface order. Specifying this value is mandatory. The interface order is defined by the order in which the interfaces appear in /sys/class/net (default) or, if existing, by an interface map. The order is also linked to the speed in this context, so 1g1 means The first 1Gbit interface, +1g1 means The first 1Gbit or 10Gbit interface. ?1g1 would match the very first interface, regardless of its speed.

[Note]Ordering Numbers

Ordering numbers start with 1 rather than with 0.

4

The bonding mode to be used for this logical interface. Overwrites the default set in the global attributes section for this interface. See https://www.kernel.org/doc/Documentation/networking/bonding.txt for a list of available modes. Specifying this option is optional—if not specified here, the global setting applies.

D.4.1. Network Conduit Examples

Example D.2. Network Modes for Different NIC Numbers

The following example defines a network mode named my_mode for nodes with 6, 3 and an arbitrary number of network interfaces. Since the first mode that matches is applied, it is important that the specific modes (for 6 and 3 NICs) are listed before the general one:

            {
               "pattern" : "my_mode/6/.*",
               "conduit_list" : { ... }
            },
            {
               "pattern" : "my_mode/3/.*",
               "conduit_list" : { ... }
            },
            {
               "pattern" : "my_mode/.*/.*",
               "conduit_list" : { ... }
            },

Example D.3. Network Modes for Certain Roles

The following example defines network modes for Compute Nodes with four physical interfaces, the Administration Server (role crowbar), the Control Node, and a general mode applying to all other nodes.

            {
               "pattern" : "my_mode/4/nova-multi-compute",
               "conduit_list" : { ... }
            },
            {
               "pattern" : "my_mode/.*/crowbar",
               "conduit_list" : { ... }
            },
            {
               "pattern" : "my_mode/.*/nova-multi-controller",
               "conduit_list" : { ... }
            },
            {
               "pattern" : "my_mode/.*/.*",
               "conduit_list" : { ... }
            },

The following values for node_role can be used:

ceph-mon-master
ceph-mon
ceph-store
cinder-controller
cinder-volume
crowbar
database-server
glance-server
keystone-server
nova-multi-compute
nova-multi-controller
nova_dashboard-server
neutron-server
rabbitmq-server
swift-dispersion
swift-proxy
swift-ring-compute
swift-storage

The role crowbar refers to the Administration Server.


Example D.4. Network Modes for Certain Machines

Apart from the roles listed under Example D.3, “Network Modes for Certain Roles” each individual node in SUSE Cloud has a unique role, which lets you create modes matching exactly one node. The role is named after the scheme crowbar-d FULLY QUALIFIED HOSTNAME. The FULLY QUALIFIED HOSTNAME in turn is composed of the MAC address of the network interface used to PXE boot the node and the domain name configured on the Administration Server. Colons and periods are replaced with underscores. An example role name would be: crowbar-d1a-12-05-1e-35-49_my_cloud.

Network mode definitions for certain machines must be listed first in the conduit map to make sure no other, general rules which would also map, are applied.

            {
               "pattern" : "my_mode/.*/crowbar-d1a-12-05-1e-35-49_my_cloud",
               "conduit_list" : { ... }
            },

D.5. Network Definitions

The network definitions contain IP address assignments, the bridge and VLAN setup and settings for the router preference. Each network is also assigned to a logical interface defined in the network conduit section. In the following the network definition is explained using the example of the admin network definition:

    "admin" : {
       "conduit" : "intf0"1,
       "add_bridge" : false2,
       "use_vlan" : false3,
       "vlan" : 1004,
       "router_pref" : 105,
       "subnet" : "192.168.124.0"6,
       "netmask" : "255.255.255.0",
       "router" : "192.168.124.1",
       "broadcast" : "192.168.124.255",
       "ranges" : {
          "admin" : { "start" : "192.168.124.10",
                      "end" : "192.168.124.11" },
          "switch" : { "start" : "192.168.124.241",
                        "end" : "192.168.124.250" },
          "dhcp" : { "start" : "192.168.124.21",
                     "end" : "192.168.124.80" },
          "host" : { "start" : "192.168.124.81",
                     "end" : "192.168.124.160" }
       }
    },
  

1

Logical interface assignment. The interface must be defined in the network conduit section and must be part of the active network mode.

2

Bridge setup. Do not touch. Should be false for all networks.

3

Create a VLAN for this network. Changing this setting is not recommended.

4

ID of the VLAN. Change this to the VLAN ID you intend to use for the specific network if required. This setting can also be changed using the YaST Crowbar interface. The VLAN ID for the nova-floating network must always match the one for the public network.

5

Router preference, used to set the default route. On nodes hosting multiple networks the router with the lowest router_pref becomes the default gateway. Changing this setting is not recommended.

6

Network address assignments. These values can also be changed by using the YaST Crowbar interface.

[Important]VLAN Settings

As of SUSE Cloud 3, using a VLAN for the admin network is only supported on a native/untagged VLAN. If you need VLAN support for the admin network, it must be handled at switch level.

When changing the network configuration with YaST or by editing /etc/crowbar/network.json you can define VLAN settings for each network. For the networks nova-fixed and nova-floating, however, special rules apply:

The use_vlan setting will be ignored. VLANs will only be used when deploying Neutron with openvswitch plus VLAN, with cisco plus VLAN, or with linuxbridges. If Neutron is deployed with one of these settings, you must specify correct VLAN IDs for both networks. The VLAN ID for the nova-floating network must match the one for the public network.

When deploying Compute Nodes with Microsoft Hyper-V or Windows Server, you must not use openvswitch with gre, but rather openvswitch with VLAN (recommended) or linuxbridge as a plugin for Neutron.

Appendix E. Setting up a Netboot Environment for Microsoft* Windows

Setting up Compute Nodes running Microsoft Hyper-V Server or Windows Server 2012 requires to configure the Administration Server to be able to provide the netboot environment for node installation. The environment is generated from a machine running Microsoft Hyper-V Server or Microsoft Windows Server 2012.

E.1. Requirements

The following requirements must be met in order to successfully deploy Hyper-V:

  • Provide a separate machine running Microsoft Windows Server 2012 or Microsoft Hyper-V Server. The machine must be able to access the Administration Server and the Internet.

  • Install Samba (package samba and the Microsoft Hyper-V tools (package hyper-v) on the Administration Server.

E.2. Providing a Hyper-V Netboot Environment

In order to provide a Hyper-V netboot environment on the Administration Server, a samba share, that can be mounted on the Windows machine, is created on the Administration Server. Among others, this share contains the Hyper-V tools which provide Windows scripts to generate the environment.

Procedure E.1. Preparing the Administration Server

  1. Ensure that the requirements listed at Section E.1, “Requirements” are met.

  2. This step is only required if you are running Hyper-V Server—skip it, if you are running Windows Server 2012.

    Add the following line to the /etc/fstab:

    /srv/tftpboot/hyperv-6.2 /srv/tftpboot/windows-6.2 bind bind

    and mount the directory you added:

    mount /srv/tftpboot/windows-6.2
  3. If you have more than one hard disk, edit /srv/tftpboot/adk-tools/build_winpe.ps1and adjust the value for $install_media accordingly.

  4. Make sure the Samba daemons smb and nmb are automatically started during boot and are currently running by executing the following commands:

    insserv smb nmb
    rcsmb start
    rcnmb start
  5. Edit the Samba configuration file /etc/samba/smb.conf and add the following share:

    [reminst]
            comment = MS Windows remote install
            guest ok = Yes
            inherit acls = Yes
            path = /srv/tftpboot
            read only = No
            force user = root

    By default, the workgroup name is set to WORKGROUP in the [global] section of /etc/samba/smb.conf. Adjust it, if needed.

  6. Reload the smb service:

    rcsmb reload

Once Samba is properly configured on the Administration Server, log in to the machine running Microsoft Windows Server 2012 or Microsoft Hyper-V Server and generate the environment:

Procedure E.2. Netboot Environment Generation

  1. Log in to the Microsoft Windows Server 2012 or Microsoft Hyper-V Server machine. Connect the device name X: to the Samba share \\crowbar\reminst configured on the Administration Server (which is named crowbar by default) in the previous step. This can either be done from the Explorer or on the command line with the net use x: \\crowbar\reminst command.

  2. Device X: contains a directory X:\adk-tools with image creation scripts for either Hyper-V (build_winpe_hyperv-6.2.ps1) or Windows Server (build_winpe_windows-6.2.ps1). Build the image by running the following commands on the command line:

    Hyper-V Server
    powershell -ExecutionPolicy Bypass x:\adk-tools\build_winpe_hyperv-6.2.ps1
    Windows Server 2012
    powershell -ExecutionPolicy Bypass x:\adk-tools\build_winpe_windows-6.2.ps1

    Executing the script requires Internet access, because additional software needs to be downloaded.

After the netboot environment is set up, you can choose either Windows Server 2012 or Hyper-V Server 2012 as the Target Platform for newly discovered nodes from the Node Dashboard.

Appendix F. VMware vSphere Installation Instructions

SUSE Cloud supports the Nova Compute VMware vCenter driver which enables access to advanced features such as vMotion, High Availability, and Dynamic Resource Scheduling (DRS). However, VMware vSphere is not supported natively by SUSE Cloud—it rather delegates requests to an existing vCenter. It requires preparations at the vCenter and post install adjustments of the Compute Node.

F.1. Requirements

The following requirements must be met in order to successfully deploy a Nova Compute VMware node:

  • VMware vSphere vCenter 5.1

  • VMware vSphere ESXi nodes 5.1

  • Security groups are only supported when running VMWare NSX. You need to deploy Neutron with the vmware plugin as described in Section 5.10, “Deploying Neutron” to have security group support. This is also a prerequisite for gre tunnel support.

F.2. Preparing the VMware vCenter Server

SUSE Cloud requires the VMware vCenter server to run version 5.1 or better. You need to create a single datacenter for SUSE Cloud (multiple datacenters are currently not supported):

  1. Log in to the vCenter Server using the vSphere Web Client

  2. Choose Hosts and Clusters and create a single Datacenter

  3. Set up a New Cluster which has DRS enabled.

  4. Set Automation Level to Fully Automated and Migration Threshold to Aggressive.

  5. Create shared storage. Only shared storage is supported and data stores must be shared among all hosts in a cluster. It is recommended to remove data stores not intended for OpenStack from clusters being configured for OpenStack. Currently, a single data store can be used per cluster.

  6. Create a port group named br-int. Network devices of all instances will be attached to this group.

F.3. Finishing the Nova Compute VMware node Installation

Deploy Nova as described in Section 5.11, “Deploying Nova” on a single Compute Node and fill in the VMWare vCenter Settings attributes:

vCenter IP Address

IP address of the vCenter server.

vCenter Username / vCenter Password

vCenter login credentials.

Cluster Names

A comma-separated list of cluster names you have added on the vCenter server.

VLAN Interface

The physical interface that is to be used for VLAN networking. The default value of vmnic0 references the first available interface (eth0). vmnic1 would be the second interface (eth1).

Figure F.1. The Nova barclamp: VMware Configuration

The Nova barclamp: VMware Configuration

Appendix G. Using Cisco Nexus Switches with Neutron

G.1. Requirements

The following requirements must be met in order to use Cisco Nexus switches with Neutron:

  • Cisco Nexus series 3000, 5000 or 7000

  • All Compute Nodes must be equipped with at least two network cards.

  • The switch needs to have the XML management interface enabled. SSH access to the management interface must be enabled (refer to the switch's documentation for details).

  • Enable VLAN trunking for all Neutron managed VLANs on the switch port to which the controller node running Neutron is connected to.

  • If VLAN configurations for Neutron managed VLANs already exist on the switch (for example from a previous SUSE Cloud deployment), you need to delete them via the switch's management interface prior to deploying Neutron.

  • When using the cisco plugin, Neutron reconfigures the VLAN trunk configuration on all ports used for the nova-fixed traffic (the traffic between the instances). This requires to configure separate network interfaces exclusively used by nova-fixed. This can be achieved by adjusting /etc/crowbar/network.json (refer to Appendix D, The Network Barclamp Template File). The following example shows an appropriate configuration for dual mode, where nova-fixed has bee mapped to conduit intf1 and all other networks to other conduits. Configuration attributes not relevant in this context have been replaced with ....

    Example G.1. Exclusively Mapping nova-fixed to conduit intf1 in dual mode

    {
       "attributes" : {
          "network" : {
             "conduit_map" : [
                ...
             ],
             "mode" : "single",
             "networks" : {
                "nova_fixed" : {
                  ...,
    	      "conduit" : "intf1"
                },
                "nova_floating" : {
                  ...,
    	      "conduit" : "intf0"
                },
                "public" : {
                  ...,
    	      "conduit" : "intf0"
                },
                "storage" : {
                  ...,
    	      "conduit" : "intf0"
                },
                "os_sdn" : {
                  ...,
    	      "conduit" : "intf0"
                },
                "admin" : {
                  ...,
    	      "conduit" : "intf0"
                },
                "bmc" : {
                  ...,
    	      "conduit" : "bmc"
                },
                "bmc_vlan" : {
                  ...,
    	      "conduit" : "intf2"
                },
             },
    	 ...,
          },
       }
    }

  • Make a note of all switch ports to which the interfaces using the nova-fixed network on the Compute Nodes are connected. This information will be needed when deploying Neutron.

G.2. Deploying Neutron with the Cisco Plugin

  1. Create a Neutron barclamp proposal in the Crowbar Web interface.

  2. Select cisco as the Plugin and vlan for Mode.

  3. The Cisco Switch Credentials table will be faded out. Enter the IP Address, the SSH Port number and the login credentials for the switch's management interface. If you have multiple switches, open a new row in the table by clicking Add and enter the data for another switch.

    Figure G.1. The Neutron barclamp: Cisco Plugin

    The Neutron barclamp: Cisco Plugin

  4. Choose whether to encrypt public communication (HTTPS) or not (HTTP). If choosing HTTPS, refer to SSL Support: Protocol for configuration details.

  5. Choose a node for deployment and Apply the proposal.

  6. Deploy Nova (see Section 5.11, “Deploying Nova”), Horizon (see Section 5.12, “Deploying Horizon (OpenStack Dashboard)” and all other remaining barclamps.

  7. Once all barclamps have been deployed, return to the Neutron barclamp by choosing Barclamps+OpenStack+Neutron+Edit. The proposal now contains an additional table named Assign Switch Ports, listing all Compute Nodes.

    For each Compute Node enter the switch it is connected to and the port number from the notes you took earlier. The values need to be entered like the following: 1/13 or Eth1/20.

  8. Once you have entered the data for all Compute Nodes, re-apply the proposal.

    [Important]Deploying Additional Compute Nodes

    Whenever you deploy additional Compute Nodes to an active SUSE Cloud deployment using the Cisco plugin with Neutron, you need to update the Neutron barclamp proposal by entering their port data as described in the previous step.

[Note]Verifying the Setup

In order to verify if Neutron was correctly deployed, do the following:

  1. Launch an instance (refer to Section “Launching Instances” (Chapter 1, Using SUSE Cloud Dashboard, ↑End User Guide) for instructions).

  2. Find out which VLAN was assigned to the network by running the command neutron net-show fixed. The result lists a segmentation_id matching the VLAN.

  3. Log in to the switch's management interface and list the VLAN configuration. If the setup was deployed correctly, the port of the Compute Node the instance is running on, is in trunk mode for the matching VLAN.

Terminology

Active/Active

A concept of how services are running on nodes in a High Availability cluster. In an active/active setup, both the main and redundant systems are managed concurrently. If a failure of services occurs, the redundant system is already online, and can take over until the main system is fixed and brought back online.

Active/Passive

A concept of how services are running on nodes in a High Availability cluster. In an active/passive setup, one or more services are running on an active cluster node, whereas the passive node stands by. Only in case of the active node failing, the services are transferred to the passive node.

Administration Server

Also called Crowbar Administration Node. Manages all other nodes. It assigns IP addresses to them, PXE boots them, configures them, and provides them the necessary software for their roles. To provide these services, the Administration Server runs Crowbar, Chef, DHCP, TFTP, NTP, and other services.

AMI (Amazon Machine Image)

A virtual machine that can be created and customized by a user. AMIs can be identified by an ID prefixed with ami-.

Availability Zone

An OpenStack method of partitioning clouds. It enables you to arrange OpenStack Compute hosts into logical groups, which typically have physical isolation and redundancy from other availability zones, for example, by using separate power supply or network equipment for each zone. When users provision resources, they can specify from which availability zone their instance should be created. This allows cloud consumers to ensure that their application resources are spread across disparate machines to achieve high availability in the event of hardware failure. Since the Grizzly release, availability zones are implemented via host aggregates.

AWS (Amazon Web Services)

A collection of remote computing services (including Amazon EC2, Amazon S3, and others) that together make up Amazon's cloud computing platform.

barclamp

A set of Chef cookbooks, templates, and other logic. Used to apply a particular Chef role to individual nodes or a set of nodes.

Ceilometer

Code name for Telemetry.

Cell

Cells provide a new way to scale Compute deployments, including the ability to have compute clusters (cells) in different geographic locations all under the same Compute API. This allows for a single API server being used to control access to multiple cloud installations. Cells provide logical partitioning of Compute resources in a child/parent relationship.

Chef

An automated configuration management platform for deployment of your entire cloud infrastructure. The Chef server manages many of the software packages and allows the easy changing of nodes.

Ceph

A massively scalable, open source, distributed storage system. It consists of an object store, a block store, and a POSIX-compliant distributed file system.

Cinder

Code name for OpenStack Block Storage.

Cluster

A set of connected computers that work together. In many respects (and from the outside) they can be viewed as a single system. Clusters can be further categorized depending on their purpose, for example: High Availability clusters, high-performance clusters, or load-balancing clusters.

Cluster Partition

Whenever communication fails between one or more nodes and the rest of the cluster, a cluster partition occurs: The nodes of a cluster are split into partitions but still active. They can only communicate with nodes in the same partition and are unaware of the separated nodes. As the loss of the nodes on the other partition cannot be confirmed, a Split Brain scenario develops.

Cluster Resource Manager

The main management entity in a High Availability cluster responsible for coordinating all non-local interactions. The SUSE Linux Enterprise High Availability Extension uses Pacemaker as CRM. Each node of the cluster has its own CRM instance, but the one running on the Designated Coordinator (DC) is the one elected to relay decisions to the other non-local CRMs and process their input.

Container

A container is a storage compartment for data. It can be thought of as a directory, only that it cannot be nested.

cloud-init

A package commonly installed in virtual machine images. It uses the SSH public key to initialize an instance after boot.

Compute Node

Node within a SUSE Cloud. A physical server running a Hypervisor. A Compute Node is a host for guest virtual machines that are deployed in the cloud. It starts virtual machines on demand using nova-compute. To split virtual machine load across more than one server, a cloud should contain multiple Compute Nodes.

Control Node

Node within a SUSE Cloud. The Control Node is configured through the Administration Server and registers with the Administration Server for all required software. Hosts the OpenStack API endpoints and the OpenStack scheduler and runs the nova services—except for nova-compute, which is run on the Compute Nodes. The Control Node coordinates everything about cloud virtual machines: like a central communication center it receives all requests (for example, if a user wants to start or stop a virtual machine) and communicates with the Compute Nodes to coordinate fulfillment of the request. A cloud can contain multiple Control Nodes.

Cookbook

A collection of Chef recipes which deploy a software stack or functionality. The unit of distribution for Chef.

Crowbar

Bare-metal installer and an extension of Chef server. The primary function of Crowbar is to get new hardware into a state where it can be managed by Chef. That means: Setting up BIOS and RAID, network, installing a basic operating system, and setting up services like DNS, NTP, and DHCP. The Crowbar server manages all nodes, supplying configuration of hardware and software.

Designated Coordinator (DC)

One Cluster Resource Manager in a High Availability cluster is elected as the Designated Coordinator (DC). The DC is the only entity in the cluster that can decide that a cluster-wide change needs to be performed, such as fencing a node or moving resources around. After a membership change, the DC is elected from all nodes in the cluster.

DRBD (Distributed Replicated Block Device)

DRBD* is a block device designed for building high availability clusters. The whole block device is mirrored via a dedicated network and is seen as a network RAID-1.

EBS (Amazon Elastic Block Store)

Block-level storage volumes for use with Amazon EC2 instances. Similar to OpenStack Cinder.

EC2 (Amazon Elastic Compute Cloud)

A public cloud run by Amazon. It provides similar functionality to OpenStack Compute.

Ephemeral Disk

Ephemeral disks offer machine local disk storage linked to the lifecycle of a virtual machine instance. When a virtual machine is terminated, all data on the ephemeral disk is lost. Ephemeral disks are not included in any snapshots.

Failover

Occurs when a resource fails on a cluster node (or the node itself fails) and the affected resources are started on another node.

Fencing

Describes the concept of preventing access to a shared resource by isolated or failing cluster members. Should a cluster node fail, it will be shut down or reset to prevent it from causing trouble. The resources running on the cluster node will be moved away to another node. This way, resources are locked out of a node whose status is uncertain.

Flavor

The compute, memory, and storage capacity of nova computing instances (in terms of virtual CPUs, RAM, etc.). Flavors can be thought of as templates for the amount of cloud resources that are assigned to an instance.

Floating IP Address

An IP address that a Compute project can associate with a virtual machine. A pool of floating IPs is available in OpenStack Compute, as configured by the cloud operator. After a floating IP address has been assigned to an instance, the instance can be reached from outside the cloud by this public IP address. Floating IP addresses can be dynamically disassociated and associated with other instances.

Fixed IP Address

When an instance is launched, it is automatically assigned a fixed (private) IP address, which stays the same until the instance is explicitly terminated. Private IP addresses are used for communication between instances.

Glance

Code name for OpenStack Image.

Guest Operating System

An instance of an operating system installed on a virtual machine.

Heat

Code name for Orchestration.

High Availability Cluster

High Availability clusters seek to minimize two things: System downtime and data loss. System downtime occurs when a user-facing service is unavailable beyond a specified maximum amount of time.  System downtime and data loss (accidental deletion or destruction of data) can occur not only in the event of a single failure, but also in case of cascading failures, where a single failure deteriorates into a series of consequential failures.

Horizon

Code name for OpenStack Dashboard.

Host

A physical computer.

Host Aggregate

An OpenStack method of grouping hosts via a common set of metadata. It enables you to tag groups of hosts with certain capabilities or characteristics. A characteristic could be related to physical location, allowing creation or further partitioning of availability zones, but could also be related to performance (for example, indicating the availability of SSD storage) or anything else which the cloud administrators deem appropriate. A host can be in more than one host aggregate.

Hybrid Cloud

One of several deployment models for a cloud infrastructure. A composition of both public and private clouds that remain unique entities, but are bound together by standardized technology for enabling data and application portability. Integrating SUSE Studio and SUSE Manager with SUSE Cloud delivers a platform and tools with which to enable enterprise hybrid clouds.

Hypervisor

A piece of computer software, firmware or hardware that creates and runs virtual machines. It arbitrates and controls access of the virtual machines to the underlying hardware.

IaaS (Infrastructure-as-a-Service)

A service model of cloud computing where processing, storage, networks, and other fundamental computing resources are rented over the Internet. It allows the customer to deploy and run arbitrary software, including operating systems and applications. The customer has control over operating systems, storage, and deployed applications but does not control the underlying cloud infrastructure. Housing and maintaining it is in the responsibility of the service provider.

Image

A file that contains a complete Linux virtual machine.

In the SUSE Cloud context, images are virtual disk images that represent the contents and structure of a storage medium or device, such as a hard disk, in a single file. Images are used as a template from which a virtual machine can be started. For starting a virtual machine, SUSE Cloud always uses a copy of the image.

Images have both content and metadata; the latter are also called image properties.

Instance

A virtual machine that runs inside the cloud.

Instance Snapshot

A point-in-time copy of an instance. It preserves the disk state of a running instance and can be used to launch a new instance or to create a new image based upon the snapshot.

Keypair

OpenStack Compute injects SSH keypair credentials that are injected into images when they are launched.

Keystone

Code name for OpenStack Identity.

libvirt

Virtualization API library. Used by OpenStack to interact with many of its supported hypervisors.

Linux Bridge

A software allowing multiple virtual machines to share a single physical NIC within OpenStack Compute. It behaves like a hub: You can connect multiple (physical or virtual) network interface devices to it. Any Ethernet frames that come in from one interface attached to the bridge is transmitted to all other devices.

Logical Volume (LV)

Acts as a virtual disk partition. After creating a Volume Group (VG), logical volumes can be created in that volume group. Logical volumes can be used as raw block devices, swap devices, or for creating a (mountable) file system like disk partitions.

Migration

The process of moving a virtual machine instance from one Compute Node to another. This process can only be executed by cloud administrators.

Multicast

A technology used for a one-to-many communication within a network that can be used for cluster communication. Corosync supports both multicast and unicast.

Network

In the OpenStack Networking API: An isolated L2 network segment (similar to a VLAN). It forms the basis for describing the L2 network topology in a given OpenStack Networking deployment.

Neutron

Code name for OpenStack Networking.

Node

A (physical) server that is managed by Crowbar.

Nova

Code name for OpenStack Compute.

Object

Basic storage entity in OpenStack Object Storage, representing a file that your store there. When you upload data to OpenStack Object Storage, the data is neither compressed nor encrypted, it is stored as-is.

Open vBridge

A virtual networking device. It behaves like a virtual switch: network interface devices connect to its ports. The ports can be configured similar to a physical switch's port, including VLAN configurations.

OpenAIS/Corosync

The messaging/infrastructure layer used in a High Availability cluster that is set up with SUSE Linux Enterprise High Availability Extension. For example, the cluster communication channels are defined in /etc/corosync/corosync.conf.

OpenStack

A collection of open source software to build and manage public and private clouds. Its components are designed to work together to provide Infrastructure as a Service and massively scalable cloud computing software.

At the same time, OpenStack is also a community and a project.

OpenStack Block Storage

One of the core OpenStack components and services (code name: Cinder). It provides persistent block level storage devices for use OpenStack compute instances. The block storage system manages the creation, attaching and detaching of the block devices to servers. Prior to the OpenStack Grizzly release, the service was part of nova-volume (block service).

OpenStack Compute

One of the core OpenStack components and services (code name: Nova). It is a cloud computing fabric controller and as such, the main part of an IaaS system. It provides virtual machines on demand.

OpenStack Dashboard

One of the core OpenStack components or services (code name: Horizon). It provides a modular Web interface for OpenStack services and allows end users and administrators to interact with each OpenStack service through the service's API.

OpenStack Identity

One of the core OpenStack components or services (code name: Keystone). It provides authentication and authorization for all OpenStack services.

OpenStack Image

One of the core OpenStack components or services (code name: Glance). It provides discovery, registration, and delivery services for virtual disk images.

OpenStack Networking

One of the core OpenStack components or services (code name: Neutron). It provides network connectivity as a service between interface devices (for example, vNICs) managed by other OpenStack services (for example, Compute). Allows users to create their own networks and attach interfaces to them.

OpenStack Object Storage

One of the core OpenStack components or services (code name: Swift). Allows to store and retrieve files while providing built-in redundancy and fail-over. Can be used for backing up and archiving data, streaming data to a user's Web browser, or developing new applications with data storage integration.

OpenStack Service

A collection of Linux services (or daemons) that work together to provide core functionality within the OpenStack project, like storing objects, providing virtual servers, or authentication and authorization. All services have code names, which are also used in configuration files and command line programs that belong to the service.

Orchestration

A module (code name: Heat) to orchestrate multiple composite cloud applications using file-based or Web-based templates. It contains both a user interface and an API and describes your cloud deployment in a declarative language. The module is an integrated project of OpenStack as of the Havana release.

PaaS (Platform-as-a-Service)

A service model of cloud computing where a computing platform and cloud-based application development tools are rented over the Internet. The customer controls software deployment and configuration settings, but not the underlying cloud infrastructure including network, servers, operating systems, or storage.

Pacemaker

An open source cluster resource manager used in SUSE Linux Enterprise High Availability Extension.

Port

In the OpenStack Networking API: An attachment port to an L2 OpenStack Networking network.

Project

A concept in OpenStack Identity. Used to identify a group, an organization, or a project (or more generically, an individual customer environment in the cloud). Also called tenant. The term tenant is primarily used in the OpenStack command line tools.

Proposal

Special configuration for a barclamp. It includes barclamp-specific settings, and a list of nodes to which the proposal should be applied.

Private Cloud

One of several deployment models for a cloud infrastructure. The infrastructure is operated exclusively for a single organization and may exist on or off premises. The cloud is owned and managed by the organization itself, by a third party or a combination of both.

Private IP Address

See Fixed IP Address.

Public Cloud

One of several deployment models for a cloud infrastructure. The cloud infrastructure is designed for use by the general public and exists on the premises of the cloud provider. Services like applications, storage, and other resources are made available to the general public for free or are offered on a pay-per-use model. The infrastructure is owned and managed by a business, academic or government organization, or some combination of these.

Public IP Address

See Floating IP Address.

qcow (QEMU Copy on Write)

A disk image format supported by the QEMU virtual machine manager. A qcow2 image helps to optimize disk space as it consumes disk space only when contents are written on it and grows as data is added.

qcow2 is a more recent version of the qcow format where a read-only base image is used, and all writes are stored to the qcow2 image.

Quorum

In a cluster, a Cluster Partition is defined to have quorum (is quorate) if it has the majority of nodes (or votes). Quorum distinguishes exactly one partition. It is part of the algorithm to prevent several disconnected partitions or nodes from proceeding and causing data and service corruption (Split Brain). Quorum is a prerequisite for Fencing, which then ensures that quorum is indeed unique.

Quota

Restriction of resources to prevent overconsumption within a cloud. In OpenStack, quotas are defined per project and contain multiple parameters, such as amount of RAM, number of instances, or number of floating IP addresses.

RC File (openrc.sh)

Environment file needed for the OpenStack command line tools. The RC file is project-specific and contains the credentials used by OpenStack Compute, Image, and Identity services.

Recipe

A group of Chef scripts and templates. Recipes are used by Chef to deploy a unit of functionality.

Region

An OpenStack method of aggregating clouds. Regions are a robust way to share some infrastructure between OpenStack compute installations, while allowing for a high degree of failure tolerance. Regions have a separate API endpoint per installation.

Resource

In a High Availability context: Any type of service or application that is known to the cluster resource manager. Examples include an IP address, a file system, or a database.

Resource Agent (RA)

A script acting as a proxy to manage a resource in a High Availability cluster. For example, it can start, stop or monitor a resource.

Role

In the Crowbar/Chef context: an instance of a Proposal that is active on a node.

In the OpenStack Identity context: concept of controlling the actions or set of operations that a user is allowed to perform. A role includes a set of rights and privileges. A user assuming that role inherits those rights and privileges.

S3 (Amazon Simple Storage Service)

An object storage by Amazon that can be used to store and retrieve data on the Web. Similar in function to OpenStack Object Storage. It can act as a back-end store for Glance images.

SaaS (Software-as-a-Service)

A service model of cloud computing where applications are hosted by a service provider and made available to customers remotely as a Web-based service.

SBD (STONITH Block Device)

In an environment where all nodes of an High Availability cluster have access to shared storage, a small partition is used for disk-based fencing.

Security Group

Concept in OpenStack Networking. A security group is a container for security group rules. Security group rules allow to specify the type of traffic and direction (ingress/egress) that is allowed to pass through a port.

Single Point of Failure (SPOF)

An individual piece of equipment or software which will cause system downtime or data loss if it fails. In order to eliminate single points of failure, High Availability systems seek to provide redundancy for crucial pieces of equipment or software.

Snapshot

See Volume Snapshot or Instance Snapshot.

Split Brain

Also known as a partitioned cluster scenario. Either through a software or hardware failure, the cluster nodes are divided into two or more groups that do not know of each other. STONITH prevents a split brain situation from badly affecting the entire cluster.

Stateful Service

A service where subsequent requests to the service depend on the results of the first request.

Stateless Service

A service that provides a response after your request, and then requires no further attention.

STONITH

The acronym for Shoot the other node in the head. It refers to the fencing mechanism that shuts down a misbehaving node to prevent it from causing trouble in a cluster.

Storage Node

Node within a SUSE Cloud. Acts as the controller for cloud-based storage. A cloud can contain multiple Storage Nodes.

Subnet

In the OpenStack Networking API: A block of IP addresses and other network configuration (for example, a default gateway, DNS servers) that can be associated with an OpenStack Networking network. Each subnet represents an IPv4 or IPv6 address block. Multiple subnets can be associated with a network, if necessary.

SUSE Cloud Administrator

User role in SUSE Cloud. Manages projects, users, images, flavors, and quotas within SUSE Cloud.

SUSE Cloud Dashboard

The SUSE® Cloud Dashboard is a Web interface that enables cloud administrators and users to manage various OpenStack services. It is based on OpenStack Dashboard (also known under its codename Horizon).

SUSE Cloud Operator

User role in SUSE Cloud. Installs and deploys SUSE Cloud.

SUSE Cloud User

User role in SUSE Cloud. End user who launches and manages instances, can create snapshots, and use volumes for persistent storage within SUSE Cloud.

SUSE Linux Enterprise High Availability Extension

An integrated suite of open source clustering technologies that enables you to implement highly available physical and virtual Linux clusters.

Swift

Code name for OpenStack Object Storage.

TAP Device

A virtual networking device. A TAP device, such as vnet0 is how hypervisors such as KVM and Xen implement a virtual network interface card (vNIC). An Ethernet frame sent to a TAP device is received by the guest operating system. The tap option connects the network stack of the guest operating system to a TAP network device on the host.

Telemetry

A module (code name: Ceilometer) for metering OpenStack-based clouds. The project aims to provide a unique point of contact across all OpenStack core components for acquiring metrics which can then be consumed by other components such as customer billing. The module is an integrated project of OpenStack as of the Havana release.

Tenant

See Project.

Unicast

A technology for sending messages to a single network destination. Corosync supports both multicast and unicast. In Corosync, unicast is implemented as UDP-unicast (UDPU).

User

In the OpenStack context, a digital representation of a person, system, or service who uses OpenStack cloud services. Users can be directly assigned to a particular project and behave as if they are contained in that project.

Veth Pair

A virtual networking device. The acronym veth stands for virtual Ethernet interface. A veth is a pair of virtual network interfaces correctly directly together. An Ethernet frame sent to one end of a veth pair is received by the other end of a veth pair. OpenStack Networking makes use of veth pairs as virtual patch cables to make connections between virtual bridges.

VLAN

A physical method for network virtualization. VLANs allow to create virtual networks across a distributed network so that disparate hosts (on independent networks) appear as if they were part of the same broadcast domain.

VM (Virtual Machine)

An operating system instance that runs on top of a hypervisor. Multiple virtual machines can run on the same physical host at the same time.

vNIC

Virtual network interface card.

Volume

Detachable block storage device. Unlike a SAN, it can only be attached to one instance at a time.

Volume Group (VG)

A virtual disk consisting of aggregated physical volumes. Volume groups can be logically partitioned into logical volumes.

Volume Snapshot

A point-in-time copy of an OpenStack storage volume. Used to back up volumes.

vSwitch (Virtual Switch)

A software that runs on a host or node and provides the features and functions of a hardware-based network switch.

Zone

A logical grouping of Compute services and virtual machine hosts.


SUSE Cloud Deployment Guide 3