Häufig gestellte Fragen zu Azure Blob Storage

Nachdem Sie eine Richtlinie konfiguriert haben, kann es bis zu 24 Stunden dauern, bis sie wirksam wird. Sobald die Richtlinie wirksam ist, kann die Zeit für die Ausführung von Aktionen je nach Größe des Speicherkontos und der ausgeführten Vorgänge variieren.

Es dauert bis zu 24 Stunden, bis die aktualisierte Richtlinie in Kraft tritt. Sobald die Richtlinie wirksam ist, variiert die für die Ausführung der Aktionen benötigte Zeit je nach Größe des Speicherkontos und der ausgeführten Vorgänge. Wenn das Update eine Regel deaktivieren oder löschen soll und „enableAutoTierToHotFromCool“ verwendet wurde, wird dennoch das automatische Tiering auf die heiße Speicherebene durchgeführt. Legen Sie beispielsweise basierend auf dem letzten Zugriff eine Regel einschließlich „enableAutoTierToHotFromCool“ fest. Wenn die Regel deaktiviert oder gelöscht wird und sich ein Blob derzeit auf der Ebene „Kalt“ oder „Cold“ befindet und dann darauf zugegriffen wird, wird er wieder auf die heiße Ebene zurückverschoben, da diese für den Zugriff außerhalb der Lebenszyklusverwaltung verwendet wird. Das Blob wird dann nicht von der heißen Ebene auf die Ebene „Kalt“ oder „Cold“ verschoben, da die Regel für die Lebenszyklusverwaltung deaktiviert/gelöscht wurde. Die einzige Möglichkeit, „autoTierToHotFromCool“ zu verhindern, besteht darin, die Nachverfolgung des letzten Zugriffszeitpunkts zu deaktivieren.

Abhängig von der Größe und der Anzahl von Objekten, die sich in einem Speicherkonto befinden, sind möglicherweise mehrere Ausführungen erforderlich, um alle Objekte zu verarbeiten. Sie können auch die Speicherressourcenprotokolle überprüfen, um zu überprüfen, ob die Vorgänge von der Richtlinie für die Lebenszyklusverwaltung ausgeführt werden.

Überprüfen Sie, ob Datenschutzfeatures wie vorläufiges Löschen oder Versionsverwaltung für das Speicherkonto aktiviert sind. Selbst wenn die Richtlinie die Blobs löscht, können diese Blobs je nach Konfiguration dieser Features noch in einem vorläufig gelöschten Zustand oder als ältere Version vorhanden sein.

Wenn eine Lebenszyklusverwaltungsrichtlinie für das Speicherkonto wirksam ist, kann die Aktivierung eines Blobs durch Ändern von deren Ebene zu einem Szenario führen, bei dem die Richtlinie das Blob zurück auf die Archivspeicherebene verschiebt. Dies kann geschehen, wenn der Zeitpunkt der letzten Änderung, der Erstellungszeitpunkt oder die letzte Zugriffszeit den für die Richtlinie festgelegten Schwellenwert überschreitet. Es gibt drei Möglichkeiten, dies zu verhindern:

• Fügen Sie die Bedingung daysAfterLastTierChangeGreaterThan zur Aktion „tierToArchive“ der Richtlinie hinzu. Lesen Sie dazu Verwenden von Richtlinien für die Lebenszyklusverwaltung zum Archivieren von Blobs.

• Deaktivieren Sie vorübergehend die Regel, die sich auf dieses Blob auswirkt, um zu verhindern, dass es erneut archiviert wird. Aktivieren Sie die Regel erneut, wenn das Blob sicher zurück auf die Archivspeicherebene verschoben werden kann.

• Wenn das Blob dauerhaft auf der Ebene „Heiß“, „Kalt“ oder „Cold“ bleiben muss, kopieren Sie es an einen anderen Speicherort, an dem die Richtlinie für die Lebenszyklusverwaltung nicht wirksam ist.

Das Blobpräfix-Abgleichsfeld einer Richtlinie ist ein vollständiger oder partieller Blobpfad, der verwendet wird, um die Blobs abzugleichen, auf die die Richtlinienaktionen angewendet werden sollen. Der Pfad muss mit dem Namen des Containers beginnen. Wenn kein Präfixabgleich angegeben wird, gilt die Richtlinie für alle Blobs im Speicherkonto. Das Format der Präfix-Übereinstimmungszeichenfolge lautet [container name]/[blob name].
Beachten Sie die folgenden Punkte zum Präfix match string:

• Eine Präfix-Übereinstimmungszeichenfolge wie container1/ gilt für alle Blobs im Container namens "container1". Eine Präfix-Übereinstimmungszeichenfolge von Container1, ohne das schräge Schrägstrichzeichen (/) gilt für alle Blobs in allen Containern, in denen der Containername mit dem Zeichenfolgencontainer1 beginnt. Das Präfix entspricht Containern namens "container11", "container1234", "container1ab" usw.
• Eine Präfixüberstimmungszeichenfolge von container1/sub1/ gilt für alle Blobs im Container namens Container1 , die mit der Zeichenfolge sub1/beginnen. Das Präfix entspricht beispielsweise Blobs namens container1/sub1/test.txt oder container1/sub1/sub1/sub2/test.txt.
• Das Zeichen „Sternchen“ (*) ist ein gültiges Zeichen für einen Blobnamen. Wenn das Sternchen in einem Präfix verwendet wird, stimmt das Präfix blobs mit einem Sternchen in ihren Namen überein. Das Sternchen funktioniert nicht als Wildcardzeichen.
• Das Fragezeichen (?) ist ein gültiges Zeichen für einen Blobnamen. Wenn das Fragezeichen in einem Präfix verwendet wird, stimmt das Präfix blobs mit einem Fragezeichen in ihren Namen überein. Das Fragezeichen funktioniert nicht als Wildcardzeichen.
• Die Präfixvergleiche betrachten nur positive (=) logische Vergleiche. Daher werden negative (!=) logische Vergleiche ignoriert.
• Bei dem Präfixabgleich wird die Groß-/Kleinschreibung beachtet.

Leider gibt es keine Möglichkeit, den Zeitpunkt nachzuverfolgen, zu dem die Richtlinie ausgeführt wird, da es sich um einen Hintergrundplanungsprozess handelt. Die Plattform führt die Richtlinie jedoch einmal pro Tag aus.

Die tägliche Bestandsregel ist so konzipiert, dass sie einmal täglich ausgeführt wird. Darüber hinaus gibt es eine wöchentliche Bestandsregel, die für jeden Sonntag geplant ist.

Obwohl wir uns bemühen, ein konsistentes Erlebnis zu bieten, können wir die genaue Ausführungszeit für jede Ausführung nicht garantieren. Die Ausführungszeit der Bestandsregel kann variieren. Wenn beispielsweise die heutige Richtlinie für 12:05 Uhr geplant ist, kann sie um 12:07 Uhr, 12:15 Uhr oder an einem anderen Zeitpunkt am folgenden Tag beginnen.

Der Blobinventurbericht generiert drei Arten von Dateien. Siehe Inventurdateien. Bestandskund*innen, die die Blobinventur verwenden, stellen möglicherweise eine Änderung bei der Anzahl der Inventurdateien fest – anstelle von nur einer Datei werden jetzt mehrere Dateien angezeigt. Gegenwärtig gibt es bereits eine Manifestdatei, die die Liste der Dateien enthält. Dieses Verhalten bleibt unverändert, das heißt, diese Dateien werden in der Manifestdatei aufgeführt.

Die Änderung wurde implementiert, um die Leistung der Blobinventur zu verbessern, insbesondere für umfangreiche Speicherkonten mit mehr als fünf Millionen Objekten. Jetzt werden Ergebnisse parallel in mehrere Dateien geschrieben, um den Engpass bei Verwendung einer einzelnen Inventurdatei zu beseitigen. Diese Änderung wurde aufgrund des Feedbacks von Kund*innen vorgenommen, die Schwierigkeiten beim Öffnen und Arbeiten mit einer übermäßig großen einzelnen Inventurdatei hatten.

Für Benutzer*innen wirkt sich diese Änderung positiv auf die Ausführung einer Blobinventur aus. Die Leistung sollte sich dadurch verbessern, und die Gesamtlaufzeit sollte sich verkürzen. Um jedoch in vollem Umfang von dieser Verbesserung zu profitieren, müssen Sie Ihren Code so aktualisieren, dass er anstelle von nur einer Datei mehrere Ergebnisdateien verarbeitet. Durch diese Anpassung wird Ihr Code auf den neuen Ansatz ausgerichtet und die Verarbeitung von Inventurdaten optimiert.

Nein, vorhandene Daten sind nicht betroffen. Nur neue Blobinventurergebnisse enthalten mehrere Inventurdateien.

Nein, die Änderung erfolgt nahtlos.

