Überlegungen zu mehrinstanzenfähigen Steuerungsebenen

Eine mehrinstanzenfähige Lösung verfügt über mehrere Ebenen, und jede hat ihre eigenen Aufgaben. Die Datenebene ermöglicht Endbenutzern und Clients die Interaktion mit dem System. Die Steuerungsebene ist die Komponente, die übergeordnete Aufgaben für alle Mandanten verwaltet, z. B. Zugriffssteuerung, Bereitstellung und Systemwartung, um die Aufgaben Ihrer Plattformadministratoren zu unterstützen.

Dieser Artikel bietet Informationen zu den Aufgaben von Steuerungsebenen und wie Sie eine Steuerungsebene entwerfen, die Ihren Anforderungen entspricht.

Betrachten Sie beispielsweise ein Buchhaltungssystem für die Verwaltung von Finanzdatensätzen. Mehrere Mandanten speichern ihre Finanzdatensätze im System. Wenn Endbenutzer auf das System zugreifen, um ihre Finanzdatensätze anzuzeigen und einzugeben, verwenden sie die Datenebene. Die Datenebene ist wahrscheinlich die primäre Anwendungskomponente für Ihre Lösung. Ihre Mandanten betrachten sie wahrscheinlich als die Möglichkeit, um das System für seinen vorgesehenen Zweck zu verwenden. Die Steuerungsebene ist dagegen die Komponente, die neue Mandanten integriert, Datenbanken für jeden Mandanten erstellt und andere Verwaltungs- und Wartungsvorgänge ausführt. Wenn das System keine Steuerungsebene hätte, müssten Administratoren viele manuelle Prozesse ausführen. Oder Datenebenen- und Steuerungsebenenaufgaben würden miteinander gemischt, was die Lösung übermäßig komplex macht.

Viele komplexe Systeme enthalten Steuerungsebenen. Die Azure-Steuerungsebene Azure Resource Manager beispielsweise besteht aus einer Reihe von APIs, Tools und Back-End-Komponenten, die für die Bereitstellung und Konfiguration von Azure-Ressourcen verantwortlich sind. Die Kubernetes-Steuerungsebene verwaltet viele Aufgaben, z. B. die Platzierung von Kubernetes-Pods auf Workerknoten. Fast alle SaaS-Lösungen (Software-as-a-Service) verfügen über eine Steuerungsebene zur Verarbeitung mandantenübergreifender Aufgaben.

Wenn Sie mehrinstanzenfähige Lösungen entwerfen, müssen Sie Steuerungsebenen berücksichtigen. Die folgenden Abschnitte enthalten die Details, die Sie für die Umfangsdefinition und den Entwurf einer Steuerungsebene benötigen.

Aufgaben einer Steuerungsebene

Es gibt keine einzelne Vorlage für eine Steuerungsebene oder deren Aufgaben. Die Anforderungen und die Architektur Ihrer Lösung bestimmen, was Ihre Steuerungsebene tun muss. Bei einigen mehrinstanzenfähigen Lösungen hat die Steuerungsebene ein breites Aufgabenspektrum und ist ein eigenständiges, komplexes System. Bei anderen mehrinstanzenfähigen Lösungen übernimmt die Steuerungsebene nur grundlegende Aufgaben.

Im Allgemeinen kann eine Steuerungsebene viele der folgenden Kernaufgaben haben:

