openstack/openstack-ansible
Code Issues Proposed changes

Merge "[docs] Revise overview chapter in OSA install guide"

Browse Source
This commit is contained in:
Jenkins 2016-07-05 09:06:18 +00:00 committed by Gerrit Code Review
commit cf881d5293
25 changed files with 339 additions and 316 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

41
doc/source/developer-docs/ops-lxc-commands.rst Normal file
View File

@ -0,0 +1,41 @@
========================
Linux Container commands
========================
The following are some useful commands to manage LXC:
- List containers and summary information such as operational state and
network configuration:
.. code-block:: shell-session
# lxc-ls --fancy
- Show container details including operational state, resource
utilization, and ``veth`` pairs:
.. code-block:: shell-session
# lxc-info --name container_name
- Start a container:
.. code-block:: shell-session
# lxc-start --name container_name
- Attach to a container:
.. code-block:: shell-session
# lxc-attach --name container_name
- Stop a container:
.. code-block:: shell-session
# lxc-stop --name container_name
--------------
.. include:: navigation.txt

1
doc/source/developer-docs/ops.rst
View File

@ -7,6 +7,7 @@ installed environments.
.. toctree::
ops-lxc-commands.rst
ops-addcomputehost.rst
ops-galera.rst
ops-logging.rst

14
doc/source/install-guide-revised-draft/app.rst Normal file
View File

@ -0,0 +1,14 @@
==========
Appendices
==========
`Home <index.html>`_ OpenStack-Ansible Installation Guide
.. toctree::
:maxdepth: 2
app-configfiles.rst
app-resources.rst
app-plumgrid.rst
app-nuage.rst
app-custom-layouts.rst

2
doc/source/install-guide-revised-draft/configure.rst
View File

@ -4,6 +4,8 @@ Chapter 4. Deployment configuration
-----------------------------------
.. toctree::
:maxdepth: 2
configure-initial.rst
configure-networking.rst

BIN
doc/source/install-guide-revised-draft/figures/arch-layout-production.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 286 KiB

3
doc/source/install-guide-revised-draft/figures/arch-layout-production.svg Normal file
View File

File diff suppressed because one or more lines are too long
Side by Side

After

Width:  |  Height:  |  Size: 55 KiB

BIN
doc/source/install-guide-revised-draft/figures/arch-layout-test.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 214 KiB

3
doc/source/install-guide-revised-draft/figures/arch-layout-test.svg Normal file
View File

File diff suppressed because one or more lines are too long
Side by Side

After

Width:  |  Height:  |  Size: 40 KiB

BIN
doc/source/install-guide-revised-draft/figures/arch-layout.graffle Normal file
View File

Binary file not shown.

BIN
doc/source/install-guide-revised-draft/figures/environment-overview.png
View File

Binary file not shown.
Side by Side

Before

Width:  |  Height:  |  Size: 71 KiB

50
doc/source/install-guide-revised-draft/index.rst
View File

@ -7,55 +7,15 @@ and is currently under development.
`Home <index.html>`_ OpenStack-Ansible Installation Guide
Overview
^^^^^^^^
Table of Contents
^^^^^^^^^^^^^^^^^
.. toctree::
:maxdepth: 2
overview.rst
Deployment host
^^^^^^^^^^^^^^^
.. toctree::
deploymenthost.rst
Target hosts
^^^^^^^^^^^^
.. toctree::
targethosts.rst
Configuration
^^^^^^^^^^^^^
.. toctree::
configure.rst
Installation
^^^^^^^^^^^^
.. toctree::
install-foundation.rst
install-infrastructure.rst
install-openstack.rst
Appendices
^^^^^^^^^^
.. toctree::
app-configfiles.rst
app-resources.rst
app-plumgrid.rst
app-nuage.rst
app-custom-layouts.rst
install.rst
app.rst

6
doc/source/install-guide-revised-draft/install-foundation.rst
View File

