Partager via

Architecture multilocataires et Stockage Azure

  • Article

Stockage Azure est un service fondamental utilisé dans presque toutes les solutions. Les solutions multilocataires utilisent souvent Stockage Azure pour le stockage d’objets blob, de fichiers, de files d’attente et de tables. Sur cette page, nous décrivons quelques-unes des fonctionnalités de Stockage Azure qui sont utiles pour les solutions multilocataires, puis nous fournissons des liens vers des conseils qui peuvent vous aider, lorsque vous planifiez la façon dont vous allez utiliser Stockage Azure.

Fonctionnalités de Stockage Azure qui prennent en charge l’architecture multilocataires

Stockage Azure inclut de nombreuses fonctionnalités qui prennent en charge l’architecture multilocataires.

Signatures d’accès partagé

Lorsque vous utilisez Stockage Azure à partir d’une application cliente, il est important de déterminer si les demandes des clients doivent être envoyées par le biais d’un autre composant que vous contrôlez, comme un réseau de distribution de contenu ou une API, ou si le client doit se connecter directement à votre compte de stockage. Il peut y avoir de bonnes raisons d’envoyer des demandes par le biais d’un autre composant, notamment la mise en cache des données à la périphérie de votre réseau. Toutefois, dans certaines situations, il est avantageux pour les points de terminaison clients de se connecter directement à Stockage Azure pour télécharger ou charger des données. Cette connexion vous permet d’améliorer les performances de votre solution, en particulier lorsque vous travaillez avec des objets blob volumineux ou un grand nombre de fichiers. Cela réduit également la charge sur vos serveurs et applications backend, 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 Stockage Azure.

Les signatures d’accès partagé peuvent être utilisées pour limiter l’étendue des opérations qu’un client peut effectuer et les objets sur lesquels il peut effectuer des opérations. Par exemple, si vous avez un compte de stockage partagé pour tous vos locataires, et que vous stockez toutes les données du locataire A dans un conteneur d’objets blob nommé tenanta, vous pouvez créer une signature d’accès partagé qui autorise uniquement les utilisateurs du locataire A à accéder à ce conteneur. Pour plus d’informations, consultez Modèles d’isolation pour explorer les approches que vous pouvez utiliser pour isoler les données de vos locataires dans un compte de stockage.

Le modèle de clé de valet est utile pour émettre des signatures d’accès partagé limitées et étendues à partir de votre couche Application. Supposons, par exemple, que vous disposez d’une application multilocataires qui permet aux utilisateurs de charger des vidéos. Votre couche Application ou API peut authentifier le client à l’aide de votre propre système d’authentification. Vous pouvez ensuite fournir une clé d’accès partagé au client qui lui permet de charger un fichier vidéo vers un objet blob spécifié, dans un conteneur et un chemin d’accès blob que vous spécifiez. Le client charge ensuite le fichier directement dans le compte de stockage, évitant ainsi la bande passante et la charge supplémentaires sur votre API. S’il essaie de lire des données à partir du conteneur d’objets blob ou d’écrire des données dans une autre partie du conteneur vers un autre conteneur dans le compte de stockage, Stockage Azure bloque la demande. La signature expire après une période configurable.

Les stratégies d’accès stockées étendent la fonctionnalité de signature d’accès partagé, qui vous permet de définir une stratégie unique qui peut être utilisée lors de l’émission de plusieurs signatures d’accès partagé.

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

Stockage Azure fournit également un contrôle d’accès basé sur l’identité à l’aide de Microsoft Entra ID. Cette fonctionnalité vous permet également d’utiliser le contrôle d’accès basé sur les attributs, qui vous donne un accès plus affiné aux chemins d’accès aux objets blob, ou aux objets blob qui ont été marqués avec un ID de locataire spécifique.

Gestion du cycle de vie

Lorsque vous utilisez le stockage d’objets blob dans une solution multilocataires, vos locataires peuvent nécessiter des stratégies différentes pour la conservation des données. Lorsque vous stockez des volumes importants de données, vous pouvez également configurer les données d’un locataire spécifique pour qu’elles soient automatiquement déplacées vers les niveaux de stockage Froid ou Archive, à des fins d’optimisation des coûts.

Envisagez d’utiliser des stratégies de gestion du cycle de vie pour définir le cycle de vie des objets blob pour tous les locataires ou pour un sous-ensemble de locataires. Une stratégie de gestion du cycle de vie peut être appliquée à des conteneurs d’objets blob ou à un sous-ensemble d’objets blob au sein d’un conteneur. Toutefois, le nombre de règles que vous pouvez spécifier dans une stratégie de gestion du cycle de vie est limité. Veillez à planifier et à tester l’utilisation de cette fonctionnalité dans un environnement multilocataires, et envisagez de déployer plusieurs comptes de stockage, si vous dépassez les limites.

Stockage non modifiable

Quand vous configurez un stockage d’objets blob immuable sur des conteneurs de stockage avec des stratégies de rétention basées sur l’heure, Stockage Azure empêche la suppression ou la modification des données avant l’heure spécifiée. La prévention est appliquée à la couche de compte de stockage et s’applique à tous les utilisateurs. Même les administrateurs de votre organisation ne peuvent pas supprimer les données immuables.

Le stockage immuable peut être utile lorsque vous travaillez avec des locataires qui ont des exigences légales ou de conformité pour gérer des données ou des enregistrements. Toutefois, vous devez prendre en compte la façon dont cette fonctionnalité est utilisée dans le contexte du cycle de vie de votre locataire. Par exemple, si des locataires se sont retirés et demandent la suppression de leurs données, vous risquez de ne pas pouvoir répondre à leurs demandes. Si vous utilisez un stockage immuable pour les données de vos locataires, réfléchissez à la façon dont vous répondez à ce problème dans vos conditions d’utilisation du service.

Copie côté serveur

Dans un système multilocataires, il est parfois nécessaire de déplacer les données d’un compte de stockage vers un autre. Par exemple, si vous déplacez un locataire entre des unités 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 travaillez avec de gros volumes de données, il est recommandé d’utiliser des API de copie côté serveur pour réduire le temps nécessaire à la migration des données.

L’outil AzCopy est une application que vous pouvez exécuter à partir de votre propre ordinateur, ou à partir 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 propres solutions. AzCopy est également utile pour le chargement et le téléchargement 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 l’API Put Block From URL, Put Page From URL, Append Block From URL ou Copy Blob From URL lorsque vous travaillez avec des objets blob plus petits.

Réplication d’objets

La fonctionnalité de réplication d’objets réplique automatiquement les données entre des comptes de stockage source et de destination. La réplication d’objets est asynchrone. Dans une solution multilocataires, cette fonctionnalité peut être utile lorsque vous devez répliquer en continu des données entre les unités de déploiement ou dans une implémentation du modèle Geode.

Chiffrement

Stockage Azure vous permet de fournir des clés de chiffrement pour vos données. Dans une solution multilocataires, envisagez de combiner cette fonctionnalité avec des étendues de chiffrement, ce qui vous permet de définir différentes clés de chiffrement pour différents locataires, même si leurs données sont stockées dans le même compte de stockage. En utilisant ces fonctionnalités ensemble, vous pouvez également fournir aux locataires un contrôle sur leurs propres données. S’ils doivent désactiver leur compte, la suppression de la clé de chiffrement garantit que leurs données ne soient plus accessibles.

Surveillance

Lorsque vous utilisez une solution multilocataires, déterminez si vous devez mesurer la consommation pour chaque locataire et définissez les mesures spécifiques dont vous avez besoin pour effectuer le suivi, telles que la quantité de stockage utilisée pour chaque locataire (capacité) ou le nombre d’opérations effectuées pour les données de chaque locataire. Vous pouvez également utiliser l’allocation des 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 surveillance intégrées. Il est important de prendre en compte les services que vous allez utiliser dans le compte Stockage Azure. Par exemple, lorsque vous travaillez avec des objets blob, il est possible d’afficher la capacité totale d’un compte de stockage, mais pas d’un seul conteneur. En revanche, lorsque vous travaillez avec des partages de fichiers, il est possible de voir la capacité de chaque partage, mais pas pour chaque dossier.

