Diretrizes de recuperação após desastre para a aplicação SAP
Para configurar a Recuperação Após Desastre (DR) para a carga de trabalho SAP no Azure, tem de testar, ajustar e atualizar o processo regularmente. Testar a recuperação após desastre ajuda a identificar a sequência de serviços dependentes que são necessários antes de poder acionar a ativação pós-falha de DR da carga de trabalho SAP ou iniciar o sistema no site secundário. Normalmente, as organizações têm os seus sistemas SAP ligados aos serviços do Active Directory (AD) e do Sistema de Nomes de Domínio (DNS) para funcionarem corretamente. Quando configurar a DR para a carga de trabalho SAP, certifique-se de que os serviços AD e DNS estão a funcionar antes de recuperar o SAP e outros sistemas não SAP, para garantir que a aplicação funciona corretamente. Para obter orientações sobre como proteger o Active Directory e o DNS, saiba como proteger o Active Directory e o DNS. A recomendação de DR para a aplicação SAP descrita neste documento está num nível abstrato. Tem de conceber a sua estratégia de DR com base na configuração específica e documentar o cenário ponto a ponto.
Recomendação de DR para cargas de trabalho SAP
Normalmente em sistemas SAP NetWeaver distribuídos; os serviços centrais, a base de dados e o armazenamento partilhado (NFS/SMB) são um ponto único de falhas (SPOF). Para mitigar o efeito de diferentes SPOFs, é necessário configurar a redundância destes componentes. A redundância destes componentes SPOF na região primária é obtida através da configuração da elevada disponibilidade. A configuração de elevada disponibilidade do componente protege o sistema SAP contra falhas locais ou catástrofes. Contudo, para proteger as aplicações SAP contra desastres dispersos geográficos, a estratégia de DR deve ser implementada para todos os componentes SAP.
Para sistemas SAP em execução em máquinas virtuais, pode utilizar o Azure Site Recovery para criar um plano de recuperação após desastre. Segue-se a abordagem de recuperação após desastre recomendada para cada componente de um sistema SAP. Os motores SAP autónomos não NetWeaver, como TREX e aplicações não SAP, não são abrangidos neste documento.
| Componentes | Recomendação |
|---|---|
| SAP Web Dispatcher | Replicar VM com o Azure Site Recovery |
| SAP Central Services | Replicar VM com o Azure Site Recovery |
| Servidor da Aplicação SAP | Replicar VM com o Azure Site Recovery |
| Base de Dados SAP | Utilizar o método de replicação oferecido pela base de dados |
| Armazenamento Partilhado | Replicar conteúdo com o método adequado por tipo de armazenamento |
SAP Web Dispatcher
O componente SAP Web Dispatcher funciona como um balanceador de carga para o tráfego SAP entre os servidores de aplicações SAP. Tem diferentes opções para alcançar a elevada disponibilidade do componente SAP Web Dispatcher na região primária. Para obter mais informações sobre esta opção, veja High Availability of the SAP Web Dispatcher and SAP Web dispatcher HA setup on Azure (Elevada Disponibilidade do SAP Web Dispatcher e configuração ha do sap web dispatcher no Azure).
- Opção 1: elevada disponibilidade com a solução de cluster.
- Opção 2: elevada disponibilidade com Sap Web Dispatchers paralelos.
Para obter DR para a configuração do SAP Web Dispatcher de elevada disponibilidade na região primária, pode utilizar o Azure Site Recovery. Para despachantes Web paralelos (opção 2) em execução na região primária, pode configurar o Azure Site Recovery para obter DR. No entanto, se tiver configurado o SAP Web Dispatcher com a opção 1 na região primária, terá de efetuar algumas alterações adicionais após a ativação pós-falha para ter uma configuração ha semelhante na região de DR. Uma vez que a configuração do SAP Web Dispatcher de elevada disponibilidade com a solução de cluster é configurada de forma semelhante aos serviços centrais sap. Siga as mesmas diretrizes mencionadas para os Serviços Centrais do SAP.
SAP Central Services
Os serviços centrais sap contêm enqueue e servidor de mensagens, que é um dos SPOF da sua aplicação SAP. Num sistema SAP, só pode existir uma dessas instâncias e pode ser configurada para elevada disponibilidade. Leia Elevada Disponibilidade para o Serviço SAP Central para compreender a solução de elevada disponibilidade para a carga de trabalho SAP no Azure.
A configuração da elevada disponibilidade dos Serviços Centrais sap protege os recursos e os processos de incidentes locais. Para obter dr para serviços sap central, pode utilizar o Azure Site Recovery. O Azure Site Recovery replica VMs e os discos geridos anexados, mas existem considerações adicionais para a estratégia de DR. Consulte a secção abaixo para obter mais informações, com base no sistema operativo utilizado para os serviços centrais sap.
Para o sistema SAP, a redundância do componente SPOF na região primária é obtida ao configurar a elevada disponibilidade. Para obter uma configuração de elevada disponibilidade semelhante na região de recuperação após desastre após a ativação pós-falha, tem de considerar pontos adicionais, como a reconfiguração do cluster, a disponibilidade dos diretórios partilhados do SAP, juntamente com a replicação de VMs e o disco gerido anexado ao site de DR com o Azure Site Recovery. No Linux, a elevada disponibilidade da aplicação SAP pode ser obtida com a solução de cluster pacemaker. O diagrama abaixo mostra os diferentes componentes envolvidos na configuração da elevada disponibilidade dos serviços centrais sap com o Pacemaker. Cada componente tem de ser tido em consideração para ter uma elevada disponibilidade semelhante configurada no site de DR. Se tiver configurado o SAP Web Dispatcher com a solução de cluster pacemaker, também será aplicada uma consideração semelhante.
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. Terá de criar um balanceador de carga interno separado no site de DR de antemão ou após a ativação pós-falha. Se criar previamente um balanceador de carga interno, crie um conjunto de back-end vazio e adicione VMs após o evento de ativação pós-falha.
Solução de cluster do Pacemaker
As configurações de um cluster pacemaker residem em ficheiros locais de VMs, que são replicadas para o site de DR com o Azure Site Recovery. A configuração do cluster pacemaker tal como está não funciona nas VMs após a ativação pós-falha. É necessária reconfiguração adicional do cluster para que a solução funcione.
Leia estes blogues para saber mais sobre a reconfiguração do cluster pacemaker na região de DR, com base no tipo do seu mecanismo de armazenamento e esgrima.
- Ativação pós-falha do Cluster DE HA do SAP ASCS/ERS com dispositivo SBD (com o servidor de destino iSCSI) para a região de DR com o Azure Site Recovery.
- Ativação pós-falha do Cluster DE HA do SAP ASCS (no SO Linux) para a região de DR com o Azure Site Recovery.
Diretórios partilhados sap para Linux
A configuração de elevada disponibilidade do SAP NetWeaver ou da plataforma ABAP utiliza o servidor de replicação enqueue para alcançar a redundância ao nível da aplicação para o serviço enqueue do sistema SAP com a configuração do cluster Pacemaker. A configuração de elevada disponibilidade dos serviços centrais sap (ASCS e ERS) utiliza montagens NFS. Por isso, tem de se certificar de que os binários SAP e os dados nestas montagens NFS são replicados para o site de DR. O Azure Site Recovery replica VMs e o disco gerido local ligado, mas não replica montagens NFS. Com base no tipo de armazenamento NFS que configurou para a configuração, tem de se certificar de que os dados são replicados e disponíveis no site de DR. A metodologia de replicação entre regiões para cada armazenamento é apresentada ao nível abstrato. Tem de confirmar os passos exatos para replicar o armazenamento e realizar testes.
| Diretórios partilhados sap | Replicação entre regiões |
|---|---|
| NFS em ficheiros do Azure | Personalizado (como rsync) |
| NFS no ANF | Sim (Replicação Entre Regiões) |
| Cluster NFS | Personalizado |
Dica
Recomendamos que implemente um dos serviços NFS originais do Azure: NFS em volumes ANF de Ficheiros do Azure ou NFS para armazenar dados partilhados num sistema SAP de elevada disponibilidade. Tenha em atenção que estamos a descentuar as arquiteturas de referência do SAP, através de clusters NFS.
Mecanismo de Esgrima
Independentemente do sistema operativo (SLES ou RHEL) e da sua versão, o pacemaker requer um mecanismo de esgrima válido para que toda a solução funcione corretamente. Com base no tipo de mecanismo de esgrima que configurou na sua região primária, tem de se certificar de que o mesmo mecanismo de esgrima está configurado no site de DR após a ativação pós-falha.
| Mecanismo de Esgrima | Recomendação de DR entre regiões |
|---|---|
| SBD com o servidor de destino iSCSI | Replicar o servidor de destino iSCSI com o Azure Site Recovery. Nas VMs de DR, detete novamente o disco iSCSI. |
| Agente de cerca do Azure | Ative as Identidades do Sistema Gerido (MSI) em VMs dr. Atribuir funções personalizadas. Atualize o recurso do agente de vedação no cluster. |
| SBD com o disco partilhado do Azure* | Configurar o novo Disco Partilhado do Azure na região de DR. Anexe o Disco Partilhado do Azure a VMs DR após a ativação pós-falha.Configurar o dispositivo SBD do disco partilhado do Azure. |
*O ZRS para o disco partilhado do Azure está disponível em regiões limitadas.
Nota
Recomendamos que tenha o mesmo mecanismo de esgrima para a região primária e de DR para facilitar o funcionamento e a ativação pós-falha. Não é aconselhável ter um mecanismo de esgrima diferente após a ativação pós-falha para o local de DR.
Servidores de Aplicações SAP
Na região primária, a redundância dos servidores de aplicações SAP é obtida através da instalação de instâncias em várias VMs. Para ter DR para servidores de aplicações SAP, o Azure Site Recovery pode ser configurado para cada VM do servidor de aplicações. Para armazenamentos partilhados (sistema de ficheiros de transporte, sistema de ficheiros de dados de interface) anexado aos servidores de aplicações, siga a prática de DR adequada com base no tipo de armazenamento partilhado.
Servidores de Base de Dados SAP
Para bases de dados com cargas de trabalho SAP, utilize a tecnologia de replicação DBMS nativa para configurar a DR. A utilização do Azure Site Recovery para bases de dados não é recomendada, uma vez que não garante a consistência da BD e tem limitação de alterações a dados. A tecnologia de replicação para cada base de dados é diferente, por isso siga as respetivas diretrizes de base de dados. A tabela abaixo mostra a lista de bases de dados utilizadas para cargas de trabalho SAP e a recomendação de DR correspondente.
| Base de Dados | Recomendação de DR |
|---|---|
| SAP HANA | Replicação do Sistema HANA (HSR) |
| Oracle | Oracle Data Guard (FarSync) |
| IBM DB2 | Recuperação após desastre de elevada disponibilidade (HADR) |
| Microsoft SQL | Microsoft SQL AlwaysOn |
| SAP ASE | ASE HADR AlwaysOn |
| SAP MaxDB | Base de Dados de Reserva |
Para uma solução otimizada para custos, pode até utilizar a opção de cópia de segurança e restauro para a estratégia de DR da base de dados.
Criar cópias de segurança e restauro
A cópia de segurança e o restauro são outras soluções que pode utilizar para obter a recuperação após desastre para as cargas de trabalho SAP se o RTO e o RPO empresariais não forem críticos. Pode utilizar o Azure Backup, um serviço de cópia de segurança baseado na cloud para tirar cópias de diferentes componentes da carga de trabalho SAP, como máquinas virtuais, discos geridos e bases de dados suportadas. Para saber mais sobre as definições e limitações gerais de suporte para cenários e implementações de Azure Backup, veja Azure Backup matriz de suporte.
| Serviços | Componente | Suporte do Azure Backup |
|---|---|---|
| Computação | VMs do Azure | Suportado |
| Armazenamento | Azure Managed Disks incluindo discos partilhados | Suportado |
| Armazenamento | Partilha de Ficheiros do Azure – 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 | Base de dados SAP HANA em VMs do Azure | Suportado |
| Base de Dados | SQL Server em VMs do Azure | Suportado |
| Base de Dados | Oracle | Suportado* |
| Base de Dados | IBM DB2, SAP ASE | Não suportado |
Nota
*O Azure Backup suporta a base de dados Oracle com a cópia de segurança da VM do Azure para instantâneos consistentes com a base de dados.
O Azure Backup não suporta todos os armazenamentos e bases de dados do Azure que são utilizados para a carga de trabalho SAP.
O Azure Backup armazena cópias de segurança 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 armazenamento georredundante (GRS), os dados de cópia de segurança são replicados para uma região secundária emparelhada. Com a funcionalidade de restauro entre regiões ativada, pode restaurar dados do tipo de gestão suportado na região secundária.
A cópia de segurança e o restauro são uma abordagem otimizada para custos mais tradicional, mas inclui uma troca de RTO mais elevado. Como precisa de restaurar todas as aplicações a partir da cópia de segurança, se existir uma ativação pós-falha para a região de DR. Por isso, tem de analisar as suas necessidades empresariais e, em conformidade, conceber uma estratégia de DR.