Blob Storage: Objektspeicher für die Cloud

Azure Blob Storage (Binary Large Object) ist die Objektspeicherlösung von Azure zum Speichern großer Mengen unstrukturierter Daten — also Daten, die nicht in das Schema einer relationalen Datenbank passen. Beispiele sind Bilder, Videos, Audiodateien, PDF-Dokumente, Protokolldateien, Backups und Anwendungsbinärdateien. Auf Blob Storage wird über HTTP/HTTPS-REST-APIs, das Azure SDK oder die Azure CLI zugegriffen. Es ist einer der am häufigsten verwendeten Azure-Dienste und bildet die Grundlage vieler Data-Lake-, Medien- und Backup-Architekturen.

Blob Storage ist in einer dreistufigen Hierarchie organisiert: Storage Account → Container → Blob. Ein Container ähnelt einem Ordner auf der obersten Ebene — er gruppiert zusammengehörige Blobs und definiert die Zugriffsrichtlinie für alle darin enthaltenen Objekte. Ein Blob ist ein einzelnes Objekt (eine Datei), das in einem Container gespeichert ist. Blob-Namen können Schrägstriche (/) enthalten, um eine Ordnerhierarchie zu simulieren (z. B. images/2024/photo.jpg); Blob Storage ist jedoch grundsätzlich flach aufgebaut — die Schrägstriche sind Bestandteil des Blob-Namens und keine echten Verzeichnisse.

Azure Blob Storage unterstützt drei Blob-Typen: Block blobs — der am häufigsten verwendete Typ, ideal zum Speichern von Dokumenten, Bildern und Videos. Die Daten werden in Blöcke aufgeteilt und parallel hochgeladen; die maximale Größe beträgt etwa 190 TB. Append blobs — optimiert für Vorgänge, bei denen Daten nur angehängt werden, etwa beim Schreiben von Protokolldateien; neue Daten werden immer am Ende hinzugefügt. Page blobs — Sammlungen von 512-Byte-Seiten, die für den wahlfreien Lese- und Schreibzugriff optimiert sind; sie werden von verwalteten Azure-VM-Datenträgern als zugrunde liegender Speichermechanismus verwendet. Verwenden Sie im Zweifelsfall Block blobs — sie sind der Standard für die allgemeine Objektspeicherung.

Blob Storage bietet drei Zugriffsebenen, die Speicherkosten und Zugriffskosten gegeneinander abwägen: Hot tier — höchste Speicherkosten, niedrigste Zugriffskosten; für häufig aufgerufene Daten. Cool tier — niedrigere Speicherkosten, höhere Zugriffskosten und eine Mindestspeicherdauer von 30 Tagen; für selten aufgerufene Daten wie Monatsberichte. Archive tier — niedrigste Speicherkosten (etwa 95 % günstiger als Hot), erfordert jedoch eine mehrere Stunden dauernde Rehydrierung, bevor auf die Daten zugegriffen werden kann; für langfristige Compliance-Archive, auf die nur selten zugegriffen wird. Sie können eine Standardebene auf Kontoebene festlegen und diese pro Blob überschreiben.

Die manuelle Verwaltung von Blob-Zugriffsebenen für Millionen von Blobs ist unpraktikabel. Richtlinien zur Lebenszyklusverwaltung automatisieren diesen Vorgang: Sie definieren Regeln, nach denen Blobs abhängig von ihrem Alter oder ihrem letzten Zugriffsdatum in günstigere Zugriffsebenen verschoben oder gelöscht werden. Zum Beispiel können Blobs nach 30 Tagen ohne Änderung in die Zugriffsebene „Cool“, nach 180 Tagen in „Archive“ verschoben und nach 365 Tagen gelöscht werden. So optimiert Ihr Speicher die Kosten im Laufe der Zeit automatisch, ohne dass ein manueller Eingriff erforderlich ist. Lebenszyklusrichtlinien werden in JSON definiert und auf Speicherkontoebene angewendet, sodass sie alle Blobs im Konto betreffen.

Standardmäßig sind alle Blobs in einem Container privat – nur authentifizierte Benutzer mit den entsprechenden Berechtigungen können darauf zugreifen. Sie können Container und Blobs öffentlich zugänglich machen, indem Sie die Zugriffsebene des Containers auf Blob (einzelne Blobs sind lesbar) oder Container (die Containerauflistung und alle Blobs sind lesbar) festlegen. Für einen detaillierteren, zeitlich begrenzten Zugriff verwenden Sie Shared Access Signatures (SAS) – URLs mit einem kryptografischen Token, das bestimmte Berechtigungen (Lesen, Schreiben, Löschen) für eine bestimmte Ressource und einen bestimmten Zeitraum gewährt, ohne dass Sie Ihre Kontoschlüssel weitergeben müssen.