• Ressourcenverwaltung: Bereitstellen und Verwalten der Systemressourcen, die das System zur Verarbeitung der Workload benötigt, einschließlich mandantenspezifischer Ressourcen. Ihre Steuerungsebene könnte eine Bereitstellungspipeline aufrufen und orchestrieren , die für Bereitstellungen zuständig ist, oder sie könnte die Bereitstellungsvorgänge selbst ausführen.
• Ressourcenkonfiguration: Konfigurieren Sie freigegebene Ressourcen so neu, dass sie neue Mandanten berücksichtigen. Beispielsweise könnte Ihre Steuerungsebene das Netzwerkrouting konfigurieren, um sicherzustellen, dass eingehender Datenverkehr den Ressourcen des richtigen Mandanten zugeordnet wird, oder Sie müssen möglicherweise Ihre Ressourcenkapazität skalieren.
• Mandantenkonfiguration: Speichern und verwalten Sie die Konfiguration jedes einzelnen Mandanten.
• Mandanten-Lebenszyklusverwaltung: Behandeln von Mandantenlebenszyklus-Ereignissen, einschließlich Onboarding, Verschieben und Offboarding von Mandanten.
• Telemetrie: Verfolgen Sie die Verwendung Ihrer Features durch jeden Mandanten und die Leistung des Systems.
• Nachverfolgung des Verbrauchs: Messen Sie den Verbrauch der Ressourcen Ihres Systems durch jeden Mandanten. Verbrauchsmetriken können Ihren Abrechnungssysteme Daten liefern, oder sie können für die Ressourcengovernance verwendet.

Wenn Sie das vollständig mehrinstanzenfähige Mandantenmodell verwenden und keine mandantenspezifischen Ressourcen bereitstellen, nachverfolgt eine grundlegende Steuerungsebene eventuell nur Mandanten und deren zugehörige Metadaten. Beispielsweise könnte die Steuerungsebene immer, wenn sich ein neuer Mandant bei Ihrem Dienst anmeldet, die entsprechenden Datensätze in einer Datenbank aktualisieren, sodass der Rest des Systems die Anforderungen des neuen Mandanten verarbeiten kann.

Angenommen, Ihre Lösung verwendet hingegen ein Bereitstellungsmodell, das eine mandantenspezifische Infrastruktur erfordert, z. B. das automatisierte Einzelinstanzenmodell. In diesem Szenario hat Ihre Steuerungsebene möglicherweise weitere Aufgaben, z. B. das Bereitstellen oder Neukonfigurieren der Azure-Infrastruktur, wenn Sie das Onboarding eines neuen Mandanten durchführen. Bei dieser Art von Lösung muss die Steuerungsebene Ihrer Lösung wahrscheinlich mit den Steuerungsebenen für die von Ihnen verwendeten Dienste und Technologien interagieren, wie Azure Resource Manager oder die Kubernetes-Steuerungsebene.

Komplexere Steuerungsebenen können auch mehr Aufgaben übernehmen:

• Ausführen automatisierter Wartungsvorgänge: Gängige Wartungsvorgänge umfassen das Löschen oder Archivieren alter Daten, das Erstellen und Verwalten von Datenbankindizes sowie das Rotieren von Geheimnissen und kryptografischen Zertifikaten.
• Mandantenplatzierung: Teilen Sie Mandanten bestehenden Bereitstellungen oder Stempeln zu, entsprechend verschiedenen Kriterien wie den Zielen für die Stempelauslastung, Anforderungen an Mandanten und Strategien für das Bin Packing.
• Umverteilung der Mandanten: Verteilen Sie die vorhandenen Mandanten erneut auf die Bereitstellungsstempel, wenn sich ihre Auslastung ändert.
• Nachverfolgung der Kundenaktivitäten: Integration in externe Kundenverwaltungslösungen wie Microsoft Dynamics 365, um die Kundenaktivitäten nachzuverfolgen.

Umfangsdefinition einer Steuerungsebene

Sie müssen sorgfältig überlegen, wie viel Aufwand sie für die Erstellung einer Steuerungsebene für Ihre Lösung betreiben möchten. Steuerungsebenen an sich bieten keinen unmittelbaren Kundennutzen, sodass es möglicherweise nicht einfach ist, Ausgaben für die technische Entwicklung zum Entwerfen und Erstellen einer qualitativ hochwertigen Steuerungsebene zu rechtfertigen. Wenn Ihr System jedoch wächst und skaliert wird, benötigen Sie zunehmend automatisierte Verwaltung und Vorgänge, um mit Ihrem Wachstum Schritt halten zu können.

