Tacker30 es un proyecto oficial de OpenStack que implementa un VNFM genérico y un NFVO para
desplegar y operar NSs y VNFs en una infraestructura de NFV como OpenStack. Se basa en NFV- MANO de ETSI y proporciona un conjunto funcional de componentes para orquestar servicios de red de extremo a extremo utilizando VNFs.
▪ Arquitectura
La Figura 2.17 muestra la arquitectura de alto nivel de Tacker compuesta por los siguientes componentes:
28 https://openbaton.github.io/ 29 https://www.onap.org/
30https://wiki.openstack.org/wiki/Tacker
52
a. Catálogo de NFV. Representa un repositorio de descriptores para servicios de red (NSD), VNFs (VNFD) y grafos de envío de VNF (VNFFGD), los cuales son especificados mediante plantillas de servicio TOSCA y almacenados en una DB.
b. Gestor de VNF (VNFM). Encargado de gestionar los procesos relacionados al ciclo de vida de las
VNFs (Create, Read, Update, Delete, CRUD) y facilitar su configuración inicial. Similarmente,
se encarga del monitoreo, auto recuperación y escalado automático de VNFs desplegadas en base a políticas.
c. Orquestador de NFV (NFVO). Permite generalizar, mediante plantillas, el despliegue de NSs de extremo a extremo. Se encarga de verificar y asignar recursos sobre el VIM, asegurando una eficiente colocación de las VNFs mediante políticas.
d. API. Tacker exporta sus capacidades actuales mediante un API, el cual es accesible mediante la
línea de comandos (CLI), el Dashboard (Horizon) o remotamente a través de REST. A través del API, se controla el ciclo de vida de descriptores y posteriores instancias de VNFs, NSs y VNFFGs. Los APIs proporcionados se corresponde con las interfaces NFV-MANO definidas por ETSI.
▪ Interfaces de programación de aplicaciones (APIs)
De acuerdo con la documentación de Tacker31 se proporcionan APIs encargadas de controlar las
operaciones CRUD de descriptores y posteriores instancias. Se distinguen tres tipos de APIs: el NFVO NS API orientado a los servicios de red (NSs), el VNFM API orientado a las funciones de red
virtualizadas (VNFs) y el VNFFG API orientado a las cadenas de función de servicio (SFCs) o grafos
de envío de VNF (VNFFG). La Tabla 2.1, Tabla 2.2 y Tabla 2.3 muestran las opciones que actualmente incorporan las diferentes APIs. En la documentación de Tacker se proporciona información adicional como los formatos de solicitud y respuesta de las operaciones realizadas.
▪ Flujo de trabajo
Las operaciones de gestión y orquestación de NFV efectuadas por Tacker, se controlan a través del API que se proporciona. El API es utilizado por diferentes entidades como los OSS/BSS o un orquestador de NFV (NFVO) distinto con el objetivo de desplegar servicios de red sobre una plataforma NFV. La Figura 2.18 muestra un ejemplo del flujo de trabajo para gestionar VNFs y VNFFGs, el cual incluye siete etapas fundamentales.
• En la primera etapa, a través del VNFM API, diferentes clientes pueden realizar operaciones
CRUD sobre descriptores (VNFDs), las cuales posteriormente son reflejadas en el catálogo de NFV.
• En la segunda etapa, se procede a instanciar una VNF específica en la NFVI. Para este fin, se
utiliza la opción “Create VNF” del VNFM API, especificando el Id del VNFD recuperado previamente desde el catálogo. El despliegue de la VNF está controlado por diferentes procesos que ejecuta el VNFM y el NFVO. Como los descriptores están especificados en TOSCA, se realiza un proceso de conversión al formato de plantilla de despliegue utilizado por Heat ya que éste está encargado de gestionar el ciclo de vida de las máquinas virtuales (VMs) en OpenStack.
• En la tercera etapa, se procede a configurar la VNF previamente instanciada utilizando para ello
el marco de controladores de gestión (Mgmt Driver). El controlador de gestión utiliza un enfoque de selección de servicios, permitiendo especificar una configuración inicial la cual puede ser actualizada cuando la VNF se encuentra activa.
• En la cuarta etapa, Tacker inicia el proceso de monitorización de las condiciones de estado de
todas las VNFs que se encuentran operativas con el objetivo de detectar fallos y ejecutar procesos de recuperación.
53
Tabla 2.1 NFVO NS API.
URI Method API
/v1.0/nsd GET List nsds: lists NSD names/IDs
/v1.0/nsd/<nsd_id> GET Show nsd: shows information of a specific NS /v1.0/nsd POST Create nsd: creates a NSD
/v1.0/nsd/<nsd_id> DELETE Delete nsd:deletes a specific NSD
/v1.0/ns GET List ns’: lists instantiated NS’ in NFV Orchestrator /v1.0/ns/<ns_id> GET Show ns: shows information of a specific NSD /v1.0/ns POST Create ns: creates a NS based on the ID
Tabla 2.2 VNFM API.
URI Method API
/v1.0/vnfds GET List vnfds: lists VNFDs stored in the catalog
/v1.0/vnfds/<vnfd_id> GET Show vnfd: shows information for a specified VNFD
/v1.0/vnfds POST Create vnfd: creates a VNFD entry based on the vnfd template /v1.0/vnfds/<vnfd_id> PUT Update vnfd: updates a given VNFD
/v1.0/vnfds/<vnfd_id> DELETE Delete vnfdany associated VNFs can be deleted.:Deletes a given VNFD. Only a VNFD without /v1.0/vnfs GET List vnfs: lists instantiated VNFs
/v1.0/vnfs/<vnf_id> GET Show vnf: shows information of a given VNF /v1.0/vnfs POST Create vnf: creates a VNF based on the VNFD
/v1.0/vnfs/<vnf_id> PUT Update vnf: updates a VNF based on user config file or data /v1.0/vnfs/<vnf_id> DELETE Delete vnf: deletes a given VNF
/v1.0/vnfs/<vnf_id>/resources GET List VNF resources: given VNF. Lists resources, such as VDU/CP, of a /v1.0/vnfs/<vnf_id>/actions POST Trigger VNF scaling: Triggers VNF scaling action.
Tabla 2.3 VNFFG API.
URI Method API
/v1.0/vnffgd GET List vnffgds: lists VNFFGDs stored in the catalog /v1.0/vnffgd/<vnffgd_id> GET Show vnffgd: shows information of a given VNFFGD /v1.0/vnffgd POST Create vnffgd: creates a VNFFGD
/v1.0/vnffgd/<vnffgd_id> DELETE Delete vnffgd: without any associated VNFFGs can be deleted.deletes a given VNFFGD. Only a VNFFGD /v1.0/vnffg GET List vnffgs: lists instantiated VNFFGs
/v1.0/vnffg/<vnffg_id> GET Show vnffg: shows information of a given VNFFG /v1.0/vnffg POST Create vnffg: creates a VNFFG
/v1.0/vnffg/<vnffg_id> DELETE Delete vnffg: deletes a given VNFFG /v1.0/nfps GET List nfps: lists NFPs
/v1.0/nfps/<nfp_id> GET Show nfp: shows information of a given NFP /v1.0/sfcs GET List SFCs: lists active SFCs
/v1.0/sfcs/<sfc_id> GET Show SFC: shows information of a given SFC /v1.0/classifiers GET List classifiers: lists classifiers
54
• En la quinta etapa se procede a crear VNFFGs con diferentes VNFs que se encuentren en estado
operacional. El proceso a seguir es similar al utilizado en el despliegue de VNFs. Para ello, primero se debe crear un descriptor de VNFFG (VNFFGD) para incorporarlo al catálogo de NFV. Esto se consigue mediante el VNFFG API que permite especificar las operaciones CRUD relacionadas.
• En la sexta etapa se procede a crear una instancia de VNFFG mediante la creación de la ruta de
envío de red correspondiente y el clasificador requerido sobre la NFVI subyacente. Para realizar esta y otras operaciones CRUD también se utiliza el VNFFG API. Como se puede ver en la Figura 2.18, Tacker incorpora un controlador de SFC destinado a encadenar las VNFs especificadas en el descriptor utilizando para ello el Networking-SFC API que proporciona Neutron en OpenStack de forma nativa.
• En la etapa final, se considera un eventual fallo de una VNF. En la política de monitorización
asociada a la VNF se especifica la acción a ser ejecutada cuando se detecta un fallo. Por ejemplo, se podría solicitar que se re-genere (re-spawning) la VM cuando no existe respuesta desde la VNF o ejecutar un proceso de escalamiento automático (auto scaling) para agregar o eliminar (scale out/in) instancias de VNF cuando la CPU de la VM alcanza un determinado umbral.