Optimieren von Kosten durch automatisches Verwalten des Datenlebenszyklus

Artikel
10/25/2024

Die Azure Blob Storage-Lebenszyklusverwaltung bietet eine regelbasierte Richtlinie, mit deren Hilfe Sie den Übergang von Blob-Daten auf die entsprechenden Zugriffsebenen und den Ablauf der Daten am Ende des Datenlebenszyklus umsetzen können.

Mit der Richtlinie für die Lebenszyklusverwaltung können Sie die folgenden Aufgaben ausführen:

Sofortiger Übergang von kalten zu heißen Blobs, wenn darauf zugegriffen wird, um die Leistung zu optimieren.
Übergang von aktuellen Blobversionen, vorherigen Blobversionen oder Blobmomentaufnahmen zu einer kälteren Speicherebene, wenn für einen bestimmten Zeitraum nicht darauf zugegriffen wurde bzw. keine Änderungen vorgenommen wurden, um die Kosten zu optimieren.
Löschen von aktuellen Blobversionen, vorherigen Blobversionen oder Blobmomentaufnahmen am Ende ihres Lebenszyklus.
Wenden Sie Regeln auf ein gesamtes Speicherkonto an, um Container oder eine Teilmenge von Blobs mithilfe von Namenspräfixen oder BLOB-Indextags als Filter auszuwählen.

Tipp

Während die Lebenszyklusverwaltung Ihnen hilft, Daten zwischen Ebenen in einem einzelnen Konto zu verschieben, können Sie eine Speicheraufgabe verwenden, um diese Aufgabe über mehrere Konten hinweg zu erledigen. Eine Speicheraufgabe ist eine Ressource, die in Azure Speichervorgänge verfügbar ist. Dies ist ein serverloses Framework, mit dem Sie allgemeine Datenvorgänge für Millionen von Objekten über mehrere Speicherkonten hinweg ausführen können. Weitere Informationen finden Sie unter Was sind Azure Speichervorgänge?

Lebenszyklusverwaltungsrichtlinien werden für Blockblobs und Anfügeblobs in Konten vom Typ „Allgemein v2“, „Premium-Blockblob“ und „Blob Storage“ unterstützt. Die Lebenszyklusverwaltung hat keinen Einfluss auf Systemcontainer wie die $logs oder $web-Container.

Wichtig

Wenn ein DataSet lesbar sein muss, legen Sie keine Richtlinie zum Verschieben von Blobs auf die Archivebene fest. Blobs auf der Archivebene können nur gelesen werden, wenn sie zum ersten Mal aktiviert werden. Dies ist ein Prozess, der zeitaufwändig und teuer sein kann. Weitere Informationen finden Sie unter Übersicht über die Aktivierung von Blobs aus der Archivebene. Wenn ein Dataset häufig gelesen werden muss, legen Sie keine Richtlinie zum Verschieben von Blobs in die kühle oder kalte Ebene fest, da dies zu höheren Transaktionskosten führen kann.

Optimieren von Kosten durch Verwalten des Datenlebenszyklus

Datasets haben eindeutige Lebenszyklen. Früh im Lebenszyklus greifen Benutzer häufig auf einige Daten zu. Aber häufig sinkt der Zugriffsbedarf mit zunehmendem Alter der Daten drastisch. Außerdem gibt es Daten, die in der Cloud lediglich vorgehalten werden und auf die nach der Speicherung nur selten zugegriffen wird. Einige Daten laufen Tage oder Monate nach der Erstellung ab, während andere Daten im Verlauf ihrer gesamten Lebensdauer aktiv gelesen und geändert werden.

Stellen Sie sich ein Szenario vor, bei dem in den frühen Stages des Lebenszyklus häufig auf Daten zugegriffen wird, nach zwei Wochen aber nur noch gelegentlich. Nach dem ersten Monat wird auf das Dataset nur noch selten zugegriffen. In diesem Szenario empfiehlt sich in den frühen Phasen heißer Speicher. Die kalte Speicherebene eignet sich am besten für den gelegentlichen Zugriff. Die Archivspeicherebene ist die beste Option, wenn die Daten mehr als einen Monat alt sind. Indem Sie Daten basierend auf ihrem Alter mit Richtlinienregeln für die Lebenszyklusverwaltung auf die entsprechende Speicherebene verschieben, können Sie die kostengünstigste Lösung für Ihre Anforderungen entwerfen.

Definition der Richtlinie zur Lebenszyklusverwaltung

Eine Richtlinie zur Lebenszyklusverwaltung ist eine Sammlung von Regeln in einem JSON-Dokument. Das folgende JSON-Beispiel zeigt eine vollständige Regeldefinition:

{
  "rules": [
    {
      "name": "rule1",
      "enabled": true,
      "type": "Lifecycle",
      "definition": {...}
    },
    {
      "name": "rule2",
      "type": "Lifecycle",
      "definition": {...}
    }
  ]
}

Eine Richtlinie ist eine Sammlung von Regeln, wie in der folgenden Tabelle beschrieben:

Parametername	Parametertyp	Notizen
`rules`	Ein Array von Regelobjekten	Eine Richtlinie muss mindestens eine Regel enthalten. Sie können in einer Richtlinie bis zu 100 Regeln definieren.

Jede Regel innerhalb der Richtlinie verfügt über mehrere Parameter, die in der folgenden Tabelle beschrieben werden:

Parametername	Parametertyp	Notizen	Erforderlich
`name`	String	Ein Regelname kann bis zu 256 alphanumerische Zeichen enthalten. Bei Regelnamen wird die Groß-/Kleinschreibung unterschieden. Er muss innerhalb einer Richtlinie eindeutig sein.	True
`enabled`	Boolean	Ein optionaler boolescher Wert, über den eine Regel temporär deaktiviert werden kann. Der Standardwert ist „True“, wenn dieser Wert nicht festgelegt wurde.	False
`type`	Ein Enumerationswert	Aktuell ist `Lifecycle` der gültige Typ.	True
`definition`	Ein Objekt, das die Lebenszyklusregel definiert	Jede Definition beinhaltet einen Filtersatz und einen Aktionssatz.	True

Definition der Lebenszyklusverwaltungsregel

Jede Regeldefinition innerhalb einer Richtlinie enthält einen Filtersatz und einen Aktionssatz. Der Filtersatz schränkt Regelaktionen auf eine bestimmte Menge von Objekten innerhalb eines Containers oder auf Objektnamen ein. Der Aktionssatz wendet die Ebenen- oder Löschaktionen auf den gefilterten Satz von Objekten an.

Beispielregel

Mit der folgenden Beispielregel wird das Konto so gefiltert, dass Aktionen für Objekte ausgeführt werden, die sich in sample-container befinden und mit blob1 beginnen.

Blob 30 Tage nach der letzten Änderung in die kalte Ebene verschieben
Blob 90 Tage nach der letzten Änderung in die Archivebene verschieben
Blob 2.555 Tage (sieben Jahre) nach der letzten Änderung löschen
Löschen vorheriger Versionen 90 Tage nach der Erstellung

{
  "rules": [
    {
      "enabled": true,
      "name": "sample-rule",
      "type": "Lifecycle",
      "definition": {
        "actions": {
          "version": {
            "delete": {
              "daysAfterCreationGreaterThan": 90
            }
          },
          "baseBlob": {
            "tierToCool": {
              "daysAfterModificationGreaterThan": 30
            },
            "tierToArchive": {
              "daysAfterModificationGreaterThan": 90,
              "daysAfterLastTierChangeGreaterThan": 7
            },
            "delete": {
              "daysAfterModificationGreaterThan": 2555
            }
          }
        },
        "filters": {
          "blobTypes": [
            "blockBlob"
          ],
          "prefixMatch": [
            "sample-container/blob1"
          ]
        }
      }
    }
  ]
}

Hinweis

Das Element baseBlob in einer Richtlinie für die Lebenszyklusverwaltung bezieht sich auf die aktuelle Version eines Blobs. Das Element version verweist auf eine vorherige Version.

Regelfilter

Filter schränken Regelaktionen auf eine Teilmenge der Blobs innerhalb des Speicherkontos ein. Wenn mehrere Filter definiert sind, wird ein logisches AND für alle Filter ausgeführt. Sie können einen Filter verwenden, um anzugeben, welche Blobs einbezogen werden sollen. Mit Filtern können Sie nicht angeben, welche Blobs ausgeschlossen werden sollen.

Filter umfassen Folgendes:

Filtername	Filtertyp	Notizen	Ist erforderlich
blobTypes	Ein Array von vordefinierten Enumerationswerten.	In der aktuellen Version werden `blockBlob` und `appendBlob` unterstützt. Nur die Löschaktion wird unterstützt für `appendBlob`; Ebene einstellen wird nicht unterstützt.	Ja
prefixMatch	Ein Array von Zeichenfolgen für Präfixe, die abgeglichen werden sollen. Jede Regel kann bis zu zehn Präfixe definieren, bei denen die Groß- und Kleinschreibung beachtet wird. Eine Präfixzeichenfolge muss mit einem Containernamen beginnen. Wenn Sie beispielsweise eine Übereinstimmung mit allen Blobs unter „`https://myaccount.blob.core.windows.net/sample-container/blob1/...`“ erzielen möchten, lautet der prefixMatch-Wert `sample-container/blob1`. Dieser Filter stimmt mit allen Blobs im Beispielcontainer überein, deren Namen mit blob1 beginnen. .	Wenn Sie prefixMatch nicht definieren, gilt die Regel für alle Blobs im Speicherkonto. Präfixzeichenfolgen unterstützen keinen Wildcardabgleich. Zeichen wie `*` und `?` werden als Zeichenfolgenliterale behandelt.	Nein
blobIndexMatch	Ein Array von Wörterbuchwerten, die aus dem Blobindextag-Schlüssel und den Wertbedingungen bestehen, die abgeglichen werden sollen. In jeder Regel können bis zu 10 Blobindextag-Bedingungen definiert werden. Wenn Sie beispielsweise alle Blobs mit `Project = Contoso` unter `https://myaccount.blob.core.windows.net/` für eine Regel abgleichen möchten, lautet der blobIndexMatch-Wert `{"name": "Project","op": "==","value": "Contoso"}`.	Wenn Sie blobIndexMatch nicht definieren, gilt die Regel für alle Blobs im Speicherkonto.	Nein

Weitere Informationen zum Blob-Index-Feature sowie zu bekannten Problemen und Einschränkungen finden Sie unter Verwalten und Suchen von Daten in Azure Blob Storage mit Blob-Index.

Regelaktionen

Aktionen werden auf die gefilterten Blobs angewandt, wenn die Ausführungsbedingung erfüllt ist.

Die Lebenszyklusverwaltung unterstützt das Tiering und das Löschen von aktuellen Versionen, vorherigen Versionen und Blobmomentaufnahmen. Definieren Sie mindestens eine Aktion für jede Regel.

Hinweis

Das Tiering wird in einem Premium-Blockblob-Speicherkonto noch nicht unterstützt. Für alle anderen Konten ist das Tiering nur für Blockblobs und nicht für Anfüge- und Seitenblobs zulässig.

Aktion	Aktuelle Version	Momentaufnahme	Frühere Versionen
tierToCool	Unterstützt für `blockBlob`	Unterstützt	Unterstützt
tierToCold	Unterstützt für `blockBlob`	Unterstützt	Unterstützt
enableAutoTierToHotFromCool¹	Unterstützt für `blockBlob`	Nicht unterstützt	Nicht unterstützt
tierToArchive⁴	Unterstützt für `blockBlob`	Unterstützt	Unterstützt
delete^2,3	Für `blockBlob` und `appendBlob` unterstützt	Unterstützt	Unterstützt

¹ Die Aktion enableAutoTierToHotFromCool ist nur verfügbar, wenn sie mit der Ausführungsbedingung daysAfterLastAccessTimeGreaterThan verwendet wird. Diese Bedingung wird in der nächsten Tabelle beschrieben.

² Bei der Anwendung auf ein Konto mit aktiviertem hierarchischem Namespace entfernt eine Löschaktion leere Verzeichnisse. Wenn das Verzeichnis nicht leer ist, werden Objekte, die die Bedingungen der Richtlinie erfüllen, innerhalb des ersten Ausführungszyklus der Lebenszyklusrichtlinie gelöscht. Wenn diese Aktion zu einem leeren Verzeichnis führt, das ebenfalls die Bedingungen der Richtlinie erfüllt, wird dieses Verzeichnis innerhalb des nächsten Ausführungszyklus entfernt usw.

³ Eine Richtlinie für die Lebenszyklusverwaltung löscht die aktuelle Version eines Blobs erst, wenn frühere Versionen oder Momentaufnahmen, die diesem Blob zugeordnet sind, gelöscht wurden. Wenn Blobs in Ihrem Speicherkonto über frühere Versionen oder Momentaufnahmen verfügen, müssen Sie frühere Versionen und Momentaufnahmen einschließen, wenn Sie eine Löschaktion als Teil der Richtlinie angeben.

⁴ Nur Speicherkonten, die für LRS, GRS oder RA-GRS konfiguriert sind, unterstützen das Verschieben von Blobs in die Archivebene. Die Archivebene wird für ZRS-, GZRS- oder RA-GZRS-Konten nicht unterstützt. Diese Aktion wird basierend auf der für das Konto konfigurierten Redundanz aufgelistet.

Hinweis

Wenn für das gleiche Blob mehrere Aktionen definiert sind, wendet die Lebenszyklusverwaltung die am wenigsten teure Aktion auf das Blob an. Beispielsweise ist die Aktion delete kostengünstiger als die Aktion tierToArchive. Die Aktion tierToArchive ist kostengünstiger als die Option tierToCool.

Die Ausführungsbedingungen basieren auf dem Alter. Aktuelle Versionen verwenden den Zeitpunkt der letzten Änderung oder des letzten Zugriffs, vorherige Versionen verwenden den Erstellungszeitpunkt der Version, und Blobmomentaufnahmen verwenden den Erstellungszeitpunkt der Momentaufnahme, um das Alter nachzuverfolgen.

Aktionsausführungsbedingung	Wert der Bedingung	BESCHREIBUNG
daysAfterModificationGreaterThan	Ganzzahliger Wert, der das Alter in Tagen angibt	Die Bedingung für Aktionen für eine aktuelle Version eines Blobs
daysAfterCreationGreaterThan	Ganzzahliger Wert, der das Alter in Tagen angibt	Die Bedingung für Aktionen für die aktuelle Version eines Blobs oder einer Blobmomentaufnahme
daysAfterLastAccessTimeGreaterThan¹	Ganzzahliger Wert, der das Alter in Tagen angibt	Die Bedingung für eine aktuelle Version eines Blobs, wenn die Zugriffsnachverfolgung aktiviert ist
daysAfterLastTierChangeGreaterThan	Ganzzahliger Wert, der das Alter in Tagen nach der letzten Änderungszeit für die Blobebene angibt	Die Mindestdauer in Tagen, in denen ein aktivierter Blob in heißen, kühlen oder kalten Ebenen aufbewahrt wird, bevor er in die Archivebene zurückgegeben wird. Diese Bedingung gilt nur für `tierToArchive`-Aktionen.

¹ Wenn die Nachverfolgung des letzten Zugriffszeitpunkts nicht aktiviert ist, verwendet daysAfterLastAccessTimeGreaterThan statt der Eigenschaft LastAccessTime des Blobs das Datum, an dem die Lebenszyklusrichtlinie aktiviert wurde. Dieses Datum wird auch verwendet, wenn die Eigenschaft LastAccessTime ein NULL-Wert ist. Weitere Informationen dazu, wie die Nachverfolgung des letzten Zugriffszeitpunkts verwendet wird, finden Sie unter Verschieben von Daten basierend auf dem Zeitpunkt des letzten Zugriffs.

Ausführungen der Lebenszyklusrichtlinie

Wenn Sie eine Lebenszyklusrichtlinie konfigurieren oder bearbeiten, kann es bis zu 24 Stunden dauern, bis Änderungen wirksam werden und die erste Ausführung gestartet wird. Die Zeit für die Ausführung von Richtlinienaktionen hängt von der Anzahl der ausgewerteten und betriebenen Blobs ab.

Wenn Sie eine Richtlinie deaktivieren, werden keine neuen Richtlinienausführungen geplant. Wenn jedoch eine Ausführung bereits läuft, wird diese fortgesetzt, bis sie abgeschlossen ist, und Ihnen werden alle Aktionen in Rechnung gestellt, die zum Abschließen der Ausführung erforderlich sind. Weitere Informationen finden Sie unter Regionale Verfügbarkeit und Preise.

Ereignis „Lebenszyklusrichtlinie abgeschlossen“

Das Ereignis LifecyclePolicyCompleted wird generiert, wenn die von einer Lebenszyklusverwaltungsrichtlinie definierten Aktionen durchgeführt werden. Für jede Aktion, die in der Richtliniendefinition enthalten ist, wird ein Zusammenfassungsabschnitt angezeigt. Der folgende JSON-Code zeigt ein LifecyclePolicyCompleted-Ereignis für eine Richtlinie als Beispiel. Da die Richtliniendefinition die Aktionen delete, tierToCool, tierToCold und tierToArchive enthält, wird für jede ein Zusammenfassungsabschnitt angezeigt.

{
    "topic": "/subscriptions/xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx/resourceGroups/contosoresourcegroup/providers/Microsoft.Storage/storageAccounts/contosostorageaccount",
    "subject": "BlobDataManagement/LifeCycleManagement/SummaryReport",
    "eventType": "Microsoft.Storage.LifecyclePolicyCompleted",
    "eventTime": "2022-05-26T00:00:40.1880331",    
    "id": "xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx",
    "data": {
        "scheduleTime": "2022/05/24 22:57:29.3260160",
        "deleteSummary": {
            "totalObjectsCount": 16,
            "successCount": 14,
            "errorList": ""
        },
        "tierToCoolSummary": {
            "totalObjectsCount": 0,
            "successCount": 0,
            "errorList": ""
        },
        "tierToColdSummary": {
            "totalObjectsCount": 0,
            "successCount": 0,
            "errorList": ""
        },
        "tierToArchiveSummary": {
            "totalObjectsCount": 0,
            "successCount": 0,
            "errorList": ""
        }
    },
    "dataVersion": "1",
    "metadataVersion": "1"
}

In folgender Tabelle wird das Schema des LifecyclePolicyCompleted-Ereignisses beschrieben.

Feld	Typ	BESCHREIBUNG
scheduleTime	Zeichenfolge	Zeitpunkt, an dem die Lebenszyklusrichtlinie geplant ist
deleteSummary	vector<byte>	Zusammenfassung der Ergebnisse von Blobs, die für den Löschvorgang geplant sind
tierToCoolSummary	vector<byte>	Zusammenfassung der Ergebnisse von Blobs, die für einen Vorgang zum Festlegen der kalten Ebene geplant sind
tierToColdSummary	vector<byte>	Zusammenfassung der Ergebnisse von Blobs, die für einen Vorgang zum Festlegen der kalten Ebene geplant sind
tierToArchiveSummary	vector<byte>	Zusammenfassung der Ergebnisse von Blobs, die für einen Vorgang zum Festlegen der Archivebene geplant sind

Beispiele für Richtlinien für den Lebenszyklus

Die folgenden Beispiele veranschaulichen die Behandlung von gängigen Szenarien mithilfe von Regeln zur Lebenszyklusverwaltung.

Verschieben von alternden Daten auf eine kühlere Ebene

Dieses Beispiel zeigt den Übergang von Blockblobs mit dem Präfix sample-container/blob1 oder container2/blob2. Die Richtlinie überführt Blobs, die mehr als 30 Tage nicht verändert wurden, in den kalten Speicher und Blobs, die in 90 Tagen nicht verändert wurden, in die Archivebene:

{
  "rules": [
    {
      "name": "agingRule",
      "enabled": true,
      "type": "Lifecycle",
      "definition": {
        "filters": {
          "blobTypes": [ "blockBlob" ],
          "prefixMatch": [ "sample-container/blob1", "container2/blob2" ]
        },
        "actions": {
          "baseBlob": {
            "tierToCool": { "daysAfterModificationGreaterThan": 30 },
            "tierToArchive": { "daysAfterModificationGreaterThan": 90 }
          }
        }
      }
    }
  ]
}

Verschieben von Daten basierend auf dem Datum des letzten Zugriffs

Sie können die Nachverfolgung des letzten Zugriffs aktivieren, um zu erfassen, wann Ihr Blob zuletzt gelesen oder geschrieben wurde, und als Filter zum Verwalten des Tierings und der Aufbewahrung Ihrer Blobdaten. Informationen zum Aktivieren der Nachverfolgung des letzten Zugriffs finden Sie unter Optionales Aktivieren der Nachverfolgung der Zugriffszeit.

Wenn die Zeitüberwachung für den letzten Zugriff aktiviert ist, wird die Blobeigenschaft, mit der LastAccessTime aufgerufen wird, aktualisiert, wenn ein Blob gelesen oder beschrieben wird. Dabei gilt der Vorgang Get Blob als Zugriff. Get Blob Properties, Get Blob Metadata und Get Blob Tags gelten nicht als Zugriff. Daher wird bei diesen Vorgängen die Uhrzeit des letzten Zugriffs nicht aktualisiert.

Wenn die Nachverfolgung des letzten Zugriffszeitpunkts aktiviert ist, ermittelt die Lebenszyklusverwaltung anhand von LastAccessTime, ob die Ausführungsbedingung daysAfterLastAccessTimeGreaterThan erfüllt ist. Die Lebenszyklusverwaltung verwendet in den folgenden Fällen statt LastAccessTime das Datum, an dem die Lebenszyklusrichtlinie aktiviert wurde:

Der Wert der Eigenschaft LastAccessTime des Blobs ist ein NULL-Wert.

Hinweis

Die Eigenschaft lastAccessedOn des Blobs ist NULL, wenn seit dem Aktivieren der Nachverfolgung des letzten Zugriffszeitpunkts auf ein Blob nicht zugegriffen wurde.
Die Nachverfolgung des letzten Zugriffszeitpunkts ist nicht aktiviert.

Um die Auswirkungen auf die Lesezugriffswartezeit zu minimieren, wird die Uhrzeit des letzten Zugriffs nur beim ersten Lesezugriff der letzten 24 Stunden aktualisiert. Bei nachfolgenden Lesezugriffen innerhalb desselben 24-Stunden-Zeitraums wird die Uhrzeit des letzten Zugriffs nicht aktualisiert. Wenn ein Blob zwischen zwei Lesezugriffen geändert wird, ist die Uhrzeit des letzten Zugriffs die aktuellere der beiden Werte.

Im nachstehenden Beispiel werden Blobs in den kalten Speicher verschoben, wenn auf sie während 30 Tagen nicht zugegriffen wurde. Bei der enableAutoTierToHotFromCool-Eigenschaft handelt es sich um einen booleschen Wert, der angibt, ob für einen Blob automatisch ein Tiering von der kalten Ebene zurück zur heißen Ebene durchgeführt werden soll, wenn nach dem Tiering auf die kalte Ebene noch mal auf den Blob zugegriffen wird.

Tipp

Wenn ein Blob in die kalte Ebene verschoben und dann vor dem Ablauf von 30 Tagen automatisch zurückverschoben wird, wird eine Gebühr für das vorzeitige Löschen berechnet. Bevor Sie die enablAutoTierToHotFromCool-Eigenschaft festlegen, müssen Sie die Zugriffsmuster Ihrer Daten analysieren, um unerwartete Gebühren zu reduzieren.

{
  "enabled": true,
  "name": "last-accessed-thirty-days-ago",
  "type": "Lifecycle",
  "definition": {
    "actions": {
      "baseBlob": {
        "enableAutoTierToHotFromCool": true,
        "tierToCool": {
          "daysAfterLastAccessTimeGreaterThan": 30
        }
      }
    },
    "filters": {
      "blobTypes": [
        "blockBlob"
      ],
      "prefixMatch": [
        "mylifecyclecontainer/log"
      ]
    }
  }
}

