M365Con 2027 – die kostenlose Online-Konferenz · 11–22 Jan 2027 · 120 sessions→ m365con.net

Blog · Mirko Peters

Azure Elastic SAN vs. Managed Disks vs. Blob Storage: Die richtige Wahl treffen

Von ·

Willkommen zurück im Blog, in dem wir die Gespräche aus unserer Sendung vertiefen. Die Wahl des richtigen Speicherorts für Ihre Daten kann angesichts des umfangreichen Speicherökosystems von Azure schnell unübersichtlich werden. Ob Sie eine neue Cloud-Bereitstellung planen oder eine bestehende Unternehmensumgebung erweitern: Das Verständnis der Feinheiten von Microsoft Azure Storage ist sowohl für

Automatisch mit KI aus dem Originalbeitrag übersetzt. Englisches Original lesen

Cover: Azure Elastic SAN — Simply Explained

Willkommen zurück im Blog, in dem wir die Gespräche aus unserer Sendung vertiefen. Die Wahl des richtigen Speicherorts für Ihre Daten kann angesichts des umfangreichen Speicherökosystems von Azure schnell unübersichtlich werden. Ob Sie eine neue Cloud-Bereitstellung planen oder eine bestehende Unternehmensumgebung erweitern: Das Verständnis der Feinheiten der Speicherangebote von Microsoft Azure ist sowohl für Leistung als auch für Kosteneffizienz entscheidend. Heute vergleichen wir Azure Elastic SAN mit Managed Disks, Azure Files und Blob Storage, damit Sie die beste Architektur für Ihre konkreten Anwendungsanforderungen ermitteln können.

Wenn Sie sich unterwegs noch tiefer mit diesen Konzepten befassen möchten, sehen Sie sich unbedingt die passende Podcast-Folge Azure Elastic SAN — Simply Explained an, in der wir die Prinzipien dieser Speicherarchitektur im Detail erläutern.

Das Speicherökosystem von Azure im Überblick

Azure bietet ein beeindruckendes Spektrum an Speicherdiensten, die auf unterschiedliche Datentypen, Zugriffsmuster und Leistungsanforderungen zugeschnitten sind. Mit wachsenden Cloud-Umgebungen geht es bei der Auswahl des richtigen Werkzeugs jedoch weniger darum, eine Standardoption zu wählen, und mehr darum, die Eigenschaften einer Workload mit den zugrunde liegenden Speicherfunktionen abzugleichen. Betrachtet man Azure Managed Disks, Blob Storage, Azure Files und das neuere Elastic SAN, zeigt sich, dass jeder Dienst für bestimmte betriebliche und leistungsbezogene Herausforderungen entwickelt wurde.

Viele Organisationen beginnen in der Cloud klein und hängen einzelnen virtuellen Maschinen Standard- oder Premium-Datenträger an, ohne lange über die künftige Skalierbarkeit nachzudenken. Doch sobald sich Workloads vervielfachen, Datenbankanforderungen schwanken und Leistungsbedarfe sprunghaft steigen, erkennen Architekten schnell, dass ein Einheitsansatz zu verschwendetem Budget und Leistungsengpässen führt. Um eine belastbare und kosteneffiziente Cloud-Umgebung aufzubauen, sollten wir daher untersuchen, warum klassische Speicheransätze im großen Maßstab an ihre Grenzen stoßen und wie moderne Lösungen wie Elastic SAN diese Lücke schließen.

Warum einzelne Datenträger zum Engpass werden

Azure Managed Disks eignen sich für viele einzelne virtuelle Maschinen hervorragend. Für eine einzelne Datenbank oder einen eigenständigen Webserver ist die Bereitstellung eines dedizierten Datenträgers unkompliziert und zuverlässig. Die Herausforderung zeigt sich, sobald Umgebungen Dutzende oder Hunderte von Workloads umfassen, die jeweils sehr unterschiedliche Leistungsmuster aufweisen.

Betrachten wir ein typisches Unternehmenssetup: Eine zentrale SQL-Datenbank erreicht ihre höchste Transaktionslast möglicherweise zum Monatsende. Ein Reporting-Server könnte jeden Morgen während der täglichen Stand-ups und Analyseaktualisierungen außergewöhnlich stark ausgelastet sein. Backup-Workloads wiederum können nachts erhebliche Speicherbandbreite beanspruchen, während andere Systeme nahezu im Leerlauf sind. Wenn jede Workload einzeln für ihre eigene Spitzenlast dimensioniert wird, zahlen Organisationen häufig für dedizierte Leistung, die einen Großteil der Zeit kaum genutzt wird. Sie stellen dann im Grunde mehrere Speicherressourcen überdimensioniert bereit, nur um gelegentliche Spitzenzeiten abzufangen.

Außerdem löst das Hinzufügen weiterer oder schnellerer Datenträger nicht automatisch jedes Speicherleistungsproblem. Die virtuellen Maschinen von Azure selbst haben je nach konfigurierter Größe strikte Grenzwerte für die gesamte Datenträger-IOPS und den Durchsatz. Das bedeutet, dass Sie leistungsstarke, teure Datenträger anhängen können und trotzdem auf einen frustrierenden Leistungsengpass stoßen, weil die virtuelle Maschine selbst keinen zusätzlichen Speicherverkehr mehr verarbeiten kann. Die Speicherinfrastruktur könnte theoretisch mehr Leistung bereitstellen, doch der Architekturpfad über die virtuelle Maschine hat seine Grenze bereits erreicht.

IOPS, Durchsatz und VM-Limits verstehen

Um eine optimale Speicherarchitektur zu entwerfen, müssen wir genau betrachten, wie Leistung gemessen wird. Zwei zentrale Konzepte bestimmen die Leistung von Cloud-Speicher: IOPS und Durchsatz.

IOPS steht für Input/Output Operations per Second, also Ein- und Ausgabevorgänge pro Sekunde. Der Wert beschreibt, wie viele einzelne Speicherzugriffe pro Sekunde möglich sind. Datenbanken wie Microsoft SQL Server oder PostgreSQL erzeugen häufig enorme Mengen kleiner, zufälliger Lese- und Schreibvorgänge. Eine hohe IOPS-Leistung ist daher entscheidend für eine reaktionsschnelle Anwendung. Wenn Ihre Datenbank Zeit damit verbringt, auf IOPS des Speichers zu warten, spüren Benutzer Verzögerungen, unabhängig davon, wie viel CPU-Leistung Ihre virtuellen Computer besitzen.

Der Durchsatz beschreibt dagegen, wie viele Daten in einem bestimmten Zeitraum übertragen werden können. Er wird meist in Megabyte oder Gigabyte pro Sekunde gemessen. Große Datenbanksicherungen, umfangreiche Dateiübertragungen, Videoverarbeitung und intensive Analyse-Workloads hängen stark von einem anhaltenden Durchsatz ab und weniger von reiner IOPS-Leistung. Unterschiedliche Workloads erfordern völlig verschiedene Kombinationen beider Kennzahlen. Diese innerhalb der Grenzen virtueller Computer auszubalancieren, gehört zu den Kernaufgaben jedes Cloud-Architekten.

Was ist Azure Elastic SAN?

Klassische lokale Rechenzentren lösen ähnliche Leistungs- und Skalierungsprobleme seit Jahrzehnten mit Storage Area Networks, kurz SANs. Statt jedem Server eine vollständig eigenständige Speicherinfrastruktur zu geben, schaffen Unternehmensrechenzentren zentrale Speichersysteme, auf die mehrere Server sicher und effizient zugreifen können.

Azure Elastic SAN überträgt dieses vertraute Modell gemeinsam genutzten Speichers direkt in die Cloud. Dafür müssen Organisationen keine physischen Speichercontroller kaufen, keine Hardware-Arrays installieren, keine Serverracks verkabeln und keine älteren SAN-Systeme selbst betreiben. Azure Elastic SAN ist verwalteter Blockspeicher in Azure, der vollständig um einen gemeinsam genutzten Speicherpool herum entwickelt wurde.

Stellen Sie es sich als großen, zentralen Speicherraum für Ihre Cloud-Workloads vor. Innerhalb dieser Speicherumgebung erhalten einzelne Anwendungen und virtuelle Computer jeweils eigene, getrennte Volumes. Die Workloads bleiben logisch voneinander getrennt, doch die zugrunde liegende Speicherkapazität und Leistung lässt sich als Teil einer größeren, flexiblen gemeinsamen Ressource verwalten.

Elastic SAN, Managed Disks und Blob Storage im Vergleich

Um das richtige Werkzeug für Ihre Umgebung auszuwählen, hilft es zu verstehen, wo Azure Elastic SAN im Vergleich zu anderen wichtigen Speicherdiensten im Azure-Portfolio steht.

Die Architektur von Azure Elastic SAN

Wer versteht, wie Azure Elastic SAN aufgebaut ist, kann besser nachvollziehen, wie Administratoren Kapazität und Leistung im großen Maßstab verwalten. Der Dienst basiert auf drei primären Organisationsebenen: dem SAN selbst, Volume Groups und einzelnen Volumes.

Das SAN

Die SAN-Ressource stellt den obersten Container in Azure dar. Hier legen Administratoren die gesamte Speicherkapazität, die verfügbaren Leistungsmerkmale und die Redundanzoptionen fest. Anstatt jeden Speicher als eigenständige Ressource mit eigenem, isoliertem Lebenszyklus anzulegen, richten Sie ein größeres SAN ein und organisieren darunter den Speicher, den verschiedene Anwendungen benötigen.

Volume Groups

Volume-Gruppen sind eine wichtige Grenze für Verwaltung und Sicherheit zusammengehöriger Speichervolumes. Beispielsweise könnte eine Unternehmensorganisation eine Volume-Gruppe speziell für produktive SQL-Server-Datenbanken anlegen, eine zweite für Entwicklungs- und Testumgebungen und eine dritte für persistente Workloads in Azure Kubernetes Service (AKS).

Verschiedene Volume-Gruppen können unterschiedliche Anforderungen an die Netzwerkanbindung und unterschiedliche Sicherheitsrichtlinien haben. Wenn Sie diese Regeln auf Ebene der Volume-Gruppe anwenden, übernehmen neue Volumes automatisch die passende Konfiguration. So müssen Administratoren die Konnektivitätsregeln nicht für jedes einzelne Volume neu festlegen, das sie bereitstellen.

Volumes

Volumes sind die eigentlichen Speichereinheiten, die von Ihren Servern und Anwendungen genutzt werden. Eine SQL-Server-Instanz könnte ein Volume für die primären Datenbankdateien und ein völlig separates Volume für die Transaktionsprotokolle verwenden. Eine AKS-Anwendung könnte ein Volume zum Speichern persistenter Anwendungsdaten nutzen. Jedes Volume bleibt vollständig getrennt und logisch isoliert, auch wenn sich mehrere Volumes dieselbe zugrunde liegende SAN-Infrastruktur teilen.

So funktioniert das gemeinsame Leistungsmodell

Einer der wirkungsvollsten Aspekte von Azure Elastic SAN ist die Art, wie die Leistung zugewiesen wird. Bei klassischen Setups mit verwalteten Datenträgern ist die Leistung strikt an die Datenträgergröße gekoppelt. Wenn Sie mehr IOPS benötigen, müssen Sie oft einen größeren Datenträger bereitstellen, als Sie tatsächlich brauchen.

Azure Elastic SAN führt ein gemeinsames Leistungsmodell ein. Laut den Plattformspezifikationen trägt jede 1 TiB Basiskapazität eine bestimmte Leistung zum SAN-Pool bei, beispielsweise 5.000 IOPS und 200 MB pro Sekunde Durchsatz. Entscheidend ist, dass diese Leistung dem SAN-Pool gehört und nicht exklusiv für eine einzelne Workload reserviert und gesperrt wird.

So können unterschiedliche Volumes die verfügbare Leistung entsprechend ihrem aktuellen Bedarf nutzen, solange die Gesamtgrenzen des SAN und die Maximalwerte einzelner Volumes nicht überschritten werden. Der private Speicherzugriff stellt sicher, dass Elastic-SAN-Speicher niemals direkt aus dem öffentlichen Internet erreichbar ist. Organisationen können so strikte Netzwerkgrenzen einhalten und genau steuern, welche Workloads sich über sichere private Endpunkte verbinden dürfen.

Stellen Sie sich vor, Sie verwalten vier verschiedene SQL-Datenbanken in Ihrer Umgebung. Die Vertriebsdatenbank ist während der üblichen Geschäftszeiten am stärksten ausgelastet. Die Finanzabteilung erzeugt rund um den Monatsabschluss umfangreiche Berichte. Ein Lagersystem führt nachts intensive Verarbeitungen durch. Eine weitere Datenbank erlebt einen großen wöchentlichen Datenimport. Bei einzeln bereitgestellten Datenträgern muss jede Workload auf ihren absoluten theoretischen Spitzenbedarf dimensioniert werden. Elastic SAN erlaubt es diesen Volumes, aus einem gemeinsamen Leistungspool zu schöpfen. Benötigt die Finanzabteilung zusätzliche IOPS, während das Lagersystem ruhig ist, kann sie auf diesen verfügbaren Spielraum zugreifen. Später verlagert sich die Leistung dann natürlich auf die Workload, die sie gerade am stärksten braucht.

Gemeinsam genutzte Leistung ist allerdings nicht unbegrenzt. Wenn mehrere Workloads gleichzeitig sehr stark ausgelastet sind und ihr kombinierter Bedarf über das hinausgeht, was das SAN bereitstellen kann, können Anfragen gedrosselt werden. Das führt zu höherer Latenz und geringerer Reaktionsfähigkeit der Anwendungen. Administratoren müssen daher weiterhin die kombinierten Spitzenlasten überwachen, damit der zugrunde liegende SAN-Pool korrekt dimensioniert ist.

Das passende Werkzeug für die Anforderungen Ihrer Anwendung wählen

Die Wahl der richtigen Speicherarchitektur in Azure hängt davon ab, die Datenstruktur, die Zugriffsprotokolle und das Leistungsprofil Ihrer Anwendung zu analysieren. Wenn Sie unstrukturierte Medienbestände speichern oder einen Data Lake aufbauen, ist Azure Blob Storage unschlagbar. Wenn Sie Legacy-Anwendungen migrieren, die auf gemeinsame Netzwerkordner angewiesen sind, ist Azure Files Ihre beste Wahl. Für einfache Anwendungen auf einer einzelnen VM halten Azure Managed Disks die Lösung schlank und leistungsfähig.

Wenn Sie jedoch dichte Datenbank-Cluster, containerisierte Anwendungen oder komplexe mehrstufige Umgebungen verwalten, die unter isolierten Speichergrenzen und überdimensionierten Budgets leiden, bietet Azure Elastic SAN eine leistungsstarke architektonische Alternative. Indem Kapazität und Leistung in einem zentralen Block-Storage-Fundament gebündelt werden, können Organisationen mehr Effizienz, Flexibilität und Kontrolle erreichen.

Um dieses Thema zu vertiefen und eine moderierte Diskussion darüber zu hören, wie diese Technologien in moderne Unternehmensarchitekturen passen, hören Sie sich unsere begleitende Podcast-Folge an: Azure Elastic SAN — Simply Explained. Wenn Sie Ihre Speicherstrategie unter Berücksichtigung dieser Prinzipien bewerten, bleibt Ihre Azure-Umgebung auch mit wachsendem Unternehmen schnell, skalierbar und kosteneffizient.

Entitäten in diesem Artikel

Azure Elastic SAN IOPS Azure Files Azure Disk Storage Microsoft Azure Virtual machine Azure Blob Storage

Verwandte Artikel

RSS