Introducción a SUSE Open Stack Cloud 7

Introducción a SUSE OpenStack Cloud 7 p. 1
Introducción a SUSE
OpenStack Cloud 7
SUSE OpenStack Cloud www.suse.com
v. 1.2 – 20170812
Juan Herrera Utande
juan.herrera@suse.com

Indice
Esquema general de la solución SUSE OpenStack Cloud (SOC)..........................................3
Introducción..................................................................................................................................................3
Elementos principales..............................................................................................................................5
Servidor de administración...................................................................................................................6
SUSE Manager.............................................................................................................................................7
Nodos de control.......................................................................................................................................8
Nodos de cómputo...................................................................................................................................9
Nodos de almacenamiento.................................................................................................................10
Alta disponibilidad.......................................................................................................................................10
High Availability Extension..................................................................................................................10
Zonas de disponibilidad........................................................................................................................13
Cluster de computación............................................................................................................................13
Alta disponibilidad en nodos de cómputo..................................................................................14
Marcado de imágenes............................................................................................................................15
Integración con KVM..............................................................................................................................15
Alta disponibilidad en Nova con KVM...........................................................................................16
Integración con VMWare......................................................................................................................17
Alta disponibilidad de Nova con VMWare...................................................................................18
Automatización de tareas........................................................................................................................19
Automatización de la creación imágenes personalizadas para los sistemas
operativos...................................................................................................................................................20
Creación de plantillas HEAT................................................................................................................21
Gestión de configuraciones y despliegue de software.........................................................21
Almacenamiento..........................................................................................................................................22
Creación de entornos................................................................................................................................22
Seguridad de la plataforma....................................................................................................................23
Acceso a la información relativa a la seguridad......................................................................23
Políticas activas de seguridad mediante SUSE Manager...................................................24
Elementos específicos de seguridad en OpenStack.............................................................26
Gestión de usuarios mediante directorios externos y Keystone.....................................26
Segregación...............................................................................................................................................26

Esquema general de la solución SUSE
OpenStack Cloud (SOC)
Introducción
SUSE® OpenStack Cloud es una plataforma de cloud computing automatizada
que permite a las organizaciones la implantación rápida y la gestión sencilla de
nubes privadas de alta disponibilidad, con entornos de hipervisor mixtos y basadas
en OpenStack. SUSE OpenStack Cloud combina la potencia de OpenStack y otros
proyectos de código abierto, como Crowbar, Pacemaker, KVM o Ceph, con la
excelente ingeniería y asistencia de SUSE.
Características principales de SUSE OpenStack Cloud:
 Software libre basado en la versión Newton de OpenStack.
 Solución fiable y preparada para su uso en producción
 Soporte Enterprise 24x7 y ciclo de vida extendido
 Seguimiento centralizado de recursos aportando información relevante sobre
las actividades y capacidad de la infraestructura cloud para optimizar el
despliegue automático de servicios.
 Procesos de instalación automatizados con Crowbar usando scripts
predefinidos (barclamps) para configurar y desplegar de manera sencilla los
nodos de control, cómputo y almacenamiento.
 Integración con de las tecnologías de Pacemaker y Corosync para posibilitar el
montaje en alta disponibilidad de todos los elementos que componen
OpenStack
 Soporte heterogéneo de hipervisores: KVM, Xen, VMWare, HyperV y z/VM
 Soporte para despliegue sobre nodos físicos (Ironic)
 Despliegue clústeres Big Data gracias al módulo Sahara
 Despliegue de clústeres de orquestación de contenedores gracias al módulo
Magnum que da soporte a Kubernetes y/o Mesos

El esquema de módulos de SUSE OpenStack Cloud
SUSE dispone de un programa específico de partnerships alrededor de OpenStack
para garantizar una solución completa, con calidad empresarial, que aúna los
mejores proyectos de código abierto con elementos proporcionados por sus
partners de Cloud en las áreas de:
- Almacenamiento (Ceph, NetApp, EMC, ..),
- Red definida por software (Open vSwitch, Nuage, Midokura, …)
- Hipervisores (VMWare, Cloudbase,...),
- Plataforma hardware (HPE, Fujitsu, Cisco, Lenovo, SuperMicro…)
Más información sobre el programa de partners de OpenStack Cloud:
https://www.suse.com/es-es/partners/suse-openstack-cloud/

