Daten gelten oft als der wertvollste Teil einer Lösung, da sie Ihre und die wertvollen Geschäftsinformationen Ihrer Kunden darstellen. Daher ist es wichtig, Ihre Daten sorgfältig zu verwalten. Bei der Planung mehrinstanzenfähiger Speicher- oder Datenkomponenten müssen Sie sich für einen Ansatz zur gemeinsamen Nutzung oder Isolierung der Daten Ihrer Mandanten entscheiden.
Dieser Artikel beschreibt die wichtigsten Aspekte und Anforderungen, die für Lösungsarchitekten bei der Entscheidung für einen Ansatz zur Speicherung von Daten in einem mehrinstanzenfähigen System wichtig sind. Anschließend stellen wir allgemeine Muster für den Einsatz mehrinstanzenfähiger Speicher- und Datendienste sowie zu vermeidende Antimuster vor. Schließlich bieten wir für spezifische Situationen gezielte Orientierungshilfe.
Wesentliche Aspekte und Anforderungen
Es ist wichtig, die Ansätze für Speicher- und Datendienste aus verschiedenen Blickwinkeln zu betrachten, die sich ungefähr an den Grundpfeilern des Azure Well-Architected Framework orientieren.
Skalieren
Wenn Sie mit Diensten zur Speicherung Ihrer Daten arbeiten, müssen Sie die Anzahl Ihrer Mandanten und das Volumen der von Ihnen gespeicherten Daten berücksichtigen. Wenn Sie nur eine kleine Anzahl von Mandanten (max. fünf) haben und für jeden Mandanten nur geringe Datenmengen speichern, ist es wahrscheinlich vergebliche Mühe, einen hoch skalierbaren Datenspeicheransatz zu planen oder einen vollständig automatisierten Ansatz zur Verwaltung Ihrer Datenressourcen zu entwickeln. Sobald Ihr Unternehmen wächst, werden Sie zunehmend von einer klaren Strategie zur Skalierung Ihrer Daten- und Speicherressourcen und zur Automatisierung der Verwaltung dieser Ressourcen profitieren. Wenn Sie mindestens 50 Mandanten haben oder planen, diese Größenordnung zu erreichen, ist es besonders wichtig, dass Sie bei der Konzeption Ihres Daten- und Speicheransatzes Skalierbarkeit in den Mittelpunkt stellen.
Überlegen Sie, in welchem Umfang Sie die Skalierung planen, und planen Sie Ihren Architekturansatz für die Datenspeicherung so, dass er dieser Größenordnung gerecht wird.
Vorhersagbarkeit der Leistung
Mehrinstanzenfähige Daten- und Speicherdienste sind besonders anfällig für das Noisy Neighbor-Problem. Es ist wichtig zu prüfen, ob Mandanten die Leistung anderer Mandanten beeinträchtigen könnten. Haben Ihre Mandanten beispielsweise im Laufe der Zeit sich überschneidende Spitzen in ihrem Nutzungsverhalten erkennen lassen? Nutzen alle Ihre Kunden Ihre Lösung täglich zur gleichen Zeit, oder sind Anforderungen gleichmäßig verteilt? Diese Faktoren wirken sich auf den Grad der Isolierung aus, für den Sie planen müssen, auf die Menge der bereitzustellenden Ressourcen und auf das Ausmaß, in dem die Ressourcen von den Mandanten gemeinsam genutzt werden können.
Es ist wichtig, die Ressourcen- und Anforderungskontingente von Azure im Rahmen dieser Entscheidung zu berücksichtigen. Angenommen, Sie stellen ein einzelnes Speicherkonto bereit, das alle Daten Ihrer Mandanten enthält. Wenn Sie eine bestimmte Anzahl von Speichervorgängen pro Sekunde überschreiten, lehnt Azure Storage die Anforderungen Ihrer Anwendung ab, wovon alle Ihre Mandanten betroffen sind. Dieses Verhalten wird als Drosselung bezeichnet. Eine Überwachung auf gedrosselte Anforderungen ist daher wichtig. Weitere Informationen finden Sie unter Wiederholungsanleitung für Azure-Dienste.
Datenisolation
Beim Entwerfen einer Lösung mit mehrinstanzenfähigen Diensten gibt es in der Regel verschiedene Optionen und Grade der Datenisolierung, die jeweils eigene Vor- und Nachteile haben. Beispiel:
- Bei Verwendung von Azure Cosmos DB können Sie separate Container für jeden Mandanten bereitstellen und Datenbanken und Konten für mehrere Mandanten freigeben. Alternativ können Sie für jeden Mandanten unterschiedliche Datenbanken oder sogar Konten bereitstellen, je nachdem, welcher Isolierungsgrad erforderlich ist.
- Wenn Sie Azure Storage für Blobdaten verwenden, können Sie separate Blobcontainer für jeden Mandanten oder separate Speicherkonten bereitstellen.
- Bei Verwenden von Azure SQL können Sie mit separaten Tabellen in gemeinsam genutzten Datenbanken arbeiten. Oder Sie können für jeden Mandanten separate Datenbanken oder Server bereitstellen.
- Bei allen Azure-Diensten können Sie die Bereitstellung von Ressourcen innerhalb eines einzigen gemeinsamen Azure-Abonnements in Erwägung ziehen, oder Sie können mit mehreren Azure-Abonnements arbeiten, ggf. sogar mit einem pro Mandanten.
Es gibt nicht die eine Lösung, die sich für jede Situation eignet. Die von Ihnen gewählte Option hängt von einer Reihe von Faktoren und den Anforderungen Ihrer Mandanten ab. Wenn Ihre Mandanten beispielsweise bestimmte Compliance- oder gesetzliche Standards erfüllen müssen, ist möglicherweise ein höherer Grad an Isolierung erforderlich. Ebenso können kommerzielle Anforderungen bestehen, die Daten Ihrer Kunden physisch zu isolieren. Oder Sie müssen Isolierung erzwingen, um das Noisy Neighbor-Problem zu vermeiden. Wenn Mandanten ihre eigenen Verschlüsselungsschlüssel verwenden müssen, individuelle Sicherungs- und Wiederherstellungsrichtlinien haben oder ihre Daten an unterschiedlichen geografischen Standorten speichern müssen, kann es außerdem erforderlich sein, sie von anderen Mandanten zu isolieren oder sie mit Mandanten mit ähnlichen Richtlinien in Gruppen zusammenzufassen.
Komplexität der Implementierung
Es ist wichtig, die Komplexität Ihrer Implementierung zu berücksichtigen. Es hat sich bewährt, die Architektur so einfach wie möglich zu halten und dennoch Ihre Anforderungen zu erfüllen. Vermeiden Sie es, sich auf eine Architektur festzulegen, die mit zunehmender Skalierung immer komplexer wird, oder auf eine, für deren Entwicklung und Wartung Sie nicht über die nötigen Ressourcen oder Fachkenntnisse verfügen.
Wenn Ihre Lösung nicht für eine große Anzahl von Mandanten skaliert werden muss oder Sie keine Bedenken hinsichtlich Leistung oder Datenisolierung haben, ist es besser, Ihre Lösung einfach zu halten und unnötige Komplexität zu vermeiden.
Ein besonderes Anliegen bei mehrinstanzenfähigen Datenlösungen ist der von Ihnen unterstützte Grad der Anpassung. Kann ein Mandant zum Beispiel Ihr Datenmodell erweitern oder benutzerdefinierte Datenregeln anwenden? Stellen Sie sicher, dass Sie diese Anforderung schon im Voraus mit einplanen. Vermeiden Sie das Forking oder Bereitstellen von benutzerdefinierter Infrastruktur für einzelne Mandanten. Benutzerdefinierte Infrastruktur hemmt die Skalierbarkeit und verhindert das Testen der Lösung und Bereitstellen von Updates. Erwägen Sie stattdessen die Verwendung von Featureflags und anderen Formen der Mandantenkonfiguration.
Komplexität von Verwaltung und Betrieb
Überlegen Sie, wie Sie Ihre Lösung betreiben und wie sich Ihr mehrinstanzenfähiger Ansatz auf Ihre Abläufe und Prozesse auswirkt. Beispiel:
- Verwaltung: Ziehen Sie mandantenübergreifende Verwaltungsvorgänge in Betracht, z. B. regelmäßige Wartungen. Wie starten und überwachen Sie die Vorgänge für jeden Mandanten, wenn Sie mehrere Konten, Server oder Datenbanken einsetzen?
- Überwachung und Messung: Wenn Sie Ihre Mandanten überwachen oder deren Nutzung messen, überlegen Sie, wie Ihre Lösung Metriken meldet und ob diese problemlos mit dem Mandanten verknüpft werden können, der die Anforderung ausgelöst hat.
- Berichterstellung: Das Melden von Daten in verschiedenen isolierten Mandanten kann es erforderlich machen, dass jeder Mandant Daten in einem zentralen Data Warehouse veröffentlicht, anstatt Abfragen in jeder Datenbank einzeln durchzuführen und die Ergebnisse dann zu aggregieren.
- Schema-Updates: Wenn Sie eine Datenbank einsetzen, die ein Schema erzwingt, planen Sie, wie Sie Schema-Updates in Ihrem gesamten Bestand bereitstellen möchten. Überlegen Sie, woher Ihre Anwendung weiß, welche Schemaversion für die Datenbankabfragen eines bestimmten Mandanten zu verwenden ist.
- Anforderungen: Berücksichtigen Sie die Anforderungen Ihrer Mandanten an Hochverfügbarkeit (z. B. SLAs [Vereinbarungen zum Servicelevel] zur Betriebszeit) und Notfallwiederherstellung (z. B.RTOs [Recovery Time Objectives] und RPOs [Recovery Point Objectives]). Wenn Mandanten unterschiedliche Erwartungen haben, können Sie die Anforderungen der einzelnen Mandanten erfüllen?
- Migration: Wie migrieren Sie Mandanten, wenn sie auf einem anderen Diensttyp, eine andere Bereitstellung oder eine andere Region umstellen müssen?
Kosten
Im Allgemeinen gilt: Je höher die Dichte der Mandanten in Ihrer Bereitstellungsinfrastruktur, desto geringer die Kosten für deren Bereitstellung. Die gemeinsam genutzte Infrastruktur erhöht jedoch die Wahrscheinlichkeit von Problemen wie Noisy Neighbor. Berücksichtigen Sie daher die Nachteile sorgfältig.
Zu berücksichtigende Ansätze und Muster
Mehrere Entwurfsmuster im Azure Architecture Center sind für mehrinstanzenfähige Speicher- und Datendienste von Bedeutung. Sie sollten sich für ein Muster entscheiden, dem Sie konsequent folgen. Sie können aber auch verschiedene Muster miteinander kombinieren. So können Sie beispielsweise eine mehrinstanzenfähige Datenbank für die meisten Ihrer Mandanten nutzen, aber für Mandanten, die mehr zahlen oder ungewöhnliche Anforderungen haben, Einzelmandantenstempel bereitstellen. Ebenso ist es oft sinnvoll, die Skalierung mithilfe von Bereitstellungsstempeln vorzunehmen, selbst wenn Sie eine mehrinstanzenfähige Datenbank oder partitionierte Datenbanken innerhalb eines Stempels verwenden.
Muster mit Bereitstellungsstempeln
Weitere Informationen zur Verwendung des Musters mit Bereitstellungsstempeln zur Unterstützung einer mehrinstanzenfähigen Lösung finden Sie unter Übersicht.
Freigegebene mehrinstanzenfähige Datenbanken und Dateispeicher
Sie können erwägen, eine freigegebene mehrinstanzenfähige Datenbank, ein Speicherkonto oder eine Dateifreigabe bereitzustellen und für alle Mandanten freizugeben.
Dieser Ansatz bietet die höchste Dichte von Mandanten für die Infrastruktur, sodass er in der Regel bei allen Ansätzen zu den niedrigsten Kosten führt. Auch der Verwaltungsaufwand ist oft geringer, da nur eine einzige Datenbank bzw. Ressource zu verwalten, zu sichern und zu schützen ist.
Wenn Sie jedoch mit freigegebener Infrastruktur arbeiten, sind mehrere Einschränkungen zu beachten:
- Skalierungsgrenzen: Wenn Sie auf eine einzige Ressource angewiesen sind, berücksichtigen Sie die unterstützten Skalierungs- und Grenzwerte dieser Ressource. So werden beispielsweise die maximale Größe einer Datenbank oder eines Dateispeichers oder die maximalen Durchsatzgrenzwerte zu einem Stolperstein, wenn sich Ihre Architektur auf eine einzige Datenbank stützt. Überlegen Sie sich genau, welche maximale Skalierung Sie erreichen möchten, und vergleichen Sie diese mit Ihren derzeitigen und künftigen Grenzwerten, ehe Sie dieses Muster auswählen.
- Noisy Neighbors: Das Noisy Neighbor-Problem könnte zu einem Faktor werden, insbesondere wenn Sie Mandanten haben, die besonders aktiv sind oder größere Workloads generieren als andere. Erwägen Sie das Befolgen des Musters mit Drosselung oder Musters mit Bandbreiteneinschränkung, um diese Auswirkungen zu minimieren.
- Überwachung einzelner Mandanten: Möglicherweise haben Sie Schwierigkeiten, die Aktivität zu überwachen und den Verbrauch für einen einzelnen Mandanten zu messen. Einige Dienste wie Azure Cosmos DB bieten Berichte zur Ressourcennutzung für jede Anforderung, sodass diese Informationen nachverfolgt werden können, um den Verbrauch für jeden Mandanten zu messen. Andere Dienste bieten nicht den gleichen Detailgrad. Die Metriken für Dateikapazität von Azure Files sind z. B. nur bei Premium-Freigaben pro Dateifreigabedimension verfügbar. Im Standardtarif werden die Metriken jedoch nur auf Speicherkontoebene zur Verfügung gestellt.
- Anforderungen der Mandanten: Mandanten haben möglicherweise unterschiedliche Anforderungen an Sicherheit, Sicherung, Verfügbarkeit oder Speicherort. Wenn diese nicht mit der Konfiguration Ihrer einzelnen Ressource übereinstimmen, können Sie sie möglicherweise nicht aufnehmen.
- Schemaanpassung: Beim Arbeiten mit einer relationalen Datenbank oder in einer anderen Situation, in der das Schema der Daten Bedeutung hat, ist die Anpassung des Schemas auf Mandantenebene schwierig.
Sharding-Muster
Beim Sharding-Muster werden mehrere separate Datenbanken, sog. Shards, bereitgestellt, die die Daten eines oder mehrerer Mandanten enthalten. Im Gegensatz zu Bereitstellungsstempeln implizieren Shards nicht, dass die gesamte Infrastruktur dupliziert wird. Sie können Datenbanken horizontal partitionieren, ohne auch eine andere Infrastruktur in Ihrer Lösung zu duplizieren oder horizontal zu partitionieren.
Das Erstellen von Shards ist eng verwandt mit der Partitionierung, weshalb die Begriffe oft synonym verwendet werden. Weitere Informationen finden Sie in der Anleitung Horizontale, vertikale und funktionale Datenpartitionierung.
Das Muster mit horizontalem Partitionieren kann auf eine sehr große Anzahl von Mandanten skaliert werden. Darüber hinaus können Sie je nach Workload eine hohe Dichte von Mandanten pro Partition erreichen, sodass die Kosten attraktiv sein können. Das Muster mit horizontalem Partitionieren eignet sich auch, um Kontingente, Grenzwerte und Einschränkungen für Azure-Abonnements und -Dienste zu berücksichtigen.
Einige Datenspeicher, z. B. Azure Cosmos DB, unterstützen die Partitionierung nativ. Beim Arbeiten mit anderen Lösungen wie Azure SQL kann es komplexer sein, eine Shardinginfrastruktur zu erstellen und Anforderungen eines bestimmten Mandanten an den richtigen Shard weiterzuleiten.
Sharding erschwert auch die Unterstützung von Konfigurationsunterschieden auf Mandantenebene und die Bereitstellung eigener Verschlüsselungsschlüssel für Kunden.
Mehrinstanzenfähige App mit dedizierten Datenbanken für jeden Mandanten
Ein weiterer gängiger Ansatz ist die Bereitstellung einer einzelnen mehrinstanzenfähigen Anwendung mit dedizierten Datenbanken für jeden Mandanten.
In diesem Modell sind die Daten des jeweiligen Mandanten von den anderen Mandanten isoliert, und Sie können möglicherweise ein gewisses Maß an Anpassung für jeden Mandanten unterstützen.
Da Sie dedizierte Datenressourcen für jeden Mandanten bereitstellen, können die Kosten für diesen Ansatz höher sein als bei Hostingmodellen mit gemeinsamer Nutzung. Azure bietet jedoch mehrere Optionen, die Sie in Betracht ziehen können, um die Kosten für das Hosten einzelner Datenressourcen durch mehrere Mandanten zu teilen. Wenn Sie beispielsweise mit Azure SQL arbeiten, können Sie Pools für elastische Datenbanken in Betracht ziehen. Für Azure Cosmos DB können Sie Durchsatz für eine Datenbank bereitstellen, und der Durchsatz wird von den Containern in dieser Datenbank gemeinsam genutzt, obwohl dieser Ansatz nicht geeignet ist, wenn Sie eine garantierte Leistung für jeden Container benötigen.
Da in diesem Ansatz nur die Datenkomponenten für jeden Mandanten einzeln bereitgestellt werden, können Sie wahrscheinlich eine hohe Dichte für die anderen Komponenten in Ihrer Lösung erreichen und die Kosten für diese Komponenten senken.
Bei Bereitstellung von Datenbanken für die einzelnen Mandanten sind automatisierte Ansätze wichtig.
Muster mit Geoknoten
Das Muster mit Geoknoten ist speziell für geografisch verteilte Lösungen konzipiert, einschließlich mehrinstanzenfähiger Lösungen. Es unterstützt hohe Auslastungen und hohe Grade an Resilienz. Wenn Sie das Geoknoten-Muster implementieren, muss die Datenschicht in der Lage sein, die Daten in verschiedene geografische Regionen zu replizieren und Schreibvorgänge in mehreren geografischen Räumen zu unterstützen.
Azure Cosmos DB bietet zur Unterstützung dieses Musters Multimasterschreibvorgänge. Cassandra unterstützt Cluster in mehreren Regionen. Andere Datendienste können dieses Muster in der Regel nicht ohne erhebliche Anpassung unterstützen.
Zu vermeide Antimuster
Bei der Erstellung mehrinstanzenfähiger Dienste ist die Vermeidung von Situationen wichtig, die Ihre Skalierungsfähigkeit einschränken.
Für relationale Datenbanken umfasst dies Folgendes:
- Tabellenbasierte Isolierung. Wenn Sie in einer Einzeldatenbank arbeiten, vermeiden Sie die Erstellung einzelner Tabellen für jeden Mandanten. Eine Einzeldatenbank kann bei diesem Ansatz keine sehr große Anzahl von Mandanten unterstützen, und es wird zunehmend schwieriger, Daten abzufragen, zu verwalten und zu aktualisieren. Ziehen Sie stattdessen eine einzelne Gruppe mehrinstanzenfähiger Tabellen mit einer Spalte für die Mandanten-ID in Betracht. Alternativ können Sie auch eines der oben beschriebenen Muster wählen, um für jeden Mandanten separate Datenbanken bereitzustellen.
- Mandantenanpassung auf Spaltenebene. Vermeiden Sie das Anwenden von Schemaaktualisierungen, die nur für einen Einzelmandanten gelten. Angenommen, Sie haben eine einzelne mehrinstanzenfähige Datenbank. Vermeiden Sie das Hinzufügen einer neuen Spalte, um die Anforderungen eines bestimmten Mandanten zu erfüllen. Bei einer kleinen Anzahl von Anpassungen mag das noch akzeptabel sein, aber bei einer großen Anzahl wird das Ganze schnell unüberschaubar. Erwägen Sie stattdessen eine Überarbeitung Ihres Datenmodells dahingehend, dass benutzerdefinierte Daten für jeden Mandanten in einer dedizierten Tabelle nachverfolgt werden.
- Manuelle Schemaänderungen. Vermeiden Sie es, Ihr Datenbankschema manuell zu ändern, auch wenn Sie nur eine einzige gemeinsam genutzte Datenbank haben. Sie können leicht den Überblick über die erfolgten Aktualisierungen verlieren. Und wenn Sie auf weitere Datenbanken aufskalieren müssen, ist es schwierig, das anzuwendende Schema zu bestimmen. Erstellen Sie stattdessen zum Bereitstellen Ihrer Schemaänderungen eine automatisierte Pipeline, die Sie konsequent einsetzen. Verfolgen Sie die Schemaversion nach, die für jeden Mandanten in einer dedizierten Datenbank oder Nachschlagetabelle verwendet wird.
- Versionsabhängigkeiten. Vermeiden Sie, dass Ihre Anwendung von einer einzelnen Version Ihres Datenbankschemas abhängig ist. Beim Skalieren müssen Sie möglicherweise Schema-Updates zu unterschiedlichen Zeiten für verschiedene Mandanten anwenden. Stellen Sie stattdessen sicher, dass Ihre Anwendungsversion mit mindestens einer Schemaversion abwärtskompatibel ist, und vermeiden Sie destruktive Schemaaktualisierungen.
Datenbanken
Es gibt einige Features, die bei Mehrinstanzenfähigkeit nützlich sein können. Diese sind jedoch nicht in allen Datenbankdiensten verfügbar. Überlegen Sie, ob Sie diese benötigen, wenn Sie sich für den Dienst entscheiden, den Sie in Ihrem Szenario nutzen möchten:
- Sicherheit auf Zeilenebene kann eine Sicherheitsisolierung für die Daten bestimmter Mandanten in einer gemeinsam genutzten mehrinstanzenfähigen Datenbank ermöglichen. Dieses Feature ist in Azure SQL und Postgres Flex verfügbar, nicht aber in anderen Datenbanken wie MySQL oder Azure Cosmos DB.
- Verschlüsselung auf Mandantenebene ist möglicherweise erforderlich, um Mandanten zu unterstützen, die eigene Verschlüsselungsschlüssel für ihre Daten haben. Dieses Feature ist in Azure SQL als Teil von Always Encrypted verfügbar. Azure Cosmos DB bietet kundenseitig verwaltete Schlüssel auf Kontoebene und unterstützt auch Always Encrypted.
- Ressourcenpools bieten die Möglichkeit, dass mehrere Datenbanken oder Container sich Ressourcen und Kosten teilen. Dieses Feature ist in den Pools für elastische Datenbanken und verwalteten Instanzen von Azure SQL und beim Datenbankdurchsatz von Azure Cosmos DB verfügbar, obgleich jede Option Einschränkungen unterliegt, deren Sie sich bewusst sein sollten.
- Die Partitionierung wird in einigen Diensten stärker nativ unterstützt als in anderen. Dieses Feature ist in Azure Cosmos DB bei Verwendung seiner logischen und physischen Partitionierung und in PostgreSQL Hyperscale verfügbar. Azure SQL unterstützt zwar die Partitionierung nicht nativ, bietet aber Partitionierungstools zur Unterstützung dieser Art von Architektur.
Wenn Sie mit relationalen Datenbanken oder anderen schemabasierten Datenbanken arbeiten, sollten Sie außerdem überlegen, wo der Schema-Update-Prozess ausgelöst werden soll, wenn Sie eine Reihe von Datenbanken verwalten. Bei einem kleinen Bestand an Datenbanken können Sie eine Bereitstellungspipeline zum Bereitstellen von Schemaänderungen in Betracht ziehen. Mit zunehmendem Wachstum kann es für Ihre Logikschicht besser sein, die Schemaversion für eine bestimmte Datenbank zu erkennen und den Aktualisierungsprozess anzustoßen.
Datei- und Blobspeicher
Überlegen Sie, wie Sie Daten innerhalb eines Speicherkontos isolieren möchten. Sie können z. B. für jeden Mandanten ein eigenes Speicherkonto bereitstellen oder Speicherkonten gemeinsam nutzen lassen und einzelne Container bereitstellen. Alternativ können Sie auch gemeinsam genutzte Blobcontainer erstellen und dann die Daten der einzelnen Mandanten anhand des Blobpfads trennen. Berücksichtigen Sie Grenzwerte und Kontingente für Azure-Abonnements, und planen Sie Ihr Wachstum sorgfältig, um sicherzustellen, dass Ihre Azure-Ressourcen Ihren künftigen Anforderungen entsprechen.
Planen Sie bei gemeinsam genutzten Containern Ihre Authentifizierungs- und Autorisierungsstrategie sorgfältig, um sicherzustellen, dass Mandanten nicht auf die Daten anderer Mandanten zugreifen können. Erwägen Sie das Muster mit Valetschlüsseln, wenn Sie Clients Zugriff auf Azure Storage ermöglichen.
Kostenzuteilung
Überlegen Sie, wie Sie den Verbrauch messen und die Kosten für die Nutzung gemeinsam genutzter Datendienste den Mandanten zuteilen möchten. Greifen Sie, wann immer möglich, auf integrierte Metriken zurück, anstatt eigene zu berechnen. Bei gemeinsam genutzter Infrastruktur wird es jedoch schwierig, Telemetriedaten für einzelne Mandanten aufzuteilen, und Sie sollten eine benutzerdefinierte Messung auf Anwendungsebene in Betracht ziehen.
Im Allgemeinen bieten cloudnative Dienste wie Azure Cosmos DB und Azure Blob Storage detailliertere Metriken zur Nachverfolgung und Modellierung der Nutzung für einen bestimmten Mandanten. Azure Cosmos DB liefert zum Beispiel den verbrauchten Durchsatz für jede Anforderung und Antwort.
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:
- Paul Burpo | Principal 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
Weitere Informationen zur Mehrinstanzenfähigkeit und zu bestimmten Azure-Diensten finden Sie unter: