Adoptando redes definidas por software en la empresa

Transcripción

1 Documento técnico de TI de Intel Eficiencia de los Centros de Datos Redes definidas por software Mayo de 2014 Adoptando redes definidas por software en la empresa Resumen ejecutivo Al virtualizar la red mediante una interfaz programable, podemos ofrecer mejor soporte a los desarrolladores de aplicaciones de Intel. TI de Intel está adoptando redes definidas por software (SDN, software-defined networking) para habilitar el aprovisionamiento a pedido de redes y servicios de red. Al virtualizar la red mediante una interfaz programable, podemos ofrecer mejor soporte a los clientes internos desarrolladores de aplicaciones de Intel que trabajan en un entorno de desarrollo ágil y rápido. Estos clientes necesitan poder acceder a los recursos de red sin tener que negociar un cuello de botella creado por la configuración de redes y el aprovisionamiento de servicios. SDN puede ayudarnos a aumentar el valor empresarial de las máquinas virtuales (, virtual machines) en nuestros centros de datos y puede ofrecer los siguientes beneficios adicionales: Tiempo reducido de aprovisionamiento de red Proceso simplificado de creación de redes en un entorno de autoservicio Costos reducidos de servicio gracias a la mejor eficiencia en la administración de redes Recientemente, la industria de SDN realizó varias mejoras en el rendimiento y la escalabilidad de los componentes SDN. Durante los últimos dos años hemos evaluado lo siguiente para ayudarnos a determinar los beneficios de implementar SDN: Probar y analizar diferentes arquitecturas SDN para comprender el flujo de datos entre nodos Actualizar los roles y las responsabilidades de los empleados que crearán redes en un ambiente de autoservicio pero que quizás no tengan experiencia en ingeniería de redes A medida que continuemos adoptando SDN e implementándola en nuestro entorno de virtualización seguiremos evaluando cómo los componentes y las arquitecturas SDN pueden eliminar las barreras a los servicios de red para nuestros clientes, permitiéndoles implementar aplicaciones más rápidamente. Definir los casos de uso que justifican la implementación de SDN. Sridhar Mahankali Cloud Network Engineer, TI de Intel Sanjay Rungta Senior Principal Engineer, TI de Intel

