Behandeln von Verfügbarkeitsproblemen in Azure-Speicherkonten

  • Artikel

In diesem Artikel erfahren Sie, wie Sie Änderungen an der Verfügbarkeit (z. B. die Anzahl fehlerhafter Anforderungen) untersuchen. Diese Änderungen an der Verfügbarkeit können häufig durch die Überwachung 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 Metrik Verfügbarkeit enthält einen Prozentwert. Es wird berechnet, indem der abrechenbare Gesamtanforderungswert verwendet und durch die Anzahl der anwendbaren Anforderungen dividiert wird, einschließlich der Anforderungen, die zu unerwarteten Fehlern führen.

Jeder Wert unter 100 % gibt an, dass einige Speicheranforderungen 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 verschiebt, um einen besseren Lastenausgleich für Anforderungen zu erzielen. Die Wiederholungslogik in Ihrer Clientanwendung sollte solche zeitweiligen Bedingungen verarbeiten.

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

Metriken zeigen eine Zunahme der Drosselungsfehler an

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

Wenn der ClientThrottlingError- oder ServerBusyError-Wert der ResponseType-Dimension einen Anstieg des Prozentsatzes der Anforderungen anzeigt, bei denen ein Drosselungsfehler auftritt, müssen Sie eines von zwei Szenarien untersuchen:

  • Vorübergehender Anstieg von PercentThrottlingError
  • Permanenter Anstieg des PercentThrottlingError-Fehlers

Eine Zunahme von Drosselungsfehlern tritt häufig gleichzeitig mit einer Erhöhung der Anzahl von Speicheranforderungen oder beim anfänglichen Auslastungstest Ihrer Anwendung auf. Dies kann sich auch im Client als HTTP-status Nachrichten von Speichervorgängen als "503 Server ausgelastet" oder "500 Vorgangstimeout" manifestieren.

Vorübergehender Anstieg der Drosselungsfehler

Wenn Sie Spitzen bei Drosselungsfehlern sehen, die mit Zeiträumen hoher Aktivität für die Anwendung übereinstimmen, implementieren Sie eine exponentielle (nicht lineare) Backoffstrategie für Wiederholungen in Ihrem Client. Backoff-Wiederholungsversuche reduzieren die unmittelbare Last auf der Partition und helfen Ihrer Anwendung, Datenverkehrsspitzen zu glätten. Weitere Informationen zum Implementieren von Wiederholungsrichtlinien mithilfe der Speicherclientbibliothek finden Sie unter der RetryOptions.MaxRetries-Eigenschaft .

Hinweis

Es können auch Spitzen bei Drosselungsfehlern auftreten, die nicht mit Zeiträumen hoher Aktivität für die Anwendung übereinstimmen. Die wahrscheinlichste Ursache ist der Speicherdienst, der Partitionen verschiebt, um den Lastenausgleich zu verbessern.

Permanenter Anstieg der Drosselungsfehler

Wenn sie einen konstant hohen Wert für Drosselungsfehler nach einer dauerhaften Zunahme Ihrer Transaktionsvolumen oder bei der Durchführung ihrer anfänglichen Auslastungstests für Ihre Anwendung feststellen, 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 auftreten (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 in einer Tabelle Drosselungsfehler auftreten, sollten Sie ein anderes Partitionierungsschema verwenden, um Ihre Transaktionen mithilfe eines größeren Bereichs von Partitionsschlüsselwerten auf mehrere Partitionen zu verteilen. Eine häufige Ursache für dieses Problem ist das Antimuster prepend/append, 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 Schreibengpass führen). Ziehen Sie einen anderen Partitionierungsentwurf in Betracht, oder bewerten Sie, ob die Verwendung von BlobSpeicher eine bessere Lösung ist. Überprüfen Sie außerdem, ob eine Drosselung aufgrund von Spitzen im Datenverkehr auftritt, und untersuchen Sie Möglichkeiten, ihr Anforderungsmuster zu glätten.

