Considérations relatives aux plans de contrôle multilocataires

Une solution multilocataire a plusieurs plans, chacun ayant ses propres responsabilités. Le plan de données permet aux utilisateurs finaux et aux clients d’interagir avec le système. Le plan de contrôle est le composant qui gère les tâches générales pour tous les locataires, comme le contrôle d’accès, le provisionnement et la maintenance du système afin de prendre en charge les tâches de vos 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 finaux 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. Vos locataires le considèrent probablement comme le moyen approprié d’utiliser le système dans le but prévu. Le plan de contrôle est le composant qui 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. Si le système n’avait pas de plan de contrôle, les administrateurs devraient exécuter de nombreux processus manuels. Ou les tâches de plan de données et de plan de contrôle seraient mélangées, ce qui compliquerait la solution.

De nombreux systèmes complexes incluent des plans de contrôle. Par exemple, le plan de contrôle Azure, Azure Resource Manager, est un ensemble d’API, d’outils et de composants de back-end chargés du déploiement et de la configuration des ressources Azure. Le plan de contrôle Kubernetes gère de nombreuses tâches, comme le placement des 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 fournissent les détails dont vous avez besoin pour concevoir un plan de contrôle et définir son étendue.

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. 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 :

• Provisionner et gérer les ressources système dont le système a besoin pour servir la charge de travail, y compris les ressources propres au locataire. Votre plan de contrôle peut appeler et orchestrer un pipeline de déploiement responsable des déploiements, ou il peut exécuter les opérations de déploiement proprement dites
• Reconfigurez les ressources partagées pour connaître les nouveaux locataires. Par exemple, votre plan de contrôle peut configurer le routage réseau afin de garantir que le trafic entrant est mappé aux ressources du locataire approprié, ou vous pourriez devoir mettre à l’échelle votre capacité de ressources.
• Stocker et gérer la configuration de chaque locataire
• Gérer les événements de cycle de vie des locataires, notamment l’intégration, le déplacement et le retrait des locataires
• Suivre l’utilisation par chaque locataire de vos fonctionnalités et les performances du système
• Mesurer la consommation, par chaque locataire, des ressources de votre système. Les métriques de consommation peuvent informer vos systèmes de facturation ou être utilisées pour la gouvernance des ressources

Si vous utilisez le modèle de location multilocataire complet et que vous ne déployez pas de ressources propres au locataire, un plan de contrôle de base peut simplement suivre les locataires et leurs métadonnées associées. Par exemple, chaque fois qu’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 soit en mesure de répondre aux demandes du nouveau locataire.

En revanche, supposez que votre solution utilise un modèle de déploiement qui nécessite une infrastructure propre au locataire, comme le modèle automatisé à locataire unique. Dans ce scénario, votre plan de contrôle peut avoir des responsabilités supplémentaires, telles que le déploiement ou la reconfiguration de l’infrastructure Azure chaque fois que vous intégrez un nouveau locataire. Le plan de contrôle de votre solution doit probablement interagir avec les plans de contrôle des services et technologies que vous utilisez, comme Azure Resource Manager ou le plan de contrôle Kubernetes.

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

• Effectuer des opérations de maintenance automatisées. Les opérations de maintenance courantes incluent la suppression ou l’archivage d’anciennes données, la création et la gestion d’index de base de données, ainsi que la permutation des secrets et des certificats de chiffrement
• Allouer des locataires à des déploiements ou des empreintes existants, ce qui est parfois appelé placement de locataire
• Rééquilibrer les locataires existants parmi les empreintes de déploiement
• Intégrer des solutions de gestion des clients externes, telles que Microsoft Dynamics 365, pour suivre l’activité des clients

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

