Browse Source

Merge "Add introduction and architecture doc"

tags/4.0.0.0rc1
Zuul 2 weeks ago
committed by Gerrit Code Review
parent
commit
8c6d708553
11 changed files with 454 additions and 0 deletions
  1. BIN
      doc/source/_images/etsi-architecture.png
  2. +35
    -0
      doc/source/_images/etsi-architecture.pu
  3. BIN
      doc/source/_images/tacker-design-etsi.png
  4. +81
    -0
      doc/source/_images/tacker-design-etsi.pu
  5. BIN
      doc/source/_images/tacker-design-legacy.png
  6. +103
    -0
      doc/source/_images/tacker-design-legacy.pu
  7. BIN
      doc/source/_images/tacker-design.png
  8. +61
    -0
      doc/source/_images/tacker-design.pu
  9. +106
    -0
      doc/source/user/architecture.rst
  10. +12
    -0
      doc/source/user/index.rst
  11. +56
    -0
      doc/source/user/introduction.rst

BIN
doc/source/_images/etsi-architecture.png View File

Before After
Width: 674  |  Height: 375  |  Size: 15 KiB

+ 35
- 0
doc/source/_images/etsi-architecture.pu View File

@@ -0,0 +1,35 @@
@startuml

'# Components
agent "OSS/BSS" as oss
agent "EM/VNF" as vnf
agent NFVI as nfvi

frame "MANO components" {
agent "NFVO\n(Tacker)" as nfvo
agent "VNFM\n(Tacker)" as vnfm
agent VIM as vim
}

agent "NFVO\n(Tacker)" as nfvo
agent "VNFM\n(Tacker)" as vnfm
agent VIM as vim

frame "NFV descriptors (SOL001)" {
file "VNFD\n(SOL004)" as vnfd
file "NSD\n(SOL007)" as nsd
}

'# vnfd -[hidden]- nsd

'# Relationships
oss .down. vnf
vnf .down. nfvi

nfvo -down- vnfm : Or-Vnfm (SOL003)
vnfm .down. vim

oss -right- nfvo : Os-Ma-Nfvo (SOL005)
vnf -right- vnfm : Ve-Vnfm-em (SOL002)\nVe-Vnfm-nfv (SOL003)

@enduml

BIN
doc/source/_images/tacker-design-etsi.png View File

Before After
Width: 1126  |  Height: 917  |  Size: 64 KiB

+ 81
- 0
doc/source/_images/tacker-design-etsi.pu View File

@@ -0,0 +1,81 @@
@startuml

'# Components
component "tacker-client" as client

frame "tacker-server" {
component server {
component "VNF Lifecycle\nManagement" as lcm
component "VNF Package\nManagement" as vnfpkgm
}
}

frame "tacker-conductor" {
component "mgmt-driver" as mgmt {
'component Noop as noop
component OpenWRT as wrt
}
component "monitor-driver" as monitor {
component Ping as ping
component Zabbix as zabbix
}
component conductor {
component "Conductor Server" as cond
component "VNF Lifecycle Driver" as lcm_driver
}
component "infra-driver" as infra {
component "OpenStack Driver" as os_driver
component "Kubernetes Driver" as ks_driver
}
}

database "tacker DB" as db {
component "DB Interface" as db_if
component "MariaDB" as maria
db_if <-right-> maria
}

cloud "NFV infrastructures" {
node "OpenStack" as os {
node "VNF (VM)" as vm
}
node "Kubernetes" as ks {
node "VNF (Container)" as container
}
}

'# Relationships
client <-down-> lcm
client <-down-> vnfpkgm

lcm <-down-> db_if
vnfpkgm <-down-> db_if

lcm <-down-> cond
cond <-down-> lcm_driver
vnfpkgm <-down-> cond

cond <-down-> db_if
lcm_driver <-down-> db_if

lcm_driver <-down-> os_driver
os_driver <-down-> os
lcm_driver <-down-> ks_driver
ks_driver <-down-> ks

