Visão geral da recuperação de desastres e diretrizes de infraestrutura para carga de trabalho SAP

  • Artigo

Muitas organizações que executam aplicativos de negócios críticos no Azure configuram a estratégia de Alta Disponibilidade (HA) e Recuperação de Desastres (DR). O objetivo da alta disponibilidade é aumentar o SLA dos sistemas de negócios, eliminando pontos únicos de falha na infraestrutura do sistema subjacente. As tecnologias de alta disponibilidade reduzem o efeito de falhas não planejadas na infraestrutura e ajudam na manutenção planejada. A recuperação de desastres é definida como políticas, ferramentas e procedimentos para permitir a recuperação ou a continuação de infraestruturas e sistemas tecnológicos vitais após um desastre natural ou induzido pelo homem geograficamente generalizado.

Para obter alta disponibilidade para a carga de trabalho SAP no Azure, as máquinas virtuais geralmente são implantadas em um conjunto de disponibilidade, zonas de disponibilidade ou em um conjunto de escala flexível para proteger os aplicativos contra manutenção de infraestrutura ou falha na região. Mas a implantação não protege os aplicativos de desastres generalizados na região. Portanto, para proteger os aplicativos contra desastres regionais, a estratégia de recuperação de desastres para os aplicativos deve estar em vigor. A recuperação de desastres é uma abordagem documentada e estruturada projetada para ajudar uma organização a executar os processos de recuperação em resposta a um desastre e para proteger ou minimizar a interrupção dos serviços de TI e promover a recuperação.

Este documento fornece detalhes sobre como proteger cargas de trabalho SAP de catástrofes de grande escala implementando uma abordagem de DR estruturada. Os detalhes neste documento são apresentados em um nível abstrato, com base em diferentes serviços do Azure e componentes SAP. A estratégia exata de DR e a ordem de recuperação para sua carga de trabalho SAP devem ser testadas, documentadas e ajustadas regularmente. Além disso, o documento se concentra na estratégia de DR do Azure para o Azure para a carga de trabalho do SAP.

Considerações gerais sobre o plano de recuperação de desastres

A carga de trabalho SAP no Azure é executada em máquinas virtuais em combinação com diferentes serviços do Azure para implantar diferentes camadas (serviços centrais, servidores de aplicativos, servidor de banco de dados) de um aplicativo SAP NetWeaver típico. Em geral, uma estratégia de DR deve ser planejada para todo o cenário de TI em execução no Azure, o que significa levar em conta também aplicativos não SAP. A solução de negócios em execução em sistemas SAP pode não ser executada como um todo, se os serviços ou ativos dependentes não forem recuperados no site de DR. Portanto, você precisa criar um plano de DR abrangente bem definido, considerando todos os componentes e sistemas.

Para DR no Azure, as organizações devem considerar diferentes cenários que podem desencadear failover.

  • Disponibilidade de aplicativos ou processos de negócios SAP.
  • Indisponibilidade dos serviços do Azure (como máquinas virtuais, armazenamento, balanceador de carga, etc.) dentro de uma região devido a falha generalizada.
  • Ameaças e vulnerabilidades potenciais para o aplicativo (por exemplo, ataque DDoS da camada de aplicativo)
  • A conformidade comercial exigia tarefas operacionais para testar a estratégia de DR (por exemplo, exercício de falha de DR a ser realizado todos os anos de acordo com a conformidade).

Para atingir a meta de recuperação para diferentes cenários, a organização deve descrever o RTO (Recovery Time Objetive, objetivo de tempo de recuperação) e o RPO (Recovery Point Objetive, objetivo de ponto de recuperação) para sua carga de trabalho com base nos requisitos de negócios. O RTO descreve a quantidade de tempo que o aplicativo pode ficar inativo, normalmente medido em horas, minutos ou segundos. Considerando que o RPO descreve a quantidade de dados transacionais que é aceitável para os negócios perderem para que as operações normais sejam retomadas. Identificar RTO e RPO do seu negócio é crucial, pois ajudaria você a projetar sua estratégia de DR de forma otimizada. Os componentes (computação, armazenamento, banco de dados, etc.) envolvidos na carga de trabalho SAP são replicados para a região de DR usando diferentes técnicas (serviços nativos do Azure, tecnologia de replicação de banco de dados nativa, scripts personalizados). Cada técnica fornece RPO diferente, que deve ser levado em conta ao projetar uma estratégia de DR. No Azure, você pode usar alguns dos serviços nativos do Azure, como o Azure Site Recovery, o Backup do Azure, que pode ajudá-lo a atender ao RTO e ao RPO de suas cargas de trabalho SAP. Consulte o SLA do Azure Site Recovery e o Backup do Azure para alinhar de forma ideal com seu RTO e RPO.

Considerações de design para recuperação de desastres no Azure

Há diferentes elementos a serem considerados ao projetar uma solução de recuperação de desastres no Azure. Os princípios e conceitos considerados para projetar soluções de recuperação de desastres locais também se aplicam ao Azure. Mas, no Azure, a seleção de regiões é uma parte fundamental na estratégia de design para recuperação de desastres. Portanto, tenha em mente os seguintes pontos ao escolher a região de DR no Azure.

  • Os requisitos de conformidade normativa ou de negócios podem especificar um requisito de distância entre um local principal e um local de recuperação de desastres. Um requisito de distância ajuda a fornecer disponibilidade se ocorrer um desastre natural em uma geografia mais ampla. Nesse caso, uma organização pode escolher outra região do Azure como seu site de recuperação de desastres. As regiões do Azure geralmente são separadas por uma grande distância que pode ser de centenas ou até milhares de quilômetros, como nos Estados Unidos. Devido à distância, a latência de ida e volta da rede pode ser maior, o que pode resultar em RPO mais alto.

  • Os clientes que desejam imitar sua estratégia de DR de metrô local no Azure podem usar zonas de disponibilidade para recuperação de desastres. Mas a estratégia de DR de zona a zona pode ficar aquém do requisito de resiliência se houver um desastre natural geograficamente generalizado.

  • No Azure, cada região é emparelhada com outra região dentro da mesma geografia (exceto para o Sul do Brasil). Essa abordagem permite a replicação de recursos fornecida pela plataforma em toda a região. O benefício de escolher a região emparelhada pode ser encontrado no documento de pares de região. Se uma organização optar por usar regiões emparelhadas do Azure, vários pontos adicionais para uma carga de trabalho SAP precisam ser considerados:

    • Nem todos os serviços do Azure oferecem replicação inter-regional em região emparelhada.

    • Os serviços e recursos do Azure em regiões emparelhadas do Azure podem não ser simétricos. Por exemplo, Arquivos NetApp do Azure, SKUs de VM como a Série M disponíveis na região Primária podem não estar disponíveis na região emparelhada. Para verificar se o produto ou serviços do Azure está disponível em uma região, consulte Produtos do Azure por região.

    • A opção GRS está disponível para conta de armazenamento com tipo de armazenamento padrão que replica dados para a região emparelhada. Mas o armazenamento padrão não é adequado para DBMS SAP ou discos de dados virtuais.

    • O serviço de backup do Azure usado para fazer backup de soluções com suporte pode replicar backups somente entre regiões emparelhadas. Para todos os outros dados, execute suas próprias replicações com recursos DBMS nativos, como SQL Server Always On, SAP HANA System Replication e outros serviços. Use uma combinação de Azure Site Recovery, rsync ou robocopy e outro software de terceiros para a camada de aplicativos SAP.

Implantação de carga de trabalho SAP de referência

