Mehrinstanzenfähigkeitsmodelle für eine mehrinstanzenfähige Lösung

Für die Arbeit mit Mandanten in Ihrer Lösung gibt es mehrere Lösungen. Ihr Ansatz hängt 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 in Betracht ziehen, ist es hilfreich, sich zunächst zu überlegen, wie Sie die Mandanten für Ihr Unternehmen definieren, was Ihre geschäftlichen Beweggründe sind und wie Sie Ihre Lösung skalieren wollen. Dieser Artikel enthält Richtlinien, die technischen Entscheidungsträgern helfen sollen, Instanzenmodelle und deren Kompromisse zu bewerten.

Definieren eines Mandanten

Sie müssen zunächst einen Mandanten für Ihr Unternehmen definieren. Überlegen Sie, wer Ihr Kunde ist oder wer Ihre Dienste erhält. Es gibt zwei häufige Modelle:

• Business to business (B2B): Wenn Ihre Kunden andere Unternehmen sind, ordnen Sie Ihre Mandanten wahrscheinlich diesen Kunden zu. Überlegen Sie jedoch, ob Ihre Kunden Abteilungen wie Teams oder Abteilungen haben und ob sie in mehreren Ländern oder Regionen präsent sind. Möglicherweise müssen Sie einen einzelnen Kunden mehreren Mandanten zuordnen, wenn unterschiedliche Anforderungen für diese Untergruppen gelten. Ebenso möchte ein Kunde möglicherweise zwei Instanzen Ihres Diensts verwalten, damit sie ihre Entwicklungs- und Produktionsumgebungen voneinander trennen können. Ein einzelner Mandant hat in der Regel mehrere Benutzer. Beispielsweise sind alle Mitarbeiter des Kunden Benutzer innerhalb eines einzelnen Mandanten.

• Business to Consumer (B2C): Wenn Ihre Kunden Verbraucher sind, ist es oft komplizierter, Kunden, Mandanten und Benutzer zu verknüpfen. 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 zum Beispiel die folgenden Arten von Mandanten:

• Wenn Es sich bei Ihren Mandanten um einzelne Personen oder Familien handelt, müssen Sie ggf. überlegen, wie Sie personenbezogene Daten und die Datenhoheitsgesetze in jeder von Ihnen dienenden Zuständigkeit behandeln.

• Wenn Es sich bei Ihren Mandanten um Unternehmen handelt, müssen Sie möglicherweise die Anforderungen Ihrer Kunden hinsichtlich der Einhaltung gesetzlicher Vorschriften und der Isolierung ihrer Daten berücksichtigen. Stellen Sie sicher, dass Sie ein angegebenes Ziel auf Dienstebene (Service Level Objective, SLO) erfüllen, z. B. Verfügbarkeit von Betriebszeiten oder Diensten.

Entscheiden, welches Modell verwendet werden soll

Die Auswahl eines Mandantenmodells ist nicht nur eine technische Entscheidung. Es ist auch eine kommerzielle Entscheidung. Sie müssen die folgenden Fragen berücksichtigen:

• Geschäftsziele: Überlegen Sie, ob die Kosten für jeden Mieter gesenkt werden sollen oder ob die Mietererfahrung maximiert werden soll, um besser mit den strategischen Zielen übereinzustimmen.

• Compliance: Berücksichtigen Sie, ob Ihre Kunden alle Formen der Mehrinstanzenfähigkeit akzeptieren werden. Wie wirkt sich jedes Mehrinstanzenmodell auf Ihre Complianceanforderungen oder die Complianceanforderungen Ihrer Kunden aus?

• Maßstab: Überlegen Sie, ob eine Einzelmandantenlösung auf Ihre zukünftigen Wachstumswünsche skaliert werden kann.

• Automatisierung: Berücksichtigen Sie die Größe Ihres Betriebsteams und den Umfang Ihrer Infrastrukturverwaltung, den Sie automatisieren können.

