Compartilhar via

Confiabilidade nos Arquivos do Azure

Este artigo descreve o suporte à confiabilidade nos Arquivos do Azure, abrangendo a resiliência intra-regional por meio de zonas de disponibilidade e implantações de várias regiões. Ele também abrange a proteção entre regiões por meio de opções de GRS (armazenamento com redundância geográfica). Para obter mais informações, confira Confiabilidade do Azure.

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.

Os Arquivos do Azure fornecem compartilhamentos de arquivos totalmente gerenciados na nuvem que podem ser acessados por meio de protocolos SMB (Bloco de Mensagens de Servidor) padrão do setor e NFS (Sistema de Arquivos de Rede). Dependendo da região do Azure, os Arquivos do Azure podem dar suporte a uma variedade de configurações de redundância para habilitar a HA (alta disponibilidade) e a recuperação de desastre (DR) para cargas de trabalho hospedadas:

  • O LRS (armazenamento com redundância local) e o ZRS (armazenamento com redundância de zona) foram projetados para HA e garantem a durabilidade dos dados em um único datacenter ou entre zonas de disponibilidade.

  • O GRS e o GZRS (armazenamento com redundância de zona geográfica) fornecem DR entre regiões e replicam dados para uma região secundária para proteger contra interrupções regionais.

Observação

Os Arquivos do Azure fazem parte da plataforma de Armazenamento do Azure. Alguns dos recursos dos Arquivos do Azure são comuns em muitos serviços de Armazenamento do Azure. Neste artigo, usamos Armazenamento do Microsoft Azure para nos referirmos a essas funcionalidades comuns.

Recomendações de implantação de produção

Para saber como implantar os Arquivos do Azure para dar suporte aos requisitos de confiabilidade da solução e como a confiabilidade afeta outros aspectos de sua arquitetura, consulte as práticas recomendadas de arquitetura para arquivos do Azure no Azure Well-Architected Framework.

Visão geral da arquitetura de confiabilidade

Os Arquivos do Azure estão disponíveis em duas camadas de mídia:

  • A camada Premium usa SSD (unidades de estado sólido) para alto desempenho. Essa camada é recomendada para cargas de trabalho que exigem baixa latência.

  • A camada standard dá suporte a HD (unidades de disco rígido). Os compartilhamentos de arquivos HDD fornecem uma opção de armazenamento econômica para compartilhamentos de arquivos de uso geral.

Para obter mais informações, consulte Planejar a implantação de Arquivos do Azure – camadas de armazenamento.

Os Arquivos do Azure implementam a redundância no nível da conta de armazenamento e os compartilhamentos de arquivos herdam essa configuração de redundância automaticamente. O serviço dá suporte a vários modelos de redundância que diferem em sua abordagem de proteção de dados.

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?.

Diagrama que mostra como os dados são replicados em zonas de disponibilidade usando LRS.

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.

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.

Para gerenciar efetivamente falhas transitórias ao usar os Arquivos do Azure, configure os valores de tempo limite apropriados para suas operações de arquivo com base no tamanho do arquivo e nas condições de rede. Arquivos maiores exigem tempos limite mais longos, enquanto operações menores podem usar valores mais curtos para detectar falhas rapidamente.

Para garantir que apenas conexões seguras sejam estabelecidas para seu compartilhamento NFS, recomendamos que você configure um ponto de extremidade privado para sua conta de armazenamento. Um ponto de extremidade privado usa o Link Privado do Azure para atribuir um endereço IP estático à sua conta de armazenamento de dentro do espaço de endereço privado da rede virtual. Um ponto de extremidade privado ajuda a prevenir interrupções de conectividade devido a alterações dinâmicas de endereços IP. Para obter mais informações sobre segurança para seus compartilhamentos NFS, consulte compartilhamentos de arquivos NFS – Segurança e rede.

Suporte à zona de disponibilidade

As zonas de disponibilidade são grupos fisicamente separados de datacenters em cada região do Azure. Quando uma zona falha, os serviços podem fazer o failover de uma das zonas restantes.

Os Arquivos do Azure fornecem suporte robusto à zona de disponibilidade por meio de configurações ZRS que distribuem automaticamente seus dados entre várias zonas de disponibilidade em uma região. Ao contrário do LRS, o ZRS garante que o Azure replica de forma síncrona seus dados de arquivo em várias zonas de disponibilidade. O ZRS garante que seus dados permaneçam acessíveis mesmo que uma zona experimente uma interrupção.

Diagrama que mostra como os dados são replicados na região primária com ZRS (armazenamento com redundância de zona).

Suporte de regiões

O ZRS tem suporte em compartilhamentos de arquivos HDD (padrão) em todas as regiões com zonas de disponibilidade.

O ZRS tem suporte para compartilhamentos de arquivos SSD (premium) por meio do tipo de FileStorage conta de armazenamento. Para obter uma lista de regiões que dão suporte ao ZRS para contas de compartilhamento de arquivos SSD, consulte o suporte do ZRS para compartilhamentos de arquivos SSD.

