Azure Blob Storage – gyakori kérdések

A platform naponta egyszer futtatja az életciklus-szabályzatot. Miután konfigurált egy szabályzatot, akár 24 óráig is eltarthat, amíg érvénybe lép. A szabályzat életbe lépése után a műveletek futtatásához szükséges idő a tárfiók méretétől és az elvégzett műveletektől függően változhat.

A frissített szabályzat érvénybe lépése 24 órát is igénybe vehet. A szabályzat életbe lépése után a műveletek futtatásához szükséges idő a tárfiók méretétől és az elvégzett műveletektől függően változik. Ha a frissítés egy szabály letiltására vagy törlésére szolgál, és engedélyezi aAutoTierToHotFromCool használatát, akkor 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 engedélyezését a legutóbbi hozzáférés alapján. Ha a szabály le van tiltva vagy törölve van, és egy blob jelenleg a ritka vagy a ritka elérésű rétegben van, majd elérhető, visszaáll a gyakori elérésű szintre, mivel az életciklus-kezelésen kívüli hozzáférésre vonatkozik. A blob ezután nem lép át a gyakori vagy a ritka elérésűre, mivel az életciklus-felügyeleti szabály le van tiltva vagy törölve. Az autoTierToHotFromCool megelőzésének egyetlen módja, ha kikapcsolja a legutóbbi hozzáférési idő nyomon követését.

A tárfiókban lévő objektumok méretétől és számától függően előfordulhat, hogy egynél több futtatásra van szükség az összes objektum feldolgozásához. A tárerőforrás-naplókban azt is ellenőrizheti, hogy a műveleteket az életciklus-kezelési szabályzat hajtja-e végre.

Ellenőrizze, hogy engedélyezve vannak-e az olyan adatvédelmi funkciók, mint a helyreállítható törlés vagy a verziószámozás a tárfiókban. Még ha a szabályzat törli is a blobokat, előfordulhat, hogy ezek a blobok továbbra is helyreállíthatóan törölt állapotban vagy régebbi verzióként léteznek attól függően, hogy ezek a funkciók hogyan vannak konfigurálva.

Ha a tárfiókra érvényes életciklus-kezelési szabályzat van érvényben, akkor a blob rétegének módosításával történő rehidratálása olyan forgatókönyvet eredményezhet, amelyben az életciklus-szabályzat visszahelyezi a blobot az archív szintre. Ez akkor fordulhat elő, ha az utolsó módosítás időpontja, létrehozási ideje vagy utolsó hozzáférési ideje meghaladja a szabályzathoz beállított küszöbértéket. Ennek megakadályozása három módon lehetséges:

• Adja hozzá a daysAfterLastTierChangeGreaterThan feltételt a szabályzat tierToArchive műveletéhez. Ez a feltétel csak az utolsó módosítás időpontjára vonatkozik. Lásd: Életciklus-felügyeleti szabályzatok használata blobok archiválásához.

• Tiltsa le a blobot ideiglenesen érintő szabályt, hogy megakadályozza a blob újbóli archiválását. Engedélyezze újra a szabályt, ha a blobot biztonságosan vissza lehet helyezni az archív szintre.

• Ha a blobnak tartósan a gyakori, a ritka elérésű vagy a hideg rétegben kell maradnia, másolja a blobot egy másik helyre, ahol az életciklus-kezelési szabályzat nincs érvényben.

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 a következő [container name]/[blob name]: .
Tartsa szem előtt a következő pontokat az előtag egyező sztringjét illetően:

• Egy előtag egyezik a tároló1/-hez hasonló sztringgel, amely a tároló1 nevű tárolóban lévő összes blobra vonatkozik. A tároló1 sztringjének előtagja a záró perjel karakter (/) nélkül az összes olyan tároló összes blobjára vonatkozik, ahol a tároló neve a sztringtároló1 karakterrel kezdődik. Az előtag egyezik a container11, container1234, container1ab stb. nevű tárolókkal.
• A container1/sub1/ előtag egyezik a tároló1/al1/ sztringjével, amely a tároló1 nevű tárolóban lévő összes olyan blobra vonatkozik, amely az 1. sztring al1/- sztringjével kezdődik. Az előtag például megfelel a container1/sub1/test.txt vagy container1/sub1/sub2/test.txt nevű bloboknak.
• A csillag karakter * egy blobnévben érvényes karakter. Ha a csillag karaktert egy előtagban használja, akkor az előtag egyezik a blobokkal a nevükben egy csillaggal. A csillag nem helyettesítő karakterként működik.
• A kérdőjel egy ? blobnévben érvényes karakter. Ha a kérdőjel karaktert egy előtagban használják, 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.
• Az előtag egyeztetése a kis- és nagybetűk megkülönböztetésével működik.

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.

