Observação
O acesso a essa página exige autorização. Você pode tentar entrar ou alterar diretórios.
O acesso a essa página exige autorização. Você pode tentar alterar os diretórios.
O Armazenamento de Filas do Azure é um serviço para armazenar e distribuir um grande número de mensagens. O Armazenamento de Filas é usado com frequência para criar uma lista de pendências de trabalho a ser processada de forma assíncrona. Ele fornece entrega de mensagens confiáveis para arquiteturas de aplicativo flexivelmente acopladas. Uma única mensagem de fila pode ter até 64 KB de tamanho e uma fila pode conter milhões de mensagens, até o limite de capacidade total de uma conta de armazenamento.
Quando você usa o Azure, a confiabilidade é uma responsabilidade compartilhada. A Microsoft fornece uma variedade de recursos para dar suporte à resiliência e recuperação. Você é responsável por entender como esses recursos funcionam em todos os serviços que você usa e selecionar os recursos necessários para atender aos seus objetivos de negócios e metas de tempo de atividade.
Este artigo descreve como tornar o Armazenamento de Filas resiliente a uma variedade de possíveis interrupções e problemas, incluindo falhas transitórias, interrupções de zona de disponibilidade e interrupções de região. Ele também descreve como você pode usar backups para se recuperar de outros tipos de problemas e realça algumas informações importantes sobre o SLA (contrato de nível de serviço) do Armazenamento de Filas.
Note
O Armazenamento de Filas faz parte da plataforma de Armazenamento do Azure. Alguns dos recursos do Armazenamento de Filas são comuns em muitos serviços de Armazenamento do Azure.
Recomendações de implantação de produção para confiabilidade
Para ambientes de produção:
Habilite o ZRS (armazenamento com redundância de zona) para as contas de armazenamento que contêm recursos de Armazenamento de Filas. O ZRS fornece maior disponibilidade replicando seus dados de forma síncrona em várias zonas de disponibilidade na região primária. A maior disponibilidade ajuda a proteger suas contas de armazenamento contra falhas na zona de disponibilidade.
Se você precisar de resiliência a interrupções de região e a região primária da conta de armazenamento estiver emparelhada, considere habilitar o GRS (armazenamento com redundância geográfica). O GRS replica dados de forma assíncrona para a região emparelhada. Em regiões com suporte, você pode combinar redundância geográfica com redundância de zona usando armazenamento com redundância de zona geográfica (GZRS).
Para requisitos avançados de mensagens, considere usar o Barramento de Serviço do Azure. Para saber mais sobre as diferenças entre o Armazenamento de Filas e o Barramento de Serviço, consulte Comparar filas do Armazenamento do Azure e filas do Barramento de Serviço.
Visão geral da arquitetura de confiabilidade
O Armazenamento de Filas opera como um serviço de mensagens distribuídas dentro da infraestrutura da plataforma de Armazenamento do Azure. O serviço fornece redundância por meio de várias cópias dos dados da fila e da mensagem. O modelo de redundância específico depende da configuração da conta de armazenamento.
O armazenamento com redundância local (LRS) replica os dados em suas contas de armazenamento para uma ou mais zonas de disponibilidade do Azure localizadas na região primária de sua escolha. Embora não haja nenhuma opção para escolher sua zona de disponibilidade preferencial, o Azure pode mover ou expandir contas LRS entre zonas para melhorar o balanceamento de carga. Não há garantia de que seus dados serão distribuídos entre zonas. Para obter informações sobre zonas de disponibilidade, consulte O que são as Zonas de Disponibilidade?.
O armazenamento com redundância de zona (ZRS), o armazenamento com redundância geográfica (GRS) e o armazenamento com redundância de zona geográfica (GZRS) fornecem proteções extras. Este artigo descreve essas opções em detalhes.
Resiliência a falhas transitórias
Falhas transitórias são falhas curtas e intermitentes nos componentes. Elas ocorrem com frequência em um ambiente distribuído, como a nuvem, e são uma parte normal das operações. Falhas transitórias se corrigem após um curto período de tempo. É importante que seus aplicativos possam lidar com falhas transitórias, geralmente repetindo solicitações afetadas.
Todos os aplicativos hospedados na nuvem devem seguir as diretrizes transitórias de tratamento de falhas do Azure quando eles se comunicam com qualquer APIs, bancos de dados e outros componentes hospedados na nuvem. Para obter mais informações, confira Recomendações para tratamento de falhas transitórias.
O Armazenamento de Filas geralmente é usado em aplicativos para ajudá-los a lidar com falhas transitórias em outros componentes. Usando mensagens assíncronas com um serviço como o Armazenamento de Filas, os aplicativos podem se recuperar de falhas transitórias reprocessando mensagens posteriormente. Para saber mais, consulte o Guia de Mensagens Assíncronas.
Dentro do próprio serviço, o Armazenamento de Filas lida automaticamente com falhas transitórias usando vários mecanismos que a plataforma de Armazenamento do Azure e as bibliotecas de clientes fornecem. O serviço foi projetado para fornecer recursos de enfileiramento de mensagens resilientes mesmo durante problemas temporários de infraestrutura.
As bibliotecas de clientes do Armazenamento de Filas do Azure incluem políticas de repetição internas que lidam automaticamente com falhas transitórias comuns, como tempos limite de rede, indisponibilidade de serviço temporário (HTTP 503) e respostas de limitação (HTTP 429). Quando seu aplicativo encontra essas condições transitórias, as bibliotecas de cliente repitam automaticamente as operações usando estratégias de retirada exponencial.
Para gerenciar falhas transitórias efetivamente usando o Armazenamento de Filas, você pode executar as seguintes ações:
Configure tempos limite apropriados em seu cliente de Armazenamento de Filas para equilibrar a capacidade de resposta com resiliência a lentidão temporária. Os tempos limite padrão nas bibliotecas de clientes do Armazenamento do Azure normalmente são adequados para a maioria dos cenários.
Implemente padrões de disjuntor em seu aplicativo quando ele processa mensagens de filas. Os padrões de disjuntor evitam falhas em cascata quando os serviços de downstream apresentam problemas.
Use os tempos limite de visibilidade adequadamente quando seu aplicativo receber mensagens. Os tempos limite de visibilidade garantem que as mensagens fiquem disponíveis para repetição se o aplicativo encontrar falhas durante o processamento.
Para saber mais sobre a arquitetura do Armazenamento de Tabelas do Azure e como criar aplicativos resilientes e de alta escala, consulte a lista de verificação de desempenho e escalabilidade do Armazenamento de Filas.
Resiliência a falhas de zona de disponibilidade
As zonas de disponibilidade são grupos fisicamente separados de datacenters em uma região do Azure. Quando uma zona falha, os serviços podem fazer o failover de uma das zonas restantes.
O Armazenamento de Filas do Azure é com redundância de zona quando implantado com a configuração do ZRS. Ao contrário do LRS, o ZRS garante que o Azure replica de forma síncrona os dados da sua fila em várias zonas de disponibilidade. O ZRS garante que seus dados permaneçam acessíveis mesmo que uma zona experimente uma interrupção. O ZRS garante que suas filas permaneçam acessíveis mesmo se uma zona de disponibilidade inteira ficar indisponível. Todas as operações de gravação devem ser confirmadas em várias zonas antes de serem concluídas, o que fornece garantias de consistência fortes.
A redundância de zona é habilitada no nível da conta de armazenamento e se aplica a todos os recursos de Armazenamento de Filas nessa conta. Você não pode configurar filas individuais para diferentes níveis de redundância. A configuração se aplica a toda a conta de armazenamento. Quando uma zona de disponibilidade sofre uma interrupção, o Armazenamento do Azure roteia automaticamente as solicitações para zonas íntegras sem exigir nenhuma intervenção do aplicativo.
Requirements
- Suporte à região: Você pode implantar contas de Armazenamento do Azure com redundância de zona em qualquer região que dê suporte a zonas de disponibilidade.
- Tipos de conta de armazenamento: Você deve usar uma conta de armazenamento de uso geral padrão v2 para habilitar o ZRS para o Armazenamento de Filas. As contas de armazenamento Premium não dão suporte ao Armazenamento de Filas.
Cost
Ao habilitar o armazenamento com redundância de zona (ZRS), você é cobrado a uma taxa diferente do armazenamento com redundância local (LRS) devido à sobrecarga de armazenamento e replicação extra.
Para obter informações detalhadas sobre preços, consulte Preços do Armazenamento de Filas.
Configurar o suporte à zona de disponibilidade
Crie uma conta de armazenamento com redundância de zona e uma fila seguindo as etapas a seguir.
Crie uma conta de armazenamento e selecione ZRS, GZRS ou armazenamento com redundância de zona geográfica de acesso de leitura (RA-GZRS) como a opção de redundância durante a criação da conta.
Como alterar o tipo de replicação Para saber como alterar uma conta de armazenamento existente para armazenamento com redundância de zona (ZRS) e sobre as opções de configuração e os requisitos, consulte Como alterar a forma como uma conta de armazenamento é replicada.
Desabilite a redundância de zona. Converta contas ZRS novamente em uma configuração não zonal, como armazenamento com redundância local (LRS), usando o mesmo processo de alteração de configuração de redundância.
Comportamento quando todas as zonas estão saudáveis
Esta seção descreve o que esperar quando uma conta de armazenamento de filas é configurada para redundância de zona e todas as zonas de disponibilidade estão operacionais.
Roteamento de tráfego entre zonas: o Armazenamento do Azure com armazenamento com redundância de zona (ZRS) distribui automaticamente solicitações entre clusters de armazenamento em várias zonas de disponibilidade. A distribuição de tráfego é transparente para aplicativos e não requer nenhuma configuração do lado do cliente.
Replicação de dados entre zonas: todas as operações de gravação no ZRS são replicadas de forma síncrona em todas as zonas de disponibilidade dentro da região. Quando você carrega ou modifica dados, a operação não é considerada concluída até que os dados sejam replicados com êxito em todas as zonas de disponibilidade. Essa replicação síncrona garante consistência forte e perda de dados zero durante falhas de zona.
Comportamento durante uma falha de zona
Quando uma zona de disponibilidade fica indisponível, o Armazenamento de Filas lida automaticamente com o processo de failover executando as ações a seguir.
Detecção e resposta: a Microsoft detecta automaticamente falhas de zona e inicia processos de recuperação. Nenhuma ação do cliente é necessária para contas de armazenamento com redundância de zona (ZRS).
Se uma zona se tornar indisponível, o Azure realizará atualizações da rede, como o redirecionamento de DNS (Sistema de Nomes de Domínio).
- Notificação: a Microsoft não notifica você automaticamente quando uma zona está inativa. No entanto, você pode usar o Azure Resource Health para monitorar a integridade de um recurso individual e pode configurar alertas do Resource Health para notificá-lo de problemas. Você também pode usar a Integridade do Serviço do Azure para entender a integridade geral do serviço, incluindo quaisquer falhas de zona, e pode configurar alertas de Integridade do Serviço para notificá-lo de problemas.
Solicitações ativas: As solicitações em voo podem ser descartadas durante o processo de recuperação e devem ser repetidas. Os aplicativos devem implementar a lógica de repetição para lidar com essas interrupções temporárias.
Perda de dados esperada: Nenhuma perda de dados ocorre durante falhas de zona porque os dados são replicados de forma síncrona em várias zonas antes da conclusão das operações de gravação.
Tempo de inatividade esperado: uma pequena quantidade de tempo de inatividade, normalmente, alguns segundos, pode ocorrer durante a recuperação automática, pois o tráfego é redirecionado para zonas saudáveis. Ao criar aplicativos para ZRS, siga práticas para manipulação de falha transitórias, incluindo a implementação de políticas de novas tentativas com retirada exponencial.
- Redirecionamento de tráfego. Se uma zona ficar indisponível, o Azure realizará atualizações de rede, como a renomeação do Sistema de Nomes de Domínio (DNS), para que as solicitações sejam direcionadas para as zonas de disponibilidade íntegras restantes. O serviço mantém a funcionalidade completa utilizando as zonas que permanecem ativas, sem requerer qualquer intervenção do cliente.
Recuperação de zona
Quando a zona de disponibilidade com falha é recuperada, o Armazenamento do Azure restaura automaticamente as operações normais em todas as zonas de disponibilidade. O serviço garante automaticamente a consistência dos dados sincronizando todas as operações que ocorreram durante o período de interrupção.
Testar falhas em zonas
Quando você usa o armazenamento com redundância de zona (ZRS), o Armazenamento do Azure gerencia automaticamente a replicação, o roteamento de tráfego e as respostas de zona para baixo. Como esse recurso é totalmente gerenciado, você não precisa iniciar nem validar processos de falha da zona de disponibilidade.
Resiliência a falhas em toda a região
O Armazenamento do Azure, incluindo o Armazenamento de Blobs do Azure, os Arquivos do Azure, o Armazenamento de Tabelas do Azure e o Armazenamento de Filas do Azure, fornece uma variedade de recursos de redundância geográfica e failover para atender a diferentes requisitos.
Important
O armazenamento com redundância geográfica (GRS) só funciona em regiões emparelhadas do Azure. Se a região da sua conta de armazenamento não estiver emparelhada, considere usar as soluções personalizadas de várias regiões para resiliência.
Armazenamento georredundante para regiões emparelhadas
O Armazenamento do Azure fornece vários tipos de GRS em regiões emparelhadas. Seja qual for o tipo de GRS usado, os dados na região secundária são sempre replicados usando armazenamento com redundância local (LRS). Essa abordagem fornece proteção contra falhas de hardware na região secundária.
O GRS fornece suporte para failovers planejados e não planejados para a região emparelhada do Azure quando há uma interrupção na região primária. O GRS replica de forma assíncrona os dados da região primária para a região emparelhada.
O armazenamento com redundância de zona geográfica (GZRS) replica dados em várias zonas de disponibilidade na região primária e na região emparelhada.
Armazenamento com redundância geográfica
- O armazenamento com redundância geográfica com acesso de leitura (RA-GRS) e o armazenamento com redundância geográfica de zona de acesso de leitura (RA-GZRS) estendem o GRS e o GZRS, com o benefício adicional de acesso de leitura ao ponto de extremidade secundário. Essas opções são ideais para aplicativos criados para aplicativos comercialmente críticos de alta disponibilidade. No caso improvável de o ponto de extremidade primário sofrer uma interrupção, os aplicativos configurados para acesso de leitura à região secundária poderão continuar operando.
Tipos de failover
O Armazenamento do Azure dá suporte a três tipos de failover para cenários diferentes.
Failover não planejado gerenciado pelo cliente: você será responsável por iniciar a recuperação se houver uma falha de armazenamento em toda a região em sua região primária.
Failover planejado gerenciado pelo cliente: Você será responsável por iniciar a recuperação se outra parte da sua solução tiver uma falha em sua região primária e precisar mudar toda a solução para uma região secundária. Use uma recuperação panejada quando o armazenamento permanecer operacional na região primária, mas você precisar fazer o failover de toda a sua solução para uma região secundária, como em exercícios de recuperação de desastres projetados para atender aos requisitos de conformidade e auditoria.
Failover gerenciado pela Microsoft: em circunstâncias excepcionais, a Microsoft pode iniciar o failover para todas as contas GRS (armazenamento com redundância geográfica) em uma região. No entanto, o failover gerenciado pela Microsoft é um último recurso e deve ser executado somente após um longo período de interrupção. Você não deve confiar no failover gerenciado pela Microsoft.
As contas de GRS podem usar qualquer um desses tipos de failover. Você não precisa pré-configurar uma conta de armazenamento para usar qualquer um dos tipos de failover antecipadamente.
Requirements
Suporte à região: As configurações com redundância geográfica do Armazenamento do Azure usam regiões emparelhadas do Azure para replicação de região secundária. A região secundária é determinada automaticamente com base na seleção da região primária e não pode ser personalizada. Para obter uma lista completa de regiões emparelhadas do Azure, consulte a lista de regiões do Azure.
Se a região da sua conta de armazenamento não estiver emparelhada, considere usar as soluções personalizadas de várias regiões para resiliência.
- Tipos de conta de armazenamento: O GRS (armazenamento com redundância geográfica) e o failover e o failback iniciados pelo cliente estão disponíveis em todas as regiões emparelhadas do Azure que dão suporte a contas de Armazenamento do Azure v2 de uso geral.
Considerations
Ao implementar o Armazenamento de Filas de várias regiões, considere os seguintes fatores importantes.
Latência de replicação assíncrona: a replicação de dados para a região secundária é assíncrona, o que significa que há um atraso entre quando os dados são gravados na região primária e quando ficam disponíveis na região secundária. Esse atraso poderá resultar em uma possível perda de dados se ocorrer uma falha na região primária antes que os dados recentes sejam replicados. A perda de dados é medida pelo objetivo de ponto de recuperação (RPO). Você pode esperar que o atraso de replicação seja inferior a 15 minutos, mas esse tempo é uma estimativa e não é garantido.
Você pode verificar a propriedade Hora da Última Sincronização para entender quantos dados podem ser perdidos se sua conta de armazenamento tiver um failover não planejado.
Acesso à região secundária: Com o armazenamento com redundância geográfica (GRS) e configurações de armazenamento com redundância de zona geográfica (GZRS), a região secundária não será acessível para leituras até que ocorra um failover.
O armazenamento com redundância geográfica de acesso de leitura (RA-GRS) e as configurações de armazenamento com redundância de zona geográfica de acesso de leitura (RA-GZRS) fornecem acesso de leitura à região secundária durante operações normais, mas devido à latência de replicação assíncrona, eles podem retornar dados ligeiramente desatualizados.
- Limitações de recursos: alguns recursos do Armazenamento do Azure não têm suporte ou têm limitações quando você usa GRS (armazenamento com redundância geográfica) ou failover gerenciado pelo cliente. Examine a compatibilidade de recursos antes de implementar a redundância geográfica.
Cost
As configurações da conta de Armazenamento do Microsoft Azure de várias regiões incorrem em custos adicionais para replicação e armazenamento entre regiões na região secundária. A transferência de dados entre regiões do Azure é cobrada com base nas taxas de largura de banda entre regiões padrão.
Para obter informações detalhadas sobre preços, consulte Preços do Armazenamento de Filas.
Configurar o suporte a várias regiões
- Crie uma nova conta de armazenamento com redundância geográfica (GRS). Para criar uma conta de GRS, consulte Como criar uma conta de armazenamento e selecionar GRS, armazenamento com redundância geográfica de acesso de leitura (RA-GRS), armazenamento com redundância de zona geográfica (GZRS) ou armazenamento com redundância de zona geográfica de acesso de leitura (RA-GZRS) durante a criação da conta.
Habilite a redundância geográfica em uma conta de armazenamento existente. Para converter uma conta de armazenamento existente em GRS (armazenamento com redundância geográfica), consulte Alterar como uma conta de armazenamento é replicada.
Warning
Depois que sua conta for reconfigurada para redundância geográfica, pode levar uma quantidade significativa de tempo até que os dados existentes na nova região primária sejam totalmente copiados para a nova secundária.
Para evitar uma grande perda de dados, verifique o valor da propriedade Hora da Última Sincronização antes de iniciar um failover não planejado. Para avaliar a possível perda de dados, compare a hora da última sincronização com a última vez em que os dados foram gravados na nova primária.
Habilitar a redundância geográfica Converta contas GRS novamente em configurações de região única, como armazenamento com redundância local (LRS ) ou armazenamento com redundância de zona (ZRS) usando o mesmo processo de alteração de configuração de redundância.
Comportamento quando todas as regiões estão saudáveis
Esta seção descreve o que esperar quando uma conta de armazenamento é configurada para redundância geográfica e todas as regiões estão operacionais.
Roteamento de tráfego entre regiões: o Armazenamento do Azure usa uma abordagem ativa-passiva em que todas as operações de gravação e a maioria das operações de leitura são direcionadas para a região primária.
Para configurações de armazenamento com redundância geográfica de acesso de leitura (RA-GRS) e armazenamento com redundância de zona geográfica de acesso de leitura (RA-GZRS), os aplicativos podem, opcionalmente, ler da região secundária acessando o ponto de extremidade secundário. Essa abordagem requer a configuração explícita do aplicativo e não é automática. Além disso, devido ao atraso de replicação assíncrona, os dados na região secundária podem estar ligeiramente desatualizados.
Replicação de dados entre regiões: as operações de gravação são confirmadas pela primeira vez na região primária usando os seguintes tipos de redundância configurados:
- Armazenamento com redundância local (LRS) para armazenamento com redundância geográfica (GRS) e RA-GRS
- Armazenamento com redundância de zona (ZRS) para armazenamento com redundância de zona geográfica (GZRS) e RA-GZRS
Após a conclusão bem-sucedida na região primária, os dados são replicados de forma assíncrona para a região secundária em que são armazenados usando LRS.
A natureza assíncrona da replicação entre regiões significa que normalmente há um tempo de retardo entre quando os dados são gravados na região primária e quando estão disponíveis na região secundária. Você pode monitorar o tempo de replicação usando a propriedade Hora da Última Sincronização.
Comportamento durante uma falha de região
Esta seção descreve o que esperar quando uma conta de armazenamento é configurada para redundância geográfica e há uma interrupção na região primária.
Failover gerenciado pelo cliente (não planejado): Use um failover não planejado quando o armazenamento na região primária não estiver disponível.
Detecção e resposta: Caso sua conta de armazenamento não esteja disponível em sua região primária, você pode considerar iniciar um failover não planejado gerenciado pelo cliente. Para tomar essa decisão, considere os seguintes fatores:
Se o Azure Resource Health mostra problemas ao acessar a conta de armazenamento em sua região primária
Se a Microsoft aconselhou você a executar failover para outra região
Warning
Um failover não planejado pode resultar em perda de dados. Antes de iniciar um failover gerenciado pelo cliente, decida se a restauração do serviço justifica o risco de perda de dados.
Notificação: a Microsoft não notifica você automaticamente quando uma região está inoperante. No entanto:
Você pode usar o Azure Resource Health para monitorar a integridade de um recurso individual e configurar alertas do Resource Health para notificá-lo de problemas.
Você pode usar a Integridade do Serviço do Azure para entender a integridade geral do serviço, incluindo quaisquer falhas na região, e pode configurar alertas de Integridade do Serviço para notificá-lo de problemas.
Solicitações ativas: Durante o processo de failover, os pontos de extremidade da conta de armazenamento primário e secundário ficam temporariamente indisponíveis para leituras e gravações. Todas as solicitações ativas podem ser descartadas e os aplicativos cliente precisam tentar novamente após a conclusão do failover.
Perda de dados esperada: a perda de dados é comum durante um failover não planejado devido ao atraso de replicação assíncrona, o que significa que as gravações recentes podem não ser replicadas. Você pode verificar a propriedade Hora da Última Sincronização para entender quantos dados podem ser perdidos durante um failover não planejado. A perda de dados esperada geralmente é chamada de RPO (objetivo de ponto de recuperação). Normalmente, você pode esperar que o RPO seja inferior a 15 minutos, mas esse tempo não é garantido.
Tempo de inatividade esperado: A quantidade de tempo de inatividade esperado geralmente é chamada de RTO (objetivo de tempo de recuperação). O failover gerenciado pelo cliente normalmente é concluído dentro de 60 minutos, dependendo do tamanho e da complexidade da conta.
Redirecionamento de tráfego: À medida que o failover é concluído, o Azure atualiza automaticamente os pontos de extremidade da conta de armazenamento para que os aplicativos não precisem ser reconfigurados. Se o aplicativo mantiver as entradas do DNS (Sistema de Nomes de Domínio) armazenadas em cache, talvez seja necessário limpar o cache para garantir que o aplicativo envie tráfego para a nova região primária.
Configuração pós-failover: depois que um failover não planejado for concluído, sua conta de armazenamento na região de destino usará a camada LRS (armazenamento com redundância local). Se você precisar replicá-lo geograficamente novamente, será necessário habilitar novamente o armazenamento com redundância geográfica (GRS) e aguardar que os dados sejam replicados para a nova região secundária.
Para obter mais informações sobre como iniciar o failover gerenciado pelo cliente, consulte Como o failover gerenciado pelo cliente (não planejado) funciona e Como iniciar um failover de conta de armazenamento.
Failover gerenciado pelo cliente (planejado): uma recuperação panejada destina-se a ser usado quando o armazenamento permanece operacional na região primária, mas você precisa fazer failover de toda a solução para uma região secundária por outro motivo. Por exemplo, outro serviço do Azure pode estar enfrentando um problema e você precisa mudar para usar uma região secundária para toda a sua solução. Ou você pode usar uma recuperação planejada para realizar um teste de recuperação de desastre (DR) para fins de conformidade e auditoria.
Detecção e resposta: Você é responsável por decidir fazer failover. Normalmente, você toma essa decisão se precisar fazer failover entre regiões, mesmo que sua conta de armazenamento esteja íntegra. Por exemplo, você pode disparar um *failover* quando houver uma falha grave de outro componente de aplicativo da qual não é possível se recuperar na região primária.
Notificação: a Microsoft não notifica você automaticamente quando uma região está inoperante. No entanto:
Você pode usar o Azure Resource Health para monitorar a integridade de um recurso individual e configurar alertas do Resource Health para notificá-lo de problemas.
Você pode usar a Integridade do Serviço do Azure para entender a integridade geral do serviço, incluindo quaisquer falhas na região, e pode configurar alertas de Integridade do Serviço para notificá-lo de problemas.
Solicitações ativas: Durante o processo de failover, os pontos de extremidade da conta de armazenamento primário e secundário ficam temporariamente indisponíveis para leituras e gravações. Todas as solicitações ativas podem ser descartadas e os aplicativos cliente precisam tentar novamente após a conclusão do failover.
Perda de dados esperada: Nenhuma perda de dados é esperada porque o processo de failover é concluído somente depois que todos os dados são sincronizados, o que resulta em um RPO de zero.
Tempo de inatividade esperado: O failover normalmente é concluído dentro de 60 minutos, o que significa que o RTO esperado é de 60 minutos, dependendo do tamanho e da complexidade da conta. Durante o processo de failover, os pontos de extremidade da conta de armazenamento primário e secundário ficam temporariamente indisponíveis para leituras e gravações.
Redirecionamento de tráfego: À medida que o failover é concluído, o Azure atualiza automaticamente os pontos de extremidade da conta de armazenamento para que os aplicativos não precisem ser reconfigurados. Se o aplicativo mantiver as entradas DNS armazenadas em cache, talvez seja necessário limpar o cache para garantir que o aplicativo envie tráfego para a nova região primária.
Configuração pós-failover: Depois que um failover planejado for concluído, sua conta de armazenamento na região de destino continuará sendo replicada geograficamente e permanecerá na camada GRS.
Para obter mais informações sobre como iniciar o failover gerenciado pelo cliente, consulte Como o failover gerenciado pelo cliente (planejado) funciona e Como iniciar um failover de conta de armazenamento.
Failover gerenciado pela Microsoft: No raro caso de um grande desastre em que a Microsoft determina que a região primária é permanentemente irrecuperável, um failover automático para a região secundária pode ser iniciado. A Microsoft lida com todo o processo e nenhuma ação do cliente é necessária. O tempo decorrido antes do failover depende da gravidade do desastre e do tempo necessário para avaliar a situação.
Notificação: a Microsoft não notifica você automaticamente quando uma região está inoperante. No entanto:
Você pode usar o Azure Resource Health para monitorar a integridade de um recurso individual e configurar alertas do Resource Health para notificá-lo de problemas.
Você pode usar a Integridade do Serviço do Azure para entender a integridade geral do serviço, incluindo quaisquer falhas na região, e pode configurar alertas de Integridade do Serviço para notificá-lo de problemas.
Important
Use as opções de failover gerenciadas pelo cliente para desenvolver, testar e implementar seus planos de recuperação de desastre. Não confie no failover gerenciado pela Microsoft, que só pode ser usado em circunstâncias extremas. Um failover gerenciado pela Microsoft provavelmente é iniciado para uma região inteira. Ele não pode ser iniciado para contas de armazenamento individuais, assinaturas ou clientes. O failover pode ocorrer em horários diferentes para diferentes serviços do Azure. É recomendável usar o failover gerenciado pelo cliente.
Recuperação de região
O processo de failback difere significativamente entre cenários de failover gerenciados pela Microsoft e gerenciados pelo cliente.
Failover gerenciado pelo cliente (não planejado): após um failover não planejado, a conta de armazenamento é configurada com LRS (armazenamento com redundância local). Para realizar o failback, você precisará restabelecer a relação GRS e aguardar a replicação dos dados.
Failover gerenciado pelo cliente (planejado): após um failover planejado, a conta de armazenamento permanece replicada geograficamente. Você poderá iniciar outro failover gerenciado pelo cliente para fazer failback para a região primária original. As mesmas considerações de failover se aplicam.
Failover gerenciado pela Microsoft: se a Microsoft iniciar um failover, é provável que ocorreu um desastre significativo na região primária e a região primária pode não ser recuperável. Quaisquer linhas do tempo ou planos de recuperação dependem da extensão dos esforços regionais de desastre e recuperação. Você deverá monitorar as comunicações de Integridade do Serviço do Azure para obter detalhes.
Teste de falhas na região
Você pode simular falhas regionais para testar os procedimentos de recuperação de desastre.
Teste de failover planejado: para contas de armazenamento com redundância geográfica (GRS), você pode executar operações de recuperação panejada durante as janelas de manutenção para testar o processo completo de failover e failback. Embora a recuperação panejada não exija perda de dados, ele envolve tempo de inatividade durante o failover e o failback.
Teste de ponto de extremidade secundário: para configurações de armazenamento com redundância geográfica de acesso de leitura (RA-GRS) e armazenamento com redundância de zona geográfica de acesso de leitura (RA-GZRS), teste regularmente as operações de leitura no ponto de extremidade secundário para garantir que seu aplicativo possa ler com êxito os dados da região secundária.
Soluções personalizadas de várias regiões para resiliência
Os recursos de failover entre regiões do Armazenamento do Azure podem ser inadequados devido aos seguintes motivos:
Sua conta de armazenamento está em uma região não emparelhada.
Seus objetivos de disponibilidade operacional não são satisfeitos pelo tempo de recuperação ou perda de dados que as opções de failover internas fornecem.
Você precisa fazer failover para uma região que não seja o par da região primária.
Você precisará de uma configuração ativa/ativa entre as regiões.
Esta seção fornece uma visão geral de alto nível de algumas abordagens a serem consideradas. Uma visão geral abrangente das topologias de implantação de várias regiões para o Armazenamento do Azure está fora do escopo deste artigo.
Note
Para requisitos avançados de várias regiões, considere usar o Barramento de Serviço, que inclui suporte para regiões não controladas.
Você pode implantar o Armazenamento do Azure em várias regiões usando contas de armazenamento separadas em cada região. Essa abordagem fornece flexibilidade na seleção de região, a capacidade de usar regiões não emparelhadas e um controle mais granular sobre o tempo de replicação e a consistência dos dados. Ao implementar várias contas de armazenamento entre regiões, você precisa configurar a replicação de dados entre regiões, implementar políticas de failover e balanceamento de carga e garantir a consistência dos dados entre regiões.
Essa abordagem exige que você gerencie a distribuição de mensagens, manipule a sincronização de dados entre filas nas diferentes contas de armazenamento e implemente a lógica de failover personalizada.
Backup e restauração
O Armazenamento de Filas não fornece recursos de backup tradicionais, como restauração pontual (PITR). Isso ocorre porque as filas são projetadas para armazenamento transitório de mensagens em vez de persistência de dados de longo prazo. Normalmente, as mensagens são processadas e removidas das filas durante as operações normais do aplicativo.
Para cenários que exigem durabilidade de mensagens além das opções de redundância internas, considere implementar seu próprio registro em log de mensagens no nível do aplicativo ou persistência em um armazenamento de dados permanente, como o Armazenamento de Blobs ou o Banco de Dados SQL do Azure. Essa abordagem permite que você mantenha o histórico de mensagens enquanto usa o Armazenamento de Filas para a finalidade pretendida de buffer temporário de mensagens e coordenação de processamento.
Contrato de nível de serviço
O SLA (contrato de nível de serviço) para o Armazenamento do Azure descreve a disponibilidade esperada do serviço e as condições que devem ser atendidas para atingir essa expectativa de disponibilidade. O SLA de disponibilidade para o qual você está qualificado depende da camada de armazenamento e do tipo de replicação que você usa. Para obter mais informações, consulte SLAs para serviços online.