Die erforderlichen Aktionen hängen davon ab, wie Sie die Blobinventurergebnisse derzeit verarbeiten:

• Wenn Ihre aktuelle Verarbeitung von einer einzigen Inventurergebnisdatei ausgeht, müssen Sie Ihren Code so ändern, dass mehrere Inventurergebnisdateien berücksichtigt werden.

• Wenn Ihre aktuelle Verarbeitung jedoch das Lesen der Liste der Ergebnisdateien aus der Manifestdatei umfasst, müssen Sie keine Änderungen an der Verarbeitung der Ergebnisse vornehmen. Der vorhandene Ansatz funktioniert weiterhin nahtlos mit dem aktualisierten Feature.

Dies wird nicht empfohlen, ist aber möglich. Bitten Sie über Ihre Supportkanäle darum, dieses Feature zu deaktivieren.

Bitte wenden Sie sich an Ihr aktuelles Kontoteam und Ihre Supportkanäle.

Diese Änderung wird ab dem 1. September 2023 schrittweise eingeführt.

Nein. Die Metriken für Datenträger werden von Azure Compute unterstützt. Weitere Informationen finden Sie unter Metriken pro Datenträger für verwaltete und nicht verwaltete Datenträger.

Einige Azure-Metrikdiagramme, z. B. diejenigen, die Verfügbarkeits- und Latenzdaten anzeigen, verwenden eine gestrichelte Linie, um anzugeben, dass zwischen zwei bekannten Datenpunkten des Aggregationsintervalls ein fehlender Wert (auch als NULL-Wert bekannt) liegt. Wenn Sie beispielsweise in der Zeitauswahl die Zeitgranularität 1 minute ausgewählt haben, aber die Metrik um 07:26, 07:27, 07:29 und 07:30 gemeldet wurde, verbindet eine gestrichelte die Werte 07:27 und 07:29, da zwischen diesen beiden Datenpunkten eine Minutenlücke besteht. Eine ausgezogene Linie verbindet alle anderen Datenpunkte. Die gestrichelte Linie fällt auf Null, wenn die Metrik die Aggregation „count“ und „sum“ verwendet. Für die Aggregationen „avg“, „min“ oder „max“ verbindet eine gestrichelte Linie die zwei nächstgelegenen bekannten Datenpunkte. Wenn die Daten außerdem auf der rechten oder linken Seite des Diagramms fehlen, wird die gestrichelte Linie in Richtung des fehlenden Datenpunkts erweitert.

Sie können eine Ressourcenintegritätsbenachrichtigung basierend auf dem Azure Resource Health-Dienst konfigurieren, um die Verfügbarkeit Ihres Speicherkontos nachzuverfolgen. Wenn keine Transaktionen für das Konto vorhanden sind, wird die Benachrichtigung basierend auf der Integrität des Speicherclusters gemeldet, in dem sich Ihr Speicherkonto befindet,.

Die Metriken „Blobkapazität“ und „Blobanzahl“ werden stündlich ausgegeben. Ein Hintergrundprozess berechnet diese Metriken und aktualisiert sie mehrmals pro Tag.

In Analytics-Protokollen werden alle Lese-, Schreib-, Auflistungs- und Löschvorgänge mit erfolgreichen und nicht erfolgreichen Anforderungen für alle Vorgänge erfasst. Analytics-Protokolle werden bestmöglich erstellt und es wird keine Reihenfolge garantiert.

Der Änderungsfeed ist eine Lösung, die Transaktionsprotokolle von erfolgreichen Mutationen oder Änderungen an Ihrem Konto bereitstellt, z B. die Erstellung, Änderung und Löschung von Blobs. Beim Änderungsfeed werden alle Ereignisse garantiert in der Reihenfolge von erfolgreichen Änderungen pro Blob aufgezeichnet und angezeigt. Deshalb müssen keine überflüssigen Daten aus einer großen Menge von Lesevorgängen oder fehlerhaften Anforderungen herausgefiltert werden. Der Änderungsfeed ist grundsätzlich für die Entwicklung von Anwendungen konzipiert und optimiert, die bestimmte Garantien erfordern.

