Mehrinstanzenfähigkeit und Azure Storage

Azure Storage ist ein grundlegender Dienst, der in fast jeder Lösung verwendet wird. Lösungen für mehrere Mandanten verwenden oftmals Azure Storage für Blob-, Datei-, Warteschlangen- und Tabellenspeicher. Auf dieser Seite werden einige der Features von Azure Storage beschrieben, die für Lösungen für mehrere Mandanten nützlich sind. Im Anschluss stellen wir Links zu den Anleitungen zur Verfügung, die Sie bei der Planung der Nutzung von Azure Storage unterstützen können.

Features von Azure Storage, die Mehrinstanzenfähigkeit unterstützen

Azure Storage enthält viele Features, die Mehrinstanzenfähigkeit unterstützen.

Shared Access Signatures

Wenn Sie mit Azure Storage von einer Clientanwendung aus arbeiten, müssen Sie unbedingt berücksichtigen, ob Clientanforderungen über eine weitere Komponente gesendet werden sollen, die Ihrer Kontrolle unterliegt – etwa ein Content Delivery Network oder eine API –, oder ob der Client eine direkte Verbindung mit Ihrem Speicherkonto herstellen soll. Es kann gute Gründe geben, Anforderungen über eine weitere Komponente zu senden, beispielsweise das Zwischenspeichern von Daten am Rand Ihres Netzwerks. In machen Situationen ist es jedoch vorteilhaft, wenn Clientendpunkte zum Herunterladen oder Hochladen von Daten eine direkte Verbindung mit Azure Storage herstellen. Diese Verbindung hilft Ihnen, die Leistung Ihrer Lösung zu verbessern, insbesondere bei der Arbeit mit großen Blobs oder einer großen Anzahl von Dateien. Außerdem werden die Last für Ihre Back-End-Anwendungen und -Server sowie die Anzahl der Netzwerkhops reduziert. Mit einer Shared Access Signature (SAS) können Sie Ihren Clientanwendungen den sicheren Zugriff auf Objekte in Azure Storage ermöglichen.

Shared Access Signatures können verwendet werden, um den Bereich der Vorgänge, die ein Client ausführen kann, und die Objekte, für die er Vorgänge ausführen kann, einzuschränken. Wenn Sie beispielsweise über ein freigegebenes Speicherkonto für alle Ihre Mandanten verfügen und Sie alle Daten von Mandant A in einem Blobcontainer namens tenanta speichern, können Sie eine SAS erstellen, die nur den Benutzern von Mandant A den Zugriff auf diesen Container erlaubt. Weitere Informationen finden Sie unter Isolationsmodelle, um die Ansätze zu untersuchen, die Sie verwenden können, um die Daten Ihrer Mandanten in einem Speicherkonto zu isolieren.

Das Valetschlüsselmuster eignet sich als ein Verfahren zur Ausgabe von eingeschränkten Shared Access Signatures für einen beschränkten Bereich von Ihrer Logikschicht aus. Angenommen, Sie verfügen über eine mehrinstanzenfähige Anwendung, mit der Benutzer Videos hochladen können. Ihre API oder Logikschicht kann den Client mit Ihrem eigenen Authentifizierungssystem authentifizieren. Anschließend können Sie für den Client eine SAS bereitstellen, mit dem er eine Videodatei in ein angegebenes Blob in einen Container unter einem Blobpfad hochladen kann, die Sie festlegen. Anschließend lädt der Client die Datei direkt in das Speicherkonto hoch, und zusätzliche Bandbreite und Auslastung Ihrer API werden vermieden. Wenn der Client versucht, Daten aus dem Blobcontainer zu lesen oder Daten in einen anderen Teil des Containers oder in einen anderen Container im Speicherkonto zu schreiben, blockiert Azure Storage die Anforderung. Die Signatur läuft nach einem konfigurierbaren Zeitraum ab.

Gespeicherte Zugriffsrichtlinien erweitern die SAS-Funktionalität, was Ihnen die Möglichkeit gibt, eine einzelne Richtlinie zu definieren, die zur Ausstellung mehrerer Shared Access Signatures verwendet werden kann.

Identitätsbasierte Zugriffssteuerung

Azure Storage bietet ebenfalls eine identitätsbasierte Zugriffssteuerung mithilfe von Microsoft Entra ID. Mit dieser Funktion können Sie auch attributbasierte Zugriffssteuerung verwenden, die Ihnen einen detailliertere Steuerung des Zugriffs auf Blobpfade oder Blobs ermöglicht, die mit einer bestimmten Mandanten-ID gekennzeichnet wurden.