Archivieren von Daten nach der Erfassung

Außerdem gibt es Daten, die in der Cloud lediglich vorgehalten werden und auf die nur sehr selten oder gar nicht zugegriffen wird. Die folgende Lebenszyklusrichtlinie ist so konfiguriert, dass Daten kurz nach der Erfassung archiviert werden. In diesem Beispiel werden Blockblobs im Container archivecontainer an eine Archivebene überführt. Der Übergang wird durch Ausführung der Aktion für Blobs 0 Tage nach dem Zeitpunkt der letzten Änderung erreicht.

{
  "rules": [
    {
      "name": "archiveRule",
      "enabled": true,
      "type": "Lifecycle",
      "definition": {
        "filters": {
          "blobTypes": [ "blockBlob" ],
          "prefixMatch": [ "archivecontainer" ]
        },
        "actions": {
          "baseBlob": {
              "tierToArchive": { 
                "daysAfterModificationGreaterThan": 0
              }
          }
        }
      }
    }
  ]
}

Hinweis

Microsoft empfiehlt, Ihre Blobs aus Effizienzgründen direkt auf die Archivzugriffsebene hochzuladen. Sie können die Archivebene im Header x-ms-access-tier für den Vorgang Put Blob (Blob festlegen) oder Put Block List (Blockliste festlegen) angeben. Der Header x-ms-access-tier wird von der REST-Version 2018-11-09 und höher oder den neuesten Blobspeicher-Clientbibliotheken unterstützt.

Ablauf von Daten nach dem Alter

Für einige Daten wird erwartet, dass sie einige Tage oder Monate nach der Erstellung ablaufen. Sie können eine Richtlinie zur Lebenszyklusverwaltung so einrichten, dass Daten durch Löschung auf der Grundlage ihres Alters ablaufen. Das folgende Beispiel zeigt eine Richtlinie, die alle Blockblobs löscht, die in den letzten 365 Tagen nicht geändert wurden.

{
  "rules": [
    {
      "name": "expirationRule",
      "enabled": true,
      "type": "Lifecycle",
      "definition": {
        "filters": {
          "blobTypes": [ "blockBlob" ]
        },
        "actions": {
          "baseBlob": {
            "delete": { "daysAfterModificationGreaterThan": 365 }
          }
        }
      }
    }
  ]
}

Löschen von Daten mit Blobindextags

Einige Daten sollten nur ablaufen, wenn sie explizit zur Löschung gekennzeichnet sind. Sie können eine Lebenszyklusverwaltungsrichtlinie so konfigurieren, dass Daten ablaufen, die mit Schlüssel-Wert-Attributen für den Blobindex gekennzeichnet sind. Im folgenden Beispiel ist eine Richtlinie dargestellt, mit der alle Blockblobs gelöscht werden, die mit Project = Contoso gekennzeichnet sind. Weitere Informationen zum Blobindex finden Sie unter Verwalten und Suchen von Daten in Azure Blob Storage mit dem Blobindex.

{
    "rules": [
        {
            "enabled": true,
            "name": "DeleteContosoData",
            "type": "Lifecycle",
            "definition": {
                "actions": {
                    "baseBlob": {
                        "delete": {
                            "daysAfterModificationGreaterThan": 0
                        }
                    }
                },
                "filters": {
                    "blobIndexMatch": [
                        {
                            "name": "Project",
                            "op": "==",
                            "value": "Contoso"
                        }
                    ],
                    "blobTypes": [
                        "blockBlob"
                    ]
                }
            }
        }
    ]
}

Verwalten früherer Versionen

Für Daten, die während ihrer gesamten Lebensdauer regelmäßig geändert werden und auf die regelmäßig zugegriffen wird, können Sie die Blob Storage-Versionsverwaltung aktivieren, um frühere Versionen eines Objekts automatisch zu verwalten. Sie können eine Richtlinie erstellen, um frühere Versionen Ebenen zuzuordnen oder zu löschen. Das Alter der Version wird durch Auswertung der Erstellungszeit der Version bestimmt. Entsprechend dieser Richtlinienregel werden frühere Versionen innerhalb des Containers activedata, die 90 Tage oder älter sind (nach der Versionserstellung), der Ebene „kalt“ zugeordnet und frühere Versionen, die 365 Tage oder älter sind, gelöscht.

