Behandeln von Verfügbarkeitsproblemen in Azure-Speicherkonten

In diesem Artikel können Sie Veränderungen bei der Verfügbarkeit untersuchen (z. B. die Anzahl der fehlgeschlagenen Anfragen). Diese Änderungen an der Verfügbarkeit können häufig durch das Überwachen von Speichermetriken in Azure Monitor identifiziert werden. Allgemeine Informationen zur Verwendung von Metriken und Protokollen in Azure Monitor finden Sie in den folgenden Artikeln:

Überwachen der Verfügbarkeit

Sie sollten die Verfügbarkeit der Speicherdienste in Ihrem Speicherkonto überwachen, indem Sie den Wert der Metrik Verfügbarkeit überwachen. Die Verfügbarkeitsmetrik enthält einen Prozentwert. Es wird berechnet, indem der Gesamtwert von abgerechneten Anforderungen berechnet und durch die Anzahl der anwendbaren Anforderungen geteilt wird, einschließlich der Anforderungen, die unerwartete Fehler verursacht haben.

Jeder unter 100 % liegende Wert zeigt an, dass einige Speicheranfragen fehlschlagen. Sie können sehen, warum sie fehlschlagen, indem Sie die ResponseType-Dimension auf Fehlertypen wie ServerTimeoutError untersuchen. Sie sollten davon ausgehen, dass die Verfügbarkeit vorübergehend unter 100 % fällt, z. B. vorübergehende Servertimeouts, während der Dienst Partitionen zu besseren Lastenausgleichsanforderungen verschiebt. Die Wiederholungslogik in Ihrer Clientanwendung sollte solche zeitweiligen Bedingungen verarbeiten. Die Verfügbarkeitsmetrik ist nur für Zeiträume verfügbar, in denen Transaktionen auch auf dem Konto auftreten.

Sie können Features in Azure Monitor verwenden, um Benachrichtigungen zu erhalten, wenn die Verfügbarkeit für einen Dienst unter einen von Ihnen angegebenen Schwellenwert fällt.

Metriken zeigen einen Anstieg von Throttlingfehlern

Drosselungsfehler treten auf, wenn Sie die Skalierbarkeitsziele eines Speicherdiensts überschreiten. Der Speicherdienst drosselt, um sicherzustellen, dass kein einzelner Client oder Mandant diesen Dienst auf Kosten anderer verwenden kann. Weitere Informationen zu Skalierbarkeitszielen für Speicherkonten und Leistungszielen für Partitionen in Speicherkonten finden Sie unter Skalierbarkeits- und Leistungsziele für Standardspeicherkonten.

Wenn die Metriken ClientThrottlingError oder ServerBusyError für die ResponseType-Dimension einen Anstieg des Prozentsatzes der Anforderungen anzeigt, die mit einem Drosselungsfehler scheitern, sollten Sie eines der folgenden beiden Szenarien untersuchen:

  • Vorübergehende Zunahme von Drosselungsfehlern
  • Dauerhafter Anstieg von Throttling-Fehlern

Eine Zunahme von Fehlern durch Drosselung tritt häufig gleichzeitig mit einer steigenden Anzahl von Speicheranforderungen auf oder wenn Sie Ihre Anwendung erstmals einem Lasttest unterziehen. Dies kann sich auch im Client als HTTP-Status-Meldungen "503 Server Busy" oder "500 Operation Timeout" bei Speicheroperationen äußern.

Important

