Optimalizace nákladů pomocí automatické správy životního cyklu dat

Datové sady mají jedinečné životní cykly. Na začátku životního cyklu lidé často přistupují k některým datům. S tím, jak data stárnou, ale potřeba přístupu často výrazně klesá. Některá data zůstávají v cloudu nečinná a po uložení se k nich přistupuje jen zřídka. Platnost některých datových sad vyprší dny nebo měsíce po vytvoření, zatímco jiné datové sady se aktivně čtou a upravují během své životnosti. Správa životního cyklu služby Azure Storage nabízí zásady založené na pravidlech, které můžete použít pro převod dat objektů blob na odpovídající úrovně přístupu nebo k vypršení platnosti dat na konci jejich životního cyklu.

Poznámka

Každá poslední aktualizace času přístupu se účtuje jako "jiná transakce" maximálně každých 24 hodin pro každý objekt, a to i v případě, že se k ní přistupuje 1000krát za den. To je oddělené od poplatků za transakce čtení.

Pomocí zásad správy životního cyklu můžete:

  • Převést objekty blob ze studené na horké okamžitě při přístupu, abyste je optimalizovali z hlediska výkonu.
  • Pokud chcete optimalizovat náklady, převést aktuální verze objektu blob, předchozí verze objektu blob nebo snímky objektů blob na chladnější úroveň úložiště, pokud se k těmto objektům po určitou dobu nepřístupilo nebo se k těmto objektům nepoužilo. V tomto scénáři mohou zásady správy životního cyklu přesouvat objekty z horké do studené, z horké do archivní nebo ze studené do archivní.
  • Odstraňte aktuální verze objektu blob, předchozí verze objektu blob nebo snímky objektů blob na konci jejich životního cyklu.
  • Definujte pravidla, která se mají spouštět jednou denně na úrovni účtu úložiště.
  • Použijte pravidla pro kontejnery nebo podmnožinu objektů blob a jako filtry použijte předpony názvů nebo značky indexu objektů blob .

Představte si scénář, kdy se k datům často přistupuje v počátečních fázích životního cyklu, ale jen občas po dvou týdnech. Kromě prvního měsíce se k datové sadě přistupuje jen zřídka. V tomto scénáři je horké úložiště nejvhodnější v počátečních fázích. Studené úložiště je nejvhodnější pro občasný přístup. Archivní úložiště je nejlepší možnost úrovně po tom, co data stárnou více než měsíc. Přesunutím dat do příslušné úrovně úložiště na základě jejich stáří pomocí pravidel zásad správy životního cyklu můžete navrhnout nejlevnější řešení pro vaše potřeby.

Zásady správy životního cyklu jsou podporované u objektů blob bloku a připojovacích objektů blob v účtech pro obecné účely verze 2, objektech blob bloku úrovně Premium a v účtech služby Blob Storage. Správa životního cyklu nemá vliv na systémové kontejnery, $logs jako jsou kontejnery nebo $web .

Důležité

Pokud datová sada musí být čitelná, nenastavujte zásady pro přesun objektů blob do archivní úrovně. Objekty blob v archivní úrovni se nedají číst, pokud nejsou nejprve dosazovány, což je proces, který může být časově náročný a nákladný. Další informace najdete v tématu Přehled dosazování objektů blob z archivní úrovně.

Definice zásad správy životního cyklu

Zásady správy životního cyklu jsou kolekce pravidel v dokumentu JSON. Následující ukázkový kód JSON ukazuje úplnou definici pravidla:

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

Zásada je kolekce pravidel, jak je popsáno v následující tabulce:

Název parametru Typ parametru Poznámky
rules Pole objektů pravidel V zásadách se vyžaduje aspoň jedno pravidlo. V rámci jedné zásady můžete definovat až 100 pravidel.

Každé pravidlo v rámci zásady má několik parametrů, které jsou popsané v následující tabulce:

Název parametru Typ parametru Poznámky Vyžadováno
name Řetězec Název pravidla může obsahovat až 256 alfanumerických znaků. V názvu pravidla se rozlišují malá a velká písmena. Musí být jedinečný v rámci zásad. Ano
enabled Logická hodnota Volitelná logická hodnota, která umožňuje dočasné zakázání pravidla. Výchozí hodnota je true, pokud není nastavená. Ne
type Hodnota výčtu Aktuální platný typ je Lifecycle. Ano
definition Objekt, který definuje pravidlo životního cyklu Každá definice se skládá ze sady filtrů a sady akcí. Ano

Definice pravidla správy životního cyklu

Každá definice pravidla v rámci zásady obsahuje sadu filtrů a sadu akcí. Sada filtrů omezuje akce pravidla na určitou sadu objektů v kontejneru nebo názvech objektů. Sada akcí použije akce vrstvy nebo odstranění na filtrovanou sadu objektů.

Ukázkové pravidlo

Následující ukázkové pravidlo vyfiltruje účet tak, aby spouštějí akce s objekty, které existují uvnitř sample-container , a začínají na blob1.

  • Vrstvení objektu blob na studenou úroveň 30 dnů po poslední úpravě
  • Vrstvení objektu blob do archivní vrstvy 90 dnů po poslední úpravě
  • Odstranění objektu blob 2 555 dnů (sedm let) od poslední úpravy
  • Odstranit předchozí verze 90 dní po vytvoření
{
  "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"
          ]
        }
      }
    }
  ]
}

Poznámka

Element baseBlob v zásadách správy životního cyklu odkazuje na aktuální verzi objektu blob. Element version odkazuje na předchozí verzi.

Filtry pravidel

Filtry omezují akce pravidla na podmnožinu objektů blob v rámci účtu úložiště. Pokud je definováno více než jeden filtr, logická AND se spustí na všech filtrech.

Filtry zahrnují:

Název filtru Typ filtru Poznámky Je povinné
typy objektů blob Pole předdefinovaných výčtových hodnot. Aktuální verze podporuje blockBlob a appendBlob. Odstranění je podporováno pouze pro appendBlob, úroveň set se nepodporuje. Yes
předponaMatch Pole řetězců pro předpony, které mají být spárovány. Každé pravidlo může definovat až 10 předpon rozlišující malá a velká písmena. Řetězec předpony musí začínat názvem kontejneru. Pokud například chcete pro pravidlo spárovat všechny objekty blob v části https://myaccount.blob.core.windows.net/sample-container/blob1/... , předponaMatch je sample-container/blob1. Pokud nedefinujete prefixMatch, pravidlo se použije pro všechny objekty blob v rámci účtu úložiště. Ne
objekt blobIndexMatch Pole slovníkových hodnot, které se skládají z klíče značky indexu objektů blob a podmínek hodnoty, které se mají shodovat. Každé pravidlo může definovat až 10 podmínek pro značky indexů objektů blob. Pokud například chcete spárovat všechny objekty blob s polem Project = Contoso pro https://myaccount.blob.core.windows.net/ pravidlo, hodnota blobIndexMatch je {"name": "Project","op": "==","value": "Contoso"}. Pokud nedefinujete objekt blobIndexMatch, pravidlo se použije na všechny objekty blob v rámci účtu úložiště. Ne

Další informace o funkci indexu objektů blob spolu se známými problémy a omezeními najdete v tématu Správa a vyhledání dat na Azure Blob Storage s indexem objektů blob.

Akce pravidel

Akce se použijí u filtrovaných objektů blob při splnění podmínky spuštění.

Správa životního cyklu podporuje vrstvení a odstraňování aktuálních verzí, předchozích verzí a snímků objektů blob. Definujte alespoň jednu akci pro každé pravidlo.

Poznámka

V účtu úložiště objektů blob bloku úrovně Premium se ještě nepodporuje vrstvení. U všech ostatních účtů je vrstvení povolené jenom u objektů blob bloku, a ne pro doplňovací objekty blob a objekty blob stránky.

Akce Aktuální verze Snímek Předchozí verze
tierToCool Podporováno pro blockBlob Podporováno Podporováno
enableAutoTierToHotFromCool Podporováno pro blockBlob Nepodporováno Nepodporováno
úroveňNaarchivu Podporováno pro blockBlob Podporováno Podporováno
odstranit1 Podporováno pro blockBlob a appendBlob Podporováno Podporováno

1 Při použití u účtu s povoleným hierarchickým oborem názvů akce odstranění odebere prázdné adresáře. Pokud adresář není prázdný, akce odstranění odebere objekty, které splňují podmínky zásad v rámci prvního 24hodinového cyklu. Pokud má tato akce za následek prázdný adresář, který zároveň splňuje podmínky zásad, odebere se tento adresář během dalšího 24hodinového cyklu atd.

Poznámka

Pokud pro stejný objekt blob definujete více než jednu akci, správa životního cyklu na objekt blob použije nejlevnější akci. Například akce delete je levnější než akce tierToArchive. Akce tierToArchive je levnější než akce tierToCool.

Podmínky spuštění jsou založené na věku. Aktuální verze používají čas poslední změny nebo čas posledního přístupu, předchozí verze používají čas vytvoření verze a snímky objektů blob používají čas vytvoření snímku ke sledování stáří.

Podmínka spuštění akce Hodnota podmínky Description
daysAfterModificationGreaterThan Celočíselná hodnota označující stáří ve dnech Podmínka pro akce s aktuální verzí objektu blob
dnyAfterCreationGreaterThan Celočíselná hodnota označující stáří ve dnech Podmínka pro akce u předchozí verze objektu blob nebo snímku objektu blob
daysAfterLastAccessTimeGreaterThan Celočíselná hodnota označující stáří ve dnech Podmínka pro aktuální verzi objektu blob, když je povolené sledování přístupu
daysAfterLastTierChangeGreaterThan Celočíselná hodnota označující stáří ve dnech po poslední změně úrovně objektu blob Tato podmínka se vztahuje pouze na tierToArchive akce a je možné ji použít pouze s podmínkou daysAfterModificationGreaterThan .

Příklady zásad životního cyklu

Následující příklady ukazují, jak řešit běžné scénáře s pravidly zásad životního cyklu.

Přesun stárnoucí dat na chladnější úroveň

Tento příklad ukazuje, jak převést objekty blob bloku s sample-container/blob1 předponou nebo container2/blob2. Zásada přemísí objekty blob, které se během více než 30 dnů nezměnily, do studeného úložiště a objekty blob, které se neupraví za 90 dnů, na archivní úroveň:

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

Přesun dat na základě času posledního přístupu

Můžete povolit sledování času posledního přístupu, abyste mohli uchovávat záznamy o tom, kdy se objekt blob naposledy načetl nebo zapisuje, a jako filtr pro správu vrstvení a uchovávání dat objektů blob. Informace o tom, jak povolit sledování času posledního přístupu, najdete v tématu Volitelné povolení sledování času přístupu.

Když je povolené sledování času posledního přístupu, vlastnost objektu blob s názvem LastAccessTime se aktualizuje při čtení nebo zápisu objektu blob. Operace získání objektu blob se považuje za operaci přístupu. Získání vlastností objektu blob, získání metadat objektu blob a získání značek objektů blob nejsou operacemi přístupu, a proto neaktualizuje čas posledního přístupu.

Aby se minimalizoval vliv na latenci přístupu ke čtení, aktualizuje se čas posledního přístupu pouze při prvním čtení za posledních 24 hodin. Další čtení ve stejném 24hodinovém období neaktualizuje čas posledního přístupu. Pokud se objekt blob mezi čteními změní, čas posledního přístupu je novější z těchto dvou hodnot.

V následujícím příkladu se objekty blob přesunou do studeného úložiště, pokud se k nim 30 dnů nepřistupuje. Vlastnost enableAutoTierToHotFromCool je logická hodnota, která označuje, jestli se má objekt blob automaticky vrstvit ze studené zpět na horkou, pokud se k němu znovu přistupuje po vrstvení na úroveň studenou.

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

Archivace dat po ingestování

Některá data zůstávají v cloudu nečinná a jsou zřídka (pokud vůbec) přístupná. Následující zásady životního cyklu jsou nakonfigurované tak, aby archivovaly data krátce po jejich ingestci. Tento příklad převede objekty blob bloku v kontejneru s názvem archivecontainer do archivní úrovně. Přechod se provádí tak, že se objekty blob budou provádět 0 dní po času poslední změny.

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

Poznámka

Microsoft doporučuje nahrát objekty blob přímo do archivní úrovně pro zajištění vyšší efektivity. Archivní úroveň můžete zadat v hlavičce x-ms-access-tier operace Put Blob nebo Put Block List . Hlavička x-ms-access-tier je podporovaná ve verzi REST 2018-11-09 a novějších nebo nejnovějších klientských knihovnách úložiště objektů blob.

Vypršení platnosti dat na základě věku

Očekává se, že platnost některých dat vyprší dny nebo měsíce po vytvoření. Zásady správy životního cyklu můžete nakonfigurovat tak, aby platnost dat vypršela odstraněním na základě stáří dat. Následující příklad ukazuje zásadu, která odstraní všechny objekty blob bloku, které se za posledních 365 dnů nezměnily.

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

Odstranění dat pomocí značek indexu objektů blob

Platnost některých dat by měla vypršela jenom v případě, že jsou explicitně označená k odstranění. Zásady správy životního cyklu můžete nakonfigurovat tak, aby vypršela platnost dat označených atributy klíč/hodnota indexu objektů blob. Následující příklad ukazuje zásadu, která odstraní všechny objekty blob bloku označené pomocí Project = Contoso. Další informace o indexu objektů blob najdete v tématu Správa a vyhledání dat v Azure Blob Storage pomocí indexu objektů blob.

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

Správa předchozích verzí

U dat, která se v průběhu svého životního cyklu pravidelně upravují, můžete povolit správu verzí služby Blob Storage, aby se automaticky udržovaly předchozí verze objektu. Můžete vytvořit zásadu pro vrstvení nebo odstranění předchozích verzí. Stáří verze se určuje vyhodnocením času vytvoření verze. Toto pravidlo zásad přesune předchozí verze v rámci kontejneru activedata , které jsou starší 90 dnů po vytvoření verze, na studenou úroveň a odstraní předchozí verze, které jsou starší 365 dnů.

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

Podpora funkcí

Podpora této funkce může být ovlivněna povolením Data Lake Storage Gen2, protokolu NFS (Network File System) 3.0 nebo protokolu SSH File Transfer Protocol (SFTP).

Pokud jste některou z těchto funkcí povolili, přečtěte si téma Podpora funkcí Blob Storage v účtech Azure Storage , kde můžete posoudit podporu této funkce.

Dostupnost a ceny v jednotlivých oblastech

Funkce správy životního cyklu je dostupná ve všech oblastech Azure.

Zásady správy životního cyklu jsou bezplatné. Zákazníkům se účtují standardní provozní náklady pro nastavení volání rozhraní API úrovně objektů blob . Operace odstranění jsou zdarma. Za operace spravované prostřednictvím zásad životního cyklu se ale můžou účtovat jiné služby a nástroje Azure, jako je Microsoft Defender pro službu Storage.

Každá aktualizace času posledního přístupu k objektu blob se účtuje v kategorii ostatních operací .

Další informace o cenách najdete v tématu Ceny objektů blob bloku.

Časté otázky

Vytvořil(a) jsem novou zásadu. Proč se akce nespustí okamžitě?

Platforma spouští zásady životního cyklu jednou denně. Jakmile zásadu nakonfigurujete, může trvat až 24 hodin, než se uplatní. Jakmile zásady platí, může první spuštění některých akcí trvat až 24 hodin.

Pokud aktualizuji existující zásadu, jak dlouho trvá, než se akce spustí?