Sie können beide Features nutzen, da der Änderungsfeed und Blob Storage-Ereignisse dieselben Informationen mit derselben garantierten Zuverlässigkeit bei der Übermittlung liefern. Der Hauptunterschied besteht in der Wartezeit, Sortierung und Speicherung von Ereignisdatensätzen. Der Änderungsfeed veröffentlicht Datensätze wenige Minuten nach der Änderung im Protokoll und garantiert außerdem die Reihenfolge von Änderungsvorgängen pro Blob. Blob Storage-Ereignisse werden in Echtzeit per Pushübertragung übermittelt und sind möglicherweise nicht geordnet. Änderungsfeedereignisse werden in Ihrem Speicherkonto dauerhaft als schreibgeschützte, stabile Protokolle gespeichert. Storage-Ereignisse sind dagegen kurzlebig und für die Nutzung durch den Ereignishandler vorgesehen (es sei denn, sie werden explizit gespeichert). Beim Änderungsfeed können die Protokolle von einer beliebigen Anzahl Ihrer Anwendungen nach Bedarf über Blob-APIs oder -SDKs genutzt werden.

Ja. Netzwerksicherheitsregeln für das Speicherkonto, einschließlich IP-basierter und VNET-Firewalls, werden für den Endpunkt der statischen Website unterstützt und können zum Schutz Ihrer Website verwendet werden.

Nein. Eine statische Website unterstützt nur anonymen öffentlichen Lesezugriff für Dateien im Container $web.

Derzeit können Sie eine benutzerdefinierte Domäne mit einer statischen Website mithilfe von Microsoft Azure Content Delivery Network (Azure CDN) konfigurieren. Azure CDN ermöglicht für Ihre Website für alle Zugriffe weltweit eine dauerhaft niedrige Latenz.

Sie können ein benutzerdefiniertes SSL-Zertifikat mit einer statischen Website konfigurieren, indem sie Azure CDN verwenden. Azure CDN ermöglicht für Ihre Website für alle Zugriffe weltweit eine dauerhaft niedrige Latenz.

Sie können den Hostheader für eine statische Website konfigurieren, indem Sie Azure CDN – Verizon Premium verwenden. Wir freuen uns auf Ihr Feedback, das Sie uns hier senden können.

Ein 404-Fehler kann auftreten, wenn Sie mit einer falschen Schreibweise auf einen Dateinamen verweisen. Beispiel: Index.html statt index.html. Bei Dateinamen und Erweiterungen in der URL einer statischen Website wird die Groß-/Kleinschreibung beachtet, auch wenn Sie über HTTP bereitgestellt werden. Dies kann auch passieren, wenn Ihr Azure CDN-Endpunkt noch nicht bereitgestellt wurde. Warten Sie nach der Bereitstellung eines neuen Azure CDN bis zu 90 Minuten, bis die Weitergabe abgeschlossen ist.

Öffnen Sie im Azure-Portal die Konfigurationsseite der statischen Website Ihres Kontos, und suchen Sie den Namen und die Erweiterung, die im Feld Indexdokumentname festgelegt sind. Stellen Sie sicher, dass dieser Name genau mit dem Namen der Datei im $web-Container des Speicherkontos identisch ist. Bei Dateinamen und Erweiterungen in der URL einer statischen Website wird die Groß-/Kleinschreibung beachtet, auch wenn Sie über HTTP bereitgestellt werden.

Nein. Verwenden Sie die Abfragebeschleunigung oder die Azure-Suche, wenn Sie die Inhalte Ihrer Blobdaten durchsuchen müssen.

Blobindextags unterstützen nur String-Datentypen, und bei Abfragen werden Ergebnisse in lexikografischer Reihenfolge zurückgegeben. Zahlen sollten mit Nullen aufgefüllt werden. Datumsangaben und Uhrzeiten sollten in einem ISO 8601-konformen Format gespeichert werden.

Nein, mit Resource Manager-Tags lassen sich Ressourcen der Steuerungsebene organisieren (Abonnements, Ressourcengruppen und Speicherkonten). Indextags ermöglichen die Blobverwaltung und Ermittlung auf der Datenebene.

Speicherkapazität für Blob Storage wird in Einheiten der durchschnittlichen täglich gespeicherten Datenmenge in Gigabyte (GB) über einen monatlichen Zeitraum abgerechnet. Wenn Sie beispielsweise in der ersten Hälfte des Monats durchweg 10 GB Speicher und in der zweiten Hälfte des Monats keinen Speicher nutzen, wird Ihnen eine Nutzung von 5 GB Speicher für diesen Monat in Rechnung gestellt.

Nächste Schritte

Weitere Informationen zu Azure Blob Storage finden Sie unter den folgenden Links:

• Einführung in Azure Storage
• Was ist Azure Blob Storage