Depois de identificar uma região de DR, é importante que a amplitude dos serviços principais do Azure (como rede, computação, armazenamento) configurados na região primária esteja disponível e possa ser configurada na região de DR. A organização deve desenvolver um padrão de implantação de DR para a carga de trabalho SAP. O padrão de implantação varia e deve estar alinhado com as necessidades da organização.

  • Implante a carga de trabalho SAP de produção em sua região principal e a carga de trabalho que não é de produção na região de recuperação de desastres.
  • Implante toda a carga de trabalho SAP (produção e não produção) em sua região principal. A região de recuperação de desastres só é usada se houver um failover.

A arquitetura de referência a seguir mostra o sistema SAP NetWeaver típico em execução no Azure, juntamente com alta disponibilidade na região primária. O local secundário mostrado abaixo é o local de recuperação de desastres onde os sistemas SAP serão restaurados após um evento de desastre. As regiões principal e de recuperação de desastres fazem parte da mesma assinatura. Para obter a carga de trabalho de DR para SAP, você precisa identificar a estratégia de recuperação para cada camada SAP junto com os diferentes serviços do Azure que o aplicativo usa.

As organizações devem planejar e projetar uma estratégia de DR para todo o seu cenário de TI. Normalmente, os sistemas SAP executados em ambiente de produção são integrados com diferentes serviços e interfaces, como Ative Directory, DNS, aplicativos de terceiros e assim por diante. Portanto, você também deve incluir os sistemas não-SAP e outros serviços em seu planejamento de recuperação de desastres. Este documento se concentra no planejamento de recuperação para aplicativos SAP. Mas você pode expandir o tamanho e o escopo do planejamento de DR para componentes dependentes para atender às suas necessidades.

Arquitetura de referência de recuperação de desastres para carga de trabalho SAP

Componentes de infraestrutura da solução de DR para carga de trabalho SAP

Uma carga de trabalho SAP em execução no Azure usa diferentes componentes de infraestrutura para executar uma solução de negócios. Para planejar a DR para essa solução, é essencial que todos os componentes de infraestrutura configurados na região primária estejam disponíveis e também possam ser configurados na região de DR. Os seguintes componentes de infraestrutura devem ser levados em consideração ao projetar a solução de DR para carga de trabalho SAP no Azure.

  • Rede
  • Computação
  • Armazenamento

Rede

  • O ExpressRoute estende sua rede local para a nuvem da Microsoft por meio de uma conexão privada com a ajuda de um provedor de conectividade. Ao projetar a arquitetura de recuperação de desastres, deve-se levar em conta a construção de uma conectividade de rede de back-end robusta usando o circuito ExpressRoute com redundância geográfica. É aconselhável configurar pelo menos um circuito de Rota Expressa do local para a região principal, e o outro deve se conectar à região de recuperação de desastres. Consulte o artigo Designing of Azure ExpressRoute for disaster recovery , que descreve diferentes cenários para projetar a recuperação de desastres para a Rota Expressa.

    Nota

    Considere configurar uma VPN site a site (S2S) como um backup da Rota Expressa do Azure. Para obter mais informações, consulte Usando VPN S2S como backup para o emparelhamento privado do Azure ExpressRoute.

  • A rede virtual e as sub-redes abrangem todas as zonas de disponibilidade de uma região. Para DR em duas regiões, você precisa configurar redes virtuais e sub-redes separadas na região de recuperação de desastres. Consulte Sobre a rede na recuperação de desastres da VM do Azure para saber mais sobre a configuração de rede na região de DR.

  • O Azure Standard Load Balancer fornece elementos de rede para o design de alta disponibilidade dos seus sistemas SAP. Para sistemas clusterizados, o Standard Load Balancer fornece o endereço IP virtual para o serviço de cluster, como instâncias ASCS/SCS e bancos de dados executados em VMs. Para executar o sistema SAP altamente disponível no site de DR, um balanceador de carga separado deve ser criado e a configuração do cluster deve ser ajustada de acordo.

  • O Gateway de Aplicativo do Azure é um balanceador de carga de tráfego da Web. Com a sua funcionalidade Web Application Firewall , o seu serviço adequado para expor aplicações Web à Internet com segurança melhorada. O Gateway de Aplicativo do Azure pode atender clientes públicos (Internet) ou privados, ou ambos, dependendo da configuração. Após o failover, para aceitar tráfego HTTPs de entrada semelhante na região DR, um Gateway de Aplicativo do Azure separado deve ser configurado na região DR.

  • Como os componentes de rede (como rede virtual, firewall, etc.) são criados separadamente na região de DR, você precisa se certificar de que a carga de trabalho SAP na região de DR esteja adaptada às alterações de rede, como atualização de DNS, firewall, etc.

  • As redes virtuais em ambas as regiões são independentes e, para estabelecer comunicação entre as duas, você precisa habilitar o emparelhamento de rede virtual entre as duas regiões.

