Considérations relatives aux plans de contrôle multilocataires

Une solution multi-locataires comporte plusieurs plans, chacun ayant ses propres responsabilités. Le plan de données permet aux utilisateurs et aux clients d’interagir avec un système. Le plan de contrôle gère des tâches de niveau supérieur, telles que le contrôle d’accès, l’approvisionnement et la maintenance du système, sur tous les locataires pour prendre en charge les tâches des administrateurs de plateforme.

Cet article fournit des informations sur les responsabilités des plans de contrôle et sur la façon de concevoir un plan de contrôle qui répond à vos besoins.

Par exemple, prenez un système de comptabilité pour la gestion des enregistrements financiers. Plusieurs locataires stockent leurs enregistrements financiers dans le système. Lorsque les utilisateurs accèdent au système pour afficher et entrer leurs enregistrements financiers, ils utilisent le plan de données. Le plan de données est probablement le composant d’application principal de votre solution. Les locataires l’affichent généralement comme l’interface principale pour utiliser le système comme prévu.

En revanche, le plan de contrôle intègre de nouveaux locataires, crée des bases de données pour chaque locataire et effectue d’autres opérations de gestion et de maintenance. Sans plan de contrôle, les administrateurs doivent s’appuyer sur des processus manuels. Dans certains cas, les tâches de plan de données et de plan de contrôle deviennent enchevêtrées, ce qui surcomplique les solutions.

De nombreux systèmes complexes incluent un plan de contrôle. Par exemple, le plan de contrôle Azure, Azure Resource Manager, est un ensemble d’API, d’outils et de composants principaux qui déploient et configurent des ressources Azure. Et le plan de contrôle Kubernetes gère de nombreuses tâches, comme le placement de pods Kubernetes sur les nœuds Worker. Presque toutes les solutions SaaS (Software as a Service) ont un plan de contrôle pour gérer les tâches interlocataires.

Lorsque vous concevez des solutions multilocataires, vous devez prendre en compte les plans de contrôle. Les sections suivantes décrivent comment étendre et concevoir un plan de contrôle.

Responsabilités d’un plan de contrôle

Il n’existe aucun modèle unique pour un plan de contrôle ou ses responsabilités. Les exigences et l’architecture de votre solution déterminent ce que votre plan de contrôle doit faire et comment il fonctionne. Dans certaines solutions multilocataires, le plan de contrôle a un large éventail de responsabilités et est un système complexe à part entière. Dans d’autres solutions multilocataires, le plan de contrôle n’a que des responsabilités de base.

En général, un plan de contrôle peut avoir plusieurs des responsabilités principales suivantes :

• Gestion des ressources: Il provisionne et gère les ressources système qui servent la charge de travail, y compris les ressources spécifiques au locataire. Le plan de contrôle peut appeler et orchestrer un pipeline de déploiement ou exécuter directement des opérations de déploiement.

• Configuration des ressources : Il reconfigure les ressources partagées pour reconnaître les nouveaux locataires. Par exemple, le plan de contrôle peut configurer le routage réseau pour vous assurer que le trafic entrant atteint les ressources du locataire approprié, ou vous devrez peut-être mettre à l’échelle votre capacité de ressources.

• Configuration du locataire : Il stocke et gère la configuration de chaque locataire.

• Gestion du cycle de vie du locataire : Il gère les événements de cycle de vie des locataires, notamment l’intégration, le déplacement et le débordage des locataires.

• Télémétrie: Il effectue le suivi de l’utilisation de chaque locataire de vos fonctionnalités et des performances du système.

• Suivi de la consommation : Il mesure et agrège la consommation des ressources de chaque locataire. Les métriques de consommation peuvent informer vos systèmes de facturation ou prendre en charge la gouvernance des ressources.

Si vous utilisez le modèle multilocataire complet et que vous ne déployez pas de ressources spécifiques au locataire, un plan de contrôle de base peut uniquement suivre les locataires et leurs métadonnées associées. Par exemple, lorsqu’un nouveau locataire s’inscrit à votre service, le plan de contrôle peut mettre à jour les enregistrements appropriés dans une base de données afin que le reste du système puisse traiter les demandes du nouveau locataire.

