Ciudad de México27 de Septiembre de 2018
Arquitectura de centro
de datos de VMware NSX
y solución de contenedor
en el ecosistema de Dell EMCPedro RiverollVMware Sr. Solutions Engineer
Expectativa de esta sesión
• Obtener información sobre la arquitectura de NSX
• Obtener información sobre oferta de contenedores
y la forma en que NSX proporciona valor
• Obtener información sobre la stack de Dell y VMware:
PRA, VCF y VxRack Flex con NSX y diseño de contenedores
5 5©2018 VMware, Inc.
• Seguridad • Cloud
Native
• Automatización • Multi-Cloud
Casos de uso NSX
¿Qué es NSX?
7 7©2018 VMware, Inc.
host3
host2
host1
VDS
VDS
VDS
host6
host5
host4
VDS
VDS
VDS
rack1 rack2
Host Virtualization
• Host virtualization
– Crear una máquina
virtual(VM)
– Varias VMs por hosts
– Snapshot, backup
– vMotion
• ¿vMotion entre racks?
• Beneficios de vSphere
VM1 VM2
Subnet A Subnet B
VM1 VM2
Logical View
IP A.1 IP A.2
Subnet A
8 8©2018 VMware, Inc.
host3
host2
host1
VDS
VDS
VDS
host6
host5
host4
VDS
VDS
VDS
rack1 rack2
Host Virtualization
• Problema:
• Las máquinas virtuales,
son virtuales
• Sus direcciones Ips no lo
son
• Beneficios de vSphere
VM1
Subnet A Subnet B
VM1 VM2
Logical View
IP A.1 IP A.2
Subnet A Subnet B
VM2
9 9©2018 VMware, Inc.
host3
host2
host1
VDS
VDS
VDS
host6
host5
host4
VDS
VDS
VDS
rack1 rack2
¿Extender capa 2?
• Propagar la subred A a
todo el data center
VM1
Subnet A
VM1 VM2
Logical View
IP A.1 IP A.2
Subnet A
VM2
10 10©2018 VMware, Inc.
host3
host2
host1
VDS
VDS
VDS
host6
host5
host4
VDS
VDS
VDS
rack1 rack2
¿Extender capa 2?
• ¿Cómo?:
• ¿Crear una instancia de
servicios físicos?
• ¿Proporcionar servicios
físicos de acuerdo a
necesidades?
• ¿Desviar el tráfico a los
appliance físicos?
• ¿Manejar multiples
instancias del mismo
servicio?
• Acciones pendientes
VM1
Subnet A
VM1 VM2
Logical View
IP A.1 IP A.2
Subnet A
VM2
?
VM1 VM2IP A.1 IP A.2
Subnet A
VM1
VM2
11 11©2018 VMware, Inc.
host3
host2
host1
N-VDS
N-VDS
N-VDS
host6
host5
host4
N-VDS
N-VDS
N-VDS
rack1 rack2
TEP A.1
TEP A.2
TEP A.3
TEP B.1
TEP B.2
TEP B.3
El modelo de Overlay
• N-VDS: NSX Virtual
Distributed Switch
(NSX Componente del
plano de control)
• Switches lógicos son
embebidos en el
hipervisor
• Se extienden a otros
hypervisores por medios
de tuneles IP
• NSX mantiene una table
manteniendo el control
de las ubicaciones
• Introducción a switcheo lógico
Subnet A Subnet B
VM1
VM2
VM1 VM2
Logical View
IP N.1 IP N.2
VM (vnic) Location
Mac VM1 TEP A.1
Mac VM2 TEP A.3
Logical Switch
TEP: Tunnel End Point
12 12©2018 VMware, Inc.
host3
host2
host1
N-VDS
N-VDS
N-VDS
host6
host5
host4
N-VDS
N-VDS
N-VDS
rack1 rack2
TEP A.1
TEP A.2
TEP A.3
TEP B.1
TEP B.2
TEP B.3
El Modelo de Overlay
• Requerimientos de la
infraestructura física:
– Conectividad IP
– 1600 byte MTU
(minimum, jumbo
frame recomendado)
• Introducción a switches lógicos
Subnet A Subnet B
VM1VM1 VM2
Logical View
IP N.1 IP N.2
VM2
VM (vnic) Location
Mac VM1 TEP A.1
Mac VM2 TEP B.3
Logical Switch
TEP: Tunnel End Point
13 13©2018 VMware, Inc.
El Modelo de Overlay
• Requerimientos de la
infraestructura física:
– Conectividad IP
– 1600 byte MTU
(minimum, jumbo
frame recomendado)
• Cualquier topología:
– L2 end-to-end
– Pod with L3
aggregation
– Spine/Leaf…
• Funciona con cualquier topología de red
host1
N-VDS
host2
N-VDSTEP A.1 TEP B.1
14 14©2018 VMware, Inc.
El Modelo de Overlay
• Requerimientos de la
infraestructura física:
– Conectividad IP
– 1600 byte MTU
(minimum, jumbo
frame recomendado)
• Cualquier vendor:
– Un único vendor
– Mezcla de vendors
– Mezcla de dispositivos
• Funciona con cualquier vendor
host1
N-VDS
host2
N-VDSTEP A.1 TEP B.1
15 15©2018 VMware, Inc.
N-VDS
N-VDS
N-VDS
N-VDS
N-VDS
N-VDS
rack1 rack2
TEP A.1
TEP A.2
TEP A.3
TEP B.1
TEP B.2
TEP B.3
Las redes pueden ser entregadas junto con las VMs
Las redes pueden ser
creadas como se crean
VMs:
• No hay conflict entre
redes
• Puede ser automatizado
• Toda operación de NSX
pueder ser ejecutada por
medio de APIs
VM1 VM2
Logical View
IP N.1 IP N.2
Subnet N
VM1 VM2IP N.1 IP N.2
Subnet N
VM3 VM4IP M.1 IP M.2
Subnet M
VM1 VM2
VM1 VM2
VM3 VM4
Subnet A Subnet B
16 16©2018 VMware, Inc.
N-VDS
N-VDS
N-VDS
N-VDS
N-VDS
N-VDS
rack1 rack2
TEP A.1
TEP A.2
TEP A.3
TEP B.1
TEP B.2
TEP B.3
Servicios Virtuales de Red
Microsegmentación
• Un firewall es creado por
cada tarjeta de red virtual
• Permite filtrar el tráfico
entre VMs del mismo
segmento
• Las reglas de firewall son
configuradas de mantera
consistentente de
manera centralizada
• Microsegmentación
VM1 VM2
Logical View
IP N.1 IP N.2
Subnet N
VM1 VM2IP N.1 IP N.2
Subnet N
VM3 VM4IP M.1 IP M.2
Subnet M
VM1
VM2
VM1
VM2
VM3
VM4
Subnet A Subnet B
17 17©2018 VMware, Inc.
N-VDS
N-VDS
N-VDS
N-VDS
N-VDS
N-VDS
rack1 rack2
TEP A.1
TEP A.2
TEP A.3
TEP B.1
TEP B.2
TEP B.3
Servicios Virtuales de Red
• NSX va más alla de capa 2
Subnet A Subnet B
VM1 VM2
Logical View
VM5 VM6
VM3 VM4
VM1 VM2
VM3 VM4Internet
VM5
Load
Balancing
Firewallin
g
VPN
DHCP
Switching
NAT
Routing
Connect
to physical
Meta
Data
Proxy
VM6
18 18©2018 VMware, Inc.
NSX-T corre en diferentes plataformas
NSX es una plataforma de red
virtual:
• VMs o contenedores
• Servidores físicos (agente)
• Múltiples vCenters
• Inter hypervisores(ESXi, KVM)
• En sitio o en la nube
• Red definida por software… en cualquier lugar
ESXi HV
ESXi HV
ESXi HV
N-VDS
N-VDS
N-VDS
KVM HV
KVM HV
N-VDS
N-VDS
ESXi HV
N-VDS
vCenter1
vCenter2 KVM
Bare Metal
Server
NSX
VM
NSX
AWS, Azure, VMC on AWS
19 19©2018 VMware, Inc.
NSX-T
20
Arquitectura de NSX en todas partesCualquier nube Cualquier dispositivoCualquier sitio
API y automatización
En las instalaciones, en la nube, híbrida
Múltiples dominios y la diversidad de los terminales
Visibilidad y funcionamiento
Política y coherencia
Red y conectividad
Seguridad
Servicios: FW/LB/NAT/DHCP/Más
21
Ventajas de VMware NSX-T en un ambiente de PaaS o CaaS
Visibilidad Seguridad Redes Coherencia
Aplic.WebBase
de datosAplic.Web Base
de datosAplic.Web Base
de datosAplic.Web Base
de datos
K8S Openshift PAS PKS
22
Arquitectura NSX para la nube privada, la nube pública y los contenedores
Plano de
administración
Plano
de control
Plano
de datos
NSX Manager Administrador de procesamiento (vCenter, CSM, NCP)
Clúster de control centralizado de NSX
HV ESXi HV KVM
N-VDS N-VDS
VPN
Multi-Hypervisor VM de NSX Edge
o de bajo nivel
Puente
de capa 2
Puerta de enlace
de la nube de NSX
VM Linux VM Windows
(Puerta de enlace de VPN, DirectConnect, ExpressRoute)
Infraestructura de nube pública o privada VMware Cloud en AWS
23
Caracterización de los componentes de arquitectura crítica
Inventario
Lógica de la regla de
DFW
Disponi-bilidad
API
Ancho de banda
Convergencia
Disponi-bilidad
Servicios
EscalaAprendizaje del plano de control
Convergencia
Disponi-bilidad
NSX Manager Controladora EDGE
• Interactúe con varios administradores
de procesamiento
• Múltiples sistemas vCenter para ESXi
• Administrador de servicios de nube
• Plug-in del contenedor de red
• Sin dependencias en el hipervisor,
la superposición o la subred
• Disponibilidad: la misma que cualquier modelo
de dispositivo
• Reserva de recursos requerida
• Plano de control de escalamiento horizontal
distribuido
• Procesamiento central y local
• Sin dependencias en el hipervisor, la
superposición o la subred
• Disponibilidad: en función de la mayoría
• Reserva de recursos requerida
• Enrutamiento distribuido simplificado
• Ancho de banda norte-sur de 10/25/40 Gbps
para el DPDK
• Virtual y de bajo nivel
• Convergencia inferior a un segundo
• Servicios: NAT, DHCP, proxy de metadatos
• Disponibilidad: activo-en espera y ECMP
• Reserva de recursos requerida
24
Plano de datosResistencia y rendimiento mejorados
Diseñado para la funcionalidad
multiusuario y el escalamientoArquitectura del edge distribuida
simplificada con un mayor rendimiento
por medio del DPDK
Nodo
perimetral
Clúster perimetral
Nodo
perimetral
Nodo
perimetral
Nodo
perimetral
HV TN1vSwitch1
p1 p2
TEP
Zona de transporte de superposición
TEP: SuperposiciónTunnel End Point
(terminal de túnel)(con su propia dirección IP)
Túnel GENEVE
HV TN1 vSwitch2
p1 p2
TEP
Superposición de última generación que mantiene
el rendimiento con una mayor flexibilidad
Grupos de usuarios/CMP
Administrador
Aplicaciones nativas de la nubeAspectos básicos del contenedor como servicio y la plataforma como servicio
“Una de las cosas que hemos aprendido es que si no acelera el tiempo de ingreso al mercado, no habrá duda que el mercado cambiará sin importar qué tan bien haya diseñado, creado o implementado el producto o capacitado a su gente. No obtendrá resultados óptimos porque será demasiado tarde”.
James McGlennonVicepresidente ejecutivo y director de TI, Liberty Mutual Insurance Group
39
¿Qué tienen de especial las aplicaciones nativas de la nube?
• Impredecibles
• Dependientes del SO
• Demasiada capacidad
• Infraestructura de
• Desarrollo de cascada
• Dependientes
• Escalamiento manual
• Recuperación lenta
• Predecibles
• Independientes del SO
• Capacidad adecuada
• Colaborativas
• Entrega continua
• Independientes
• Escalamiento automático
• Recuperación rápida
Aplicaciones tradicionales frente a aplicaciones nativas de la nube
Aplicaciones empresariales tradicionales
Aplicaciones nativas de la nube
40
Declaración de problemas de red para las plataformas CaaS/PaaS
Retos• La red necesita cambiar a medida que las aplicaciones
cambian o se lanzan (dinámica)
• Requiere NAT para conectarse a la red de contenedor
• No hay microsegmentación entre microservicios y de
microservicios a VM/base de datos
• No hay herramientas operacionales para la red de contenedor
• No hay redes multiusuario que coincidan con el grupo
de usuarios de PaaS
Redes predeterminadas en CaaS/PaaSEnfoque de NSX para las redes
de CaaS/PaaS
Beneficios• Conexiones de red de máquinas virtuales, contenedores
y servidores de bajo nivel en la capa 3
• Automatización de red integrada para que las aplicaciones
impulsen el diseño de red
• Microsegmentación (con monitoreo, registro, registros
de auditoría) entre los microservicios y de los microservicios
a la base de datos
• Conjunto de herramientas común (SPAN, IPFIX, syslogs,
seguimiento de paquetes) para todos los tipos de terminales
VM
(NAT)
Correo Compra
Red de contenedor
Plataforma CaaS/PaaS Plataforma CaaS/PaaS
41
Ventajas de VMware NSX-T en un ambiente de PaaSo CaaS
42
PaaS frente a CaaS y la función de NSX-T• Donde NSX-T se ajusta a:
• La microsegmentación de las VM y los
contenedores
• La coordinación de red dinámica
• El balanceo de carga para VMX y contenedores
• Monitoreo y solución de problemas comunes para
todas las aplicaciones tradicionales y basadas en
microservicios
• ¿Debo usar una PaaS o un CaaS?
• ¿Se trata de una aplicación nueva o una
completamente refactorizada?
• ¿Proporciona su desarrollador la aplicación
o el código?
43
Componentes Función
Ops ManagerOPS Manager administra el estado de las implementaciones PKS de BOSH; esto incluye
la implementación de BOSH.
BOSHBOSH es un proyecto de código abierto que unifica el diseño, la implementación y la administración
del ciclo de vida de la versión de software de nube pequeño y a gran escala. Para PKS, BOSH
implementa PKS Admin y otros mosaicos
PKS Admin (intermediador)PKS Admin es una máquina virtual implementada por BOSH para crear y administrar
la infraestructura de Kubernetes incluida en los espacios de nombres, los pods y los
clústeres de Kubernetes, entre otros.
Clústeres de K8sUn clúster de Kubernetes (K8s) es una agrupación lógica de las máquinas virtuales o los servidores
físicos que alojan los contenedores de tiempo de ejecución c (tiempo de ejecución de Docker)
VMware NSX-TVMware NSX-T proporciona servicios de red y seguridad para las aplicaciones que se ejecutan
en máquinas virtuales y contenedores
Plug-in de contenedor
nativo (NCP)
El plug-in de contenedor nativo NSX-T es una integración entre CNI y NSX-T que permite a K8s
coordinar y administrar automáticamente la topología de red NSX-T en función de las necesidades
de las aplicaciones.
44
Solo Pivotal Container Service (PKS)Componentes lógicos
45
Componentes FunciónOps Manager OPS Manager administra el estado de las implementaciones de PCF BOSH, por lo que reemplazará a cualquier
configuración de implementación de BOSH modificada manualmente.
BOSH BOSH es un proyecto de código abierto que unifica el diseño, la implementación y la administración del ciclo de vida
de la versión de software de nube pequeño y a gran escala.
Go Router Los Go Routers ayudan a enrutar el tráfico entrante al componente apropiado. Puede tratarse de un operador que
recurre a la controladora de nube o un usuario de aplicación que accede a una aplicación que se ejecuta en una Diego
Cell. No es un enrutador de red típico y no realiza ningún trabajo de enrutamiento en el nivel de red.
Diego Brain Diego Brain distribuye las tareas y LRP a las Diego Cells y corrige las discrepancias entre los conteos reales
y deseados para garantizar la tolerancia a fallas y la coherencia a largo plazo.
Diego Cells Diego Cells son las VM que insertan y ejecutan los artefactos de las aplicaciones como instancias de la aplicación
o contenedores
Mosaico de servicio Los mosaicos de servicio se instalan en cada base de PCF y se comparten entre varias implementaciones de
aplicaciones. Según el tamaño de la implementación, el servicio aprovisionado previamente se puede implementar
en una sola red de gran tamaño o en varias redes más pequeñas donde cada maneja un tipo diferente de servicio.
Mosaico de servicios dinámicos Los mosaicos de servicios dinámicos no se comparten entre todas las implementaciones dentro de una base de PCF.
Cada implementación podría tener un servicio dedicado y, al final, terminaría necesitando una subred grande debido
a que los servicios crearían VM adicionales que consumirían las IP según demanda.
46
Pivotal Container Service y Pivotal ApplicationService (PAS)Componentes lógicos
47
Pivotal Container Service y Pivotal Application Service (PAS)Componentes dinámicos
Luce genial… ¿Y ahora qué?¿Cómo comenzar?
49
¿Qué puede obtener con un sistema diseñado?
Menor tiempo
de ingreso al mercado
Simplifica considerablemente
el diseño y la implementación
resultantes con un tiempo
de implementación
considerablemente más rápido
Mayor eficiencia
Proporciona orientación
detallada para reducir en gran
medida el tiempo dedicado
a la actualización, la revisión,
el respaldo, la restauración,
el monitoreo y las alertas
Implementaciones
y operaciones
sin riesgo
Garantiza la interoperabilidad
y la compatibilidad de todos
los componentes de software
Impulso de la
agilidad de TI
Permite una plataforma
compatible con un amplio
conjunto de casos de uso
y aplicaciones de negocios
tradicionales y nativas
de la nube
50
Diseño adecuado para el caso de uso adecuado
• Desarrollo/prueba de concepto pequeños
• Pruebe fácilmente la plataforma
• Desarrolle de manera coherente y portable
• Diseño listo para la producción
• Varias zonas de disponibilidad
• Resistencia y escalamiento incorporados
• Escalamiento horizontal de un sistema
de nivel empresarial
• Varias zonas de disponibilidad
• Resistencia y escalamiento incorporados
• Diseño de tres módulos con separación de tareas
• Escalamiento horizontal y el rendimiento de I/O masivos Sistema Dell EMC VxRack Flex
Pivotal Ready Architecture en VxRail (un solo módulo)
Pivotal Ready Architecture en VxRail (listo para la producción)
51
Pivotal Ready Architecture en VxRailDesarrollo y prueba de concepto pequeños
• Base comprobada
• Basada en la plataforma estándar de VxRail
• Orientación y pruebas adicionales
• Diseño de módulo único contraído
• Administración
• Nodos perimetrales de NSX-T
• Cargas de trabajo de CaaS y PaaS
• Redes simplificadas
• Todas las redes de PAS y PKS detrás de NSX-T
• Nodos perimetrales de NSX-T
58
Dell EMC VxRack System FlexSistema de escalamiento horizontal de nivel empresarial
para PAS y PKS
• Ventajas de Dell EMC VxRack Flex
• Sistema subyacente listo para usar con HCI
y red
• Incluye implementación, expansión
y actualización
• Varias zonas de disponibilidad
• Resistencia y escalamiento incorporados
• Diseño de tres módulos con separación
de tareas
• Escalamiento horizontal y el rendimiento
de I/O masivos
63
Top Related