Architecture multilocataire et Stockage Azure

Stockage Azure est un service de base que presque toutes les solutions utilisent. Les solutions mutualisées utilisent souvent le stockage d'objets blob, de fichiers, de files d’attente et de tables. Cet article décrit les fonctionnalités de Stockage pour les solutions mutualisées. Il fournit des liens vers des conseils qui peuvent vous aider à planifier l’utilisation du stockage.

Fonctionnalités de stockage qui prennent en charge l’architecture mutualisée

Stockage Azure inclut de nombreuses fonctionnalités qui prennent en charge les environnements multi-locataires.

Signatures d’accès partagé

Lorsque vous utilisez le stockage à partir d’une application cliente, déterminez s’il faut acheminer les demandes du client via un autre composant que vous contrôlez, comme un réseau de distribution de contenu ou une API. Vous pouvez également autoriser les clients à se connecter directement à votre compte de stockage. L’envoi de requêtes via un autre composant peut offrir des avantages tels que la mise en cache des données à la périphérie de votre réseau.

L’accès direct du client au stockage pour télécharger ou charger des données peut améliorer les performances, en particulier pour les objets blob volumineux ou de nombreux fichiers. Elle réduit également la charge sur vos applications et serveurs back-end et réduit le nombre de tronçons réseau.

Une signature d’accès partagé (SAP) vous permet de fournir en toute sécurité à vos applications clientes un accès aux objets dans le stockage.

Vous pouvez utiliser une SAS pour restreindre l'étendue des opérations qu'un client peut effectuer et sur quels objets il peut effectuer ces opérations. Par exemple, si vous disposez d’un compte de stockage partagé pour tous vos locataires et que vous stockez les données du locataire A dans un conteneur d’objets blob nommé tenanta, vous pouvez créer une SAP qui permet uniquement aux utilisateurs du locataire A d’accéder à ce conteneur. Pour plus d’informations sur les approches qui isolent les données de vos locataires dans un compte de stockage, consultez modèles d’isolation.

Utilisez le modèle de clé valet pour générer des jetons SAS contraints et limités à partir de votre couche d'application. Par exemple, si votre application multilocataire permet aux utilisateurs de charger des vidéos, votre API ou la couche Application peut authentifier le client à l’aide du système d’authentification de votre application. Vous pouvez ensuite fournir un SAS qui permet au client de charger un fichier vidéo vers un chemin spécifique d'un blob dans un conteneur désigné. Le client charge ensuite le fichier directement dans le compte de stockage, ce qui réduit la bande passante et la charge sur votre API. Si le client tente de lire des données à partir du conteneur d’objets blob ou d’écrire des données dans un autre conteneur du compte de stockage, Storage bloque la requête. La SAS expire après une période configurable.

Les stratégies d’accès stockées étendent la fonctionnalité SAP, ce qui vous permet de définir une stratégie unique à utiliser lorsque vous émettez plusieurs signatures.

Contrôle d’accès basé sur l’identité

Stockage Azure fournit également un contrôle d’accès basé sur l’identité via l’ID Microsoft Entra. Cette fonctionnalité permet un contrôle d’accès basé sur des attributs, qui fournit un accès précis aux chemins d’objet blob ou aux objets blob étiquetés avec un ID de locataire spécifique.

Gestion du cycle de vie

Lorsque vous utilisez le stockage de blobs dans une solution multilocataire, vos locataires peuvent nécessiter des stratégies différentes pour la conservation des données. Lorsque vous stockez de grands volumes de données, vous pouvez également déplacer automatiquement des données spécifiques au locataire vers les niveaux de stockage froid ou archive afin d’optimiser les coûts.

Utilisez des stratégies de gestion du cycle de vie pour définir le cycle de vie de l’objet blob pour tous les locataires ou pour un sous-ensemble de locataires. Vous pouvez appliquer une stratégie de gestion du cycle de vie aux conteneurs d’objets blob ou à un sous-ensemble d’objets blob au sein d’un conteneur. Toutefois, les stratégies de gestion du cycle de vie ont des limites sur le nombre de règles que vous pouvez spécifier. Planifiez et testez soigneusement votre configuration dans un environnement multilocataire. Envisagez de déployer plusieurs comptes de stockage si votre nombre de règles dépasse les limites.

