Compartilhar via


Diretrizes de recuperação de desastre para aplicativo SAP

Para configurar a DR (Recuperação de Desastre) para carga de trabalho SAP no Azure, você precisa testar, ajustar e atualizar o processo regularmente. Testar a recuperação de desastres ajuda a identificar a sequência de serviços dependentes necessários para disparar o failover de DR da carga de trabalho do SAP ou iniciar o sistema no site secundário. Geralmente, os sistemas SAP das organizações são conectados aos serviços do AD (Active Directory) e do DNS (Sistema de Nomes de Domínio) para funcionar corretamente. Ao configurar a DR para a carga de trabalho do SAP, verifique se os serviços do AD e de DNS estão funcionando antes de recuperar o SAP e outros sistemas diferentes dele, a fim de garantir que o aplicativo funcione corretamente. Para obter diretrizes sobre como proteger o Active Directory e o DNS, veja como proteger o Active Directory e o DNS. A recomendação de DR para o aplicativo SAP descrita neste documento está em um nível abstrato. Você precisa projetar sua estratégia de DR com base em sua configuração específica e documentar o cenário de ponta a ponta.

Recomendação de DR para cargas de trabalho SAP

Geralmente em sistemas SAP NetWeaver distribuídos, os serviços centrais, bancos de dados e armazenamentos compartilhados (NFS/SMB) são o SPOF (ponto único de falha). Para atenuar o efeito de diferentes SPOFs, é necessário configurar a redundância desses componentes. A redundância desses componentes SPOF na região primária é obtida configurando a alta disponibilidade. A configuração de alta disponibilidade do componente protege o sistema SAP contra falhas ou catástrofes locais. Mas, para proteger os aplicativos SAP contra desastres geográficos dispersos, a estratégia de DR deve ser implementada para todos os componentes SAP.

Para sistemas SAP em execução nas máquinas virtuais, você pode usar o Azure Site Recovery para criar um plano de recuperação de desastre. Veja a seguir a abordagem de recuperação de desastre recomendada para cada componente de um sistema SAP. Mecanismos autônomos não NetWeaver SAP, como TREX e aplicativos não SAP, não são abordados neste documento.

Componentes Recomendação
SAP Web Dispatcher Replicar VM usando o Azure Site Recovery
SAP Central Services Replicar VM usando o Azure Site Recovery
Servidor de Aplicativo SAP Replicar VM usando o Azure Site Recovery
Banco de Dados SAP Usar método de replicação oferecido pelo banco de dados
Armazenamento compartilhado Replicar conteúdo usando o método apropriado por tipo de armazenamento

SAP Web Dispatcher

O componente SAP Web Dispatcher funciona como balanceador de carga para tráfego SAP entre os servidores de aplicativo SAP. Você tem opções diferentes para obter a alta disponibilidade do componente SAP Web Dispatcher na região primária. Para obter mais informações sobre essa opção, confira Alta disponibilidade do SAP Web Dispatcher e Configuração de HA do SAP Web Dispatcher no Azure.

  • Opção 1: alta disponibilidade usando a solução de cluster.
  • Opção 2: alta disponibilidade com distribuidores da Web de SAP paralelos.

Para realizar a DR para configuração do SAP Web Dispatcher com alta disponibilidade na região primária, você pode usar o Azure Site Recovery. Para dispatchers da Web paralelos (opção 2) em execução na região primária, é possível configurar o Azure Site Recovery para realizar a DR. Mas para o SAP Web Dispatcher configurado usando a opção 1 na região primária, você precisa fazer algumas alterações adicionais após o failover para ter uma configuração de HA semelhante na região da DR. Como a configuração da alta disponibilidade do SAP Web Dispatcher com a solução de cluster é configurada de maneira semelhante aos serviços centrais SAP. Siga as mesmas diretrizes mencionadas para serviços centrais SAP.

SAP Central Services

Os serviços centrais SAP contêm enfileiramento e servidor de mensagens, que é um dos SPOF do aplicativo SAP. Em um sistema SAP, pode haver apenas uma dessas instâncias e ela pode ser configurada para alta disponibilidade. Leia Alta Disponibilidade para serviços centrais SAP para entender a solução de alta disponibilidade diferente para carga de trabalho SAP no Azure.