En revanche, si votre solution utilise un modèle de déploiement qui nécessite une infrastructure spécifique au locataire, comme le modèle monolocataire automatisé, votre plan de contrôle peut avoir plus de responsabilités. Il peut être nécessaire de déployer ou de reconfigurer l’infrastructure Azure lorsque vous intégrez un nouveau locataire. Dans ce scénario, le plan de contrôle interagit probablement avec les plans de contrôle pour d’autres outils, tels que Resource Manager ou le plan de contrôle Kubernetes.

Les plans de contrôle avancés peuvent assumer davantage de responsabilités :

• Opérations de maintenance automatisées : Il effectue des opérations de maintenance courantes, notamment la suppression ou l’archivage d’anciennes données, la création et la gestion des index de base de données et la rotation des secrets et des certificats de chiffrement.

• Placement des locataires : il affecte les locataires à des déploiements ou des tampons existants en fonction de critères tels que les objectifs d’utilisation des tampons, les exigences des locataires et les stratégies de remplissage des bacs.

• Rééquilibrage des locataires : il rééquilibre les locataires existants entre les tampons de déploiement à mesure que leur utilisation évolue.

• Suivi des activités des clients : Il s’intègre à des solutions de gestion des clients externes, telles que Dynamics 365, pour suivre l’activité des clients.

Définir l’étendue d’un plan de contrôle

Réfléchissez soigneusement à l’effort de création d’un plan de contrôle pour votre solution. Un plan de contrôle ne fournit pas directement de valeur client immédiate, ce qui peut rendre difficile de justifier l’effort d’ingénierie sur la conception et la construction d’un plan de contrôle de haute qualité. Toutefois, à mesure que votre système augmente et se met à l’échelle, vous avez de plus en plus besoin de gestion et d’opérations automatisées pour suivre votre croissance.

Dans certaines situations, vous n’aurez peut-être pas besoin d’un plan de contrôle complet. Cette approche peut fonctionner si votre système a moins de 10 locataires. Votre équipe peut assumer les responsabilités du plan de contrôle et utiliser des opérations et des processus manuels pour intégrer et gérer les locataires. Toutefois, vous devez toujours disposer d’un processus et maintenir un emplacement central pour suivre vos locataires et leurs configurations.

Au fur et à mesure que vous dépassez quelques locataires, vous pouvez tirer parti du suivi de chaque locataire et de l’application de la surveillance dans votre flotte de ressources et de locataires. Vous remarquerez peut-être que votre équipe consacre un temps et un effort croissants à la gestion des locataires. Vous pouvez également remarquer des bogues ou des problèmes opérationnels en raison d’incohérences dans la façon dont les membres de l’équipe effectuent des tâches de gestion. Si ces situations se produisent, envisagez de créer un plan de contrôle plus complet pour assumer ces responsabilités.

Concevoir un plan de contrôle

Après avoir déterminé les exigences et l’étendue de votre plan de contrôle, vous devez le concevoir et l'architecturer. Un plan de contrôle est un composant important et mérite le même niveau de planification que toute autre partie de votre architecture.

Considérations

Ces considérations implémentent les piliers d’Azure Well-Architected Framework, un ensemble de principes directeurs que vous pouvez utiliser pour améliorer la qualité d’une charge de travail. Pour plus d’informations, consultez Well-Architected Framework.

Un plan de contrôle fonctionne comme son propre système. Vous devez donc prendre en compte les cinq piliers de l’infrastructureWell-Architected lorsque vous en concevez un. Les sections suivantes mettent en évidence des domaines particuliers sur lesquels se concentrer.

Fiabilité

La fiabilité permet de garantir que votre application peut respecter les engagements que vous avez pris envers vos clients. Pour en savoir plus, consultez Liste de contrôle de l'examen de la conception pour la fiabilité.

Les plans de contrôle servent souvent de composants essentiels. Vous devez planifier le niveau de résilience et de fiabilité approprié dont votre plan de contrôle a besoin.

Tenez compte de l’impact d’une panne du plan de commande. Dans les cas extrêmes, une panne peut rendre votre solution entière indisponible. Même si votre plan de contrôle n’est pas un point de défaillance unique, une panne peut entraîner les problèmes suivants :

• Votre système ne peut pas intégrer de nouveaux locataires, ce qui peut affecter votre croissance commerciale et commerciale.

• Votre système ne peut pas gérer les locataires existants, ce qui entraîne davantage d’appels à votre équipe de support technique

• Vous ne pouvez pas mesurer la consommation des locataires ni les facturer pour leur utilisation, ce qui entraîne une perte de revenus