Vous devez soigneusement réfléchir à la quantité d’efforts à consacrer à la création d’un plan de contrôle pour votre solution. Les plans de contrôle par eux-mêmes ne fournissent pas de valeur immédiate pour le client ; il peut donc ne pas être facile de justifier les efforts d’ingénierie consacrés à la conception et à la construction d’un plan de contrôle de haute qualité. Toutefois, à mesure que votre système se développe et évolue, vous aurez de plus en plus besoin d’une gestion et d’opérations automatisées afin d’être capable de suivre le rythme de croissance.

Dans certaines situations, vous n’aurez peut-être pas besoin d’un plan de contrôle complet. Cette situation peut s’appliquer si votre système a moins de cinq locataires. Au lieu de cela, votre équipe peut assumer les responsabilités d’un plan de contrôle, et peut 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 d’un emplacement central pour suivre vos locataires et leurs configurations.

Si vous vous développez au-delà de quelques locataires, vous tirerez probablement profit d’un moyen de suivre chaque locataire et d’appliquer le monitoring à l’échelle de votre parc de ressources et de locataires. Vous pourriez également remarquer que votre équipe consacre de plus en plus de temps et d’efforts à la gestion des locataires. Ou il se peut que vous observiez des bogues ou des problèmes opérationnels dus à des incohérences dans la façon dont les membres de l’équipe effectuent les tâches de gestion. Si de telles situations se produisent, il est utile d’envisager de construire un plan de contrôle plus complet pour assumer ces responsabilités.

Concevoir un plan de contrôle

Une fois que vous avez 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. Vous devez le planifier soigneusement, comme vous le feriez pour les autres éléments de votre système.

Plans de contrôle bien conçus

Étant donné qu’un plan de contrôle est son propre système, il est important de prendre en compte les cinq piliers d’Azure Well-Architected Framework lorsque vous en concevez un. Les sections suivantes mettent en évidence certains domaines particuliers sur lesquels se concentrer.

Fiabilité

Les plans de contrôle sont souvent des composants stratégiques. Il est essentiel de planifier le niveau de résilience et de fiabilité dont votre plan de contrôle a besoin.

Réfléchissez à ce qui se passe si votre plan de contrôle n’est pas disponible. Dans les cas extrêmes, une panne de plan de contrôle peut entraîner l’indisponibilité de l’ensemble de votre solution. Même si votre plan de contrôle n’est pas un point de défaillance unique, une panne peut avoir certains des effets suivants :

• Votre système n’est pas en mesure d’intégrer de nouveaux locataires, ce qui peut affecter votre chiffre d’affaires et la croissance de votre entreprise
• 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 répondre à un incident de sécurité en désactivant ou en reconfigurant un locataire
• La dette de maintenance s’accumule, ce qui entraîne des dommages à long terme au système. Par exemple, si votre solution nécessite chaque nuit un nettoyage des anciennes données, vos disques risquent de se remplir ou vos performances de 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 être différents de ceux que vous proposez à vos clients.

Suivez les instructions d’Azure Well-Architected Framework pour créer des solutions fiables dans tout votre système, y compris votre plan de contrôle.

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. En fonction de sa conception et de ses fonctionnalités, un plan de contrôle peut être vulnérable à de nombreux types d’attaques, notamment :

• Un plan de contrôle peut avoir accès aux clés et aux secrets pour tous les locataires. Un attaquant qui a accès à votre plan de contrôle peut être en mesure d’accéder aux données ou aux ressources d’un locataire
• Un plan de contrôle peut souvent déployer de nouvelles ressources sur Azure. Les attaquants peuvent être en mesure d’exploiter votre plan de contrôle pour déployer leurs propres ressources dans vos abonnements, ce qui peut entraîner des frais importants
• Si un attaquant réussit à mettre votre plan de contrôle hors connexion, il peut y avoir des dommages immédiats et à long terme à votre système et à votre entreprise. Consultez Fiabilité pour obtenir des exemples de conséquences de l’indisponibilité d’un plan de contrôle