@ -1,8 +1,8 @@
`Home <index.html>`_ OpenStack-Ansible Installation Guide
===============================
Chapter 5. Foundation playbooks
===============================
====================
Foundation playbooks
====================
**Figure 5.1. Installation work flow**

6
doc/source/install-guide-revised-draft/install-infrastructure.rst
View File

@ -1,8 +1,8 @@
`Home <index.html>`_ OpenStack-Ansible Installation Guide
===================================
Chapter 6. Infrastructure playbooks
===================================
========================
Infrastructure playbooks
========================
**Figure 6.1. Installation workflow**

6
doc/source/install-guide-revised-draft/install-openstack.rst
View File

@ -1,8 +1,8 @@
`Home <index.html>`_ OpenStack-Ansible Installation Guide
==============================
Chapter 7. OpenStack playbooks
==============================
===================
OpenStack playbooks
===================
**Figure 7.1. Installation work flow**

11
doc/source/install-guide-revised-draft/install.rst Normal file
View File

@ -0,0 +1,11 @@
============
Installation
============
`Home <index.html>`_ OpenStack-Ansible Installation Guide
.. toctree::
:maxdepth: 2
install-foundation.rst
install-infrastructure.rst
install-openstack.rst

106
doc/source/install-guide-revised-draft/overview-host-layout.rst Normal file
View File

@ -0,0 +1,106 @@
`Home <index.html>`_ OpenStack-Ansible Installation Guide
.. _host-layout:
===========
Host layout
===========
The hosts are called target hosts because Ansible deploys the OSA
environment within these hosts. We recommend a
deployment host from which Ansible orchestrates the deployment
process. One of the target hosts can function as the deployment host.
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" <overview-requirements.html>`_ and `the section
called "Configuring LVM" <targethosts-configlvm.html>`_ for more information.
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 <http://www.haproxy.org/>`_. We recommend
using physical load balancers for a production environment.
A Control Plane and Infrastucture target host contains the following
services:
- Infrastructure:
- Galera
- RabbitMQ
- Memcached
- Logging
- Repository
- OpenStack:
- Identity (keystone)
- Image service (glance)
- Compute management (nova)
- Networking (neutron)
- Orchestration (heat)
- Dashboard (horizon)
Log aggregation hosts contain the following services:
- Rsyslog
Compute target hosts contain the following services:
- Compute virtualization
- Logging
(Optional) Storage target hosts contain the following services:
- Block Storage scheduler
- Block Storage volumes
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 and one storage host.
It also has the following features:
- One Network Interface Card (NIC) for each target host
- No log aggregation target 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 layout for a production environment involves seven target
hosts in total: three control plane and infrastructure hosts, two compute hosts,
one storage host and one log aggregation host. It also has the following features:
- Bonded NICs
- NFS/Ceph-backed storage for nova, glance, and cinder
All hosts will 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

83
doc/source/install-guide-revised-draft/overview-hostlayout.rst
View File

@ -1,83 +0,0 @@
`Home <index.html>`_ OpenStack-Ansible Installation Guide
===========
Host layout
===========
We recommend a layout that contains a minimum of five hosts (or servers):
- Three control plane infrastructure hosts
- One logging infrastructure host
- One compute host
If using the optional Block Storage (cinder) service, we recommend
the use of a sixth host. Block Storage hosts require an LVM volume group named
``cinder-volumes``. See `the section called "Installation
requirements" <overview-requirements.html>`_ and `the section
called "Configuring LVM" <targethosts-configlvm.html>`_ for more information.
The hosts are called target hosts because Ansible deploys the OSA
environment within these hosts. We recommend a
deployment host from which Ansible orchestrates the deployment
process. One of the target hosts can function as the deployment host.
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 HAProxy. We recommend using physical load balancers for
production environments.
Infrastructure Control Plane target hosts contain the following
services:
- Infrastructure:
- Galera
- RabbitMQ
- Memcached
- Logging
- Repository
- OpenStack:
- Identity (keystone)
- Image service (glance)
- Compute management (nova)
- Networking (neutron)
- Orchestration (heat)
- Dashboard (horizon)
Infrastructure Logging target hosts contain the following services:
- Rsyslog
Compute target hosts contain the following services:
- Compute virtualization
- Logging
(Optional) Storage target hosts contain the following services:
- Block Storage scheduler
- Block Storage volumes
**Figure 1.1. Host Layout Overview**
.. image:: figures/environment-overview.png
--------------
.. include:: navigation.txt

101
doc/source/install-guide-revised-draft/targethosts-network.rst → doc/source/install-guide-revised-draft/overview-network-arch.rst
View File

@ -1,17 +1,17 @@
`Home <index.html>`_ OpenStack-Ansible Installation Guide
=====================
Designing the network
=====================
.. _network-architecture:
This section describes the recommended network architecture.
Some components are mandatory, such as the bridges described below. We
recommend other components such as a bonded network interface but this
is not a requirement.
====================
Network architecture
====================
For a production environment, some components are mandatory, such as bridges
described below. We recommend other components such as a bonded network interface.
.. important::
Follow the reference design as closely as possible for production deployments.
Follow the reference design as closely as possible.
Although Ansible automates most deployment operations, networking on
target hosts requires manual configuration as it varies
@ -23,10 +23,10 @@ particular environment.
Bonded network interfaces
~~~~~~~~~~~~~~~~~~~~~~~~~
The reference architecture includes bonded network interfaces, which
use multiple physical network interfaces for better redundancy and throughput.
Avoid using two ports on the same multi-port network card for the same bonded
interface since a network card failure affects both physical network
The reference architecture for a production environment includes bonded network
interfaces, which use multiple physical network interfaces for better redundancy
and throughput. Avoid using two ports on the same multi-port network card for the
same bonded interface since a network card failure affects both physical network
interfaces used by the bond.
The ``bond0`` interface carries traffic from the containers
@ -71,7 +71,7 @@ connected to the host's bridges and to the host's physical network interfaces:
.. image:: figures/networkcomponents.png
Target hosts can contain the following network bridges:
Target hosts contain the following network bridges:
- LXC internal ``lxcbr0``:
@ -167,6 +167,81 @@ The following image shows how virtual machines connect to the ``br-vlan`` and
.. image:: figures/networking-compute.png
Network ranges
~~~~~~~~~~~~~~
.. TODO Edit this for production and test environment?
In this guide, the following IP addresses and hostnames are
used when installing OpenStack-Ansible.
+-----------------------+-----------------+
| Network | IP Range |
+=======================+=================+
| Management Network | 172.29.236.0/22 |
+-----------------------+-----------------+
| Tunnel (VXLAN) Network| 172.29.240.0/22 |
+-----------------------+-----------------+
| Storage Network | 172.29.244.0/22 |
+-----------------------+-----------------+
IP assignments
~~~~~~~~~~~~~~
+------------------+----------------+-------------------+----------------+
| Host name | Management IP | Tunnel (VxLAN) IP | Storage IP |
+==================+================+===================+================+
| infra1 | 172.29.236.101 | 172.29.240.101 | 172.29.244.101 |
+------------------+----------------+-------------------+----------------+
| infra2 | 172.29.236.102 | 172.29.240.102 | 172.29.244.102 |
+------------------+----------------+-------------------+----------------+
| infra3 | 172.29.236.103 | 172.29.240.103 | 172.29.244.103 |
+------------------+----------------+-------------------+----------------+
| | | | |
+------------------+----------------+-------------------+----------------+
| net1 | 172.29.236.111 | 172.29.240.111 | |
+------------------+----------------+-------------------+----------------+
| net2 | 172.29.236.112 | 172.29.240.112 | |
+------------------+----------------+-------------------+----------------+
| net3 | 172.29.236.113 | 172.29.240.113 | |
+------------------+----------------+-------------------+----------------+
| | | | |
+------------------+----------------+-------------------+----------------+
| compute1 | 172.29.236.121 | 172.29.240.121 | 172.29.244.121 |
+------------------+----------------+-------------------+----------------+
| compute2 | 172.29.236.122 | 172.29.240.122 | 172.29.244.122 |
+------------------+----------------+-------------------+----------------+
| compute3 | 172.29.236.123 | 172.29.240.123 | 172.29.244.123 |
+------------------+----------------+-------------------+----------------+
| | | | |
+------------------+----------------+-------------------+----------------+
| lvm-storage1 | 172.29.236.131 | | 172.29.244.131 |
+------------------+----------------+-------------------+----------------+
| | | | |
+------------------+----------------+-------------------+----------------+
| nfs-storage1 | 172.29.236.141 | | 172.29.244.141 |
+------------------+----------------+-------------------+----------------+
| | | | |
+------------------+----------------+-------------------+----------------+
| ceph-mon1 | 172.29.236.151 | | 172.29.244.151 |
+------------------+----------------+-------------------+----------------+
| ceph-mon2 | 172.29.236.152 | | 172.29.244.152 |
+------------------+----------------+-------------------+----------------+
| ceph-mon3 | 172.29.236.153 | | 172.29.244.153 |
+------------------+----------------+-------------------+----------------+
| | | | |
+------------------+----------------+-------------------+----------------+
| swift1 | 172.29.236.161 | | 172.29.244.161 |
+------------------+----------------+-------------------+----------------+
| swift2 | 172.29.236.162 | | 172.29.244.162 |
+------------------+----------------+-------------------+----------------+
| swift3 | 172.29.236.163 | | 172.29.244.163 |
+------------------+----------------+-------------------+----------------+
| | | | |
+------------------+----------------+-------------------+----------------+
| log1 | 172.29.236.171 | | |
+------------------+----------------+-------------------+----------------+
--------------

