Compartilhar via

Visão geral e diretrizes de infraestrutura da recuperação de desastre para cargas de trabalho SAP

  • Artigo

Muitas organizações que executam aplicativos empresariais críticos no Azure configuram a estratégia de HA (alta disponibilidade) e DR (recuperação de desastre). A finalidade da alta disponibilidade é aumentar o SLA dos sistemas empresariais, eliminando os pontos únicos de falha na infraestrutura do sistema subjacente. As tecnologias de alta disponibilidade reduzem o efeito da falha de infraestrutura não planejada e ajudam na manutenção planejada. A Recuperação de Desastres é definida como políticas, ferramentas e procedimentos que permitem a recuperação ou a continuação de sistemas e infraestrutura de tecnologia vital após um desastre natural ou induzido pelo homem, geograficamente disseminado.

Para obter alta disponibilidade para a carga de trabalho SAP no Azure, as máquinas virtuais são normalmente implantadas em um conjunto de disponibilidade, zonas de disponibilidade ou em um conjunto de escala flexível para proteger os aplicativos contra manutenção ou falha da infraestrutura dentro da região. Mas a implantação não protege os aplicativos contra desastres generalizados na região. Portanto, para proteger os aplicativos contra desastres regionais, a estratégia de recuperação de desastre para os aplicativos deve estar em vigor. A recuperação de desastre é uma abordagem documentada e estruturada criada para ajudar uma organização a executar os processos de recuperação em resposta a um desastre e 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 contra catástrofes em larga escala, implementando a 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 da DR e a ordem de recuperação da 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 carga de trabalho SAP.

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

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 executada nos sistemas SAP pode não funcionar 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 a DR no Azure, as organizações devem considerar diferentes cenários que podem disparar o failover.

  • Disponibilidade do processo empresarial ou do aplicativo SAP.
  • Indisponibilidade dos serviços do Azure (como máquinas virtuais, armazenamento, balanceador de carga etc.) em uma região devido a uma falha generalizada.
  • Possíveis vulnerabilidades e ameaças ao aplicativo (por exemplo, ataque de DDoS na camada de aplicativo)
  • A conformidade empresarial exigiu tarefas operacionais para testar a estratégia de DR (por exemplo, o exercício de falha de DR a ser executado 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 (Objetivo de Tempo de Recuperação) e o RPO (Objetivo de Ponto de Recuperação) para a carga de trabalho com base nos requisitos de negócios. O RTO descreve o período em que o aplicativo pode ficar inativo, geralmente medido em horas, minutos ou segundos. Enquanto que o RPO descreve o volume de dados transacionais que as empresas aceitam perder para que as operações normais sejam retomadas. Identificar o RTO e o RPO da empresa é essencial, pois ajudará a criar a estratégia de DR de maneira ideal. 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 técnicas diferentes (serviços nativos do Azure, tecnologia de replicação de BD nativo, scripts personalizados). Cada técnica fornece um RPO diferente, que deve ser considerado ao criar uma estratégia de DR. No Azure, você pode usar alguns dos serviços nativos do Azure, como o Azure Site Recovery e o Backup do Azure, os quais podem ajudar a atender ao RTO e ao RPO das cargas de trabalho SAP. Veja o SLA do Azure Site Recovery e do Backup do Azure para se alinhar de maneira ideal ao RTO e ao RPO.

Consideração de design para recuperação de desastre no Azure

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

  • Os requisitos de conformidade comercial ou regulatória podem especificar um requisito de distância entre um site primário e um de recuperação de desastres. Um requisito de distância ajuda a fornecer disponibilidade, se ocorrer um desastre natural em uma área geográfica mais generalizada. Nesse caso, uma organização pode escolher outra região do Azure como o site de recuperação de desastre. 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 no Estados Unidos. Devido à distância, a latência de ida e volta da rede pode ser maior, o que pode resultar em um RPO mais alto.

  • Os clientes que desejam reproduzir sua estratégia de DR metropolitana local no Azure podem usar zonas de disponibilidade para recuperação de desastre. Mas a estratégia de DR zona a zona pode não atender ao requisito de resiliência se houver um desastre natural geograficamente generalizado.

  • No Azure, cada região é emparelhada com outra região na mesma área geográfica (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ões. Se uma organização optar por usar as regiões emparelhadas do Azure, vários pontos adicionais para uma carga de trabalho SAP precisarão ser considerados:

    • Nem todos os serviços do Azure oferecem replicação entre regiões na região emparelhada.

    • Os serviços e recursos do Azure em regiões emparelhadas do Azure podem não ser simétricos. Por exemplo, o Azure NetApp Files, os 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 os produtos ou os serviços do Azure estão disponíveis em uma região, confira Produtos do Azure por Região.

    • A opção de GRS está disponível para conta de armazenamento com o tipo de armazenamento padrão que replica dados para a região emparelhada. Mas o armazenamento padrão não é adequado para SAP DBMS 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 nativos do DBMS, como replicação do sistema SQL Server Always On, SAP HANA e outros serviços. Use uma combinação de Azure Site Recovery, rsync ou robocopy e outros componentes de software de terceiros para a camada do aplicativo SAP.

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

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

  • Implante a carga de trabalho SAP de produção na região primária e a carga de trabalho não relacionada à produção na região de recuperação de desastre.
  • Implante toda a carga de trabalho SAP (produção e não produção) na região primária. A região de recuperação de desastre só será 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 a alta disponibilidade na região primária. O site secundário mostrado abaixo é o site de recuperação de desastre em que os sistemas SAP serão restaurados após um evento de desastre. As regiões primária e de recuperação de desastre fazem parte da mesma assinatura. Para realizar a DR para carga de trabalho SAP, você precisa identificar a estratégia de recuperação para cada camada SAP, juntamente com os diferentes serviços do Azure usados pelo aplicativo.

As organizações devem planejar e elaborar uma estratégia de DR para todo o cenário de TI. Normalmente, os sistemas SAP em execução no ambiente de produção são integrados a diferentes serviços e interfaces, como Active Directory, DNS, aplicativo de terceiros e assim por diante. Portanto, você também deve incluir os sistemas não SAP e outros serviços no planejamento de recuperação de desastre. 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 desastre 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 componentes de infraestrutura a seguir devem ser considerados ao criar uma solução de DR para carga de trabalho SAP no Azure.

  • Rede
  • Computação
  • Armazenamento

Rede

  • O ExpressRoute estende as redes locais para a nuvem da Microsoft em uma conexão privada com a ajuda de um provedor de conectividade. Ao criar a arquitetura de recuperação de desastre, é necessário considerar a criação de uma conectividade de rede de back-end robusta, usando o circuito do ExpressRoute com redundância geográfica. É aconselhável configurar pelo menos um circuito ExpressRoute do local para a região primária, e o outro deve se conectar à região de recuperação de desastres. Consulte o artigo Projeto do Azure ExpressRoute para recuperação de desastres, que descreve diferentes cenários para projetar a recuperação de desastres para o ExpressRoute.

    Observação

    Configure uma VPN S2S (site a site) como backup do Azure ExpressRoute. Para obter mais informações, confira Como usar a VPN S2S como backup para 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 desastre. Veja Sobre a rede na recuperação de desastre 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 sistemas SAP. Para sistemas clusterizados, o Standard Load Balancer fornece o endereço IP virtual para o serviço de cluster, como instâncias do ASCS/SCS e bancos de dados em execução nas VMs. Para executar o sistema SAP com alta disponibilidade no site de DR, um balanceador de carga separado deve ser criado e a configuração do cluster deve ser ajustada adequadamente.

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

  • Como os componentes de rede (como rede virtual, firewall etc.) são criados separadamente na região de DR, você precisa garantir que a carga de trabalho SAP na região de DR seja 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 a 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 nas VMs do Azure pode ser habilitada replicando componentes por meio do 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 site primário para o site de recuperação de desastre. Dependendo da região da DR do Azure selecionada, o tipo de SKU de VM pode não estar disponível no site da DR. Você precisa garantir que os tipos de SKU de VM necessários também estejam disponíveis na região de DR do Azure. Verifique os Produtos do Azure por Região para ver se o tipo de SKU da família de VMs necessário está disponível.

    Importante

    Se o sistema SAP estiver configurado com conjunto de dimensionamento flexível 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 desastre para VMs implantadas no conjunto de dimensionamento.

  • Para bancos de dados em execução nas máquinas virtuais do Azure, é recomendável usar a tecnologia de replicação de banco de dados nativo para sincronizar dados com o site de recuperação de desastre. 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 desastre, verifique se os respectivos SKUs de VM estão disponíveis na zona do site de recuperação de desastre.

    Observação

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

  • Com os aplicativos de produção em execução na região primária o tempo todo, as instâncias de reserva são usadas normalmente para economizar custos do Azure. Se estiver usando Instâncias reservadas, você precisará se inscrever para um compromisso de um ou três anos, o 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 de SKU da VM necessária durante o failover. Para garantir que a capacidade de SKU da VM esteja disponível, você pode considerar a opção de habilitar a reserva de capacidade sob demanda. Ela reserva a capacidade de computação em uma região do Azure ou em uma zona de disponibilidade do Azure por qualquer período, sem compromisso. O Azure Site Recovery é integrado à 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 os 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 de VMs (por exemplo, família Mv2) e outros recursos. Às vezes, as organizações desejam usar uma assinatura diferente do Azure para DR. Cada assinatura (primária e de DR) pode ter cotas diferentes atribuídas a 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 para configurar a DR, os discos gerenciados locais anexados às VMs são replicados para a região da DR. Durante a replicação, as gravações em 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 com base nos dados. Ao fazer 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, confira 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 Disco Compartilhado do Azure (versão prévia). 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 os cenários compatíveis com o Disco Compartilhado do Azure, consulte Matriz de suporte para discos compartilhados na recuperação de desastres de VM do Azure (versão prévia)

  • Além dos discos de dados gerenciados do Azure anexados a VMs, diferentes soluções de armazenamento nativas do Azure são usadas para executar o aplicativo 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 são compatíveis com o Azure Site Recovery. Veja abaixo a lista de tipos de armazenamento que normalmente são usados para carga de trabalho SAP.

    Tipo de armazenamento Recomendação de 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 no Azure NetApp Files Usar Replicação entre regiões dos volumes do Azure NetApp Files
    Disco Compartilhado do Azure (LRS ou ZRS) Azure Site Recovery com o Disco Compartilhado do Azure (em versão prévia)
    SMB em arquivos do Azure (LRS ou ZRS) Usar RoboCopy para copiar arquivos entre dois sites
    SMB no Azure NetApp Files Usar Replicação entre regiões dos volumes do Azure NetApp Files

  • Para soluções de armazenamento personalizadas, como clusters 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, Azure NetApp Files) 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, verifique se o respectivo serviço de armazenamento é oferecido no site de DR. Para obter mais informações, confira Produtos do Azure por região.

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

  • Se estiver usando zonas de disponibilidade para recuperação de desastre, tenha em mente os seguintes pontos:

    • O recurso do Azure NetApp Files ainda não tem reconhecimento de zona. No momento, o recurso do Azure NetApp Files não está implantado em todas as zonas de disponibilidade em uma região do Azure. Portanto, pode acontecer de o serviço Azure NetApp Files não estar disponível na zona de disponibilidade escolhida para sua estratégia de DR.
    • A replicação entre regiões dos volumes do Azure NetApp File só está disponível em pares de regiões fixos, não entre zonas.

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

Próximas etapas