Consideraciones para los planos de control multiinquilino

Una solución multiinquilino tiene varios planos, y cada uno tiene sus propias responsabilidades. El plano de datos permite a los usuarios y clientes interactuar con un sistema. El plano de control administra tareas de nivel superior, como el control de acceso, el aprovisionamiento y el mantenimiento del sistema, en todos los inquilinos para admitir las tareas de los administradores de la plataforma.

En este artículo se proporciona información sobre las responsabilidades de los planos de control y cómo diseñar un plano de control que satisfaga sus necesidades.

Por ejemplo, considere un sistema de contabilidad para administrar registros financieros. Varios inquilinos almacenan sus registros financieros en el sistema. Cuando los usuarios acceden al sistema para ver y escribir sus registros financieros, usan el plano de datos. Es probable que el plano de datos sea el componente de aplicación principal de la solución. Los inquilinos normalmente lo ven como la interfaz principal para usar el sistema según lo previsto.

En cambio, el plano de control incorpora nuevos inquilinos, crea bases de datos para cada inquilino y realiza otras operaciones de administración y mantenimiento. Sin un plano de control, los administradores deben confiar en procesos manuales. En algunos casos, las tareas del plano de datos y del plano de control se entrelazan, lo que sobrecomplica las soluciones.

Muchos sistemas complejos incluyen un plano de control. Por ejemplo, el plano de control de Azure, Azure Resource Manager, es un conjunto de API, herramientas y componentes back-end que implementan y configuran recursos de Azure. Y el plano de control de Kubernetes administra muchas tareas, como la colocación de pods de Kubernetes en nodos de trabajo. Casi todas las soluciones de software como servicio (SaaS) tienen un plano de control para controlar las tareas entre inquilinos.

Al diseñar soluciones multiinquilino, debe tener en cuenta los planos de control. En las secciones siguientes se describe cómo definir el ámbito y el diseño de un plano de control.

Responsabilidades de un plano de control

No hay ninguna plantilla única para un plano de control o sus responsabilidades. Los requisitos y la arquitectura de la solución dictan lo que debe hacer el plano de control y cómo funciona. En algunas soluciones multiinquilino, el plano de control tiene una amplia gama de responsabilidades y es un sistema complejo en su propio derecho. En otras soluciones multiinquilino, el plano de control solo tiene responsabilidades básicas.

En general, un plano de control puede tener muchas de las siguientes responsabilidades principales:

• Administración de recursos: Aprovisiona y administra los recursos del sistema que sirven a la carga de trabajo, incluidos los recursos específicos del inquilino. El plano de control puede invocar y organizar una canalización de implementación o ejecutar operaciones de implementación directamente.

• Configuración de recursos: Vuelve a configurar los recursos compartidos para reconocer nuevos inquilinos. Por ejemplo, el plano de control podría configurar el enrutamiento de red para asegurarse de que el tráfico entrante alcanza los recursos correctos del inquilino, o puede que tenga que escalar la capacidad del recurso.

• Configuración del inquilino: Almacena y administra la configuración de cada inquilino.

• Administración del ciclo de vida del inquilino: Controla los eventos del ciclo de vida del inquilino, como la incorporación, la reubicación y la retirada de inquilinos.

• Telemetría: Realiza un seguimiento del uso de cada inquilino de las características y el rendimiento del sistema.

• Seguimiento de consumo:Mide y agrega el consumo de recursos de cada inquilino. Las métricas de consumo pueden informar a los sistemas de facturación o respaldar la gestión de recursos.

Si usa el modelo multiinquilino completo y no implementa recursos específicos del inquilino, un plano de control básico solo puede realizar un seguimiento de los inquilinos y sus metadatos asociados. Por ejemplo, cuando un nuevo inquilino se suscribe al servicio, el plano de control podría actualizar los registros adecuados en una base de datos para que el resto del sistema pueda atender las solicitudes del nuevo inquilino.

