Diretrizes de recuperação de desastres para aplicativos SAP
Para configurar a recuperação de desastres (DR) para a carga de trabalho do SAP no Azure, você precisa testar, ajustar e atualizar o processo regularmente. O teste de recuperação de desastres ajuda a identificar a sequência de serviços dependentes necessários antes que você possa acionar o failover de DR da carga de trabalho SAP ou iniciar o sistema no local secundário. As organizações geralmente têm seus sistemas SAP conectados aos serviços Ative Directory (AD) e DNS (Sistema de Nomes de Domínio) para funcionar corretamente. Ao configurar o DR para sua carga de trabalho SAP, verifique se os serviços AD e DNS estão funcionando antes de recuperar o SAP e outros sistemas não SAP, para garantir que o aplicativo funcione corretamente. Para obter orientações sobre como proteger o Ative Directory e o DNS, saiba como proteger o Ative Directory e o DNS. A recomendação de DR para a aplicação SAP descrita neste documento está em 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
Normalmente em sistemas distribuídos SAP NetWeaver; serviços centrais, banco de dados e armazenamento compartilhado (NFS/SMB) são pontos únicos de falhas (SPOF). Para mitigar 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 pela configuração de 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 de desastres dispersos geograficamente, a estratégia de DR deve ser implementada para todos os componentes SAP.
Para sistemas SAP executados em máquinas virtuais, você pode usar o Azure Site Recovery para criar um plano de recuperação de desastres. A seguir está a abordagem de recuperação de desastres recomendada para cada componente de um sistema SAP. Mecanismos SAP autônomos que não sejam NetWeaver, 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 aplicativos SAP | Replicar VM usando o Azure Site Recovery |
| Banco de dados SAP | Usar o 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 um balanceador de carga para o tráfego SAP entre servidores de aplicativos SAP. Você tem diferentes opções para obter alta disponibilidade do componente SAP Web Dispatcher na região principal. Para obter mais informações sobre essa opção, consulte Alta disponibilidade do SAP Web Dispatcher e Configuração de HA do SAP Web dispatcher no Azure.
- Opção 1: Alta disponibilidade usando solução de cluster.
- Opção 2: Alta disponibilidade com SAP Web Dispatchers paralelos.
Para obter DR para configuração altamente disponível do SAP Web Dispatcher na região primária, você pode usar o Azure Site Recovery. Para despachantes da Web paralelos (opção 2) em execução na região primária, você pode configurar o Azure Site Recovery para obter 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 de DR. Como a configuração do SAP Web Dispatcher, a alta disponibilidade com a solução de cluster é configurada de maneira semelhante aos serviços centrais da SAP. Siga as mesmas diretrizes mencionadas para o SAP Central Services.
SAP Central Services
Os serviços centrais SAP contêm enqueue e servidor de mensagens, que é um dos SPOF do seu aplicativo SAP. Em um sistema SAP, pode haver apenas uma instância desse tipo, e ela pode ser configurada para alta disponibilidade. Leia Alta disponibilidade para SAP Central Service para entender as diferentes soluções de alta disponibilidade para carga de trabalho SAP no Azure.
A configuração da alta disponibilidade para SAP Central Services protege recursos e processos contra incidentes locais. Para obter DR para SAP Central Services, você pode usar o Azure Site Recovery. O Azure Site Recovery replica 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 usado para os serviços centrais SAP.
Para o sistema SAP, a redundância do componente SPOF na região primária é obtida através da configuração de 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 pontos adicionais. Isso inclui reconfigurar o cluster, certificar-se de que os diretórios compartilhados 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 alcançada usando a solução de cluster de marcapasso. O diagrama abaixo mostra os diferentes componentes envolvidos na configuração de alta disponibilidade para serviços centrais SAP com Pacemaker. Cada componente deve ser levado em consideração para ter uma alta disponibilidade semelhante configurada no site de DR. Se você configurou o SAP Web Dispatcher usando a solução de cluster de marcapasso, uma consideração semelhante também se aplicaria.
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 antes ou após o failover. Se você criar o balanceador de carga interno previamente, crie um pool de back-end vazio e adicione VMs após o evento de failover.
Solução de cluster Pacemaker
As configurações de um cluster de marcapasso 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 de marcapasso no estado em que se encontra 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 do cluster de marcapasso na região DR, com base no tipo de seu mecanismo de armazenamento e cerca.
- Failover do Cluster SAP ASCS/ERS HA com dispositivo SBD (usando o servidor de destino iSCSI) para a região DR usando o Azure Site Recovery.
- Failover do SAP ASCS HA Cluster (no sistema operacional Linux) para a região DR usando o Azure Site Recovery.
Diretórios compartilhados SAP para Linux
A configuração de alta disponibilidade da plataforma SAP NetWeaver ou ABAP usa o servidor de replicação enqueue para obter redundância no nível do aplicativo para o serviço de enqueue do sistema SAP com configuração de cluster 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 os dados SAP nessas montagens NFS sejam replicados para o site de DR. O Azure Site Recovery replica VMs e disco gerenciado local anexado, mas não replica montagens NFS. Com base no tipo de armazenamento NFS configurado para a configuração, você precisa garantir que os dados sejam replicados e estejam disponíveis no site de DR. A metodologia de replicação inter-regional para cada armazenamento é apresentada em nível abstrato. Você precisa confirmar as etapas exatas para replicar o armazenamento e executar testes.
| Diretórios compartilhados SAP | Replicação inter-regional |
|---|---|
| NFS em arquivos do Azure | Personalizado (como rsync) |
| NFS sobre ANF | Sim (replicação entre regiões) |
| Cluster NFS | Personalizado |
Gorjeta
Recomendamos implantar um dos serviços NFS primários do Azure: NFS em arquivos do Azure ou volumes ANF NFS para armazenar dados compartilhados em um sistema SAP altamente disponível. Esteja ciente de que estamos desenfatizando as arquiteturas de referência SAP, utilizando clusters NFS.
Mecanismo de Esgrima
Independentemente do sistema operacional (SLES ou RHEL) e sua versão, o marcapasso requer um mecanismo de vedação válido para que toda a solução funcione corretamente. Com base no tipo de mecanismo de vedação que você configurou na região principal, você precisa garantir que o mesmo mecanismo de vedação esteja configurado no site de DR após o failover.
| Mecanismo de Esgrima | 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. Em VMs DR, descubra o disco iSCSI novamente. |
| Agente de vedação do Azure | Habilite identidades de sistema gerenciado (MSI) em VMs DR. Atribua funções personalizadas. Atualize o recurso do agente de cerca no cluster. |
| SBD usando o disco compartilhado do Azure* | Configure o novo Disco Compartilhado do Azure na região DR. Anexe o Disco Compartilhado do Azure a VMs DR após o failover. Configure o dispositivo SBD de disco compartilhado do Azure. |
*O ZRS para disco compartilhado do Azure está disponível em regiões limitadas.
Nota
Recomendamos ter o mesmo mecanismo de vedação para as regiões primária e DR para facilitar a operação e o failover. Não é aconselhável ter um mecanismo de vedação diferente após o failover para o local de DR.
Servidores de aplicativos SAP
Na região primária, a redundância dos servidores de aplicativos SAP é obtida com a instalação de instâncias em várias VMs. Para ter DR para servidores de aplicativos SAP, o Azure Site Recovery pode ser configurado para cada VM do servidor de aplicativos. Para armazenamentos compartilhados (sistema de arquivos de transporte, sistema de arquivos de dados 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 carga de trabalho SAP, use a tecnologia de replicação DBMS nativa para configurar a DR. O uso do Azure Site Recovery para bancos de dados não é recomendado, pois não garante a consistência do banco de dados e tem limitação de rotatividade de dados. A tecnologia de replicação para cada banco de dados é diferente, portanto, siga as respetivas diretrizes de banco de dados. A tabela a seguir mostra a lista de bancos de dados usados para cargas de trabalho SAP e a recomendação de DR correspondente.
| Base de Dados | Recomendação DR |
|---|---|
| SAP HANA | Replicação do sistema HANA (HSR) |
| Oracle | Oracle Data Guard (FarSync) |
| IBM DB2 | Recuperação de desastres de alta disponibilidade (HADR) |
| Microsoft SQL | Microsoft SQL Always On |
| SAP ASE | ASE HADR Sempre Ativo |
| SAP MaxDB | Base de dados em espera |
Para uma solução de custo otimizado, você pode até usar a opção de backup e restauração para a estratégia de DR do banco de dados.
Cópia de segurança e restauro
Backup e restauração é outra solução que você pode usar para obter recuperação de desastres para suas cargas de trabalho SAP se o RTO e o RPO de negócios 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 de sua carga de trabalho SAP, como máquinas virtuais, discos gerenciados e bancos de dados suportados. Para saber mais sobre as configurações e limitações gerais de suporte para cenários e implantações do Backup do Azure, consulte Matriz de suporte do Backup do Azure.
| Serviços | Componente | Suporte de Backup do Azure |
|---|---|---|
| Computação | Azure VMs | Suportado |
| Armazenamento | Azure Managed Disks, incluindo discos partilhados | Suportado |
| Armazenamento | Azure File Share - SMB (Standard ou Premium) | Suportado |
| Armazenamento | Blobs do Azure | Suportado |
| Armazenamento | Azure File Shared - NFS (Standard ou Premium) | Não suportado |
| Armazenamento | Azure NetApp Files | Não suportado |
| Base de Dados | Banco de dados SAP HANA em VMs do Azure | Suportado |
| Base de Dados | Servidor SQL em VMs do Azure | Suportado |
| Base de Dados | Oracle | Suportado* |
| Base de Dados | IBM DB2, SAP ASE | Não suportado |
Nota
*O backup do Azure oferece 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 a carga de trabalho do SAP.
O backup do Azure armazena backups no cofre do serviço de recuperação, que replica seus dados com base no tipo de replicação escolhido (LRS, ZRS ou GRS). Para armazenamento com redundância geográfica (GRS), 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 suportado na região secundária.
O backup e a restauração são uma abordagem mais tradicional de custo otimizado, mas vêm com uma compensação de RTO mais alto. Como você precisa restaurar todos os aplicativos do backup se houver failover para a região de DR. Portanto, você precisa analisar a necessidade do seu negócio e, consequentemente, projetar uma estratégia de DR.