Solucionar problemas de disponibilidade em contas de armazenamento do Azure

  • Artigo

Este artigo ajuda você a investigar alterações na disponibilidade (como o número de solicitações com falha). Essas alterações na disponibilidade geralmente podem ser identificadas monitorando as métricas de armazenamento no Azure Monitor. Para obter informações gerais sobre como usar métricas e logs no Azure Monitor, confira os seguintes artigos:

Disponibilidade de monitoramento

Você deve monitorar a disponibilidade dos serviços de armazenamento em sua conta de armazenamento monitorando o valor da métrica de disponibilidade . A métrica de disponibilidade contém um valor percentual. Ele é calculado pegando o valor total de solicitações faturadas e dividindo-o pelo número de solicitações aplicáveis, incluindo aquelas solicitações que produziram erros inesperados.

Qualquer valor inferior a 100% indica que algumas solicitações de armazenamento estão falhando. Você pode ver por que eles estão falhando examinando a dimensão ResponseType para tipos de erro, como ServerTimeoutError. Você deve esperar ver a disponibilidade cair temporariamente abaixo de 100% por motivos como tempo limite de servidor transitório, enquanto o serviço move partições para melhores solicitações de balanceamento de carga; a lógica de repetição em seu aplicativo cliente deve lidar com essas condições intermitentes.

Você pode usar recursos no Azure Monitor para alertá-lo se a disponibilidade de um serviço estiver abaixo de um limite especificado.

As métricas mostram um aumento nos erros de limitação

Erros de limitação ocorrem quando você excede as metas de escalabilidade de um serviço de armazenamento. O serviço de armazenamento limita para garantir que nenhum cliente ou locatário possa usar o serviço às custas de outras pessoas. Para obter mais informações, consulte Escalabilidade e metas de desempenho para contas de armazenamento padrão para obter detalhes sobre metas de escalabilidade para contas de armazenamento e metas de desempenho para partições em contas de armazenamento.

Se o valor ClientThrottlingError ou ServerBusyError da dimensão ResponseType mostrar um aumento no percentual de solicitações que estão falhando com um erro de limitação, você precisará investigar um dos dois cenários:

  • Aumento transitório em PercentThrottlingError
  • Aumento permanente no erro PercentThrottlingError

Um aumento de erros de limitação geralmente ocorre ao mesmo tempo que um aumento no número de solicitações de armazenamento ou quando você está inicialmente testando seu aplicativo. Isso também pode se manifestar no cliente como "503 Server Busy" ou "500 Operation Timeout" HTTP status mensagens de operações de armazenamento.

Aumento transitório de erros de limitação

Se você estiver vendo picos de erros de limitação que coincidem com períodos de alta atividade para o aplicativo, você implementará uma estratégia de back-off exponencial (não linear) para repetições em seu cliente. As tentativas de back-off reduzem a carga imediata na partição e ajudam seu aplicativo a suavizar os picos de tráfego. Para obter mais informações sobre como implementar políticas de repetição usando a Biblioteca de Clientes de Armazenamento, consulte a propriedade RetryOptions.MaxRetries .

Observação

Você também pode ver picos de erros de limitação que não coincidem com períodos de alta atividade para o aplicativo. A causa mais provável é o serviço de armazenamento movendo partições para melhorar o balanceamento de carga.

Aumento permanente de erros de limitação

Se você estiver vendo um valor consistentemente alto para limitação de erros após um aumento permanente em seus volumes de transação ou quando estiver executando seus testes de carga iniciais em seu aplicativo, você precisará avaliar como seu aplicativo está usando partições de armazenamento e se ele está se aproximando dos destinos de escalabilidade de uma conta de armazenamento. Por exemplo, se você estiver vendo erros de limitação em uma fila (que conta como uma única partição), considere usar filas adicionais para espalhar as transações em várias partições. Se você estiver vendo erros de limitação em uma tabela, considere usar um esquema de partição diferente para espalhar suas transações em várias partições usando um intervalo mais amplo de valores de chave de partição. Uma causa comum desse problema é o anti-padrão prepend/acréscimo, em que você seleciona a data como a chave de partição e, em seguida, todos os dados em um determinado dia são gravados em uma partição (sob carga, isso pode resultar em um gargalo de gravação). Considere um design de partição diferente ou avalie se usar o armazenamento de blobs pode ser uma solução melhor. Além disso, marcar se a limitação está ocorrendo devido a picos no tráfego e investigar maneiras de suavizar seu padrão de solicitações.

