blob: f1861d0a701d931f1ef43b5cbc4c54b4d59ee144 (
plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
|
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
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
===========================
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. The following scenarios correspond to a supported <Scenario>.yaml
deploy settings file:
+-------------------------+------------+-----------------+
| **Scenario** | **Owner** | **Known Issues**|
+-------------------------+------------+-----------------+
| os-nosdn-nofeature-ha | Apex | |
+-------------------------+------------+-----------------+
| os-nosdn-nofeature-noha | Apex | |
+-------------------------+------------+-----------------+
| os-nosdn-ovs-noha | OVS for NFV| |
+-------------------------+------------+-----------------+
| os-nosdn-fdio-noha | FDS | |
+-------------------------+------------+-----------------+
| os-odl_l2-nofeature-ha | Apex | |
+-------------------------+------------+-----------------+
| os-odl_l3-nofeature-ha | Apex | APEX-112 |
+-------------------------+------------+-----------------+
| os-odl_l2-sfc-noha | SFC | |
+-------------------------+------------+-----------------+
| os-odl_l2-bgpvpn-noha | SDNVPN | |
+-------------------------+------------+-----------------+
| os-odl_l2-fdio-noha | FDS | |
+-------------------------+------------+-----------------+
| os-onos-nofeature-ha | ONOSFW | |
+-------------------------+------------+-----------------+
| os-onos-sfc-ha | ONOSFW | |
+-------------------------+------------+-----------------+
|