Uplatnění aktualizované zásady trvá až 24 hodin. Když se zásada uplatní, může trvat až 24 hodin, než se akce spustí. Akce zásad proto mohou trvat až 48 hodin. Pokud má aktualizace zakázat nebo odstranit pravidlo a byla použita možnost enableAutoTierToHotFromCool, automatické vrstvení na horkou úroveň bude i nadále probíhat. Můžete například nastavit pravidlo zahrnující enableAutoTierToHotFromCool na základě posledního přístupu. Pokud je pravidlo zakázané nebo odstraněné a objekt blob je aktuálně ve studeném stavu a pak se k němu přistupuje, přesune se zpět na horkou, protože se použije u přístupu mimo správu životního cyklu. Objekt blob se pak nepřesune z horkého do studeného, protože pravidlo správy životního cyklu je zakázané nebo odstraněné. Jediným způsobem, jak zabránit funkci autoTierToHotFromCool, je vypnout sledování času posledního přístupu.

Dosazování archivovaného objektu blob. Návody zabránit dočasnému přesunutí zpět do archivní úrovně?

Pokud pro účet úložiště platí zásady správy životního cyklu, může dosazování objektu blob změnou jeho úrovně vést ke scénáři, kdy zásady životního cyklu přesunou objekt blob zpět do archivní úrovně. K tomu může dojít v případě, že čas poslední změny, čas vytvoření nebo čas posledního přístupu překročí prahovou hodnotu nastavenou pro zásadu. Existují tři způsoby, jak tomu zabránit:

  • Přidejte podmínku daysAfterLastTierChangeGreaterThan do akce zásady tierToArchive. Tato podmínka platí jenom pro čas poslední změny. Viz Použití zásad správy životního cyklu k archivaci objektů blob.

  • Zakažte pravidlo, které dočasně ovlivňuje tento objekt blob, aby se zabránilo jeho opětovné archivaci. Až bude možné objekt blob bezpečně přesunout zpět do archivní úrovně, znovu toto pravidlo povolte.

  • Pokud objekt blob musí trvale zůstat na horké nebo studené úrovni, zkopírujte ho do jiného umístění, kde se zásady správy životního cyklu nepoužívají.

Řetězec shody předpony objektu blob nepoužádal zásadu na očekávané objekty blob.

Pole shody předpony objektu blob zásad obsahuje úplnou nebo částečnou cestu k objektu blob, která se používá k vyhledání shodných objektů blob, na které se mají použít akce zásad. Cesta musí začínat názvem kontejneru. Pokud není zadaná žádná shoda předpony, použijí se zásady na všechny objekty blob v daném účtu úložiště. Formát řetězce shody předpony je [container name]/[blob name].

Mějte na paměti následující body týkající se řetězce shody předpony:

  • Řetězec shody předpony , jako je container1/ , se vztahuje na všechny objekty blob v kontejneru s názvem container1. Předpona odpovídající řetězci container1 bez koncového znaku lomítka (/) se vztahuje na všechny objekty blob ve všech kontejnerech, kde název kontejneru začíná řetězcem container1. Předpona se bude shodovat s kontejnery s názvy container11, container1234, container1ab atd.
  • Řetězec shody předpony container1/sub1/ se vztahuje na všechny objekty blob v kontejneru s názvem container1 , které začínají řetězcem sub1/. Například předpona bude odpovídat objektům blob s názvem container1/sub1/test.txt nebo container1/sub1/sub2/test.txt.
  • Hvězdička * je platným znakem v názvu objektu blob. Pokud se v předponě používá hvězdička, bude předpona odpovídat objektům blob s hvězdičkou v jejich názvech. Hvězdička nefunguje jako zástupný znak.
  • Znak ? otazníku je platným znakem v názvu objektu blob. Pokud se v předponě použije znak otazníku, bude předpona odpovídat objektům blob s otazníkem v jejich názvech. Otazník nefunguje jako zástupný znak.
  • Shoda předpon bere v úvahu pouze kladná (=) logická porovnání. Záporná logická porovnání (!=) se ignorují.

Existuje způsob, jak identifikovat čas, kdy se zásady budou provádět?

Bohužel neexistuje způsob, jak sledovat čas, kdy se zásada spustí, protože se jedná o proces plánování na pozadí. Platforma ale bude tyto zásady spouštět jednou denně.

Další kroky