Bearbeiten

Freigeben über


Häufig gestellte Fragen zu Azure Blob Storage

Dieser Artikel enthält eine Liste der häufig gestellten Fragen (FAQ) zu Azure Blob Storage.

Richtlinien für die Lebenszyklusverwaltung

Ich habe eine neue Richtlinie erstellt. Warum werden die Aktionen nicht sofort ausgeführt?

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.

Wie lange dauert es nach dem Aktualisieren einer vorhandenen Richtlinie, bis die Aktionen ausgeführt werden?

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.

Die Ausführung wird abgeschlossen, aber einige Blobs werden nicht verschoben oder gelöscht.

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.

Ich sehe keine Kapazitätsänderungen, obwohl die Richtlinie die Blobs ausführt und löscht

Ü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.

Ich habe ein archiviertes Blob aktiviert. Wie kann ich verhindern, dass es vorübergehend zurück auf die Archivspeicherebene verschoben wird?

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.

Der Blob-Präfix-Match-String hat die Richtlinie nicht auf die erwarteten Blobs angewendet

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.

Gibt es eine Möglichkeit, den Zeitpunkt zu identifizieren, zu dem die Richtlinie ausgeführt wird?

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.

Azure Storage-Blobbestand

Ich habe eine neue Bestandsregel erstellt. Wird sie täglich zur gleichen Zeit ausgeführt?

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.

Kann ich erwarten, dass die Regeln zu einer bestimmten Zeit ablaufen?

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.

Ausgabe mehrerer Inventurdateien

Was hat sich in Bezug auf die Anzahl der erstellten Inventurdateien geändert?

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.

Warum wurde die Änderung vorgenommen?

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.

Wie wirkt sich diese Änderung auf mich als Benutzer*in aus?

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.

Sind meine vorhandenen Daten betroffen?

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

Kommt es zu Downtime oder Dienstunterbrechungen?

Nein, die Änderung erfolgt nahtlos.

Muss jetzt irgendetwas anders gehandhabt werden?

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.

Kann ich zum vorherigen Verhalten zurückkehren, wenn mir die Änderung nicht gefällt?

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

Wie kann ich Feedback geben oder Probleme im Zusammenhang mit den Änderungen melden?

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

Wann wird diese Änderungen wirksam?

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

Metriken und Protokolle

Unterstützt Azure Storage Metriken für verwaltete oder nicht verwaltete Datenträger?

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.

Was bedeutet eine gestrichelte Linie in einem Azure-Metrikdiagramm?

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.

Wie verfolge ich die Verfügbarkeit meines Speicherkontos nach?

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,.

Wie oft wird die Blobanzahl- und die Blobkapazitätsmetrik aktualisiert?

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

Unterstützung für Änderungsfeeds

Worin besteht der Unterschied zwischen dem Änderungsfeed und Storage Analytics-Protokollierung?

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.

Sollte ich den Änderungsfeed oder Storage-Ereignisse verwenden?

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.

Hosten von statischen Websites

Funktioniert die Azure Storage Firewall mit einer statischen Website?

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.

Unterstützen statische Websites Microsoft Entra ID?

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

Wie verwende ich eine benutzerdefinierte Domäne mit einer statischen Website?

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.

Wie verwende ich ein benutzerdefiniertes Secure Sockets Layer(SSL)-Zertifikat mit der statischen Website?

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.

Wie füge ich benutzerdefinierte Header und Regeln für die statische Website hinzu?

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.

Warum erhalte ich einen HTTP 404-Fehler von einer statischen Website?

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.

Warum wird das Stammverzeichnis der Website nicht auf die Standardindexseite umgeleitet?

Ö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.

Blobindextags

Kann ich Blobindex zum Filtern und Abfragen von Inhalten in meinen Blobs verwenden?

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

Gibt es Anforderungen für Indextagwerte, die erfüllt werden 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.

Sind Blobindextags mit Azure Resource Manager-Tags verwandt?

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.

Kostenverwaltung

Werden die Kosten anteilig berechnet, wenn ich Azure Blob Storage nur einige Tage im Monat verwende?

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: