Optymalizowanie kosztów przez automatyczne zarządzanie cyklem życia danych
Zarządzanie cyklem życia usługi Azure Blob Storage oferuje zasady oparte na regułach, których można użyć do przeniesienia danych obiektów blob do odpowiednich warstw dostępu lub wygaśnięcia danych na końcu cyklu życia danych.
Za pomocą zasad zarządzania cyklem życia można wykonywać następujące czynności:
- Przeniesienie obiektów blob z chłodnych na gorącą natychmiast po ich korzystaniu z nich w celu zoptymalizowania pod kątem wydajności.
- Przeniesienie bieżących wersji obiektu blob, poprzednich wersji obiektu blob lub migawek obiektów blob do chłodniejszej warstwy magazynowania, jeśli te obiekty nie były używane lub modyfikowane przez pewien czas, aby zoptymalizować pod kątem kosztów.
- Usuń bieżące wersje obiektu blob, poprzednie wersje obiektu blob lub migawki obiektów blob na końcu ich cyklu życia.
- Zastosuj reguły do całego konta magazynu, aby wybrać kontenery lub do podzbioru obiektów blob przy użyciu prefiksów nazw lub tagów indeksu obiektów blob jako filtrów .
Napiwek
Chociaż zarządzanie cyklem życia ułatwia przenoszenie danych między warstwami na jednym koncie, można użyć zadania magazynu, aby wykonać to zadanie na dużą skalę na wielu kontach. Zadanie magazynu to zasób dostępny w usłudze Azure Storage Actions. Platforma bezserwerowa, której można użyć do wykonywania typowych operacji na danych na milionach obiektów na wielu kontach magazynu. Aby dowiedzieć się więcej, zobacz Co to jest usługa Azure Storage Actions?.
Zasady zarządzania cyklem życia są obsługiwane w przypadku blokowych obiektów blob i uzupełnialnych obiektów blob na kontach ogólnego przeznaczenia w wersji 2, kontach blokowych obiektów blob w warstwie Premium i kontach usługi Blob Storage. Zarządzanie cyklem życia nie ma wpływu na kontenery systemowe, takie jak $logs kontenery lub $web .
Ważne
Jeśli zestaw danych musi być czytelny, nie należy ustawiać zasad przenoszenia obiektów blob do warstwy Archiwum. Obiekty blob w warstwie Archiwum nie mogą być odczytywane, chyba że są one najpierw ponownie wypełniania— proces, który może być czasochłonny i kosztowny. Aby uzyskać więcej informacji, zobacz Omówienie ponownego wypełniania obiektów blob z warstwy archiwum. Jeśli zestaw danych musi być często odczytywany, nie należy ustawiać zasad przenoszenia obiektów blob do warstw chłodnych lub zimnych, ponieważ może to spowodować wyższe koszty transakcji.
Optymalizowanie kosztów przez zarządzanie cyklem życia danych
Zestawy danych mają unikatowe cykle życia. Na wczesnym etapie cyklu życia użytkownicy często uzyskują dostęp do niektórych danych. Jednak potrzeba dostępu często drastycznie spada w miarę starzenia się danych. Niektóre dane pozostają bezczynne w chmurze i rzadko są dostępne po ich przechowywaniu. Niektóre zestawy danych wygasają dni lub miesiące po utworzeniu, podczas gdy inne zestawy danych są aktywnie odczytywane i modyfikowane przez całe ich okresy istnienia.
Rozważmy scenariusz, w którym dane są często używane na wczesnym etapie cyklu życia, ale tylko od czasu do czasu po dwóch tygodniach. Poza pierwszym miesiącem zestaw danych jest rzadko używany. W tym scenariuszu magazyn gorący jest najlepszy we wczesnych etapach. Magazyn chłodny jest najbardziej odpowiedni w przypadku okazjonalnego dostępu. Magazyn archiwum jest najlepszą opcją warstwy po wieku danych w ciągu miesiąca. Przenosząc dane do odpowiedniej warstwy magazynowania na podstawie wieku z regułami zasad zarządzania cyklem życia, możesz zaprojektować najtańsze rozwiązanie dla Twoich potrzeb.
Definicja zasad zarządzania cyklem życia
Zasady zarządzania cyklem życia to kolekcja reguł w dokumencie JSON. Poniższy przykładowy kod JSON przedstawia pełną definicję reguły:
{
"rules": [
{
"name": "rule1",
"enabled": true,
"type": "Lifecycle",
"definition": {...}
},
{
"name": "rule2",
"type": "Lifecycle",
"definition": {...}
}
]
}
Zasady są kolekcją reguł, zgodnie z opisem w poniższej tabeli:
| Nazwa parametru | Typ parametru | Uwagi |
|---|---|---|
rules |
Tablica obiektów reguł | Co najmniej jedna reguła jest wymagana w zasadach. W zasadach można zdefiniować maksymalnie 100 reguł. |
Każda reguła w ramach zasad ma kilka parametrów opisanych w poniższej tabeli:
| Nazwa parametru | Typ parametru | Uwagi | Wymagania |
|---|---|---|---|
name |
String | Nazwa reguły może zawierać maksymalnie 256 znaków alfanumerycznych. W nazwie reguły jest rozróżniana wielkość liter. Musi być unikatowa w ramach zasad. | Prawda |
enabled |
Wartość logiczna | Opcjonalna wartość logiczna umożliwiająca tymczasowe wyłączenie reguły. Wartość domyślna ma wartość true, jeśli nie jest ustawiona. | Fałsz |
type |
Wartość wyliczenia | Bieżącym prawidłowym typem jest Lifecycle. |
Prawda |
definition |
Obiekt definiujący regułę cyklu życia | Każda definicja składa się z zestawu filtrów i zestawu akcji. | Prawda |
Definicja reguły zarządzania cyklem życia
Każda definicja reguły w ramach zasad zawiera zestaw filtrów i zestaw akcji. Zestaw filtrów ogranicza akcje reguły do określonego zestawu obiektów w nazwach kontenerów lub obiektów. Zestaw akcji stosuje akcje warstwy lub usuwania do filtrowanego zestawu obiektów.
Przykładowa reguła
Poniższa przykładowa reguła filtruje konto, aby uruchamiać akcje na obiektach, które istnieją wewnątrz sample-container i zaczynają się od blob1.
- Warstwa blob do warstwy Chłodna 30 dni po ostatniej modyfikacji
- Obiekt blob warstwy do warstwy archiwum 90 dni po ostatniej modyfikacji
- Usuń obiekt blob 2555 dni (siedem lat) po ostatniej modyfikacji
- Usuń poprzednie wersje 90 dni po utworzeniu
{
"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"
]
}
}
}
]
}
Uwaga
Element baseBlob w zasadach zarządzania cyklem życia odnosi się do bieżącej wersji obiektu blob. Element version odwołuje się do poprzedniej wersji.
Filtry reguł
Filtruje akcje reguły ograniczania do podzbioru obiektów blob na koncie magazynu. Jeśli zdefiniowano więcej niż jeden filtr, wartość logiczna jest uruchamiana AND we wszystkich filtrach. Możesz użyć filtru, aby określić, które obiekty blob mają być uwzględniane. Filtr nie zapewnia możliwości określenia obiektów blob do wykluczenia.
Filtry obejmują:
| Nazwa filtru | Typ filtru | Uwagi | Jest wymagany |
|---|---|---|---|
| BlobTypes | Tablica wstępnie zdefiniowanych wartości wyliczenia. | Bieżąca wersja obsługuje wersję blockBlob i appendBlob. Tylko akcja Usuń jest obsługiwana dla elementu appendBlob; Ustawienie warstwy nie jest obsługiwane. |
Tak |
| prefiksMatch | Tablica ciągów do dopasowania prefiksów. Każda reguła może definiować maksymalnie 10 prefiksów z uwzględnieniem wielkości liter. Ciąg prefiksu musi zaczynać się od nazwy kontenera. Jeśli na przykład chcesz dopasować wszystkie obiekty blob w obszarze https://myaccount.blob.core.windows.net/sample-container/blob1/..., określ prefiksMatch jako sample-container/blob1. Ten filtr będzie zgodny ze wszystkimi obiektami blob w przykładowym kontenerze , którego nazwy zaczynają się od obiektu blob1.. |
Jeśli nie zdefiniujesz prefiksuMatch, reguła dotyczy wszystkich obiektów blob na koncie magazynu. Ciągi prefiksu nie obsługują dopasowywania symboli wieloznacznych. Znaki takie jak * i ? są traktowane jako literały ciągu. |
Nie. |
| blobIndexMatch | Tablica wartości słownika składająca się z klucza tagu indeksu obiektów blob i warunków wartości do dopasowania. Każda reguła może definiować maksymalnie 10 warunków tagów indeksów obiektów blob. Jeśli na przykład chcesz dopasować wszystkie obiekty blob z elementami Project = Contoso dla https://myaccount.blob.core.windows.net/ reguły, obiekt blobIndexMatch to {"name": "Project","op": "==","value": "Contoso"}. |
Jeśli nie zdefiniujesz obiektu blobIndexMatch, reguła dotyczy wszystkich obiektów blob na koncie magazynu. | Nie. |
Aby dowiedzieć się więcej na temat funkcji indeksu obiektów blob wraz ze znanymi problemami i ograniczeniami, zobacz Zarządzanie danymi i znajdowanie ich w usłudze Azure Blob Storage za pomocą indeksu obiektów blob.
Akcje reguły
Akcje są stosowane do filtrowanych obiektów blob po spełnieniu warunku uruchomienia.
Zarządzanie cyklem życia obsługuje obsługę warstw i usuwanie bieżących wersji, poprzednich wersji i migawek obiektów blob. Zdefiniuj co najmniej jedną akcję dla każdej reguły.
Uwaga
Obsługa warstw nie jest jeszcze obsługiwana na koncie magazynu blokowych obiektów blob w warstwie Premium. W przypadku wszystkich innych kont obsługa warstw jest dozwolona tylko w blokowych obiektach blob, a nie w przypadku uzupełnialnych i stronicowych obiektów blob.
| Akcja | Bieżąca wersja | Snapshot | Poprzednie wersje |
|---|---|---|---|
| tierToCool | Obsługiwane dla blockBlob |
Obsługiwane | Obsługiwane |
| tierToCold | Obsługiwane dla blockBlob |
Obsługiwane | Obsługiwane |
| enableAutoTierToHotFromCool1 | Obsługiwane dla blockBlob |
Nieobsługiwane | Nieobsługiwane |
| tierToArchive4 | Obsługiwane dla blockBlob |
Obsługiwane | Obsługiwane |
| usuń2,3 | Obsługiwane w systemach blockBlob i appendBlob |
Obsługiwane | Obsługiwane |
1 Akcja enableAutoTierToHotFromCool jest dostępna tylko w przypadku użycia z daysAfterLastAccessTimeGreaterThan warunkiem uruchomienia. Ten warunek został opisany w następnej tabeli.
2 Po zastosowaniu do konta z włączoną hierarchiczną przestrzenią nazw akcja usuwania usuwa puste katalogi. Jeśli katalog nie jest pusty, akcja usuwania usuwa obiekty spełniające warunki zasad w ramach pierwszego cyklu wykonywania zasad. Jeśli ta akcja spowoduje, że pusty katalog spełnia również warunki zasad, ten katalog zostanie usunięty w następnym cyklu wykonywania itd.
3 Zasady zarządzania cyklem życia nie spowodują usunięcia bieżącej wersji obiektu blob, dopóki nie zostaną usunięte żadne poprzednie wersje ani migawki skojarzone z tym obiektem blob. Jeśli obiekty blob na koncie magazynu mają poprzednie wersje lub migawki, podczas określania akcji usuwania w ramach zasad należy uwzględnić poprzednie wersje i migawki.
4 Tylko konta magazynu skonfigurowane dla magazynu LRS, GRS lub RA-GRS obsługują przenoszenie obiektów blob do warstwy Archiwum. Warstwa archiwum nie jest obsługiwana dla kont magazynu ZRS, GZRS ani RA-GZRS. Ta akcja jest wyświetlana na podstawie nadmiarowości skonfigurowanej dla konta.
Uwaga
Jeśli zdefiniujesz więcej niż jedną akcję dla tego samego obiektu blob, zarządzanie cyklem życia zastosuje najmniej kosztowną akcję do obiektu blob. Na przykład akcja delete jest tańsza niż akcja tierToArchive. Akcja tierToArchive jest tańsza niż akcja tierToCool.
Warunki uruchamiania są oparte na wieku. Bieżące wersje używają czasu ostatniej modyfikacji lub czasu ostatniego dostępu, poprzednie wersje używają czasu tworzenia wersji, a migawki obiektów blob używają czasu tworzenia migawki do śledzenia wieku.
| Warunek uruchomienia akcji | Wartość warunku | opis |
|---|---|---|
| daysAfterModificationGreaterThan | Wartość całkowita wskazująca wiek w dniach | Warunek akcji w bieżącej wersji obiektu blob |
| daysAfterCreationGreaterThan | Wartość całkowita wskazująca wiek w dniach | Warunek akcji w bieżącej wersji lub poprzedniej wersji obiektu blob lub migawki obiektu blob |
| daysAfterLastAccessTimeGreaterThan1 | Wartość całkowita wskazująca wiek w dniach | Warunek bieżącej wersji obiektu blob po włączeniu śledzenia dostępu |
| daysAfterLastTierChangeGreaterThan | Wartość całkowita wskazująca wiek w dniach po zmianie czasu ostatniej warstwy obiektów blob | Minimalny czas trwania w dniach, przez który obiekt blob z ponownym wypełnianiem jest przechowywany w warstwie Gorąca, Chłodna lub Chłodna przed powrotem do warstwy Archiwum. Ten warunek dotyczy tylko tierToArchive akcji. |
1 Jeśli śledzenie czasu ostatniego dostępu nie jest włączone, daysAfterLastAccessTimeGreaterThan używa daty włączenia zasad cyklu życia zamiast LastAccessTime właściwości obiektu blob. Ta data jest również używana, gdy LastAccessTime właściwość jest wartością null. Aby uzyskać więcej informacji na temat korzystania ze śledzenia czasu ostatniego dostępu, zobacz Przenoszenie danych na podstawie czasu ostatniego dostępu.
Uruchomienia zasad cyklu życia
Podczas konfigurowania lub edytowania zasad cyklu życia może upłynąć do 24 godzin, aby zmiany zaczęły obowiązywać i rozpoczynać pierwsze wykonanie. Czas potrzebny na ukończenie akcji zasad zależy od liczby ocenianych i obsługiwanych obiektów blob.
Jeśli wyłączysz zasady, nie zostaną zaplanowane żadne nowe uruchomienia zasad, ale jeśli przebieg jest już w toku, ten przebieg będzie kontynuowany do momentu jego zakończenia i opłaty są naliczane za wszystkie akcje wymagane do ukończenia przebiegu. Zobacz Dostępność regionalna i cennik.
Ukończone zdarzenie zasad cyklu życia
Zdarzenie LifecyclePolicyCompleted jest generowane przy wykonywaniu akcji zdefiniowanych przez zasady zarządzania cyklem życia. Zostanie wyświetlona sekcja podsumowania dla każdej akcji uwzględnionej w definicji zasad. Poniższy kod JSON przedstawia przykładowe LifecyclePolicyCompleted zdarzenie dla zasad. Ponieważ definicja zasad zawiera deleteakcje , , tierToCooltierToColditierToArchive, zostanie wyświetlona sekcja podsumowania dla każdego z nich.
{
"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"
}
W poniższej tabeli opisano schemat LifecyclePolicyCompleted zdarzenia.
| Pole | Typ | Opis |
|---|---|---|
| scheduleTime | string | Godzina zaplanowana przez zasady cyklu życia |
| deleteSummary | bajt wektorowy<> | Podsumowanie wyników zaplanowanych operacji usuwania obiektów blob |
| tierToCoolSummary | bajt wektorowy<> | Podsumowanie wyników obiektów blob zaplanowanych dla operacji warstwy do chłodu |
| tierToColdSummary | bajt wektorowy<> | Podsumowanie wyników obiektów blob zaplanowanych dla operacji warstwowo-zimnej |
| tierToArchiveSummary | bajt wektorowy<> | Podsumowanie wyników obiektów blob zaplanowanych dla operacji warstwy do archiwum |
Przykłady zasad cyklu życia
W poniższych przykładach pokazano, jak rozwiązywać typowe scenariusze z regułami zasad cyklu życia.
Przenoszenie starzejących się danych do chłodniejszej warstwy
W tym przykładzie pokazano, jak przenieść blokowe obiekty blob z prefiksem sample-container/blob1 lub container2/blob2. Zasady przechodzą obiekty blob, które nie zostały zmodyfikowane w ciągu ponad 30 dni do magazynu chłodnego, a obiekty blob nie zostały zmodyfikowane w ciągu 90 dni do warstwy Archiwum:
{
"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 }
}
}
}
}
]
}
Przenoszenie danych na podstawie czasu ostatniego dostępu
Możesz włączyć śledzenie czasu ostatniego dostępu, aby zachować rekord czasu ostatniego odczytu lub zapisu obiektu blob oraz jako filtr do zarządzania obsługą warstw i przechowywania danych obiektów blob. Aby dowiedzieć się, jak włączyć śledzenie czasu ostatniego dostępu, zobacz Opcjonalne włączanie śledzenia czasu dostępu.
Po włączeniu śledzenia czasu ostatniego dostępu właściwość obiektu blob o nazwie LastAccessTime jest aktualizowana, gdy obiekt blob jest odczytywany lub zapisywany. Operacja Pobierania obiektu blob jest uznawana za operację dostępu. Pobieranie właściwości obiektu blob, pobieranie metadanych obiektów blob i pobieranie tagów obiektów blob nie jest operacjami dostępu, dlatego nie aktualizuj czasu ostatniego dostępu.
Jeśli śledzenie czasu ostatniego dostępu jest włączone, zarządzanie cyklem życia używa LastAccessTime do określenia, czy warunek uruchomienia daysAfterLastAccessTimeGreaterThan jest spełniony. Zarządzanie cyklem życia używa daty włączenia zasad cyklu życia zamiast LastAccessTime w następujących przypadkach:
Wartość
LastAccessTimewłaściwości obiektu blob jest wartością null.Uwaga
Właściwość
lastAccessedOnobiektu blob ma wartość null, jeśli dostęp do obiektu blob nie został włączony od czasu ostatniego śledzenia czasu dostępu.Śledzenie czasu ostatniego dostępu nie jest włączone.
Aby zminimalizować wpływ na opóźnienie dostępu do odczytu, tylko pierwszy odczyt z ostatnich 24 godzin aktualizuje czas ostatniego dostępu. Kolejne operacje odczytu w tym samym 24-godzinnym okresie nie aktualizują czasu ostatniego dostępu. Jeśli obiekt blob jest modyfikowany między operacjami odczytu, czas ostatniego dostępu jest nowszym z dwóch wartości.
W poniższym przykładzie obiekty blob są przenoszone do magazynu chłodnego, jeśli nie były dostępne przez 30 dni. Właściwość enableAutoTierToHotFromCool jest wartością logiczną, która wskazuje, czy obiekt blob powinien być automatycznie warstwowany z chłodu do gorącego, jeśli po ponownym warstwie jest uzyskiwany dostęp do warstwy Chłodna.
Napiwek
Jeśli obiekt blob zostanie przeniesiony do warstwy Chłodna, a następnie zostanie automatycznie przeniesiony z powrotem przed upływem 30 dni, opłata za wczesne usunięcie zostanie naliczona. Przed ustawieniem enablAutoTierToHotFromCool właściwości należy przeanalizować wzorce dostępu danych, aby zmniejszyć nieoczekiwane opłaty.
{
"enabled": true,
"name": "last-accessed-thirty-days-ago",
"type": "Lifecycle",
"definition": {
"actions": {
"baseBlob": {
"enableAutoTierToHotFromCool": true,
"tierToCool": {
"daysAfterLastAccessTimeGreaterThan": 30
}
}
},
"filters": {
"blobTypes": [
"blockBlob"
],
"prefixMatch": [
"mylifecyclecontainer/log"
]
}
}
}
Archiwizowanie danych po pozyskiwaniu
Niektóre dane pozostają bezczynne w chmurze i rzadko, jeśli kiedykolwiek, uzyskują do nich dostęp. Następujące zasady cyklu życia są skonfigurowane do archiwizowania danych wkrótce po ich pozyskiwaniu. W tym przykładzie blokowe obiekty blob są przenoszone w kontenerze o nazwie archivecontainer do warstwy archiwum. Przejście jest realizowane przez działanie na obiektach blob 0 dni po ostatniej modyfikacji.
{
"rules": [
{
"name": "archiveRule",
"enabled": true,
"type": "Lifecycle",
"definition": {
"filters": {
"blobTypes": [ "blockBlob" ],
"prefixMatch": [ "archivecontainer" ]
},
"actions": {
"baseBlob": {
"tierToArchive": {
"daysAfterModificationGreaterThan": 0
}
}
}
}
}
]
}
Uwaga
Firma Microsoft zaleca przekazywanie obiektów blob bezpośrednio do warstwy Archiwum w celu zwiększenia wydajności. Warstwę archiwum można określić w nagłówku x-ms-access-tier operacji Put Blob lub Put Block List . Nagłówek x-ms-access-tier jest obsługiwany z interfejsem REST w wersji 2018-11-09 i nowszych lub najnowszych bibliotek klienta magazynu obiektów blob.
Wygasanie danych na podstawie wieku
Oczekuje się, że niektóre dane wygasną dni lub miesiące po utworzeniu. Zasady zarządzania cyklem życia można skonfigurować tak, aby wygasały dane, usuwając je na podstawie wieku danych. W poniższym przykładzie przedstawiono zasady, które usuwają wszystkie blokowe obiekty blob, które nie zostały zmodyfikowane w ciągu ostatnich 365 dni.
{
"rules": [
{
"name": "expirationRule",
"enabled": true,
"type": "Lifecycle",
"definition": {
"filters": {
"blobTypes": [ "blockBlob" ]
},
"actions": {
"baseBlob": {
"delete": { "daysAfterModificationGreaterThan": 365 }
}
}
}
}
]
}
Usuwanie danych za pomocą tagów indeksu obiektów blob
Niektóre dane powinny być wygasłe tylko wtedy, gdy jawnie oznaczone do usunięcia. Zasady zarządzania cyklem życia można skonfigurować tak, aby wygasały dane oznaczone atrybutami klucza/wartości indeksu obiektów blob. W poniższym przykładzie przedstawiono zasady, które usuwają wszystkie blokowe obiekty blob oznaczone tagiem Project = Contoso. Aby dowiedzieć się więcej na temat indeksu obiektów blob, zobacz Zarządzanie danymi i znajdowanie ich w usłudze Azure Blob Storage za pomocą indeksu obiektów blob.
{
"rules": [
{
"enabled": true,
"name": "DeleteContosoData",
"type": "Lifecycle",
"definition": {
"actions": {
"baseBlob": {
"delete": {
"daysAfterModificationGreaterThan": 0
}
}
},
"filters": {
"blobIndexMatch": [
{
"name": "Project",
"op": "==",
"value": "Contoso"
}
],
"blobTypes": [
"blockBlob"
]
}
}
}
]
}
Zarządzanie poprzednimi wersjami
W przypadku danych, które są modyfikowane i uzyskiwane regularnie przez cały okres ich istnienia, można włączyć przechowywanie wersji magazynu obiektów blob, aby automatycznie obsługiwać poprzednie wersje obiektu. Możesz utworzyć zasady do warstwy lub usunąć poprzednie wersje. Wiek wersji jest określany przez ocenę czasu utworzenia wersji. Ta reguła zasad przenosi poprzednie wersje w kontenerze activedata , które są 90 dni lub starsze po utworzeniu wersji do warstwy Chłodna, i usuwa poprzednie wersje, które mają 365 dni lub starsze.
{
"rules": [
{
"enabled": true,
"name": "versionrule",
"type": "Lifecycle",
"definition": {
"actions": {
"version": {
"tierToCool": {
"daysAfterCreationGreaterThan": 90
},
"delete": {
"daysAfterCreationGreaterThan": 365
}
}
},
"filters": {
"blobTypes": [
"blockBlob"
],
"prefixMatch": [
"activedata/"
]
}
}
}
]
}
Dostępność regionalna i cennik
Funkcja zarządzania cyklem życia jest dostępna we wszystkich regionach świadczenia usługi Azure.
Zasady zarządzania cyklem życia są bezpłatne. Klienci są rozliczani za standardowe koszty operacji dla wywołań interfejsu API set Blob Tier . Operacje usuwania są bezpłatne. Jednak inne usługi i narzędzia platformy Azure, takie jak Microsoft Defender for Storage , mogą pobierać opłaty za operacje zarządzane za pomocą zasad cyklu życia.
Każda aktualizacja ostatniego czasu dostępu obiektu blob jest rozliczana w innej kategorii operacji . Każda ostatnia aktualizacja czasu dostępu jest naliczana jako "inna transakcja" co najwyżej raz co 24 godziny na obiekt, nawet jeśli jest uzyskiwany dostęp do 1000 razy dziennie. Jest to oddzielone od opłat za transakcje odczytu.
Aby uzyskać więcej informacji o cenach, zobacz Cennik blokowych obiektów blob.
Znane problemy i ograniczenia
Obsługa warstw nie jest jeszcze obsługiwana na koncie magazynu blokowych obiektów blob w warstwie Premium. W przypadku wszystkich innych kont obsługa warstw jest dozwolona tylko w blokowych obiektach blob, a nie w przypadku uzupełnialnych i stronicowych obiektów blob.
Zasady zarządzania cyklem życia muszą być odczytywane lub zapisywane w całości. Aktualizacje częściowe nie są obsługiwane.
Każda reguła może mieć maksymalnie 10 prefiksów z uwzględnieniem wielkości liter i maksymalnie 10 warunków tagów indeksu obiektów blob.
Zasady zarządzania cyklem życia nie mogą zmieniać warstwy obiektu blob korzystającego z zakresu szyfrowania.
Akcja usuwania zasad zarządzania cyklem życia nie będzie działać z żadnym obiektem blob w niezmienialnym kontenerze. Za pomocą niezmiennych zasad można tworzyć i odczytywać obiekty, ale nie modyfikować ani usuwać. Aby uzyskać więcej informacji, zobacz Przechowywanie danych obiektów blob krytycznych dla działania firmy przy użyciu niezmiennego magazynu.
Często zadawane pytania
Zobacz Często zadawane pytania dotyczące zarządzania cyklem życia.