Este documento presenta OpenStack, un sistema operativo de código abierto para implementar nubes informáticas. Explica los principales componentes de OpenStack como Nova, Neutron, Cinder y Glance, y las decisiones de diseño clave para implementar una nube privada con OpenStack, incluyendo la arquitectura, elección de hardware, integración con sistemas existentes y gestión del ciclo de vida.

1. Construyendo una nube con OpenStack
Alfredo Moralejo
Senior Cloud Domain Architect

2. Objetivos
● Presentar casos de uso de OpenStack
● Entender la arquitectura básica
● Principales decisiones de diseño de tu nube OpenStack
● Consideraciones para la implementación
● Gestión de la nube
● Uso de nubes OpenStack

3. Qué es OpenStack?
• “Sistema Operativo” del cloud totalmente Open Source
• Compuesto de varios sub-proyectos
• Proporciona todos los componentes necesarios para crear una cloud de
tipo Infrastructure-as-a-Service
• Diseñado para replicar el concepto de las nubes públicas existentes
líderes en el mercado, e.g. Amazon AWS
• Gobernada por la Fundación OpenStack, independiente
• Participación de los numerosas empresas, desde lideres del mercado
hardware y software a startups orientadas a soluciones específicas

4. Workloads evolucionan...
Workloads tradicionales
• Cada componente reside en un único
sistema o un conjunto estático de ellos
• No toleran downtime en componentes
• Se apoya en características de la
infrastructura subyacente para
asegurar la disponibilidad
• Aplicaciones scalan verticalmente
Workloads Cloud
• Los componentes se distribuyen entre
diferentes sistemas de manera
dinámica
• Aplicaciones desarrolladas para tolerar
fallos de sistemas
• No se apoya en la infraestructura
subyacente para asegurar la disponibilidad
• Aplicaciones escalan horizontalmente

5. Out of our 2700+ production Cassandra nodes, 218 were rebooted. 22 Cassandra nodes were on hardware that did not reboot successfully. This
led to those Cassandra nodes not coming back online. Our automation detected the failed nodes and replaced them all, with minimal human
intervention. Netflix experienced 0 downtime that weekend.

6. Entonces, donde encaja OpenStack?
OpenStack is adecuado para los siguientes casos de uso :
– Construir plataformas Infrastructure-as-aService tipo cloud públicas :
• Cloud Privadas tipo “Infrastructure on Demand”
• Proporcionar entornos de test y desarrollo bajo demanda - e.g. sandbox
• Plataformas de proveedores de servicio públicos tipo IaaS
– Construir plantaformas de escalabilidad horizontal para workloads tipo cloud:
• Aplicaciones de escala Web, e.g. tipo NetFlix, video-streaming
• Aplicaciones con gran demanda de recursos y muy paralelizables, e.g.
secuenciación genética, cálculos científicos, etc...

7. OpenStack no es un reemplazo
directo para la
virtualización empresarial

8. Arquitectura de OpenStack
• OpenStack está compuesto de diferentes componentes autónomos
• Todos ellos diseñados para permitir la escalabilidad horizontal
• OpenStack se puede considerar como un framework, extensible basado en drivers y
plugins
• Fundamentalmente escrito en Python y fuertemente ligado a Linux

9. Servicio de Identidades – Keystone (I)
• Keystone proporciona un servicio común para la autenticación y autorización en
OpenStack
• Gestiona usuarios, roles y a que proyectos pertenecen
• Proporciona un catálogo de todos los servicios OpenStack
• Todos los servicios OpenStack utilizan Keystone para verificar las peticiones

10. Servicio de Identidades – Keystone (II)
Decisiones de diseño :
• ¿Lo necesito? - Si
• ¿Donde puedo almacenar mis usuarios/credenciales?
– Base de datos interna OpenStack
– Uso de LDAP externo
– Posibilidad de uso de autenticación externa
– Desde Icehouse es posible federar keystone con un Identity Provider con SAML
• ¿Donde almacenar la asignación de usuarios y roles?
– Base de datos interna OpenStack
– Uso de LDAP externo

11. Servicio de Cómputo – Nova (I)
• Nova is responsable del ciclo de vida de instancias.
• Puede gestionar diferentes tipos de instancias via drivers, e.g-
– VMs con KVM, VMware vSphere, Xen, Hyper-V...
– Containers con LXC,
• Sistemas físicos no incluido en nova sino en Ironic (experimental)
• Soporte a docker movido a heat

12. Servicio de Cómputo – Nova (II)
Decisiones de diseño :
• ¿Lo necesito? - Si
• ¿Qué hypervisor utilizar?
– KVM es el hypervisor de referencia en el proyecto
– Posibilidad de integración de VMware vCenter (Xen, Hyper-V)
• ¿Como debo segregar mis hypervisores?
– Availability Zones
– Host Aggregates, separar tipos de hyprervisor por características hardware
• ¿Como debo dimensionar mis hypervisores?
– Estimar un perfil de carga esperada – definir flavors
– Nivel de sobre-suscripción (defecto 16:1 CPU, 1.5:1 RAM)

13. Servicio de Imágenes – Glance (I)
• Glance proporciona un mecanismo para el almacenamiento y acceso a plantillas de
instancias
• Soporta multiples formatos de disco, incluyendo qcow2, vmdk, ami, y ovf
• Diferentes opciones de almacenamiente de las imágenes, incluyendo Swift, NFS,
Ceph…

14. Servicio de Imágenes – Glance (II)
Decisiones de diseño :
• ¿Lo necesito? - Si
• ¿Qué almacenamiento utilizar?
– Swift (servicio de almacenamiento de objetos)
– CEPH (solución de Software Defined Storage)
– Almacenamiento local o externo NFS
• ¿Como debo crear mis imágenes?
– Ligeras (JEOS – Just Enough Operating System)
– Configuración automática via servicio de gestión de configuración (puppet...)
– Posibilidad de creación de imágenes como snapshots de instancias existentes

15. Almacenamiento de objetos – Swift (I)
• Swift proporciona un mecanismo para el almacenamiento y acceso a datos no
estructurados.
• Proporciona una interfaz via API RESTful/HTTP-based
• Altamente tolerante a fallos con replicación, auto-reparación, y balanceo de
carga
• Diseñado para ser implementad utilizando hardware commodity

16. Almacenamiento de objetos - Swift (II)
Decisiones de diseño :
• ¿Lo necesito? -
– ¿Lo necesitan mis usuarios?
– ¿Tengo aplicaciones que utilicen este tipo de interfaz?
– Posible uso para albergar imágenes glance
– Posible para hacer backup de volumenes cinder
– Alternativas con otras soluciones de almacenamiento objetos, CEPH
• Dimensionamiento
– Uso de servidores commodity separados para almacenamiento (3 o más nodos)
– Uso de servidores como proxy (al menos dos)
– Posibilidad de uso de otros sistemas de almacenamiento como backend

17. Gestión de redes – Neutron (I)
• Neutron es responsable de proporcionar servicios de red a las instancias ejecutadas en
OpenStack en modo self-service y bajo demanada.
• Proporciona una API para definir, configurar y usar los diferentes recursos de red (redes,
direccionamiento, routers, load balancers, firewalls, etc...)
• Utiliza plugins para el uso de diferentes mecanismos y extensiones como :
• Open vSwitch (default in Red Hat’s distribution)
• Cisco, PLUMgrid, VMware NSX, Nuage, Arista, Mellanox, Brocade, etc.

18. Gestión de redes – Neutron (II)
Decisiones de diseño :
• ¿Lo necesito? -
– Típicamente si (aunque se sigue manteniendo nova-network)
• Qué mecanismo utilizar para virtualizar la red
– Implementación incluida en OpenStack con OpenVswitch
– Existen diferentes plugins para integración con diferentes elementos hardware y
SDNs que pueden proporcionar funcionalidades adicionales
– Algunos SDNs pueden introducir limitaciones en el resto de decisiones (hypervisor)
– Segmentación de red via VLANs o túneles VxLAN o GRE

19. Gestión de redes – Neutron (III)
Decisiones de diseño :
• Uso de extensiones para otros servicios de red
– LbaaS : Load Balance as a Service
• Implementación de referencia con haproxy
• Uso de otros balanceadores via drivers
– FwaaS : Firewall as a Service
• Implementación de referencia con iptables
• Uso de otros firewalls via drivers
– VPNaaS : VPN as a Service
• Implementación de referencia con openswan
• Uso de otras VPNs via drivers

20. Almacenamiento bloque – Cinder (I)
• Cinder proporciona almacenamiento en modo bloque a las instancias en OpenStack.
• Usado para proporcionar almacenamiento persistente o adicional al efímero.
• Incluye gestión de snapshots (asistido por hardware) y backup de volúmenes
• Utiliza plugins/drivers para utilizar diferentes backends de almacenamiento-
– CEPH, Red Hat Storage (GlusterFS), IBM XIV, HP Leftland, 3PAR, etc.

21. Almacenamiento bloque – Cinder (II)
Decisiones de diseño :
• ¿Lo necesito? -
– Típicamente, si
• Qué almacenamiento de backen utilizar
– Soluciones de Software Defined Network basado en hardware commodity, como CEPH
– Cabinas de almacenamiento externo (chequear plugins adicionales) como NetApp, IBM
XIV, HP Leftland, 3PAR, et...
– Considerar precio, escalabilidad y protocolo de acceso
– Chequear soportabilidad de operaciones de API
– Posibilidad de uso para backend de backup

