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

Este artigo se baseia nas considerações e recomendações na área de design da zona de destino do Azure para BCDR. Esse artigo descreve restrições exclusivas em zonas de destino que oferecem suporte a uma plataforma SAP. O SAP é uma plataforma de missão crítica, portanto, você também deve incorporar outras orientações de missão crítica em seu projeto.

Cenário e escopo

Incorpore princípios em sua arquitetura que abordem cenários locais de continuidade dos negócios e recuperação de desastre (BCDR). Esses princípios também se aplicam ao Azure. Mas o Azure pode ter mais capacidade de hardware do que seu ambiente local para compensar uma falha de host. Para recuperar automaticamente até mesmo as maiores VMs (máquinas virtuais) do Azure, você pode configurá-las para reiniciar em outro servidor. Configure suas implantações do Azure para usar as mesmas condições que suas implantações locais. Se você usar configurações de cluster de failover automático para implantar sistemas locais ou hardware bare-metal, implante-os da mesma maneira no Azure. Os aplicativos SAP que executam os processos de negócios mais críticos da sua organização exigem:

• Disponibilidade de serviços e processos de negócios.

• Objetivos de tempo de recuperação (RTOs) para cenários de falha ou cenários de desastre.

• RPOs (objetivos de ponto de recuperação) para cenários de falha.

• Tarefas de gerenciamento operacional e de ciclo de vida e tecnologia que é executada 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.

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 de backup e restauração

• Critérios para decidir entre recuperação de desastres inter-regional e regional

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 corporativo SAP.

Considerações de design para alta disponibilidade

Quando você implementa a alta disponibilidade, o objetivo é fornecer disponibilidade para o único ponto de falha do software SAP, como:

• Sistemas de gerenciamento de banco de dados.

• Pontos únicos de falha em um aplicativo, como SAP Advanced Business Application Programming (ABAP), ABAP SAP Central Services (ASCS) e SAP Central Services (SCS). Exemplos de alta disponibilidade 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 falhas de software. Aplique disponibilidade a todas as tarefas necessárias de gerenciamento do ciclo de vida. Por exemplo, você pode corrigir o sistema operacional nas VMs, no sistema de gerenciamento de banco de dados (DBMS) e no software SAP. Para minimizar as interrupções que podem ocorrer durante o tempo de inatividade planejado e as operações de gerenciamento do ciclo de vida, use ferramentas comuns que ajudem 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 recurso de clustering de failover do Windows Server 2022 dá suporte ao failover. No Linux, o Linux Pacemaker ou ferramentas de parceiros, como o SIOS Protection Suite e o Veritas InfoScale, oferecem suporte ao failover. No Azure, você pode implantar apenas uma configuração de alta disponibilidade de subconjunto em seu próprio datacenter.

Para obter mais informações, consulte Cenários com suporte para cargas de trabalho do SAP em VMs do Azure e Cenários com suporte para SAP HANA em Instâncias Grandes.

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 armazenamento para dados do DBMS. O Azure também não dá suporte a logs de transações ou logs de restauração. O princípio orientador é usar duas pilhas de armazenamento independentes, mesmo que sejam baseadas em compartilhamentos NFS (Sistema de Arquivos de Rede). Essas limitações são exclusivas para soluções do Azure e não para soluções locais.

O Azure fornece outras opções porque dá suporte ao compartilhamento de NFS e Bloco de Mensagens do Servidor. Você pode usar discos compartilhados do Azure no Windows para componentes ASCS e SCS e cenários específicos de alta disponibilidade. Configure seus clusters de failover separadamente para os componentes da camada de aplicativo SAP e a camada do DBMS. 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 exigem um endereço IP virtual para um cluster de failover. Uma exceção comum é quando você usa o Oracle Data Guard, que 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. Você pode usar um balanceador de carga para cada 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 VMs usando o Standard Azure Load Balancer em cenários de alta disponibilidade SAP.

Para obter mais informações, consulte arquitetura de alta disponibilidade e cenários para SAP NetWeaver.

A tabela a seguir mostra os SLAs (contratos de nível de serviço) no nível da plataforma para várias opções de implantação de alta disponibilidade. Os parceiros que fornecem os serviços gerenciados também fornecem o SLA no nível do aplicativo.

Conjuntos de disponibilidade do Azure versus zonas de disponibilidade

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

• As VMs não estã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 a primeira VM implantada no conjunto define o host. Por exemplo, você não pode combinar VMs da série M e VMs da série E em um conjunto de disponibilidade.

