Nota:
El acceso a esta página requiere autorización. Puede intentar iniciar sesión o cambiar directorios.
El acceso a esta página requiere autorización. Puede intentar cambiar los directorios.
Azure Storage es un servicio fundamental que casi todas las soluciones usan. Las soluciones multicliente suelen usar almacenamiento para blobs, archivos, colas y almacenamiento de tablas. En este artículo se describen las características de Storage para soluciones multiinquilino. Proporciona vínculos a instrucciones que pueden ayudarle a planear cómo usar Storage.
Características de almacenamiento que admiten multitenencia
Azure Storage incluye muchas características que admiten el multiinquilinato.
Firmas de acceso compartido
Cuando use Storage desde una aplicación cliente, considere si debe enrutar las solicitudes del cliente a través de otro componente que usted controla, como una red de entrega de contenido o una API. O bien, puede permitir que los clientes se conecten directamente a la cuenta de almacenamiento. El envío de solicitudes a través de otro componente puede proporcionar ventajas como el almacenamiento en caché de datos en el perímetro de la red.
El acceso directo de cliente a Storage para descargar o cargar datos puede mejorar el rendimiento, especialmente para blobs grandes o muchos archivos. También reduce la carga en las aplicaciones y servidores back-end y reduce el número de saltos de red.
Una firma de acceso compartido (SAS) le permite proporcionar de forma segura a las aplicaciones cliente acceso a objetos de Storage.
Puede usar una SAS para restringir el ámbito de las operaciones que un cliente puede realizar y los objetos con los que pueden realizar operaciones. Por ejemplo, si tiene una cuenta de almacenamiento compartida para todos los inquilinos y almacena los datos del inquilino A en un contenedor de blobs denominado tenanta, puede crear una SAS que permita que solo los usuarios del inquilino A accedan a ese contenedor. Para más información sobre los enfoques que aíslan los datos de los inquilinos en una cuenta de almacenamiento, consulte Modelos de aislamiento.
Use el patrón de clave de acceso limitado para emitir tokens SAS restringidos y con ámbito desde la capa de aplicación. Por ejemplo, si la aplicación multiinquilino permite a los usuarios cargar vídeos, la API o el nivel de aplicación pueden autenticar el cliente mediante el sistema de autenticación de la aplicación. A continuación, puede proporcionar una SAS que permita al cliente cargar un archivo de vídeo en una ruta de blob específica dentro de un contenedor designado. A continuación, el cliente carga el archivo directamente en la cuenta de almacenamiento, lo que reduce el ancho de banda y la carga en la API. Si el cliente intenta leer datos del contenedor de blobs o escribir datos en otro contenedor de la cuenta de almacenamiento, Storage bloquea la solicitud. La SAS expira después de un período de tiempo configurable.
Las directivas de acceso almacenadas amplían la funcionalidad de SAS, lo que le permite definir una sola directiva que se usará al emitir varias firmas.
Control de acceso basado en identidades
Azure Storage también proporciona control de acceso basado en identidad a través de Microsoft Entra ID. Esta funcionalidad habilita el control de acceso basado en atributos, que proporciona acceso específico a rutas de acceso de blobs o a blobs etiquetados con un identificador de inquilino específico.
Administración del ciclo de vida
Cuando se usa Blob Storage en una solución multiinquilino, los inquilinos pueden requerir directivas diferentes para la retención de datos. Al almacenar grandes volúmenes de datos, también podría querer mover automáticamente los datos específicos del cliente a los niveles de almacenamiento frío o de archivo para optimizar los costos.
Use directivas de administración del ciclo de vida para establecer el ciclo de vida de los blobs para todos los inquilinos o para un subconjunto de inquilinos. Puede aplicar una directiva de administración del ciclo de vida a contenedores de blobs o un subconjunto de blobs dentro de un contenedor. Pero las directivas de administración del ciclo de vida tienen límites en el número de reglas que puede especificar. Planee y pruebe cuidadosamente la configuración en un entorno multiinquilino. Considere la posibilidad de implementar varias cuentas de almacenamiento si el recuento de reglas supera los límites.
Almacenamiento inmutable
Al configurar el almacenamiento de blobs inmutable en contenedores de almacenamiento mediante directivas de retención basadas en tiempo, Storage evita la eliminación o modificación de los datos antes de un tiempo especificado. Esta implementación se lleva a cabo en la capa de la cuenta de almacenamiento y se aplica a todos los usuarios, incluidos los administradores de su organización.
Use almacenamiento inmutable si los inquilinos deben mantener datos o registros debido a los requisitos legales o de cumplimiento. Evalúe cómo se ajusta esta característica al ciclo de vida del inquilino. Por ejemplo, si un inquilino está desactivado y solicita la eliminación de datos, es posible que no pueda cumplir su solicitud. Si usa almacenamiento inmutable para los datos de inquilino, considere cómo solucionar este problema en sus términos de servicio.
Copia del lado servidor
En un sistema multiinquilino, es posible que tenga que mover datos de una cuenta de almacenamiento a otra. Por ejemplo, si mueve un inquilino entre stamps de implementación o reequilibra un conjunto particionado de cuentas de almacenamiento, debe copiar o mover los datos de un inquilino específico. Cuando tenga grandes volúmenes de datos, use las API de copia del lado servidor para reducir el tiempo de migración.
La herramienta AzCopy es una aplicación que puede ejecutar desde el equipo o una máquina virtual para administrar el proceso de copia. AzCopy es compatible con la funcionalidad de copia del lado del servidor y proporciona una interfaz de línea de comandos que puedes ejecutar desde tus soluciones. También puede usar AzCopy para cargar y descargar grandes volúmenes de datos.
Si necesita usar las API de copia del lado servidor directamente desde el código, considere la posibilidad de usar las siguientes opciones:
- Colocar Bloque Desde URL API
- Colocar Página Desde URL API
- API de anexar bloques desde la URL
- Copy Blob From URL API for smaller blobs (Copia de Blob from URL API para blobs más pequeños)
Replicación de objetos
La replicación de objetos es una característica que replica automáticamente y de forma asincrónica los datos entre una cuenta de almacenamiento de origen y de destino. En una solución multiinquilino, use esta característica para replicar continuamente los datos entre instancias de implementación o al implementar el patrón Geode.
Encriptación
Azure Storage permite proporcionar claves de cifrado para los datos. En una solución multiinquilino, considere la posibilidad de combinar esta funcionalidad con ámbitos de cifrado. Puede asignar claves de cifrado diferentes a distintos inquilinos, incluso cuando sus datos residen en la misma cuenta de almacenamiento. Estas características permiten a los inquilinos controlar sus propios datos. Si desactivan su cuenta, eliminar la clave de cifrado garantiza que nadie pueda acceder a sus datos.
Monitorización
En una solución multiinquilino, considere si necesita medir el consumo de cada inquilino. Defina las métricas específicas para realizar el seguimiento, como la capacidad de almacenamiento que usa cada inquilino o el número de operaciones realizadas para los datos de cada inquilino. También puede usar la asignación de costos para realizar un seguimiento del costo del uso de cada inquilino y habilitar el cobro por uso en varias suscripciones.
Azure Storage proporciona funcionalidades de supervisión integradas. Tenga en cuenta los servicios que planea usar en la cuenta de almacenamiento. Por ejemplo, al usar blobs, puede ver la capacidad total de una cuenta de almacenamiento, pero no un solo contenedor. Al usar recursos compartidos de archivos, puede ver la capacidad de cada recurso compartido, pero no de cada carpeta.
También puede registrar todas las solicitudes en Storage y, a continuación, agregar y analizar esos registros. Este enfoque proporciona flexibilidad al agregar y agrupar datos para cada inquilino. Pero en las soluciones que crean grandes volúmenes de solicitudes a Storage, considere si la ventaja que obtiene de este enfoque justifica el costo de capturar y procesar esos registros.
El inventario de Azure Storage proporciona otro enfoque para medir el tamaño total de un contenedor de blobs.
Modelos de aislamiento
Cuando se usa Storage en un sistema multiinquilino, determine el nivel de aislamiento que se va a aplicar. Azure Storage admite varios modelos de aislamiento.
Cuentas de almacenamiento para cada inquilino
El nivel de aislamiento más seguro usa una cuenta de almacenamiento dedicada para cada inquilino. Este modelo garantiza el completo aislamiento de las claves de almacenamiento, que puede rotar de forma independiente. También permite escalar la solución más allá de los límites y cuotas de cada cuenta de almacenamiento. Pero también debe tener en cuenta el número máximo de cuentas de almacenamiento permitidas dentro de una sola suscripción de Azure.
Nota:
Considere las cuotas y los límites de almacenamiento al seleccionar un modelo de aislamiento. Estos límites incluyen los límites de servicio de Azure, los objetivos generales de escalabilidad y los objetivos de escalabilidad para el proveedor de recursos de Storage.
Cada componente de Storage proporciona más opciones para el aislamiento de inquilinos.
Modelos de aislamiento de Blob Storage
En la tabla siguiente se resumen las diferencias entre los principales modelos de aislamiento de inquilinato para blobs de Storage.
| Consideración | Contenedores de blobs compartidos | Contenedores de blobs para cada inquilino | Cuentas de almacenamiento para cada inquilino |
|---|---|---|---|
| Aislamiento de datos | Bajo-medio. Usa rutas para identificar los datos de cada cliente o los espacios de nombres jerárquicos. | Mediana. Use direcciones URL de SAS con ámbito de contenedor para admitir el aislamiento de seguridad. | Alto |
| Aislamiento de rendimiento | Bajo | Bajo. La mayoría de las cuotas y los límites se aplican a toda la cuenta de almacenamiento. | Alto |
| Complejidad de la implementación | Bajo | Media | Alto |
| Complejidad operativa | Bajo | Media | Alto |
| Escenario de ejemplo | Cada inquilino tiene solo unos pocos blobs. | Se emiten direcciones URL de SAS con ámbito de inquilino. | Cada cliente tiene su propio sello de implementación. |
Contenedores de blobs compartidos
Al trabajar con Blob Storage, puede usar un contenedor de blobs compartido que incluya rutas de blobs para separar los datos de cada cliente.
| Id. de inquilino | Ruta de acceso del blob de ejemplo |
|---|---|
tenant-a |
https://contoso.blob.core.windows.net/sharedcontainer/tenant-a/blob1.mp4 |
tenant-b |
https://contoso.blob.core.windows.net/sharedcontainer/tenant-b/blob2.mp4 |
Este enfoque es fácil de implementar, pero en muchos escenarios, las rutas de acceso de blob no proporcionan suficiente aislamiento entre inquilinos. Blob Storage no admite una estructura de directorios o carpetas verdadera, por lo que no se puede asignar acceso a todos los blobs dentro de una ruta de acceso especificada. Sin embargo, Storage proporciona una funcionalidad para listar o enumerar los blobs que comienzan con un prefijo especificado. Esta característica admite escenarios que usan contenedores de blobs compartidos y no requieren control de acceso de nivel de directorio.
La característica de espacio de nombres jerárquico de Storage proporciona una estructura de directorios o carpetas más sólida, incluido el control de acceso específico del directorio. Esta característica admite escenarios multiusuario en los que se han compartido contenedores de blobs, pero se quiere conceder acceso a los datos de un solo inquilino.
En algunas soluciones multiinquilino, es posible que solo necesite almacenar un único blob o un conjunto de blobs para cada inquilino, como iconos de inquilino para personalizar una interfaz de usuario. Un único contenedor de blobs compartido puede funcionar en estos escenarios. Puede usar el identificador de inquilino como nombre del blob y, a continuación, leer un blob específico en lugar de enumerar una ruta de acceso de blob.
Al usar contenedores compartidos, tenga en cuenta si necesita realizar un seguimiento de los datos y el uso de Storage para cada inquilino. Para más información, consulte Supervisión.
Contenedores de blobs para cada inquilino
Es posible crear contenedores de blobs individuales para cada usuario dentro de una sola cuenta de almacenamiento. No hay límite para el número de contenedores de blobs que puede crear dentro de una cuenta de almacenamiento.
Al crear un contenedor para cada inquilino, puede usar el control de acceso de almacenamiento, incluido SAS, para administrar el acceso de los datos de cada inquilino. También puede supervisar fácilmente la capacidad que usa cada contenedor.
Modelos de aislamiento de almacenamiento de archivos
En la tabla siguiente se resumen las diferencias entre los principales modelos de aislamiento de inquilinos para los archivos de almacenamiento.
| Consideración | Recursos compartidos de archivos compartidos | Recursos compartidos de archivos para cada inquilino | Cuentas de almacenamiento para cada inquilino |
|---|---|---|---|
| Aislamiento de datos | Medio-alto. Aplicar reglas de autorización para directorios y archivos específicos del inquilino. | Medio-alto | Alto |
| Aislamiento de rendimiento | Bajo | Bajo-medio. La mayoría de las cuotas y los límites se aplican a toda la cuenta de almacenamiento, pero debe establecer cuotas de tamaño para cada recurso compartido de archivos. | Alto |
| Complejidad de la implementación | Bajo | Media | Alto |
| Complejidad operativa | Bajo | Media | Alto |
| Escenario de ejemplo | Una aplicación controla todo el acceso a los archivos. | Los inquilinos acceden a sus propios archivos. | Cada cliente tiene su propio sello de implementación. |
Recursos compartidos de archivos compartidos
Al trabajar con comparticiones de archivos, puede usar una compartición de archivos que incluya rutas de archivo para separar los datos de cada cliente.
| Id. de inquilino | Ruta de acceso de archivo de ejemplo |
|---|---|
tenant-a |
https://contoso.file.core.windows.net/share/tenant-a/blob1.mp4 |
tenant-b |
https://contoso.file.core.windows.net/share/tenant-b/blob2.mp4 |
Cuando la aplicación se comunica a través del protocolo Bloque de mensajes del servidor (SMB) y usa Active Directory Domain Services local o en Azure, los recursos compartidos de archivos admiten la autorización tanto en el nivel de recurso compartido como en el nivel de directorio o archivo.
En otros escenarios, considere la posibilidad de usar SAS para conceder acceso a recursos compartidos de archivos o archivos específicos. SAS no admite la concesión de acceso a directorios.
Al usar recursos de archivos compartidos, considere si necesita realizar un seguimiento de los datos y del uso de almacenamiento para cada cliente. Para más información, consulte Supervisión.
Recursos compartidos de archivos para cada inquilino
Puede crear recursos compartidos de archivos individuales para cada inquilino dentro de una sola cuenta de almacenamiento. No hay ningún límite en el número de recursos compartidos de archivos que puede crear dentro de una cuenta de almacenamiento.
En este escenario, puede usar el control de acceso de almacenamiento, incluido SAS, para administrar el acceso a los datos de cada arrendatario. También puede supervisar fácilmente la capacidad que usa cada recurso compartido de archivos.
Modelos de aislamiento de Table Storage
En la tabla siguiente se resumen las diferencias entre los principales modelos de aislamiento de inquilinato para tablas de Storage.
| Consideración | Tablas compartidas con claves de partición para cada inquilino | Tablas para cada inquilino | Cuentas de almacenamiento para cada inquilino |
|---|---|---|---|
| Aislamiento de datos | Bajo. La aplicación impone el aislamiento. | Bajo medio | Alto |
| Aislamiento de rendimiento | Bajo | Bajo. La mayoría de las cuotas y los límites se aplican a toda la cuenta de almacenamiento. | Alto |
| Complejidad de la implementación | Bajo | Media | Alto |
| Complejidad operativa | Bajo | Media | Alto |
| Escenario de ejemplo | Una solución multiinquilino grande tiene un nivel de aplicación compartido. | Se emiten direcciones URL de SAS con ámbito de inquilino. | Cada cliente tiene su propio sello de implementación. |
Tablas compartidas con claves de partición para cada inquilino
Al usar table storage que incluye una sola tabla compartida, considere la posibilidad de usar la compatibilidad integrada para la creación de particiones. Cada entidad debe incluir una clave de partición, como un identificador de inquilino.
Las directivas y tokens de SAS permiten especificar un intervalo de claves de partición. Azure Storage garantiza que las solicitudes que contienen la firma solo pueden acceder a los intervalos de claves de partición especificados. Puede implementar el patrón de clave de acceso limitado, que permite a los clientes que no son de confianza acceder a la partición de un solo inquilino, sin afectar a otros inquilinos.
En el caso de las aplicaciones a gran escala, considere el rendimiento máximo de cada partición de tabla y la cuenta de almacenamiento.
Tablas para cada inquilino
Puede crear tablas individuales para cada inquilino dentro de una sola cuenta de almacenamiento. No hay límite para el número de tablas que puede crear dentro de una cuenta de almacenamiento.
En este escenario, puede usar el control de acceso de almacenamiento, incluido SAS, para administrar el acceso a los datos de cada arrendatario.
Modelos de aislamiento de Queue Storage
En la tabla siguiente se resumen las diferencias entre los principales modelos de aislamiento de inquilinos para las colas de Storage.
| Consideración | Colas compartidas | Colas para cada inquilino | Cuentas de almacenamiento para cada inquilino |
|---|---|---|---|
| Aislamiento de datos | Bajo | Bajo medio | Alto |
| Aislamiento de rendimiento | Bajo | Bajo. La mayoría de las cuotas y los límites se aplican a toda la cuenta de almacenamiento. | Alto |
| Complejidad de la implementación | Bajo | Media | Alto |
| Complejidad operativa | Bajo | Media | Alto |
| Escenario de ejemplo | Una solución multiinquilino grande tiene un nivel de aplicación compartido. | Se emiten direcciones URL de SAS con ámbito de inquilino. | Cada cliente tiene su propio sello de implementación. |
Colas compartidas
Si comparte una cola, tenga en cuenta las cuotas y los límites que se aplican. En las soluciones que tienen un gran volumen de solicitudes, considere si la capacidad de procesamiento objetivo de 2,000 mensajes por segundo funciona para su escenario.
Las colas no proporcionan particiones ni subcolas, por lo que se podrían entremezclar los datos de todos los inquilinos.
Colas para cada inquilino
Puede crear colas individuales para cada inquilino dentro de una sola cuenta de almacenamiento. No hay límite para el número de colas que puede crear dentro de una cuenta de almacenamiento.
En este escenario, puede usar el control de acceso de almacenamiento, incluido SAS, para administrar el acceso a los datos de cada arrendatario.
Al crear dinámicamente colas para cada inquilino, tenga en cuenta cómo consume la capa de aplicación los mensajes de la cola de cada inquilino. Para escenarios avanzados, considere la posibilidad de usar Azure Service Bus, que admite características como sesiones, entrega automática de mensajes, temas y suscripciones. Estas funcionalidades pueden mejorar las soluciones multiinquilino.
Colaboradores
Microsoft mantiene este artículo. Los colaboradores siguientes escribieron este artículo.
Autor principal:
- John Downs | Ingeniero principal de software, Patrones y prácticas de Azure
Otros colaboradores:
- Dr. Christian Geuer-Pollmann | Ingeniero principal de clientes, FastTrack para Azure
- Patrick Horn | Senior Customer Engineering Manager, FastTrack for Azure
- Ben Hummerstone | Ingeniero principal de clientes, FastTrack para Azure
- Vic Perdana | Arquitecto de soluciones en la nube, ISV de Azure
- Daniel Scott-Raynsford | Arquitecto de soluciones asociadas, datos e inteligencia artificial
- Arsen Vladimirskiy | Ingeniero principal de clientes, FastTrack para Azure
Para ver los perfiles no públicos de LinkedIn, inicie sesión en LinkedIn.