Por el contrario, si la solución usa un modelo de implementación que requiere una infraestructura específica del inquilino, como el modelo automatizado de un solo inquilino, el plano de control podría tener más responsabilidades. Es posible que tenga que implementar o volver a configurar la infraestructura de Azure al incorporar un nuevo inquilino. En este escenario, es probable que el plano de control interactúe con los planos de control para otras herramientas, como Resource Manager o el plano de control de Kubernetes.

Los planos de control avanzados pueden asumir más responsabilidades:

• Operaciones de mantenimiento automatizadas: Realiza operaciones de mantenimiento comunes, como eliminar o archivar datos antiguos, crear y administrar índices de base de datos y rotar secretos y certificados criptográficos.

• Ubicación del inquilino: asigna inquilinos a implementaciones o stamps existentes en función de criterios como destinos de uso de sellos, requisitos de inquilino y estrategias de empaquetado de contenedores.

• Reequilibrio de inquilinos: reequilibra los inquilinos existentes en los stamps de implementación a medida que cambia su uso.

• Seguimiento de la actividad del cliente: Se integra con soluciones externas de administración de clientes, como Dynamics 365, para realizar un seguimiento de la actividad del cliente.

Ámbito de un plano de control

Considere cuidadosamente cuánto esfuerzo dedicar a crear un plano de control para la solución. Un plano de control no proporciona directamente un valor inmediato al cliente, lo que puede dificultar la justificación del esfuerzo de ingeniería en el diseño y la construcción de un plano de control de alta calidad. Sin embargo, a medida que el sistema crece y escala, cada vez necesita más administración y operaciones automatizadas para mantenerse al día con su crecimiento.

En determinadas situaciones, es posible que no necesite un plano de control completo. Este enfoque puede funcionar si el sistema tiene menos de 10 inquilinos. Su equipo puede asumir las responsabilidades del plano de control y usar operaciones y procesos manuales para incorporar y administrar inquilinos. Sin embargo, todavía debe contar con un proceso y mantener un lugar central para hacer un seguimiento de sus usuarios y sus configuraciones.

A medida que crezca más allá de algunos inquilinos, es probable que se beneficie de tener una manera de realizar un seguimiento de cada inquilino y aplicar la supervisión en toda la flota de recursos e inquilinos. Es posible que observe que el equipo dedica un tiempo y esfuerzo crecientes a la administración de inquilinos. O bien, es posible que observe errores o problemas operativos debido a incoherencias en la forma en que los miembros del equipo realizan tareas de administración. Si se producen estas situaciones, considere la posibilidad de crear un plano de control más completo para asumir estas responsabilidades.

Diseño de un plano de control

Después de determinar los requisitos y el ámbito del plano de control, debe diseñarlo y arquitectarlo. Un plano de control es un componente importante y merece el mismo nivel de planificación que cualquier otra parte de la arquitectura.

Consideraciones

Estas consideraciones implementan los pilares del Azure Well-Architected Framework, que es un conjunto de principios rectores que puede utilizar para mejorar la calidad de una carga de trabajo. Para obtener más información, consulte Marco de buena arquitectura.

Un plano de control funciona como su propio sistema, por lo que debe tener en cuenta los cinco pilares del marco deWell-Architected al diseñar uno. En las secciones siguientes se resaltan áreas concretas en las que centrarse.

Fiabilidad

La confiabilidad ayuda a garantizar que la aplicación pueda cumplir los compromisos contraídos con los clientes. Para obtener más información, consulte Lista de comprobación de revisión de diseño para confiabilidad.

Los aviones de control suelen servir como componentes críticos. Debe planear el nivel adecuado de resistencia y confiabilidad que necesita el plano de control.

Considere el impacto de una interrupción del plano de control. En casos extremos, una interrupción podría hacer que toda la solución no esté disponible. Incluso si el plano de control no es un único punto de error, una interrupción podría provocar los siguientes problemas:

• El sistema no puede incorporar nuevos inquilinos, lo que podría afectar al crecimiento empresarial y de ventas.

• El sistema no puede administrar los inquilinos existentes, lo que da lugar a más llamadas al equipo de soporte técnico.

