Optimieren von Kosten durch automatisches Verwalten des Datenlebenszyklus

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.

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.

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:

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

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"
          ]
        }
      }
    }
  ]
}

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:

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.

¹ 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.

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.

¹ 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.

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.

{
  "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
              }
          }
        }
      }
    }
  ]
}

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.

Nächste Schritte

• Konfigurieren einer Richtlinie für die Lebenszyklusverwaltung
• Zugriffsebenen „Heiß“, „Kalt“ und „Archiv“ für Blobdaten
• Verwalten und Suchen von Daten in Azure Blob Storage mit dem Blobindex
• Bewährte Methoden für die Verwendung von Blobzugriffsebenen