Merge "Add introduction and architecture doc"
This commit is contained in:
commit
8c6d708553
Binary file not shown.
After Width: | Height: | Size: 15 KiB |
|
@ -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
|
Binary file not shown.
After Width: | Height: | Size: 64 KiB |
|
@ -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
|
Binary file not shown.
After Width: | Height: | Size: 93 KiB |
|
@ -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
|
Binary file not shown.
After Width: | Height: | Size: 51 KiB |
|
@ -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
|
|
@ -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
|
|
@ -30,6 +30,18 @@ Getting Started
|
|||
User Guide
|
||||
----------
|
||||
|
||||
Overview
|
||||
^^^^^^^^
|
||||
|
||||
.. toctree::
|
||||
:maxdepth: 1
|
||||
|
||||
introduction
|
||||
architecture
|
||||
|
||||
Use cases
|
||||
^^^^^^^^^
|
||||
|
||||
.. toctree::
|
||||
:maxdepth: 1
|
||||
|
||||
|
|
|
@ -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…
Reference in New Issue