Vous pouvez également journaliser toutes les demandes effectuées sur Stockage Azure, puis vous pouvez agréger et analyser ces journaux. Cette approche offre davantage de flexibilité par rapport à la façon dont vous agrégez et regroupez les données pour chaque locataire. Toutefois, dans les solutions qui créent génèrent l’envoi de volumes élevés de requêtes à Stockage Azure, il est important de déterminer si l’avantage que vous retirez de cette approche justifie le coût de la capture et du traitement de ces journaux.

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

Modèles d’isolation

Lorsque vous travaillez avec un système multilocataires qui utilise Stockage Azure, vous devez prendre une décision concernant le niveau d’isolation que vous souhaitez utiliser. Stockage Azure prend en charge plusieurs modèles d’isolation.

Comptes de stockage par locataire

Le niveau d’isolation le plus élevé consiste à déployer un compte de stockage dédié pour un locataire. Cela garantit que toutes les clés de stockage sont isolées et que leur rotation peut être effectuée indépendamment les unes des autres. Cette approche vous permet de mettre à l’échelle votre solution pour éviter les limites et les quotas qui s’appliquent à chaque compte de stockage, mais vous devez également prendre en compte le nombre maximal de comptes de stockage pouvant être déployés dans un seul abonnement Azure.

Notes

Stockage Azure présente de nombreux quotas et limites que vous devez prendre en compte lorsque vous sélectionnez un modèle d’isolation. Il s’agit des limites de service Azure, des objectifs de scalabilitéet des objectifs de scalabilité pour le fournisseur de ressources Stockage Azure.

En outre, chaque composant de Stockage Azure fournit des options supplémentaires pour l’isolation des locataires.

Modèles d’isolation du stockage d’objets blob

Le tableau suivant récapitule les différences entre les principaux modèles d’isolation de location pour les objets blob Stockage Azure :

Considération Conteneurs d’objets blob partagés Conteneurs d’objets blob par locataire Comptes de stockage par locataire
Isolation des données Faible à moyen. Utiliser des chemins d’accès pour identifier les données de chaque locataire ou les espaces de noms hiérarchiques Moyenne. Utiliser des URL SAS délimitées par conteneur pour prendre en charge l’isolation de la sécurité Élevé
Isolation des performances Faible Faible. La plupart des quotas et limites s’appliquent à l’ensemble du compte de stockage Élevé
Complexité du déploiement Faible Moyenne Élevé
Complexité opérationnelle Faible Moyenne Élevé
Exemple de scénario Stockage d’un petit nombre d’objets blob par locataire Émettre des URL SAS délimitées au locataire Tampons de déploiement distincts pour chaque locataire

Conteneurs d’objets blob partagés

Lorsque vous travaillez avec le stockage d’objets blob, vous pouvez choisir d’utiliser un conteneur d’objets blob partagé, et vous pouvez ensuite utiliser des chemins d’accès aux objets blob pour séparer les données de chaque locataire :

ID client Exemple de chemin d’accès blob
tenant-a https://contoso.blob.core.windows.net/sharedcontainer/tenant-a/blob1.mp4
tenant-b https://contoso.blob.core.windows.net/sharedcontainer/tenant-b/blob2.mp4

Bien que cette approche soit simple à implémenter, dans de nombreux scénarios, les chemins d’accès aux objets blob ne fournissent pas une isolation suffisante entre les locataires. Cela est dû au fait que le stockage d’objets blob ne fournit pas le concept de répertoires ou de dossiers. Cela signifie que vous ne pouvez pas attribuer l’accès à tous les objets blob dans un chemin d’accès spécifié. Toutefois, Stockage Azure permet de répertorier (énumérer) les objets blob qui commencent par un préfixe spécifié, ce qui peut être utile lorsque vous travaillez avec des conteneurs d’objets blob partagés et que vous n’avez pas besoin d’utiliser le contrôle d’accès au niveau du répertoire.

