A menudo, los datos se consideran la parte más valiosa de una solución, ya que representan información empresarial valiosa tanto suya como de sus clientes. Por lo tanto, es importante administrar cuidadosamente los datos. Al planificar los componentes de almacenamiento o de datos para un sistema multiinquilino, debe decidir un enfoque para compartir o aislar los datos de los inquilinos.
En este artículo, encontrará una guía sobre las consideraciones clave y los requisitos que son esenciales para los arquitectos de soluciones cuando deben decidir un enfoque para almacenar datos en un sistema multiinquilino. A continuación, se sugieren algunos patrones comunes para aplicar el multiinquilinato a los servicios de almacenamiento y datos, y algunos antipatrones que se deben evitar. Por último, encontrará una guía destinada a algunas situaciones específicas.
Consideraciones clave y requisitos
Es importante tener en cuenta los enfoques que se usan para los servicios de almacenamiento y datos a partir de una serie de perspectivas, que se alinean aproximadamente con los pilares del Marco de buena arquitectura de Azure.
Escala
Al trabajar con servicios que almacenan datos, debe tener en cuenta el número de inquilinos que tiene y el volumen de datos que almacena. Si tiene un número pequeño de inquilinos (por ejemplo, cinco o menos) y almacena pequeñas cantidades de datos para cada inquilino, es probable que sea un desperdicio planear un enfoque de almacenamiento de datos altamente escalable o crear un enfoque totalmente automatizado para administrar los recursos de datos. No obstante, a medida que crece, se beneficia cada vez más de tener una estrategia clara para escalar los datos y los recursos de almacenamiento, y para aplicar la automatización a su administración. Cuando tiene 50 inquilinos o más, o si tiene previsto alcanzar ese nivel de escala, es muy importante diseñar el enfoque de almacenamiento y datos teniendo la escala como consideración clave.
Tenga en cuenta la medida en que planea escalar, y planee claramente el enfoque arquitectónico del almacenamiento de datos para satisfacer ese nivel de escala.
Predictibilidad del rendimiento
Los servicios de almacenamiento y datos de varios inquilinos son especialmente susceptibles al problema del vecino ruidoso. Es importante tener en cuenta si es posible que sus inquilinos afecten al rendimiento de los demás. Por ejemplo, ¿los picos en los patrones de uso de los inquilinos se superponen a lo largo del tiempo? ¿Todos los clientes usan la solución a la misma hora cada día, o las solicitudes se distribuyen de manera uniforme? Estos factores afectarán al nivel de aislamiento que tiene que diseñar, a la cantidad de recursos que tiene que aprovisionar y al grado en que los recursos se pueden compartir entre inquilinos.
Es importante tener en cuenta las cuotas de recursos y solicitudes de Azure como parte de esta decisión. Por ejemplo, supongamos que implementa una única cuenta de almacenamiento para contener todos los datos de los inquilinos. Si supera un número específico de operaciones de almacenamiento por segundo, Azure Storage rechazará las solicitudes de la aplicación, y todos los inquilinos se verán afectados. Esto se denomina comportamiento de limitación. Es importante supervisar las solicitudes limitadas. Para más información, consulte la Guía de reintentos para servicios de Azure.
Aislamiento de datos
Al diseñar una solución que contenga servicios de datos de varios inquilinos, normalmente hay diferentes opciones y niveles de aislamiento de datos, cada uno con sus propias ventajas y ventajas. Por ejemplo:
- Al usar Azure Cosmos DB, puede implementar contenedores independientes para cada inquilino, y compartir bases de datos y cuentas entre varios inquilinos. Como alternativa, puede considerar la posibilidad de implementar bases de datos diferentes o incluso cuentas para cada inquilino, en función del nivel de aislamiento necesario.
- Al usar Azure Storage para los datos de blobs, puede implementar contenedores de blobs independientes para cada inquilino, o puede implementar cuentas de almacenamiento independientes.
- Al usar Azure SQL, puede usar tablas independientes en bases de datos compartidas, o bien puede implementar bases de datos o servidores independientes para cada inquilino.
- En todos los servicios de Azure, puede considerar la posibilidad de implementar recursos dentro de una única suscripción compartida a Azure, o bien puede usar varias suscripciones a Azure, quizás incluso una por inquilino.
No hay ninguna solución única que funcione para toda situación. La opción que elija dependerá de una serie de factores y de los requisitos de los inquilinos. Por ejemplo, si los inquilinos tienen que cumplir estándares normativos o de cumplimiento específicos, es posible que tenga que aplicar un mayor nivel de aislamiento. Del mismo modo, es posible que tenga requisitos comerciales para aislar físicamente los datos de los clientes, o que tenga que aplicar aislamiento para evitar el problema del vecino ruidoso. Además, si los inquilinos tienen que usar sus propias claves de cifrado, tienen directivas de copia de seguridad y restauración individuales, o necesitan que sus datos se almacenen en distintas ubicaciones geográficas, es posible que tenga que aislarlos de otros inquilinos o agruparlos con inquilinos que tengan directivas similares.
Complejidad de la implementación
Es importante tener en cuenta la complejidad de la implementación. Como procedimiento recomendado, la arquitectura debe ser lo más sencilla posible, siempre que se cumplen sus requisitos. Evite embarcarse en una arquitectura que se vuelva cada vez más compleja a medida que escale, o bien una arquitectura que no tenga los recursos ni la experiencia necesarios para desarrollar y mantener.
De manera similar, si la solución no necesita escalarse a un gran número de inquilinos, o si no tiene problemas con el rendimiento ni el aislamiento de datos, es mejor mantener la sencillez de la solución y evitar agregar complejidad innecesaria.
Una inquietud particular relacionada con las soluciones de datos de varios inquilinos es el nivel de personalización que se admite. Por ejemplo, ¿puede un inquilino ampliar el modelo de datos o aplicar reglas de datos personalizadas? Asegúrese de diseñar con base en este requisito por adelantado. Evite bifurcar o proporcionar una infraestructura personalizada para inquilinos individuales. Una infraestructura personalizada le impide la capacidad de escalar, probar la solución e implementar actualizaciones. En su lugar, considere la posibilidad de usar marcas de características y otras formas de configuración de inquilinos.
Complejidad de la administración y las operaciones
Tenga en cuenta cómo planear la operación de la solución y cómo el enfoque de multiinquilinato afecta a sus operaciones y procesos. Por ejemplo:
- Administración: considere las operaciones de administración entre inquilinos, como las actividades de mantenimiento normales. Si usa varias cuentas, servidores o bases de datos, ¿cómo iniciará y supervisará las operaciones de cada inquilino?
- Supervisión y medición: si supervisa o mide los inquilinos, tenga en cuenta de qué manera la solución informa de las métricas, y si se pueden vincular fácilmente al inquilino que desencadenó la solicitud.
- Generación de informes: la generación de informes de datos entre inquilinos aislados puede exigir que cada inquilino publique datos en un almacenamiento de datos centralizado, en lugar de ejecutar consultas en cada base de datos individualmente y, a continuación, agregar los resultados.
- Actualizaciones del esquema: si usa una base de datos que aplica un esquema, planifique cómo implementará las actualizaciones del esquema en toda la infraestructura. Tenga en cuenta de qué manera la aplicación sabe qué versión de esquema usar para las consultas a las base de datos de un inquilino específico.
- Requisitos: tenga en cuenta los requisitos de alta disponibilidad de los inquilinos (por ejemplo, contratos de nivel de servicio, o SLA, de tiempo de actividad) y los requisitos de recuperación ante desastres (por ejemplo, objetivos de tiempo de recuperación, o RTO, y objetivos de punto de recuperación, o RPO). Si los inquilinos tienen expectativas diferentes, ¿podrá cumplir los requisitos de cada inquilino?
- Migración: ¿cómo migrará los inquilinos si tienen que moverse a un tipo de servicio diferente, a una implementación diferente o a otra región?
Coste
Por lo general, cuanto mayor sea la densidad de los inquilinos en la infraestructura de implementación, menor será el costo de aprovisionar esa infraestructura. Sin embargo, la infraestructura compartida aumenta la probabilidad de errores, como el problema del vecino ruidoso, así que analice atentamente las ventajas y desventajas.
Enfoques y patrones que se deben tener en cuenta
Varios patrones de diseño del Centro de arquitectura de Azure son pertinentes para los servicios de almacenamiento y datos de varios inquilinos. Puede optar por seguir un patrón de manera coherente. O bien, podría considerar la posibilidad de combinar y asociar patrones. Por ejemplo, puede usar una base de datos multiinquilino para la mayoría de los inquilinos, pero implementar stamps de inquilino único para aquellos que pagan más o que tienen requisitos poco comunes. De manera similar, suele ser un procedimiento recomendado escalar mediante stamps de implementación, incluso cuando se usa una base de datos de varios inquilinos o bases de datos particionadas dentro de un stamp.
Patrón de stamps de implementación
Para obtener más información sobre cómo se puede usar el patrón de stamps de implementación para admitir una solución multiinquilino, consulte Información general.
Bases de datos y almacenes de archivos multiinquilino compartidos
Considere la posibilidad de implementar una base de datos multiinquilino compartida, una cuenta de almacenamiento o un recurso compartido de archivos, y compartirlos entre todos los inquilinos.
Este enfoque proporciona la mayor densidad de inquilinos para la infraestructura, por lo que tiende a tener el menor costo entre todos los enfoques. También suele reducir la sobrecarga de administración, ya que hay una base de datos o un recurso únicos para administrar, hacer una copia de seguridad y proteger.
Sin embargo, cuando se trabaja con una infraestructura compartida, hay varias advertencias que se deben tener en cuenta:
- Límites de escalado: cuando se basa en un único recurso, tenga en cuenta el escalado y los límites admitidos de ese recurso. Por ejemplo, el tamaño máximo de una base de datos o un almacén de archivos, o los límites máximos de rendimiento, se volverán obstáculos difíciles, si la arquitectura se basa en una base de datos única. Considere detenidamente la escala máxima que necesita lograr y compárela con los límites actuales y futuros antes de seleccionar este patrón.
- Vecinos ruidosos: el problema de vecino ruidoso puede entrar en juego, en especial si tiene inquilinos que están muy ocupados o generan cargas de trabajo más altas que otros inquilinos. Considere la posibilidad de aplicar el patrón de limitación o el patrón de limitación de velocidad para mitigar estos efectos.
- Supervisión de cada inquilino: es posible que tenga dificultades para supervisar la actividad y medir el consumo de un solo inquilino. Algunos servicios, como Azure Cosmos DB, brindan informes sobre el uso de recursos para cada solicitud, por lo que se puede realizar un seguimiento de esta información para medir el consumo de cada inquilino. Otros servicios no proporcionan el mismo nivel de detalle. Por ejemplo, las métricas de Azure Files para la capacidad de archivo están disponibles por dimensión de recurso compartido de archivos, solo cuando se usan recursos compartidos prémium. Sin embargo, el nivel estándar proporciona las métricas solo a nivel de cuenta de almacenamiento.
- Requisitos de los inquilinos: los inquilinos pueden tener diferentes requisitos de seguridad, copia de seguridad, disponibilidad o ubicación de almacenamiento. Si no coinciden con la configuración del recurso único, es posible que no pueda darles cabida.
- Personalización del esquema: al trabajar con una base de datos relacional u otra situación en la que el esquema de los datos es importante, la personalización del esquema de nivel de inquilino es difícil.
Patrón de particionamiento
El patrón de particionamiento implica la implementación de varias bases de datos independientes, denominadas particiones, que contienen los datos de uno o varios inquilinos. A diferencia de los stamps de implementación, las particiones no implican que toda la infraestructura esté duplicada. Puede particionar bases de datos sin duplicar ni particionar otras infraestructuras de la solución.
El particionamiento está estrechamente relacionado con la creación de particiones, y los términos se suelen usar indistintamente. Analice la guía para la creación de particiones de datos horizontales, verticales y funcionales.
El patrón de particionamiento se puede escalar a un gran número de inquilinos. Además, según la carga de trabajo, es posible que pueda lograr una alta densidad de inquilinos por particiones, por lo que el costo puede ser atractivo. El patrón de particionamiento también se puede usar para abordar las cuotas, los límites y las restricciones de suscripción y servicio de Azure.
Algunos almacenes de datos, como Azure Cosmos DB, ofrecen compatibilidad nativa para particionamiento o creación de particiones. Al trabajar con otras soluciones, como Azure SQL, puede ser más complejo crear una infraestructura de particionamiento y enrutar las solicitudes a la partición correcta para un inquilino determinado.
El particionamiento también dificulta la compatibilidad con las diferencias de configuración de nivel de inquilino y la capacidad de los clientes de proporcionar sus propias claves de cifrado.
Aplicación multiinquilino con bases de datos dedicadas para cada inquilino
Otro enfoque común es implementar una única aplicación multiinquilino, con bases de datos dedicadas para cada inquilino.
En este modelo, los datos de cada inquilino están aislados de los demás, y es posible que pueda admitir algún grado de personalización para cada inquilino.
Dado que los recursos de datos dedicados se aprovisionan para cada inquilino, el costo de este enfoque puede ser mayor que los modelos de hospedaje compartido. Sin embargo, Azure brinda varias opciones que puede tener en cuenta para compartir el costo de hospedar recursos de datos individuales entre varios inquilinos. Por ejemplo, al trabajar con Azure SQL, puede considerar los grupos elásticos. Para Azure Cosmos DB, puede aprovisionar el rendimiento de una base de datos y el rendimiento se comparte entre los contenedores de esa base de datos, aunque este enfoque no es adecuado cuando se necesita un rendimiento garantizado para cada contenedor.
En este enfoque, como solo los componentes de datos se implementan individualmente para cada inquilino, es probable que pueda lograr una alta densidad para los demás componentes de la solución y reducir su costo.
Es importante usar enfoques de implementación automatizados al aprovisionar bases de datos para cada inquilino.
Patrón de nodo geográfico
El patrón de nodo geográfico está diseñado específicamente para soluciones distribuidas geográficamente, incluidas las soluciones de multiinquilino. Admite una alta carga y altos niveles de resistencia. Si implementa el patrón de nodo geográfico, la capa de datos debe ser capaz de replicar los datos entre regiones geográficas y debe admitir escrituras en varias zonas geográficas.
Azure Cosmos DB proporciona escrituras de arquitectura multimaestro para admitir este patrón, y Cassandra admite clústeres de varias regiones. Por lo general, otros servicios de datos no pueden admitir este patrón sin una personalización significativa.
Antipatrones que se deben evitar
Al crear servicios de datos multiinquilino, es importante evitar situaciones que impidan su capacidad de escalado.
En el caso de las bases de datos relacionales, se incluye:
- Aislamiento basado en tablas. Al trabajar en una base de datos única, evite crear tablas individuales para cada inquilino. Una base de datos única no podrá admitir un gran número de inquilinos cuando use este enfoque, y cada vez se vuelve más difícil consultar, administrar y actualizar los datos. En su lugar, considere la posibilidad de usar un único conjunto de tablas multiinquilino con una columna de identificador de inquilino. Como alternativa, puede usar uno de los patrones descritos anteriormente para implementar bases de datos independientes para cada inquilino.
- Personalización del inquilino a nivel de columna. Evite aplicar actualizaciones de esquema que solo se apliquen a un único inquilino. Por ejemplo, suponga que tiene una sola base de datos multiinquilino, evite agregar una nueva columna para satisfacer los requisitos de un inquilino específico. Puede ser aceptable para un número reducido de personalizaciones, pero esto se vuelve rápidamente inmanejable cuando se tiene que tener en cuenta un gran número de personalizaciones. En su lugar, considere la posibilidad de revisar el modelo de datos para realizar un seguimiento de los datos personalizados de cada inquilino en una tabla dedicada.
- Cambios manuales en el esquema. Evite actualizar el esquema de la base de datos manualmente, incluso si solo tiene una única base de datos compartida. Es fácil perder de vista las actualizaciones que ha aplicado y, si necesita escalar horizontalmente a más bases de datos, es difícil identificar el esquema correcto que se debe aplicar. En su lugar, cree una canalización automatizada para implementar los cambios de esquema y úsela de manera coherente. Haga un seguimiento de la versión de esquema usada para cada inquilino en una base de datos dedicada o una tabla de búsqueda.
- Dependencias de versiones. Evite que la aplicación tome una dependencia en una sola versión del esquema de la base de datos. A medida que escale, es posible que tenga que aplicar actualizaciones de esquema en momentos diferentes para distintos inquilinos. En su lugar, asegúrese de que la versión de la aplicación sea compatible con versiones anteriores con al menos una versión de esquema y evite actualizaciones de esquema destructivas.
Bases de datos
Hay algunas características que pueden ser útiles para el multiinquilinato. Sin embargo, no están disponibles en todos los servicios de base de datos. Tenga en cuenta si los necesita cuando decida el servicio que va a usar para su escenario:
- La seguridad a nivel de fila puede ofrecer aislamiento de seguridad para los datos de inquilinos específicos en una base de datos multiinquilino compartida. Esta característica está disponible en Azure SQL y Postgres Flex, pero no está disponible en otras bases de datos, como MySQL o Azure Cosmos DB.
- El cifrado a nivel de inquilino puede ser necesario para admitir los inquilinos que proporcionan sus propias claves de cifrado para sus datos. Esta característica está disponible en Azure SQL como parte de Always Encrypted. Azure Cosmos DB ofrece claves administradas por el cliente a nivel de cuenta y también admite Always Encrypted.
- La agrupación de recursos ofrece la capacidad de compartir recursos y costos entre varias bases de datos o contenedores. Esta característica está disponible en los grupos elásticos y las instancias administradas de Azure SQL, y en el rendimiento de bases de datos de Azure Cosmos DB, aunque cada opción tiene limitaciones que debe conocer.
- El particionamiento y la creación de particiones tienen más compatibilidad nativa en algunos servicios que otros. Esta característica está disponible en Azure Cosmos DB, mediante su partición lógica y física, y en Hiperescala de PostgreSQL. Aunque Azure SQL no admite el particionamiento de forma nativa, brinda herramientas de particionamiento para admitir este tipo de arquitectura.
Además, al trabajar con bases de datos relacionales u otras bases de datos basadas en esquemas, tenga en cuenta dónde se debe desencadenar el proceso de actualización del esquema al mantener una flota de bases de datos. En un pequeño patrimonio de bases de datos, podría considerar la posibilidad de usar una canalización de implementación para implementar los cambios de esquema. A medida que crece, puede ser mejor que el nivel de aplicación detecte la versión del esquema de una base de datos específica e inicie el proceso de actualización.
Almacenamiento de archivos y blobs
Tenga en cuenta el enfoque que usa para aislar los datos dentro de una cuenta de almacenamiento. Por ejemplo, puede implementar cuentas de almacenamiento independientes para cada inquilino, o compartir cuentas de almacenamiento e implementar contenedores individuales. Como alternativa, puede crear contenedores de blobs compartidos y, luego, puede usar la ruta de acceso del blob para separar los datos de cada inquilino. Tenga en cuenta los límites y cuotas de la suscripción a Azure y planee con cuidado su crecimiento para asegurarse de que los recursos de Azure se escalen para satisfacer sus necesidades futuras.
Si usa contenedores compartidos, planee con cuidado la estrategia de autenticación y autorización para asegurarse de que los inquilinos no puedan acceder a los datos de los demás. Estudie el patrón de clave de acceso limitado cuando proporcione a los clientes acceso a recursos de Azure Storage.
Asignación de costos
Tenga en cuenta cómo medirá el consumo y asignará costos a los inquilinos para el uso de servicios de datos compartidos. Siempre que sea posible, utilice métricas integradas en lugar de calcular las propias. Sin embargo, con una infraestructura compartida, resulta difícil dividir los datos de telemetría para inquilinos individuales y debe considerar la posibilidad de utilizar la medición personalizada de nivel de aplicación.
En general, los servicios nativos de nube, como Azure Cosmos DB y Azure Blob Storage, proporcionan métricas más granulares para hacer un seguimiento y modelar el uso de un inquilino específico. Por ejemplo, Azure Cosmos DB ofrece el rendimiento consumido para cada solicitud y respuesta.
Colaboradores
Microsoft mantiene este artículo. Originalmente lo escribieron los siguientes colaboradores.
Autor principal:
- John Downs | Ingeniero de clientes principal, FastTrack for Azure
Otros colaboradores:
- Paul Burpo | Principal Customer Engineer, FastTrack for Azure
- Daniel Scott-Raynsford | Partner Technology Strategist
- Arsen Vladimirskiy | Principal Customer Engineer, FastTrack for Azure
Para ver los perfiles no públicos de LinkedIn, inicie sesión en LinkedIn.
Pasos siguientes
Para obtener más información sobre el multiinquilinato y servicios específicos de Azure,vea: