6 Mandantenfähiger Objektspeicher ist die Konstruktion, die es vielen unabhängigen Kunden ermöglicht, eine einzige Speicherplattform zu teilen, während jeder sie so erlebt, als wäre sie seine eigene. Für einen Service Provider, einen Telekommunikationsanbieter oder eine Neocloud ist sie das Fundament, auf dem alles andere ruht, denn ein Speicherdienst wird erst dann zum Geschäft, wenn mehr als ein Kunde dieselbe Infrastruktur sicher nutzen kann. Gelingt die Mandantenfähigkeit, können Sie eine große gemeinsame Flotte zu attraktiven Kosten ausbauen. Misslingt sie, drohen Datenlecks zwischen Kunden, unvorhersehbare Leistung und Abrechnungen, die Sie nicht verteidigen können. Dieser Beitrag erklärt, was Mandantenfähigkeit bei Objektspeicher bedeutet und welche Grenzen sie funktionieren lassen. Ein Mandant ist schlicht ein Kunde oder eine isolierte Einheit innerhalb eines Kunden, der seine Daten und seine Zugriffe gehören. Mandantenfähigkeit ist die Gesamtheit der Kontrollen, die Mandanten auf gemeinsam genutzter Hardware voneinander trennen und es dem Betreiber dennoch ermöglichen, eine Plattform statt Hunderter zu betreiben. Was mandantenfähiger Objektspeicher bedeutet In einem mandantenfähigen System wird eine physische Plattform logisch so aufgeteilt, dass jeder Mandant eigene Konten, eigene Buckets oder Namespaces und eigene Zugangsdaten hat. Zwei Mandanten können Objekte mit demselben Namen speichern, Kapazität aus demselben Pool nutzen und dieselben Endpunkte ansprechen – und dennoch kann keiner den anderen sehen oder beeinflussen. Der Betreiber sieht das gesamte System, jeder Mandant nur seinen Ausschnitt. Das unterscheidet sich davon, jedem Kunden einfach einen eigenen Cluster zu geben: Das ist leicht zu durchschauen, aber teuer und langsam zu skalieren. Der Sinn der Mandantenfähigkeit besteht darin, eine Isolation, die sich dediziert anfühlt, auf einer tatsächlich gemeinsam genutzten Infrastruktur zu erreichen. Falls Konzepte des Objektspeichers für Sie neu sind, ist der Beitrag Was Objektspeicher eigentlich ist ein guter Ausgangspunkt, bevor Sie hier weiterlesen. Warum Objektspeicher zur Mandantenfähigkeit passt Objektspeicher passt aus einigen strukturellen Gründen gut zur Mandantenfähigkeit. Er nutzt einen flachen, in Buckets und Konten organisierten Namespace statt eines starren Verzeichnisbaums, sodass sich Zuständigkeiten ganz natürlich auf Konto- und Bucket-Ebene zuordnen lassen. Jedes Objekt trägt umfangreiche Metadaten, sodass Tags für Mandant, Aufbewahrung und Abrechnung mit den Daten selbst wandern. Und er ist darauf ausgelegt, horizontal über viele Knoten zu skalieren, sodass neue Mandanten und mehr Kapazität einfach durch Wachstum des Pools hinzukommen statt durch neue Silos. Diese Eigenschaften ermöglichen es einer Plattform, viele Kunden aufzunehmen, ohne bei jedem neuen Kunden umgestaltet werden zu müssen. Gerade die Metadaten zahlen sich für Provider aus, denn das Tagging pro Objekt ermöglicht später genaue Berichte und eine automatisierte Lebenszyklusverwaltung. Siehe Indizierung von Objektspeicher-Metadaten zur Frage, wie diese Metadatenebene organisiert und abgefragt wird. Die vier Grenzen, die Mandantenfähigkeit funktionieren lassen Solide Mandantenfähigkeit läuft auf vier Grenzen hinaus, von denen jede für sich halten muss. Identität und Zugriff. Jede Anfrage muss einem Mandanten zugeordnet und gegen dessen Richtlinien geprüft werden, sodass keine Zugangsdaten jemals die Objekte eines anderen Mandanten erreichen können. Das ist die Sicherheitsgrenze, und sie stützt sich auf dieselben Prinzipien wie das Identitäts- und Zugriffsmanagement: Least Privilege, eng begrenzte Schlüssel und klare Zuständigkeiten. Kapazität und Quoten. Da Mandanten aus einem gemeinsamen Pool schöpfen, braucht jeder eine Quote, damit nicht ein Kunde Platz verbraucht, für den andere bezahlt haben. Mit Quoten lassen sich zudem Stufen verkaufen und automatisch durchsetzen. Leistungsfairness. Eine gemeinsam genutzte Plattform muss verhindern, dass eine Lastspitze eines einzelnen Mandanten alle anderen beeinträchtigt – das klassische Noisy-Neighbor-Problem. Ratenbegrenzung und Quality-of-Service-Kontrollen sollen verhindern, dass die Last eines Mandanten zum Ausfall eines anderen wird. Berichte. Was Sie nicht messen können, können Sie nicht abrechnen. Daher ist das Metering von Kapazität, Anfragen und Datenübertragung pro Mandant eine eigene Grenze. Es macht zudem die Durchsetzung von Quoten und die Kapazitätsplanung erst möglich. Die Sicherheitsgrenze lässt am wenigsten Spielraum für Fehler und verdient eine eigene, tiefere Betrachtung. Zum Bedrohungsmodell und zu den Kontrollen, die Mandanten kryptografisch und betrieblich voneinander trennen, lesen Sie Isolation in mandantenfähigem Speicher. Isolation ohne Cluster pro Kunde Ein häufiger Impuls ist, Kunden durch eigene Hardware für jeden zu isolieren. Das funktioniert, untergräbt aber die Wirtschaftlichkeit, die einen Speicherdienst tragfähig macht, weil das Pooling verloren geht, das Fixkosten auf viele Mandanten verteilt. Logische Isolation (getrennte Konten, Namespaces, Richtlinien und Verschlüsselungskontext auf gemeinsamer Infrastruktur) liefert die Trennung, die Kunden brauchen, und erhält zugleich den gemeinsamen Pool. Für die wenigen Kunden, deren Verträge tatsächlich eine physische Trennung verlangen, funktioniert ein hybrider Ansatz: Die meisten Mandanten teilen sich den Pool, während einige sensible Mandanten dedizierte Kapazität innerhalb desselben Betriebsrahmens erhalten. Ziel ist es, teure physische Isolation den Fällen vorzubehalten, die sie wirklich erfordern, statt sie standardmäßig anzuwenden. KI-Plattformen stehen vor einer verschärften Version dieser Abwägung, weil GPU-Workloads zusätzlich zur Datenisolation eine Leistungsisolation erfordern. Diesen speziellen Gestaltungsspielraum behandelt der Leitfaden für das Design mandantenfähiger KI-Infrastruktur. Metering und Abrechnung pro Mandant Beim Metering trifft Mandantenfähigkeit auf das Geschäft. Um fair abzurechnen und die eigenen Margen im Blick zu behalten, brauchen Sie pro Mandant Werte für die gespeicherte Kapazität über die Zeit, das Anfragevolumen und die ausgehende Datenübertragung. Diese Zahlen speisen drei Dinge zugleich: die Rechnung, die Durchsetzung von Quoten und Ihr eigenes Verständnis der Kosten pro Mandant im Verhältnis zum verlangten Preis. Ist das Metering schwach, rechnen Provider tendenziell zu wenig ab, stellen zu viel bereit oder beides – und die Marge schmilzt unbemerkt. Da die vollständigen Kosten eines gespeicherten Terabytes das gesamte Modell bestimmen, sollten Sie das Metering pro Mandant mit einer Kostensicht verbinden – mehr dazu im Beitrag Speicherkosten pro Terabyte. Häufige Fallstricke Einige Fehlermuster wiederholen sich. Wer Isolation als einzelne Funktion statt als vier getrennte Grenzen behandelt, lässt Lücken – oft bei Leistung oder Berichten, selbst wenn die Zugriffskontrolle solide ist. Wer Quoten aufschiebt, bis ein Mandant den Pool füllt, verwandelt eine Kapazitätsplanung in einen Feuerwehreinsatz. Wer eigene Verwaltungstools baut, statt standardisierte Self-Service-Funktionen bereitzustellen, schafft einen Supportaufwand, der mit jedem Kunden wächst. Und wer das Metering bis zum ersten Abrechnungsstreit aufschiebt, muss die Nutzung im Nachhinein rekonstruieren, was selten gut geht. All das lässt sich günstiger von Anfang an einplanen als nachrüsten. Checkliste: mandantenfähigen Objektspeicher gestalten Setzen Sie Identität und Zugriff pro Mandant durch, damit keine Zugangsdaten die Objekte eines anderen Mandanten erreichen können. Vergeben Sie Kapazitätsquoten, damit kein Mandant den gemeinsamen Pool erschöpfen kann. Wenden Sie Leistungskontrollen an (Ratenbegrenzung, Quality of Service), um Noisy Neighbors einzudämmen. Messen Sie Kapazität, Anfragen und Egress pro Mandant vom ersten Tag an, nicht erst nach dem ersten Streit. Bevorzugen Sie logische Isolation auf gemeinsamer Infrastruktur; reservieren Sie dedizierte Hardware für die wenigen Verträge, die sie erfordern. Stellen Sie standardisierte Self-Service-Funktionen bereit (Buckets, Schlüssel, Lebenszyklus, Nutzung) statt eigener Tools. Versehen Sie Objekte mit Metadaten zu Mandant, Aufbewahrung und Abrechnung, damit sich Berichte und Lebenszyklus automatisieren lassen. Alles zusammengefasst Mandantenfähiger Objektspeicher macht aus einer Speicherplattform einen Dienst. Das Handwerk liegt in den vier Grenzen: Identität und Zugriff, um Mandanten zu schützen, Quoten, um den Pool fair zu halten, Leistungskontrollen, damit kein Kunde zum Ausfall eines anderen wird, und Metering, damit Abrechnung und Marge stimmen. Gelingt das mit logischer Isolation auf gemeinsamer Infrastruktur, erhalten Sie die Trennung, die Kunden erwarten, zu der Wirtschaftlichkeit, die ein Provider braucht. Die naheliegenden nächsten Schritte sind die Sicherheitsdetails im Beitrag zur Isolation und das Nutzungsmodell in S3 as a Service, beide unten verlinkt. Service Provider, die ein kommerzielles Angebot auf einer mandantenfähigen Plattform aufbauen, sollten außerdem diese Beiträge lesen: Backup as a Service für Anbieter und So starten Sie einen S3-Speicherdienst. Häufig gestellte Fragen Was ist der Unterschied zwischen Mandantenfähigkeit und einem eigenen Cluster für jeden Kunden? Ein eigener Cluster pro Kunde bietet starke Isolation, aber eine schlechte Wirtschaftlichkeit, weil das Pooling verloren geht, das Fixkosten verteilt. Mandantenfähigkeit bietet logische Isolation (getrennte Konten, Namespaces, Richtlinien und Verschlüsselungskontext) auf gemeinsamer Infrastruktur, sodass Kunden eine Trennung erhalten, die sich dediziert anfühlt, während der Betreiber eine skalierbare Plattform betreibt. Wie wird verhindert, dass ein Mandant die Daten eines anderen sieht? Jede Anfrage wird einem Mandanten zugeordnet und gegen dessen Zugriffsrichtlinien geprüft, sodass Zugangsdaten auf die eigenen Konten und Buckets beschränkt sind. Zusammen mit einem Verschlüsselungskontext pro Mandant und Schlüsseln nach dem Least-Privilege-Prinzip stellt das sicher, dass keine Zugangsdaten die Objekte eines anderen Mandanten erreichen. Die sicherheitsspezifischen Kontrollen behandelt der Beitrag über mandantenfähigen Speicher und dessen Isolation. Was ist das Noisy-Neighbor-Problem? Es tritt auf, wenn der starke Datenverkehr eines Mandanten die Leistung für andere auf derselben Plattform beeinträchtigt. Mandantenfähige Systeme begegnen dem mit Ratenbegrenzung und Quality-of-Service-Kontrollen, die die Auswirkungen eines einzelnen Mandanten begrenzen, sodass eine Lastspitze eines Kunden nicht zum Ausfall für alle anderen wird. Warum ist Metering pro Mandant so wichtig? Metering pro Mandant speist Abrechnung, Durchsetzung von Quoten und Transparenz über die Marge zugleich. Ohne Metering rechnen Provider tendenziell zu wenig ab oder stellen zu viel bereit, die Marge schmilzt unbemerkt, und Abrechnungsstreitigkeiten lassen sich kaum klären, weil die Nutzung im Nachhinein rekonstruiert werden muss. Wer Kapazität, Anfragen und Egress pro Mandant von Anfang an misst, vermeidet alle drei Probleme. Weiterführende Lektüre Verwandte Beiträge: Isolation in mandantenfähigem Speicher, S3 as a Service (auf Englisch), S3-API-Kompatibilität sowie der Hub-Beitrag Speicher für Service Provider (auf Englisch).