2 Documento técnico de Adoptando redes definidas por software en la empresa Contenido Resumen ejecutivo... 1 El desafío empresarial... 2 Desarrollando el uso de la nube en nuestros centros de datos: Almacenamiento, computación y redes... 2 Beneficios empresariales esperados de una red virtualizada programable... 3 Solución... 3 Seleccionando una arquitectura SDN... 4 Arquitectura de red superpuesta... 4 Cambiando la arquitectura de seguridad... 6 Cambiando roles y responsabilidades... 6 Resultados preliminares... 7 Siguientes pasos... 7 Conclusión... 7 Información relacionada... 7 Siglas... 7 IT@INTEL El programa IT@Intel conecta a profesionales de TI alrededor del mundo con sus colegas dentro de nuestra organización-compartiendo lecciones aprendidas, métodos y estrategias. Nuestro objetivo es simple: Compartir las mejores prácticas de TI de Intel que crean valor para el negocio y convierten a TI en una ventaja competitiva. Visítenos hoy en o póngase en contacto con su representante local de Intel para obtener más información. EL DESAFÍO EMPRESARIAL TI de Intel opera aproximadamente servidores en 64 centros de datos que soportan a más de empleados 1. Durante más de una década, TI de Intel ha virtualizado los servidores en nuestros entornos de centros de datos empresariales, de oficina y de servicios. En el año 2000, llevaba más de 90 días aprovisionar una máquina virtual (). Hoy podemos aprovisionar una a pedido para acelerar el tiempo de comercialización para las unidades de negocios (BU, business units) que están desarrollando aplicaciones. Más del 85 por ciento de la carga de trabajo en los centros de datos empresariales, de oficina y de servicios se están ejecutando en. Sin embargo, los recursos de red han continuado siendo un cuello de botella para el aprovisionamiento a pedido, especialmente en nuestros centros de datos empresariales y de oficina. Por lo tanto, estamos buscando una solución para acelerar el aprovisionamiento de los servicios de red, lo que nos permitirá atender mejor la empresa. Desarrollando el uso de la nube en nuestros centros de datos: Almacenamiento, computación y redes Como se ilustra en la línea de tiempo en la Tabla 1, podemos ubicar el uso de la virtualización en Intel ya en el año En 1 Para definir Centro de Datos Intel usa la clasificación de tamaño de centro de datos de IDC: Cualquier cuarto de más de 100 pies cuadrados que aloje servidores y otros componentes de infraestructura. 2009, sólo el 12 por ciento del entorno de computación empresarial estaba virtualizado. Además, en ese momento llevaba más de 90 días aprovisionar una, y la confiabilidad del entorno virtualizado variaba. En 2009, comenzamos a virtualizar la mayoría de nuestro entorno de servidores para centros de datos empresariales y de oficina. Solo tres años más tarde, en 2012, el 75 por ciento del entorno de computación empresarial estaba virtualizado, el aprovisionamiento de computación era a pedido, y la disponibilidad se ubicaba entre el 99,7% y el 99,9%. A partir de 2014 (con el 85 por ciento de la computación empresarial virtualizada), planificamos continuar virtualizando los servicios de computación, de almacenamiento, y de red, así como también aprovisionar estos servicios a pedido. Esto nos ayudará a mantener el ritmo de la significativa expansión del ecosistema de desarrollo de aplicaciones de Intel. Con el modelo de aprovisionamiento tradicional de redes que usamos antes del modelo SDN, aprovisionar una red requería de cuatro a seis horas de tiempo total de trabajo; y con interrupciones, atraso en los pedidos de aprovisionamiento de redes y otras complejidades el proceso de aprovisionamiento de redes podía llevar hasta 13 días. La demora se transmitía a otras tareas que impactaban en las aplicaciones como ajuste de la seguridad, balanceo de carga local y global, y configuraciones del Tabla 1. Desde el año 2000, hemos pasado de un pequeño porcentaje de máquinas virtuales () a una nube privada en 2010, y a una nube híbrida hoy. Servidores virtualizados ALOJAMIENTO TRADICIONAL VIRTUALIZACIÓN TRADICIONAL INTEL CLOUD % 42% 75% 85% Aprovisionamiento Más de 90 días 10 días Computación a pedido NUBE HÍBRIDA CONVERGENTE 2.0 Computación, redes, y almacenamiento a pedido Pedidos de servicio Manual Manual Algunos a pedido Autoservicio completo Confiabilidad Confiabilidad variable de servidores Confiabilidad de de 99,7% Confiabilidad de 99,7%-99,9% Capaz de confiabilidad de 99,9% 2

3 Adoptando redes definidas por software en la empresa Documento técnico de sistema de nombre de dominio (DNS, domain name system). Para mantener el ritmo del volumen cada vez mayor de pedidos, necesitamos virar hacia la implementación de componentes programables de red en nuestro entorno de servidores de centros de datos empresariales y de oficina. Si bien las LAN virtuales (VLAN) y el enrutamiento y reenvío virtuales (VRF, virtual routing and forwarding) nos permiten virtualizar ciertos recursos de red además de la red física, esas tecnologías por sí mismas no tienen la programabilidad necesaria para la automatización y el autoservicio. Beneficios empresariales esperados de una red virtualizada programable Integrar los componentes de los servicios de redes programables en la red del centro de datos pueda ayudar a aumentar la agilidad, a simplificar el proceso de aprovisionamiento, y a reducir el costo total de propiedad (TCO). Agilidad. Configurar las redes y aprovisionar servicios como los balanceadores de carga y firewalls puede crear un cuello de botella en el proceso general de implementación de aplicaciones. Con una red virtualizada programable, podemos aprovisionar dinámicamente recursos de red desde una consola administrada centralmente o construir automatización personalizada adicional usando APIs. Anticipamos que la mayoría de nuestros servicios de red para centros de datos pueden aprovisionarse a pedido sin participación del administrador de la red. Simplicidad. Una red virtualizada con aprovisionamiento a pedido puede reducir la carga sobre el administrador de la red y facilitar a nuestros clientes la creación y administración de sus propias redes para el desarrollo de aplicaciones. TCO (costo total de propiedad).una red virtualizada con la capacidad de automatizar la configuración del equipo de red puede reducir la necesidad de configurar manualmente los componentes individuales de red. Esperamos que esta vista global programable de la red nos ayude a reducir el costo de las operaciones relacionadas con las redes. SOLUCIÓN Las capacidades de las redes definidas por software (SDN), ilustradas en la Figura 1, nos permiten virtualizar la red del centro de datos empresarial de manera similar a la virtualización de servidores. SDN separa el plano de control del plano de datos para proporcionar una interfaz centralizada y programable para la porción habilitada por SDN de la red. Al hacer que los componentes de red sean programables, SDN ofrece modelos multitenant más nuevos y control de acceso de seguridad distribuido, mejora la escalabilidad, y facilita una rápida innovación de servicios mediante aplicaciones de red. El entorno de nube privada basado en OpenStack* que hemos diseñado y adoptado en nuestra red de centros de datos empresariales proporciona un marco para integrar elementos SDN. Las API Neutron de OpenStack permiten el aprovisionamiento, modificación y eliminación de servicios de red mediante componentes de red programable, de código abierto y propietarios. Las capacidades SDN son relativamente nuevas para la industria y siguen madurando. TI de Intel está evaluando SDN para determinar si reducirá el tiempo de aprovisionamiento de redes, simplificará el proceso de aprovisionamiento de servicios de red, y reducirá los costos de servicio. Nuestra evaluación se ha centrado en probar y analizar el desempeño de los controladores SDN. El controlador SDN actúa como el núcleo de la SDN presentando una vista lógica de la red de cada usuario y administrando el control del flujo entre el hardware de red y los usuarios. CUALQUIER APLICACIÓN Virtualización de servidores Componentes de servidores físicos VN: Máquina virtual VN CUALQUIER UBICACIÓN VN Virtualización de redes VN Componentes de redes físicas Figura 1. De la misma manera que la virtualización de servidores crea múltiples máquinas virtuales () desacopladas de los servidores físicos, la virtualización de la red -es decir, la red definida por software (SDN)- crea múltiples redes virtuales desacopladas de los componentes de la red física. Evolución de la red: De la dependencia de un hardware al software abierto Cuando las redes de computación comenzaron a volverse populares, solo unos pocos proveedores fabricaban tanto el hardware incluyendo los chips de silicio que lo alimentaban como el software. Esto requería que las compañías compraran hardware, software, y servicios adicionales para aprovisionar una red de diferentes proveedores. A medida que maduró la industria, algunos proveedores comenzaron a concentrar sus esfuerzos en desarrollar componentes de hardware exclusivamente. Como resultado, el mercado de software se abrió y permitió que terceros desarrollaran y expandieran las capacidades del software. Con el advenimiento de las redes definidas por software (SDN), las compañías pueden regular el desarrollo de software y hacerlo más abierto. Creemos que SDN ayudará a eliminar la dependencia del proveedor al mismo tiempo que se simplificará y automatizará el proceso de aprovisionamiento de red.. DESACOPLADO 3

