Partilhar via

Fiabilidade nos ficheiros do Azure

Este artigo descreve o suporte de fiabilidade no Azure Files. Os Arquivos do Azure fornecem compartilhamentos de arquivos totalmente gerenciados na nuvem que podem ser acessados por meio dos protocolos SMB (Server Message Block) e NFS (Network File System) padrão do setor.

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 Azure Files resiliente a uma variedade de potenciais falhas e problemas, incluindo falhas transitórias, falhas 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 essenciais sobre o acordo de nível de serviço (SLA) Azure Files.

Observação

O Azure Files faz 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 o Armazenamento do Azure para fazer referência a esses recursos 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 sua solução e como a confiabilidade afeta outros aspetos da sua arquitetura, consulte Práticas recomendadas de arquitetura para Arquivos do Azure no Azure Well-Architected Framework.

Visão geral da arquitetura de confiabilidade

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

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.

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

  • O nível Premium utiliza unidades de estado sólido (SSD) para um elevado desempenho. Essa camada é recomendada para cargas de trabalho que exigem baixa latência.

  • A camada Standard suporta discos rígidos (HDD). As partilhas de ficheiros HDD fornecem uma opção de armazenamento económica para partilhas de ficheiros de uso geral.

Para mais informações, consulte Planear a implementação do Azure Files - Camadas de armazenamento.

O Azure Files implementa 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 suporta vários modelos de redundância que diferem em sua abordagem à proteção de dados.

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.

Para gerenciar efetivamente falhas transitórias quando você usa 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 detetar 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 Azure Private Link para atribuir um endereço IP estático à sua conta de armazenamento a partir do espaço de endereçamento privado da sua rede virtual. Um ponto de extremidade privado ajuda a evitar interrupções de conectividade devido a alterações dinâmicas de endereço IP. Para obter mais informações sobre segurança para seus compartilhamentos NFS, consulte Compartilhamentos de arquivos NFS - Segurança e rede.

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.

Os Arquivos do Azure fornecem suporte robusto à zona de disponibilidade por meio de configurações do ZRS que distribuem automaticamente seus dados em várias zonas de disponibilidade dentro de 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 se uma zona sofrer uma interrupção.

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

Requerimentos

O ZRS é suportado em:

Custo

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

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

  • Desative a redundância de zona. Converta contas ZRS de volta para uma configuração não zonal, como LRS, usando o mesmo processo de alteraçã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 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 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

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.

  • 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 de armazenamento com redundância de zona (ZRS).

    Se uma zona ficar indisponível, o Azure realizará atualizações de rede, como o redirecionamento do DNS (Sistema de Nomes de Domínio).

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

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.

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

Importante

Os Ficheiros do Azure apenas suportam redundância geográfica (GRS ou GZRS) para partilhas de ficheiros padrão (HDD).

Os Azure Files não oferecem suporte ao armazenamento com redundância geográfica com acesso em leitura (RA-GRS) ou ao armazenamento com redundância de zona geográfica com acesso em leitura (RA-GZRS). Se uma conta de armazenamento estiver configurada para utilizar RA-GRS ou RA-GZRS, as partilhas de ficheiros padrão (HDD) são configuradas e faturadas 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ê é 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 utilizar qualquer um destes tipos de failover. Não é necessário pré-configurar uma conta de armazenamento para usar qualquer um dos tipos de failover com antecedência.

Requerimentos

  • Somente compartilhamentos de arquivos padrão: Os Ficheiros do Azure apenas suportam redundância geográfica (GRS ou GZRS) para partilhas de ficheiros padrão (HDD). Os compartilhamentos de arquivos Premium (SSD) devem usar LRS ou ZRS. Se tem partilhas de ficheiros premium e pretende replicar os dados entre regiões para maior resiliência, veja Soluções multi-região personalizadas para resiliência.

  • GRS e GZRS apenas: O Azure Files não suporta o armazenamento com redundância geográfica para acesso de leitura (RA-GRS) ou o armazenamento com redundância de zona geográfica para acesso de leitura (RA-GZRS). Se uma conta de armazenamento estiver configurada para utilizar RA-GRS ou RA-GZRS, as partilhas de ficheiros padrão (HDD) são configuradas e faturadas como GRS ou GZRS.

Considerações

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

  • Hora da última sincronização: Para os Arquivos do Azure, a Hora da última sincronização é determinada com base no instantâneo mais recente do sistema na região secundária.

    O cálculo do tempo da última sincronização pode esgotar o tempo limite se houver mais de 100 partilhas de ficheiros numa conta de armazenamento. Recomendamos que implemente no máximo 100 partilhas de ficheiros para cada conta de armazenamento, para evitar tempos de espera.

  • 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 do Arquivos do Azure não são suportados ou têm limitações quando você usa o GRS ou o 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. Analise a documentação de compatibilidade de recursos antes de implementar a redundância geográfica.

Custo

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

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 geo-redundante com acesso de leitura (RA-GRS), armazenamento geo-redundante de zona (GZRS) ou armazenamento geo-redundante de zona com 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.

    Advertência

    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 em 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 (LRS ou ZRS) através do 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: 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 confirmadas primeiro na região primária usando o tipo de redundância configurado (LRS para GRS ou ZRS para 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 lhe aconselhar a executar o failover para outra região

      Advertência

      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.

    • 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 gerido pelo cliente (planejado): Use um failover planejado quando o armazenamento continuar operacional na região principal, mas for necessário realizar o 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.

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

    Importante

    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 será 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 a utilização de failover gerido 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 gerido pelo cliente para retornar à 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

Para contas GRS, você pode executar operações de failover planejadas durante as janelas de manutenção para testar o processo completo de failover e failback. O failover planejado não requer perda de dados, mas requer tempo de inatividade durante o failover e o failback.

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.

  • Você usa tipos de compartilhamento de arquivos que não suportam 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 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.

  • 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. Esta abordagem requer desenvolvimento personalizado e mecanismos de resolução de conflitos.

  • Use o Azure File Sync 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 SMB do Azure (ponto de extremidade na nuvem), um servidor de arquivos do Windows local e um compartilhamento de arquivos montado que é executado em uma máquina virtual (VM) em outra região do Azure (um ponto de extremidade do 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 arquivos de várias regiões:

    • Desative a hierarquização na nuvem para garantir que todos os dados estejam presentes localmente no servidor de arquivos.

    • Provisione armazenamento suficiente na VM do Azure para armazenar 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.

Backup e restauração

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

O backup de Arquivos do Azure cria instantâneos de nível de partilha na mesma conta de armazenamento. Esse recurso permite a rápida recuperação 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 de recuperação operacional e de curto prazo, você pode criar snapshots em nível de compartilhamento e armazená-los na mesma conta de armazenamento. As cópias instantâneas ao nível de partilha permitem a recuperação rápida de ficheiros individuais ou partilhas de ficheiros inteiras para o local original ou para um alternativo.

  • Armazenamento de backup em cofre: Usando o backup em cofre, você pode copiar seus instantâneos diários para um cofre dos Serviços de Recuperação do Azure. Para aumentar a segurança, esse cofre é isolado e arejado da conta de armazenamento principal.

    Quando você usa uma região do Azure emparelhada e configura o cofre para usar o GRS, o cofre replica dados para a região emparelhada. Essa replicação oferece suporte à recuperação entre regiões e fluxos de trabalho de DR.

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.

Conteúdo relacionado

  • Last updated on