Ya hace unos años que el proyecto Crossbow tuvo lugar y se implementó en plataformas tales como OpenSolaris, Illumos, y sus derivados. OpenIndiana es uno de sus actuales exponentes, y como es lógico, posee las caracteristicas de redes virtualizadas que su kernel posibilita.
Esto se veía como una fantasía en entornos GNU/Linux no sólo por cuestiones de tecnología (sabemos que aunque no sean tan extensamente usados, kernels como los de Illumos, o las diferentes variantes de *BSD son mucho más avanzados que el Linux), sino también por estandarización.
Para comenzar con este artículo, ingresemos en nuestro sistema dos términos: Software Defined Networking (SDN) y Network Functions Virtualization (NFV).
OpenDaylight es un proyecto que intenta establecer un framework de código y blueprints que permitan acelerar la generación y adopción de SDNs. Y no es sólo para GNU/Linux, sino que tiene aires de grandeza, y apunta a estar disponible para muchos sistemas operativos.
Limitaciones de la infraestructura de red actual Hoy en día los usuarios de redes se están volviendo muy exquisitos. El uso de infinidad de dispositivos móviles, asi como el poder interconectarlos con los sistemas que los alimentan está llevando a la industria a complicarse cada día más, y no poder responder, en tiempo y forma, a sus demandas, con la consiguiente pérdida de valor en el mercado. Aparte, cuando se quiere proveer lo que se requiere, la inversión en infraestructura de red es suficientemente alta como para plantearse si conviene o no continuar en ese mercado, o sencillamente bajar las persianas, y dejar que otro, con más espalda financiera, o con mejor existencia de infraestructura, tome el lugar.
Los protocolos de red tienden a ser definidos en forma aislada unos de otros, por lo que cada uno intenta resolver una problemática particular, para la cualha sido concebido. Claro esta, cuando los protocolos se desarrollan de esta forma, la complejidad derivada de su interacción puede escalar en forma geométrica con cada nuevo protocolo que se introduce. Inclusive, en algunos casos, la falta de flexibilidad de algunos fabricantes lleva a que sus productos sólo puedan “conversar” con un muy acotado conjunto de otros sistemas. A veces, inclusive del mismo fabricante.
Eso lleva, también, a que las infraestructuras de red se vuelvan relativamente estáticas, ya que una regla de oro en este tipo de entornos es que “si algo ya está funcionando, no se debe modificar por nada del mundo”. Y si se requiere de agregar o modificar su esquema, se debe, previamente, analizar todos y cada uno de los elementos que en él existen para evitar hacer más ruido de lo normal, y generar más problemas que soluciones.
Frente a esta política de lo estático en cuestiones de redes, tenemos la completamente opuesta referida a los servidores, donde la virtualización ha logrado que los usuarios ya no se preocupen por dónde estará su máquina, e inclusive en muchos casos ni siquiera sobre si es necesario o no contar con alguna. Lógicamente, esto también lleva a que la gente ya no esté muy interesada que digamos por el lugar físico donde estarán ubicados los sistemas, siempre y cuando sean alcanzables por las redes definidas, así como que cuenten con las necesidades de disponibilidad y calidad de servicio que se especifican en los contratos que se firman con los proveedores.
Hace muchos años las aplicaciones se encontraban alojadas en una única máquina y le brindaban servicio a una serie de clientes preestablecidos. Hoy en día, un servicio puede estar conformado por otros tantos distribuidos en infinidd de máquinas virtuales que tienen extensas y complejísimas conversaciones de intercambio de información. Esa máquinas virtuales, en la mayor parte de los casos, son tan dinámicas como para moverse de equipo físico a equipo físico por el hecho de mejorar aspectos de disponibilidad, consumo de recursos, o sencillamente para rebalancearse entre diferentes sistemas. Con entornos de este estilo, una infraestructura estática de red está completamente fuera de tono, y no puede abastecer este tipo de necesidades. Es muy común ver entornos donde se debe manejar en forma manual todo el conjunto de modificaciones derivadas de esto.
No pensemos en los casos en los que un vendedor de tecnología de red comienza a tener problemas financieros que lo llevan a tener que cerrar sus puertas, porque es ahí cuando la locura de los administradores de red puede verse bien desplegada. No se sabe, en el caso de cambiar una marca por otra, cuánto podrá o no interactuar con el resto del ecosistema, o si podrá realmente abastecer de este tipo de políticas a los servidores, tanto físicos como virtuales, que conforman un servicio. Pánico total.
Nacer del caos La importancia de un SDN es permitir a los usuarios de sistemas operativos que puedan programar las diferentes capas de red, separando el control de los datos o del forwarding de información. Cuenta con todas las bondades de la virtualización en el sentido más amplio del término, como ser la optimización de los recursos de red, mejorar los tiempos de implementación (siempre será mucho más sencillo pensar en la implementación de un vSwitch, o un swith virtual, que en la adquisición de uno físico, aprender su “idioma”, programarlo, probarlo, etc.), y sobre todo, permitir que otras porciones de software comanden la generación o modificación de redes según sea necesario.
Si, por ejemplo, un usuario requiere acceso a una porción de la red, pero sólo a través de un programa, uno podría pensar en la capacidad de ese programa de rearmar la estructura de la red que lo conecta con algún otro sistema de forma tal de enlazar la del usuario con la de destino. Si se quisiera hacer eso desde el punto de vista físico, no habría otra opción más que desplegar cableados y programar equipos que, dada la necesidad de contar con inteligencia en las capas superiores del conjunto OSI, de seguro no serían nada económicos.
Lo cierto es que cada vendedor de equipamiento que deseó implementar algo de este estilo lo hizo de forma bastante propietaria, inclusive algunas veces hasta privativa. En medio de este gran lío, nace un proyecto que apunta a estandarizar y entregar los elementos necesarios para que los desarrollos futuros estén basados en estos estándares, así como cumplan con los elementos necesarios para permitir la interoperabilidad tan deseada.
Qué mejor en este caso (caso o caos, úsese indistintamente) que un proyecto aparecido con una licencia EPL (Eclipse Public License, la que se usa para los proyectos Java, que no es la que personalmente más me gusta, pero está aprobada como licencia de código libre, ergo la tengo que aguantar con una sonrisa) que establece las bases para lo que vendrá. Y encima de todo, el proyecto se aloja ni más ni menos que en la Linux Foundation, que cada día demuestra, al menos hasta ahora y esperando no tener que remendar esta opinión en el futuro, estar un poco más a la altura de las circunstancias.
Los casos de uso La Open Network Foundation (ONF) es una entidad dirigida por proveedores de equipamiento de red notables, desarrolladores de aplicaciones y software de redes, fabricantes de computadoras y de semiconductores. Casi se podría decir que en la ONF “toda la carne está en el asador” (expresión típica de las costas donde vivo, Argentina, donde el asador siempre debe estar bien lleno de alimentos deliciosos).
La unión de estas figuras intenta fijar en un SDN funciones específicas que permitan la satisfacción de una variedad de necesidades.
A nivel de campus que permitan la centralización de las facultades de aprovisionamiento, así como la convergencia de los modelos de datos, voz, y video, en cualquier tipo de dispositivos, ya se trate de aquellos interconectados por redes cableadas como inalámbricas. En este caso los SDNs deben soportar el aprovisionamiento y la gestión completamente automatizada de los recursos de red, los que a la vez estarán definidos por por los perfiles de sus usuarios y de las aplicaciones que ellos deben utlizar.
A nivel de centro de cómputos, un SDN debe simplificar al máximo la virtualización de de la red, así como agilizar su escalabilidad a niveles utópicos, al menos al día de la fecha. Lógicamente, debe poder integrarse con los subsistemas de almacenamiento existentes, ya que los mismos también hacen uso extensivo de funciones de red, así como de virtualización.
A nivel de nube ya se trate de una privada o una pública, o inclusive una hibrida, un SDN debe permitir que los recursos de red sean generados de una forma completamente flexible, permitiendo la modificación topológica, o el cambio de arquitectura, de una manera natural, sin terribles esfuerzos de reconfiguración, y sobre todo sin pánico sobre lo que haya por debajo de ellos.
Obviamente, los proveedores de servicios se sentirán felices de utilizar este tipo de tecnologías, ya que las mismas permiten bajar drásticamente los costos de equipamiento, y ni que hablar de los esfuerzos de operación y administración de las redes.
Del caos puede nacer más caos, o no OpenDaylight supone el soporte para otros entornos anteriormente desarrollados, como ser OpenFlow, y promete ser suficientemente extensible como para hacerlo también con otros estándares abiertos del estilo de I2RS (Interface to the Routing System), VxLAN (Virtual Extensible LAN), o PCEP (Path Computation Element Protocol).
OpenFlow aparece en este escenario como la primera interfaz de comunicaciones estandarizada definida entre las capas de control y de forwarding de una arquitectura de un SDN, permitiendo entonces la manipulación directa de sus reglas tanto a nivel físico como virtual. Esto incluye switches, routers, y demás.
Con esto, que parece bastante trivial, se mueve el control de los switches y routers del interior de cada uno de ellos a una capa superior donde todos pueden ser manejados en una forma centralizada, y con un lenguaje estándar. Ergo, cualquier tarea de administración, incluyendo la automatización de la misma, pueden ser ejecutadas desde un único lugar, con un único método. El sueño del sysadmin, hecho realidad.
Hidrogenoterapia Así llegamos a Hydrogen, la primera versión de OpenDaylight, lista para bajar desde el sitio opendaylight.org en tres sabores: Base, Virtualization y Service Provider.
La versión Base está pensada para los que queremos hacer pruebas, verificar su funcionamiento, tanto en ambientes físicos como virtuales. Dentro de sus módulos encontramos los siguientes:
- Controller: Un SDN multiprotocolo altamente escalable y extensible basado en OSGi. OSGi son las siglas de Open Services Gateway initiative, y define especificaciones abiertas de software para permitir el diseño de plataformas multipropósito compatibles.
- Plugin OpenFlow: Se incorpora un módulo de compatibilidad con las APIs de este módulo.
- Bibliotecas de los protocolos de OpenFlow: Esto es una implementación de la versión 1.3 de la biblioteca de protocolos de Openflow, específicamente la correspondiente a la especificación de switches 1.3.3, que permite la interconexión de los puertos de OpenFlow contra los de los diferentes dispositivos físicos o virtuales de una infraestructura de red.
- OVSDB: Una base de datos que permite la gestión y manipulación de vSwitches. También es un protocolo de gestión usado para manipular la configuración de los Open vSwitches, que ha logrado un buen nivel de éxito gracias a su adopción por parte de varios fabricantes de switches ethernet. Entre las tablas que dicha base de datos posee encontramos las siguientes:
- Open_vSwitch: configuración de un switch virtual.
- Bridge: configuración de un bridge.
- Port: configuración de un puerto.
- Interface: configuración de un dispositivo físico de un puerto.
- Flow_Table: configuración de Openflow.
- QoS: configuración de niveles de servicio.
- Queue: cola de salida a nivel de QoS.
- Mirror: espejado de puertos.
- Controller: configuración de un controller OpenFlow.
- Manager: conexiones de gestión de OVSDB.
- NetFlow: configuración de NetFlow.
- SSL: configuración SSL.
- sFlow: configuración de sFlow.
- IPFIX: configuración de IPFIX.
- Flow_Sample_Collector_Set: configuración de Flow_Sample_Collector_Set.
Las relaciones entre estas tablas se puede ver a continuación:
- YANG Tools: Para los proyectos basados en OpenDaylight, un set de herramientas basadas en Java para NETCONF y YANG.
Un diagrama esquemático de OpenDaylight versión Base se puede ver a continuación:
La versión Virtualization agrega, a los elementos de la versión Base, los siguientes:
- Affinity Metadata Service: un conjunto de APIs para representar las relaciones de carga de trabajo y los niveles de servicios esperados de una red de este estilo.
- Defense4All: un framework para la detección y mitigación de los riesgos posibles ante un ataque del estilo DdoS (Distributed Denial of Service).
- Open DOVE: un esquema de virtualización de redes multiusuario basado en overlays, incorporado a las capas de control y de vSwitches.
- Virtual Tenant Network: una aplicación de virtualización multiusuario basada en OpenFlow.
Nótense las secciones resaltadas en el siguiente diagrama esquemático:
Finalmente, la versión para proveedores de servicio, o Service Providers, agrega aspectos necesarios tales como:
BGP-LS/PCEP: soporte para gestión de tráfico basado en BGP-LS, y PCEP. El primero no es más que el viejo y querido Border Gateway Protocol, y el segundo fue pensado originalmente considerando que su entrada podría ser una gráfica de red, y su salida podría ser un camino de red y configurado.
Un diagrama esquemático puede ser el siguiente:
Conclusion De seguro en el próximo tiempo veremos más y más proveedores de sistemas tanto de datos puros como de infraestructura de red afianzarse y garantizar su futuro a través de la adopción de estos nuevos paradigmas.
Como sea, no perdamos de vista a Illumos, y sus descendientes, ya que para cuando el tema comienza a formar parte de la mesa de diálogo y desarrollo por un lado, tenemos lo mismo pero ya desarrollado, y funcionando, desde hace más de un lustro en OpenIndiana y OpenSolaris.