67
doc/source/install-guide-revised-draft/overview-osa.rst
View File

@ -4,13 +4,14 @@
About OpenStack-Ansible
=======================
OpenStack-Ansible (OSA) uses the Ansible IT automation framework to
deploy an OpenStack environment on Ubuntu Linux. OpenStack components are
installed into Linux Containers (LXC) for isolation and ease of
OpenStack-Ansible (OSA) uses the Ansible IT automation engine to
deploy an OpenStack environment on Ubuntu Linux. OpenStack components may
be installed into Linux Containers (LXC) for isolation and ease of
maintenance.
This documentation is intended for deployers of the OpenStack-Ansible
deployment system who are interested in installing an OpenStack environment.
This documentation is intended for deployers, and walks through an
OpenStack-Ansible installation for a test environment, and a production
environment.
Third-party trademarks and tradenames appearing in this document are the
property of their respective owners. Such third-party trademarks have
@ -22,9 +23,7 @@ or endorsement or sponsorship of us by, these other companies.
Ansible
~~~~~~~
OpenStack-Ansible Deployment uses a combination of Ansible and
Linux Containers (LXC) to install and manage OpenStack. Ansible
provides an automation platform to simplify system and application
Ansible provides an automation platform to simplify system and application
deployment. Ansible manages systems using Secure Shell (SSH)
instead of unique protocols that require remote daemons or agents.
@ -33,22 +32,8 @@ For more information, see `Ansible - Intro to
Playbooks <http://docs.ansible.com/playbooks_intro.html>`_.
In this guide, we refer to the host running Ansible playbooks as
the deployment host and the hosts on which Ansible installs OSA as the
target hosts.
A recommended minimal layout for deployments involves five target
hosts in total: three infrastructure hosts, one compute host, and one
logging host. All hosts will need at least one networking interface, but
we recommend multiple bonded interfaces. More information on setting up
target hosts can be found in `the section called "Host layout"`_.
For more information on physical, logical, and virtual network
interfaces within hosts see `the section called "Host
networking"`_.
.. _the section called "Host layout": overview-hostlayout.html
.. _the section called "Host networking": overview-hostnetworking.html
the deployment host and the hosts on which Ansible installs OpenStack services
and infrastructure components as the target hosts.
Linux Containers (LXC)
~~~~~~~~~~~~~~~~~~~~~~
@ -75,40 +60,6 @@ following features:
- Built on a foundation of stable Linux technologies with an active
development and support community.
Useful commands:
- List containers and summary information such as operational state and
network configuration:
.. code-block:: shell-session
# lxc-ls --fancy
- Show container details including operational state, resource
utilization, and ``veth`` pairs:
.. code-block:: shell-session
# lxc-info --name container_name
- Start a container:
.. code-block:: shell-session
# lxc-start --name container_name
- Attach to a container:
.. code-block:: shell-session
# lxc-attach --name container_name
- Stop a container:
.. code-block:: shell-session
# lxc-stop --name container_name
--------------
.. include:: navigation.txt

