ES | EN
| Table of Contents |
|---|
Introducción
...
Multitenant es un principio de arquitectura software en la cual una sola instancia de la aplicación es capaz de servir a múltiples clientes u organizaciones (tenant o instancia).
Este modelo se diferencia de las arquitecturas con múltiples instancias donde cada organización o cliente tiene su propia instancia instalada de la aplicación ya que en una arquitectura multitenant la aplicación puede particionar virtualmente sus datos y su configuración para que cada cliente tenga una instancia virtual adaptada a sus requerimientos.
En la figura de la derecha podemos apreciar las diferencias en comparación con una arquitectura convencional de "Singletenant" o una solo tenencia. Podemos observar que en Singletenant cada cliente accede a su propia aplicación, que a su vez usa su propia base de datos, mientras que en la arquitectura Multitenant todos los clientes acceden a la misma aplicación, y esta tendrá acceso a bases de datos compartidas o exclusivas para una determinada instancia.
Soporte Multitenant en Plataforma
Onesait Platform ofrece soporte multitenant, de tal forma que en un mismo entorno con una sola instancia de plataforma, cada vertical y sus respectivos clientes tendran los datos en repositorios independientes.
En el siguiente diagrama, podemos ver un ejemplo de caso de uso de la plataforma en modo multitenant, y como quedarían almacenados los datos:
...
Como vemos, cada vertical tiene asociada una base de datos de configuración, donde se almacenan los elementos de plataforma, mientras que los datos de las ontologías (RTDB) para cada cliente se almacenan en una instancia independiente. Para nuestro ejemplo, Carrefour compartirá la misma instancia RTDB para Prosumers y motion.
Todo esto es transparente para el usuario, es decir, apenas cambia la usabilidad de plataforma, solo hay que tener en cuenta un par de puntos que comentaremos más adelante.
Configuración del entorno multitenant
Para utilizar el entorno en modo multitenant, basta con indicar la variable de entorno MULTITENANCY_ENABLED a 'true' en los módulos Controlpanel y OAuth Server:
Una vez habilitado, existe un usuario de plataforma global con rol PLATFORM_ADMIN encargado de crear los verticales.
Creación de verticales
Si entramos con el usuario platform_admin, veremos una pantalla con el listado de verticales de plataforma:
Para crear uno, vamos a create y elegimos el nombre del vertical:
...
Tenemos que copiar el nombre del esquema de base de datos de configuración, y lanzar el servicio config-init, con la variable de entorno CONFIGDB_SCHEMA con ese valor:
...
Con esto se nos cargará los datos básicos de configuración para el nuevo vertical.
Además, se creará un usuario administrador para el vertical, siguiendo el formato ‘administrator_{vertical}’, en este caso administrator_waste , con contraseña por defecto OpenP2019! y un cliente por defecto para desarrollo en el vertical, con formato development.
Con este usuario se podrán crear clientes o tenants para el vertical, así como usuarios de plataforma y asignarlos a un cliente.
Creación de Clientes o Tenants de un Vertical
Con el usuario administrador del vertical podemos crear clientes, desde la opción de menú ‘Tenant Management’, bajo el nivel de Administration:
...
Para crear uno nuevo, le damos a create y rellenamos la información:
...
Se crea un usuario developer asignado al cliente por defecto. En este caso se creará lugo_developer para el tenant smart-lugo del vertical waste.
...
Si entramos en cada cliente/tenant, podemos ver un listado de los usuarios del mismo:
...
Adición de un Cliente existente a otro vertical
Para nuestro ejemplo, el cliente Carrefour ya existe en el vertical Prosumers, por lo que si queremos que también sea un cliente de Waste, será necesario volver a hacer uso del usuario platform_admin, y dirigirnos al vertical Waste e ir a la pestaña ‘Tenants’.
Aquí le damos a ‘Add’ y añadimos Carrefour.
...
Ahora los usuarios de carrefour podrán acceder al vertical Prosumers y al de Waste.
Creación de Usuarios para un Tenant
Para crear usuarios y asociarlos a un tenant, con el administrador del vertical, el proceso es el mismo que siempre, solo que esta vez nos aparecerá una opción más al crearlo: un combo con los clientes de ese vertical.
Seleccionamos al que lo queramos asignar y lo creamos:
Es importante resaltar, que un usuario de plataforma solo puede estar asociado a un solo cliente, aunque debido a este último, pueda acceder a diferentes verticales.
Consideraciones cuando un Cliente está asociado a varios verticales
Para nuestro ejemplo, como Carrefour está asociado a Waste y Prosumers, cuando nos logamos en plataforma bien a través del Controlpanel o bien a través de Oauth2, necesitamos especificar el vertical al cual queremos acceder.
NOTA: Si accedemos con tokens de dispositivo o de API, no es necesario realizar ninguna acción adicional, porque la plataforma relaciona de manera unívoca estos tokens con: vertical, cliente y usuario.
Controlpanel
En el caso de que entremos a través del Controlpanel, después de introducir nuestra contraseña se nos asignará un rol provisional sin autorización más que para elegir el vertical al que queremos acceder, por esto nos saltará una pantalla con un combo para elegir el vertical. Lo seleccionaremos y nos logaremos:
Como os habréis fijado en capturas anteriores, cuando la plataforma opera en modo multitenant, se indica en todo momento el vertical en el que se está trabajando en la barra superior a la derecha:
...
Oauth 2.0
Para Oauth 2, será necesario especificar un parámetro adicional “vertical”, con el nombre del vertical al que queremos tener acceso. Si no lo especificamos y nuestro usuario está asociado a varios verticales, se nos dará un token con rol provisional, que no tendrá ningún nivel de autorización para operar con él.
...
Sin embargo, si añadimos el vertical, nos asignará el rol correcto:
Nueva instalación con versión 1.6.0-Empire o superior
Cuando se realice una instalación nueva, sin datos en la ConfigDB, habrá que indicar la variable de entorno UPDATE_MODE_MULTITENANT a false. Si esta variable no se pone a false, aparecerán mensajes de warning.
Esta variable está pensada para hacer upgrade de entornos que ya tengan datos, para que los datos existentes se migren a la base de datos maestra (usuarios, tokens…).
Actualización a versión 1.6.0-Empire o superior
Si se actualiza un entorno a esta versión, no hará falta especificar nadaCon el modelo SaaS este modelo de arquitectura es cada ve más importante porque nos permite optimizar recursos.
Cada cliente del servicio es considerado como un tenant, esto permite que se pueda personalizar elementos de la aplicación, como son colores de la interfaz, pero no se personaliza el código como tal.
Algo importante en esta arquitectura es que un cliente no necesariamente es un usuario único, puede ser un grupo de usuarios.
Ventajas y desventajas de un multitenant
Ventajas.
Reducción en costes de infraestructura y mantenimiento ya que los costes son distribuidos entre todos los clientes.
Fácil actualización, ya que es necesario actualizar una sola instancia.
Seguridad de la información de cada cliente, ya que cuenta con un schema separado para cada uno.
Optimiza el uso de recursos de los servidores.
Desventajas
Dificulta el desarrollo de características específicas para un cliente.
Único punto de error: si la aplicación tiene un error o falla, fallará para todos los clientes.
Soporte Multitenant en Plataforma
La funcionalidad Multitenant en Plataforma se soporta sobre 2 conceptos:
Vertical: representa un producto y proyecto concreto. Supongamos el despliegue de Plataforma sobre una organización que ofrece productos en modo SaaS, en ese caso podríamos tener diferentes verticales desplegados sobre una instancia, por ejemplo Vertical Smart Home, Vertical Waste Management,…
Tenant: representa a un cliente a la que la organización sirve sus productos, por ejemplo podríamos ofrecer la solución Smart Home a Carrefour, Leroy Merlin,…
Con el soporte de Onesait Platform con una sola instancia de plataforma podríamos servir a varios verticales y tenants.
Las capacidades de plataforma en cuanto al modo multitenant se reflejan así:
Cada Vertical tiene su propia ConfigDB, o dicho de otra forma, cada Vertical puede crear sus propios conceptos de plataforma de forma independiente al resto, esto es sus ontologías, APIs, DataFlows, microservicios, dashboards,…
Cada Tenant tiene su propia RealTimeDB: de modo que los datos de cada tenant se almacenan de forma independiente y no se mezclan.
Los usuarios son generales a toda la instancia de plataforma y se pueden asociar a vertiales y tenants.
Todo esto es transparente para el usuario, es decir, apenas cambia la usabilidad de plataforma, solo hay que tener en cuenta un par de puntos que comentaremos más adelante.