Arquitetura e cenários de alta disponibilidade para SAP NetWeaver

Definições terminológicas

Alta disponibilidade: refere-se a um conjunto de tecnologias que minimizam as interrupções de TI fornecendo continuidade de negócios de serviços de TI por meio de componentes redundantes, tolerantes a falhas ou protegidos contra failover dentro do mesmo data center. No nosso caso, o data center reside em uma região do Azure.

Recuperação de desastres: também se refere à minimização da interrupção dos serviços de TI e sua recuperação, mas em vários data centers que podem estar a centenas de quilômetros de distância uns dos outros. No nosso caso, os centros de dados podem residir em várias regiões do Azure dentro da mesma região geopolítica ou em locais conforme estabelecido por si como cliente.

Visão geral da alta disponibilidade

A alta disponibilidade do SAP no Azure pode ser separada em três tipos:

• Alta disponibilidade da infraestrutura do Azure:

  Por exemplo, a alta disponibilidade pode incluir computação (VMs), rede ou armazenamento e seus benefícios para aumentar a disponibilidade de aplicativos SAP.

• Utilizando a reinicialização da VM de infraestrutura do Azure para proteger aplicativos SAP:

  Se você decidir não usar funcionalidades como o WSFC (Cluster de Failover do Windows Server) ou o Pacemaker no Linux, a reinicialização da VM do Azure será utilizada. Ele restaura a funcionalidade nos sistemas SAP se houver algum tempo de inatividade planejado e não planejado da infraestrutura do servidor físico do Azure e da plataforma subjacente geral do Azure.

• Alta disponibilidade da aplicação SAP:

  Para obter alta disponibilidade total do sistema SAP, você deve proteger todos os componentes críticos do sistema SAP. Por exemplo:

  • Servidores de aplicações SAP redundantes.
  • Componentes únicos. Um exemplo pode ser um componente de ponto único de falha (SPOF), como uma instância SAP ASCS/SCS ou um sistema de gerenciamento de banco de dados (DBMS).

A alta disponibilidade do SAP no Azure difere da alta disponibilidade do SAP em um ambiente físico ou virtual local.

Não há nenhuma configuração de alta disponibilidade SAP integrada ao sapinst para Linux como existe para Windows. Para obter informações sobre a alta disponibilidade local do SAP para Linux, consulte Informações de parceiros de alta disponibilidade.

Alta disponibilidade da infraestrutura do Azure

SLA para máquinas virtuais de instância única

Atualmente, há um SLA de VM única de 99,9% com armazenamento premium. Para ter uma ideia sobre qual pode ser a disponibilidade de uma única VM, você pode criar o produto dos vários Contratos de Nível de Serviço do Azure disponíveis.

A base de cálculo é de 30 dias por mês, ou 43.200 minutos. Por exemplo, um tempo de inatividade de 0,05% corresponde a 21,6 minutos. Como habitualmente, a disponibilidade dos vários serviços é calculada da seguinte forma:

(Serviço de Disponibilidade #1/100) x (Serviço de Disponibilidade #2/100) x (Serviço de Disponibilidade #3/100) *...

Por exemplo:

(99,95/100) x (99,9/100) x (99,9/100) = 0,9975 ou uma disponibilidade global de 99,75%.

Várias instâncias de máquinas virtuais no mesmo conjunto de disponibilidade

Para todas as máquinas virtuais que têm duas ou mais instâncias implantadas no mesmo conjunto de disponibilidade, garantimos que você tenha conectividade de máquina virtual com pelo menos uma instância pelo menos 99,95% do tempo.

Quando duas ou mais VMs fazem parte do mesmo conjunto de disponibilidade, cada máquina virtual no conjunto de disponibilidade recebe um domínio de atualização e um domínio de falha pela plataforma subjacente do Azure.

• Os domínios de atualização garantem que várias VMs não sejam reinicializadas ao mesmo tempo durante a manutenção planejada de uma infraestrutura do Azure. Apenas uma VM é reinicializada de cada vez.
• Os domínios de falha garantem que as VMs sejam implantadas em componentes de hardware que não compartilham uma fonte de alimentação e um switch de rede comuns. Quando servidores, um switch de rede ou uma fonte de alimentação passam por um tempo de inatividade não planejado, apenas uma VM é afetada.

Para obter mais informações, consulte gerenciar a disponibilidade de máquinas virtuais no Azure usando o conjunto de disponibilidade.

Zonas de Disponibilidade do Azure

O Azure está em processo de implantação de um conceito de Zonas de Disponibilidade do Azure em diferentes Regiões do Azure. Nas regiões do Azure onde as Zonas de Disponibilidade são oferecidas, as regiões do Azure têm vários data centers, que são independentes no fornecimento de fonte de alimentação, resfriamento e rede. O motivo para oferecer zonas diferentes em uma única região do Azure é permitir que você implante aplicativos em duas ou três Zonas de Disponibilidade oferecidas. Supondo que problemas em fontes de energia e/ou rede afetariam apenas uma infraestrutura de Zona de Disponibilidade, sua implantação de aplicativo em uma região do Azure ainda está totalmente funcional. Eventualmente com alguma capacidade reduzida, uma vez que algumas VMs em uma zona podem ser perdidas. Mas as VMs nas outras duas zonas ainda estão em funcionamento. As regiões do Azure que oferecem zonas estão listadas em Zonas de Disponibilidade do Azure.

Ao usar as Zonas de Disponibilidade, há algumas coisas a considerar. A lista de considerações como:

• Não é possível implantar Conjuntos de Disponibilidade do Azure em uma Zona de Disponibilidade. A única possibilidade de combinar conjuntos de disponibilidade e zonas de disponibilidade é com grupos de colocação de proximidade. Para obter mais informações, consulte o artigo Combinar conjuntos de disponibilidade e zonas de disponibilidade com grupos de posicionamento de proximidade.
• Não é possível usar o Balanceador de Carga Básico para criar soluções de cluster de failover baseadas nos Serviços de Cluster de Failover do Windows ou no Pacemaker Linux. Em vez disso, você precisa usar a SKU do Balanceador de Carga Padrão do Azure.
• As Zonas de Disponibilidade do Azure não estão a dar garantias de uma certa distância entre as diferentes zonas dentro de uma região.
• A latência de rede entre diferentes Zonas de Disponibilidade do Azure dentro das diferentes regiões do Azure pode ser diferente de região para região do Azure. Haveria casos em que você, como cliente, pode executar razoavelmente a camada de aplicativo SAP implantada em diferentes zonas, uma vez que a latência da rede de uma zona para a VM DBMS ativa ainda é aceitável a partir de um impacto no processo de negócios. Considerando que pode haver cenários de clientes em que a latência entre a VM DBMS ativa em uma zona e uma instância de aplicativo SAP em uma VM em outra zona pode ser muito intrusiva e não aceitável para os processos de negócios SAP. Como resultado, as arquiteturas de implantação precisam ser diferentes com uma arquitetura ativa/ativa para o aplicativo ou uma arquitetura ativa/passiva se a latência for muito alta.
• O uso de discos gerenciados do Azure é obrigatório para implantação em Zonas de Disponibilidade do Azure.

Conjunto de dimensionamento de máquina virtual com orquestração flexível

No Azure, os Conjuntos de Dimensionamento de Máquina Virtual com orquestração flexível oferecem um meio de obter alta disponibilidade para cargas de trabalho SAP, muito parecido com outras estruturas de implantação, como conjuntos de disponibilidade e zonas de disponibilidade. Com um conjunto de escala flexível, as VMs podem ser distribuídas em várias zonas de disponibilidade e domínios de falha, tornando-se uma opção adequada para a implantação de cargas de trabalho SAP altamente disponíveis.

O conjunto de dimensionamento de máquina virtual com orquestração flexível oferece a flexibilidade de criar o conjunto de escala dentro de uma região ou estendê-la por zonas de disponibilidade. Ao criar, a escala flexível definida dentro de uma região com platformFaultDomainCount>1 (FD>1), as VMs implantadas no conjunto de escala seriam distribuídas entre o número especificado de domínios de falha na mesma região. Por outro lado, a criação do conjunto de escala flexível entre zonas de disponibilidade com platformFaultDomainCount=1 (FD=1) distribuiria as VMs em diferentes zonas e o conjunto de escala também distribuiria VMs em diferentes domínios de falha dentro de cada zona com base no melhor esforço. Para carga de trabalho SAP, apenas o conjunto de escala flexível com FD=1 é suportado.

A vantagem de usar conjuntos de escala flexíveis com FD=1 para implantação interzonal, em vez da implantação tradicional da zona de disponibilidade, é que as VMs implantadas com o conjunto de escala seriam distribuídas entre diferentes domínios de falha dentro da zona de uma maneira de melhor esforço. Para evitar as limitações associadas à utilização do grupo de posicionamento de proximidade para garantir a disponibilidade de VMs em todos os datacenters do Azure ou em cada coluna de rede, é aconselhável implantar a carga de trabalho SAP em zonas de disponibilidade usando um conjunto de escala flexível com FD=1. Essa estratégia de implantação garante que as VMs implantadas em cada zona não fiquem restritas a um único datacenter ou coluna de rede, e todos os componentes do sistema SAP, como bancos de dados, ASCS/ERS e camada de aplicativo, tenham escopo no nível zonal.

Portanto, para a nova implantação de carga de trabalho SAP em zonas de disponibilidade, recomendamos o uso de um conjunto de escala flexível com FD=1. Para obter mais informações, consulte Conjunto de dimensionamento de máquina virtual para documento de carga de trabalho SAP.

Manutenção planejada e não planejada de máquinas virtuais

Dois tipos de eventos da plataforma Azure podem afetar a disponibilidade de suas máquinas virtuais:

• Os eventos de manutenção planejada são atualizações periódicas feitas pela Microsoft para a plataforma subjacente do Azure. As atualizações melhoram a confiabilidade, o desempenho e a segurança gerais da infraestrutura da plataforma na qual suas máquinas virtuais são executadas.
• Eventos de manutenção não planejada ocorrem quando o hardware ou a infraestrutura física subjacente à máquina virtual falhou de alguma forma. Pode incluir falhas de rede local, falhas de disco local ou outras falhas de nível de rack. Quando essa falha é detetada, a plataforma Azure migra automaticamente sua máquina virtual do servidor físico não íntegro que hospeda sua máquina virtual para um servidor físico íntegro. Esses eventos são raros, mas também podem fazer com que sua máquina virtual seja reinicializada.

Para obter mais informações, consulte Manutenção de máquinas virtuais no Azure.

Redundância do Armazenamento do Azure

Os dados em sua conta de armazenamento são sempre replicados para garantir durabilidade e alta disponibilidade, atendendo ao SLA de Armazenamento do Azure mesmo em caso de falhas transitórias de hardware.

Como o Armazenamento do Azure mantém três imagens dos dados por padrão, o uso de RAID 5 ou RAID 1 em vários discos do Azure é desnecessário.

Para obter mais informações, consulte Replicação do Armazenamento do Azure.

Managed Disks do Azure

Managed Disks é um tipo de recurso no Azure Resource Manager, é uma opção de armazenamento recomendada em vez de VHDs (discos rígidos virtuais) armazenados em contas de armazenamento do Azure. Os discos gerenciados se alinham automaticamente com um conjunto de disponibilidade do Azure da máquina virtual à qual estão conectados. Eles aumentam a disponibilidade de sua máquina virtual e os serviços que estão sendo executados nela.

Para obter mais informações,veja Azure Managed Disks overview (Descrição geral dos Managed Disks do Azure).

Recomendamos que você use discos gerenciados porque eles simplificam a implantação e o gerenciamento de suas máquinas virtuais.

Comparação de diferentes tipos de implantação para carga de trabalho SAP

Aqui está um resumo rápido dos vários tipos de implantação disponíveis para cargas de trabalho SAP.

Opções de implantação de alta disponibilidade para carga de trabalho SAP

Ao implantar uma carga de trabalho SAP de alta disponibilidade no Azure, é importante levar em conta os vários tipos de implantação disponíveis e como eles podem ser aplicados em diferentes regiões do Azure (como entre zonas, em uma única zona ou em uma região sem zonas). A tabela a seguir ilustra várias opções de alta disponibilidade para sistemas SAP em regiões do Azure.

• Implantação em diferentes zonas de uma região: para obter a mais alta disponibilidade, os sistemas SAP devem ser implantados em diferentes zonas de uma região. Isso garante que, se uma zona não estiver disponível, o sistema SAP continuará disponível em outra zona. Se você estiver implantando uma nova carga de trabalho SAP em zonas de disponibilidade, é aconselhável usar escalas flexíveis de máquina virtual definidas com a opção de implantação FD=1. Ele permite que você implante várias VMs em diferentes zonas em uma região sem se preocupar com restrições de capacidade ou grupos de posicionamento. A estrutura do conjunto de escala garante que as VMs implantadas com o conjunto de escala sejam distribuídas entre diferentes domínios de falha dentro da zona da melhor maneira possível. Todos os componentes SAP altamente disponíveis, como SAP ASCS/ERS, SAP databases são distribuídos em diferentes zonas, enquanto vários servidores de aplicativos em cada zona são distribuídos em diferentes domínios de falha com base no melhor esforço.
• Implantação em uma única zona de uma região: para implantar seu sistema SAP de alta disponibilidade regionalmente em um local com várias zonas de disponibilidade, e se for essencial que todos os componentes do sistema estejam em uma única zona, é aconselhável usar a opção de implantação Conjuntos de disponibilidade com grupos de posicionamento de proximidade. Essa abordagem permite agrupar todos os componentes do sistema SAP em uma única zona de disponibilidade, garantindo que as máquinas virtuais dentro do conjunto de disponibilidade estejam espalhadas por diferentes domínios de falha e atualização. Embora essa implantação alinhe a computação aos domínios de falha de armazenamento, a proximidade não é garantida. No entanto, como essa opção de implantação é regional, ela não oferece suporte ao Azure Site Recovery para recuperação de desastres de zona a zona. Além disso, essa opção restringe toda a implantação do SAP a um data center, o que pode levar a limitações de capacidade se você precisar alterar o tamanho da SKU ou as instâncias de aplicativo de expansão.
• Implantação em uma região sem zonas: se você estiver implantando seu sistema SAP em uma região que não tenha zonas, é aconselhável usar conjuntos de disponibilidade. Essa opção fornece redundância e tolerância a falhas colocando VMs em diferentes domínios de falha e domínios de atualização.

Utilizando a alta disponibilidade da infraestrutura do Azure para proteger aplicativos SAP

Se você decidir não usar funcionalidades como WSFC ou Pacemaker no Linux (com suporte para SUSE Linux Enterprise Server 12 e posterior e Red Hat Enterprise Linux 7 e posterior), a reinicialização da VM do Azure será utilizada. Ele restaura a funcionalidade nos sistemas SAP se houver algum tempo de inatividade planejado e não planejado da infraestrutura do servidor físico do Azure e da plataforma subjacente geral do Azure.

Para obter mais informações sobre a abordagem, consulte Utilizar a reinicialização da VM de infraestrutura do Azure para obter maior disponibilidade do sistema SAP.

Alta disponibilidade de aplicativos SAP no Azure IaaS

Para obter alta disponibilidade total do sistema SAP, você deve proteger todos os componentes críticos do sistema SAP. Por exemplo:

• Servidores de aplicações SAP redundantes.
• Componentes únicos. Um exemplo pode ser um componente de ponto único de falha (SPOF), como uma instância SAP ASCS/SCS ou um sistema de gerenciamento de banco de dados (DBMS).

As próximas seções discutem como obter alta disponibilidade para todos os três componentes críticos do sistema SAP.

Arquitetura de alta disponibilidade para servidores de aplicativos SAP

Windows e Linux

Normalmente, você não precisa de uma solução específica de alta disponibilidade para o servidor de aplicativos SAP e instâncias de diálogo. Você obtém alta disponibilidade por redundância e configura várias instâncias de diálogo em várias instâncias de máquinas virtuais do Azure. Você deve ter pelo menos duas instâncias de aplicativo SAP instaladas em duas instâncias de máquinas virtuais do Azure.

Dependendo do tipo de implantação (escala flexível definida com FD=1, zona de disponibilidade ou conjunto de disponibilidade), você deve distribuir as instâncias do servidor de aplicativos SAP de acordo para obter redundância.

• Conjunto de escala flexível com platformFaultDomainCount=1 (FD=1): os servidores de aplicativos SAP implantados com conjunto de escala flexível (FD=1) distribuem as máquinas virtuais em diferentes zonas de disponibilidade e o conjunto de escalas também distribuiria VMs em diferentes domínios de falha dentro de cada zona com base no melhor esforço. Isso garante que, se uma zona estiver indisponível, os servidores de aplicativos SAP implantados em outra zona continuarão disponíveis.
• Zona de disponibilidade: os servidores de aplicativos SAP implantados em zonas de disponibilidade garantem que as VMs sejam estendidas em diferentes zonas para obter redundância. Isso garante que, se uma zona estiver indisponível, os servidores de aplicativos SAP implantados em outra zona continuarão disponíveis. Para obter mais informações, consulte Configurações de carga de trabalho SAP com zonas de disponibilidade do Azure
• Conjunto de disponibilidade: os servidores de aplicativos SAP implantados no conjunto de disponibilidade garantem que as VMs sejam distribuídas em diferentes domínios de falha e domínios de atualização. Ao colocar VMs em diferentes domínios de atualização, certifique-se de que as VMs não sejam atualizadas ao mesmo tempo durante o tempo de inatividade de manutenção planejada. Enquanto isso, colocar VMs em domínios de falha diferentes garante que a VM esteja protegida contra falhas de hardware ou interrupções de energia em um data center. Mas o número de domínios de falha e atualização que você pode usar no conjunto de disponibilidade do Azure dentro de uma unidade de escala do Azure é finito. Se você continuar adicionando VMs a um único conjunto de disponibilidade, duas ou mais VMs acabarão no mesmo domínio de falha ou atualização. Para obter mais informações, consulte a seção Conjuntos de disponibilidade do Azure do documento Planejamento e implementação de máquinas virtuais do Azure para SAP NetWeaver.

Somente discos não gerenciados: ao usar discos não gerenciados com conjunto de disponibilidade, é importante reconhecer que a conta de armazenamento do Azure se torna um único ponto de falha. Portanto, é imperativo possuir um mínimo de duas contas de armazenamento do Azure, nas quais pelo menos duas máquinas virtuais são distribuídas. Em uma configuração ideal, os discos de cada máquina virtual que está executando uma instância de diálogo SAP seriam implantados em uma conta de armazenamento diferente.

Arquitetura de alta disponibilidade para uma instância SAP ASCS/SCS no Windows

Mac OS

Você pode usar uma solução WSFC para proteger a instância SAP ASCS/SCS. Com base no tipo de configuração de compartilhamento de cluster (compartilhamento de arquivos ou disco compartilhado), você pode consultar a solução apropriada com base no seu tipo de armazenamento.

• Compartilhamento de cluster - Compartilhamento de arquivos

  • Alta disponibilidade da instância SAP ASCS/SCS usando SMB em Arquivos do Azure.
  • Alta disponibilidade da instância SAP ASCS/SCS usando SMB em arquivos NetApp do Azure.
  • Alta disponibilidade da instância SAP ASCS/SCS usando SOFS (Scale out File Server).

• Compartilhamento de cluster - Disco compartilhado

  • Alta disponibilidade da instância SAP ASCS/SCS usando o disco compartilhado do Azure.
  • Alta disponibilidade da instância SAP ASCS/SCS usando SIOS.

Arquitetura de alta disponibilidade para uma instância SAP ASCS/SCS no Linux

Linux

No Linux, a configuração do clustering de instâncias SAP ASCS/SCS depende da distribuição do sistema operacional e do tipo de armazenamento que está sendo usado. Recomenda-se implementar a solução adequada de acordo com a estrutura específica do cluster do SO.

• Servidor SUSE Linux Enterprise (SLES)

  • Alta disponibilidade da instância SAP ASCS/SCS usando NFS com montagem simples.
  • Alta disponibilidade da instância SAP ASCS/SCS usando NFS em Arquivos do Azure.
  • Alta disponibilidade da instância SAP ASCS/SCS usando NFS em arquivos NetApp do Azure.
  • Alta disponibilidade da instância SAP ASCS/SCS usando NFS Server.

• Red Hat Enterprise Linux (RHEL)

  • Alta disponibilidade da instância SAP ASCS/SCS usando NFS em Arquivos do Azure.
  • Alta disponibilidade da instância SAP ASCS/SCS usando NFS em arquivos NetApp do Azure.

Configuração multi-SID do SAP NetWeaver para uma instância SAP ASCS/SCS clusterizada

Janela

Multi-SID é suportado com WSFC, usando compartilhamento de arquivos e disco compartilhado. Para obter mais informações sobre a arquitetura de alta disponibilidade multi-SID no Windows, consulte:

• Compartilhamento de arquivos: alta disponibilidade de instância SAP ASCS/SCS MULTI-SID para clustering de failover do Windows Server e compartilhamento de arquivos.
• Disco compartilhado: alta disponibilidade de instância SAP ASCS/SCS multi-SID para Clustering de Failover do Windows Server e disco compartilhado.

Linux

O clustering multi-SID é suportado em clusters Linux Pacemaker para SAP ASCS/ERS, limitado a cinco SIDs SAP no mesmo cluster. Para obter mais informações sobre a arquitetura de alta disponibilidade multi-SID no Linux, consulte:

• SUSE Linux Enterprise Server (SLES): HA para SAP NW em VMs do Azure em SLES para aplicativos SAP multi-SID guia.
• Red Hat Linux Enterprise (RHEL): HA for SAP NW on Azure VMs on RHEL for SAP applications multi-SID guide.

Alta disponibilidade da instância DBMS

Em um sistema SAP, os servidores DBMS também são o único ponto de falha. Portanto, é importante proteger o banco de dados implementando uma solução de alta disponibilidade. A solução de alta disponibilidade do SGBD varia de acordo com o banco de dados utilizado para o sistema SAP. Com base no seu banco de dados, siga as diretrizes para obter alta disponibilidade em seu banco de dados.