Partilhar via

Diretrizes de recuperação de desastres para o Avere vFXT for Azure

  • Artigo

Este artigo descreve estratégias para proteger seu fluxo de trabalho do Avere vFXT for Azure e fornece orientação 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 back-end - sistemas de hardware locais, contêineres de armazenamento de Blob 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 for Azure ficar indisponível
  • Protegendo dados no cache do cluster
  • Proteção de dados no armazenamento de hardware NAS back-end
  • Protegendo dados no armazenamento em nuvem de Blob do Azure back-end

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

Proteja-se contra tempo de inatividade

A redundância é incorporada ao produto Avere vFXT for Azure:

  • O cluster é 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 servidores de dados principais back-end (hardware NAS 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 mais alto 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 servidores de dados principais antes de um desligamento regular, mas em um desligamento não controlado, os dados alterados no cache podem ser perdidos.

Se você usar o cluster para otimizar somente leituras de arquivos, não haverá alterações a perder. Se você também usar o cluster para armazenar em cache alterações de arquivos (gravações), considere se deve ou não ajustar as políticas de cache dos principais servidores de dados 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 back-end, que armazenam mais dados e normalmente são mais importantes para restabelecer o fluxo de trabalho após uma falha.

Proteja dados em servidores de dados principais do NAS

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

Proteger dados no armazenamento de Blob do Azure

O Avere vFXT para Azure usa o LRS (armazenamento com redundância local) para os servidores de dados principais de Blob do Azure. Isso significa que os dados em seus contêineres de Blob são copiados automaticamente 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 Blob contra interrupções raras em toda a região ou exclusões acidentais.

As práticas recomendadas para proteger dados no armazenamento de Blob do Azure incluem:

  • Copie seus dados críticos para outra conta de armazenamento em outra região com frequência (conforme determinado pelo seu plano de recuperação de desastres).
  • Controle o acesso aos 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 for Azure para seus servidores de dados de núcleo de Blob.

Copie os dados do filer 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 seus dados forem criptografados pelo cluster Avere vFXT for 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 seja afetada por uma falha regional.

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

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

    Se seu contêiner usa apenas a criptografia interna do Azure, você pode ignorar esta etapa.

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

    Embora você tenha que adicionar novamente o filer 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 arquivador principal e as informações de junção (listadas na página Namespace no painel de controle) para que você possa replicá-las quando adicionar novamente o contêiner após o backup.

    Use o painel de controle do cluster para remover o arquivador principal. Abra o painel de controle do cluster e escolha Core filer>Manage core filers. Localize o sistema de armazenamento do qual deseja fazer backup e use o botão Remover para excluí-lo do cluster.

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

  4. Use qualquer ferramenta de cópia conveniente para copiar os dados no filer 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 na nuvem usado pelo Avere vFXT for 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 do filer principal e as mesmas informações de junção para que os fluxos de trabalho do cliente não precisem ser alterados.
    • Defina o valor Conteúdo do bucket para 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, não é necessário criar um novo contêiner de armazenamento. No entanto, considere gerar uma nova chave de criptografia toda vez que fizer um backup para garantir que você tenha a chave atual armazenada em um lugar 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 Avere vFXT para Azure em uma região não afetada.

    Gorjeta

    Ao criar um cluster 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 filer de núcleo de nuvem que aponte para o contêiner de Blob duplicado.

    Certifique-se de especificar que o contêiner de destino já contém dados na configuração Conteúdo do bucket do assistente de criação do filer principal. (O sistema deve alertá-lo se acidentalmente deixar este conjunto para 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 filer principal de substituição com o mesmo nome e caminho de junção do contêiner original, não precisará atualizar os processos do cliente, a menos que precise montar o novo cluster em um novo endereço IP.)

Próximos passos