facultad de ciencias de la ingenierÍa e carrera de
TRANSCRIPT
UNIVERSIDAD UTE
FACULTAD DE CIENCIAS DE LA INGENIERÍA E
INDUSTRIAS
CARRERA DE INGENIERÍA INFORMÁTICA Y
CIENCIAS DE LA COMPUTACIÓN
IMPLEMENTACIÓN DE UN PROTOTIPO DE VIRTUALIZACIÓN
DE FUNCIONES DE REDES (NFV)
TRABAJO PREVIO A LA OBTENCIÓN DEL TÍTULO DE INGENIERO EN
INFORMÁTICA Y CIENCIAS DE LA COMPUTACIÓN
MIGUEL ÁNGEL CHORA VERDEZOTO
DIRECTOR: ING. SEGUNDO BOLIVAR JACOME CANCHIG
Quito, Agosto, 2020
© Universidad UTE. 2020
Reservados todos los derechos de reproducción
FORMULARIO DE REGISTRO BIBLIOGRÁFICO
TRABAJO DE TITULACIÓN
DATOS DE CONTACTO
CÉDULA DE IDENTIDAD: 1723263271
APELLIDO Y NOMBRES: CHORA VERDEZOTO MIGUEL ÁNGEL
DIRECCIÓN: HUIGRA OE5-536 Y AJAVI
EMAIL: [email protected]
TELÉFONO FIJO: (02) 2842191
TELÉFONO MOVIL: (593) 998119525
DATOS DE LA OBRA
TÍTULO: IMPLEMENTACIÓN DE UN PROTOTIPO
DE VIRTUALIZACIÓN DE FUNCIONES
DE REDES (NFV)
AUTOR O AUTORES: CHORA VERDEZOTO MIGUEL ÁNGEL
FECHA DE ENTREGA DEL
PROYECTO DE TITULACIÓN:
10 DE AGOSTO DE 2020
DIRECTOR DEL PROYECTO DE
TITULACIÓN:
SEGUNDO BOLIVAR JACOME
CANCHIG
PROGRAMA PREGRADO POSGRADO
TÍTULO POR EL QUE OPTA: INGENIERO EN INFORMÁTICA Y
CIENCIAS DE LA COMPUTACIÓN
RESUMEN: Mínimo 250 palabras El proyecto tiene como objetivo
principal la implementación de un
prototipo de virtualización de funciones
de red NFV a través de la configuración
de máquinas virtuales, mediante una
arquitectura de virtualización Bare-
Metal, con un hypervisor tipo 1
embebido dentro de una plataforma de
virtualización, demostrando la
reducción de costos en recursos
hardware mediante una red virtual.
Para el desarrollo del proyecto se
X
utilizó la metodología Top Down
Network Design dividiendo el problema
general en una serie de procedimientos
de optimización integrados entre sí,
manteniendo una estructura clara y
concisa basado en el esquema principal
del proyecto. Toda la implementación
cuenta con licenciamiento libre
OpenSource basado en el ámbito de
sistemas y plataformas Linux, su
estructura lógica está conformada por
un clúster virtual en ProxMox
incluyendo las funciones de red
virtualizadas y una de red SDN
simulada en Mininet con enlace de
conexión al controlador OpenDylight.
Con el fin de cumplir con el objetivo
planteado el administrador de la
infraestructura podrá gestionar todos
los recursos a su alcance a través del
módulo de orquestación que posee
ProxMox, permitiendo tener un control
del ciclo de vida de cada función de red
mediante el monitoreo en vivo de todas
las máquinas virtuales implementadas.
Por otra parte, el prototipo expone la
reducción de costos en recursos
hardware que una arquitectura de red
tradicional puede generar, ya que
permite virtualizar y configurar
cualquier función de red mediante el
software que estas utilicen en las
máquinas virtuales, ofreciendo una
infraestructura escalable, concisa y
disponible ante cualquier cambio o
imprevisto que se pueda presentar.
PALABRAS CLAVES: Función de red, computación en la
nube, ProxMox, SDN, OpenFlow,
Mininet.
ABSTRACT:
This project has like main objective the
implementation of network functions
virtualization prototype NFV trough
virtual machine configuration, through
a Bare-metal virtualization architecture
with a virtualization platform which
include a hypervisor type 1, showing
the cost reduction through a virtual
network
The project development used Top
Down Network Design methodology
dividing the main issue in many
optimization procedures integrated
between all of them, keeping a clear and
fixed structure based on the main idea
of this project. The entire
implementation has free OpenSource
licensing based on the scope of Linux
systems and platforms, its logical
structure is made up of a virtual clúster
in ProxMox including virtualized
network functions and a simulated SDN
network in Mininet with connection link
to the OpenDylight controller .
In order to meet the proposed objective,
the infrastructure administrator will be
able to manage all the resources in the
scope through the orchestration
module that ProxMox has, allow to have
control of the life cycle of each network
function through live monitoring of all
deployed virtual machines.
In other side, the prototype exposes the
reduction of hardware resources costs
that a traditional network architecture
can generate, since it allows to
virtualize and configure any network
function through the software they use
in virtual machines, offering a scalable,
concise infrastructure and available for
any change or unforeseen event that
may arise.
KEYWORDS
Network function, cloud computing,
ProxMox, SDN, OpenFlow, Mininet.
Se autoriza la publicación de este Proyecto de Titulación en el Repositorio Digital de
la Institución.
__________________________________________
CHORA VERDEZOTO MIGUEL ÁNGEL
C.I. 172326327-1
DECLARACIÓN Y AUTORIZACIÓN
Yo, CHORA VERDEZOTO MIGUEL ÁNGEL, CI 1723263271 autor/a del
trabajo de titulación: Implementación de un prototipo de virtualización de
funciones de redes (NFV), previo a la obtención del título de INGENIERO
EN INFORMÁTICA Y CIENCIAS DE LA COMPUTACIÓN en la Universidad
UTE.
1. Declaro tener pleno conocimiento de la obligación que tienen las
Instituciones de Educación Superior, de conformidad con el Artículo
144 de la Ley Orgánica de Educación Superior, de entregar a la
SENESCYT en formato digital una copia del referido trabajo de
titulación de grado para que sea integrado al Sistema Nacional de
información de la Educación Superior del Ecuador para su difusión
pública respetando los derechos de autor.
2. Autorizo a la BIBLIOTECA de la Universidad UTE a tener una copia
del referido trabajo de titulación de grado con el propósito de generar
un Repositorio que democratice la información, respetando las
políticas de propiedad intelectual vigentes.
Quito, 10 de Agosto de 2020
__________________________________________
CHORA VERDEZOTO MIGUEL ÁNGEL
C.I. 1723263271
CERTIFICACIÓN DEL TUTOR
En mi calidad de tutor, certifico que el presente trabajo de titulación que lleva
por título Implementación de un prototipo de virtualización de funciones
de redes (NFV) para aspirar al título de INGENIERO EN INFORMÁTICA Y
CIENCIAS DE LA COMPUTACIÓN fue desarrollado por CHORA
VERDEZOTO MIGUEL ÁNGEL, bajo mi dirección y supervisión, en la
Facultad de Ciencias de la Ingeniería e Industrias; y que dicho trabajo
cumple con las condiciones requeridas para ser sometido a las evaluación
respectiva de acuerdo a la normativa interna de la Universidad UTE.
_______________________________________
SEGUNDO BOLIVAR JACOME CANCHIG
DIRECTOR DEL TRABAJO
C.I. 1707004618
DECLARACIÓN JURAMENTADA DEL AUTOR
Yo, CHORA VERDEZOTO MIGUEL ÁNGEL, portador(a) de la cédula de
identidad Nº 1723263271, declaro que el trabajo aquí descrito es de mi
autoría, que no ha sido previamente presentado para ningún grado o
calificación profesional; y, que he consultado las referencias bibliográficas
que se incluyen en ese documento.
La Universidad UTE puede hacer uso de los derechos correspondientes a
este trabajo, según lo establecido por la Ley de Propiedad Intelectual, por su
Reglamento y por la normativa institucional vigente.
__________________________________________
CHORA VERDEZOTO MIGUEL ÁNGEL
1723263271
i
ÍNDICE DE CONTENIDOS
PÁGINA
RESUMEN 1
ABSTACT 2
1. INTRODUCCIÓN 3
2. METODOLOGÍA 21
2.1. MÉTODO DE DESARROLLO 22
2.1.1. FASE DE IDENTIFICACIÓN O ANÁLISIS 22
2.1.2. FASE DE DISEÑO 22
2.1.3. FASE DE DESARROLLO 22
2.1.4. FASE DE TESTEO 22
2.1.5. FASE DE MANTENIMIENTO 24
3. RESULTADOS Y DISCUSIÓN 26
3.1. ANÁLISIS DE RESULTADOS 26
3.1.1. FASE DE ANÁLISIS 26
3.1.2. FASE DE DISEÑO 29
3.1.3. FASE DE DESARROLLO 31
3.1.4. FASE DE TESTEO 54
4. CONCLUSIONES Y RECOMENDACIONES 63
4.1. CONCLUSIONES 63
4.2. RECOMENDACIONES 65
BIBLIOGRAFÍA 68
ANEXOS 72
ii
ÍNDICE DE TABLAS
PÁGINA
Tabla 1. Tabla comparativa de hypervisores conocidos 28
Tabla 2. Tabla comparativa sistemas operativos Linux 29
Tabla 3. Direccionamiento IP 31
iii
ÍNDICE DE FIGURAS
PÁGINA
Figura 1. Estructura básica de la arquitectura de la tecnología NFV 4
Figura 2. Dispositivos de red separados vs funciones de red virtualizadas en un solo servidor. 9
Figura 3. Marco de referencia NFV (Zurita, 2019) 11
Figura 4. Evolución de las cifras de negocio de los servicios NFV y SDN a nivel mundial de 2015 a 2019, por área geográfica (Statistica, 2020) 12
Figura 5. Arquitectura SDN (Huawei, 2020) 13
Figura 6. Estructura de funcionamiento Hypervisores tipo 1 y 2 (HostDime, 2020) 17
Figura 7. Diseño Físico - Prototipo NFV 30
Figura 8. Topología Lógica - prototipo NFV 31
Figura 9. Compatibilidad de Sistemas Operativos convencionales con ProxMox. 32
Figura 10. Interfaz General del Clúster en ProxMox 33
Figura 11. Ejemplo de alta disponibilidad en ProxMox. 34
Figura 12. Monitoreo en vivo de los recursos de todo el Datacenter virtual 35
Figura 13. Clúster creado en ProxMox. 35
Figura 14. Características físicas del servidor detalladas en ProxMox. 36
Figura 15. Opciones de configuración de ProxMox. 37
Figura 16. Almacenamiento “local” y “local-lvm” de todo el Clúster. 37
Figura 17. Almacenamiento local del nodo pxe. 38
iv
Figura 18. Almacenamiento “local-lvm” del nodo pxe. 38
Figura 19. Backup de Máquinas Virtuales. 39
Figura 20. Restore de una Máquina Virtual 40
Figura 21. Migración en Vivo de una Máquina Virtual 40
Figura 22. Configuración de Firewall en el Clúster 41
Figura 23. Reglas de Firewall en el Nodo Primario 42
Figura 24. Reglas de Firewall a nivel de Máquina Virtual 42
Figura 25. Autenticación de usuarios en ProxMox. 43
Figura 26. Recursos de la función de red que se ejecutada como Firewall. 44
Figura 27. Recursos de la función de red que se ejecutada como Firewall. 44
Figura 28. Línea de comandos del nodo pxe. 45
Figura 29. Networking virtual desplegado en el servidor físico 45
Figura 30. Consola virtual de la primera función de red DNS 46
Figura 31. Consola virtual de la primera función de red DNS 46
Figura 32. Consola virtual de la segunda función de red WEB 47
Figura 33. Interfaz gráfica demostrativa de funcionalidad del servicio WEB 47
Figura 34. Consola virtual de la tercera función de red Firewall 48
Figura 35. Interfaz gráfica demostrativa de funcionalidad del servicio Firewall 48
Figura 36. Consola virtual de la cuarta función de red Aplicaciones 49
v
Figura 37. Interfaz gráfica demostrativa de funcionalidad del servicio de Aplicaciones 49
Figura 38. Interfaz gráfica ejecución del controlador OpenDylight en Ubuntu 20.04 50
Figura 39. Interfaz gráfica ejecución de la red virtual desarrollada en Python y ejecutada a través de Mininet en Ubuntu 18.04 51
Figura 40. Interfaz gráfica de las 3 máquinas host creadas a través de Mininet en Ubuntu 18.04 51
Figura 41. Interfaz gráfica web del controlador OpenDylight junto con la topología integrada con Mininet 52
Figura 42. Interfaz gráfica web del controlador OpenDylight apartado YangVisualizer 52
Figura 43. Interfaz gráfica del controlador OpenDylight con el despliegue de la topología virtualizada en Mininet. 53
Figura 44. Dispositivos creados en ProxMox enlazados al switch virtual creado en mininet. 54
Figura 45. Interfaz gráfica de conectividad entre funciones de red en ProxMox 54
Figura 46. Interfaz gráfica de conectividad entre funciones de red en ProxMox 55
Figura 47. Pruebas de conectividad terminal en Ubuntu 20.04 56
Figura 48. Análisis de tráfico de datos mediante Wireshark 56
Figura 49. Prueba de conectividad de Firewall, IP segura 57
Figura 50. Acceso de IP en el archivo ui.allow, para acceder a la interfaz web del Firewall CSF 57
Figura 51. Login de acceso a la interfaz gráfica del firewall CSF desplegado en ProxMox 58
vi
Figura 52. Interfaz gráfica del servicio de aplicaciones LogicalDoc desplegad en ProxMox 58
Figura 53. Interfaz gráfica de la terminal del host 1 de la red en mininet 59
Figura 54. Interfaz gráfica de la terminal del host 2 de la red en Mininet 59
Figura 55. Interfaz gráfica de la terminal del host 3 de la red en Mininet 60
Figura 56. Interfaz gráfica del controlador OpenDylight con el flujo de datos de los hosts implementados. 60
Figura 57. Interfaz gráfica de Wireshark, como prueba de flujos de datos y protocolos de envío y recepción mediante OpenFlow 61
vii
ÍNDICE DE ANEXOS PÁGINA
Anexo 1 INSTALACIÓN DE PROXMOX VE 6.2 72
Anexo 2 CREAR UNA MÁQUINA VIRTUAL EN ProxMox 77
Anexo 3 BACKUP DE MÁQUINAS VIRTUALES 82
Anexo 4 CREACIÓN DE USUARIOS Y PERMISOS EN PROXMOX 83
Anexo 5 SCRIPT CLI – FUNCIÓN DE RED DNS 84
Anexo 6 SCRIPT CLI – FUNCIÓN DE RED WEB 86
Anexo 7 SCRIPT CLI – FUNCIÓN DE RED APP 88
Anexo 8 SCRIPT CLI – FUNCIÓN DE RED FIREWALL 90
Anexo 9 CARACTERÍSTICA MÍNIMAS PARA LA INSTALACIÓN DE MININET Y OPENDYLIGHT 91
Anexo 10 INSTALACIÓN DEL SIMULADOR VIRTUAL DE REDES SDN MININET 92
Anexo 11 INSTALACIÓN DEL CONTROLADOR OPENDYLIGHT 93
1
RESUMEN
El proyecto tiene como objetivo principal la implementación de un prototipo
de virtualización de funciones de red NFV a través de la configuración de
máquinas virtuales, mediante una arquitectura de virtualización Bare-Metal,
con un hypervisor tipo 1 embebido dentro de una plataforma de
virtualización, demostrando la reducción de costos en recursos hardware
mediante una red virtual.
Para el desarrollo del proyecto se utilizó la metodología Top Down Network
Design dividiendo el problema general en una serie de procedimientos de
optimización integrados entre sí, manteniendo una estructura clara y concisa
basado en el esquema principal del proyecto. Toda la implementación
cuenta con licenciamiento libre OpenSource basado en el ámbito de
sistemas y plataformas Linux, su estructura lógica está conformada por un
clúster virtual en ProxMox incluyendo las funciones de red virtualizadas y
una de red SDN simulada en Mininet con enlace de conexión al controlador
OpenDylight.
Con el fin de cumplir con el objetivo planteado el administrador de la
infraestructura podrá gestionar todos los recursos a su alcance a través del
módulo de orquestación que posee ProxMox, permitiendo tener un control
del ciclo de vida de cada función de red mediante el monitoreo en vivo de
todas las máquinas virtuales implementadas.
Por otra parte, el prototipo expone la reducción de costos en recursos
hardware que una arquitectura de red tradicional puede generar, ya que
permite virtualizar y configurar cualquier función de red mediante el software
que estas utilicen en las máquinas virtuales, ofreciendo una infraestructura
escalable, concisa y disponible ante cualquier cambio o imprevisto que se
pueda presentar.
Palabras Clave: Función de red, computación en la nube, ProxMox, SDN,
OpenFlow, Mininet.
2
ABSTRACT
This project has like main objective the implementation of network functions
virtualization prototype NFV trough virtual machine configuration, through a
Bare-metal virtualization architecture with a virtualization platform which
include a hypervisor type 1, showing the cost reduction through a virtual
network
The project development used Top Down Network Design methodology
dividing the main issue in many optimization procedures integrated between
all of them, keeping a clear and fixed structure based on the main idea of this
project. The entire implementation has free OpenSource licensing based on
the scope of Linux systems and platforms, its logical structure is made up of
a virtual clúster in ProxMox including virtualized network functions and a
simulated SDN network in Mininet with connection link to the OpenDylight
controller .
In order to meet the proposed objective, the infrastructure administrator will
be able to manage all the resources in the scope through the orchestration
module that ProxMox has, allow to have control of the life cycle of each
network function through live monitoring of all deployed virtual machines.
In other side, the prototype exposes the reduction of hardware resources
costs that a traditional network architecture can generate, since it allows to
virtualize and configure any network function through the software they use in
virtual machines, offering a scalable, concise infrastructure and available for
any change or unforeseen event that may arise.
Keywords: Network function, cloud computing, ProxMox, SDN, OpenFlow,
Mininet.
1. INTRODUCCIÓN
3
1. INTRODUCCIÓN
Actualmente las infraestructuras de red tradicionales buscan día a día
garantizar la integridad, confidencialidad y disponibilidad de la
información, reduciendo los riesgos y evitando de alguna manera un
incremento en sus costos. Por lo cual la implementación de tecnología
NFV (Network Function Virtualization o en español Virtualización de
Funciones de Red), se presenta como una solución óptima que
permite una mayor continuidad de trabajo, rendimiento y seguridad en
el manejo a través de una red virtualizada.
NFV permite desarrollar funciones de red, mediante software
eliminando dispositivos dedicados, tales como routers, switches,
firewalls, etc. (Mendoza Zambrano, 2016). El escenario que exhibe
NFV representa un gran salto para la evolución de nuevas
tecnologías, refiriéndose a nuevos retos de migración de IPV4 a IPV6,
el IoT (Internet de las Cosas), el Big Data, redes de quinta generación
(5G), ciudades inteligentes.
Realizar cambios estructurales a nivel de hardware hace que los
costos se minimicen en una sobrecompra de equipos innecesarios en
la mayoría de los casos, hoy en día las redes informáticas buscan una
mayor exigencia sin tomar en cuenta los recursos físicos utilizados.
Los servicios basados en NFV procesan varias funciones
interconectadas en un mismo servidor físico, procesando el tráfico en
la red a través de VNFs (Virtualized Network Functions o en español
Funciones de Red Virtualizadas). (Kouchaksaraei, Tavernier, Rossem,
& Peuster, 2017).
Por lo tanto el prototipo NFV pretende demostrar una solución
directamente a las restricciones que presentan las redes tradicionales
en relación a la virtualización, además trae nuevos beneficios y una
transformación en la arquitectura, tomando en cuenta aspectos
esenciales como el diseño de la infraestructura de la red, sistemas
operativos nativos, escalabilidad del hardware, el software dedicado
4
para la representación de funciones de red, entornos dinámicos y
sobre todo una óptima administración y gestión centralizada mediante
el orquestador principal de toda la infraestructura.
La virtualización gestiona de mejor manera el hardware mediante un
hypervisor que simula y reasigna de forma inmediata los recursos a
los servicios de software a demanda. NFV propone que toda la
funcionalidad reside en los programas que se ejecuta en las funciones
de red virtuales y no en las máquinas. La Figura 1, simboliza una sola
plataforma de hardware que puede soportar múltiples dispositivos o
máquinas virtuales, que son fáciles de activar o desactivar según sea
necesario, permitiendo a los proveedores de servicios ejecutar su red
en servidores estándar en lugar de los propietarios. (Red Hat, 2020)
Figura 1. Estructura básica de la arquitectura de la tecnología NFV (Ciena, 2020)
La tecnología NFV cuenta con las siguientes características:
➢ Permite convertir las funciones de red que se ejecutan en el
hardware convencional a través de la virtualización, enfocándose
en el software que se configura en cada máquina virtual.
➢ Promueve el desarrollo e innovación de diferentes plataformas de
software enfocados al networking, admitiendo una administración
centralizada en la infraestructura de red.
➢ Utiliza servidores y equipos de uso general.
5
➢ Utiliza APIs (Interfaz de programación de aplicaciones) para su
desarrollo, que permite la intercomunicación con otras plataformas
de administración de red.
➢ Organiza y automatiza los servicios de red eficientemente de
manera centralizada.
➢ Evita sobre carga en una red, la virtualización facilita la expansión
y escalamiento al momento de ser requerido de acuerdo con las
necesidades.
➢ Los administradores de red manejan funciones de administración a
través de un sistema operativo que coordina los dispositivos
virtuales que se ejecutan en una red.
➢ Es parte de un cambio radical en la forma en que las redes de
hardware y software operan e interactúan actualmente.
➢ La facilidad de agregar una función de red es tan sencilla como
poner en marcha una nueva máquina virtual, por lo cual se puede
efectuar cuando sea necesario y conveniente.
Las siguientes ventajas:
➢ Permite una reducción de costos y ahorro de recursos hardware
inmersamente proporcional a las redes tradicionales de hoy en
día.
➢ Al necesitar menos hardware físico, se logra la consolidación de
los recursos, lo cual da como resultado una reducción de los
costos generales, energéticos y de espacio físico.
➢ Se puede ejecutar funciones de red en un hardware común, en
lugar de hacerlo en un hardware exclusivo dedicado para una
función en específico.
➢ Al desarrollar en equipos convencionales el espacio y potencia
puede alojar varias funciones de red compartiendo los recursos.
➢ Mantiene un control ágil y flexible en las redes comunicacionales,
mediante una administración centralizada en toda la
infraestructura virtualizada.
6
➢ Crear y mantener un servicio es tan fácil como crear una máquina
virtual de acuerdo con la necesidad de la infraestructura.
➢ Al tener una infraestructura virtual se puede gestionar de manera
ágil los recursos informáticos virtuales para cada servicio
virtualizado.
➢ La NFV ofrece a los proveedores la flexibilidad para ejecutar VNF
en diferentes servidores o para trasladarlas cuando cambian las
necesidades.
Y las siguientes desventajas:
➢ Vulnerabilidad y seguridad en la infraestructura al ser tecnología
en constante cambio.
➢ La falta de interoperabilidad comprobada de las soluciones
existentes.
➢ Características y funciones inconsistentes de las distintas
soluciones.
➢ La falta de confiabilidad y desempeño comprobada de las
soluciones actuales.
➢ Los gastos asociados a tecnologías de software para
virtualización.
Con NFV, los proveedores de servicios pueden ejecutar funciones de
red en hardware estándar debido a que están virtualizadas en un
único servidor. Esto significa que se necesita menos hardware físico,
lo que permite la consolidación de recursos que se traduce en espacio
físico, energía y reducciones de costos generales.
La arquitectura NFV según el ETSI (Instituto Europeo de Normas de
Telecomunicaciones) cuenta con las siguientes características:
➢ Funciones de red virtualizadas (VNF): son aplicaciones de
software que ofrecen funciones de red, como el uso compartido de
archivos, los servicios de directorio y la configuración de IP. (Red
Hat, 2020)
7
➢ Infraestructura de virtualización de las funciones de red
(NFVi): consiste en los elementos de la infraestructura (como la
informática, el almacenamiento y las conexiones de redes) de una
plataforma que permiten admitir el software, como un hipervisor
(por ejemplo, KVM) o una plataforma de gestión de contenedores,
los cuales son necesarios para ejecutar las aplicaciones de red.
(Red Hat, 2020)
➢ Gestión, automatización y organización de la red (MANO):
proporciona el marco para gestionar la infraestructura de NFV e
implementar VNF nuevas. (Red Hat, 2020)
Paralelamente mantiene tres tipos de administradores que verifican la
eficacia, midiendo y controlando los recursos de las NFV’s en
ejecución, tomando decisiones que permitan la estabilidad y
continuidad en el trabajo de cada servicio virtualizado en la
infraestructura de la red. A continuación, se detalla los paradigmas de
administración NFV:
➢ Orquestador MANO (Management and Network
Orchestration):
• Es el gestor que ordena la infraestructura de la red virtualizada
así también como las funciones de red virtualizadas.
• Arbitra el uso de recursos y redes comunes en un entorno de
virtualización
• Despliega y monitoriza las aplicaciones virtuales de red (VNF).
• Realiza las operaciones de escalado de las aplicaciones
virtuales de red (VNF)
➢ VIM (Virtualization Infraestructure Manager):
• Arbitra/Gestiona los recursos de una NFVI en un dominio
• Gestiona el ciclo de vida de los recursos en un dominio NFVI.
Crear, mantiene y eliminar MV (Virtual Machine o Máquina
8
Virtual en español).
• Mantiene el inventario de MV asociadas a los recursos físicos.
• Gestión de rendimiento y fallos en el hardware, software y
recursos superiores
• Mantiene northbound APIs, por lo que expone los recursos
físicos y virtuales disponibles a otros sistemas de gestión
superiores.
➢ VNF (Virtual Network Function Manager):
• Gestiona el ciclo de vida de una VNF: Crea mantiene y
termina/elimina instancias VNF.
• Es el responsable del FCAPS (Fault Configuration, Acouting,
Perfomarce and Security Management), de las VNFs
• Escala las VNFs (scale up/scale down) lo que resulta en
escalar el uso de CPU, memoria y recursos hardware.
➢ Orquestador:
• Orquestador de servicios:
▪ Crear servicios E2E formados por distintas VNFs
▪ Puede instanciar VNFMs
• Orquestador de recursos:
▪ Coordina, autoriza, comunica y emplea recursos NFVI
entre diferentes infraestructuras a través del VIM
correspondiente
La Figura 2 representa un cambio de funciones de red divididas en
varios dispositivos hardware a una nube de NFV’s interconectadas en
un mismo equipo central, separando la capa del hardware y software
dedicado. Por lo tanto, una NFV se define como funciones que
realizan los dispositivos de hardware (equilibradores de carga,
firewalls, enrutadores, conmutadores) y que se virtualizan cada vez
más como aplicaciones virtuales. Esta "de virtualización de función de
9
red" es una progresión natural de virtualización de servidores y
virtualización de red. (Docs.Microsoft, 2020)
Figura 2. Dispositivos de red separados vs funciones de red virtualizadas en un solo servidor (Huerta, 2015).
A continuación, se detalla algunas de las muchas funciones de red
que se pueden virtualizar en la tecnología NFV como parte de su
infraestructura:
➢ Firewall: Permite controlar la seguridad de redes privadas en
empresas o instituciones, con el fin de evitar el hacking de la red o
la infesta de virus maliciosos que sean capaces de dañar los
recursos informáticos o la red interna de una organización.
➢ Enrutadores (Router): Provee de una gran variedad de servicios
para interconectar redes, así como la salida de una red interna a
internet.
➢ Equilibrador de Carga: El balanceador de carga distribuye el
tráfico entrante entre varios destinos. Esto aumenta la
disponibilidad de las aplicaciones.
➢ Conmutadores (Switch): Interconecta varios dispositivos
mediante puentes de red, pasando los datos a través de su
dirección MAC.
➢ Servidores: Proporciona servicios y recursos mediante una
conexión establecida interna o externa a sus clientes según sea
necesario.
10
NFV permite que la infraestructura de una red genere, garantice y
gestione la escalabilidad y el control de las VNF de una forma estable
y flexible tomando en cuenta los recursos asignados a cada una. Los
atributos de una red virtualizada que deben ser tomados en cuenta
son:
➢ Infraestructuras escalables
Los recursos hardware adquiridos en la infraestructura basada en
la tecnología NFV debe tener la capacidad de escalar según sea
necesario y conveniente de acuerdo con un control y crecimiento
planificado y no planificado en función a los requerimientos que la
infraestructura de la red lo necesite.
➢ Costos de hardware y gastos de capital
Los costos de hardware y software siempre serán un punto de
relevancia, ya que dependerá de la sostenibilidad y el ciclo de
vida útil que la tecnología NFV nos puede proporcionar, de tal
forma que se debe estabilizar en un punto óptimo los gastos
asignados de acuerdo con el hardware que sea necesario.
➢ Elección del sistema operativo host y la capa de virtualización
El sistema operativo anfitrión de cada host en la infraestructura de
la red es de vital importancia ya que la compatibilidad para el
manejo y la conexión con el Hypervisor es transcendental para la
administración tomando en cuenta el licenciamiento y las
estructuras de soporte técnico que en el futuro puedan
presentarse.
➢ Diseño de las funciones de red
La elección y la implementación de las funciones de red escogidas
para virtualizar y gestionadas por un Hypervisor como control de la
virtualización genera un gran enfoque en la red ya que su
11
funcionalidad depende de su arquitectura diseñada desde su
inicio.
➢ Administración y Orquestación.
La administración en la tecnología NFV permitirá que pueda
interactuar con cualquier tipo de SDN, permitiendo el control y la
gestión de su arquitectura en el orden deseado, agregando o
creando instancias de acuerdo con la necesidad que presente la
infraestructura de la red.
La infraestructura base de la tecnología NFV está representada en
la Figura 3, de la cual se desplegó el diseño de la arquitectura del
prototipo, en base a la metodología aplicada. A continuación, se
presenta un esquema lógico acerca del desarrollo NFV.
Figura 3. Marco de referencia NFV (Zurita, 2019)
Virtualización NFV - Nacional e Internacional: NFV ha presentado
un gran cambio global desde su aparición, la figura 3 muestra la
evolución del negocio de servicios NFV y SDN en un cambio poco
12
exponencial en variación entre cada año, sin embargo, hasta el 2019
ya existe un gran salto en el desarrollo de esta tecnología en
comparación al 2015, denotando que NFV y SDN se presentan como
tecnologías prematuras en constante desarrollo y cambio hacia el
futuro de plataformas virtuales.
Figura 4. Evolución de las cifras de negocio de los servicios NFV y SDN a nivel mundial de 2015 a 2019, por área geográfica (Statistica, 2020)
Actualmente la región latinoamericana presenta un índice más bajo y
poco probable de gestión NFV y SDN, cabe destacar que el miedo y
la discrepancia a un gran cambio son aspectos que denotan el avance
y desarrollo en nuestra región para que las empresas empiecen a
crear arquitecturas nuevas basadas en eje a la virtualización. Pocas
son las compañías que actualmente despliegan una infraestructura
virtualizada, gran parte se basan en servidores de grandes
prestaciones que en mucho de los casos requieren de un cuidado
extremo para evitar daños físicos y evitar que toda la infraestructura
se venga abajo por daños ambientales.
Por otra parte, las redes definidas por software en un nivel inferior a
NFV se destaca por dividir la capa de control de la capa de aplicación
para introducir en el medio un controlador que gestiona la
infraestructura, CISCO define a las redes definidas por software de la
siguiente manera:
13
“Una red definida por software es una arquitectura diseñada para
hacer que una red sea más flexible y fácil de administrar, SDN
centraliza la gestión abstrayendo el plano de control de la función
de reenvío de datos en los dispositivos de red discretos (Cisco,
2020)”
Cabe recalcar que una SDN es una tecnología muy diferente a NFV,
pero ambas son complementarias una de la otra, ya que NFV en su
arquitectura viene delimitada por software que controla sus VNFs en
su capa de control. Por lo que, al implantar esta nueva tecnología
requiere que los desarrolladores realicen una serie de pasos
manuales. Se debe decidir qué funciones de red virtual usar en los
servicios, seleccionando las VNF’s existentes para reutilizar nuevos
servicios en base a la virtualización y el software elegido.
La arquitectura SDN se presenta en la Figura 5, demostrando las
capas que la componen mediante la comunicación del protocolo de
transferencia OpenFlow que es un protocolo de comunicaciones que
da acceso al plano de reenvío de un conmutador de red o enrutador a
través de la red (OpenDylight, 2020).
Figura 5. Arquitectura SDN (Huawei, 2020)
Elementos SDN: Una arquitectura SDN ofrece una red centralizada y
programable y consta de lo siguientes elementos:
14
➢ Un controlador, el elemento central de una arquitectura SDN, que
permite la administración y el control centralizados, la
automatización y la aplicación de políticas en entornos de red
físicos y virtuales. (Cisco, 2020)
➢ API en dirección sur que transmiten información entre el
controlador y los dispositivos de red individuales (como
conmutadores, puntos de acceso, enrutadores y firewalls). (Cisco,
2020)
➢ API en dirección norte que transmiten información entre el
controlador y las aplicaciones y motores de políticas, a las que una
SDN parece un único dispositivo de red lógico. (Cisco, 2020)
Además, cuenta con las siguientes características:
➢ Programabilidad de la red.
➢ Centralizar inteligencia y control lógicamente.
➢ Abstracción de la red.
➢ Las arquitecturas de SDN dan comienzo a una nueva era de
apertura.
➢ Función de seguridad más efectiva.
➢ Carga administrativa de la configuración y suministro de funciones
como calidad de servicios y seguridad.
Las siguientes ventajas:
➢ Optimización en el desempeño de la red.
➢ Optimización de costos operativos.
➢ Mejora de la seguridad de su infraestructura TI.
➢ Incremento de los puntos terminales en los dispositivos IoT.
➢ Mejora del consumo de ancho de banda de las aplicaciones.
➢ Menor costo.
➢ Mayor escalabilidad y flexibilidad.
➢ Gestión simplificada.
Y las siguientes desventajas:
15
➢ Los gastos asociados con nuevo hardware y sistemas de software.
➢ La falta de interoperabilidad comprobada de las soluciones
existentes.
➢ Características y funciones inconsistentes de las distintas
soluciones.
➢ La falta de confiabilidad y desempeño comprobada de las
soluciones actuales.
Mininet: Mininet es un emulador que crea redes virtuales con hosts,
conmutadores, controladores y enlaces virtuales. Crea una red virtual
realista, ejecutando kernel real, conmutador y código de aplicación, en
una sola máquina (VM, nube o nativa). Mininet también es una
excelente manera de desarrollar, compartir y experimentar con los
sistemas de red definidos por software (SDN). (Mininet, 2020)
Redes definidas por software (SDN) y virtualización de las
funciones de red (NFV): Al igual que las redes definidas por
software, NFV separa las funciones de red del hardware. NFV
proporciona la infraestructura en la cual puede ejecutarse el software
de la SDN. Además, ofrece a los proveedores la flexibilidad para
ejecutar funciones en diferentes servidores o para trasladarlas cuando
cambian las necesidades. Esta flexibilidad agiliza la prestación de
servicios y la distribución de aplicaciones por parte de los proveedores
de telecomunicaciones. (Red Hat, 2020)
Por ejemplo, si un cliente solicita una función de red nueva, se puede
poner en marcha una nueva máquina virtual (VM) que gestione esa
solicitud. Cuando la función ya no sea necesaria, se podrá retirar la
máquina virtual. Esto permite determinar el valor de un posible nuevo
servicio sin correr muchos riesgos. Pueden utilizarse en conjunto,
según lo que se quiera lograr, y ambas utilizan un hardware básico.
Con ellas, puede crear una arquitectura de red más flexible y
programable que utilice los recursos de manera eficiente.
16
Por lo tanto para que toda esta infraestructura NFV y SDN pueda
implementarse debe existir un hypervisor que gestione todos los
recursos para cada máquina virtual efectuada, los hypervisores tienen
la principal función de monitorear máquinas virtuales en una
determinada plataforma informática, el hypervisor es el encargado de
asignar los recursos virtuales a las VM, por ejemplo, los CPU,
memoria y disco que pueden ocupar cada máquina virtual.(Blenk,
Basta, Reisslein, & Kellerer, 2016).
Existen dos tipos de hypervisores llamados tipo 1 o también
mencionados como “nativos” ya que se ejecutan directamente en el
hardware del host para controlar y administrador máquinas virtuales
invitadas directamente con los recursos físicos, así mismo
hypervisores tipo 2 o también llamados “hypervisores hospedados”, ya
que se ejecutan en un sistema operativo principal como cualquier otro
programa.
Para esquematizar de una forma más intuitiva el concepto
mencionado anteriormente la figura 4, simboliza el funcionamiento de
un hypervisor tipo 1 o nativo representado por 3 capas; el hardware o
recursos físicos, la capa del hypervisor (orquestador de la
infraestructura) y finalmente las máquinas virtuales. Por otra parte, el
hypervisor tipo 2 se enfoca en una capa adicional después de los
recursos físicos, con un sistema operativo principal que alberga al
hypervisor como cualquier otro programa más del sistema.
17
Figura 6. Estructura de funcionamiento Hypervisores tipo 1 y 2 (HostDime, 2020)
A continuación, se detallan dos de los hypervisores más utilizados en
el ámbito profesional libres y pagados:
➢ KVM: Es un hipervisor de tipo 1 (sin sistema operativo). Todos los
hipervisores necesitan algunos componentes al nivel del sistema
operativo (por ejemplo, administrador de memoria, planificador de
procesos, pila de entrada o salida (E/S), controladores de
dispositivos, gestión de seguridad, pila de red y más) para ejecutar
las máquinas virtuales. KVM cuenta con todos estos componentes
porque es parte del kernel de Linux. Cada máquina virtual se
implementa como un proceso regular de Linux, programada por el
planificador estándar de Linux con hardware virtual dedicado como
tarjeta de red, adaptador de gráficos, CPU, memoria y discos.
(PROXMOX, 2020)
➢ VM Ware vSphere: VMware vSphere es la plataforma de
virtualización líder del sector para construir infraestructuras de
cloud. Permite a los usuarios ejecutar aplicaciones críticas para el
negocio con confianza y responder con mayor rapidez a las
necesidades empresariales.(Joos, 2017)
18
➢ Oracle VM Virtual Box: Es un potente producto de virtualización
x86 y AMD64 / Intel64 para uso empresarial y doméstico, es la
única solución profesional que está disponible gratuitamente como
software de código abierto a los términos de la versión de la
licencia GPL. (VirtualBox, 2020)
Una de las grandes plataformas de virtualización de alta disponibilidad
en el mercado y con licenciamiento libre OpenSource es ProxMox ya
que cuenta con las características necesarias para un desarrollo NFV.
ProxMox: Proxmox VE es una plataforma de código abierto completa
para la virtualización empresarial que integra estrechamente el
hipervisor KVM y los contenedores LXC, el almacenamiento definido
por software y la funcionalidad de red en una sola plataforma, y
gestiona fácilmente clústers de alta disponibilidad y herramientas de
recuperación ante desastres con en la interfaz de gestión web.
(PROXMOX, 2020)
A continuación, se muestra las características fundamentales:
Es una plataforma de virtualización que permite crear, implementar y
desarrollar infraestructuras de red virtualizadas mediante instancias
en máquinas virtuales como funciones de red. Permite crear
volúmenes, manejo de usuarios. Maneja un switch virtual que permite
troncalizar cualquier tipo de red que se maneje interna o
externamente.
➢ Proxmox VE es una potente plataforma de virtualización de
servidor de código abierto para administrar dos tecnologías de
virtualización: KVM (máquina virtual basada en el kernel) para
máquinas virtuales y LXC para contenedores, con una única
interfaz basada en la web. (PROXMOX, 2020)
➢ Integra herramientas para configurar la alta disponibilidad entre
servidores, almacenamiento definido por software, redes y
recuperación ante desastres. (PROXMOX, 2020)
19
➢ Utiliza tecnología de virtualización basada en contenedores; una
alternativa ligera a la virtualización completa de la máquina
porque ofrece una sobrecarga menor. (PROXMOX, 2020)
➢ Proxmox VE se basa en Debian GNU / Linux y utiliza un kernel de
Linux personalizado. (PROXMOX, 2020)
➢ Utiliza KVM que es la tecnología de virtualización de Linux líder en
la industria para la virtualización completa. (PROXMOX, 2020)
Basados en la página oficial de ProxMox el ambiente virtualizado para
una implementación real necesita como mínimo en hardware:
➢ 2GB de RAM para el SO.
➢ Memoria designada para invitados.
➢ Para Ceph o ZFS se requiere memoria adicional,
aproximadamente 1 GB de memoria por cada TB utilizada de
almacenamiento.
Y para un ambiente virtualizado de pruebas requiere de los siguientes
elementos:
➢ CPU: 64 bits (Intel EMT64 o AMD64)
➢ CPU / placa base compatible con Intel VT / AMD-V (para soporte
de virtualización completa KVM)
➢ Mínimo 1 GB de RAM
➢ Disco duro
➢ Una NIC
Empresas Españolas como MicroPyme, Oreka I.T, JMG Virtual
Consulting y empresas ecuatorianas como TICSECUADOR, QUANIX,
INNOVA SOLUTIONS se centran en el Cloud Computing para dar
soluciones de licenciamiento libre utilizando ProxMox como una
infraestructura de servicios para sus clientes.
La solución de un prototipo NVF mediante ProxMox permite realizar
una transformación de hardware de red, es decir que los elementos
20
de red dejan de ser dispositivos hardware y se convierten en
dispositivos de software encapsulados por instancias dentro de
máquinas virtuales; permitiendo un control exhaustivo de los recursos
asignados a cada máquina virtual implementada como servicio.
Por lo tanto, el objetivo general de este proyecto será el de
implementar un prototipo de virtualización de funciones de red NFV
con la configuración de máquinas virtuales mediante una arquitectura
de virtualización Bare-Metal, con un hypervisor tipo 1 embebido
dentro de una plataforma de virtualización, demostrando la reducción
de costos en recursos hardware mediante una red virtual.
Para lo cual es necesario primeramente fundamentar los contenidos
de la investigación mediante la revisión de artículos científicos,
publicaciones, trabajos de investigación relacionados, que den cuenta
del estado del arte de las nuevas tecnologías NFV, previa
implementación del prototipo de virtualización de funciones de red
NFV planteado. A continuación, se debe seleccionar una metodología
y aplicarla para el desarrollo del prototipo de virtualización a través del
análisis de metodologías existentes. Para luego Diseñar la topología
de red para la previa implementación del prototipo de virtualización
con base en la metodología seleccionada, y finalmente implementar y
configurar las funciones de red seleccionadas a través de máquinas
virtuales con la gestión y administración de recursos de un hypervisor.
1. METODOLOGÍA
22
2. METODOLOGÍA
La implementación de un prototipo de virtualización de funciones de
red soluciona grandes inconvenientes causados por la acumulación
de recursos físicos que requieren de una mayor demanda al momento
de realizar cambios estructurales en infraestructuras de redes de gran
tamaño en relación con el hardware. La transformación de
infraestructura en un enfoque basado en la virtualización de funciones
de red (NFV) permite que las redes virtualizadas sean mucho más
ágiles, eficaces y sobre todo adaptables a un entorno escalable.
2.1. MÉTODO DE DESARROLLO
Para el desarrollo de la implementación del prototipo de funciones de
Red se utilizará la metodología Top Down Network Design,
permitiendo desarrollar la infraestructura a través de normas que
permiten la estabilidad en el prototipo. El planteamiento de la
metodología escogida contempla una investigación fundamentada en
libros digitales, artículos científicos, artículos electrónicos y paginas
oficiales; dando sustento a cada una de las etapas del proyecto de
tesis, empezando con la etapa de identificación hasta culminar con la
etapa de testeo del prototipo de virtualización. A continuación, se
detalla la argumentación de la metodología resaltando las
características y fundamentos más importantes en el uso del proyecto
de tesis.
Actualmente Top Down es una de las metodologías más usadas en el
diseño de redes por su concepto de divide y vencerás, subdividiendo
el problema principal en subcategorías y priorizando el trabajo de
acuerdo a la complejidad del mismo, conllevando así la facilidad en el
trabajo para una mayor flexibilidad al momento de resolver cada uno
de los inconvenientes que se puedan presentar en el desarrollo del
proyecto. (LAGLA GALLARDO , 2019)
23
Las fases implementadas en el prototipado de acuerdo con la
metodología Top Down Network Design son las siguientes:
2.1.1. FASE DE IDENTIFICACIÓN O ANÁLISIS
Como parte del análisis y la identificación de todos los requerimientos
que el prototipo de virtualización de funciones de red demanda, está
la utilización de software con licenciamiento libre Open Source; todos
los complementos de software y hardware usados para el desarrollo
del proyecto, así como las configuraciones y herramientas necesarias
para la puesta en marcha del prototipo de virtualización de funciones
de red mediante máquinas virtuales a través de un Hypervisor que
administre toda la infraestructura virtual.
2.1.2. FASE DE DISEÑO
Una vez encontrado todos los requerimientos, ideas y necesidades
para el desarrollo, se inicia el diseño de la arquitectura de todo el
proyecto, tomando en cuenta los parámetros mencionados en el
estado del arte acerca de la infraestructura NFV, en esta fase se
desarrolla el diseño físico y lógico de la topología de red tomando en
cuenta los recursos que se identificaron en la fase de análisis.
2.1.3. FASE DE DESARROLLO
La fase de implementación y desarrollo del prototipo muestra y
ejecuta los resultados de la infraestructura ya en producción, en esta
fase se implementa la infraestructura virtual, funciones de red,
administración y demás funcionalidades de orquestación NFV.
Posteriormente en la fase de testeo se estima pruebas de todo el
prototipo desarrollado.
2.1.4. FASE DE TESTEO
En esta fase se realiza pruebas de funcionalidad y conectividad para
evitar la prolongación de errores dentro del prototipo, se realiza flujos
24
de control mediante Wireshark para analizar, controlar y verificar el
envío y recepción de datos dentro de toda la infraestructura de la red
virtualizada.
2.1.5. FASE DE MANTENIMIENTO
Esta fase no aplica en el esquema desarrollado, ya que al ser un
prototipo de prueba y no en producción no conlleva realizar un
mantenimiento adicional; sin embargo, se puede realizar una revisión
de toda la estructura de la red simulada para mejorar o corregir fallos
que altere la funcionalidad del modelo.
3. RESULTADOS Y DISCUSIÓN
26
3. RESULTADOS Y DISCUSIÓN
Esta fase detalla exhaustivamente el proceso de implementación y
desarrollo del prototipo de virtualización de Funciones de Red;
detallando la ejecución y resultados de toda la infraestructura NFV
implementada en los equipos físicos.
3.1. ANÁLISIS DE RESULTADOS
3.1.1. FASE DE ANÁLISIS
Tomando en cuenta los requerimientos mínimos de hardware y
software mencionados en el apartado teórico; se desarrolló un Clúster
virtual mediante la plataforma de virtualización ProxMox con las
siguientes características físicas y lógicas que se presentan a
continuación:
• Requerimientos Físicos
➢ Hardware en Producción
La implementación del prototipo cuenta con los siguientes
componentes físicos:
▪ Equipo Dell Intel Core I7 64 bits
▪ 8 GB de memoria RAM
▪ 1 HDD de 500 GB
▪ Laptop Sony Intel Core I7 64 bits
▪ 8 GB de memoria RAM
▪ 1 HDD de 500 GB
• Requerimientos Lógicos
Plataforma de Virtualización ProxMox – Hypervisor KVM Como base del desarrollo lógico de todo el prototipo NFV se utilizó
la plataforma de virtualización ProxMox en la que viene embebido
estrechamente el hypervisor tipo 1 KVM y los contenedores LXC,
27
el almacenamiento definido por software, funcionalidad de red y
herramientas de recuperación de desastres en la interfaz de
gestión web. ProxMox permite administrar fácilmente clústers de
alta disponibilidad proporcionando soluciones de cloud computing
con licenciamiento libre Open Source.
Posteriormente, la tabla 1, muestra una comparación de
características acerca de los componentes de hypervisores de
diferente índole y que recalca a KVM como una óptima solución,
ya que permite el acceso directo al hardware subyacente (y no a
otros sistemas operativos y controladores de dispositivos con los
que contentar), este tipo de hipervisor se considera el mejor en
rendimiento y el más eficiente para la informática empresarial, ya
que se plasma directamente con el hardware del equipo físico en
producción. ProxMox cuenta con componentes de orquestación
que permite gestionar el ciclo de vida de las funciones de red,
gestionar toda la infraestructura virtualizada, arbitrar de forma libre
el uso de recursos en torno a la virtualización, mantener alertas en
desarrollo y ejecución de cada máquina virtual ante cualquier
eventualidad que se pueda generar. La versión utilizada para el
prototipo es:
➢ Proxmox VE 6.2
ProxMox Posee un enfoque empresarial para virtualizar una
infraestructura TI, optimizando los recursos existentes con un
menor gasto y a su vez escalable a la hora de representar una
infraestructura NFV. Además, cuenta con tecnología líder en
virtualización Linux, posee amplias características y
configuraciones que permite crear todo un data center virtual a
través de la virtualización de VM y contenedores LXC permitiendo
virtualizar clústers de alta disponibilidad.
28
Tabla 1. Tabla comparativa de hypervisores conocidos
Funciones de Red Virtualizadas Para el despliegue de funciones de red operadas en el entorno de
virtualización de ProxMox, el sistema operativo Linux Centos 7 es
el principal SO de toda la infraestructura virtual, es un sistema
operativo de código robusto basado en el kernel GNU/Linux Red
Hat Enterprise, ofreciendo un sistema de clase empresarial con un
licenciamiento gratuito. Por lo que, a diferencia de otras versiones
de Linux, Centos es el ideal candidato para el desarrollo y
despliegue de las NFVs ya que es considerado extremadamente
estable e ideal para cargas de trabajo de misión crítica.
Sin embargo, Ubuntu no se queda atrás, ya que se destaca en el
ámbito funcional, por lo que el desarrollo SDN es administrado por
la versión desktop 20.0, esta versión es recomendada en la
página oficial de Open Dylight para el desarrollo y ejecución en el
ámbito SDN Open Source; subsiguiente, la tabla 2, expone un
análisis comparativo de características de sistemas Linux
recalcando a Centos como un sistema operativo de grandes
prestaciones permitiendo desarrollar servidores de cualquier indol
Características VirtualBox VMWare KVM
Conocimiento requerido para administración
Bajo Bajo
Medio
Integración video I/O Medio Alto Alto Capacidad para Virtualización
NO NO Si
Driver para los guest Ninguno Ninguno Ninguno Requerimientos del guest Ninguno Ninguno Ninguno Discos Raw Configuración
adicional Configuración
adicional Configuración
adicional Soporta Network Bridge Si Si Si Sistemas Operativos guest probados
Windows, Linux, Red Hat
Windows, Linux, Red Hat
Windows, Linux, Red Hat, Free BSD
Requiere configuración al actualizar el Kernel
Si Si Soporte de virtualización KVM
Escalabilidad Escalabilidad Mínima
Escalabilidad Limitada
Escalabilidad Alta
Licenciamiento Libre Licencia Libre
Rendimiento Medio Medio Alto
Virtualización empresarial Baja Medio Alto
29
y ajustándose a cargas de trabajo netamente altas y con un gran
rendimiento. Cada función de red virtualizada se encuentra
implementada de acuerdo con las características y recursos
necesarios en su sistema operativo base. La versión de Centos
utilizada es:
➢ Sistema Operativo Linux Centos 7
Tabla 2. Tabla comparativa sistemas operativos Linux
3.1.2. FASE DE DISEÑO
Tomando en cuenta la introducción teórica del proyecto, se realizó el
esquema físico y lógico de red final del prototipo, todo esto basado en
componentes hardware y software ya mencionado anteriormente en la
fase de análisis.
• Diseño Físico
El esquema que se representa en la Figura 7, simboliza el diseño
físico del prototipo final; cuenta con un equipo DELL y un equipo
Sony ambos conectados a un switch D-Link de 8 puertos con
salida al router del proveedor de servicios de internet (ISP) Netlife.
El equipo Dell es el encargado de virtualizar toda la arquitectura
principal del nodo 1 en ProxMox llamado PXE en el cual se
Distribución Tipo Usos Ciclo de Vida
CentOS Basado sobre Red Hat™ Enterprise Linux Mantenido por comunidad
Gratuita Servidores Est. trabajo Producción
10 años ·5½ años actualizaciones ·1 año mantenimiento ·3½ años parches críticos
Red Hat™ Enterprise Linux Mantenido por Red Hat, Inc.
Comercial Servidores Est. trabajo Producción
10 años ·5½ años actualizaciones ·1 año mantenimiento ·3½ años parches críticos 3 años soporte extendido
Ubuntu™ Server LTS Mantenido por Canonical
Gratuita Comercial
Servidores Producción
5 años
Debian™ Linux Mantenido por comunidad
Gratuita Multiuso Producción
Sin ciclos fijos 1 año tras siguiente versión estable
Fedora™ Mantenido por comunidad y Red Hat, Inc.
Gratuita Multiuso Vanguardia
12 a 18 meses
30
encuentran las funciones de red virtualizadas. Por otra parte, el
Equipo Sony designado al nodo 2 llamado PXE2 se encarga de
realizar pruebas de Back Up, replicaciones en vivo de VM ante
cualquier fallo y el desarrollo SDN para su conexión con las
funciones de red virtualizadas en el nodo 1.
Figura 7. Diseño Físico - Prototipo NFV
• Diseño Lógico
Tomando en cuenta los recursos disponibles en ambos equipos
mencionados anteriormente en la fase de análisis, la estructura
lógica está simbolizada en la figura 8, existen dos nodos físicos en
los cuales están montados ProxMox, obteniendo a PXE como el
nodo principal en el cual se encuentran las funciones de red
virtuales; DNS, WEB, FIREWALL-DHCP, APLICACIONES, GLPI
Y ZABBIX, mientras que PXE2 es el nodo secundario con el
despliegue SDN conformado por OpenDylight y Mininet. Además
de tener las pruebas de Back Up de máquinas virtuales,
replicaciones en vivo y conexión a las funciones de red virtuales
del nodo 1, todo esto dentro de la red LAN generada mediante la
conexión con el ISP (Proveedor de Servicios de Internet) Netlife.
31
Figura 8. Topología Lógica - prototipo NFV
Dentro del esquema lógico, la tabla 3 manifiesta la lista de direcciones
IP asignados a cada máquina física y virtual que forma parte de la
arquitectura del prototipo.
Tabla 3. Direccionamiento IP
Dispositivo IP Asignada Gateway
Servidor Dell (PXE) 192.168.100.8 192.168.100.1
Equipo Sony (PXE2) 192.168.100.19 192.168.100.1
NFV-DNS 192.168.100.111 192.168.100.1
NFV-WEB 192.168.100.112 192.168.100.1
NFV-APP 192.168.100.115 192.168.100.1
NFV-FIREWALL-DHCP 192.168.100.116 192.168.100.1
NFV-GLPI 192.168.100.136 192.168.100.1
NFV-ZABBIX 192.168.100.162 192.168.100.1
OPENDYLIGHT 192.168.100.134 192.168.100.1
MININET 192.168.100.135 192.168.100.1
3.1.3. FASE DE DESARROLLO
De acuerdo con la arquitectura NFV ProxMox representa el
Orquestador de toda la infraestructura virtual, ya que permite
gestionar, monitorear, respaldar, montar clústers y varias
funcionalidades más que se habilitan en el despliegue de la
administración virtual. La instalación y configuración de ProxMox se
representa en el Anexo 1.
32
COMPATIBILIDAD CON LA MAYORÍA DE SISTEMAS
OPERATIVOS
ProxMox permite virtualizar un sinnúmero de sistemas operativos
convencionales entre los más utilizados están Linux y Microsoft
Windows en todas sus versiones, Solaris, AIX, entre otros.
El proyecto al tener un enfoque al software libre todas las máquinas
virtuales con funcionalidades tienen como sistema operativo principal
Linux, entre las versiones más utilizadas tenemos:
• Centos en las versiones 7 y 8 con Interfaz Gráfica y Línea de
Comandos.
• Ubuntu en las versiones 18,19 y 20 con Interfaz Gráfica.
Sin embargo, como representación de la alta compatibilidad que
posee la plataforma se virtualizó un sistema operativo Windows
Server 2012 con Interfaz Gráfica como referencia de plataformas
Windows. La figura 9, representa un esquema de todos los sistemas
operativos implementados en el proyecto con ProxMox, el anexo 2
profundiza la creación y configuración de una máquina virtual y
contenedores LXC.
Figura 9. Compatibilidad de Sistemas Operativos convencionales con ProxMox.
33
ORQUESTACIÓN NFV EN PROXMOX - ALTA DISPONIBILIDAD
La interfaz gráfica final se exhibe en la figura 10, ejemplifica en detalle
toda la implementación final del prototipo, la interfaz web de ProxMox
especifica un Clúster virtual conformado por dos nodos físicos
representados en el diseño de la topología de red. El nodo principal
PXE contiene las funciones de red virtualizadas; DNS, WEB,
FIREWALL-DHCP, APP-ARCHIVOS, GLPI y ZABBIX bajo el sistema
operativo Centos 7, mientras que en el nodo secundario contiene el
desarrollo SDN conformado por el controlador OpenDylight y el
emulador Mininet bajo el sistema operativo Ubuntu 20.04. Los anexos
5,6,7,8 detallan la implementación de cada función de red virtual a
través de scripts en una interfaz de comandos, mientras que los
anexos 9,10 y 11 el desarrollo de OpenDylight y Mininet en la terminal
de Ubuntu.
Figura 10. Interfaz General del Clúster en ProxMox
Una de las características más grandes que dispone ProxMox es la
“Alta disponibilidad” en el clúster, por ejemplo: Si uno de los
“Servidores Físicos (NODO)” esta sobrecargado o sufre algún daño,
este transfiere automáticamente a otro “Servidor Físico (NODO)” con
34
menos carga. Para ejemplificar de mejor manera se desconectó
intencionalmente el cable de red del nodo 2 para que el clúster
detecte automáticamente un problema y comience la migración al
nodo 1, la figura 11 muestra el nodo 2 sin conexión, pero con la
máquina virtual NFV-DNS en migración hacia el nodo principal que
está disponible.
Figura 11. Ejemplo de alta disponibilidad en ProxMox.
ADMINISTRACIÓN CENTRALIZADA - MONITOREO EN VIVO En el Clúster se debe definir uno de los nodos como "Orquestador"
con el objetivo de centralizar el trabajo, sin embargo, cada nodo
cuenta con su propio administrador Web. La figura 12 muestra el
monitoreo en vivo de todo el datacenter virtual conformado en este
caso por los dos nodos físicos y que gráficamente se representa con
el siguiente estatus:
• El apartado health muestra todos los nodos en línea y los nodos
desconectados.
• El apartado guest muestra las máquinas virtuales en línea,
apagadas o con error.
• El apartado nodes, muestra los nodos activos con todas sus
capacidades físicas asignadas.
• El apartado resources, muestra el porcentaje de recursos
utilizados dentro de todo el datacenter.
35
• El apartado subscriptions, indicara alguna suscripción de proxmox
si fuera el caso.
Los recursos físicos utilizados muestran un porcentaje de uso de
acuerdo con la necesidad de cada nodo en ejecución y subyacente a
este a las necesidades de cada máquina virtual en ejecución y
rendimiento.
Figura 12. Monitoreo en vivo de los recursos de todo el Datacenter virtual
En el apartado Clúster se muestra los nodos conectados al datacenter
virtual, se puede añadir varios nodos al Clúster mediante línea de
comandos siempre y cuando se encuentren con el nombre indicado,
la versión y zona horaria en sincronización. La figura 13 señala el
Clúster implementado con los dos nodos físicos en producción
asociados a un ID y una IP asignada.
Figura 13. Clúster creado en ProxMox.
36
Celph-nautilus es una de las características más avanzadas en
storage de ProxMox ya que permite implementar una red de fibra de
aproximadamente 10 gigabit con discos RAID, desarrollando una
infraestructura veloz, confiable y robusta, permitiendo que el
administrador de la infraestructura administre copias, respaldos,
imágenes de una manera bastante rápida y sobre todo confiable ante
fallos en almacenamiento. La figura 14 nos muestra la instalación de
la característica Celp Nautilus, característica que se puede
implementar en infraestructuras virtuales de gran escala y con
grandes servicios en producción.
Figura 14. Características físicas del servidor detalladas en ProxMox.
El apartado de “options” muestra el idioma del teclado, la redirección
de proxy, el tipo de viewer de las máquinas virtuales que por defecto
utiliza No-VNC, un email que envía alarmas por correo electrónico
configurado en ProxMox en relación ante algún evento suscitado en la
infraestructura virtual.
La figura 15 puntualiza las iniciativas del datacenter, permitiendo
cambiar las opciones de acuerdo con las necesidades de la red.
37
Figura 15. Opciones de configuración de ProxMox.
ALMACENAMIENTO DEFINIDO POR SOFTWARE Proxmox soporta almacenamiento local con el grupo LVM, el
directorio y ZFS, así como tipos de red de almacenamiento con iSCSI,
Canal de fibra, NFS, GlusterFS, CEPH. El apartado “Storage”
expuesto en la figura 16, señala las unidades locales de ProxMox. La
unidad “Local” contiene las copias de seguridad de las máquinas
virtuales, las ISO almacenadas de todo el nodo, en este caso la
imagen de Centos 7 y Ubuntu 20.04. Así mismo se puede crear
containers que se generan a través de máquinas virtuales
previamente configuradas y conocidas como “templates” en diferentes
formatos virtuales.
Figura 16. Almacenamiento “local” y “local-lvm” de todo el Clúster.
38
La figura 17, evidencia el almacenamiento local, por defecto es
asignado 120 GB en la partición principal, mientras que el disco LVM
posee el restante del almacenamiento del nodo.
Figura 17. Almacenamiento local del nodo pxe.
Al observar la figura 18, el disco “local-lvm” contiene el tamaño
restante del disco físico. El formato de disco asignado es LVM-Thin,
ya que permite crear máquinas virtuales más grandes que el disco
duro total del nodo, claro está que las VM ocuparán los recursos de
acuerdo con la capacidad del disco del equipo físico.
Figura 18. Almacenamiento “local-lvm” del nodo pxe.
BACKUP & MIGRACIÓN EN VIVO DE "MÁQUINAS VIRTUALES"
El apartado Backup tal como se expone en la figura 19, muestra un
ejemplo de copia de seguridad de las funciones de red virtualizadas,
permitiendo tener una gran disponibilidad ante el peor de los
escenarios en relación a problemas que se pueda generar en el
clúster, cabe aclarar que cada máquina virtual cuenta con su
39
respectiva copia de seguridad. El anexo 3 muestra el procedimiento
de Backup de una VM.
Figura 19. Backup de Máquinas Virtuales.
De la misma manera al tener una administración centralizada, basta
con presionar el botón restore de la máquina virtual que necesitamos
recuperar el ultimo backup para recuperar el ultimo estado en firme de
la máquina virtual en caso de alguna falla. La figura 20, representa la
recuperación de la máquina virtual Ubuntu, mediante su copia de
seguridad, de la misma manera se puede efectuar una copia de
seguridad de forma inmediata o dejarlo programado.
40
Figura 20. Restore de una Máquina Virtual
De la misma manera es posible realizar migración en vivo de
máquinas virtuales, sin la necesidad de apagar o hacer algún cambio
en la máquina virtual, demostrando la alta disponibilidad que posee
ProxMox. La figura 21 muestra la migración en vivo de la máquina
virtual que alberga la función de red DNS.
Figura 21. Migración en Vivo de una Máquina Virtual
41
AUTENTICACIÓN Y FIREWALL Proxmox proporciona una manera fácil de proteger la infraestructura
mediante el firewall que tiene embebido, es posible definir reglas para
todas las máquinas virtuales o definir reglas precisas a una máquina
virtual. ProxMox Facilita la configuración del firewall a nivel general
del clúster, por nodo o a su vez por máquina virtual. La figura 22
muestra 2 reglas de firewall que fueron configuradas a nivel general
de todo el clúster.
Figura 22. Configuración de Firewall en el Clúster La figura 23 muestra la configuración a nivel general únicamente en el
nodo primario, con reglas establecidas en protocolos de
comunicación.
42
Figura 23. Reglas de Firewall en el Nodo Primario
De la misma manera se puede realizar el bloqueo a través de Firewall
mediante cada Máquina Virtual, si ese fuese el caso, la figura 24
muestra reglas de protocolo configuradas para la máquina virtual que
alberga a la función de red WEB.
Figura 24. Reglas de Firewall a nivel de Máquina Virtual
Así mismo se puede definir la autenticación de acceso al área de
"Administración a los Nodos" a través de cuentas propias con
Proxmox. La figura 25, representa los usuarios que almacena el
clúster y que pertenecen a un grupo llamado Tesis dentro del Pool de
prueba Administrador, cada usuario tiene permisos y roles diferentes
para administrar la plataforma.
43
Figura 25. Autenticación de usuarios en ProxMox.
CONFIGURACIONES DE RED Dentro de cada máquina virtual el administrador de red puede
monitorear, los recursos que se están siendo utilizados mediante
gráficas de rendimiento de todo el sistema operativo, las CPU que
utiliza el nodo, el tráfico de la red, la memoria RAM usada y una
muestra del total de los recursos disponibles a través de un mapa
general del monitoreo en vivo. La figura 26, evidencia el panorama
general de uno de los servicios de red, en este caso el Firewall CSF
que contiene dos tarjetas de red virtuales conectadas por un puente
de red a la tarjeta física que maneja el equipo. Proxmox administra las
tarjetas físicas a través de "Bridges" que comparte a las "Máquinas
Virtuales".
44
Figura 26. Recursos de la función de red que se ejecutada como Firewall.
ProxMox permite un despliegue escalable en cuanto a los recursos de
cada máquina virtual, permitiendo agregar almacenamiento,
networking y demás características relacionadas con la necesidad de
una función de red virtual. La figura 27, muestra las características
utilizadas en la creación de la máquina virtual que es utilizada como
función de red de MAIL.
Figura 27. Recursos de la función de red que se ejecutada como Firewall.
La figura 28, muestra la consola Shell del nodo PXE en la cual se
puede agregar varios nodos físicos al clúster virtual, realizar
actualizaciones del sistema y modificaciones recurrentes que sean
necesarias para un mejor desempeño en el sistema.
45
Figura 28. Línea de comandos del nodo pxe.
Todo el networking virtualizado se representa en la figura 29,
mostrando el nodo PXE que representa el equipo físico Dell.
Existe una sola interfaz física de red representada con el nombre
“eno1” y asociada a la IP que me otorga el servidor DHCP de mi
Proveedor de servicios de Internet Netlife, en este caso la IP
192.168.100.8 con Gateway 192.168.100.1 como puente de conexión
a la red externa. Además, existe una interfaz virtual asociada a la
subred 172.168.10.0/24 que representa la red interna de las funciones
de red del DHCP.
Figura 29. Networking virtual desplegado en el servidor físico
46
FUNCIONES DE RED
La figura 30, representa la primera función de red en la cual se
representó el servicio DNS. Se observa la consola de la máquina
virtual a través del viewer No-VNC y la IP asociada al servicio de red.
Figura 30. Consola virtual de la primera función de red DNS
La figura 31, exhibe el servicio DNS configurado en la máquina virtual
Centos 7 y que despliega un servicio Unbound configurado con la
subred 172.168.10.0/24 con DNS públicos de Google.
Figura 31. Consola virtual de la primera función de red DNS
La segunda función de red en la cual se virtualizo el servicio WEB
mediante WordPress como gestor de contenidos gráficos y con
almacenamiento en una base de datos con MariaDB, muestra el
47
servicio WEB que se aprecia en la consola de la máquina virtual
representada en la figura 32.
Figura 32. Consola virtual de la segunda función de red WEB
La figura 33, se asocia a la función de red Web desplegada en
ProxMox, la cual muestra una página web configurada en WordPress
como prueba de funcionamiento del servicio Web.
Figura 33. Interfaz gráfica demostrativa de funcionalidad del servicio WEB
La tercera función de red representada gráficamente en la figura 34,
que funciona lógicamente como Firewall y DHCP a la vez, muestra el
estatus del servicio DHCP a través de la consola de la máquina virtual
configurada en Centos 7.
48
Figura 34. Consola virtual de la tercera función de red Firewall
La figura 35, se asocia a la función de red del DHCP-Firewall
representado en la tercera máquina virtual con Centos 7, esta figura
muestra a través del navegador web la interfaz gráfica del firewall-
CSF configurado junto con el DHCP en la terminal de Centos.
Figura 35. Interfaz gráfica demostrativa de funcionalidad del servicio Firewall
La figura 36, representa la cuarta función de red en la cual se
representó la etapa de aplicaciones y que gráficamente muestra una
consola de la máquina virtual con la IP asociada y el servicio en
ejecución.
49
Figura 36. Consola virtual de la cuarta función de red Aplicaciones
La interfaz gráfica que muestra la figura 37, se asocia a la función de
red de aplicaciones desarrollado en la cuarta máquina virtual con
Centos 7; el panel web muestra a LogicalDOC un sistema de gestión
documental gratuito, que fue diseñado para gestionar y compartir
documentos en el interior de una organización. Este aplicativo fue
configurado como prueba de funcionalidad de virtualización a través
de software.
Figura 37. Interfaz gráfica demostrativa de funcionalidad del servicio de Aplicaciones
INTEGRACIÓN SDN CON NFV
Parte del prototipo implementado, las redes definidas por software son
piezas complementarias en la arquitectura NFV estas se integran
dentro del diseño como parte de la arquitectura desarrollada. La figura
50
38 muestra la ejecución del controlador OpenDylight en la terminal de
Ubuntu 20.04 previamente instalado y configurado en el anexo 11.
Figura 38. Interfaz gráfica ejecución del controlador OpenDylight en Ubuntu 20.04
El simulador de redes SDN-Mininet previamente configurado en el
anexo 10 muestra la simulación de un switch virtual conectado a los
equipos de la red que la conforman. La figura 39, muestra la ejecución
de la red programada en Python ejecutada mediante Mininet y
estructurada con un switch virtual OVS asociada a 3 máquinas host
con interfaces virtuales creadas en la VM de Ubuntu. La programación
del scrypt desarrollado en Python se acoge los parámetros del
controlador remoto OpenDylight, y el protocolo de transferencia de
datos OpenFlow.
51
Figura 39. Interfaz gráfica ejecución de la red virtual desarrollada en Python y ejecutada a través de Mininet en Ubuntu 18.04
Observamos en la figura 40, las terminales de los 3 host configurados
en el script de Mininet estos hosts pertenecen a una red 10.0.3.0/24
asignada automáticamente por el parámetro dhclient programado en
Python, sin embargo, esta subred virtual tiene conexión a la red
externa con las funciones de red en ProxMox a través del controlador
OpenDylight.
Figura 40. Interfaz gráfica de las 3 máquinas host creadas a través de Mininet en Ubuntu 18.04
Dentro del controlador OpenDylight observamos la red que se creó en
Mininet y que se puede monitorear a través del controlador verificando
el flujo de datos entre máquinas conectadas al switch virtual. La figura
41, muestra la topología gráfica de la red que se creó en Mininet.
52
Figura 41. Interfaz gráfica web del controlador OpenDylight junto con la topología integrada con Mininet
OpenDylight ofrece un sin número de APIS integradas y por desarrollar en
la integración con diferentes plataformas OpenSource compatibles con
OpenFlow. La figura 42, muestra Yang Visualizer uno de los componentes
gráficos que ofrece Dylight para observar la distribución del controlador
por etapas y nodos de conexión.
Figura 42. Interfaz gráfica web del controlador OpenDylight apartado YangVisualizer
53
La figura 43, representa el despliegue e integración entre Mininet,
OpenDylight y la conectividad con la red NFV desplegada en
ProxMox. Se aprecia que automáticamente un host adicional se
asigna a la topología mostrada en el controlador, ese host representa
el puente de conexión hacia la red externa mediante el controlador
OpenDylight con las interfaces asignadas a cada host virtual en el
script de Python.
Figura 43. Interfaz gráfica del controlador OpenDylight con el despliegue de la topología virtualizada en Mininet.
Por otra parte, se creó un script en Python el cual permite que los
dispositivos enlazados dentro de la red NFV se agregan al switch virtual a
través del controlador OpenDylight mediante la ejecución en Mininet.
La figura 44 muestra la topología que se despliega en el controlador con
las funciones de red conectadas al switch virtual.
54
Figura 44. Dispositivos creados en ProxMox enlazados al switch virtual creado en mininet.
3.1.4. FASE DE TESTEO
Pruebas de Conectividad
Como pruebas de conectividad se ejecutó el comando ping en una
terminal dentro de las funciones de red virtualizadas en ProxMox
hacia otras máquinas virtuales en la misma red. La figura 45, muestra
un ping de conexión hacia la función de red desplegada como Firewall
con la IP 192.168.100.116 y a la función de aplicaciones con la IP
192.168.100.115; vemos una conexión exitosa entre ambas
máquinas.
Figura 45. Interfaz gráfica de conectividad entre funciones de red en ProxMox
55
Así mismo la figura 46, exhibe la conectividad de la función de red
desplegada como DNS con conexión hacia el firewall, el servicio de
aplicaciones y servicio web. Demostrando que existe conectividad
entre todas las máquinas virtualizadas.
Figura 46. Interfaz gráfica de conectividad entre funciones de red en ProxMox
La figura 47, muestra una terminal en Linux Ubuntu, verificando la
conectividad con el comando PING hacia las funciones de red
desplegadas en ProxMox.
56
Figura 47. Pruebas de conectividad terminal en Ubuntu 20.04
El flujo de datos transmitidos hacia las funciones de red es
representado gráficamente en la figura 48 a través de Wireshark
generando un análisis de datos transmitidos desde el origen de las
máquinas virtuales hacia el destino en las funciones de red mediante
el protocolo ICMP con una conexión exitosa.
Figura 48. Análisis de tráfico de datos mediante Wireshark
Así mismo para verificar la conectividad con a la interfaz web del
firewall a ingresamos con la dirección IP asignada, mediante el puerto
57
1025 configurado previamente en el archivo de configuración csf.conf
dentro de la terminal de Centos 7. La figura 49, muestra una conexión
fallida ya que en el archivo de configuración ui.allow necesita la
configuración IP de la máquina en la cual se va acceder a la interfaz
web, sin realizar ese procedimiento no podremos acceder al firewall.
Figura 49. Prueba de conectividad de Firewall, IP segura
Una vez agregada la IP del host que se quiere acceder al firewall en el
archivo de configuración ui.allow, ya se obtendrá un acceso positivo a
través de la interfaz web. La figura 50, nos muestra el archivo de
configuración ui.allow el cual está configurado con 2 IP en el
segmento de red en el cual esta desplegado la función del firewall.
Figura 50. Acceso de IP en el archivo ui.allow, para acceder a la interfaz web del Firewall CSF
Siguiendo los pasos anteriores y como prueba de seguridad,
observamos en la figura 51, el login de la interfaz del CSF accediendo
desde la IP configurada en el archivo ui.allow anteriormente,
demostrando la segunda función de red desplegada como Firewall.
58
Figura 51. Login de acceso a la interfaz gráfica del firewall CSF desplegado en ProxMox
Finalmente, como prueba del funcionamiento del servicio de red de
aplicaciones abrimos un navegador en Ubuntu y a través de la IP
asignada observamos a LogicalDOC una aplicación web que gestiona
y comparte documentos en el interior de una organización. La figura
52, muestra el servicio web que se encuentra desplegado en la
función de red de aplicaciones.
Figura 52. Interfaz gráfica del servicio de aplicaciones LogicalDoc desplegad en ProxMox
59
CONECTIVIDAD SDN
La red desplegada en Mininet muestra la conectividad entre la red
virtual y la red implementada en ProxMox mediante el protocolo
OpenFlow La figura 53, muestra un ping de conectividad hacia la
función de red implementada en ProxMox que es el servicio WEB.
Figura 53. Interfaz gráfica de la terminal del host 1 de la red en mininet
La figura 54, muestra un ping de conectividad desde el nodo 2 hacia
la función de red implementada en ProxMox que vendría a ser el
servicio de red que funciona como Firewall.
Figura 54. Interfaz gráfica de la terminal del host 2 de la red en Mininet
60
La figura 55, nos muestra un ping de conectividad desde el nodo 3
hacia la función de red implementada en ProxMox que vendría a ser
el servicio de red que funciona como DNS.
Figura 55. Interfaz gráfica de la terminal del host 3 de la red en Mininet
Dentro del apartado de “nodes” en el controlador OpenDylight muestra
una tabla de todos los nodos conectados y flujos de datos emitidos
desde los hosts simulados y conectados al switch virtual.
La figura 56, muestra una tabla de los nodos asociados con un índice
de colisiones, flujo de datos fallidos, correctos, tamaño de bytes
enviados y recibidos desde el switch virtual hacia los nodos
virtualizados.
Figura 56. Interfaz gráfica del controlador OpenDylight con el flujo de datos de los hosts implementados.
61
Como prueba de conectividad de envío y recepción de datos
favorables observamos en la figura 57, que mediante WireShark el
protocolo de conectividad entre la capa de infraestructura virtual
Mininet y el controlador de aplicaciones OpenDylight se comunican
mediante el protocolo de transferencia de datos OpenFlow.
Figura 57. Interfaz gráfica de Wireshark, como prueba de flujos de datos y protocolos de envío y recepción mediante OpenFlow
4. CONCLUSIONES Y RECOMENDACIONES
63
4. CONCLUSIONES Y RECOMENDACIONES
4.1. CONCLUSIONES
• El prototipo NFV cuenta con un sistema de virtualización basado
en Linux Debian OpenSource bajo el Kernel del Hypervisor tipo 1
KVM como componente de administración y de orquestación; un
único servidor físico virtualiza toda una arquitectura virtual con
funciones de red desplegadas.
• La herramienta de virtualización (ProxMox) utilizada es muy
práctica para demostrar la potencialidad que puede alcanzar la
tecnología NFV y SDN, ya que destaca la flexibilidad y rapidez
para crear un nuevo servidor virtual en relación con otras
plataformas de virtualización con licenciamiento libre.
• Toda la infraestructura virtualizada se encuentra desarrollada en
dos equipos físicos por la limitación de recursos que se dispone,
demostrando la reducción de costos en recursos hardware en
producción y la escalabilidad de esta tecnología al demostrar que
las funciones de red virtualizadas reducen los dispositivos de
hardware a una gran escala.
• Actualmente tecnologías OpenSource se está volviendo tendencia
mundial en el aspecto tecnológico, ya que cada vez existe más
gente que se une a la comunidad para dar apoyo a proyectos de
gran escalabilidad como lo son las tecnologías NFV y SDN que
pueden generar una mayor infraestructura virtual y aún menor
costo.
• Infraestructuras virtuales están ganando una gran acogida en el
ámbito empresarial junto con tecnología definida por software,
generando alianzas entre empresas dedicadas al desarrollo de
software con empresas de cloud computing; generando así redes
64
de nueva generación a un menor costo y con un alto rendimiento
escalable.
• Las redes definidas por software centralizan tablas de flujo de
datos, simplificando el despliegue y la administración de la red,
mejorando notablemente el tiempo de trabajo del administrador de
red en el control y despliegue de grandes data centers virtuales.
• La reducción de costos es completamente evidente, varios
servidores físicos de grandes costos que están dedicados a
proporcionar una sola funcionalidad de red pueden convertirse y
unificarse para formar uno solo y desplegar toda una
infraestructura virtual al despliegue de varios servicios.
65
4.2. RECOMENDACIONES
• Es necesario realizar copias de seguridad de las máquinas
virtuales en producción, para tener un plan de contingencia ante
cualquier situación que se pueda suscitar, ProxMox ofrece tener
otro nodo en paralelo junto con el principal, ya que al tener algún
daño el nodo físico principal las máquinas virtuales
automáticamente comienza a migrar al nodo secundario.
• Es recomendable realizar tablas de contenidos acerca de los
datos, usuarios y contraseñas de todas las bases creadas en las
funciones de red para evitar la confusión entre sistemas y evitando
perder contratiempos con la recuperación de nuevos usuarios.
• Es importante realizar actualizaciones y configuraciones
necesarias del sistema previo a la instalación de cualquier
aplicativo implementado como OpenDylight, Mininet y las
funciones de red desplegadas en ProxMox a través de Centos 7,
se puede generar errores en el proceso de configuración e
interacción con las diferentes plataformas interconectadas con el
fin de desplegar los prototipos.
• Es de vital importancia realizar todas las pruebas con una red
interna en la cual se pueda realizar modificaciones con el fin de
tener un control del direccionamiento IP utilizado para evitar
confusiones y poseer un control total de la infraestructura
virtualizada.
• Se debe tomar en cuenta los recursos físicos asignados a cada
máquina virtual para que el Cluster implementado mantenga un
equilibrio de carga entre todos sus recursos, evitando usar al
mínimo la alta disponibilidad ante fallas que mantiene ProxMox.
66
• Se recomienda elaborar una estadística del funcionamiento de
cada máquina virtual del Cluster para prolongar la vida y
funcionamiento de todos los servicios virtuales desarrollados y así
prevenir riesgos futuros.
BIBLIOGRAFÍA
68
BIBLIOGRAFÍA
• Andrew s. Tanenbaum, & Stallings, W. (2003). Sistemas operativos:
aspectos internos y principios de diseño traducción y revisión técnica. In
Pearson education. Retrieved from
http://cotana.informatica.edu.bo/downloads/Sistemas Operativos.pdf
• Blenk, A., Basta, A., Reisslein, M., & Kellerer, W. (2016). Survey on
network virtualization hypervisors for software defined networking. IEEE
Communications Surveys and Tutorials, 18(1), 655–685.
https://doi.org/10.1109/COMST.2015.2489183
• Cisco. (2013). Cisco para medianas empresas Descripción general
Soluciones de virtualización de Cisco para medianas empresas. 1–6.
• Almiron, V. (2014). Redes :Administracion De Servidores. 320.
• Joos, T. (2017). VMware vSphere 6.5. VMware VSphere 6.5, 1–4.
https://doi.org/10.3139/9783446452978
• Kouchaksaraei, H. R., Tavernier, W., Rossem, S. Van, & Peuster, M.
(2017). A Network Service Development Kit Supporting the End-to-End
Lifecycle of NFV-based Telecom Services.
• Schneider, S., Peuster, M., Tavernier, W., & Karl, H. (2018). A Fully
Integrated Multi-Platform NFV SDK. 2018 IEEE Conference on Network
Function Virtualization and Software Defined Networks, NFV-SDN 2018,
(3), 1–2. https://doi.org/10.1109/NFV-SDN.2018.8725794
• VirtualBox, O. V. (2020). Virtual Box. Obtenido de
https://www.virtualbox.org/
69
• Funciones de red de. Docs.microsoft.com. (2020). Recuperado 12 Marzo
2020, desde https://docs.microsoft.com/es-es/windows-
server/networking/networking.
• HostDime. Premier Global Data Center. (2020). Obtenido de:
https://blog.hostdime.com.co/cual-es-el-hipervisor-bare-metal/
• Advisor. (2014). NFV Los beneficios y los desafíos que acompañan el
proceso de virtualización de funciones de red. Obtenido de
https://www.la.logicalis.com/globalassets/latin-
america/advisors/es/advisor-nfv.pdf
• Centos. (5 de Abril de 2020). Obtenido de https://www.centos.org/
• Ciena. (2020). Ciena. Obtenido de
https://www.ciena.com/insights/articles/What-is-NFV-prx.html
• Cisco. (1 de Abril de 2020). Cisco. Obtenido de
https://www.cisco.com/c/en/us/solutions/software-defined-
networking/overview.html
• Cisco Systems, I. (2012). Lo que usted necesita saber sobre routers y
switches. Obtenido de
https://www.cisco.com/c/dam/global/es_mx/assets/ofertas/desconectados
anonimos/routing/pdfs/brochure_redes.pdf
• Huawei. (24 de Julio de 2020). Huawei. Obtenido de
https://forum.huawei.com/enterprise/es/arquitectura-sdn-software-
defined-networking/thread/589066-100235
• Huerta, F. (18 de Marzo de 2015). Predicciones de telecomunicaciones
2015. Obtenido de
https://www2.deloitte.com/content/dam/Deloitte/es/Documents/tecnologia-
70
media-telecomunicaciones/Deloitte_ES_TMT_Predicciones-
telecomunicaciones-2015.pdf
• LAGLA GALLARDO , C. P. (2019). PROPUESTA DE REDISEÑO DE
RED DE DATOS DE LA EMPRESA COBRAFACIL FABRASILISA S.A
BAJO METODOLOGÍA PPDIOO Y DISEÑO TOP-DOWN. Quito.
• Mininet. (24 de Julio de 2020). Mininet. Obtenido de http://mininet.org/
• Pfsense. (5 de Abril de 2020). Obtenido de https://www.pfsense.org/
• PROXMOX. (23 de Julio de 2020). PROXMOX. Obtenido de PROXMOX:
https://proxmox.com/en/
• Red Hat. (7 de Abril de 2020). Obtenido de
https://www.redhat.com/en/topics/virtualization/what-is-nfv
• UBUNTU. (5 de Abril de 2020). Obtenido de https://ubuntu.com/
• VirtualBox, O. V. (2020). Virtual Box. Obtenido de
https://www.virtualbox.org/
• Zurita, A. (2019). Obtenido de
http://oa.upm.es/54213/1/TFG_ARTURO_ZURITA_SANCHEZ.pdf
• OpenDylight, (2020). OpenDylight. Obtenido de:
https://docs.opendaylight.org/en/stable-neon/index.html
ANEXOS
72
ANEXOS
Anexo 1
INSTALACIÓN DE PROXMOX VE 6.2
• Descargamos la imagen desde la página oficial de ProxMox:
https://proxmox.com/en/downloads
• Mediante una usb o disco booteable procedemos con la instalación de
ProxMox
• La pantalla principal de instalación se representa en la figura 58, en la
cual seleccionamos “Install Proxmox Ve”.
Figura 58. Pantalla principal de instalación de ProxMox.
• Damos click en el botón “I agree”, tal cual se observa en la figura 59.
73
Figura 59. Términos de condición ProxMox.
• Configuramos la red principal de ProxMox, la figura 60 muestra la
configuración de la red en la cual se representó ProxMox:
Figura 60. Configuración de red inicial de ProxMox.
• Configuramos la zona horaria ProxMox, la figura 61 muestra la
configuración de la zona horaria de la máquina de ProxMox.
74
Figura 61. Configuración de zona horaria ProxMox.
• Configuramos el usuario administrador ProxMox, la figura 62, muestra la
configuración de la contraseña y el email asignado para recibir
notificaciones.
Figura 62. Configuración de usuario administrador.
75
• Esperamos el proceso de instalación. La figura 63 muestra el proceso de
instalación en proceso.
Figura 63. Proceso de instalación de ProxMox
• Una vez finalizada la instalación, reiniciamos el equipo. La figura 64,
muestra el fin de la instalación con el URL por el cual podremos acceder
una vez reiniciado el equipo.
Figura 64. Instalación completa de ProxMox.
76
• CLI de ProxMox, la figura 65 muestra la interfaz de línea de comandos
de ProxMox.
Figura 65. CLI de ProxMox
• Configuración inicial de la interfaz gráfica de ProxMox, la figura 66
muestra la configuración del usuario principal root con su contraseña,
idioma del teclado y lenguaje del sistema.
Figura 66. Inicio de sesión de configuración de root inicial
77
Anexo 2
CREAR UNA MÁQUINA VIRTUAL EN PROXMOX
• Desde la Interfaz Web de ProxMox accedemos a la parte superior
izquierda en la que nos permite crear una nueva máquina virtual tal cual
se observa en la figura 67.
Figura 67. Crear una nueva máquina virtual.
• Se desplegará una ventana de configuraciones, escribimos el nombre de
la máquina virtual, tomando como ejemplo la figura 68.
Figura 68. Configuración general de la máquina virtual.
• Seleccionamos la imagen ISO del sistema. La figura 69 muestra un ISO
precargado del sistema operativo Centos 7.
78
Figura 69. Elección del sistema operativo a ser virtualizado.
• Dejamos por default las configuraciones de System, tal cual se observa
en la figura 70.
Figura 70. Configuración grafica del sistema virtualizado.
• Asignamos el disco necesario a la máquina virtual dependiendo de la
necesidad. La figura 71 muestra un ejemplo de configuración de disco de
una máquina virtual.
79
Figura 71. Configuración de disco de la VM.
• Asignamos los núcleos necesarios a la VM dependiendo de la
necesidad. La figura 72 muestra un ejemplo de configuración de
procesamiento de una máquina virtual.
Figura 72. Configuración de CPU de la VM.
80
• Asignamos la memoria ram necesaria a la máquina virtual dependiendo
de la necesidad. La figura 73 muestra un ejemplo de configuración de
memoria ram de una máquina virtual.
Figura 73. Configuración de memoria de la VM.
• Asignamos el modelo de tarjeta ethernet Intel E1000, ya que permite
simular una tarjeta de red GigaBit. La figura 74 muestra un ejemplo de
configuración de disco de una máquina virtual.
Figura. 74. Configuración de red de la VM.
81
• Verificamos todas las configuraciones y presionamos en Finish, tal cual
se muestra en la figura 75.
Figura 75. Detalles finales de la configuración de la VM.
• Una vez creada la máquina virtual nos aparecerá un icono dentro del
nodo físico, Iniciamos la máquina en Start. La figura 76 muestra un
ejemplo inicio en la consola de la VM.
Figura 76. Consola de la VM en ProxMox
82
Anexo 3
BACKUP DE MÁQUINAS VIRTUALES
• Para realizar el BackUp de una máquina virtual, accedemos a la pestaña
“BackUp” dentro de las opciones de la máquina en la cual vamos a
realizar el respaldo; a continuación, seleccionamos el disco que contiene
el nodo físico, escogemos el modelo, el tipo de archivo de compression y
un email para recibir una notificación cuando finalice el proceso.
Figura 77. Configuración de BackUp de una VM.
• Podemos verificar el estatus del proceso, tal cual se observa en la figura
78.
Figura 78. Consola de la VM en ProxMox
83
Anexo 4
CREACIÓN DE USUARIOS Y PERMISOS EN
PROXMOX
• Para crear un usuario en ProxMox nos dirigimos al apartado de Users y
damos un clcik en add, se desplegará una venta como muestra la figura
Figura 79. Configuración de un nuevo usuario en ProxMox.
• La figura 80 muestra el usuario creado anteriormente.
Figura 80. Interfaz gráfica demostrativa del usuario nuevo.
84
Anexo 5
SCRIPT CLI – FUNCIÓN DE RED DNS
• La figura 81 muestra la línea de comandos a seguir para el despliegue
de la función de red que da el servicio DNS.
Figura 81. Script parte 1 de la función de red DNS.
• La figura 82 muestra la segunda parte de la línea de comandos a seguir
para el despliegue de la función de red que da el servicio DNS.
Figura 82. Script parte 2 de la función de red DNS.
85
• La figura 83 muestra el estatus del servidor DHCP que está activo como
prueba de funcionalidad del servicio.
Figura 83. Ejecución del servicio DHCP en la función de red DNS.
86
Anexo 6
SCRIPT CLI – FUNCIÓN DE RED WEB
• La figura 84 muestra la línea de comandos a seguir para el despliegue
de la función de red que da el servicio WEB.
Figura 84. Script parte 1 de la función de red WEB.
• La figura 85 muestra la segunda parte de la línea de comandos a seguir
para el despliegue de la función de red que da el servicio WEB.
87
Figura 85. Script parte 2 de la función de red WEB.
88
Anexo 7
SCRIPT CLI – FUNCIÓN DE RED APP
• La figura 86, muestra la línea de comandos a seguir para el despliegue
de la función de red que da el servicio APP.
Figura 86. Script parte 1 de la función de red APP.
• La figura 87, muestra la línea de comandos de la segunda parte a seguir
para el despliegue de la función de red que da el servicio APP.
Figura 87. Script parte 2 de la función de red APP.
89
• La figura 88 muestra la lista de puertos, para verificar que el puerto 8080
este a la escucha de toda IP del servidor.
Figura 88. Lista de los puertos a escucha del servidor de aplicaciones.
90
Anexo 8
SCRIPT CLI – FUNCIÓN DE RED FIREWALL
• La figura 89, muestra la línea de comandos a seguir para el despliegue
de la función de red que da el servicio FIREWALL-DHCP.
Figura 89. Script parte 1 de la función de red FIREWALL -DHCP.
• La figura 90, muestra la línea de comandos de la segunda parte a seguir
para el despliegue de la función de red que da el servicio FIREWALL-
DHCP.
Figura 90. Script parte 2 de la función de red FIREWALL-DHCP.
91
Anexo 9
CARACTERÍSTICA MÍNIMAS PARA LA INSTALACIÓN
DE MININET Y OPENDYLIGHT
• Sistema Operativo Ubuntu 20.04 LTS con 2gb RAM 50 GB HDD
• Actualizar los Repositorios del Sistema
• Ejecutar como usuario root los siguientes comandos
sudo apt-get update
sudo apt-get upgrade
• Instalar la versión de Java como mínimo la versión 8
sudo apt-get install openjdk-8-jdk
• Es necesario configurar JAVA_HOME y el PATH, tal y como se muestra
en la figura 83.
export JAVA_HOME=/usr/lib/jvm/java-8-openjdk-amd64
export PATH=$PATH:$JAVA_HOME/bin
Figura 91. Configuración del archivo JAVA_HOME Y PATH de java.
92
Anexo 10
INSTALACIÓN DEL SIMULADOR VIRTUAL DE REDES
SDN MININET
• La instalación del simulador Mininet se realiza de forma nativa desde el
repositorio en el cual se encuentra el programa.
sudo apt-get install mininet
• Obtenemos el código fuente en el repositorio de GitHub
git clone git://github.com/mininet/mininet
• Accedemos a la carpeta mininet
cd mininet
• Desplegamos todas las versiones disponibles
git tag
• Cambiamos la versión que deseamos instalar
git checkout -b 2.2.1 2.2.1 # or whatever version you wish to install
• Regresamos un directorio atras
cd ..
• Una vez que tenemos el directorio fuente, ejecutamos el comando para
instalar Mininet
mininet/util/install.sh
• Verificamos que el programa ha sido instalado correctamente con el
siguiente comando que crea una red automática
sudo mn
93
Anexo 11
INSTALACIÓN DEL CONTROLADOR OPENDYLIGHT
• Descargamos la versión Nitrógeno 0.8.4 desde la página oficial
https://www.opendaylight.org/
• Se procede a descomprimir el archivo
tar -xzvf karaf-0.8.4.tar.gz
• Accedemos al directorio karaf-0.8.4
cd karaf-0.8.4
• Ejecutamos el archivo karaf
sudo ./bin/karaf
• Comenzará a ejecutarse todo el archivo como en la figura 84.
Figura 92. Ejecución del archivo karaf
94
• Una vez terminada la ejecución del archivo presentara una pantalla
como se muestra en la figura 85 con la consola de OpenDaylight
Figura 93. Consola del controlador OpenDylight.
• Instalación de Interfaz gráfica y componentes de ODL
• Los componentes para desplegar la interfaz gráfica y los componentes
ODL que permiten la conexión SDN son los siguientes.
feature:install odl-dlux-core odl-restconf-all odl-mdsal-apidocs odl-
dluxapps-topology odl-dluxapps-nodes odl-dluxapps-yangvisualizer
odl-l2switch-all odl-l2switch-switch-ui http odl-mdsal-clústering odl-
openflowplugin-flow-services
Figura 94. Características agregadas para la interfaz web del controlador
OpenDylight.
• Mediante la dirección local host por el puerto 8181 en cualquier
navegador accedemos a la interfaz gráfica en la cual se visualizará los
elementos de OpenDylight
https://localhost:8181/index.html
95
• A continuación, la figura 87 muestra la interfaz gráfica de acceso.
Figura 95. Interfaz gráfica del controlador OpenDylight.
• El usuario y contraseña por defecto son los siguientes
User: admin
Contraseña: admin