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 é abstrata, e você deve projetar sua estratégia de DR com base em sua configuração específica, documentando 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. No entanto, se você configurou o dispatcher da Web SAP usando a opção 1 na região primária, será necessário fazer algumas alterações adicionais após o failover para ter uma configuração HA semelhante na região de 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. Verifique a seção abaixo para obter mais informações com base no sistema operacional usado para serviços centrais 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 desastre após o failover, considere pontos adicionais como reconfiguração de cluster, disponibilidade de diretórios compartilhados SAP, além de replicar VMs e o disco gerenciado anexado ao site de DR usando 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.
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.
- Cluster de HA do SAP ASCS/ERS com failover de dispositivo SBD (usando o servidor de destino iSCSI) para a região de DR usando o Azure Site Recovery.
- Failover do Cluster de HA do SAP ASCS (no sistema operacional Linux) para a região de DR usando o Azure Site Recovery.
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 verificar se os dados foram replicados e estão 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 abaixo mostra a lista de bancos de dados usados 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 desastre para as cargas de trabalho SAP, se o RTO e o RPO dos negócios não forem críticos. Você pode usar o backup do Azure, um serviço de backup baseado em nuvem, para tirar cópias de diferentes componentes da 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.