14
doc/source/install-guide-revised-draft/overview-ref-arch.rst Normal file
View File

@ -0,0 +1,14 @@
`Home <index.html>`_ OpenStack-Ansible Installation Guide
======================
Reference Architecture
======================
.. TODO
- Describe OSA community reference architectures that can be installed
using OSA
- Add deployment view diagrams
--------------
.. include:: navigation.txt

28
doc/source/install-guide-revised-draft/overview-requirements.rst
View File

@ -12,13 +12,14 @@ Installation requirements
CPU requirements
~~~~~~~~~~~~~~~~
Compute hosts have multi-core processors that have `hardware-assisted
virtualization extensions`_ available. These extensions provide a significant
performance boost and improve security in virtualized environments.
* Compute hosts with multi-core processors that have `hardware-assisted
virtualization extensions`_ available. These extensions provide a
significant performance boost and improve security in virtualized
environments.
Infrastructure hosts have multi-core processors for best
performance. Some services, such as MySQL, greatly benefit from additional CPU
cores and other technologies, such as `Hyper-threading`_.
* Infrastructure hosts with multi-core processors for best
performance. Some services, such as MySQL, greatly benefit from additional
CPU cores and other technologies, such as `Hyper-threading`_.
.. _hardware-assisted virtualization extensions: https://en.wikipedia.org/wiki/Hardware-assisted_virtualization
.. _Hyper-threading: https://en.wikipedia.org/wiki/Hyper-threading
@ -36,21 +37,21 @@ Deployment hosts
Compute hosts
Disk space requirements vary depending on the total number of instances
running on each host and the amount of disk space allocated to each instance.
Compute hosts have at least 100GB of disk space available at an
absolute minimum. Consider disks that provide higher
throughput with lower latency, such as SSD drives in a RAID array.
Compute hosts need to have at least 100GB of disk space available. Consider
disks that provide higher throughput with lower latency, such as SSD drives
in a RAID array.
Storage hosts
Hosts running the Block Storage (cinder) service often consume the most disk
space in OpenStack environments. As with compute hosts,
choose disks that provide the highest I/O throughput with the lowest latency
for storage hosts. Storage hosts contain 1TB of disk space at a
for storage hosts. Storage hosts need to have 1TB of disk space at a
minimum.
Infrastructure hosts
The OpenStack control plane contains storage-intensive services, such as
the Image (glance) service as well as MariaDB. These control plane hosts
have 100GB of disk space available at a minimum.
need to have 100GB of disk space available at a minimum.
Logging hosts
An OpenStack-Ansible deployment generates a significant amount of logging.
@ -62,7 +63,6 @@ Logging hosts
environment. Reserve a minimum of 50GB of disk space for storing
logs on the logging hosts.
Hosts that provide Block Storage (cinder) volumes must have logical volume
manager (LVM) support. Ensure those hosts have a ``cinder-volumes`` volume group
that OpenStack-Ansible can configure for use with cinder.
@ -83,8 +83,8 @@ Network requirements
network interface. This works for small environments, but it can cause
problems when your environment grows.
For the best performance, reliability and scalability, deployers should
consider a network configuration that contains the following features:
For the best performance, reliability and scalability in a production environment,
deployers should consider a network configuration that contains the following features:
* Bonded network interfaces: Increases performance and/or reliability
(dependent on bonding architecture).