Requirements

O ZRS é compatível com todos os tipos de compartilhamento de arquivos.

Custo

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 os preços dos Arquivos do Azure.

Configurar o suporte à zona de disponibilidade

  • Crie um compartilhamento de arquivos com redundância de zona. Para criar um novo compartilhamento de arquivos com o ZRS, consulte Criar um compartilhamento de arquivos do Azure e selecione ZRS ou GZRS como a opção de redundância durante a criação da conta.

  • Como alterar o tipo de replicação Para converter uma conta de armazenamento existente em ZRS e saber mais sobre opções e requisitos de migração, consulte Alterar a configuração de redundância para arquivos do Azure.

  • Desabilite a redundância de zona. Converta contas ZRS de volta para uma configuração não zonal, como LRS, utilizando o mesmo processo de alteração de configuração de redundância.

Operações normais

Esta seção descreve o que esperar quando uma conta de armazenamento de arquivos é 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.

Experiência de redução de atividade na zona

Esta seção descreve o que esperar quando uma conta de armazenamento de arquivos é configurada para redundância de zona e há uma interrupção da zona de disponibilidade.

  • 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: o Armazenamento do Azure não notifica você quando uma zona está inoperante. No entanto, você pode usar o Azure Resource Health para monitorar a integridade da sua conta de armazenamento. Você também pode usar a Integridade do Serviço do Azure para entender a integridade geral do serviço de Armazenamento do Azure, incluindo quaisquer falhas de zona.

    Configure alertas nesses serviços para receber notificações de problemas da zona. Para obter mais informações, veja Criar alertas da Integridade do Serviço no portal do Azure e Criar e configurar alertas do Resource Health.

  • 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: o Azure redireciona automaticamente o tráfego para as zonas de disponibilidade íntegras restantes. O serviço mantém a funcionalidade completa usando as zonas sobreviventes sem a necessidade de intervenção do cliente. Não é necessário desmontar compartilhamentos de arquivos do Azure dos clientes conectados.

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.

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 zona para baixo. Como esse recurso é totalmente gerenciado, você não precisa iniciar nem validar processos de falha da zona de disponibilidade.

Suporte para várias regiões

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.

Importante

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 abordagens alternativas de várias regiões.

Replicação entre 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.

Importante

Azure Files só dá suporte à redundância geográfica (GRS ou GZRS) para compartilhamentos de arquivos padrão (HDD).

O Arquivos do Azure não oferece suporte ao armazenamento georredundante de acesso de leitura (RA-GRS) ou ao armazenamento georredundante de zona de acesso de leitura (RA-GZRS). Se uma conta de armazenamento estiver configurada para usar RA-GRS ou RA-GZRS, os compartilhamentos de arquivos padrão (HDD) serão configurados e cobrados como GRS ou GZRS.

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.

Suporte de regiões

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 abordagens alternativas de várias regiões.

Requirements

  • Somente compartilhamentos de arquivos padrão: Os Arquivos do Azure só dão suporte à redundância geográfica (GRS ou GZRS) para compartilhamentos de arquivos padrão (HDD). Os compartilhamentos de arquivos Premium (SSD) devem usar LRS ou ZRS. Se você tiver compartilhamentos de arquivos premium e quiser replicar os dados entre regiões para obter maior resiliência, consulte abordagens alternativas de várias regiões.

  • Somente GRS e GZRS: os Arquivos do Azure não oferecem suporte ao armazenamento com redundância geográfica com acesso de leitura (RA-GRS) ou ao armazenamento com redundância de zona geográfica com acesso de leitura (RA-GZRS). Se uma conta de armazenamento estiver configurada para usar RA-GRS ou RA-GZRS, os compartilhamentos de arquivos padrão (HDD) serão configurados e cobrados como GRS ou GZRS.

Considerações

Ao implementar arquivos do Azure 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.

  • Hora da Última Sincronização: Para arquivos do Azure, a Hora da Última Sincronização é baseada no instantâneo mais recente do sistema na região secundária.

    O cálculo da Hora da Última Sincronização pode expirar se houver mais de 100 compartilhamentos de arquivos em uma conta de armazenamento. Recomendamos que você implante 100 ou menos compartilhamentos de arquivos para cada conta de armazenamento para evitar tempos limite.

  • Acesso à região secundária: A região secundária não é acessível para leituras até que ocorra um failover.

  • Limitações de recursos: Alguns recursos de Arquivos do Azure não têm suporte ou têm limitações quando você usa GRS ou failover gerenciado pelo cliente. Essas limitações incluem tipos específicos de compartilhamento de arquivos, camadas de acesso e ferramentas e operações de gerenciamento. Examine a documentação de compatibilidade de recursos antes de implementar a redundância geográfica.

Custo

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 os preços dos Arquivos do Azure.

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 de arquivos existente. Para converter uma conta de armazenamento de arquivos existente em GRS, consulte Alterar a configuração de redundância para arquivos do Azure.

    Aviso

    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 região primária.

  • Habilitar a redundância geográfica Converta contas GRS novamente em configurações de região única (LRS ou ZRS) por meio do mesmo processo de alteração de configuração de redundância.