Eine erhöhte Drosselung weist nicht immer darauf hin, dass ein Speicherkonto seine allgemeinen Skalierbarkeitsgrenzwerte erreicht hat. Eine Drosselung kann auftreten, wenn eine Arbeitslast eine hohe Anzahl von Anfragen auf eine kleine Anzahl von Partitionsschlüsseln bündelt, wodurch eine heiße Partition entsteht. In diesen Situationen können Anwendungen eine erhöhte Latenz aufweisen oder HTTP 503 (Server Busy)- und HTTP 500 (Operation Timeout)-Antworten erhalten. Um die Drosselung zu reduzieren, implementieren Sie eine exponentielle Backoff-Wiederholungsrichtlinie und entwerfen Workloads, sodass Anforderungen über Partitionen verteilt werden. Vermeiden Sie Benennungsmuster, die den Datenverkehr auf einen kleinen Bereich von Blobnamen konzentrieren, und lesen Sie die Empfehlungen zur Minderung von Hot Partitions, wenn die Drosselung anhält. Weitere Informationen finden Sie unter Mitigate hot partitions in Azure Blob Storage.

Vorübergehende Zunahme von Drosselungsfehlern

Wenn bei Ihnen vermehrt Drosselungsfehler auftreten, die mit Zeiträumen hoher Aktivität in der Anwendung zusammenfallen, sollten Sie in Ihrem Client eine exponentielle (nicht lineare) Backoff-Strategie für Wiederholungsversuche implementieren. Wiederholungsversuche mit Backoff reduzieren die unmittelbare Belastung der Partition und helfen Ihrer Anwendung, Lastspitzen im Datenverkehr abzufedern. Weitere Informationen zur Implementierung von Wiederholungsrichtlinien unter Verwendung der Storage-Clientbibliothek finden Sie unter der RetryOptions.MaxRetries-Eigenschaft.

Notiz

Möglicherweise treten auch Spitzen bei Drosselungsfehlern auf, die nicht mit Zeiträumen hoher Aktivität in der Anwendung zusammenfallen. Die wahrscheinlichste Ursache ist, dass der Speicherdienst Partitionen verschiebt, um den Lastenausgleich zu verbessern.

Dauerhafter Anstieg von Throttling-Fehlern

Wenn bei Drosselungsfehlern nach einer dauerhaften Erhöhung der Transaktionsvolumes oder beim Ausführen der anfänglichen Auslastungstests für Ihre Anwendung ein konsistent hoher Wert angezeigt wird, müssen Sie bewerten, wie Ihre Anwendung Speicherpartitionen verwendet und ob sie sich den Skalierbarkeitszielen für ein Speicherkonto nähert. Wenn z. B. Drosselungsfehler in einer Warteschlange angezeigt werden (die als einzelne Partition zählt), sollten Sie die Verwendung zusätzlicher Warteschlangen in Betracht ziehen, um die Transaktionen auf mehrere Partitionen zu verteilen. Wenn Drosselungsfehler in einer Tabelle auftreten, sollten Sie ein anderes Partitionierungsschema verwenden, um Ihre Transaktionen über mehrere Partitionen zu verteilen, indem Sie einen größeren Bereich von Partitionsschlüsselwerten verwenden. Eine häufige Ursache für dieses Problem ist das Prepend-/Append-Anti-Pattern, bei dem Sie das Datum als Partitionsschlüssel auswählen und dann alle Daten eines bestimmten Tages in eine einzige Partition geschrieben werden (unter Last kann dies zu einem Schreibengpass führen). Ziehen Sie einen anderen Partitionierungsentwurf in Betracht, oder bewerten Sie, ob die Verwendung von BLOB-Speicher eine bessere Lösung sein könnte. Überprüfen Sie außerdem, ob die Drosselung aufgrund von Spitzen in Ihrem Datenverkehr auftritt, und untersuchen Sie, wie Sie Ihr Anforderungsmuster glätten.

Wenn Sie Ihre Transaktionen über mehrere Partitionen verteilen, müssen Sie die für das Speicherkonto eingestellten Skalierbarkeitsgrenzen kennen. Wenn Sie z. B. 10 Warteschlangen verwendet haben und jeweils maximal 2.000 1 KB Nachrichten pro Sekunde verarbeiten, beträgt die Gesamtgrenze von 20.000 Nachrichten pro Sekunde für das Speicherkonto. Wenn Sie mehr als 20.000 Entitäten pro Sekunde verarbeiten müssen, erwägen Sie die Verwendung mehrerer Speicherkonten. Sie sollten außerdem beachten, dass sich die Größe Ihrer Anfragen und Entitäten darauf auswirkt, wann der Speicherdienst Ihre Clients drosselt. Wenn Sie mehr Anfragen und Entitäten haben, werden Sie möglicherweise eher gedrosselt.