Se você distribuir suas transações em várias partições, ainda deverá estar ciente dos limites de escalabilidade definidos para a conta de armazenamento. Por exemplo, se você usou 10 filas, cada uma processando o máximo de 2.000 mensagens 1KB por segundo, estará no limite geral de 20.000 mensagens por segundo para a conta de armazenamento. Se você precisar processar mais de 20.000 entidades por segundo, considere usar várias contas de armazenamento. Você também deve ter em mente que o tamanho de suas solicitações e entidades afeta quando o serviço de armazenamento limita seus clientes. Se você tiver solicitações e entidades maiores, poderá ser limitado mais cedo.

O design de consulta ineficiente também pode fazer com que você atinja os limites de escalabilidade para partições de tabela. Por exemplo, uma consulta com um filtro que seleciona apenas um por cento das entidades em uma partição, mas que verifica todas as entidades em uma partição precisará acessar cada entidade. Cada leitura de entidade contará para o número total de transações nessa partição. Portanto, você pode alcançar facilmente os destinos de escalabilidade.

Observação

Seu teste de desempenho deve revelar quaisquer designs de consulta ineficientes em seu aplicativo.

As métricas mostram um aumento nos erros de tempo limite

Erros de tempo limite ocorrem quando a dimensão ResponseType é igual a ServerTimeoutError ou ClientTimeout.

Suas métricas mostram um aumento de erros de tempo limite para um de seus serviços de armazenamento. Ao mesmo tempo, o cliente recebe um grande volume de mensagens HTTP status "500 Operation Timeout" de operações de armazenamento.

Observação

Você pode ver erros de tempo limite temporariamente à medida que o serviço de armazenamento equilibra as solicitações movendo uma partição para um novo servidor.

Os tempo limite do servidor (ServerTimeOutError) são causados por um erro no servidor. Os tempo limite do cliente (ClientTimeout) acontecem porque uma operação no servidor excedeu o tempo limite especificado pelo cliente. Por exemplo, um cliente que usa a Biblioteca de Clientes de Armazenamento pode definir um tempo limite para uma operação.

Os tempos limite do servidor indicam um problema com o serviço de armazenamento que requer uma investigação mais aprofundada. Você pode usar métricas para ver se está atingindo os limites de escalabilidade do serviço e identificar quaisquer picos no tráfego que possam estar causando esse problema. Se o problema for intermitente, pode ser devido à atividade de balanceamento de carga no serviço. Se o problema for persistente e não for causado pelo seu aplicativo atingir os limites de escalabilidade do serviço, você deverá gerar um problema de suporte. Para tempo limite do cliente, você deve decidir se o tempo limite está definido como um valor apropriado no cliente e alterar o valor de tempo limite definido no cliente ou investigar como você pode melhorar o desempenho das operações no serviço de armazenamento, por exemplo, otimizando suas consultas de tabela ou reduzindo o tamanho das mensagens.

As métricas mostram um aumento nos erros de rede

Erros de rede ocorrem quando a dimensão ResponseType é igual a NetworkError. Isso ocorre quando um serviço de armazenamento detecta um erro de rede quando o cliente faz uma solicitação de armazenamento.

A causa mais comum desse erro é a desconexão de um cliente antes que um tempo limite expire no serviço de armazenamento. Investigue o código em seu cliente para entender por que e quando o cliente se desconecta do serviço de armazenamento. Você também pode usar ferramentas de análise de rede de terceiros para investigar problemas de conectividade de rede do cliente.

Confira também

Entre em contato conosco para obter ajuda

Se você tiver dúvidas ou precisar de ajuda, crie uma solicitação de suporte ou peça ajuda à comunidade de suporte do Azure. Você também pode enviar comentários sobre o produto para a comunidade de comentários do Azure.