Vanliga frågor och svar om Azure Blob Storage

Plattformen kör livscykelprincipen en gång om dagen. När du har konfigurerat en princip kan det ta upp till 24 timmar att börja gälla. När principen är i kraft kan den tid det tar för åtgärder att köra variera beroende på storleken på lagringskontot och de åtgärder som utförs.

Den uppdaterade principen tar upp till 24 timmar innan den börjar gälla. När principen är i kraft varierar den tid det tar för åtgärderna att köras beroende på storleken på lagringskontot och de åtgärder som utförs. Om uppdateringen är att inaktivera eller ta bort en regel och enableAutoTierToHotFromCool användes, kommer automatisk nivåindelning till den frekventa nivån fortfarande att ske. Ange till exempel en regel som omfattar enableAutoTierToHotFromCool baserat på senaste åtkomst. Om regeln är inaktiverad eller borttagen och en blob för närvarande är på lågfrekvent eller kall nivå och sedan nås, flyttas den tillbaka till den frekventa nivån eftersom den tillämpas på åtkomst utanför livscykelhanteringen. Blobben flyttas inte från frekvent till lågfrekvent eller kall eftersom livscykelhanteringsregeln har inaktiverats eller tagits bort. Det enda sättet att förhindra autoTierToHotFromCool är att inaktivera spårning av senaste åtkomsttid.

Beroende på storleken och antalet objekt som finns i ett lagringskonto kan mer än en körning krävas för att bearbeta alla objekt. Du kan också kontrollera lagringsresursloggarna för att se om åtgärderna utförs av livscykelhanteringsprincipen.

Kontrollera om dataskyddsfunktioner som mjuk borttagning eller versionshantering är aktiverade på lagringskontot. Även om principen tar bort blobarna kan dessa blobar fortfarande finnas i ett mjukt borttaget tillstånd eller som en äldre version beroende på hur dessa funktioner konfigureras.

Om det finns en princip för livscykelhantering som gäller för lagringskontot kan uthydrering av en blob genom att ändra dess nivå resultera i ett scenario där livscykelprincipen flyttar bloben tillbaka till arkivnivån. Detta kan inträffa om den senaste ändrade tiden, skapandetiden eller den senaste åtkomsttiden överskrider det tröskelvärde som angetts för principen. Det finns tre sätt att förhindra detta:

• Lägg till villkoret daysAfterLastTierChangeGreaterThan i tierToArchive-åtgärden för principen. Det här villkoret gäller endast för den senaste ändrade tiden. Se Använda livscykelhanteringsprinciper för att arkivera blobar.

• Inaktivera regeln som tillfälligt påverkar den här blobben för att förhindra att den arkiveras igen. Återaktivera regeln när bloben kan flyttas tillbaka till arkivnivån på ett säkert sätt.

• Om blobben måste hålla sig på den frekventa, lågfrekventa eller kalla nivån permanent kopierar du bloben till en annan plats där livscykelhanteringsprincipen inte gäller.

Matchningsfältet för blobprefix för en policy är en fullständig eller partiell blobsökväg som används till att matcha de blobar som du vill att policyåtgärderna ska gälla för. Sökvägen måste börja med containernamnet. Om ingen prefixmatchning anges gäller policyn för alla blobar i lagringskontot. Formatet för prefixmatchningssträngen är [container name]/[blob name].
Tänk på följande punkter om prefixets matchningssträng:

• Ett prefix matchar strängen som container1/ gäller för alla blobar i containern med namnet container1. En prefixmatchningssträng för container1, utan det avslutande snedstreckstecknet (/), gäller för alla blobar i alla containrar där containernamnet börjar med strängcontainern1. Prefixet matchar containrar med namnet container11, container1234, container1ab och så vidare.
• Ett prefix matchar strängen container1/sub1/ gäller för alla blobar i containern med namnet container1 som börjar med strängen sub1/. Prefixet matchar till exempel blobar med namnet container1/sub1/test.txt eller container1/sub1/sub2/test.txt.
• Asterisktecknet * är ett giltigt tecken i ett blobnamn. Om asterisktecknet används i ett prefix matchar prefixet blobar med en asterisk i deras namn. Asterisken fungerar inte som jokertecken.
• Frågetecknet ? är ett giltigt tecken i ett blobnamn. Om frågetecknet används i ett prefix matchar prefixet blobar med ett frågetecken i deras namn. Frågetecknet fungerar inte som jokertecken.
• Prefixmatchningen tar endast hänsyn till positiva (=) logiska jämförelser. Negativa (!=) logiska jämförelser ignoreras.
• Prefixmatchningen fungerar på ett skiftlägeskänsligt sätt.

Tyvärr finns det inget sätt att spåra den tid då principen körs, eftersom det är en bakgrundsschemaläggningsprocess. Plattformen kör dock principen en gång per dag.

Den dagliga inventeringsregeln är utformad för att köras en gång varje dag. Dessutom finns det en veckovis inventeringsregel som är schemalagd för varje söndag.

Vi strävar efter att tillhandahålla en konsekvent upplevelse, men vi kan inte garantera den exakta körningstiden för varje körning. Inventeringsregelns körningstid kan variera. Om dagens princip till exempel är schemalagd till 12:05 kan den starta kl. 12:07, 12:15 eller någon annan gång följande dag.

Blob Inventory-rapporten genererar tre typer av filer. Se Inventeringsfiler. Befintliga kunder som använder blobinventering kan se en ändring i antalet inventeringsfiler, från en fil till flera filer. I dag har vi redan en manifestfil som innehåller listan över filer. Det här beteendet förblir oförändrat, så dessa filer visas i manifestfilen.

Ändringen implementerades för att förbättra blobinventeringsprestanda, särskilt för stora lagringskonton som innehåller över fem miljoner objekt. Nu skrivs resultaten parallellt med flera filer, vilket eliminerar flaskhalsen med att använda en enda inventeringsfil. Den här ändringen föranleddes av kundfeedback eftersom de rapporterade svårigheter med att öppna och arbeta med den alltför stora enskilda inventeringsfilen.

Som användare har den här ändringen en positiv inverkan på din upplevelse av blobinventeringskörningar. Det förväntas förbättra prestandan och minska den totala körningstiden. Men för att kunna dra full nytta av den här förbättringen måste du se till att koden uppdateras för att bearbeta flera resultatfiler i stället för bara en. Den här justeringen justerar koden med den nya metoden och optimerar hanteringen av inventeringsdata.

Nej, befintliga data påverkas inte. Endast nya blobinventeringsresultat har flera inventeringsfiler.

Nej, ändringen sker sömlöst.

Dina nödvändiga åtgärder beror på hur du för närvarande bearbetar blobinventeringsresultat:

• Om den aktuella bearbetningen förutsätter en enda inventeringsresultatfil måste du ändra koden för att hantera flera inventeringsresultatfiler.

• Men om den aktuella bearbetningen innebär att läsa listan över resultatfiler från manifestfilen behöver du inte göra några ändringar i hur du bearbetar resultaten. Den befintliga metoden fortsätter att fungera sömlöst med den uppdaterade funktionen.

Detta rekommenderas inte, men det är möjligt. Gå igenom dina supportkanaler för att be om att inaktivera den här funktionen.

Gå igenom ditt aktuella kontoteam och dina supportkanaler.

Den här ändringen börjar gradvis distribueras från och med den 1 september 2023.

Nej. Azure Compute stöder måtten på diskar. Mer information finns i Mått per disk för hanterade och ohanterade diskar.

Vissa Azure-måttdiagram, till exempel de som visar tillgänglighets- och svarstidsdata, använder en streckad linje för att indikera att det saknas ett värde (även kallat nullvärde) mellan två kända tidsintervalldatapunkter. Om du i tidsväljaren till exempel valde 1 minute tidskornighet, men måttet rapporterades 07:26, 07:27, 07:29 och 07:30, ansluter en streckad linje 07:27 och 07:29 eftersom det finns en minuts mellanrum mellan dessa två datapunkter. En solid linje ansluter alla andra datapunkter. Den streckade linjen går ned till noll när måttet använder aggregeringar av typen antal och summa. För avg-, min- eller max-aggregeringarna ansluter en streckad linje de två närmaste kända datapunkterna. Och om data saknas längst till höger eller längst till vänster i diagrammet expanderas den streckade linjen i riktningen mot datapunkten som saknas.

Du kan konfigurera en resurshälsoavisering baserat på Azure Resource Health-tjänsten för att spåra tillgängligheten för ditt lagringskonto. Om det inte finns några transaktioner på kontot rapporterar aviseringen baserat på hälsotillståndet för lagringsklustret där ditt lagringskonto finns.

