Compartilhar via

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

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 seu cache. Os dados são armazenados a 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íveis perdas de dados, considere estas quatro áreas:

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

Cada cliente do Avere vFXT para Azure deve criar seu próprio plano de recuperação de desastre abrangente que inclua planos para esses itens. Você também pode criar resiliência em aplicativos usados com o cluster vFXT. Leia os links nas próximas etapas para obter ajuda.

Proteger contra tempo de inatividade

A redundância é interna no 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 filers de back-end core (NAS de hardware ou Blob do Azure) para armazenamento de longo prazo.

Cada cluster do Avere vFXT para Azure deve estar localizado em uma única zona de disponibilidade, mas você pode usar clusters redundantes localizados em zonas diferentes 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 em perder o acesso aos dados. No entanto, tenha em mente que as transações entre regiões têm maior latência e custo maior do que as transações que permanecem dentro de uma região.

Proteger dados no cache do cluster

Os dados armazenados em cache são sempre gravados nos arquivos principais antes de um desligamento regular, mas em um desligamento descontrolado, os dados alterados no cache podem ser perdidos.

Se você usar o cluster apenas para otimizar leituras de arquivo, não haverá alterações a serem perdidas. Se você também usar o cluster para armazenar em cache as alterações de arquivo (gravações), considere se deve ou não ajustar as políticas de cache dos principais arquivistas para personalizar a frequência com que os dados são gravados 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 normalmente são mais importantes para restabelecer seu fluxo de trabalho após uma falha.

Proteger dados em filers principais do NAS

Use métodos aceitos para proteger os dados armazenados em um filer de núcleo de hardware nas local, incluindo instantâneos e backups completos, conforme recomendado pelo provedor NAS. A recuperação de desastre para esses arquivos 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 arquivos principais do Blob do Azure. Isso significa que os dados em seus contêineres de Blob são automaticamente copiados para proteção contra falhas transitórias de hardware em um data center.

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

As práticas recomendadas para proteger dados no Armazenamento de Blobs do Azure incluem:

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

Copiar dados do arquivo 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 nova chave de criptografia e armazene-a com segurança fora dos sistemas afetados.

    Se os dados forem criptografados pelo cluster do 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 segura e que não será afetada por uma falha regional.

    Você deve fornecer essa chave ao adicionar o contêiner a um cluster, mesmo que esteja adicionando-a novamente ao cluster original.

    Leia as 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 arquivista 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 arquivista principal após o backup, removê-lo é a melhor maneira de garantir que todos os dados sejam completamente gravados no back-end. (Às vezes, a opção "suspender" pode deixar dados alterados no cache.)

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

    Use o painel de controle de cluster para remover o arquivista principal. Abra o painel de controle de cluster e escolha o arquivista> PrincipalGerenciar arquivos principais. Localize o sistema de armazenamento que você deseja fazer backup e use o botão Remover para excluí-lo do cluster.

  3. Crie um novo 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 no arquivista principal para o novo contêiner. A cópia deve replicar os dados sem alterações e sem interromper o formato proprietário do sistema de arquivos de nuvem usado pelo Avere vFXT para Azure. As ferramentas baseadas no Azure incluem o AzCopy, o Azure PowerShell e o 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 do arquivista principal e informações de junção para que os fluxos de trabalho do cliente não precisem ser alterados.
    • Defina o valor do conteúdo do Bucket como a opção de dados existente.
    • Se o contêiner foi criptografado pelo cluster, você deve inserir a chave de criptografia atual para seu conteúdo. (Esta é a chave que você atualizou na etapa um.)

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

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

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

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

    Dica

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

  2. Adicione um novo arquivista de núcleo de nuvem que aponte para o contêiner de Blob duplicado.

    Especifique se o contêiner de destino já contém dados na configuração de conteúdo bucket do assistente de criação do arquivista principal. (O sistema deve alertá-lo se você acidentalmente deixar esse conjunto como Vazio.)

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

Próximas etapas

  • Last updated on