From 24f09fb531b41a7ecb7df915cb4c7cd8df77f3ad Mon Sep 17 00:00:00 2001 From: Miruna Paun Date: Fri, 29 Sep 2017 16:11:21 +0200 Subject: Adding lastest changes to the ENC1.0 Installation Guide USERDOCAP-240 Signed-off-by: Miruna Paun --- .../doc/high_availability.xml | 20 ++++----- .../doc/installation_instructions.xml | 48 ++++++++++++---------- 2 files changed, 36 insertions(+), 32 deletions(-) diff --git a/book-enea-nfv-core-installation-guide/doc/high_availability.xml b/book-enea-nfv-core-installation-guide/doc/high_availability.xml index 93f6468..4fe02fe 100644 --- a/book-enea-nfv-core-installation-guide/doc/high_availability.xml +++ b/book-enea-nfv-core-installation-guide/doc/high_availability.xml @@ -53,14 +53,14 @@ framework for the high availability of Network Services, on top of a virtualized infrastructure. The key feature is immediate notification of unavailability of virtualized resources from VIM, to process recovery of - VNFs on them. + VNFs on them. The Doctor project has also collaborated with the Availability project on identifying gaps in upstream projects, such as but not exclusively OpenStack. It has also worked towards implementing missing features and improving functionality, with a good example being the Aodh event based alarms, which allow for fast notifications when certain - predefined events occur. + predefined events occur. The Doctor project also produced an architectural design and a reference implementation based on opensource components, which will be @@ -128,7 +128,7 @@ interfaces. These can be visual dashboards like OpenStack Horizon or Fuel Dashboard, or via CLI tools like the OpenStack unified CLI, that can be accessed from one of the servers that act as OpenStack - Controller nodes. + Controller nodes. In Enea NFV Core 1.0 the Administrator can also access the Zabbix dashboard to perform supplementary configurations. The same @@ -136,7 +136,7 @@ dashboard, enabling the user to visually inspect the faults reported by the monitoring tools through visual representations of the virtual and physical resources, the relationships between them and the fault - correlation. + correlation. For Vitrage, users will usually want to configure additional use-cases and describe relationships between components via template @@ -221,7 +221,7 @@ The NFVI sends monitoring events for the resources the VIM has - been subscribed to. + been subscribed to. This subscription message exchange between the VIM and NFVI @@ -251,7 +251,7 @@ This step shows database lookup geared to find the virtual resources affected by the detected fault. Vitrage will perform various calculations to detect what virtual resources are affected - by the raw failure presented by Zabbix. + by the raw failure presented by Zabbix. Vitrage can be configured via templates to correlate instances with the physical hosts they are running on, so that if a compute @@ -259,7 +259,7 @@ typical use-case is to mark the compute node down (mark_host_down) and update the states of all instances running on them. This is done by issuing Nova API calls - for each of these instances. + for each of these instances. Step 5c. shows the Controller (Nova in this case) acting upon the state change of the instance and issuing an event alarm to @@ -555,7 +555,7 @@ root@node-6:~# systemctl restart vitrage-graph control plane services, so it can effectively provide redundancy and recovery for the Controller nodes only. A reason for this is that Controller nodes and Compute nodes essentially have very different High - Availability requirements that need to be considered. + Availability requirements that need to be considered. Typically, for Controller nodes, the services that run on them are stateless, with few exceptions, where only one instance of a given service @@ -588,7 +588,7 @@ root@node-6:~# systemctl restart vitrage-graph over a large cluster, since each node has to talk to every other, essentially creating a mesh configuration. A solution to this problem could be partitioning the cluster into smaller groups, but this has its - limitations and it is generally difficult to manage. + limitations and it is generally difficult to manage. A better solution is using pacemaker-remote, a feature of pacemaker, which allows for extending the cluster beyond the @@ -788,7 +788,7 @@ ipaddr=10.0.100.155 login=ADMIN passwd=ADMIN op monitor interval="60s" -
+
OpenStack Resource Agents The OpenStack community has been working for some time on diff --git a/book-enea-nfv-core-installation-guide/doc/installation_instructions.xml b/book-enea-nfv-core-installation-guide/doc/installation_instructions.xml index 8fe5e89..2b89490 100644 --- a/book-enea-nfv-core-installation-guide/doc/installation_instructions.xml +++ b/book-enea-nfv-core-installation-guide/doc/installation_instructions.xml @@ -43,25 +43,25 @@
Other Preparations - Reading the following documents aides in familiarizing yourself with - Fuel: + Reading the following addition and optional documents aides in + familiarizing yourself with Fuel: Fuel + url="https://docs.openstack.org/fuel-docs/latest/userdocs/fuel-install-guide.html">Fuel Installation Guide Fuel + url="https://docs.openstack.org/fuel-docs/latest/userdocs/fuel-user-guide.html">Fuel User Guide Fuel + url="https://docs.openstack.org/fuel-docs/latest/devdocs/develop.html">Fuel Developer Guide @@ -70,6 +70,12 @@ url="http://docs.openstack.org/developer/fueldocs/plugindocs/fuel-plugin-sdk-guide.html">Fuel Plugin Developers Guide + + + OPNFV + Fuel Installation Guide + Prior to installation, a number of deployment specific parameters @@ -121,8 +127,10 @@
Hardware Requirements - The following minimum hardware requirements must be met for the - installation of Enea NFV Core using Fuel, to be successful: + Enea NFV Core 1.0 has been validated on the hardware configuration + shown below, which represents the minimum hardware requirements that must + be met for the installation of Enea NFV Core 1.0 using Fuel, to be + successful: @@ -190,7 +198,7 @@ This section describes the installation of the Enea NFV Core installation server (Fuel Master) as well as the deployment of the full - ENFV Core reference platform stack across a server cluster. + Enea NFV Core reference platform stack across a server cluster. It is recommended to install the Fuel Master on a VM using virt-manager, with a minimum of 8GB of RAM, 4 CPUs and at least 100GB @@ -287,17 +295,6 @@ - - In the Security Setup menu, restrict the - ssh access on the network: - - - - - - - - In the PXE setup menu, the default values can be left unchanged. @@ -440,6 +437,10 @@ Zabbix for Fuel + + + Tacker VNF Manager + Login to the Fuel Master via ssh using the @@ -447,7 +448,8 @@ additional plugins: $ fuel plugins --install /opt/opnfv/vitrage-1.0-1.0.4-1.noarch.rpm -$ fuel plugins --install zabbix_monitoring-2.5-2.5.3-1.noarch.rpm +$ fuel plugins --install zabbix_monitoring-2.5-2.5.3-1.noarch.rpm +$ fuel plugins --install tacker-1.0-1.0.0-1.noarch.rpm Expected output: Plugin ....... was successfully installed.
@@ -496,7 +498,8 @@ $ fuel plugins --install zabbix_monitoring-2.5-2.5.3-1.noarch.rpm Select Neutron with VLAN segmentation - (recommended when enabling DPDK). + (needed when enabling DPDK). VXLAN is available but not + supported. @@ -823,7 +826,8 @@ $ fuel plugins --install zabbix_monitoring-2.5-2.5.3-1.noarch.rpmIn the FUEL UI of your Environment, click the Settings tab and select OpenStack - Services on the left side pane: + Services on the left side pane, make sure Tacker is NOT enabled + and save your settings: -- cgit v1.2.3-54-g00ecf