Analysloggar innehåller poster för alla läs-, skriv-, list- och borttagningsåtgärder med lyckade och misslyckade begäranden i alla åtgärder. Analysloggar är bäst och ingen beställning garanteras.

Ändringsflödet är en lösning som tillhandahåller transaktionslogg för lyckade mutationer eller ändringar i ditt konto, till exempel skapande av blobar, ändringar och borttagningar. Ändringsflödet garanterar att alla händelser registreras och visas i ordning efter lyckade ändringar per blob, vilket innebär att du inte behöver filtrera bort brus från en enorm mängd läsåtgärder eller misslyckade begäranden. Ändringsflödet är i grunden utformat och optimerat för programutveckling som kräver vissa garantier.

Du kan använda båda funktionerna som ändringsflöde och Blob Storage-händelser ger samma information med samma leveranstillförlitlighetsgaranti, där den största skillnaden är svarstid, beställning och lagring av händelseposter. Ändringsflödet publicerar poster i loggen inom några minuter efter ändringen och garanterar även ordningen på ändringsåtgärder per blob. Lagringshändelser skickas i realtid och kanske inte ordnas. Ändringsflödeshändelser lagras vederbörligen i ditt lagringskonto som skrivskyddade stabila loggar med din egen definierade kvarhållning, medan lagringshändelser är tillfälliga att användas av händelsehanteraren om du inte uttryckligen lagrar dem. Med ändringsflöde kan valfritt antal av dina program använda loggarna på egen hand med hjälp av blob-API:er eller SDK:er.

Ja. Lagringskontots nätverkssäkerhetsregler, inklusive IP-baserade brandväggar och VNET-brandväggar, stöds för slutpunkten för den statiska webbplatsen och kan användas för att skydda din webbplats.

Nej. En statisk webbplats stöder endast supports anonym offentlig läsåtkomst för filer i $web-containern.

Du kan konfigurera en anpassad domän med en statisk webbplats med hjälp av Azure Content Delivery Network (Azure CDN). Med Azure CDN får du konsekvent korta svarstider till din webbplats från var som helst i världen.

Du kan konfigurera ett anpassat SSL-certifikat för en statisk webbplats genom att använda Azure CDN. Med Azure CDN får du konsekvent korta svarstider till din webbplats från var som helst i världen.

Du kan konfigurera värdhuvudet för en statisk webbplats med hjälp av Azure CDN – Verizon Premium. Vi vill gärna höra vad du tycker här.

Ett 404-fel kan inträffa om du refererar till ett filnamn med hjälp av ett felaktigt ärende. Till exempel: Index.html i stället index.htmlför . Filnamnen och tilläggen i url:en för en statisk webbplats är skiftlägeskänsliga även om de hanteras via HTTP. Detta kan också inträffa om din Azure CDN-slutpunkt ännu inte har etablerats. Vänta upp till 90 minuter efter att du har etablerat ett nytt Azure CDN för att spridningen ska slutföras.

I Azure-portalen öppnar du konfigurationssidan för den statiska webbplatsen för ditt konto och letar reda på namnet och tillägget som anges i fältet Indexdokumentnamn. Kontrollera att det här namnet är exakt samma som namnet på filen som finns $web-containern för lagringskontot. Filnamnen och tilläggen i url:en för en statisk webbplats är skiftlägeskänsliga även om de hanteras via HTTP.

Nej, om du behöver söka i dina blobdata använder du frågeacceleration eller Azure-sökning.

Blobindextaggar stöder endast strängdatatyper och frågor returnerar resultat med lexikal ordning. För tal, noll pad talet. Lagra som iso 8601-kompatibelt format för datum och tider.

Nej, Resource Manager-taggar hjälper till att organisera kontrollplansresurser som prenumerationer, resursgrupper och lagringskonton. Indextaggar ger blobhantering och identifiering på dataplanet.

Lagringskapacitet debiteras i enheter för den genomsnittliga datamängden som lagras (mätt i GB) under en månad. Om du till exempel ständigt använder 10 GB lagringsutrymme under första hälften av månaden och inget alls under resten av månaden blir din genomsnittliga användning 5 GB.

Nästa steg

Du kan lära dig mer om Azure Blob Storage genom att gå till följande länkar:

• Introduktion till Azure Storage
• Vad är Azure Blob Storage?