Wenn Sie Ihre Transaktionen auf mehrere Partitionen verteilen, müssen Sie die für das Speicherkonto festgelegten Skalierbarkeitsgrenzwerte kennen. Wenn Sie z. B. 10 Warteschlangen verwendet haben, die jeweils maximal 2.000 1 KB Nachrichten pro Sekunde verarbeiten, haben Sie das Gesamtlimit von 20.000 Nachrichten pro Sekunde für das Speicherkonto erreicht. Wenn Sie mehr als 20.000 Entitäten pro Sekunde verarbeiten müssen, sollten Sie mehrere Speicherkonten verwenden. Sie sollten auch bedenken, dass sich die Größe Ihrer Anforderungen und Entitäten auf die Drosselung Ihrer Clients durch den Speicherdienst auswirkt. Wenn Sie über größere Anforderungen und Entitäten verfügen, werden Sie möglicherweise früher gedrosselt.

Ineffizienter Abfrageentwurf kann auch dazu führen, dass Sie die Skalierbarkeitsgrenzwerte für Tabellenpartitionen erreichen. Beispielsweise muss eine Abfrage mit einem Filter, der nur ein Prozent der Entitäten in einer Partition auswählt, aber alle Entitäten in einer Partition überprüft, auf jede Entität zugreifen. Jede gelesene Entität wird auf die Gesamtzahl der Transaktionen in dieser Partition angerechnet. Daher können Sie die Skalierbarkeitsziele problemlos erreichen.

Hinweis

Ihre Leistungstests sollten ineffiziente Abfrageentwürfe in Ihrer Anwendung offenlegen.

Metriken zeigen eine Zunahme von Timeoutfehlern an

Timeoutfehler treten auf, wenn die ResponseType-DimensionServerTimeoutError oder ClientTimeout entspricht.

Ihre Metriken zeigen eine Zunahme von Timeoutfehlern für einen Ihrer Speicherdienste an. Gleichzeitig empfängt der Client eine große Menge von HTTP-status Nachrichten von Speichervorgängen mit "500 Vorgangstimeout".

Hinweis

Möglicherweise treten vorübergehend Timeoutfehler auf, wenn der Speicherdienst einen Lastenausgleich für Anforderungen durch Verschieben einer Partition auf einen neuen Server angibt.

Die Servertimeouts (ServerTimeOutError) werden durch einen Fehler auf dem Server verursacht. Die Clienttimeouts (ClientTimeout) treten auf, weil 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.

Servertimeouts deuten auf ein Problem mit dem Speicherdienst hin, das eine weitere Untersuchung erfordert. Mithilfe von Metriken können Sie ermitteln, ob Sie die Skalierbarkeitsgrenzwerte für den Dienst erreichen, und um Spitzen im Datenverkehr zu identifizieren, die dieses Problem verursachen könnten. Wenn das Problem zeitweilig auftritt, kann dies auf eine Lastenausgleichsaktivität im Dienst zurückzuführen sein. Wenn das Problem dauerhaft ist und nicht dadurch verursacht wird, dass Ihre Anwendung die Skalierbarkeitsgrenzen des Diensts erreicht, sollten Sie ein Supportproblem auslösen. Bei 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 eine Zunahme von Netzwerkfehlern an

Netzwerkfehler treten auf, wenn die ResponseType-Dimensiongleich NetworkError ist. Dies tritt auf, wenn ein Speicherdienst einen Netzwerkfehler erkennt, wenn der Client eine Speicheranforderung sendet.

Die häufigste Ursache für diesen Fehler ist ein Client, der die Verbindung trennt, bevor ein Timeout im Speicherdienst abläuft. Untersuchen Sie den Code in Ihrem Client, um zu verstehen, warum und wann der Client die Verbindung mit dem Speicherdienst trennt. Sie können auch Netzwerkanalysetools von Drittanbietern verwenden, um Probleme mit der Netzwerkkonnektivität vom Client zu untersuchen.

Siehe auch

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.