In bestimmten Situationen benötigen Sie möglicherweise keine vollständige Steuerungsebene. Diese Situation kann eintreten, wenn Ihr System über weniger als fünf bis zehn Mandanten verfügt. Stattdessen kann Ihr Team die Aufgaben einer Steuerungsebene übernehmen und manuelle Vorgänge und Prozesse verwenden, um das Onboarding von Mandanten durchzuführen und diese zu verwalten. Sie sollten jedoch weiterhin über einen Prozess und einen zentralen Ort zum Nachverfolgen Ihrer Mandanten und deren Konfigurationen verfügen.

Wenn Ihr Wachstum ein paar Mandanten überschreitet, werden Sie wahrscheinlich von einer Möglichkeit profitieren, jeden Mandanten nachzuverfolgen und die Überwachung auf Ihre Ressourcen- und Mandantenflotte anwenden zu können. Möglicherweise stellen Sie auch fest, dass Ihr Team immer mehr Zeit und Aufwand in die Mandantenverwaltung steckt. Oder Sie bemerken eventuell Fehler oder Betriebsprobleme aufgrund von Inkonsistenzen in der Art und Weise, wie Teammitglieder Verwaltungsaufgaben ausführen. Wenn diese Situationen auftreten, lohnt es sich, die Erstellung einer umfassenderen Steuerungsebene zu erwägen, um diese Aufgaben zu übernehmen.

Entwerfen einer Steuerungsebene

Nachdem Sie die Anforderungen und den Umfang Ihrer Steuerungsebene festgelegt haben, müssen Sie sie und ihre Architektur entwerfen. Eine Steuerungsebene ist eine wichtige Komponente. Sie müssen sie genau planen, genau wie die anderen Elemente Ihres Systems planen würden.

Well-Architected-Steuerungsebenen

Da eine Steuerungsebene ein eigenes System darstellt, ist es wichtig, bei deren Entwurf alle fünf Säulen des Azure Well-Architected Frameworks zu berücksichtigen. In den folgenden Abschnitten werden bestimmte Bereiche hervorgehoben, auf die sie sich konzentrieren sollten.

Zuverlässigkeit

Steuerungsebenen sind häufig unternehmenskritische Komponenten. Es ist wichtig, dass Sie das Maß an Resilienz und Zuverlässigkeit planen, das Ihre Steuerungsebene benötigt.

Überlegen Sie, was passiert, wenn Ihre Steuerungsebene nicht verfügbar ist. Im Extremfall kann ein Ausfall der Steuerungsebene dazu führen, dass Ihre gesamte Lösung nicht verfügbar ist. Auch wenn Ihre Steuerungsebene kein Single Point of Failure ist, kann ein Ausfall einige der folgenden Auswirkungen haben:

• Ihr System kann kein Onboarding neuer Mandanten durchführen, was sich auf das Wachstum Ihres Umsatzes und Ihrer Geschäfte auswirken kann.
• Ihr System kann vorhandene Mandanten nicht verwalten, was zu einem erhöhten Anrufaufkommen bei Ihrem Supportteam führt.
• Sie können den Verbrauch von Mandanten nicht messen oder ihnen ihre Nutzung in Rechnung stellen, was zu Umsatzeinbußen führt.
• Sie können nicht auf einen Sicherheitsvorfall reagieren, indem Sie einen Mandanten deaktivieren oder neu konfigurieren.
• Wartungsschulden häufen sich an, was zu langfristigen Schäden am System führt. Wenn Ihre Lösung beispielsweise eine nächtliche Bereinigung alter Daten erfordert, könnten Ihre Datenträger volllaufen, oder Ihre Leistung könnte beeinträchtigt werden.

Definieren Sie Servicelevelziele für Ihre Steuerungsebene, einschließlich Verfügbarkeitszielen, RTO (Recovery Time Objective) und RPO (Recovery Point Objective). Die Ziele, die Sie für Ihre Steuerungsebene festlegen, unterscheiden sich möglicherweise von denen, die Sie Ihren Kunden anbieten.

