Nota
O acesso a esta página requer autorização. Podes tentar iniciar sessão ou mudar de diretório.
O acesso a esta página requer autorização. Podes tentar mudar de diretório.
O Azure Queue Storage é um serviço para armazenar e distribuir um grande número de mensagens. O armazenamento em fila é comumente usado para criar uma lista de pendências de trabalho para processar de forma assíncrona. Ele fornece entrega de mensagens confiável para arquiteturas de aplicativos com acoplamento flexível. Uma 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 oferecer 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 em Fila resiliente a uma variedade de potenciais interrupções e problemas, incluindo falhas transitórias, interrupções em zonas de disponibilidade e interrupções regionais. Descreve também como pode usar backups para recuperar de outros tipos de problemas e destaca algumas informações chave sobre o acordo de nível de serviço (SLA) de Armazenamento em Fila.
Note
O Armazenamento em Fila faz parte da plataforma de Armazenamento do Azure. Alguns dos recursos do Armazenamento em Fila 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 em Fila. O ZRS oferece maior disponibilidade replicando seus dados de forma síncrona em várias zonas de disponibilidade na região primária. Uma 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 principal da sua conta de armazenamento estiver emparelhada, considere habilitar o armazenamento com redundância geográfica (GRS). O GRS replica dados de forma assíncrona para a região emparelhada. Em regiões compatíveis, você pode combinar redundância geográfica com redundância de zona usando GZRS (armazenamento com redundância de zona geográfica).
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 de 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ído dentro da infraestrutura da plataforma de Armazenamento do Azure. O serviço fornece redundância por meio de várias cópias da fila e dos dados da mensagem. O modelo de redundância específico depende da configuração da sua conta de armazenamento.
O LRS (armazenamento com redundância local) 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 opção para escolher sua zona de disponibilidade preferida, 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 espalhados por zonas. Para obter mais informações sobre zonas de disponibilidade, consulte O que são 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 em componentes. Eles ocorrem com frequência em um ambiente distribuído, como a nuvem, e são uma parte normal das operações. As falhas transitórias corrigem-se após um curto período de tempo. É importante que seus aplicativos possam lidar com falhas transitórias, geralmente tentando novamente as solicitações afetadas.
Todos os aplicativos hospedados na nuvem devem seguir as diretrizes de tratamento de falhas transitórias do Azure quando se comunicam com quaisquer APIs, bancos de dados e outros componentes hospedados na nuvem. Para obter mais informações, consulte Recomendações para o tratamento de falhas transitórias.
O armazenamento em fila é comumente 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 em Fila, os aplicativos podem se recuperar de falhas transitórias reprocessando mensagens posteriormente. Para saber mais, consulte Cartilha de mensagens assíncrona.
Dentro do próprio serviço, o Armazenamento em Fila lida com falhas transitórias automaticamente usando vários mecanismos fornecidos pela plataforma de Armazenamento do Azure e pelas bibliotecas de cliente. O serviço foi projetado para fornecer recursos resilientes de enfileiramento de mensagens, mesmo durante problemas temporários de infraestrutura.
As bibliotecas de cliente de armazenamento em fila incluem políticas de repetição internas que lidam automaticamente com falhas transitórias comuns, como tempos limite de rede, indisponibilidade temporária do serviço (HTTP 503) e respostas de limitação (HTTP 429). Quando seu aplicativo encontra essas condições transitórias, as bibliotecas de cliente tentam operações automaticamente usando estratégias de backoff exponencial.
Para gerenciar falhas transitórias de forma eficaz usando o Armazenamento em Fila, você pode executar as seguintes ações:
Configure tempos limite apropriados no seu cliente de Armazenamento de Fila para equilibrar a capacidade de resposta com a resiliência face a lentidão temporária. Os tempos limite padrão nas bibliotecas de cliente do Armazenamento do Azure geralmente são adequados para a maioria dos cenários.
Implemente padrões de disjuntor em seu aplicativo quando ele processar mensagens de filas. Os padrões dos disjuntores evitam falhas em cascata quando os serviços a jusante 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 Tabela do Azure e como projetar aplicativos resilientes e de alta escala, consulte Lista de verificação de desempenho e escalabilidade para armazenamento em fila.
Resiliência a falhas na zona de disponibilidade
As zonas de disponibilidade são grupos fisicamente separados de centros de dados dentro de uma região Azure. Quando uma zona falha, os serviços podem ser transferidos para uma das zonas restantes.
O Armazenamento de Filas do Azure é redundante 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 fila em várias zonas de disponibilidade. O ZRS garante que seus dados permaneçam acessíveis mesmo se uma zona sofrer 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 reconhecidas em várias zonas antes de serem concluídas, o que fornece fortes garantias de consistência.
A redundância de zona é habilitada no nível da conta de armazenamento e se aplica a todos os recursos de armazenamento em fila nessa conta. Não é possível 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 encaminha automaticamente as solicitações para zonas íntegras sem exigir qualquer intervenção do seu aplicativo.
Requirements
- Apoio regional: Pode implementar contas de Azure Storage redundantes em qualquer região que suporte zonas de disponibilidade.
- Tipos de contas de armazenamento: Deve usar uma conta de armazenamento padrão v2 de uso geral para ativar o ZRS para armazenamento em fila. As contas de armazenamento premium não suportam o Armazenamento em Fila.
Cost
Quando você habilita o armazenamento com redundância de zona (ZRS), é cobrado a uma taxa diferente do LRS (armazenamento com redundância local) devido à sobrecarga extra de replicação e armazenamento.
Para obter informações detalhadas sobre preços, consulte Preços de armazenamento em fila.
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.
Altere o tipo de replicação. Para saber como alterar uma conta de armazenamento existente para ZRS (armazenamento com redundância de zona) e sobre opções e requisitos de configuração, consulte Alterar a forma como uma conta de armazenamento é replicada.
Desative a redundância de zona. Converta contas ZRS de volta para uma configuração não zonal, como LRS (armazenamento com redundância local), usando o mesmo processo de alteração de configuração de redundância.
Comportamento quando todas as zonas estão íntegras
Esta seção descreve o que esperar quando uma conta de armazenamento de fila é 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 as solicitações entre clusters de armazenamento em várias zonas de disponibilidade. A distribuição do tráfego é transparente para os 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 da região. Quando você carrega ou modifica dados, a operação não é considerada concluída até que os dados tenham sido replicados com êxito em todas as zonas de disponibilidade. Essa replicação síncrona garante forte consistência e zero perda de dados durante falhas de zona.
Comportamento durante uma falha de zona
Quando uma zona de disponibilidade fica indisponível, o Armazenamento em Fila lida automaticamente com o processo de failover executando as seguintes ações.
Deteção e resposta: A Microsoft deteta automaticamente falhas de zona e inicia processos de recuperação. Nenhuma ação do cliente é necessária para contas ZRS (zone-redundant storage, armazenamento com redundância de zona).
Se uma zona ficar indisponível, o Azure realizará atualizações de rede, como o redirecionamento do DNS (Sistema de Nomes de Domínio).
- Notificação: a Microsoft não o notifica automaticamente quando uma zona está inativa. No entanto, pode utilizar o Azure Resource Health para monitorizar a integridade de um recurso individual, e pode configurar alertas de integridade de recursos para notificá-lo de problemas. Também pode usar o Azure Service Health para compreender o estado geral do serviço, incluindo quaisquer falhas de zona, e pode configurar alertas de Service Health para o notificar de problemas.
Solicitações ativas: As solicitações durante o 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 à medida que o tráfego é redirecionado para zonas saudáveis. Ao projetar aplicativos para ZRS, siga as práticas para tratamento de falhas transitórias, incluindo a implementação de políticas de repetição com back-off exponencial.
- Reencaminhamento do tráfego. Se uma zona ficar indisponível, o Azure realizará atualizações de rede, como o redirecionamento do DNS (Sistema de Nomes de Domínio), para que as solicitações sejam direcionadas para as zonas de disponibilidade íntegras restantes. O serviço mantém a funcionalidade completa usando as zonas sobreviventes, sem necessidade de intervenção do cliente.
Recuperação de zona
Quando a zona de disponibilidade com falha se recupera, 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.
Teste de falhas de zona
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 zone-down. Como esse recurso é totalmente gerenciado, você não precisa iniciar ou 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, Arquivos do Azure, Armazenamento de Tabela do Azure e 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 soluções multi-região personalizadas para resiliência.
Armazenamento geo-redundante 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 o LRS (armazenamento com redundância local). 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 dados de forma assíncrona 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 georredundante
- O armazenamento com redundância geográfica de acesso de leitura (RA-GRS) e o armazenamento com redundância de zona geográfica de acesso de leitura (RA-GZRS) estendem o armazenamento com redundância geográfica (GRS) e o armazenamento com redundância de zona geográfica (GZRS), com o benefício adicional do acesso de leitura ao endpoint secundário. Essas opções são ideais para soluções projetadas para aplicações críticas de negócios com alta disponibilidade. No caso improvável do endpoint primário sofrer uma interrupção, as aplicações configuradas para acesso de leitura à região secundária podem continuar a operar.
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ê é responsável por iniciar a recuperação se houver uma falha de armazenamento em toda a região principal.
Failover planejado gerenciado pelo cliente: Você é responsável por iniciar a recuperação se outra parte da solução tiver uma falha na região primária e precisar alternar toda a solução para uma região secundária. Use um failover planejado quando o armazenamento permanecer operacional na região principal, mas você precisar fazer failover de toda a solução para uma região secundária, como para exercícios de recuperação de desastres projetados para garantir os requisitos de conformidade e auditoria.
Failover gerenciado pela Microsoft: Em circunstâncias excecionais, a Microsoft pode iniciar o failover para todas as contas de armazenamento com redundância geográfica (GRS) em uma região. No entanto, o failover gerenciado pela Microsoft é um último recurso e só deve ser executado após um longo período de interrupção. Você não deve confiar no failover gerenciado pela Microsoft.
As contas GRS podem usar qualquer um desses tipos de failover. Não é necessário pré-configurar uma conta de armazenamento para usar qualquer um dos tipos de failover com antecedência.
Requirements
Apoio regional: Configurações geo-redundantes do Azure Storage utilizam regiões emparelhadas Azure para replicação de regiões secundárias. A região secundária é determinada automaticamente com base na sua seleção de região primária e não pode ser personalizada. Para obter uma lista completa de regiões emparelhadas do Azure, consulte Lista de regiões do Azure.
Se a região da sua conta de armazenamento não estiver emparelhada, considere usar soluções multi-região personalizadas para resiliência.
- Tipos de contas de armazenamento: Armazenamento geo-redundante (GRS) e failover e failback iniciados pelo cliente estão disponíveis em todas as regiões emparelhadas do Azure que suportam contas de armazenamento Azure v2 de uso geral.
Considerations
Ao implementar o armazenamento em 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 pode resultar em perda potencial de dados se ocorrer uma falha na região primária antes que os dados recentes sejam replicados. A perda de dados é medida pelo RPO (Recovery Point Objetive, objetivo de ponto de recuperação). 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 Last Sync Time para entender quantos dados podem ser perdidos se sua conta de armazenamento tiver um failover não planejado.
Acesso à região secundária: Com as configurações de armazenamento com redundância geográfica (GRS) e armazenamento com redundância de zona geográfica (GZRS), a região secundária não fica acessível para leituras até que ocorra um failover.
As configurações de armazenamento com redundância geográfica de acesso de leitura (RA-GRS) e 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, elas podem retornar dados ligeiramente desatualizados.
- Limitações de recursos: Alguns recursos do Armazenamento do Azure não são suportados ou têm limitações quando você usa o armazenamento com redundância geográfica (GRS) ou failover gerenciado pelo cliente. Analise a compatibilidade de recursos antes de implementar a redundância geográfica.
Cost
As configurações de conta de Armazenamento do 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 padrão de largura de banda entre regiões.
Para obter informações detalhadas sobre preços, consulte Preços de armazenamento em fila.
Configurar suporte a várias regiões
- Crie uma nova conta de armazenamento com redundância geográfica (GRS). Para criar uma conta GRS, consulte Criar uma conta de armazenamento e selecione 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 a forma como uma conta de armazenamento é replicada.
Warning
Depois que sua conta for reconfigurada para redundância geográfica, pode levar um tempo significativo até que os dados existentes na nova região primária sejam totalmente copiados para a nova região secundária.
Para evitar uma grande perda de dados, verifique o valor da propriedade Last Sync Time antes de iniciar um failover não planejado. Para avaliar a possível perda de dados, compare a última hora de sincronização com a última vez que os dados foram gravados na nova região primária.
Desative a redundância geográfica. Converta contas GRS de volta para 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 a partir da região secundária acessando o ponto de extremidade secundário. Essa abordagem requer 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 primeiro 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 onde são armazenados usando o LRS.
A natureza assíncrona da replicação entre regiões significa que normalmente há um tempo de atraso 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 Last Sync Time.
Comportamento durante uma interrupção regional
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 principal.
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.
Deteção e resposta: No caso improvável de sua conta de armazenamento não estar disponível na região principal, 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 principal
Se a Microsoft aconselha 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 o notifica automaticamente quando uma região está fora do ar. No entanto:
Você pode usar a Integridade dos Recursos do Azure para monitorar a integridade de um recurso individual e pode configurar alertas de Integridade de Recursos para notificá-lo sobre problemas.
Pode usar o Azure Service Health para compreender a saúde geral do serviço, incluindo quaisquer falhas regionais, e pode configurar alertas de Service Health para o notificar 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 Last Sync Time para entender quantos dados podem ser perdidos durante um failover não planejado. A perda de dados esperada é frequentemente chamada de RPO (Recovery Point Objetive, 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 é frequentemente referida como o objetivo de tempo de recuperação (RTO). O failover gerenciado pelo cliente normalmente é concluído em 60 minutos, dependendo do tamanho e da complexidade da conta.
Reencaminhamento do 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 seu aplicativo mantiver as entradas 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: Após a conclusão de um failover não planejado, sua conta de armazenamento na região de destino usa o nível de armazenamento com redundância local (LRS). Se precisar replicá-lo geograficamente, será necessário reativar 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 failover gerenciado pelo cliente, consulte Como funciona o failover gerenciado pelo cliente (não planejado) e Iniciar um failover de conta de armazenamento.
Failover gerenciado pelo cliente (planejado): Use um failover planejado quando o armazenamento permanecer operacional na região principal, mas você precisar 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 alternar para usar uma região secundária para toda a sua solução. Ou pode-se usar um failover planejado para conduzir um exercício de recuperação de desastres (DR) para fins de conformidade e auditoria.
Deteçã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 acionar um failover quando há uma grande interrupção de outro componente de aplicativo do qual não é possível recuperar na região primária.
Notificação: A Microsoft não o notifica automaticamente quando uma região está fora do ar. No entanto:
Você pode usar a Integridade dos Recursos do Azure para monitorar a integridade de um recurso individual e pode configurar alertas de Integridade de Recursos para notificá-lo sobre problemas.
Pode usar o Azure Service Health para compreender a saúde geral do serviço, incluindo quaisquer falhas regionais, e pode configurar alertas de Service Health para o notificar 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 em 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, as contas de armazenamento primária e secundária tornam-se temporariamente indisponíveis para operações de leitura e escrita.
Reencaminhamento do 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: Após a conclusão de um failover planejado, sua conta de armazenamento na região de destino continua a ser replicada geograficamente e permanece no nível GRS.
Para obter mais informações sobre como iniciar failover gerenciado pelo cliente, consulte Como funciona o failover gerenciado pelo cliente (planejado) e Iniciar um failover de conta de armazenamento.
Failover gerenciado pela Microsoft: No caso raro de um desastre grave 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 de ocorrer o failover depende da gravidade do desastre e do tempo necessário para avaliar a situação.
Notificação: A Microsoft não o notifica automaticamente quando uma região está fora do ar. No entanto:
Você pode usar a Integridade dos Recursos do Azure para monitorar a integridade de um recurso individual e pode configurar alertas de Integridade de Recursos para notificá-lo sobre problemas.
Pode usar o Azure Service Health para compreender a saúde geral do serviço, incluindo quaisquer falhas regionais, e pode configurar alertas de Service Health para o notificar de problemas.
Important
Use opções de failover gerenciadas pelo cliente para desenvolver, testar e implementar seus planos de DR. 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 momentos diferentes para diferentes serviços do Azure. Recomendamos que você use failover gerenciado pelo cliente.
Recuperação da região
O processo de failback difere significativamente entre cenários de failover gerenciados pela Microsoft e 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 fazer failback, você precisa restabelecer a relação de armazenamento com redundância geográfica (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ê pode iniciar outro failover gerenciado pelo cliente para fazer failover 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 tenha ocorrido um desastre significativo na região primária e a região primária pode não ser recuperável. Quaisquer prazos ou planos de recuperação dependem da extensão dos esforços regionais de desastre e recuperação. Você deve monitorar as comunicações do Azure Service Health para obter detalhes.
Teste para falhas regionais
Você pode simular falhas regionais para testar seus procedimentos de recuperação de desastres.
Teste de failover planejado: Para contas de armazenamento com redundância geográfica (GRS), você pode executar operações de failover planejadas durante as janelas de manutenção para testar todo o processo de failover e failback. O failover planejado não requer perda de dados, mas envolve tempo de inatividade durante failover e failback.
Teste de endpoint 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 em relação ao 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 não ser adequados devido aos seguintes motivos:
Sua conta de armazenamento está em uma região não emparelhada.
As metas de tempo de atividade da sua empresa não são satisfeitas pelo tempo de recuperação ou perda de dados que as opções integradas de failover oferecem.
Você precisa fazer failover para uma região que não seja o par da sua região principal.
Você precisa de uma configuração ativa/ativa entre 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 Service Bus, que inclui suporte para regiões não emparelhadas.
Você pode implantar o Armazenamento do Azure em várias regiões usando contas de armazenamento separadas em cada região. Essa abordagem oferece flexibilidade na seleção de regiões, 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 balanceamento de carga e failover 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 uma lógica de failover personalizada.
Backup e restauração
O armazenamento em fila não fornece recursos tradicionais de backup, como a restauração point-in-time (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 log ou persistência de mensagens no nível do aplicativo 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 em Filas para sua finalidade de buffer temporário de mensagens e coordenação de processamento.
Contrato de nível de serviço
O contrato de nível de serviço (SLA) 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 usado. Para obter mais informações, consulte SLAs para Serviços Online.