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 finales y los clientes interactuar con el sistema. El plano de control es el componente que administra tareas de nivel superior en todos los inquilinos, como el control de acceso, el aprovisionamiento y el mantenimiento del sistema, 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 finales acceden al sistema para ver e introducir 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 probablemente piensen en él como la manera de usar el sistema para su propósito previsto. Por otro lado, el plano de control es el componente que incorpora nuevos inquilinos, crea bases de datos para cada inquilino y realiza otras operaciones de administración y mantenimiento. Si el sistema no tuviera un plano de control, los administradores tendrían que ejecutar muchos procesos manuales. O bien, las tareas del plano de datos y del plano de control se combinarían, lo que haría que la solución fuese excesivamente complicada.

Muchos sistemas complejos incluyen planos de control. Por ejemplo, el plano de control de Azure, Azure Resource Manager, es un conjunto de API, herramientas y componentes de back-end que son responsables de implementar y configurar los recursos de Azure. 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 proporcionan los detalles necesarios para definir el ámbito y diseñar 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. 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: Aprovisionamiento y administración de los recursos del sistema que el sistema necesita para atender la carga de trabajo, incluidos los recursos específicos del inquilino. Es posible que el plano de control invoque y orqueste una canalización de implementación responsable de las implementaciones, o puede que ejecute las operaciones de implementación él mismo.
• Configuración de recursos: Volver a configurar los recursos compartidos para tener en cuenta los nuevos inquilinos. Por ejemplo, puede que el plano de control configure el enrutamiento de red para asegurarse de que el tráfico entrante se asigna a los recursos correctos del inquilino, o puede que tenga que escalar la capacidad de los recursos.
• Configuración de inquilinos: Almacenar y administrar la configuración de cada inquilino.
• Administración del ciclo de vida del inquilino: Controlar los eventos de ciclo de vida del inquilino, como la incorporación, el traslado y la retirada de inquilinos.
• Telemetría: Realizar un seguimiento del uso de las características y el rendimiento del sistema por parte de cada inquilino.
• Seguimiento del consumo: Medir el consumo que cada inquilino hace de los recursos del sistema. Las métricas de consumo pueden informar a los sistemas de facturación o pueden usarse para la gobernanza de recursos.

Si usa el modelo de inquilinos multiinquilino completo y no implementa ningún recurso específico del inquilino, un plano de control básico podría simplemente realizar un seguimiento de los inquilinos y sus metadatos asociados. Por ejemplo, cada vez que 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, supongamos que 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. En este escenario, el plano de control podría tener más responsabilidades, como la implementación o reconfiguración de la infraestructura de Azure siempre que incorpore un nuevo inquilino. En este tipo de solución, el plano de control de la solución probablemente tenga que interactuar con los planos de control de los servicios y tecnologías que use, como Azure Resource Manager o el plano de control de Kubernetes.

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

• Operaciones de mantenimiento automatizadas: Entre las operaciones de mantenimiento comunes, se incluyen la eliminación o el archivado de datos antiguos, la creación y administración de índices de base de datos y la rotación de secretos y certificados criptográficos.
• Ubicación de inquilinos: Asignar inquilinos a implementaciones o stamps existentes, que pueden basarse en diversos criterios, como los objetivos de uso de stamps, los requisitos de inquilino y las estrategias de empaquetado de contenedores.
• Reequilibrio de inquilinos: Reequilibrar los inquilinos existentes en los stamps de implementación a medida que cambia su uso.
• Seguimiento de la actividad del cliente: Integrarse con soluciones externas de administración de clientes, como Microsoft Dynamics 365, para realizar un seguimiento de la actividad del cliente.

Ámbito de un plano de control

Debe tener muy en cuenta cuánto esfuerzo debe dedicar a crear un plano de control para la solución. Los planos de control por sí mismos no proporcionan valor inmediato al cliente, por lo que es posible que no sea fácil justificar el gasto de esfuerzos de ingeniería en el diseño y la compilación de un plano de control de alta calidad. Sin embargo, a medida que el sistema crezca y se escale, necesitará cada vez más administración y operaciones automatizadas para poder mantenerse al día con el crecimiento.

En determinadas situaciones, es posible que no necesite un plano de control completo. Esta situación puede darse si el sistema va a tener menos de 5-10 inquilinos. En su lugar, el equipo puede asumir las responsabilidades de un plano de control y puede usar operaciones y procesos manuales para incorporar y administrar los inquilinos. Sin embargo, sigue debiendo tener un proceso y un lugar central para realizar un seguimiento de los inquilinos 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. También puede observar que el equipo dedica una cantidad creciente de tiempo y esfuerzo a la administración de inquilinos. O bien, es posible que observe errores o problemas operativos debido a incoherencias en las formas en que los miembros del equipo realizan las tareas de administración. Si se producen estas situaciones, merece la pena considerar la posibilidad de crear un plano de control más completo para que asuma 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 determinar su arquitectura. Un plano de control es un componente importante. Debe planearlo cuidadosamente, igual que planearía los demás elementos del sistema.

Planos de control bien diseñados

Dado que un plano de control es su propio sistema, es importante tener en cuenta los cinco pilares de Azure Well-Architected Framework al diseñar uno. En las secciones siguientes se resaltan algunas áreas concretas en las que debe centrarse.

Confiabilidad

Los planos de control suelen ser componentes críticos. Es esencial que planee el nivel de resistencia y confiabilidad que necesita el plano de control.

Tenga en cuenta lo que sucede si el plano de control no está disponible. En casos extremos, una interrupción del plano de control puede provocar que toda la solución deje de estar disponible. Incluso si el plano de control no es un único punto de error, una interrupción podría tener algunos de los siguientes efectos:

• 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 responder a un incidente de seguridad deshabilitando o volviendo a configurar un inquilino.
• La deuda de mantenimiento se acumula, lo que da lugar a daños a largo plazo al sistema. Por ejemplo, si la solución requiere 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 que establezca para el plano de control pueden ser diferentes de los que ofrece a sus clientes.

Siga las instrucciones de Azure Well-Architected Framework para crear soluciones confiables en todo el sistema, incluido el plano de control.

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:

• Un plano de control podría tener acceso a claves y secretos de todos los inquilinos. Un atacante que tenga acceso al plano de control podría obtener acceso a los datos o recursos del inquilino.
• Un plano de control a menudo puede implementar nuevos recursos en Azure. Es posible que los atacantes puedan aprovechar el plano de control para implementar sus propios recursos en las suscripciones, lo que podría ocasionar cargos cuantiosos.
• Si un atacante logra poner el plano de control sin conexión, puede haber daños inmediatos y a largo plazo en el sistema y en la empresa. Consulte Confiabilidad para ver ejemplos de las consecuencias de que un plano de control no esté disponible.

Al diseñar e implementar un plano de control, es esencial que siga los procedimientos recomendados de seguridad y cree un modelo de amenazas completo para documentar y mitigar posibles amenazas y problemas de seguridad en la solución. Para obtener más información, consulte la guía de Azure Well-Architected Framework para crear soluciones seguras.

Excelencia operativa

Dado que un plano de control es un componente crítico, debe tener muy en cuenta cómo implementarlo y utilizarlo en producción.

Al igual que con otras partes de la solución, debe implementar instancias que no sean de producción del plano de control para poder 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 implementa los recursos que no son de producción. Además, planifique cómo limpiar rápidamente los recursos de prueba para que no se acumulen cargos por error.

También debe planear cómo rige el acceso de su equipo al plano de control. Siga los procedimientos recomendados para conceder solo los permisos que los miembros del equipo necesitan para realizar sus tareas. Además de ayudar a evitar incidentes de seguridad, este enfoque ayuda a reducir el efecto de una mala configuración por accidente.

Componentes

No hay ninguna plantilla única para un plano de control, y los componentes que diseñe y compile dependerán de sus requisitos. Normalmente, un plano de control consta de API y componentes de trabajo en segundo plano. En algunas soluciones, un plano de control también podría incluir 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

Se recomienda separar los recursos del plano de control de los que se usan para atender los planos de datos de los inquilinos. Por ejemplo, debe considerar la posibilidad de usar servidores de bases de datos, servidores de aplicaciones y otros componentes independientes. A menudo, es recomendable mantener los recursos del plano de control en un grupo de recursos de Azure independiente de los que contienen recursos específicos del inquilino.

