diff --git a/doc/source/install-guide/overview-host-layout.rst b/doc/source/install-guide/overview-host-layout.rst deleted file mode 100644 index c6fbee2ead..0000000000 --- a/doc/source/install-guide/overview-host-layout.rst +++ /dev/null @@ -1,103 +0,0 @@ -.. _host-layout: - -=========== -Host layout -=========== - -* Infrastructure: - - * Galera - * RabbitMQ - * Memcached - * Repository - -* (Optional) Load Balancer hosts: - - * HAProxy - - .. note:: - - Use at least one load balancer to manage the traffic among - the target hosts. You can use any type of load balancer such as a hardware - appliance or software like `HAProxy `_. We recommend - using physical load balancers for a production environment. - -* Log aggregation host: - - * Rsyslog - -* OpenStack API services: - - * Identity (keystone) - * Image service (glance) - * Compute management (nova) - * Networking (neutron) - * Orchestration (heat) - * Dashboard (horizon) - -* Compute hosts: - - * Compute virtualization (``nova-compute``) - * Networking agent (``neutron-agent``) - -* (Optional) Storage hosts: - - * Block Storage scheduler (``cinder-scheduler``) - * Block Storage volumes (``cinder-volume``) - - .. note:: - - If the optional Block Storage (cinder) service is used, we recommend - using an additional host. Block Storage hosts require an LVM volume group named - ``cinder-volumes``. See `the section called "Installation - requirements" `_ and `the section - called "Configuring LVM" `_ - for more information. - -Test environment -~~~~~~~~~~~~~~~~ - -The test environment is a minimal set of components to deploy a working -OpenStack-Ansible environment. It consists of three hosts in total: - -* One control plane and infrastructure host -* One compute host -* One storage host - -It contains the following features: - -* One Network Interface Card (NIC) for each target host -* No log aggregation host -* File-backed storage for glance and nova -* LVM-backed cinder - -.. image:: figures/arch-layout-test.png - :width: 100% - :alt: Test environment host layout - -Production environment -~~~~~~~~~~~~~~~~~~~~~~ - -The production environment is a more complicated set of components to deploy -a working OpenStack-Ansible environment. The layout for a production -environment involves seven target hosts in total: - -* Three control plane and infrastructure hosts -* Two compute hosts -* One storage host -* One log aggregation host - -It contains the following features: - -* Bonded NICs -* NFS/Ceph-backed storage for nova, glance, and cinder - -All hosts need at least one networking -interface, but we recommend multiple bonded interfaces. - -For more information on physical, logical, and virtual network -interfaces within hosts see :ref:`network-architecture`. - -.. image:: figures/arch-layout-production.png - :width: 100% - :alt: Production environment host layout diff --git a/doc/source/install-guide/overview-service-architecture.rst b/doc/source/install-guide/overview-service-architecture.rst new file mode 100644 index 0000000000..70a746e3e5 --- /dev/null +++ b/doc/source/install-guide/overview-service-architecture.rst @@ -0,0 +1,123 @@ +.. _service-architecture: + +==================== +Service architecture +==================== + +Introduction +~~~~~~~~~~~~ +OpenStack-Ansible has a flexible deployment configuration model that is +capable of deploying: + +* All services in separate LXC machine containers, or on designated hosts + without using LXC containers. +* All network traffic on a single network interface, or on many network + interfaces. + +This flexibility enables deployers to choose how to deploy OpenStack in a +way that makes the most sense for the specific use-case. + +The following sections describe the services deployed by OpenStack-Ansible. + +Infrastructure services +~~~~~~~~~~~~~~~~~~~~~~~ + +The following infrastructure components are deployed by OpenStack-Ansible: + +* MariaDB/Galera + + All OpenStack services require an underlying database. MariaDB/Galera + implements a multi-master database configuration which simplifies the + ability to use it as a highly available database with a simple failover + model. + +* RabbitMQ + + OpenStack services make use of RabbitMQ for Remote Procedure Calls (RPC). + OpenStack-Ansible deploys RabbitMQ in a clustered configuration with all + queues mirrored between the cluster nodes. As Telemetry (ceilometer) message + queue traffic is quite heavy, for large environments we recommended + separating Telemetry notifications to a separate RabbitMQ cluster. + +* MemcacheD + + OpenStack services use MemcacheD for in-memory caching, speeding up + transactions. For example, the OpenStack Identity service (keystone) uses + MemcacheD for caching authentication tokens. This is to ensure 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 which are used for + the installation of the environment. The artifacts include: + + * A git repository containing a copy of the source code which 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. OpenStack-Ansible + provides a deployment of `HAProxy`_, but we recommend using a physical + load balancing appliance for production deployments. + +* Utility Container + + The utility container is prepared with the appropriate credentials and + clients in order to administer the OpenStack environment. It is set to + automatically use the internal service endpoints. + +* Log Aggregation Host + + A rsyslog service is optionally setup to receive rsyslog traffic from all + hosts and containers. You can replace this 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 as + the deployment will be significantly faster. If this option is not used, + OpenStack-Ansible will fall back to modifying ``/etc/hosts`` entries for + all hosts in the environment. + +.. _HAProxy: http://www.haproxy.org/ +.. _Unbound DNS: https://www.unbound.net/ + +OpenStack services +~~~~~~~~~~~~~~~~~~ + +OpenStack-Ansible is able to deploy the following OpenStack services: + +* Bare Metal (`ironic`_) +* Block Storage (`cinder`_) +* Compute (`nova`_) +* Container Infrastructure Management (`magnum`_) +* Dashboard (`horizon`_) +* Data Processing (`sahara`_) +* Identity (`keystone`_) +* Image (`glance`_) +* Networking (`neutron`_) +* Object Storage (`swift`_) +* Orchestration (`heat`_) +* Telemetry (`aodh`_, `ceilometer`_, `gnocchi`_) + +.. _ironic: http://docs.openstack.org/developer/ironic +.. _cinder: http://docs.openstack.org/developer/cinder +.. _nova: http://docs.openstack.org/developer/nova +.. _magnum: http://docs.openstack.org/developer/magnum +.. _horizon: http://docs.openstack.org/developer/horizon +.. _sahara: http://docs.openstack.org/developer/sahara +.. _keystone: http://docs.openstack.org/developer/keystone +.. _glance: http://docs.openstack.org/developer/glance +.. _neutron: http://docs.openstack.org/developer/neutron +.. _swift: http://docs.openstack.org/developer/swift +.. _heat: http://docs.openstack.org/developer/heat +.. _aodh: http://docs.openstack.org/developer/aodh +.. _ceilometer: http://docs.openstack.org/developer/ceilometer +.. _gnocchi: http://docs.openstack.org/developer/gnocchi + diff --git a/doc/source/install-guide/overview.rst b/doc/source/install-guide/overview.rst index 4fa42dc16b..131e6a5fb1 100644 --- a/doc/source/install-guide/overview.rst +++ b/doc/source/install-guide/overview.rst @@ -6,6 +6,6 @@ Overview overview-osa.rst overview-requirements.rst - overview-host-layout + overview-service-architecture.rst overview-network-arch.rst overview-storage-arch.rst