sábado, 14 de julio de 2012

De las redes IP a la virtualización de las redes: Las razones del SDN




FIDEL SALGUEIRO
 
Las Redes Definidas por Software (SDN) es un concepto emergente en el cual se desagrega la red integrada verticalmente con el fin de flexibilizarla y mejorar su capacidad de gestión. El principio detrás del SDN es permitir la «personalización masiva» de operaciones de red para soportar la prestación de servicios diferenciados en la nube. Es en esencia un concepto orientado a servicios Cloud.
Las SDN conforman un conjunto de tecnologías que integra planos de datos, control y gestión de la red a través de interfaces de programación de aplicaciones (API). Las API´s facilitan el desarrollo de un amplio conjunto de nuevas aplicaciones y servicios de red. Lo más importante es que abren la capacidad de desarrollo a los desarrolladores independientes, proveedores de servicio de valor añadido (VARs) y organizaciones de usuarios. Este es quizás el aspecto más importante del SDN, su apertura a la inteligencia colectiva.
EN EL PLANO DE DATOS
Las redes virtuales de área local (VLAN) se inventaron en la década de 1980 con el fin de ampliar el alcance geográfico de las redes Ethernet, su mayor fortaleza era permitir que grupos de usuarios se interconectaran de modo lógico y sin restricciones de ubicación física. Pese a ello, cuando comenzaron a utilizarse masivamente en la virtualización de servidores, se pusieron de manifiesto algunas de las limitaciones que poseen las VLAN´s tradicionales.
A nivel de capa 2 (modelo OSI), las VLAN´s están limitadas a un número de 4.000 VLAN, y en adición el tráfico de VLAN es solo gestionado en las fronteras de capa 2, lo cual es sumamente restrictivo para el tráfico virtual M2M que generan los servicios móviles orientados a la nube.
Por último, los proveedores de aplicaciones «Cloud» tienen, en particular aquellos que ofrecen soluciones de «Infraestructura como servicio», demasiados requerimientos de capacidad multiusuario que son mucho más granulares de lo que la VLAN´s pueden soportar.
Haciendo abstracción del plano de datos, es posible resolver estos problemas mediante la creación de túneles o lo que comúnmente se denomina «tunneling», técnica diseñada específicamente para satisfacer las necesidades de virtualización de servidores y arquitecturas en la nube. Este concepto permite crear redes lógicas vinculadas a recursos de cómputo y almacenamiento, según sea necesario, para entregar rápidamente un servicio IT, asignado de modo dinámico mediante la implementación de políticas que son parte de la configuración del túnel.
De esta manera la asignación de recursos se efectúa sin impactar el funcionamiento de la red física, limitando los posibles errores o interrupciones en el servicio y reduciendo el tiempo de despliegue global del servicio. Esta es una de las introducciones del SDN, que junto con el VXLAN o Virtualización extensible LAN (VXLAN), son protocolos de encapsulamiento que atienden el tráfico dentro del túnel, no refieren a la conectividad ni al funcionamiento de la red física, las políticas y servicios de red en los puntos de encapsulamiento / desencapsulamiento, son ahora un paso intermedio a la abstracción del plano de datos y no la actividad principal de la red, configurada en Switch, Router o Servidores.
La abstracción del plano de datos resuelve una serie de problemas para la virtualización en los centros de datos, pero agrega un nivel importante de complejidad en la superposición de las redes físicas y las redes lógicas, las cuales deben ser gestionadas simultáneamente. Debido a que las técnicas de túneles deben ser habilitadas a través de algún mecanismo de control, se desarrolla el OpenFlow.
OPENFLOW EN LA PRÁCTICA
En un Router o Switch, el plano de datos (el hardware) y el plano de control (el software) residen en el dispositivo. En OpenFlow, las distintas funciones de control, Protocolo Spanning Tree, el direccionamiento MAC, etc., están determinadas por el software del servidor en lugar del firmware, lo cual permite al controlador y a OpenFlow realizar muchas otras funciones tradicionales de control (como enrutamiento, firewall y balanceo de carga).
OpenFlow comenzó a atraer el interés de los equipos de redes de los grandes centros de datos que estaban en la búsqueda de un procedimiento que les permitiese soportar clusters de Mapreduce/Hadoop (modelo diseñado para el procesamiento en paralelo de grandes volúmenes de datos que dividen el trabajo en un grupo de tareas independientes. Es un estilo de programación en paralelo que está soportado por algunas nubes del estilo de capacity-on-demand tales como BigTable de Google Hadoop), los cuales tenían requerimientos de red muy específicos: Cada servidor virtual necesita un ancho de banda de red igual a todos los otros servidores, esto es como requerimiento de «ancho de banda transversal».
Los operadores de nube proveedores de Infraestructura como Servicio (IaaS) comenzaron las investigaciones sobre arquitecturas OpenFlow al ver que la misma llenaba los requisitos de ancho de banda transversal con un gran número de máquinas virtuales que se encontraban dispersas en los bastidores de sus centros de datos.
Estos proveedores de IaaS fueron impulsados igualmente por la necesidad de contar con soporte de multi-tenencia (gestión de identidad y acceso) un requisito que supera las capacidades de los scripts tradicionales y las VLAN, debido a las restricciones de escala y velocidad. Esto dio lugar a una nueva clase de aplicaciones OpenFlow y a la investigación en virtualización de la red, y es el origen del cambio que vendrá en las redes IP.
Las soluciones más actuales de OpenFlow incorporan una arquitectura de tres capas, donde la primera está compuesta por todos los switches Ethernet que estén habilitados con OpenFlow. Por lo general, se trata de switches Ethernet físicos que tienen la característica de OpenFlow habilitada. Hay dos capas de software en el servidor: un OpenFlow Controller y aplicaciones de software OpenFlow construidas en la parte superior del Controller, que ofrece una serie de funciones para las aplicaciones, como la administración de los recursos del switch en una visión unificada de la red, (superposición de las redes física y lógica), el «tunneling», la coordinación de aplicaciones y la provisión de bibliotecas comunes a las aplicaciones.
En la capa superior, las aplicaciones de software OpenFlow implementan las funciones de control real de la red, tales como la conmutación y el enrutamiento. OpenFlow se ha vuelto un tema controvertido en la industria de redes, en parte, porque termina por convertir el hardware de conmutación en un commodity. Dado que el protocolo requiere la cooperación entre el hardware de conmutación y el software del controlador, empresas como Cisco Systems se ven envuelta en un dilema, de allí su entrada al mundo de los servidores y la virtualización. Para aquellas empresas que se han involucrado en el desarrollo de OpenFlow, este se ha convertido en una manera de acelerar la innovación y diferenciar realmente sus soluciones de hardware.
Sin dudas OpenFlow y Software-Defined Networking generarán una verdadera ruptura. El mejor ejemplo de una industria que está siendo transformada por este tipo de arquitecturas es la telefonía móvil y sus tiendas de aplicaciones. Antes una sola compañía fabricaba el teléfono, su sistema operativo y sus «apps», agendas, algunas aplicaciones sencillas y tal vez un par de juegos. Hoy, estamos en la era de los Software-Defined Mobile Devices, dispositivos móviles definidos por el software. Esto ha dado lugar a la creación de ecosistemas completos de desarrollo de nuevas aplicaciones.
Durante los próximos años veremos progresión constante de nuevas aplicaciones de software de redes que llegarán al mercado desde nuevos ecosistemas de empresa. Es todo un cambio de paradigma, en la forma como entendemos las redes.

Fuente: InsideTele.com