Vmware Documento PDF

C A SO D E U SO D EL P RO D U C TO
REDES DEFINIDAS
POR SOFTWARE EN
EL CENTRO DE DATOS
Los roles cambiantes de la
infraestructura de red de
software y hardware
REDES DEFINIDAS POR SOFTWARE EN EL CENTRO DE DATOS
Índice
Resumen ejecutivo: Redes definidas por software en el centro de datos 3
El software ya conquistó el mundo 3
La evolución de la red y las redes definidas por software 4
Requisitos del modelo basado en software para las actualizaciones de redes.5
Virtualización de redes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
Automatización. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
Extensiones en nubes múltiples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
Nativas en la nube . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
Seguridad de red . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
Administración de estructuras de conexión. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
Pautas de diseño basadas en software 9
Diseño para soluciones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
Seguridad intrínseca . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
Cobertura de activos virtuales y físicos. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
El estado mixto es la nueva norma. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
El centro de datos nuevo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
El camino hacia la adopción de la nube . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
Consideraciones clave y nuevos criterios de diseño 13

Interacciones entre el software y el hardware. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
Codependencia. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
Independencia. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
El hardware sigue siendo importante. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
División del trabajo. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
Intersecciones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
Infraestructura actual y futura . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
Overlays para la virtualización de redes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
La nube. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
Separación de la estructura de conexión . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
Simplicidad con virtualización. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
Una mentalidad en evolución 17
Apéndice A: La visión histórica 19
Velocidades, avances y el surgimiento de los "componentes comerciales". . . . . . 19
Software de redes en el centro de datos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
El surgimiento de la estructura de conexión . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
El software está conquistando el mundo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
De estructuras de conexión al administrador de estructuras
de conexión y las SDN. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
C A SO D E U SO D EL PRO D U C TO | 2
Resumen ejecutivo: Redes definidas por software en el centro

de datos
Todas las organizaciones de TI lidian con la complejidad. El hecho de tener
complejidad no es, en sí mismo, consecuencia de la mediocracia. De hecho, es lo
opuesto. La complejidad es un subproducto del éxito. La complejidad puede ser
un artefacto de crecimiento rápido o el resultado de fusiones y adquisiciones. Sin
embargo, independientemente del origen, la complejidad es un problema. Es el
enemigo de la eficiencia, la seguridad y la innovación.
Este documento propone una serie de principios de diseño que sientan las
"Las ofertas de redes
bases para mitigar la complejidad de TI y alcanzar nuevos niveles de eficiencia y
tradicionales no son seguridad. Dichos principios de diseño comienzan con una estrategia basada en
software que les permite a sus profesionales de TI administrar la complejidad del
adecuadas para satisfacer
pasado con el modelo coherente de redes y seguridad del futuro.
las expectativas El estado futuro de la red le brinda a su organización de TI la capacidad de crear
empresariales relativas redes dinámicas definidas por software que se basen en una infraestructura de red
física estática, estable y confiable. Además de ofrecer otros beneficios para TI y el
a la rápida entrega de negocio, esta estrategia de integración del software ayuda a que las funciones de
nuevos servicios, modelos redes y seguridad logren las características de la nube: agilidad, velocidad,
capacidad de administración y portabilidad.
de negocios más flexibles,
En su punto más alto, este documento plantea que los problemas que existen en
respuesta en tiempo real las redes de hoy no pueden resolverse con los enfoques de ayer. Para resolver los
y escalabilidad masiva".1 problemas de hoy y, al mismo tiempo, crear una plataforma para el crecimiento
futuro, las organizaciones de TI necesitan pensar de manera innovadora. La
—GARTNER mentalidad en términos de redes y seguridad debe evolucionar a una que
abandone los modelos del pasado centrados en el hardware para adoptar la
integración del software para las estrategias de redes del futuro.
El software ya conquistó el mundo

Pasaron siete años desde la publicación del artículo Why Software Is Eating the
World (Por qué el software está conquistando el mundo), de Marc Andreesen,
en The Wall Street Journal. Hoy en día, los argumentos presentados en el artículo
han quedado demostrados en empresas de todo el mundo. Una encuesta de Dell
Technologies y el Institute for the Future halló que el mantra de que "cada negocio
es ahora un negocio de software" se ha vuelto realidad: el 82 por ciento de los
encuestados prevén convertirse en un negocio definido por software en los
próximos cinco años.
Lo próximo es la red. No porque vaya a desaparecer la red física. Siempre habrá
infraestructura de red física para realizar tareas menores, lidiar con la latencia
o administrar flujos, entre otras funciones. La infraestructura de red física continúa
evolucionando y volviéndose extremadamente sólida según las necesidades
específicas de las estructuras de conexión de los centros de datos, las redes de
los campus y las redes de área amplia (WAN) enrutadas. El hardware conforma
un tejido de conexiones altamente confiables, lo que de por sí es una tarea difícil
de perfeccionar en pos de un modelo operacional sumamente eficiente. Sin
embargo, la historia nos ha enseñado que, cuando confiamos en el hardware para
hacer tareas más complicadas, como definir políticas que sigan automáticamente
cargas de trabajo dinámicas temporales, el hardware comienza a ceder a la presión.
Además, la nube no tiene límites de hardware y se extiende con transparencia por
centros de datos privados hacia los usuarios.
Cuando usted virtualiza la red y adopta una estrategia basada en software,

suceden dos cosas:
• Simplifica la infraestructura y aumenta significativamente su eficiencia.
• Refuerza la seguridad de la infraestructura, ya que quedan menos "costuras"
o brechas para explotar.
1
Gartner, 2018, Strategic Roadmap for Networking (Plan estratégico de redes), 3 de mayo de 2018, ID G00351455
W H I T E PA P E R | 3
La evolución de la red y las redes definidas por software

El antiguo mantra "No puede saber adónde va si no sabe de dónde viene" sigue
siendo válido para las redes modernas de los centros de datos de la actualidad. A
medida que nos adentramos en el motivo del cambio que atraviesa el mundo y en
cómo liderar con modelos de software es cada vez más importante, es fundamental
conocer la historia reciente de las redes para entender cómo llegamos al lugar
donde nos encontramos.
Por este motivo, agregamos un apéndice a este documento con una breve historia
"Después de décadas de de las redes en el centro de datos. Esta historia aporta contexto para los diferentes
objetivos que las redes procuran lograr, ya sea con nuevas tecnologías de software
centrarse en la velocidad,
o con tecnologías ancladas en el hardware.
el rendimiento de las redes
La evolución de las redes definidas por software
y las funciones, la futura
La Open Networking Foundation (ONF) define las redes definidas por software
innovación en materia (software-defined networking, SDN) como "la separación física del plano de
de redes apuntará a la control de la red del plano de reenvío, y donde el plano de control controla varios
dispositivos". Es un principio de diseño que se utiliza ampliamente en la actualidad,
simplicidad operacional
pero no es una solución real para casos de uso específicos. Aunque diferentes casos
y a modelos de negocios de uso aún utilizan este principio de diseño básico, los problemas que abordan
que estén estrechamente son muy diferentes. El diagrama siguiente muestra los casos de uso generales y
alineados con servicios la adopción del mercado que los impulsó.
elásticos basados en la
Procesamiento vSAN/ Nube Virtualización Nube Nube
virtual HCI privada de red pública híbrida
Virtualización
nube".2 Redes de
Firewall Firewall de -
Microsegmentación -
Microsegmentación
nubes múltiples
perimetral virtual appliance adaptativa
—GARTNER Seguridad
Principios de SDN Evolución de SDN
Acceso-agreg.-core Estructura de
Administradores de
de capa 2/capa 3 conexión leaf-spine
estructuras de conexión
Arquitecturas
de red
Administración de
estructuras de
Velocidades
conexión
de red
1/10 GE 40 GE 100 GE 400 GE
Figura 1. Casos de uso de alto nivel para redes definidas por software
Redes de nubes múltiples: La virtualización allanó el camino para la nube privada,

que requería la misma agilidad de la red que del resto del centro de datos. Esto dio
como resultado el primer caso de uso de virtualización de redes que completó la
automatización necesaria para el centro de datos definido por software (software-
defined data center, SDDC). La virtualización de redes separó las redes creadas
para máquinas virtuales (virtual machine, VM) de la red física. El nuevo perímetro
de red había hecho la transición a la virtualización con aproximadamente 80
millones de puertos virtuales hasta la fecha.3 Al mismo tiempo, las nubes públicas
comenzaron a convertirse en una realidad, haciéndola aún más crítica para una
red separada de software, con las mismas prácticas operacionales en entornos
dispares. Además, las aplicaciones iniciaron la transición a nuevas arquitecturas de
microservicios basadas en contenedores, lo que dio lugar a las aplicaciones nativas
de la nube. Este cambio demostró que la red virtual podía extenderse más allá de la
máquina virtual hacia nuevas cargas de trabajo futuras.
2
3
Cálculo interno de VMware.
Seguridad de red: La transición a la nube privada y el SDDC creó inherentemente un

