Azure Storage: Speicherkonto, Container und BLOBs für virtuelle Maschinen

Viele Systembetreuer mit Verantwortung für Unternehmens­daten gelangen bei der Entwicklung eines Cloud-Konzepts irgendwann an den Punkt, an dem sie detailliert wissen müssen, wo und wie die Daten in Azure aufbewahrt werden. Compliance-Anforderungen verlangen genaue Kenntnisse der geplanten Speicherung in der Cloud.

Zum einen ist es wichtig zu wissen, in welchem Land sich sensible Daten einer Organisation befinden werden, und zum anderen, wie sie das Rechenzentrum der Wahl verarbeitet. Die Azure Cloud hält sie auf unter­schiedliche Weise hochverfügbar vor, beispielsweise in lokal redundantem oder Zonen-redundantem Speicher und auch geografisch repliziert.

Azure Storage Account

Zu Beginn ist ein Storage-Account erforderlich und er legt einen Rahmen fest. Das Speicherkonto bildet also die Basis für die Weiter­verarbeitung von Daten in Azure. Es ist auch für Dienste wie Azure Site Recovery, Backup, IaaS oder Azure als Cluster-Witness erforderlich. Parallel dazu kommt dieses Modell auch in Azure Stack zur Anwendung.

Ein Standard Storage-Account in der Cloud liefert 20.000 IOPS und Platz für 40 virtuelle Festplatten mit je 500 IOPS, insgesamt 500 TB. Premium-Speicherkonten auf Basis von SSD mit geringer Latenz werden für verschiedene VMs angeboten und machen maximal 50 Gbps Durchsatz möglich.

Ein Speicherkonto teilt sich in verschiedene Endpunkte auf: darunter zum einen in den BLOB-Speicher mit direkter Ablage für Applikationen über die Storage API, zum anderen für den Dateizugriff via SMB und klassischer Freigabe. Dateifrei­gaben lassen sich aus virtuellen Maschinen ansprechen und wie gewohnt zuordnen (mappen).

Azure BLOB-Storage

Damit unstrukturierte Daten wie Videos, Textdateien oder virtuelle Festplatten Platz finden, werden diese in Azure auf BLOB-Speicher (Binary Large Object) untergebracht. Hinter jedem Storage-Account können sich verschiedene Container mit Page- oder Block-BLOBs befinden. Container sind hier vergleichbar mit Ordnern im klassischen Systemumfeld, auch Zugriffsberechtigungen lassen sich festlegen.

Die unter­schiedlichen Endpunkte sind über URLs eindeutig erreichbar. Ein Page-Blob-Endpunkt für eine gebuchte IaaS-Maschine mit einem Default Container in der Azure Cloud Deutschland setzt sich in meinem Beispiel folgendermaßen zusammen:

https://sa01kueppersger.blob.core.cloudapi.de/vhds/HOST-0120161215083939.vhd

Für mögliche File-, Queue- und Table-Endpunkte (NoSQL) werden URLs nach einem ähnlichen Muster generiert. Dabei können Page-BLOBs eine maximale Größe von 1TB pro Datei mit 512-Byte-Seiten erreichen, sie sind optimiert für zufällige Lese- und Schreiboperationen.

VHDs virtueller Maschinen werden in Page-BLOBs erstellt. Block-BLOBs werden in einer Reihe von 100 MB-Blöcken geschrieben, erreichen maximal 4,77 TB und sind zur Ablage von Videos, Bildern oder Text vorgesehen. Zum Schutz der Daten innerhalb des Azure BLOB-Dienstes besteht die Möglichkeit zur Aktivierung einer Speicher­dienst­verschlüsselung.

Replikationsoptionen

Um Hochver­füg­barkeit zu gewährleisten und mög­lichem Datenverlust entgegen­zuwirken, werden Daten mit unter­schiedlichen Replikations­verfahren redundant vorgehalten:

• LRS (Locally Redundant Storage) bedeutet, dass drei synchrone Kopien in einem einzelnen Datacenter gespeichert werden. Beim Standort Germany Central wäre es beispielsweise nur das RZ in Frankfurt. Der Write Ackknowledge erreicht die Applikation, nachdem die drei Kopien in das lokale Stamp geschrieben wurden. Ein Stamp ist die auf mehrere Racks verteilte Speicher-Skalierungseinheit.
• ZRS (Zone Redundant Storage) speichert drei Kopien der Daten in mehreren Datacentern einer Region. Ein Write Ack erfolgt ebenfalls nach Ablage der drei Kopien. Eine Region ist eine Ansammlung von Rechen­zentren, die nah beieinander liegen. Ein Rechenzentrum entspricht dem Gebäude, das Racks, Stamps usw. hostet.
• GRS (Geographically Redundant Storage) heißt, dass drei Kopien lokal in einem Datacenter gespeichert werden und Azure zusätzlich drei Kopien asynchron an einen ca. 400 km entfernten Standort überträgt. Beim primären Speichern der Daten in Germany Central würden drei Kopien in Germany Northeast (Nähe Magdeburg) abgelegt. Der Write Ack im asynchronen Modus passiert nach drei lokal geschriebenen Kopien.
• RA-GRS (Read-access Geographically Redundant Storage) nutzt den gleichen Replikations­mechanismus wie GRS mit dem Zusatz, dass auch lesend auf das sekundäre RZ zugegriffen werden kann.

Storage-Tiering und Preisgestaltung

Die Kosten für Blob-Speicher eines Speicherkontos hängen ab von der festgelegten Redundanz, der möglichen Leistung und der Zugriffs­ebene. Letztere gliedert sich beim Block-Blob in kalte und heiße Daten.

Der Preis für Hot Data errechnet sich auf Basis des belegten Speichers, seine Verwendung ist sinnvoll für Daten, auf die häufig zugegriffen wird. Cold Data ist günstiger, jedoch nur, wenn Daten wirklich weniger oft abgerufen werden. Im Allgemeinen liefern die Azure Preisrechner Richtwerte für eine Fakturierung.