La versión digital de esta tesis está protegida por la Ley de Derechos de Autor del Ecuador.
Los derechos de autor han sido entregados a la “ESCUELA POLITÉCNICA NACIONAL” bajo el libre consentimiento del (los) autor(es).
Al consultar esta tesis deberá acatar con las disposiciones de la Ley y las siguientes condiciones de uso:
Cualquier uso que haga de estos documentos o imágenes deben ser sólo para efectos de investigación o estudio académico, y usted no puede ponerlos a disposición de otra persona.
Usted deberá reconocer el derecho del autor a ser identificado y citado como el autor de esta tesis.
No se podrá obtener ningún beneficio comercial y las obras derivadas tienen que estar bajo los mismos términos de licencia que el trabajo original.
El Libre Acceso a la información, promueve el reconocimiento de la originalidad de las ideas de los demás, respetando las normas de presentación y de citación de autores con el fin de no incurrir en actos ilegítimos de copiar y hacer pasar como propias las creaciones de terceras personas.
Respeto hacia sí mismo y hacia los demás.
FACULTAD DE INGENIERÍA ELÉCTRICA Y ELECTRÓNICA
DISEÑO E IMPLEMENTACIÓN DE UNA APLICACIÓN PARA BALANCEO DE CARGA PARA UNA RED DEFINIDA POR
SOFTWARE (SDN)
PROYECTO PREVIO A LA OBTENCIÓN DEL TÍTULO DE INGENIERO EN ELECTRÓNICA Y REDES DE INFORMACIÓN
MARLON ESTEBAN OLAYA YANDUN [email protected]
DIRECTOR: ING. DAVID MEJÍA, MSC.
[email protected]
Quito, noviembre 2015
DECLARACIÓN
Yo MARLON ESTEBAN OLAYA YANDUN, declaro bajo juramento que el trabajo aquí escrito 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 este documento.
A través de la presente declaración cedo mis derechos de propiedad intelectual, correspondientes a este trabajo, a la Escuela Politécnica Nacional, según lo esta- blecido por la Ley de Propiedad Intelectual, por su reglamento y por la normatividad institucional vigente.
Marlon Esteban Olaya Yandun
CERTIFICACIÓN
Certifico que el presente trabajo fue desarrollado por MARLON ESTEBAN OLAYA YANDUN, bajo mi supervisión.
Ing. David Mejía, MSc.
Director del Proyecto
AGRADECIMIENTOS
En primer lugar agradezco a mis padres Yolanda y Benigno, por todo el apoyo que me han dado desde el principio de mi vida, en especial a mi madre que ha estado conmigo en los buenos y malos momentos, siempre animándome y ayudándome a ser mejor ser humano.
También debo agradecer a Tatita por todo el amor, cariño, comprensión y apoyo que me ha brindado durante prácticamente toda mi carrera universitaria, sin ella este objetivo posiblemente hubiera tardado más, gracias por el apoyo y la presión bonita.
No puedo dejar de agradecer a los padres de Taty, la Sra. Gloria y Don Miguel por abrirme las puertas de su hogar y tratarme como otro de sus hijos durante todos estos años.
Agradezco al Ing. Davíd Mejía por su guía y concejo durante el desarrollo de este proyecto.
Finalmente agradezco a todos mis amigos que de alguna forma me apoyaron en la realización de este proyecto y que han sido parte de mi vida, entre ellos debo agradecer de sobre manera al Meri por la paciencia y ayuda compartiendo sus conocimientos y al Santos por tantos favores y molestias causadas a lo largo del tiempo que nos conocemos, muchas gracias muchachos.
DEDICATORIA
A aquel que ha estado presente en todo lo que he hecho desde el 2011, mi hijo.
Esteban Olaya
ÍNDICE DE CONTENIDOS
DECLARACIÓN I
CERTIFICACIÓN II
AGRADECIMIENTOS III
DEDICATORIA IV
ÍNDICE DE CONTENIDOS V
ÍNDICE DE FIGURAS X
ÍNDICE DE TABLAS XI
ÍNDICE DE CÓDIGOS XII
RESUMEN XIII
PRESENTACIÓN XIV
1 FUNDAMENTOS TEÓRICOS 1
1.1 REDES DEFINIDAS POR SOFTWARE . . . 1
1.1.1 OPENFLOW . . . 2
1.1.1.1 Wire Protocol . . . 3
1.1.1.2 Of-Config . . . 6
1.1.1.3 Mensajes OpenFlow . . . 9
1.1.1.3.1 Mensajes Controlador-Switch . . . 9
1.1.1.3.2 Mensajes Asincrónicos . . . 10
1.1.1.3.3 Simétricos . . . 10
1.1.2 CONTROLADOR SDN . . . 11
1.2 RYU . . . 11
1.2.1 FUNCIONAMIENTO . . . 12
1.2.2 COMPONENTES . . . 13
1.2.2.1 Ejecutables . . . 13
1.2.2.2 Componentes Base . . . 14
1.2.2.3 Controlador OpenFlow . . . 14
1.2.2.4 Codificador/Decodificador OpenFlow . . . 14
1.2.2.5 Aplicaciones . . . 15
1.2.2.6 Librerías . . . 15
1.2.2.7 Librerías de Terceros . . . 16
1.3 SISTEMA DE ENCOLAMIENTO . . . 16
1.3.1 CLIENTES . . . 17
1.3.2 SERVIDORES WEB . . . 17
1.3.2.1 Tráfico web . . . 17
1.3.3 BALANCEADOR DE CARGA . . . 19
1.3.3.1 Algoritmos de encolamiento . . . 19
1.3.3.1.1 FiFo . . . 20
1.3.3.1.2 Round Robin . . . 21
1.3.3.1.3 Deficit Round Robin . . . 21
2 DISEÑO Y DESARROLLO DE LA APLICACIÓN 26 2.1 ANÁLISIS DE REQUERIMIENTOS . . . 26
2.1.1 AMBIENTE FÍSICO . . . 26
2.1.2 USUARIOS Y FACTORES HUMANOS . . . 26
2.1.3 FUNCIONALIDAD . . . 27
2.2 CRITERIOS DE ENCOLAMIENTO . . . 27
2.2.1 FIFO . . . 28
2.2.2 ROUND ROBIN . . . 28
2.2.3 DEFICIT ROUND ROBIN . . . 29
2.3 ETAPAS DE LA APLICACIÓN . . . 29
2.3.1 RECEPCIÓN DE PAQUETES . . . 29
2.3.1.1 Paquetes ARP . . . 30
2.3.1.2 Paquetes no ARP . . . 30
2.3.2 PROCESAMIENTO . . . 31
2.3.2.1 Procesamiento FIFO . . . 32
2.3.2.2 Procesamiento RR . . . 33
2.3.2.3 Procesamiento DRR . . . 33
2.3.3 CREACIÓN DE REGLAS . . . 34
2.4 DESARROLLO DE LA APLICACIÓN . . . 37
2.4.1 RECEPCIÓN DE PAQUETES . . . 37
2.4.2 PROCESAMIENTO . . . 42
2.4.2.1 Criterio FIFO . . . 43
2.4.2.2 Criterio RR . . . 43
2.4.2.3 Criterio DRR . . . 43
2.4.3 CREACIÓN DE REGLAS . . . 48
3 IMPLEMENTACIÓN, PRUEBAS Y ANÁLISIS DE RESULTADOS 51 3.1 IMPLEMENTACIÓN DE LA SDN . . . 51
3.1.1 IMPLEMENTACIÓN EN MININET . . . 51
3.1.1.1 Proceso de Configuración . . . 52
3.1.2 IMPLEMENTACIÓN FÍSICA . . . 55
3.1.2.1 Switch OpenFlow . . . 57
3.1.2.1.1 VLAN . . . 58
3.1.2.1.2 Instancia OpenFlow . . . 58
3.1.2.1.3 Controlador . . . 60
3.1.2.2 Servidores . . . 61
3.1.2.3 Clientes . . . 63
3.2 PRUEBAS Y ANÁLISIS DE RESULTADOS . . . 64
3.2.1 PRUEBAS EN MININET . . . 66
3.2.1.1 Criterio FIFO . . . 68
3.2.1.2 Criterio RR . . . 69
3.2.2 PRUEBAS EN LA SDN FÍSICA . . . 72
3.2.2.1 Criterio FIFO . . . 72
3.2.2.2 Criterio RR . . . 77
3.2.2.3 Criterio DRR . . . 79
3.2.3 PRUEBAS GENERALES DE LA APLICACIÓN . . . 79
3.2.3.1 Tiempos de respuesta . . . 81
3.2.3.1.1 Criterio FIFO . . . 81
3.2.3.1.2 Criterio RR . . . 82
3.2.3.1.3 Criterio DRR . . . 82
4 CONCLUSIONES Y RECOMENDACIONES 91 4.1 CONCLUSIONES . . . 91
4.2 RECOMENDACIONES . . . 95
REFERENCIAS BIBLIOGRÁFICAS 98
ANEXOS 101
ANEXO A . . . A-1
ÍNDICE DE FIGURAS
Figura 1.1 Componentes principales del modelo OpenFlow [25] . . . 2
Figura 1.2 Entrada (Flow) de una tabla de flujos OpenFlow 1.0.0[26] . . . 6
Figura 1.3 Cabecera OpenFlow 1.0.0 [25] . . . 6
Figura 1.4 Acciones OpenFlow 1.0.0 [25] . . . 8
Figura 1.5 Relación entre componentes, protocolo Of-Config y protocolo OpenFlow [27] . . . 9
Figura 1.6 Perspectiva cliente web . . . 18
Figura 1.7 Balanceo de carga manual . . . 20
Figura 1.8 FIFO . . . 21
Figura 1.9 Round Robin con tres servidores. . . 22
Figura 1.10 Deficit Round Robin con tres servidores (Parte 1) . . . 24
Figura 1.11 Deficit Round Robin con tres servidores (Parte 2) . . . 25
Figura 2.1 Criterio de encolamiento basado en FIFO . . . 28
Figura 2.2 Criterio de encolamiento basado en Round Robin . . . 29
Figura 2.3 Criterio de encolamiento basado en Deficit Round Robin . . . . 30
Figura 2.4 Funcionamiento en caso de paquete ARP . . . 31
Figura 2.5 Funcionamiento en caso de paquetes que no son ARP . . . 32
Figura 2.6 Funcionamiento de la etapa de procesamiento. . . 33
Figura 2.7 Procesamiento FIFO . . . 34
Figura 2.8 Procesamiento RR . . . 35
Figura 2.9 Procesamiento DRR . . . 36
Figura 3.1 SDN implementada con Mininet . . . 52
Figura 3.2 Terminal para cada cada host, switch y controlador . . . 54
Figura 3.3 Creación de la topología en Mininet . . . 55
Figura 3.4 Configuración de la versión de OpenFlow en el switch . . . 55
Figura 3.5 Pantalla de inicio de VMware vSphere Client . . . 58
Figura 3.6 Advertencia de seguridad . . . 59
Figura 3.7 Administrador de máquinas virtuales . . . 59
Figura 3.8 Página de inicio servidor web 1 . . . 62
Figura 3.9 Página de inicio servidor web 2 . . . 62
Figura 3.10 Página de inicio servidor web 3 . . . 63
Figura 3.11 Archivo de configuración vacío . . . 66
Figura 3.12 Archivo de configuración con información . . . 67
Figura 3.13 Arranque del controlador y la aplicación . . . 68
Figura 3.14 Valores de configuración en Mininet . . . 69
Figura 3.15 Respuesta al cliente 1 . . . 70
Figura 3.16 Flujos instalados en el switch virtual criterio FIFO . . . 71
Figura 3.17 Flujos instalados en el switch virtual criterio RR . . . 71
Figura 3.18 Pruebas criterio FIFO . . . 73
Figura 3.19 Flujos que descartan paquetes . . . 74
Figura 3.20 Flujos para el tráfico entre cliente-servidor . . . 75
Figura 3.21 Flujos para el tráfico entre servidor-cliente . . . 76
Figura 3.22 Pasos 1 y 2 del procedimiento de pruebas para el criterio DRR 85 Figura 3.23 Flujos cliente-servidor creados hasta el paso 3 del procedi- miento de pruebas DRR . . . 86
Figura 3.24 Cambio de tiempos de vida de flujos en el archivo de configu- ración . . . 86
Figura 3.25 Flujos con tiempos de vida modificados . . . 87
Figura 3.26 Petición web utilizando HTTPS con Chrome . . . 88
Figura 3.27 Petición web utilizando HTTPS con Opera . . . 89
Figura 3.28 Pruebas audio y video . . . 90
ÍNDICE DE TABLAS
Tabla 1.1 Contadores OpenFlow 1.0.0 [26] . . . 7
Tabla 1.2 Ejemplos de controladores y sus respectivos desarrolladores . . 12
Tabla 3.1 Características del PC de pruebas . . . 52
Tabla 3.2 Características de las PC clientes 1 y 2 . . . 56
Tabla 3.3 Características de las PC clientes 3 y 4 . . . 56
Tabla 3.4 Características de la PC de clientes y de la PC de servidores . . 57
Tabla 3.5 Configuración de la instancia OpenFlow . . . 60
Tabla 3.6 Configuración del controlador en el switch . . . 60
Tabla 3.7 Características de los clientes Linux virtuales . . . 63
Tabla 3.8 Resultados esperados . . . 78
Tabla 3.9 Resultados fallidos obtenidos . . . 78
Tabla 3.10 Tiempos de respuesta para FIFO (primeras pruebas) . . . 81
Tabla 3.11 Tiempos de respuesta para FIFO (segundas pruebas) . . . 82
Tabla 3.12 Tiempos de respuesta para RR (primeras pruebas) . . . 82
Tabla 3.13 Tiempos de respuesta para RR (segundas pruebas) . . . 82
Tabla 3.14 Tiempos de respuesta para DRR . . . 83
Tabla 3.15 Tiempos de respuesta para DRR . . . 83
Tabla 3.16 Tiempos de respuesta para FIFO, RR y DRR . . . 84
Tabla 3.17 Tiempos de descarga de audio y vídeo . . . 84
ÍNDICE DE CÓDIGOS
Código 2.1 Función _packet_in_handler . . . 39
Código 2.2 Función _arp_handler (parte 1) . . . 40
Código 2.3 Función _arp_handler (parte 2) . . . 41
Código 2.4 Función _arp_handler (parte 3) . . . 42
Código 2.5 Función fifo . . . 43
Código 2.6 Función round_robin . . . 43
Código 2.7 Función stats_reply_handler . . . 46
Código 2.8 Función proc_index . . . 47
Código 2.9 Función def_round_robin . . . 47
Código 2.10 Función add_flow . . . 49
Código 3.1 Conexión con Mininet usando SSH . . . 53
Código 3.2 Creación de la topologia usando Mininet . . . 53
Código 3.3 Levantamiento del servidor web en el host h4 . . . 54
Código 3.4 Levantamiento del servidor web en el host h5 . . . 54
Código 3.5 Levantamiento del servidor web en el host h6 . . . 54
Código 3.6 Estableciendo la versión 1.0 de OpenFlow en el switch . . . 54
Código 3.7 Creación de la VLAN y asociación de puertos . . . 58
Código 3.8 Creación de la instancia OpenFlow . . . 59
Código 3.9 Ingreso de la VLAN 50 a la instancia OpenFlow . . . 59
Código 3.10 Información del controlador . . . 60
Código 3.11 Asociación del controlador con la instancia . . . 61
Código 3.12 Hablilitación de la instancia OpenFlow . . . 61
Código 3.13 Habilitación de OpenFlow de manera global . . . 61
Código 3.14 Inicio del funcionamiento del controlador . . . 65
Código 3.15 Petición HTTP desde los clientes . . . 67
Código 3.16 Ping hacia cualquier dirección IP . . . 68
Código 3.17 Comando para mostrar los flujos del switch . . . 68
RESUMEN
En el presente trabajo se realiza un estudio de las SDN (Software Defined Net- works) y el controlador Ryu, para luego aplicar esta tecnología en el diseño e im- plementación de un balanceador de carga para servidores web dentro de una SDN.
En el primer capítulo se revisa la teoría necesaria para la comprensión y el co- rrecto desarrollo de este proyecto. En primer, lugar se exponen las definiciones y conceptos necesarios para entender las SDN, sus características y además varias de sus ventajas y desventajas con respecto a las redes tradicionales. A continua- ción se analiza el controlador Ryu, utilizado para el desarrollo de este proyecto. Se continúa con una breve revisión acerca de los servidores web y la necesidad de la distribución de carga en los mismos. Luego se realiza un breve estudio de los balanceadores de carga y su funcionamiento. Finalmente se efectúa un pequeño análisis de varios algoritmos que son la base para el desarrollo del balanceador de carga.
En el capítulo dos se presenta el análisis de requerimientos realizado para el diseño de un balanceador de carga, después se eligen los criterios para el encolamiento en base a los algoritmos analizados en el capítulo uno, a continuación se realiza el diseño de cada etapa de la aplicación y se muestra el proceso de desarrollo de las mismas.
En el capítulo tres se presenta la implementación de una SDN virtual, una SDN fí- sica y la aplicación que funcionará sobre estas. En primer lugar se muestra la SDN implementada en Mininet, para posteriormente pasar a la implementación de la SDN física, donde se revisan las características y la configuración del switch Open- Flow y de los equipos utilizados para los servidores y los clientes. Posteriormente se realizan las pruebas de la aplicación, tanto en Mininet como en la SDN física, para finalmente presentar y analizar los resultados obtenidos.
En el capítulo cuatro se presentan las conclusiones y recomendaciones obtenidas del desarrollo de este proyecto.
PRESENTACIÓN
Las necesidades de transmitir grandes cantidades de información de forma segura y eficiente han causado el continuo avance y desarrollo de las tecnologías de la información. Uno de estos avances es la arquitectura conocida como SDN (Software Defined Network ) que permite un mayor control sobre todos los dispositivos de interconexión de la red desde un solo punto lógico de administración.
Las SDN son redes que en este momento se encuentran en continuo desarrollo por todas las potencialidades que tienen en aspectos de seguridad y de servicios que pueden ofrecerse de manera sencilla a través de las mismas.
Internet en la actualidad es utilizada por la mayor parte de la población mundial pa- ra diferentes propósitos como por ejemplo realizar compras, leer, escuchar música, mirar vídeos, entre otros. Cada página web en Internet está alojada en un servidor web y puede tener visitantes de todas partes del mundo, por lo tanto, para sitios populares se utiliza más de un servidor web, ya que la cantidad de tráfico en un so- lo servidor podría causar una saturación y posterior caída del mismo, provocando pérdidas de tiempo y dinero. Para evitar este tipo de pérdidas se realiza una distribu- ción del tráfico entre los diferentes servidores que alojan el mismo contenido, siendo este proceso transparente para el usuario. Esta distribución se realiza mediante un software o hardware especializado conocido como “balanceador de carga”, estos balanceadores de carga en el mercado tienen un alto costo y probablemente no estén al alcance de las compañías que están comenzando a desarrollarse.
El gran avance tecnológico en las comunicaciones, la importancia de los sitios web en Internet y el alto costo de un balanceador de carga han inspirado al desarrollo de este Proyecto de Titulación denominado “DISEÑO E IMPLEMENTACIÓN DE UNA APLICACIÓN PARA BALANCEO DE CARGA PARA UNA RED DEFINIDA POR SOFTWARE (SDN)”.
En este Proyecto se presenta la base teórica de las SDN, la implementación de una SDN virtual y una SDN física, el tema principal es el diseño e implementación de una aplicación para balancear la carga de servidores en una SDN.
Este Proyecto ayuda a incursionar en la arquitectura SDN y demostrar las capacida- des de las mismas. Se utiliza el controlador Ryu que además de estar en constante desarrollo es de uso libre y de código abierto, lo que implica que las aplicaciones realizadas para el mismo no tienen valor comercial alguno. Un servicio que pudiera
implicar un gran gasto utilizando el software o hardware de balanceo de carga en redes convencionales, en una SDN resultaría con un costo nulo.
CAPÍTULO 1
FUNDAMENTOS TEÓRICOS
En el presente capítulo se revisará la teoría necesaria para la comprensión y el correcto desarrollo de este Proyecto de Titulación. En primer lugar se expondrán las definiciones y conceptos necesarios para entender las SDN(Software Defined Networks), sus características, además varias de sus ventajas y desventajas con respecto a las redes tradicionales. A continuación se analizará el controlador utili- zado para el desarrollo de este proyecto, se continuará con una breve revisión sobre los servidores web y la necesidad de la distribución de carga en los mismos. Luego se revisará los balanceadores de carga y como funcionan. Finalmente se realizará un breve análisis de varios algoritmos que serán la base para el desarrollo de la aplicación concerniente a este proyecto.
1.1. REDES DEFINIDAS POR SOFTWARE [25], [14]
La ONF(Open Networking Foundation)1 menciona que las SDN son redes en las que se ha separado el plano de datos del plano de control. El plano de datos se ubica en cada dispositivo de la red, sea este un router o un switch. El plano de control se ha centralizado en un solo punto lógico llamado Controlador SDN, del cual se hablará más adelante.
Las SDN tienen la intención de optimizar y simplificar las operaciones en la red acercando más las interacciones entre las aplicaciones y servicios de la red con los elementos de la misma; se optimiza las interacciones ya que los elementos de la red solo trabajan en el plano de datos y todas las decisiones las realiza el controlador SDN, de la misma manera se simplifican las operaciones, ya que las acciones son programadas en el controlador en vez de en cada dispositivo de la red.
La interfaz de comunicación entre el controlador y los dispositivos de la red consti- tuye el protocolo OpenFlow, del que se hablará a continuación.
1La ONF es una organización orientada al usuario, dedicada a difundir las SDN a través del desarrollo de estándares.
1.1.1. OPENFLOW [25], [26]
Es un protocolo que fue ideado e implementado con fines de investigación en la universidad de Stanford. Su objetivo era permitir la creación de protocolos experi- mentales en las redes de los campus en las universidades y así no tener que crear una plataforma experimental desde cero para cada protocolo experimental. La idea creció, entonces se tuvo la visión de que OpenFlow puede reemplazar todas las funcionalidades de los protocolos de capas 2 y 3 en switches y routers comerciales.
El modelo OpenFlow que difunde la ONF no es un protocolo en si, es un conjunto de protocolos y una API2, los componentes principales de este se muestran en la Figura 1.1, donde se puede ver dos partes, los dispositivos de la red y el controlador.
Figura 1.1: Componentes principales del modelo OpenFlow [25]
Los protocolos OpenFlow se dividen en dos:
Protocolo de conexión, se encarga de varias tareas como:
• Establecer un control de sesión.
• Definir la estructura del mensaje para la modificación de flujos.
• Recolectar Estadísticas.
2API = Aplication Programming Interface, es un conjunto de funciones y métodos que ofrece una biblioteca para ser utilizada de forma fácil por otro software.
Protocolo de configuración y administración (of-config), basado en NETCONF3, que tiene las siguientes funciones:
• Asignar los puertos físicos del dispositivo de red a un controlador espe- cífico.
• Definir el comportamiento del elemento de red en caso de desconexión del controlador.
La primera versión de OpenFlow, disponible para ser instalada en equipos físicos es la 1.0.0 disponible desde Diciembre del 2009. La última versión de OpenFlow es 1.5 cuya documentación estuvo disponible a partir de Diciembre de 2014 en el sitio web de la ONF, cabe recalcar que los equipos físicos disponibles hasta ahora (Abril 2015) solo tienen implementación de las versiones 1.0.0 para producción y 1.3 para pruebas.
1.1.1.1. Protocolo de conexión (Wire Protocol)[25], [27]
Antes de profundizar en el protocolo de conexión es necesario definir varios térmi- nos fundamentales que se utilizarán [26].
switch OpenFlow: Está constituído por una tabla de flujos (Flow Table) ,donde se realiza la búsqueda de la ruta de los paquetes para su reenvío, y un canal seguro hacia un controlador externo que administrará el switch utilizando el protocolo OpenFlow.
Tabla de flujo: Contiene un conjunto de flujos(flows).
Flujo: Es un conjunto conformado por valores de una cabecera OpenFlow, valores de contadores y acciones.
Match: Se dice que un paquete hace match con un flujo cuando uno o va- rios valores de las cabeceras del paquete corresponden a los valores de la cabecera OpenFlow en el flujo.
Las entradas de la tabla de flujo están formadas tal como se muestra en la Figu- ra 1.2, donde se puede observar tres campos: la cabecera, los contadores y las acciones.
3NETCONF = Network Configuration Protocol, es un protocolo brinda herramientas para instalar, manipular y borrar la configuración de dispositivos de red, m’as información en [18].
Cabecera: como se muestra en la Figura 1.3, la cabecera contiene los valores de los siguientes campos:
• Puerto de Ingreso: Número de puerto del switch por el cual ingresó el paquete.
• Ethernet-Dirección origen: Dirección física del dispositivo de origen.
• Ethernet-Dirección destino: Dirección física del dispositivo destino.
• Ethernet-Tipo: Entero en formato hexadecimal que identifica el tipo de paquete, por ejemplo: ARP4 = 0x0806, IP5 = 0x0800, IPv66 = 0x86DD, etc.
• VLAN-ID: Identificador de VLAN7.
• VLAN-Prioridad: Prioridad del mensaje en la VLAN.
• IP-Dirección origen: Dirección IP del origen del mensaje.
• IP-Dirección destino: Dirección IP del destino del mensaje.
• IP-TOS: Campo ToS8de un paquete IP.
• TCP9/UDP10-origen: Puerto de origen.
• TCP/UDP-destino: Puerto destino.
Contadores: se tiene contadores de cuatro tipos: por tabla, por flujo, por puer- to y por cola, en la Tabla 1.1 se listan todos estos contadores. Los contadores de duración hacen referencia al tiempo desde que se instaló el flujo en el switch, el contador de errores recibidos incluye los errores de trama, de satu- ración y CRC11, además de algún otro tipo de error recibido.
4ARP = Adress Resolution Protocol, es un protocolo que permite resolver la dirección física de un equipo mediante la dirección IP [4]
5IP = Internet Protocol, es un protocolo de capa Internet del modelo TCP/IP utilizado para el direccionamiento de paquetes con direcciones de 32 bits [4].
6IPv6 = Internet Protocol version 6, es un Protocolo de capa Internet del modelo TCP/IP utilizado para el direccionamiento de paquetes utilizando direcciones de 128 bits.
7VLAN = Virtual Local Area Network, es una Red de Area Local virtual, aislada de cualquier otra red configurada en el mismo equipo [7]
8ToS = Type of Service, es un campo de la cabecera IP que es utilizado para dar prioridad de servicio en ciertas redes.
9TCP = Transmision Control Protocol, es un protocolo orientado a conexión de capa de transporte del modelo TCP/IP
10UDP = User Datagram Protocol, es un protocolo no orientado a conexión de la capa de trans- porte del modelo OSI
11CRC = Cyclic Redundancy Check, es un código de detección de errores utilizado en redes y dispositivos de almacenamiento para verificar algún cambio inesperado en los datos a nivel binario.
Acciones: cada flujo está ligado a cero o más acciones, estas indican al switch que hacer con los paquetes que cumplan con los valores de la cabecera del flujo. En caso de no haber ninguna acción de reenvío indicada, el paquete será descartado. Las acciones a cumplirse para cada flujo se realizan en el orden especificado, en caso de no poder realizar las acciones en ese orden se producirá un error en el flujo y este no será insertado en la tabla de flujos.
Las acciones pueden ser Requeridas u Opcionales, así como se muestran en la Figura 1.4, a continuación una breve explicación de las mismas.
• Requeridas: Son las acciones que un switch OpenFlow debe soportar, estas son:
◦ Forward : Es la acción de reenvío de paquetes, esta acción es reque- rida hacia cualquier puerto físico del switch, así como a los siguientes puertos virtuales:
⋄ ALL: Indica el reenvío del paquete por todas las interfaces.
⋄ CONTROLLER: Indica que el paquete será reenviado hacia el controlador.
⋄ LOCAL: Permite a las aplicaciones OpenFlow acceder a los puer- tos del sistema operativo (SO) del cliente.
⋄ TABLE: Se utiliza para crear un flujo de trabajo con mútiples ta- blas12 en una secuencia ordenada.
⋄ IN_PORT: Indica que el paquete se reenviará por el puerto de entrada del mismo.
◦ Drop: Se da cuando un flujo no tiene acciones asociadas, por lo tanto cualquier paquete que cumpla con la cabecera del flujo será descar- tado.
• Opcionales: Son las acciones que un switch OpenFlow no está obligado a soportar, pero si son soportadas pueden potenciar las funcionalidades del switch, estas son:
◦ Forward : Esta acción es opcional hacia los siguientes puertos virtua- les:
⋄ NORMAL: Indica que los paquetes serán tratados de la forma tradicional, es decir que el switch OpenFlow funcione como un
12Los flujos de trabajo con múltiples tablas pueden ser utilizados desde la versió 1.3 de OpenFlow.
switch tradicional con sus comportamientos de inundación y apren- dizaje.
⋄ FLOOD: Reenvía el paquete por todas las interfaces, excluyendo la de entrada.
◦ Enqueue: Reenvía el paquete a través de una cola asociada a un puerto, esto se utiliza para dar una Calidad de Servicio13 básica.
◦ Modify Field : Ayuda a la integración con otras redes, permite realizar modificaciones sobre campos en las cabeceras de los paquetes, por ejemplo:
⋄ Cambio de la dirección física de origen y/o destino del paquete
⋄ Cambio de la dirección IP de origen y/o destino del paquete.
⋄ Cambio de la prioridad en una cabecera VLAN.
⋄ Cambio de puerto TCP/UDP de origen y/o destino del paquete.
Esta acción, aunque no sea de implementación obligatoria para los fabricantes, es la que abre el abanico de posibilidades de uso de una implementación OpenFlow.
Figura 1.2: Entrada (Flow) de una tabla de flujos OpenFlow 1.0.0[26]
Figura 1.3: Cabecera OpenFlow 1.0.0 [25]
1.1.1.2. Protocolo de configuración y administración (Of-Config) [25], [26]
La documentación de la primera versión oficial del protocolo Of-Config(1.0) está disponible desde diciembre de 2011 y estaba dirigida a dispositivos de red con soporte para OpenFlow 1.2.
13QoS.- es el rendimiento promedio de la red visto por los usuarios.
Contador Bits Por Tabla
Entradas Activas 32
Búsquedas de paquetes 64
Coincidencias 64
Por Flujo
Paquetes recibidos 64
Bytes recibidos 64
Duración (segundos) 32
Duración (nanosegundos) 32 Por Puerto
Paquetes recibidos 64
Paquetes transmitidos 64
Bytes recibidos 64
Bytes transmitidos 64
Paquetes descartados 64
Errores recibidos 64
Errores transmitidos 64
Errores de alineación de trama 64
Errores de saturación 64
Errores CRC 64
Colisiones 64
Por Cola
Paquetes a transmitir 64
Bytes a transmitir 64
Errores de saturación a transmitir 64 Tabla 1.1: Contadores OpenFlow 1.0.0 [26]
Of-Config fue diseñado originalmente para configurar la información relacionada a OpenFlow en los elementos de la red. Este protocolo se estructura en torno a esquemas XML14, modelos de datos Yang15 y el protocolo NETCONF.
El servicio que envía los mensajes Of-Config hacia el switch OpenFlow se denomina Punto de Configuración OpenFlow, este puede ser provisto por software mediante un controlador OpenFlow o por cualquier sistema de gestión tradicional.
En un switch OpenFlow se pueden crear varias instancias o redes virtuales Open- Flow ya sea con FlowVisor16o cualquier otro modelo de virtualización. En la Figura
14XML = Extensible Markup Languaje, es un lenguaje de etiquetas que define reglas para la codifi- cación de archivos en un formato que es comprensible tanto para humanos como para máquinas[36].
15Es un lenguaje de modelado de datos usado para modelar la configuración y el estado de los datos manipulados por el protocolo de configuración de red NETCONF [19].
16Es un controlador OpenFlow de proósito especial que actúa como proxy transparente entre switches OpenFlow y varios controladores, FlowVisor segmenta la red OpenFlow y cada sección se
Figura 1.4: Acciones OpenFlow 1.0.0 [25]
1.5 se muestra la diferencia en como trabajan los protocolos Of-Config y OpenFlow.
En un switch OpenFlow que tiene dos instancias lógicas OpenFlow y cada instancia la maneja un controlador diferente mediante el protocolo OpenFlow, mientras que la asignación de los recursos OpenFlow (como por ejemplo puertos del switch) a cada switch lógico la realiza el Punto de Configuración mediante el protocolo Of-Config.
Resumiendo, el protocolo Of-Config fue diseñado para satisfacer las necesidades de configuración de OpenFlow 1.2, es decir cumple con las siguientes funcionalida- des:
Asignar uno o más controladores OpenFlow.
Configuración de colas y puertos.
Cambio del estado de los puertos remotamente.
administra mediante un controlador diferente. [21]
Figura 1.5: Relación entre componentes, protocolo Of-Config y protocolo OpenFlow [27]
1.1.1.3. Mensajes OpenFlow [26]
Para el desarrollo del presente proyecto es necesario conocer los mensajes del protocolo OpenFlow, a continuación se dará una breve revisión a los mensajes más importantes para la correcta realización de este proyecto.
El protocolo OpenFlow soporta tres tipos de mensajes: controlador-switch, asincró- nicos y simétricos.
1.1.1.3.1. Mensajes Controlador-Switch
Son mensajes enviados por el controlador hacia el switch y estos pueden o no re- querir una respuesta, estos mensajes son utilizados principalmente para gestionar o revisar el estado del switch, entre estos están:
Features: Una vez establecida la conexión entre switch y controlador, el con- trolador envía una petición (Features-request) hacia el switch y este último ten- drá que responderle (Features-reply) indicando las características de Open- Flow que soporta.
Modify-State: Se utilizan para gestionar el switch, su función principal es aña- dir, eliminar y modificar flujos en las tablas de flujos.
Read-State: Este mensaje se utiliza para recolectar las estadísticas de las tablas de flujos, de cada flujo y de cada puerto.
Send-Packet: El controlador utiliza este mensaje para enviar un paquete es- pecífico por un puerto del switch.
Barrier : El controlador envía una petición al switch y espera por una respuesta un cierto tiempo, se utiliza para sincronización.
1.1.1.3.2. Mensajes Asincrónicos
Son mensajes enviados desde el switch hacia el controlador, sin que este último lo haya solicitado, a continuación los más importantes:
Packet-In: Este mensaje se envía cuando un paquete que llega al switch no hace match con ninguno de los flujos instalados en el switch o cuando cumple con alguno y la acción asociada al mismo es “reenviar el paquete al controla- dor”.
Flow-Removed : Se da cuando se borra una entrada de la tabla de flujos, ya sea por un mensaje Modify-State, por un temporizador de inactividad o por un temporizador fijo de tiempo de vida del flujo.
Port-Status: Se envía este mensaje hacia el controlador cuando cambia el estado de un puerto (UP/DOWN).
Error : El switch envía estos mensajes al controlador cuando detecta algún problema.
1.1.1.3.3. Simétricos
Pueden enviarse desde el controlador al switch o viceversa, sin que el switch o el controlador los hayan solicitado, se tiene tres mensajes de este tipo:
Hello: Estos mensajes se intercambian entre switch y controlador al iniciar la conexión.
Echo: Estos mensajes pueden ser usados para verificar: si un controlador está activo, ancho de banda o latencia. Estos mensajes pueden ser de petición o respuesta.
Vendor : Es un tipo de mensajes utilizado para ofrecer funcionalidades adi- cionales y realización de pruebas, en posteriores revisiones de OpenFlow el nombre del mensaje cambia a Experimenter[28].
1.1.2. CONTROLADOR SDN [25], [32], [37]
El controlador SDN es un software que configura, controla y administra los disposi- tivos de conectividad en una red OpenFlow. Las SDN son programables mediante el controlador, es decir las aplicaciones deben ser desarrolladas para cada contro- lador, este se comunicará con los dispositivos de conectividad mediante OpenFlow y realizará las tareas de configuración, instalación de flujos, administración, que se haya programado en la aplicación.
Un controlador ideal debería proveer:
Administración del estado de la red.
Un modelo de datos de alto nivel que capture las relaciones entre los recursos que se administra, las políticas y los servicios prestados por el controlador.
Una API moderna que facilite las interacciones entre controlador y aplicación.
Una sesión de control segura mediante TCP entre el controlador y los elemen- tos de la red.
Un protocolo basado en estándares para configurar el estado de la red.
Un mecanismo de descubrimiento de servicios, equipos y topología.
Existe una gran variedad de controladores en el mercado, tanto Open Source17 como propietarios, una breve lista de algunos de ellos se muestra en la Tabla 1.2.
Para el desarrollo de este Proyecto de Titulación se utilizará el controlador Ryu, por lo tanto se profundizará en los aspectos más importantes del mismo.
1.2. RYU [9]
Ryu no es solo un controlador SDN, es también un Framework18 de red basado en componentes, es decir esá formado por una gran cantidad de librerías y recursos
17Open Source es el software de código abierto, de libre acceso.
18Un Framework es un marco de trabajo constituido por varios elementos como por ejemplo un modelo, librerías, un compilador o intérprete dependiendo del lenguaje, etc.
Controladores Privativos
Nombre Desarrollador
Active Broadband Controller Active Broadband Networks
NorthStar Juniper Networks
Big Network Controller Big Switch Networks Blue Planet SDN controller Cyan Inc
ContexNet controller ConteXtream Active Fabric Controller Dell
Application Policy Infrastructure
Controller (APIC) Cisco Systems
The HP Virtual Application Net-
works SDN Controller Hewlett-Packard (HP) Smart Network Controller Huawei Technologies IBM SDN for Virtual Environ-
ments
IBM
NSX Controller VMware
Controladores Open Source
Nombre Desarrollador
NOX NOXRepo
POX NOXRepo
SDN Open Network Operating System (ONOS)
ON.Lab OpenContrail Controller OpenContrail
OpenDaylight OpenDaylight Project
Floodlight Open SDN Controller Project Floodlight
RYU Ryu SDN Framework Community
Beacon Stanford University
Trema Trema
Tabla 1.2: Ejemplos de controladores y sus respectivos desarrolladores
que facilitan el desarrollo de aplicaciones, además puede ser utilizado como contro- lador de red en OpenStack19. Ryu está escrito completamente en Python y trabaja con las versiones 2.6 en adelante pero todavía no es completamente funcional con Python 320.
1.2.1. FUNCIONAMIENTO [34], [35]
Las aplicaciones de Ryu utilizan un solo hilo de ejecución e implementan algu- na funcionalidad al framework. El controlador utiliza una programación dirigida por
19Más informació de Ruy con Openstack en [38].
20Los desarrolladores se encuentran activamente añadiendo el soporte para Python 3 pero aun no está completamente implementado.
eventos, es decir, las acciones que se realizan dependen de los eventos que ocu- rran en tiempo de ejecución. Cabe mencionar que los eventos son manejados como mensajes entre las aplicaciones.
Cada aplicación de Ryu tiene una cola de tipo FIFO21(First In - First Out)para recibir eventos, cada evento es procesado por el hilo de ejecución y no se pasará a otro hasta terminar el evento en curso.
La API de Ryu permite crear eventos propios y manipuladores22para eventos espe- cíficos o generar eventos preestablecidos. Para crear los manipuladores de eventos se utiliza el decorador23ryu.controller.handler.set_ev_cls.
1.2.2. COMPONENTES [35]
Los componentes que forman el framework Ryu se los puede clasificar por su fun- cionalidad de la siguiente manera:
Ejecutables
Componentes Base Controlador OpenFlow
Codificador/Decodificador del protocolo de conexión OpenFlow Aplicaciones
Librerías
Librerías de Terceros
A continuación se explicará brevemente los componentes de la clasificación men- cionada.
1.2.2.1. Ejecutables
El componente ryu-manageres el ejecutable principal que permite correr las aplica- ciones24desarrolladas.
21FIFO = First In - First Out, es un concepto que dice: .Elprimero que entra es el primero que sale", se usa en teoría de colas, estructuras de datos.
22Los manipuladores son más conocidos con el nombre de “Handlers”.
23Un decorador es una función que recibe como parámetro otra función y retorna una función compuesta por las acciones de cada función[10].
24Cuando se habla de “aplicaciones” quiere decir las aplicaciones desarrolladas para Ryu.
1.2.2.2. Componentes Base
ryu.base.app_manager, se encarga de la la administración de las aplicaciones de Ryu, tiene las siguientes tareas:
Cargar la aplicación.
Proveer de contextos25para las aplicaciones.
Direccionar mensajes entre aplicaciones.
1.2.2.3. Controlador OpenFlow
El componente ryu.controller.controller es la parte fundamental del Controlador OpenFlow, este maneja las conexiones de los switches, además genera y enruta los eventos (mensajes OpenFlow) hacia la aplicación indicada.
En esta clasificación también se encuentran componentes como:ryu.controller.dpset que se encarga del descubrimiento de enlaces,ryu.controller.ofp_eventestá a car- go de las definiciones de los eventos OpenFlow y ryu.controller.ofp_handler que tiene la tarea de manejar las negociaciones OpenFlow.
1.2.2.4. Codificador/Decodificador OpenFlow
En esta sección se encuentran dos componentes para cada versión de OpenFlow, desde la versión 1.0 hasta la 1.4, estos componentes son:
ryu.ofproto.ofproto_v1_x26 En este componente se puede encontrar las defini- ciones de OpenFlow 1.x, estas incluyen por ejemplo el número de puerto TCP a utilizar o los valores correspondientes a los puertos que se utilizan para realizar la acción forward que se mencionó en la Sección 1.1.1.1.
ryu.ofproto.ofproto_v1_x_parserAquí se puede encontrar la implementación del codificador y decodificador para OpenFlow 1.x. En este componente están las clases y funciones necesarias para crear los mensajes OpenFlow, reenviarlos, procesarlos, instalar flujos en el switch OpenFlow, modificarlos, entre otras acciones.
25Los contextos o context son objetos Python utilizados de forma compartida entre aplicaciones.
26“x” corresponde al numero de la versión, pudiendo ser esta 0, 2, 3 o 4.
1.2.2.5. Aplicaciones
Como parte del framework Ryu están presentes varias aplicaciones implementadas para hacer uso del Controlador OpenFlow que este provee, estas aplicaciones pue- den servir de ejemplo a los desarrolladores que están comenzando a programar para Ryu o puede utilizarse cualquiera de las funciones que esté en una aplicación en un nuevo código, ya que solo son archivos de texto plano escritos en Python.
Entre las aplicaciones incorporadas en Ryu están:
ryu.app.simple_switch.- es una implementación de un switch capa 2 con Open- Flow 1.0.
ryu.app.rest.- Es un API para utilizar REST27.
ryu.app.simple_switch_13.- Es una implementación para un switch capa 2 con OpenFlow 1.3.
ryu.app.ofctl_rest.- Es una aplicación para utilizar servicios ofctl28
1.2.2.6. Librerías
En esta sección se tiene varias librerías implementadas con el propósito de facilitar la construcción o manipulación de protocolos, las librerías que se puede encontrar aquí son:
ryu.lib.packet.- esta librería contiene la implementación para codificar y de- codificar paquetes de varios protocolos como TCP, IP, UDP, Ethernet, entre otros.
ryu.lib.ovs.- esta librería contiene las clases y métodos necesarios para inter- actuar con el OVSDB29.
ryu.lib.of_config.- esta librería permite trabajar con Of-Config, ya que tiene las clases y métodos para utilizar con el protocolo.
27REST = Representational State Transfer, es una arquitectura de software utilizada para servicios web [1].
28ofctl permite utilizar mensajes OpenFlow del tipo Controler-Switch (Sección 1.1.1.3)de forma sincroónica.
29OVSDB = Open vSwitch Data Base Management Protocol, es un protocolo que fue utilizado para administrar y programar Open vSwitch cuando este fue desarrollado, porque OpenFlow no tenía las capacidades para hacerlo. [25]
ryu.lib.netconf.- esta librería es una implementación de NETCONF, y se em- plea en Of-Config.
1.2.2.7. Librerías de Terceros
Son implementaciones en Python que se utilizan en las definiciones de otras libre- rías mencionadas con anterioridad, entre estas se tiene:
ryu.contrib.ovs.- esta librería contiene las clases y métodos necesarios para realizar las conexiones con Open vSwitch y se utiliza para la implementación de la libreríaryu.lib.ovs.
ryu.contrib.oslo.config.- es utilizada por las opciones en linea de comandos deryu-managery los archivos de configuración.
ryu.contrib.ncclient.- es una librería en Python para el cliente NETCONF, tam- bién se utiliza para la implementación de la libreríaryu.lib.of_config.
1.3. SISTEMA DE ENCOLAMIENTO [2]
Se puede encontrar sistemas de encolamiento diariamente en las actividades co- tidianas como realizar una transacción en las oficinas de un banco, ingresar a un estadio de fútbol, comprar productos en un supermercado, etc. Para el desarrollo de este proyecto es importante entender el encolamiento en las redes, por lo que se explicará acerca de esto, pero sin profundizar en toda la teoría matemática que tiene como base.
Un sistema de encolamiento es un modelo abstracto en el que se tienen dos con- juntos de participantes, los clientes y los servidores. En este modelo, los clientes solicitan servicios a los servidores, si los servidores no tienen capacidad de atender a todos los clientes en ese momento, se producirá un encolamiento, es decir se pondrá en cola a los clientes que no puedan ser atendidos en ese instante de tiem- po hasta que un servidor termine de atender la solicitud en curso y pueda atender a otro cliente de la cola.
Un sistema de encolamiento específico de interés para este proyecto es en el que se tienen servidores web30y clientes que desean acceder a los servicios que estos
30Un servidor web, es un servidor que puede tener alojado cualquier tipo de contenido como audio, vídeo, paginas en texto plano, etc.
proporcionan. A continuación se expondrán los elementos que intervienen en este sistema.
1.3.1. CLIENTES
Un cliente en el sistema de encolamiento mencionado con anterioridad es cualquier navegador web, consola de comandos o cualquier aplicación capaz de realizar pe- ticiones web, es decir peticiones HTTP31o HTTPS32.
1.3.2. SERVIDORES WEB [8], [16]
Un servidor web es un programa o aplicación capaz de atender y mantener peticio- nes web, ya sea en una intranet o en Internet. Algunos autores hacen una diferen- ciación entre un servidor web y un servidor de aplicaciones, para este documento, si el servidor ofrece algún servicio mediante HTTP/HTTPS, sea este una página web o una aplicación, se considerará un servidor web. El funcionamiento básico de un servidor web es el siguiente: el servidor espera por peticiones, cuando recibe una petición busca el recurso solicitado y lo envía como respuesta a la petición, finalmente vuelve a esperar por peticiones, ese ciclo se repite indefinidamente.
1.3.2.1. Tráfico web [16]
Las peticiones web se realizan desde el cliente hacia el servidor, solicitando algún recurso alojado en el servidor, estas peticiones son realizadas utilizando los pro- tocolos HTTP o HTTPS y generalmente se realizan mediante un navegador como:
Firefox, Internet Explorer, Chrome, entre otros.
Una vez que el servidor recibe una petición, inicia una conexión cliente-servidor y empieza el intercambio de paquetes entre cliente y servidor, dependiendo del tipo de contenido expuesto por el servidor. Este intercambio se realiza entre ca- da usuario solicitante y el servidor que atiende dicha solicitud y dependiendo de la capacidad de respuesta del servidor, este puede atender a varios clientes si- multáneamente, pero el número de clientes puede aumentar casi indefinidamente, dependiendo del lugar de exposición del servidor, por lo que el tráfico en la red
31HTTP = HyperText Transfer Protocol, es un protocolo orientado a transacciones, sin estado, que se utiliza en Internet.
32HTTPS = HyperText Transfer Protocol Secure, es un protocolo seguro, basado en HTTP, que utiliza un cifrado para proteger la información.
del servidor también puede aumentar hasta llegar al límite de procesamiento del servidor.
Los clientes solo escriben el nombre o dirección IP del servidor que desean consul- tar en sus navegadores web, y el servidor responderá con la información solicitada.
En la Figura 1.6 se puede ver la perspectiva de los clientes, estos solo ven el con- tenido del servidor.
Figura 1.6: Perspectiva cliente web
Cuando un servidor web tiene un gran número de clientes generando una gran cantidad de tráfico33 es natural que un solo equipo físico o virtual se sature y no sea suficiente para satisfacer las necesidades de todos los clientes, por lo tanto es común que tener un clúster34 de servidores o varios servidores con la misma información para poder responder a todas las peticiones.
Suponiendo que no se cuenta con un clúster de servidores, solo con servidores ré- plicas, para los usuarios de una página web (un servidor web) sería molesto tener que cambiar la dirección en el navegador si el servidor los atiende con un retardo
33En este caso, la cantidad de tráfico es relativa a la capacidad del o los servidores, ya que para un servidor de pocos recursos con contenido multimedia, el tráfico generado por unas decenas de clientes puede ser grande, mientras que para un clúster de servidores, varios millones de clientes pueden generar una cantidad de tráfico que se considere grande.
34Un clúster en su modo más simple es un conjunto de dos o más computadores, que trabajan como un solo computador de mayor capacidad de procesamiento, para dar una solución a una problemática[30].
considerable o no los atiende, los usuarios buscarían la información que necesitan en otra página (otro servidor). Esto implicaría pérdidas a corto y largo plazo para los dueños del sitio web, para evitar esta pérdidas se puede utilizar un enmascara- miento de todos los servidores detrás de una única dirección o nombre, este trabajo lo puede realizar un Balanceador de Carga.
1.3.3. BALANCEADOR DE CARGA [3],[31]
Un balanceador de carga puede ser un equipo físico o un software, su trabajo es distribuir la carga35 entre varios servidores del mismo tipo, para este proyecto ser- vidores web.
Un balanceador de carga también puede tratar con los fallos de conexión de los servidores, es decir si el servidor deja de funcionar, el tráfico de este será enviado hacia otros servidores que estén en funcionamiento.
Los balanceadores de carga tienen diferentes métodos para realizar su trabajo, estos métodos pueden ser manuales, automáticos o una combinación de ambos.
En el método manual se programa directamente la regla en el balanceador, un ejemplo de este se muestra en la Figura 1.7, donde se puede ver el conjunto de servidores, el balanceador de carga y los clientes. En el balanceador de carga se tiene programado que en caso de fallar el servidor “a”, el tráfico de este se enviará al servidor “c”.
Se puede deducir que este método de balanceo puede llegar a ser muy poco efi- ciente en una red, ya que se puede sobrecargar a un solo servidor en vez de distri- buir la carga en varios.
Por otro lado, los métodos automáticos son mas eficiente que los manuales ya que la carga se distribuye dinámicamente según algún patrón programado en el balan- ceador, estos patrones que realizan el balanceo se implementan de acuerdo a algún algoritmo de encolamiento.
1.3.3.1. Algoritmos de encolamiento [15] [11]
Para el desarrollo de este proyecto se eligió tres algoritmos de encolamiento: FI- FO, Round Robin y Deficit Round Robin. Estos serán la base de los métodos para balanceo de carga de la aplicación a implementarse.
35Se entiende por “carga” al tráfico generado por los clientes.
Figura 1.7: Balanceo de carga manual
1.3.3.1.1. FiFo (First in - First out )
El primero que entra, es el primero que sale, en el contexto cliente-servidor quiere decir que el primer cliente que realice la petición será atendido primero.
La Figura 1.8 ilustra lo mencionado en el párrafo anterior. En esta se puede observar una nube de clientes y una nube de servidores, para este sistema nunca se pierde el orden, en el momento de hacer una petición, cada cliente se pone en cola y una vez que esté disponible algún servidor, el cliente que está primero en la cola sale de la misma, es atendido y el proceso continúa, no existe ningún tipo de priorización, todo depende de los tiempos de llegada.
Un inconveniente con FiFo es el tamaño de la cola, si esta se llegara a llenar, los próximos clientes no serían atendidos, es decir sus peticiones solo serían ignora- das. Este modo de balanceo puede ser fácilmente implementado y puede llegar a ser útil como enlace entre una conexión de alta velocidad y una de baja velocidad.
Figura 1.8: FIFO
1.3.3.1.2. Round Robin
Este algoritmo integra los servidores en un conjunto y les da un orden. Los servido- res, desde el primero hasta el último, atenderán cada uno a un cliente, después de que el último atienda al cliente que le corresponda, otra vez atenderá el primero y continuará el ciclo hasta terminar de atender a todos los clientes.
En la Figura 1.9 se muestra un ejemplo del proceso Round Robin con tres servido- res, en la cola que se puede ver están los clientes enumerados según su llegada y a la derecha se puede observar un conjunto de servidores representado en un gráfico de tipo pastel que gira en sentido antihorario cada vez que un servidor atiende a un cliente.
1.3.3.1.3. Deficit Round Robin
Este algoritmo está basado en Round Robin, pero tiene varios parámetros adiciona- les que proporcionan una forma de encolamiento que considera el número de bytes que puede aceptar cada servidor en una ronda.
En este algoritmo se consideran los siguientes parámetros:
quantum, es el tamaño máximo de un paquete que puede ser recibido en la ronda actual por un servidor.
deficit-counter, es un contador de deficit, es decir este aumenta si el tamaño del paquete es mayor al quantum.
Para explicar el proceso de Deficit Round Robin se considera que cada servidor tiene su propia cola y solo procesará los paquetes que estén en su cola; además se asume que el quantum es fijo para cada servidor.
Para empezar a recibir los paquetes se debe fijar los valores del quantum en un valor estático y deficit-counter en cero (q = valorVdc = 0).
A continuación se dan a conocer los pasos del proceso Deficit Round Robin:
Figura 1.9: Round Robin con tres servidores.
1. Se actualiza el deficit-counter a su valor más el valor del quantum (dc = dc+q).
2. Se compara si el tamaño del paquete es menor que el deficit-counter (paquete ≤ dc).
Si es menor, el paquete se envía al servidor y el deficit-counter se resetea a cero (dc = 0) y el servidor termina su turno.
Si es mayor, el paquete se queda en la cola del servidor y espera para ser enviado en la siguiente ronda, el deficit-counter se iguala al valor del quantum (dc = q) y el servidor termina su turno.
En la Figura 1.10 y Figura 1.11 se muestra el proceso Deficit Round Robin con tres servidores. Cada servidor tiene un quantum diferente, pero constante para todo el
proceso, en las figuras existen dos partes claramente diferenciadas, los paquetes y los servidores, en cada paquete se tiene el orden de llegada y entre paréntesis el tamaño del mismo, en cada servidor se tiene los valores del deficit-counter y del quantum para cada paso en el proceso.
1. En ‘a’ se puede ver el arribo del primer paquete, de modo que comienza el proceso:
dc1=0; q1=1000; paquete1=1800 dc1=dc1+q→ dc1=0 + 1000 = 1000 dc1<paquete1→ dc1=q1=1000
El paquete1se encola y el servidor termina su turno.
2. En ‘b’ se puede observar que el defict-counte del primer servidor no es cero y el segundo servidor atenderá al segundo paquete:
dc2=0; q2=2000; paquete2=1100 dc2=dc2+q→ dc2=0 + 1100 = 1100 dc2>paquete2→ dc2=0
El paquete2se envía al servidor y termina su turno.
3. En ’c’ el tercer paquete está por ser procesado:
dc3=0; q3=1500; paquete3=1500 dc3=dc3+q→ dc3=0 + 1500 = 1500 dc3=paquete3→ dc3=0
El paquete3se envía al servidor y termina su turno.
4. La parte ‘d’ de la Figura 1.11 presenta el inicio de la segunda ronda, por lo que es nuevamente el turno del primer servidor:
dc1=1000; q1=1000; paquete1=1800 dc1=dc1+q→ dc1=1000 + 1000 = 2000 dc1>paquete1→ dc1=0
El paquete1 se envía al primer servidor y termina su turno encerando su deficit-counter.
5. En ‘e’ se muestra que el cuarto paquete está por ser atendido:
dc2=0; q2=2000; paquete4=800 dc2=dc2+q→ dc2=0 + 2000 = 2000 dc2>paquete4→ dc2=0
El paquete4se envía al segundo servidor y termina su turno.
6. En ‘f’ se ve el quinto paquete en la cabeza de la cola de llegada:
dc3=0; q3=1500; paquete5=800 dc3=dc3+q→ dc3=0 + 1500 = 1500 dc1>paquete5→ dc1=0
El paquete5se envía al tercer servidor y termina su turno.
Figura 1.10: Deficit Round Robin con tres servidores (Parte 1)
Figura 1.11: Deficit Round Robin con tres servidores (Parte 2)
Este proceso se repetirá mientras haya paquetes en cola. Como se puede observar Deficit Round Robin trabaja de igual manera que Round Robin siempre y cuando los paquetes no excedan el tamaño del quantum.
En el siguiente capítulo se diseñará y codificará la aplicación para balanceo de carga, que tendrá tres modos de balanceo, los mismos que se basarán en los algo- ritmos explicados en esta sección.
CAPÍTULO 2
DISEÑO Y DESARROLLO DE LA APLICACIÓN
En este capítulo se presentará el análisis de requerimientos realizado para el diseño de un balanceador de carga, después se elegirá los criterios para el encolamiento en base a los algoritmos analizados en el capítulo anterior, a continuación se reali- zará el diseño de cada etapa de la aplicación y se mostrará el proceso de desarrollo en cada etapa.
2.1. ANÁLISIS DE REQUERIMIENTOS [17]
En esta sección se realiza el análisis de requerimientos para la aplicación a desarro- llada. No existe un cliente que pueda ser parte del proceso, por lo tanto se analiza los requerimientos de un balanceador de carga básico y se adiciona los requeri- mientos para su funcionamiento en una SDN.
Se consideran varios tipos de requerimientos como: ambiente físico, usuarios o factores humanos y funcionalidad.
2.1.1. AMBIENTE FÍSICO
Los requerimientos de ambiente físico se refieren al lugar físico donde funcionará la aplicación. Con respecto a este tipo de requerimientos, se tiene:
La aplicación debe funcionar con switches que soporten el protocolo Open- Flow como el Switch HP-Procurve 3500 de 24 puertos.
2.1.2. USUARIOS Y FACTORES HUMANOS
Estos requerimientos se refieren a los usuarios de la aplicación y la capacitación acerca del uso de la misma. Estos requerimientos son:
El acceso del usuario a la aplicación debe ser solo a nivel de configuración, por lo tanto es necesario que la configuración se realice desde un archivo externo
a la aplicación, lo que evitará que el usuario tenga que editar el código de la aplicación.
2.1.3. FUNCIONALIDAD
El análisis de este tipo de requerimientos dice lo que se necesita que haga la apli- cación y como lo debe hacer. Las funcionalidades de la aplicación deben obedecer a los siguientes requerimientos:
Debe trabajar como balanceador de carga para los servidores web.
Debe trabajar en una red con soporte del protocolo OpenFlow.
Debe enmascarar las direcciones de los servidores, es decir mostrar solo una dirección a los clientes.
Debe tener tres modos de operación, basados en FIFO, Round Robin y Deficit Round Robin.
Debe actuar cada vez que llegue un nuevo cliente.
2.2. CRITERIOS DE ENCOLAMIENTO
En esta sección se selecciona el criterio para distribuir la carga entre los servidores web. Estos criterios de distribución o balanceo de carga se basan en los algorit- mos vistos en el Capítulo 1 y teniendo en cuenta los requerimientos extraídos del apartado anterior.
Antes de elegir un criterio para el balanceo de carga, se consideró que la aplicación trabajaría en una SDN, por lo tanto de ser posible se trabajaría introduciendo flujos en las tablas de los switches, para reducir el tiempo de retardo de cada paquete.
Por otro lado, los algoritmos de encolamiento mencionados en el capítulo anterior generalmente se implementan a nivel de paquetes, pero en el escenario que se ma- neja para este proyecto el procesamiento de cada paquete no sería algo eficiente, ya que cada paquete debería ir hasta el controlador, que es la entidad que realiza el procesamiento, y aumentaría el retardo en cada uno de estos.
Después de analizar las condiciones mencionadas en el párrafo anterior se decidió realizar la selección, diseño e implementación de la aplicación a nivel de clientes, es decir, los criterios de encolamiento están orientados a distribuir clientes a cada servidor, no paquetes.
2.2.1. FIFO
El criterio de encolamiento basado en FIFO es el que se representa en la Figura 2.1, en esta se puede observar un sistema en funcionamiento formado por varios servidores, el controlador Ryu, un switch OpenFlow y el arribo de los clientes que se puede notar en la parte a de la Figura.
Figura 2.1: Criterio de encolamiento basado en FIFO
FIFO implica solo el orden de arribo, pero al tratarse de una aplicación que distri- buye a los clientes, no solo basta con tener en cuenta el orden de llegada, por este motivo se decidió implementar un mecanismo de distribución a la salida del switch, este mecanismo distribuye los clientes de manera aleatoria entre los servidores disponibles, es decir, se conserva la base de FIFO en el switch, que es direccionar primero al cliente que llega primero, pero el servidor que lo atiende puede ser cual- quiera de los disponibles, sin un orden especifico en estos, este comportamiento se puede ver en la parte b de la misma figura.
2.2.2. ROUND ROBIN
La Figura 2.2 representa el criterio basado en Round Robin, aunque es parecida a la mostrada en la Sección 2.2.1, la diferencia fundamental entre estos dos es el mecanismo de distribución a la salida del switch, en este caso se puede ver que en
b
los clientes son distribuidos utilizando Round Robin, es decir, los servidores han sido ordenados y los clientes se reparten entre los servidores de forma cíclica, de uno en uno empezando por el primer servidor.
Figura 2.2: Criterio de encolamiento basado en Round Robin
2.2.3. DEFICIT ROUND ROBIN
Después de analizar el algoritmo Deficit Round Robin, se concluyó que este solo podía ser implementado completamente a nivel de paquetes, como se explicó en la Sección 2.2 para este proyecto no es conveniente una implementación a nivel de paquetes, por lo tanto solo se utilizaron ciertos aspectos de Deficit Round Robin, como el control del número de bytes y el orden de tratamiento de clientes para la selección del criterio que se explica a continuación.
En la Figura 2.3 se representa como funciona el sistema aplicando el criterio basa- do en Deficit Round Robin, se pueden diferenciar tres partes en esta figura: en a se tiene el orden de llegada de los clientes, en b se destaca la interacción entre el controlador Ryu y el switch OpenFlow, ya que se realiza una constante retroalimen- tación entre estos, lo que permite llegar a c que es el direccionamiento de cada cliente al servidor con menos carga en el momento de la petición.
2.3. ETAPAS DE LA APLICACIÓN
La aplicación se diseño en tres etapas, una etapa de recepción de paquetes, una de procesamiento y finalmente la etapa de creación de reglas.
2.3.1. RECEPCIÓN DE PAQUETES
Para esta etapa, primero se considera si el paquete es ARP o no.
Las direcciones de los servidores físicos están ocultas tras una dirección IP publica
Figura 2.3: Criterio de encolamiento basado en Deficit Round Robin
así como una dirección MAC válida, y la respuesta ARP se necesita únicamente para que los clientes puedan llenar sus tablas ARP, por lo tanto no es necesario que estas peticiones lleguen a los servidores físicos. Las únicas peticiones que llegarán a los servidores serán de tipo HTTP o HTTPS.
2.3.1.1. Paquetes ARP
Para el tratamiento de las peticiones ARP, la aplicación trabaja como se muestra en el diagrama de flujo de la Figura 2.4, el cual muestra el funcionamiento en caso de recibir un paquete ARP de parte de un cliente. A continuación se explica el diagrama:
La aplicación recibe la petición ARP.
Se comprueba si el paquete se dirige hacia la dirección IP publica de los ser- vidores.
Se construye un paquete ARP de respuesta con la dirección publica.
Se envía el paquete de respuesta ARP hacia el cliente que hizo la petición.
2.3.1.2. Paquetes no ARP
Para los paquetes que no son ARP, se trabaja como muestra la Figura 2.5, el pro- ceso es:
Se revisa la dirección de destino del paquete.
Figura 2.4: Funcionamiento en caso de paquete ARP
Si no es la dirección publica, se descarta el paquete.
Si es la dirección publica, se revisa el puerto destino, este debe ser el puerto 80 (HTTP) o el 443 (HTTPS).
En caso de no ser ninguno de los puertos del item anterior se descarta el paquete.
En caso que si sea uno de los puertos mencionados, este paquete pasa a la etapa de procesamiento.
2.3.2. PROCESAMIENTO
En la etapa de procesamiento es donde el controlador realiza un análisis del pa- quete que ingresó y decide hacia que servidor enviarlo de acuerdo al criterio de
Figura 2.5: Funcionamiento en caso de paquetes que no son ARP
balanceo que se esté utilizando, por lo tanto se tienen tres diferentes tipos de pro- cesamiento, uno por cada criterio: FIFO, RR (Round Robin) y DRR (Deficit Round Robin).
El funcionamiento general de esta etapa se puede observar en la Figura 2.6, donde se muestra como actuará la aplicación desde que inicia esta etapa, en a se rea- liza la selección del servidor, a continuación se explica más detalladamente este proceso para cada criterio de encolamiento.
2.3.2.1. Procesamiento FIFO
En la Figura 2.7 se observa el trabajo que realizará la aplicación en la parte a de la Figura 2.6, si el criterio seleccionado fue FIFO.
El procesamiento que se realiza en este caso es muy sencillo, solo se trata los paquetes en el orden de llegada y para enviarlo se selecciona un servidor aleatorio del conjunto de servidores disponibles.