La fonctionnalité d’espace de noms hiérarchique de Stockage Azure offre la possibilité d’avoir un concept plus fort d’un répertoire ou d’un dossier, notamment le contrôle d’accès propre au répertoire. Cela peut être utile dans certains scénarios multilocataires où vous avez des conteneurs d’objets blob partagés, mais où vous souhaitez accorder l’accès aux données d’un locataire unique.

Dans certaines solutions multilocataires, vous devrez peut-être stocker un seul objet blob ou un ensemble d’objets blob pour chaque locataire, tels que des icônes de locataire pour la personnalisation d’une interface utilisateur. Dans ces scénarios, un seul conteneur d’objets blob partagé peut suffire. Vous pouvez utiliser l’identificateur de locataire comme nom d’objet blob, puis lire un objet blob spécifique au lieu d’énumérer un chemin d’accès d’objet blob.

Lorsque vous travaillez avec des conteneurs partagés, déterminez si vous devez effectuer le suivi des données et de l’utilisation des services Stockage Azure pour chaque locataire, et planifiez l’approche adéquate. Pour plus d’informations, consultez Surveillance.

Conteneurs d’objets blob par locataire

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

En créant des conteneurs pour chaque locataire, vous pouvez utiliser le contrôle d’accès Stockage Azure, notamment la signature d’accès partagé, pour gérer l’accès aux 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écapitule les différences entre les principaux modèles d’isolation de location pour les fichiers Stockage Azure :

Considération Partages de fichiers partagés Partages de fichiers par locataire Comptes de stockage par locataire
Isolation des données Moyenne-élevée. Appliquer des règles d’autorisation pour les fichiers et répertoires spécifiques au locataire Moyenne-élevée Élevé
Isolation des performances Faible Faible à moyen. La plupart des quotas et des limites s’appliquent à l’ensemble du compte de stockage, mais définissent des quotas de taille sur un niveau par partage Élevé
Complexité du déploiement Faible Moyenne Élevé
Complexité opérationnelle Faible Moyenne Élevé
Exemple de scénario L’application contrôle tous les accès aux fichiers Les locataires accèdent à leurs propres fichiers Tampons de déploiement distincts pour chaque locataire

Partages de fichiers partagés

Lorsque vous utilisez des partages de fichiers, vous pouvez choisir d’utiliser un partage de fichiers partagé, puis vous pouvez utiliser des chemins d’accès de fichiers pour séparer les données de chaque locataire :

ID client Exemple de chemin d'accès au fichier
tenant-a https://contoso.file.core.windows.net/share/tenant-a/blob1.mp4
tenant-b https://contoso.file.core.windows.net/share/tenant-b/blob2.mp4

Lorsque vous utilisez une application qui peut communiquer à l’aide du protocole SMB (Server Message Block) et lorsque vous utilisez Active Directory Domain Services localement ou dans Azure, les partages de fichiers prennent en charge l’autorisation au niveau du partage et des répertoires/fichiers.

Dans d’autres scénarios, envisagez d’utiliser les signatures d’accès partagé pour accorder l’accès à des fichiers ou partages de fichiers spécifiques. Lorsque vous utilisez la signature d’accès partagé, vous ne pouvez pas accorder l’accès aux répertoires.

Lorsque vous travaillez avec des partages de fichiers partagés, déterminez si vous devez effectuer le suivi des données et de l’utilisation des services Stockage Azure pour chaque locataire, et planifiez l’approche adéquate (en fonction des besoins). Pour plus d’informations, consultez Surveillance.

Partages de fichiers par locataire

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

En créant des partages de fichiers pour chaque locataire, vous pouvez utiliser le contrôle d’accès Stockage Azure, notamment la signature d’accès partagé, pour gérer l’accès aux données de chaque locataire. Vous pouvez également surveiller facilement la capacité utilisée par chaque partage de fichiers.

Modèles d’isolation du stockage de tables

Le tableau suivant récapitule les différences entre les principaux modèles d’isolation de location pour les tables Stockage Azure :

Considération Tables partagées avec clés de partition par locataire Tables par locataire Comptes de stockage par locataire
Isolation des données Faible. L’application applique l’isolation Faible-Moyenne. Élevé
Isolation des performances Faible Faible. La plupart des quotas et limites s’appliquent à l’ensemble du compte de stockage Élevé
Complexité du déploiement Faible Moyenne Élevé
Complexité opérationnelle Faible Moyenne Élevé
Exemple de scénario Solution multilocataire volumineuse avec une couche Application partagée Émettre des URL SAS délimitées au locataire Tampons de déploiement distincts pour chaque locataire

Tables partagées avec clés de partition par locataire

Lorsque vous utilisez le stockage de tables avec une seule table partagée, vous pouvez envisager d’utiliser la prise en charge intégrée du partitionnement. Chaque entité doit inclure une clé de partition. Un identificateur de locataire est souvent un bon choix pour une clé de partition.

Les stratégies et les signatures d’accès partagé vous permettent de spécifier une plage de clés de partition, et Stockage Azure garantit que les demandes contenant la signature peuvent accéder uniquement aux plages de clés de partition spécifiées. Cela vous permet d’implémenter le modèle de clé de valet, qui permet aux clients non autorisés d’accéder à la partition d’un locataire unique, sans affecter les autres locataires.

Pour les applications à grande échelle, prenez en compte le débit maximal de chaque partition de table et le compte de stockage.

Tables par locataire

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

En créant des tables pour chaque locataire, vous pouvez utiliser le contrôle d’accès Stockage Azure, notamment la signature d’accès partagé, pour gérer l’accès aux données de chaque locataire.

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

Le tableau suivant récapitule les différences entre les principaux modèles d’isolation de location pour les files d’attente Stockage Azure :

Considération Files d’attente partagées Files d’attente par locataire Comptes de stockage par locataire
Isolation des données Faible Faible-Moyenne. Élevé
Isolation des performances Faible Faible. La plupart des quotas et limites s’appliquent à l’ensemble du compte de stockage Élevé
Complexité du déploiement Faible Moyenne Élevé
Complexité opérationnelle Faible Moyenne Élevé
Exemple de scénario Solution multilocataire volumineuse avec une couche Application partagée Émettre des URL SAS délimitées au locataire Tampons de déploiement distincts pour chaque locataire

Files d’attente partagées

Si vous choisissez de partager une file d’attente, prenez en compte les quotas et les limites qui s’appliquent. Dans les solutions avec un volume de demandes élevé, déterminez si le débit cible de 2 000 messages par seconde est suffisant.

Les files d’attente ne fournissent pas de partitionnement ou de sous-files d’attente, de sorte que les données de tous les locataires peuvent être mélangées.

Files d’attente par locataire

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

En créant des files d’attente pour chaque locataire, vous pouvez utiliser le contrôle d’accès Stockage Azure, notamment la signature d’accès partagé, pour gérer l’accès aux données de chaque locataire.

Lorsque vous créez dynamiquement des files d’attente pour chaque locataire, réfléchissez à la façon dont votre couche Application utilisera les messages de la file d’attente de chaque locataire. Pour les scénarios plus avancés, envisagez d’utiliser Azure Service Bus, qui prend en charge des fonctionnalités telles que les rubriques et les abonnements, les sessions et le transfert automatique des messages, qui peuvent être utiles dans une solution multilocataires.

Contributeurs

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

Auteur principal :

Autres contributeurs :

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

Étapes suivantes

Passez en revue les approches de stockage et de données pour l’architecture multilocataire.