4 Documento técnico de Adoptando redes definidas por software en la empresa Seleccionando una arquitectura SDN Nuestra evaluación reveló que se puede implementar SDN de dos maneras. Un método utiliza OpenFlow*, una interfaz de comunicaciones de estándar abierto que permite el acceso directo y la manipulación de las tablas de reenvío. El otro método usa una red superpuesta, que contiene nodos y enlaces lógicos construidos sobre una red existente. Crea un servicio de red que no está disponible en la red física existente, donde cada enlace lógico puede consistir en numerosos enlaces físicos en la red subyacente. OpenFlow requiere nuevo hardware para soportar la tabla de reenvío de Open Flow. Una red superpuesta no requiere ningún hardware adicional de modo que no es necesario invertir en nuevos equipos. Además, hay diferentes versiones de OpenFlow, y no todos los proveedores de hardware de red y de controladores SDN soportan las mismas versiones. OpenFlow es apropiado cuando el flujo de datos es volátil y las redes necesitan reprogramarse con base en el cambio de flujo. Sin embargo, no tenemos un entorno de hardware homogéneo, y debido a que los flujos de datos entre nuestros nodos de partida y de destino suelen ser predecibles una vez establecidos, un modelo superpuesto nos proporciona más valor que un modelo OpenFlow. Desde 2012 hasta mediados de 2013 probamos cuatro controladores SDN con múltiples arquitecturas, que van desde una arquitectura basada en una superposición a una arquitectura basada en OpenFlow. Los criterios de prueba incluyeron benchmarks de ancho de banda de red y de rendimiento. La Figura 2 ilustra nuestro sistema de prueba. Realizamos nuestras pruebas en tres fases: Fase 1: Problemas de rendimiento del controlador SDN. Esta fase de prueba a principios de 2012 soportó la validez del concepto SDN e identificó algunos problemas de desempeño comunes a todos los controladores SDN que probamos. Estos problemas necesitarían ser resueltos por la industria antes de que podamos adoptar la tecnología. Por ejemplo, resultados de un escenario de prueba de una red 10 gigabit Ethernet (GbE) sin la red superpuesta mostró un rendimiento de 9,39 Gbps en dos en dos hipervisores. La misma configuración usando una red superpuesta mostró un rendimiento de solo 3,3 Gbps. Este rendimiento no mejoró cuando agregamos más a los hipervisores, lo que indicó que los controladores de superposición no estaban optimizados. Fase 2: Desafíos de escalabilidad. Durante esta fase de pruebas a fines de 2012 y comienzos de 2013, mejoró el rendimiento, aunque encontramos desafíos de escalabilidad. Descubrimos que la arquitectura no podía escalarse a un gran número de y de flujos. Para cada comunicación, se iniciaron nuevos flujos que no expiraron, por lo que la cantidad de túneles también aumentó en un gran número de. Fase 3: Flujos optimizados. La fase final de pruebas a mediados de 2013 reveló que los proveedores de productos habían abordado la proliferación de flujos y que el software había madurado y se había estabilizado. A pesar de que diferentes proveedores abordaron el problema de manera diferente, el resultado fue que cada pudo mantener la comunicación sin necesidad de transmitir a otras ; se optimizó el establecimiento de los flujos con base en las direcciones de partida y de destino. Arquitectura de red superpuesta La configuración de red superpuesta SDN ofrece el mayor valor en términos de optimizar el flujo de datos en nuestros centros de datos. En las segunda mitad de 2013, implementamos una red superpuesta en nuestro entorno de producción. La Figura 3 ilustra una vista de alto nivel de nuestra arquitectura SDN. Los tres componentes principales de esta arquitectura son el(los) controlador(es) SDN, los nodos de la puerta de enlace, y los nodos del hipervisor que se conectan a las usando interruptores virtuales. Túnel superpuesto sobre la red CONTROLADOR 1 2 n Hipervisor Procesador Intel Xeon serie 5600 CLIENTE 10GbE SWITCH 10GbE 10GbE Almacenamiento compartido (NSF) 10GbE 1 2 n Hipervisor Procesador Intel Xeon serie 5600 SISTEMA BAJO PRUEBA Figura 2. Configuración de prueba de Intel. Durante nuestra evaluación de las redes definidas por software (SDN) usamos una arquitectura basada en una superposición para probar y monitorear el rendimiento del controlador SDN, los problemas de escalabilidad, y la optimización del flujo. 4