• Vereinbarungen auf Serviceebene (SLAs): Überlegen Sie, ob Ihre Kunden erwarten, dass Sie SLAs erfüllen oder ob Sie SLOs 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 Flotte von Ressourceninstanzen verwalten. Die Bereitstellung einzelner Azure-Ressourcen für jeden Kunden ist wahrscheinlich nicht nachhaltig, es sei denn, Sie stellen ein dediziertes Abonnement für jeden Mandanten bereit und verwenden es. Wenn Sie dasselbe Azure-Abonnement für mehrere Mandanten freigeben, können Azure-Ressourcenkontingente und -grenzwerte gelten, und die Betriebskosten für die Bereitstellung und Neukonfiguration dieser Ressourcen erhöhen sich bei 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, auch wenn dieser Ansatz kostenaufwändiger ist.

Mandanten und Bereitstellungen

Als nächstes sollten Sie festlegen, ob Sie zwischen logischen Mandanten und Bereitstellungen unterscheiden sollten.

Betrachten Sie beispielsweise einen Musikstreamingdienst. Zunächst können Sie eine Lösung erstellen, die tausende oder sogar Zehntausende von Benutzern problemlos verarbeiten kann. Da Ihre Organisation jedoch weiterhin wächst, stellen Sie möglicherweise fest, dass Sie Ihre Lösung duplizieren müssen, oder einige seiner Komponenten, um auf neue Kundennachfrage zu skalieren. Um diese Aufgabe auszuführen, müssen Sie bestimmen, wie bestimmte Kunden bestimmten Instanzen Ihrer Lösung zugewiesen werden. Sie können Kunden zufällig, geografisch oder durch Ausfüllen einer einzelnen Instanz zuweisen und dann eine andere Instanz starten, auch als Bin Packing bezeichnet. Sie müssen jedoch wahrscheinlich einen Datensatz Ihrer Kunden und der Infrastruktur verwalten, in der sich ihre Daten und Anwendungen befinden, damit Sie den Datenverkehr an den richtigen Speicherort weiterleiten können. In diesem Beispiel können Sie jeden Kunden als separaten Mandanten darstellen und Benutzern die Bereitstellung zuordnen, die ihre Daten enthält. Auf diese Weise entsteht eine Eins-zu-viele-Beziehung zwischen Mandanten und Bereitstellungen, und Sie können Mandanten nach Belieben zwischen Bereitstellungen verschieben.

Stellen Sie sich im Gegensatz dazu ein Unternehmen vor, das Cloudsoftware für Anwaltskanzleien erstellt. Ihre Kunden könnten auf einer eigenen Infrastruktur bestehen, um die Einhaltung gesetzlicher Vorschriften zu gewährleisten. 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 Mandanten ihre eigenen Bereitstellungen haben, verfügen sie über ihre eigene Infrastruktur, sodass es für Ihren Code weniger wichtig sein könnte, eine Mehrinstanzenfähigkeit zu berücksichtigen.

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 im folgenden Diagramm dargestellt:

Das Diagramm ist in drei Hauptabschnitte unterteilt: Mandanten, Ihre Lösung sowie die ID des Mandanten und die ID der Bereitstellung. Die Pfeile zeigen von den Mandanten A, B, C und D auf ein Feld mit der Aufschrift Mandantenzuordnung im Lösungsabschnitt. Dieser Abschnitt enthält auch einen Webserver und eine Datenbank für die Bereitstellung 1 und Bereitstellung 2. Ein weiterer Pfeil zeigt vom Feld für die Zuordnung der Mandanten auf den Abschnitt, der die IDs der Mandanten und der Bereitstellung enthält. Mandanten A und B verfügen über eine Bereitstellungs-ID von 1, und Mandanten C und D verfügen über eine Bereitstellungs-ID von 2.

Weitere Informationen finden Sie unter Zuordnen von Anforderungen an Mandanten.

Mieterisolierung

Eine der wichtigsten Überlegungen bei der Entwicklung einer mehrinstanzenfähigen Architektur ist der Grad der Isolierung, den jeder Mandant benötigt. Isolation kann auf die folgenden Konfigurationen verweisen:

• Eine einzige gemeinsam genutzte Infrastruktur, die separate Instanzen Ihrer Anwendung und separate Datenbanken für jeden Mandanten enthält.

• 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. In extremen Szenarien kann es sogar erforderlich sein, eine separate physische Infrastruktur mithilfe dedizierter Hosts bereitzustellen.

