Professional Documents
Culture Documents
OPENSTACK
(Episode 06)
Controller Nodes
Presentation By:
Roozbeh Shafiee
Summer 2015
IRAN OpenStack Users Group
OpenStack Controller Nodes
Agenda:
Managing Services By Controller
Iran OpenStack Community
Database:
OpenStack Compute uses a SQL database to store and retrieve stateful
Information. MySQL is the popular database choice in the OpenStack community.
Loss of the database leads to errors. As a result, we recommend that you cluster
Your database to make it failure tolerant. Configuring and maintaining a database
cluster is done outside OpenStack and is determined by the database software
you choose to use in your cloud environment. MySQL/Galera is a popular option
for MySQL-based databases.
Message Queue:
Most OpenStack services communicate with each other using the message queue.
In general, if the message queue fails or becomes inaccessible, the cluster grinds
to a halt and ends up in a read-only state, with information stuck at the point
where the last message was sent.
Message Queue:
RabbitMQ has native clustering support, there have been reports of issues
when running it at a large scale.
Qpid is the messaging system of choice for Red Hat and its derivatives.
Qpid does not have native clustering capabilities and requires a supplemental
service, such as Pacemaker or Corsync.
0mq does not offer stateful queues.
Accordingly, we recommend that you cluster the message queue. Be aware that
clustered message queues can be a pain point for many OpenStack deployments.
Conductor Services:
In the previous version of OpenStack, all nova-compute services required direct
access to the database hosted on the cloud controller. Because:
Security
performance
Conductor Services:
The conductor service resolves both of these issues by acting as a proxy for the
nova-compute service. Now, instead of nova-compute directly accessing the
database, it contacts the nova-conductor service, and nova-conductor accesses
the database on nova-compute s behalf. Since nova-compute no longer has direct
access to the database, the security issue is resolved. Additionally, nova-conductor
is a nonblockingservice, so requests from all compute nodes are fulfilled in parallel.
For example, the EC2 API refers to instances using IDs that contain hexadecimal,
whereas the OpenStack API uses names and digits. Similarly, the EC2 API tends to
rely on DNS aliases for contacting virtual machines, as opposed to OpenStack,
which typically lists IP addresses.
As with databases and message queues, having more than one API server is a good
thing. Traditional HTTP load-balancing techniques can be used to achieve a highly
available nova-api service.
Scheduling:
The scheduling services are responsible for determining the compute or storage
node where a virtual machine or block storage volume should be created.
The scheduling services receive creation requests for these resources from the
message queue and then begin the process of determining the appropriate node
where the resource should reside.
This process is done by applying a series of user-configurable filters against the
available collection of nodes.
Scheduling:
There are currently two schedulers:
nova-scheduler (for virtual machines)
cinder-scheduler (for block storage volumes)
You should consider running multiple instances of each scheduler. The schedulers
all listen to the shared message queue, so no special load balancing is required.
Images:
The OpenStack Image Service consists of two parts:
Glance-api
Glance-registry
The former is responsible for the delivery of images; the compute node
uses it to download images from the backend.
The latter maintains the metadata information associated with virtual
machine images and requires a database.
Images:
The glance-api part is an abstraction layer that allows a choice of backend.
Currently, it supports:
OpenStack Object Storage - Allows you to store images as objects.
File system - Uses any traditional file system to store the images as files.
S3 - Allows you to fetch images from Amazon S3.
HTTP - Allows you to fetch images from a web server.
Images:
If you have an OpenStack Object Storage service, we recommend using this as a
scalable place to store your images. You can also use a file system with sufficient
performance or Amazon S3 unless you do not need the ability to upload new
Images through OpenStack.
Dashboard:
The OpenStack dashboard (horizon) provides a web-based user interface to the
various OpenStack components. The dashboard includes:
End-user area (for users to manage their virtual infrastructure)
Admin area (for cloud operators to manage the OpenStack environment).
For example, a cloud administrator might be able to list all instances in the cloud,
whereas a user can see only those in his current group. Resources quotas, such as
The number of cores that can be used, disk space, and so on, are associated with
a project.