Elementos principales
SUSE OpenStack Cloud se basa en las tecnologías de SUSE Linux Enterprise
Server, OpenStack, Crowbar y Chef. SUSE Linux Enterprise Server 12 SP2 se utiliza
como sistema operativo subyacente para todas las máquinas de la infraestructura
de la nube (también llamados nodos). La capa de administración de la nube,
OpenStack, actúa como “Sistema Operativo de la Nube”. Crowbar y Chef se utilizan
para desplegar y administrar automáticamente los nodos de OpenStack desde un
servidor central de administración.
Infraestructura de SUSE OpenStack Cloud
SUSE OpenStack Cloud se despliega en cuatro tipos diferentes de máquinas:
o Un servidor de administración para desplegar y administrar nodos
o Uno o más nodos de control para albergar los servicios de
administración de la nube
o Varios módulos de cómputo donde se instancian las máquinas
virtuales

o (Opcional) Varios nodos de almacenamiento para almacenamiento de
bloques y objetos
Servidor de administración
El servidor de administración provee todos los servicios necesarios para gestionar
y desplegar los demás nodos de la nube. La mayoría de estos servicios los
proporciona la herramienta Crowbar que, junto a Chef, automatiza todas las tareas
necesarias de instalación y configuración. Entre los servicios ofrecidos por el
servidor, se encuentran DHCP, DNS, NTP, PXE, TFTP.
Flujo típico de despliegue de un nodo de OpenStack mediante Crowbar
El servidor de administración también alberga los repositorios de software de
SUSE Linux Enterprise Server y SUSE OpenStack Cloud. Son necesarios para el
despliegue de los nodos. Si no se encuentran disponibles otras fuentes para los
repositorios, puede albergar la herramienta de administración de suscripciones
(SMT), ofreciendo repositorios con actualizaciones y parches para todos los nodos.

SUSE Manager
SUSE Manager es una herramienta opcional que centralizada de gestión de
sistemas y ofrece funcionalidades de primera clase para la gestión centralizada de
sistemas basados en SUSE Linux Enterprise Server, RedHat Enterprise Linux y
CentOS.
SUSE Manager incluye gestión de software, aprovisionamiento de entornos y
monitorización que permiten gestionar los ecosistemas basados en Linux tanto
sobre infraestructura física como en servidores virtuales.
Como resultado se pueden obtener altos grados de eficiencia en la gestión y la
posibilidad de disponer de entornos auditados y controlados a nivel de
actualización de funcionalidades, bugs y gestión de vulnerabilidades.
Ciclo de administración con SUSE Manager

Cada equipo del entorno de SUSE OpenStack Cloud debe ser registrado para ser
gestionado mediante un barclamp específico en Crowbar durante el proceso de
instalación. Se pueden registrar hasta un máximo de 50 nodos de OpenStack
independientemente de si estos son nodos de control o computación lo que
permite escalar desde nubes básicas hasta grandes entornos empresariales.
Los equipos basados en SUSE Linux Enterprise Server, RedHat Enterprise Linux o
CentOS que se ejecuten sobre los nodos de cómputo de OpenStack también
pueden ser integrados y gestionados en SUSE Manager mediante la adquisición de
suscripciones de cliente adicionales.
Más información en: https://www.suse.com/es-es/products/suse-openstack-
cloud/features/cloud-ready-applications.html
Nodos de control
Los nodos de control albergan todos los servicios OpenStack necesarios para
orquestar las máquinas virtuales desplegadas en los módulos de cómputo de SUSE
OpenStack Cloud. OpenStack en SUSE OpenStack Cloud utiliza una base de datos
PostgreSQL, que también se alberga en los nodos de control. Los siguientes
componentes de OpenStack, en caso de que se desplieguen, se ejecutan en los
nodos de control:
 Base de datos PostgreSQL
 Glance, para gestionar imágenes virtuales
 Keystone, proporciona autenticación y autorización para todos los servicios de
OpenStack
 Neutron, proporciona “red como servicio” entre interfaces gestionadas por
otros servicios de OpenStack
 Cinder, proporciona almacenamiento de bloques
 Horizon proporciona el Dashboard, una interfaz web para los servicios de