Stockage non modifiable

Lorsque vous configurez un stockage d’objets blob immuable sur des conteneurs de stockage à l’aide de stratégies de rétention basées sur le temps, le stockage empêche la suppression ou la modification des données avant une heure spécifiée. Cette application se produit au niveau de la couche de compte de stockage et s’applique à tous les utilisateurs, y compris les administrateurs de votre organisation.

Utilisez un stockage immuable si les locataires doivent conserver des données ou des enregistrements en raison des exigences légales ou de conformité. Évaluez la façon dont cette fonctionnalité correspond à votre cycle de vie de locataire. Par exemple, si un locataire est désactivé et demande la suppression des données, vous ne pourrez peut-être pas répondre à leur demande. Si vous utilisez un stockage immuable pour les données client, envisagez de résoudre ce problème en termes de service.

Copie côté serveur

Dans un système multilocataire, vous devrez peut-être déplacer des données d’un compte de stockage vers un autre. Par exemple, si vous déplacez un locataire entre des empreintes de déploiement ou rééquilibrez un ensemble partitionné de comptes de stockage, vous devez copier ou déplacer les données d’un locataire spécifique. Lorsque vous avez de grands volumes de données, utilisez des API de copie côté serveur pour réduire le temps de migration.

L’outil AzCopy est une application que vous pouvez exécuter à partir de votre ordinateur ou d’une machine virtuelle pour gérer le processus de copie. AzCopy est compatible avec la fonctionnalité de copie côté serveur et fournit une interface de ligne de commande scriptable que vous pouvez exécuter à partir de vos solutions. Vous pouvez également utiliser AzCopy pour charger et télécharger de grands volumes de données.

Si vous devez utiliser les API de copie côté serveur directement à partir de votre code, envisagez d’utiliser les options suivantes :

• Placer un bloc à partir de l’API d’URL
• Placer la page à partir de l’API d’URL
• Ajouter un bloc à partir de l’API d’URL
• Copier un objet blob à partir de l’API d’URL pour les objets blob plus petits

Réplication d’objets

La réplication d’objets est une fonctionnalité qui réplique automatiquement et de manière asynchrone les données entre un compte de stockage source et de destination. Dans une solution multilocataire, utilisez cette fonctionnalité pour répliquer en continu les données entre des tampons de déploiement ou lorsque vous implémentez le modèle Geode.

Chiffrement

Stockage Azure vous permet de fournir des clés de chiffrement pour vos données. Dans une solution mutualisée, envisagez de combiner cette fonctionnalité avec des étendues de chiffrement. Vous pouvez affecter différentes clés de chiffrement à différents locataires, même lorsque leurs données résident dans le même compte de stockage. Ces fonctionnalités permettent ensemble aux locataires de contrôler leurs propres données. S’ils désactivent leur compte, la suppression de la clé de chiffrement garantit que personne ne peut accéder à leurs données.

Supervision

Dans une solution mutualisée, déterminez si vous devez mesurer la consommation pour chaque locataire. Définissez les métriques spécifiques à suivre, telles que la capacité de stockage utilisée par chaque locataire ou le nombre d’opérations effectuées pour les données de chaque locataire. Vous pouvez également utiliser l’allocation de coûts pour suivre le coût de l’utilisation de chaque locataire et activer la rétrofacturation sur plusieurs abonnements.

Stockage Azure fournit des fonctionnalités de supervision intégrées. Tenez compte des services que vous envisagez d’utiliser dans le compte de stockage. Par exemple, lorsque vous utilisez des objets blob, vous pouvez afficher la capacité totale d’un compte de stockage, mais pas un seul conteneur. Lorsque vous utilisez des partages de fichiers, vous pouvez afficher la capacité de chaque partage, mais pas chaque dossier.

Vous pouvez également journaliser toutes les requêtes vers le stockage, puis agréger et analyser ces journaux. Cette approche offre une flexibilité lorsque vous agrégez et regroupez des données pour chaque locataire. Toutefois, dans les solutions qui créent des volumes élevés de requêtes vers le stockage, évaluez si le bénéfice que vous tirez de cette approche justifie le coût de capture et de traitement de ces logs.

L’inventaire Stockage Azure offre une autre approche pour mesurer la taille totale d’un conteneur de blobs.

Modèles d’isolation

Lorsque vous utilisez le stockage dans un système multilocataire, déterminez le niveau d’isolation à appliquer. Stockage Azure prend en charge plusieurs modèles d’isolation.

Comptes de stockage pour chaque locataire

Le niveau d’isolation le plus fort utilise un compte de stockage dédié pour chaque locataire. Ce modèle garantit une isolation complète des clés de stockage, que vous pouvez faire pivoter indépendamment. Il vous permet également de mettre à l’échelle votre solution au-delà des limites et des quotas pour chaque compte de stockage. Toutefois, vous devez également prendre en compte le nombre maximal de comptes de stockage autorisés dans un seul abonnement Azure.

Chaque composant de stockage fournit d'autres options pour l'isolement des locataires.

Modèles d’isolation du stockage de blobs

Le tableau suivant résume les différences entre les principaux modèles d'isolation locative pour les objets blob de stockage.

Conteneurs de blobs partagés

Lorsque vous travaillez avec le stockage d’objets blob, vous pouvez utiliser un conteneur d’objets blob partageable qui inclut des chemins d’accès d’objets blob pour séparer les données de chaque client.

Cette approche est simple à implémenter, mais dans de nombreux scénarios, les chemins d'accès des blobs ne fournissent pas suffisamment d'isolation entre les locataires. Le stockage d’objets blob ne prend pas en charge une véritable structure de répertoires ou de dossiers. Vous ne pouvez donc pas affecter l’accès à tous les objets blob dans un chemin d’accès spécifié. Toutefois, le stockage offre une possibilité de lister ou d’énumérer des objets blob commençant par un préfixe spécifié. Cette fonctionnalité prend en charge les scénarios qui utilisent des conteneurs d’objets blob partagés et qui ne nécessitent pas de contrôle d’accès au niveau du répertoire.

La fonctionnalité d’espace de noms hiérarchique dans Le stockage fournit une structure de répertoire ou de dossiers plus forte, y compris un contrôle d’accès spécifique au répertoire. Cette fonctionnalité prend en charge les scénarios multilocataires où vous avez des conteneurs d’objets blob partagés, mais que vous souhaitez accorder l’accès aux données d’un seul locataire.

Dans certaines solutions multilocataires, il se peut que vous n'ayez besoin que de stocker un seul blob ou un ensemble de blobs pour chaque locataire, comme les icônes de locataire afin de personnaliser une interface utilisateur. Un seul conteneur d’objets blob partagé peut fonctionner pour ces scénarios. Vous pouvez utiliser l’identificateur de locataire comme nom d’objet blob et lire l’objet blob spécifique au lieu d’énumérer un chemin d’accès d’objet blob.

Lorsque vous utilisez des conteneurs partagés, déterminez si vous devez suivre les données et l’utilisation du stockage pour chaque locataire. Pour en savoir plus, consultez Monitoring.

Conteneurs d’objets blob pour chaque locataire

Vous pouvez créer des conteneurs blob individuels pour chaque locataire au sein d’un compte de stockage unique. Il n’existe aucune limite au nombre de conteneurs d’objets blob que vous pouvez créer dans un compte de stockage.

Lorsque vous créez un conteneur pour chaque locataire, vous pouvez utiliser le contrôle d’accès au stockage, y compris saS, pour gérer l’accès pour les données de chaque locataire. Vous pouvez également surveiller facilement la capacité utilisée par chaque conteneur.

Modèles d’isolation du stockage de fichiers

Le tableau suivant résume les différences entre les principaux modèles d’isolation de location pour les fichiers de stockage.

Partages de fichiers partagés

Lorsque vous travaillez avec des partages de fichiers, vous pouvez utiliser un partage de fichiers partagé qui inclut des chemins de fichier pour séparer les données de chaque locataire.

Lorsque votre application communique via le protocole SMB (Server Message Block) et que vous utilisez les services de domaine Active Directory localement ou dans Azure, les partages de fichiers prennent en charge l’autorisation au niveau du partage et du répertoire ou du fichier.