Azure Blob Storage kann statische Websites hosten – HTML-, CSS-, JavaScript- und Bilddateien werden direkt über HTTP/HTTPS aus einem Speicherkonto bereitgestellt, ohne serverseitigen Code. Aktivieren Sie das Hosting statischer Websites für ein Speicherkonto, legen Sie ein Indexdokument (z. B. index.html) und ein Fehlerdokument fest und laden Sie Ihre statischen Dateien in den speziellen Container $web hoch. Die URL des Speicherkontos wird zur URL Ihrer Website. Kombinieren Sie den Dienst mit Azure CDN, um Unterstützung für benutzerdefinierte Domänen und HTTPS sowie globales Edge-Caching zu erhalten und die Website für Benutzer weltweit zu beschleunigen.

Blob Storage eignet sich hervorragend für Sicherungen von Anwendungen und Datenbanken: Der Dienst ist äußerst langlebig (11 Neunen an Dauerhaftigkeit mit LRS, mit GRS sogar noch höher), hochverfügbar und bei großen Datenmengen sehr kostengünstig – insbesondere mit den Zugriffsebenen „Cool“ oder „Archive“. Viele Azure-Sicherungsdienste (Azure Backup für VMs, automatisierte Sicherungen von SQL Database) speichern ihre Daten im Hintergrund in Blob Storage. Sie können auch Sicherungsskripte schreiben, die im Rahmen eines geplanten Auftrags eine Datenbank mithilfe der Azure CLI oder des SDK direkt in einem Blob sichern.

Azure Data Lake Storage Gen2 (ADLS Gen2) basiert auf Blob Storage und bietet zusätzlich einen hierarchischen Namespace, der Verzeichnisoperationen (Umbenennen, Löschen) atomar und effizient macht – ein entscheidender Vorteil für Big-Data-Analyseworkloads. Wenn Sie den hierarchischen Namespace für ein Speicherkonto aktivieren, wird es in ADLS Gen2 umgewandelt und lässt sich nativ in Azure Synapse Analytics, Azure Databricks und HDInsight integrieren. Der Dienst unterstützt sowohl die Blob Storage API als auch das HDFS-Protokoll und ist daher mit vorhandenen Hadoop-basierten Tools und Frameworks kompatibel.

Die Preise für Blob Storage setzen sich aus drei Bestandteilen zusammen: Speicherkosten – pro GB und Monat, abhängig von der Zugriffsebene (Hot ca. 0,018 USD/GB, Cool ca. 0,01 USD/GB, Archive ca. 0,001 USD/GB in East US). Operationskosten – pro 10.000 Lese- und Schreibvorgänge, wobei die Kosten für kühlere Zugriffsebenen höher sind. Datenübertragungskosten – eingehende Daten (Upload) sind kostenlos, ausgehende Daten (Download ins Internet) werden berechnet. Bei großen Datenmengen hat die Wahl der Zugriffsebene erhebliche Auswirkungen auf die Gesamtkosten: Durch das Verschieben selten aufgerufener Daten von Hot zu Cool lässt sich die Speicherrechnung normalerweise halbieren, während Archive die Kosten um 95 % senken kann.

Regulierte Branchen wie das Finanz- und Gesundheitswesen müssen Daten zur Einhaltung von Vorschriften wie SEC Rule 17a-4 und HIPAA im WORM-Format (write once, read many) speichern. Die Unveränderlichkeitsrichtlinien von Azure Blob Storage ermöglichen es Ihnen, Blobs zu sperren, sodass sie während eines festgelegten Aufbewahrungszeitraums weder geändert noch gelöscht werden können. Es gibt zwei Richtlinientypen: Aufbewahrung für einen bestimmten Zeitraum (der Blob bleibt bis zu einem festgelegten Datum gesperrt) und rechtliche Aufbewahrung (der Blob bleibt auf unbestimmte Zeit gesperrt, bis die Aufbewahrung aufgehoben wird). Nach dem Sperren können selbst Administratoren des Speicherkontos die Blobs während des Aufbewahrungszeitraums nicht löschen.

Testen Sie Ihr Verständnis der Konzepte aus Microsoft Azure Fundamentals (AZ-900), die in dieser Lektion behandelt wurden.

In dieser Lektion haben Sie gelernt: Blob Storage ist ein Objektspeicher für unstrukturierte Daten, die in der Hierarchie aus Speicherkonto, Container und Blob organisiert sind, die drei Zugriffsebenen – Hot, Cool und Archive – gleichen Speicherkosten und Zugriffskosten für unterschiedliche Nutzungsmuster aus und Richtlinien zur Lebenszyklusverwaltung verschieben Blobs abhängig von ihrem Alter automatisch in günstigere Zugriffsebenen oder löschen sie. Als Nächstes betrachten wir Azure Files und Queue Storage für die Dateifreigabe und die Entkopplung von Nachrichten.