• Vous ne pouvez pas désactiver ou reconfigurer un locataire en réponse à un incident de sécurité.

• La dette de maintenance s’accumule, ce qui entraîne des dommages à long terme au système. Par exemple, si votre solution nécessite un nettoyage nocturne des anciennes données, vos disques peuvent être saturés ou vos performances peuvent se dégrader.

Définissez des objectifs de niveau de service pour votre plan de contrôle, notamment des cibles de disponibilité, l’objectif de temps de récupération (RTO) et l’objectif de point de récupération (RPO). Les objectifs que vous définissez pour votre plan de contrôle peuvent différer des objectifs que vous proposez à vos clients.

Sécurité

La sécurité offre des garanties contre les attaques délibérées et l’utilisation abusive de vos précieuses données et systèmes. Pour en savoir plus, consultez Liste de contrôle de l'examen de la conception pour la sécurité.

Les plans de contrôle sont souvent des systèmes hautement privilégiés. Les problèmes de sécurité au sein d’un plan de contrôle peuvent avoir des conséquences catastrophiques. Selon sa conception et ses fonctionnalités, un plan de contrôle peut être vulnérable à de nombreux types d’attaques différents, notamment les types suivants :

• Accès non autorisé aux secrets : un plan de contrôle peut avoir accès aux clés et aux secrets de tous les locataires. Un attaquant qui a accès à votre plan de contrôle pourrait accéder aux données ou aux ressources de n’importe quel locataire.

• Abus des fonctionnalités de déploiement : Un plan de contrôle peut souvent déployer de nouvelles ressources sur Azure. Les attaquants peuvent exploiter votre plan de contrôle pour déployer leurs propres ressources dans vos abonnements et entraîner des frais importants.

• Déni de service : Si un attaquant désactive correctement votre plan de contrôle, des dommages immédiats et à long terme peuvent se produire sur votre système et votre entreprise. Pour connaître les conséquences potentielles du temps d’arrêt du plan de contrôle, consultez Fiabilité.

Lorsque vous concevez et implémentez un plan de contrôle, vous devez suivre les bonnes pratiques de sécurité et créer un modèle de menace complet. Ce modèle doit identifier et atténuer les menaces potentielles et les problèmes de sécurité dans votre solution.

Excellence opérationnelle

L’excellence opérationnelle couvre les processus opérationnels qui déploient une application et la maintiennent en production. Pour plus d’informations, consultez la Liste de contrôle de l'examen de la conception pour l'excellence opérationnelle.

Un plan de contrôle est un composant critique. Vous devez donc examiner attentivement la façon dont vous déployez et utilisez-le en production.

Comme d’autres parties de votre solution, vous devez déployer des instances hors production de votre plan de contrôle afin de pouvoir tester soigneusement leurs fonctionnalités. Si votre plan de contrôle effectue des opérations de déploiement, envisagez la façon dont vos plans de contrôle hors production interagissent avec votre environnement Azure et l’abonnement Azure dans lequel déployer des ressources hors production. Planifiez le nettoyage rapide des ressources de test afin qu’elles n’accumulent pas accidentellement des frais.

Planifiez également comment régir l’accès de votre équipe à votre plan de contrôle. Accordez uniquement les autorisations dont les membres de l’équipe ont besoin pour effectuer leurs tâches. Cette approche permet d’éviter les incidents de sécurité et de réduire l’effet d’une mauvaise configuration accidentelle.

Composants

Il n’existe aucun modèle unique pour la création d’un plan de contrôle. Les composants que vous concevez et générez dépendent de vos besoins. La plupart des plans de contrôle sont constitués d’API et de composants de travail en arrière-plan. Dans certaines solutions, un plan de contrôle inclut également une interface utilisateur, que votre équipe ou même vos clients peuvent utiliser.

Isoler votre plan de contrôle des charges de travail client

Vous devez séparer les ressources de votre plan de contrôle des ressources qui servent les plans de données de vos locataires. Par exemple, utilisez des serveurs de base de données distincts, des serveurs d’applications et d’autres composants. Conservez les ressources du plan de contrôle dans un groupe de ressources Azure dédié, séparé des ressources spécifiques au locataire.

L’isolation du plan de contrôle offre les avantages suivants :

