Continuidade de negócios e recuperação de desastres para uma migração do SAP

  • Artigo

Este artigo baseia-se em algumas das considerações e recomendações definidas na área de design da zona de destino do Azure para BCDR. O artigo pode ajudá-lo a entender as restrições exclusivas em qualquer zona de destino que dê suporte a uma plataforma SAP. Como o SAP é uma plataforma crítica, você também deve se referir às outras diretrizes apresentadas na seção Áreas de design da zona de destino do Azure desta documentação e incorporá-la ao seu design.

Cenário e escopo

Sua arquitetura precisa incorporar princípios que abordam cenários locais de BCDR (continuidade dos negócios e recuperação de desastres). Esses princípios também se aplicam ao Azure. A main diferença é que o Azure pode ter mais capacidade de hardware do que seu ambiente local para compensar uma falha de host. Você pode recuperar automaticamente até mesmo as maiores VMs do Azure configurando-as para reiniciar em outro servidor. Configure suas implantações do Azure para usar as mesmas condições que suas implantações locais. Se você implantou sistemas locais ou hardware bare-metal usando configurações automáticas de cluster de failover, implante-os da mesma maneira no Azure. Os aplicativos SAP que executam os processos de negócios mais críticos de uma organização exigem:

  • Disponibilidade do processo de serviço e de negócios.
  • RTOs (objetivos de tempo de recuperação) para cenários de falha ou desastre.
  • RPOs (objetivos de ponto de recuperação) para cenários de falha.
  • Tarefas operacionais e de gerenciamento do ciclo de vida e tecnologia que preenche durante cenários de falha. Essas tarefas de gerenciamento incluem aplicação de patches em sistemas operacionais convidados e sistemas de gerenciamento de banco de dados, clonagem e atualização de sistemas SAP.

Dica

Concorde com uma solução hadr (alta disponibilidade e recuperação de desastre) para cada um dos arquétipos em seu cenário sap no início. Verifique se todos os componentes sap são cobertos com uma solução apropriada.

Configure o HADR no Azure mais cedo, em pelo menos um cenário, e mantenha-o em execução lá. Isso dá às suas equipes a oportunidade de adquirir experiência nas tecnologias envolvidas, o que pode ser diferente das tecnologias existentes. Configurar o HADR antecipadamente também pode ajudá-lo a desenvolver e desenvolver seus SOP (procedimentos operacionais padrão).

Planeje ter alta disponibilidade completa, recuperação de desastre e proteção de backup para cargas de trabalho de produção assim que o sistema estiver ativo.

Este artigo aborda os seguintes aspectos do BCDR para um cenário de SAP de escala empresarial:

  • Alta disponibilidade em uma região do Azure.
  • Considerações sobre backup e restauração.
  • Critérios para decidir entre a recuperação de desastres entre regionais e regionais.

Alta disponibilidade em uma região do Azure

As seções a seguir fornecem considerações de design e recomendações para alta disponibilidade em uma região do Azure para um cenário empresarial sap.

Considerações de design para alta disponibilidade

Para alta disponibilidade, o foco é fornecer disponibilidade para o ponto único de falha do software SAP, como:

  • Sistemas de gerenciamento de banco de dados.
  • Pontos únicos de falha no aplicativo, como SAP ABAP e ASCS + SCS. Os exemplos incluem o SAP NetWeaver e a arquitetura SAP S/4HANA.
  • Outras ferramentas, como o SAP Web Dispatcher.

Para outros cenários, não restrinja a disponibilidade a falhas de infraestrutura ou software. Aplique a disponibilidade a todas as tarefas necessárias de gerenciamento do ciclo de vida, como aplicação de patch do sistema operacional nas VMs, no DBMS e no software SAP. Para minimizar interrupções que podem ocorrer durante operações planejadas de tempo de inatividade e gerenciamento do ciclo de vida, use ferramentas comuns que ajudam a proteger seus sistemas contra interrupções de serviço não planejadas.

O SAP e os bancos de dados SAP dão suporte a clusters de failover automático. No Windows, o Clustering de Failover do Windows Server dá suporte ao failover. No Linux, o Linux Pacemaker ou ferramentas de terceiros, como o SIOS Protection Suite e o Veritas InfoScale, dão suporte ao failover. Com o Azure, você pode implantar apenas uma configuração de alta disponibilidade de subconjunto em seu próprio datacenter.

Para saber mais sobre como o Azure dá suporte ao SAP, consulte Cenários com suporte para cargas de trabalho SAP em VMs do Azure e Cenários com suporte para Instâncias Grandes do SAP HANA.

Para a camada DBMS, o padrão de arquitetura comum é replicar bancos de dados ao mesmo tempo e com pilhas de armazenamento diferentes daquelas que as VMs primárias e secundárias usam. O Azure não dá suporte a arquiteturas nas quais as VMs primárias e secundárias compartilham o armazenamento para dados DBMS. Nem Suporte do Azure logs de transação ou refazer. O princípio de orientação é usar duas pilhas de armazenamento independentes, mesmo que elas sejam baseadas em compartilhamentos NFS (Sistema de Arquivos de Rede). Essa abordagem é a limitação main quando você compara o que é possível localmente com o que é possível no Azure.

O Azure fornece outras opções, pois dá suporte ao compartilhamento de NFS ou Bloco de Mensagens do Servidor. Você pode usar discos compartilhados do Azure no Windows para componentes ASCS + SCS e cenários específicos de alta disponibilidade. Configure os clusters de failover separadamente para componentes da camada de aplicativo SAP e a camada DBMS. Atualmente, o Azure não dá suporte a arquiteturas de alta disponibilidade que combinam componentes da camada de aplicativo SAP e a camada DBMS em um cluster de failover.

A maioria dos clusters de failover para componentes da camada de aplicativo SAP e a camada DBMS exige um endereço IP virtual para um cluster de failover. Uma exceção comum é quando você usa o Oracle Data Guard. Ele não requer um endereço IP virtual. O Azure Load Balancer deve lidar com o endereço IP virtual para todos os outros casos. Um princípio de design é usar um balanceador de carga por configuração de cluster. Recomendamos que você use a versão padrão do balanceador de carga. Para obter mais informações, consulte Conectividade de ponto de extremidade público para máquinas virtuais usando o Azure Standard Load Balancer em cenários de alta disponibilidade do SAP.

Para obter mais informações e opções, confira Arquitetura e cenários de alta disponibilidade para SAP NetWeaver.

A seguir estão os SLAs no nível da plataforma para diferentes opções de implantação de alta disponibilidade. Os parceiros que fornecem os serviços gerenciados fornecem o SLA no nível do aplicativo.

Camada Cenário de HA SLA da plataforma
Camada 1 Zona de disponibilidade 99,99%
Camada 2 Conjunto de disponibilidade 99,95%
Nível 3 VM única (autorrecuperação) 99,9%

Para obter mais informações, consulte a próxima seção.

Conjuntos de disponibilidade do Azure versus zonas de disponibilidade

Antes de implantar sua infraestrutura de alta disponibilidade e dependendo da região escolhida, determine se deseja implantar com um conjunto de disponibilidade do Azure ou uma zona de disponibilidade. As diferenças de main para VMs implantadas com um conjunto de disponibilidade são:

  • As VMs não são distribuídas entre diferentes zonas de disponibilidade.
  • O tipo de VMs que você pode implantar por meio de um único conjunto de disponibilidade é restrito porque o host é definido pela primeira VM implantada no conjunto. Um exemplo de resultado é que você não poderá combinar VMs da série M e da série E em um conjunto de disponibilidade.

Uma vantagem de implantar sua arquitetura de alta disponibilidade em diferentes zonas de disponibilidade é que o SLA (contrato de nível de serviço) para as VMs pode ser maior. Para obter detalhes, consulte SLAs de VM do Azure. Dependendo da região do Azure, você pode descobrir diferentes condições de latência de rede no tráfego entre as VMs. Para obter mais informações, confira Configurações de carga de trabalho do SAP com zonas de disponibilidade do Azure.

Se você escolher uma abordagem de implantação zonal, considere os efeitos da latência entre zonas para a região escolhida do Azure, entre o servidor de aplicativos e o banco de dados e entre os dois nós de banco de dados, nas opções de design de desempenho e arquitetura.

Se você usar uma implantação zonal ativa/passiva para a camada de servidor de aplicativos (os servidores de aplicativos devem se conectar ao banco de dados na mesma zona de disponibilidade), criar automação e um SOP para habilitar a recuperação rápida e automatizada se houver um failover de banco de dados.

Se você usar zonas de disponibilidade em sua solução SAP, projete todos os outros serviços do Azure e componentes de infraestrutura no cenário do SAP para redundância de zona também para que você possa obter redundância de zona verdadeira. Exemplos de serviços e componentes a levar em conta são gateways do Azure ExpressRoute, Azure Load Balancer, Arquivos do Azure, Azure NetApp Files, proxy reverso, firewalls, antivírus e infraestrutura de backup.

Recomendações de design para alta disponibilidade

  • O Azure fornece várias opções para ajudá-lo a atender aos SLAs de infraestrutura do aplicativo. Você deve escolher a mesma opção para todos os três componentes SAP: serviços centrais, servidor de aplicativos e banco de dados. Para obter informações sobre SLAs para VMs, conjuntos de disponibilidade e zonas de disponibilidade, consulte SLA para Máquinas Virtuais.

  • Quando você implanta VMs em um conjunto de disponibilidade, o alinhamento com domínios de falha e atualização impede que as VMs fiquem no mesmo hardware de host, o que fornece proteção contra falhas de hardware. Quando você implanta VMs por meio de zonas de disponibilidade e usa zonas diferentes, as VMs são criadas em diferentes locais físicos. Essa configuração fornece proteção adicional contra problemas de energia, resfriamento ou rede que afetam os datacenters da zona como um todo. No entanto, você não pode implantar conjuntos de disponibilidade do Azure em uma zona de disponibilidade do Azure, a menos que use grupos de posicionamento por proximidade.

    Se você escolher uma abordagem de implantação zonal, o DBMS do SAP, os serviços centrais e as camadas de aplicativo serão executados em diferentes zonas de disponibilidade. No entanto, cada zona de disponibilidade provavelmente terá vários servidores de aplicativos. Nesse cenário, os servidores de aplicativos em cada zona não se beneficiam automaticamente de domínios de falha e domínios de atualização. Você pode obter esses benefícios usando conjuntos de disponibilidade, conforme descrito em Grupos de posicionamento por proximidade do Azure para obter a latência de rede ideal com o SAP.

  • Ao criar conjuntos de disponibilidade, use o número máximo de domínios de falha e domínios de atualização disponíveis. Por exemplo, se você implantar mais de duas VMs em um conjunto de disponibilidade, use o número máximo de domínios de falha (três) e domínios de atualização suficientes para limitar o efeito de possíveis falhas de hardware físico, interrupções de rede ou interrupções de energia, além da manutenção planejada do Azure. O número padrão de domínios de falha é dois e você não pode alterá-lo online mais tarde.

  • Em uma implantação de conjunto de disponibilidade, cada componente de um sistema SAP precisa estar em seu próprio conjunto de disponibilidade. Os serviços centrais do SAP, o banco de dados e as VMs de aplicativo devem estar em seus próprios conjuntos de disponibilidade.

  • Quando você usa grupos de posicionamento por proximidade do Azure em uma implantação de conjunto de disponibilidade, todos os três componentes SAP (serviços centrais, servidor de aplicativos e banco de dados) devem estar no mesmo grupo de posicionamento por proximidade.

  • Se você usar grupos de posicionamento por proximidade, use um por SID SAP. Os grupos não se estendem entre zonas de disponibilidade ou regiões do Azure.

  • Quando você usa grupos de posicionamento por proximidade do Azure em uma implantação de zonas de disponibilidade, os dois componentes sap (serviços centrais e servidor de aplicativos) devem estar no mesmo grupo de posicionamento por proximidade. As VMs de banco de dados das duas zonas não fazem mais parte dos grupos de posicionamento por proximidade. Os grupos de posicionamento por zona de proximidade têm como escopo a implantação da VM que executa as instâncias do SAP ASCS + SCS. A vantagem dessa configuração é que você tem mais flexibilidade no redimensionamento de VMs. Também é mais fácil mover para novos tipos de VM na camada DBMS ou na camada de aplicativo do sistema SAP.

  • Atualmente, o Azure não dá suporte à combinação de alta disponibilidade do ASCS e do banco de dados em um único cluster do Linux Pacemaker. Separe-os em clusters individuais. Você pode combinar até cinco clusters de serviços centrais em um par de VMs.

  • Use um SKU Standard Load Balancer na frente de clusters de banco de dados e ASCS.

  • Execute todos os sistemas de produção em SSDs gerenciados Premium e use Azure NetApp Files ou Armazenamento em Disco Ultra. Pelo menos o disco do sistema operacional deve estar na camada Premium para que você possa obter um melhor desempenho e o melhor SLA.

  • Implante ambas as VMs no par de alta disponibilidade em um conjunto de disponibilidade ou em zonas de disponibilidade. Essas VMs devem ter o mesmo tamanho e ter a mesma configuração de armazenamento.

  • Use a tecnologia de replicação de banco de dados nativo para sincronizar o banco de dados em um par de alta disponibilidade.

  • Use um dos seguintes serviços para executar clusters de serviços centrais do SAP, dependendo do sistema operacional:

  • Configure os parâmetros de tempo limite do cluster conforme recomendado na documentação para serviços centrais e clusters de banco de dados.

Armazenamento para cargas de trabalho SAP

  • Escolher as opções de armazenamento certas faz parte do design para resiliência para sua carga de trabalho sap. O design para cargas de trabalho SAP no armazenamento do Azure destina-se a manter a latência para um mínimo e maximizar a taxa de transferência. Considere sua implementação e como as diretrizes a seguir podem ajudá-lo a tomar decisões de arquitetura para sua implementação do SAP no Azure. Para obter informações sobre os vários tipos de armazenamento e sua compatibilidade com cargas de trabalho e componentes do SAP, consulte Tipos de Armazenamento do Azure para cargas de trabalho SAP.

  • Você deve executar o SAP HANA no Azure somente nos tipos de armazenamento certificados pelo SAP. Observe que determinados volumes devem ser executados em determinadas configurações de disco, quando aplicável. Essas configurações incluem habilitar o Acelerador de Gravação e usar o armazenamento Premium. Você também precisa garantir que o sistema de arquivos executado no armazenamento seja compatível com o DBMS executado no computador. Para obter mais informações, consulte Configurações de armazenamento para SAP HANA.

  • Além dos discos de dados gerenciados do Azure anexados a VMs, várias soluções de armazenamento compartilhado nativas do Azure são usadas para executar aplicativos SAP no Azure. Sua configuração de alta disponibilidade pode ser diferente, pois alguns serviços de armazenamento disponíveis no Azure não têm suporte do Azure Site Recovery. Os tipos de armazenamento a seguir normalmente são usados para cargas de trabalho SAP.

    Tipo de armazenamento Suporte à configuração de alta disponibilidade
    Discos compartilhados do Azure (LRS ou ZRS) Cluster de Failover do Windows Server. Para obter detalhes de configuração, consulte Criar HA do SAP com failover do Windows Server clustering .
    NFS no Arquivos do Azure (LRS ou ZRS) Cluster baseado no Pacemaker em ambientes Linux. Certifique-se de marcar a disponibilidade do NFS em regiões diferentes..
    NFS no Azure NetApp Files Cluster baseado no Pacemaker em ambientes Linux. Para obter mais informações, consulte Azure NetApp Files para máquinas virtuais SAP.
    SMB no Arquivos do Azure (LRS ou ZRS) Cluster de Failover do Windows Server. Para obter detalhes de configuração, consulte Alta disponibilidade para SAP NetWeaver em VMs do Azure no Windows com Arquivos do Azure SMB Premium para aplicativos SAP.
    SMB no Azure NetApp Files Cluster de Failover do Windows Server. Para obter detalhes de configuração, consulte Alta disponibilidade para SAP NetWeaver em VMs do Azure no Windows com Azure NetApp Files (SMB) para aplicativos SAP.

  • Em vez de serviços de armazenamento compartilhado nativos do Azure, você pode usar clusters NFS tradicionais (com base na replicação drbd), GlusterFS ou volume compartilhado clusterizado com Espaços de Armazenamento Diretos como uma solução de armazenamento compartilhado alternativa para executar cargas de trabalho SAP no Azure. Essas opções são especialmente úteis quando os serviços de armazenamento compartilhado nativos do Azure não estão disponíveis na região do Azure de destino ou não dão suporte à arquitetura de destino. Para obter informações sobre a disponibilidade do serviço de armazenamento, confira Produtos do Azure por região.

  • Para saber mais sobre as opções de armazenamento disponíveis para cargas de trabalho sap no Azure, confira as recomendações e diretrizes de armazenamento para configurar a recuperação de desastre.

