O NetApp Disaster Recovery é um serviço de recuperação de desastres baseado em nuvem, acessado por meio do NetApp Console, que automatiza fluxos de trabalho de recuperação de desastres para ambientes VMware e Kubernetes. Ele replica cargas de trabalho VMware locais que utilizam armazenamento ONTAP, ou cargas de trabalho Kubernetes que utilizam armazenamento ONTAP gerenciado pelo Trident, para outro site como destino de recuperação de desastres. O serviço utiliza a tecnologia ONTAP SnapMirror, com orquestração nativa do VMware ou orquestração do Trident Protect, para proteger as cargas de trabalho enquanto preserva as eficiências de armazenamento ONTAP, como compressão e deduplicação.

O NetApp Disaster Recovery não requer nenhuma capacitação. Ele aparece automaticamente na navegação à esquerda do NetApp Console em Proteção > Disaster recovery. Para acessar o NetApp Console, em um navegador, digite: "https://console.netapp.com/".

É necessária uma licença de NetApp Disaster Recovery para acesso completo e contínuo. Você pode experimentar o serviço com um teste gratuito de 30 dias antes de adquirir uma licença ou assinatura. Para obter detalhes, consulte "Configure o licenciamento do NetApp Disaster Recovery".

O NetApp Disaster Recovery oferece suporte aos seguintes destinos de proteção:

Para cargas de trabalho VMware, o NetApp Disaster Recovery oferece suporte aos seguintes tipos de datastore:

Para cargas de trabalho do Kubernetes, o NetApp Disaster Recovery protege volumes persistentes provisionados por meio do NetApp Trident no armazenamento ONTAP.

O NetApp Disaster Recovery oferece as seguintes opções de licenciamento:

As taxas de recuperação de desastres são baseadas na capacidade utilizada dos datastores no site de origem quando houver pelo menos uma VM ou recurso Kubernetes com um plano de replicação.

Para um sistema BYOL (Bring Your Own License), se os dados excederem a capacidade permitida, as operações no serviço serão limitadas até que você obtenha uma licença de capacidade adicional ou atualize a licença no NetApp Console.

Após o término do período de avaliação gratuita, você ainda pode visualizar e excluir recursos, como cargas de trabalho e planos de replicação, e executar todas as operações agendadas que foram criadas durante o período de avaliação. Para continuar usando o serviço com todas as funcionalidades, você precisa obter uma assinatura de pagamento conforme o uso (PAYGO) do seu provedor de nuvem ou adquirir uma licença BYOL da NetApp.

Você pode adquirir uma licença ou assinar a qualquer momento e não será cobrado até o término do período de teste de 30 dias.

O NetApp Disaster Recovery suporta as seguintes topologias:

Para a lista completa, veja "Pré-requisitos para recuperação de desastres".

Um agente do Console é um componente de software que permite que o NetApp Console se comunique com o seu armazenamento ONTAP e clusters VMware vCenter. Ele é necessário para que o NetApp Disaster Recovery funcione corretamente. O agente reside em sua rede privada (seja um data center local ou uma VPC na nuvem) e se comunica com suas instâncias de armazenamento ONTAP e clusters vCenter.

Para recuperação de desastres de um ambiente local para outro, instale o agente do Console local no site de recuperação de desastres. Para recuperação de desastres de um ambiente local para a AWS, instale o agente do Console para AWS na sua AWS VPC. Os clusters de origem e destino vCenter devem usar o mesmo agente do Console. A recuperação de desastres funciona apenas com a implantação do agente no modo padrão.

Cada cluster Kubernetes deve ter o NetApp Trident instalado, um backend ONTAP e uma classe de armazenamento configurados, além dos CRDs e do controlador de snapshot de volume instalados. Os aplicativos devem usar volumes persistentes provisionados por meio da classe de armazenamento Trident. Ao adicionar um cluster Kubernetes como um site, o NetApp Disaster Recovery orienta você na instalação e no registro do Trident Protect nesse cluster. Consulte "Requisitos de cluster Kubernetes para o NetApp Disaster Recovery" para obter comandos passo a passo e verificações.

Um site é um contêiner lógico, geralmente associado a um data center ou a um local na nuvem, que hospeda um ou mais vCenter clusters ou clusters Kubernetes. Você adiciona tanto um site de origem (produção) quanto um site de destino (recuperação de desastres) antes de criar um plano de replicação.

Um grupo de recursos é um contêiner lógico que permite a você gerenciar várias VMs, datastores ou namespaces e recursos do Kubernetes como uma única unidade, para que possam ser protegidos com um snapshot comum. Uma VM pode pertencer a apenas um grupo de recursos por vez. Você pode criar um grupo de recursos para cada aplicativo ou carga de trabalho que deseja proteger, e as VMs são ligadas com base na ordem de inicialização que você configurar dentro do grupo.

Um plano de replicação é um conjunto de regras sobre a frequência com que os backups ocorrem e como lidar com eventos de failover. Ele seleciona os sites de origem e destino, atribui grupos de recursos, define mapeamentos de recuperação e configura o comportamento de inicialização. Os planos definem o objetivo de ponto de recuperação (RPO) por meio da frequência da replicação de dados.