Anstatt die Isolation als diskrete Eigenschaft zu betrachten, sollten Sie es als Spektrum betrachten. Sie können Komponenten Ihrer Architektur bereitstellen, die je nach Ihren Anforderungen isolierter oder weniger isoliert sind als andere Komponenten in derselben Architektur. Die folgende Abbildung zeigt ein Kontinuum der Isolation:

Das Diagramm zeigt einen Pfeil von vollständig isoliert (nichts gemeinsam genutzt) zu vollständig gemeinsam genutzt (alles gemeinsam genutzt). Auf der vollständig isolierten Seite enthalten blaue Boxen separate Rechenressourcen, separate Datenbanken, separate Netzwerke und separate Domänennamen. Die grünen Kästchen in der Mitte des Pfeils enthalten gemeinsam genutzte Rechenleistung, gemeinsam genutzte Netzwerke und gemeinsam genutzte Domänennamen. Ein blaues Feld enthält separate Datenbanken. Auf der vollständig gemeinsam genutzten Seite enthalten die grünen Kästchen gemeinsam genutzte Rechenleistung, gemeinsam genutzte Datenbank, gemeinsam genutzte Netzwerke und gemeinsam genutzte Domänennamen.

Die Isolationsstufe wirkt sich auf viele Aspekte Ihrer Architektur aus:

• Sicherheit: Wenn Sie die Infrastruktur für mehrere Mandanten freigeben, achten Sie darauf, nicht auf Daten von einem Mandanten zuzugreifen, wenn Sie Antworten an einen anderen 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: Mehrere Mandanten können gemeinsam genutzte Infrastruktur verwenden, sodass sie weniger teuer ist.

• Leistung: Wenn Sie die Infrastruktur teilen, wird die Leistung Ihres Systems möglicherweise beeinträchtigt, da mehr Kunden sie nutzen, da die Ressourcen möglicherweise schneller verbraucht werden. Mandanten, die ungewöhnliche Nutzungsmuster aufweisen, können Leistungsprobleme verschlimmern.

• Zuverlässigkeit: Wenn Sie eine einzelne Gruppe gemeinsam genutzter Infrastruktur verwenden, kann ein Problem mit einer Komponente zu einem Ausfall für alle Ihre Mandanten führen.

• Reaktionsfähigkeit auf individuelle Mandantenanforderungen: Wenn Sie eine Infrastruktur bereitstellen, die einem Mandanten zugeordnet ist, können Sie die Konfiguration für die Ressourcen möglicherweise an die Anforderungen des jeweiligen Mandanten anpassen. Sie können diese Funktion sogar in Ihrem Preismodell berücksichtigen, damit Kunden mehr für isolierte Bereitstellungen bezahlen können.

Ihre Lösungsarchitektur kann Ihre verfügbaren Isolationsoptionen beeinflussen. Betrachten Sie beispielsweise eine Lösungsarchitektur mit drei Ebenen:

• Ihre Benutzeroberflächenebene könnte eine gemeinsam genutzte mehrinstanzenfähige Web-App sein. Alle Ihre Mandanten greifen auf einen einzigen Hostnamen zu.

• Ihre mittlere Ebene kann eine gemeinsame Anwendungsschicht sein, die gemeinsame Nachrichtenwarteschlangen enthält.

• Ihre Datenebene kann isolierte Datenbanken, Tabellen oder BLOB-Container sein.

Sie können für jede Ebene unterschiedliche Isolationsebenen verwenden. Sie sollten Ihre Entscheidung darüber, was Sie teilen und was Sie isolieren, auf mehreren Faktoren basieren, einschließlich der Kosten, der Komplexität, der Anforderungen Ihrer Kunden und der Anzahl der Ressourcen, die Sie bereitstellen können, bevor Sie die 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 Einzelmandantenbereitstellungsmodell stellen Sie eine dedizierte Infrastruktur für jeden Mandanten bereit, wie im folgenden Beispiel gezeigt:

Das Diagramm ist in drei Abschnitte unterteilt, eine für Mandant A, eine für Mandant B und eine für Mandant C. Ein Pfeil zeigt von Mandant A auf ein Feld mit der Bezeichnung "Bereitstellung A". Dieses Feld enthält einen Webserver für Den Mandanten A. Ein weiterer Pfeil zeigt von Mandant B auf ein Feld mit der Bezeichnung "Bereitstellung B". Dieses Feld enthält einen Webserver für Mandanten B. Ein weiterer Pfeil zeigt von Mandant C auf ein Feld mit der Bezeichnung Bereitstellung C. Dieses Feld enthält einen Webserver für Den Mandanten C.