OpenStack
 Nova controller para gestionar los nodos de cómputo. Incluye una API y un
planificador
 RabbitMQ, un agente de mensajes
 Swift proporciona almacenamiento de objetos. Dispone de un servidor proxy
para monitorear su salud (junto con herramientas de balanceo) y Swift ring
(índice de objetos, réplicas y dispositivos).

 Calamari, monitor del cluster principal de Ceph. Necesita desplegarse en un
nodo dedicado
 Hawk, un monitor para clústeres en alta disponibilidad
 Heat, un sistema de orquestación
 Servidor y agentes de Ceilometer. Este servicio recopila datos de uso de CPU y
red con fines de facturación
 Trove, una base de datos como servicio. Se necesita desplegar en un nodo
dedicado
Al ser un punto focal en la arquitectura de SUSE OpenStack Cloud que ejecuta
diversos servicios, un único nodo de control puede convertirse rápidamente en un
cuello de botella, sobre todo en grandes despliegues. Es posible distribuir los
servicios antes listados entre más de un nodo de control, hasta una configuración
en que cada nodo ejecute un único servicio.
En ambientes en producción se recomienda desplegar ciertas partes de los
servicios de red (Neutron) en un nodo aparte o integrar sistemas de SDN
específicos.
Albergar los servicios de identidad (Keystone) en un nodo exclusivo permite
separar los servicios de autenticación y autorización de otros servicios de la nube
por razones de seguridad. Otro candidato ideal para alojarse en un nodo separado
es el almacenamiento de bloques (Cinder, y en especial sus volúmenes) cuando se
utilicen discos locales para el almacenamiento. Desplegarlo en uno o más nodos
separados permite utilizar hardware de almacenamiento y red más adecuados a
estos servicios. Trove, la base de datos como servicio de SUSE OpenStack Cloud y
Calamari, el servidor de gestión y monitoreo de Ceph, siempre deberían
desplegarse en nodos de control exclusivos.
Nodos de cómputo
Los nodos de cómputo son el conjunto de máquinas en las cuales se ejecutan las
instancias. Dichas máquinas necesitan equiparse con suficientes CPUs y RAM
suficiente para iniciar varias instancias. También necesitan suficiente espacio en
disco. El nodo de control distribuye eficazmente las instancias entre el conjunto de
nodos de cómputo y provee los recursos de red que se necesiten. El servicio de
cómputo (Nova) de OpenStack se ejecuta en los nodos de cómputo y proporciona
medios para configurar, iniciar y parar máquinas virtuales.

SUSE OpenStack Cloud soporta varios hipervisores, tales como Hyper-V, KVM,
VMware vSphere, Xen, z/VM y Docker. Cada imagen que se pueda iniciar con una
instancia está asociada a un hipervisor. Los nodos de cómputo pueden ejecutar un
sólo hipervisor a la vez. Puede elegir qué hipervisor desea ejecutar en cada nodo
de cómputo cuando despliegue el barclamp de Nova.
Nodos de almacenamiento
Los nodos de almacenamiento son el conjunto de máquinas que proporcionan
almacenamiento de objetos o bloques y solo son necesarios en caso de que no se
disponga de sistemas de almacenamientos externos compatibles con OpenStack.
El almacenamiento de objetos lo proporcionan OpenStack Swift, mientras que el
almacenamiento de bloques lo proporciona Cinder, el cual soporta diversos back-
ends, entre ellos Ceph, que se puede desplegar durante la instalación. El despliegue
de Swift y Ceph es opcional si ya se dispone de sistemas de almacenamiento
externos con drivers específicos para OpenStack o que proporcionen protocolos
basados en bloques y sistemas de ficheros en red.
Alta disponibilidad
High Availability Extension
Un fallo en algún componente de SUSE OpenStack Cloud (SOC) puede conducir a
paradas de servicio y/o pérdida de datos. Para evitarlo, SUSE OpenStack Cloud 7
permite que todas las funciones provistas por los nodos de control estén en alta
disponibilidad. Durante el despliegue de la nube, se puede configurar un cluster en
alta disponibilidad compuesto por varios nodos. Se pueden asignar roles al cluster
en vez de asignarlos a nodos individuales. A partir de SUSE OpenStack Cloud 7,
además de los nodos de control, podemos tener los servidores de cómputo
configurados con alta disponibilidad.
Para todos los roles en alta disponibilidad, sus respectivas funciones se gestionan
automáticamente por la High Availability Extension de SUSE Linux Enterprise. La
High Availability Extension utiliza Pacemaker como gestor de recursos del cluster y
Corosync/OpenIAS como capa de mensajería/infraestructura.

Puede visualizar el status del cluster y su configuración con las herramientas de
gestión de cluster HA Web Console (Hawk) o la shell crm desde el nodo de
administración.
Para adecuar el entorno a los requerimientos de alta disponibilidad del cliente la
propuesta es crear los siguientes clusters con Pacemaker:
- Cluster de datos: para los barclamps de la base de datos y de
RabbitMQ
- Cluster de red: para el barclamp de Neutron
- Cluster de servicios: para los barclamps de Keyston, Glance, Cinder,
Neutron, Nova, Horizon, Heat, Manilla y Ceilometer.
- Cluster de computación: para los nodos de Nova. Este cluster es
necesario si y sólo si se desea HA a nivel de nodos de computación
gestionado por SOC.
Los clusters serán desplegados en los tres nodos físicos definidos como nodos de
control del Cloud. La el estado de cada servicio en los diferentes clusters y
servidores físicos será el siguiente:

Distribución entre los nodos de control físicos:
Ante la posibilidad de cortes de conexión entre los dos centros de datos en los que
se reparten los servicios de OpenStack y del entorno de virtualización de VMWare
se configurará en Pacemaker el sistema STONITH basado en SBD (Shared Block
Device) mediante una dispositivo de bloques externo accesible por iSCSI en el
entorno de almacenamiento de NetApp.
Este sistema junto con las configuraciones de quórum del cluster nos permitirán
definir el comportamiento antes los diferentes tipos de corte del servicios o ante
situaciones split-brain.
Si bien se pueden usar políticas automáticas ya predefinidas en Pacemaker el
cliente podrá personalizarlas. Es de especial importancia definir en qué escenarios
de desea delegar al cluster la recuperación del entorno y en qué caso se preferirá
hacerlo de manera manual.

Zonas de disponibilidad
Se recomienda que durante la fase de configuración de SOC se creen al menos dos
zonas de disponibilidad que representen a ambos centros de datos. Esto permitirá
que los proyectos que hagan uso de la infraestructura puedan hacer
configuraciones adicionales sobre la alta disponibilidad de sus cargas de trabajo.
Cluster de computación
El disponer de dos infraestructuras de virtualización bajo una misma capa de red
SDN permitirá gran flexibilidad en los sistemas de despliegue y nos permite aunar
lo mejor de cada plataforma de manera casi transparente.
Todas las cargas de cómputo a nivel de OpenStack están gestionadas por Nova.
Nova dispondrá de una configuración específica para cada tipo de hipervisor pero,
una vez instalados y configurados desde Crowbar, en la consola de OpenStack
dichos servidores podrán ser utilizados indistintamente para el aprovisionamiento
de recursos.
Si se desea, la tecnología subyacente a nivel de hipervisor puede ser totalmente
transparente para los proyectos que se definan.
Se recomienda, en todo caso, definir agrupaciones de servidores a nivel de
hipervisor ya que, junto con la definición de zonas de disponibilidad para cada uno
de los centros de datos, aportarán más grados de libertad y flexibilidad en la
definición y modelado de los proyecto a implantar sobre el entorno de nube.

Esquema de despliegue multi-hipervisor:
Alta disponibilidad en nodos de cómputo
Si bien la gestión del multi hipervisor permitirá una gestión unificada mediante
Horizon o el API de OpenStack a nivel la configuración de alta disponibilidad se
deberán seguir estrategias separadas para cada uno de ellos.
Los nodos de cómputo basados en KVM se pueden dar de alta
Si bien los nodos de cómputo basados en VMWare también pueden ser
gestionados en Pacemaker esto solo afecta a la comunicación con el API de Nova
en dichos y no a las cargas de trabajo que se ejecutan en los diferentes servidores
ESXi.
Esto implica que una máquina virtual no va poder ser movida en caliente desde un
host de Nova basado en KVM a un host the Nova basado en VMWare y viceversa.

Dichos movimientos tendrán que ser necesariamente hacia otros nodos de KVM o
VMWare respectivamente.
Más adelante se detallarán los procedimientos para dotar de alta disponibilidad a
cada tipo de hipervisor.
Marcado de imágenes
En un entorno de multi hipervisor es importante que las imágenes base de los
sistemas operativos a desplegar tengan definido el tipo de hipervisor
(qemu/qcow2 para KVM y vmware para VMWare). Gracias a herramientas como
SUSEStudio o Kiwi se podrán mantener ambos tipos de imágenes a partir de las
mismas imágenes fuente simplificando la definición posterior de plantillas de
automatización del aprovisionamiento de infraestructura y el despliegue de
software.
Integración con KVM
KVM es el hipervisor por defecto incluido en todas las distribuciones de OpenStack
ya existe un framework standard para su conexión con el resto de piezas de la
arquitectura.
Dentro del proceso de despliegue de los nodos de OpenStack en SOC existe un
barclamp específico en Crowbar denominado nova-compute-kvm
Las principales configuraciones a definir de cara al despliegue son:
- Ratios de overcommitment para los recursos de memoria y CPU
virtuales.
- Soporte para migración en caliente: este podrá ser activado en cuyo
caso, será necesario definir los parámetros de acceso al almacenamiento
NFS que será utilizado por todos aquellos nodos de Nova-KVM en los que
también esté activada la opción de migración en caliente.

Alta disponibilidad en Nova con KVM
Los nodos de cómputo de Nova con KVM pueden ser incluidos de manera sencilla
en el cluster de Pacemaker tal como se explicaba al principio del documento al
venir integrados en el producto los recursos de cluster preconfigurados.
Si un nodo de cómputo falla o queda inaccesible y el cluster no puede recuperarlo
se activará el mecanismos de “fencing” y todas las máquinas virtuales se moverán
a otro nodo de cómputo.

Integración con VMWare
Soporte en SOC para integraciones con VMWare
VMWare aporta grandes mejoras a un entorno de OpenStack. Muchas de sus
características facilitan la implementación de OpenStack simplificando la
configuración y el número de pasos necesarios para la provisión de recursos.
Las funcionalidades de la plataforma vSphere se hacen visibles en el mundo
OpenStack a través de drivers que hacen de proxies traduciendo las peticiones en
el formato del API de OpenStack a sus equivalentes en las diferentes soluciones de
VMWare.

Dicha integración no solo se limita al hipervisor si no que, tal como veíamos en el
diagrama anterior, se puede hacer una integración completa con los sistemas de
red definida por software y almacenamiento de VMWare.
Si se utiliza VCDriver podremos además beneficiarnos de funcionalidades
avanzadas como vMotion, HA y Dynamic Resource Scheduler (DRS) soportadas
dentro de OpenStack.
Centrándonos en la integración relativa a los nodos de cómputo de OpenStack
(Nova) necesitaremos disponer de acceso a través del API de vCenter versión 5.1 o
superior.
Desplegaremos un nuevo nodo de Nova para VMWare desde Crowbar con su
barclamp correspondiente proporcionando la información relativa a la dirección y
las credenciales de acceso así como una lista de los nombres de clusters a los que
se quiere tener acceso. También será obligatorio especificar los datastores que
estarán disponibles para las máquinas virtuales que se creen desde OpenStack.
A todos los efectos estos nodos de Nova actúan como proxies y por tanto no les
aplican los requerimientos de HW/SW de los nodos de virtualización puros y
pueden ser virtualizados.
Alta disponibilidad de Nova con VMWare
Este apartado se refiere solo al nodo de Nova que hace de proxy con el entorno de
vCenter.
Si se desea alta disponibilidad ante la caída de un nodo ESXi se deberán realizar las
configuraciones correspondientes con la solución de HA de VMWare siendo todo
esto trasparente al entorno OpenStack.
Gracias a la integración con la solución SDN que nos permitirá compartir
direccionamientos entre las dos nubes y a la disponibilidad de una solución de HA
tanto en el lado de VMWare como con en el lado de OpenStack (mediante las
extensiones de ha de SUSE) podremos elegir entre dos modos de despliegue:

- Crear un cluster activo/pasivo sobre una máquina virtual KVM dentro
de la infraestructura base del entorno de OpenStack y utilizar Crowbar para
desplegar y configurar sobre ella en el el barclamp de Nova-Vmware
- Crear una máquina con soporte HA dentro de la infraestructura de
VMWare y utilizar Crowbar para desplegar y configurar sobre ella en el el
barclamp de Nova-Vmware
Automatización de tareas
El módulo Heat está incluido por defecto en SOC por lo que se podrán realizar
todas las tareas de automatización para el despliegue de infraestructura mediante
la creación de plantillas en los formatos:
- HOT: formato nativo de Heat
- CFN: formato nativo de Amazon AWS y compatible con OpenStack.
Las plantillas HOT y CFN describen una instalación compuesta por uno o más
recursos de la nube, descritos en una o varias plantillas agrupadas mediante
composición que son instanciados como “Heat Stacks”
Si bien HEAT permite definir escenarios complejos para el despliegue de los
recursos del entorno SOC (desde nodos de cómputo individuales, hasta
agrupaciones de nodos de cómputo, volúmenes de almacenamiento,
configuraciones de red y reglas de seguridad) es recomendable el uso de una
herramienta especializada debido a las limitaciones de la herramienta en ese tipo
de escenarios.
Por tanto, los despliegues de software sobre la infraestructura aprovisionada se
pueden (y deben) realizar con herramientas optimizadas para la gestión de la
configuración tales como Ansible, Salt, Chef o Puppet.
Mediante el uso recursos de despliegue de software dentro de las plantillas
podremos realizar en enlace con dichas herramientas.
Para la automatización de los procesos de despliegue de infraestructura y software
se recomienda un proceso en tres fases que une los tres elementos configurables
durante el despliegue de nuevos proyectos:

1. Definición de las imágenes base del sistema operativo: creación de
imágenes personalizadas que contienen las configuraciones básicas de los
sistemas operativos y los paquetes que son comunes a todos los escenarios.
El uso de este tipo de imágenes simplifica el proceso posterior de gestión
del software que podrá obviar las configuraciones relativas al sistema
operativo.
2. Uso de plantillas Heat que nos permitan utilizar una o más imágenes
base en el proceso automatizado de creación de la infraestructura
necesaria..
3. El paso final de configuración del entorno software cada despliegue
mediante Ansible, Salt, Puppet o similares.
Automatización de la creación imágenes personalizadas
para los sistemas operativos
En una primera fase se actúa al nivel de las imágenes de sistema operativo con el
objetivo de garantizar que estas disponen de las características específicas del
cliente que serán compartidas por todas las instancias del entorno cloud.
Existen múltiples herramientas que facilitan la gestión de dichas imágenes y su
preparación. La herramienta Kiwi de SUSE viene integrada dentro del entorno SOC
y, así mismo, se dispone de la herramienta de acceso público SUSE Studio (basada
en Kiwi) y que permite la gestión completa del proceso de creación y prueba de
las imágenes para múltiples sistemas operativos y formatos de salida (OpenStack
con KVM o Xen, VMWare, Microsoft Azure y Amazon AWS)
SUSE Studio integra un gestor de dependencias, un gestor de versiones y un
entorno de ejecución de imagenes para que todo el proceso de creación y pruebas
de las imágenes pueda realizarse desde un mismo punto y sin consumir recursos
en el entorno del cliente.
https://susestudio.com/help/faq.html
Las imágenes generadas por el cliente deberán ser importadas en Glance para
poder ser usadas dentro del proceso de aprovisionamiento de OpenStack.

Creación de plantillas HEAT
En la segunda fase entran en juego las plantillas de Heat que definen, para un
determinado producto o servicio del cliente, el conjunto de la infraestructura a a
provisionar (instancias de cómputo, redes virtuales, almacenamiento,,,,) junto con
las imágenes base de los sistemas operativos que hemos generado para cada uno
de los hipervisores
Es este punto es importante el marcado de las imágenes disponibles en Glance
para que podamos hacer la correcta selección de las mismas dentro del template
en función del tipo de hipervisor.
Gestión de configuraciones y despliegue de software
Una vez desplegada la infraestructura mediante las plantillas CFN o HOT, ya sea
ésta simple o compleja, se activará el hook de invocación de la herramienta de
gestión de la configuración deseada para la ejecución de las plantillas generadas
por el cliente para los diferentes escenarios de despliegue de software.

Almacenamiento
Si el cliente dispone de un sistema de almacenamiento externo para su uso con los
entornos de virtualización VMWare y OpenStack se puede simplificar la
arquitectura global de OpenStack al poder prescindir del módulo opcional de
almacenamiento de objetos (basado en Swift o Ceph).
Así mismo podremos desplegar Cinder utilizando los drivers y características
nativas para OpenStack de los sistemas de almacenamiento certificados o el
acceso mediante iSCSI o NFS.
La lista completa de sistemas de almacenamiento compatibles con Cinder se
puede consultar en: https://wiki.openstack.org/wiki/CinderSupportMatrix
En este entorno, el almacenamiento físico para los repositorios de imágenes de
Glance y características como “live-migration” en KVM en las instancias de
cómputo se configuran mediante el uso de volúmenes específicos aprovisionados
en soluciones tipo NetApp, Pure, EMC ... y exportados como NFS.
Creación de entornos
Desde el SUSE Customer Center se pueden generar códigos adicionales para la
instalación de entornos de pruebas/evaluación para SOC.
La instalación de dichos entornos puede realizarse manualmente siguiendo las
directrices de la guía de despliegue y se pueden aplicar si fuera necesario las
configuraciones de los diferentes clusters para alta disponibilidad creando, de este
modo, réplicas exactas del entorno de producción.
Para la creación de entornos destinados a pruebas o formación de manera más
rápida, SUSE dispone de un sistema de despliegue rápido de un entorno SOC
sobre infraestructura virtual que se distribuye mediante un lápiz USB o una imagen
autoarrancable.

Dicha imagen al arrancar crea un entorno completo de SOC incluyendo un nodo de
administración, un nodo de control, un nodo de red, dos nodos de almacenamiento
y tres nodos de cómputo.
Se recomienda que este entorno se despliegue en un entorno físico o virtual con
las siguientes características:
- Procesador de cuatro núcleos Intel/AMD con soporte para
extensiones de virtualización
- Un mínimo de 16GB de RAM (32GB de RAM recomendados)
- 200GB de disco (se recomienda usar discos SSD)
- Puerto USB (USB3 recomendado)
Si se desea realizar el proceso de despliegue de manera rápida pero paso a paso
también existe una imagen preconfigurada de un servidor de administración con
una configuración base predeterminada. Una vez arrancado se pueden añadir
máquinas virtuales adicionales con soporte PXE y para las que se irán aplicando los
roles correspondientes mediante Crowbar (computación, control, …). Este entorno
puede ser puesto en marcha en un hardware básico y la limitación vendrá
solamente impuesta por el número de máquinas virtuales a añadir (casa servicio
consumirá una máquina virtual).
Seguridad de la plataforma
Acceso a la información relativa a la seguridad
SUSE dispone de un completo conjunto de herramientas, documentación y
políticas para garantizar los máximos estándares de seguridad en sus productos.
El sistema operativo SUSE Linux Enterprise Server sobre el que se ejecutan los
servicios de SUSE OpenStack Cloud dispone, entre otras, de las certificaciones
FIPS 140-2 y Common Criteria:
https://www.suse.com/support.security/certifications/