Befolgen Sie den Azure Well-Architected Framework-Leitfaden zum Erstellen zuverlässiger Lösungen in Ihrem gesamten System, einschließlich Ihrer Steuerungsebene.

Sicherheit

Steuerungsebenen sind häufig Systeme mit hohen Berechtigungen. Sicherheitsprobleme innerhalb einer Steuerungsebene können katastrophale Folgen haben. Abhängig von ihrem Entwurf und ihrer Funktionalität kann eine Steuerungsebene anfällig für viele verschiedene Arten von Angriffen sein, einschließlich der folgenden:

• Eine Steuerungsebene kann möglicherweise Zugriff auf Schlüssel und Geheimnisse für alle Mandanten haben. Ein Angreifer, der Zugriff auf Ihre Steuerungsebene hat, kann möglicherweise Zugriff auf die Daten oder Ressourcen eines Mandanten erhalten.
• Eine Steuerungsebene kann häufig neue Ressourcen in Azure bereitstellen. Angreifer können möglicherweise Ihre Steuerungsebene ausnutzen, um ihre eigenen Ressourcen in Ihren Abonnements bereitzustellen, was bei Ihnen möglicherweise umfangreiche Gebühren verursachen kann.
• Wenn ein Angreifer Ihre Steuerungsebene erfolgreich offline schaltet, kann es zu sofortigen und langfristigen Schäden an Ihrem System und an Ihrem Unternehmen kommen. Beispielhafte Konsequenzen der Nichtverfügbarkeit einer Steuerungsebene finden Sie unter Zuverlässigkeit.

Wenn Sie eine Steuerungsebene entwerfen und implementieren, ist es wichtig, dass Sie bewährte Sicherheitsmethoden einhalten und ein umfassendes Bedrohungsmodell erstellen, um potenzielle Bedrohungen und Sicherheitsprobleme in Ihrer Lösung zu dokumentieren und abzumildern. Weitere Informationen finden Sie im Azure Well-Architected Framework-Leitfaden zum Erstellen sicherer Lösungen.

Optimaler Betrieb

Da eine Steuerungsebene eine kritische Komponente ist, sollten Sie sorgfältig überlegen, wie Sie sie in der Produktion bereitstellen und betreiben.

Wie bei anderen Teilen Ihrer Lösung sollten Sie Nicht-Produktionsinstanzen Ihrer Steuerungsebene so bereitstellen, dass Sie deren Funktionalität gründlich testen können. Wenn Ihre Steuerungsebene Bereitstellungsvorgänge ausführt, sollten Sie überlegen, wie Ihre Nicht-Produktionssteuerungsebenen mit Ihrer Azure-Umgebung interagieren und in welchem Azure-Abonnement Sie Nicht-Produktionsressourcen bereitstellen werden. Erstellen Sie auch einen Plan für die rasche Bereinigung der Testressourcen, damit nicht unbeabsichtigt Gebühren anfallen.

Sie sollten auch planen, wie Sie den Zugriff Ihres Teams auf Ihre Steuerungsebene steuern wollen. Folgen Sie bewährten Methoden, um nur die Berechtigungen zu erteilen, die Teammitglieder benötigen, um ihre Aufgaben auszuführen. Neben der Vermeidung von Sicherheitsvorfällen trägt dieser Ansatz dazu bei, die Auswirkungen versehentlicher Fehlkonfigurationen zu verringern.

Komponenten

Es gibt keine einzelne Vorlage für eine Steuerungsebene, und die Komponenten, die Sie entwerfen und erstellen, hängen von Ihren Anforderungen ab. In der Regel besteht eine Steuerungsebene aus APIs und Hintergrund-Workerkomponenten. Bei manchen Lösungen kann zur Steuerungsebene eine Benutzeroberfläche gehören, die vielleicht von Ihrem Team oder gar Ihren Kunden genutzt wird.

Isolieren Ihrer Steuerungsebene von Mandantenworkloads

Es ist eine bewährte Praxis, die Ressourcen Ihrer Steuerungsebene von den Ressourcen zu trennen, die für die Datenebenen Ihrer Mandanten verwendet werden. Beispielsweise sollten Sie die Verwendung separater Datenbankserver, Anwendungsserver sowie anderer Komponenten in Betracht ziehen. Häufig empfiehlt es sich, die Ressourcen Ihrer Steuerungsebene in einer separaten Azure-Ressourcengruppe zu sammeln, die von denen getrennt ist, die mandantenspezifische Ressourcen enthalten.

Wenn Sie Ihre Steuerungsebene von den Workloads der Mandanten isolieren, erhalten Sie mehrere Vorteile:

• Sie können die Skalierung gesondert konfigurieren. Beispielsweise kann Ihre Steuerungsebene konsistente Ressourcenanforderungen aufweisen, und die Ressourcen Ihrer Mandanten werden vielleicht je nach ihren Anforderungen elastisch skaliert.
• Es gibt einen Bulkhead zwischen Ihren Steuerungs- und Datenebenen, wodurch verhindert wird, dass sich Noisy Neighbor-Probleme zwischen den Ebenen Ihrer Lösung ausbreiten.
• Steuerungsebenen sind in der Regel Systeme mit hohen Berechtigungen, die über umfangreiche Zugriffsmöglichkeiten verfügen. Durch die Trennung der Steuerungsebene von den Datenebenen verringern Sie die Wahrscheinlichkeit, dass ein Sicherheitsrisiko es Angreifern ermöglicht, ihre Berechtigungen auf Ihr gesamtes System zu erhöhen.
• Sie können separate Netzwerk- und Firewallkonfigurationen bereitstellen. Datenebenen und Steuerungsebenen erfordern in der Regel unterschiedliche Arten von Netzwerkzugriff.

Orchestrieren von Sequenzen von zeitintensiven Vorgängen

Die Vorgänge, die eine Steuerungsebene ausführt, sind häufig zeitintensiv und umfassen die Koordination mehrerer Systeme. Die Vorgänge können auch komplexe Fehlermodi aufweisen. Wenn Sie Ihre Steuerungsebene entwerfen, ist es wichtig, eine geeignete Technologie für das Koordinieren zeitintensiver Vorgänge oder Workflows zu verwenden.

Angenommen, beim Onboarding eines neuen Mandanten führt Ihre Steuerungsebene beispielsweise die folgenden Aktionen nacheinander aus:

1. Bereitstellen einer neuen Datenbank. Diese Aktion ist ein Azure-Bereitstellungsvorgang. Dieser kann einige Minuten dauern.
2. Aktualisieren des Metadatenkatalogs Ihres Mandanten. Diese Aktion kann die Ausführung eines Befehls für eine Azure SQL-Datenbank umfassen.
3. Senden einer Begrüßungs-E-Mail an den neuen Mandanten. Diese Aktion ruft eine Drittanbieter-API auf, um die E-Mail zu senden.
4. Aktualisieren Ihres Abrechnungssystems, um die Rechnungstellung für den neuen Mandanten vorzubereiten. Diese Aktion ruft eine Drittanbieter-API auf. Sie haben bemerkt, dass sie zeitweilig fehlschlägt.
5. Aktualisieren Ihres CRM-Systems (Customer Relationship Management), sodass es den neuen Mandanten nachverfolgt. Diese Aktion ruft eine Drittanbieter-API auf.

Wenn ein Schritt in der Sequenz fehlschlägt, müssen Sie überlegen, was zu tun ist, z. B.:

• Wiederholen des fehlgeschlagenen Vorgangs. Wenn Ihr Azure SQL-Befehl in Schritt 2 beispielsweise mit einem vorübergehenden Fehler fehlschlägt, könnten Sie den Vorgang wiederholen.
• Fahren Sie mit dem nächsten Schritt fort. Sie könnten z. B. entscheiden, dass es akzeptabel ist, wenn die Aktualisierung Ihres Abrechnungssystems fehlschlägt, da Ihr Vertriebsteam den Kunden möglicherweise später manuell hinzufügt.
• Brechen Sie den Workflow ab, und lösen Sie einen manuellen Wiederherstellungsprozess aus.