Lorsque vous concevez et implémentez un plan de contrôle, il est essentiel de suivre les bonnes pratiques de sécurité et de créer un modèle de menace complet pour documenter et atténuer les menaces et problèmes de sécurité potentiels dans votre solution. Pour plus d’informations, consultez l’aide Azure Well-Architected Framework pour la création de solutions sécurisées.

Excellence opérationnelle

Un plan de contrôle étant un composant critique, vous devez soigneusement réfléchir à la façon dont vous le déployez et l’utilisez en production.

Comme pour d’autres parties de votre solution, vous devez déployer des instances hors production de votre plan de contrôle afin de pouvoir tester minutieusement son fonctionnement. Si votre plan de contrôle effectue des opérations de déploiement, réfléchissez à la façon dont vos plans de contrôle hors production interagissent avec votre environnement Azure, et à l’abonnement Azure dans lequel vous déployez des ressources hors production.

Vous devez également planifier la façon dont vous gérez l’accès de votre équipe à votre plan de contrôle. Suivez les bonnes pratiques pour accorder uniquement les autorisations dont les membres de l’équipe ont besoin pour effectuer leurs tâches. En plus d’aider à éviter les incidents de sécurité, cette approche permet de réduire l’effet d’une mauvaise configuration accidentelle.

Composants

Il n’existe pas de modèle unique pour un plan de contrôle, et les composants que vous concevez et générez dépendent de vos besoins. En règle générale, un plan de contrôle se compose d’API et de composants Worker en arrière-plan. Dans certaines solutions, un plan de contrôle peut également inclure une interface utilisateur.

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

Nous vous recommandons de séparer les ressources de votre plan de contrôle de celles utilisées pour servir les plans de données de vos locataires. Par exemple, vous devez envisager d’utiliser des serveurs de base de données, des serveurs d’applications et des plans Azure App Service distincts, ainsi que d’autres composants. Il est souvent judicieux de conserver les ressources de votre plan de contrôle dans un groupe de ressources Azure distinct de ceux qui contiennent des ressources propres au locataire.

En isolant votre plan de contrôle des charges de travail des locataires, vous bénéficiez de plusieurs avantages :

• 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
• Il existe une cloison entre vos plans de contrôle et de données, ce qui permet d’éviter que les problèmes de voisins bruyants ne se propagent entre les plans de 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. En séparant le plan de contrôle des plans de données, vous réduisez la probabilité qu’une vulnérabilité de sécurité permette à des 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 opérations effectuées par un plan de contrôle sont souvent longues, et impliquent une coordination entre plusieurs systèmes. Les opérations peuvent également avoir des modes d’échec complexes. Lorsque vous concevez votre plan de contrôle, il est important d’utiliser une technologie appropriée pour coordonner des workflows ou des opérations de longue durée.

Par exemple, supposez que, lorsque vous intégrez un nouveau locataire, votre plan de contrôle exécute les actions suivantes dans l’ordre :

1. Déploiement d’une nouvelle base de données. Cette action est une opération de déploiement Azure. Elle 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 tierce 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 tierce. Vous avez remarqué qu’elle échouait par intermittence.
5. Mise à jour de votre système de gestion de la relation client (CRM) pour suivre le nouveau locataire. Cette action appelle une API tierce.

Si une étape de la séquence échoue, vous devez réfléchir à ce qu’il faut faire, par exemple :

• 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 l’échec de la mise à jour de votre système de facturation est acceptable, car votre équipe commerciale ajoutera manuellement le client
• Abandonner le workflow et déclencher un processus de récupération manuelle

Vous devez également prendre en compte l’expérience utilisateur pour chaque scénario d’échec.

Gérer les composants partagés

Un plan de contrôle doit savoir quels composants ne sont pas dédiés à des locataires spécifiques, mais sont partagés. 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. Chaque fois qu’un locataire est intégré, reconfiguré ou désactivé, votre plan de contrôle doit savoir quoi faire avec ces composants partagés.