• Vous pouvez configurer la mise à l’échelle séparément. Par exemple, votre plan de contrôle peut avoir des besoins en ressources réguliers, et les ressources de vos locataires peuvent être mises à l’échelle de manière élastique en fonction de leurs besoins

• Une séparation claire crée une cloison entre vos plans de contrôle et les plans de données, ce qui permet d’empêcher les problèmes de voisin bruyants de se propager dans votre solution.

• Les plans de contrôle sont généralement des systèmes hautement privilégiés qui ont des niveaux d’accès élevés. L’isolation du plan de contrôle réduit la probabilité d’une vulnérabilité de sécurité permettant aux attaquants d’élever leurs autorisations sur l’ensemble de votre système.

• Vous pouvez déployer des configurations réseau et de pare-feu distinctes. Les plans de données et les plans de contrôle nécessitent généralement différents types d’accès réseau

Orchestrer des séquences d’opérations de longue durée

Les plans de contrôle effectuent souvent des opérations de longue durée qui nécessitent une coordination entre plusieurs systèmes. Ces opérations peuvent également avoir des modes d’échec complexes. Vous devez donc choisir des technologies qui prennent en charge des opérations ou des flux de travail longs.

Par exemple, lorsque vous intégrez un nouveau locataire, votre plan de contrôle peut exécuter les actions suivantes dans la séquence :

1. Déploiement d’une nouvelle base de données. Cette opération de déploiement Azure peut prendre plusieurs minutes.

2. Mise à jour de votre catalogue de métadonnées de locataire. Cette action peut impliquer l’exécution d’une commande sur une base de données Azure SQL.

3. Envoi d’un e-mail de bienvenue au nouveau locataire. Cette action appelle une API non-Microsoft pour envoyer l’e-mail.

4. Mise à jour de votre système de facturation de façon à préparer la facturation du nouveau locataire. Cette action appelle une API non-Microsoft qui échoue occasionnellement.

5. Mise à jour de votre système de gestion de la relation client (CRM) pour suivre le nouveau locataire. Cette action appelle une API non-Microsoft.

Si une étape de la séquence échoue, réfléchissez à la façon de répondre :

• Recommencer l’opération qui a échoué. Par exemple, si votre commande Azure SQL à l’étape 2 échoue avec une erreur temporaire, vous pouvez réessayer

• Passez à l’étape suivante. Par exemple, vous pouvez décider que vous pouvez autoriser l’échec de la mise à jour vers votre système de facturation, car votre équipe commerciale peut ajouter manuellement le client ultérieurement.

• Abandonner le workflow et déclencher un processus de récupération manuelle

Considérez également l’expérience utilisateur pour chaque scénario d’échec.

Gérer les composants partagés

Un plan de contrôle doit reconnaître tous les composants partagés plutôt que dédiés à des locataires spécifiques. Certains composants peuvent être partagés entre tous les locataires d’une empreinte. D’autres composants peuvent être partagés entre toutes les empreintes d’une région, ou même partagés globalement entre toutes les régions et les empreintes. Lorsque vous intégrez, reconfigurez ou offboardez un locataire, votre plan de contrôle doit savoir comment gérer ces composants partagés.

Certains composants partagés nécessitent une reconfiguration lorsque les locataires sont ajoutés ou supprimés. Par exemple, supposons que vous disposez d’un profil Azure Front Door globalement partagé. Si vous ajoutez un locataire qui a un nom de domaine personnalisé, votre plan de contrôle peut avoir besoin de mettre à jour la configuration du profil pour acheminer les demandes de ce nom de domaine vers l’application appropriée. De même, lorsqu’un locataire est retiré, votre plan de contrôle peut avoir besoin de supprimer le nom de domaine personnalisé du profil Azure Front Door pour éviter les attaques de prise de contrôle de sous-domaine.

Les composants partagés peuvent avoir des règles de mise à l’échelle complexes que votre plan de contrôle doit suivre. Par exemple, si vous utilisez une approche bin-package pour déployer les bases de données de vos locataires, le plan de contrôle doit affecter chaque nouvelle base de données à un pool élastique Azure SQL.

Vous pouvez déterminer que vous devez augmenter les ressources allouées à votre pool pour chaque dixième base de données que vous ajoutez. Lorsque vous ajoutez ou supprimez un locataire, votre plan de contrôle doit réévaluer la configuration du pool et décider s’il faut modifier les ressources du pool. Lorsque vous atteignez le nombre maximal de bases de données que vous pouvez affecter à un pool élastique unique, vous devez créer un pool et utiliser ce pool pour les nouvelles bases de données client. Votre plan de contrôle doit gérer chacun de ces composants partagés, notamment les mettre à l’échelle et les reconfigurer lorsque des modifications se produisent.