Ihre Anwendung ist für das Initiieren und Koordinieren der Bereitstellung der Ressourcen der einzelnen Mandanten verantwortlich. In der Regel verwenden Lösungen, die dieses Modell verwenden, Infrastruktur als Code oder die Azure Resource Manager-APIs umfassend. 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 Schutz kann für Kunden wichtig sein, die einen hohen Aufwand für die Einhaltung gesetzlicher Vorschriften haben. Außerdem ist es unwahrscheinlich, dass sich die Mandanten gegenseitig in ihrer Systemleistung beeinträchtigen, auch bekannt als das Problem der lauten Nachbarn. 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 niedrig, da Sie die Infrastruktur nicht für Ihre Mandanten freigeben. Wenn ein einzelner Mandant eine bestimmte Infrastrukturkosten erfordert, benötigen 100 Mandanten wahrscheinlich 100 Mal die Kosten. Außerdem kann die laufende Wartung, z. B. das Anwenden neuer Konfigurationen oder Softwareupdates, zeitaufwändig sein. 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 Flotte. Planen Sie, wie Sie Daten in mehreren Bereitstellungen abfragen und bearbeiten können.

Vollständig mehrinstanzenfähige Bereitstellungen

Im gegenteiligen Extrem können Sie eine vollständig mehrinstanzenfähige Bereitstellung in Betracht ziehen, in 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:

In diesem Diagramm zeigen Pfeile von Feldern mit der Bezeichnung "Mandant A", "Mandant B" und "Mandant C" auf ein Feld, das als gemeinsame Ressourcen bezeichnet wird. Diese Box enthält einen Webserver für die Mandanten A, B und C.

Nützt: Dieses Modell ist ansprechend, da das Ausführen einer Lösung mit gemeinsam genutzten Komponenten weniger teuer ist als die Verwendung einzelner Ressourcen für jeden Mandanten. Selbst wenn Sie höhere Ebenen oder SKUs von Ressourcen bereitstellen müssen, um der erhöhten Last Rechnung zu tragen, 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 Mandanten-IDs 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. Möglicherweise müssen Sie auch die Auswirkungen berücksichtigen, die 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.

• Ermitteln Sie, wie Sie Ihre Azure-Kosten für Mandanten nachverfolgen und zuordnen, wenn diese Informationen für Sie wichtig sind.

• Sie können die Wartung vereinfachen, indem Sie eine einzelne Bereitstellung verwenden, da Sie nur eine Gruppe von Ressourcen aktualisieren müssen. Es ist jedoch auch oft riskanter, da sich Änderungen auf Ihre gesamte Kundenbasis 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 das Erreichen eines Ressourcenkontingentlimits zu vermeiden, können Sie einen Pool mehrerer Instanzen Ihrer Ressourcen bereitstellen, 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 Beschränkung, wie weit Sie eine einzelne Bereitstellung skalieren können, und die Kosten für die Skalierung können möglicherweise nichtlinear steigen. Wenn Sie z. B. eine einzelne gemeinsam genutzte Datenbank in großem Maßstab betreiben, kann es sein, dass Sie den Durchsatz ausschöpfen und immer mehr für einen höheren Durchsatz bezahlen müssen, um mit Ihrer Nachfrage Schritt zu halten.

Vertikal partitionierte Bereitstellungen

Sie müssen sich nicht für einen dieser Extrempunkte dieser Bandbreite entscheiden. Stattdessen können Sie Ihre Mandanten vertikal partitionieren, indem Sie den folgenden Ansatz verwenden:

• Verwenden Sie eine Kombination aus Bereitstellungen mit einem Mandanten und mehrinstanzenfähigen Bereitstellungen. Beispielsweise haben Sie möglicherweise die meisten Daten- und Anwendungsebenen Ihrer Kunden auf mehrinstanzenfähigen Infrastrukturen, aber Sie stellen Einzelmandanten-Infrastrukturen für Kunden bereit, die eine höhere Leistung oder Datenisolation erfordern.

