Desde que conocí OpenStack, en noviembre de 2017, he dedicado muchísimas horas a

comprender las capacidades que ofrece este despliegue de software libre.

OpenStack es un proyecto open source, que comenzó en 2010 con el soporte de la

empresa Rackspace, que brinda servicios de infraestructura IT (IaaS).

Por su parte, Red Hat y Canonical (Ubuntu) se unieron al proyecto, y hoy Ubuntu es el SO
que más despliegue tiene como soporte de los servicios de OpenStack.

OpenStack es un conjunto de piezas de software, que se comunican entre sí mediante API

REST.

Las API REST:

REST representa, a partir del año 2000, un nuevo enfoque para las comunicaciones y
servicios web. Es la puerta común mediante la cual diversos proyectos se comunican entre
sí.
REST permite tanto escribir como leer datos de un servidor HTTP, utilizando en general el
formato Json/XML. De modo que, independientemente del lenguaje con el que haya sido
escrito un determinado programa, si dispone de API REST, podemos recuperar datos de
éste, o darle órdenes para que ejecute ciertas acciones, en un lenguaje universal y por
encima de la pila TCP/IP.
Quizás sea importante aprender Json pero para otros fines que escapan a la cooperativa,
yo por lo menos no lo manejo.
La integración de diversas aplicaciones entre sí no sería posible sin API REST. Es un
estándar muy usado, más que su alternativa SOAP. Encontré ejemplos de API/REST para
hacer tweets, pedir datos del clima de una ciudad mediante Google, hacer una búsqueda de
posts en Instagram geolocalizados.

Aunque una nube OpenStack no requiere necesariamente comunicarse con aplicaciones (o

servidores) públicas de Internet mediante REST, utiliza el estándar para que los proyectos
oficiales de OpenStack puedan intercambiar recursos entre sí. Además, como REST es un
estándar conocido, es posible desarrollar software e integrarlo a OpenStack, de hecho
algunos de los nuevos stacks empezaron de esta manera.
Seguramente en nuestro caso, prescindiremos de las capacidades de las API REST:
➔ Porque no manejamos JSON. Solucionable
➔ Porque vamos a trabajar directamente sobre el *servidor (de modo que usaremos el
comando openstack para realizar las tareas necesarias, que genera la serie de
consultas JSON al servidor correspondiente). *a que nos referimos con servidor en
éste ítem? De ser necesario deberíamos customizar/modificar la API que indicas
como comando openstack
➔ Porque nuestra cloud sería, en todo caso, cerrada y no tendría ningún interés de
comunicarse con otros servidores remotos en Internet. No necesariamente, ya que
debemos contemplar servicios como NTP, DNS, VPNs entre otras posibles cosas

Los stacks de OpenStack:

Openstack es absolutamente descentralizado, donde cualquier stack puede correr en
cualquier plataforma GNU/Linux (preferentemente Ubuntu, SUSE ó RHEL) sin necesidad
de respetar una jerarquía.
Cada stack, se encarga de una parte específica del Hardware del nodo que lo reside, y en
general usan programas open source conocidos para tal fin, por ejemplo:
➔ Cinder se encarga del almacenamiento en bloques. Almacena la información en
bloques de almacenamiento, usando LVM como volume manager, entre el disco y
las particiones, o NFS. Hay otras opciones también.
➔ Nova se encarga de mantener activa y corriendo las instancias. Para esto usa
QEMU/KVM, que es software conocido.
➔ Neutron administra las redes, pero utiliza OpenVirtualSwitch (OVS) o Linux Bridge
para el switcheo virtual. El enrutamiento es por forwarding.

Para darle seguridad a una nube OpenStack, las comunicaciones HTTP pasan primero por
un servidor de autenticación, Keystone, que devuelve tokens para habilitar a los stacks
hablar entre ellos. Los tokens se usan mucho en las REST API.

IaaS: Infraestructura como servicio:

Infrastructure as a service es una denominación para referirse a “entregar infraestructura a
disposición del usuario, para que diseñe su propia nube”.
IaaS es el modelo de cloud de más bajo nivel, es decir, el más esencial y por lo tanto más
flexible. Repercute en un diseño muy elástico para el cliente, al poder brindarle recursos de
hardware virtualizados pero sin una estructura predefinida.
Por ejemplo, la plataforma Google Drive es un ejemplo de SaaS, el más alto nivel de
servicios de cloud computing, donde Google provee a los usuarios un programa (la
plataforma Google Drive) mediante la cual el usuario se limita a las opciones que este
software le permite (el dashboard de google drive).

De todos modos, no debe confundirnos la clasificación IaaS que recibe OpenStack.

Es cierto que IaaS está asociado a flexibilidad, variedad, aprovechamiento del HW al más
bajo nivel posible. Pero también es cierto que, en última instancia, el objetivo del cloud
computing es brindar servicios a través de la red, los cuales (los servicios) corren dentro de
un entorno virtualizado, en una distribución GNU/Linux en nuestro caso.

Casi que la definición de IaaS nos hace creer que es la manera de acceder a nuestros
recursos de Hardware de manera pura y directa, sin pasar por una plataforma (un programa
o software por encima) que nos limiten en nuestras operaciones.

Esto me lleva a que me haga una pregunta esencial para lo que buscamos… ¿Cómo puedo
optimizar el uso del HW que tengo a disposición para poder brindar servicios de red?

Entonces… ¿Para qué levantar toda una infraestructura sostenida por stacks, corriendo en
el mismo HW, para que en realidad el fin sea ofrecer servicios fuera de la red donde viven
estos stacks?

¿Qué sentido tiene instalar stacks en un mismo servidor, y que entre ellos hablen por
encima de TCP/IP?, si quiero acceder a los recursos de un disco rígido, ¿primero debo
pasar por un servidor, estando físicamente en el mismo server?

Creo entonces que, en estas condiciones, si en OpenStack buscamos la flexibilidad de

aprovechar nuestro Hardware al máximo, estamos equivocados.

El siguiente vídeo me resultó bastante interesante, en especial porque “intenta” comparar

OpenStack con Vsphere (que es de VMware, muy parecido a Proxmox). Sin embargo las
razones por las cuales defiende OpenStack están fundadas en el uso público y en un perfil
de negocio, orientado a clientes que utilizan la infraestructura que el administrador de
OpenStack tiene para darles.
https://www.youtube.com/watch?v=n628Y2NYcXQ
OpenStack como solución para empresas que trabajan en cloud:
https://searchdatacenter.techtarget.com/es/cronica/OpenStack-tiene-mucho-potencial-pero-
su-adopcion-va-despacio-en-AL-OpenStack-Day-Mexico

¿Qué pasa con la virtualización, pieza fundamental del diseño?

Las técnicas de virtualización de servidores y entornos Linux son una pieza clave del
diseño. Elegir la técnica de virtualización que mejor se acomode a nuestras necesidades
nos permitirá mejorar la performance y funcionamiento de los servicios que tengamos
corriendo.

La técnica de virtualización más extendida en el open source es QEMU, que emula por
completo el HW a bajo nivel, para hacerle creer a la vm que “ella es la dueña de todo el
HW”. QEMU funciona casi como cualquier emulador, y opera por lo tanto en la capa más
alta de virtualización:

Fuente:
https://docs.google.com/document/d/1koA2J26tzWjvTZycuUrOQ68g9hnC2vvhwsdoAs3b2e
A/edit

Además de QEMU, aparece el concepto de KVM para entornos Linux.

KVM permite que la emulación QEMU funcione más rápida, ya que al integrarse
KVM/QEMU, las instrucciones dirigidas al procesador por parte de las vms (procesador y
RAM) no son emuladas sino que atacan directamente al procesador, gracias a la tecnología
VT-X de los procesadores Intel (los procesadores AMD tienen una función parecida).