gran depósito de recursos que coloca aplicaciones de sectores muy diferentes de la
organización una al lado de la otra. Por ejemplo, una aplicación de recursos humanos
(RR. HH.) podría ejecutarse en el mismo servidor físico que utiliza una aplicación
de finanzas. La protección de firewall perimetral, junto con la separación de zonas
desmilitarizadas (DMZ), no alcanzaba para impedir que los atacantes salten de una
aplicación a otra. La seguridad de red necesitaba una nueva forma de segmentación.
Los mismos principios para las SDN proporcionaron el próximo caso de uso de la
microsegmentación. El punto de control central, que también desarrollaba las redes
virtuales, podía segmentar creando redes únicas para cada aplicación e implementar
firewalls internos para proteger el tráfico entre aplicaciones. Esto también posibilitó
cambiar a modelos de seguridad de confianza cero.
Administración de estructuras de conexión físicas: La necesidad de redes físicas
no desaparece con las SDN. Las arquitecturas de redes físicas evolucionaron tanto
en diseño como en velocidad. El movimiento de datos dentro del centro de datos,
habitualmente denominado tráfico horizontal, comenzó a dejar atrás el movimiento de
datos entrantes y salientes. Las arquitecturas escalonadas heredadas no podían seguir
el ritmo, de modo que se adoptó un nuevo diseño spine-leaf. Este diseño dio lugar a la
tercera evolución de las SDN como administrador de estructuras de conexión físicas.
El mismo principio de diseño de las SDN podía separar las complejidades que conlleva
administrar y operar la estructura de conexión física controlando los protocolos de
interconexión y de redes físicas, y ofreciendo visibilidad avanzada.
Requisitos del modelo basado en software para las

actualizaciones de redes
A medida que su organización se aproxima a las actualizaciones de redes y adopta
soluciones definidas por software, es importante recordar que los impulsores de
negocios deben guiar las decisiones de infraestructura. Los impulsores pueden
consistir en objetivos de nivel alto para modernizar el centro de datos, estrategias que
den prioridad a la nube o cuestiones más tácticas, como una consolidación de centros
de datos en curso. De cualquier forma, la conversación debe comenzar a un nivel
estratégico que considere el negocio y sus prioridades.
Posteriormente, los profesionales de TI desarrollan un entorno que respalde la
nueva iniciativa mediante una estrategia de redes definidas por software de acuerdo
con las prioridades del negocio. Para la infraestructura, el requisito de redes en
LA VIRTUALIZACIÓN DE REDES nubes múltiples de alto nivel adopta la forma de la virtualización de redes, la
PUEDE AYUDARLO A: automatización, las extensiones en nubes múltiples y los enfoques de redes nativas
de la nube. La seguridad de red se convierte en una parte intrínseca de la carga de
• Reducir el tiempo de trabajo y las aplicaciones. La administración de estructuras de conexión pasa a
aprovisionamiento de la red iniciativas de eficiencia operacional.
de semanas a minutos
• Obtener mayor eficiencia Virtualización de redes
operacional mediante la La base de cualquier actualización de red con un enfoque basado en software
automatización de los procesos es la virtualización de redes. Comenzar con la virtualización de redes establece
una plataforma de base que es independiente de los futuros ciclos de hardware,
de cambio manuales
posibilita las migraciones de centros de datos y fluye sin dificultades desde el
• Ubicar y trasladar cargas de perímetro/la sucursal, el centro de datos y hacia la nube. De la misma forma en que
trabajo de forma independiente con la virtualización de servidor se reproducen las características de un servidor físico
con respecto a la topología en software, la virtualización de redes replica los componentes de los servicios de
física redes y seguridad en software. Por consiguiente, la red virtual se aprovisiona y
administra de manera independiente del hardware, y los dispositivos de red física
• Mejorar la seguridad de redes simplemente se convierten en vehículos para reenviar paquetes.
en el centro de datos
Tradicionalmente, los cambios en las redes se han considerado desde la perspectiva
• Promover la agilidad mientras de la aversión al riesgo. El dominio de fallas de la red puede ser el centro de datos
se satisfacen los requisitos de entero. La red simplemente tiene que funcionar, y los criterios clave de éxito se miden
tiempo de servicio del sistema como tiempo de servicio del sistema. La virtualización de redes aún mantiene el
mediante la reducción de los mismo objetivo del tiempo de servicio del sistema, además de lograr que la red
dominios de fallas simplemente funcione, pero también agrega la agilidad como una prioridad principal.
Dado que ahora se desarrollan redes para cada aplicación o incluso cada carga de
trabajo, los dominios de fallas ahora son pequeños y es posible realizar cambios
rápidos que brinden agilidad.
Con la virtualización de redes, sus administradores de red pueden aprovisionar

y modificar redes virtuales, incluidos switches lógicos, enrutadores, firewalls,
balanceadores de carga y VPN, en cuestión de minutos en vez de días o semanas.
Con estas capacidades, la virtualización de redes ayuda a su empresa a lograr
avances importantes en la simplicidad, la velocidad, la agilidad y la seguridad,
ya que se automatizan y se simplifican muchos de los procesos que se utilizan
en la ejecución de una red del centro de datos.
Con beneficios como estos, muchas empresas están aprovechando el poder
de la virtualización de redes para transformar su TI de infraestructuras basadas
en hardware a arquitecturas ágiles basadas en software. Al basarse en software,
pueden entregar los servicios con mayor rapidez, fortalecer la seguridad, mantener
las aplicaciones en pleno funcionamiento y obtener ahorros significativos en gastos
de capital y operacionales.
UN BREVE COMENTARIO SOBRE LA RESOLUCIÓN DE PROBLEMAS

Al igual que con todas las separaciones, un nivel significativo de integración
operacional ofrece la mayor visibilidad. Afortunadamente, dado que estas
separaciones no son netamente nuevas, puede implementarse un esquema
operativo común. De hecho, incorporar la capa de separación de redes
al software aumenta el nivel de visibilidad, ya que aumenta el nivel de
intersección de herramientas de redes y procesamiento. Por ejemplo, una
herramienta de redes tradicional es traceroute, que muestra los saltos en
una red. Esta misma herramienta está disponible, pero ahora comienza con
el host y puede incluir también toda la infraestructura virtual con contexto
de aplicaciones integrado.
CONSIDERACIONES DE DISEÑO
Automatización
DE ALTO NIVEL PARA LA La automatización no es un objetivo, es una necesidad. La automatización en una
AUTOMATIZACIÓN red virtual aprovecha las estructuras al nivel de la aplicación para convertirse en
1. La automatización debe parte de la solución, en lugar de un proceso acoplado. La "integración" puede
comenzar con estructuras significar muchas cosas diferentes, que se analizarán en detalle en la siguiente
integradas, no con enfoques sección de criterios de diseño. La automatización que forma parte de las
adosados donde se actúe estructuras a nivel de la aplicación es nativa del hipervisor para las máquinas
virtuales, en organizadores de contenedores como Kubernetes, y se extiende a
después de los hechos.
la nube. Conocer la automatización implica conocer los objetivos de los usuarios
2. El software puede eliminar destinatarios de la automatización.
las restricciones para la
automatización aprovechando
las estructuras de las cargas de Máquina virtual VDI Contenedores Nube pública
trabajo.
3. Así, las plataformas basadas
en software pueden extender
las integraciones nativas más
allá del centro de datos hacia
la nube y hacia la sucursal.
Estructuras nativas Interfaz de red de
Hipervisor Hipervisor y Interfaz de nube
necesarias para la contenedores y pública y organizador
y organizador Active Directory
automatización plataforma de contenedores
Figura 2. Estructuras de capa de aplicación
La terminología de las redes definidas por software comenzó con proyectos que se
basaban en el hecho de que las estructuras de redes, como el enrutamiento, las IP,
las redes de área local virtual (virtual local area network, VLAN) y los switches, eran
un cuello de botella en un proceso totalmente automatizado. Estos mismos cuellos
de botella dieron
Confidential
lugar a la nube y a la TI paralela. Se creaban entornos
! 2018 VMware, Inc. 1
completamente separados que eran ejecutados por desarrolladores, para

desarrolladores, como las nubes para desarrolladores.
La automatización integral, desde la sucursal hasta el centro de datos y la

nube, elimina los cuellos de botella de las redes. Pero, aunque la visión de la
automatización ubicua es importante, implementar y ejecutar dicha estructura
puede resultar difícil. Hay restricciones que se deben considerar.
TEORÍA DE RESTRICCIONES La automatización de las redes y la seguridad se suele ver limitada por la esencia
La teoría de restricciones es un inconexa de la infraestructura que ejecuta cargas de trabajo. El software puede
paradigma de la administración eliminar esta restricción mediante la inclusión de redes y seguridad en las
que considera que cualquier estructuras de las cargas de trabajo, como dentro de VMware vSphere®. Esta
sistema administrable se automatización de seguridad en redes virtuales abre las puertas al 80 por ciento
del beneficio. El 20 por ciento restante se aprovecha dando los pasos iniciales hacia
encuentra limitado para lograr
una estrategia basada en software: la virtualización de redes y la automatización.
plenamente sus objetivos por
Una vez que se han implementado la plataforma y el primer caso de uso, las piezas
una cantidad muy pequeña de restantes se acomodan rápidamente eliminada la restricción inicial.
restricciones.
Extensiones en nubes múltiples
Hoy en día, las nubes múltiples son una realidad muy común. El 86 por ciento de
las empresas ya han adoptado una estrategia de nubes múltiples, según un estudio
que realizó Forrester Consulting en representación de Virtustream.4 La elección de
una plataforma basada en software extiende una plataforma común a entornos de
nubes múltiples con políticas, componentes y cumplimiento en común.
El uso de plataformas diversas destinadas a un fin específico, como AWS y Azure,
conllevó un deterioro en la flexibilidad de TI que buscan ofrecer estas plataformas.
Estos sistemas específicos fuerzan una desaceleración en el desarrollo o hacen que
este se lleve a cabo en forma paralela a la TI. La red de nube virtual mitiga estos
desafíos. Utiliza virtualización de redes y automatización con seguridad intrínseca
para crear una arquitectura integral más amplia.
Esta arquitectura permite que los desarrolladores trabajen en cualquier lugar, sin
sortear la TI. Cada entorno de nube pública ha desarrollado su propio entorno de
infraestructura como servicio (Infrastructure-as-a-Serivce, IaaS) que actúa como
base para otras plataformas como servicio (Platform-as-a-Service, PaaS) y ofertas
diferenciadas únicas, como aprendizaje automático, servicios de bases de datos,
opciones de almacenamiento y mucho más. De la misma manera en que la
virtualización de redes se ejecuta en diversas estructuras de conexión físicas dentro
de un SDDC, estos servicios también pueden ejecutarse en infraestructuras de nube
pública. Esto permite que TI mantenga un control y operaciones comunes para las
redes y la seguridad, mientras que permite a los desarrolladores aprovechar los
beneficios únicos de cada una, sin preocuparse por cómo cada entorno de nube ha
implementado la IaaS.
Nativas en la nube
Las redes de nubes múltiples han creado un nuevo modelo que actúa como
una plataforma donde se adapta perfectamente la infraestructura lista para
desarrolladores. Es un entorno que "simplemente funciona" para los desarrolladores
y permite que TI mantenga el control, sin obstaculizar el trabajo del equipo
de desarrollo. Contenedores como servicio (containers as a service, CaaS) es
exactamente esto: infraestructura de TI implementada y administrada por TI.
En este caso de uso, los componentes de microservicios se configuran, aseguran,
optimizan y refuerzan individualmente para cumplir con los requisitos de TI.
Los desarrolladores nativos de la nube suelen tener algunas inquietudes básicas
(como entrega continua, una arquitectura de aplicaciones basada en microservicios
y un desarrollo que dé prioridad a los dispositivos móviles) y habitualmente buscan
soporte con varios lenguajes y marcos. Por lo general, es fácil hablar de nativo
de la nube en la burbuja de contenedores o en la burbuja de una nube pública
en particular. Pero es importante recordar que lo nativo de la nube tiene sus raíces
en el software, no en el hardware. Según la Cloud-Native Computing Foundation,
"nativo de la nube" es un enfoque que utiliza una pila de software de código fuente
abierto para implementar aplicaciones como microservicios.
4
Boletín informativo de Virtustream, New Study: Shifting Business Priorities Herald the Era of Multi-Cloud (Nuevo
estudio: Las prioridades cambiantes de los negocios anuncian la era de las nubes múltiples), 12 de julio de 2018.
Seguridad de red
La evolución de la virtualización a las nubes privadas y el SDDC trajo aparejado
el surgimiento de la microsegmentación. Partió de la noción de la segmentación
general de redes, que realizan estructuras de redes tales como VLAN, ACL e incluso
ALGUNOS BENEFICIOS DE TENER
firewalls físicos, y la acercó a la aplicación. Este cambio era necesario porque las
LA SEGURIDAD MÁS PRÓXIMA A LA
estructuras de redes no ofrecían suficiente seguridad, mientras que la protección
APLICACIÓN:
de firewalls físicos demostró no ser viable para segmentar todo el tráfico horizontal
• Se minimizan las brechas en en el centro de datos debido al costo y la complejidad. Para atender primero la
la posición de seguridad para necesidad de agilidad, la microsegmentación debe en primer lugar acercarse a la
evitar infracciones de datos carga de trabajo para estar lo suficientemente cerca del contexto de la "aplicación
• Se aseguran las aplicaciones que se desea conocer", pero lo suficientemente lejos de modo que no quede
sin obstaculizar el desarrollo ni expuesta al huésped y, por lo tanto, expuesta a ataques.
aumentar el tiempo de salida al
El paso siguiente es distribuir la función de firewall para asegurar un cumplimiento
mercado
de políticas amplio y profundo. El control continúa centralizado y colocado
• Se simplifican las auditorías con control de virtualización de redes para brindar los mismos beneficios de
automatización. La microsegmentación basada en los principios de las SDN a
través del uso de un firewall distribuido puede manejar políticas amplias junto
con un profundo nivel de inspección hasta la capa 7. Así, se puede automatizar la
creación de políticas de seguridad a través de herramientas en función del contexto
de las aplicaciones y la identidad, como Active Directory.
Con la base de seguridad intrínseca y de microsegmentación aplicada a las
máquinas virtuales, los mismos principios se extienden a las cargas de trabajo
nativas de la nube y de nube pública. Tener el control y el cumplimiento en
software permite que se muevan sin dificultades a otras cargas de trabajo. Esto
brinda uniformidad, no solo para las políticas, sino también para el cumplimiento.
Esto sirve como el fundamento del concepto de seguridad intrínseca que se
analizará con mayor detalle en las pautas de diseño.
Administración de estructuras de conexión

Los requisitos de administración de estructuras de conexión físicas se encuentran
inherentemente separados de los del resto de la red virtual. Aun así, ambos se
deben considerar juntos desde el punto de vista operacional, pero no como parte
del mismo caso de uso final. La estructura de conexión física se puede diseñar de
muchas maneras, desde protocolos basados en estándares hasta administradores
de estructuras de conexión patentadas, o algún punto en el medio. Los requisitos
de la estructura de conexión física están diseñados para satisfacer las necesidades
de entornos de infraestructura específicos (centro de datos, campus, sucursal) y
optimizados en cuanto a precio, rendimiento y latencia. Los requisitos originales
de tiempo de servicio del sistema y cambio mínimo se mantienen.
RECURSOS
Ciertas mejores prácticas observan la separación de deberes y objetivos
mientras se mantiene la simplicidad operativa. Pueden encontrarse ejemplos
de estas mejores prácticas en la Guía de diseño 2.0 para la implementación de
NSX Data Center con Cisco ACI como underlay.
Otras herramientas como VMware vRealize Network Insight pueden ofrecer

visibilidad en infraestructuras físicas y virtuales.
Para obtener más guías de diseño de referencia detalladas, consulte:
• Diseño de referencia de VMware NSX-T
• Guía de diseño de referencia para PAS y PKS con VMware NSX-T Data Center
Pautas de diseño basadas en software