• Stellen Sie mehrere Instanzen Ihrer Lösung geografisch bereit, und ordnen Sie jeden Mandanten einer bestimmten Bereitstellung zu. Dieser Ansatz ist effektiv, wenn Sie Mandanten in verschiedenen Regionen haben.

Das folgende Beispiel veranschaulicht eine gemeinsam genutzte Bereitstellung für einige Mandanten und eine Bereitstellung mit einem einzelnen Mandanten für einen anderen Mandanten:

In diesem Diagramm zeigen die Pfeile von Mandant A und Mandant B auf ein Feld, das mit Bereitstellung 1 bezeichnet ist. Dieses Feld enthält einen Webserver für Mandanten A und B. Ein weiterer Pfeil verweist von Mandant C auf ein Feld mit der Bezeichnung "Deployment 2". Dieses Feld enthält einen Webserver für Mandanten C.

Nützt: Da Sie noch einige Ihrer Infrastruktur teilen, können Sie einige der Kostenvorteile der Verwendung gemeinsam genutzter mehrinstanzenfähiger Bereitstellungen erzielen. Sie können kostengünstigere freigegebene Ressourcen für bestimmte Kunden bereitstellen, z. B. Kunden, die Ihren Dienst mithilfe einer Testversion auswerten. Sie können Kunden sogar einen höheren Preis für die Nutzung einer Single-Tenant-Bereitstellung berechnen, wodurch Sie einen Teil Ihrer Kosten decken können.

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 Bereitstellungen 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 jeder Bereitstellung befinden, damit Sie Informationen zu Systemproblemen oder Upgrades an die relevanten Kunden übermitteln können.

Horizontal partitionierte Bereitstellungen

Sie können Ihre Bereitstellungen auch horizontal partitionieren. In einer horizontalen Bereitstellung verfügen Sie über einige freigegebene Komponenten, verwalten aber andere Komponenten mit Einzelmandantenbereitstellungen. Sie können z. B. eine einzelne Anwendungsebene erstellen und dann einzelne Datenbanken für jeden Mandanten bereitstellen, wie in diesem Diagramm gezeigt:

In diesem Diagramm zeigen Pfeile von Boxen mit der Bezeichnung "Mandant A", "Mandant B" und "Mandant C" auf eine Box, die einen Webserver enthält, den die Mandanten A, B und C gemeinsam nutzen.

Nützt: Horizontal partitionierte Bereitstellungen können Ihnen helfen, ein lautes Nachbarproblem zu mindern. Wenn Sie feststellen, dass bestimmte Komponenten den größten Teil der Auslastung ihres Systems verursachen, können Sie separate Komponenten für jeden Mandanten bereitstellen. Zum Beispiel könnten Ihre Datenbanken den größten Teil der Systemlast absorbieren, weil die Abfragelast hoch ist. Wenn ein einzelner Mandant eine große Anzahl von Anforderungen an Ihre Lösung sendet, kann die Leistung einer Datenbank beeinträchtigt werden, aber die Datenbanken anderer Mandanten und gemeinsam genutzte Komponenten wie die Anwendungsschicht bleiben davon unberührt.

Risiken: Bei einer horizontal partitionierten Bereitstellung müssen Sie dennoch die automatisierte Bereitstellung und Verwaltung Ihrer Komponenten berücksichtigen, insbesondere die Komponenten, die ein einzelner Mandant verwendet.

Testen des Isolationsmodells

Je nachdem, welches Isolationsmodell Sie auswählen, sollten Sie Ihre Lösung testen, um sicherzustellen, dass die Daten eines Mandanten nicht versehentlich an eine andere verloren gehen und dass alle lauten Nachbarn-Ergebnisse 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

Microsoft verwaltet diesen Artikel. Die folgenden Mitwirkenden haben diesen Artikel geschrieben.

Hauptautor:

• John Downs | Principal Software Engineer, Azure Patterns & Practices

Andere Mitwirkende:

• Chad Kittel | Principal Software Engineer, Azure Patterns & Practices
• Paolo Salvadori | Principal Customer Engineer, FastTrack für Azure
• Arsen Vladimirskiy | Principal Customer Engineer, FastTrack für Azure

Um nicht-öffentliche LinkedIn-Profile anzuzeigen, melden Sie sich bei LinkedIn an.

Nächster Schritt

Berücksichtigen Sie den Lebenszyklus Ihrer Mandanten.