{
  "rules": [
    {
      "enabled": true,
      "name": "versionrule",
      "type": "Lifecycle",
      "definition": {
        "actions": {
          "version": {
            "tierToCool": {
              "daysAfterCreationGreaterThan": 90
            },
            "delete": {
              "daysAfterCreationGreaterThan": 365
            }
          }
        },
        "filters": {
          "blobTypes": [
            "blockBlob"
          ],
          "prefixMatch": [
            "activedata/"
          ]
        }
      }
    }
  ]
}

Regionale Verfügbarkeit und Preise

Die Funktion zur Lebenszyklusverwaltung ist in allen Azure-Regionen verfügbar.

Richtlinien für die Lebenszyklusverwaltung sind kostenlos. Kunden werden die regulären Betriebskosten für die Set Blob Tier (Blobebene festlegen)-API-Aufrufe in Rechnung gestellt. Löschvorgänge sind kostenfrei. Andere Azure-Dienste und -Dienstprogramme wie Microsoft Defender für Storage können jedoch Vorgänge berechnen, die über eine Lebenszyklusrichtlinie verwaltet werden.

Jede Aktualisierung der letzten Zugriffszeit auf einen Blob wird unter der Kategorie andere Vorgänge abgerechnet. Jede letzte Aktualisierung zur Zugriffszeit wird als „andere Transaktion“ höchstens einmal alle 24 Stunden pro Objekt selbst dann in Rechnung gestellt, wenn an einem Tag 1.000 mal darauf zugegriffen wird. Dies erfolgt getrennt von den Gebühren für Lesetransaktionen.

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

Bekannte Probleme und Einschränkungen

Das Tiering wird in einem Premium-Blockblob-Speicherkonto noch nicht unterstützt. Für alle anderen Konten ist das Tiering nur für Blockblobs und nicht für Anfüge- und Seitenblobs zulässig.
Eine Richtlinie für das Lebenszyklusmanagement muss vollständig gelesen oder geschrieben werden. Teilaktualisierungen werden nicht unterstützt.
Jede Regel kann bis zu 10 Präfixe (unter Beachtung von Groß-/Kleinschreibung) und bis zu 10 Blob-Indextagbedingungen aufweisen.
Eine Lebenszyklusverwaltungrichtlinie kann die Ebene eines Blobs, das einen Verschlüsselungsbereich verwendet, nicht ändern.
Die Löschaktion einer Richtlinie zur Lebenszyklusverwaltung funktioniert nicht mit einem Blob in einem unveränderlichen Container. Mit einer Unveränderlichkeitsrichtlinie können Objekte erstellt und gelesen, aber nicht geändert oder gelöscht werden. Weitere Informationen finden Sie unter Speichern unternehmenskritischer Blobdaten mit unveränderlichem Speicher.

Häufig gestellte Fragen (FAQ)

Weitere Informationen finden Sie unter Häufig gestellte Fragen zur Lebenszyklusverwaltung.

Freigeben über

Optimieren von Kosten durch automatisches Verwalten des Datenlebenszyklus

Optimieren von Kosten durch Verwalten des Datenlebenszyklus

Definition der Richtlinie zur Lebenszyklusverwaltung

Definition der Lebenszyklusverwaltungsregel

Beispielregel

Regelfilter

Regelaktionen

Ausführungen der Lebenszyklusrichtlinie

Ereignis „Lebenszyklusrichtlinie abgeschlossen“

Beispiele für Richtlinien für den Lebenszyklus

Verschieben von alternden Daten auf eine kühlere Ebene

Verschieben von Daten basierend auf dem Datum des letzten Zugriffs

Archivieren von Daten nach der Erfassung

Ablauf von Daten nach dem Alter

Löschen von Daten mit Blobindextags

Verwalten früherer Versionen

Regionale Verfügbarkeit und Preise

Bekannte Probleme und Einschränkungen

Häufig gestellte Fragen (FAQ)

Nächste Schritte

Feedback

Zusätzliche Ressourcen