Lorsque votre plan de contrôle gère les composants partagés, il est important de connaître les conditions de concurrence, qui peuvent se produire lorsque plusieurs opérations se produisent en parallèle. Par exemple, si vous intégrez un nouveau locataire en même temps que vous retirez un autre locataire, vous devez vous assurer que votre état final est cohérent et répond à vos besoins de mise à l’échelle.

Utiliser plusieurs plans de contrôle

Dans un environnement complexe, vous devrez peut-être utiliser plusieurs plans de contrôle qui gèrent différentes zones. De nombreuses solutions multilocataires suivent le modèle Empreintes de déploiement et partitionnent les locataires sur plusieurs empreintes. Dans ce modèle, vous pouvez créer des plans de contrôle distincts pour les responsabilités globales et locales.

Plans de contrôle globaux

Un plan de contrôle global gère généralement la gestion globale et le suivi des locataires. Un plan de contrôle global peut avoir les responsabilités suivantes :

• Placement des locataires : le plan de contrôle global détermine le tampon qu’un locataire doit utiliser. Il peut faire cette détermination en fonction de facteurs tels que la région du locataire, l'utilisation de la capacité de chaque module et les exigences de niveau de service du locataire.

• Intégration des locataires et gestion du cycle de vie : Ces responsabilités incluent le suivi de tous les locataires entre les déploiements.

Plans de contrôle d’empreinte

Chaque tampon de déploiement comprend son propre plan de contrôle des tampons, qui gère les locataires et les ressources allouées à ce tampon. Un plan de contrôle d’empreinte peut avoir les responsabilités suivantes :

• Approvisionnement des ressources du locataire : Il crée et gère des ressources spécifiques au locataire dans le cluster, comme les bases de données et les conteneurs de stockage.

• Gestion des ressources partagées : Il surveille la consommation des ressources partagées et déploie de nouvelles instances lorsqu’elles approchent de leur capacité maximale.

• Opérations de maintenance : Il gère les tâches au sein du tampon, telles que la gestion des index de base de données et les opérations de nettoyage.

Le plan de contrôle de chaque empreinte est coordonné avec le plan de contrôle global. Par exemple, si un nouveau locataire s’inscrit, le plan de contrôle global peut initialement sélectionner un tampon pour les ressources du locataire. Ensuite, le plan de contrôle global requête le plan de contrôle du tampon afin de créer les ressources nécessaires pour le locataire.

Le diagramme suivant montre comment deux plans de contrôle peuvent coexister dans un seul système.

Plans de contrôle de locataire

Les locataires peuvent utiliser un plan de contrôle au niveau du locataire pour gérer leurs propres ressources logiques ou physiques. Un plan de contrôle de locataire peut avoir les responsabilités suivantes :

• Gestion de la configuration : Il gère la configuration spécifique au locataire, comme l’accès utilisateur.

• Opérations de maintenance initiées par le locataire : Il prend en charge les opérations telles que la sauvegarde de données ou le téléchargement de sauvegardes précédentes.

• Gestion des mises à jour : Elle effectue des mises à jour si vous autorisez les locataires à contrôler leurs propres mises à jour de leurs applications.

Le diagramme suivant illustre un système complexe qui comprend un plan de contrôle global, des plans de contrôle de tampon et des plans de contrôle de locataire.

Contributeurs

Microsoft gère cet article. Les contributeurs suivants ont écrit cet article.

Auteur principal :

• John Downs | Ingénieur logiciel principal, modèles Azure & Pratiques

Autres contributeurs :

• Bohdan Cherchyk | Ingénieur client senior, FastTrack for Azure
• Landon Pierce | Ingénieur client, Microsoft FastTrack for Azure
• Daniel Scott-Raynsford | Stratégiste de la technologie partenaire
• Arsen Vladimirskiy | Ingénieur client principal, FastTrack for Azure

Pour afficher les profils LinkedIn non publics, connectez-vous à LinkedIn.

Étape suivante

• FrameworkWell-Architected

Ressources associées

• Présentation des considérations architecturales
• Approches architecturales pour les plans de contrôle dans les solutions multi-locataires