This article describes OpenStack Compute (Nova), which represents the core of any workload. Even though there are cloud services that work without computation, at best they represent static storage — all dynamic activity involves some element of computation.
The name OpenStack Compute refers to a specific project, also called Nova, but there are really two projects that relate to computation and the software that runs it — Image and Compute:
- OpenStack Image manages static disk images which contain the executable code as well as the operating environment.
- OpenStack Compute (Nova) manages the running instances.
Nova controls the cloud computing fabric and as such forms the core of an infrastructure service. Nova is also the most complex component of the OpenStack family, primarily because of its highly distributed nature and numerous processes.
Nova interfaces with several other OpenStack services: It uses Keystone to perform its authentication, Horizon as its administrative interface, and Glance to supply its images. The tightest interaction is with Glance which Nova requires to download images for use in launching images.
Before going into more detail on Nova, let's take a closer look at the Image service, which, chronologically, represents the beginning of the Compute workload. Glance is the project name for the OpenStack Image Service which registers, lists, and retrieves virtual machine (VM) images.
Glance manages the images in an OpenStack cluster but is not responsible for the actual storage. It provides an abstraction to multiple storage technologies ranging from simple file systems to object storage systems, such as the OpenStack Swift project. Along with the actual disk images, it holds metadata and status information describing the image.
The OpenStack Image Store is a central repository for virtual images. Users and other projects can store both public and private images which they can access to launch instances. They can request a list of available images, retrieve their configuration information, and then use them as a basis for starting Nova instances. It is also possible to take snapshots from running instances as a means of backing up the VMs and their states.
Nova comes into action after the image is created. It typically uses an image to launch an instance, or VM. Although it does not include any virtualization software itself, it can integrate with many common hypervisors through drivers that interface with the virtualization technologies.
From a practical perspective, launching an instance involves identifying and specifying the virtual hardware templates (called flavors in OpenStack). The templates describe the compute (virtual CPUs), memory (RAM), and storage configuration (hard disks) to be assigned to the VM instances. The default installation provides five flavors which are configurable by administrators.
Nova then schedules the requested instance by assigning execution to a
specific compute node (called a host in OpenStack). Each system must
regularly report its status and capabilities
which uses the data to optimize its allocations.
The whole assignment process consists of two phases. The Filtering phase applies a set of filters to generate a list of the most suitable hosts. Every OpenStack service publishes its capabilities which is one of the most important considerations. The scheduler narrows the selection of hosts to meet the parameters of the request. A Weighting phase then uses a special function to calculate the cost of each host and sorts the results. The output of this phase is a list of hosts that can satisfy the user's request for a given number of instances with the least cost.
Nova also carries out several additional functions, many of which interact closely with other OpenStack projects covering networking, security, and administration. But Nova generally handles the instance-specific aspects of these, such as attaching and detaching storage, assigning IP addresses, or taking snapshots of running instances.
Nova uses a shared-nothing architecture (Figure 1), so that all major components can be run on separate servers. The distributed design relies on a message queue to handle the asynchronous component-to-component communications.
Figure 1. Nova architecture
Nova stores states of VMs in a central Structured Query Language
(SQL)-based database that all OpenStack components use. This database
holds details of available instance types, networks (if
nova-network is in use), and projects. Any database that
SQLAlchemy supports can be used.
The primary user interface to OpenStack Compute is the Web dashboard (OpenStack Horizon). This central portal for all OpenStack modules presents a graphic interface of all the projects and makes application programming interface (API) calls to invoke any requested services.
The API is based on Representational State Transfer. It's a Web Server
Gateway Interface application that routes uniform resource indicators to
action methods on controller classes. The API receives HTTP requests,
processes the commands, and then delegates the task to other components
via the message queue or HTTP (in the case of the
ObjectStore). The Nova API supports the OpenStack Compute
API, the Amazon Elastic Compute Cloud (Amazon EC2) API, and an Admin API
for privileged users. It initiates most orchestration activities and
policies (like Quota).
Each HTTP request requires specific authentication credentials using one of the authentication schemes the provider has configured for the Compute node. The Authorization Manager is not a separate binary; rather, it is a Python class that any OpenStack component can use for authentication. It exposes authorized APIs usage for users, projects, and roles and communicates with OpenStack Keystone for details. The actual user store can be a database or Lightweight Directory Access Protocol (LDAP) back end.
ObjectStore is a simple HTTP-based object-based storage
(like Amazon Simple Storage Service) for images. It can be and usually is
replaced with OpenStack Glance.
The message queue provides a means for all of the components in OpenStack Nova to communicate and coordinate with each other. It's like a central task list that all Nova components share and update.
All of these components run in a nonblocking message-based architecture and can be run from the same or different hosts as long as they use the same message queue service. They interact in a callback-oriented manner using the Advanced Message Queuing Protocol. By default, most distributions implement RabbitMQ accessed via the Kombu library, but plug-ins are also available for Apache Qpid and ZeroMQ.
Nova components use remote procedure call to communicate with each other
via the Message Broker using Pub/sub. More technically, Nova implements
rpc.call (request/response; the API acts as consumer) and
rpc.cast (one way; the API acts as publisher).
Nova API and the scheduler use the message queue as the Invoker, whereas
Network and Compute act as workers. An Invoker sends messages via
rpc.cast. The Worker pattern
receives messages from the queue and answers each
with the appropriate response.
Nova compute is a worker daemon that manages communication with the hypervisors and VMs. It retrieves its orders from the message queue and performs VM create and delete tasks using the hypervisor's API. It also updates the status of its tasks in the central database.
For the sake of completeness, some daemons cover functionality originally assigned to Nova that is slowly moving to other projects. The Network Manager administers IP forwarding, network bridges, and virtual LANs. It is a worker daemon picking network-related tasks from message queue. These functions are now also covered by OpenStack Neutron which can be selected in its place.
The Volume Manager handles attach and detach of persistent block storage volumes to VMs (similar to Amazon Elastic Block Store). This functionality has been extracted to OpenStack Cinder. It's an iSCSI solution that uses Logical Volume Manager.
Setting it up
The actual installation instructions vary greatly between distributions and OpenStack releases. Generally, they are available as part of the distribution. Nonetheless, you must complete the same basic tasks. This section gives you an idea of what's involved.
OpenStack relies on a 64-bit x86 architecture; otherwise, it is designed for commodity hardware, so the minimal system requirements are modest. It is possible to run the entire suite of OpenStack projects on a single system with 8GB of RAM, but for any serious work, the official recommendation is for the cloud controller node that runs the network, volume, API, scheduler, and image services to have at least 12GB of RAM, two 2TB disks, and a network adapter. Compute nodes (running the virtual instances) will vary much more in terms of their load, but a good starting point for a simple system is a quad-core CPU, 32GB of RAM, and 2Gbit network adapters.
The installation instructions depend on the distribution and, more
specifically, on the package-management utility you select. In many cases,
it's necessary to declare the repository. So, for example, in the case of
Zypper, you announce to
You then install the required Nova packages on both the controller and compute nodes. The package-management utility should automatically install any dependencies.
For the purpose of illustration, I have provided the primary commands for Ubuntu, Red Hat (Red Hat Enterprise Linux®, CentOS, Fedora), and openSUSE:
- Ubuntu: On the controller node, run:
On the compute node, run:
sudo apt-get install nova-compute nova-network sudo apt-get install glance
- Red Hat: Run the following command:
sudo yum install openstack-nova sudo yum install openstack-glance
- openSUSE: Run the following command:
sudo zypper install openstack-nova openstack-glance
Nova configuration involves several files, but the most important is nova.conf, which is installed in /etc/nova. A default set of options works fine for a standard installation, but you will need to edit the configuration for any special requirements. You can examine the nova.conf file format here and see a list of nova.conf configuration options here.
To get an idea of how OpenStack Compute might be used in practice, imagine that you have a base image that you would like to launch in OpenStack. After configuring the system and making some personalized customizations, you may want to take a snapshot of the running instance so that you can accelerate the provisioning process to execute the same task again. After you have completed the project, you might want to stop the instance. You may even want to delete the image.
- Log in to the OpenStack Dashboard as a user with a Member role.
- In the navigation pane, beneath Manage Compute, click Images & Snapshots, then click Create Image. The Create An Image window opens (Figure 2) in which you can configure the settings that define your instance.
- Enter a name and location for the image that you have previously
created or downloaded. You need to specify the format of the image
file, but there is no need to indicate the minimum disk size or RAM
unless you want to supply them.
Figure 2. Create an image
- After creating the image, beneath Manage Compute, click
Instances, and then click Launch
Figure 3. Launch an instance
- A window confirms your configuration and allows you to specify the required Flavor, or basic hardware configuration. Click Launch; the instance should be up and running.
- Consider taking a snapshot. Again, beneath Manage Compute, click
Instances, and then click Create
Snapshot in the row associated with the instance of
Figure 4. Instances
Other tasks you can execute from this window include editing, pausing, suspending, and rebooting the instance. It is also the place to go to terminate the instance after you have finished using it.
- To delete the image and any snapshots, go back to the Images & Snapshots menu where you have the option to delete the objects you no longer need.
Figure 5. Images and snapshots
That's all it takes to get started with the OpenStack Compute functionality. The main point to remember as you plan and deploy your compute workloads using OpenStack is that it is not a virtualization platform but a management abstraction that allows you to orchestrate workflows across multiple hypervisors using a variety of pluggable technologies. OpenStack merely simplifies the management and integration of these components.
- Read more OpenStack articles in this series.
- Check out the OpenStack documentation.
- Read the official recommendations for the OpenStack cloud controller node.
- Keep up with OpenStack on Twitter.
- Learn more about the AQMP.
- Read about IBM's open cloud architecture.
- Learn more about the Kombu library.
- Explore developerWorks' Cloud computing zone.
- Follow developerWorks on Twitter.
- Watch developerWorks demos ranging from product installation and setup demos for beginners to advanced functionality for experienced developers.
- Get started with IBM SmartCloud Application Services by watching the demo.
Get products and technologies
- Try OpenStack for yourself.
- Download SQLAlchemy.
- Check out Apache Qpid.
- Check out ZeroMQ.
- Download RabbitMQ.
- Evaluate IBM products in the way that suits you best: Download a product trial or try a product online.
- Get involved in the developerWorks Community. Connect with other developerWorks users while you explore developer-driven blogs, forums, groups, and wikis.
Dig deeper into Cloud computing on developerWorks
Get samples, articles, product docs, and community resources to help build, deploy, and manage your cloud apps.
Complete cloud software, infrastructure, and platform knowledge.
Software development in the cloud. Register today to create a project.
Deploy public cloud instances in as few as 5 minutes. Try the SoftLayer public cloud instance for one month.