Compartilhar via

Diretrizes de recuperação de desastre para Avere vFXT para Azure

  • Artigo

Este artigo descreve estratégias para proteger seu fluxo de trabalho do Avere vFXT para Azure e fornece diretrizes para fazer backup de dados para que você possa se recuperar de acidentes ou interrupções.

O Avere vFXT para Azure armazena temporariamente dados em cache. Os dados são armazenados em longo prazo em sistemas de armazenamento de back-end – sistemas de hardware locais, contêineres de armazenamento de Blobs do Azure ou ambos.

Para se proteger contra interrupções e possível perda de dados, considere estas quatro áreas:

  • Proteção contra tempo de inatividade se um sistema Avere vFXT para Azure ficar indisponível
  • Proteger dados no cache do cluster
  • Proteger dados no armazenamento de hardware NAS de back-end
  • Proteger dados no armazenamento de nuvem de Blobs do Azure de back-end

Cada cliente Avere vFXT para Azure deve criar o próprio plano de recuperação de desastres abrangente que inclui planos para esses itens. Você também pode criar resiliência em aplicativos que você usa com o cluster vFXT. Leia os links em Próximas etapas para obter ajuda.

Proteger contra tempo de inatividade

A redundância é interna ao produto Avere vFXT para Azure:

  • O cluster está altamente disponível, e nós de cluster individuais podem fazer failover com interrupção mínima.
  • Os dados alterados no cache são gravados regularmente em arquivadores principais de back-end (hardware NAS ou Blob do Azure) para armazenamento de longo prazo.

Cada cluster Avere vFXT para Azure deve estar localizado em uma só zona de disponibilidade, mas você pode usar clusters redundantes localizados em diferentes zonas ou regiões diferentes para fornecer acesso rapidamente no caso de uma interrupção regional.

Você também pode posicionar contêineres de armazenamento em várias regiões se estiver preocupado com relação à perda de acesso aos dados. No entanto, saiba que as transações entre as regiões têm maior latência e um custo maior do que as transações que permanecem dentro de uma região.

Proteger dados no cache de cluster

Os dados armazenados em cache são sempre gravados nos arquivadores principais antes de um desligamento normal, mas em um desligamento não controlado, os dados alterados no cache podem ser perdidos.

Se você usar o cluster para otimizar somente as leituras de arquivo, não haverá nenhuma alteração a ser perdida. Se você também usar o cluster para armazenar em cache as alterações de arquivo (gravações), decida se quer ajustar as políticas de cache para personalizar a frequência de gravação dos dados no armazenamento de longo prazo.

Em geral, seu plano de recuperação deve se concentrar no backup dos sistemas de armazenamento de back-end, que contêm mais dados e geralmente são mais importantes para restabelecer o fluxo de trabalho após uma falha.

Proteger dados em arquivadores principais do NAS

Use métodos aceitos para proteger os dados armazenados em um arquivo de núcleo de hardware de NAS local, incluindo instantâneos e backups completos, conforme recomendado pelo provedor NAS. A recuperação de desastres para esses arquivadores principais está além do escopo deste artigo.

Proteger dados no armazenamento de Blobs do Azure

O Avere vFXT para Azure usa o LRS (armazenamento com redundância local) para os arquivadores de núcleo de Blob do Azure. Isso significa que os dados em seus contêineres de blob são copiados automaticamente para proteção contra falhas de hardware transitórias dentro de um data center.

Esta seção apresenta dicas de como proteger ainda mais seus dados no armazenamento de Blobs contra interrupções raras em toda a região ou exclusões acidentais.

As melhores práticas para proteger os dados no armazenamento de Blobs do Azure incluem:

  • Copiar os dados críticos para outra conta de armazenamento em outra região com frequência (quantas vezes for determinado pelo seu plano de recuperação de desastre).
  • Controlar o acesso a dados em todos os sistemas de destino para evitar a exclusão acidental ou corrupção. Considere usar bloqueios de recursos no armazenamento de dados.
  • Habilitar o recurso de instantâneo de nuvem do Avere vFXT para Azure para seus arquivadores principais do Blob.

Copiar dados do arquivador principal do Avere vFXT para uma conta de backup