Hasta ahora, analizamos los requisitos y vimos los diferentes enfoques hacia las
SDN. Como se detalla en la sección "Requisitos del modelo basado en software
para las actualizaciones de redes" de este documento, no todas las soluciones que
siguen los principios de las SDN realizan la misma tarea. Algunas soluciones incluso
pueden ser ofrecidas por diferentes proveedores. Esta sección incluye una serie
de pautas de diseño para pasar de una arquitectura de redes tradicional a una
arquitectura automatizada que funcione con desarrolladores y contenga seguridad
intrínseca y nube. Estos son algunos de los beneficios de las soluciones de VMware
NSX®, que brindan una plataforma de virtualización de redes para el centro de
datos definido por software (SDDC).
Las soluciones de VMware NSX suministran redes y seguridad íntegramente en
software, separadas de la infraestructura física subyacente e independientes a
cualquier red underlay. NSX se presta perfectamente a una estrategia basada en
software y a la red de nube virtual. Brinda conectividad integral y generalizada
para sus aplicaciones y datos, independientemente de su ubicación.
Suministrar una
infraestructura Red de nube virtual
Extender una lista para desarrolladores
Automatizar plataforma
para promover común Nativo de la nube
la seguridad
y agilidad Nubes múltiples y sucursal
Consolidar y
asegurar la
red existente Automatización
Virtualización de red Seguridad de aplicaciones y datos
Seguridad de red
Figura 3. Múltiples caminos para transformar las redes y seguridad
Diseño para soluciones

Confidential ! 2018 VMware, Inc. 1
Seguridad intrínseca
Aunque alguna vez fue simplemente puro debate tecnológico acerca del rol que
desempeña el hipervisor en materia de seguridad, hoy en día, la microsegmentación
es un término de marketing que utilizan muchas empresas para brindar una
solución acoplada a su manera. Los objetivos originales de la microsegmentación
aún son válidos, pero han evolucionado hasta convertirse en una parte intrínseca de
la red de nube virtual.
PERÍMETRO/SUCURSAL
Nube
SaaS
PaaS IaaS
Centro de datos
SEGURIDAD Y CONTROL
Firewalls físicos
Antes de 2013 2014-2018 2018

Firewalls perimetrales Microsegmentación Seguridad intrínseca en
con proceso manual con proceso automatizado todos lados en la implementación
Figura 4. Desde microsegmentación hasta seguridad intrínseca
Seguridad intrínseca:
• Crece con la carga de trabajo: Las estructuras de seguridad escalan junto con el
software donde se ejecutan.
• Evoluciona naturalmente a nuevas cargas de trabajo: Las estructuras son flexibles
a nuevos tipos que coincidan con el ritmo del software.
• Es independiente de los dominios: Las cargas de trabajo se pueden ubicar sin
dificultades en la zona desmilitarizada, en las instalaciones, en la nube, en
entornos alojados, o en el perímetro o la sucursal.
• Es amplia y profunda: Debe ser simple para comenzar de manera amplia y al
mismo tiempo tener el contexto, la automatización y la escalabilidad para cubrir
la profundidad.
• Es extensible: Las limitaciones están claramente definidas y las estructuras de los
socios están integradas.
La característica fundamental de la seguridad intrínseca es que hereda las

propiedades de la carga de trabajo.
Cobertura de activos virtuales y físicos

Todo esto plantea el interrogante: ¿Qué sucede con la carga de trabajo física? El
enfoque basado en software de la red de nube virtual envuelve las cargas de
trabajo de hardware nativas con software.
El primer punto de entrada es la zona desmilitarizada. La red de nube virtual
posibilita un enfoque de "zona desmilitarizada en cualquier lugar" que toma los
principios de seguridad de la zona desmilitarizada y los desacopla de la estructura
tradicional de red física y de procesamiento para maximizar la seguridad y
visibilidad de un modo más escalable y eficiente. El desafío que plantean los
métodos tradicionales para asegurar las fronteras es que el firewall o el centinela
normalmente protegen una única ubicación a lo largo de la frontera. Para controlar
exitosamente todas las actividades, tanto en la frontera como dentro de la
zona desmilitarizada, la solución de seguridad debe poder escalar para brindar
protección fronteriza para cada dispositivo individual en la zona desmilitarizada, así
como una red segura. Esto planteó un desafío al utilizar los enfoques tradicionales
basados en hardware. Con la red de nube virtual, una zona desmilitarizada puede
estar en cualquier lado.
Luego está la serie de cargas de trabajo que esperan migrar a un entorno virtual.
La red de nube virtual lleva a cabo esta migración mitigando el impacto de redes
y seguridad a través de la separación de software. A menudo, las cargas de trabajo
quedan abandonadas en el entorno físico cuando ya se acabó el tiempo o la
energía para el proyecto, pero gracias a la facilidad que ofrece la red de nube
virtual para la migración, estos recursos pueden regresar al entorno virtual.
Luego, existe una serie de sistemas heredados que no pueden virtualizarse (por
ejemplo, AIX) o sistemas que son inherentemente no virtuales (por ejemplo,
equipos de hospital). Estos sistemas son inherentemente reacios a las soluciones de
integración de software; de lo contrario, probablemente ya estarían virtualizados o
se virtualizarían eventualmente en el marco de iniciativas de Internet de las cosas.
Estos sistemas suelen tener sistemas operativos heredados o específicos que los
enfoques de seguridad de terminales de sistemas operativos nativos o basados en
agentes no pueden manejar. Para estos sistemas, la red de nube virtual adopta un
enfoque centrado en el hardware.
El primer flujo del tráfico de estos sistemas llega o viene de cargas de trabajo ya
integradas nativamente en la red de nube virtual. Tradicionalmente, este había sido
el escenario más difícil de cubrir, dado que el dominio virtual se llena de cambios en
tiempo real, pero los mecanismos para asegurar el entorno físico, como las listas de
control de acceso (access control lists, ACL) o los firewalls físicos, implicaban un
proceso manual. Ahora, con la seguridad hacia y desde el dominio virtual, estos
flujos son de los más simples. Constituyen una parte intrínseca de la red de nube
virtual.
W H I T E PA P E R | 1 0
Finalmente, están los flujos de entorno físico a entorno físico y, a diferencia de los
flujos de entorno físico a entorno virtual, son de los más simples de bloquear con
los métodos tradicionales. Estos flujos ahora pueden trasladarse al panel de
visualización único mediante herramientas de visibilidad e integraciones de firewall
incorporadas en la red de nube virtual.
Si la carga de trabajo ya es nativa de la nube, como es el caso de los contenedores
en el nivel básico de hardware, la seguridad intrínseca ya se encuentra establecida.
Con el complemento de red de contenedores en el nivel básico de hardware, las
cargas de trabajo de contenedores ya tienen extendida la red de nube virtual.
Visibilidad y operaciones integrales
…….
Zona desmilitarizada en cualquier lugar
……. Seguridad tradicional
Máquinas virtuales Contenedores
…….
Contenedores y PaaS
Infraestructura Infraestructura del

virtualizada nivel básico de hardware
NSX Microsegmentación
Figura 5. Seguridad virtual y física
Luego, la red de nube virtual se extiende a las oficinas o sucursales remotas

(Remote Office/Branch Office, ROBO) y a los usuarios finales. Debido a que la red
de área extendida definida por software (Software-Defined Wide-Area Network,
SD-WAN) lleva la WAN al software, los espacios de trabajo digitales y los escritorios
virtuales ya están todos integrados.
El estado mixto es la nueva norma

El objetivo de la uniformidad total al finalizar las actualizaciones de hardware de la
red ya no es válido. Una vez terminado un ciclo, el próximo ya ha comenzado. Los
dominios ajenos a la red física ahora existen en la nube y en entornos alojados. Se
puede afirmar que cualquier solución debe ser compatible con una diversidad de
hardware antiguo, hardware nuevo y nada de hardware. Prácticamente todas las
empresas tienen una mezcla de hardware heredado de redes, nuevo hardware de
redes y cargas de trabajo en áreas donde el hardware de redes está fuera del
control de TI (por ejemplo, nubes públicas, proveedores de servicios, etcétera).
Sucursales/remoto Clásica de 3 niveles Estructura de conexión de red Nubes públicas

y entornos alojados
Virtualización de red
Cualquier dispositivo, cualquier arquitectura, en la nube y alojado
Figura 6. Diseño del estado mixto de las redes
Proporcionar una overlay de redes simplificada en software permite completar la

actualización de redes físicas según consideraciones de la red física y simplifica la
migración a nuevo hardware de redes y administradores de estructuras de
conexión. La red overlay se encarga de las redes lógicas, lo que permite que se
actualice la infraestructura física sin interrumpir la automatización o el desarrollo
de aplicaciones.
Figura 7. Diseño del estado mixto de las aplicaciones
El centro de datos nuevo