Al aislar el plano de control de las cargas de trabajo de los inquilinos, obtendrá varias 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.
• Hay un mamparo entre los planos de control y de datos, lo que ayuda a evitar que los problemas de vecinos ruidosos se propaguen entre los planos de la solución.
• Los planos de control suelen ser sistemas con privilegios elevados con niveles altos de acceso. Al separar el plano de control de los planos de datos, se reduce la probabilidad de que una vulnerabilidad de seguridad permita 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

Las operaciones que realiza un plano de control suelen ser de larga duración e implican la coordinación entre varios sistemas. Las operaciones también pueden tener modos de error complejos. Al diseñar el plano de control, es importante usar una tecnología adecuada para coordinar operaciones o flujos de trabajo de larga duración.

Por ejemplo, supongamos que, al incorporar un nuevo inquilino, el plano de control ejecuta las siguientes acciones en secuencia:

1. Implementar una nueva base de datos. Esta acción es una 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 de terceros 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 de terceros. Ha observado que se produce un error intermitente.
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 de terceros.

Si se produce un error en algún paso de la secuencia, deberá pensar en qué debe hacer, como lo siguiente:

• 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 es aceptable si se produce un error en la actualización del sistema de facturación, ya que el equipo de ventas puede agregar manualmente al cliente más adelante.
• Abandonar el flujo de trabajo y desencadenar un proceso de recuperación manual.

También debe tener en cuenta cómo es la experiencia del usuario en cada escenario de error.

Administrar componentes compartidos

Un plano de control debe tener en cuenta los componentes que no están dedicados a inquilinos específicos, sino que son compartidos. 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. Cada vez que un inquilino se incorpora, se reconfigura o se quita, el plano de control debe saber qué hacer con estos componentes compartidos.

Es posible que algunos componentes compartidos deban volver a configurarse cada vez que se agrega o se quita un inquilino. Por ejemplo, supongamos que tiene un perfil de Azure Front Door compartido globalmente. Si agrega un inquilino con 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, supongamos que sigue un enfoque de empaquetado de contenedores para implementar las bases de datos de los inquilinos. Cuando se incorpora un nuevo inquilino, se agrega una nueva base de datos de Azure SQL para ese inquilino y, a continuación, se asigna a un grupo elástico de Azure SQL. Es posible que haya determinado que necesita aumentar los recursos asignados al grupo para 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 empezar a usar ese grupo para las nuevas bases de datos de inquilino. El plano de control debe asumir la responsabilidad de administrar cada uno de estos componentes compartidos, escalarlos y reconfigurarlos cada vez que cambie algo.

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, cada uno con diferentes áreas de responsabilidad. Muchas soluciones multiinquilino siguen el patrón de stamps de implementación e inquilinos de particiones en varios stamps. Al usar 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 es responsable de la administración y el seguimiento generales 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 stamp y los requisitos de nivel de servicio del inquilino.
• Incorporación y administración del ciclo de vida de los inquilinos. Estas responsabilidades incluyen el seguimiento de todos los inquilinos en todas las implementaciones.

Planos de control de stamp

Un plano de control de stamp se implementa en cada stamp de implementación y es responsable de los inquilinos y los recursos asignados a ese stamp. Un plano de control de stamp puede tener estas responsabilidades:

• Creación y administración de recursos específicos del inquilino dentro del stamp, como bases de datos y contenedores de almacenamiento.
• Administración de recursos compartidos, incluida la supervisión del consumo de recursos compartidos y la implementación de nuevas instancias cuando se aproximan a su capacidad máxima.
• Realización de operaciones de mantenimiento dentro del stamp, 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, supongamos que se registra un nuevo inquilino. Inicialmente, el plano de control global es responsable de seleccionar un stamp para los recursos del inquilino. 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 un ejemplo de cómo pueden coexistir los dos planos de control 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 la configuración específica del inquilino, como el acceso de usuario.
• Operaciones de mantenimiento iniciadas por el inquilino, como la copia de seguridad de datos o la descarga de una copia de seguridad anterior.
• Administración de 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 stamp y un plano de control para cada inquilino:

Colaboradores

Microsoft mantiene este artículo. Originalmente lo escribieron los siguientes colaboradores.

Autor principal:

• John Downs | Ingeniero principal de software

Otros colaboradores:

• Mick Alberts | Escritor técnico
• Bohdan Cherchyk | Ingeniero de clientes sénior, FastTrack for Azure
• Landon Pierce | Ingeniero de cliente, 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

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