4 Le stockage objet multi-locataire est l’organisation qui permet à de nombreux clients indépendants de partager une même plateforme de stockage tout en ayant chacun l’impression qu’elle leur appartient. Pour un fournisseur de services, un opérateur télécom ou un neocloud, c’est le socle sur lequel tout repose, car un service de stockage ne devient une activité commerciale qu’à partir du moment où plusieurs clients peuvent utiliser la même infrastructure en toute sécurité. Réussissez la multi-location et vous pourrez développer un vaste parc partagé avec une économie attractive. Ratez-la et vous vous exposerez à des fuites de données entre clients, à des performances imprévisibles et à une facturation indéfendable. Cet article explique ce que signifie la multi-location dans le stockage objet et les frontières qui la font fonctionner. Un locataire (tenant) est simplement un client, ou une unité isolée au sein d’un client, qui possède ses données et ses accès. La multi-location est l’ensemble des contrôles qui séparent les locataires sur un matériel partagé, tout en permettant à l’opérateur d’exploiter une seule plateforme plutôt que des centaines. Ce que signifie le stockage objet multi-locataire Dans un système multi-locataire, une plateforme physique unique est partitionnée logiquement afin que chaque locataire dispose de ses propres comptes, de ses propres buckets ou espaces de noms et de ses propres identifiants d’accès. Deux locataires peuvent stocker des objets portant le même nom, consommer de la capacité dans le même pool et utiliser les mêmes points de terminaison, sans qu’aucun ne puisse voir l’autre ni l’affecter. L’opérateur voit l’ensemble du système ; chaque locataire ne voit que sa part. C’est différent de l’attribution d’un cluster distinct à chaque client, approche facile à appréhender mais coûteuse et lente à faire évoluer. L’objectif de la multi-location est d’obtenir une isolation qui donne l’impression d’être dédiée, sur une infrastructure réellement partagée. Si les concepts du stockage objet sont nouveaux pour vous, l’article qu’est-ce que le stockage objet (en anglais) constitue un bon point de départ avant d’aller plus loin. Pourquoi le stockage objet se prête à la multi-location Le stockage objet est bien adapté à la multi-location pour plusieurs raisons structurelles. Il utilise un espace de noms plat organisé en buckets et en comptes plutôt qu’une arborescence de répertoires rigide, ce qui permet naturellement d’attribuer la propriété au niveau du compte et du bucket. Il associe des métadonnées riches à chaque objet, de sorte que les étiquettes de locataire, de conservation et de facturation accompagnent les données elles-mêmes. Et il est conçu pour évoluer horizontalement sur de nombreux nœuds : ajouter des locataires et de la capacité revient à agrandir le pool plutôt qu’à créer de nouveaux silos. Ces propriétés permettent à une seule plateforme d’accueillir de nombreux clients sans refonte à chaque nouvel arrivant. L’aspect métadonnées est particulièrement rentable pour les fournisseurs, car l’étiquetage par objet est ce qui permet ensuite un reporting précis et l’automatisation du cycle de vie. Consultez l’indexation des métadonnées du stockage objet pour savoir comment cette couche de métadonnées est organisée et interrogée. Les quatre frontières qui font fonctionner la multi-location Une multi-location solide repose sur quatre frontières, chacune devant tenir indépendamment. L’identité et les accès. Chaque requête doit être attribuée à un locataire et vérifiée au regard de ses politiques, afin qu’aucun identifiant ne puisse jamais atteindre les objets d’un autre locataire. C’est la frontière de sécurité, et elle s’appuie sur les mêmes principes que la gestion des identités et des accès : moindre privilège, clés à portée limitée et propriété clairement définie. La capacité et les quotas. Comme les locataires puisent dans un pool partagé, chacun a besoin d’un quota pour qu’un client ne puisse pas consommer l’espace payé par les autres. Les quotas permettent aussi de vendre des offres par paliers et de les appliquer automatiquement. L’équité des performances. Une plateforme partagée doit empêcher qu’un pic de trafic d’un seul locataire ne dégrade le service de tous les autres : c’est le problème classique du « voisin bruyant ». La limitation de débit et les contrôles de qualité de service visent à éviter que la charge d’un locataire ne devienne la panne d’un autre. Le reporting. On ne peut pas facturer ce que l’on ne peut pas mesurer : le comptage par locataire de la capacité, des requêtes et des transferts de données est donc une frontière à part entière. C’est aussi ce qui rend possibles l’application des quotas et la planification de capacité. La frontière de sécurité est celle qui laisse le moins de place à l’erreur, et elle mérite un traitement plus approfondi. Pour le modèle de menace et les contrôles qui maintiennent les locataires séparés sur les plans cryptographique et opérationnel, lisez l’isolation du stockage multi-locataire. Isoler sans un cluster par client Un réflexe courant consiste à isoler les clients en attribuant à chacun du matériel dédié. Cela fonctionne, mais cela ruine l’économie qui rend un service de stockage viable, car on perd la mutualisation qui répartit les coûts fixes sur de nombreux locataires. L’isolation logique (comptes, espaces de noms, politiques et contextes de chiffrement distincts sur une infrastructure partagée) assure la séparation dont les clients ont besoin tout en préservant le pool partagé. Pour le petit nombre de clients dont les contrats exigent réellement une séparation physique, une approche hybride fonctionne : la plupart des locataires partagent le pool, tandis que quelques clients sensibles disposent d’une capacité dédiée au sein du même cadre opérationnel. L’objectif est de réserver l’isolation physique, coûteuse, aux cas qui l’exigent vraiment plutôt que de l’appliquer par défaut. Les plateformes d’IA font face à une version plus aiguë de cet arbitrage, car les charges de travail GPU ajoutent l’isolation des performances à celle des données. Cet espace de conception spécifique est traité dans le guide de conception d’une infrastructure d’IA multi-locataire. Comptage et facturation par locataire Le comptage est le point de rencontre entre la multi-location et l’activité commerciale. Pour facturer équitablement et garder vos propres marges visibles, vous avez besoin, pour chaque locataire, de la capacité stockée dans le temps, du volume de requêtes et des données transférées vers l’extérieur. Ces chiffres alimentent trois choses à la fois : la facture, l’application des quotas et votre propre compréhension du coût par locataire au regard du prix facturé. Lorsque le comptage est faible, les fournisseurs ont tendance à sous-facturer, à surprovisionner, ou les deux, ce qui érode discrètement la marge. Comme le coût complet d’un téraoctet stocké détermine tout le modèle, il est utile de compléter le comptage par locataire par l’analyse des coûts présentée dans le coût du stockage par téraoctet. Les pièges courants Quelques schémas d’échec reviennent régulièrement. Traiter l’isolation comme une seule fonctionnalité plutôt que comme quatre frontières distinctes laisse des failles, souvent au niveau des performances ou du reporting, même lorsque le contrôle d’accès est solide. Attendre qu’un locataire remplisse le pool pour mettre en place des quotas transforme un plan de capacité en situation d’urgence. Développer des outils de gestion sur mesure au lieu d’exposer des primitives standard en libre-service crée une charge de support qui augmente avec chaque client. Et repousser le comptage jusqu’au premier litige de facturation oblige à reconstituer l’utilisation après coup, ce qui se passe rarement bien. Chacun de ces points coûte moins cher à intégrer dès la conception qu’à corriger ensuite. Check-list : concevoir un stockage objet multi-locataire Appliquer l’identité et les accès par locataire afin qu’aucun identifiant ne puisse atteindre les objets d’un autre locataire. Attribuer des quotas de capacité pour qu’un locataire ne puisse pas épuiser le pool partagé. Appliquer des contrôles de performances (limitation de débit, qualité de service) pour contenir les voisins bruyants. Compter la capacité, les requêtes et l’egress par locataire dès le premier jour, et non après le premier litige. Privilégier l’isolation logique sur une infrastructure partagée ; réserver le matériel dédié aux quelques contrats qui l’exigent. Exposer des primitives standard en libre-service (buckets, clés, cycle de vie, utilisation) plutôt que des outils sur mesure. Étiqueter les objets avec des métadonnées de locataire, de conservation et de facturation pour automatiser le reporting et le cycle de vie. Synthèse Le stockage objet multi-locataire est ce qui transforme une plateforme de stockage en service. Le savoir-faire réside dans les quatre frontières : l’identité et les accès pour sécuriser les locataires, les quotas pour garder le pool équitable, les contrôles de performances pour qu’un client ne devienne pas la panne d’un autre, et le comptage pour garder la facturation et la marge honnêtes. Réalisez-les grâce à l’isolation logique sur une infrastructure partagée, et vous obtiendrez la séparation attendue par les clients avec l’économie dont un fournisseur a besoin. Les étapes suivantes naturelles sont l’approfondissement de la sécurité dans l’article sur l’isolation et le modèle de consommation du S3 as a service, tous deux mentionnés ci-dessous. Les fournisseurs de services qui construisent une offre commerciale sur une plateforme multi-locataire devraient aussi lire la sauvegarde en tant que service pour les fournisseurs et comment lancer un service de stockage S3. Questions fréquentes Quelle est la différence entre la multi-location et l’attribution d’un cluster distinct à chaque client ? Un cluster distinct par client offre une isolation forte mais une économie médiocre, car on perd la mutualisation qui répartit les coûts fixes. La multi-location fournit une isolation logique (comptes, espaces de noms, politiques et contextes de chiffrement distincts) sur une infrastructure partagée : les clients bénéficient d’une séparation qui semble dédiée, tandis que l’opérateur exploite une seule plateforme évolutive. Comment empêcher un locataire de voir les données d’un autre ? Chaque requête est attribuée à un locataire et vérifiée au regard des politiques d’accès de celui-ci, de sorte que les identifiants sont limités à leurs propres comptes et buckets. Associé à un contexte de chiffrement par locataire et à des clés selon le principe du moindre privilège, ce mécanisme garantit qu’aucun identifiant ne peut atteindre les objets d’un autre locataire. Les contrôles spécifiques à la sécurité sont traités dans l’article sur l’isolation du stockage multi-locataire. Qu’est-ce que le problème du « voisin bruyant » ? C’est la situation dans laquelle le trafic important d’un locataire dégrade les performances des autres utilisateurs de la plateforme. Les systèmes multi-locataires y répondent par la limitation de débit et des contrôles de qualité de service qui plafonnent l’impact de chaque locataire, afin qu’un pic de charge d’un client ne se transforme pas en panne pour les autres. Pourquoi le comptage par locataire est-il si important ? Le comptage par locataire alimente à la fois la facturation, l’application des quotas et la visibilité sur les marges. Sans lui, les fournisseurs ont tendance à sous-facturer ou à surprovisionner, ce qui érode discrètement la marge, et ils peinent à résoudre les litiges de facturation, car l’utilisation doit être reconstituée après coup. Mesurer dès le départ la capacité, les requêtes et l’egress par locataire évite ces trois problèmes. Pour aller plus loin À lire également : l’isolation du stockage multi-locataire, le S3 as a service (en anglais), la compatibilité avec l’API S3 et la page centrale, le stockage pour les fournisseurs de services (en anglais).
