Azure-Ressourcenorganisation in mehrinstanzenfähigen Lösungen

Azure bietet viele Optionen zum Organisieren Ihrer Ressourcen. Bei einer mehrinstanzenfähigen Lösung müssen beim Planen der Strategie für die Ressourcenorganisation bestimmte Kompromisse abgewogen werden. In diesem Artikel werden zwei Kernelemente des Organisierens von Azure-Ressourcen beschrieben: Mandantenisolation und horizontale Skalierung über mehrere Ressourcen. Hier werden einige der häufigsten Bereitstellungsansätze beschrieben, die verschiedene Isolationsmodelle für Mandanten unterstützen können. Außerdem wird beschrieben, wie Sie mit den Ressourcengrenzwerten und -kontingenten von Azure arbeiten und wie Sie Ihre Lösung über diese Grenzwerte hinaus skalieren.

Wesentliche Aspekte und Anforderungen

Anforderungen an die Mandantenisolation

Wenn Sie eine mehrinstanzenfähige Lösung in Azure bereitstellen, müssen Sie entscheiden, ob Sie jedem Mandanten Ressourcen zuweisen oder Ressourcen für mehrere Mandanten freigeben. In den Abschnitten über Ansätze mit Mehrinstanzenfähigkeit und dienstspezifische Leitfäden in dieser Reihe werden die Optionen und Kompromisse für viele Ressourcenkategorien beschrieben. Grundsätzlich gibt es verschiedene Optionen für die Mandantenisolation. Lesen Sie Für eine mehrinstanzenfähige Lösung zu berücksichtigende Mandantenmodelle als Leitfaden, sich für ein Isolationsmodell zu entscheiden.

Skalieren

Die meisten Azure-Ressourcen, Ressourcengruppen und Abonnements verfügen über Grenzwerte, die Ihre Skalierungsfähigkeit einschränken kann. Möglicherweise müssen Sie Aufskalieren oder Bin Packing in Betracht ziehen, um die geplante Anzahl von Mandanten oder die geplante Systemlast zu erreichen.

Wenn Sie genau wissen, dass Sie keine große Anzahl an Mandanten oder keine hohe Last erreichen werden, sollten Sie Overengineering bei Ihrem Aufskalierungsplan vermeiden. Wenn Sie jedoch planen, dass Ihre Lösung wächst, sollten Sie Ihren Aufskalierungsplan sorgfältig durchdenken. Folgen Sie dem Leitfaden in diesem Artikel, um sicherzustellen, dass Ihre Architektur für das Skalieren geeignet ist.

Bestimmen Sie, wie Sie Mandanten über mehrere Ressourceninstanzen bereitstellen und zuweisen, wenn Sie über einen automatisierten Bereitstellungsprozess verfügen und ressourcenübergreifend skalieren müssen. Wie erkennen Sie beispielsweise, dass Sie die Anzahl der Mandanten erreichen, die einer bestimmten Ressource zugewiesen werden können? Planen Sie, neue Ressourcen Just-in-Time bereitzustellen, wenn Sie sie benötigen? Oder stellen Sie einen Ressourcenpool Ahead-of-Time bereit, damit sie bei Bedarf verwendet werden können?

Außerdem ist es wichtig, Annahmen im Code und der Konfiguration zu vermeiden, da diese Ihre Skalierungsfähigkeit einschränken können. Vielleicht müssen Sie beispielsweise künftig auf mehrere Speicherkonten aufskalieren. Stellen Sie daher beim Erstellen der Anwendungsebene sicher, dass das Speicherkonto, mit dem sie eine Verbindung herstellt, je nach aktivem Mandanten dynamisch wechseln kann.

Zu berücksichtigende Ansätze und Muster

Mandantenisolation

Azure-Ressourcen werden in einer Hierarchie bereitgestellt und verwaltet. Die meisten Ressourcen werden in Ressourcengruppen bereitgestellt, die sich in Abonnements befinden. Verwaltungsgruppen gruppieren Abonnements logisch. Alle diese hierarchischen Ebenen sind einem Microsoft Entra-Mandanten zugeordnet.

Wenn Sie festlegen, wie Ressourcen für jeden Mandanten bereitgestellt werden, können Sie auf unterschiedlichen Hierarchieebenen isolieren. Jede Option funktioniert für bestimmte Arten von mehrinstanzenfähigen Lösungen und hat Vor- und Nachteile. Es ist auch üblich, Ansätze zu kombinieren, indem verschiedene Isolationsmodelle für unterschiedliche Komponenten einer Lösung verwendet werden.

Isolation innerhalb einer freigegebenen Ressource

Sie können eine Azure-Ressource für mehrere Mandanten freigeben und alle ihre Workloads auf einer einzelnen Instanz ausführen. Lesen Sie den dienstspezifischen Leitfaden für die Azure-Dienste, die Sie verwenden, um alle potenziell wichtigen spezifischen Überlegungen und Optionen zu kennen.

Wenn Sie einzelne Instanzen einer Ressource ausführen, müssen Sie alle Dienstgrenzwerte, Abonnementgrenzwerte oder Kontingente berücksichtigen, die bei der Skalierung erreicht werden können. Beispielsweise gibt es eine maximale Anzahl von Knoten, die von einem Azure Kubernetes Service-Cluster (AKS) unterstützt werden, sowie eine Obergrenze für die Anzahl von Transaktionen pro Sekunde, die von einem Speicherkonto unterstützt werden. Überlegen Sie, wie Sie auf mehrere freigegebene Ressourcen skalieren, wenn Sie sich diesen Grenzwerten nähern.

Außerdem müssen Sie sicherstellen, dass Ihr Anwendungscode vollständig auf Mehrinstanzenfähigkeit ausgelegt ist und den Zugriff auf die Daten für einen bestimmten Mandanten einschränkt.

Zur Veranschaulichung des Ansatzes mit freigegebenen Ressourcen wird angenommen, dass Contoso eine mehrinstanzenfähige SaaS-Anwendung erstellt, die eine Webanwendung, eine Datenbank und ein Speicherkonto enthält. Sie könnten sich entscheiden, gemeinsam genutzte Ressourcen bereitzustellen, um alle ihre Kunden zu bedienen. Im folgenden Diagramm ist eine einzelne Gruppe von Ressourcen für alle Kund*innen freigegeben.

Getrennte Ressourcen in einer Ressourcengruppe

Sie können auch dedizierte Ressourcen für jeden Mandanten bereitstellen. Sie können auch eine vollständige Kopie Ihrer Lösung für einen einzelnen Mandanten bereitstellen. Außerdem können Sie einige Komponenten zwischen Mandanten freigeben, während Sie andere Komponenten für einen bestimmten Mandanten dediziert bereitstellen. Dieser Ansatz wird horizontale Partitionierung genannt.

Es wird empfohlen, Ressourcengruppen zu verwenden, um Ressourcen mit demselben Lebenszyklus zu verwalten. In einigen mehrinstanzenfähigen System ist es sinnvoll, Ressourcen für mehrere Mandaten in einer einzelnen Ressourcengruppe oder einer Reihe von Ressourcengruppen bereitzustellen.

Es ist wichtig, dass Sie darüber nachdenken, wie Sie diese Ressourcen bereitstellen und verwalten. Dazu gehört, ob die Bereitstellung mandantenspezifischer Ressourcen von Ihrer Bereitstellungspipeline oder Ihrer Anwendung initiiert wird. Sie müssen auch festlegen, wie Sie klar identifizieren, dass bestimmte Ressourcen zu bestimmten Mandanten gehören. Erwägen Sie eine eindeutige Namenskonventionsstrategie, Ressourcentags oder eine Mandantenkatalog-Datenbank zu verwenden.

Eine bewährte Methode ist es, getrennte Ressourcengruppen für die Ressourcen zu verwenden, die Sie für mehrere Mandanten freigeben, sowie für die, die Sie für einzelne Mandanten bereitstellen. Jedoch beschränkt Azure die Anzahl von Ressourcen eines einzelnen Typs, die in einer Ressourcengruppe bereitgestellt werden kann, für manche Ressourcen. Diese Beschränkung bedeutet, dass Sie während des Wachstums eventuell über mehrere Ressourcengruppen skalieren müssen.