Lebenszyklusverwaltung

Wenn Sie Blobspeicher in einer mehrinstanzenfähigen Lösung verwenden, benötigen Ihre Mandanten möglicherweise unterschiedliche Richtlinien für die Datenaufbewahrung. Beim Speichern großer Datenmengen kann es darüber hinaus sinnvoll sein, aus Gründen der Kostenoptimierung die automatische Auslagerung der Daten eines bestimmten Mandanten in die kalte Speicherebene oder Archivebene zu konfigurieren.

Erwägen Sie die Verwendung von Richtlinien für die Lebenszyklusverwaltung, um den Bloblebenszyklus für alle Mandanten oder für eine Teilmenge von Mandanten festzulegen. Eine Richtlinie zur Lebenszyklusverwaltung kann auf Blobcontainer oder auf eine Teilmenge von Blobs innerhalb eines Containers angewendet werden. Die Anzahl der Regeln, die Sie in einer Richtlinie für die Lebenszyklusverwaltung angeben können, ist jedoch begrenzt. Planen und testen Sie die Verwendung dieses Features in einer mehrinstanzenfähigen Umgebung, und erwägen Sie die Bereitstellung mehrerer Speicherkonten, um die Überschreitung der Grenzwerte zu vermeiden.

Unveränderlicher Speicher

Wenn Sie unveränderlichen Blobspeicher in Speichercontainern mit zeitbasierten Aufbewahrungsrichtlinien konfigurieren, verhindert Azure Storage das Löschen oder Ändern der Daten vor einem angegebenen Zeitpunkt. Diese Unterbindung wird auf Speicherkontoebene durchgesetzt und betrifft alle Benutzer. Nicht einmal die Administratoren Ihrer Organisation können unveränderliche Daten löschen.

Unveränderlicher Speicher kann sinnvoll sein, wenn Sie für Mandanten arbeiten, die rechtliche oder Complianceanforderungen für die Aufbewahrung von Daten oder Datensätzen einzuhalten haben. Sie sollten jedoch berücksichtigen, wie dieses Feature im Kontext Ihres Mandantenlebenszyklus verwendet wird. Wenn beispielsweise für Mandanten ein Offboarding durchgeführt wird und sie die Löschung ihrer Daten anfordern, können Sie ihren Anforderungen möglicherweise nicht nachkommen. Wenn Sie unveränderlichen Speicher für die Daten Ihrer Mandanten verwenden, überlegen Sie, wie Sie diesem Problem in Ihren Nutzungsbedingungen Rechnung tragen.

Serverseitiger Code

In einem System für mehrere Mandanten besteht manchmal die Notwendigkeit, Daten aus einem Speicherkonto in ein anderes zu verschieben. Wenn Sie beispielsweise einen Mandanten zwischen Bereitstellungsstempeln verschieben oder einen Shardingsatz von Speicherkonten ausgleichen, müssen Sie die Daten eines bestimmten Mandanten kopieren oder verschieben. Bei der Arbeit mit großen Datenmengen empfiehlt es sich, serverseitige Kopier-APIs zu verwenden, um die Zeit für die Migration der Daten zu verringern.

Das AzCopy-Tool ist eine Anwendung, die Sie auf Ihrem eigenen Computer oder auf einem virtuellen Computer ausführen können, um den Kopiervorgang zu verwalten. AzCopy ist mit der serverseitigen Kopierfunktion kompatibel und bietet eine skriptfähige Befehlszeilenschnittstelle, die Sie von Ihren eigenen Lösungen aus ausführen können. AzCopy ist außerdem nützlich zum Hochladen und Herunterladen großer Datenmengen.

Wenn Sie die serverseitigen Kopier-APIs direkt aus Ihrem Code verwenden müssen, ziehen Sie für das Arbeiten mit kleineren Blobs die APIs Put Block From URL, Put Page From URL, Append Block From URL und Copy Blob From URL in Betracht.

Objektreplikation

Die Funktion zur Objektreplikation repliziert Daten zwischen einem Quell- und einem Zielspeicherkonto automatisch. Die Objektreplikation erfolgt asynchron. In einer Lösung mit mehreren Mandanten kann dieses Feature nützlich sein, wenn Sie fortlaufend Daten zwischen Bereitstellungsstempeln oder in einer Implementierung des Geode-Musters replizieren müssen.

Verschlüsselung

In Azure Storage können Sie für Ihre Daten Verschlüsselungsschlüssel bereitstellen. Erwägen Sie in einer mehrinstanzenfähigen Lösung, diese Fähigkeit mit Verschlüsselungsbereichen zu kombinieren, mit denen Sie verschiedene Verschlüsselungsschlüssel für verschiedene Mandanten definieren können, auch wenn ihre Daten im gleichen Speicherkonto gespeichert sind. Durch die gemeinsame Verwendung dieser Features können Sie Mandanten außerdem die Kontrolle über ihre eigenen Daten bieten. Wenn sie ihr Konto deaktivieren müssen, wird durch das Löschen des Verschlüsselungsschlüssels sichergestellt, dass ihre Daten nicht mehr zugänglich sind.

Überwachung

Berücksichtigen Sie bei der Arbeit mit einer mehrinstanzenfähigen Lösung, ob Sie den Verbrauch für jeden Mandanten messen müssen, und definieren Sie die spezifischen Metriken, die nachverfolgt werden müssen, etwa die Menge des für jeden Mandanten verwendeten Speichers (die Kapazität) oder die Anzahl der für die Daten jedes Mandanten ausgeführten Operationen. Sie können auch die Kostenzuordnung verwenden, um die Kosten für die Nutzung durch die einzelnen Mandanten zu verfolgen und eine Rückverrechnung über mehrere Abonnements hinweg zu ermöglichen.

Azure Storage bietet integrierte Überwachungsfunktionen. Es ist wichtig, die Dienste zu berücksichtigen, die Sie im Azure Storage-Konto verwenden müssen. Wenn Sie beispielsweise mit Blobs arbeiten, kann die Gesamtkapazität eines Speicherkontos angezeigt werden, nicht aber die eines einzelnen Containers. Wenn Sie mit Dateifreigaben arbeiten, ist es demgegenüber möglich, die Kapazität für jede Freigabe anzuzeigen, nicht aber die jedes Ordners.

Außerdem können Sie alle an Azure Storage gesendeten Anforderungen protokollieren und diese Protokolle anschließend zusammenfassen und analysieren. Dadurch erhalten Sie mehr Flexibilität beim Aggregieren und Gruppieren von Daten für jeden Mandanten. In Lösungen, die große Mengen von Anforderungen an Azure Storage generieren, sollte jedoch außerdem berücksichtigt werden, ob der Vorteil, den Ihnen dieser Ansatz bietet, in einem Verhältnis zu den Kosten steht, die mit der Erfassung und Verarbeitung dieser Protokolle einhergehen.

Azure Storage-Bestand bietet einen weiteren Ansatz zum Messen der Gesamtgröße eines Blobcontainers.

Isolationsmodelle

Bei der Arbeit mit einem mehrinstanzenfähigen System, das Azure Storage verwendet, müssen Sie eine Entscheidung zum Isolationsgrad treffen, den Sie verwenden möchten. Azure Storage unterstützt mehrere Isolationsmodelle.

Speicherkonten pro Mandant

Die höchste Isolationsstufe besteht in der Bereitstellung eines dedizierten Speicherkontos pro Mandant. Dadurch wird sichergestellt, dass alle Speicherschlüssel isoliert sind und unabhängig voneinander rotiert werden können. Bei diesem Ansatz können Sie Ihre Lösung skalieren, um die für jedes Speicherkonto geltenden Grenzwerte und Kontingente zu vermeiden. Sie müssen jedoch auch die maximale Anzahl von Speicherkonten berücksichtigen, die in einem einzelnen Azure-Abonnement bereitgestellt werden können.

Darüber hinaus bietet jede Komponente von Azure Storage weitere Optionen für die Mandantenisolation.

Blobspeicher-Isolationsmodelle

In der folgenden Tabelle werden die Unterschiede der wichtigsten Mandantenisolationsmodelle für Azure Storage Blobs erläutert:

Gemeinsame Blobcontainer

Beim Arbeiten mit Blobspeicher können Sie sich für einen gemeinsamen Blobcontainer entscheiden und dann Blobpfade verwenden, um die Daten der einzelnen Mandanten zu trennen:

Dieser Ansatz ist zwar einfach zu implementieren, in vielen Szenarien bieten Blobpfade aber keine ausreichende Isolation zwischen Mandanten. Dies liegt daran, dass Blob Storage kein Konzept von Verzeichnissen oder Ordnern bietet. Dies bedeutet, dass Sie keinen Zugriff auf alle Blobs innerhalb eines angegebenen Pfads zuweisen können. Allerdings bietet Azure Storage die Möglichkeit, Blobs aufzulisten (zu enumerieren), die mit einem angegebenen Präfix beginnen. Dies kann nützlich sein, wenn Sie mit gemeinsamen Blobcontainern arbeiten und keine Zugriffssteuerung auf Verzeichnisebene erforderlich ist.

Mit dem Feature hierarchischer Namespace von Azure Storage besteht die Möglichkeit, ein stärkeres Verzeichnis- oder Ordnerkonzept zu bieten, einschließlich einer verzeichnisspezifischen Zugriffssteuerung. Dies kann bei einigen mehrinstanzenfähigen Szenarien nützlich sein, in denen Sie gemeinsame Blobcontainer nutzen, aber Zugriff auf die Daten eines einzelnen Mandanten erteilen möchten.

In einigen mehrinstanzenfähigen Lösungen müssen Sie möglicherweise nur ein einzelnes Blob oder eine Gruppe von Blobs für jeden Mandanten speichern, etwa Mandantensymbole zum Anpassen einer Benutzeroberfläche. In diesen Szenarien kann ein einzelner gemeinsamer Blobcontainer ausreichend sein. Sie können den Mandantenbezeichner als Blobnamen verwenden und dann ein bestimmtes Blob lesen, anstatt einen Blobpfad aufzählen zu müssen.

Überlegen Sie beim Arbeiten mit freigegebenen Containern, ob Sie die Daten und die Azure Storage-Dienstnutzung für jeden Mandanten nachverfolgen müssen, und planen Sie eine entsprechende Vorgehensweise. Weitere Informationen finden Sie unter Überwachung.

Blobcontainer pro Mandant

Sie können einzelne Blobcontainer für jeden Mandanten innerhalb eines einzelnen Speicherkontos erstellen. Es gibt keine Beschränkung für die Anzahl von Blobcontainern, die Sie innerhalb eines Speicherkontos erstellen können.

Durch Erstellen von Containern für jeden Mandanten können Sie Azure Storage-Zugriffssteuerung einschließlich SAS verwenden, um den Zugriff auf die Daten jedes Mandanten zu verwalten. Auch können Sie problemlos die Kapazität überwachen, die von den einzelnen Containern verwendet wird.

Dateispeicher-Isolationsmodelle

In der folgenden Tabelle werden die Unterschiede der wichtigsten Mandantenisolationsmodelle für Azure Storage-Dateien erläutert:

Gemeinsame Dateifreigaben

Wenn Sie mit Dateifreigaben arbeiten, können Sie eine gemeinsame Dateifreigabe und zusätzliche Dateipfade verwenden, um die Daten für die einzelnen Mandanten zu trennen:

Wenn Sie eine Anwendung verwenden, die mithilfe des SMB-Protokolls (Server Message Block) kommunizieren kann, und wenn Sie Active Directory Domain Services lokal oder in Azure verwenden, können Dateifreigaben Autorisierung unterstützen, sowohl auf der Freigabe- als auch auf der Verzeichnis-/Dateiebene.

Erwägen Sie in anderen Szenarien den Einsatz von SAS, um den Zugriff auf bestimmte Dateifreigaben oder Dateien zu erteilen. Wenn Sie SAS verwenden, können Sie keinen Zugriff auf Verzeichnisse erteilen.

Überlegen Sie beim Arbeiten mit freigegebenen Containern, ob Sie die Daten und die Azure Storage-Dienstnutzung für jeden Mandanten nachverfolgen müssen, und planen Sie eine entsprechende Vorgehensweise. Weitere Informationen finden Sie unter Überwachung.

Dateifreigaben pro Mandant

Sie können für jeden Mandanten einzelne Dateifreigaben innerhalb eines einzelnen Speicherkontos erstellen. Es gibt keine Beschränkung für die Anzahl der Dateifreigaben, die Sie innerhalb eines Speicherkontos erstellen können.