Sie müssen auch berücksichtigen, wie die Benutzererfahrung für jedes Fehlerszenario aussieht.

Verwalten freigegebener Komponenten

Eine Steuerungsebene muss alle Komponenten kennen, die nicht bestimmten Mandanten zugeordnet sind, sondern gemeinsam genutzt werden. Einige Komponenten können von allen Mandanten innerhalb eines Stempels gemeinsam genutzt werden. Andere Komponenten können für alle Stempel in einer Region oder sogar global für alle Regionen und Stempel freigegeben werden. Immer wenn für einen Mandant ein Onboarding, eine Neukonfiguration oder ein Offboarding durchgeführt wird, muss Ihre Steuerungsebene wissen, was mit diesen freigegebenen Komponenten zu tun ist.

Einige freigegebene Komponenten müssen möglicherweise neu konfiguriert werden, wenn ein Mandant hinzugefügt oder entfernt wird. Angenommen, Sie verfügen über ein global freigegebenes Azure Front Door-Profil. Wenn Sie einen Mandanten mit einem benutzerdefinierten Domänennamen hinzufügen, muss Ihre Steuerungsebene möglicherweise die Konfiguration des Profils aktualisieren, um Anforderungen für diesen Domänennamen an die richtige Anwendung zu routen. Ebenso muss Ihre Steuerungsebene beim Offboarding eines Mandanten möglicherweise den benutzerdefinierten Domänennamen aus dem Azure Front Door-Profil entfernen, um Übernahmeangriffe auf die Subdomänen zu vermeiden.

Freigegebene Komponenten verfügen möglicherweise über komplexe Skalierungsregeln, die Ihre Steuerungsebene befolgen muss. Angenommen, Sie verwenden einen Ansatz zur Bin-Paketierung, um die Datenbanken Ihrer Mandanten bereitzustellen. Wenn ein neuer Mandant integriert wird, fügen Sie eine neue Azure SQL-Datenbank für diesen Mandanten hinzu und weisen sie dann einem Azure SQL-Pool für elastische Datenbanken zu. Möglicherweise haben Sie festgestellt, dass Sie die Ihrem Pool zugeordneten Ressourcen für jede zehnte Datenbank erhöhen müssen, die Sie hinzufügen. Wenn Sie einen Mandanten hinzufügen oder entfernen, muss Ihre Steuerungsebene die Konfiguration des Pools neu auswerten und entscheiden, ob die Ressourcen des Pools geändert werden sollen. Wenn Sie die maximale Anzahl von Datenbanken erreichen, die Sie einem einzelnen Pool für elastische Datenbanken zuweisen können, müssen Sie einen neuen Pool erstellen und diesen Pool für neue Mandantendatenbanken verwenden. Ihre Steuerungsebene muss die Verantwortung für die Verwaltung jeder dieser freigegebenen Komponenten übernehmen und sie skalieren und neu konfigurieren, sobald sich etwas ändert.

Wenn Ihre Steuerungsebene freigegebene Komponenten verwaltet, ist es wichtig, sich der Wettbewerbsbedingungen (Race Conditions) bewusst zu sein, die auftreten können, wenn mehrere Vorgänge parallel ausgeführt werden. Wenn Sie beispielsweise einen neuen Mandanten gleichzeitig mit einem anderen Mandanten integrieren, müssen Sie sicherstellen, dass Ihr letztendlicher Endzustand konsistent ist und Ihre Skalierungsanforderungen erfüllt.

Verwenden mehrerer Steuerungsebenen

In einer komplexen Umgebung müssen Sie möglicherweise mehrere Steuerungsebenen mit jeweils unterschiedlichen Aufgabenbereichen verwenden. Viele mehrinstanzenfähige Lösungen folgen dem „Bereitstellungsstempel“-Muster und konfigurieren Mandantenshards über mehrere Stempel hinweg. Wenn Sie dieses Muster verwenden, könnten Sie separate Steuerungsebenen für globale und Stempelaufgaben erstellen.

