Hot-, Cool- und Archiv-Zugriffsebenen für Blob-Daten

Die Speicherung von Daten in der Cloud nimmt immer mehr zu. Um die Kosten für die zunehmenden Speicheranforderungen im Blick zu behalten, kann es hilfreich sein, die Daten anhand ihrer Zugriffshäufigkeit und Aufbewahrungsdauer zu organisieren. Azure Storage weist verschiedene Zugriffsebenen auf, sodass Sie Blobdaten basierend auf ihrer Verwendung auf die kostengünstigste Weise speichern können. Folgende Azure Storage-Zugriffsebenen stehen zur Verfügung:

  • Heiße Zugriffsebene: Onlineebene, die für die Speicherung von Daten optimiert ist, auf die häufig zugegriffen wird oder die häufig geändert werden. Die Hot Tier hat die höchsten Speicherkosten, aber die niedrigsten Zugriffskosten.
  • Kalte Zugriffsebene: Onlineebene, die für die Speicherung von Daten optimiert ist, auf die nicht häufig zugegriffen wird oder die nicht häufig geändert werden. Die Daten im Cool-Tier sollten mindestens 30 Tage lang gespeichert werden. Der Cool Tier hat geringere Speicherkosten und höhere Zugriffskosten als der Hot Tier.
  • Archivzugriffsebene: Offlineebene, die für die Speicherung von Daten optimiert ist, auf die nur selten zugegriffen wird und die flexible Latenzanforderungen in der Größenordnung von Stunden aufweisen. Die Daten in der Archivschicht sollten mindestens 180 Tage lang aufbewahrt werden.

Azure Storage-Kapazitätsgrenzen werden auf Kontoebene und nicht nach Zugriffsebene festgelegt. Sie können die Kapazitätsauslastung auf einer Ebene maximieren oder die Kapazität auf zwei oder mehr Ebenen verteilen.

Hinweis

Das Festlegen der Zugriffsebene ist nur für Blockblobs gestattet. Für Anfüge- und Seitenblobs wird dies nicht unterstützt.

Onlinezugriffsebenen

Wenn Ihre Daten in einer Online-Zugriffsebene (entweder Hot oder Cool) gespeichert sind, können die Benutzer sofort darauf zugreifen. Die Hot Tier ist die beste Wahl für Daten, die aktiv genutzt werden, während die Cool Tier ideal für Daten ist, auf die weniger häufig zugegriffen wird, die aber dennoch zum Lesen und Schreiben verfügbar sein müssen.

Beispiele für Anwendungsszenarien für die heiße Schicht sind:

  • Daten, die aktiv verwendet werden oder bei denen häufige Lese- und Schreibvorgänge zu erwarten sind
  • Daten, die für die Verarbeitung und eventuelle Migration auf die kalte Speicherebene bereitgestellt werden.

Zu den Nutzungsszenarien für die kalte Speicherebene gehören:

  • Kurzfristige Datensicherung und Notfallwiederherstellung
  • Ältere Datasets, die nicht häufig verwendet werden, aber für den sofortigen Zugriff verfügbar sein müssen.
  • Umfangreiche Datasets, die kostengünstig gespeichert werden müssen, während weitere Daten zur Verarbeitung gesammelt werden

Informationen zum Verschieben eines Blobs auf die heiße oder kalte Zugriffsebene finden Sie unter Festlegen der Zugriffsebene eines Blobs.

Die Daten im Cool-Tier haben eine etwas geringere Verfügbarkeit, bieten aber die gleiche hohe Beständigkeit, Abruflatenz und Durchsatzmerkmale wie das Hot-Tier. Für Daten in der "Cool"-Stufe können eine etwas geringere Verfügbarkeit und höhere Zugriffskosten im Vergleich zur "Hot"-Stufe ein akzeptabler Kompromiss für niedrigere Gesamtspeicherkosten sein. Weitere Informationen finden Sie unter SLA für Speicher.

Für ein Blob auf der kalten Ebene in einem Konto vom Typ „Universell v2“ fällt eine Gebühr für frühzeitiges Löschen an, wenn es vor Ablauf von 30 Tagen gelöscht oder auf eine andere Ebene verschoben wird. Diese Gebühr fällt anteilig an. Wenn beispielsweise ein Blob in die Cool-Ebene verschoben und nach 21 Tagen gelöscht wird, wird eine Gebühr für die vorzeitige Löschung erhoben, die 9 (30 minus 21) Tagen entspricht, in denen der Blob in der Cool-Ebene gespeichert war.

Die Hot und Cool Tiers unterstützen alle Redundanzkonfigurationen. Weitere Informationen zu Datenredundanzoptionen in Azure Storage finden Sie unter Azure Storage-Redundanz.

Zugriffsebene „Archiv“

Die Archivschicht ist eine Offline-Schicht zur Speicherung von Daten, auf die nur selten zugegriffen wird. Die Archivzugriffsebene hat die niedrigsten Speicherkosten, aber höhere Kosten für den Datenabruf und höhere Latenzzeiten im Vergleich zu den Hot- und Cool-Tiers. Beispiele für Nutzungsszenarien für die Zugriffsebene Archiv sind:

  • Langfristige Sicherung, sekundäre Sicherung und Archivierungsdatasets
  • Originaldaten (Rohdaten), die auch nach der Umwandlung in ein endgültiges verwendbares Format erhalten bleiben müssen
  • Compliance- und Archivdaten, die über einen langen Zeitraum gespeichert werden müssen und auf die selten zugegriffen wird

Informationen zum Verschieben eines Blobs in die Archivebene finden Sie unter Archivieren eines Blobs.

Die Daten müssen sich mindestens 180 Tage lang auf der Archivebene befinden, sonst könnten sie frühzeitig gelöscht werden. Wenn beispielsweise ein Blob in die Archivschicht verschoben und dann nach 45 Tagen gelöscht oder in die Hot-Schicht verschoben wird, wird Ihnen eine Gebühr für die vorzeitige Löschung in Höhe von 135 (180 minus 45) Tagen für die Speicherung dieses Blob in der Archivschicht berechnet.

Solange sich ein Blob auf der Archivebene befindet, kann es nicht gelesen oder geändert werden. Um ein Blob, das sich auf der Archivebene befindet, lesen oder herunterladen zu können, müssen Sie es zunächst auf einer Onlineebene („Heiß“ oder „Kalt“) aktivieren. Abhängig von der Priorität, die Sie für den Aktivierungsvorgang angeben, kann es bis zu 15 Stunden dauern, bis die Daten auf der Archivebene aktiviert sind. Weitere Informationen zur Blobaktivierung finden Sie unter Übersicht über die Aktivierung von Blobs aus der Archivebene.

Die Metadaten eines archivierten Blobs bleiben für den Lesezugriff verfügbar, sodass Sie das Blob und seine Eigenschaften, Metadaten und Indextags auflisten können. Metadaten für einen Blob in der Archivebene sind schreibgeschützt, während Blob-Indextags gelesen oder geschrieben werden können. Momentaufnahmen werden für archivierte Blobs nicht unterstützt.

Die folgenden Operationen werden für Blobs in der Archivebene unterstützt:

Nur Speicherkonten, die für LRS, GRS oder RA-GRS konfiguriert sind, unterstützen das Verschieben von Blobs in die Archivebene. Die Archivspeicherebene wird für ZRS-, GZRS- oder RA-GZRS-Konten nicht unterstützt. Weitere Informationen zu Redundanzkonfigurationen in Azure Storage finden Sie unter Azure Storage-Redundanz.

Um die Redundanzkonfiguration für ein Speicherkonto zu ändern, das Blobs in der Archivebene enthält, müssen Sie zunächst alle archivierten Blobs in der heißen oder kalten Ebene aktivieren. Microsoft empfiehlt, die Redundanzkonfiguration für ein Speicherkonto mit archivierten Blobs möglichst nicht zu ändern, da Aktivierungsvorgänge kostspielig und zeitaufwändig sein können.

Die Migration eines Speicherkontos von LRS zu GRS wird unterstützt, solange keine Blobs in die Archivebene verschoben wurden, während das Konto für LRS konfiguriert war. Die Migration von LRS zu GRS wird unterstützt, solange keine Blobs in die Archivebene verschoben wurden, während das Konto auf LRS eingestellt war.

Einstellung für die Standardzugriffsebene eines Kontos

Speicherkonten verfügen über eine Einstellung für die Standardzugriffsebene, mit der die Onlineebene angegeben wird, auf der ein neues Blob erstellt wird. Die Standardeinstellung für die Zugriffsebene kann entweder auf "Heiß" oder "Kühl" eingestellt werden. Sie können die Standardeinstellung für ein einzelnes Blob überschreiben, wenn Sie das Blob hochladen oder die zugehörige Ebene ändern.

Die Standardzugriffsebene für ein neues universelles V2-Speicherkonto ist standardmäßig auf die heiße Ebene festgelegt. Sie können die Einstellung für die Standardzugriffsebene beim oder nach dem Erstellen eines Speicherkontos ändern. Wenn Sie diese Einstellung im Speicherkonto nicht ändern oder die Ebene beim Hochladen eines Blobs nicht explizit festlegen, wird ein neuer Blob standardmäßig auf die heiße Ebene hochgeladen.

Für ein Blob, dem keine explizite Ebene zugewiesen ist, wird die zugehörige Ebene von der Einstellung für die Standardzugriffsebene des Kontos abgeleitet. Wenn die Zugriffsebene eines Blobs von der Einstellung für die Standardzugriffsebene des Kontos abgeleitet ist, wird im Azure-Portal als Zugriffsebene Heiß (abgeleitet) oder Kalt (abgeleitet) angezeigt.

Die Änderung der Einstellung für die Standardzugriffsebene eines Speicherkontos gilt für alle Blobs im Konto, für die keine explizite Zugriffsebene festgelegt ist. Wenn Sie in einem allgemeinen v2-Konto die Standardeinstellung für die Zugriffsebene von „Heiß“ auf „Kalt“ umschalten, werden Ihnen die Schreibvorgänge (pro 10.000) für alle Blobs berechnet, für die die Zugriffsebene abgeleitet wird. Wenn Sie in einem allgemeinen v2-Konto von „Kalt“ auf „Heiß“ umschalten, werden Ihnen sowohl Lesevorgänge (pro 10.000) als auch Datenabrufe (pro GB) berechnet.

Wenn Sie ein Legacy-Blob-Storage-Konto erstellen, müssen Sie bei der Erstellung die Standardeinstellung für die Zugriffsebene Hot oder Cool festlegen. Das Ändern der Standard-Kontozugriffsebene von "Hot" auf "Cool" in einem älteren Blob Storage-Konto ist kostenlos. Wenn Sie in einem Blob-Storage-Konto von „Kalt“ auf „Heiß“ umschalten, werden Ihnen sowohl Lesevorgänge (pro 10.000) als auch Datenabrufe (pro GB) in Rechnung gestellt. Microsoft empfiehlt, wenn möglich allgemeine v2-Speicherkonten anstelle von Blob-Storage-Konten zu verwenden.

Hinweis

Die Archivebene wird nicht als Standardzugriffsebene für ein Speicherkonto unterstützt.

Festlegen oder Ändern der Ebene eines Blobs

Um die Ebene eines Blobs beim Erstellen explizit festzulegen, geben Sie sie beim Hochladen des Blobs an.

Nach dem Erstellen eines Blobs können Sie die zugehörige Ebene mit einer der folgenden Methoden ändern:

  • Durch Aufrufen des Vorgangs Set Blob Tier, entweder direkt oder über eine Richtlinie zur Lebenszyklusverwaltung. Der Aufruf von Blobtarif festlegen ist in der Regel die beste Option, um die Ebene eines Blobs von einer heißeren in eine kältere Ebene zu ändern.
  • Durch Aufrufen des Vorgangs Copy Blob zum Kopieren eines Blobs zwischen Ebenen. Der Aufruf von Copy Blob wird für die meisten Szenarien empfohlen, bei denen Sie ein Blob aus der Archivebene auf einer Onlineebene aktivieren oder von der kalten auf die heiße Ebene verschieben. Durch Kopieren eines Blobs können Sie die Gebühr für frühzeitiges Löschen vermeiden, wenn das erforderliche Speicherintervall für das Quellblob noch nicht verstrichen ist. Das Kopieren eines Blobs führt jedoch zu Kapazitätsgebühren für zwei Blobs: das Quellblob und das Zielblob.

Der Wechsel der Stufe eines Blobs von Heiß zu Kühl oder Archiv erfolgt sofort, ebenso der Wechsel von Kühl zu Heiß. Die Rehydrierung eines Blob von der Archivebene in die heiße oder kühle Ebene kann bis zu 15 Stunden dauern.

Beachten Sie bei der Änderung der Ebene eines Blobs die folgenden Aspekte:

  • Für ein Blob, das einen Verschlüsselungsbereich verwendet, kann Festlegen der Blobebene nicht aufgerufen werden. Weitere Informationen zu Verschlüsselungsbereichen finden Sie unter Verschlüsselungsbereiche für Blobspeicher.
  • Wenn die Ebene eines BLOBs auf der Grundlage der Standardzugriffsebene des Speicherkontos als „Kalt“ abgeleitet wird und der BLOB in die Archivebene verschoben wird, fallen keine Gebühren für die vorzeitige Löschung an.
  • Wird ein Blob explizit in die Ebene "Cool" und dann in die Ebene "Archiv" verschoben, fällt die Gebühr für vorzeitiges Löschen an.

In der folgenden Tabelle sind die Ansätze zusammengefasst, die Sie zum Verschieben von Blobs zwischen verschiedenen Ebenen nutzen können.

Ursprung/Ziel Heiße Zugriffsebene Kalte Zugriffsebene Archivzugriffsebene
Zugriffsebene „Heiß“ Ändern Sie die Ebene eines Blobs mit Blobtarif festlegen oder Blob kopieren von „Heiß“ in „Kalt“. Weitere Informationen

Verschieben Sie Blobs mit einer Richtlinie für die Lebenszyklusverwaltung auf die Ebene „Kalt“. Weitere Informationen
Ändern Sie die Ebene eines Blobs mit Blobtarif festlegen oder Blob kopieren von „Heiß“ in „Archiv“. Weitere Informationen

Archivieren Sie Blobs mit einer Richtlinie für die Lebenszyklusverwaltung. Weitere Informationen
Zugriffsebene „Kalt“ Ändern Sie die Ebene eines Blobs mit Blobtarif festlegen oder Blob kopieren von „Kalt“ in „Heiß“. Weitere Informationen

Verschieben Sie Blobs mit einer Richtlinie für die Lebenszyklusverwaltung auf die Ebene „Heiß“. Weitere Informationen
Ändern Sie die Ebene eines Blobs mit Blobtarif festlegen oder Blob kopieren von „Kalt“ in „Archiv“. Weitere Informationen

Archivieren Sie Blobs mit einer Richtlinie für die Lebenszyklusverwaltung. Weitere Informationen
Zugriffsebene „Archiv“ Aktivieren Sie ein Blob mit Blobtarif festlegen oder Blob kopieren für die Ebene „Heiß“. Weitere Informationen Aktivieren Sie ein Blob mit Blobtarif festlegen oder Blob kopieren für die Ebene „Kalt“. Weitere Informationen

Lebenszyklusverwaltung für Blobs

Die Blob Storage-Lebenszyklusverwaltung umfasst eine regelbasierte Richtlinie, mit der Sie Daten zur gewünschten Zugriffsebene verschieben können, wenn die angegebenen Bedingungen erfüllt sind. Über die Lebenszyklusverwaltung können Sie auch festlegen, dass Daten am Ende ihrer Lebensdauer ablaufen. Weitere Informationen finden Sie unter Optimieren der Kosten durch Automatisieren der Azure Blob Storage-Zugriffsebenen.

Hinweis

Daten, die in einem Premium-Block-Blob-Storage-Konto gespeichert sind, können nicht mithilfe von Set Blob Tier oder mithilfe von Azure Blob Storage Lebenszyklusverwaltung in Hot, Cool oder Archive eingestuft werden. Um Daten zu verschieben, müssen Sie Blobs aus dem Blockblob-Speicherkonto synchron in die Hot-Tier eines anderen Kontos kopieren, indem Sie die API Put Block From URL oder eine Version von AzCopy verwenden, die diese API unterstützt. Die Put Block From URL-API kopiert Daten synchron auf den Server, was heißt, dass der Aufruf erst abgeschlossen wird, nachdem alle Daten vom ursprünglichen Serverspeicherort an den Zielspeicherort verschoben wurden.

Zusammenfassung der Zugriffsebenenoptionen

In der folgenden Tabelle sind die Funktionen der Zugriffsebenen Hot, Cool und Archive zusammengefasst.

Zugriffsebene „Heiß“ Zugriffsebene „Kalt“ Zugriffsebene „Archiv“
Verfügbarkeit 99,9 % 99 % Offline
Verfügbarkeit
(RA-GRS-Lesevorgänge)
99,99 % 99,9 % Offline
Nutzungsgebühren Höhere Speicherkosten, jedoch geringere Zugriffs- und Transaktionskosten Geringere Speicherkosten, jedoch höhere Zugriffs- und Transaktionskosten Geringste Speicherkosten, jedoch höchste Zugriffs- und Transaktionskosten
Empfohlene Mindestaufbewahrungsdauer für Daten 30 Tage1 180 Tage
Latenz
(Zeit bis zum ersten Byte)
Millisekunden Millisekunden Stunden2
Unterstützte Redundanzkonfigurationen Alle Alle Nur LRS, GRS und RA-GRS3

1 Objekte der Stufe Cool auf Allzweckkonten v2 haben eine Mindestaufbewahrungsdauer von 30 Tagen. Bei Blob Storage-Konten gilt keine Mindestaufbewahrungsdauer für die kalte Ebene.

2 Bei der Rehydrierung eines Blob aus der Archivebene können Sie entweder eine Standard- oder eine hohe Rehydrierungspriorität wählen. Die Optionen unterscheiden sich in Bezug auf Abrufwartezeiten und Kosten. Weitere Informationen finden Sie unter Übersicht über die Rehydrierung von Klecksen aus der Archivebene.

3 Weitere Informationen zu Redundanzkonfigurationen in Azure Storage finden Sie unter Azure Storage-Redundanz.

Preise und Abrechnung

Für alle Speicherkonten wird ein Blockblobspeicher-Preismodell angewandt, das auf der Ebene des jeweiligen Blobs basiert. Beachten Sie die in den folgenden Abschnitten beschriebenen Aspekte der Abrechnung.

Weitere Informationen zu den Preisen für Blockblobs finden Sie unter Preise für Blockblobs.

Kosten für die Speicherkapazität

Die Kosten für die Datenspeicherung hängen nicht nur von der gespeicherten Datenmenge ab, sondern auch von der Zugriffsebene. Je „kälter“ die Ebene, desto geringer die Kosten für die Kapazität pro GB.

Kosten für den Datenzugriff

Je „kälter“ die Ebene, desto höher die Gebühren für den Datenzugriff. Für Daten in der Zugriffsstufe Cool und Archive wird eine Gebühr pro Gigabyte für den Lesezugriff erhoben.

Transaktionskosten

Für alle Ebenen fällt eine Gebühr pro Transaktion an, die steigt, je „kälter“ die Ebene ist.

Datenübertragungskosten bei Georeplikation

Diese Gebühr gilt nur für Konten mit konfigurierter Georeplikation (einschließlich GRS und RA-GRS). Die Datenübertragung für die Georeplikation wird pro Gigabyte abgerechnet.

Übertragungskosten für ausgehende Daten

Ausgehende Datenübertragungen (Daten, die aus einer Azure-Region übertragen werden) werden nach Bandbreitennutzung pro GB abgerechnet. Weitere Informationen zu den Kosten für ausgehende Datenübertragungen finden Sie auf der Seite Bandbreite: Preisübersicht.

Ändern der Standardzugriffsebene eines Kontos

Bei einer Änderung der Kontozugriffsebene fallen Gebühren für die Ebenenänderung für alle Blobs an, für die noch keine explizite Ebene festgelegt ist. Weitere Informationen finden Sie im folgenden Abschnitt Ändern der Zugriffsebene eines Blobs.

Ändern der Zugriffsebene eines Blobs

Beachten Sie die folgenden Auswirkungen auf die Abrechnung bei der Änderung der Ebene eines Blobs:

  • Wenn ein Blob hochgeladen oder zwischen Ebenen verschoben wird, wird dies sofort nach dem Hochladen oder einer Ebenenänderung zur entsprechenden Gebühr in Rechnung gestellt.
  • Wenn ein Blob auf eine kühlere Schicht (Hot to Cool, Hot to Archive oder Cool to Archive) verschoben wird, wird der Vorgang als Schreibvorgang auf der Zielschicht abgerechnet, wobei die Gebühren für Schreibvorgänge (pro 10.000) und Datenschreiben (pro GB) der Zielschicht gelten.
  • Wenn ein Blob in eine wärmere Schicht (Archive to Cool, Archive to Hot oder Cool to Hot) verschoben wird, wird der Vorgang als Lesevorgang aus der Quellschicht abgerechnet, wobei die Gebühren für Lesevorgänge (pro 10.000) und Datenabrufe (pro GB) der Quellschicht gelten. Für alle Blobs, die aus der Ebene „Kalt“ oder „Archiv“ verschoben werden, können auch Gebühren für das frühe Löschen anfallen.
  • Während ein Blob aus der Archivschicht rehydriert wird, werden die Daten dieses Blobs als archivierte Daten abgerechnet, bis die Daten wiederhergestellt sind und die Schicht des Blobs auf Hot oder Cool wechselt.

Die folgende Tabelle gibt Aufschluss darüber, wie Ebenenänderungen abgerechnet werden.

Schreibgebühren (Vorgang + Zugriff) Lesegebühren (Vorgang + Zugriff)
Vorgang Set Blob Tier Von „Hot“ in „Cool“
Heiß zum Archiv
Cool zum Archiv
„Archive“ in „Cool“
„Archive“ in „Hot“
Kühl bis heiß

Wenn Sie die Zugriffsebene für ein Blob ändern, wenn die Versionsverwaltung aktiviert ist, oder wenn das Blob über Momentaufnahmen verfügt, kann dies zu zusätzlichen Kosten führen. Informationen zu Blobs mit aktivierter Versionsverwaltung finden Sie in der Dokumentation zur Blobversionsverwaltung unter Preise und Abrechnung. Informationen zu Blobs mit Momentaufnahmen finden Sie in der Dokumentation zu Blobmomentaufnahmen unter Preise und Abrechnung.

Featureunterstützung

Die Unterstützung für dieses Features kann durch die Aktivierung von Data Lake Storage Gen2, dem Network File System (NFS) 3.0-Protokoll oder dem SSH File Transfer Protocol (SFTP) beeinträchtigt werden.

Wenn Sie eine dieser Funktionen aktiviert haben, lesen Sie bitte den Abschnitt Unterstützung der Blob Storage-Funktion in Azure Storage-Konten, um die Unterstützung für dieses Features zu bewerten.

Nächste Schritte