Separación de una nube – Celdas

El Teorema de Brewer afirma que es imposible garantizar la Consistencia(Consistency), Disponibilidad(Availability) y la Tolerancia al Particionado(Partition Tolerance) de datos de manera simultanea en un Sistema Distribuido, de tal forma que solo posible tener alguna combinación de dos características al mismo tiempo.

Celdas

Para permitir el crecimiento horizontal de una nube de manera que pudiese superar los limites impuestos por las Base de Datos Relacionales y/o Message Brokers, el servicio de OpenStack Compute(Nova) propuso el concepto de Celdas, el cual sacrifica la Consistencia de los datos en favor a la Disponibilidad y Tolerancia al Particionado.

Su primera etapa de implementación fue realizada a partir del release de Grizzly. Esta versión carece de documentación y es bastante confusa para en su utilización, es por ello que se creo una segunda versión con un manifiesto y algunas lecciones aprendidas, como lo son:

  • El almacenar los datos en un solo lugar.
  • Contar con solo una forma de instalar o utilizar celdas.
  • Guardar la menor cantidad de información de manera global.

Y aunque su instalación y configuración aun no se encuentran todos los pasos en la documentación oficial, podemos deducir algunos pasos escritos en la biblioteca de Nova para Devstack que son ejecutados al habilitar el servicio de “n-cell”.

local.conf

...
ENABLED_SERVICES+=,n-cell

Belmiro Moreira comparte la arquitectura utilizada por el Conseil Européen pour la Recherche Nucléaire(CERN) en su publicación “CERN Cloud Architecture”.

Cada celda contara con el servicio de nova-cell que utilizara un archivo de configuración en el cual se especificara los valores para la conexión a la Base de Datos y el Message Broker. Para poder identificar cada celda se utilizara un nombre único y el tipo de celda definira el propósito de la misma.

/etc/nova/nova-cells.conf

[DEFAULT]
transport_url = rabbit://stackrabbit:password@host:5672/child_cell
dhcpbridge_flagfile
...
[database]
connection = mysql+pymysql://root:password@host/nova_cell?charset=utf8
...
[cells]
name = child
cell_type = compute
enable = True

En el caso del servicio de nova, este solo utilizara la API como capa intermedia entre las llamadas de los clientes y las celdas.

/etc/nova/nova.conf

...
[cells]
name = region
cell_type = api
enable = True

Por ultimo es necesario crear un esquema de base de datos y establecer la comunicación con el Message Broker. Supongo el iniciar o reiniciar el servicio dependerá en gran medida de la distro que se utilice.

$ nova-manage --config-file /etc/nova/nova-cells.conf db sync
$ nova-manage --config-file $/etc/nova/nova-cells.conf cell create --name=region --cell_type=parent --username=stackrabbit --hostname=host --port=5672 --password=password --virtual_host=/ --woffset=0 --wscale=1
$ nova-manage cell create --name=child --cell_type=child --username=stackrabbit --hostname=host --port=5672 --password=password --virtual_host=child_cell --woffset=0 --wscale=1

Durante el Summit en Austin, Andrew Laski compartió los avances realizados en Celdas V2, este ha sido un esfuerzo continuo a traves de varios releases.

Leave a Reply