O objetivo de ponto de recuperação (RPO) é a quantidade máxima de perda de dados aceitável em caso de desastre; ele é definido pela frequência ou agendamento de replicação do plano de replicação. O objetivo de tempo de recuperação (RTO) é o tempo máximo aceitável para recuperar de um desastre; ele é determinado pelo tempo necessário para o failover para o site de recuperação de desastres e reiniciar todas as máquinas virtuais ou aplicativos.

Para obter instruções, consulte "Adicionar sites no NetApp Disaster Recovery".

Por padrão, a descoberta é executada a cada 24 horas; você pode personalizar a programação para se adequar ao seu ambiente. O intervalo mínimo é de 30 minutos e o máximo é de 24 horas. NetApp recomenda realizar algumas descobertas manuais primeiro para obter informações atualizadas e, em seguida, definir a programação para execução automática. Recursos adicionados ou excluídos recentemente são reconhecidos na próxima descoberta agendada ou manual.

Não. Hospedar VMs protegidas e não protegidas no mesmo datastore pode causar problemas. Especificamente, se o datastore for transferido para o failover, quaisquer VMs não protegidas nele deixarão de existir na origem após o failover, e o NetApp Disaster Recovery não as iniciará no site de failover.

Você deve organizar os recursos antes de implementar o NetApp Disaster Recovery para que as cargas de trabalho protegidas e não protegidas usem subconjuntos separados de datastores e garantir que um único datastore não seja protegido por mais de um plano de replicação.

Se você planeja usar backups gerenciados pela plataforma (gerenciados pelo ONTAP), use a política MirrorAll. MirrorVault e Assíncrono são alternativas aceitáveis, mas você deve garantir que o snapshot selecionado durante o failover ou failback exista tanto no volume de origem quanto no volume de destino, caso contrário, a operação falhará com um erro de "nenhum snapshot comum encontrado". MirrorLatest não é recomendado porque deixa apenas um snapshot comum para failover. Para relações do SnapMirror gerenciadas pelo NetApp Disaster Recovery, não agende atualizações para elas fora do serviço, pois o NetApp Disaster Recovery gerencia o tempo de replicação.

Sim. Se uma relação do SnapMirror já existir entre os volumes de origem e destino de um datastore protegido, o NetApp Disaster Recovery utiliza essa relação para todas as operações de replicação em vez de criar uma nova.

Sim. Você pode migrar aplicativos VMware de um site de origem para outro usando um plano de replicação configurado para migração. Após iniciar a migração, o serviço verifica a cada 30 minutos se a migração está progredindo conforme o planejado; você pode monitorar o progresso em Monitoramento de Tarefas. A migração não é suportada atualmente para cargas de trabalho baseadas em Kubernetes. Consulte "Migrar aplicativos para outro site".

Sim. Durante um teste de failover, o NetApp Disaster Recovery cria VMs temporárias a partir de um novo volume FlexClone do snapshot selecionado e mapeia um datastore temporário baseado em FlexClone para os hosts ESXi. Isso não consome capacidade física adicional, não modifica o volume de origem original e não interrompe a relação do SnapMirror nem as cargas de trabalho de produção, que continuam a ser replicadas normalmente. Após o teste, limpe o ambiente de teste usando a ação Clean up failover test. Consulte "Falha na execução de aplicativos para um site remoto".

Sim. Por padrão, todas as VMs são inicializadas juntas em paralelo, mas você pode atribuir a cada VM um número sequencial (por exemplo, 1, 2, 3) para controlar a ordem de inicialização ou atribuir o mesmo número a várias VMs para inicializá-las simultaneamente. Você também pode definir um atraso de inicialização (0–10 minutos) por VM para escalonar a inicialização, o que é útil para garantir que as VMs prioritárias estejam em execução antes que as VMs de prioridade posterior sejam iniciadas.

O failback retorna as operações para o site de origem original após a resolução de um desastre. Partindo de uma relação do SnapMirror que tenha sofrido failover para o destino, o NetApp Disaster Recovery ressincroniza quaisquer alterações de volta para a VM ou cluster Kubernetes de origem original antes de reverter a direção da replicação. O processo:

Consulte "Restaurar aplicativos para a fonte original".

Use o Painel de Controle de Recuperação de Desastres para verificar se os sites e planos estão íntegros, desconectados ou degradados; revisar avisos recentes e trabalhos com falha; identificar cargas de trabalho protegidas e desprotegidas; e visualizar a capacidade rapidamente. Consulte "Veja o status do plano de recuperação de desastres".

Use o Monitoramento de tarefas para revisar os registros de data e hora da tarefa, o status e o iniciador (ou "sistema", se o Disaster Recovery a iniciou). Você pode cancelar uma tarefa que está "Em andamento" ou "Na fila" no menu Ações, o que é útil se uma tarefa estiver travada ou se você precisar priorizar outra operação. Consulte "Monitorar trabalhos do NetApp Disaster Recovery".

Você pode gerar relatórios com escopo para VMware, Kubernetes ou todas as cargas de trabalho, abrangendo detalhes do plano de replicação, status de conformidade e resumos de tarefas. Os relatórios podem ser baixados como arquivos PDF, HTML ou JSON. Eles abrangem um período de um a sete dias. Para mais informações, consulte "Criar relatórios no NetApp Disaster Recovery".

Um AppVault é o storage de nuvem de destino onde o Trident Protect salva os dados de proteção do Kubernetes. Você cria um AppVault ao configurar um plano de replicação do Kubernetes. Você também pode gerenciar AppVaults na página Configurações.