Máquinas virtuais

  • No Azure, diferentes componentes de um único sistema SAP são executados em máquinas virtuais com diferentes tipos de SKU. Para DR, a proteção de um aplicativo (SAP NetWeaver e não-SAP) em execução em VMs do Azure pode ser habilitada replicando componentes usando o Azure Site Recovery para outra região ou zona do Azure. Com o Azure Site Recovery, as VMs do Azure são replicadas continuamente do local principal para o local de recuperação de desastres. Dependendo da região de DR do Azure selecionada, o tipo de SKU de VM pode não estar disponível no site de DR. Você precisa certificar-se de que os tipos de SKU de VM necessários também estão disponíveis na região DR do Azure. Verifique os Produtos do Azure por Região para ver se o tipo de SKU da família VM necessário está disponível ou não.

    Importante

    Se o sistema SAP estiver configurado com escala flexível definida com FD=1, você precisará usar o PowerShell para configurar o Azure Site Recovery para recuperação de desastres. Atualmente, é o único método disponível para configurar a recuperação de desastres para VMs implantadas em conjunto de escala.

  • Para bancos de dados executados em máquinas virtuais do Azure, é recomendável usar a tecnologia de replicação de banco de dados nativa para sincronizar dados com o site de recuperação de desastres. As VMs grandes nas quais os bancos de dados estão sendo executados podem não estar disponíveis em todas as regiões. Se você estiver usando zonas de disponibilidade para recuperação de desastres, verifique se as respetivas SKUs de VM estão disponíveis na zona do seu site de recuperação de desastres.

    Nota

    Não é aconselhável usar o Azure Site Recovery para bancos de dados, pois ele não garante a consistência do banco de dados e tem limitação de rotatividade de dados.

  • Com aplicativos de produção em execução na região primária o tempo todo, as instâncias de reserva geralmente são usadas para economizar custos do Azure. Se estiver usando instâncias reservadas, você precisará se inscrever para um compromisso de 1 ou 3 anos que pode não ser econômico para o site de DR. Além disso, configurar o Azure Site Recovery não garante a capacidade da SKU de VM necessária durante o failover. Para certificar-se de que a capacidade de SKU da VM está disponível, você pode considerar uma opção para habilitar a reserva de capacidade sob demanda. Ele reserva a capacidade de computação em uma região do Azure ou em uma zona de disponibilidade do Azure por qualquer período de tempo sem compromisso. O Azure Site Recovery é integrado com a reserva de capacidade sob demanda. Com essa integração, você pode usar o poder da reserva de capacidade com o Azure Site Recovery para reservar a capacidade de computação no site de DR e garantir seus failovers. Para obter mais informações, leia Limitações e restrições de reserva de capacidade sob demanda.

  • Uma assinatura do Azure tem cotas para famílias VM (por exemplo, família Mv2) e outros recursos. Às vezes, as organizações querem usar uma assinatura diferente do Azure para DR. Cada assinatura (primária e DR) pode ter cotas diferentes atribuídas para cada família de VMs. Verifique se a assinatura usada para o site de DR tem cotas de computação suficientes disponíveis.

Armazenamento

  • Ao habilitar o Azure Site Recovery para uma VM configurar a DR, os discos gerenciados locais anexados às VMs são replicados para a região de DR. Durante a replicação, as gravações de disco da VM são enviadas para uma conta de armazenamento em cache na região de origem. Os dados são enviados de lá para a região de destino e os pontos de recuperação são gerados a partir dos dados. Quando você faz failover de uma VM durante a DR, um ponto de recuperação é usado para restaurar a VM na região de destino. Mas o Azure Site Recovery não dá suporte a todos os tipos de armazenamento disponíveis no Azure. Para obter mais informações, consulte Matriz de suporte do Azure Site Recovery para armazenamentos.

  • Para o sistema SAP em execução no Windows com disco compartilhado do Azure, você pode usar o Azure Site Recovery com o Azure Shared Disk (visualização). Como o recurso está em visualização pública, não recomendamos a implementação do cenário para as cargas de trabalho de produção SAP mais críticas. Para obter mais informações sobre cenários com suporte para o Disco Compartilhado do Azure, consulte Matriz de suporte para discos compartilhados na recuperação de desastres da VM do Azure (visualização)

  • Além dos discos de dados gerenciados do Azure anexados a VMs, diferentes soluções de armazenamento nativo do Azure são usadas para executar aplicativos SAP no Azure. A abordagem de DR para cada solução de armazenamento do Azure pode ser diferente, pois nem todos os serviços de armazenamento disponíveis no Azure têm suporte com o Azure Site Recovery. Abaixo está a lista de tipos de armazenamento normalmente usados para a carga de trabalho SAP.

    Tipo de armazenamento Recomendação da estratégia de DR
    Disco gerenciado Azure Site Recovery
    NFS em arquivos do Azure (LRS ou ZRS) Script personalizado para replicar dados entre dois sites (por exemplo, rsync)
    NFS em arquivos NetApp do Azure Usar a replicação entre regiões de volumes do Azure NetApp Files
    Azure Shared Disk (LRS ou ZRS) Azure Site Recovery com Disco Compartilhado do Azure (em visualização)
    SMB em arquivos do Azure (LRS ou ZRS) Use o RoboCopy para copiar arquivos entre dois sites
    SMB em arquivos NetApp do Azure Usar a replicação entre regiões de volumes do Azure NetApp Files

  • Para soluções de armazenamento personalizadas, como cluster NFS, você precisa garantir que a estratégia de DR apropriada esteja em vigor.

  • Diferentes serviços de armazenamento nativos do Azure (como Arquivos do Azure, Arquivos NetApp do Azure) podem não estar disponíveis em todas as regiões. Portanto, para ter uma configuração SAP semelhante na região de DR após o failover, certifique-se de que o respetivo serviço de armazenamento seja oferecido no site de DR. Para obter mais informações, consulte Produtos do Azure por Região.

  • Se você estiver usando o armazenamento de redundância de zona (ZRS) para Arquivos do Azure e o Disco Compartilhado do Azure em sua região principal e quiser manter a mesma opção de redundância do ZRS também na região DR, consulte [Suporte ZRS para compartilhamentos de arquivos premium](Suporte de armazenamento com redundância de zona (ZRS) de Arquivos do Azure para compartilhamentos de arquivos premium | Microsoft Learn) e ZRS para discos gerenciados documento para suporte a ZRS em regiões do Azure.

  • Se estiver usando zonas de disponibilidade para recuperação de desastres, lembre-se dos seguintes pontos:

    • O recurso Arquivos NetApp do Azure ainda não reconhece zona. Atualmente, o recurso Arquivos NetApp do Azure não é implantado em todas as zonas de disponibilidade em uma região do Azure. Portanto, pode acontecer que o serviço Azure NetApp Files não esteja disponível na zona de disponibilidade escolhida para sua estratégia de DR.
    • A replicação entre regiões dos volumes do Arquivo NetApp do Azure só está disponível em pares de regiões fixas, não entre zonas.

  • Se você configurar seu armazenamento com integração com o Ative Directory, uma configuração semelhante também deverá ser feita na conta de armazenamento do site de DR.

Próximos passos