5 Adoptando redes definidas por software en la empresa Documento técnico de CONTROLADOR SDN El controlador SDN hace posible una red SDN abstrayendo la red del hardware. El controlador en realidad una aplicación de software, no un hardware administra la comunicación entre las aplicaciones y los dispositivos de red. En una implementación grande, puede haber más de un controlador SDN, lo que crea un cluster de controladores SDN. El enfoque de centralización en una consola da como resultado una red inteligente caracterizada por flujos optimizados de comunicación y configuración automatizada, junto con una vista general de la red desde una única consola: Flujos de datos optimizados. Una red tradicional tiene una ruta única desde la partida del flujo de comunicación hasta su destino. El controlador SDN puede identificar muchas rutas para un flujo y puede dividir el tráfico del flujo en múltiples nodos. El controlador SDN optimiza la ruta de red para un flujo de datos en particular con base en los nodos de partida y de destino. Las capacidades aumentan el rendimiento y la escalabilidad de la red. Configuración automatizada. A diferencia de la configuración de red tradicional, manual, dispositivo por dispositivo, el controlador SDN ahorra tiempo y aumenta la precisión y consistencia de la configuración automatizando la configuración de los dispositivos de red. Este enfoque ayuda a ajustar fácilmente las configuraciones cuando cambian las condiciones de la red. En esencia, el controlador SDN ayudar a administrar toda la arquitectura de red como si fuese un único dispositivo. Vista general de la red. La consola del controlador SDN proporciona administradores de red con una vista global de la red completa, mejorando la eficiencia en la toma de decisiones y la administración. La interfaz programable del controlador SDN brinda a los administradores de red mayor control sobre el tráfico de red que lo que permite una red tradicional. Por ejemplo, nuestras políticas de seguridad pueden requerir que el tráfico entrante para un servidor en particular deba atravesar un firewall. Pero el tráfico saliente no plantea una amenaza de seguridad y no tendría que pasar necesariamente por el firewall. En una red tradicional, este nivel de control granular es difícil de lograr. Con SDN, un empleado que no sea un ingeniero de red puede programar fácilmente al controlador para redirigir el tráfico saliente de manera de circunvalar el firewall. Estas políticas pueden ser aplicadas mediante el controlador SDN a nivel de sesión, usuario, dispositivo y aplicación. NODOS DE PUERTA DE ENLACE/SERVICIOS Los nodos de puerta de enlace proporcionan una manera de integrar la arquitectura de la red física VLAN con la arquitectura de la nube habilitada por SDN, que es configurada y administrada por el controlador SDN. La capacidad de la puerta de enlace permite la integración de dos entornos, permitiendo que el hipervisor habilitado por SDN se comunique con la red no habilitada por SDN. Los nodos de servicio procesan la difusión, multidifusión, y establecimiento de flujo entre las diferentes. NODOS DE Los nodos de hipervisor alojan las. Como se ilustra en la Figura 3, cada nodo de hipervisor ejecuta el módulo de conmutación virtual, que es donde el controlador SDN construye las redes virtuales para los usuarios. Un único hipervisor alojaría de varias redes virtuales. El control de políticas es administrado por un switch virtual entre el hipervisor y las. Red virtual 1 Servicios de red Red virtual 2 Servicios de red Red virtual 3 Servicios de red VIRTUAL SO de nube Proveedor de servicios de nube Lógica de negocios CLUSTER DE CONTROLADOR SDN API PUERTA DE ENLACE FÍSICA MALLA DEL TÚNEL vlan Arquitectura física Figura 3. Una arquitectura de red definida por software (SDN) superpuesta consiste en tres componentes principales: un cluster de controladores SDN, nodos de puerta de enlace/servicios, y nodos de hipervisor. En esencia, un controlador SDN facilita la administración de toda la arquitectura de red como si fuese un único dispositivo 5

