Költségek optimalizálása az adatéletciklus automatikus kezelésével
Az Azure Blob Storage életciklus-kezelése egy szabályalapú szabályzatot kínál, amellyel a blobadatok áttérhetnek a megfelelő hozzáférési szintekre, vagy az adatéletciklus végén lejárhatnak az adatok.
Az életciklus-kezelési szabályzattal a következőt teheti:
- A teljesítmény optimalizálása érdekében a blobokat azonnal át kell váltani a ritka elérésűről a gyakori elérésűre.
- A blobok aktuális verzióit, a blob korábbi verzióit vagy a blob pillanatképeit egy hűvösebb tárolási szintre válthatja, ha ezek az objektumok egy ideje nem érhetők el vagy módosultak, a költségek optimalizálása érdekében.
- Törölje a blobok aktuális verzióit, a blob korábbi verzióit vagy a blob pillanatképeit az életciklusuk végén.
- Szabályok alkalmazása egy teljes tárfiókra, tárolók kijelölésére vagy blobok egy részhalmazára névelőtagok vagy blobindexcímkék szűrőként való használatával.
Tipp.
Bár az életciklus-kezelés segítségével egyetlen fiók rétegei között helyezheti át az adatokat, a tárolási feladatokkal ezt a feladatot több fiókra kiterjedő skálázható skálázva hajthatja végre. A tárolási feladat az Azure Storage Actionsben elérhető erőforrás; egy kiszolgáló nélküli keretrendszer, amellyel több tárfiókban több millió objektumon hajthat végre gyakori adatműveleteket. További információ: Mi az Azure Storage Actions?
Az életciklus-kezelési szabályzatok a blokkblobok és a hozzáfűző blobok esetében támogatottak az általános célú v2, a prémium szintű blokkblobok és a blokkblob-tárfiókok esetén. Az életciklus-felügyelet nincs hatással a rendszertárolókra, például a tárolókra$logs.$web
Fontos
Ha egy adatkészletnek olvashatónak kell lennie, ne állítson be házirendet a blobok archiválási szintre való áthelyezéséhez. Az archív szinten lévő blobok csak akkor olvashatók, ha először rehidratálják őket, ami időigényes és költséges folyamat lehet. További információ: A blob rehidratációjának áttekintése az archív rétegből. Ha egy adatkészletet gyakran kell olvasni, ne állítson be olyan házirendet, amely a blobokat a ritka vagy a ritka elérésű szintekre helyezi át, mivel ez magasabb tranzakciós költségeket eredményezhet.
Költségek optimalizálása az adatéletciklus kezelésével
Az adathalmazok egyedi életciklusokkal rendelkeznek. Az életciklus korai szakaszában az emberek gyakran férnek hozzá bizonyos adatokhoz. A hozzáférés iránti igény azonban gyakran drasztikusan csökken az adatok életkorának megfelelően. Egyes adatok tétlenek maradnak a felhőben, és ritkán férnek hozzá a tárolás után. Egyes adathalmazok a létrehozás után napokkal vagy hónapokkal lejárnak, míg más adatkészletek aktívan olvashatók és módosíthatók az egész élettartamuk során.
Vegyünk egy olyan forgatókönyvet, amelyben az adatok gyakran elérhetők az életciklus korai szakaszában, de csak alkalmanként két hét után. Az első hónap után az adatkészlet ritkán érhető el. Ebben a forgatókönyvben a gyakori elérésű tárolás a legjobb a korai szakaszokban. A ritka elérésű tárolás az alkalmi hozzáféréshez a legmegfelelőbb. Az archív tárolás a legjobb rétegzési lehetőség, miután az adatok több mint egy hónapig öregednek. Az adatoknak az életciklus-kezelési szabályzat szabályaival meghatározott életkora alapján a megfelelő tárolási szintre való áthelyezésével a legkevésbé költséges megoldást tervezheti meg az igényeinek megfelelően.
Életciklus-felügyeleti szabályzat definíciója
Az életciklus-felügyeleti szabályzat egy JSON-dokumentumban lévő szabályok gyűjteménye. Az alábbi JSON-minta egy teljes szabálydefiníciót mutat be:
{
"rules": [
{
"name": "rule1",
"enabled": true,
"type": "Lifecycle",
"definition": {...}
},
{
"name": "rule2",
"type": "Lifecycle",
"definition": {...}
}
]
}
A szabályzatok szabályok gyűjteményei, az alábbi táblázatban leírtak szerint:
| Paraméter neve | Paramétertípus | Jegyzetek |
|---|---|---|
rules |
Szabályobjektumok tömbje | Egy szabályzatban legalább egy szabályra szükség van. Egy szabályzatban legfeljebb 100 szabály határozható meg. |
A szabályzat minden szabálya több paramétert tartalmaz, ezeket az alábbi táblázatban ismertetjük:
| Paraméter neve | Paramétertípus | Jegyzetek | Kötelező |
|---|---|---|---|
name |
Sztring | A szabálynevek legfeljebb 256 alfanumerikus karaktert tartalmazhatnak. A szabály neve megkülönbözteti a kis- és nagybetűk nevét. A szabályzaton belül egyedinek kell lennie. | Igaz |
enabled |
Logikai | Nem kötelező logikai érték, amely lehetővé teszi egy szabály ideiglenes letiltásának engedélyezését. Az alapértelmezett érték igaz, ha nincs beállítva. | Hamis |
type |
Enumerálási érték | Az aktuális érvényes típus a következő Lifecycle: . |
Igaz |
definition |
Az életciklus-szabályt meghatározó objektum | Minden definíció egy szűrőkészletből és egy műveletkészletből áll. | Igaz |
Életciklus-felügyeleti szabály definíciója
A szabályzatok minden szabálydefiníciója tartalmaz egy szűrőkészletet és egy műveletkészletet. A szűrőkészlet korlátozza a szabályműveleteket egy tárolón vagy objektumnéven belüli bizonyos objektumokra. A műveletkészlet a réteg- vagy törlési műveleteket alkalmazza a szűrt objektumkészletre.
Mintaszabály
Az alábbi mintaszabály szűri a fiókot, hogy sample-container a belső objektumokon futtassa a műveleteket, és kezdje a következővel blob1:
- Réteg blob a ritka elérésű réteghez 30 nappal a legutóbbi módosítás után
- Réteg blob az utolsó módosítás után 90 nappal archiválja a réteget
- Blob törlése 2555 nap (hét év) a legutóbbi módosítás után
- Korábbi verziók törlése 90 nappal a létrehozás után
{
"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"
]
}
}
}
]
}
Feljegyzés
Az életciklus-felügyeleti szabályzat baseBlob eleme egy blob aktuális verziójára hivatkozik. A verzióelem egy korábbi verzióra hivatkozik.
Szabályszűrők
A szűrők a tárfiókban lévő blobok egy részhalmazára korlátozzák a szabályműveleteket. Ha egynél több szűrő van definiálva, egy logikai AND fut az összes szűrőn. Szűrővel megadhatja, hogy mely blobokat vegye fel. A szűrő nem adja meg, hogy mely blobokat zárja ki.
A szűrők a következők:
| Szűrő neve | Szűrő típusa | Jegyzetek | Kötelező |
|---|---|---|---|
| blobTypes | Előre definiált enumerálási értékek tömbje. | Az aktuális kiadás támogatja blockBlob és appendBlob. Csak a Törlés művelet támogatott appendBlob; A réteg beállítása nem támogatott. |
Igen |
| prefixMatch | Az illesztendő előtagok sztringjeinek tömbje. Minden szabály legfeljebb 10 kis- és nagybetűs előtagot definiálhat. Az előtagsztringeknek egy tároló nevével kell kezdődniük. Ha például az összes blobot https://myaccount.blob.core.windows.net/sample-container/blob1/...meg szeretné egyezni, adja meg azMatch előtagot sample-container/blob1. Ez a szűrő egyezik a mintatároló összes blobjával, amelynek a neve blob1-vel kezdődik.. |
Ha nem definiálja azMatch előtagot, a szabály a tárfiókon belüli összes blobra vonatkozik. Az előtag-sztringek nem támogatják a helyettesítő karakterek egyeztetését. Az olyan karaktereket, mint például * a ? sztringkonstansok, és a rendszer sztringkonstansként kezeli. |
Nem |
| blobIndexMatch | A szótárértékek tömbje, amely a blobindexcímkekulcsból és az egyeztetendő értékfeltételekből áll. Minden egyes szabály legfeljebb 10 blobindexcímke-feltételt definiálhat. Ha például az összes blobot Project = Contoso egy szabály alá https://myaccount.blob.core.windows.net/ szeretné illeszteni, akkor a blobIndexMatch a .{"name": "Project","op": "==","value": "Contoso"} |
Ha nem definiálja a BlobIndexMatch függvényt, a szabály a tárfiókban lévő összes blobra vonatkozik. | Nem |
Ha többet szeretne megtudni a blobindex funkcióról és az ismert problémákról és korlátozásokról, olvassa el az Azure Blob Storage-adatok kezelése és keresése blobindexekkel című témakört.
Szabályműveletek
A rendszer műveleteket alkalmaz a szűrt blobokra, ha a futtatási feltétel teljesül.
Az életciklus-felügyelet támogatja az aktuális verziók, korábbi verziók és blob pillanatképek rétegzését és törlését. Minden szabályhoz adjon meg legalább egy műveletet.
Feljegyzés
A rétegzés még nem támogatott egy prémium szintű blokkblobtárfiókban. Az összes többi fiók esetében a rétegzés csak blokkblobokon engedélyezett, hozzáfűző és oldalblobok esetében nem.
| Művelet | Aktuális verzió | Pillanatkép | Korábbi verziók |
|---|---|---|---|
| tierToCool | Támogatottak: blockBlob |
Támogatott | Támogatott |
| tierToCold | Támogatottak: blockBlob |
Támogatott | Támogatott |
| enableAutoTierToHotFromCool1 | Támogatottak: blockBlob |
Nem támogatott | Nem támogatott |
| tierToArchive4 | Támogatottak: blockBlob |
Támogatott | Támogatott |
| törlés2,3 | Támogatott és blockBlobappendBlob |
Támogatott | Támogatott |
1 A enableAutoTierToHotFromCool művelet csak akkor érhető el, ha a daysAfterLastAccessTimeGreaterThan futtatási feltételt használja. Ezt a feltételt a következő táblázatban ismertetjük.
2 Ha hierarchikus névtérrel rendelkező fiókra van alkalmazva, a törlési művelet eltávolítja az üres könyvtárakat. Ha a címtár nem üres, akkor a törlési művelet eltávolítja azokat az objektumokat, amelyek megfelelnek a szabályzat feltételeinek az első életciklus-végrehajtási ciklusban. Ha ez a művelet egy üres könyvtárat eredményez, amely szintén megfelel a szabályzat feltételeinek, akkor a következő végrehajtási ciklusban a címtár el lesz távolítva, és így tovább.
3 Az életciklus-felügyeleti szabályzat csak akkor törli a blob aktuális verzióját, ha az adott blobhoz társított korábbi verziók vagy pillanatképek nem törlődnek. Ha a tárfiókban lévő blobok korábbi verziókkal vagy pillanatképekkel rendelkeznek, akkor az előző verziókat és pillanatképeket is tartalmaznia kell, amikor a szabályzat részeként törlési műveletet ad meg.
4 Csak az LRS-hez, GRS-hez vagy RA-GRS-hez konfigurált tárfiókok támogatják a blobok archiválási szintre való áthelyezését. Az archív réteg nem támogatott ZRS-, GZRS- vagy RA-GZRS-fiókok esetében. Ez a művelet a fiókhoz konfigurált redundancia alapján lesz listázva.
Feljegyzés
Ha több műveletet határoz meg ugyanazon a blobon, az életciklus-felügyelet a legkevésbé költséges műveletet alkalmazza a blobra. A művelet delete például olcsóbb, mint a művelet tierToArchive. A művelet tierToArchive olcsóbb, mint a művelet tierToCool.
A futtatási feltételek az életkoron alapulnak. Az aktuális verziók az utolsó módosítás időpontját vagy a legutóbbi hozzáférési időt használják, a korábbi verziók a verziólétrehozás idejét, a blob-pillanatképek pedig a pillanatkép létrehozásának idejét használják az életkor nyomon követéséhez.
| Műveletfuttatási feltétel | Feltétel értéke | Leírás |
|---|---|---|
| daysAfterModificationGreaterThan | Az életkort napokban kifejező egész szám | A blob aktuális verzióján végzett műveletek feltétele |
| daysAfterCreationGreaterThan | Az életkort napokban kifejező egész szám | A blob vagy blob pillanatképének aktuális vagy korábbi verzióján végzett műveletek feltétele |
| daysAfterLastAccessTimeGreaterThan1 | Az életkort napokban kifejező egész szám | A blob aktuális verziójának feltétele, ha engedélyezve van a hozzáférés-követés |
| daysAfterLastTierChangeGreaterThan | Egész szám, amely a blobszint legutóbbi változási idejét követő napokban jelzi az életkort | A rehidratált blobok minimális időtartama meleg, ritka elérésű vagy hideg szinten marad, mielőtt visszakerülnek az archív szintre. Ez a feltétel csak a műveletekre tierToArchive vonatkozik. |
1 Ha az utolsó hozzáférési idő nyomon követése nincs engedélyezve, a daysAfterLastAccessTimeGreaterThan a blob tulajdonsága LastAccessTime helyett az életciklus-szabályzat engedélyezésének dátumát használja. Ezt a dátumot akkor is használja a rendszer, ha a LastAccessTime tulajdonság null értékű. A legutóbbi hozzáférési idő nyomon követésével kapcsolatos további információkért lásd : Adatok áthelyezése a legutóbb elért idő alapján.
Életciklus-szabályzat fut
Egy életciklus-szabályzat konfigurálása vagy szerkesztése akár 24 órát is igénybe vehet, amíg a módosítások érvénybe lépnek, és az első végrehajtás elindul. A szabályzatműveletek végrehajtásához szükséges idő a kiértékelt és végrehajtott blobok számától függ.
Ha letilt egy szabályzatot, akkor nem lesznek új szabályzatfuttatások ütemezve, de ha egy futtatás már folyamatban van, a futtatás addig folytatódik, amíg befejeződik, és a futtatáshoz szükséges műveletekért díjat számítunk fel. Lásd: Regionális rendelkezésre állás és díjszabás.
LifecyclePolicyCompleted (befejezett életciklus-szabályzat) esemény
Az életciklus-felügyeleti szabályzatok által meghatározott műveletek végrehajtásakor a rendszer LifecyclePolicyCompleted eseményt hoz létre. A szabályzatdefinícióban szereplő minden művelethez megjelenik egy összefoglaló szakasz. Az alábbi json egy szabályzathoz tartozó példaeseményt LifecyclePolicyCompleted mutat be. Mivel a szabályzatdefiníció tartalmazza a delete, tierToCool, tierToColdés tierToArchive a műveleteket, mindegyikhez megjelenik egy összefoglaló szakasz.
{
"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"
}
Az alábbi táblázat az esemény sémáját LifecyclePolicyCompleted ismerteti.
| Mező | Típus | Leírás |
|---|---|---|
| scheduleTime | húr | Az életciklus-szabályzat ütemezésének időpontja |
| deleteSummary | vektor<bájt> | A törlési műveletre ütemezett blobok eredményeinek összegzése |
| tierToCoolSummary | vektor<bájt> | A rétegről a ritka elérésűre ütemezett blobok eredményeinek összegzése |
| tierToColdSummary | vektor<bájt> | A réteg-hideg művelethez ütemezett blobok eredményeinek összegzése |
| tierToArchiveSummary | vektor<bájt> | A rétegről archív műveletre ütemezett blobok eredményeinek összegzése |
Példák életciklus-szabályzatokra
Az alábbi példák bemutatják, hogyan kezelhetők a gyakori forgatókönyvek életciklus-szabályzatszabályokkal.
Öregedő adatok áthelyezése egy hűvösebb szintre
Ez a példa bemutatja, hogyan lehet áttűnni a blokkblobok előtaggal sample-container/blob1 vagy container2/blob2. A szabályzat azokat a blobokat váltja át, amelyeket 30 nap alatt nem módosítottak a ritka elérésű tárolásra, és a blobok 90 nap alatt nem lettek módosítva az archív szintre:
{
"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 }
}
}
}
}
]
}
Adatok áthelyezése az utolsó hozzáférés ideje alapján
A legutóbbi hozzáférési idő nyomon követésével rögzítheti, hogy a blob mikor olvasható vagy íródott utoljára, és szűrőként kezelje a blobadatok rétegzését és megőrzését. A legutóbbi hozzáférési idő nyomon követésének engedélyezéséről további információt a hozzáférési idő nyomon követésének opcionális engedélyezésével kapcsolatban talál.
Ha engedélyezve van az utolsó hozzáférési idő nyomon követése, a blobok olvasása vagy írásakor a rendszer frissíti a meghívott LastAccessTime blobtulajdonságot. A Blob lekérése művelet hozzáférési műveletnek minősül. A Blob tulajdonságainak lekérése, a Blob-metaadatok lekérése és a Blobcímkék lekérése nem hozzáférési műveletek, ezért nem frissíti az utolsó hozzáférési időt.
Ha engedélyezve van az utolsó hozzáférési idő nyomon követése, az életciklus-felügyelet annak meghatározására használjaLastAccessTime, hogy teljesül-e a napok futási feltételeAfterLastAccessTimeGreaterThan. Az életciklus-felügyelet az életciklus-szabályzat engedélyezésének dátumát használja a következő esetek helyett LastAccessTime :
A blob tulajdonságának értéke
LastAccessTimenull értékű.Feljegyzés
A
lastAccessedOnblob tulajdonsága null értékű, ha egy blob nem érhető el a legutóbbi hozzáférési idő nyomon követése óta.A legutóbbi hozzáférési idő nyomon követése nincs engedélyezve.
Az olvasási hozzáférés késésére gyakorolt hatás minimalizálása érdekében csak az elmúlt 24 óra első olvasása frissíti az utolsó hozzáférési időt. Az ugyanabban a 24 órás időszakban lévő későbbi olvasások nem frissítik az utolsó hozzáférési időt. Ha egy blob módosul az olvasások között, az utolsó hozzáférési idő a két érték közül a legutóbbi.
Az alábbi példában a blobok át lesznek helyezve a ritka elérésű tárolóba, ha 30 napja nem fértek hozzá. A enableAutoTierToHotFromCool tulajdonság egy logikai érték, amely azt jelzi, hogy a blobokat automatikusan vissza kell-e rétegztetni a ritka elérésűről a gyakori elérésűre, ha a rétegzés után ismét hozzáfér a ritka elérésűhöz.
Tipp.
Ha egy blobot áthelyeznek a ritka elérésű szintre, majd automatikusan visszahelyeznek 30 nap eltelte előtt, a rendszer korai törlési díjat számít fel. A tulajdonság beállítása enablAutoTierToHotFromCool előtt mindenképpen elemezze az adatok hozzáférési mintáit, hogy csökkentse a váratlan díjakat.
{
"enabled": true,
"name": "last-accessed-thirty-days-ago",
"type": "Lifecycle",
"definition": {
"actions": {
"baseBlob": {
"enableAutoTierToHotFromCool": true,
"tierToCool": {
"daysAfterLastAccessTimeGreaterThan": 30
}
}
},
"filters": {
"blobTypes": [
"blockBlob"
],
"prefixMatch": [
"mylifecyclecontainer/log"
]
}
}
}
Adatok archiválása a betöltés után
Egyes adatok tétlenek maradnak a felhőben, és ritkán, ha valaha is hozzáférnek. A következő életciklus-szabályzat úgy van konfigurálva, hogy az adatok röviddel a betöltés után archiválva legyenek. Ez a példa az archív rétegbe elnevezett archivecontainer tároló blobjait blokkolja. Az áttűnés úgy történik, hogy a legutóbb módosított idő után 0 nappal blobokon lép fel.
{
"rules": [
{
"name": "archiveRule",
"enabled": true,
"type": "Lifecycle",
"definition": {
"filters": {
"blobTypes": [ "blockBlob" ],
"prefixMatch": [ "archivecontainer" ]
},
"actions": {
"baseBlob": {
"tierToArchive": {
"daysAfterModificationGreaterThan": 0
}
}
}
}
}
]
}
Feljegyzés
A Microsoft azt javasolja, hogy a nagyobb hatékonyság érdekében töltse fel a blobokat közvetlenül az archív szintre. Az archív szintet az x-ms-access-tier fejlécben adhatja meg a Put Blob vagy a Put Block List műveletben. Az x-ms-access-tier fejléc a REST 2018-11-09-es verziójával és az újabb vagy a legújabb Blob Storage-ügyfélkódtárakkal támogatott.
Adatok lejárata az életkor alapján
Egyes adatok várhatóan napokkal vagy hónappal a létrehozás után lejárnak. Az életciklus-kezelési szabályzatot úgy konfigurálhatja, hogy az adatok az adat életkora alapján törléssel lejárjanak. Az alábbi példa egy olyan szabályzatot mutat be, amely törli az összes olyan blokkblobot, amelyet az elmúlt 365 napban nem módosítottak.
{
"rules": [
{
"name": "expirationRule",
"enabled": true,
"type": "Lifecycle",
"definition": {
"filters": {
"blobTypes": [ "blockBlob" ]
},
"actions": {
"baseBlob": {
"delete": { "daysAfterModificationGreaterThan": 365 }
}
}
}
}
]
}
Adatok törlése blobindexcímkékkel
Egyes adatok csak akkor legyenek lejártak, ha kifejezetten törlésre vannak megjelölve. Az életciklus-felügyeleti szabályzatot úgy konfigurálhatja, hogy lejárjanak a blobindex-kulcs/érték attribútumokkal címkézett adatok. Az alábbi példa egy szabályzatot mutat be, amely törli a címkével ellátott összes blokkblobot Project = Contoso. A blobindexről további információt az Azure Blob Storage-adatok kezelése és keresése blobindexkel című témakörben talál.
{
"rules": [
{
"enabled": true,
"name": "DeleteContosoData",
"type": "Lifecycle",
"definition": {
"actions": {
"baseBlob": {
"delete": {
"daysAfterModificationGreaterThan": 0
}
}
},
"filters": {
"blobIndexMatch": [
{
"name": "Project",
"op": "==",
"value": "Contoso"
}
],
"blobTypes": [
"blockBlob"
]
}
}
}
]
}
Korábbi verziók kezelése
A teljes élettartama során rendszeresen módosított és elérhető adatok esetében engedélyezheti a Blob Storage verziószámozását az objektumok korábbi verzióinak automatikus karbantartásához. Létrehozhat egy szabályzatot a korábbi verziók rétegzéséhez vagy törléséhez. A verzió korát a verziólétrehozási idő kiértékelésével határozzuk meg. Ez a szabályzatszabály a verziólétrehozás után 90 napos vagy annál régebbi korábbi verziókat activedata helyezi át a ritka elérésű szintre, és törli a 365 napos vagy annál régebbi korábbi verziókat.
{
"rules": [
{
"enabled": true,
"name": "versionrule",
"type": "Lifecycle",
"definition": {
"actions": {
"version": {
"tierToCool": {
"daysAfterCreationGreaterThan": 90
},
"delete": {
"daysAfterCreationGreaterThan": 365
}
}
},
"filters": {
"blobTypes": [
"blockBlob"
],
"prefixMatch": [
"activedata/"
]
}
}
}
]
}
Regionális rendelkezésre állás és díjszabás
Az életciklus-felügyeleti funkció minden Azure-régióban elérhető.
Az életciklus-felügyeleti szabályzatok ingyenesek. Az ügyfeleknek a Blob Tier API-hívásokhoz tartozó szokásos üzemeltetési költségekért kell fizetnie. A törlési műveletek ingyenesek. Az életciklus-szabályzattal felügyelt műveletekért azonban más Azure-szolgáltatások és segédprogramok, például a Microsoft Defender for Storage is díjat számíthatnak fel.
A blob utolsó hozzáférési idejének minden egyes frissítését a másik műveleti kategóriában számítjuk fel. Minden utolsó hozzáférési idő frissítését objektumonként legfeljebb 24 óránként kell "más tranzakcióként" fizetni, még akkor is, ha egy nap 1000 alkalommal éri el. Ez eltér az olvasási tranzakciók díjától.
A díjszabással kapcsolatos további információkért tekintse meg a Blokkblobok díjszabását.
Ismert problémák és korlátozások
A rétegzés még nem támogatott egy prémium szintű blokkblobtárfiókban. Az összes többi fiók esetében a rétegzés csak blokkblobokon engedélyezett, hozzáfűző és oldalblobok esetében nem.
Az életciklus-felügyeleti szabályzatot teljes egészében kell olvasni vagy írni. A részleges frissítések nem támogatottak.
Minden szabály legfeljebb 10 kis- és nagybetűs előtaggal és legfeljebb 10 blobindexcímkefeltételsel rendelkezhet.
Az életciklus-felügyeleti szabályzatok nem módosíthatják a titkosítási hatókört használó blobok szintjét.
Az életciklus-felügyeleti házirendek törlési művelete nem működik a nem módosítható tárolóban lévő blobokkal. Nem módosítható szabályzattal objektumok hozhatók létre és olvashatók, de nem módosíthatók vagy törölhetők. További információ: Üzlet szempontjából kritikus blobadatok tárolása nem módosítható tárterülettel.
Gyakori kérdések (GYIK)
Lásd az életciklus-kezeléssel kapcsolatos gyakori kérdéseket.