Dans d’autres scénarios, envisagez d’utiliser SAS pour accorder l’accès à des partages de fichiers ou des fichiers spécifiques. SAS ne prend pas en charge l’octroi de l’accès aux répertoires.

Lorsque vous utilisez des partages de fichiers partagés, déterminez si vous devez suivre les données et l’utilisation du stockage pour chaque locataire. Pour en savoir plus, consultez Monitoring.

Partages de fichiers pour chaque locataire

Vous pouvez créer des partages de fichiers individuels pour chaque locataire au sein d’un compte de stockage unique. Il n’existe aucune limite au nombre de partages de fichiers que vous pouvez créer dans un compte de stockage.

Pour ce scénario, vous pouvez utiliser le contrôle d’accès au stockage, y compris saS, pour gérer l’accès pour les données de chaque locataire. Vous pouvez également surveiller facilement la capacité utilisée par chaque partage de fichiers.

Modèles d’isolation pour le stockage en table

Le tableau suivant résume les différences entre les principaux modèles d’isolation de location pour les tables de stockage.

Tables partagées avec des clés de partition pour chaque client

Lorsque vous utilisez le stockage de tables qui inclut une table partagée unique, envisagez d’utiliser la prise en charge intégrée du partitionnement. Chaque entité doit inclure une clé de partition, telle qu’un identificateur de locataire.

Les jetons et stratégies SAP vous permettent de spécifier une plage de clés de partition. Stockage Azure garantit que les requêtes qui contiennent la signature peuvent uniquement accéder aux plages de clés de partition spécifiées. Vous pouvez implémenter le modèle de clé Valet, qui permet aux clients non approuvés d’accéder à la partition d’un seul locataire sans affecter d’autres locataires.

Pour les applications à grande échelle, tenez compte du débit maximal de chaque partition de table et du compte de stockage.

Tables pour chaque locataire

Vous pouvez créer des tables individuelles pour chaque locataire au sein d’un compte de stockage unique. Il n’existe aucune limite au nombre de tables que vous pouvez créer dans un compte de stockage.

Pour ce scénario, vous pouvez utiliser le contrôle d’accès au stockage, y compris saS, pour gérer l’accès pour les données de chaque locataire.

Modèles d’isolation du stockage de files d’attente

Le tableau suivant résume les différences entre les principaux modèles d’isolation de location pour les files d’attente de stockage.

Files d’attente partagées

Si vous partagez une file d’attente, tenez compte des quotas et des limites qui s’appliquent. Dans les solutions qui ont un volume de requêtes élevé, déterminez si le débit cible de 2 000 messages par seconde fonctionne pour votre scénario.

Les files d’attente ne fournissent pas de partitionnement ou de sous-file d’attente. Par conséquent, toutes les données des locataires peuvent être entremêlées.

Files d’attente pour chaque locataire

Vous pouvez créer des files d’attente individuelles pour chaque locataire au sein d’un compte de stockage unique. Il n’existe aucune limite au nombre de files d’attente que vous pouvez créer dans un compte de stockage.

Pour ce scénario, vous pouvez utiliser le contrôle d’accès au stockage, y compris saS, pour gérer l’accès pour les données de chaque locataire.

Lorsque vous créez dynamiquement des files d’attente pour chaque locataire, réfléchissez à la façon dont la couche Application consomme les messages de la file d’attente de chaque locataire. Pour les scénarios avancés, envisagez d’utiliser Azure Service Bus, qui prend en charge des fonctionnalités telles que les sessions, le transfert automatique des messages, les rubriques et les abonnements. Ces fonctionnalités peuvent améliorer les solutions mutualisées.

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 :

• Dr Christian Geuer-Pollmann | Ingénieur client principal, FastTrack pour Azure
• Patrick Horn | Senior Customer Engineering Manager, FastTrack pour Azure
• Ben Hummerstone | Ingénieur client principal, FastTrack pour Azure
• Vic Perdana | Architecte de solution cloud, Azure ISV
• Daniel Scott-Raynsford | Architecte de solutions partenaires, données et IA
• Arsenal Vladimirskiy | Ingénieur client principal, FastTrack pour Azure

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

Ressource associée

• Approches de stockage et de données pour l’architecture mutualisée