24
doc/source/install-guide-revised-draft/overview-security.rst
View File

@ -6,7 +6,7 @@ Security
The OpenStack-Ansible project provides several security features for
OpenStack deployments. This section of documentation covers those
features and how they can benefit deployers of various sizes.
features and how they can benefit deployers.
Security requirements always differ between deployers. If you require
additional security measures, refer to the official
@ -30,15 +30,14 @@ that each LXC container may take on a system. This is done within the
.. _security modules: https://en.wikipedia.org/wiki/Linux_Security_Modules
.. _mandatory access controls: https://en.wikipedia.org/wiki/Mandatory_access_control
.. _AppArmor: https://en.wikipedia.org/wiki/AppArmor
.. _lxc_hosts role: https://github.com/openstack/openstack-ansible/blob/master/playbooks/roles/lxc_hosts/templates/lxc-openstack.apparmor.j2
.. _lxc_hosts role: https://github.com/openstack/openstack-ansible-lxc_hosts
Encrypted communication
~~~~~~~~~~~~~~~~~~~~~~~
While in transit, data is encrypted between some OpenStack services in
OpenStack-Ansible deployments. Not all communication between all services is
encrypted. For more details on what traffic is encrypted, and how
to configure SSL certificates, refer to the documentation section titled
Data in transit is encrypted between some OpenStack services in
OpenStack-Ansible deployments. For more details on what traffic is encrypted,
and how to configure SSL certificates, see
`Securing services with SSL certificates`_.
.. _Securing services with SSL certificates: configure-sslcertificates.html
@ -46,7 +45,7 @@ to configure SSL certificates, refer to the documentation section titled
Host security hardening
~~~~~~~~~~~~~~~~~~~~~~~
Deployers can apply security hardening to OpenStack infrastructure and compute
Security hardening is applied by default to OpenStack infrastructure and compute
hosts using the ``openstack-ansible-security`` role. The purpose of the role is to
apply as many security configurations as possible without disrupting the
operation of an OpenStack deployment.
@ -58,7 +57,7 @@ Least privilege
~~~~~~~~~~~~~~~
The `principle of least privilege`_ is used throughout OpenStack-Ansible to
limit the damage that could be caused if an attacker gained access to a set of
limit the damage that could be caused if an attacker gains access to any
credentials.
OpenStack-Ansible configures unique username and password combinations for
@ -103,13 +102,12 @@ The resources within an OpenStack environment can be divided into two groups:
* MariaDB
* RabbitMQ
To manage instances, you are able to access certain public API endpoints, such as
the Nova or Neutron API. Configure firewalls to limit network access to
these services.
Configure firewalls to limit network access to all services that users must access
directly.
Other services, such as MariaDB and RabbitMQ, must be segmented away from
direct user access. You must configure a firewall to only allow
connectivity to these services within the OpenStack environment itself. This
direct user access. Configure a firewall to only allow connectivity to
these services within the OpenStack environment itself. This
reduces an attacker's ability to query or manipulate data in OpenStack's
critical database and queuing services, especially if one of these services has
a known vulnerability.

75
doc/source/install-guide-revised-draft/overview-workflow.rst
View File