Si está diseñando un nuevo centro de datos, la conversación sobre redes debería
comenzar con software que siente las bases para la organización entera. Sin
embargo, en muchos casos, las organizaciones cometen el error de mantener
aislada la decisión sobre las redes y utilizar de forma predeterminada la próxima
generación de equipos de redes del proveedor de redes actual.
Este error de planificación genera que la organización continúe arraigando las

soluciones en compras futuras de hardware. Las decisiones de incorporar el
último y mejor kit, junto con pilas de software e infraestructura convergente e
hiperconvergente, pueden eclipsar los objetivos finales que buscan alcanzar estas
soluciones. Para poner en funcionamiento el nuevo centro de datos, desde la
migración de cargas de trabajo hasta modelos operativos sin dificultades, la red
debe ofrecer una solución que pueda usarse no solo en el nuevo centro de datos,
sino también en todo el entorno actual, mientras se recorre el camino hacia la
adopción de la nube.
Aplicaciones
de 3 niveles
Aplicaciones
heredadas Aplicaciones
Aplicaciones nativas de la nube
nativas de la nube
Virtualización de red
+,-.('*
Nuevo centro de datos
!"#$"%&'()*
Centros de datos principales

Actualizaciones de red física
independientes de las aplicaciones /&-.()*
Figura 8. Migración y actualización sin dificultades
El camino hacia la adopción de la nube

Finalmente, ya sea que elija la próxima generación de switches o una tecnología de
administración de estructuras de conexión, adoptar un modelo basado en software
conlleva adoptar estrategias de nube. La actualización de la red es una oportunidad
perfecta para adoptar una solución que comience con software y pueda simplificar
la actualización.
The Virtual Cloud Network
Delivered by VMware NSX
Telco
Edge
Edge
Datacenter
Branch
Datacenter for VMware

Datacenter Telco
Branch
Telco
Branch
Edge
Figura 9. Consistencia integral

Confidential desde
©2018 VMware, Inc.el centro de datos hasta la sucursal y la nube 1
Consideraciones clave y nuevos criterios de diseño

En esta sección, ofrecemos consideraciones clave y nuevos criterios de diseño
que ayudarán a su organización a crear una base para una estrategia basada en
software que mitigue la complejidad de TI y permita nuevos niveles de eficiencia
y seguridad.
Interacciones entre el software y el hardware

A menudo, se piensa en la interacción entre el software y el hardware cuando
ya es demasiado tarde en un proyecto. Tener estas conversaciones de forma
temprana puede guiar a una estrategia más integral hacia las redes que acabe con
el aislamiento y ayude a reducir el riesgo. Estos son algunos de los problemas que
se deben considerar en estas conversaciones.
Codependencia
¿Los servicios de hardware y software se combinan para formar una capa
cohesionada de plano de datos, control y administración? ¿La combinación
es una buena o mala estrategia? La capacidad de servicio y de los dispositivos
de hardware, junto con su software de administración, se actualizará de manera
codependiente. Esta codependencia puede derivar en la actualización de algunos
componentes que son rehenes de otros componentes, lo que anula los beneficios
de velocidad y agilidad que aporta el software.
Incluso el hardware de redes se separa del hardware que ejecuta. Cumulus
Networks se fundó en 2010 con este ideal, y Cisco también comenzó a ofrecer
esta separación de sistemas operativos de redes de centros de datos y hardware
en 2018.5
Independencia
Si los servicios de hardware y software están desagregados, los ciclos
independientes de cualquiera de los servicios permiten la utilización del hardware
durante más tiempo y con menos preocupación por los plazos del ciclo de vida del
software. Esto permite que sus habilidades de software aumenten continuamente
con las últimas actualizaciones, con poca o nada de preocupación por la red
underlay. Un área de innovación no debe detener la innovación de otra área.
5
https://blogs.cisco.com/datacenter/new-portability-options-for-ciscos-data-center-networking
Cloud specific networking
Administración de
estructuras de conexión
Sistema SD-WAN
operativo Red de Redes SP
de la red nube virtual Sucursal
Redes de campus
Hardware
de red física
Figura 10. Puntos de separación de redes
Teniendo en cuenta estas dos cuestiones, ¿cómo es el ciclo de vida de la

aplicación? ¿Está directamente asociado al hardware o existe una delimitación
clara? ¿Deberían estar vinculadas las estructuras de redes virtuales con soluciones
de administración basadas en hardware? El software superará los paradigmas de las
soluciones limitadas por hardware en cuanto a velocidad de innovación, función de
servicio, escalabilidad y agilidad.
El hardware sigue siendo importante

Aunque hablamos de basarnos en software, el hardware sigue siendo importante.
Todos los entornos de centros de datos en las instalaciones requieren una
estructura de conexión de hardware para proporcionar movimiento de paquetes.
De forma similar, todos los entornos requieren servicios de software para ejecutar
la estructura de conexión de hardware y para impulsar la implementación de
aplicaciones, la administración y diferentes operaciones.
División del trabajo

¿Dónde se ubica la división del trabajo respecto de estos dos objetivos: administrar
una estructura de conexión de switches de hardware y administrar una pila
virtualizada para la aplicación y las dependencias de servicios relacionadas?
Encontrar ese punto de intersección debería ayudar a su organización a
proporcionar el nivel más alto de productividad operacional. Es el punto donde
se puede lograr la administración, la agilidad de aplicaciones y, sobre todo, el
nivel más alto de disponibilidad operacional. La plataforma virtual de la aplicación
debería apoyarse en este punto de intersección.
Intersecciones
El diseño de intersecciones no es nada nuevo para el software. Las interacciones
a través de interfaces de programación de aplicaciones (API) están bien definidas
NOTA DE ADVERTENCIA: y se utilizan en gran medida. Las aplicaciones se deagregan e interactúan a través
Si está investigando soluciones, de API. Ahora se está produciendo el mismo nivel de desagregación para el
recuerde que "integración" ahora software que ejecuta la infraestructura del centro de datos, pero de una forma
es un término de marketing que levemente más matizada. Las plataformas no solo exponen las API, sino que
debe tratarse con un alto nivel permiten desarrollar interfaces o complementos.
de escepticismo. Siempre tome
todas las diligencias debidas. Un ejemplo es la interfaz de red de contenedores para contenedores o el
complemento Neutron de OpenStack. Esta interfaz y complemento mapean un
flujo completo junto con una serie de API para respaldar un nivel de "integración"
y acuerdos de nivel de servicio (service-level agreements, SLA). Estas API crean
los bloques fundamentales del centro de datos definido por software, en caso de
que estén bien definidas. Una área gris del centro de datos es el Lejano Oeste de
las API abiertas sin interfaces o complementos bien definidos. Las API abiertas no
constituyen una "integración".
Infraestructura actual y futura

¿Dónde está la intersección entre la infraestructura actual y futura? Hoy en día, su
organización mantiene una gran combinación no solo de diferentes tipos de cargas
de trabajo, sino de infraestructura física diferente o nada de infraestructura (nube,
entorno alojado, SaaS, etc.). Cualquier solución debe evaluar la intersección entre
las soluciones que estén bajo el control de hardware y las que sean controladas por
software.
Las operaciones de centros de datos están evolucionando de la misma forma en

que se desagregan y ponen en funcionamiento las aplicaciones a través de una
serie de API. La estructura de conexión de red física se ha separado en un conjunto
simple de funcionalidades de estructuras de conexión. Diversos componentes de
hardware pueden conectarse a esta estructura de conexión de modo "plug-and-
play", y pueden emplearse diversas técnicas de estructura de conexión, tanto
antiguas como nuevas. La plataforma de separación se desagrega de dicha
underlay, lo que otorga independencia.
Interfaz
de red Administrador
de aplicaciones
Servicio
Aplicaciones y redes
implementadas independientemente
de la infraestructura
Red de
aplicaciones
All individual
components
exchangeable
Administrador
de estructuras
de conexión Underlay optimizada
Hardware de estructuras de conexión para mayor simplicidad
Nube pública
o alojado
SO de la red
Figura 11. La infraestructura impulsada por API

Confidential 2018 VMware, Inc. 1
COMENTARIO SOBRE
Sería fácil suponer que un conjunto de soluciones debería manejarlo todo: un
LA INFRAESTRUCTURA
HIPERCONVERGENTE (HCI) software que ejecute todo, desde la estructura de conexión del hardware hasta
las soluciones de aplicaciones que se implementen en ella. Sin embargo, la realidad
Podría parecer que los
objetivos de la HCI rompen es otra. El software puede cambiar rápidamente en términos de capacidad,
con la metodología basada funcionalidad, capacidad de servicio y escalabilidad. Las limitaciones del hardware
en software. En cambio, la se definen en un momento específico de las etapas iniciales en la ingeniería de un
metodología que da prioridad conjunto de chips; el hardware ahora está "limitado por el hardware", a falta de un
al software en realidad se basa mejor término para referirse a sus límites. Esto es algo que experimentan todas las
en estos valores fundamentales tiendas de TI cuando observan sus redes "heredadas" y deciden qué necesidades
para crear soluciones llave en faltan para respaldar la visión de la próxima generación de centros de datos.
mano. No hay necesidad de atar
el software al hardware para El software vinculado a un sistema de hardware está, por definición, vinculado al
obtener estos mismos beneficios. pasado de esa estructura de conexión. El software debe satisfacer continuamente
Estas soluciones también se las necesidades heredadas y, al mismo tiempo, intentar ofrecer nuevas funciones.
ofrecen actualmente como Esta vinculación o atadura con el pasado desacelera la innovación en el software y,
diseños validados. por lo tanto, genera una rotación más rápida de hardware para atender las nuevas
necesidades de servicios. Esto sucede con demasiada frecuencia en los centros de
datos de la actualidad.
Overlays para la virtualización de redes

En esencia, la virtualización de redes crea un conjunto de redes overlay entre las
cargas de trabajo. Las cargas de trabajo pueden ser VM, contenedores o incluso
nivel básico de hardware. Las consideraciones para las redes overlay se pueden
desglosar en dos conjuntos: objetivos e implementación.
Objetivos de la overlay: conectar clientes o cargas de trabajo, o funcionar como

una técnica de administración de estructuras de conexión
Existen muchos objetivos separados para las redes overlay que pueden usarse
todos al mismo tiempo. A primera vista, podría parecer "muerte por overlay". Pero
la realidad es que las redes overlay se han apilado durante décadas. Un paquete
típico en el centro de datos ya se ha encapsulado muchas veces: capa 2 con MAC,
capa 3 con IP, control con TCP/UDP y, finalmente, la overlay nativa de la carga de
trabajo, VLAN. Todo lo demás serán separaciones que pueden servir para muchos
propósitos.
El primer caso de uso se utiliza desde hace décadas para transportar a múltiples
clientes en redes de proveedores de servicios: la conmutación de etiquetas
multiprotocolo (Multi-Protocol Label Switching, MPLS). El concepto es el mismo
para los casos de uso de la virtualización de redes: proporcionar dominios de
redes aislados para aplicaciones, clientes u otros marcos específicos. VXLAN y
ahora GENEVE ofrecen el encapsulamiento del tráfico de aplicaciones o clientes en
cualquier estructura de conexión IP. Sin embargo, estos encapsulamientos pueden
usarse para simplificar la conectividad de las estructuras de conexión físicas,
además de permitir la administración de estructuras de conexión.
Implementación de la overlay: ubicada con el hipervisor o el entorno

de cargas de trabajo nativas, o dividida con el hardware de red
Podría parecer que los detalles de la implementación incumben solo a los
proveedores de las soluciones, pero en un mundo de interacciones enrevesadas
entre el hardware y el software, ahora también le incumben al usuario final de
la tecnología. Dos publicaciones del grupo de trabajo de Network Virtualization
Overlay (NVO3) (RFC 8014 – An Architecture for Data-Center Network
Virtualization y RFC 8394 – Split Network Virtualization Edge [Split-NVE] Control-
Plane Requirements) ilustran que existen diferentes mecanismos para implementar
una overlay. Estas publicaciones tienen únicamente fines informativos y no son
guías de implementación.
RFC 8014 describe el concepto del "NVE ubicado con el hipervisor". Para este
modo, la única solución para VMware ESXi™ es NSX, ya que es la única técnica
de virtualización de redes nativa en el hipervisor ESXi. Cualquier otra solución se
incluiría en el modo "Split-NVE", que introduce varias consideraciones complejas,
según se describe en RFC 8394. En el modo Split-NVE, el punto de entrada real
a la red overlay es externo al hipervisor, por lo que resulta necesario entender
algunas consideraciones de control significativas. El RFC exige que parte de esta
inteligencia se implemente en el hipervisor, lo que llama tNVE, pero en la práctica, el
tNVE no es algo que implemente el hipervisor. Para ESXi, algunas soluciones que no
son nativas intentan replicar esta funcionalidad a través de una combinación de API,
pero estas soluciones generalmente entran en el caso de uso de la administración
de estructuras de conexión y no en la virtualización de aplicaciones, cargas de
trabajo o redes de clientes. Split-NVE también genera una dependencia de
hardware y va en contra de la estrategia basada en software que se describe
en este documento.
¿Qué sucede con otros hipervisores o contenedores, o con la nube? Los RFC
no tratan estos elementos implícitamente, pero los conceptos son los mismos.
Tomemos el ejemplo de KVM, que tiene OVS para proporcionar una interacción
con ubicación conjunta. Los contenedores poseen la interfaz de red de
contenedores (container network interface, CNI) para proporcionar una interacción
con ubicación conjunta. Un tercer tipo de diseño, no descrito por el RFC, es la
ubicación conjunta con el huésped. Esto se debe a que, en el centro de datos, la
ubicación conjunta con el hipervisor es el método preferido. Para la nube, la opción
sería una ubicación conjunta del huésped a través de un agente.
La nube
Dar prioridad a la nube no es simplemente una estrategia para las aplicaciones. Las
redes de nube no tienen restricciones de hardware. Los servicios de computación en
nube están restringidos únicamente por los servicios de software y tienen
una habilidad inherente para ser modificados de manera continua sin ninguna
consideración por los sistemas de hardware subyacentes o la interrupción imperiosa
que impone un ciclo de hardware. Los servicios de computación en nube ya han
demostrado las ventajas de una desagregación completo de la plataforma de
aplicaciones de los dispositivos de hardware subyacentes. Por lo tanto, la red
virtual no debe requerir una consideración de la estructura de conexión de hardware.
Separación de la estructura de conexión

Los servicios de computación en nube y las plataformas de virtualización de redes
no atan contenedores, microservicios y máquinas virtuales a estructuras de
administración de mano dura que generan complejidad. La administración de
estructuras de conexión sentadas sobre un laberinto de políticas leaf-and-switch
y perfiles vinculados a dominios de estructuras de conexión física por otras
separaciones de políticas crea apoyos inestables para la administración de
virtualización de redes.
Simplicidad con virtualización

La virtualización del procesamiento simple ya ha demostrado que desagregar
dependencias de procesamiento de los sistemas de servidor subyacentes
proporciona un nivel increíble de productividad operacional. La virtualización
de redes debería hacer lo mismo. La plataforma de virtualización de redes le
proporciona a la plataforma de aplicaciones el mismo nivel de desagregación
de la estructura de conexión de switches. También hace posible un ciclo de vida
independiente de la estructura de conexión física, lo que puede reducir los gastos
operacionales. Las estructuras de red para esta red virtualizada (usando el mismo
paradigma simple de funciones de conmutación lógica, enrutamiento y servicios de
aplicaciones) sientan bases firmes para una plataforma de aplicaciones sobre una
estructura de conexión de switches administrada independientemente. Dicha base
permite que la plataforma de aplicaciones suministre una plataforma de nube
virtual independiente, en cualquier lugar.
Recuerde que todos los entornos de TI requieren una estructura de conexión de
switches para la transferencia de paquetes de alto rendimiento. Sin embargo, una
plataforma de aplicaciones no requiere que la estructura de conexión de switches
de hardware proporcione nada por encima de la transferencia de paquetes a alta
velocidad en la dirección correcta.
Una mentalidad en evolución

En definitiva, las redes y la seguridad deben lograr las características de la nube:
agilidad, velocidad, capacidad de administración y portabilidad. Las redes ya no
se tratan de la lealtad a una marca en honor a la historia. Los equipos de redes
se encuentran actualmente en una posición clave para abandonar las soluciones
basadas en hardware y promover el cambio. No confunda esto por una tendencia
hacia una solución basada solo en la virtualización. Solo debe tenderse a adoptar
la solución que mejor resuelva los problemas del negocio.
Para resolver los problemas de hoy y, al mismo tiempo, crear una plataforma
para el crecimiento futuro, las organizaciones de TI necesitan pensar de manera
innovadora. La mentalidad en materia de redes y seguridad debe evolucionar hacia
una que espere y adopte el crecimiento. Este cambio conlleva enfrentar nuevos
desafíos, estar dispuesto a superar los obstáculos, no temer al fracaso y encontrar
valor en el éxito de las nuevas ideas (por ejemplo, la red de nube virtual). Una
mentalidad enfocada en el crecimiento repercute a nivel empresarial y personal.
En tiempos de transformación (digital) significativa, donde el software es una
fuerza dominante, tanto las empresas como los individuos deben, en igual medida,
estar abiertos a la evolución de los procesos, las herramientas y, sobre todo, las
personas.
PRINCIPIOS FUNDAMENTALES DE LA HIGIENE CIBERNÉTICA EN UN MUNDO
DONDE LA NUBE Y LA MOVILIDAD SON TENDENCIAS
Para cualquier diseño arquitectónico, habrá un toma y daca entre disponibilidad,

capacidad de administración, rendimiento, capacidad de recuperación y seguridad.
Una arquitectura de soluciones debe ofrecer estas características de acuerdo con
"Para hacer realidad los requisitos técnicos y de negocios de una organización dentro de los límites de
los cambios de redes sus restricciones y su aceptación del riesgo. Atrás quedaron los días de los enlaces
troncales y rangos de las VLAN, y las ataduras complejas a la estructura de
significativos que
conexión del hardware. El futuro depende de la capacidad para crear redes físicas
requiere el negocio estáticas, estables y confiables donde puedan ejecutarse redes definidas por
digital, no alcanzará con software más dinámicas. La dependencia de firewalls físicos para proteger la
información es cosa del pasado. El futuro reside en una estrategia multiparte de
cambios incrementales
protección exhaustiva que aborde todos los aspectos de la seguridad de datos.
de tecnología y Para lograr el éxito en este nuevo futuro, se necesita un cambio de mentalidad en
organizacionales; también materia de redes y seguridad.
debe producirse un cambio
cultural".6
—GARTNER
Figura 12. La evolución de la red moderna
¿Por qué VMware y NSX? Como ya se mencionó, el software está conquistando el

mundo, y VMware ha formado parte de ese proceso desde el comienzo. Desde la
concepción de la empresa, se han alcanzado hitos importantísimas en materia de
virtualización de servidores con las líneas de productos de VMware ESX® y vSphere.
En los últimos cinco años, hemos experimentado un crecimiento y éxito similares en
el ámbito de la virtualización de redes con NSX. Ahora es momento de pensar de
forma levemente diferente acerca de la próxima renovación y actualización de
su red, mirar más allá de la "creación de paquetes" y pensar en cómo desea que
evolucione el negocio. Una estructura de conexión de red suministrada en software
puede ayudarlo a conseguirlo y a ofrecer dichas experiencias a sus clientes.
COMENZAR
Más información sobre las soluciones

de VMware NSX y un nuevo enfoque
para modernizar su red >
Síganos en
línea:
6
Apéndice A: La visión histórica

En esta sección de referencia, ofrecemos una mirada sobre la evolución de las
redes en el centro de datos, desde la carrera de velocidades y avances hasta el
surgimiento (y en algunos casos, la reversión) de los "componentes comerciales"
(en inglés, merchant silicon), las estructuras de conexión y la administración de
estructuras de conexión, y, finalmente, las redes definidas por software. Esta
historia breve aporta un contexto para los diferentes objetivos que las redes
procuran lograr, ya sea con nuevas tecnologías de software o con tecnologías
ancladas en el hardware.
Velocidades, avances y el surgimiento de los "componentes comerciales"

Cuando Google presentó su infame solicitud de propuestas (RFP) de redes en
2004 (una RFP que nadie pudo contestar debido a su escala actual), ya se estaba
produciendo un cambio gigante en el mundo de las redes. El control distribuido y
los planos de reenvío estaban reemplazando el procesamiento central de paquetes.
Estaba surgiendo 10 Gigabit Ethernet (10GbE), lo que desató una guerra en torno
al próximo ciclo de actualización de red, con la esperanza de imponer nuevos
requisitos de ancho de banda para las capas tradicionales de core y agregación
a fin de soportar velocidades más elevadas en el perímetro de acceso.
En ese momento, algunas empresas como Force10 (previo a la adquisición de Dell)
ya estaban desarrollando ASIC de diseño personalizado en este nuevo modelo y
los suministraban a algunos de los mayores clientes de servicios web y escala
web. Mientras tanto, recién se estaban fundando empresas como Arista Networks
(originalmente "Arastra") en 2004, que buscaban aprovechar una estrategia
utilizando chips listos para usar, lo que posteriormente se conocería como
componente comercial (merchant silicon). Esta fue la chispa que encendió la
iniciativa de utilizar chips proporcionados en masa por empresas como Broadcom,
Intel, Dune y Fulcrum. Este movimiento que consiste en usar componentes
desarrollados por empresas cuyo enfoque principal consiste en crear componentes
de redes llevaría eventualmente a lo que se conoce hoy como switches "white-box"
y, finalmente, a diversos modelos de sistemas operativos de redes desagregados.
Entonces, ¿qué sucede con Cisco? Aproximadamente en el año 2006, Cisco
adquirió Nuova Systems para desarrollar y suministrar switches de acceso
desarrollados específicamente para el centro de datos, lo que posibilitó también
su expansión al negocio de servidores. Durante este tiempo, Cisco también
estaba ocupado desarrollando la primera generación de switches diseñados
específicamente para centros de datos con la serie Nexus 7000, cuyo lanzamiento
tuvo lugar en 2008. Mientras tanto, Cisco se apegaba a su estrategia de hardware
original, en uso desde la fundación de la empresa en la década de 1980: desarrollar
equipos de telecomunicaciones para redes basados en componentes
"personalizados" o internos.
Esta estrategia se basa en la creencia de que ingenieros especializados pueden

desarrollar un chip con funcionalidad y funciones avanzadas a un ritmo superior
que el de las empresas que ofrecen componentes comerciales. En términos
generales, esta estrategia también generó una mayor justificación del precio, debido
a que la innovación de funciones, la velocidad de entrega y las tablas más grandes
y rápidas significaban que el hardware podía venderse como algo muy valioso.
Adelantándonos a tiempos más recientes: el switch diseñado específicamente para
centros de datos más actualizado de Cisco es la serie Nexus 9000. La familia de
switches comenzó con un enfoque interesante. A medida que HP, Arista, Brocade y
otras empresas erosionaban la cuota de mercado de switches para centros de
datos del gigante en redes, Cisco lanzó Nexus 9000 en 2014 con una campaña de
ventas, marketing y desarrollo con un "plus comercial". Esencialmente, Cisco decía
que el camino por tomar y el futuro de los switches para centros de datos era un
enfoque híbrido. Este principio de diseño combinaría técnicamente el ASIC Trident
2 de Broadcom con un segundo chip, el componente personalizado propio de
Cisco.
Finalmente, avancemos al año 2018. En relación con la familia de Nexus 9000, en

menos de cuatro años, Cisco volvió a enfocarse en el desarrollo de componentes
internos de cosecha propia. A finales de 2018, casi todos los modelos de Nexus
9000 de primera y segunda generación con un plus comercial tendrán oficialmente
fin de soporte o ciclo de vida (EOS/EOL). La rotación de hardware para
dispositivos de red ya no se cuenta en múltiplos de años.
Analizaremos más adelante por qué dicha rotación está en aumento, pero por ahora
será suficiente resaltar los constantes cambios en el panorama del hardware para
centro de datos que deben tomarse en consideración. La empresa de investigación
de mercado Dell'Oro Group comenzó a dar seguimiento a estas nuevas arquitecturas
"Muchos de los centros de de switches en la categoría de switches para centros de datos en 2010.
datos más grandes del
Software de redes en el centro de datos
mundo se parecen mucho a En simultáneo con el surgimiento de los componentes comerciales, se inició un
una solución de overlay. La cambio hacia el software de redes desarrollado específicamente para impulsar
sistemas distribuidos más grandes, creados especialmente para las redes de centros
underlay es una estructura de datos. Este cambio dará lugar, finalmente, a los modelos de hardware y software
de conexión simple de capa desagregados que se tratarán más adelante en este documento. Es importante
tener en cuenta este cambio, ya que el software de redes para centros de datos
3, y la overlay suele ser todavía se ejecuta de la misma manera hoy en día, pero difiere mucho de la
específica para aplicaciones. decisión basada en software.
Para empresas como Yahoo, El sistema operativo de switch para centro de datos empezaba a crecer con
variantes como FTOS (Force10), EOS (Arista) y NX-OS (Cisco). Estos nuevos
Google o Facebook, será una sistemas no solo fortalecían los sistemas operativos para soportar la demanda del
overlay de HTTP. Pero a este entorno de centro de datos, sino que también comenzaban a vincular los sistemas
en grupos utilizando protocolos como agregación de enlaces de chasis múltiple
nivel, toda la tecnología es (Multi-Chassis Link Aggregation Group, MLAG) o canal de puerto virtual (Virtual
efectivamente similar, casi Port-Channel, vPC), lo que creó puntos de control cada vez más grandes. Aunque
sigue siendo un criterio de decisión importante para la infraestructura de red física,
como una solución de overlay es solo una pieza del rompecabezas y no el final ni el comienzo del diseño de redes
virtual, donde el software en de centro de datos con una estrategia basada en software.
los perímetros está haciendo El surgimiento de la estructura de conexión
algo y una red física muy Regresando a 2004, las empresas de escala web más grandes comenzaron a
adoptar un diseño totalmente nuevo para las redes de centros de datos, lo que
sencilla no hace demasiado".
impulsó la idea de las estructuras de conexión de centros de datos.
MARTIN CASADO, MANAGING THE PHYSICAL
AND VIRTUAL WORLDS IN PARALLEL
(ADMINISTRACIÓN DEL MUNDO FÍSICO Y EL
MUNDO VIRTUAL EN PARALELO)
Figura 13. La evolución de las estructuras de conexión de redes en Google, Jupiter Rising: A Decade of Clos
Topologies and Centralized Control in Google’s Data Center Network (Surgimiento de Jupiter: una década de
topología de Clos y control centralizado en la red de centro de datos de Google)
Había comenzado la carrera para hacer que las estructuras de conexión de switches
fueran más consumibles para la empresa. Cisco lanzó sus propias tecnologías de
estructuras de conexión personalizadas, como Fabric Path y Dynamic Fabric
Automation. Cuando Juniper lanzó QFabric y Arista, Force10 y otros estaban
adoptando un enfoque más de "estándares" para las estructuras de conexión
utilizando el concepto de leaf-and-spine con protocolos estándares como BGP
que ahora se incorporaban al centro de datos y la capa 3 pasando a la parte
superior del rack. Hoy en día, las estructuras de conexión todavía se desarrollan
de esta forma y entran en la terminología común de diseños leaf-spine. La clave de
estos diseños consiste en crear bloques fundamentales muy simplificados para la
red. La simplificación de la red ahora ha comenzado a convertirse en un tema
importante para todos los proveedores de redes principales.
El software está conquistando el mundo

A medida que las redes evolucionan, el software va modificando la forma en que
opera el centro de datos, y las nubes públicas están en auge. La virtualización,
liderada por VMware, encabeza un cambio fundamental en las operaciones de TI
y la forma en que los desarrolladores interactúan con la infraestructura. En el
camino, el perímetro de redes está cambiando a la capa de virtualización.
De estructuras de conexión al administrador de estructuras de conexión y las

SDN
Las estructuras de conexión que se estaban desarrollando todavía carecían de
las herramientas fundamentales para automatizar y resolver los problemas de la
estructura de conexión de red física, lo que dio lugar al desarrollo de Cisco ACI,
Arista CloudVision, Big Switch Networks y otros. Los objetivos iniciales se
centraban principalmente en los problemas de operación y automatización de
la estructura de conexión de red física, pero también comenzaron a adentrarse
en el perímetro virtual.
Durante este tiempo, a medida que la virtualización y la nube cambiaban el nuevo
perímetro de la red en la capa de virtualización, el término "redes definidas por
software" comenzaba a ser algo común. Se iniciaron proyectos como OpenFlow,
y otros buscaban crear una red impulsada por software más programable.
Desafortunadamente, el término SDN comenzó a abarcar la combinación de
administración de estructuras de conexión físicas, estructuras de conexión
programables y lo que VMware inició a través de Nicira: la virtualización de redes.
La confusión todavía continúa hoy en día y es otro motivo por el cual es importante
establecer los objetivos fundamentales de una actualización de red.
La virtualización y la nube transformaron fundamentalmente el perímetro de la red,
lo que complejiza las opciones que tienen las organizaciones de TI cuando realizan
una actualización de red. Cuando se habla de actualizaciones de red, las estructuras
de conexión, los administradores de estructuras de conexión, las cajas blancas y los
sistemas operativos de centros de datos compiten por el tiempo de los equipos de
redes. A los profesionales de redes se les presenta el desafío de definir con claridad
los problemas que necesitan resolver e identificar dónde deben comenzar a
desarrollar las soluciones para estos problemas.
COMENZAR
Más información sobre las soluciones

de VMware NSX y un nuevo enfoque
para modernizar su red >
Síganos en
línea:
VMware, Inc. 3401 Hillview Avenue Palo Alto CA 94304 USA Tel. 877-486-9273 Fax 650-427-5001 www.vmware.com/latam
Copyright © 2019 VMware, Inc. Todos los derechos reservados. Este producto está protegido por las leyes de copyright y de propiedad intelectual internacionales y de los EE. UU. Los productos de VMware están
cubiertos por una o más patentes enumeradas en http://www.vmware.com/go/patents. VMware es una marca registrada o marca comercial de VMware, Inc. en los Estados Unidos y otras jurisdicciones. Todas las
demás marcas y nombres mencionados en este documento pueden ser marcas comerciales de sus respectivas empresas. N.º de elemento: CS-0800_VM_SoftwareDefinedNetworking_WP_R3_190116_EK_ESLA
1/19

Vmware Documento PDF

Cargado por

Copyright:

Formatos disponibles

Vmware Documento PDF

Cargado por

Información del documento

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Vmware Documento PDF

Cargado por

Copyright:

Formatos disponibles

C A SO D E U SO D EL P RO D U C TO

Consideraciones clave y nuevos criterios de diseño 13

Resumen ejecutivo: Redes definidas por software en el centro

El software ya conquistó el mundo

Cuando usted virtualiza la red y adopta una estrategia basada en software,

La evolución de la red y las redes definidas por software

Principios de SDN Evolución de SDN

Redes de nubes múltiples: La virtualización allanó el camino para la nube privada,

Seguridad de red: La transición a la nube privada y el SDDC creó inherentemente un

Requisitos del modelo basado en software para las

Con la virtualización de redes, sus administradores de red pueden aprovisionar

UN BREVE COMENTARIO SOBRE LA RESOLUCIÓN DE PROBLEMAS

Figura 2. Estructuras de capa de aplicación

completamente separados que eran ejecutados por desarrolladores, para

La automatización integral, desde la sucursal hasta el centro de datos y la

Administración de estructuras de conexión

Otras herramientas como VMware vRealize Network Insight pueden ofrecer

Pautas de diseño basadas en software

Virtualización de red Seguridad de aplicaciones y datos

Figura 3. Múltiples caminos para transformar las redes y seguridad

Diseño para soluciones

Antes de 2013 2014-2018 2018

Figura 4. Desde microsegmentación hasta seguridad intrínseca

La característica fundamental de la seguridad intrínseca es que hereda las

Cobertura de activos virtuales y físicos

Visibilidad y operaciones integrales

Zona desmilitarizada en cualquier lugar

……. Seguridad tradicional

Máquinas virtuales Contenedores

Infraestructura Infraestructura del

Luego, la red de nube virtual se extiende a las oficinas o sucursales remotas

El estado mixto es la nueva norma

Sucursales/remoto Clásica de 3 niveles Estructura de conexión de red Nubes públicas

Confidential ! 2018 VMware, Inc. 1

Proporcionar una overlay de redes simplificada en software permite completar la

Figura 7. Diseño del estado mixto de las aplicaciones

El centro de datos nuevo

Este error de planificación genera que la organización continúe arraigando las

Centros de datos principales

Confidential ! 2018 VMware, Inc. 1

Figura 8. Migración y actualización sin dificultades

El camino hacia la adopción de la nube

Datacenter for VMware

Figura 9. Consistencia integral

Consideraciones clave y nuevos criterios de diseño

Interacciones entre el software y el hardware

Cloud specific networking

Figura 10. Puntos de separación de redes

Teniendo en cuenta estas dos cuestiones, ¿cómo es el ciclo de vida de la

El hardware sigue siendo importante

División del trabajo

Infraestructura actual y futura

Las operaciones de centros de datos están evolucionando de la misma forma en

Figura 11. La infraestructura impulsada por API

Overlays para la virtualización de redes

Objetivos de la overlay: conectar clientes o cargas de trabajo, o funcionar como

Implementación de la overlay: ubicada con el hipervisor o el entorno

Separación de la estructura de conexión

Simplicidad con virtualización