openstack-ansible/doc/source/reference/architecture/service-arch.rst
Jean-Philippe Evrard 8bfc32399e [Docs] Simplify overview page
This modifies the overview section to be one page instead of
4 long sections. We just refer to the architecture reference
for details about the architecture.

Change-Id: I1f5da9acaa677b2cd752cda30c33eba846a96eb4
2018-03-20 11:44:57 +00:00

94 lines
3.5 KiB
ReStructuredText

Service architecture
====================
Introduction
~~~~~~~~~~~~
OpenStack-Ansible has a flexible deployment configuration model that
can deploy all services in separate machine containers or on designated hosts
without using containers, and all network traffic either on a single
network interface or on many network interfaces.
This flexibility enables deployers to choose how to deploy OpenStack in the
appropriate way for the specific use case.
The following sections describe the services that OpenStack-Ansible deploys.
Infrastructure services
~~~~~~~~~~~~~~~~~~~~~~~
OpenStack-Ansible deploys the following infrastructure components:
* MariaDB with Galera
All OpenStack services require an underlying database. MariaDB with Galera
implements a multimaster database configuration, which simplifies its use
as a highly available database with a simple failover model.
* RabbitMQ
OpenStack services use RabbitMQ for Advanced Message Queuing Protocol (AMQP).
OSA deploys RabbitMQ in a clustered configuration with all
queues mirrored between the cluster nodes. Because Telemetry (ceilometer)
message queue traffic is quite heavy, for large environments we recommend
separating Telemetry notifications into a separate RabbitMQ cluster.
* Memcached
OpenStack services use Memcached for in-memory caching, which accelerates
transactions. For example, the OpenStack Identity service (keystone) uses
Memcached for caching authentication tokens, which ensures that token
validation does not have to complete a disk or database transaction every
time the service is asked to validate a token.
* Repository
The repository holds the reference set of artifacts that are used for
the installation of the environment. The artifacts include:
* A Git repository that contains a copy of the source code that is used
to prepare the packages for all OpenStack services
* Python wheels for all services that are deployed in the environment
* An apt/yum proxy cache that is used to cache distribution packages
installed in the environment
* Load balancer
At least one load balancer is required for a deployment. OSA
provides a deployment of `HAProxy`_, but we recommend using a physical
load balancing appliance for production environments.
* Utility container
If a tool or object does not require a dedicated container, or if it is
impractical to create a new container for a single tool or object, it is
installed in the utility container. The utility container is also used when
tools cannot be installed directly on a host. The utility container is
prepared with the appropriate credentials and clients to administer the
OpenStack environment. It is set to automatically use the internal service
endpoints.
* Log aggregation host
A rsyslog service is optionally set up to receive rsyslog traffic from all
hosts and containers. You can replace rsyslog with any alternative log
receiver.
* Unbound DNS container
Containers running an `Unbound DNS`_ caching service can optionally be
deployed to cache DNS lookups and to handle internal DNS name resolution.
We recommend using this service for large-scale production environments
because the deployment will be significantly faster. If this service is not
used, OSA modifies ``/etc/hosts`` entries for all hosts in the environment.
.. _HAProxy: http://www.haproxy.org/
.. _Unbound DNS: https://www.unbound.net/
OpenStack services
~~~~~~~~~~~~~~~~~~
OSA is able to deploy a multitude of services.
Have a look at the role maturity matrix to know the status of the
service you want to deploy.