Certains composants partagés peuvent devoir être reconfigurés chaque fois qu’un locataire est ajouté ou supprimé. Par exemple, supposons que vous disposez d’un profil Azure Front Door globalement partagé. Si vous ajoutez un locataire avec un nom de domaine personnalisé, votre plan de contrôle peut devoir mettre à jour la configuration du profil pour acheminer les requêtes 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, supposons que vous suivez une approche par compression de compartiment pour déployer les bases de données de vos locataires. Lorsqu’un nouveau locataire est intégré, vous ajoutez une nouvelle base de données Azure SQL pour ce locataire, puis vous l’affectez à un pool élastique Azure SQL. Vous avez peut-être déterminé 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 nouveau pool et commencer à utiliser ce pool pour les nouvelles bases de données client. Votre plan de contrôle doit prendre la responsabilité de gérer chacun de ces composants partagés, de les mettre à l’échelle et de les reconfigurer chaque fois que quelque chose change.

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, chacun avec des domaines de responsabilité différents. De nombreuses solutions multilocataires suivent le modèle Empreintes de déploiement et partitionnent les locataires sur plusieurs empreintes. Lorsque vous utilisez ce modèle, vous pouvez créer des plans de contrôle distincts pour les responsabilités globales et d’empreinte.

Plans de contrôle globaux

Un plan de contrôle global est généralement responsable de la gestion et du suivi globaux des locataires. Un plan de contrôle global peut avoir les responsabilités suivantes :

• Positionnement du locataire. Le plan de contrôle global détermine l’empreinte qu’un locataire doit utiliser. Il peut effectuer cette détermination en fonction de facteurs tels que la région du locataire, l’utilisation de la capacité de chaque empreinte, et les exigences du 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 sur tous les déploiements

Plans de contrôle d’empreinte

Un plan de contrôle d’empreinte est déployé dans chaque empreinte de déploiement, et est responsable des locataires et des ressources allouées à cette empreinte. Un plan de contrôle d’empreinte peut avoir les responsabilités suivantes :

• Création et gestion des ressources propres au locataire dans l’empreinte, telles que les bases de données et les conteneurs de stockage
• Gestion des ressources partagées, y compris le monitoring de la consommation des ressources partagées et le déploiement de nouvelles instances lorsqu’elles approchent de leur capacité maximale
• Exécution d’opérations de maintenance dans l’empreinte, telles que les opérations de gestion des index de base de données et de nettoyage

Le plan de contrôle de chaque empreinte est coordonné avec le plan de contrôle global. Par exemple, supposez qu’un nouveau locataire s’inscrit. Le plan de contrôle global est initialement responsable de la sélection d’une empreinte pour les ressources du locataire. Ensuite, le plan de contrôle global invite le plan de contrôle de l’empreinte à créer les ressources nécessaires pour le locataire.

Le diagramme suivant illustre un exemple de la façon dont les deux plans de contrôle peuvent coexister dans un système unique :

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 propre au locataire, comme l’accès utilisateur
• Opérations de maintenance lancées par le locataire, telles que la sauvegarde de données ou le téléchargement d’une sauvegarde précédente
• Gestion des mises à jour, si vous autorisez les locataires à contrôler leurs propres mises à jour de leurs applications

Le diagramme suivant montre un système complexe qui a un plan de contrôle global, des plans de contrôle d’empreinte et un plan de contrôle pour chaque locataire :

Contributeurs

Cet article est géré par Microsoft. Il a été écrit à l’origine par les contributeurs suivants.

Auteur principal :

• John Downs | Ingénieur client principal, FastTrack for Azure

Autres contributeurs :

• Mick Alberts | Rédacteur technique
• Bohdan Cherchyk | Ingénieur client senior, FastTrack for Azure
• Landon Pierce | Ingénieur client, FastTrack pour 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.

Étapes suivantes

• Vue d’ensemble des considérations sur l’architecture
• Azure Well-Architected Framework
• Approches architecturales pour les plans de contrôle dans les solutions multilocataires