@ -21,80 +21,5 @@ OpenStack-Ansible (OSA) installation.
=======
Network ranges
~~~~~~~~~~~~~~
For consistency, the following IP addresses and hostnames are
referred to in this installation workflow.
+-----------------------+-----------------+
| Network | IP Range |
+=======================+=================+
| Management Network | 172.29.236.0/22 |
+-----------------------+-----------------+
| Tunnel (VXLAN) Network| 172.29.240.0/22 |
+-----------------------+-----------------+
| Storage Network | 172.29.244.0/22 |
+-----------------------+-----------------+
IP assignments
~~~~~~~~~~~~~~
+------------------+----------------+-------------------+----------------+
| Host name | Management IP | Tunnel (VxLAN) IP | Storage IP |
+==================+================+===================+================+
| infra1 | 172.29.236.101 | 172.29.240.101 | 172.29.244.101 |
+------------------+----------------+-------------------+----------------+
| infra2 | 172.29.236.102 | 172.29.240.102 | 172.29.244.102 |
+------------------+----------------+-------------------+----------------+
| infra3 | 172.29.236.103 | 172.29.240.103 | 172.29.244.103 |
+------------------+----------------+-------------------+----------------+
| | | | |
+------------------+----------------+-------------------+----------------+
| net1 | 172.29.236.111 | 172.29.240.111 | |
+------------------+----------------+-------------------+----------------+
| net2 | 172.29.236.112 | 172.29.240.112 | |
+------------------+----------------+-------------------+----------------+
| net3 | 172.29.236.113 | 172.29.240.113 | |
+------------------+----------------+-------------------+----------------+
| | | | |
+------------------+----------------+-------------------+----------------+
| compute1 | 172.29.236.121 | 172.29.240.121 | 172.29.244.121 |
+------------------+----------------+-------------------+----------------+
| compute2 | 172.29.236.122 | 172.29.240.122 | 172.29.244.122 |
+------------------+----------------+-------------------+----------------+
| compute3 | 172.29.236.123 | 172.29.240.123 | 172.29.244.123 |
+------------------+----------------+-------------------+----------------+
| | | | |
+------------------+----------------+-------------------+----------------+
| lvm-storage1 | 172.29.236.131 | | 172.29.244.131 |
+------------------+----------------+-------------------+----------------+
| | | | |
+------------------+----------------+-------------------+----------------+
| nfs-storage1 | 172.29.236.141 | | 172.29.244.141 |
+------------------+----------------+-------------------+----------------+
| | | | |
+------------------+----------------+-------------------+----------------+
| ceph-mon1 | 172.29.236.151 | | 172.29.244.151 |
+------------------+----------------+-------------------+----------------+
| ceph-mon2 | 172.29.236.152 | | 172.29.244.152 |
+------------------+----------------+-------------------+----------------+
| ceph-mon3 | 172.29.236.153 | | 172.29.244.153 |
+------------------+----------------+-------------------+----------------+
| | | | |
+------------------+----------------+-------------------+----------------+
| swift1 | 172.29.236.161 | | 172.29.244.161 |
+------------------+----------------+-------------------+----------------+
| swift2 | 172.29.236.162 | | 172.29.244.162 |
+------------------+----------------+-------------------+----------------+
| swift3 | 172.29.236.163 | | 172.29.244.163 |
+------------------+----------------+-------------------+----------------+
| | | | |
+------------------+----------------+-------------------+----------------+
| log1 | 172.29.236.171 | | |
+------------------+----------------+-------------------+----------------+
--------------
.. include:: navigation.txt

7
doc/source/install-guide-revised-draft/overview.rst
View File

@ -7,10 +7,13 @@ Chapter 1. Overview
.. toctree::
overview-osa.rst
overview-hostlayout.rst
overview-host-layout
overview-ref-arch.rst
overview-network-arch.rst
overview-requirements.rst
overview-workflow.rst
overview-security.rst
overview-workflow.rst
--------------

1
doc/source/install-guide-revised-draft/targethosts.rst
View File

@ -7,7 +7,6 @@ Target hosts
.. toctree::
targethosts-prepare.rst
targethosts-network.rst
targethosts-networkconfig.rst
**Figure 3.1. Installation workflow**