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

Artigo
08/14/2024

Este artigo baseia-se nas considerações e recomendações na área de design da zona de aterrissagem do Azure para BCDR. Esse artigo descreve restrições exclusivas em zonas de aterrissagem que suportam 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 âmbito

Incorpore princípios em sua arquitetura que abordam cenários locais de continuidade de negócios e recuperação de desastres (BCDR). Esses princípios também se aplicam no 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 máquinas virtuais (VMs) 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 (Recovery Point Objetives, objetivos de ponto de recuperação) para cenários de falha.
Tarefas operacionais e de gerenciamento do ciclo de vida e tecnologia executada durante cenários de falha. Essas tarefas de gerenciamento incluem a aplicação de patches em sistemas operacionais convidados e sistemas de gerenciamento de banco de dados, clonagem e atualização de sistemas SAP.

Gorjeta

Determine uma solução HADR (high availability and disaster recovery) para cada um dos arquétipos em seu cenário SAP logo no início. Certifique-se de que a solução abrange todos os componentes SAP.

Configure uma solução HADR no Azure antecipadamente, em pelo menos um cenário, e mantenha-a ativa. Em seguida, suas equipes podem obter experiência com as tecnologias da solução, que podem diferir das tecnologias existentes. Configure o HADR antecipadamente para ajudar a desenvolver e evoluir seus procedimentos operacionais padrão (POPs).

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

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

Alta disponibilidade em uma região do Azure
Considerações sobre o backup e o restauro
Critérios para decidir entre recuperação de desastres transregional 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 empresarial SAP.

Considerações de design para alta disponibilidade

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

Sistemas de gestão de bases 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 de software. Aplique a 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 ajudam a proteger seus sistemas contra interrupções de serviço não planejadas.

Os bancos de dados SAP e SAP suportam clusters de failover automáticos. No Windows, o recurso de cluster de failover do Windows Server 2022 oferece suporte a failover. No Linux, o Linux Pacemaker ou ferramentas de parceiros como SIOS Protection Suite e Veritas InfoScale suportam 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 suportados para cargas de trabalho SAP em VMs do Azure e Cenários suportados 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 oferece suporte a arquiteturas nas quais as VMs primárias e as VMs secundárias compartilham armazenamento para dados DBMS. O Azure também não suporta logs de transações ou logs de refazer. O princípio orientador é usar duas pilhas de armazenamento independentes, mesmo que elas sejam baseadas em compartilhamentos NFS (Network File System). 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 aplicativos SAP e a camada DBMS. O Azure não oferece suporte a arquiteturas de alta disponibilidade que combinam componentes da camada de aplicativos SAP e a camada DBMS em um cluster de failover.

A maioria dos clusters de failover para componentes da camada de aplicativos SAP e a camada DBMS requer 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 Balanceador de Carga do Azure Padrão em cenários de alta disponibilidade do 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) de nível de 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.

Escalão de serviço	Cenário de alta disponibilidade	SLA da plataforma
1	Availability zone	99,99%
2	Conjunto de disponibilidade	99,95%
3	VM única (autorrecuperação)	99.90%

Conjuntos de disponibilidade do Azure vs. 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 espalhadas por 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 que você implanta no conjunto define o host. Por exemplo, não é possível 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 de rede entre VMs. Para obter mais informações, consulte Configurações de carga de trabalho 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 as opções de design de desempenho e 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 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 em seu cenário SAP para redundância de zona também para que você possa alcançar redundância de zona verdadeira. Exemplos de serviços e componentes a ter em conta incluem gateways do Azure ExpressRoute, Balanceador de Carga, Azure Files, 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 cumprir os SLAs de infraestrutura do seu aplicativo. Você deve escolher a mesma opção para todos os três componentes SAP: serviços centrais, o servidor de aplicativos e o 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 falhas de hardware. Ao implantar VMs por meio de zonas de disponibilidade e usar zonas diferentes, você cria as VMs em diferentes locais físicos. Essa configuração fornece proteção extra contra problemas de energia, resfriamento ou rede que afetam os datacenters da zona 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 de proximidade.

Se você escolher uma abordagem de implantação zonal, o DBMS SAP, os serviços centrais e as camadas de aplicativos 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 de domínios de falha e 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 de proximidade do Azure para latência de rede ideal com 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 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 SAP, o banco de dados e as VMs de aplicativos devem estar em seus próprios conjuntos de disponibilidade.
Ao usar grupos de posicionamento de proximidade do Azure em uma implantação de conjunto de disponibilidade, verifique se todos os três componentes SAP (serviços centrais, o servidor de aplicativos e o banco de dados) estão no mesmo grupo de posicionamento de proximidade.
Se você usar grupos de posicionamento de proximidade, use um para cada identificação de sistema SAP (SID). Os grupos não se estendem por zonas de disponibilidade ou regiões do Azure.
Ao usar grupos de posicionamento de 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 de proximidade. As VMs de banco de dados nas duas zonas não fazem mais parte dos grupos de posicionamento de proximidade. Os grupos de posicionamento de proximidade para cada zona têm escopo com a implantação da VM que executa as instâncias 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 suporta a combinação de ASCS e alta disponibilidade de banco de dados em um único cluster Linux Pacemaker. Separe-os em grupos 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 clusters de banco de dados.
Execute todos os sistemas de produção em SSDs Premium do Azure e use os Arquivos NetApp do Azure ou o Armazenamento em Disco Ultra do Azure. No mínimo, certifique-se de que o disco do sistema operacional esteja 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. Certifique-se de que essas VMs tenham 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 SAP, dependendo do sistema operacional:
- Um cluster do SUSE Linux Enterprise Server Pacemaker suporta um agente de cerca do Azure e até três dispositivos de isolamento de nó.
- Um cluster Red Hat Enterprise Linux Pacemaker dá suporte a um agente de cerca do Azure e não oferece 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 para resiliência em sua carga de trabalho SAP. O design adequado de armazenamento 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 que são 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 oferece 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 de NFS em várias regiões.
NFS em arquivos NetApp do Azure	Cluster baseado em Pacemaker em ambientes Linux. Para obter mais informações, consulte Arquivos NetApp do Azure 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 SAP NetWeaver de alta disponibilidade com o Azure Files SMB.
SMB em arquivos NetApp do Azure	Cluster de failover do Windows Server 2022. Para obter detalhes de configuração, consulte Alta disponibilidade para SAP NetWeaver com arquivos NetApp do Azure (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 de Dispositivo de Bloco Replicado Distribuído), GlusterFS ou um volume compartilhado de cluster com o Storage Spaces Direct 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 oferecem 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 desastres.

Cópia de segurança e restauro

As seções a seguir descrevem considerações de projeto 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 de alta disponibilidade adequada 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 as regulamentações de conformidade que exigem armazenamento de longo prazo de backups. Em outros cenários, você também precisa ter um backup a partir do qual possa restaurar. Esta orientação pressupõe 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 point-in-time 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 point-in-time normalmente fornece proteção contra erros do operador, como a exclusão de dados, seja na camada DBMS ou através do SAP.
Mantenha uma loja para manter seus backups de longo prazo, a fim de atender às normas de conformidade.
Use backups de banco de dados para clonar o sistema SAP e restaurar os backups em outro servidor ou VM.
Use dados de banco de dados de produção de backups de banco de dados para atualizar sistemas que não sejam de 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 snapshots de instâncias de banco de dados SAP HANA.

Se você fizer backup e restaurar localmente, precisará trazer esses recursos para sistemas SAP no Azure. Se você gosta de sua solução atual, verifique se seu fornecedor de backup dá suporte a implantações do Azure ou se ele tem uma solução de software como serviço (SaaS) 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 HANA.

Você também pode usar o Backup do Azure para fazer backup de bancos de dados que têm a replicação do sistema SAP HANA (HSR) 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 HANA ou nós de configuração HSR como um único contêiner HSR.
O benefício do backup instantâneo e da restauração instantânea.
Uma abordagem baseada em snapshot consistente com HANA que se integra ao Backint for SAP HANA. Você pode usar o Backup como um único produto para todo o cenário HANA e para qualquer tamanho de banco de dados.

Para obter mais informações, consulte Sistema de banco de dados SAP HANA com replicação habilitada e Backup de snapshot de instância 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 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 da vida 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.
Idealmente, evite extrair seus backups do Azure para sua infraestrutura de backup local, especialmente para bancos de dados grandes. Essa abordagem pode afetar a largura de banda usada pelos circuitos da Rota Expressa.
Teste de carga das ferramentas de backup e recuperação como parte do plano de teste de desempenho.

Recuperação após desastre

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

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

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 ofereçam VMs da série M do Azure ou VMs da série Mv2. O Armazenamento do 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 do emparelhamento de regiões do Azure para cargas de trabalho SAP são:

Os pares nem sempre são consistentes com os serviços de VM da série M ou da série 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 o SQL Server Always On ou a replicação do sistema SAP HANA. Use uma combinação de Site Recovery, ferramentas como rsync ou e robocopyoutros softwares que não sejam da Microsoft para a camada de aplicativos 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 desastres emparelhada correspondente. Essa situação leva à competição de recursos para criar VMs inativas na região de recuperação de desastres. A solução alternativa é executar sistemas que não sejam de 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 das infraestruturas do Azure na região de recuperação de desastres 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 um período de tempo mínimo com capacidade mínima de TI e por recursos humanos críticos apenas enquanto trabalha para recuperar a operação normal na região principal. 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 primária?
Você implantará sistemas SAP não produtivos na região de recuperação de desastres?
Você usará uma arquitetura que agrupe todos os sistemas SAP na região primária? Essa configuração garante que a região de recuperação de desastres seja usada apenas para recuperação de desastres.

A maioria das organizações usa ambas as regiões para sistemas operacionais SAP. 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 desastres.

Ao escolher uma região de recuperação de desastres, certifique-se de ter conectividade da Rota Expressa com essa região. Se você tiver vários circuitos de Rota Expressa se conectando ao Azure, pelo menos um desses circuitos deverá se conectar à região principal do Azure. Os outros devem se conectar à região de recuperação de desastres. Este tipo de arquitetura liga-o à rede do Azure numa área geográfica ou geopolítica diferente e ajuda a proteger a sua ligação se uma catástrofe afetar uma das regiões do Azure.

Algumas organizações usam uma combinação de alta disponibilidade e arquitetura de recuperação de desastres, que agrupa alta disponibilidade com recuperação de desastres na mesma região do Azure. Mas agrupar alta disponibilidade com recuperação de desastres não é o ideal. As zonas de disponibilidade do Azure dão suporte a essa arquitetura. A distância entre 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, portanto, um desastre natural pode comprometer os serviços de aplicativo na região onde 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 sejam sempre executados na mesma zona. As organizações escolhem essa arquitetura pelos seguintes motivos:

A conformidade é suficiente com configurações que suportam distâncias menores entre a implantação de produção e uma meta de recuperação de desastres.
A soberania de dados é um fator.
Estão envolvidos fatores geopolíticos.
É uma opção de baixo custo que suporta falhas zonais, às vezes combinadas com a 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 desastres é o RPO e o RTO para failover no local de recuperação de desastres. Quanto maior a distância entre a região de produção e as regiões de recuperação de desastres, maior a latência da rede. Você replica de forma assíncrona entre regiões do Azure, mas a latência da rede pode afetar a taxa de transferência que você pode replicar e o destino 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 desastres

Certifique-se de que o CIDR (roteamento entre domínios sem classe) para a rede virtual primária não entre em conflito ou se sobreponha ao CIDR da rede virtual do site de recuperação de desastres.
Configure conexões de Rota Expressa do local para as regiões de recuperação de desastres do Azure primária e secundária.
Considere configurar conexões VPN do local para as regiões de recuperação de desastres do Azure primária e secundária. Use esse método como uma alternativa ao uso da Rota Expressa.
Use a Recuperação de Site para replicar um servidor de aplicativos para um site de recuperação de desastres. A Recuperação de Site também pode ajudá-lo a replicar VMs de cluster de serviços centrais para o local de recuperação de desastres. Ao invocar a recuperação de desastres, você precisa reconfigurar o cluster 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 desastres.
Use a replicação entre regiões nos Arquivos NetApp do Azure para sincronizar volumes de arquivos entre a região primária e a região de recuperação de desastres.
Use a replicação nativa de banco de dados, em vez de Site Recovery, para sincronizar dados com o site de recuperação de desastres.
Emparelhe as redes virtuais primárias e de recuperação de desastres. Por exemplo, para replicação do sistema HANA, você precisa emparelhar uma rede virtual SAP HANA DB precisa para a rede virtual SAP HANA DB do local 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 comercial 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 do ERP que atendem a duas unidades de negócios diferentes, no Sul e no Oeste do Reino Unido.

Próximo passo

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

Partilhar via