Applies to SUSE OpenStack Cloud 7

1 The SUSE OpenStack Cloud Architecture

Abstract

SUSE OpenStack 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 OpenStack Cloud 7 provides the following features:

  • Open source software that is based on the OpenStack Newton 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) and 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.

  • Heterogeneous hypervisor support (Xen and KVM).

SUSE OpenStack 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). The cloud management layer, OpenStack, works as the Cloud Operating System. Crowbar and Chef are used to automatically deploy and manage the OpenStack nodes from a central Administration Server.

SUSE OpenStack Cloud Infrastructure
Figure 1.1: SUSE OpenStack Cloud Infrastructure

SUSE OpenStack 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—together with Chef—automates all the required installation and configuration tasks. Among the services provided by the server are DHCP, DNS, NTP, PXE, TFTP.

Administration Server Diagram

The Administration Server also hosts the software repositories for SUSE Linux Enterprise Server and SUSE OpenStack Cloud. They are needed for node deployment. 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 components needed to orchestrate virtual machines deployed on the Compute Nodes in the SUSE OpenStack Cloud. OpenStack on SUSE OpenStack Cloud uses a PostgreSQL database, which is also hosted on the Control Node(s). The following OpenStack components—if deployed—run on the Control Node(s):

  • PostgreSQL database

  • Image (Glance) for managing virtual images

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

  • 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, a user Web interface for the OpenStack components

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

  • Message broker (RabbitMQ)

  • Swift proxy server plus dispersion tools (health monitor) and Swift ring (index of objects, replicas, and devices). Swift provides object storage.

  • Ceph master cluster monitor (Calamari), needs to be deployed on a dedicated node

  • Hawk, a monitor for a pacemaker cluster (HA setup)

  • Heat, an orchestration engine

  • Ceilometer server and agents. Ceilometer collects CPU and networking data for billing purposes.

  • Trove, a Database-as-a-Service, needs to be deployed on a dedicated node

Being a central point in the SUSE OpenStack Cloud architecture that runs a lot of services, a single Control Node can quickly become a performance bottleneck. This is especially true for large SUSE OpenStack 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 10.9, “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. Trove, the Database-as-a-Service for SUSE OpenStack Cloud and Calamari, the server for Ceph management and monitoring, always need to be deployed on dedicated Control Nodes.

Note
Note: Moving Services in an Existing Setup

In case you plan to move a service in an already deployed SUSE OpenStack Cloud from one Control Node to another, it is strongly recommended to shut down or save all instances before doing so. 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.2.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 component Compute (Nova) runs on the Compute Nodes and provides means for setting up, starting, and stopping virtual machines.

SUSE OpenStack Cloud supports several hypervisors such as KVM, VMware vSphere and 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 or block storage. Object storage is provided by the OpenStack Swift component, while block storage is provided by Cinder. The latter supports several back-ends, including Ceph, that can be deployed during the installation. Deploying Swift and Ceph is optional.

1.5 HA Setup

A failure of components in SUSE OpenStack Cloud can lead to system downtime and/or data loss. To prevent this, SUSE OpenStack Cloud 7 allows you to make all functions provided by the Control Node(s) highly available. During cloud deployment, you can set up a High Availability (HA) cluster consisting of several nodes. You can assign certain roles to this cluster instead of assigning them to individual nodes. As of SUSE OpenStack Cloud 7, Control Nodes and Compute Nodes can be made highly available.

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 as messaging/infrastructure layer.

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

Important
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 Nodes) can be critical and can cause downtime within the cloud. For more information on making those services highly-available and avoiding other potential points of failure in your cloud setup, refer to Section 2.6, “High Availability”.

Print this page