Separación de una nube – Regiones

Existen distintas causas por las que es necesario distribuir la información. Por ejemplo, las normativas de Privacidad y Protección de Datos en la Unión Europea impiden la apropiación, divulgación y comercialización de los datos de los clientes obligando a las organizaciones a almacenar dicha información en el lugar donde se origina. Otro ejemplo es quizá la creación de una aplicación de que sea tolerante a fallos, donde necesite replicar datos entre dos máquinas alojadas en distintas regiones.

Cualquiera que sea, se requiere que los recursos de un centro de datos puedan ser administrados de manera mas flexible sin llegar a ser demasiado determinista, esto es, ofrecer al usuario la capacidad de definir el destino donde cada recurso al ser creado.

Esta serie de artículos pretende mostrar de manera practica, las distintas maneras que OpenStack ofrece para distribuir los recursos, las cuales son:

  • Regiones(Regions)
  • Celdas(Cells)
  • Zonas de disponibilidad(Availability Zones)
  • Host agrupados(Host aggregate)

Regiones

Una región representa una instancia de OpenStack, es decir, un colección de adicional de servicios de OpenStack (Nova, Cinder, Neutron, etc.) generalmente distribuidos en otra zona geográfica. Para lograrlo es necesario realizar una serie de cambios en la configuración de la nube.

El primer cambio permite utilizar la interfaz web para acceder a una lista predefinida de regiones, esta definición solo existe dentro del contexto de la instancia de Horizon por lo que quizá pueda causar algo de confusión en su uso. Su configuración consiste en enlistar los endpoints de Keystone de cada región en una lista de tuplas en el archivo de configuración de la instancia de Horizon. Utilicemos como ejemplo la siguiente configuración:

/etc/openstack-dashboard/local_settings.py

AVAILABLE_REGIONS = [
    ('http://regionuno.ejemplo.com:5000/v2.0', 'RegionUno'),
    ('http://regiondos.ejemplo.com:5000/v2.0', 'RegionDos'),
    ('http://regiontres.ejemplo.com:5000/v2.0', 'RegionTres'),
]

Una vez aplicado el cambio y reiniciado el servicio, la pagina de inicio de sesión tendrá la opción de seleccionar la región a utilizar.

También es posible que con este cambio un usuario que este definido en RegionDos no se encuentre definido en RegionTres ya que sus instancias de Keystone no comparten la misma fuente de datos. Para ello necesitamos modificar la configuración de los servicios de Keystone para que consuma la misma fuente de datos el cual depende de el tipo de driver que utilicemos.

/etc/keystone/keystone.conf

[identity]
# Entry point for the identity backend driver in the `keystone.identity`
# namespace. Keystone provides a `sql` and `ldap` driver. This option is also
# used as the default driver selection (along with the other configuration
# variables in this section) in the event that `[identity]
# domain_specific_drivers_enabled` is enabled, but no applicable domain-
# specific configuration is defined for the domain in question. Unless your
# deployment primarily relies on `ldap` AND is not using domain-specific
# configuration, you should typically leave this set to `sql`. (string value)
driver = sql

[database]
connection = mysql+pymysql://root:[email protected]/keystone?charset=utf8

Por ultimo es necesario registrar cada servicio con su respectiva región.

...
$ openstack endpoint create --region RegionDos compute --publicurl http://regiondos.ejemplo.com:8774/v2.1 --internalurl http://regiondos.ejemplo.com:8774/v2.1 --adminurl http://regiondos.ejemplo.com:8774/v2.1
...

Horizon detectará este cambio al inicio de la sesión y desplegará esta información en el área que se muestra los distintos proyectos.

multi-region

Como resultado obtenemos una arquitectura compartida lo cual puede tener sus implicaciones a medida que la nube crezca.

Nota: Es posible modificar los valores de la region en devstack aunque he de reconocer que he tenido algunos problemas con el servicio de nova-legacy. En la documentación oficial menciona los valores a configurar en los archivos de configuración.

Devstack – RegionUno

local.conf

...
HOST_IP=10.0.0.3
REGION_NAME=RegionUno
...

Devstack – RegionDos

local.conf

...
disable_service horizon
KEYSTONE_SERVICE_HOST=10.0.0.3
KEYSTONE_AUTH_HOST=10.0.0.3
REGION_NAME=RegionDos
KEYSTONE_REGION_NAME=RegionUno