22. Portal de auto servicio - Horizon
• Horizon es el portal web para auto-servicio en OpenStack
• Interactúa con el resto de servicios via APIs standard.
• Proporciona un subconjunto de las funcionalidades de los usuarios
– Ejemplos: creación de instancias, configuración de redes, creación de volúmenes
cinder...
• Expone algunas tareas de administración básica, e.g. creación de usuarios

23. Portal de auto servicio - Horizon

24. Servicio de orquestación - Heat
• Heat facilitala creación de stacks de aplicaciones que contienen multiples recursos.
• Stacks se definen con un lenguaje descriptivo de templates
• Heat gestiona la orquestación automática de los diferentes recursos necesarios y
sus dependencias
• Permite el escalado automático de stacks basado en métricas configurables

25. Servicio de telemetría - Ceilometer
• Ceilometer es responsable de la colección centralizada de métricas y datos de
monitorización.
• Principalmente usado para chargeback en función de uso de recursos.
• Ceilometer consume datos de otros componentes via agentes o polling.
• Arquitectura extensible para poder añadir métricas que exponer via API.

27. Otros proyectos en roadmap
● Trove : Database as a Service – Integrade desde icehouse
● Sahara : Hadoop as a Service – Integrado desde juno
● Ironic : Bare metal as a Service – Integrado en kilo
● Zaqar : Messaging as a Service – Incubación desde icehouse
● Designare : DNS as a Service – Incubación desde juno
● Manila : Shared Filesystem as a Service – Incubación desde juno

28. Arquitectura de despliegue (I)
● Definir la arquitectura para albergar los diferentes componentes
● Criterios de diseño
● Alta disponibilidad para todos los componentes
● Nivel de escalabilidad adecuado
● Seguridad y acceso a APIs
● Integración con componentes existentes
● Balanceadores de carga
● Componentes de infraestructura

29. Arquitectura de despliegue (II)
● Uso de virtualización en capas de control
● KVM en modo standalone
● Virtualización tradicional (RHEV)
● Solución de HA en bases de datos (galera, pacemaker, mongodb replica sets)
● Solución de HA en sistema de mensajería (mirrored queues, pacemaker,...)
● Solución de HA en componentes de control A/A (via balanceador de carga)
● Solución de HA en componentes de control A/P (pacemaker)
● Definir solución de escalabilidad de los diferentes componentes

30. Arquitectura de despliegue (III)
● Nodos se dividen en diferentes “roles”. Ejemplo de referencia:
● Support Nodes – ejecutan servicios de soporte, bases de datos y mensajería
● Controller Node – ejecutan los servicios de API y control de los servicios
● Compute Node – ejecutan las instancias de usuarios
● Neutron Node – ejecutan los agentes Neutron, e.g. DHCP and L3
● Storage Node – proporciona almacenamiento a OpenStack, e.g. Ceph
● Load Balancers – balancean el acceso a los servicios de API

31. MongoDB
RabbitMQ

32. Implementando OpenStack
● Abordar el proyecto como la creación de una nueva plataforma completa.
● Formar UN equipo multidisciplinar para el diseño e implantación de la plataforma.
● Considerar roadmap y funcionalidades futuras al diseñar la solución
● Curva de aprendizaje importante
● Probar y prototipar la solución, capacidades de APIs, backends, etc...
● Buscar grupo de usuarios que puedan aprovechar y probar la solución
● Apoyarse en el trabajo realizado por las distribuciones enterprise y buscar
proveedores de confianza con experiencia y conocimientos en este área.

33. Gestionando OpenStack
● Actualizaciones frecuentes (6 meses) e importantes
● Automatización del proceso de despliegue de plataforma OpenStack
● Automatización del proceso de pruebas de plataforma OpenStack
● Buscar distribuciones de OpenStack que proporcionen las herramientas adecuadas
para despliegue y gestión de ciclo de vida, foreman, puppet, Red Hat Satellite
● Probar los diferentes cambios es crítico
● Utilizad herramientas de pruebas automatizadas, tempest, rally

34. Usando OpenStack
● OpenStack está pensado para posibilitar la automatización
● Automatización del proceso de despliegue y configuración de instancias
● Uso de cloud management system como CloudForms
● Uso de herramientas de gestión de configuración como puppet
● Integración en pipelines de continuous integration y delivery –
● jenkins jcloud plugin
● Uso de heat para deployment of stacks completos
● Buscar distribuciones de OpenStack que proporcionen las herramientas adecuadas

35. Patrones de diseño en aplicaciones cloud
● Arquitecturas de aplicación :
● Distribución de componentes
● Acoplamiento débil entre componentes
● Componentes sin estado
● Replicación de estado
● Procesamiento idempotente y/o transaccional
● Arquitectura de gestión
● Configuración externa y centralizada
● Gestión automática de escalabilidad
● Gestión automática de errores