Recuperação de desastre para máquinas virtuais do Azure Stack Hub

Este artigo descreve as considerações de arquitetura e design de uma solução que oferece uma abordagem otimizada para a recuperação de desastres de cargas de trabalho executadas em máquinas virtuais (VMs) hospedadas no Hub de Pilha do Azure.

Arquitetura

Baixe um Arquivo Visio dessa arquitetura.

Workflow

Os componentes de nuvem da solução proposta incluem os seguintes serviços:

• Uma assinatura do Azure que hospeda todos os recursos de nuvem que fazem parte desta solução.

• Um locatário do Microsoft Entra ID associado à assinatura do Azure que fornece autenticação de entidades de segurança do Microsoft Entra para autorizar o acesso aos recursos do Azure.

• Um cofre de Serviços de Recuperação do Azure na região do Azure mais próxima de um datacenter local que hospeda a implantação do Hub de Pilha do Azure.

  Observação

  A escolha da região do Azure mais próxima do datacenter local é específica para o cenário de exemplo incluído neste artigo. Do ponto de vista da recuperação de desastres, é melhor selecionar uma região do Azure que esteja mais distante do local que hospeda o ambiente de produção. A decisão, no entanto, pode depender de outros fatores, como a necessidade de minimizar a latência de feeds de dados regionais ou de satisfazer os requisitos de residência de dados.

• Um circuito do Azure ExpressRoute que conecta os datacenters locais à região do Azure que hospeda o cofre dos Serviços de Recuperação do Azure, configurado com emparelhamento privado e emparelhamento da Microsoft. O primeiro garante que os requisitos de latência sejam atendidos após um failover. O objetivo deste último é minimizar o tempo necessário para replicar as alterações entre as cargas de trabalho locais e o site de failover no Azure.

• Uma conta de Armazenamento do Azure que contém blobs que contêm os arquivos VHD criados pela replicação do sistema operacional e volumes de dados de VMs protegidas do Azure Stack Hub. Esses arquivos VHD servem como a origem para os discos gerenciados de VMs do Azure que são provisionados automaticamente após um failover.

• Uma rede virtual do Azure que hospeda o ambiente de recuperação de desastres. Ele é configurado de uma maneira que espelha o ambiente de rede virtual no Hub de Pilha do Azure que hospeda as cargas de trabalho de produção, incluindo componentes como balanceadores de carga e grupos de segurança de rede. Essa rede virtual geralmente está conectada à rede virtual do Azure Stack Hub por meio de uma conexão de Rota Expressa para facilitar a recuperação em nível de carga de trabalho.

  Observação

  Às vezes, uma conexão VPN site a site é suficiente em cenários em que os requisitos de RPO (Recovery Point Objective, objetivo de ponto de recuperação) são menos rigorosos.

• Uma rede virtual isolada do Azure destinada a failovers de teste, configurada de uma maneira que espelha o ambiente de rede virtual no Azure Stack Hub que hospeda as cargas de trabalho de produção, incluindo componentes como balanceadores de carga e grupos de segurança de rede.

Os componentes no local da solução proposta incluem os seguintes serviços:

• Um sistema integrado do Azure Stack Hub no modelo de implantação conectado. O sistema executa a atualização atual (2002 a partir de 20/9) e está no datacenter local do cliente.

• Uma assinatura do Azure Stack Hub e uma rede virtual, ou várias redes virtuais emparelhadas, que hospeda todas as VMs locais para esta solução.

• Servidores de processo e configuração do Azure Site Recovery executados em VMs de pilha de hub do Azure do Windows Server 2016 ou 2012 R2. Os servidores gerenciam as comunicações com o cofre dos Serviços de Recuperação do Azure e o roteamento, a otimização e a criptografia do tráfego de replicação.

  Observação

  Por padrão, um servidor de configuração hospeda um único servidor de processo. Você pode implantar servidores de processo dedicados para acomodar um volume maior de tráfego de replicação.

• As VMs do Hub de Pilha do Azure que devem ser protegidas. Eles executam versões compatíveis dos sistemas operacionais Windows Server, CentOS e Ubuntu.

• O serviço de Mobilidade de Recuperação de Site (também conhecido como agente de mobilidade) que é executado em VMs protegidas. Ele controla as alterações nos discos locais, registra as alterações nos logs de replicação e replica os logs para o servidor de processo. O servidor de processo os roteia para a conta de armazenamento do Azure de destino. Os logs são usados para criar pontos de recuperação para discos gerenciados que são implementados usando blobs armazenados na conta de armazenamento do Azure que você designa.

Componentes

• Microsoft Entra ID
• Rede Virtual do Azure
• Serviços de Recuperação do Azure
• Azure ExpressRoute
• Armazenamento de Blobs do Azure
• Azure Stack Hub

Alternativas

A solução recomendada descrita neste artigo não é a única maneira de fornecer funcionalidade de recuperação de desastres para cargas de trabalho baseadas em VM do Azure Stack Hub. Os clientes têm outras opções, incluindo:

• Um failover para outro carimbo do Azure Stack Hub. Os usuários que precisam se proteger contra uma interrupção do datacenter ou do site podem usar outra implantação do Hub do Azure Stack para implementar provisões de recuperação de desastres. Com locais primários e secundários, os usuários podem implantar aplicativos em uma configuração ativa/passiva em dois ambientes. Para cargas de trabalho menos críticas, pode ser aceitável usar a capacidade não utilizada no local secundário para executar a restauração sob demanda de aplicativos do backup. Você também pode implementar um site de recuperação em outro datacenter, que, por sua vez, usa o Site Recovery para provisionar uma réplica do site de recuperação no Azure. Vários fatores determinam se o uso do Site Recovery com o Azure servindo como o site de failover é uma solução viável. Esses fatores incluem regulamentações governamentais, políticas corporativas e requisitos de latência.

  Observação

  A partir de julho de 2020, o Site Recovery não oferece suporte a esse cenário, o que significa que a implementação precisa usar um parceiro ou uma solução interna.

• Backup e restauração. O backup de seus aplicativos e conjuntos de dados possibilita que você se recupere rapidamente do tempo de inatividade resultante de corrupção de dados, exclusões acidentais ou paralisações localizadas. Para aplicativos baseados em VM do Azure Stack Hub, você pode usar um agente convidado para proteger dados de aplicativos, configurações do sistema operacional e dados armazenados em volumes. O backup de uma VM usando um agente de sistema operacional convidado normalmente inclui a captura de configurações do sistema operacional, arquivos, pastas, volumes, binários de aplicativos e dados de aplicativos. A recuperação de um aplicativo de um agente requer a recriação da VM, seguida pela instalação do sistema operacional e do agente convidado. Nesse ponto, você pode restaurar dados no sistema operacional convidado.

• Backup de snapshots de disco. É possível usar instantâneos para capturar uma configuração de VM do Azure Stack Hub e os discos anexados a uma VM parada. Esse processo requer produtos de backup que se integrem às APIs do Azure Stack Hub para capturar a configuração da VM e criar instantâneos de disco.

  Observação

  Desde julho de 2020, o uso de snapshots de disco para uma VM em execução não é suportado. A criação de um instantâneo de um disco anexado a uma VM em execução pode degradar o desempenho ou afetar a disponibilidade do sistema operacional ou do aplicativo na VM.

• Faça backup e restaure VMs usando uma solução de backup externo no mesmo datacenter e, em seguida, replique os backups para outro local. Dessa forma, você pode restaurar VMs do Azure Stack Hub para a mesma instância do Azure Stack Hub, para uma instância diferente ou para o Azure.

Detalhes do cenário

O Azure Stack Hub inclui a funcionalidade de autorrecuperação, fornecendo correção automática em uma variedade de cenários que envolvem falhas localizadas de seus componentes. No entanto, falhas em grande escala, incluindo interrupções que afetam racks de servidores ou desastres no nível do local, exigem considerações adicionais. Essas considerações devem fazer parte da estratégia de continuidade de negócios e recuperação de desastres para cargas de trabalho de usuários baseadas em VM. Essa estratégia também deve levar em conta a recuperação da infraestrutura do Azure Stack, que é separada da recuperação da carga de trabalho.

As soluções tradicionais de recuperação de carga de trabalho local são complexas de configurar, caras e trabalhosas de manter e difíceis de automatizar, especialmente quando você usa outro local como o site de failover. A Microsoft recomenda uma solução alternativa que depende de uma combinação de componentes locais e de nuvem para fornecer maneiras resilientes, baseadas em desempenho, altamente automatizadas e diretas de implementar, proteger e gerenciar uma estratégia econômica de recuperação de desastres. O elemento principal dessa solução é o Site Recovery, com o site de failover residindo no Azure.

Possíveis casos de uso

O Site Recovery com o Azure como site de failover elimina todas as desvantagens mencionadas anteriormente. Você pode usar seus recursos para proteger servidores físicos e virtuais, incluindo aqueles executados em plataformas de virtualização Microsoft Hyper-V ou VMware ESXi. Você também pode usar os mesmos recursos para facilitar a recuperação de cargas de trabalho executadas em VMs do Azure Stack Hub.

Funcionalidade principal

O Site Recovery é uma solução de recuperação de desastres que facilita a proteção de computadores físicos e virtuais, fornecendo dois conjuntos de recursos:

• Replicação de alterações em discos de computador que estão entre os locais de produção e recuperação de desastres
• A orquestração de failover e failback ordenados entre esses dois locais.

O Site Recovery oferece três tipos de failovers:

• Testar o failover. Esse failover oferece a oportunidade de validar sua configuração de Site Recovery em um ambiente isolado, sem qualquer perda de dados ou impacto no ambiente de produção.
• Failover planejado. Esse failover oferece a opção de iniciar a recuperação de desastres sem perda de dados, normalmente como parte do tempo de inatividade planejado.
• Failover não planejado. Esse failover serve como último recurso no caso de uma interrupção não planejada que afete a disponibilidade do site primário e potencialmente resulte em perda de dados.

O Site Recovery oferece suporte a vários cenários, como failover e failback entre dois sites locais, failover e failback entre duas regiões do Azure e migração de nuvens de provedores de terceiros. No entanto, no contexto deste artigo, o foco está na replicação de discos locais de VMs do Azure Stack Hub para o Armazenamento do Azure e no failover e failback de VM entre uma pilha do Azure Stack Hub e uma região do Azure.

Os detalhes da arquitetura do Site Recovery e seus componentes dependem de vários critérios, incluindo:

• Os tipos de computadores a serem protegidos (físico versus virtual).
• Para ambientes virtualizados, o tipo de hipervisor que hospeda as máquinas virtuais a serem protegidas (Hyper-V versus VMware ESXi).
• Para ambientes Hyper-V, o uso do System Center Virtual Machine Manager (SCVMM) para gerenciamento de hosts Hyper-V.

Com o Azure Stack Hub, a arquitetura corresponde àquela aplicável a computadores físicos. Isso não é particularmente surpreendente, porque em ambos os casos, o Site Recovery não pode se beneficiar do acesso direto a um hipervisor. Em vez disso, o mecanismo que rastreia e replica alterações em discos locais é implementado no sistema operacional protegido.

Para fazer isso, o Site Recovery depende do serviço de Mobilidade do Site Recovery (também conhecido como agente de mobilidade), que é implantado automaticamente em VMs individuais à medida que você as inscreve no escopo da proteção baseada no Site Recovery. Em cada VM protegida, a instância instalada localmente do agente de mobilidade monitora e encaminha continuamente as alterações para o sistema operacional e os discos de dados para o servidor de processo. No entanto, para otimizar e gerenciar o fluxo de tráfego de replicação originado de VMs protegidas, o Site Recovery implementa um conjunto adicional de componentes em execução em uma VM separada, conhecida como servidor de configuração.

O servidor de configuração coordena as comunicações com o cofre do Site Recovery e gerencia a replicação de dados. Além disso, o servidor de configuração hospeda um componente conhecido como servidor de processo, que atua como um gateway, recebendo dados de replicação, otimizando-os por meio de cache e compactação, criptografando-os e, finalmente, encaminhando-os para o Armazenamento do Azure. Efetivamente, o servidor de configuração funciona como o ponto de integração entre o Site Recovery e as VMs protegidas em execução no Azure Stack Hub. Você implementa essa integração implantando o servidor de configuração e registrando-o no cofre dos serviços de Site Recovery.

Como parte da configuração do Site Recovery, você define o ambiente de recuperação de desastres pretendido, incluindo componentes de infraestrutura como redes virtuais, balanceadores de carga ou grupos de segurança de rede da maneira que espelha o ambiente de produção. A configuração também inclui uma política de replicação, que determina os recursos de recuperação e consiste nos seguintes parâmetros:

• Limite de RPO. Essa configuração representa o objetivo de ponto de recuperação desejado que você deseja implementar e determina a frequência na qual o Site Recovery gera instantâneos de ponto de recuperação consistentes com falhas. Seu valor não afeta a frequência da replicação porque essa replicação é contínua. O Site Recovery gerará um alerta e, opcionalmente, uma notificação por e-mail, se o RPO efetivo atual fornecido pelo Site Recovery exceder o limite especificado. O Site Recovery gera instantâneos de pontos de recuperação consistentes com falhas a cada cinco minutos.

  Observação

  Um instantâneo consistente com falha captura os dados que estavam no disco quando o instantâneo foi tirado. Ele não inclui conteúdo de memória. Efetivamente, um instantâneo consistente com falhas não garante consistência de dados para o sistema operacional ou aplicativos instalados localmente.

• Retenção do ponto de recuperação. Essa configuração representa a duração (em horas) da janela de retenção para cada instantâneo do ponto de recuperação. As VMs protegidas podem ser recuperadas em qualquer ponto de recuperação dentro de uma janela de retenção. O Site Recovery oferece suporte a até 24 horas de retenção para VMs replicadas para contas de Armazenamento do Azure com a camada de desempenho premium. Há um limite de retenção de 72 horas ao usar contas de Armazenamento do Azure com a camada de desempenho padrão.

• Frequência de instantâneos consistentes com o aplicativo. Essa configuração determina a frequência (em horas) na qual o Site Recovery gera instantâneos consistentes com o aplicativo. Um instantâneo consistente com aplicativos representa um instantâneo point-in-time de aplicativos em execução em uma VM protegida. Há um limite de 12 instantâneos consistentes com aplicativos. Para VMs que executam o Windows Server, o Site Recovery usa o VSS (Serviço de Cópias de Sombra de Volume). O Site Recovery também oferece suporte a instantâneos consistentes com aplicativos para Linux, mas isso requer a implementação de scripts personalizados. Os scripts são usados pelo agente de mobilidade ao aplicar um instantâneo consistente com o aplicativo.

  Observação

  Para obter detalhes sobre a implementação de instantâneos consistentes com aplicativos em VMs do Azure Stack Hub que executam Linux, consulte Perguntas gerais sobre o Site Recovery.

Para cada disco de uma VM protegida do Azure Stack Hub que você designar, os dados são replicados para um disco gerenciado correspondente no Armazenamento do Azure. O disco armazena a cópia do disco de origem e todos os instantâneos consistentes com falhas e aplicativos do ponto de recuperação. Como parte de um failover, você escolhe um instantâneo consistente com falhas ou aplicativo de ponto de recuperação que deve ser usado ao anexar o disco gerenciado à VM do Azure, que serve como uma réplica da VM protegida do Azure Stack Hub.

Durante operações comerciais regulares, as cargas de trabalho protegidas são executadas em VMs do Azure Stack Hub, com as alterações em seus discos sendo replicadas continuamente por meio de interações entre o agente de mobilidade, o servidor de processo e o servidor de configuração para a conta de Armazenamento do Azure designada. Quando você inicia um failover de teste, planejado ou não planejado, o Site Recovery provisiona automaticamente as VMs do Azure usando as réplicas de discos das VMs do Azure Stack Hub correspondentes.

Você tem a opção de orquestrar um failover criando planos de recuperação que contêm etapas manuais e automatizadas. Para implementar o último, você pode usar runbooks de Automação do Azure, que consistem em scripts personalizados do PowerShell, fluxos de trabalho do PowerShell ou scripts Python 2.

Depois que o site primário fica disponível novamente, o Site Recovery oferece suporte à inversão da direção da replicação, permitindo que você execute um failback com tempo de inatividade minimizado e sem perda de dados. No entanto, com o Azure Stack Hub, essa abordagem não está disponível. Em vez disso, para fazer failback, é necessário baixar arquivos de disco da VM do Azure, carregá-los no Azure Stack Hub e anexá-los a VMs novas ou existentes.

Considerações

Estas considerações implementam os pilares do Azure Well-Architected Framework, que é um conjunto de princípios de orientação que podem ser usados para aprimorar a qualidade de uma carga de trabalho. Para obter mais informações, confira Microsoft Azure Well-Architected Framework.

Confiabilidade

A confiabilidade garante que seu aplicativo possa cumprir os compromissos que você assume com os seus clientes. Para obter mais informações, confira Visão geral do pilar de confiabilidade.

O Azure Stack Hub ajuda a aumentar a disponibilidade da carga de trabalho por meio da resiliência inerente à sua infraestrutura. Essa resiliência fornece alta disponibilidade para VMs do Azure Stack Hub protegidas pelo Site Recovery e para componentes essenciais da infraestrutura de Site Recovery local, incluindo os servidores de configuração e processo.

Da mesma forma, você tem a opção de usar a resiliência de componentes baseados em nuvem da infraestrutura de Site Recovery. Por padrão, os Serviços de Recuperação do Azure são com redundância geográfica, o que significa que sua configuração é replicada automaticamente para uma região do Azure que faz parte de um par de regiões predefinido. Você tem a opção de alterar as configurações de replicação para localmente redundantes se isso for suficiente para suas necessidades de resiliência. Observe que não é possível alterar essa opção se o cofre contiver itens protegidos. A mesma opção de resiliência está disponível para qualquer conta de Armazenamento do Azure com a camada de desempenho padrão, embora seja possível alterá-la a qualquer momento.

Você pode aprimorar ainda mais o grau dessa resiliência projetando e implementando soluções que ampliam o escopo da proteção da carga de trabalho. Este é o valor agregado fornecido pelo Site Recovery. No contexto do Site Recovery em execução no Azure Stack Hub, há dois aspectos principais da disponibilidade da carga de trabalho que precisam ser explorados com mais detalhes:

• Failover para o Azure
• Failback para o Azure Stack Hub

Você precisa considerar ambos ao desenvolver uma estratégia de recuperação de desastres orientada por RPOs (Recovery Point Objectives, objetivos de ponto de recuperação) e RTOs (Recovery Time Objectives, objetivos de tempo de recuperação). RTO e RPO representam requisitos de continuidade estipulados por funções de negócios individuais dentro de uma organização. RPO designa um período de tempo que representa a perda máxima aceitável de dados após um incidente que afetou a disponibilidade desses dados. O RTO designa a duração máxima aceitável do tempo que pode levar para restabelecer funções de negócios após um incidente que afetou a disponibilidade dessas funções.

Failover para o Azure

O failover para o Azure está no centro das considerações de disponibilidade no contexto da proteção baseada em Site Recovery das VMs do Azure Stack Hub. Para maximizar a disponibilidade da carga de trabalho, a estratégia de failover deve abordar a necessidade de minimizar a potencial perda de dados (RPO) e minimizar o tempo de failover (RTO).

Para minimizar a perda de dados potencial, você pode considerar:

• Maximização da taxa de transferência e minimização da latência do tráfego de replicação seguindo considerações de escalabilidade e desempenho. Para obter mais informações, consulte a próxima seção deste artigo.
• Aumentar a frequência de pontos de recuperação consistentes com aplicativos para cargas de trabalho de banco de dados (até o máximo de um ponto de recuperação por hora). Os pontos de recuperação consistentes com aplicativo são criados com base nos instantâneos consistentes com aplicativo. Instantâneos consistentes com aplicativos capturam dados de aplicativos em disco e na memória. Embora essa abordagem minimize a perda potencial de dados, ela tem uma grande desvantagem. Instantâneos consistentes com aplicativos exigem o uso do Serviço de Cópias de Sombra de Volume no Windows ou scripts personalizados no Linux, para desativar aplicativos instalados localmente. O processo de captura pode prejudicar o desempenho, especialmente se a utilização de recursos for alta. Não é recomendável usar a frequência baixa para instantâneos consistentes com o aplicativo em cargas de trabalho que não são de banco de dados.

O principal método de minimizar o tempo de failover envolve o uso de planos de recuperação de Site Recovery. Um plano de recuperação orquestra um failover entre os sites primário e secundário, definindo a sequência na qual os servidores protegidos fazem failover. Você pode personalizar um plano adicionando instruções manuais e tarefas automatizadas. Seu objetivo é tornar o processo consistente, preciso, repetível e automatizado.

Ao criar um plano de recuperação, você atribui servidores protegidos a grupos de recuperação para fins de failover. Os servidores em cada grupo realizam failover juntos. Isso ajuda a dividir o processo de failover em unidades menores e mais fáceis de gerenciar, representando conjuntos de servidores que podem fazer failover sem depender de dependências externas.

Para minimizar o tempo de failover, como parte da criação de um plano de recuperação, você deve:

• Defina grupos de VMs do Azure Stack Hub que devem fazer failover juntos.
• Defina dependências entre grupos de VMs do Hub do Azure Stack para determinar a sequência ideal de um failover.
• Automatize tarefas de failover, se possível.
• Inclua ações manuais personalizadas, se necessário.

Você define um plano de recuperação e cria grupos de recuperação para capturar propriedades específicas do aplicativo. Como exemplo, vamos considerar um aplicativo tradicional de três camadas com um back-end baseado no SQL Server, um componente de middleware e um front-end da Web. Ao criar um plano de recuperação, você pode controlar a ordem de inicialização dos servidores em cada camada, com os servidores que executam instâncias do SQL Server ficando online primeiro, seguidos pelos da camada de middleware e unidos posteriormente pelos servidores que hospedam o front-end da Web. Essa sequência garante que o aplicativo esteja funcionando no momento em que o último servidor for iniciado. Para implementá-lo, basta criar um plano de recuperação com três grupos de recuperação, contendo servidores nas respectivas camadas.

Além de controlar o failover e a ordem de inicialização, você também tem a opção de adicionar ações a um plano de recuperação. Geralmente, há dois tipos de ações:

• Automatizado. Essa ação é baseada nos runbooks de Automação do Azure, que envolvem um dos dois tipos de tarefas:
  • Provisionamento e configuração de recursos do Azure, incluindo, por exemplo, a criação de um endereço IP público e a associação com a interface de rede anexada a uma VM do Azure.
  • Modificar a configuração do sistema operacional e dos aplicativos em execução em uma VM do Azure que foi provisionada após um failover.
• Manual. Essa ação não oferece suporte à automação e está incluída em um plano de recuperação principalmente para fins de documentação.

Failback para o Azure Stack Hub

Em cenários baseados no Site Recovery, o failback, se implementado corretamente, não envolve perda de dados. Isso significa que o foco da estratégia de failover é minimizar o tempo de failback (RTO). No entanto, como mencionado anteriormente, ao fazer failback para o Azure Stack Hub, você não pode confiar em seus planos de recuperação. Em vez disso, o failback envolve a seguinte sequência de etapas:

1. Pare e desaloque VMs do Azure no ambiente de recuperação de desastres.
2. Identifique o parâmetro URI de cada um dos discos gerenciados anexados às VMs que você pretende baixar.
3. Baixe os arquivos VHD (disco rígido virtual) identificados pelos parâmetros de URI identificados na etapa anterior para seu ambiente local.
4. Carregue os arquivos VHD no Azure Stack Hub.
5. Anexe os VHDs carregados a VMs novas ou existentes do Azure Stack Hub.
6. Inicie as VMs do Azure Stack Hub.

A abordagem ideal para minimizar o tempo de failback é automatizá-lo.

Considerações específicas sobre a carga de trabalho

O Site Recovery integra-se a aplicativos e funções baseados no Windows Server, incluindo SharePoint, Exchange, SQL Server e AD DS (Serviços de Domínio Active Directory). Isso permite que você use os seguintes recursos para implementar a proteção e a recuperação em nível de aplicativo:

• Integração com tecnologias de replicação em nível de aplicativo, como Grupos de Disponibilidade AlwaysOn do SQL Server, DAGs (Grupos de Disponibilidade de Banco de Dados) do Exchange e replicação do AD DS
• Instantâneos consistentes de aplicativos para os aplicativos simples ou multicamadas.
• Uma biblioteca de automação avançada que fornece scripts específicos do aplicativo, prontos para a produção, que pode ser baixada e integrada nos planos de recuperação

Como alternativa, você tem a opção de usar mecanismos de replicação específicos da carga de trabalho para fornecer resiliência no nível do site. Essa é uma opção comumente usada ao implementar a recuperação de desastres para controladores de domínio do AD DS, SQL Server ou Exchange, todos os quais oferecem suporte nativo à replicação. Embora isso exija o provisionamento de VMs do Azure que hospedam essas cargas de trabalho no ambiente de recuperação de desastres, o que aumenta o custo, ele oferece os seguintes benefícios:

• Reduz o tempo necessário para failover e failback
• Simplifica o failover em nível de carga de trabalho, acomodando cenários nos quais o failover no nível do site não é necessário

Segurança

O gerenciamento da recuperação de desastres de cargas de trabalho baseadas em VM de usuário em cenários híbridos garante considerações de segurança adicionais. Essas considerações podem ser agrupadas nas seguintes categorias:

• Criptografia em trânsito. Isso inclui a comunicação entre VMs protegidas do Azure Stack Hub, componentes locais de Site Recovery e componentes de Site Recovery baseados em nuvem:

  • O agente de mobilidade instalado nas VMs protegidas sempre se comunica com o servidor de processo por meio do Transport Layer Security (TLS) 1.2.
  • É possível que a comunicação do servidor de configuração para o Azure e do servidor de processo para o Azure use o TLS 1.1 ou 1.0. Para aumentar o nível de segurança da conectividade híbrida, você deve considerar a imposição do uso do TLS 1.2.

  Observação

  Para obter detalhes sobre como configurar a criptografia baseada em TLS 1.2, consulte Configurações do Registro TLS (Transport Layer Security) e Atualização para habilitar TLS 1.1 e TLS 1.2 como protocolos seguros padrão no WinHTTP no Windows

• Criptografia em repouso. Isso inclui o Armazenamento do Azure e as VMs do Azure no site de recuperação de desastres.

  • O Armazenamento do Azure é criptografado em repouso para todas as contas de armazenamento usando criptografia Advanced Encryption Standard de 256 bits e é compatível com o Federal Information Processing Standard 140-2. A criptografia é ativada automaticamente e não pode ser desativada. Por padrão, a criptografia usa chaves gerenciadas pela Microsoft, mas os clientes têm a opção de usar suas próprias chaves armazenadas em um cofre de chaves do Azure.
  • Os discos gerenciados de VMs do Azure são criptografados automaticamente usando a criptografia do lado do servidor dos discos gerenciados do Azure, que também se aplica a seus instantâneos, contando com o uso de chaves de criptografia gerenciadas por plataforma.

Além disso, você pode impor acesso restrito às contas de Armazenamento do Azure que hospedam conteúdo de discos replicados pelo Site Recovery. Para fazer isso, habilite a identidade gerenciada para o cofre dos Serviços de Recuperação e atribua a essa identidade gerenciada as seguintes funções de controle de acesso baseado em função do Azure (RBAC do Azure) no nível da conta de Armazenamento do Azure:

• Contas de armazenamento baseadas no Resource Manager (nível de desempenho Standard):
  • Colaborador
  • Colaborador de dados de blob de armazenamento
• Contas de armazenamento baseadas no Resource Manager (nível de desempenho Premium):
  • Colaborador
  • Proprietário de Dados do Blob de Armazenamento

O cofre dos Serviços de Recuperação do Azure oferece mecanismos que protegem ainda mais seu conteúdo, incluindo as seguintes proteções:

• RBAC do Azure. Isso permite a delegação e a segregação de responsabilidades de acordo com o princípio do menor privilégio. Há três funções internas relacionadas ao Site Recovery que restringem o acesso às operações do Site Recovery:
  • Colaborador do Site Recovery. Essa função tem todas as permissões necessárias para gerenciar operações do Azure Site Recovery em um cofre dos Serviços de Recuperação do Azure. No entanto, um usuário com essa função não pode criar ou excluir o cofre ou atribuir direitos de acesso a outros usuários. Esta função é mais adequada para administradores de recuperação de desastres que podem permitir e gerir a recuperação de desastres para um locatário do Azure Stack Hub.
  • Operador do Site Recovery. Esta função tem permissões para executar e gerenciar operações de failover e failback. Um usuário com essa função não pode habilitar ou desabilitar a replicação, criar ou excluir cofres, registrar nova infraestrutura ou atribuir direitos de acesso a outros usuários. Essa função é mais adequada para um operador de recuperação de desastres que pode fazer failover de VMs do Azure Stack Hub quando instruído por proprietários de aplicativos e administradores de TI em um cenário de desastre real ou simulado.
  • Leitor do Site Recovery. Essa função tem permissões para controlar todas as operações de gerenciamento do Site Recovery. Essa função é mais adequada para a equipe de TI responsável por monitorar o status de VMs protegidas do Azure Stack Hub e aumentar os tíquetes de suporte, se necessário.
• Bloqueios de recursos do Azure. Você tem a opção de criar e atribuir bloqueios somente leitura e excluir a um cofre do Site Recovery para reduzir o risco de o cofre ser alterado ou excluído acidental e maliciosamente.
• Exclusão temporária. O objetivo da exclusão suave é ajudar a proteger o cofre e seus dados contra exclusões acidentais ou maliciosas. Com a exclusão suave, qualquer conteúdo excluído é retido por 14 dias adicionais, permitindo sua recuperação durante esse período. A retenção adicional de 14 dias do conteúdo do cofre não incorre em nenhum custo. A exclusão suave está habilitada por padrão.
• Proteção de operações sensíveis à segurança. O cofre dos Serviços de Recuperação do Azure permite habilitar uma camada adicional de autenticação sempre que uma operação sensível à segurança, como desabilitar a proteção, é tentada. Essa validação extra ajuda a garantir que os usuários autorizados executem essas operações.
• Monitoramento e alertas de atividade suspeita. Os Serviços de Recuperação do Azure fornecem monitoramento interno e alertas de eventos sensíveis à segurança relacionados às operações do cofre.

Otimização de custo

A otimização de custos é a análise de maneiras de reduzir as despesas desnecessárias e melhorar a eficiência operacional. Para obter mais informações, confira Visão geral do pilar de otimização de custo.

Ao considerar o custo da solução de recuperação de desastres baseada em Site Recovery descrita neste artigo, você precisa levar em conta os componentes locais e baseados em nuvem. O modelo de preços do Azure Stack Hub determina a precificação dos componentes locais. Assim como no Azure, o Azure Stack Hub oferece um acordo de pagamento conforme o uso, disponível por meio de contratos corporativos e do programa Provedor de Soluções na Nuvem. Esse arranjo inclui um preço mensal para cada VM do Windows Server. Se você tiver a opção de usar licenças existentes do Windows Server, poderá reduzir significativamente o custo para o preço básico da VM. No entanto, com Site Recovery, você geralmente precisará de apenas uma única VM do Azure Stack Hub por locatário, que é necessária para implementar o servidor de configuração específico do locatário.

As cobranças relacionadas ao Azure estão associadas ao uso dos seguintes recursos:

• Serviços de Recuperação do Azure. O preço é determinado pelo número de instâncias protegidas. É importante notar que cada instância protegida não incorre em cobranças de Site Recovery durante os primeiros 31 dias.

• Armazenamento do Azure. O preço reflete uma combinação dos seguintes fatores:

  • Nível de desempenho
  • Volume de dados armazenados
  • Volume de transferência de dados de saída
  • Quantidade e tipos de operações executadas (somente para o nível de desempenho padrão)
  • Redundância de dados (somente para o nível de desempenho padrão)

• Azure ExpressRoute. O preço é baseado em um dos dois modelos:

  • Dados ilimitados. Este modelo inclui uma taxa mensal com todas as transferências de dados de entrada e saída incluídas.
  • Dados limitados. Este modelo inclui uma taxa mensal com todas as transferências de dados de entrada gratuitas e transferências de dados de saída cobradas por GB.

  Observação

  Essa avaliação não inclui os custos de conexões físicas fornecidas por provedores de conectividade de terceiros.

• VMs do Azure. O preço das VMs do Azure reflete uma combinação de dois componentes:

  • Custo de computação. O tamanho da VM, seu tempo de atividade e o modelo de licenciamento de seu sistema operacional determinam o custo.
  • Custo do disco gerenciado. O tamanho do disco e a camada de desempenho determinam o custo.

  Observação

  Vale a pena notar que a hidratação elimina a necessidade de executar VMs do Azure durante operações comerciais regulares, com cargas de trabalho em execução no Azure Stack Hub, o que reduz consideravelmente os custos de computação das implementações baseadas no Site Recovery, especialmente em comparação com as soluções tradicionais de recuperação de desastres.

  Observação

  Os preços dos recursos variam entre as regiões do Azure.

  Observação

  Para ver detalhes sobre preços, consulte Preços do Azure.

Excelência operacional

A excelência operacional abrange os processos de operações que implantam um aplicativo e o mantêm em execução na produção. Para obter mais informações, confira Visão geral do pilar de excelência operacional.

As principais considerações sobre a capacidade de gerenciamento da recuperação de desastres baseada no Site Recovery das VMs do Azure Stack Hub incluem:

• Implementação do Site Recovery no Azure Stack Hub
• Procedimentos de failover e failback
• Delegação de funções e responsabilidades
• DevOps

Implementação do Site Recovery no Azure Stack Hub

Para implementar o Site Recovery no Azure Stack Hub em um ambiente de locatário único de pequeno a médio porte, você pode seguir o processo de provisionamento manual orientado pela interface gráfica do Cofre dos Serviços de Recuperação no portal do Azure. Para implementações multilocatário, convém considerar a automação de partes do processo de implementação, porque normalmente será necessário configurar uma VM de servidor de configuração separada e um cofre de Serviços de Recuperação separado para cada locatário. Você também tem a opção de automatizar a implantação do agente de mobilidade seguindo o procedimento descrito em Preparar a máquina de origem para a instalação por push do agente de mobilidade.

Procedimentos de failover e failback

Para simplificar o gerenciamento de failover, considere a implementação de planos de recuperação para todas as cargas de trabalho protegidas. Para obter mais informações, consulte a seção Confiabilidade, anteriormente neste artigo. Você também encontrará recomendações para otimizar o gerenciamento do procedimento de failback.

Delegação de funções e responsabilidades

O planejamento e a implementação da recuperação de desastres de cargas de trabalho baseadas em VM do Azure Stack Hub usando o Site Recovery geralmente envolvem a interação das partes interessadas:

• Os operadores do Azure Stack Hub gerenciam a infraestrutura do Azure Stack Hub, garantindo que haja recursos de computação, armazenamento e rede suficientes necessários para implementar uma solução abrangente de recuperação de desastres e disponibilizar esses recursos aos locatários. Eles também colaboram com proprietários de aplicativos e dados para ajudar a determinar a abordagem ideal para implantar suas cargas de trabalho no Azure Stack Hub.
• Os administradores do Azure gerenciam os recursos do Azure necessários para implementar soluções híbridas de recuperação de desastres.
• Os administradores do Microsoft Entra gerenciam recursos do Microsoft Entra, incluindo objetos de usuário e grupo que são usados para provisionar, configurar e gerenciar recursos do Azure.
• A equipe de TI do locatário do Azure Stack Hub projeta, implementa e gerencia o Site Recovery, incluindo failover e failback.
• Os usuários do Azure Stack Hub precisam fornecer requisitos de RPO e RTO e enviar solicitações para implementar a recuperação de desastres para suas cargas de trabalho.

Certifique-se de que há uma compreensão clara das funções e responsabilidades atribuídas aos proprietários e operadores de aplicativos no contexto de proteção e recuperação. Os usuários são responsáveis por proteger as VMs. Os operadores são responsáveis pelo status operacional da infraestrutura do Azure Stack Hub.

DevOps

Embora a configuração da recuperação em nível de VM usando o Site Recovery seja principalmente uma responsabilidade das operações de TI, há algumas considerações específicas de DevOps que devem ser incorporadas a uma estratégia abrangente de recuperação de desastres. O Azure Stack Hub facilita a implementação da Infraestrutura como Código (IaC), que incorpora a implantação automatizada de uma variedade de cargas de trabalho, incluindo aplicativos e serviços baseados em VM. Você pode usar esse recurso para simplificar o provisionamento de cenários de recuperação de desastres baseados na Site Recovery, o que simplifica a configuração inicial em vários cenários de locatário.

Por exemplo, você pode usar os mesmos modelos do Gerenciador de Recursos do Azure para provisionar todos os recursos de rede necessários para acomodar cargas de trabalho baseadas em VM em um carimbo do Azure Stack Hub para seu aplicativo em uma única operação coordenada. Você pode usar o mesmo modelo para provisionar um conjunto correspondente de recursos no Azure para provisionar um site de recuperação de desastre. Para levar em conta quaisquer diferenças entre os dois ambientes, você pode simplesmente especificar valores diferentes de parâmetros de modelo em cada caso.

Eficiência de desempenho

A eficiência do desempenho é a capacidade de dimensionar sua carga de trabalho para atender às demandas colocadas por usuários de maneira eficiente. Para obter mais informações, consulte Visão geral do pilar de eficiência de desempenho.

Ao planejar a implantação do Site Recovery no Azure Stack Hub, você precisa considerar a quantidade de recursos de processamento, armazenamento e rede alocados para os servidores de configuração e processo. Talvez seja necessário ajustar o dimensionamento estimado da VM do Azure Stack Hub que hospeda os componentes do Site Recovery após a implantação para acomodar alterações nos requisitos de processamento ou armazenamento. Você tem três opções básicas para ajustar o dimensionamento:

• Implementar dimensionamento vertical. Isso envolve modificar a quantidade e o tipo de recursos de processador, memória e disco da VM do Azure Stack Hub que hospeda o servidor de configuração, incluindo o servidor de processo. Para estimar os requisitos de recursos, você pode usar as informações na tabela a seguir:

  Requisitos de dimensionamento do servidor de processo e configuração

  CPU	Memória	Cache de disco	Taxa de alteração de dados	Computadores protegidos
  8 vCPUs 2 soquetes * 4 núcleos de 2,5 GHz	16 GB	300 GB	500 GB ou menos	< 100 computadores
  12 vCPUs 2 soquetes * 6 núcleos de 2,5 GHz	18 GB	600 GB	500 GB -1 TB	100 a 150 computadores
  16 vCPUs 2 soquetes * 8 núcleos de 2,5 GHz	32 GB	1 TB	1-2 TB	150-200 computadores

• Implementar dimensionamento horizontal. Isso envolve provisionar ou desprovisionar VMs do Azure Stack Hub com o servidor de processo instalado para corresponder às demandas de processamento de VMs protegidas do Azure Stack Hub. Em geral, se for necessário escalar horizontalmente sua implantação para além de 200 computadores de origem ou se você tiver uma taxa de rotatividade diária total acima de 2 TB, serão necessários servidores de processo adicionais para lidar com o tráfego de replicação. Para estimar o número e a configuração de servidores de processo adicionais, consulte Recomendações de tamanho para o servidor de processo.

• Modificar a política de replicação. Isso envolve a alteração de parâmetros da política de replicação, com foco em snapshots consistentes com aplicativos.

Do ponto de vista da rede, há vários métodos diferentes para ajustar a largura de banda disponível para o tráfego de replicação:

• Modifique o tamanho da VM. O tamanho das VMs do Azure Stack Hub determina a largura de banda máxima da rede. No entanto, é importante notar que não há garantias de largura de banda. Em vez disso, as VMs podem utilizar a quantidade de largura de banda disponível até o limite determinado por seu tamanho.

• Substitua os switches de uplink. Os sistemas do Azure Stack Hub dão suporte a uma variedade de switches de hardware, oferecendo várias opções de velocidades de uplink. Cada nó de cluster do Azure Stack Hub tem dois uplinks para a parte superior dos switches de rack para tolerância a falhas. O sistema aloca metade da capacidade de uplink para infraestrutura crítica. O restante é capacidade compartilhada para serviços do Azure Stack Hub e todo o tráfego de usuários. Os sistemas implantados com velocidades mais rápidas têm mais largura de banda disponível para o tráfego de replicação.

  Observação

  Embora seja possível segregar o tráfego de rede anexando um segundo adaptador de rede a um servidor, com as VMs do Azure Stack Hub, todo o tráfego de VM para a Internet compartilha o mesmo uplink. Um segundo adaptador de rede virtual não segregará o tráfego no nível de transporte físico.

• Modifique a taxa de transferência da conexão de rede com o Azure. Para acomodar volumes maiores de tráfego de replicação, você pode considerar o uso do Azure ExpressRoute com emparelhamento da Microsoft para conexões entre redes virtuais do Azure Stack Hub e o Armazenamento do Azure. O Azure ExpressRoute estende as redes locais até a nuvem da Microsoft por meio de conexão privada fornecida por um provedor de conectividade. Você pode comprar circuitos de Rota Expressa para uma ampla gama de larguras de banda, de 50 megabits por segundo (Mbps) a 100 gigabits por segundo.

  Observação

  Para obter detalhes sobre a implementação do Azure ExpressRoute em cenários do Azure Stack Hub, consulte Conectar o Azure Stack Hub ao Azure usando o Azure ExpressRoute.

• Modifique a limitação do tráfego de replicação no servidor de processo. Você pode controlar quanta largura de banda é usada pelo tráfego de replicação nas VMs que estão hospedando servidores de processo na interface gráfica do agente dos Serviços de Recuperação do Microsoft Azure. Os recursos compatíveis incluem a definição dos limites para horas de trabalho e não de trabalho, com os valores de largura de banda variando de 512 kilobits por segundo a 1.023 Mbps. Como alternativa, você pode aplicar a mesma configuração usando o cmdlet Set-OBMachineSetting PowerShell.

• Modifique a largura de banda de rede alocada por VM protegida no servidor de processo. Para fazer isso, modifique o valor da entrada UploadThreadsPerVM dentro da chave HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows Azure Backup\Replication . Por padrão, o valor é definido como 4, mas você pode aumentá-lo para 32 se houver largura de banda de rede suficiente disponível.

Implantar este cenário

Pré-requisitos

A implementação da solução recomendada depende do cumprimento dos seguintes pré-requisitos:

• Acesso a uma assinatura do Azure, com permissões suficientes para provisionar e gerenciar todos os componentes de nuvem dos componentes do Site Recovery, incluindo:

  • Cofre dos Serviços de Recuperação do Azure na região do Azure designada como o site de recuperação de desastres para o ambiente de produção do Azure Stack Hub.
  • Uma conta de Armazenamento do Azure que hospeda conteúdo de discos replicados de VMs do Azure Stack Hub.
  • Uma rede virtual do Azure que representa o ambiente de recuperação de desastres ao qual as VMs do Azure hidratadas serão conectadas após um failover planejado ou não planejado.
  • Uma rede virtual isolada do Azure que representa o ambiente de teste ao qual as VMs do Azure hidratadas serão conectadas após um failover de teste.
  • Uma conectividade baseada na Rota Expressa do Azure entre o ambiente local, as redes virtuais do Azure e a conta de armazenamento do Azure usada para hospedar cópias de arquivos VHD com conteúdo replicado de discos de VMs protegidas do Azure Stack Hub.

• Uma assinatura de usuário do Azure Stack Hub. Todas as VMs do Azure Stack Hub protegidas por um servidor de configuração individual do Site Recovery devem pertencer à mesma assinatura de usuário do Azure Stack Hub.

• Uma rede virtual do Azure Stack Hub. Todas as VMs protegidas devem ter conectividade direta com as VMs que hospedam o componente do servidor de processo (por padrão, essa é a VM do servidor de configuração).

• Uma VM do Windows Server do Hub do Azure Stack que hospedará o servidor de configuração e um servidor de processo. A VM deve pertencer à mesma assinatura e estar anexada à mesma rede virtual que as VMs do Azure Stack Hub que precisam ser protegidas. Além disso, a VM precisa:

  • Estar em conformidade com os requisitos de software e hardware do servidor de configuração do Site Recovery
  • Satisfaça a documentação de requisitos de rede de conectividade externa.

  Observação

  Considerações adicionais sobre armazenamento e desempenho para os servidores de configuração e processo são descritas com mais detalhes posteriormente nesta arquitetura.

  • Satisfaça os requisitos internos de conectividade. Em particular, as VMs do Azure Stack Hub que você deseja proteger precisam ser capazes de se comunicar com:

    • O servidor de configuração via porta TCP 443 (HTTPS) de entrada para gerenciamento de replicação
    • O servidor de processo via porta TCP 9443 para fornecer dados de replicação.

    Observação

    Você pode alterar a porta usada pelo servidor de processo para conectividade externa e interna como parte de sua configuração ao executar a Instalação Unificada do Site Recovery.

• VMs do Azure Stack Hub a serem protegidas, executando qualquer um dos sistemas operacionais com suporte para proteger VMs do Azure Stack Hub que executam sistemas operacionais Windows Server, você deve:

  • Crie uma conta do Windows com direitos administrativos. Você pode especificar essa conta ao habilitar o Site Recovery nessas VMs. O servidor de processo usa essa conta para instalar o serviço de Mobilidade de Site Recovery. Em um ambiente de grupo de trabalho, certifique-se de desabilitar o controle de Acesso de Usuário Remoto nos sistemas operacionais Windows Server de destino definindo o valor da entrada de registro LocalAccountTokenFilterPolicy DWORD na chave HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System para 1.
  • Habilite as regras de Compartilhamento de Arquivos e Impressoras e Instrumentação de Gerenciamento do Windows no firewall do Microsoft Defender.

• Para proteger VMs do Azure Stack Hub que executam sistemas operacionais Linux, você deve:

  • Criar uma conta de usuário raiz. Você pode especificar essa conta ao habilitar o Site Recovery nessas VMs. O servidor de processo usa essa conta para instalar o serviço de Mobilidade de Site Recovery.
  • Instale os pacotes openssh, openssh-server e openssl mais recentes.
  • Habilite e execute a porta 22 do Secure Shell (SSH).
  • Habilite o subsistema FTP seguro e a autenticação de senha.

Etapas de implementação de alto nível

Em um alto nível, a implementação da recuperação de desastres baseada em Site Recovery no Azure Stack Hub consiste nos seguintes estágios:

1. Prepare as VMs do Azure Stack Hub para serem protegidas pelo Site Recovery. Verifique se as VMs atendem aos pré-requisitos do Site Recovery listados na seção anterior.

2. Crie e configure um cofre dos Serviços de Recuperação do Azure. Configure um cofre dos Serviços de Recuperação do Azure e especifique o que deseja replicar. Os componentes e atividades do Site Recovery são configurados e gerenciados usando o cofre.

3. Configurar o ambiente de replicação de origem. Provisione um servidor de configuração e um servidor de processo do Site Recovery instalando os binários da Instalação Unificada do Site Recovery e registre-os no cofre.

   Observação

   Você pode executar novamente a Instalação Unificada do Site Recovery para implementar servidores de processo adicionais em VMs do Azure Stack Hub.

4. Configurar o ambiente de replicação de destino. Crie ou selecione uma conta de armazenamento existente do Azure e uma rede virtual do Azure na região do Azure que hospedará o site de recuperação de desastres. Durante a replicação, o conteúdo dos discos para as VMs protegidas do Azure Stack Hub é copiado para a conta de Armazenamento do Azure. Durante o failover, o Site Recovery provisiona automaticamente as VMs do Azure que servem como réplicas de VMs protegidas do Azure Stack Hub e as conecta à rede virtual do Azure.

5. Habilite a replicação. Configure a replicação e habilite a replicação para as VMs do Azure Stack Hub. O serviço de mobilidade é instalado automaticamente em cada VM do Azure Stack Hub para a qual a replicação está habilitada. O Site Recovery inicia a replicação de cada VM do Azure Stack Hub, de acordo com as configurações de política definidas.

6. Execute um failover de teste. Depois que a replicação for estabelecida, verifique se o failover funcionará conforme o esperado executando um failover de teste.

7. Execute um failover planejado ou não planejado. Após um failover de teste bem-sucedido, você está pronto para conduzir um failover planejado ou não planejado para o Azure. Você tem a opção de designar quais VMs do Azure Stack Hub incluir no failover.

8. Executar um failback. Quando você estiver pronto para fazer failback, pare as VMs do Azure correspondentes às VMs do Azure Stack Hub que você falhou, baixe seus arquivos de disco para o armazenamento local, carregue-os no Azure Stack Hub e anexe-os a uma VM nova ou existente.

Resumo

Em conclusão, o Azure Stack Hub é uma oferta exclusiva, que difere em muitos aspectos de outras plataformas de virtualização. Como tal, merece considerações especiais no que diz respeito à estratégia de continuidade de negócios para suas cargas de trabalho. Usando os serviços do Azure, você pode simplificar o design e a implementação dessa estratégia. Neste artigo de referência de arquitetura, exploramos o uso do Microsoft Site Recovery para proteger cargas de trabalho baseadas em VM do Azure Stack Hub no modelo de implantação conectado. Essa abordagem permite que os clientes se beneficiem da resiliência e da capacidade de gerenciamento do Azure Stack Hub e da hiperescala e da presença global da nuvem do Azure.

É importante observar que a solução de recuperação de desastres descrita aqui se concentrou exclusivamente em cargas de trabalho baseadas em VM do Azure Stack Hub. Isso é apenas parte de uma estratégia geral de continuidade de negócios que deve levar em conta outros tipos de carga de trabalho do Azure Stack Hub e cenários que afetam sua disponibilidade.

Próximas etapas

Documentação do produto:

• Sobre o Site Recovery
• Visão geral do Azure Stack Hub
• O que é o Microsoft Entra ID?
• O que é o Armazenamento de Blobs do Azure?
• O que é o Azure ExpressRoute?
• O que é a Rede Virtual do Azure?

Módulos do Microsoft Learn:

• Azure Stack Hub
• Configuração do Microsoft Entra ID
• Configurar contas de armazenamento
• Configurar redes virtuais
• Projetar e implementar o Azure ExpressRoute
• Projetar sua solução de recuperação de site no Azure

Recursos relacionados

• Projeto de arquitetura híbrida
• Fazer backup de arquivos e aplicativos no Azure Stack Hub
• Conexões Híbridas
• Compartilhamento de arquivo híbrido com recuperação de desastre para funcionários de filiais locais e remotas