Mastering OpenStack - Episode 06 - Controller Nodes

Presentation By:
Roozbeh Shafiee
Summer 2015
IRAN OpenStack Users Group
MASTERING
OPENSTACK
(Episode 06)
Controller Nodes

IRAN Community| OpenStack.ir
Agenda:
●
Managing Services By Controller
●
Iran OpenStack Community
OpenStack Controller Nodes

Managing Services By Controller:
●
Databases
●
Message queue services
●
Conductor services
●
Authentication and authorization for identity management
●
Image-management services
●
Scheduling services
●
User dashboard
●
API endpoints

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.
Popular choices for a message-queue service are:
●
RabbitMQ
●
Qpid
●
0mq
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
With regard to security, if a compute node is compromised, the attacker inherently
has access to the database.
With regard to performance, nova-compute calls to the database are
single-threaded and blocking. This creates a performance bottleneck because
database requests are fulfilled serially ratherthan in parallel.

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 data base, the security issue is resolved. Additionally, nova-conductor‐
is a nonblockingservice, so requests from all compute nodes are fulfilled in parallel.
“If you are using nova-network and multi-host networking in your cloud
environment, nova-compute still requires direct access to the database.”

Application Programming Interface (API):
You must choose whether you want to support the Amazon EC2 compatibility APIs,
or just the OpenStack APIs. One issue you might encounter when running both
APIs is an inconsistent experience when referring to images and instances.
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.

Application Programming Interface (API):
If OpenStack is not set up in the right way, it is simple to have scenarios in which
users are unable to contact their instances due to having only an incorrect DNS
alias. Despite this, EC2 compatibility can assist users migrating to your cloud.
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)
Both schedulers are able to:
●
Scale horizontally (for high-availability purposes)
●
Very large or high-schedule-frequency installations
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).
The dashboard is implemented as a Python web application that normally runs in
Apache httpd . Therefore, you may treat it the same as any other web application,
provided it can reach the API servers (including their admin endpoints) over the
network.

Authentication and Authorization:
The concepts supporting OpenStack’s authentication and authorization are
Derived from well-understood and widely used systems of a similar nature. Users
have credentials they can use to authenticate, and they can be a member of one
or more groups (known as projects or tenants, interchangeably).
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.

Authentication and Authorization:
The OpenStack Identity Service (keystone) is the point that provides the
authentication decisions and user attribute information, which is then used by the
other OpenStack services to perform authorization.
The Identity Service supports different plug-ins for authentication decisions and
identity storage. Examples of these plug-ins include:
• In-memory key-value Store (a simplified internal storage structure)
• SQL database (such as MySQL or PostgreSQL)
• PAM (Pluggable Authentication Module)
• LDAP (such as OpenLDAP or Microsoft’s Active Directory)

Iran OpenStack Community

Stay in Touch and Join Us:
●
Home Page: OpenStack.ir
●
Meetup Page: Meetup.com/Iran-OpenStack
●
Mailing List: OpenStack-ir@Lists.OpenStack.org
●
Twitter: @OpenStackIR , #OpenStackIRAN
●
IRC Channel on FreeNode: #OpenStack-ir

Roozbeh Shafiee
Iran OpenStack Community Manager
Roozbeh@OpenStack.ir
OpenStack.ir
Thank You
We need to work together to build a better community

Mastering OpenStack - Episode 06 - Controller Nodes

More Related Content

What's hot

Viewers also liked

Similar to Mastering OpenStack - Episode 06 - Controller Nodes

Recently uploaded

Mastering OpenStack - Episode 06 - Controller Nodes