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. 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 oderBin 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?
Tipp
In den frühen Phasen von Entwurf und Entwicklung entscheiden Sie sich eventuell nicht dafür, einen automatisierten Aufskalierungsprozess zu implementieren. Dennoch sollten Sie die nötigen Prozesse für das Skalieren während des Wachstums bedenken und klar dokumentieren.
Außerdem ist es wichtig, Voraussetzungen in Ihrem Code und Ihrer Konfiguration zu vermeiden, da diese Ihre Skalierungsfähigkeit einschränken können. Beispielsweise müssen Sie eventuell auf mehrere Speicherkonten aufskalieren. Stellen Sie sicher, dass in Ihrer Logikschicht nicht davon ausgegangen wird, dass nur eine Verbindung zu einem einzelnen Speicherkonto für alle Mandanten hergestellt wird.
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. Eventuell wird entschieden, freigegebene Ressourcen bereitzustellen und diese Ressourcen zum Bedienen aller Kund*innen zu verwenden. 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 und andere, für einen bestimmten Mandanten dedizierte Komponenten bereitstellen.
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: Adventure Works, Fabrikam und Tailwind. Es wird entschieden, die Webanwendung und das Speicherkonto für die drei Kunden freizugeben und dann einzelne Datenbanken für jeden Mandanten bereitzustellen. Im folgenden Diagramm wird jedem Kunden jeweils eine Ressourcengruppe zugewiesen, die freigegebene Ressourcen enthält, sowie eine, die eine Datenbank 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.
Warnung
Für die meisten mehrinstanzenfähigen Lösungen wird davon abgeraten, mehrere Microsoft Entra-Mandanten zu erstellen. Das Arbeiten mit mehreren Microsoft Entra-Mandanten führt zu zusätzlicher Komplexität und verringert Ihre Fähigkeit, Ihre Ressourcen zu skalieren und zu verwalten. In der Regel wird dieser Ansatz nur von Anbietern verwalteter Dienste (Managed Service Providers, MSPs) verwendet, die Azure-Umgebungen im Auftrag ihrer Kunden betreiben.
Ein einzelner Microsoft Entra-Mandant kann von mehreren separaten Abonnements und Azure-Ressourcen verwendet werden. Bevor Sie mehrere Microsoft Entra-Mandanten bereitstellen, überlegen Sie, ob es andere Ansätze gibt, mit denen Sie Ihre Ziele erreichen können.
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.
Tipp
Für viele Lösungen ist es einfacher, den alle Ressourcen zusammen zu skalieren, anstatt sie einzeln zu skalieren. Erwägen Sie, dem Muster der Bereitstellungsstempel zu folgen.
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.
Hinweis
Das Prinzip der Skalierung auf mehrere Ressourcen gilt auch dann, wenn Sie mit Diensten arbeiten, die mehrere Instanzen unterstützen.
Beispielsweise unterstützt Azure App Service das Hochskalieren der Anzahl von Instanzen Ihres Plans, doch es gibt Grenzwerte dafür, wie weit Sie einen einzelnen Plan skalieren können. In einer mehrinstanzenfähigen App mit umfangreicher Skalierung können Sie diese Grenzwerte überschreiten und müssen zusätzliche App Service-Ressourcen bereitstellen, um mit Ihrem Wachstum Schritt zu halten.
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 eine Azure Application Gateway-Instanz 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.
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, einzelne Komponenten eine nach der anderen 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.
- 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 Customer Engineer, FastTrack for Azure
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.