Durch Erstellen von Dateifreigaben für jeden Mandanten können Sie Azure Storage-Zugriffssteuerung einschließlich SAS verwenden, um den Zugriff auf die Daten jedes Mandanten zu verwalten. Ferner können Sie problemlos die Kapazität überwachen, die von jeder Dateifreigabe verwendet wird.

Tabellenspeicher-Isolationsmodelle

In der folgenden Tabelle werden die Unterschiede der wichtigsten Mandantenisolationsmodelle für Azure Storage-Tabellen erläutert:

Freigegebene Tabellen mit Partitionsschlüsseln pro Mandant

Wenn Sie Tabellenspeicher mit einer einzelnen freigegebenen Tabelle verwenden, können Sie die integrierte Partitionierungsunterstützung in Betracht ziehen. Jede Entität muss einen Partitionsschlüssel enthalten. Ein Mandantenbezeichner ist oftmals eine gute Wahl für einen Partitionsschlüssel.

Shared Access Signatures und Richtlinien ermöglichen die Angabe eines Partitionsschlüsselbereichs, und Azure Storage stellt sicher, dass Anforderungen, die die Signatur enthalten, nur auf die angegebenen Partitionsschlüsselbereiche zugreifen können. Dadurch können Sie das Valetschlüsselmuster implementieren, das nicht vertrauenswürdigen Clients den Zugriff auf die Partition eines einzelnen Mandanten ermöglicht, ohne Auswirkungen auf andere Mandanten.

Berücksichtigen Sie bei Anwendungen im großen Maßstab den maximalen Durchsatz für jede Tabellenpartition und das Speicherkonto.

Tabellen pro Mandant

Sie können für jeden Mandanten einzelne Tabellen innerhalb eines einzelnen Speicherkontos erstellen. Es gibt keine Beschränkung für die Anzahl der Tabellen, die Sie innerhalb eines Speicherkontos erstellen können.

Durch Erstellen von Tabellen für jeden Mandanten können Sie Azure Storage-Zugriffssteuerung einschließlich SAS verwenden, um den Zugriff auf die Daten jedes Mandanten zu verwalten.

Warteschlangenspeicher-Isolationsmodelle

In der folgenden Tabelle werden die Unterschiede der wichtigsten Mandantenisolationsmodelle für Azure Storage-Warteschlangen erläutert:

Freigegebene Warteschlangen

Wenn Sie sich für die gemeinsame Nutzung einer Warteschlange entscheiden, berücksichtigen Sie die geltenden Kontingente und Grenzwerte. Überlegen Sie bei Lösungen mit einem hohen Anforderungsvolumen, ob der Zieldurchsatz von 2.000 Nachrichten pro Sekunde ausreichend ist.

Warteschlangen bieten keine Partitionierung oder Unterwarteschlangen, daher werden die Daten aller Mandanten möglicherweise vermischt.

Warteschlangen pro Mandant

Sie können für jeden Mandanten einzelne Warteschlangen innerhalb eines einzelnen Speicherkontos erstellen. Es gibt keine Beschränkung für die Anzahl der Warteschlangen, die Sie innerhalb eines Speicherkontos erstellen können.

Durch Erstellen von Warteschlangen für jeden Mandanten können Sie Azure Storage-Zugriffssteuerung einschließlich SAS verwenden, um den Zugriff auf die Daten jedes Mandanten zu verwalten.

Wenn Sie dynamisch Warteschlangen für jeden Mandanten erstellen, berücksichtigen Sie, wie Ihre Logikschicht die Nachrichten aus der Warteschlange jedes Mandanten nutzt. Für komplexere Szenarien sollten Sie die Verwendung von Azure Service Bus in Betracht ziehen, der Features wie Themen und Abonnements, Sitzungen und die automatische Weiterleitung von Nachrichten unterstützt. Dies kann in einer mehrinstanzenfähigen Lösung nützlich sein.

Beitragende

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

Hauptautor:

• John Downs | Principal Software Engineer

Andere Mitwirkende:

• Dr. Christian Geuer-Pollmann | Principal Customer Engineer, FastTrack für Azure
• Patrick Horn | Senior Customer Engineering Manager, FastTrack für Azure
• Ben Hummerstone | Principal Customer Engineer, FastTrack für Azure
• Arsen Vladimirskiy | Principal Customer Engineer, FastTrack for Azure
• Vic Perdana | Cloud Solution Architect, Azure ISV

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

Nächste Schritte

Überprüfen Sie die Speicher- und Datenansätze für mehrere Mandanten.