• No puede medir el consumo de inquilinos ni facturarlos por su uso, lo que da lugar a pérdidas de ingresos.

• No puede deshabilitar ni volver a configurar un tenant en respuesta a un incidente de seguridad.

• La deuda de mantenimiento se acumula, lo que da lugar a daños a largo plazo al sistema. Por ejemplo, si tu solución requiere una limpieza nocturna de datos antiguos, los discos podrían llenarse o el rendimiento podría disminuir.

Defina los objetivos de nivel de servicio para el plano de control, incluidos los destinos de disponibilidad, el objetivo de tiempo de recuperación (RTO) y el objetivo de punto de recuperación (RPO). Los objetivos establecidos para el plano de control pueden diferir de los objetivos que ofrezca a sus clientes.

Seguridad

La seguridad proporciona garantías contra ataques deliberados y el uso incorrecto de datos y sistemas valiosos. Para obtener más información, consulte Lista de comprobación de revisión de diseño para seguridad.

Los planos de control suelen ser sistemas con privilegios elevados. Los problemas de seguridad dentro de un plano de control pueden tener consecuencias graves. En función de su diseño y funcionalidad, un plano de control podría ser vulnerable a muchos tipos diferentes de ataques, incluidos los siguientes:

• Acceso no autorizado a secretos: Un plano de control puede tener acceso a claves y secretos para todos los inquilinos. Un atacante que tenga acceso al plano de control podría obtener acceso a los datos o recursos de cualquier inquilino.

• Abuso de funcionalidades de implementación: Un plano de control a menudo puede implementar nuevos recursos en Azure. Los atacantes podrían aprovechar tu plano de control para implementar sus propios recursos en tus suscripciones y potencialmente incurrir en cargos significativos.

• Denegación de servicio: Si un atacante deshabilita correctamente el plano de control, se pueden producir daños inmediatos y a largo plazo en el sistema y la empresa. Para ver posibles consecuencias del tiempo de inactividad del plano de control, consulte Confiabilidad.

Al diseñar e implementar un plano de control, debe seguir los procedimientos recomendados de seguridad y crear un modelo de amenazas completo. Este modelo debe identificar y mitigar posibles amenazas y problemas de seguridad en la solución.

Excelencia operativa

La excelencia operativa abarca los procesos de las operaciones que implementan una aplicación y la mantienen en ejecución en producción. Para obtener más información, consulte la Lista de comprobación de revisión de diseño para la excelencia operativa.

Un plano de control es un componente crítico, por lo que debe considerar cuidadosamente cómo implementarlo y operarlo en producción.

Al igual que otras partes de la solución, debe implementar instancias de no producción del plano de control para que pueda probar exhaustivamente su funcionalidad. Si el plano de control realiza operaciones de implementación, tenga en cuenta cómo interactúan los planos de control que no son de producción con el entorno de Azure y en qué suscripción de Azure se van a implementar recursos que no son de producción. Planifique cómo limpiar rápidamente los recursos de prueba para que no se acumulen cargos por error.

Planee también cómo controlar el acceso de su equipo al plano de control. Conceda solo los permisos que los miembros del equipo necesitan para realizar sus tareas. Este enfoque ayuda a evitar incidentes de seguridad y a reducir el efecto de una configuración incorrecta accidental.

Componentes

No hay ninguna plantilla única para crear un plano de control. Los componentes que diseñe y compile dependen de sus requisitos. La mayoría de los planos de control constan de API y componentes de trabajo en segundo plano. En algunas soluciones, un plano de control también incluye una interfaz de usuario, que el equipo o incluso los clientes podrían usar.

Aislamiento del plano de control de las cargas de trabajo de inquilino

Debe separar los recursos del plano de control de los recursos que gestionan los planos de datos de los clientes. Por ejemplo, use servidores de bases de datos independientes, servidores de aplicaciones y otros componentes. Mantenga los recursos del plano de control en un grupo de recursos de Azure dedicado, independiente de los recursos específicos del inquilino.

El aislamiento del plano de control proporciona las siguientes ventajas:

• Podrá configurar el escalado por separado. Por ejemplo, puede que el plano de control tenga unos requisitos de recursos coherentes y que los recursos de los inquilinos se escalen elásticamente en función de sus necesidades.

• Una separación clara crea un mamparo entre los planos de control y los planos de datos, lo que ayuda a evitar que los problemas de vecino ruidosos se extiendan a través de la solución.

• Los planos de control suelen ser sistemas con privilegios elevados con niveles altos de acceso. El aislamiento del plano de control reduce la probabilidad de una vulnerabilidad de seguridad que permite a los atacantes elevar sus permisos en todo el sistema.

• Podrá implementar configuraciones de firewall y de red independientes. Los planos de datos y los planos de control suelen requerir diferentes tipos de acceso a la red.

Orquestación de secuencias de operaciones de larga duración

Los planos de control suelen realizar operaciones de larga duración que requieren coordinación entre varios sistemas. Estas operaciones también pueden tener modos de error complejos, por lo que debe elegir tecnologías que admitan operaciones o flujos de trabajo de larga duración.

Por ejemplo, al incorporar un nuevo inquilino, el plano de control podría ejecutar las siguientes acciones en secuencia:

1. Implementar una nueva base de datos. Esta operación de implementación de Azure puede tardar varios minutos en completarse.

2. Actualizar el catálogo de metadatos del inquilino. Esta acción puede implicar la ejecución de un comando en una base de datos de Azure SQL.

3. Enviar un correo electrónico de bienvenida al nuevo inquilino. Esta acción invoca una API que no es de Microsoft para enviar el correo electrónico.

4. Actualizar el sistema de facturación para prepararse para facturar el nuevo inquilino. Esta acción invoca una API que no es de Microsoft que, en ocasiones, produce un error.

5. Actualizar el sistema de administración de relaciones con clientes (CRM) para realizar un seguimiento del nuevo inquilino. Esta acción invoca una API que no es de Microsoft.

Si se produce un error en algún paso de la secuencia, considere cómo responder:

• Volver a intentar la operación con error. Por ejemplo, si el comando de Azure SQL del paso 2 produce un error transitorio, podría reintentarlo.

• Continúe con el paso siguiente. Por ejemplo, puede decidir que puede permitir que se produzca un fallo en la actualización del sistema de facturación porque el equipo de ventas puede agregar manualmente un cliente más adelante.

• Abandonar el flujo de trabajo y desencadenar un proceso de recuperación manual.

Tenga en cuenta también la experiencia del usuario para cada escenario de error.

Administrar componentes compartidos

Un plano de control debe reconocer los componentes que son compartidos en lugar de dedicados a inquilinos específicos. Algunos componentes pueden compartirse entre todos los inquilinos dentro de un sello. Es posible que otros componentes se compartan entre todos los sellos de una región o incluso se compartan globalmente en todas las regiones y sellos. Al incorporar, volver a configurar o retirar un inquilino, la plataforma de control debe saber cómo gestionar estos componentes compartidos.

Algunos componentes compartidos requieren reconfiguración cuando se agregan o quitan inquilinos. Por ejemplo, supongamos que tiene un perfil de Azure Front Door compartido globalmente. Si agrega un inquilino que tiene un nombre de dominio personalizado, es posible que el plano de control tenga que actualizar la configuración del perfil para enrutar las solicitudes de ese nombre de dominio a la aplicación correcta. Del mismo modo, cuando se quita un inquilino, es posible que el plano de control tenga que quitar el nombre de dominio personalizado del perfil de Azure Front Door para evitar ataques de adquisición de subdominios.

Los componentes compartidos pueden tener reglas de escalado complejas que el plano de control debe seguir. Por ejemplo, si usa un enfoque de empaquetamiento de contenedores para implementar las bases de datos de los inquilinos, el plano de control debe asignar cada nueva base de datos a un grupo elástico de Azure SQL.

