Übersicht über Azure-Seitenblobs

Azure Storage bietet drei Arten von Blobspeicher: Blockblobs, Anfügeblobs und Seitenblobs. Blockblobs bestehen aus Blöcken und eignen sich ideal für das Speichern von Text- oder Binärdateien und zum effizienten Hochladen großer Dateien. Append-Blobs bestehen ebenfalls aus Blöcken, sind jedoch für Anhängevorgänge optimiert und daher ideal für Protokollierungsszenarien geeignet. Seitenblobs bestehen aus 512-Byte-Seiten, können insgesamt 8 TB groß sein und sind für häufige wahlfreie Lese-/Schreibzugriffe vorgesehen. Seitenblobs sind die Grundlage von Azure-IaaS-Datenträgern. In diesem Artikel werden die Features und Vorteile von Seitenblobs erläutert.

Seitenblobs sind eine Sammlung von 512-Byte-Seiten, die Lese-/Schreibzugriff auf beliebige Bytebereiche ermöglichen. Dadurch eignen sich Seitenblobs perfekt zum Speichern indexbasierter und platzsparender Datenstrukturen wie Betriebssystemdatenträger und sonstiger Datenträger für VMs und Datenbanken. Azure SQL-Datenbank verwendet Seitenblobs beispielsweise als zugrunde liegenden permanenten Speicher für seine Datenbanken. Darüber hinaus werden Seitenblobs auch häufig für Dateien mit bereichsbasierten Updates verwendet.

Schlüsselfeatures von Azure-Seitenblobs sind die REST-Schnittstelle, die Dauerhaftigkeit des zugrunde liegenden Speichers und die Fähigkeit zur nahtlosen Migration zu Azure. Diese Features werden im nächsten Abschnitt ausführlicher besprochen. Darüber hinaus werden Azure-Seitenblobs derzeit von zwei Speichertypen unterstützt: Storage Premium und Storage Standard. Storage Premium wurde speziell für Workloads konzipiert, die konsistent hohe Leistung und geringe Wartezeit erfordern, sodass Premium-Seitenblobs für Hochleistungsspeicher-Szenarien ideal sind. Standardspeicherkonten sind kostengünstiger zur Ausführung von Workloads, bei denen Wartezeiten eine untergeordnete Rolle spielen.

Beschränkungen

Seitenblobs können nur die Zugriffsebene Hot verwenden; sie können weder die Ebene Cool noch die Ebene Archiv verwenden. Weitere Informationen zu Zugriffsebenen finden Sie unter Zugriffsebenen „Heiß“, „Kalt“ und „Archiv“ für Blobdaten.

Beispiele für Anwendungsfälle

Im Folgenden finden Sie einige Anwendungsfälle für Seitenblobs, die mit Azure IaaS-Datenträgern beginnen. Azure-Seitenblobs bilden das Rückgrat der Plattform für virtuelle Datenträger für Azure-IaaS. Sowohl Azure-Betriebssystemdatenträger als auch Azure-Datendatenträger werden als virtuelle Datenträger implementiert, bei denen die Daten dauerhaft auf der Azure Storage-Plattform gespeichert und anschließend für maximale Leistung an die virtuellen Maschinen bereitgestellt werden. Azure-Datenträger werden im Hyper-V-VHD-Format beibehalten und als Page Blob in Azure Storage gespeichert. Zusätzlich zur Verwendung virtueller Datenträger für Azure-IaaS-VMs ermöglichen Seitenblobs auch PaaS- und DBaaS-Szenarien. Ein Beispiel wäre etwa der Azure SQL-DB-Dienst, der derzeit Seitenblobs zum Speichern von SQL-Daten verwendet, um schnelle wahlfreie Lese-/Schreibzugriffe für die Datenbank zu ermöglichen. Ein weiteres Beispiel: Bei einem PaaS-Dienst für den Zugriff auf freigegebene Medien für Anwendungen für gemeinsame Videobearbeitung ermöglichen Seitenblobs schnellen Zugriff auf zufällige Positionen in den Medien. Außerdem ermöglichen sie schnelles und effizientes Bearbeiten und Zusammenführen derselben Medien durch mehrere Benutzer.

Microsoft-Eigene Dienste wie Azure Site Recovery und Azure Backup sowie viele Drittanbieterentwickler haben mithilfe der REST-Schnittstelle von Page Blob branchenführende Innovationen implementiert. Zu den einzigartigen in Azure implementierten Szenarien zählen:

• Anwendungsorientierte inkrementelle Momentaufnahmeverwaltung: Anwendungen können Momentaufnahmen von Seitenblobs und REST-APIs nutzen, um die Anwendungsprüfpunkte ohne kostspielige Datenduplizierung zu speichern. Azure Storage unterstützt lokale Momentaufnahmen für Seitenblobs, für die nicht das Kopieren des gesamten Blobs erforderlich ist. Diese öffentlichen Momentaufnahmen-APIs ermöglichen auch das Zugreifen auf und Kopieren von Deltas zwischen Momentaufnahmen.
• Livemigration der Anwendung und Daten aus der lokalen Umgebung zur Cloud: Kopieren Sie die lokalen Daten, und schreiben Sie mithilfe von REST-APIs direkt in ein Azure-Seitenblob, während die lokale VM weiterhin ausgeführt wird. Sobald das Ziel erreicht ist, können Sie schnell ein Failover zu der Azure-VM ausführen, die die Daten verwendet. Dies ermöglicht die Migration Ihrer virtuellen Computer und virtuellen Datenträger vom lokalen Standort zur Cloud mit minimaler Ausfallzeit, da die Datenmigration im Hintergrund durchgeführt wird, während Sie weiterhin den virtuellen Computer verwenden. Die für das Failover erforderliche Ausfallzeit ist kurz (wenige Minuten).
• SAS-basierter freigegebener Zugriff, der Szenarien wie z.B. mehrere Lese- und einzelne Schreibvorgänge mit Unterstützung für Gleichzeitigkeitssteuerung ermöglicht.

Nicht verwaltete Datenträger werden eingestellt. Ausführliche Informationen finden Sie unter Migrieren Ihrer nicht verwalteten Azure-Datenträger bis zum 30. September 2025.

Preise

Beide mit Seitenblobs angebotenen Arten von Speicher verfügen über ein eigenes Preismodell. Premium-Seitenblobs folgen dem Preismodell für verwaltete Datenträger. Standardseitenblobs werden auf Grundlage der verwendeten Größe und den einzelnen Transaktionen abgerechnet. Weitere Informationen finden Sie auf der Seite Azure-Seitenblobs: Preise.

Funktionen für Seitenblobs

REST-API

Informationen zu den ersten Schritten bei der Entwicklung mithilfe von Seitenblobs finden Sie unter "Entwickeln mithilfe von Seitenblobs". Sehen Sie sich als Beispiel den Zugriff auf Seitenblobs mit der Storage-Clientbibliothek für .NET an.

Das folgende Diagramm beschreibt die allgemeinen Beziehungen zwischen Konto, Containern und Seitenblobs.

Erstellen eines leeren Seitenblobs mit einer bestimmten Größe

Beziehen Sie sich zuerst auf einen Container. Um ein Seitenblob zu erstellen, rufen Sie die GetPageBlobClient-Methode auf, und rufen Sie dann die PageBlobClient.Create-Methode auf. Übergeben Sie die maximale Größe für das Blob, das erstellt werden soll. Der Wert muss ein Vielfaches von 512 Bytes sein.

long OneGigabyteAsBytes = 1024 * 1024 * 1024;

BlobServiceClient blobServiceClient = new BlobServiceClient(connectionString);

var blobContainerClient =
    blobServiceClient.GetBlobContainerClient(Constants.containerName);

var pageBlobClient = blobContainerClient.GetPageBlobClient("0s4.vhd");

pageBlobClient.Create(16 * OneGigabyteAsBytes);

Ändern der Größe eines Seitenblobs

Verwenden Sie zum Ändern der Größe eines Seitenblobs nach der Erstellung die Resize-Methode. Die angeforderte Größe sollte ein Vielfaches von 512 Bytes sein.

pageBlobClient.Resize(32 * OneGigabyteAsBytes);

Seiten in einen Seitenblob schreiben

Verwenden Sie zum Schreiben von Seiten die PageBlobClient.UploadPages-Methode.

pageBlobClient.UploadPages(dataStream, startingOffset);

So können Sie eine sequenzielle Reihe von Seiten bis zu 4 MB schreiben. Der Offset, in den geschrieben wird, muss an einer 512-Byte-Begrenzung beginnen (startingOffset % 512 == 0) und an einer 512-Begrenzung -1 enden.

Sobald eine Schreibanforderung für eine sequenzielle Folge von Seiten im Blobdienst erfolgreich abgeschlossen und zur Gewährleistung von Dauerhaftigkeit und Ausfallsicherheit repliziert wurde, gilt der Schreibvorgang als abgeschlossen, und an den Client wird eine Erfolgsmeldung zurückgegeben.

Das folgende Diagramm zeigt zwei separate Schreibvorgänge:

1. Einen Schreibvorgang mit der Länge 1.024 Bytes, der am Offset 0 beginnt
2. Einen Schreibvorgang mit der Länge 1.024 Bytes, der am Offset 4096 beginnt

Lesen von Seiten aus einem Seitenblob

Verwenden Sie zum Lesen von Seiten die PageBlobClient.Download-Methode, um einen Bereich von Bytes aus dem Seitenblob zu lesen.

var pageBlob = pageBlobClient.Download(new HttpRange(bufferOffset, rangeSize));

So können Sie das vollständige Blob oder einen Bereich von Bytes, der an einem beliebigen Offset im Blob beginnt, herunterladen. Beim Lesen muss der Offset nicht auf einem Vielfachen von 512 beginnen. Beim Lesen von Bytes aus einer NULL-Seite gibt der Dienst 0 (null) Bytes zurück.

Die folgende Abbildung zeigt einen Lesevorgang mit einem Offset von 256 und einer Bereichsgröße von 4352. Die zurückgegebenen Daten sind in Orange hervorgehoben. Für NUL-Seiten werden Nullen zurückgegeben.

Bei einem platzsparend gefüllten Blob sollten Sie nur die gültigen Seitenbereiche herunterladen, um nicht für ausgehende 0 (null) Bytes zu zahlen und die Downloadwartezeit zu verringern.

Verwenden Sie PageBlobClient.GetPageRanges, um zu bestimmen, welche Seiten mit Daten belegt sind. Sie können dann die zurückgegebenen Bereiche aufzählen und die Daten in jedem Bereich herunterladen.

IEnumerable<HttpRange> pageRanges = pageBlobClient.GetPageRanges().Value.PageRanges;

foreach (var range in pageRanges)
{
    var pageBlob = pageBlobClient.Download(range);
}

Leasen eines Seitenblobs

Der Lease Blob-Vorgang richtet eine Sperre für Schreib- und Löschvorgänge auf einem Blob ein und verwaltet sie. Dieser Vorgang ist nützlich in Szenarien, in denen mehrere Clients auf ein Seitenblob zugreifen, um sicherzustellen, dass jeweils nur ein einziger Client in das Blob schreiben kann. Azure-Datenträger nutzen diesen Leasemechanismus z.B., um sicherzustellen, dass der Datenträger nur von einer einzelnen VM verwaltet wird. Die Sperrdauer kann 15 bis 60 Sekunden betragen oder unendlich sein. Weitere Informationen finden Sie hier.

Zusätzlich zu umfassenden REST-APIs bieten Seitenblobs auch gemeinsamen Zugriff, hohe Beständigkeit und verbesserte Sicherheit. Diese Vorteile werden in den nächsten Absätzen ausführlicher behandelt.

Paralleler Zugriff

Mit der Seitenblob-REST-API und ihrem Leasingmechanismus können Anwendungen von mehreren Clients aus auf das Seitenblob zugreifen. Stellen Sie sich beispielsweise vor, Sie müssten einen verteilten Clouddienst erstellen, der mehreren Benutzern die gemeinsame Nutzung von Speicherobjekten ermöglicht. Dies könnte eine Webanwendung sein, die verschiedenen Benutzern eine umfangreiche Sammlung von Bildern zur Verfügung stellt. Eine Möglichkeit, dies zu implementieren, ist die Verwendung eines virtuellen Computers mit angefügten Datenträgern. Dies hat folgende Nachteile: (i) Die Einschränkung, dass ein Datenträger nur einem einzelnen virtuellen Computer angehängt werden kann, was Skalierbarkeit und Flexibilität einschränkt und die Risiken steigert. Wenn ein Problem mit dem virtuellen Computer oder dem Dienst, der auf dem virtuellen Computer ausgeführt wird, auftritt, kann aufgrund der Lease nicht auf das Image zugegriffen werden, bis die Lease abläuft oder unterbrochen wird; und (ii) die zusätzlichen Kosten einer IaaS-VM.

Eine andere Möglichkeit ist die direkte Verwendung der Seitenblobs über REST-APIs von Azure Storage. Bei dieser Option entfällt die Notwendigkeit teurer IaaS-VMs. Sie bietet die vollständige Flexibilität des direkten Zugriffs von mehreren Clients aus, sie vereinfacht die Bereitstellung mit dem klassischen Bereitstellungsmodell, da die Notwendigkeit entfällt, Datenträger anzuhängen/zu trennen, und sie eliminiert das Risiko des Auftretens von Problemen auf dem virtuellen Computer. Außerdem bietet es bei zufälligen Lese-/Schreibvorgängen das gleiche Leistungsniveau wie eine Festplatte.

Dauerhaftigkeit und Hochverfügbarkeit

Sowohl Standardspeicher als auch Premium-Speicher sind dauerhafter Speicher, bei dem die Seiten-BLOB-Daten immer repliziert werden, um die Haltbarkeit und hohe Verfügbarkeit sicherzustellen. konnte für IaaS-Datenträger und Seitenblobs durchgängig eine Dauerhaftigkeit auf Unternehmensniveau bereitstellen, mit einer branchenweit führenden auf das Jahr umgerechneten Fehlerrate von null Prozent.

Weitere Informationen zur Azure Storage-Redundanz für Standard- und Premium-Speicherkonten finden Sie unter Azure Storage-Redundanz und speziell in diesen beiden Abschnitten:

• Unterstützte Azure Storage-Dienste
• Unterstützte Speicherkontotypen

Nahtlose Migration zu Azure

Für Kunden und Entwickler, die am Implementieren ihrer eigenen benutzerdefinierten Sicherungslösung interessiert sind, bietet Azure auch inkrementelle Momentaufnahmen, die nur die Deltas enthalten. Dieses Feature vermeidet die Kosten für die erste vollständige Kopie, was die Sicherungskosten erheblich reduziert. Zusammen mit der Fähigkeit, Differenzdaten effizient zu lesen und zu kopieren, ist dies eine weitere leistungsstarke Funktion, die Entwicklern ermöglicht, noch innovativer zu sein, und Sicherung und Notfallwiederherstellung (Disaster Recovery, DR) in Azure mit einer herausragenden Benutzererfahrung verbindet. Sie können Ihre eigene Sicherungs- oder DR-Lösung für Ihre VMs in Azure mithilfe von Blob-Snapshots zusammen mit der API zum Abrufen von Seitenbereichen und der API zum inkrementellen Kopieren von Blobs einrichten, um die inkrementellen Daten für DR einfach zu kopieren.

Darüber hinaus werden kritische Workloads vieler Unternehmen bereits in lokalen Rechenzentren ausgeführt. Hauptaspekte bei der Migration der Workload zur Cloud sind die Länge der Ausfallzeit, die beim Kopieren der Daten anfällt, und das Risiko unvorhergesehener Probleme nach dem Wechsel. In vielen Fällen kann die Ausfallzeit ein Ausschlusskriterium für die Migration in die Cloud sein. Die Seitenblob-REST-API von Azure löst dieses Problem, indem sie die Migration kritischer Workloads zur Cloud mit minimaler Unterbrechung ermöglicht.

Beispiele zum Erstellen einer Momentaufnahme und zum Wiederherstellen eines Seitenblobs aus einer Momentaufnahme finden Sie unter Einrichten eines Sicherungsprozesses mithilfe inkrementeller Momentaufnahmen.