Ao implantar sua arquitetura de alta disponibilidade em diferentes zonas de disponibilidade, você pode ter um SLA mais alto para as VMs. Para obter mais informações, 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, consulte Configurações de carga de trabalho do SAP com zonas de disponibilidade do Azure.

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

Se você usar uma implantação zonal ativa/passiva para a camada do servidor de aplicativos na qual os servidores de aplicativos devem se conectar ao banco de dados na mesma zona de disponibilidade, configure a automação e crie um SOP para permitir a recuperação rápida e automatizada se ocorrer um failover do 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 em seu cenário 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 serem considerados incluem gateways do Azure ExpressRoute, Load Balancer, Arquivos do Azure, Azure NetApp Files, proxies reversos, firewalls, serviços 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 seu 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 mais informações sobre SLAs para VMs, conjuntos de disponibilidade e zonas de disponibilidade, consulte SLAs para serviços online.

• Quando você implanta VMs em um conjunto de disponibilidade, o alinhamento com domínios de falha e atualização impede que as VMs estejam no mesmo hardware de host, o que fornece proteção contra falha de hardware. Ao implantar VMs por meio de zonas de disponibilidade e usar zonas diferentes, você cria as VMs em locais físicos diferentes. Essa configuração fornece proteção extra contra problemas de energia, resfriamento ou rede que afetam os datacenters da região como um todo. Mas 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 SAP, os serviços centrais e as camadas de aplicativo serão executados em diferentes zonas de disponibilidade. Mas cada zona de disponibilidade provavelmente tem vários servidores de aplicativos. Nesse cenário, os servidores de aplicativos em cada zona não se beneficiam automaticamente dos domínios de falha e dos domínios de atualização. Você pode usar conjuntos de disponibilidade para obter esses benefícios. Para obter mais informações, consulte 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 atualize os domínios 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 use 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 posteriormente.

• 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 aplicativos devem estar em seus próprios conjuntos de disponibilidade.

• Ao usar grupos de posicionamento por proximidade do Azure em uma implantação de conjunto de disponibilidade, verifique se todos os três componentes SAP (serviços centrais, servidor de aplicativos e banco de dados) estão no mesmo grupo de posicionamento por proximidade.

• Se você usar grupos de posicionamento por proximidade, use um para cada SID (Identificação do sistema) SAP. Os grupos não abrangem zonas de disponibilidade ou regiões do Azure.

• Ao usar grupos de posicionamento por proximidade do Azure em uma implantação de zonas de disponibilidade, verifique se os dois componentes SAP (serviços centrais e servidor de aplicativos) estão 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 proximidade para cada zona têm como escopo a implantação da VM que executa as instâncias do SAP ASCS e SCS. A vantagem dessa configuração é que você tem mais flexibilidade para redimensionar VMs. Você também pode alternar facilmente para novos tipos de VM na camada DBMS ou na camada de aplicativo do sistema SAP.

• O Azure não dá suporte à combinação de ASCS e alta disponibilidade de 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 o Standard Load Balancer na frente do ASCS e dos clusters de banco de dados.

• Execute todos os sistemas de produção em SSDs Premium do Azure e use o Azure NetApp Files ou o Armazenamento em Disco Ultra do Azure. No mínimo, verifique se o disco do sistema operacional está na camada Premium para que você possa melhorar o desempenho e obter o melhor SLA.

• Implante ambas as VMs no par de alta disponibilidade em um conjunto de disponibilidade ou em zonas de disponibilidade. Verifique se essas VMs têm o mesmo tamanho e a mesma configuração de armazenamento.

• Use a tecnologia de replicação de banco de dados nativa 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:

  • Um cluster do SUSE Linux Enterprise Server Pacemaker dá suporte a um agente de isolamento do Azure e até três dispositivos de isolamento de nó.

  • Um cluster do Red Hat Enterprise Linux Pacemaker dá suporte a um agente de limite do Azure e não dá suporte a dispositivos de isolamento de nó.

  • Um cluster do Windows.

  • Software de cluster não Microsoft certificado pela SAP.

• 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

• Escolha as opções de armazenamento certas ao projetar resiliência em sua carga de trabalho SAP. O design de armazenamento adequado do Azure para cargas de trabalho SAP pode minimizar a latência 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 mais informações, consulte Tipos de armazenamento do Azure para cargas de trabalho SAP.

• Você deve executar o SAP HANA no Azure somente em tipos de armazenamento certificados pela SAP. Você deve executar determinados volumes em determinadas configurações de disco. Por exemplo, as configurações podem habilitar o Acelerador de Gravação ou usar o armazenamento SSD Premium. Você também precisa garantir que o sistema de arquivos executado no armazenamento seja compatível com o DBMS executado na máquina. 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 executam aplicativos SAP no Azure. Sua configuração de alta disponibilidade pode ser diferente porque o Azure Site Recovery não dá suporte a alguns serviços de armazenamento disponíveis no Azure. Use os seguintes tipos de armazenamento para cargas de trabalho SAP.

  Tipo de armazenamento	Suporte à configuração de alta disponibilidade
  Discos compartilhados do Azure (LRS (armazenamento com redundância local) ou ZRS (armazenamento com redundância de zona))	Cluster de failover do Windows Server 2022. Para obter detalhes de configuração, consulte Projetar alta disponibilidade do SAP com clustering de failover do Windows Server 2022.
  NFS em Arquivos do Azure (LRS ou ZRS)	Cluster baseado em Pacemaker em ambientes Linux. Certifique-se de verificar a disponibilidade do NFS em várias regiões.
  NFS no Azure NetApp Files	Cluster baseado em Pacemaker em ambientes Linux. Para obter mais informações, consulte Azure NetApp Files para VMs SAP.
  SMB em Arquivos do Azure (LRS ou ZRS)	Cluster de failover do Windows Server 2022. Para obter detalhes de configuração, consulte Instalar o SAP NetWeaver de alta disponibilidade com o SMB dos Arquivos do Azure.
  SMB no Azure NetApp Files	Cluster de failover do Windows Server 2022. Para obter detalhes de configuração, consulte Alta disponibilidade para SAP NetWeaver 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 do Dispositivo de Blocos Replicados Distribuídos), GlusterFS ou um volume compartilhado de cluster com Espaços de Armazenamento Diretos como uma solução alternativa de armazenamento compartilhado 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 mais informações sobre a disponibilidade do serviço de armazenamento, consulte Produtos do Azure por região.

• Para obter informações sobre as opções de armazenamento disponíveis para cargas de trabalho SAP no Azure, consulte 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 de design e recomendações 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 armazenamento de backups de longo prazo. Em outros cenários, você também precisa ter um backup do qual possa restaurar. Essas diretrizes pressupõem que você já estabeleceu backup e restauração e segue as práticas recomendadas 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 de tempo que atenda ao seu RTO. A recuperação pontual normalmente fornece proteção contra erros do operador, como exclusão de dados, na camada DBMS ou por meio do SAP.

• Mantenha um armazenamento 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.

• Faça backup de um sistema SAP HANA com replicação habilitada.

• Faça backup de instantâneos de instância de banco de dados do SAP HANA.

Se você fizer backup e restaurar localmente, precisará trazer esses recursos para sistemas SAP no Azure. Se você gostar da solução atual, verifique se o fornecedor de backup dá suporte a implantações do Azure ou se ele tem uma solução SaaS (software como serviço) para o Azure.

O Azure fornece um serviço SaaS de backup chamado Backup do Azure, que tira instantâneos de VM e gerencia backups de streaming do SQL Server e do SAP HANA . Se você usar o 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.

Você também pode usar o Backup do Azure para fazer backup de bancos de dados que têm a HSR (replicação do sistema) do SAP HANA habilitada. O Backup do Azure gerencia automaticamente os backups quando ocorre um failover e elimina a necessidade de intervenção manual. O backup também fornece:

• Proteção imediata sem backups completos corretivos, para que você possa proteger instâncias do HANA ou nós de configuração do HSR como um único contêiner do HSR.

• O benefício do backup instantâneo e da restauração instantânea.

• Uma abordagem baseada em instantâneo consistente com o HANA que se integra ao Backint para SAP HANA. Você pode usar o Backup como um único produto para todo o cenário do HANA e para qualquer tamanho de banco de dados.

Para obter mais informações, consulte Sistema de banco de dados do SAP HANA com replicação habilitada e Backup de instantâneo de instância do SAP HANA.

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

• Você pode usar o Backup do Azure para fazer backup do servidor de aplicativos SAP e das 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 Matriz de suporte para backup de bancos de dados SAP HANA em VMs do Azure.

• Se você usar uma solução de backup de infraestrutura como serviço, 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 real, dentro dos prazos esperados. Use uma configuração de produção ou uma configuração semelhante para áreas como rede e segurança.

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

• O ideal é evitar extrair seus backups do Azure para sua infraestrutura de backup local, especialmente para bancos de dados grandes. Essa abordagem pode afetar a quantidade de largura de banda que os circuitos do ExpressRoute usam.

• Teste a 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ão do Azure inclui mais de 65 regiões do Azure e nem todas 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 do Azure ou VMs da série Mv2. 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 sua 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, ferramentas como rsync ou robocopye outros softwares que não sejam da Microsoft para a camada de aplicativo SAP.

• Se ocorrer um desastre, vários clientes afetados em uma região do Azure farão failover para a região de recuperação de desastre emparelhada correspondente. Essa situação leva à competição de recursos para ativar VMs inativas na região de recuperação de desastres. A solução alternativa é executar sistemas de não produção na região de recuperação de desastres e usar os mesmos recursos para hospedar réplicas de recuperação de desastres de sistemas de produção. Esse uso de dupla finalidade de infraestruturas do Azure na região de recuperação de desastre ajuda a evitar restrições de capacidade de recursos.

Outra consideração importante é garantir a capacidade operacional necessária na região do desastre. Se ocorrer um desastre, talvez seja necessário executar o aplicativo SAP por uma janela mínima de tempo com capacidade mínima de TI e por recursos humanos críticos somente enquanto você trabalha para recuperar a operação normal na região primária. Essa estratégia requer que você tenha uma infraestrutura de TI mínima disponível na região de recuperação de desastres.

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

• Você implantará sistemas de produção em sua região principal?

• Você implantará sistemas SAP de não produção na região de recuperação de desastres?

• 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 operar sistemas SAP. As organizações que executam cópias completas de sistemas de produção como sistemas de teste de regressão de negócios geralmente planejam usar o sistema de teste de regressão de negócios da linha de produtos SAP como um destino de recuperação de desastres.

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 desastres. Esse tipo de arquitetura conecta você à rede do Azure em uma área geográfica ou 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 combinação de arquitetura de alta disponibilidade e recuperação de desastre, 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. A distância entre zonas de disponibilidade em uma região do Azure não é tão grande quanto a distância entre duas regiões do Azure, portanto, um desastre natural pode comprometer os serviços de aplicativo na região em que ele ocorre. Você também precisa considerar a latência entre os servidores de aplicativos SAP e os servidores de banco de dados. De acordo com a nota 1100926 da SAP, 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 altas latências, tenha procedimentos operacionais para garantir que os servidores de aplicativos SAP e os servidores de banco de dados sempre sejam executados na mesma zona. 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 suporta falhas zonais, às vezes combinadas com transferência de backup para a região secundária para catástrofes naturais que afetam um grande raio.

Outro fator a ser considerado ao escolher sua região de recuperação de desastre é o RPO e o RTO para failover para o site de recuperação de desastre. Quanto maior a distância entre a região de produção e as regiões de recuperação de desastre, maior a latência da rede. Você replica de forma assíncrona entre regiões do Azure, mas a latência de rede pode afetar a taxa de transferência que você pode replicar e o destino de RPO. Para minimizar seu RPO, você pode usar uma arquitetura combinada de alta disponibilidade e recuperação de desastres. Mas essa configuração representa um risco potencialmente maior de desastres naturais em grande 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árias e secundárias do Azure.

• Considere configurar conexões VPN do local para as regiões de recuperação de desastre primárias e secundárias do Azure. Use esse método como uma alternativa ao uso do ExpressRoute.

• Use o Site Recovery para replicar um servidor de aplicativos para um site de recuperação de desastre. O 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 desastres, você precisa reconfigurar o cluster do Linux Pacemaker no site de recuperação de desastres. Por exemplo, talvez seja necessário substituir o endereço IP virtual ou SBD ou executar corosync.conf.

• 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 recuperação de desastre.

• Use a replicação entre regiões no Azure NetApp Files 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 nativa, em vez do 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 do sistema HANA, você precisa emparelhar uma rede virtual do Banco de Dados do SAP HANA com a rede virtual do Banco de Dados do SAP HANA do site de recuperação de desastres.

• Se você usar o armazenamento do Azure NetApp Files para suas implantações SAP, no mínimo, crie duas contas do 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. Para minimizar o efeito comercial de uma interrupção regional, implante cada grupo em uma região separada em uma construção de região emparelhada. Por exemplo, para minimizar o efeito de uma interrupção regional, você pode implantar dois sistemas críticos de componentes centrais de ERP que atendem a duas unidades de negócios diferentes, no Sul do Reino Unido e no Oeste do Reino Unido.

Próxima etapa

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