Dispone adicionalmente de guías específicas para bastionado de sistemas:
https://www.suse.com/documentation/sles-
12/book_security/data/book_security.html
Para la identificación temprana de posibles amenazas, el cliente puede registrarse
en el SUSE Customer Center (SCC) para recibir notificaciones por email sobre
vulnerabilidades o actualizaciones de seguridad que puedan afectar a los
productos instalados tan pronto como estas son detectadas.
Adicionalmente existe:
- Un listado público y detallado todos los CVE relacionados tanto con
el sistema operativo base como con el resto de productos de SUSE (tales
como SUSE OpenStack Cloud) de los últimos 16 años:
https://www.suse.com/security/cve/
- Un buscador donde poder realizar conjuntas completas por producto,
versión, paquete, código de CVE, … :
https://download.suse.com/patch/finder/
En ambos casos, para cada CVE, se puede consultar el detalle de la vulnerabilidad,
los productos afectados, el impacto y la solución implementada. Se incluyen
también los enlaces al sistema de seguimiento de bugs que son totalmente
públicos y que permiten obtener detalles extendidos e interactuar con los equipos
de ingeniería de SUSE.
Políticas activas de seguridad mediante SUSE Manager
Toda la información disponible sobre seguridad y actualizaciones nos ayuda a
identificar en todo momento el estado de nuestra infraestructura cloud pero, para
una correcta aplicación de las políticas de seguridad y auditoría, se hace necesario
que los parches y actualizaciones asociados a vulnerabilidades se puedan instalar
de una manera sencilla y rápida.
No es menos importante el poder disponer de informes claros de que equipos o
productos están afectados y poder planificar las acciones de subsanación
correspondientes.

La funcionalidad de auditoría de SUSE Manager es clave en este proceso ya que
nos permitirá en todo momento:
- Conocer las versiones de los paquetes de SO disponibles en cada
equipo
- Generar informes sobre vulnerabilidades con los sistemas afectados
- Con los resultados de los informes se pueden planificar los procesos
de actualización que pueden ser manuales o programados y donde se
puede gobernar el proceso pudiendo definir agrupaciones de servidores,
gestionar excepciones, realizar simulaciones de ejecución, …
SUSE Manager es un módulo opcional que está integrado con el nodo de
administración de SOC por lo que permite integrar la instalación o actualización de
paquetes con las operativas de gestión del cluster garantizando de este modo que
las intervenciones no afecten en ningún momento a la disponibilidad de la
plataforma.
Desde SUSE Manager podemos conectar con más de un entorno SOC pudiendo
definir entornos de pruebas sobre los que realizar pruebas. Por defecto SUSE
Manager viene configurado para gestionar tres tipos de escenarios: desarrollo,
pruebas y producción.
Dichos escenarios pueden ser personalizados por el cliente para adecuarlos a sus
procedimientos de pruebas y despliegue.

Elementos específicos de seguridad en OpenStack
Dentro del producto SOC se plantea un despliegue en el que se activen por
defecto las características de cifrado en los diferentes APIs internos de los
componentes de OpenStack de manera que la interacción entre ellos y
desde/hacia la consola de gestión Neutron se realice mediante SSL.
Gestión de usuarios mediante directorios externos y
Keystone
El usuario podrá. adicionalmente, delegar la gestión de usuarios y tentants a su
entorno de directorio activo permitiendo de esta manera centralizar el
mantenimiento de acceso tanto a la administración del entorno de OpenStack
como al de los diferentes proyectos. Si fuera necesario se puede realizar un mapeo
de los grupos definidos en el Directorio Activo con los tenants/proyectos definidos
en OpenStack.
La integración con directorio activo de Microsoft o servidores LDAP se realiza a
través del módulo Keystone. SOC incluye soporte para la versión 3 del API lo que
permite la gestión de dominios y grupos.
El backend para Keystone utilizado por defecto en SOC es UUID. Si bien se seguirá
incluyendo PKI por compatibilidad hacia atrás, se desaconseja su uso en entornos
productivos (CVE-2015-7546).
Segregación
El entorno permitirá un particionado lógico del entorno en proyectos (también
llamados tenants en versiones anteriores de OpenStack) sobre los que se pueden
definir reglas de acceso y consumo de los recursos.
Diferentes proyectos, usuarios y grupos se pueden agrupar en dominios.
El aislamiento de estas particiones lógicas de los recursos del cloud están
garantizadas por las capacidades de gestión de entornos “multi-tentant” de SUSE
OpenStack Cloud 7.

Introducción a SUSE Open Stack Cloud 7

Recomendados

Recomendados

Más contenido relacionado

La actualidad más candente

La actualidad más candente (20)

Similar a Introducción a SUSE Open Stack Cloud 7

Similar a Introducción a SUSE Open Stack Cloud 7 (20)

Más de Juan Herrera Utande

Más de Juan Herrera Utande (7)

Último

Último (11)

Introducción a SUSE Open Stack Cloud 7