6 Documento técnico de Adoptando redes definidas por software en la empresa Muestra de grupo de seguridad a nivel del usuario Usuario de la aplicación Firewall del centro de datos físico Grupo de seguridad de administración Se aplica a todas las dentro del usuario y permite acceso de administración a los host bastión Grupo de seguridad web Permite acceso a la aplicación web desde Internet Servidores web Grupo de seguridad de base de datos Permite comunicación entre la base de datos y otras de aplicaciones Servidores de aplicaciones Servidores de bases de datos Figura 4. El modelo del grupo de seguridad muestra la flexibilidad del control de acceso a la red que tenemos con nuestro entorno de nube privada basado en OpenStack* con capacidades de red definida por software (SDN). Cambiando la arquitectura de seguridad La consumerización y otras tendencias de la industria han contribuido a aumentar el número de aplicaciones que se están aprovisionando en nuestros entornos de virtualización con conexión a Internet. Tradicionalmente hemos usado la segmentación basada en redes y el control de acceso a redes como los mecanismos primarios para asegurar las. En nuestro modelo de aprovisionamiento tradicional de red, dependíamos de dispositivos monolíticos de firewall externos para proporcionar el control de acceso granular a la red en estas y aplicaciones. Este tipo de modelo de seguridad presentaba desafíos a la escalabilidad, a la capacidad de soporte, y riesgos. Por ejemplo en algunos de nuestros entornos, el firewall externo debía ejecutar miles de reglas de seguridad, que creaba problemas en la capacidad de administración de la seguridad y aumentaba el potencial de infracciones. Nuestro entorno de nube privada basado en OpenStack combinado con las capacidades SDN nos permite pasar a un marco de seguridad más distribuido y concentrado en los usuarios. Cada usuario de aplicación se aprovisiona en su propio entorno de red virtual privada además de en nuestra nube privada. Nuestro control de acceso se administra dentro del entorno de red virtual del usuario usando grupos de seguridad. Los grupos de seguridad son esencialmente una colección de reglas de control de acceso que pueden ser activadas dentro de cada usuario. Se pueden aplicar múltiples conjuntos de grupos de seguridad a las para definir la seguridad de la red para esa, como se ilustra en la Figura 4. Al usar los grupos de seguridad a nivel del usuario de la aplicación ejecutados en los hosts, podemos implementar un conjunto más administrable de reglas de control de acceso para cada usuario y habilitar el autoservicio para administrar esas reglas. Los dispositivos de firewall físico pueden, entonces, utilizarse para asegurar el perímetro del centro de datos, al mismo tiempo que requieren un conjunto más pequeño y más administrable de reglas de seguridad. Cambiando roles y responsabilidades Ya no hay una separación estricta entre las responsabilidades de nuestros equipos de redes, servidores y computación cuando se crea una instancia de red. Con SDN, las capacidades de red que se implementaron alguna vez en un dispositivo de red física se implementan ahora en una red virtual. Por lo tanto, para adoptar SDN es necesario combinar las habilidades que se dividían anteriormente entre administradores de sistemas y administradores de red. Para cerrar esta brecha, hemos creado la función de administración de sistemas de nube. La red de autoservicio en acción Las redes definidas por software (SDN) convierten el aprovisionamiento de servicios de red en una actividad de autoservicio para los empleados que no sean administradores de red. Por ejemplo, Thomas Birch, Administrador de Programas de Incubadoras de TI en Intel, usa SDN para crear redes que permiten a las unidades de negocios (BU) de Intel lanzar un servicio web. Esta es una captura de pantalla de la interfaz web que Birch usa para administrar las redes que él crea. Para su caso de uso, Birch establece conexiones entrantes en una máquina virtual () estableciendo reglas de red. Él mira una, determina qué otras necesitan comunicarse con ella y por qué razón, e implementa y prueba la instancia de red, todo desde la interfaz web. Antes de que adoptáramos SDN, Birch debía requerir el aprovisionamiento de servicios de red al administrador de la red. Ahora él crea redes en tiempo real. Antes de SDN, dice Birch, había automatización limitada, y la configuración requería mucha modificación manual. Debía pedirle a un ingeniero de TI que abriera puertos específicos, lo que me convertía en un intermediario SDN me dio el control. Para crear una red de autoservicio, los empleados usan una GUI de web para aprovisionar una instancia de red virtual 6