Globale Steuerungsebenen

Eine globale Steuerungsebene ist in der Regel für die allgemeine Verwaltung und Nachverfolgung von Mandanten verantwortlich. Eine globale Steuerungsebene könnte die folgenden Aufgaben haben:

• Mandantenplatzierung. Die globale Steuerungsebene bestimmt, welchen Stempel ein Mandant verwenden soll. Diese Bestimmung kann auf Grundlage von Faktoren wie der Region des Mandanten, der Kapazitätsauslastung der einzelnen Stempel und den Anforderungen des Mandanten an den Servicelevel erfolgen.
• Onboarding von Mandanten und Lebenszyklusverwaltung. Diese Aufgaben umfassen die Nachverfolgung aller Mandanten in allen Bereitstellungen.

Stempelsteuerungsebenen

In jedem Bereitstellungsstempel wird eine Stempelkontrollebene bereitgestellt, die für die dem Stempel zugeordneten Mandanten und Ressourcen verantwortlich ist. Eine Stempelkontrollebene hat möglicherweise folgende Aufgaben:

• Erstellen und Verwalten mandantenspezifischer Ressourcen innerhalb des Stempels, z. B. Datenbanken und Speichercontainer.
• Verwalten freigegebener Ressourcen, einschließlich der Überwachung der Nutzung freigegebener Ressourcen und der Bereitstellung neuer Instanzen, wenn sie sich ihrer maximalen Kapazität nähern.
• Ausführen von Wartungsvorgängen innerhalb des Stempels, z. B. Datenbankindexverwaltungs- und Bereinigungsvorgänge.

Die Steuerungsebene jedes Stempels koordiniert sich mit der globalen Steuerungsebene. Angenommen, ein neuer Mandant registriert sich beispielsweise. Die globale Steuerungsebene ist anfangs für die Auswahl eines Stempels für die Ressourcen des Mandanten zuständig. Anschließend fordert die globale Steuerungsebene die Steuerungsebene des Stempels auf, die erforderlichen Ressourcen für den Mandanten zu erstellen.

Das folgende Diagramm zeigt ein Beispiel, wie die beiden Steuerungsebenen in einem einzelnen System koexistieren könnten:

Mandantensteuerungsebenen

Mandanten könnten eine Steuerungsebene auf Mandantenebene verwenden, um ihre eigenen logischen oder physischen Ressourcen zu verwalten. Eine Mandantensteuerungsebene könnte die folgenden Aufgaben haben:

• Verwaltung mandantenspezifischer Konfigurationen, z. B. Benutzerzugriff.
• Vom Mandanten initiierte Wartungsvorgänge, z. B. Sichern von Daten oder Herunterladen einer vorherigen Sicherung.
• Updateverwaltung, wenn Sie Mandanten erlauben, ihre eigenen Updates für ihre Anwendungen zu steuern.

Das folgende Diagramm zeigt ein komplexes System, das über eine globale Steuerungsebene, Stempelsteuerungsebenen und eine Steuerungsebene für jeden Mandanten verfügt:

Beitragende

Dieser Artikel wird von Microsoft gepflegt. Er wurde ursprünglich von folgenden Mitwirkenden geschrieben:

Hauptautor:

• John Downs | Principal Software Engineer

Andere Mitwirkende:

• Mick Alberts | Technical Writer
• Bohdan Cherchyk | Senior Customer Engineer, FastTrack for Azure
• Landon Pierce | Customer Engineer, FastTrack for Azure
• Daniel Scott-Raynsford | Partner Technology Strategist
• Arsen Vladimirskiy | Principal Customer Engineer, FastTrack for Azure

Melden Sie sich bei LinkedIn an, um nicht öffentliche LinkedIn-Profile anzuzeigen.

Nächste Schritte

• Architekturaspekte: Übersicht
• Azure Well-Architected Framework
• Architekturansätze für Steuerungsebenen in mandantenfähigen Lösungen