Für die Arbeit mit Mandanten in Ihrer Lösung gibt es mehrere Lösungen. Ihre Wahl des Ansatzes hängt entscheidend davon ab, ob und wie Sie Ressourcen für Ihre Mandanten freigeben. Intuitiv möchten Sie vielleicht die gemeinsame Nutzung von allen Ressourcen vermeiden, aber dieser Ansatz wird schnell teuer, wenn Ihr Unternehmen wächst und Sie das Onboarding von mehr Mandanten durchführen.
Wenn Sie die verschiedenen Modelle der Mehrinstanzenfähigkeit berücksichtigen, ist es hilfreich, zunächst zu berücksichtigen, wie Sie Mandanten für Ihre Organisation definieren, welche geschäftlichen Faktoren vorliegen und wie Sie Ihre Lösung skalieren möchten. In diesem Artikel finden Sie Anleitungen, mit denen technische Entscheidungsträger die Mandantenmodelle und ihre Nachteile bewerten können.
Definieren eines Mandanten
Zunächst müssen Sie einen Mandanten für Ihre Organisation definieren. Überlegen Sie, wer Ihr Kunde ist. Anders ausgedrückt: Für wen stellen Sie Ihre Dienste zur Verfügung? Es gibt zwei häufige Modelle:
- B2B (Business-to-Business). Wenn Ihre Kunden andere Organisationen sind, ordnen Sie Ihre Mandanten wahrscheinlich diesen Kunden zu. Überlegen Sie jedoch, ob Ihre Kunden über Divisionen (Teams oder Abteilungen) verfügen und ob sie in mehreren Ländern/Regionen tätig sind. Möglicherweise müssen Sie einen einzelnen Kunden mehreren Mandanten zuordnen, wenn unterschiedliche Anforderungen für diese Untergruppen gelten. Ebenso kann es sein, dass ein Kunde zwei Instanzen Ihres Diensts verwalten möchte, damit er seine Entwicklungs- und Produktionsumgebungen voneinander trennen kann. Im Allgemeinen hat ein einzelner Mandant mehrere Benutzer*innen. Beispielsweise sind alle Mitarbeiter*innen Ihres Kunden Benutzer*innen innerhalb eines einzelnen Mandanten.
- B2C (Business-to-Consumer). Wenn Ihre Kunden Consumer sind, ist es häufig komplizierter, Kunden, Mandanten und Benutzer miteinander in Beziehung zu bringen. In einigen Szenarios kann jeder Verbraucher ein separater Mandant sein. Überlegen Sie jedoch, ob Ihre Lösung auch von Familien, Freundeskreisen, Vereinen, Verbänden oder anderen Gruppierungen genutzt werden könnte, die gemeinsam auf ihre Daten zugreifen und diese verwalten müssen. Ein Musikstreamingdienst kann beispielsweise sowohl einzelne Benutzer*innen als auch Familien unterstützen und jeden dieser Kontotypen unterschiedlich behandeln, wenn sie in Mandanten aufgeteilt werden.
Ihre Definition eines Mandanten wirkt sich auf einige Dinge aus, die Sie beim Entwerfen Ihrer Lösung berücksichtigen oder hervorheben müssen. Betrachten Sie beispielsweise diese Mandantentypen:
- Wenn es sich bei Ihren Mandanten um Einzelpersonen oder Familien handelt, müssen Sie sich möglicherweise besonders Gedanken darüber machen, wie Sie mit personenbezogenen Daten umgehen und welche Gesetze zur Datensouveränität in den einzelnen Ländern gelten, die Sie unterstützen.
- Wenn es sich bei Ihren Mandanten um Unternehmen handelt, müssen Sie möglicherweise die Anforderungen Ihrer Kunden an die Einhaltung gesetzlicher Bestimmungen, die Isolierung ihrer Daten und die Sicherstellung berücksichtigen, dass Sie ein bestimmtes Servicelevelziel (Service Level Objective, SLO) erfüllen, z. B. bezüglich Betriebszeit oder Dienstverfügbarkeit.
Wie entscheiden Sie also, welches Modell Sie verwenden?
Die Auswahl eines Mandantenmodells ist nicht nur eine technische Entscheidung. Es ist auch eine kommerzielle Entscheidung. Sie müssen Fragen wie die folgenden berücksichtigen:
- Was sind Ihre Geschäftsziele?
- Werden Ihre Kunden alle Formen der Mehrinstanzenfähigkeit akzeptieren? Wie wirkt sich jedes Mehrinstanzenmodell auf Ihre Complianceanforderungen oder die Complianceanforderungen Ihres Kunden aus?
- Kann eine Lösung mit nur einem Mandanten für Ihr zukünftiges Wachstum skaliert werden?
- Wie groß ist Ihr Betriebsteam, und wie viel Ihrer Infrastrukturverwaltung können Sie automatisieren?
- Erwarten Ihre Kunden, dass Sie Vereinbarungen zum Servicelevel (SLAs) erfüllen, oder verfügen Sie über SLOs, die Sie als Ziel haben?
Wenn Sie davon ausgehen, dass Ihr Unternehmen auf eine große Anzahl von Kunden skaliert wird, ist es wichtig, eine gemeinsame Infrastruktur bereitzustellen. Andernfalls müssen Sie eine große und wachsende Anzahl von Instanzen verwalten. Das Bereitstellen einzelner Azure-Ressourcen für jeden Kunden ist wahrscheinlich nicht nachhaltig, es sei denn, Sie stellen ein dediziertes Abonnement für jeden Mandant bereit und verwenden es. Bei der gemeinsamen Nutzung desselben Azure-Abonnements durch mehrere Mandanten können Azure-Ressourcenkontingente und -limits zum Tragen kommen, und die Betriebskosten für die Bereitstellung und Neukonfiguration dieser Ressourcen erhöhen sich mit jedem neuen Kunden.
Wenn Sie hingegen davon ausgehen, dass Ihr Unternehmen nur wenige Kunden haben wird, sollten Sie Ressourcen mit nur einem Mandanten für jeden Kunden verwenden. Wenn die Isolationsanforderungen Ihrer Kunden hoch sind, kann ebenfalls eine Infrastruktur mit nur einem Mandanten geeignet sein.
Mandanten und Bereitstellungen
Als nächstes müssen Sie bestimmen, was ein Mandant für Ihre spezielle Lösung bedeutet und ob Sie zwischen logischen Mandanten und Bereitstellungen unterscheiden sollten.
Betrachten Sie beispielsweise einen Musikstreamingdienst. Anfänglich könnten Sie eine Lösung erstellen, die Tausende (oder sogar Zehntausende) Benutzer*innen problemlos bewältigen kann. Wenn Sie jedoch weiter wachsen, werden Sie möglicherweise feststellen, dass Sie Ihre Lösung oder einige ihrer Komponenten duplizieren müssen, um eine Skalierung auf Ihre neue Kundennachfrage zu erreichen. Dies bedeutet, dass Sie die Zuweisung bestimmter Kunden zu bestimmten Instanzen Ihrer Lösung bestimmen müssen. Sie weisen Kunden möglicherweise oder geografisch zu, oder indem eine einzelne Instanz aufgefüllt wird und dann eine andere gestartet wird. Sie werden jedoch wahrscheinlich Aufzeichnungen über Ihre Kunden führen müssen und in welcher Infrastruktur deren Daten und Anwendungen verfügbar sind, sodass Sie deren Datenverkehr an die richtige Infrastruktur weiterleiten können. In diesem Beispiel können Sie jeden Kunden als separaten Mandanten darstellen und dann den Benutzern die Bereitstellung zuordnen, die ihre Daten enthält. Sie verfügen über eine 1:n-Zuordnung zwischen Mandanten und Bereitstellungen und können Mandanten nach eigenem Ermessen zwischen Bereitstellungen verschieben.
Stellen Sie sich im Gegensatz dazu ein Unternehmen vor, das Cloudsoftware für Anwaltskanzleien erstellt. Ihre Kunden setzen möglicherweise auf ihre eigene dedizierte Infrastruktur, um ihre Compliancestandards einzuhalten. Daher müssen Sie darauf vorbereitet sein, viele verschiedene Instanzen Ihrer Lösung von Anfang an bereitzustellen und zu verwalten. In diesem Beispiel enthält eine Bereitstellung immer einen einzelnen Mandanten, und ein Mandant wird seiner eigenen dedizierten Bereitstellung zugeordnet.
Ein wesentlicher Unterschied zwischen Mandanten und Bereitstellungen besteht darin, wie die Isolierung durchgesetzt wird. Wenn sich mehrere Mandanten eine einzelne Bereitstellung (eine Infrastrukturumgebung) teilen, verlassen Sie sich normalerweise auf Ihren Anwendungscode und einen Mandantenbezeichner in einer Datenbank, um die Daten der einzelnen Mandanten getrennt zu halten. Wenn Sie Mandanten mit eigenen dedizierten Bereitstellungen verwenden, verfügen diese über ihre eigene Infrastruktur, sodass es für Ihren Code weniger wichtig sein kann, sich bewusst zu sein, dass er in einer mehrinstanzenfähigen Umgebung ausgeführt wird.
Manchmal werden Bereitstellungen als Supermandanten oder Stempel bezeichnet.
Wenn Sie eine Anforderung für einen bestimmten Mandanten erhalten, müssen Sie sie der Bereitstellung zuordnen, die die Daten dieses Mandanten enthält, wie hier dargestellt:
Mandantenisolation
Einer der wichtigsten Aspekte beim Entwerfen einer mehrinstanzenfähigen Architektur ist die Isolationsstufe, die jeder Mandant benötigt. Isolation kann verschiedene Dinge bedeuten:
- Eine einzelne gemeinsam genutzte Infrastruktur mit separaten Instanzen Ihrer Anwendung und separaten Datenbanken für jeden Mandanten
- Gemeinsame Nutzung einiger gemeinsamer Ressourcen, wobei andere Ressourcen für jeden Mandanten getrennt bleiben
- Speichern von Daten in einer separaten physischen Infrastruktur. In der Cloud sind für diese Konfiguration möglicherweise separate Azure-Ressourcen für jeden Mandanten erforderlich. Dies kann sogar die Bereitstellung einer separaten physischen Infrastruktur mit dedizierten Hosts bedeuten.
Anstatt Isolation als eine diskrete Eigenschaft zu betrachten, sollten Sie sie als ein Kontinuum ansehen. Sie können abhängig von Ihren Anforderungen Komponenten Ihrer Architektur bereitstellen, die mehr oder weniger isoliert sind als andere Komponenten in derselben Architektur. Die folgende Abbildung zeigt ein Kontinuum der Isolation:
Die Isolationsstufe wirkt sich auf viele Aspekte Ihrer Architektur aus, einschließlich der folgenden:
- Sicherheit. Wenn Sie eine Infrastruktur für mehrere Mandanten gemeinsam nutzen, müssen Sie besonders darauf achten, dass Sie nicht auf Daten eines Mandanten zugreifen, wenn Sie Antworten an einen anderen Mandanten zurückgeben. Sie benötigen eine starke Grundlage für Ihre Identitätsstrategie, und Sie müssen sowohl die Mandanten- als auch die Benutzeridentität in Ihrem Autorisierungsprozess berücksichtigen.
- Kosten: Freigegebene Infrastruktur kann von mehreren Mandanten verwendet werden und ist daher kosteneffizienter.
- Leistung. Wenn Sie Infrastruktur gemeinsam nutzen, wird die Leistung Ihres Systems möglicherweise beeinträchtigt, wenn mehr Kunden sie verwenden, da die Ressourcen möglicherweise schneller verbraucht werden.
- Zuverlässigkeit. Wenn Sie eine einzelne freigegebene Infrastruktur verwenden, kann ein Problem mit den Komponenten eines Mandanten zu einem Ausfall für alle führen.
- Reaktionsfähigkeit auf die Anforderungen einzelner Mandanten. Wenn Sie eine Infrastruktur bereitstellen, die nur für einen Mandanten bestimmt ist, können Sie die Konfiguration für die Ressourcen auf die Anforderungen dieses speziellen Mandanten anpassen. Sie könnten diese Funktion sogar in Ihrem Preismodell berücksichtigen, in dem Sie Kunden die Möglichkeit geben, für isolierte Bereitstellungen mehr zu bezahlen.
Ihre Lösungsarchitektur kann Ihre verfügbaren Isolationsoptionen beeinflussen. Betrachten Sie beispielsweise eine Lösungsarchitektur mit drei Ebenen:
- Ihre Benutzeroberflächenebene kann eine freigegebene mehrinstanzenfähige Web-App sein, und alle Ihre Mandanten greifen auf einen einzelnen Hostnamen zu.
- Ihre mittlere Ebene könnte eine freigegebene Anwendungsschicht mit freigegebenen Nachrichtenwarteschlangen sein.
- Ihre Datenebene kann isolierte Datenbanken, Tabellen oder Blobcontainer umfassen.
Sie können erwägen, verschiedene Isolationsstufen auf den einzelnen Ebenen zu verwenden. Ihre Entscheidung darüber, was freigegeben und was isoliert ist, sollte auf vielen Überlegungen basieren, einschließlich Kosten, Komplexität, Anforderungen Ihrer Kunden und der Anzahl von Ressourcen, die Sie bereitstellen können, bevor Sie Azure-Kontingente und -Grenzwerte erreichen.
Gängige Mandantenmodelle
Nachdem Sie Ihre Anforderungen festgelegt haben, bewerten Sie sie anhand einiger gängiger Mandantenmodelle und entsprechender Bereitstellungsmuster.
Automatisierte Bereitstellungen mit einem Mandanten
In einem automatisierten Bereitstellungsmodell mit einem Mandanten stellen Sie eine dedizierte Infrastruktur für jeden Mandanten wie im folgenden Beispiel dargestellt bereit:
Ihre Anwendung ist für das Initiieren und Koordinieren der Bereitstellung der Ressourcen der einzelnen Mandanten verantwortlich. In der Regel nutzen Lösungen, die dieses Modell verwenden, häufig Infrastructure-as-Code (IaC) oder die Azure Resource Manager-APIs. Sie können diesen Ansatz verwenden, wenn Sie für jeden Ihrer Kunden vollständig separate Infrastrukturen bereitstellen müssen. Berücksichtigen Sie beim Planen Ihrer Bereitstellung das Muster „Bereitstellungsstempel“.
Vorteile: Ein Hauptvorteil dieses Ansatzes besteht darin, dass die Daten für jeden Mandanten isoliert sind, wodurch das Risiko versehentlicher Datenlecks reduziert wird. Dieser Schutzmechanismus kann für einige Kunden mit hohem Mehraufwand für die Einhaltung gesetzlicher Bestimmungen wichtig sein. Außerdem ist es unwahrscheinlich, dass sich die Mandanten gegenseitig in ihrer Systemleistung beeinflussen. Dieses Problem manchmal als Noisy Neighbor-Problem bezeichnet. Updates und Änderungen können mandantenübergreifend progressiv eingeführt werden, wodurch die Wahrscheinlichkeit eines systemweiten Ausfalls verringert wird.
Risiken: Wenn Sie diesen Ansatz verwenden, ist die Kosteneffizienz gering, da Sie die Infrastruktur nicht unter Ihren Mandanten aufteilen. Wenn ein einzelner Mandant bestimmte Infrastrukturkosten erfordert, benötigen 100 Mandanten wahrscheinlich das Hundertfache dieser Kosten. Darüber hinaus ist die laufende Wartung (z. B. das Anwenden von neuen Konfigurationen oder Softwareupdates) wahrscheinlich zeitaufwändig. Ziehen Sie in Erwägung, Ihre Betriebsprozesse zu automatisieren, und überlegen Sie, ob Sie Änderungen schrittweise in Ihren Umgebungen anwenden können. Sie sollten auch andere bereitstellungsübergreifende Vorgänge in Betracht ziehen, z. B. die Erstellung von Berichten und Analysen für Ihre gesamte Umgebung. Stellen Sie außerdem sicher, dass Sie berücksichtigen, wie Sie Daten bereitstellungsübergreifen abfragen und bearbeiten können.
Vollständig mehrinstanzenfähige Bereitstellungen
Im entgegengesetzten Extremfall können Sie eine vollständig mehrinstanzenfähige Bereitstellung in Betracht ziehen, bei der alle Komponenten gemeinsam genutzt werden. Sie verfügen über nur eine Gruppe von Infrastruktur zum Bereitstellen und Verwalten, und alle Mandanten verwenden sie, wie in der folgenden Abbildung dargestellt:
Vorteile: Dieses Modell ist attraktiv, da der Betrieb einer Lösung mit freigegebenen Komponenten kostengünstiger ist. Selbst wenn Sie höhere Ebenen oder SKUs von Ressourcen bereitstellen müssen, sind die Gesamtkosten für die Bereitstellung häufig niedriger als bei einer Gruppe von Ressourcen mit nur einem Mandanten. Wenn ein Benutzer oder Mandant seine Daten in einen anderen Mandanten verschieben muss, können Sie möglicherweise Mandantenbezeichner und Schlüssel aktualisieren, und Sie müssen möglicherweise keine Daten zwischen zwei separaten Bereitstellungen migrieren.
Risiken:
Achten Sie darauf, dass Sie die Daten für jeden Mandanten trennen und keine Datenlecks zwischen den Mandanten entstehen. Möglicherweise müssen Sie das Sharding von Daten verwalten. Darüber hinaus müssen Sie sich möglicherweise darüber Gedanken machen, welche Auswirkungen einzelne Mandanten auf das Gesamtsystem haben können. Wenn beispielsweise ein großer Mandant versucht, eine umfangreiche Abfrage oder einen umfangreichen Vorgang auszuführen, wirkt sich dies möglicherweise auf andere Mandanten aus.
Legen Sie fest, wie Sie Ihre Azure-Kosten nachverfolgen und den Mandanten zuordnen, wenn dies für Sie wichtig ist.
Die Wartung kann mit einer einzelnen Bereitstellung einfacher sein, da Sie nur eine Gruppe von Ressourcen aktualisieren müssen. Dies ist jedoch häufig auch riskanter, da sich Änderungen auf Ihren gesamten Kundenstamm auswirken können.
Möglicherweise müssen Sie auch eine Skalierung in Betracht ziehen. Wenn Sie über eine gemeinsam genutzte Infrastruktur verfügen, erreichen Sie eher die Grenzwerte für die Azure-Ressourcenskalierung. Wenn Sie beispielsweise ein Speicherkonto als Teil Ihrer Lösung verwenden, erreichen bei zunehmender Skalierung die Anzahl der Anforderungen an dieses Speicherkonto möglicherweise die Grenze dessen, was das Speicherkonto verarbeiten kann. Um zu vermeiden, dass Sie auf Ressourcenkontingentlimit erreichen, können Sie in Erwägung ziehen, mehrere Instanzen Ihrer Ressourcen bereitzustellen (z. B. mehrere AKS-Cluster oder Speicherkonten). Sie können sogar überlegen, Ihre Mandanten auf Ressourcen zu verteilen, die Sie in mehreren Azure-Abonnements bereitgestellt haben.
Es gibt wahrscheinlich eine Grenze, wie weit Sie eine einzelne Bereitstellung skalieren können, und die Kosten dafür können ggf. nichtlinear ansteigen. Wenn Sie z. B. eine einzelne, freigegebene Datenbank verwenden, kann es sein, dass Sie bei einer sehr hohen Skalierung möglicherweise den Durchsatz ausschöpfen und zunehmend mehr für einen höheren Durchsatz bezahlen müssen, um mit der Nachfrage Schritt zu halten.
Vertikal partitionierte Bereitstellungen
Sie müssen sich nicht für einen dieser Extrempunkte dieser Bandbreite entscheiden. Stattdessen können Sie eine vertikale Partition Ihrer Mandanten in Betracht ziehen, indem Sie diesen Ansatz verwenden:
- Verwenden Sie eine Kombination aus Bereitstellungen mit einem Mandanten und mehrinstanzenfähigen Bereitstellungen. Beispielsweise verfügen Sie möglicherweise über die meisten Daten- und Anwendungsebenen Ihrer Kunden in mehrinstanzenfähigen Infrastrukturen, aber Sie können Infrastruktur mit nur einem Mandanten für Kunden bereitstellen, die eine höhere Leistung oder Datenisolation benötigen.
- Stellen Sie mehrere Instanzen Ihrer Lösung geografisch bereit, und ordnen Sie jeden Mandanten einer bestimmten Bereitstellung zu. Dieser Ansatz ist besonders effektiv, wenn Sie Mandanten in verschiedenen geografischen Regionen nutzen.
Das folgende Beispiel veranschaulicht eine gemeinsam genutzte Bereitstellung für einige Mandanten und eine Bereitstellung mit einem einzelnen Mandanten für einen anderen Mandanten:
Vorteile: Da Sie die Infrastruktur weiterhin gemeinsam nutzen, können Sie einige der Kostenvorteile erzielen, die sich aus gemeinsam genutzten mehrinstanzenfähigen Bereitstellungen ergeben. Sie können kosteneffizientere, freigegebene Ressourcen für bestimmte Kunden bereitstellen, z. B. für solche Kunden, die Ihren Dienst mit einer Testversion ausprobieren. Sie können Kunden sogar einen höheren Tarif für eine Bereitstellung mit nur einem Mandanten in Rechnung stellen und so einen Teil Ihrer Kosten wieder ausgleichen.
Risiken: Ihre Codebasis muss wahrscheinlich so entworfen werden, dass sie sowohl mehrinstanzenfähige Bereitstellungen als auch Bereitstellungen mit nur einem Mandanten unterstützt. Wenn Sie Migration zwischen Infrastrukturen zulassen möchten, müssen Sie berücksichtigen, wie Sie Kunden aus einer mehrinstanzenfähigen Bereitstellung zu ihrer eigenen Bereitstellung mit nur einem Mandanten migrieren. Außerdem müssen Sie wissen, welche Ihrer Mandanten sich in welchen Bereitstellungen befinden, damit Sie den relevanten Kunden Informationen zu Systemproblemen oder Upgrades übermitteln können.
Horizontal partitionierte Bereitstellungen
Sie können auch horizontale Partitionierung Ihrer Bereitstellungen in Betracht ziehen. In einer horizontalen Bereitstellung verfügen Sie über einige freigegebene Komponenten, verwalten aber andere Komponenten mit Einzelmandantenbereitstellungen. Beispielsweise können Sie eine einzelne Anwendungsebene erstellen und dann einzelne Datenbanken für jeden Mandanten bereitstellen, wie im folgenden Diagramm gezeigt:
Vorteile: Horizontal partitionierte Bereitstellungen können Ihnen dabei helfen, ein Noisy Neighbor-Problem zu beheben, wenn Sie feststellen, dass der größte Teil der Last in Ihrem System auf bestimmte Komponenten zurückzuführen ist, die Sie separat für jeden Mandanten bereitstellen können. Ihre Datenbanken können z. B. den größten Teil der Systemlast aufnehmen, da die Abfragelast hoch ist. Wenn ein einzelner Mandant eine große Anzahl von Anforderungen an Ihre Lösung sendet, kann sich dies negativ auf die Leistung einer Datenbank auswirken, aber die Datenbanken anderer Mandanten (und freigegebene Komponenten wie die Anwendungsebene) werden davon nicht betroffen.
Risiken: Bei einer horizontal partitionierten Bereitstellung müssen Sie weiterhin die automatisierte Bereitstellung und Verwaltung Ihrer Komponenten berücksichtigen, insbesondere die Komponenten, die von einem einzelnen Mandanten verwendet werden.
Testen des Isolationsmodells
Unabhängig davon, welches Isolationsmodell Sie auswählen, stellen Sie sicher, dass Sie Ihre Lösung testen, um zu überprüfen, ob die Daten eines Mandanten nicht versehentlich an einen anderen übertragen werden und dass Noisy Neighbor-Effekte akzeptabel sind. Erwägen Sie die Verwendung von Azure Chaos Studio, um absichtlich Fehler einzuführen, die reale Ausfälle simulieren, und überprüfen Sie die Resilienz Ihrer Lösung, auch wenn Komponenten fehlerhaft sind.
Beitragende
Dieser Artikel wird von Microsoft gepflegt. Er wurde ursprünglich von folgenden Mitwirkenden geschrieben:
Hauptautor:
- John Downs | Principal Customer Engineer, FastTrack for Azure
Andere Mitwirkende:
- Chad Kittel | Principal Software Engineer
- Paolo Salvatori | Principal Customer Engineer, FastTrack for Azure
- Arsen Vladimirskiy | Principal Customer Engineer, FastTrack for Azure
Melden Sie sich bei LinkedIn an, um nicht öffentliche LinkedIn-Profile anzuzeigen.
Nächste Schritte
Überlegungen zum Lebenszyklus Ihrer Mandanten