A configuração de alta disponibilidade para serviços centrais SAP protege os recursos e processos contra incidentes locais. Para realizar a DR para serviços centrais SAP, você pode usar o Azure Site Recovery. O Azure Site Recovery replica as VMs e os discos gerenciados anexados, mas há considerações adicionais para a estratégia de DR. Consulte a seção a seguir para obter mais informações, com base no sistema operacional utilizado para os serviços centrais do SAP.

Para sistema SAP, a redundância do componente SPOF na região primária é obtida configurando a alta disponibilidade. Para obter uma configuração de alta disponibilidade semelhante na região de recuperação de desastres após um failover, você precisa considerar outros pontos. Isso inclui reconfigurar o cluster, garantir que os diretórios compartilhados do SAP estejam disponíveis e replicar VMs e seus discos gerenciados para o site de DR com o Azure Site Recovery. No Linux, a alta disponibilidade do aplicativo SAP pode ser obtida usando a solução de cluster do Pacemaker. O diagrama a seguir mostra os diferentes componentes envolvidos na configuração de alta disponibilidade para serviços centrais SAP com o Pacemaker. Cada componente deve ser levado em consideração para obter uma alta disponibilidade semelhante à configurada no site de DR. Se você tiver configurado o SAP Web Dispatcher usando a solução de cluster do Pacemaker, considerações semelhantes também se aplicarão.

Arquitetura Linux do sistema SAP

Balanceador de carga interno

O Azure Site Recovery replica VMs para o site de DR, mas não replica o balanceador de carga do Azure. Você precisará criar um balanceador de carga interno separado no site de DR com antecedência ou após o failover. Se você criar um balanceador de carga interno com antecedência, crie um pool de back-end vazio e adicione VMs após o evento de failover.

Solução de cluster do Pacemaker

As configurações de um cluster do Pacemaker residem em arquivos locais de VMs, que são replicados para o site de DR com o Azure Site Recovery. A configuração de cluster do Pacemaker como está não funcionará imediatamente nas VMs após o failover. É necessária uma reconfiguração de cluster adicional para que a solução funcione.

Leia estes blogs para saber mais sobre a reconfiguração de cluster do Pacemaker na região de DR, com base no tipo do mecanismo de armazenamento e isolamento.

Diretórios compartilhados SAP para Linux

A configuração de alta disponibilidade do SAP NetWeaver ou da plataforma ABAP usa o servidor de replicação de enfileiramento para obter redundância no nível do aplicativo para o serviço de enfileiramento do sistema SAP com a configuração de cluster do Pacemaker. A configuração de alta disponibilidade dos serviços centrais SAP (ASCS e ERS) usa montagens NFS. Portanto, você precisa garantir que os binários e dados SAP nessas montagens NFS sejam replicados para o site de DR. O Azure Site Recovery replica as VMs e o disco gerenciado local anexado, mas não replica as montagens NFS. Com base no tipo de armazenamento NFS configurado para a instalação, você precisa garantir que os dados sejam replicados e estejam disponíveis no site de DR. A metodologia de replicação entre regiões para cada armazenamento é apresentada em nível abstrato. Você precisa confirmar as etapas exatas para replicar o armazenamento e executar os testes.

Diretórios compartilhados SAP Replicação entre regiões
NFS no Arquivos do Azure Personalizado (como rsync)
NFS no ANF Sim (Replicação entre Regiões)
Cluster NFS Personalizado

Dica

É recomendável implantar um dos serviços primários de NFS do Azure: NFS nos Arquivos do Azure ou Volumes do ANF no NFS para armazenar dados compartilhados em um sistema SAP altamente disponível. Lembre-se de que estamos deixando de enfatizar as arquiteturas de referência do SAP, utilizando clusters de NFS.

Mecanismo de Isolamento

Independentemente do sistema operacional (SLES ou RHEL) e sua versão, o Pacemaker requer um mecanismo de isolamento válido para que toda a solução funcione corretamente. Com base no tipo de mecanismo de isolamento que você configurou na região primária, você precisa verificar se o mesmo mecanismo de isolamento está configurado no site de DR após o failover.

Mecanismo de Isolamento Recomendação de DR entre regiões
SBD usando o servidor de destino iSCSI Replique o servidor de destino iSCSI usando o Azure Site Recovery.
Nas VMs de DR, descubra o disco iSCSI novamente.
Agente de isolamento do Azure Habilite o MSI (Identidades Gerenciadas do Sistema) nas VMs de DR.
Atribua as funções personalizadas.
Atualize o recurso do agente de isolamento no cluster.
SBD usando o disco compartilhado do Azure* Configure o novo Disco Compartilhado do Azure na região de DR. Anexe o Disco Compartilhado do Azure às VMs de DR após o failover.
Configure o dispositivo SBD do disco compartilhado do Azure.