De modo que solo deben emularse las NICs, discos rígidos, CD-ROM, si operamos con
QEMU/KVM.
Con KVM, obtenemos un rendimiento de “Virtualización Clásica” en referencia al gráfico
anterior.
Como KVM actúa a nivel de kernel en el SO anfitrión, estamos trabajando en un entorno
bare metal (tener cuidado con este término).

1http://mmc.geofisica.unam.mx/femp/Herramientas/MaquinasVirtuales/VirtualizacionEnLinuxCon-Containers/FULLTEXT02.pdf
Es decir, pasamos de esto:

A esto otro:

El siguiente documento puede aclarar muy bien cómo se relacionan KVM y QEMU:
http://i2ds.org/2015/06/25/virtualizacion-a-fondo-la-relacion-entre-kvm-y-qemu/

La aparición de linux containers (LXC):

Los contenedores linux son la evolución en rendimiento y escalabilidad en el mundo de la
virtualización.
En general, cuando emulamos una máquina virtual estamos virtualizando el hardware que
“ve” el SO virtualizado, la vm (virtual machine).
Algunas pruebas de benchmark muestran que el rendimiento de LXC es de 80%(1) respecto
del 100% que es sin virtualizar.

Además, el hardware virtualizado con el que dimensionamos puede no ser adecuado a los
requerimientos de la vm, es probable que reservemos recurso para emulación, y luego la
vm no lo consuma: estamos reservando recurso ocioso.
LXC (linux container) opera exclusivamente sobre sistemas GNU/Linux. En pocas y simples
palabras aprovecha los espacios de usuario (namespaces, chroot, cgroups) para generar
entornos linux en paralelo y aislados, sin necesidad de emular hardware.
Es posible parametrizar una instancia LXC, podemos limitar los recursos de hardware
mediante namespaces. El container corre como un programa más, y solo en el caso de que
consuma mucho recurso, tendrá mayor o menor impacto sobre el rendimiento (sin reserva
de HW, solo cuotas para limitar el consumo).

El concepto y las bases de LXC fueron usados por Docker y LXD, esta última es una
implementación de Canonical para linux containers.

Para justificar el uso de LXC, dejo el siguiente link:

http://www.diva-portal.org/smash/get/diva2:1085809/FULLTEXT02

Y también:
https://ubunlog.com/el-hosting-y-los-contenedores-lxc/

El uso de LXC puede traer problemas de seguridad si no está bien implementado. Las
pruebas que realicé en la nube OpenStack dieron como resultado lo siguiente: las instancias
que levantaba con LXC como hipervisor, podían acceder al sistema de archivos del servidor
anfitrión (esto me pareció un gran problema de seguridad). VER
LXD, la implementación de Canonical, aparentemente seguriza los problemas de LXC, sin
embargo no funciona en OpenStack.

A continuación dejo un cuadro que compara las diversas técnicas de virtualización posibles
en nubes OpenStack:
https://docs.openstack.org/nova/latest/user/support-matrix.html

De los parámetros del cuadro, son relevantes los siguientes:

● Attach block volume to instance: significa poder asignar un disco rígido (en forma de
volumen) a una instancia. Es el punto de encuentro entre Nova y Cinder. Si no
puedo asignar un bloque a una instancia, esta se crea con un disco mínimo, en el
nodo Compute, el cual se pierde se la instancia se elimina (es volátil). Es una
feature fundamental e imprescindible.
● Detach block volume from instance: es el proceso inverso del punto anterior.
● Extend block volume attached to instance: Es una propiedad de LVM, para poder
crecer el tamaño del volumen que administra Cinder, asociado a una instancia.
● Attach virtual network interface to instance: es para poder asignar una interfaz de red
(Neutron) a una instancia dentro de alguna de las redes creadas/manejadas por
Neutron.
● Detach virtual network interface from an instance: eliminar una interfaz de red a una
instancia, que estaba conectada a la red.
● Evacuate instances from host: Es para mover instancias de un nodo o server.
● Live migrate instance accross hosts: Es para mover instancias de un nodo a otro con
poco tiempo de indisponibilidad o caída. Es necesaria la intervención por comando.
● Launch instance: lanzar o levantar una instancia.
 ● Save snapshot of instance disk: Crea un snapshot y lo guarda, del estado actual de
