Veelgestelde vragen over Azure Blob Storage

Het platform voert het levenscyclusbeleid één keer per dag uit. Nadat u een beleid hebt geconfigureerd, kan het tot 24 uur duren voordat het van kracht wordt. Zodra het beleid van kracht is, kan de tijd die nodig is om acties uit te voeren variëren, afhankelijk van de grootte van het opslagaccount en de uitgevoerde bewerkingen.

Het bijgewerkte beleid duurt maximaal 24 uur om van kracht te worden. Zodra het beleid van kracht is, is de tijd die nodig is om de acties uit te voeren, afhankelijk van de grootte van het opslagaccount en de bewerkingen die worden uitgevoerd. Als de update is om een regel uit te schakelen of te verwijderen en enableAutoTierToHotFromCool is gebruikt, wordt automatisch tieren naar de dynamische laag nog steeds uitgevoerd. Stel bijvoorbeeld een regel in, inclusief enableAutoTierToHotFromCool op basis van laatste toegang. Als de regel is uitgeschakeld of verwijderd en een blob zich momenteel in de statische of koude laag bevindt en vervolgens wordt geopend, wordt deze teruggezet naar de dynamische laag, zoals die wordt toegepast op toegang buiten het levenscyclusbeheer. De blob wordt vervolgens niet verplaatst van dynamisch naar statisch of koud omdat de levenscyclusbeheerregel is uitgeschakeld of verwijderd. De enige manier om autoTierToHotFromCool te voorkomen, is door het bijhouden van laatste toegangstijd uit te schakelen.

Afhankelijk van de grootte en het aantal objecten dat zich in een opslagaccount bevindt, is er mogelijk meer dan één uitvoering vereist om alle objecten te verwerken. U kunt ook de opslagresourcelogboeken controleren om te zien of de bewerkingen worden uitgevoerd door het levenscyclusbeheerbeleid.

Controleer of functies voor gegevensbeveiliging, zoals voorlopig verwijderen of versiebeheer zijn ingeschakeld voor het opslagaccount. Zelfs als het beleid de blobs verwijdert, kunnen deze blobs nog steeds bestaan in een voorlopig verwijderde status of als een oudere versie, afhankelijk van de configuratie van deze functies.

Als er een beleid voor levenscyclusbeheer van kracht is voor het opslagaccount, kan het reactiveren van een blob door de laag ervan te wijzigen resulteren in een scenario waarin het levenscyclusbeleid de blob weer naar de archieflaag verplaatst. Dit kan gebeuren als de laatste wijzigingstijd, aanmaaktijd of laatste toegangstijd buiten de drempelwaarde valt die is ingesteld voor het beleid. Er zijn drie manieren om te voorkomen dat dit gebeurt:

• Voeg de daysAfterLastTierChangeGreaterThan voorwaarde toe aan de actie tierToArchive van het beleid. Deze voorwaarde is alleen van toepassing op de laatste wijzigingstijd. Zie Beleid voor levenscyclusbeheer gebruiken om blobs te archiveren.

• Schakel de regel die van invloed is op deze blob tijdelijk uit om te voorkomen dat deze opnieuw wordt gearchiveerd. Schakel de regel opnieuw in wanneer de blob veilig naar de archieflaag kan worden verplaatst.

• Als de blob permanent in de dynamische, statische of koude laag moet blijven, kopieert u de blob naar een andere locatie waar het levenscyclusbeheerbeleid niet van kracht is.

Het overeenkomende veld voor het blob-voorvoegsel van een beleid is een volledig of gedeeltelijk blobpad, dat wordt gebruikt om overeen te komen met de blobs waarop u de beleidsacties wilt toepassen. Het pad moet beginnen met de containernaam. Als er geen overeenkomst met het voorvoegsel is opgegeven, is het beleid van toepassing op alle blobs in het opslagaccount. De notatie van de tekenreeks voor het voorvoegselovereenkomst is [container name]/[blob name].
Houd rekening met de volgende punten over de tekenreeks voor het voorvoegsel:

• Een tekenreeks die overeenkomt met het voorvoegsel, zoals container1/ is van toepassing op alle blobs in de container met de naam container1. Een voorvoegsel komt overeen met de tekenreeks van container1, zonder het afsluitende slash-teken (/), is van toepassing op alle blobs in alle containers waar de containernaam begint met de tekenreekscontainer1. Het voorvoegsel komt overeen met containers met de naam container11, container1234, container1ab, enzovoort.
• Een overeenkomende tekenreeks voor voorvoegsels van container1/sub1/ is van toepassing op alle blobs in de container met de naam container1 die beginnen met de tekenreekssub1 /. Het voorvoegsel komt bijvoorbeeld overeen met blobs met de naam container1/sub1/test.txt of container1/sub1/sub2/test.txt.
• Het sterretje is een geldig teken * in een blobnaam. Als het sterretje wordt gebruikt in een voorvoegsel, komt het voorvoegsel overeen met blobs met een sterretje in hun namen. Het sterretje werkt niet als jokerteken.
• Het vraagteken is een geldig teken ? in een blobnaam. Als het vraagteken wordt gebruikt in een voorvoegsel, komt het voorvoegsel overeen met blobs met een vraagteken in hun namen. Het vraagteken werkt niet als jokerteken.
• De overeenkomst met het voorvoegsel beschouwt alleen positieve (=) logische vergelijkingen. Negatieve (!=) logische vergelijkingen worden genegeerd.
• Het overeenkomende voorvoegsel werkt op een hoofdlettergevoelige manier.

Helaas is er geen manier om het tijdstip bij te houden waarop het beleid wordt uitgevoerd, omdat het een achtergrondplanningsproces is. Het platform voert het beleid echter eenmaal per dag uit.

De dagelijkse voorraadregel is ontworpen om elke dag één keer te worden uitgevoerd. Daarnaast is er een wekelijkse inventarisregel gepland voor elke zondag.

Hoewel we ernaar streven om een consistente ervaring te bieden, kunnen we de exacte uitvoeringstijd voor elke uitvoering niet garanderen. De uitvoeringstijd van de inventarisregel kan variëren. Als het beleid van vandaag bijvoorbeeld is gepland om 12:05 uur, kan het worden gestart om 12:07 uur, 12:15 uur of een ander tijdstip op de volgende dag.

Het rapport Blob-inventaris produceert drie typen bestanden. Zie Inventarisbestanden. Bestaande klanten die blob-inventaris gebruiken, zien mogelijk een wijziging in het aantal voorraadbestanden, van één bestand naar meerdere bestanden. Vandaag hebben we al een manifestbestand dat de lijst met bestanden bevat. Dit gedrag blijft ongewijzigd, zodat deze bestanden worden vermeld in het manifestbestand.

De wijziging is geïmplementeerd om de prestaties van blob-inventaris te verbeteren, met name voor grote opslagaccounts met meer dan vijf miljoen objecten. Nu worden resultaten parallel naar meerdere bestanden geschreven, waardoor het knelpunt van het gebruik van één voorraadbestand wordt geëlimineerd. Deze wijziging werd gevraagd door feedback van klanten, omdat ze problemen hebben gemeld bij het openen en werken met het overmatig grote individuele voorraadbestand.

Als gebruiker heeft deze wijziging een positieve invloed op uw ervaring met blob-inventarisatieuitvoeringen. Naar verwachting verbetert u de prestaties en vermindert u de totale uitvoeringstijd. Als u echter volledig wilt profiteren van deze verbetering, moet u ervoor zorgen dat uw code wordt bijgewerkt om meerdere resultatenbestanden te verwerken in plaats van slechts één. Met deze aanpassing wordt uw code afgestemd op de nieuwe aanpak en wordt de verwerking van inventarisgegevens geoptimaliseerd.

Nee, bestaande gegevens worden niet beïnvloed. Alleen nieuwe blob-inventarisresultaten hebben meerdere inventarisbestanden.

Nee, de wijziging gebeurt naadloos.

Uw vereiste acties zijn afhankelijk van hoe u momenteel blob-inventarisresultaten verwerkt:

• Als uw huidige verwerking ervan uitgaat dat er één inventarisresultatenbestand wordt gebruikt, moet u uw code aanpassen voor meerdere inventarisresultatenbestanden.

• Als uw huidige verwerking echter betrekking heeft op het lezen van de lijst met resultatenbestanden uit het manifestbestand, hoeft u geen wijzigingen aan te brengen in de manier waarop u de resultaten verwerkt. De bestaande benadering blijft naadloos werken met de bijgewerkte functie.

Dit wordt niet aanbevolen, maar het is mogelijk. Neem contact op met uw ondersteuningskanalen om te vragen deze functie uit te schakelen.

Neem contact op met uw huidige accountteam en ondersteuningskanalen.

Deze wijziging begint met de geleidelijke implementatie vanaf 1 september 2023.

Nee Azure Compute ondersteunt de metrische gegevens op schijven. Zie metrische gegevens per schijf voor beheerde en niet-beheerde schijven voor meer informatie.

In sommige grafieken met metrische gegevens van Azure, zoals grafieken die beschikbaarheids- en latentiegegevens weergeven, gebruikt u een stippellijn om aan te geven dat er een ontbrekende waarde (ook wel null-waarde genoemd) is tussen twee bekende tijdsintervalgegevenspunten. Als u bijvoorbeeld in de tijdkiezer tijdgranulariteit hebt gekozen 1 minute , maar de metrische waarde is gerapporteerd om 07:26, 07:27, 07:29 en 07:30, verbindt een stippellijn 07:27 en 07:29 omdat er een minuut tussen deze twee gegevenspunten is. Een ononderbroken lijn verbindt alle andere gegevenspunten. De stippellijn zakt naar nul wanneer voor de metrische gegevens de aggregatie aantal en som wordt gebruikt. Voor de gemiddelde, minimale of maximale aggregaties verbindt een stippellijn de twee dichtstbijzijnde bekende gegevenspunten. Als er gegevens ontbreken aan de meest rechtse of linkse kant van de grafiek, wordt de stippellijn uitgebreid in de richting van het ontbrekende gegevenspunt.