A napi leltárszabály úgy van kialakítva, hogy minden nap egyszer fusson. Emellett minden vasárnapra ütemezve van egy heti leltárszabály.

Bár igyekszünk konzisztens élményt nyújtani, nem tudjuk garantálni az egyes futtatásokkal kapcsolatos pontos végrehajtási időt. A leltárszabály végrehajtási ideje eltérő lehet. Ha például a mai szabályzat 12:05-re van ütemezve, az a következő napon 12:07-kor, 12:15-kor vagy bármely más időpontban indulhat el.

A Blob Inventory-jelentés három fájltípust hoz létre. Lásd: Leltárfájlok. A blobleltárt használó meglévő ügyfelek egy fájlról több fájlra módosíthatják a leltárfájlok számát. Ma már rendelkezünk jegyzékfájllal, amely tartalmazza a fájlok listáját. Ez a viselkedés változatlan marad, ezért ezek a fájlok szerepelnek a jegyzékfájlban.

A módosítást a blobleltár teljesítményének növelése érdekében hajtották végre, különösen a több mint ötmillió objektumot tartalmazó nagy tárfiókok esetében. Most az eredmények több fájllal párhuzamosan vannak megírva, így kiküszöbölve az egyetlen leltárfájl használatának szűk keresztmetszetét. Ezt a változást az ügyfelek visszajelzése is jelezte, mivel nehézségekről számoltak be a túlságosan nagy önálló készletfájl megnyitása és használata során.

Felhasználóként ez a változás pozitív hatással van a blobleltár-futtatásokra. Várhatóan növeli a teljesítményt, és csökkenti a teljes futási időt. Ahhoz azonban, hogy teljes mértékben kihasználhassa ezt a fejlesztést, gondoskodnia kell arról, hogy a kód frissüljön, hogy több találatfájlt dolgozhasson fel egyetlen helyett. Ez a módosítás igazodik a kódhoz az új megközelítéshez, és optimalizálja a leltáradatok kezelését.

Nem, a meglévő adatokra nincs hatással. Csak az új blobleltár-eredmények rendelkeznek több leltárfájllal.

Nem, a változás zökkenőmentesen történik.

A szükséges műveletek attól függenek, hogy jelenleg hogyan dolgozza fel a blobleltár eredményeit:

• Ha az aktuális feldolgozás egyetlen készleteredmény-fájlt feltételez, akkor módosítania kell a kódot, hogy több leltáreredményfájlt is elférjen.

• Ha azonban a jelenlegi feldolgozás magában foglalja a jegyzékfájlból származó találatok listájának beolvasását, nem kell módosítania az eredmények feldolgozását. A meglévő megközelítés továbbra is zökkenőmentesen működik a frissített funkcióval.

Ez nem ajánlott, de lehetséges. Kérjük, hogy a támogatási csatornákon keresztül kérje a funkció kikapcsolását.

Kérjük, dolgozzon az aktuális fiókért felelős csapatán és a támogatási csatornákon.

Ez a változás 2023. szeptember 1-től fokozatos bevezetést fog kezdeni.

Szám Az Azure Compute támogatja a lemezek metrikáit. További információ: Felügyelt és nem felügyelt lemezek lemezenkénti metrikái.

Egyes Azure-metrikadiagramok, például a rendelkezésre állási és késési adatokat megjelenítő diagramok szaggatott vonallal jelzik, hogy hiányzik egy érték (más néven null érték) két ismert időfelbontási adatpont között. Ha például az időválasztóban az idő részletességét választotta 1 minute , de a metrikát 07:26, 07:27, 07:29 és 07:30 időpontban jelentették, akkor egy szaggatott vonal csatlakozik a 07:27 és a 07:29 értékhez, mert a két adatpont között percek közötti eltérés van. Egy folytonos vonal összekapcsolja az összes többi adatpontot. A szaggatott vonal nullára csökken, amikor a metrika darabszám és összeg összesítést használ. Az avg, min vagy max aggregációk esetében szaggatott vonal köti össze a két legközelebbi ismert adatpontot. Ha pedig az adatok a diagram jobb vagy bal szélén hiányoznak, akkor rendszer meghosszabbítja a szaggatott vonalat a hiányzó adatpont irányába.

Az Azure Resource Health szolgáltatáson alapuló erőforrás-állapotriasztást konfigurálhat a tárfiók rendelkezésre állásának nyomon követéséhez. Ha nincsenek tranzakciók a fiókon, akkor a riasztás annak a Tárfürtnek az állapotán alapul, amelyben a tárfiók található.

Az elemzési naplók minden olvasási, írási, listázási és törlési művelet rekordjaival rendelkeznek, amelyek minden műveletre kiterjedő sikeres és sikertelen kéréseket tartalmaznak. Az elemzési naplók a legjobbak, és nem garantálják a megrendelést.