Backup e restauração

As seções a seguir descrevem considerações e recomendações de design para backup e restauração em um cenário SAP.

Embora o backup e a restauração normalmente não sejam considerados uma solução adequada de alta disponibilidade para uma carga de trabalho SAP de produção, a tecnologia oferece outros benefícios. A maioria das empresas que usam aplicativos SAP precisa seguir os regulamentos de conformidade que exigem o armazenamento de backups por muitos anos. Também é essencial ter um backup e ser capaz de restaurá-lo em outros cenários. A suposição é que você já estabeleceu e está seguindo as práticas recomendadas de backup e restauração para aplicativos SAP, o que significa que você pode:

  • Execute uma recuperação pontual para seus bancos de dados de produção a qualquer momento, em um período que atenda ao RTO. A recuperação pontual normalmente fornece proteção contra erros do operador, como a exclusão de dados, na camada DBMS ou por meio do SAP.

  • Mantenha um repositório para manter seus backups de longo prazo para atender aos regulamentos de conformidade.

  • Use backups de banco de dados para clonar o sistema SAP e restaurar os backups em outro servidor ou VM.

  • Use dados do banco de dados de produção de backups do banco de dados para atualizar sistemas de não produção.

  • Faça backup de servidores de aplicativos SAP e VMs, discos ou instantâneos de VM.

Ao fazer backup e restaurar localmente, você precisa trazer esses recursos para sistemas SAP no Azure.

Se você estiver satisfeito com sua solução atual, marcar se o fornecedor de backup dá suporte a implantações do Azure ou se ele tem uma solução de SaaS (software como serviço) para o Azure.

O Azure fornece um serviço de SaaS de backup, Backup do Azure, que usa instantâneos de VM e gerencia SQL Server de streaming e backups do SAP HANA. Se você usar Azure NetApp Files para armazenar seus bancos de dados sap HANA, poderá executar backups com base em instantâneos de armazenamento consistentes com o HANA.

Recomendações de design para backup e restauração

  • Você pode usar Backup do Azure para fazer backup do servidor de aplicativos SAP e VMs de serviços centrais.

  • Você pode usar um backup do SAP HANA para implantações do HANA de até 8 TB. Para obter mais informações, consulte a matriz de suporte para fazer backup de bancos de dados sap HANA em VMs do Azure.

  • Se você usar uma solução de backup de IaaS, dimensione a infraestrutura de backup para garantir que ela possa fazer backup de todos os sistemas de tamanho de produção simultaneamente ou como em um cenário da vida real, dentro dos prazos esperados e usando uma configuração de produção ou uma configuração semelhante em termos de rede, segurança e assim por diante.

  • Teste os tempos de backup e recuperação para verificar se eles atendem aos seus requisitos de RTO para restaurar todos os sistemas simultaneamente após um desastre.

  • Idealmente, evite efetuar pull dos backups do Azure para sua infraestrutura de backup local, especialmente para bancos de dados grandes. Isso afeta a largura de banda que os circuitos do ExpressRoute usam.

  • Teste de carga das ferramentas de backup e recuperação como parte do plano de teste de desempenho.

Recuperação de desastre

As seções a seguir descrevem considerações de design e recomendações para recuperação de desastre em um cenário SAP.

Considerações de design para recuperação de desastre

O mapa de regiões do Azure mostra mais de 65 regiões do Azure e nem todas elas executam os mesmos serviços. Para implantações de software SAP maiores, especialmente aquelas que usam o SAP HANA, procure regiões do Azure que oferecem VMs da série M ou Mv2 do Azure. O Armazenamento do Microsoft Azure também emparelha regiões diferentes para replicar um subconjunto menor de tipos de armazenamento para outra região. Para obter mais informações, consulte Visão geral das regiões emparelhadas do Azure.

Os principais desafios de emparelhar regiões do Azure para cargas de trabalho do SAP são:

  • Os pares nem sempre são consistentes com os serviços de VM da série M ou Mv2. Muitas organizações que implantam seus sistemas SAP não usam regiões emparelhadas do Azure. Em vez disso, eles escolhem regiões com base na disponibilidade dos tipos de VM necessários.

  • Você pode replicar o armazenamento padrão entre regiões emparelhadas, mas não pode usar o armazenamento padrão para armazenar seus bancos de dados ou discos rígidos virtuais. Você pode replicar backups somente entre regiões emparelhadas que você usa. Para todos os outros dados, execute a replicação usando recursos nativos do DBMS, como SQL Server Always On ou Replicação do Sistema SAP HANA. Use uma combinação de Site Recovery, rsync ou robocopye outros softwares de terceiros para a camada de aplicativo SAP.

  • Se ocorrer um desastre, vários clientes afetados em uma região do Azure desejarão fazer failover para a região de DR emparelhada correspondente. Essa situação leva à concorrência de recursos para abrir VMs inativas na região de DR. A solução alternativa é executar sistemas de não produção na região de DR e usar os mesmos recursos para hospedar réplicas de DR de sistemas de produção. Esse uso de duas finalidades de infraestruturas do Azure na região de DR ajuda a evitar restrições de capacidade de recursos.

Outra consideração importante é proteger a capacidade operacional necessária na região de desastre. Se ocorrer um desastre, talvez seja necessário executar o aplicativo SAP por um período mínimo de tempo com capacidade mínima de TI e recursos humanos críticos apenas enquanto trabalha para recuperar a operação normal na região primária. Isso exige que você tenha infraestrutura mínima de TI disponível na região de DR.

Depois de definir suas regiões do Azure, você precisará escolher um padrão de implantação:

  • Você implantará sistemas de produção em sua região primária?
  • Você implantará sistemas SAP de não produção na região de recuperação de desastre?
  • Você usará uma arquitetura que agrupa todos os sistemas SAP na região primária? Essa configuração garante que a região de recuperação de desastre seja usada apenas para recuperação de desastre.

A maioria das organizações usa ambas as regiões para sistemas SAP operacionais. As organizações que executam cópias completas de sistemas de produção como sistemas de teste de regressão de negócios normalmente planejam usar o sistema de teste de regressão de negócios da linha de produtos SAP como um destino de recuperação de desastre.

Ao escolher uma região de recuperação de desastre, certifique-se de ter conectividade do ExpressRoute com essa região. Se você tiver vários circuitos do ExpressRoute se conectando ao Azure, pelo menos um desses circuitos deverá se conectar à região primária do Azure. Os outros devem se conectar à região de recuperação de desastre. Esse tipo de arquitetura conecta você à rede do Azure em uma área geográfica/geopolítica diferente e ajuda a proteger sua conexão se uma catástrofe afetar uma das regiões do Azure.

Algumas organizações usam uma arquitetura de alta disponibilidade e recuperação de desastre combinada, que agrupa alta disponibilidade com recuperação de desastre na mesma região do Azure. Mas agrupar alta disponibilidade com recuperação de desastre não é o ideal. As zonas de disponibilidade do Azure dão suporte a essa arquitetura. Como a distância entre as zonas de disponibilidade dentro de uma região do Azure não é tão grande quanto a distância entre duas regiões do Azure, um desastre natural pode comprometer os serviços de aplicativo na região em que ela ocorre. Você também precisa considerar a latência entre servidores de aplicativos SAP e servidores de banco de dados. Por nota sap 1100926, um tempo de ida e volta menor ou igual a 0,3 ms é um bom valor e um tempo menor ou igual a 0,7 ms é um valor moderado. Portanto, para zonas com alta latência, os procedimentos operacionais precisam estar em vigor para garantir que servidores de aplicativos SAP e servidores de banco de dados estejam em execução na mesma zona o tempo todo. As organizações escolhem essa arquitetura pelos seguintes motivos:

  • A conformidade é suficiente com configurações que dão suporte a distâncias menores entre a implantação de produção e um destino de recuperação de desastre.
  • A soberania de dados é um fator.
  • Fatores geopolíticos estão envolvidos.
  • É uma opção de baixo custo que dá suporte a falhas zonais, às vezes combinadas com a transferência de backup para a região secundária para catástrofes naturais que têm um grande raio de impacto.

Outro fator a ser considerado ao escolher sua região de recuperação de desastre é o RPO e o RTO para fazer failover para o site de recuperação de desastre. Quanto maior a distância entre as regiões de produção e recuperação de desastre, maior a latência de rede. Embora você replique de forma assíncrona entre regiões do Azure, a latência de rede pode afetar a taxa de transferência que você pode replicar e o destino do RPO. Muitas vezes, você pode minimizar seu RPO usando uma arquitetura combinada de alta disponibilidade e recuperação de desastre. Mas essa configuração representa um risco potencialmente maior de desastres naturais em larga escala.

Recomendações de design para recuperação de desastre

  • Verifique se o CIDR (roteamento entre domínios) sem classe para a rede virtual primária não entra em conflito ou se sobrepõe ao CIDR da rede virtual do site de recuperação de desastre.
  • Configure conexões do ExpressRoute do local para as regiões de recuperação de desastre primária e secundária do Azure.
  • Como alternativa ao uso do ExpressRoute, considere configurar conexões VPN do local para as regiões de recuperação de desastre primária e secundária do Azure.
  • Use Site Recovery para replicar um servidor de aplicativos para um site de recuperação de desastre. Site Recovery também pode ajudá-lo a replicar VMs de cluster de serviços centrais para o site de recuperação de desastre. Ao invocar a recuperação de desastre, você precisa reconfigurar o cluster do Linux Pacemaker no site de recuperação de desastre. Por exemplo, você precisa substituir o VIP ou o SBD, executar corosync.conf e assim por diante.
  • Replique o conteúdo do cofre de chaves, como certificados, segredos ou chaves entre regiões, para que você possa descriptografar dados na região de DR.
  • Use a replicação entre regiões em Azure NetApp Files (atualmente em versão prévia pública) para sincronizar volumes de arquivos entre a região primária e a região de recuperação de desastre.
  • Use a replicação de banco de dados nativo, em vez de Site Recovery, para sincronizar dados com o site de recuperação de desastre.
  • Emparelhe as redes virtuais primárias e de recuperação de desastre. Por exemplo, para a Replicação de Sistema do HANA, uma rede virtual do BD SAP HANA precisa ser emparelhada com a rede virtual sap HANA DB do site de recuperação de desastre.
  • Se você usar Azure NetApp Files armazenamento para suas implantações do SAP, no mínimo, crie duas contas Azure NetApp Files na camada Premium, em duas regiões.
  • Considere agrupar sistemas com base em sua importância de negócios e dependência de proximidade com base no desempenho do aplicativo. Implante cada grupo em uma região separada em um constructo de região emparelhada para minimizar o impacto nos negócios de uma interrupção regional. Por exemplo, dois sistemas ECC críticos que atendem a duas unidades de negócios diferentes podem ser implantados no Sul do Reino Unido e no Oeste do Reino Unido para minimizar o impacto de uma interrupção regional.

Próximas etapas

Opções de implantação para SAP no Azure