Puede determinar que necesita aumentar los recursos asignados al grupo por cada décima base de datos que agregue. Al agregar o quitar un inquilino, el plano de control debe volver a evaluar la configuración del grupo y decidir si desea cambiar los recursos del grupo. Cuando llegue al número máximo de bases de datos que puede asignar a un único grupo elástico, debe crear un nuevo grupo y usar ese grupo para las nuevas bases de datos de inquilino. El plano de control debe administrar cada uno de estos componentes compartidos, incluido el escalado y reconfigurarlos cuando se produzcan cambios.

Cuando el plano de control administra los componentes compartidos, es importante tener en cuenta las condiciones de carrera, que pueden producirse cuando se producen varias operaciones en paralelo. Por ejemplo, si incorpora un nuevo inquilino al mismo tiempo que quita un inquilino diferente, debe asegurarse de que el estado final sea coherente y cumpla los requisitos de escalado.

Uso de varios planos de control

En un entorno complejo, es posible que tenga que usar varios planos de control que administran diferentes áreas. Muchas soluciones multiinquilino siguen el patrón de stamps de implementación e inquilinos de particiones en varios stamps. En este patrón, puede crear planos de control independientes para las responsabilidades globales y de stamp.

Planos de control globales

Normalmente, un plano de control global controla la administración general y el seguimiento de los inquilinos. Un plano de control global puede tener las siguientes responsabilidades:

• Colocación del inquilino: el plano de control global determina qué stamp debe usar un inquilino. Puede realizar esta determinación en función de factores como la región del inquilino, el uso de la capacidad de cada estampilla y los requisitos del nivel de servicio del inquilino.

• Incorporación de inquilinos y administración del ciclo de vida: Estas responsabilidades incluyen el seguimiento de todos los inquilinos entre implementaciones.

Planos de control de stamp

Cada stamp de implementación incluye su propio plano de control del stamp, que gestiona los usuarios y los recursos asignados a ese stamp. Un plano de control de sellos puede tener las siguientes responsabilidades:

• Aprovisionamiento de recursos de inquilino: Crea y administra recursos específicos del inquilino dentro de la plataforma, como bases de datos y contenedores de almacenamiento.

• Administración de recursos compartidos: Supervisa el consumo de recursos compartidos e implementa nuevas instancias cuando se aproximan a su capacidad máxima.

• Operaciones de mantenimiento: Controla las tareas dentro del sello, como las operaciones de limpieza y administración de índices de base de datos.

Cada plano de control del stamp se coordina con el plano de control global. Por ejemplo, si un nuevo cliente se registra, el plano de control global podría seleccionar inicialmente un stamp para los recursos del cliente. A continuación, el plano de control global solicita al plano de control del stamp que cree los recursos necesarios para el inquilino.

En el diagrama siguiente se muestra cómo dos planos de control pueden coexistir en un único sistema.

Planos de control de inquilinos

Los inquilinos pueden usar un plano de control de nivel de inquilino para administrar sus propios recursos lógicos o físicos. Un plano de control de inquilinos puede tener las siguientes responsabilidades:

• Administración de configuración: Controla la configuración específica del inquilino, como el acceso de usuario.

• Operaciones de mantenimiento iniciadas por el inquilino: Admite operaciones como realizar copias de seguridad de datos o descargar copias de seguridad anteriores.

• Administración de actualizaciones: Realiza actualizaciones si permite que los inquilinos controlen sus propias actualizaciones en sus aplicaciones.

En el diagrama siguiente se muestra un sistema complejo que tiene un plano de control global, planos de control de sellos y planos de control de inquilinos.

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:

• Bohdan Cherchyk | Ingeniero superior de clientes, FastTrack para Azure
• Landon Pierce | Ingeniero de Clientes, FastTrack for Azure
• Daniel Scott-Raynsford | Partner Technology Strategist
• Arsen Vladimirskiy | Ingeniero de clientes principal, FastTrack for Azure

Para ver los perfiles no públicos de LinkedIn, inicie sesión en LinkedIn.

Paso siguiente

• Marco de buena arquitectura

Recursos relacionados

• Información general sobre consideraciones arquitectónicas
• Enfoques de arquitectura para los planos de control en soluciones multiinquilino