summaryrefslogtreecommitdiffstats
path: root/docs/installationprocedure
diff options
context:
space:
mode:
Diffstat (limited to 'docs/installationprocedure')
-rw-r--r--docs/installationprocedure/architecture.rst87
-rw-r--r--docs/installationprocedure/baremetal.rst14
-rw-r--r--docs/installationprocedure/references.rst2
-rw-r--r--docs/installationprocedure/requirements.rst15
-rw-r--r--docs/installationprocedure/virtualinstall.rst2
5 files changed, 93 insertions, 27 deletions
diff --git a/docs/installationprocedure/architecture.rst b/docs/installationprocedure/architecture.rst
index c63da27c..c2b38d00 100644
--- a/docs/installationprocedure/architecture.rst
+++ b/docs/installationprocedure/architecture.rst
@@ -23,6 +23,64 @@ The overcloud is OPNFV. Configuration will be passed into undercloud and
the undercloud will use OpenStack's orchestration component, named Heat, to
execute a deployment that will provision the target OPNFV nodes.
+Apex High Availability Architecture
+===================================
+
+Undercloud
+----------
+
+The undercloud is not Highly Available. End users do not depend on the
+underloud. It is only for management purposes.
+
+Overcloud
+---------
+
+Apex will deploy three control nodes in an HA deployment. Each of these nodes
+will run the following services:
+
+- Stateless OpenStack services
+- MariaDB / Galera
+- RabbitMQ
+- OpenDaylight
+- HA Proxy
+- Pacemaker & VIPs
+
+Stateless OpenStack services
+ All running statesless OpenStack services are load balanced by HA Proxy.
+ Pacemaker monitors the services and ensures that they are running.
+
+Stateful OpenStack services
+ All running stateful OpenStack services are load balanced by HA Proxy.
+ They are monitored by pacemaker in an active/passive failover configuration.
+
+MariaDB / Galera
+ The MariaDB database is replicated across the control nodes using Galera.
+ Pacemaker is responsible for a proper start up of the Galera cluster. HA
+ Proxy provides and active/passive failover methodology to connections to the
+ database.
+
+RabbitMQ
+ The message bus is managed by Pacemaker to ensure proper start up and
+ establishment of clustering across cluster members.
+
+OpenDaylight
+ OpenDaylight is currently installed on all three control nodes but only
+ started on the first control node. OpenDaylight's HA capabilities are not yet
+ mature enough to be enabled.
+
+HA Proxy
+ HA Proxy is monitored by Pacemaker to ensure it is running across all nodes
+ and available to balance connections.
+
+Pacemaker & VIPs
+ Pacemaker has relationships and restraints setup to ensure proper service
+ start up order and Virtual IPs associated with specific services are running
+ on the proper host.
+
+VM Migration is configured and VMs can be evacuated as needed or as invoked
+by tools such as heat as part of a monitored stack deployment in the overcloud.
+
+
OPNFV Scenario Architecture
===========================
@@ -47,31 +105,32 @@ the installer as a (-d) deploy setting. Read further in the Apex documentation
to learn more about invoking the deploy command. Below is quick reference
matrix for OPNFV scenarios supported in Apex. Please refer to the respective
OPNFV Docs documentation for each scenario in order to see a full scenario
-description. The following scenarios correspond to a supported <Scenario>.yaml
-deploy settings file:
+description. Also, please refer to release-notes for information about known
+issues per scenario. The following scenarios correspond to a supported
+<Scenario>.yaml deploy settings file:
+-------------------------+------------+-----------------+
-| **Scenario** | **Owner** | **Known Issues**|
+| **Scenario** | **Owner** | **Supported** |
+-------------------------+------------+-----------------+
-| os-nosdn-nofeature-ha | Apex | |
+| os-nosdn-nofeature-ha | Apex | Yes |
+-------------------------+------------+-----------------+
-| os-nosdn-nofeature-noha | Apex | |
+| os-nosdn-nofeature-noha | Apex | Yes |
+-------------------------+------------+-----------------+
-| os-nosdn-ovs-noha | OVS for NFV| |
+| os-nosdn-ovs-noha | OVS for NFV| Yes |
+-------------------------+------------+-----------------+
-| os-nosdn-fdio-noha | FDS | |
+| os-nosdn-fdio-noha | FDS | Yes |
+-------------------------+------------+-----------------+
-| os-odl_l2-nofeature-ha | Apex | |
+| os-odl_l2-nofeature-ha | Apex | Yes |
+-------------------------+------------+-----------------+
-| os-odl_l3-nofeature-ha | Apex | APEX-112 |
+| os-odl_l3-nofeature-ha | Apex | Yes |
+-------------------------+------------+-----------------+
-| os-odl_l2-sfc-noha | SFC | |
+| os-odl_l2-sfc-noha | SFC | Yes |
+-------------------------+------------+-----------------+
-| os-odl_l2-bgpvpn-noha | SDNVPN | |
+| os-odl_l2-bgpvpn-ha | SDNVPN | No |
+-------------------------+------------+-----------------+
-| os-odl_l2-fdio-noha | FDS | |
+| os-odl_l2-fdio-noha | FDS | Yes |
+-------------------------+------------+-----------------+
-| os-onos-nofeature-ha | ONOSFW | |
+| os-onos-nofeature-ha | ONOSFW | Yes |
+-------------------------+------------+-----------------+
-| os-onos-sfc-ha | ONOSFW | |
+| os-onos-sfc-ha | ONOSFW | Yes |
+-------------------------+------------+-----------------+
diff --git a/docs/installationprocedure/baremetal.rst b/docs/installationprocedure/baremetal.rst
index 8507b445..2de6e8a8 100644
--- a/docs/installationprocedure/baremetal.rst
+++ b/docs/installationprocedure/baremetal.rst
@@ -137,6 +137,12 @@ Install Bare Metal Jumphost
no longer carry them and they will not need special handling for
installation.
+ Python 3.4 is also required and it needs to be installed if you are using
+ the Centos 7 base image:
+
+ ``sudo yum install epel-release``
+ ``sudo yum install python34``
+
To install these RPMs download them to the local disk on your CentOS 7
install and pass the file names directly to yum:
``sudo yum install python34-markupsafe-<version>.rpm
@@ -199,7 +205,8 @@ Edit the 2 settings files in /etc/opnfv-apex/. These files have comments to
help you customize them.
1. deploy_settings.yaml
- This file includes basic configuration options deployment.
+ This file includes basic configuration options deployment, and also documents
+ all available options.
Alternatively, there are pre-built deploy_settings files available in
(``/etc/opnfv-apex/``). These files are named with the naming convention
os-sdn_controller-enabled_feature-[no]ha.yaml. These files can be used in
@@ -223,11 +230,10 @@ You are now ready to deploy OPNFV using Apex!
Follow the steps below to execute:
1. Execute opnfv-deploy
- ``sudo opnfv-deploy [ --flat ] -n network_settings.yaml
+ ``sudo opnfv-deploy -n network_settings.yaml
-i inventory.yaml -d deploy_settings.yaml``
If you need more information about the options that can be passed to
- opnfv-deploy use ``opnfv-deploy --help`` --flat collapses all networks to a
- single nic, only uses the admin network from the network settings file. -n
+ opnfv-deploy use ``opnfv-deploy --help``. -n
network_settings.yaml allows you to customize your networking topology.
2. Wait while deployment is executed.
diff --git a/docs/installationprocedure/references.rst b/docs/installationprocedure/references.rst
index 5ff2a542..a63a8421 100644
--- a/docs/installationprocedure/references.rst
+++ b/docs/installationprocedure/references.rst
@@ -18,6 +18,8 @@ OPNFV
`OPNFV Apex project page <https://wiki.opnfv.org/apex>`_
+`OPNFV Apex release notes <http://artifacts.opnfv.org/apex/colorado/docs/releasenotes/release-notes.html#references>`_
+
OpenStack
---------
diff --git a/docs/installationprocedure/requirements.rst b/docs/installationprocedure/requirements.rst
index d54d584b..1b3fe87d 100644
--- a/docs/installationprocedure/requirements.rst
+++ b/docs/installationprocedure/requirements.rst
@@ -46,14 +46,13 @@ Network requirements include:
deployment. The External network is where public internet access would
reside if available.
-\* *These networks can be combined with each other or all combined on the
- Control Plane network.*
-\* *Non-External networks will be consolidated to the Control Plane network
- if not specifically configured.*
-\*\* *Internal API network, by default, is collapsed with provisioning in IPv4
- deployments, this is not possible with the current lack of PXE boot
- support and therefore the API network is required to be its own
- network in an IPv6 deployment.*
+\*These networks can be combined with each other or all combined on the
+Control Plane network.
+
+\*\*Internal API network, by default, is collapsed with provisioning in IPv4
+deployments, this is not possible with the current lack of PXE boot
+support and therefore the API network is required to be its own
+network in an IPv6 deployment.
Bare Metal Node Requirements
----------------------------
diff --git a/docs/installationprocedure/virtualinstall.rst b/docs/installationprocedure/virtualinstall.rst
index 01971893..d2c81abe 100644
--- a/docs/installationprocedure/virtualinstall.rst
+++ b/docs/installationprocedure/virtualinstall.rst
@@ -49,7 +49,7 @@ environment will deploy with the following architecture:
Follow the steps below to execute:
1. ``sudo opnfv-deploy -v [ --virtual-computes n ]
- [ --virtual-cpus n ] [ --virtual-ram n ] [ --flat ]
+ [ --virtual-cpus n ] [ --virtual-ram n ]
-n network_settings.yaml -i inventory.yaml -d deploy_settings.yaml``
2. It will take approximately 45 minutes to an hour to stand up undercloud,