la instancia.
● Remote desktop over VNC: Es usar una consola noVNC para acceder a la consola
de la máquina mediante web.
● Image storage support: Es el soporte para Glance, que almacena las imágenes de
SOs.
● UEFI boot: Para sistemas que no usan BIOS sino UEFI (GTP en lugar de MBR)
● VLAN networking: Soporte para VLAN.

Vemos en el cuadro como LXC no soporta muchos de los servicios que otros hipervisores
si.

Con esta información en mente, puedo resumir algunas de mis experiencias con OpenStack
en lo que refieren exclusivamente a virtualización (los stacks Nova y Glance):
➔ Solo podríamos usar KVM/QEMU para poder tener acceso a las funcionalidades
necesarias (en referencia al link anterior). → OK
Podemos observar en el cuadro que LXC es inútil de implementar. → OK
➔ La implementación de QEMU/KVM es incluso muy restrictiva: se precisa preparar
una imagen especial para OpenStack del SO que se precisa virtualizar. Esta imagen
es para que pueda ser cargada en el servidor Glance y estar disponible para
levantar instancias desde allí. A bajo nivel termina emulando (con QEMU) los
recursos de HW (salvo micro y RAM que lo pasa directamente a KVM);
No es un proceso simple convertir una iso en una imagen compatible con Glance.
Cuando intenté compilar una imagen de FreeBSD me encontré con muchos
problemas, y poca información en internet. → OK, a analizar y testear
➔ Para acceder a la consola de la vm, OpenStack hace uso de noVNC, que es un
programa open source que usa HTML5 y que se encarga de emular la consola de
una vm. Puntualmente en OpenStack es muy lento su funcionamiento. → OK, a
analizar y testear

¿El storage es versátil en OpenStack?

Uno de los objetivos que me planteé al estudiar el diseño de un entorno de virtualización,
una nube privada, era que ante la caída de cualquiera de los equipos -sea cual sea- no
culminé en la caída del servicio y, más ambicioso aún: la nube siga al 100% disponible.

El almacenamiento, en general, es clave en cualquier diseño.

He dedicado tiempo en estudiar Cinder, Swift, integrarlo con QNAP, ver cómo usar QNAP
para que se integre con nuestra nube… Pero otra vez me olvidé de preguntarme algo
fundamental: ¿Qué esperamos almacenar?, o más aún, ¿qué datos tienen que estar en
HA?

En general, OpenStack posee dos stacks referidos al almacenamiento:

➔ Cinder: dialoga directo con Nova (pasando por keystone) para gestionar el
almacenamiento de las instancias. Soporta LVM como backend, mediante la
creación de un VG que puede crecer flexiblemente, thin provisioning (es decir, no
 ocupa todo el bloque sino que lo va llenando a medida que lo necesita). No soporta
ZFS.
➔ Swift: Este stack es accesible mediante Horizon (la GUI de OpenStack) o bien a
través de Cinder. Funciona como backup exclusivamente.
Sus capacidades son muy interesantes: almacena datos en forma de objetos. Estos
objetos, a su vez, se replican de manera que la información sigua consistente a
pesar que alguno (cualquiera) de los nodos caiga. Los nodos son bloques de
almacenamiento o particiones, del sistema operativo.

Se pone confuso Internet cuando te ponés a leer de almacenamiento en objetos o

containers. Aparte el término container también confunde con LXC.

Los containers son las cajas que almacenan los objetos, que en definitiva contienen los
datos que allí almacenamos.

Lo interesante de esta forma de almacenamiento, es que los únicos metadatos asociados a

un objeto son: el ID, el container que lo contiene, y la cuenta a la que pertenece.
Poca información extra al dato en sí (metadato) y una estructura plenamente horizontal
hacen que la escalabilidad de Swift sea inmensa, ordenada y flexible (no se pondría lento a
medida que se llena el espacio en disco).

Sin embargo, recordemos que solo Cinder y Horizon pueden “dialogar” con Swift para
escribir o recuperar datos. Esto se condice con el verdadero sentido de Swift: backups de
datos seguro y confiable.
Nuevamente me pregunto… ¿Qué información necesito tener 100% disponible, confiable y
en redundancia? → La de CINDER (block storage)
A esta pregunta respondo de la siguiente manera:
- Los RAWs/QCOW2 de las vms: Si se rompe o pierde el bloque definido (y
reservado) para una vm, pues entonces la vm cae o al menos queda en un estado
de suspensión (en general, como no puede escribir más el disco donde tiene
montado el /, pone a esa partición en ro para protegerse y mantenerse “viva”). Estos
bloques no pueden estar almacenados en Swift, porque solo soporta backups y
 además la instancia o vm no puede acceder directamente creyendo que es su disco
rígido. → Tal cual, según lo que nos venías contando
- Los backups de las vms: Sabemos que las rutinas de backups son muy importantes.
Tener disponible distintas versiones de una vm nos permite tener la flexibilidad de
“volver a esa versión” cuando tengamos problemas ante algún cambio drástico de la
vm. Swift puede almacenar backups (que en realidad son snapshots) pasando por
Cinder, en caliente. → Sería de SWIFT a través de GLANCE, llegando a NOVA que la
trabajaría contra CINDER, no?

El carácter horizontal, pero el diseño vertical, de OpenStack:

Es preciso explicar el modelo de implementación que tiene OpenStack: no existe una única
forma de desplegar los servicios para conformar un cloud.

OpenStack es el resultado de múltiples servicios independientes (stacks) interconectados

entre sí mediante API REST. → OK
Cada servicio o stack es un conjunto de programas software libre que se instalan en un SO
linux, en nuestro caso directamente sobre un Ubuntu server 16.04. → OK

Es un modelo horizontal en el sentido de que los stacks hablan todos contra todos →
KEYSTONE contra todos, después depende, ej: CINDER no habla con NEUTRON, en una red de
management en la que intercambian solicitudes y realizan operaciones según el caso (son
todas consultas HTTP).

Sin embargo, desplegar una nube openstack en un escenario de 3 servidores, nos obliga a
pensar en:
- 2 nodos que solo tengan instalado Nova y Cinder. → OK
- 1 nodo con todos los otros servicios. → OK
Los nodos Nova consumen recurso de CPU y memoria para las vms, de modo que
OpenStack recomienda que trabajen de manera independiente para poder aislar posibles
problemas (como un apagón o inconsistencia en los discos rígidos). Un nodo Nova que se
cae, implica la migración inmediata de las vms al otro nodo. → Aquí ya no tendríamos HA,
porque no puede conformarse un Cluster con 2 Nodos solamente, mínimo 3

Un solo nodo controller (con todos los stacks menos Nova) nos conduce directamente a una
nube que ya no es HA. En el caso de que se caiga este nodo controlador, las vm siguen
operativas pero ya no se pueden hacer maniobras como migrar vms, consultar el estado de
la nube, gestionar particiones, levantar nuevas vms, etc.