lcm_driver <-[hidden]down-> mgmt
lcm_driver <-[hidden]down-> monitor
'cond <-down-> mgmt
'cond <-down-> monitor
/'
'cond <-right-> noop
cond <-right-> wrt
wrt <-down-> vm
cond <-down-> ping
ping <-down-> vm
cond <-down-> zabbix
zabbix <-down-> vm
mgmt <-[hidden]down-> monitor
'/

@enduml

BIN
doc/source/_images/tacker-design-legacy.png View File

Before After
Width: 1653  |  Height: 966  |  Size: 93 KiB

+ 103
- 0
doc/source/_images/tacker-design-legacy.pu View File

@@ -0,0 +1,103 @@
@startuml

'# Components
component "tacker-client" as client

frame "tacker-server" {
component server {
component "Vnfm" as vnfm
component "Nfvo" as nfvo
}
component plugin {
component "VNFMPlugin" as vnfm_plugin
component "NFVOPlugin" as nfvo_plugin
'cond <-down-> vnfm_plugin
}
component "mgmt-driver" as mgmt {
'component Noop as noop
component OpenWRT as wrt
}
component "monitor-driver" as monitor {
component Ping as ping
component Zabbix as zabbix
}
component "infra-driver" as infra {
component "OpenStack Driver" as os_driver
component "Kubernetes Driver" as ks_driver
}
component "vim-driver" as vim {
component "OpenStack Driver" as os_vim
component "Kubernetes Driver" as ks_vim
}
component "policy-action-driver" as policy {
component "AutoHeal" as autoheal
component "AutoScale" as autoscale
component "Respawn" as respawn
component "Log" as log
}
}

frame "tacker-conductor" as cond {
component conductor {
component "Conductor Server"
}
}

database "tacker DB" as db {
component "NFVOPluginDb" as db_nfvo
component "VNFMPluginDb" as db_vnfm
component "MariaDB" as maria
db_nfvo <-down-> maria
db_vnfm <-down-> maria
}

cloud "NFV infrastructures" as nfv_infra {
node "OpenStack" as os {
node "VNF (VM)" as vm
}
node "Kubernetes" as ks {
node "VNF (Container)" as container
}
'vm -[hidden]up- ks
}

'# Relationships
client <-down-> vnfm
client <-down-> nfvo

vnfm <-down-> vnfm_plugin
nfvo <-down-> nfvo_plugin

vnfm_plugin <-down-> db_vnfm
nfvo_plugin <-down-> db_nfvo

vnfm_plugin <-down-> os_driver
vnfm_plugin <-down-> ks_driver

vnfm_plugin <-down-> policy
vnfm_plugin <-down-> mgmt
vnfm_plugin <-down-> monitor
/'
vnfm_plugin <-down-> autoheal
vnfm_plugin <-down-> autoscale
vnfm_plugin <-down-> respawn
vnfm_plugin <-down-> log
vnfm_plugin <-down-> wrt
vnfm_plugin <-down-> ping
vnfm_plugin <-down-> zabbix
'/

nfvo_plugin <-down-> os_vim
nfvo_plugin <-down-> ks_vim

os_driver <-down-> os
ks_driver <-down-> ks

os_vim <-down-> os
ks_vim <-down-> ks

cond <-[hidden]left-> server
mgmt <-[hidden]down-> monitor
monitor <-[hidden]down-> nfv_infra

@enduml

BIN
doc/source/_images/tacker-design.png View File

Before After
Width: 737  |  Height: 762  |  Size: 51 KiB

+ 61
- 0
doc/source/_images/tacker-design.pu View File

@@ -0,0 +1,61 @@
@startuml
'left to right direction

'# Components
package python-tackerclient {
agent "tacker-client" as client
}

package tacker {
frame "tacker-server" {
agent "server" as server
}
frame "tacker-conductor" {
agent conductor
agent "infra-driver" as infra
agent "vim-driver" as vim

agent "mgmt-driver" as mgmt
agent "monitor-driver" as monitor
agent "policy-driver" as policy
'mgmt <-[hidden]-> monitor
}
database "tacker DB" as db
}

