diff options
author | Sofia Wallin <sofia.wallin@ericsson.com> | 2017-02-17 14:00:36 +0100 |
---|---|---|
committer | Sofia Wallin <sofia.wallin@ericsson.com> | 2017-02-17 14:00:36 +0100 |
commit | 4bdb2d6a128664082bddad51091e0d9fb63068fd (patch) | |
tree | 7063348d03a3c6464226ca7fffd85f41e52042a5 /docs/release/installation/architecture.rst | |
parent | 5e4c2ffc86d0426113f60b8069e81482f82bbc8d (diff) |
Doc updates for MS6
Updated the docs structure according to directives and MS6
Change-Id: I36e92cbc58328528ebb91ff4f54ee701f5477443
Signed-off-by: Sofia Wallin <sofia.wallin@ericsson.com>
Diffstat (limited to 'docs/release/installation/architecture.rst')
-rw-r--r-- | docs/release/installation/architecture.rst | 143 |
1 files changed, 143 insertions, 0 deletions
diff --git a/docs/release/installation/architecture.rst b/docs/release/installation/architecture.rst new file mode 100644 index 00000000..38806391 --- /dev/null +++ b/docs/release/installation/architecture.rst @@ -0,0 +1,143 @@ +Triple-O Deployment Architecture +================================ + +Apex is based on the OpenStack Triple-O project as distributed by +the RDO Project. It is important to understand the basics +of a Triple-O deployment to help make decisions that will assist in +successfully deploying OPNFV. + +Triple-O stands for OpenStack On OpenStack. This means that OpenStack +will be used to install OpenStack. The target OPNFV deployment is an +OpenStack cloud with NFV features built-in that will be deployed by a +smaller all-in-one deployment of OpenStack. In this deployment +methodology there are two OpenStack installations. They are referred +to as the undercloud and the overcloud. The undercloud is used to +deploy the overcloud. + +The undercloud is the all-in-one installation of OpenStack that includes +baremetal provisioning capability. The undercloud will be deployed as a +virtual machine on a jumphost. This VM is pre-built and distributed as part +of the Apex RPM. + +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 +- Ceph Monitors and OSDs + +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. + +Ceph Monitors & OSDs + The Ceph monitors run on each of the control nodes. Each control node also + has a Ceph OSD running on it. By default the OSDs use an autogenerated + virtual disk as their target device. A non-autogenerated device can be + specified in the deploy file. + +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 +=========================== + +OPNFV distinguishes different types of SDN controllers, deployment options, and +features into "scenarios". These scenarios are universal across all OPNFV +installers, although some may or may not be supported by each installer. + +The standard naming convention for a scenario is: +<VIM platform>-<SDN type>-<feature>-<ha/noha> + +The only supported VIM type is "OS" (OpenStack), while SDN types can be any +supported SDN controller. "feature" includes things like ovs_dpdk, sfc, etc. +"ha" or "noha" determines if the deployment will be highly available. If "ha" +is used at least 3 control nodes are required. + +OPNFV Scenarios in Apex +======================= + +Apex provides pre-built scenario files in /etc/opnfv-apex which a user can +select from to deploy the desired scenario. Simply pass the desired file to +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. 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** | **Supported** | ++-------------------------+------------+-----------------+ +| os-nosdn-nofeature-ha | Apex | Yes | ++-------------------------+------------+-----------------+ +| os-nosdn-nofeature-noha | Apex | Yes | ++-------------------------+------------+-----------------+ +| os-nosdn-ovs-noha | OVS for NFV| Yes | ++-------------------------+------------+-----------------+ +| os-nosdn-fdio-noha | FDS | Yes | ++-------------------------+------------+-----------------+ +| os-odl_l2-nofeature-ha | Apex | Yes | ++-------------------------+------------+-----------------+ +| os-odl_l3-nofeature-ha | Apex | Yes | ++-------------------------+------------+-----------------+ +| os-odl_l2-sfc-noha | SFC | Yes | ++-------------------------+------------+-----------------+ +| os-odl-bgpvpn-ha | SDNVPN | No | ++-------------------------+------------+-----------------+ +| os-odl_l2-fdio-noha | FDS | Yes | ++-------------------------+------------+-----------------+ +| os-onos-nofeature-ha | ONOSFW | Yes | ++-------------------------+------------+-----------------+ +| os-onos-sfc-ha | ONOSFW | Yes | ++-------------------------+------------+-----------------+ |