Operações normais

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: Os Arquivos do Azure usam uma abordagem ativa-passiva em que todas as operações de leitura e gravação são direcionadas para a região primária.

  • Replicação de dados entre regiões: As operações de gravação são primeiramente confirmadas na região primária utilizando o tipo de redundância configurado (LRS no caso de GRS, ou ZRS no caso de 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 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.

Experiência de região inoperante

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

      Aviso

      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: O Armazenamento do Azure não notifica você quando uma região está inoperante. No entanto, você pode usar o Azure Resource Health para monitorar a integridade da sua conta de armazenamento. Você também pode usar a Integridade do Serviço do Azure para entender a integridade geral do serviço de Armazenamento do Azure, incluindo quaisquer falhas de região.

      Configure alertas nesses serviços para receber notificações de problemas no nível da região. Para obter mais informações, veja Criar alertas da Integridade do Serviço no portal do Azure e Criar e configurar alertas do Resource Health.

    • 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: O Armazenamento do Azure não notifica você quando uma região está inoperante. No entanto, você pode usar o Azure Resource Health para monitorar a integridade da sua conta de armazenamento. Você também pode usar a Integridade do Serviço do Azure para entender a integridade geral do serviço de Armazenamento do Azure, incluindo quaisquer falhas de região.

      Configure alertas nesses serviços para receber notificações de problemas no nível da região. Para obter mais informações, veja Criar alertas da Integridade do Serviço no portal do Azure e Criar e configurar alertas do Resource Health.

    • 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.

    Importante

    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

Para contas de GRS, você pode executar operações de recuperação planejada durante as janelas de manutenção para testar o processo completo de failover e failback. Embora a recuperação planejada não exija perda de dados, ela requer tempo de inatividade durante o failover e o failback.

Abordagens alternativas de várias regiões

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.

  • Você usa tipos de compartilhamento de arquivos que não dão suporte à redundância geográfica.

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.

Considere as seguintes abordagens comuns de alto nível:

  • Várias contas de armazenamento: Os Arquivos do Azure podem ser implantados 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.

  • Replicação no nível do aplicativo: Implemente a lógica de replicação personalizada usando o Azure Data Factory ou o AzCopy para sincronizar dados entre compartilhamentos de arquivos em regiões diferentes. Essa abordagem requer mecanismos personalizados de desenvolvimento e resolução de conflitos.

  • Use a Sincronização de Arquivos do Azure para replicar arquivos para um compartilhamento de arquivos em outra região do Azure. Você pode usar a Sincronização de Arquivos do Azure para sincronizar entre um compartilhamento de arquivos do Azure SMB (ponto de extremidade de nuvem), um servidor de arquivos do Windows local e um compartilhamento de arquivos montado que é executado em uma VM (máquina virtual) em outra região do Azure (um ponto de extremidade de servidor dr).

    Essa abordagem exige que você implante vários compartilhamentos de arquivos e uma VM para coordenar o processo de sincronização.

    Se você usar essa abordagem para replicação de arquivo de várias regiões:

    • Desative o tier de nuvem para garantir que todos os dados estejam presentes localmente no servidor de arquivos.

    • Provisione armazenamento suficiente na VM do Azure para manter todo o conjunto de dados.

    • Acesse e modifique arquivos no ponto de extremidade do servidor, e não no Azure, para garantir que as alterações sejam replicadas rapidamente para a região secundária.

Backups

O backup dos Arquivos do Azure é uma integração nativa entre os Arquivos do Azure e o Backup do Azure que foi projetado para proteger dados contra exclusão acidental, corrupção e ataques de ransomware.

O backup dos Arquivos do Azure cria instantâneos de nível de compartilhamento armazenados na mesma conta de armazenamento. Essa funcionalidade permite a recuperação rápida de arquivos individuais e compartilhamentos de arquivos inteiros. Você também pode usar políticas de backup para fornecer longos períodos de retenção com frequência de backup personalizável.

Você pode criar seus instantâneos e armazená-los de duas maneiras diferentes:

  • Armazenamento em nível de compartilhamento: Para cenários operacionais e de recuperação de curto prazo, você pode criar instantâneos de nível de compartilhamento e armazená-los na mesma conta de armazenamento. Os instantâneos de nível de compartilhamento permitem a recuperação rápida de arquivos individuais ou compartilhamentos de arquivos inteiros para o local original ou alternativo.

  • Armazenamento de backup em cofre: usando o backup em cofre, é possível copiar seus instantâneos diários para um cofre dos Serviços de Recuperação do Azure. Para aprimorar a segurança, esse cofre é isolado e desconectado da conta de armazenamento primária.

    Ao usar uma região emparelhada do Azure e configurar o cofre para usar GRS, o cofre replica dados para a região emparelhada. Essa replicação dá suporte à recuperação entre regiões e fluxos de trabalho de Recuperação de Desastres (DR).

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.

Conteúdo relacionado

  • Last updated on