cloud "NFV infrastructures" {
node "OpenStack" as os {
node "VNF (VM)" as vm
}
node "Kubernetes" as ks {
node "VNF (Container)" as container
}
vm -[hidden]right- ks
}


'# Relationships
client <-down-> server
server <-down-> conductor

conductor <-down-> infra
conductor <-down-> vim
conductor <-down-> mgmt
conductor <-down-> monitor
conductor <-down-> policy

server <-left-> db
conductor <-up-> db
infra <-up-> db
vim <-up-> db

infra <-down-> ks
infra <-down-> os
vim <-down-> ks
vim <-down-> os

mgmt <-down-> vm
monitor <-down-> vm
policy <-down-> vm

@enduml

+ 106
- 0
doc/source/user/architecture.rst View File

@@ -0,0 +1,106 @@
===================
Tacker architecture
===================

Tacker design can be described by the following diagram:

.. figure:: ../_images/tacker-design.png
:figwidth: 700 px
:align: left
:scale: 80 %

Packages:

* **python-tackerclient** - is the package for CLI and *REST API* calling.
* **tacker** - is the main package for Tacker project.

Components:

* **tacker-client** - provides CLI and communication with Tacker via
*REST API*.

* **server** - provides *REST API* and calls conductor via RPC.
* **conductor** - implements all logics to operate VNF and call required
drivers providing interface to NFV infrastructures.

* **infra-driver** - is responsible for exact actions to operate OpenStack or
Kubernetes resources.

* **vim-driver** - is responsible for registration of VIM.
* **mgmt-driver** - is responsible for exact actions to configure VNFs.
* **monitor-driver** - is responsible for exact actions to monitor VNFs.
* **policy-driver** - is responsible for policy based VNF operations.

Tacker Service
--------------

Tacker service is composed of two main processes:

* tacker.service
* tacker-conductor.service

*tacker.service* is a web server with Web Server Gateway Interface (WSGI)
waiting for the REST calls to redirect them to the drivers. Some operations
are sent to the Tacker Conductor via RPC. Two types of API are supported;
ESTI NFV-SOL API and Legacy API.

*tacker-conductor.service* implements some complicated logic and operations
for orchestrations and VNF managements. It is mainly responsible for ETSI
NFV-SOL based API operations and communicates with OpenStack or Kubernetes
VIM by the infra drivers. Heat client or Kubernetes python client provides the
IF to operate or manage resources for each VIM.

ETSI NFV-SOL based implementation
---------------------------------

Tacker ETSI NFV-SOL based implementation is described as the following:

.. figure:: ../_images/tacker-design-etsi.png
:figwidth: 700 px
:align: left
:width: 700 px

In Ussuri release, VNF Package Management Interface in `NFV-SOL005`_ and VNF
Lifecycle Management Interface in `NFV-SOL002`_ and `NFV-SOL003`_ are
implemented. They provide a basic function block for VNF instances.

.. TODO(yoshito-ito): add supported ETSI doc and reference
The supported operations and attributes are summarized in
:doc:`./supported-etsi-operation` and :doc:`./supported-etsi-resource`.

When a REST API call is sent to tacker-server, some simple operations are
executed in tacker-server with DB queries. The others are redirected to
`Conductor Server` via RPC, and `VNF Lifecycle Driver` calls appropriate
infra-driver to execute the actual logics for control and management of
virtualised resources.

Tacker also provides configuring and monitoring system for VNF. The
mgmt-driver or monitor-driver can be called by `Conductor Server`. In Ussuri
release, OpenWRT for mgmt-driver and Ping/Zabbix for monitor-driver are
available.

.. TODO(yoshito-ito): add ActionDriver after the implementation.

.. note:: VIM related operations such as "Register VIM" and "Update VIM" are
not defined in ETSI NFV-SOL. Users may need to use legacy Tacker.

Legacy implementation
---------------------

Legacy Tacker implementation is described as the following:

.. figure:: ../_images/tacker-design-legacy.png
:figwidth: 800 px
:align: left
:width: 800 px

When a REST API call is sent to tacker-server, VNFM and NFVO plugins handle
the request and execute connected methods in each plugin. The each plugin
(NFVOPlugin or VNFMPlugin) invokes required driver methods such as
mgmt-driver, monitor-driver, infra-driver, and vim-driver.

.. TODO(yoshito-ito): check the new fenix driver to add here.

.. _NFV-SOL002 : https://portal.etsi.org/webapp/WorkProgram/Report_WorkItem.asp?WKI_ID=49492
.. _NFV-SOL003 : https://portal.etsi.org/webapp/WorkProgram/Report_WorkItem.asp?WKI_ID=49506
.. _NFV-SOL005 : https://portal.etsi.org/webapp/WorkProgram/Report_WorkItem.asp?WKI_ID=50935

+ 12
- 0
doc/source/user/index.rst View File

@@ -30,6 +30,18 @@ Getting Started
User Guide
----------

Overview
^^^^^^^^

.. toctree::
:maxdepth: 1

introduction
architecture

Use cases
^^^^^^^^^

.. toctree::
:maxdepth: 1



+ 56
- 0
doc/source/user/introduction.rst View File

@@ -0,0 +1,56 @@
============
Introduction
============

Tacker is a Generic VNF Manager (VNFM) and an NFV Orchestrator (NFVO) to
operate Network Services (NSs) and Virtual Network Functions (VNFs) on an NFV
infrastructure platform like OpenStack or Kubernetes. The operations are based
on ETSI NFV Management and Orchestration (MANO) Architecture [1]_.

Now Tacker has two different architectures:

* ETSI NFV-SOL based implementation
* Legacy implementation

When Tacker project was originated to follow the ETSI NFV MANO standards in
Liberty release, the standarding for "NFV Solutions (SOL)", which is the
specifications for protocols and data models, was not yet defined. After the
publications of SOL documents for NFV descriptors such as VNF descriptor
(VNFD) and NS Descriptor (NSD) as `NFV-SOL001`_, `NFV-SOL004`_, and
`NFV-SOL007`_, and also after REST-based APIs have been specified as
`NFV-SOL002`_, `NFV-SOL003`_, and `NFV-SOL005`_, the SOL based new
implementations have started in Ussuri release.

ETSI NFV MANO concept
---------------------

MANO functional blocks are:

.. figure:: ../_images/etsi-architecture.png
:figwidth: 700 px
:align: left
:scale: 90 %

**NFV Orchestrator(NFVO)** - is responsible for on-boarding NS and VNF, and
providing global resource management, validation and authorization of NFV
infrastructure (NFVI) resource requests.
**VNF Manager(VNFM)** - is responsible for the lifecycle management of VNF.
**Virtualised Infrastructure Manager (VIM)** - controls and manages compute,
storage, and network resources.

Tacker provides a functional block of NFVO and VNFM. VIM can be an OpenStack
or Kubernetes cluster. In a particular use case to deploy a VNF instance,
you need to prepare a VNF Package. A VNF Package includes VNFD, software
images for Virtual Machine (VM), and other artifact resources such as scripts
and config files. NFVO is called to deploy a VNF instance with a VNF Package,
then NFVO asks VNFM to deploy actual VNF on a NFV infrastructure. All the
interfaces involved in this process is defined in ETSI NFV specifications.

.. [1] https://www.etsi.org/technologies/nfv

.. _NFV-SOL001 : https://portal.etsi.org/webapp/workProgram/Report_WorkItem.asp?wki_id=49491
.. _NFV-SOL004 : https://portal.etsi.org/webapp/WorkProgram/Report_WorkItem.asp?wki_id=50617
.. _NFV-SOL007 : https://portal.etsi.org/webapp/WorkProgram/Report_WorkItem.asp?wki_id=54501
.. _NFV-SOL002 : https://portal.etsi.org/webapp/WorkProgram/Report_WorkItem.asp?WKI_ID=49492
.. _NFV-SOL003 : https://portal.etsi.org/webapp/WorkProgram/Report_WorkItem.asp?WKI_ID=49506
.. _NFV-SOL005 : https://portal.etsi.org/webapp/WorkProgram/Report_WorkItem.asp?WKI_ID=50935

Loading…
Cancel
Save