Angenommen, Contoso hat drei Kunden (Mandanten): Adventure Works, Fabrikam und Tailwind. Es wird entschieden, die Webanwendung und das Speicherkonto für die drei Mandanten freizugeben und dann einzelne Datenbanken für jeden Mandanten bereitzustellen. Das folgende Diagramm zeigt eine Ressourcengruppe, die freigegebene Ressourcen enthält, und eine Ressourcengruppe, die die Datenbank jedes Mandanten enthält.

Getrennte Ressourcengruppen in einem Abonnement

Wenn Sie eine Gruppe Ressourcen für jeden Mandanten bereitstellen, erwägen Sie, dedizierte, mandantenspezifische Ressourcengruppen zu verwenden. Wenn Sie beispielsweise dem Muster der Bereitstellungsstempel folgen, sollte jeder Stempel in einer eigenen Ressourcengruppe bereitgestellt werden. Sie können erwägen, mehrere mandantenspezifische Ressourcengruppen in einem freigegebenen Azure-Abonnement bereitzustellen, wodurch Sie Richtlinien und Zugriffssteuerungsregeln leicht konfigurieren können.

Sie können eine Reihe von Ressourcengruppen für jeden Mandanten und auch freigegebene Ressourcengruppen für alle freigegebenen Ressourcen erstellen.

Beachten Sie die maximale Anzahl von Ressourcengruppen in jedem Abonnement und andere Grenzwerte auf Abonnementebene, die für die von Ihnen bereitgestellten Ressourcen gelten, wenn Sie mandantenspezifische Ressourcengruppen in freigegebenen Abonnements bereitstellen. Wenn Sie sich diesen Grenzwerten nähern, müssen Sie eventuell abonnementübergreifend skalieren.

Im Beispiel könnte Contoso einen Stempel für jeden seiner Kunden bereitstellen und die Stempel in dedizierten Ressourcengruppen innerhalb eines einzelnen Abonnements platzieren. Im folgenden Diagramm wird für jeden Kunden ein Abonnement erstellt, das drei Ressourcengruppen enthält.

Getrennte Abonnements

Sie können mandantenspezifische Ressourcen vollständig isolieren, indem Sie mandantenspezifische Abonnements bereitstellen. Außerdem stellt das Verwenden von getrennten Abonnements für Mandanten sicher, dass jeder Mandant alle zutreffenden Kontingente vollständig nutzen kann, da die meisten Kontingente und Grenzwerte innerhalb eines Abonnements gelten. Für einige Azure-Abrechnungskontotypen können Sie Abonnements programmgesteuert erstellen. Sie können Azure-Reservierungen und den Azure-Sparplan für Compute auch abonnementübergreifend verwenden.

Beachten Sie die maximale Anzahl der Abonnements, die Sie erstellen können. Die maximale Anzahl der Abonnements kann sich je nach Ihrer geschäftlichen Beziehung mit Microsoft oder einem Microsoft Partner unterscheiden, z. B. wenn Sie über ein Enterprise Agreement verfügen.

Es kann jedoch schwieriger sein, Kontingenterhöhungen anzufordern, wenn Sie mit einer großen Anzahl von Abonnements arbeiten. Die Kontingent-API bietet für einige Ressourcentypen eine befehlsorientierte Benutzerschnittstelle. Für viele Ressourcentypen müssen Kontingenterhöhungen jedoch angefordert werden, indem ein Supportfall initiiert wird. Wenn Sie mit vielen Abonnements arbeiten, kann es auch schwierig sein, mit Azure-Supportvereinbarungen und -Supportfällen zu arbeiten.

Erwägen Sie, Ihre mandantenspezifischen Abonnements in eine Verwaltungsgruppenhierarchie einzuordnen, um eine einfache Verwaltung von Zugriffssteuerungsregeln und -richtlinien zu ermöglichen.

Angenommen, Contoso hat sich entschieden, getrennte Azure-Abonnements für jeden seiner drei Kunden zu erstellen, wie im folgenden Diagramm dargestellt. Jedes Abonnement enthält eine Ressourcengruppe mit den vollständigen Ressourcen für diesen Kunden.

Jedes Abonnement enthält eine Ressourcengruppe mit den vollständigen Ressourcen für diesen Kunden.

Für das Vereinfachen der Verwaltung Ihrer Abonnements wird eine Verwaltungsgruppe verwendet. Indem Production als Teil des Namens der Verwaltungsgruppe verwendet wird, können produktionsspezifische Mandanten eindeutig von Nichtproduktions- oder Testmandanten unterschieden werden. Für Nichtproduktionsmandanten gelten andere Azure-Zugriffssteuerungsregeln und -richtlinien.

Alle ihre Abonnements sind einem einzelnen Microsoft Entra-Mandanten zugeordnet. Das Verwenden eines einzelnen Microsoft Entra-Mandanten bedeutet, dass die Identitäten des Contoso-Teams, einschließlich Benutzer*innen und Dienstprinzipale, in der gesamten Azure-Umgebung genutzt werden können.

Getrennte Abonnements in getrennten Microsoft Entra-Mandanten

Es ist auch möglich, manuell einzelne Microsoft Entra-Mandanten für jeden Ihrer Mandanten zu erstellen oder Ihre Ressourcen in Abonnements innerhalb der Microsoft Entra-Mandanten Ihrer Kunden bereitzustellen. Das Arbeiten mit mehreren Microsoft Entra-Mandanten macht es jedoch schwieriger, Authentifizierungen durchzuführen, Rollenzuweisungen zu verwalten, globale Richtlinien anzuwenden und viele andere Verwaltungsvorgänge auszuführen.

In Situationen, in denen Sie Azure-Ressourcen in Abonnements verwalten müssen, die an mehrere Microsoft Entra-Mandanten gebunden sind, sollten Sie erwägen, Azure Lighthouse zu verwenden, um Ihre Ressourcen über mehrere Microsoft Entra-Mandanten zu verwalten.

Contoso könnte z. B. getrennte Microsoft Entra-Mandanten und getrennte Azure-Abonnements für jeden seiner Kunden erstellen, wie im folgenden Diagramm dargestellt.

Für jeden Mandanten von Contoso wird ein Microsoft Entra-Mandant konfiguriert, der ein Abonnement und die erforderlichen Ressourcen enthält. Azure Lighthouse ist mit jedem Microsoft Entra-Mandanten verbunden.

Bin Packing

Unabhängig von Ihrem Ressourcenisolationsmodell ist es wichtig zu beachten, wann und wie Ihre Lösung auf mehrere Ressourcen hochskaliert werden soll. Eventuell müssen Sie Ihre Ressourcen skalieren, wenn die Last in Ihrem System oder die Anzahl der Mandanten zunimmt. Erwägen Sie Bin Packing, um eine optimale Anzahl von Ressourcen für Ihre Anforderungen bereitzustellen.

Ressourceneinschränkungen

Azure-Ressourcen verfügen über Grenzwerte und Kontingente, die bei Ihrer Lösungsplanung berücksichtigt werden müssen. Ressourcen unterstützen beispielsweise eine maximale Anzahl gleichzeitiger Anforderungen oder mandantenspezifische Konfigurationseinstellungen.

Die Art, wie Sie jede Ressource konfigurieren und verwenden, wirkt sich auch auf die Skalierbarkeit dieser Ressource aus. Bei einer bestimmten Menge von Computeressourcen kann Ihre Anwendung beispielsweise erfolgreich auf eine definierte Anzahl von Transaktionen pro Sekunde reagieren. Über diesen Punkt hinaus müssen Sie eventuell hochskalieren. Leistungstests helfen Ihnen dabei, den Punkt zu bestimmen, an dem Ihre Ressourcen Ihre Anforderungen nicht mehr erfüllen.

Wenn Sie einige Ihrer Ressourcen zwischen Mandanten freigeben, sollten Sie zunächst die Anzahl der Mandanten bestimmen, die die Ressource unterstützt, wenn sie gemäß Ihren Anforderungen konfiguriert ist. Stellen Sie dann so viele Ressourcen bereit, wie Sie zum Bedienen der Gesamtzahl von Mandanten benötigen.

Angenommen, Sie stellen Azure Application Gateway als Teil einer mehrinstanzenfähigen SaaS-Lösung bereit. Sie überprüfen den Anwendungsentwurf, testen die Leistung des Anwendungsgateways unter Last und überprüfen dessen Konfiguration. Anschließend stellen Sie fest, dass eine einzelne Anwendungsgateway-Ressource für 100 Kunden freigegeben werden kann. Gemäß dem Wachstumsplan Ihrer Organisation erwarten Sie, dass Sie im ersten Jahr ein Onboarding für 150 Kunden durchführen. Daher müssen Sie planen, mehrere Anwendungsgateways bereitzustellen, um Ihre erwartete Last zu bedienen.

