Optymalizowanie kosztów przez automatyczne zarządzanie cyklem życia danych
Zestawy danych mają unikatowe cykle życia. Na początku cyklu życia użytkownicy często uzyskują dostęp do niektórych danych. Jednak potrzeba dostępu często spada drastycznie w miarę starzenia się danych. Niektóre dane pozostają bezczynne w chmurze i rzadko są dostępne po zapisie. 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. Zarządzanie cyklem życia usługi Azure 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:
- Przejście obiektów blob z chłodnej na gorącą natychmiast po ich korzystaniu w celu zoptymalizowania pod kątem wydajności.
- Przenoszenie 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 dostępne lub modyfikowane przez pewien czas, aby zoptymalizować koszt. W tym scenariuszu zasady zarządzania cyklem życia mogą przenosić obiekty z gorąca do chłodna, gorąca do archiwum lub z chłodnej do archiwum.
- Usuń bieżące wersje obiektu blob, poprzednie wersje obiektu blob lub migawek obiektów blob na końcu ich cyklu życia.
- Zdefiniuj reguły, które mają być uruchamiane raz dziennie na poziomie konta magazynu.
- Zastosuj reguły do kontenerów lub do podzestawu obiektów blob przy użyciu prefiksów nazw lub tagów indeksów obiektów blob jako filtrów.
Rozważmy scenariusz, w którym dane są często dostępne na wczesnym etapie cyklu życia, ale tylko od czasu do czasu po dwóch tygodniach. Po pierwszym miesiącu zestaw danych jest rzadko używany. W tym scenariuszu magazyn gorący jest najlepszy na wczesnych etapach. Magazyn chłodny jest najbardziej odpowiedni w przypadku okazjonalnego dostępu. Magazyn archiwum jest najlepszą opcją warstwy po wiekach danych w ciągu miesiąca. Przenosząc dane do odpowiedniej warstwy magazynowania na podstawie jego wieku z regułami zasad zarządzania cyklem życia, można zaprojektować najmniej kosztowne rozwiązanie dla Twoich potrzeb.
Zasady zarządzania cyklem życia są obsługiwane w przypadku blokowych obiektów blob i uzupełnialnych obiektów blob w przypadku kont ogólnego przeznaczenia w wersji 2, blokowych obiektów blob w warstwie Premium i kont 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łnianie, 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.
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 | Wymagane |
|---|---|---|---|
name |
Ciąg | Nazwa reguły może zawierać maksymalnie 256 znaków alfanumerycznych. Nazwa reguły jest rozróżniana wielkość liter. Musi być unikatowa w ramach zasad. | Prawda |
enabled |
Wartość logiczna | Opcjonalny wartość logiczna umożliwiająca tymczasowe wyłączenie reguły. Wartość domyślna jest prawdziwa, jeśli nie jest ustawiona. | Fałsz |
type |
Wartość wyliczenia | Bieżący prawidłowy typ to Lifecycle. |
Prawda |
definition |
Obiekt, który definiuje 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. Ustawienie filtru 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 dotyczące obiektów, które istnieją wewnątrz sample-container obiektu i zaczynają się od blob1.
- Warstwowy obiekt blob do warstwy Chłodna 30 dni po ostatniej modyfikacji
- Warstwowy obiekt blob do archiwizacji w warstwie 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
},
"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ł
Filtry ograniczają akcje reguły do podzestawu obiektów blob na koncie magazynu. Jeśli zdefiniowano więcej niż jeden filtr, na wszystkich filtrach jest uruchamiany logiczny AND .
Dostępne są następujące filtry:
| Nazwa filtru | Typ filtru | Uwagi | Jest wymagane |
|---|---|---|---|
| BlobTypes | Tablica wstępnie zdefiniowanych wartości wyliczenia. | Bieżąca wersja obsługuje blockBlob wersję i appendBlob. Tylko usuwanie jest obsługiwane w systemie appendBlob, warstwa set nie jest obsługiwana. |
Tak |
| prefiksMatch | Tablica ciągów pasujących do 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 do https://myaccount.blob.core.windows.net/sample-container/blob1/... reguły, prefiksMatch to sample-container/blob1. |
Jeśli nie zdefiniujesz prefiksuMatch, reguła ma zastosowanie do wszystkich obiektów blob na koncie magazynu. | 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 tagu indeksu obiektów blob. Jeśli na przykład chcesz dopasować wszystkie obiekty blob w Project = Contoso obszarze 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 ma zastosowanie do 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 i znajdowanie danych na 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.
| Akcja | Bieżąca wersja | Snapshot | Poprzednie wersje |
|---|---|---|---|
| tierToCool | Obsługiwane dla blockBlob |
Obsługiwane | Obsługiwane |
| enableAutoTierToHotFromCool | Obsługiwane dla blockBlob |
Nieobsługiwane | Nieobsługiwane |
| tierToArchive | Obsługiwane dla blockBlob |
Obsługiwane | Obsługiwane |
| usuń1 | Obsługiwane dla blockBlob i appendBlob |
Obsługiwane | Obsługiwane |
1 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 24-godzinnego cyklu. Jeśli ta akcja spowoduje utworzenie pustego katalogu spełniającego również warunki zasad, ten katalog zostanie usunięty w ciągu najbliższego 24-godzinnego cyklu itd.
Uwaga
Jeśli zdefiniujesz więcej niż jedną akcję w tym samym obiekcie blob, zarządzanie cyklem życia stosuje najmniej kosztowną akcję do obiektu blob. Na przykład akcja delete jest tańsza niż akcja tierToArchive. Akcja jest tańsza niż akcja tierToArchivetierToCool.
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 poprzedniej wersji obiektu blob lub migawki obiektu blob |
| daysAfterLastAccessTimeGreaterThan | Wartość całkowita wskazująca wiek w dniach | Warunek bieżącej wersji obiektu blob po włączeniu śledzenia dostępu |
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 poprzedzone 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 ostatniego odczytu lub zapisu obiektu blob oraz jako filtr do zarządzania warstwami i przechowywaniem 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ówobiektów blob nie jest operacjami dostępu, dlatego nie aktualizuje czasu ostatniego dostępu.
Aby zminimalizować wpływ opóźnienia dostępu do odczytu, tylko pierwszy odczyt z ostatnich 24 godzin aktualizuje czas ostatniego dostępu. Kolejne operacje odczytu w tym samym okresie 24-godzinnym nie aktualizują czasu ostatniego dostępu. Jeśli obiekt blob jest modyfikowany między operacjami odczytu, czas ostatniego dostępu jest nowszym z tych 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 z powrotem do gorącego, jeśli po ponownym warstwie jest uzyskiwany dostęp do warstwy chłodnej.
{
"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 odbywa się przez działanie w 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 w wersji REST 2018-11-09 i nowszej lub najnowszej biblioteki klienta magazynu obiektów blob.
Wygasanie danych na podstawie wieku
Oczekuje się, że niektóre dane wygasną w dniach lub miesiącach 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 zostały 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 na 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 istnienia, można włączyć przechowywanie wersji magazynu obiektów blob, aby automatycznie obsługiwać poprzednie wersje obiektu. Możesz utworzyć zasady warstwy lub usunąć poprzednie wersje. Wiek wersji jest określany przez ocenę czasu tworzenia 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 są 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"
]
}
}
}
]
}
Obsługa funkcji
Może to mieć wpływ na obsługę tej funkcji, włączając protokół Data Lake Storage Gen2, sieciowy system plików (NFS) 3.0 lub protokół SSH File Transfer Protocol (SFTP).
Jeśli włączono dowolną z tych funkcji, zobacz Obsługa funkcji usługi Blob Storage na kontach usługi Azure Storage , aby ocenić obsługę tej funkcji.
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 warstwy obiektów blob . Operacje usuwania są bezpłatne. Jednak inne usługi i narzędzia platformy Azure, takie jak Usługa 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 ramach innej kategorii operacji .
Aby uzyskać więcej informacji na temat cen, zobacz Block Blob pricing (Cennik blokowych obiektów blob).
Często zadawane pytania
Utworzono nowe zasady. Dlaczego akcje nie są uruchamiane natychmiast?
Platforma uruchamia zasady cyklu życia raz dziennie. Po skonfigurowaniu zasad uruchomienie niektórych akcji po raz pierwszy może potrwać do 24 godzin.
Jeśli zaktualizuję istniejące zasady, jak długo trwa uruchamianie akcji?
Aktualizacja zasad trwa do 24 godzin. Po wprowadzeniu zasad uruchomienie akcji może potrwać do 24 godzin. W związku z tym wykonanie akcji zasad może potrwać do 48 godzin. Jeśli aktualizacja ma spowodować wyłączenie lub usunięcie reguły, a funkcja enableAutoTierToHotFromCool została użyta, automatyczne tworzenie warstw w warstwie Gorąca nadal będzie miało miejsce. Na przykład ustaw regułę obejmującą funkcję enableAutoTierToHotFromCool na podstawie ostatniego dostępu. Jeśli reguła jest wyłączona/usunięta, a obiekt blob jest obecnie w warstwie Chłodna, a następnie jest dostępny, zostanie przywrócony do warstwy Gorąca, ponieważ jest to stosowane w przypadku dostępu poza zarządzaniem cyklem życia. Obiekt blob nie zostanie następnie przeniesiony z Gorąca na Chłodna, ponieważ reguła zarządzania cyklem życia jest wyłączona/usunięta. Jedynym sposobem zapobiegania autoTierToHotFromCool jest wyłączenie śledzenia czasu ostatniego dostępu.
Ręcznie przywracam zarchiwizowany obiekt blob. Jak mogę zapobiec tymczasowemu przeniesieniu go z powrotem do warstwy Archiwum?
Gdy obiekt blob zostanie przeniesiony z jednej warstwy dostępu do innej, czas ostatniej modyfikacji nie ulegnie zmianie. Jeśli ręcznie przywrócisz zarchiwizowany obiekt blob do warstwy Gorąca, zostanie on przeniesiony z powrotem do warstwy Archiwum przez aparat zarządzania cyklem życia. Wyłącz regułę, która tymczasowo wpływa na ten obiekt blob, aby zapobiec ponownemu archiwizowaniu. Ponownie włącz regułę, gdy obiekt blob można bezpiecznie przenieść z powrotem do warstwy Archiwum. Możesz również skopiować obiekt blob do innej lokalizacji, jeśli będzie on musiał pozostać trwale w warstwie Gorąca lub Chłodna.
Ciąg dopasowania prefiksu obiektu blob nie zastosował zasad do oczekiwanych obiektów blob
Pole dopasowania prefiksu obiektów blob w zasadach jest pełną lub częściową ścieżką obiektów blob używaną w celu dopasowywania obiektów blob, do których mają być stosowane akcje zasad. Ścieżka musi zaczynać się od nazwy kontenera. Jeśli nie określono dopasowania prefiksu, zasady będą stosowane do wszystkich obiektów blob na koncie magazynu. Format ciągu dopasowania prefiksu to [container name]/[blob name].
Pamiętaj o następujących kwestiach dotyczących ciągu dopasowania prefiksu:
- Ciąg dopasowania prefiksu, taki jak container1/ dotyczy wszystkich obiektów blob w kontenerze o nazwie container1. Ciąg dopasowania prefiksu kontener1 bez końcowego znaku ukośnika (/) dotyczy wszystkich obiektów blob we wszystkich kontenerach, w których nazwa kontenera rozpoczyna się od ciągu container1. Prefiks będzie odpowiadał kontenerom o nazwie container11, container1234, container1ab itd.
- Ciąg dopasowania prefiksu kontener1/sub1/ dotyczy wszystkich obiektów blob w kontenerze o nazwie container1 , które zaczynają się od ciągu sub1/. Na przykład prefiks będzie odpowiadał obiektom blob o nazwie container1/sub1/test.txt lub container1/sub1/sub2/test.txt.
- Znak
*gwiazdki jest prawidłowym znakiem w nazwie obiektu blob. Jeśli znak gwiazdki jest używany w prefiksie, prefiks będzie zgodny z obiektami blob z gwiazdką w nazwach. Gwiazdka nie działa jako symbol wieloznaczny. - Znak
?zapytania jest prawidłowym znakiem w nazwie obiektu blob. Jeśli znak zapytania jest używany w prefiksie, prefiks będzie odpowiadał obiektom blob z znakiem zapytania w nazwach. Znak zapytania nie działa jako znak wieloznaczny. - Dopasowanie prefiksu uwzględnia tylko dodatnie porównania logiczne (=). Ujemne porównania logiczne (!=) są ignorowane.
Czy istnieje sposób identyfikowania czasu, w którym będą wykonywane zasady?
Niestety, nie ma możliwości śledzenia czasu, w którym będą wykonywane zasady, ponieważ jest to proces planowania w tle. Jednak platforma będzie uruchamiać zasady raz dziennie.