Lo anterior nos muestra que, con pocos servidores, el cloud queda reducido a un diseño
vertical. → mmm, Pacemaker?
Lograr HA en OpenStack significa tener réplicas de cada stack instaladas en diversos
servidores físicos. Algunos de estos stacks pueden funcionar en activo/activo y otros en
activo/pasivo. → Interesante... Desafortunadamente, Nova es un stack que no tiene desarrollo
para HA → Con Pacemaker no?, lo que nos compromete enormemente en nuestro diseño, al
menos hasta que brinden una solución abierta.
Otra opción es implementar nodos ALL-IN-ONE que tengan todos los stacks instalados
(algo así como Proxmox). Sin embargo, los foros no recomiendan implementaciones de este
estilo para un despliegue definitivo, debido a la pérdida de performance al sobrecargar los
nodos con tanto software. → Depende los recursos de las HW Nodos y las nececidades de NOVA
y NEUTRON fundamentalmente Una implementación ALL-IN-ONE también nos obliga a ser
muy minuciosos para garantizar HA y que los stacks redundantes no se pisen entre sí. En lo
personal me parece un desgaste muy grande para un diseño con poco rendimiento: siempre
es mejor tener discriminados los stacks en diversos entornos. → mmm...

Entonces, ¿descartado OpenStack?

No, en absoluto. Si bien OpenStack presenta varias cosas en contra (solo soporta KVM, no
tiene HA con las instancias, no es horizontal) aún podemos crear una nube openstack
dentro de una nube proxmox.

Recordemos que Proxmox no es más que una versión estable de Debian, corriendo
software libre en su totalidad y con algunos programas desarrollados por la comunidad
Proxmox, que le da aún más performance al sistema.

Esta misma nube la podemos usar para crear una nube OpenStack virtualizada, usando
LXC para cada servicio-stack de OpenStack (esto se condice con la implementación
recomendada de OSA, desarrollo open source de RackSpace), y KVM para Nova o incluso
un nodo aparte.

Las herramientas de virtualización que nos ofrece Proxmox y su integración con Pacemaker
nos provee de vms (KVM o LXC) en HA corriendo en almacenamiento en HA (Ceph,
GlusterFS, etc.)

No debería confundirse cuando digo “OpenStack dentro de Proxmox”, porque no es que

OpenStack se confina y se reduce al interior de un entorno Proxmox. Es mejor pensar a
Proxmox con un SO anfitrión, linux, en el cual se instala OpenStack, tal y como lo vengo
haciendo en las pruebas que estuve realizando.

Tener OpenStack virtualizado con LXC me da casi la misma performance que al estar bare
metal (instalado en el mismo entorno de trabajo que el usuario proxmox), pero con muchas
más flexibilidades, entre ellas:
- discriminar y aislar cada stack de OpenStack en un LXC diferente (tal y como lo
hace Rackspace).
- snapshots separados para poder recuperar el estado de un stack en cualquier
momento (ya que usaríamos ZFS como almacenamiento o al menos QCOW2)
- backups de los stacks.
- HA de los stacks, configuraciones activo/activo ó activo/pasivo sin ningún punto de
fallo (podemos usar para esto IPs flotantes con Pacemaker).
- Cinder funcionaría en forma bare metal ya que tendría sus propios bloques de
storage dedicado.
- OpenStack con rendimiento bare metal.
- desarrollos open source instalados sobre proxmox para mejorar la performance de la
nube.
- logs openstack aislados.
 - Desarrollo 100% GNU/Linux sobre una distribución estable, libre y LTS como Debian
Stretch 9.

El rol de Pacemaker + Corosync:

ClusterLabs, como la imagen que antecede a este texto explica, es sofware open source
para el diseño de clusters (más de un servidor conectado para brindar recursos de red) en
Alta Disponibilidad.
Los proyectos Corosync y Pacemaker son la esencia de ClusterLabs.
OpenStack recomienda el uso de este software para la configuración de stacks en
activo/activo o activo/pasivo según el caso. Se puede consultar el siguiente link al respecto:
https://docs.openstack.org/ha-guide/
Es importante mencionar en este punto, que Nova es un stack que aún no tiene una guía
para HA.

Proxmox utiliza también Corosync + Pacemaker para proveer HA en su cluster. En general,

