Azure proporciona numerosas opciones para organizar los recursos. Una solución multiinquilino tiene ventajas e inconvenientes específicos que deben tenerse en cuenta al planear la estrategia de organización de los recursos. En este artículo, se revisan dos elementos principales de la organización de los recursos de Azure: el aislamiento de inquilinos y la escalabilidad horizontal entre varios recursos. Se describen algunos enfoques de implementación comunes que pueden soportar diferentes modelos de aislamiento de inquilinos. También se describe cómo trabajar con las cuotas y los límites de recursos de Azure y cómo escalar la solución más allá de estos límites.
Consideraciones clave y requisitos
Requisitos de aislamiento de inquilinos
Al implementar una solución multiinquilino en Azure, debe decidir si quiere dedicar recursos a cada inquilino o bien compartir recursos entre varios inquilinos. En los enfoques multiinquilino y las secciones de guía específica del servicio de esta serie se describen las opciones y las contrapartidas de muchas categorías de recursos. En general, existen diversas opciones para el aislamiento de inquilinos. Revise Modelos de inquilinato que se deben tener en cuenta para una solución multiinquilino para obtener más instrucciones acerca de cómo decidir sobre el modelo de aislamiento.
Escala
La mayoría de los recursos de Azure, así como los grupos de recursos y las suscripciones, imponen límites que pueden afectar a su capacidad de escalar. Puede que deba tener en cuenta la escalabilidad horizontal o el empaquetado en contenedores para adaptarse al número planeado de inquilinos o a la carga planeada del sistema.
Si sabe con certeza que no va a aumentar a un gran número de inquilinos ni a una carga elevada, no diseñe en exceso el plan de escalado horizontal. Sin embargo, si tiene previsto que la solución crezca, considere detenidamente el plan de escalabilidad horizontal. Asegúrese de diseñar el escalado de acuerdo con las instrucciones de guía de este artículo.
Si tiene un proceso de implementación automatizado y necesita escalar entre los recursos, determine cómo va a implementar y a asignar inquilinos en varias instancias de recursos. Por ejemplo, ¿cómo va a detectar que se está aproximando al número de inquilinos que pueden asignarse a un recurso específico? ¿Planeará la implementación de nuevos recursos cuando es necesario para cuando se requieran? ¿O bien implementará un grupo de recursos con antelación de forma que estén listos para usarlos cuando los necesite?
Sugerencia
Puede que, en las primeras fases del diseño y el desarrollo, no elija implementar procesos de escalabilidad horizontal automatizados. Aun así, debe considerar y documentar claramente los procesos necesarios para escalar a medida que se crece. Al documentar los procesos, facilite la automatización de ellos si la necesidad surge en el futuro.
También es importante evitar hacer suposiciones en el código y en la configuración, lo cual puede limitar la capacidad de escalado. Por ejemplo, es posible que tenga que escalar horizontalmente a varias cuentas de almacenamiento en el futuro, por lo que, al compilar el nivel de aplicación, asegúrese de que puede cambiar de forma dinámica la cuenta de almacenamiento a la que se conecta en función del inquilino activo.
Enfoques y patrones que se deben tener en cuenta
Aislamiento de inquilinos
Los recursos de Azure se implementan y se administran a través de una jerarquía. La mayoría de los recursos se implementan en grupos de recursos, que se incluyen en suscripciones. Los grupos de administración agrupan las suscripciones de forma lógica. Todas estas capas jerárquicas están asociadas a un inquilino de Microsoft Entra.
Al determinar cómo deben implementarse los recursos para cada inquilino, puede aislar en distintos niveles de la jerarquía. Cada opción es válida para determinados tipos de soluciones multiinquilino y tiene tanto ventajas como inconvenientes. También es habitual combinar enfoques, con el uso de diferentes modelos de aislamiento para los distintos componentes de una solución.
Aislamiento dentro de un recurso compartido
Puede optar por compartir un recurso de Azure entre varios inquilinos y ejecutar todas sus cargas de trabajo en una sola instancia. Revise los servicios de Azure que usa en la guía específica del servicio para el reconocimiento de opciones o consideraciones concretas que puedan ser importantes.
Al ejecutar instancias únicas de un recurso, debe tener en cuenta los límites de servicio, los límites de suscripción o las cuotas que pueden alcanzarse a medida que se escala. Por ejemplo, existe un número máximo de nodos admitidos por un clúster de Azure Kubernetes Service (AKS) y hay un límite superior respecto al número de transacciones por segundo compatibles con una cuenta de almacenamiento. Piense cómo va a escalar a varios recursos compartidos a medida que se acerque a estos límites.
También debe asegurarse de que el código de la aplicación sea totalmente compatible con el carácter multiinquilino y que restrinja el acceso a los datos para un inquilino específico.
Para ilustrar el enfoque de recurso compartido, supongamos que Contoso está creando una aplicación SaaS multiinquilino que incluye una aplicación web, una base de datos y una cuenta de almacenamiento. Es posible que decidan implementar recursos compartidos para dar servicio a todos sus clientes. En el diagrama siguiente, todos los clientes comparten un único conjunto de recursos.
Recursos independientes en un grupo de recursos
También es posible implementar recursos dedicados para cada inquilino. Puede implementar una copia completa de la solución para un solo inquilino. Otra opción es compartir algunos componentes entre los inquilinos mientras dedican otros componentes a un inquilino específico. Este enfoque se conoce como creación de particiones horizontales.
Le recomendamos usar grupos de recursos para administrar recursos con el mismo ciclo de vida. En algunos sistemas multiinquilino, tiene sentido implementar recursos para varios inquilinos en un único grupo de recursos o en un conjunto de grupos de recursos.
Es importante tener en cuenta cómo implementar y administrar estos recursos, incluido el hecho de si es la canalización de implementación o la aplicación la que inicia la implementación de los recursos específicos del inquilino. También debe determinar cómo identificar claramente qué recursos específicos se relacionan con inquilinos concretos. Considere la posibilidad de usar una estrategia de convención de nomenclatura clara, etiquetas de recursos o una base de datos de catálogo de inquilinos.
Se recomienda usar grupos de recursos independientes para los recursos que comparte entre varios inquilinos y los recursos que implementa para inquilinos individuales. Sin embargo, en algunos casos Azure limita el número de recursos de un solo tipo que pueden implementarse en un grupo de recursos. Este límite significa que puede ser necesario escalar entre varios grupos de recursos conforme se vaya creciendo.
Supongamos que Contoso tiene tres clientes (inquilinos): Adventure Works, Fabrikam y Tailwind. Se puede optar por compartir la aplicación web y la cuenta de almacenamiento entre los tres inquilinos y, después, implementar bases de datos individuales para cada inquilino. El siguiente diagrama muestra un grupo de recursos que contiene recursos compartidos y otro que contiene una base de datos para cada inquilino.
Grupos de recursos independientes en una suscripción
Al implementar un conjunto de recursos para cada inquilino, puede usar grupos de recursos dedicados específicos del inquilino. Por ejemplo, si se sigue el patrón de stamps de implementación, cada stamp debe implementarse en su propio grupo de recursos. Considere la posibilidad de implementar varios grupos de recursos específicos del inquilino en una suscripción de Azure compartida, lo que le permite configurar directivas y reglas de control de acceso de forma fácil.
Puede optar por crear un conjunto de grupos de recursos para cada inquilino y también grupos de recursos compartidos para los recursos compartidos.
Cuando implemente grupos de recursos específicos del inquilino en suscripciones compartidas, tenga en cuenta el número máximo de grupos de recursos de cada suscripción, así como otros límites de las suscripciones aplicables a los recursos que implemente. A medida que se aproxime a estos límites, puede que tenga que escalar entre varias suscripciones.
En nuestro ejemplo, Contoso puede optar por implementar un stamp para cada uno de sus clientes y colocar los stamps en grupos de recursos dedicados dentro de una misma suscripción. En el diagrama siguiente se crea una suscripción, que contiene tres grupos de recursos, para cada cliente.
Suscripciones independientes
Los recursos específicos de un inquilino se pueden aislar por completo mediante la implementación de suscripciones específicas de inquilino. Además, dado que la mayoría de las cuotas y los límites se aplican dentro de una suscripción, el uso de una suscripción independiente por inquilino garantiza que cada uno de ellos tenga un uso pleno de las cuotas aplicables. Para algunos tipos de cuenta de facturación de Azure, puede crear suscripciones mediante programación. También puede usar las Reservas de Azure y el plan de ahorro de Azure para el proceso en todas las suscripciones.
Tenga en cuenta el número de suscripciones que puede crear. El número máximo de suscripciones puede diferir en función de su relación comercial con Microsoft o con un asociado de Microsoft, como, por ejemplo, si tiene un contrato Enterprise.
Sin embargo, puede ser más difícil solicitar aumentos de cuota cuando se trabaja con un gran número de suscripciones. La API de cuota proporciona una interfaz programática para algunos tipos de recursos. Sin embargo, para otros muchos, los aumentos de cuota deben solicitarse mediante la apertura de un caso de soporte técnico. También puede suponer un reto trabajar con contratos de soporte técnico y casos de soporte técnico de Azure cuando se trabaja con muchas suscripciones.
Considere la posibilidad de agrupar las suscripciones específicas de inquilino en una jerarquía de grupos de administración para permitir una administración sencilla de las directivas y las reglas de control de acceso.
Por ejemplo, suponga que Contoso haya decidido crear suscripciones de Azure independientes para cada uno de sus tres clientes, como se muestra en el diagrama a continuación. Cada suscripción contiene un grupo de recursos, con el conjunto completo de recursos para ese cliente.
Cada suscripción contiene un grupo de recursos, con el conjunto completo de recursos para ese cliente.
Se usa un grupo de administración para simplificar la administración de sus suscripciones. Si se incluye Producción en el nombre del grupo de administración, se pueden distinguir claramente los inquilinos de producción de los que no son de producción o de los inquilinos de prueba. A los inquilinos que no son de producción se les aplican directivas y reglas de control de acceso de Azure distintas.
Todas sus suscripciones están asociadas a un único inquilino de Microsoft Entra. El uso de un único inquilino de Microsoft Entra significa que las identidades del equipo de Contoso, incluidos los usuarios y las entidades de servicio, se pueden usar en todo su patrimonio de Azure.
Suscripciones independientes en inquilinos de Microsoft Entra independientes
Otra posibilidad es crear inquilinos individuales de Microsoft Entra de forma manual para cada uno de sus inquilinos, o bien implementar sus recursos en suscripciones de los inquilinos de Microsoft Entra de sus clientes. Sin embargo, trabajar con varios inquilinos de Microsoft Entra dificulta la autenticación, la administración de asignaciones de roles, la aplicación de directivas globales y la realización de muchas otras operaciones de administración.
Advertencia
Se recomienda crear varios inquilinos de Microsoft Entra para la mayoría de las soluciones multiinquilino. Trabajar con diversos inquilinos de Microsoft Entra introduce complejidad adicional y reduce su capacidad para escalar y administrar los recursos. Normalmente, este enfoque solo lo usan los proveedores de servicios administrados (MSP), que manejan entornos de Azure en nombre de sus clientes.
Antes de intentar implementar varios inquilinos de Microsoft Entra, considere si puede lograr sus requisitos mediante el uso de grupos de administración o suscripciones dentro de un único inquilino en su lugar.
En aquellas situaciones en las que necesite administrar recursos de Azure de suscripciones asociadas a varios inquilinos de Microsoft Entra, considere la posibilidad de usar Azure Lighthouse como ayuda para administrar sus recursos entre los distintos inquilinos de Microsoft Entra.
Por ejemplo, Contoso puede crear inquilinos de Microsoft Entra y suscripciones de Azure independientes en ambos casos para cada uno de sus clientes, tal y como se muestra en el diagrama siguiente.
Se configura un inquilino de Microsoft Entra para cada uno de los inquilinos de Contoso, que contiene una suscripción y los recursos necesarios. Azure Lighthouse está conectado a cada inquilino de Microsoft Entra.
Empaquetado en contenedores
Independientemente del modelo de aislamiento de recursos, es importante tener en cuenta cuándo y cómo se escalará horizontalmente su solución en varios recursos. Es posible que tenga que escalar los recursos a medida que aumente la carga del sistema o que se incremente el número de inquilinos. Considere el empaquetado en contenedores como opción para implementar un número óptimo de recursos de acuerdo con sus requisitos.
Sugerencia
En muchas soluciones, es más fácil escalar todo el conjunto de recursos a la vez que escalar los recursos individualmente. Considere la posibilidad de seguir el patrón de stamps de implementación.
Límites de recursos
Los recursos de Azure tienen límites y cuotas que deben tenerse en cuenta en el planeamiento de la solución. Por ejemplo, los recursos pueden admitir un número máximo de solicitudes simultáneas o de configuraciones específicas del inquilino.
La forma de configurar y usar cada recurso afecta también a la escalabilidad de este. Por ejemplo, suponga que, dada una cierta cantidad de recursos de proceso, la aplicación puede responder correctamente a un número definido de transacciones por segundo. Más allá de este punto, puede que tenga que escalar horizontalmente. Las pruebas de rendimiento le ayudan a identificar el punto en el que los recursos dejan de cumplir los requisitos.
Nota
El principio de escalado a múltiples recursos se aplica incluso cuando se trabaja con servicios que admiten varias instancias.
Por ejemplo, Azure App Service admite la escalabilidad horizontal del número de instancias del plan, pero existen límites respecto a cuánto puede escalarse un solo plan. En una aplicación multiinquilino a gran escala, puede que supere estos límites y que sea necesario implementar más planes adicionales de App Service para adaptarse al crecimiento.
Al compartir algunos de los recursos entre inquilinos, primero debe determinar el número de inquilinos que admite el recurso, cuando se configura de acuerdo con sus requisitos. A continuación, implemente tantos recursos como necesite para atender al número total de inquilinos.
Por ejemplo, supongamos que implementa una instancia de Azure Application Gateway como parte de una solución SaaS multiinquilino. Revise el diseño de la aplicación, pruebe el rendimiento de la puerta de enlace de aplicación bajo carga y revise su configuración. A continuación, determine si un único recurso de puerta de enlace de aplicación puede compartirse entre 100 clientes. Según el plan de crecimiento de su organización, se espera incorporar 150 clientes durante el primer año, por lo que debe planear la implementación de varias puertas de enlace de aplicaciones para dar servicio a la carga esperada.
En el diagrama anterior, hay dos puertas de enlace de aplicaciones. La primera está dedicada a los clientes del 1 al 100 y la segunda a los clientes del 101 a 200.
Límites de suscripciones y grupos de recursos
Tanto si trabaja con recursos compartidos como dedicados, es importante tener en cuenta los límites correspondientes. Azure limita el número de recursos que se pueden implementar en un grupo de recursos y en una suscripción de Azure. A medida que se aproxime a estos límites, deberá planear el escalado entre varios grupos de recursos o suscripciones.
Por ejemplo, suponga que implementa una puerta de enlace de aplicaciones dedicada para cada uno de los clientes en un grupo de recursos compartidos. En el caso de algunos recursos, Azure admite la implementación de hasta 800 recursos del mismo tipo en un solo grupo de recursos. Por lo tanto, cuando alcance este límite, deberá implementar las nuevas puertas de enlace de aplicaciones en otro grupo de recursos. En el diagrama siguiente hay dos grupos de recursos. Cada uno de ellos contiene 800 puertas de enlace de aplicaciones.
Empaquetado en contenedores de inquilinos entre grupos de recursos y suscripciones
También puede aplicar el concepto de empaquetado en contenedores entre los recursos, los grupos de recursos y las suscripciones. Por ejemplo, si tiene un número reducido de inquilinos, seguramente podrá implementar un solo recurso y compartirlo entre todos los inquilinos. En el diagrama siguiente se muestra el empaquetado en contenedores en un único recurso.
A medida que aumenta el tamaño, puede que se aproxime al límite de capacidad de un solo recurso y que tenga que escalar horizontalmente a varios de ellos (R). En el diagrama siguiente se muestra el empaquetado en contenedores entre varios recursos.
Con el tiempo, puede que se alcance el límite de número de recursos de un único grupo de recursos y, entonces, tendrían que implementarse varios recursos (R) en múltiples grupos de recursos (G). En el diagrama siguiente se muestra el empaquetado en contenedores entre varios recursos, en múltiples grupos de recursos.
Si crece aún más, puede implementar en varias suscripciones (S), cada una de las que contiene varios grupos de recursos (G) con múltiples recursos (R). En el diagrama siguiente se muestra el empaquetado en contenedores entre varios recursos, en múltiples grupos de recursos y suscripciones.
Al planear la estrategia de escalabilidad horizontal, puede escalar a un número muy elevado de inquilinos y mantener un alto nivel de carga.
Etiquetas
Las etiquetas de recursos permiten agregar metadatos personalizados a los recursos de Azure, lo cual puede ser útil para la administración y el seguimiento de los costos. Para obtener más detalles, consulte Asignación de costos mediante etiquetas de recursos.
Pilas de implementación
Las pilas de implementación permiten agrupar recursos en función de una vida útil común, aunque abarquen varios grupos de recursos o suscripciones. Las pilas de implementación son útiles al implementar recursos específicos del inquilino, especialmente si tiene un enfoque de implementación que requiere la implementación de diferentes tipos de recursos en diferentes lugares debido a problemas de escalado o cumplimiento. Las pilas de implementación también le permiten quitar fácilmente todos los recursos relacionados con un solo inquilino en una operación, si ese inquilino está desactivado. Para obtener información más detallada, consulte Pilas de implementación.
Antipatrones que se deben evitar
- Falta de planeamiento de escalado. Asegúrese de comprender con claridad los límites de los recursos que va a implementar y qué límites pueden ser importantes a medida que aumente la carga o el número de inquilinos. Planee cómo implementará recursos adicionales a medida que se escale y cómo probará el plan.
- Falta de planeamiento del empaquetado en contenedores. Aunque no se requiera un aumento de tamaño de forma inmediata, planee la escalabilidad de los recursos de Azure entre varios recursos, grupos de recursos y suscripciones a lo largo del tiempo. Evite hacer suposiciones en el código de la aplicación, como que haya un único recurso cuando puede que necesite escalar a varios recursos en el futuro.
- Escalado de muchos recursos individuales. Si tiene una topología de recursos compleja, puede resultar difícil escalar cada componente individualmente. A menudo es más fácil escalar la solución como unidad, de acuerdo con el patrón de stamps de implementación.
- Implementación de recursos aislados para cada inquilino, cuando no sea necesario. En muchas soluciones, es más rentable y eficaz implementar recursos compartidos para varios inquilinos.
- No se puede realizar un seguimiento de los recursos específicos del inquilino. Si implementa recursos específicos del inquilino, asegúrese de comprender qué recursos se asignan a los inquilinos. Esta información es importante para fines de cumplimiento, para realizar el seguimiento de los costes y para desaprovisionar recursos si un inquilino está fuera de la pizarra. Considere la posibilidad de usar etiquetas de recursos para realizar un seguimiento de la información del inquilino sobre los recursos y considere la posibilidad de usar pilas de implementación para agrupar recursos específicos del inquilino en una unidad lógica, independientemente del grupo de recursos o la suscripción en los que se encuentra.
- Uso de inquilinos independientes de Microsoft Entra. En general, no se recomienda aprovisionar varios inquilinos de Microsoft Entra. La administración de recursos en los inquilinos de Microsoft Entra es compleja. Es mucho más fácil escalar entre suscripciones vinculadas a un único inquilino de Microsoft Entra.
- Planificación de una arquitectura excesiva cuando no es necesario escalar. En algunas soluciones, se sabe con certeza que nunca se va a superar un determinado nivel de escala. En estos escenarios, no es necesario crear una lógica de escalado compleja. Sin embargo, si su organización tiene previsto crecer, deberá estar preparado para escalar, posiblemente a corto plazo.
Colaboradores
Microsoft mantiene este artículo. Originalmente lo escribieron los siguientes colaboradores.
Autor principal:
- John Downs | Ingeniero principal de software
Otros colaboradores:
- Jason Beck | Ingeniero de clientes sénior, FastTrack for Azure
- Bohdan Cherchyk | Ingeniero de clientes sénior, FastTrack for Azure
- Laura Nicolas | Ingeniero de clientes sénior, FastTrack for Azure
- Arsen Vladimirskiy | Principal Customer Engineer, FastTrack for Azure
- Kevin Ashley | Ingeniero de clientes sénior, FastTrack for Azure
Para ver los perfiles no públicos de LinkedIn, inicie sesión en LinkedIn.
Pasos siguientes
Revise los enfoques de administración y asignación de costos.