Arquitecturas Multi-Tenant

Las arquitecturas multi-tenant (multi-propietario) son cada vez más utilizadas entre los proveedores de SaaS (Software as a Service). En un entorno multi-tenant, todos los clientes y sus usuarios consumen el servicio desde la misma plataforma tecnológica, el intercambio de todos los componentes de la tecnología incluyendo el modelo de datos, servidores  y las capas de base de datos.

Las arquitecturas Multi-Tenant se refiere a un principio en la arquitectura de software donde una única instancia del software se ejecuta en un servidor y al servicio a múltiples clientes (los arrendatarios).

Multi-Tenant contrasta con una arquitectura multi-instancia en la cual son instancias independientes de software (o sistemas de hardware) que establecen para las organización de distintos clientes.  Con una arquitectura multi-tenant, una aplicación de software está diseñada para la  partición sus datos y la configuración de manera que cada cliente trabaja con una instancia de la aplicación virtual personalizada

Este tipo de arquitecturas se denominan multi-tenant o multipropietario, en las que sobre un único recurso operan múltiples usuarios que son dueños, por así decirlo, del mismo.

tenant11

Enfoques De La Gestión De Datos Multi-Tenant

 

1. Bases De Datos Por Separado

En esta arquitectura los datos de cada cliente  se almacenan en bases de datos separadas.  Las bases de datos  pueden estar en el mismo servidor o pueden ser divididas a través de servidores de bases de datos múltiples.  Este enfoque proporciona aislamiento máximo de datos de clientes.

tenant2
Figura 1.  Este enfoque utiliza una base de datos diferente para cada Cliente

Recursos informáticos y código de aplicación generalmente son compartidos entre todos los Clientes en un servidor, pero cada Cliente tiene su propio conjunto de datos que sigue siendo lógicamente aislada a partir de datos que pertenece a todos los otros Clientes.  Metadatos asociados a cada base de datos con el cliente rrecto, y la seguridad de base de datos impide cualquier cliente de forma accidental o malintencionada acceder a los datos a otros Clientes.

Dar a cada Cliente su propia base de datos hace que sea fácil de extender la aplicación del modelo de datos para satisfacer las necesidades de los clientes individuales, y la restauración de datos de un cliente de copias de seguridad en caso de un fracaso es un procedimiento relativamente simple.  Por desgracia, este enfoque tiende a conducir a mayores costos de mantenimiento del equipo y realizar copias de seguridad de clientes.  Los costos de hardware son también más altos ya que están bajo distintos criterios, como el número de clientes que pueden ser alojados en un servidor de base de datos.

Consideraciones:

  • El tiempo de desarrollo – El modelo de servidor independiente requiere más tiempo de desarrollo mínimo en comparación con una solución de arquitectura estándar.
  • Costos de hardware – Esta es la arquitectura más cara, ya que cada cliente requiere su propio servidor de hardware.  Además, cualquier prueba de ejecución a lo largo se sumará al costo.
  • Aplicación y el rendimiento de base de datos – Esta arquitectura tiene el rendimiento más predecible, porque el rendimiento de un cliente  no se ve afectada por cualquier otro cliente.
  • Seguridad – Debido al total aislamiento de otros clientes, los datos de cada cliente pueden ser muy bien resguardados
  • Requisitos de personalización – Cada cliente tiene su propia base de datos, por lo que es más fácil de personalizar.
  • El número de clientes – Este enfoque hace que sea mucho más difícil de manejar un gran número de clientes.

 

2. Bases De Datos Compartidas, Esquemas Separados

Este  enfoque consiste en arrendatarios de viviendas múltiples en la misma base de datos, con cada cliente que tiene su propio conjunto de tablas que se agrupan en un esquema creado específicamente para el cliente. Con este enfoque puede tener una sola base de datos con un esquema para cada cliente.

tenant31
Figura 2.  En este enfoque cada cliente tiene su propio conjunto de  tablas separadas  de una base de datos común