por lo investigado, utiliza resources propios de Pacemaker y también posee integrado
algunos resources especialmente para migración de instancias en caso de failover.

Tenemos entonces dos softwares que operan en conjunto: Corosync y Pacemaker.

Corosync se instala en cada nodo que pertenece al cluster y es el encargado de mantener
el estado de cada uno de estos (si están vivos o no). Para ello utiliza un protocolo basado
en tokens llamado TOTEM.
Corosync a su vez determina qué nodos forman parte del cluster, mediante el uso de
archivos authkey. Requiere además de que se defina una red de “Alta disponibilidad” por la
cual se trafican los paquetes TOTEM.

Por su parte, Pacemaker también se instala en cada nodo del cluster y tiene como función
la ejecución de acciones en el caso de falla de algún nodo del cluster.
Pacemaker define el concepto de resource a un recurso (un servicio o programa corriendo
en un nodo, una IP flotante, un script que se ejecuta cuando hay una caída, etc) que,
corriendo en un nodo, cuando este falla, otro nodo debe levantarlo.

Hay muchos resources que vienen por defecto en Pacemaker, el más usado es el recurso
IP flotante, que asigna una dirección IP a un nodo (alguno de los nodos toma el recurso). Si
este nodo cae, la IP flotante (la misma dirección) la toma otro nodo de modo que el servicio
que tenía esa IP sigue estando disponible.

Por ejemplo, logré con éxito configurar HA con GlusterFS + IP flotante con pacemaker,
entre dos nodos de un clúster. Para servidores NFS también es una buena alternativa para
proveer HA...

Otras fuentes:

Ver:
http://sedici.unlp.edu.ar/bitstream/handle/10915/50514/Documento_completo.pdf-PDFA.pdf?
sequence=1
También:
https://riunet.upv.es/bitstream/handle/10251/68958/OSUNA%20-%20Creaci%C3%B3n
%20de%20sistema%20cloud%20con%20OpenStack.pdf?sequence=1

A mi no me parece mal pensar en, digamos, Cinder como un monstruo enorme que maneja
todo el almacenamiento que tenemos y distribuye la carga en los discos que maneja (con
LVM). OpenStack puede ser un proyecto enorme con muchísimos servidores corriendo y
sirviendo, muy ágil para integrar nuevos stacks (con Ansible especialmente).
Sin embargo la manera en que percibo OpenStack, el enfoque que le doy, es siempre
pensando en HA: siempre pensando en que ningún servicio se corte nunca, pase lo que
pase; estar protegidos frente a cualquier evento.
Y para pensar esta HA, enseguida pienso o recuerdo el HW que dispongo para el diseño:
no puedo abstraerme en este sentido.
Y a decir verdad, estudiar OpenStack pensando todo el tiempo en HA, hace que se perciba
distinto a lo que realmente está enfocado: siento que es como encararlo de comienzo por un
costado débil del proyecto.

Entonces pienso que Openstack no es apropiado para el HW y las condiciones de HA que

tenemos y queremos. En este sentido imagino como referencia implementaciones que
cuenten de por lo menos 30-40 servidores físicos, un datacenter mucho más grande que el
nuestro.
Teniendo muchos servidores, incluso, me hubiera empeñado en profundizar en la
implementación OSA que explica Rackspace de manera oficial y libre. Con el uso de scripts
en Ansible, se maneja de manera remota por SSH la agregación de nuevos nodos al cluster
(Nova, Cinder, etc) a partir de máquinas Linux vírgenes.
KVM vs LXC:
http://www.patrikdufresne.com/fr/proxmox-kvm-vs-lxc/

https://wiki.openstack.org/wiki/Masakari#Masakari:_Instances_High_Availability_Service

https://docs.openstack.org/ha-guide/index.html

https://docs.openstack.org/ha-guide/intro-ha-arch-pacemaker.html

https://docs.openstack.org/ha-guide/intro-ha.html