Siga estas etapas para estabelecer um backup de dados em outra conta.

  1. Se necessário, gere uma chave de criptografia e armazene-a com segurança fora dos sistemas afetados.

    Se os dados forem criptografados pelo cluster Avere vFXT para Azure, você deverá gerar uma nova chave de criptografia antes de copiar os dados para outra conta de armazenamento. Armazene essa chave e senha com segurança em uma instalação que seja segura e que não vá ser afetada por uma falha regional.

    Você deve fornecer essa chave ao adicionar o contêiner a um cluster mesmo se o estiver adicionando novamente ao cluster original.

    Leia Configurações de criptografia de nuvem para obter informações detalhadas.

    Se o contêiner usar apenas a criptografia interna do Azure, você poderá ignorar esta etapa.

  2. Remova o arquivador principal do sistema. Isso força o cluster a gravar todos os dados alterados no armazenamento de back-end.

    Embora você precise adicionar novamente o arquivador principal após o backup, removê-lo é a melhor maneira de garantir que todos os dados sejam gravados completamente no back-end. (A opção "Suspender" pode, às vezes, deixar dados alterados no cache.)

    Anote o nome do arquivador principal e as informações de junção (listadas na página Namespace no painel de controle) para que você possa replicá-lo ao adicionar novamente o contêiner após o backup.

    Use o painel de controle de cluster para remover o arquivador principal. Abra o painel de controle de cluster e escolha Arquivador principal>Gerenciar arquivadores principais. Localize o sistema de armazenamento do qual você deseja fazer backup e use o botão Remover para excluí-lo do cluster.

  3. Crie um contêiner de armazenamento de blobs vazio em outra conta de armazenamento em outra região.

  4. Use qualquer ferramenta de cópia conveniente para copiar os dados para o arquivador principal para o novo contêiner. A cópia deve replicar os dados sem alterações e sem interromper o formato de sistema de arquivos de nuvem proprietário usado pelo Avere vFXT para Azure. As ferramentas baseadas no Azure incluem AzCopy, Azure PowerShell e Azure Data Factory.

  5. Depois de copiar os dados para o contêiner de backup, adicione o contêiner original de volta ao cluster, conforme descrito em Configurar armazenamento.

    • Use o mesmo nome de arquivo principal e informações de junção para que os fluxos de trabalho do cliente não precisem ser alterados.
    • Defina o valor de Conteúdo do bucket para a opção dados existentes.
    • Se o contêiner foi criptografado pelo cluster, insira a chave de criptografia atual para seu conteúdo. (Essa é a chave que você atualizou na etapa um.)

Para backups após o primeiro, você não precisa criar um contêiner de armazenamento. No entanto, considere a possibilidade de gerar uma chave de criptografia sempre que você fizer um backup para que você tenha a chave atual armazenada em um local de que você se lembre.

Acessar uma fonte de dados de backup durante uma interrupção

Para acessar o contêiner de backup de um cluster Avere vFXT para Azure, siga este processo:

  1. Se necessário, crie um cluster Avere vFXT para Azure em uma região não afetada.

    Dica

    Ao criar um cluster Avere vFXT para Azure, você pode salvar uma cópia do modelo e dos parâmetros de criação. Se você salvar essas informações ao criar o cluster primário, poderá usá-las para criar um cluster de substituição com as mesmas propriedades. Na página Resumo, clique no link Baixar modelo e parâmetros. Salve as informações em um arquivo antes de criar o cluster.

  2. Adicione um arquivador de nuvem principal que aponte para o contêiner de blob duplicado.

    Especifique que o contêiner de destino já contém dados na configuração de Conteúdo do bucket do assistente de criação do arquivador principal. (O sistema deverá alertá-lo se você deixar acidentalmente isso definido como Vazio.)

  3. Se necessário, atualize os clientes para que eles montem o novo cluster ou o novo arquivador principal, em vez do original. (Se você adicionar o arquivo de núcleo de substituição com o mesmo nome e caminho de junção que o contêiner original, não será necessário atualizar os processos de cliente, a menos que você precise montar o novo cluster em um novo endereço IP.)

Próximas etapas