7 Adoptando redes definidas por software en la empresa Documento técnico de Los representantes de cada equipo redes, servidores y computación son responsables de desarrollar y operar el entorno de nube. Estos representantes colaboran y comparten sus conjuntos de habilidades. Hay una curva de aprendizaje para los empleados que aprovisionan redes pero que no tienen necesariamente experiencia en redes. El equipo de ingeniería de red ayuda a estos empleados a entender algunos conceptos básicos y prácticas de seguridad de red, y luego la GUI de aprovisionamiento los guía el resto del camino. También estamos construyendo plantillas de entorno de aplicación intuitivas para facilitar a los clientes el aprovisionamiento de los componentes de red a pedido sin necesidad de contar con un extenso conocimiento en redes. Resultados preliminares El tiempo de aprovisionamiento de servicio ya está mejorando. La vista global del controlador SDN de la red y el beneficio del autoservicio habilitado por SDN están reduciendo la presión de que los administradores de red satisfagan acuerdos de nivel de servicio (SLA, service level agreements) en los pedidos de servicio de red. SDN está simplificando el proceso de aprovisionamiento de red. Crear redes requiere algo de capacitación, especialmente para los empleados que tienen poca o ninguna experiencia en redes. Sin embargo, después de obtener asistencia de los ingenieros de red y trabajar en la aplicación de administración SDN, los empleados disfrutan de los beneficios del enfoque de autoservicio. Aprecian la eliminación de las limitaciones para brindar soporte a las BU que trabajan para lograr un desarrollo ágil, mayor control sobre la implementación de redes, y la habilidad de implementar y probar en tiempo real. Los resultados iniciales de la prueba indican que SDN puede reducir los costos de servicio gracias a la administración de red más eficiente. También podemos conservar nuestra inversión de infraestructura actual y depender menos del hardware propietario y de dispositivos dedicados. SIGUIENTES PASOS En 2014, expandiremos la implementación de la red superpuesta desde nuestra instalación inicial en producción en También seguiremos explorando maneras de usar OpenFlow para agregar valor a la red superpuesta. Planificamos usar API para virtualizar servicios de red como balanceadores de carga y firewalls de aplicaciones web dentro de nuestro entorno de nube. Monitorearemos la sobrecarga de la CPU que estas capacidades agregarán a los hosts y, cuando correspondiere, descargaremos el procesamiento a hardware de más bajo nivel a un controlador de interfaz de red (NIC, network interface controller). A pesar de que la migración de un entorno de hipervisor a un entorno SDN presenta muchos desafíos, estamos explorando métodos para simplificar esta migración. A medida que evolucionemos de un modelo de seguridad monolítico a un modelo de seguridad distribuida, necesitaremos monitorear la escalabilidad, especialmente en términos de limitaciones del host. Pretendemos descargar el procesamiento siempre que sea posible. Para obtener más información sobre las mejores prácticas de TI de Intel, visite CONCLUSIÓN SDN virtualiza la red para nuestros entornos de nube y permite a los empleados que no sean ingenieros de red programar los componentes de la red superpuesta de modo de que podamos aprovisionar redes dinámicamente a pedido. Los servicios de red que antes llevaban varios días configurar ahora puedan prestarse en tiempo real mediante un enfoque de autoservicio. Estamos materializando los siguientes beneficios de SDN: Aprovisionamiento más rápido de servicios Creación de redes de autoservicio más simples Costos reducidos de servicio Además, tenemos más control sobre nuestra infraestructura actual, y dependemos menos del hardware propietario y dispositivos dedicados. INFORMACIÓN RELACIONADA Visite para encontrar contenido sobre temas relacionados (en inglés): Estrategia para los Centros de Datos de TI de Intel para la transformación empresarial Actualizando la arquitectura de la red del Centro de Datos a 10 gigabit Ethernet SIGLAS BU DNS GbE NIC SDN SLA TCO VLAN VRF unidad de negocios sistema de nombre de dominio Gigabit Ethernet controlador de interfaz de red red definida por software acuerdo de nivel de servicio costo total de propiedad LAN virtual máquina virtual enrutamiento y reenvío virtual 7

8 El software y las cargas de trabajo utilizadas en las pruebas de desempeño podrían haber sido optimizadas para desempeño únicamente en microprocesadores Intel. Las pruebas de desempeño, como SYSmark* y MobileMark*, se miden utilizando sistemas de computación, componentes, software, operaciones y funciones específicos. Cualquier cambio en alguno de estos factores puede dar lugar a que los resultados varíen. Debe consultar otra información y pruebas de desempeño que lo ayuden a evaluar en forma completa sus compras contempladas, incluido el desempeño de ese producto cuando se lo combina con otros productos. Configuraciones: Servidor (Sistema bajo prueba) Configuración de la PC cliente Configuración de la red Configuración del almacenamiento Aplicación Netperf* 2.5 Herramientas de recolección de datos usadas Modelo: Intel S5520UR (Urbanna) Procesador: Procesador Intel Xeon 3.33 GHz (2 sockets, 6 núcleos/socket), RAM de 96 GB, Hyper-threading deshabilitada BIOS: S B Adaptadores de red: 2 x Adaptador de Servidor Intel Ethernet X GbE al switch de 10GbE Controlador de red: ixgbe vmw-NAPI Hipervisor: ware ESX* 5.1 RC (versión ) Configuración de la invitada: 1 vcpu, RAM de 4 GB, RHEL 6.2 ( el6.x86_64), vmxnet3 y ixgbevf, 24 Big Switch Controller (Corona) versión beta Modelo: Intel S5520UR (Urbanna) Procesador: Procesador Intel Xeon 2.93 GHz (2 sockets, 6 núcleos/socket), RAM de 96 GB, Hyper-threading deshabilitada BIOS: S B Adaptadores de red: 2 x Adaptador de Servidor Intel Ethernet X GbE al switch de 10GbE Controlador de red: ixgbe vmw-N Hipervisor: ware ESX* 5.1 RC (versión ) Configuración de la invitada: 1 vcpu, RAM de 4 GB, RHEL 6.2 ( el6.x86_64), vmxnet3, 24 Modelo: Switch de 10GbE Extreme Networks Summit* X650 Conectividad de red: 2 x Adaptador de Servidor Intel Ethernet X GbE (desde el servidor) 2 x Adaptador de Servidor Intel Ethernet X GbE (desde la PC cliente) 1 x Controlador de 10 Gigabit Ethernet IX1-SFP+ 10GbE (desde NetApp FAS6240) NetApp FAS6240 Versión P1 Procesador Intel Xeon 2,53 GHz (8 proc), RAM de 48 GB 512 GB de PAM-II Almacenamiento 10GbE Rendimiento capturado de Netperf Aprovechamiento del sistema capturado en el host ware ESX* usando la utilidad esxtop LA INFORMACIÓN EN ESTE DOCUMENTO PRETENDE SER DE CARÁCTER GENERAL Y NO UNA GUÍA ESPECÍFICA. LAS RECOMENDACIONES (INCLUYENDO LOS POTENCIALES AHORROS DE COSTOS) ESTÁN BASADAS EN LA EXPERIENCIA DE INTEL Y SON SOLAMENTE ESTIMACIONES. INTEL NO GARANTIZA NI ASEGURA QUE OTROS PUEDA OBTENER RESULTADOS SIMILARES. LA INFORMACIÓN EN ESTE DOCUMENTO SE SUMINISTRA EN RELACIÓN CON PRODUCTOS INTEL. EL PRESENTE DOCUMENTO NO OTORGA NINGUNA LICENCIA, NI EXPRESA NI IMPLÍCITA, NI POR EXCLUSIÓN, NI DE NINGUNA OTRA MANERA, SOBRE NINGÚN DERECHO DE PROPIEDAD INTELECTUAL. A EXCEPCIÓN DE LO ESTABLECIDO EN LOS TÉRMINOS Y CONDICIONES DE VENTA DE INTEL PARA DICHOS PRODUCTOS, EN NINGÚN CASO INTEL SERÁ RESPONSABLE Y CONSECUENTEMENTE RECHAZA CUALQUIER GARANTÍA EXPLÍCITA O IMPLÍCITA CON RESPECTO A LA VENTA Y/O EL USO DE LOS PRODUCTOS INTEL, INCLUYENDO LAS RESPONSABILIDADES O GARANTÍAS RELACIONADAS CON LA IDONEIDAD PARA UN FIN DETERMINADO, LA COMERCIABILIDAD O LA INFRACCIÓN DE CUALQUIER PATENTE, DERECHO DE AUTOR U OTRO DERECHO DE PROPIEDAD INTELECTUAL Intel, el logotipo de Intel, Intel Xeon, Look Inside y el logotipo de Look Inside son marcas comerciales de Intel Corporation en los EE.UU. y/o en otros países. * Otros nombres y marcas pueden ser reclamados como propiedad de terceros. Copyright 2014 Intel Corporation. Todos los derechos reservados. Impreso en los EE. UU. Recicle, por favor 0514/WWES/KC/PDF US