U kunt een resourcestatuswaarschuwing configureren op basis van de Azure Resource Health-service om de beschikbaarheid van uw opslagaccount bij te houden. Als er geen transacties voor het account zijn, wordt de waarschuwing gerapporteerd op basis van de status van het opslagcluster waar uw opslagaccount zich bevindt.

Analyselogboeken bevatten records van alle lees-, schrijf-, lijst- en verwijderbewerkingen met geslaagde en mislukte aanvragen voor alle bewerkingen. Analyselogboeken zijn best-effort en er wordt geen volgorde gegarandeerd.

De wijzigingenfeed is een oplossing die transactioneel logboek biedt van geslaagde mutaties of wijzigingen in uw account, zoals het maken, wijzigen en verwijderen van blobs. De wijzigingenfeed garandeert dat alle gebeurtenissen worden vastgelegd en weergegeven in de volgorde van geslaagde wijzigingen per blob, zodat u geen ruis hoeft te filteren op een groot aantal leesbewerkingen of mislukte aanvragen. De wijzigingenfeed is fundamenteel ontworpen en geoptimaliseerd voor toepassingsontwikkeling waarvoor bepaalde garanties zijn vereist.

U kunt beide functies gebruiken als de wijzigingenfeed en blobopslaggebeurtenissen bieden dezelfde informatie met dezelfde betrouwbaarheidsgarantie voor levering, waarbij het belangrijkste verschil de latentie, volgorde en opslag van gebeurtenisrecords is. De wijzigingenfeed publiceert records binnen enkele minuten na de wijziging in het logboek en garandeert ook de volgorde van wijzigingsbewerkingen per blob. Opslaggebeurtenissen worden in realtime gepusht en zijn mogelijk niet geordend. Wijzigingenfeedgebeurtenissen worden duurzaam opgeslagen in uw opslagaccount als alleen-lezen stabiele logboeken met uw eigen gedefinieerde retentie, terwijl opslaggebeurtenissen tijdelijk moeten worden gebruikt door de gebeurtenis-handler, tenzij u ze expliciet opslaat. Met de wijzigingenfeed kan elk aantal toepassingen de logboeken op hun eigen gemak gebruiken met behulp van blob-API's of SDK's.

Ja. Netwerkbeveiligingsregels voor opslagaccounts, inclusief IP- en VNET-firewalls, worden ondersteund voor het eindpunt van de statische website en kunnen worden gebruikt om uw website te beveiligen.

Nee Een statische website ondersteunt alleen anonieme, openbare leestoegang voor bestanden in de $web-container.

U kunt een aangepast domein configureren met een statische website met behulp van Azure CDN (Azure Content Delivery Network). Azure CDN biedt overal ter wereld een consistent lage latentie voor uw website.

U kunt een aangepast SSL-certificaat configureren met een statische website met behulp van Azure CDN. Azure CDN biedt overal ter wereld een consistent lage latentie voor uw website.

U kunt de host-header voor een statische website configureren met behulp van Azure CDN - Verizon Premium. We horen graag uw feedback hier.

Er kan een 404-fout optreden als u naar een bestandsnaam verwijst met behulp van een onjuist geval. Bijvoorbeeld: Index.html in plaats van index.html. Bestandsnamen en -extensies in de URL van een statische website zijn hoofdlettergevoelig, ook als ze via HTTP worden bediend. Dit kan ook gebeuren als uw Azure CDN-eindpunt nog niet is ingericht. Wacht maximaal 90 minuten nadat u een nieuwe Azure CDN hebt ingericht voordat de doorgifte is voltooid.

Open in Azure Portal de configuratiepagina van de statische website van uw account en zoek de naam en extensie die zijn ingesteld in het veld Indexdocumentnaam. Zorg ervoor dat deze naam exact dezelfde is als de naam van het bestand dat zich in de $web-container van het opslagaccount bevindt. Bestandsnamen en -extensies in de URL van een statische website zijn hoofdlettergevoelig, ook als ze via HTTP worden bediend.

Nee, als u in uw blobgegevens wilt zoeken, gebruikt u queryversnelling of Azure Search.

Blob-indextags ondersteunen alleen tekenreeksgegevenstypen en query's retourneren resultaten met lexicografische volgorde. Voor getallen wordt het getal door nul op te vullingen. Voor datums en tijden moet u opslaan als een ISO 8601-compatibele indeling.

Nee, Resource Manager-tags helpen bij het organiseren van beheervlakresources, zoals abonnementen, resourcegroepen en opslagaccounts. Indextags bieden blobbeheer en detectie op het gegevensvlak.

Opslagcapaciteit wordt in rekening gebracht in eenheden van de gemiddelde dagelijkse hoeveelheid opgeslagen gegevens (in GB) gedurende een maand. Als u bijvoorbeeld consequent 10 GB aan opslag hebt gebruikt tijdens de eerste helft van de maand en niets in de tweede helft, krijgt u een rekening voor uw gemiddeld gebruik van 5 GB aan opslag.

Volgende stappen

Ga naar de volgende koppelingen voor meer informatie over Azure Blob Storage:

• Kennismaking met Azure Storage
• Wat is Azure Blob Storage?