Költségek optimalizálása az adatéletciklus automatikus kezelésével
Az adathalmazok egyedi életciklusokkal rendelkeznek. Az életciklus korai szakaszában a felhasználók 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 adathalmazok aktívan olvashatók és módosíthatók az élettartamuk során. Az Azure Storage életciklus-felügyelete egy szabályalapú szabályzatot kínál, amellyel a blobadatokat át lehet váltani a megfelelő hozzáférési szintekre, vagy le lehet járni az adatokat az adatéletciklus végén.
Az életciklus-felügyeleti szabályzattal a következőt teheti:
- A blobok a hozzáférésük után azonnal áttérnek a ritka elérésűről a gyakori elérésűre, hogy optimalizálva legyenek a teljesítményre.
- A blobok aktuális verzióit, a blobok 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. Ebben a forgatókönyvben az életciklus-felügyeleti szabályzat áthelyezheti az objektumokat gyakori elérésűről ritka elérésűre, gyakori elérésűről archívra vagy ritka elérésűről archiválásra.
- Törölje a blobok aktuális verzióit, a blobok korábbi verzióit vagy a blobok pillanatképeit az életciklusuk végén.
- A tárfiók szintjén naponta egyszer futtatandó szabályok meghatározása.
- Szabályok alkalmazása tárolókra vagy blobok egy részhalmazára névelőtagok vagy blobindexcímkék szűrőként való használatával.
Vegyünk egy olyan forgatókönyvet, amelyben az adatok gyakran, az életciklus korai szakaszaiban, de csak alkalmanként, két hét elteltével érhetők el. Az első hónap után az adathalmaz 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 szint az egy hónapnál idősebb adatok után. Ha az adatokat az életkora alapján a megfelelő tárolási szintre helyezi át az életciklus-felügyeleti szabályzat szabályaival, megtervezheti a legkevésbé költséges megoldást az igényeinek megfelelően.
Az életciklus-felügyeleti szabályzatok a blokkblobok és hozzáfűző blobok esetében támogatottak az általános célú v2- és prémium szintű blokkblobokban, valamint a Blob Storage-fiókokban. 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 szabályzatot a blobok archív 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 blobrehidratálás áttekintése az archív szintről.
Életciklus-felügyeleti szabályzat definíciója
Az életciklus-felügyeleti szabályzat egy JSON-dokumentum szabályainak 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 definiálható. |
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álynév 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 a szabályműveleteket egy tárolón vagy objektumnéven belüli objektumkészletre korlátozza. 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 a belső objektumokon sample-container végrehajtott műveletek futtatásához, és a következővel blob1kezdődik:
- Blob rétegből ritka elérésű rétegbe a legutóbbi módosítás után 30 nappal
- Blob rétegzésére az utolsó módosítás után 90 nappal archiválni
- Blob törlése a legutóbbi módosítás után 2555 nap (hét év) 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
},
"delete": {
"daysAfterModificationGreaterThan": 2555
}
}
},
"filters": {
"blobTypes": [
"blockBlob"
],
"prefixMatch": [
"sample-container/blob1"
]
}
}
}
]
}
Megjegyzé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 szabályműveleteket a tárfiókban lévő blobok egy részhalmazára korlátozzák. Ha egynél több szűrő van definiálva, minden szűrőn logikai AND futtatás történik.
A szűrők a következők:
| Szűrő neve | Szűrő típusa | Jegyzetek | Kötelező |
|---|---|---|---|
| blobTypes | Előre definiált számértékek tömbje. | A jelenlegi kiadás támogatja blockBlob és appendBlob. Csak a törlés támogatott appendBlob, a beállított szint nem támogatott. |
Yes |
| prefixMatch | Az illesztendő előtagok sztringjeinek tömbje. Minden szabály legfeljebb 10 kis- és nagybetűt megkülönböztető előtagot definiálhat. Az előtagsztringnek tárolónévvel kell kezdődnie. Ha például egy szabályhoz tartozó összes blobot https://myaccount.blob.core.windows.net/sample-container/blob1/... meg szeretné egyezni, azMatch előtag a következő sample-container/blob1: . |
Ha nem definiálja a prefixMatch előtagot, a szabály a tárfiókban lévő összes blobra vonatkozik. | No |
| blobIndexMatch | Szótárértékek tömbje, amely a blobindex címkekulcsából és az egyeztetendő értékfeltételekből áll. Minden szabály legfeljebb 10 blobindexcímke feltételt definiálhat. Ha például az összes olyan blobot szeretné egyezni, amely Project = Contosohttps://myaccount.blob.core.windows.net/ alá tartozik egy szabály, a blobIndexMatch a következő {"name": "Project","op": "==","value": "Contoso"}: . |
Ha nem definiálja a blobIndexMatch értéket, a szabály a tárfiókban lévő összes blobra vonatkozik. | No |
Ha többet szeretne megtudni a blobindex funkcióról és az ismert problémákról és korlátozásokról, olvassa el a Blobindexet tartalmazó Azure Blob Storage adatainak kezelése és keresése című témakört.
Szabályműveletek
A rendszer a futtatási feltétel teljesülésekor alkalmazza a műveleteket a szűrt blobokra.
Az életciklus-felügyelet támogatja az aktuális verziók, korábbi verziók és blobpillanatképek rétegezését és törlését. Minden szabályhoz definiáljon legalább egy műveletet.
| Művelet | Aktuális verzió | Pillanatkép | Korábbi verziók |
|---|---|---|---|
| tierToCool | Támogatott a következőhöz: blockBlob |
Támogatott | Támogatott |
| enableAutoTierToHotFromCool | Támogatott a következőhöz: blockBlob |
Nem támogatott | Nem támogatott |
| tierToArchive | Támogatott a következőhöz: blockBlob |
Támogatott | Támogatott |
| delete 1 | Támogatott és blockBlobappendBlob |
Támogatott | Támogatott |
1 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 könyvtá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ő 24 órás 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ő 24 órás ciklusban a címtár el lesz távolítva, és így tovább.
Megjegyzé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 blobba. Például a cselekvés delete olcsóbb, mint a művelet tierToArchive. A cselekvés tierToArchive olcsóbb, mint a cselekvés tierToCool.
A futtatási feltételek az életkoron alapulnak. Az aktuális verziók az utolsó módosítás időpontját vagy az utolsó hozzáférési időt használják, a korábbi verziók a verziólétrehozás idejét, a blobpillanatképek pedig a pillanatképek 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 blobok vagy blobok pillanatképének korábbi verzióján végzett műveletek feltétele |
| daysAfterLastAccessTimeGreaterThan | Az életkort napokban kifejező egész szám | A blob aktuális verziójának feltétele, ha a hozzáférés-követés engedélyezve van |
Példák életciklus-szabályzatokra
Az alábbi példák bemutatják, hogyan kezelhetők a gyakori forgatókönyvek az életciklus-szabályzat szabályaival.
Az idősödő adatok áthelyezése egy menőbb szintre
Ez a példa bemutatja, hogyan lehet áttűnni a blokkblobok előtaggal sample-container/blob1 vagy container2/blob2. A szabályzat a több mint 30 napja nem módosított blobokat ritka elérésű tárolóra, a 90 nap alatt nem módosított blobokat pedig az archív szintre váltja át:
{
"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 kezelheti a blobadatok rétegezé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ét ismertető cikkben talál.
Ha az utolsó hozzáférési idő nyomon követése engedélyezve van, a meghívott LastAccessTime blobtulajdonság frissül a blob olvasásakor vagy írásakor. A Blob lekérése művelet hozzáférési műveletnek minősül. A blobtulajdonságok lekérése, a blob metaadatainak lekérése és a blobcímkék lekérése nem hozzáférési művelet, ezért nem frissíti az utolsó hozzáférési időt.
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 történő további olvasások nem frissítik az utolsó hozzáférési időt. Ha egy blobot olvasások között módosítanak, az utolsó hozzáférési idő a két érték újabb időpontja.
A következő példában a blobok a ritka elérésű tárolóba kerülnek, 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étegozni a ritka elérésűről a gyakori elérésűre, ha az a ritka elérésűre való rétegzés után ismét elérhető.
{
"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 elérhetők. A következő életciklus-szabályzat úgy van konfigurálva, hogy az adatokat a betöltés után röviddel archiválja. Ez a példa egy archív szintre elnevezett archivecontainer tároló blokkblobjait váltja át. Az áttűnés a blobokon a legutóbbi módosítás után 0 nappal történik:
{
"rules": [
{
"name": "archiveRule",
"enabled": true,
"type": "Lifecycle",
"definition": {
"filters": {
"blobTypes": [ "blockBlob" ],
"prefixMatch": [ "archivecontainer" ]
},
"actions": {
"baseBlob": {
"tierToArchive": { "daysAfterModificationGreaterThan": 0 }
}
}
}
}
]
}
Megjegyzés
A Microsoft azt javasolja, hogy a nagyobb hatékonyság érdekében közvetlenül az archív szintre töltse fel a blobokat. Az archív szintet az x-ms-access-tier fejlécben adhatja meg a Put Blob vagy Put Block List műveletben. Az x-ms-access-tier fejléc a REST 2018-11-09-es és újabb vagy legújabb Blob Storage-ügyfélkódtárakkal támogatott.
Adatok lejárata életkor alapján
Egyes adatok várhatóan napokkal vagy hónappal a létrehozás után lejárnak. Az életciklus-felügyeleti szabályzatot úgy konfigurálhatja, hogy az adatok életkora alapján törléssel járjon le. Az alábbi példa egy szabályzatot mutat be, amely törli az összes olyan blokkblobot, amely nem lett módosítva az elmúlt 365 napban.
{
"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 lehetnek lejártak, ha kifejezetten törlésre vannak megjelölve. Az életciklus-felügyeleti szabályzat konfigurálható úgy, hogy lejárjanak a blobindexkulcs-/értékattribútumokkal címkézett adatok. Az alábbi példa egy olyan szabályzatot mutat be, amely törli a címkével címkézett összes blokkblobot Project = Contoso. További információ a blobindexről: Azure Blob Storage adatainak kezelése és keresése blobindexszel.
{
"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ért adatok esetében engedélyezheti, hogy a Blob Storage verziószámozása automatikusan fenntartsa egy objektum korábbi verzióit. 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ése határozza meg. Ez a szabályzatszabály a verziólétrehozás után 90 napos vagy annál régebbi korábbi verziókat helyezi át a ritka activedata 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"
]
}
}
}
]
}
Szolgáltatások támogatása
A szolgáltatás támogatását a Data Lake Storage Gen2, a Hálózati fájlrendszer (NFS) 3.0 protokoll vagy az SSH File Transfer Protocol (SFTP) engedélyezése befolyásolhatja.
Ha ezek közül a képességek közül bármelyiket engedélyezte, tekintse meg a Blob Storage szolgáltatástámogatását az Azure Storage-fiókokban a funkció támogatásának felméréséhez.
Regionális elérhetőség é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 Set Blob Tier API-hívások standard működési költségeiért kell fizetni. A törlési műveletek ingyenesek. Más Azure-szolgáltatások és -segédprogramok, például a Microsoft Defender for Storage azonban díjat számolhatnak fel az életciklus-szabályzattal felügyelt műveletekért.
A blob utolsó hozzáférési idejének minden egyes frissítését a másik műveleti kategóriában számlázzuk ki.
A díjszabással kapcsolatos további információkért lásd a blokkblobok díjszabását ismertető témakört.
GYIK
Létrehoztam egy új szabályzatot. Miért nem futnak azonnal a műveletek?
A platform naponta egyszer futtatja az életciklus-szabályzatot. A szabályzat konfigurálása után néhány művelet első futtatása akár 24 órát is igénybe vehet.
Ha módosítok egy meglévő szabályzatot, mennyi ideig tart a műveletek futtatása?
A frissített szabályzat érvénybe lépése akár 24 órát is igénybe vehet. A szabályzat életbe lépése után akár 24 órát is igénybe vehet a műveletek futtatása. Ezért a szabályzatműveletek végrehajtása akár 48 órát is igénybe vehet. Ha a frissítés letilt vagy töröl egy szabályt, és engedélyezi aAutoTierToHotFromCool használatát, az automatikus rétegzés a gyakori elérésű szintre továbbra is megtörténik. Például állítson be egy szabályt, beleértve az enableAutoTierToHotFromCool beállítást a legutóbbi hozzáférés alapján. Ha a szabály le van tiltva/törölve van, és egy blob jelenleg ritka elérésű, majd elérhető, visszavált a gyakori elérésűre, mivel az az életciklus-felügyeleten kívüli hozzáférésre vonatkozik. A blob ezután nem lép át a gyakori elérésűről a ritka elérésűre, mivel az életciklus-felügyeleti szabály le van tiltva/törölve. Az autoTierToHotFromCool letiltásának egyetlen módja az utolsó hozzáférési idő nyomon követésének kikapcsolása.
Manuálisan rehidratáltam egy archivált blobot. Hogyan megakadályozza, hogy ideiglenesen visszakerüljön az archív szintre?
Amikor egy blobot áthelyeznek az egyik hozzáférési szintről a másikra, az utolsó módosítás időpontja nem változik. Ha manuálisan rehidratál egy archivált blobot a gyakori elérésű szintre, azt az életciklus-felügyeleti motor áthelyezi az archív szintre. Tiltsa le a blobot ideiglenesen érintő szabályt, hogy megakadályozza annak újbóli archiválását. Engedélyezze újra a szabályt, ha a blobot biztonságosan vissza lehet helyezni az archív szintre. Akkor is másolhatja a blobot egy másik helyre, ha véglegesen a gyakori vagy ritka elérésű szinten kell maradnia.
A blobelőtag-egyeztetési sztring nem alkalmazta a szabályzatot a várt blobokra
A szabályzat blobelőtag-egyeztetési mezője egy teljes vagy részleges blobútvonalat tartalmaz, amelyet a rendszer azon blobok egyeztetésére használ, amelyekre alkalmazni szeretné a szabályzatműveleteket. Az elérési útnak a tároló nevével kell kezdődnie. Ha nincs megadva előtag-egyeztetés, a szabályzat a tárfiókban található összes blobra vonatkozni fog. Az előtag egyező sztringjének formátuma .[container name]/[blob name]
Tartsa szem előtt a következő pontokat az előtag egyeztetési sztringje kapcsán:
- Egy előtag egyezik a container1/ -hez hasonló sztringgel, amely a container1 nevű tárolóban lévő összes blobra vonatkozik. Az előtag egyezik a container1 sztringjével, a záró perjel karakter (/) nélkül, az összes olyan tárolóban lévő blobra vonatkozik, ahol a tároló neve a tároló1 sztringgel kezdődik. Az előtag megegyezik a container11, container1234, container1ab stb. nevű tárolókkal.
- A container1/sub1/ előtag egyező sztringje a container1 nevű tárolóban lévő összes olyan blobra vonatkozik, amely az al1 sztringgel kezdődik. Az előtag például a container1/sub1/test.txt vagy a container1/sub1/sub2/test.txtnevű bloboknak felel meg.
- A csillag karakter
*egy blobnévben érvényes karakter. Ha a csillag karaktert egy előtagban használja, akkor az előtag megegyezik a blobokkal, és a nevükben csillag szerepel. A csillag nem helyettesítő karakterként működik. - A kérdőjel karakter
?egy blobnévben érvényes karakter. Ha a kérdőjel karaktert egy előtagban használja, akkor az előtag egyezik a blobokkal a nevükben szereplő kérdőjellel. A kérdőjel nem helyettesítő karakterként működik. - Az előtagegyezés csak pozitív (=) logikai összehasonlításokat tekint. A negatív (!=) logikai összehasonlítások figyelmen kívül lesznek hagyva.
Van mód a szabályzat végrehajtásának időpontjának azonosítására?
Sajnos nem lehet nyomon követni a szabályzat végrehajtásának időpontját, mivel ez egy háttérütemezési folyamat. A platform azonban naponta egyszer futtatja a szabályzatot.