Behandeln von Verfügbarkeitsproblemen in Azure-Speicherkonten

In diesem Artikel können Sie Änderungen der Verfügbarkeit untersuchen (z. B. die Anzahl der fehlgeschlagenen Anforderungen). 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 von Azure Blob Storage
• Überwachen von Azure Files
• Überwachen von Azure Queue Storage
• Überwachen von Azure-Tabellenspeicher

Ü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 bei Drosselungsfehlern

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übergehender Anstieg bei PercentThrottlingError
• Permanenter Anstieg bei PercentThrottlingError

Eine Zunahme der Drosselungsfehler tritt häufig gleichzeitig auf, da die Anzahl der Speicheranforderungen erhöht wird oder wenn Sie die Anwendung anfänglich laden. Dies kann sich auch im Client als HTTP-Status-Meldungen "503 Server Busy" oder "500 Operation Timeout" bei Speicheroperationen äußern.

Vorübergehende Zunahme von Drosselungsfehlern

Wenn Spitzen bei Drosselungsfehlern auftreten, die mit Zeiträumen hoher Aktivität für die Anwendung übereinstimmen, implementieren Sie eine exponentielle (nicht lineare) Back-Off-Strategie für Wiederholungen in Ihrem Client. Back-off-Wiederholungen reduzieren die sofortige Auslastung der Partition und helfen Ihrer Anwendung, Spitzen im Datenverkehr zu glätten. Weitere Informationen zur Implementierung von Wiederholungsrichtlinien unter Verwendung der Storage-Clientbibliothek finden Sie unter der RetryOptions.MaxRetries-Eigenschaft.

Notiz

Möglicherweise werden auch Spitzen bei Drosselungsfehlern angezeigt, die nicht mit Zeiträumen mit hoher Aktivität für die Anwendung übereinstimmen. Die wahrscheinlichste Ursache ist, dass der Speicherdienst Partitionen verschiebt, um den Lastenausgleich zu verbessern.

Dauerhafte Zunahme von Drosselungsfehlern

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 Vor-/Anfüge-Antimuster, bei dem Sie das Datum als Partitionsschlüssel auswählen und dann alle Daten an einem bestimmten Tag in eine Partition geschrieben werden (unter Last kann dies zu einem Schreibengpässe 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 auch berücksichtigen, dass sich die Größe Ihrer Anforderungen und Entitäten auswirkt, wenn der Speicherdienst Ihre Clients drosselt. Wenn Sie größere Anforderungen und Entitäten haben, werden Sie möglicherweise früher 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.

Metriken zeigen einen Anstieg bei Timeoutfehlern

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. Zugleich erhält der Client ein hohes Volumen an HTTP-Status-Meldungen "500 Operation Timeout" von Speicheroperationen.

Hinweis

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.

Weitere Informationen

• Behandeln von Clientanwendungsfehlern
• Behandeln von Leistungsproblemen
• Überwachung, Diagnose und Problembehandlung in Azure Storage

Kontaktieren Sie uns für Hilfe

Wenn Sie Fragen haben oder Hilfe mit Ihren Azure-Gutschriften benötigen, dann erstellen Sie beim Azure-Support eine Support-Anforderung oder fragen Sie den Azure Community-Support. Sie können auch Produktfeedback an die Azure Feedback Community senden.