Nuta
Dostęp do tej strony wymaga autoryzacji. Możesz spróbować zalogować się lub zmienić katalogi.
Dostęp do tej strony wymaga autoryzacji. Możesz spróbować zmienić katalogi.
Za pomocą zasad zarządzania cyklem życia można przenieść obiekty blob do tanich warstw dostępu na podstawie ich wzorców użycia. Można również całkowicie usunąć obiekty blob na końcu ich cyklu życia. Zasada może działać na bieżących wersjach, poprzednich wersjach i migawkach, ale nie działa na obiektach blob w kontenerach systemowych, takich jak $logs lub $web. Aby uzyskać ogólne informacje, zobacz Omówienie zarządzania cyklem życia usługi Azure Blob Storage.
W tym artykule opisano elementy zasad zarządzania cyklem życia. Przykłady zasad można znaleźć w następujących artykułach:
- Zasady zarządzania cyklem życia, które przenoszą obiekty blob między poziomami
- Zasady zarządzania cyklem życia usuwające obiekty blob
Wskazówka
Chociaż zarządzanie cyklem życia ułatwia optymalizowanie kosztów dla jednego konta, można użyć funkcji Azure Storage Actions , aby wykonać wiele operacji na danych na dużą skalę na wielu kontach.
Reguły
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": {...}
}
]
}
| Nazwa parametru | Typ parametru | Notatki |
|---|---|---|
| Zasady | 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 | Notatki | Wymagane |
|---|---|---|---|
| nazwa | Sznurek | Nazwa reguły może zawierać maksymalnie 256 znaków alfanumerycznych. W nazwie reguły jest rozróżniana wielkość liter. Musi być unikalna w ramach polityki. | Tak |
| włączone | logiczny | Opcjonalna wartość logiczna umożliwiająca tymczasowe wyłączenie reguły. Wartość domyślna to true. | Nie. |
| typ | Wartość wyliczenia | Bieżącym prawidłowym typem jest Lifecycle. |
Tak |
| definicja | Obiekt definiujący regułę cyklu życia | Każda definicja składa się z zestawu filtrów i zestawu akcji. | Tak |
Filtry
Filtry ograniczają akcje do podzbioru obiektów blob w koncie magazynowym. Możesz użyć filtru, aby określić, które obiekty blob mają być uwzględniane. Filtr nie pozwala określić, które obiekty blob należy wykluczyć. Jeśli zdefiniowano więcej niż jeden filtr, do wszystkich filtrów jest stosowana wartość logiczna AND. W poniższej tabeli opisano każdy parametr.
| Nazwa filtru | Typ | Opis | Wymagane |
|---|---|---|---|
| BlobTypes | Tablica wstępnie zdefiniowanych wartości enum | Typ obiektu blob (blockblob lub appendBlob) | Tak |
| prefiksMatch | Tablica ciągów znaków | Te ciągi są prefiksami do dopasowania. | Nie. |
| blobIndexMatch | Tablica wartości słownika | Te wartości składają się z klucza tagu indeksu obiektów blob oraz dopasowanych warunków wartości. | Nie. |
Filtr dopasowania prefiksu
Jeśli zastosujesz filtr prefixMatch, każda reguła może zdefiniować maksymalnie 10 prefiksów uwzględniając wielkość liter. Ciąg prefiksu musi zaczynać się od nazwy kontenera. Jeśli na przykład chcesz dopasować wszystkie obiekty blob znajdujące się pod ścieżką https://myaccount.blob.core.windows.net/sample-container/blob1/..., określ prefixMatch jako sample-container/blob1.
Ten filtr będzie pasować do wszystkich obiektów blob, w sample-container których nazwy zaczynają się od blob1. Jeśli nie zdefiniujesz dopasowania prefiksu, reguła ma zastosowanie do wszystkich blobów na koncie magazynowym. Ciągi prefiksu nie obsługują dopasowywania znaków wieloznacznych. Znaki takie jak * i ? są traktowane jako literały ciągu.
Filtr dopasowania indeksu blobów
Jeśli zastosujesz filtr blobIndexMatch , każda reguła może zdefiniować maksymalnie 10 warunków tagów indeksu obiektów blob. Jeśli na przykład chcesz dopasować wszystkie obiekty blob z Project = Contoso pod https://myaccount.blob.core.windows.net/, wtedy filtr blobIndexMatch to {"name": "Project","op": "==","value": "Contoso"}. Jeśli nie zdefiniujesz wartości dla filtru blobIndexMatch, wówczas reguła dotyczy wszystkich blobów w ramach konta magazynowego.
Czynności
Należy zdefiniować co najmniej jedną akcję dla każdej reguły. Działania są stosowane do przefiltrowanych obiektów blob, gdy zostanie spełniony warunek uruchomienia. Aby dowiedzieć się więcej na temat warunków uruchamiania, zobacz sekcję Warunki uruchamiania akcji w tym artykule. W poniższej tabeli opisano każdą akcję dostępną w definicji zasad.
| Akcja | Opis |
|---|---|
| TierToCool | Ustaw obiekt blob na warstwę chłodnego dostępu. Nieobsługiwane jest w przypadku obiektów blob do uzupełniania, obiektów blob stronicowych lub obiektów blob na koncie magazynowania blokowego obiektów blob typu Premium. |
| TierToCold | Ustaw obiekt blob na warstwę dostępu zimnego. Nieobsługiwane jest w przypadku obiektów blob do uzupełniania, obiektów blob stronicowych lub obiektów blob na koncie magazynowania blokowego obiektów blob typu Premium. |
| TierToArchive | Ustaw obiekt blob w warstwie dostępu archiwum. Ponowne wypełnianie obiektu blob nie powoduje zaktualizowania właściwości ostatniej modyfikacji ani czasu ostatniego dostępu obiektu blob. W związku z tym ta operacja może przenieść odtworzone obiekty blob do warstwy archiwum. Aby temu zapobiec, dodaj daysAfterLastTierChangeGreaterThan warunek do tej akcji.Ta akcja nie jest obsługiwana w przypadku dodatkowych obiektów blob, stronicowych obiektów blob lub obiektów blob na koncie magazynu blokowych obiektów blob w wersji Premium. Nieobsługiwane również w przypadku obiektów blob korzystających z zakresu szyfrowania lub obiektów blob w kontach skonfigurowanych dla magazynu strefowo nadmiarowego (ZRS), magazynu geograficzno-strefowo nadmiarowego (GZRS) lub magazynu geograficzno-strefowo nadmiarowego dostępnego do odczytu (RA-GZRS). |
| enableAutoTierToHotFromCool (włączanie automatycznego poziomowania z chłodnego do gorącego) | Jeśli obiekt blob jest ustawiony na warstwę Chłodna, to działanie automatycznie przenosi go do warstwy Gorąca po uzyskaniu dostępu do niego. Ta akcja jest dostępna tylko wtedy, gdy jest używana z warunkiem uruchomienia daysAfterLastAccessTimeGreaterThan . Ta akcja nie wpływa na obiekty blob, które były ustawione na warstwę chłodną, zanim ta akcja została włączona w zasady. Ta akcja przenosi bloby z chłodnej do gorącej tylko raz na 30 dni. Ta ochrona jest stosowana, aby zabezpieczyć przed wieloma karami za przedwczesne usunięcie, które są naliczane na koncie. Brak wsparcia w poprzednich wersjach lub zrzutach. |
| Usunąć | Usuwa obiekt blob. Nieobsługiwane w przypadku stronicowych obiektów blob lub obiektów blob w niezmiennym kontenerze. |
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 usuwania jest tańsza niż akcja tierToArchive, a akcja tierToArchive jest tańsza niż akcja tierToCool.
Funkcja usuwania na kontach z hierarchiczną przestrzenią nazw
Po zastosowaniu do konta z włączoną hierarchiczną przestrzenią nazw, akcja usunięcia likwiduje 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.
Akcja usuwania blobów z wersjami i migawkami
Zasady zarządzania cyklem życia nie spowodują usunięcia bieżącej wersji obiektu blob do momentu usunięcia poprzednich wersji lub migawek z nim związanych. Jeśli obiekty blob na koncie magazynu mają poprzednie wersje lub migawki, podczas określania akcji usuwania zgodnie z polityką należy uwzględnić poprzednie wersje i migawki.
Warunki uruchamiania akcji
Wszystkie warunki uruchamiania są oparte na czasie. Jeśli liczba dni, które upłynęły, przekracza liczbę określoną dla warunku, powiązana akcja może zostać wykonana. Warunki zasad są oceniane dla każdego obiektu tylko raz podczas uruchamiania zasad. W niektórych przypadkach obiekt może spełniać warunek po jego ocenie przez przebieg. Takie obiekty są przetwarzane w kolejnych uruchomieniach.
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.
W poniższej tabeli opisano każdy warunek uruchomienia akcji.
| Nazwa warunku | Typ | Opis |
|---|---|---|
| dniPoModyfikacjiWiększeNiż | Liczba całkowita | Wiek w dniach od czasu ostatniej modyfikacji obiektu blob. Dotyczy akcji w bieżącej wersji obiektu blob. |
| daysAfterCreationGreaterThan | Liczba całkowita | Wiek w dniach po czasie tworzenia. Dotyczy działań na aktualną wersję blobu, poprzednią wersję blobu lub migawkę blobu. |
| dniPoCzasieOstatniegoDostępuWiększeNiż | Liczba całkowita | Wiek w dniach od czasu ostatniego dostępu lub w niektórych przypadkach od daty, kiedy zasady zostały włączone. Aby dowiedzieć się więcej, zobacz sekcję Śledzenie czasu dostępu poniżej. Dotyczy akcji dotyczących bieżącej wersji obiektu blob po włączeniu śledzenia dostępu. |
| DniPoOstatniejZmianiePoziomuWiększeNiż | Liczba całkowita | Wiek w dniach od czasu ostatniej zmiany poziomu obiektu blob. Minimalny czas trwania w dniach, przez który zrehydratowany obiekt blob jest przechowywany w warstwie gorącej, chłodnej lub zimnej, zanim zostanie zwrócony do warstwy archiwum. Dotyczy tylko akcji tierToArchive . |
Dostęp do śledzenia czasu
Możesz włączyć śledzenie czasu dostępu, aby zarejestrować, kiedy twój obiekt blob był ostatnio odczytywany lub zapisywany, oraz jako filtr do zarządzania przenoszeniem i przechowywaniem danych obiektu blob.
Po włączeniu śledzenia czasu dostępu właściwość obiektu blob o nazwie LastAccessTime jest aktualizowana, gdy obiekt blob jest odczytywany lub zapisywany. Operacje Get Blob i Put Blob to operacje dostępu, które zaktualizują czas dostępu obiektu blob. Jednak Pobierz właściwości obiektu BLOB, Pobierz metadane obiektu BLOB i Pobierz znaczniki obiektu BLOB nie są operacjami dostępu. Operacje nie aktualizują czasu dostępu bloba.
Jeśli zastosujesz warunek uruchomienia daysAfterLastAccessTimeGreaterThan do polityki, LastAccessTime jest używany do ustalenia, czy ten warunek jest spełniony.
Jeśli zastosujesz warunek uruchomienia daysAfterLastAccessTimeGreaterThan do zasad, ale nie włączysz śledzenia czasu dostępu, wtedy LastAccessTime nie będzie używany. Zamiast tego jest używana data włączenia ostatniego śledzenia dostępu. Faktycznie, data włączenia ostatniego śledzenia dostępu jest używana w każdej sytuacji, gdy LastAccessTime właściwość obiektu blob ma wartość null. Może się to zdarzyć nawet wtedy, gdy włączono śledzenie czasu dostępu w przypadkach, w których obiekt blob nie był dostępny od momentu włączenia śledzenia.
Uwaga / Notatka
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.
Aby dowiedzieć się, jak włączyć śledzenie czasu dostępu, zobacz Opcjonalne włączanie śledzenia czasu dostępu.
Dalsze kroki
- Omówienie zarządzania cyklem życia usługi Azure Blob Storage.
- Konfigurowanie zasad zarządzania cyklem życia
- Warstwy dostępu do danych typu blob
- Zasady zarządzania cyklem życia, które przenoszą obiekty blob między poziomami
- Zasady zarządzania cyklem życia usuwające obiekty blob
- Monitorowanie zasad zarządzania cyklem życia
- Zarządzanie danymi w usłudze Azure Blob Storage i znajdowanie ich za pomocą indeksu obiektów blob
- Najlepsze praktyki dotyczące używania warstw dostępu do obiektów blob