A változáscsatorna egy olyan megoldás, amely tranzakciós naplót biztosít a sikeres mutációkról vagy a fiók módosításairól, például blobok létrehozásáról, módosításáról és törléséről. A változáscsatorna garantálja, hogy minden eseményt a blobonkénti sikeres módosítások sorrendjében kell rögzíteni és megjeleníteni, így nem kell kiszűrnie a zajt nagy mennyiségű olvasási műveletből vagy sikertelen kérésből. A változáscsatorna alapvetően olyan alkalmazásfejlesztésre lett tervezve és optimalizálva, amely bizonyos garanciákat igényel.

Mindkét funkciót kihasználhatja, mivel a változáscsatorna és a Blob Storage-események ugyanazokat az információkat biztosítják ugyanazzal a teljesítési megbízhatósági garanciával, a fő különbség az eseményrekordok késése, sorrendje és tárolása. A változáscsatorna a módosítást követő néhány percen belül közzéteszi a rekordokat a naplóban, és garantálja a blobonkénti módosítási műveletek sorrendjét is. A rendszer valós időben küldi el a tárolási eseményeket, és előfordulhat, hogy nem lesz rendezve. A változáscsatorna-eseményeket a rendszer tartósan tárolja a tárfiókban írásvédett stabil naplókként, saját meghatározott megőrzéssel, míg a tárolási eseményeket az eseménykezelő csak akkor használja fel, ha kifejezetten nem tárolja őket. A változáscsatorna használatával tetszőleges számú alkalmazás saját kezűen használhatja a naplókat blob API-k vagy SDK-k használatával.

Igen. A Storage-fiókok hálózati biztonsági szabályai (beleértve az IP-alapú és a VNET-tűzfalakat) statikus webhelyek végpontja esetében is támogatottak, és használhatók a webhely védelmére.

Szám A statikus webhelyek csak névtelen nyilvános olvasási hozzáférést támogatnak a $web tárolókban található fájlok esetében.

Az egyéni tartomány statikus webhelyhez való konfigurálásához az Azure Content Delivery Networköt (Azure CDN) kell használnia. Az Azure CDN révén mindig alacsony késéssel érhető el a webhelye szerte a világon.

Az egyéni SSL-tanúsítvány statikus webhelyhez való konfigurálásához az Azure CDN-t kell használnia. Az Azure CDN révén mindig alacsony késéssel érhető el a webhelye szerte a világon.

A gazdagépfejléc statikus webhelyhez való konfigurálásához az Azure CDN – Verizon Premiumot kell használnia. Minket érdekel a véleménye! Itt adhat visszajelzést.

404-hiba akkor fordulhat elő, ha helytelen eset használatával hivatkozik egy fájlnévre. Például: Index.html helyett index.html. Statikus webhely URL-je esetén a rendszer a fájlnevekben és a kiterjesztésekben megkülönbözteti a kis- és nagybetűket, még HTTP-kapcsolat használatakor is. Ez akkor is előfordulhat, ha az Azure CDN-végpont még nincs kiépítve. Várjon akár 90 percet, miután kiépít egy új Azure CDN-t a propagálás befejezéséhez.

Az Azure Portalon nyissa meg a fiókjához tartozó statikus webhely konfigurációs oldalát, majd keresse meg az Indexdokumentum neve mezőben beállított nevet és kiterjesztést. Ellenőrizze, hogy ez a név pontosan megegyezik-e a tárfiók $web tárolójában található fájl nevével. Statikus webhely URL-je esetén a rendszer a fájlnevekben és a kiterjesztésekben megkülönbözteti a kis- és nagybetűket, még HTTP-kapcsolat használatakor is.

Nem, ha a blobadatok között kell keresnie, használja a lekérdezés gyorsítását vagy az Azure Search szolgáltatást.

A blobindex-címkék csak a sztring adattípusokat támogatják, a lekérdezések pedig lexikográfiai sorrendbe rendezve adnak vissza eredményeket. Számok esetén nulla a szám. Dátumok és időpontok esetén iso 8601-kompatibilis formátumban tárolja.

Nem, a Resource Manager-címkék segítenek rendszerezni a vezérlősík erőforrásait, például az előfizetéseket, az erőforráscsoportokat és a tárfiókokat. Az indexcímkék blobkezelést és felderítést biztosítanak az adatsíkon.

A Storage elszámolási egysége a tárolt adatok havi időszakban (gigabájtban) mért napi átlagmennyisége. Ha például a hónap első felében 10 GB tárhelyet használt fel, de a hónap második felében semmit, átlagosan 5 GB adattárolás használati díját számítjuk fel.

Következő lépések

Az Azure Blob Storage-ról az alábbi hivatkozásokra kattintva tudhat meg többet:

• A Microsoft Azure Storage bemutatása
• Mi az Az Azure Blob Storage?