Im vorherigen Diagramm sind zwei Anwendungsgateways dargestellt. Das erste Gateway ist für die Kunden von 1 bis 100 bestimmt und das zweite für die Kunden von 101 bis 200.

Grenzwerte für Ressourcengruppen und Abonnements

Unabhängig davon, ob Sie mit freigegebenen oder dedizierten Ressourcen arbeiten, ist es wichtig, die Grenzwerte zu berücksichtigen. Azure begrenzt die Anzahl der Ressourcen, die in einer Ressourcengruppe und in einem Azure-Abonnement bereitgestellt werden können. Wenn Sie sich diesen Grenzwerten nähern, müssen Sie planen, über mehrere Ressourcengruppen oder Abonnements zu skalieren.

Angenommen, Sie stellen ein dediziertes Anwendungsgateway für jeden Ihrer Kunden in einer freigegebenen Ressourcengruppe bereit. Für einige Ressourcen unterstützt Azure das Bereitstellen von bis zu 800 Ressourcen desselben Typs in einer einzelnen Ressourcengruppe. Wenn Sie also diesen Grenzwert erreichen, müssen Sie alle neuen Anwendungsgateways in einer anderen Ressourcengruppe bereitstellen. Im folgenden Diagramm sind zwei Ressourcengruppen dargestellt. Jede Ressourcengruppe enthält 800 Anwendungsgateways.

Ressourcengruppen- und abonnementübergreifendes Bin Packing von Mandanten

Sie können das Konzept des Bin Packing auch ressourcen-, ressourcengruppen- und abonnementübergreifend anwenden. Wenn Sie beispielsweise über eine kleine Anzahl von Mandanten verfügen, können Sie eventuell eine einzelne Ressource bereitstellen und diese für alle Ihre Mandanten freigeben. Das folgende Diagramm zeigt Bin Packing in einer einzelnen Ressource.

Während des Wachstums nähern Sie sich eventuell dem Kapazitätslimit für eine einzelne Ressource und skalieren auf mehrere (R)-Ressourcen auf. Das folgende Diagramm zeigt mehrere Ressourcen übergreifendes Bin Packing.

Im Laufe der Zeit erreichen Sie eventuell den Grenzwert der Anzahl von Ressourcen in einer einzelnen Ressourcengruppe, und Sie stellen dann mehrere (R)-Ressourcen in mehreren (G)-Ressourcengruppen bereit. Das folgende Diagramm zeigt mehrere Ressourcen übergreifendes Bin Packing in mehreren Ressourcengruppen.

Und wenn das Wachstum noch weiter fortgesetzt wird, können Sie die Bereitstellung mehrere (S)-Abonnements übergreifend durchführen, die jeweils mehrere (G) Ressourcengruppen mit mehreren (R)-Ressourcen enthalten. Das folgende Diagramm zeigt ressourcenübergreifendes Bin Packing in mehreren Ressourcengruppen und Abonnements.

Durch das Planen Ihrer Aufskalierungsstrategie können Sie auf eine sehr große Anzahl von Mandanten skalieren und eine hohe Last aufrechterhalten.

Tags

Mit Ressourcentags können Sie Ihren Azure-Ressourcen benutzerdefinierte Metadaten hinzufügen, die für das Verwalten und Nachverfolgen von Kosten nützlich sein können. Weitere Informationen finden Sie unter Zuordnen von Kosten mithilfe von Ressourcentags.

Bereitstellungsstapel

Mit Bereitstellungsstapeln können Sie Ressourcen nach einer allgemeinen Lebensdauer gruppieren, auch wenn sie mehrere Ressourcengruppen oder Abonnements umfassen. Bereitstellungsstapel sind nützlich, wenn Sie mandantenspezifische Ressourcen bereitstellen, insbesondere wenn Ihr Bereitstellungsansatz aufgrund von Skalierungs- oder Compliancebedenken unterschiedliche Arten von Ressourcen an verschiedenen Stellen verlangt. Bereitstellungsstapel ermöglichen es Ihnen auch, alle Ressourcen im Zusammenhang mit einem einzelnen Mandanten bei einem Offboarding dieses Mandaten mit einem Vorgang zu entfernen. Weitere Informationen finden Sie unter Bereitstellungsstapel.

Zu vermeide Antimuster

• Kein Planen für Skalierungen. Stellen Sie sicher, dass Sie die Grenzwerte der von Ihnen bereitgestellten Ressourcen gut verstehen, und außerdem, welche Grenzwerte bei steigender Last oder Anzahl von Mandanten wichtig werden können. Planen Sie, wie Sie zusätzliche Ressourcen bereitstellen, während Sie skalieren, und testen Sie den Plan.
• Kein Planen für Bin Packing. Planen Sie, Ihre Azure-Ressourcen im Laufe der Zeit über mehrere Ressourcen, Ressourcengruppen und Abonnements zu skalieren, auch wenn Wachstum nicht sofort bevorsteht. Vermeiden Sie Voraussetzungen in Ihrem Anwendungscode, z. B. eine einzelne Ressource zur Verfügung zu haben, wenn Sie in Zukunft eventuell auf mehrere Ressourcen skalieren müssen.
• Skalieren vieler einzelner Ressourcen. Wenn Sie über eine komplexe Ressourcentopologie verfügen, kann es schwierig werden, jede Komponente einzeln zu skalieren. Es ist häufig einfacher, Ihre Lösung als Einheit zu skalieren, indem Sie dem Muster der Bereitstellungsstempel folgen.
• Bereitstellen isolierter Ressourcen für jeden Mandanten, wenn dies nicht erforderlich ist. Bei vielen Lösungen ist es kostengünstiger und effizienter, freigegebene Ressourcen für mehrere Mandanten bereitzustellen.
• Fehler beim Nachverfolgen mandantenspezifischer Ressourcen. Wenn Sie mandantenspezifische Ressourcen bereitstellen, stellen Sie sicher, dass Sie wissen, welche Ressourcen den Mandanten zugeordnet sind. Diese Informationen sind für Compliancezwecke wichtig, zum Nachverfolgen von Kosten und zum Aufheben der Bereitstellung von Ressourcen beim Offboarding eines Mandanten. Erwägen Sie die Verwendung von Ressourcentags, um Mandanteninformationen von Ressourcen nachzuverfolgen. Verwenden Sie außerdem gegebenenfalls Bereitstellungsstapel, um mandantenspezifische Ressourcen unabhängig von ihrer Ressourcengruppe oder ihrem Abonnement in einer logischen Einheit zu gruppieren.
• Verwenden separater Microsoft Entra-Mandanten: Im Allgemeinen ist es nicht ratsam, mehrere Microsoft Entra-Mandanten bereitstellen. Verwalten von Ressourcen über Microsoft Entra-Mandaten ist komplex. Es ist einfacher, abonnementübergreifend zu skalieren, wenn die Abonnements mit einem einzelnen Microsoft Entra-Mandanten verknüpft sind.
• Zu komplexe Entwürfe, wenn Sie nicht skalieren müssen. Bei einigen Lösungen wissen Sie mit Sicherheit, dass Sie nie über eine bestimmte Skalierung hinaus wachsen werden. In diesen Szenarios ist es nicht erforderlich, eine komplexe Skalierungslogik zu erstellen. Wenn Ihre Organisation jedoch ein Wachstum plant, müssen Sie darauf vorbereitet sein, möglicherweise sogar kurzfristig zu skalieren.

Beitragende

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

Hauptautor:

• John Downs | Principal Software Engineer

Andere Mitwirkende:

• Jason Beck | Senior Customer Engineer, FastTrack for Azure
• Bohdan Cherchyk | Senior Customer Engineer, FastTrack for Azure
• Laura Nicolas | Senior Customer Engineer, FastTrack for Azure
• Arsen Vladimirskiy | Principal Customer Engineer, FastTrack for Azure
• Joshua Waddell | Senior Customer Engineer, FastTrack für Azure

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

Nächste Schritte

Hier erfahren Sie mehr über Ansätze zu Kostenverwaltung und Zuordnung.