Consideraciones del enfoque:

  • Aplicación y el rendimiento de base de datos – El rendimiento de un cliente puede verse afectada por las actividades de los clientes que comparten el servidor.
  • Seguridad – El DBMS debe asegurar que su estructura de permisos es tal que cada cliente de datos sólo está disponible para usuarios autorizados.  Además, la aplicación debe hacer uso de cualquiera de los comandos para seleccionar o restringir el esquema que se accede por un usuario.
  • Requisitos de personalización – Cada cliente tiene su propio esquema, así que es fácil de personalizar para las diferentes necesidades de cada cliente.
  • El número de clientes – Este modelo es capaz de manejar más clientes que los modelos de bases de datos separadas, pero todavía requieren una cierta cantidad de la administración.  La migración de los clientes a una base de datos independiente puede ser un desafío en función de las utilidades que se ofrecen por el DBMS.

 

3. Base de datos compartidas, esquemas compartidos

Aquí sólo tenemos una única base de datos y un esquema único. Cada Tabla debe de referirse a un id de cliente

tenant4

En este enfoque, todos los clientes comparten el mismo conjunto de tablas, y un ID de cada cliente asociados con los registros de su propiedad

De los tres enfoques que se explican el enfoque del esquema compartido, tiene los más bajos costos de hardware y de copia de seguridad, ya que le permite servir al mayor número de clientes por base de datos del servidor.  Sin embargo, debido a múltiples clientes comparten la misma base de datos las tablas, este enfoque puede incurrir en esfuerzo de desarrollo adicional en el ámbito de la seguridad, para garantizar que los clientes no pueden acceder a los datos de otros clientes, incluso en caso de errores inesperados o ataques.

El procedimiento para restaurar los datos de un cliente es similar a la del enfoque común de esquema, con la complicación adicional de que las filas individuales en la base de datos de producción se debe eliminar y luego reinsertados de la base de datos temporal.  Si hay un número muy grande de filas en las tablas afectadas, esto puede afectar el rendimiento notablemente para todos los clientes que utilizan la base de datos.

El enfoque de esquema compartido  es apropiado cuando es importante que la solicitud sea capaz de servir a un gran número de clientes con un pequeño número de servidores y clientes potenciales están dispuestos a entregar los datos de aislamiento a cambio de los costos más bajos que este enfoque permite.

Consideraciones:

  • Aplicación  y rendimiento de la base de datos- El rendimiento de un cliente puede verse afectada por las actividades de los otros clientes. El  rendimiento de las consultas tendrán que ser examinados cuidadosamente para garantizar los índices adecuados existen.
  • Seguridad- La aplicación debe utilizar código de consultas especialmente para seleccionar o restringir los datos basado en el cliente.  Pruebas sólidas deben utilizarse para garantizar que un usuario no es capaz de ver los datos de los otros clientes.  Encriptación de datos únicos para cada cliente no es posible.
  • Requisitos de personalización-Todos los clientes comparten el esquema, por lo que es mucho más difícil  permitir la individualización.  Hay una variedad de enfoques que se pueden utilizar para proporcionar personalización.  El planteamiento es permitir a un número de columnas en cada tabla genérica que se puede utilizar de diferentes maneras por cada cliente.
  • El número de Clientes- Este modelo es capaz de manejar más muchos clientes que los modelos anteriores.  La migración de los clientes que requieren un mejor rendimiento o la capacidad puede ser un reto, ya que los datos tendrán que ser extraídos de cada caso en operaciones separadas

Referencias:

http://is3ados.blogspot.com/2008_11_01_archive.html
http://en.wikipedia.org/wiki/Multitenancy
http://msdn.microsoft.com/en-us/library/aa479086.aspx
http://iablog.sybase.com/kleisath/index.php/category/database-architecture/

Visto: 53,791 veces

4 comentarios en “Arquitecturas Multi-Tenant

Deja un comentario