Ineffiziente Abfragemuster können ebenfalls dazu führen, dass Sie an die Skalierbarkeitsgrenzen für Tabellenpartitionen stoßen. Zum Beispiel benötigt eine Abfrage mit einem Filter, der nur ein Prozent der Einheiten in einer Partition auswählt, aber alle Objekte in einer Partition scannt, Zugriff auf jede Entität. Jeder Entitätslesevorgang zählt zur Gesamtzahl der Transaktionen in dieser Partition. Daher können Sie die Skalierbarkeitsziele leicht erreichen.

Notiz

Ihr Leistungstest sollte ineffiziente Abfragemuster in Ihrer Anwendung aufdecken.

Die Metriken zeigen einen Anstieg der Timeoutfehler

Timeoutfehler treten auf, wenn die ResponseType-Dimension gleich ServerTimeoutError oder ClientTimeout ist.

Ihre Metriken zeigen einen Anstieg bei Timeoutfehlern für einen Ihrer Speicherdienste an. Gleichzeitig erhält der Client bei Speicheroperationen eine große Anzahl von HTTP-Statusmeldungen „500 Operation Timeout“.

Notiz

Timeout-Fehler werden vorübergehend angezeigt, während der Speicherdienst Lasten durch Verschieben einer Partition zu einem neuen Server ausgleicht.

Die Servertimeouts (ServerTimeOutError) werden durch einen Fehler auf dem Server verursacht. Die Clienttimeouts (ClientTimeout) treten auf, da ein Vorgang auf dem Server das vom Client angegebene Timeout überschritten hat. Beispielsweise kann ein Client, der die Speicherclientbibliothek verwendet, ein Timeout für einen Vorgang festlegen.

Server-Timeouts zeigen ein Problem mit dem Speicherdienst an, das weitere Untersuchung erfordert. Sie können Metriken verwenden, um zu überprüfen, ob Sie die Skalierbarkeitsgrenzen für den Dienst erreichen, und alle Datenverkehrsspitzen zu identifizieren, die dieses Problem verursachen könnten. Wenn das Problem periodisch auftritt, kann es durch Lastenausgleich im Dienst verursacht sein. Wenn das Problem anhält und nicht dadurch verursacht wird, dass Ihre Anwendung die Dienstskalierbarkeitsgrenzen erreicht, sollten Sie eine Supportanfrage öffnen. Für Clienttimeouts müssen Sie entscheiden, ob das Timeout auf einen geeigneten Wert im Client festgelegt ist, und entweder den im Client festgelegten Timeoutwert ändern oder untersuchen, wie Sie die Leistung der Vorgänge im Speicherdienst verbessern können, z. B. indem Sie Ihre Tabellenabfragen optimieren oder die Größe Ihrer Nachrichten verringern.

Metriken zeigen einen Anstieg bei Netzwerkfehlern

Netzwerkfehler treten auf, wenn die ResponseType-Dimension gleich NetworkError ist. Diese treten auf, wenn ein Speicherdienst bei einer Speicheranforderung des Client einen Netzwerkfehler entdeckt.

Die häufigste Ursache für diesen Fehler ist eine Trennung der Client-Verbindung vor Ablauf eines Timeouts im Speicherdienst. Untersuchen Sie den Code in Ihrem Client, um herauszufinden, warum und wann der Client die Verbindung zum Speicherdienst abbricht. Sie können auch Netzwerkanalysetools von Drittanbietern verwenden, um Netzwerkkonnektivitätsprobleme über den Client zu untersuchen.

Siehe auch

  • Last updated on