*O ZRS para disco compartilhado do Azure está disponível em regiões limitadas.

Observação

É recomendável ter o mesmo mecanismo de isolamento para a região primária e para a região de DR para facilitar a operação e o failover. Não é recomendável ter um mecanismo de isolamento diferente após o failover para o site de DR.

Servidores de Aplicativo SAP

Na região primária, a redundância dos servidores de aplicativo SAP é obtida pela instalação das instâncias em várias VMs. Para ter DR para servidores de aplicativo SAP, o Azure Site Recovery pode ser configurado para cada VM do servidor de aplicativo. Para os armazenamentos compartilhados (sistema de arquivos de transporte, sistema de arquivos de interface) anexados aos servidores de aplicativos, siga a prática de DR apropriada com base no tipo de armazenamento compartilhado.

Servidores de Banco de Dados SAP

Para bancos de dados que executam a carga de trabalho SAP, use a tecnologia de replicação de DBMS nativa para configurar a DR. 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. A tecnologia de replicação para cada banco de dados é diferente. Portanto, siga as respectivas diretrizes de banco de dados. A tabela a seguir mostra a lista de bancos de dados utilizados para cargas de trabalho SAP e a recomendação de DR correspondente.

Banco de dados Recomendação de DR
SAP HANA HSR (Replicação do Sistema HANA)
Oracle Oracle Data Guard (FarSync)
IBM DB2 HADR (Alta Disponibilidade e Recuperação de Desastre)
Microsoft SQL Microsoft SQL Always On
SAP ASE ASE HADR Always On
SAP MaxDB Banco de dados em espera

Para solução otimizada para custo, você pode até mesmo usar a opção de backup e restauração para estratégia de DR do banco de dados.

Fazer backup e restaurar

O backup e a restauração são outras soluções que você pode usar para obter a recuperação de desastres para suas cargas de trabalho SAP se o RTO e o RPO da empresa não forem críticos. Você pode usar o Backup do Azure, um serviço de backup baseado em nuvem para fazer cópias de diferentes componentes da sua carga de trabalho SAP, como máquinas virtuais, discos gerenciados e bancos de dados com suporte. Para saber mais sobre as configurações gerais de suporte e as limitações para cenários e implantações de Backup do Azure, confira Matriz de suporte do Backup do Azure.

Serviços Componente Suporte de Backup do Azure
Computação VMs do Azure Com suporte
Armazenamento Azure Managed Disks, incluindo discos compartilhados Com suporte
Armazenamento Compartilhamento de Arquivos do Azure – SMB (Standard ou Premium) Com suporte
Armazenamento Blobs do Azure Com suporte
Armazenamento Arquivo Compartilhado do Azure – NFS (Standard ou Premium) Sem suporte
Armazenamento Azure NetApp Files Sem suporte
Banco de dados Banco de dados SAP HANA nas VMs do Azure Com suporte
Banco de dados SQL Server nas VMs do Azure Com suporte
Banco de dados Oracle Com suporte*
Banco de dados IBM DB2, SAP ASE Sem suporte

Observação

*O backup do Azure dá suporte ao banco de dados Oracle usando o backup de VM do Azure para instantâneos consistentes do banco de dados.

O backup do Azure não dá suporte a todos os armazenamentos e bancos de dados do Azure usados para carga de trabalho SAP.

O backup do Azure armazena backups no cofre do serviço de recuperação, que replica os dados com base no tipo de replicação escolhido (LRS, ZRS ou GRS). Para GRS (armazenamento com redundância geográfica), os dados de backup são replicados para uma região secundária emparelhada. Com o recurso de restauração entre regiões habilitado, você pode restaurar dados do tipo de gerenciamento com suporte na região secundária.

O backup e a restauração são uma abordagem mais tradicional com otimização de custo, mas vem com uma compensação de RTO maior. Como você precisa restaurar todos os aplicativos do backup, se houver failover para a região de recuperação de desastre. Portanto, você precisa analisar a necessidade de negócios e criar adequadamente uma estratégia de DR.

Referências