SAP S/4HANA no Linux no Azure

Este guia apresenta um conjunto de práticas comprovadas para executar o S/4HANA e o pacote no HANA em um ambiente de alta disponibilidade que dá suporte à recuperação de desastre (DR) no Azure. As informações do Fiori aplicam-se somente a aplicativos S/4HANA.

Arquitetura

Baixe um Arquivo Visio dessa arquitetura.

Este guia descreve um sistema de produção comum. Esta arquitetura é implantada com tamanhos de máquina virtual (VM) que podem ser alterados para acomodar as necessidades da sua organização. Para ajustá-la às necessidade da empresa, você pode reduzir essa configuração para uma única VM.

Neste guia, o layout de rede está bastante simplificado para demonstrar os princípios arquitetônicos. Ele não se destina a descrever uma rede corporativa completa.

A arquitetura usa os componentes a seguir. Alguns serviços compartilhados são opcionais.

Rede Virtual do Azure. O serviço de Rede Virtual conecta com segurança os recursos do Azure entre si. Nessa arquitetura, uma rede virtual se conecta a um ambiente local por meio de um gateway que está implantado no hub de uma topologia hub-spoke. O spoke é a rede virtual usada para os aplicativos SAP e as camadas de banco de dados.

Emparelhamento de rede virtual. Essa arquitetura usa várias redes virtuais emparelhadas. Essa topologia oferece segmentação de rede e isolamento para serviços que são implantados no Azure. O emparelhamento conecta redes de modo transparente por meio da rede de backbone da Microsoft e não incorre em uma perda de desempenho se implementado em uma única região. Sub-redes separadas são usadas para cada aplicativo de camada (SAP NetWeaver), banco de dados e serviços compartilhados, como jump box e Windows Server Active Directory.

VMs Essa arquitetura usa VMs que executam Linux para a camada de aplicativo e a camada de banco de dados, agrupadas da seguinte maneira:

• Camada de aplicativo. Essa camada arquitetônica inclui o pool de servidores de front-end Fiori, o pool do SAP Web Dispatcher, o pool de servidores de aplicativos e o cluster do SAP Central Services. Para alta disponibilidade do Central Services no Azure em execução nas VMs Linux, é necessário um serviço de compartilhamento de arquivos de rede altamente disponível, como compartilhamentos de arquivos NFS em Arquivos do Azure, Azure NetApp Files, servidores NFS (Network File System) clusterizados ou SIOS Protection Suite para Linux. Para configurar um compartilhamento de arquivos altamente disponível para o cluster do Central Services no Red Hat Enterprise Linux (RHEL), você pode configurar o GlusterFS em VMs do Azure que executam o RHEL. No SUSE Linux Enterprise Server (SLES) 15 SP1 e versões posteriores, ou SLES para Aplicativos SAP, você pode usar Discos compartilhados do Azure em um cluster do Pacemaker para obter alta disponibilidade.

• SAP HANA. A camada de banco de dados usa duas ou mais VMs Linux em um cluster para obter alta disponibilidade em uma implantação de expansão. A replicação de sistema do HANA (HSR) é usada para replicar conteúdo entre os sistemas HANA primário e secundário. O clustering do Linux é usado para detectar falhas de sistema e facilitar o failover automático. Um mecanismo de isolamento baseado em armazenamento ou em nuvem deve ser usado para garantir que o sistema com falha seja isolado ou desligado para evitar a condição de dupla personalidade do cluster. Em implantações de expansão do HANA, você pode obter alta disponibilidade do banco de dados usando uma das seguintes opções:

  • Configure os nós em espera do HANA usando o Azure NetApp Files sem o componente de clustering do Linux.
  • Expanda sem os nós em espera usando o armazenamento premium do Azure. Use o clustering Linux para failover.

• Azure Bastion. Esse serviço permite que você se conecte a uma máquina virtual usando o navegador e o portal do Azure ou por meio do cliente nativo de SSH ou RDP que já está instalado em seu computador local. Se apenas RDP e SSH forem usados para administração, o Azure Bastion será uma ótima solução. Se você usa outras ferramentas de gerenciamento, como o SQL Server Management Studio ou um front-end SAP, use uma jumpbox tradicional autoimplantada.

Serviço de DNS privado. O DNS Privado do Azure fornece um serviço de DNS confiável e seguro para sua rede virtual. O DNS Privado do Azure gerencia e resolve nomes de domínio em uma rede virtual sem a necessidade de configurar uma solução DNS personalizada.

Balanceadores de carga. Para distribuir o tráfego para VMs na sub-rede da camada de aplicativos SAP para alta disponibilidade, é recomendável usar o Azure Standard Load Balancer. Observe que o Standard Load Balancer fornece uma camada de segurança por padrão. As VMs que estão por trás do Standard Load Balancer não têm conectividade de saída com a Internet. Para habilitar a Internet de saída nas VMs, você precisa atualizar a configuração do Standard Load Balancer. Você também pode usar o Gateway da NAT do Azure para obter conectividade de saída. Para alta disponibilidade de aplicativos SAP baseados na Web, use o SAP Web Dispatcher integrado ou outro balanceador de carga disponível comercialmente. Baseie sua seleção em:

• Seu tipo de tráfego, como HTTP ou SAP GUI.
• Serviços de rede necessários, como a terminação SSL (Secure Sockets Layer).

O Standard Load Balancer dá suporte a vários IPs virtuais de front-end. Esse suporte é ideal para implementações de cluster que incluem estes componentes:

• SAP Central Service (ASCS) da Programação Avançada de Aplicativos de Negócios (ABAP)
• Servidor de Replicação Enfileiramento (ERS)

Esses dois componentes podem compartilhar um balanceador de carga para simplificar a solução.

O Standard Load Balancer também dá suporte a clusters SAP com identificador de vários sistemas (multi-SID). Em outras palavras, vários sistemas SAP no SLES ou RHEL podem compartilhar uma infraestrutura comum de alta disponibilidade para a redução de custos. É recomendável avaliar a economia de custos e evitar colocar muitos sistemas em um cluster. O Azure não dá suporte a mais de cinco SIDs por cluster.

Gateway de aplicativo. O Gateway de Aplicativo do Azure é um balanceador de carga de tráfego da Web que pode ser usado no gerenciamento do tráfego para seus aplicativos Web. Os balanceadores de carga tradicionais operam na camada de transporte (camada OSI 4 - TCP e UDP). Eles roteiam o tráfego com base no endereço IP e na porta de origem para um endereço IP e uma porta de destino. Com o Gateway de Aplicativo, é possível tomar decisões de roteamento com base em outros atributos de uma solicitação HTTP, como o caminho de URI ou os cabeçalhos de host. Esse tipo de roteamento é conhecido como balanceamento de carga da camada de aplicativo (camada OSI 7). O S/4HANA oferece serviços de aplicativo Web por meio do Fiori. Você pode balancear a carga desse front-end Fiori, que consiste em aplicativos Web, usando o Gateway de Aplicativo.

Gateway. Um gateway conecta redes distintas e estende sua rede local para uma rede virtual do Azure. O Azure ExpressRoute é o serviço do Azure recomendado para criar conexões privadas que não passam pela Internet pública, mas você também pode usar uma conexão site a site. Para reduzir a latência, o Alcance Global do ExpressRoute e o ExpressRoute FastPath são opções de conectividade que serão discutidas posteriormente neste artigo.

Gateway com redundância de zona. Você pode implantar o ExpressRoute ou gateways da VPN (rede virtual privada) em zonas para proteção contra falhas de zona. Essa arquitetura usa gateways de rede virtual com redundância de zona para resiliência, em vez de uma implantação por zona que se baseia na mesma zona de disponibilidade.

Grupo de posicionamento por proximidade. Esse grupo lógico impõe uma restrição às VMs que são implantadas em um conjunto de disponibilidade ou em um conjunto de dimensionamento de máquinas virtuais. Um grupo de posicionamento por proximidade favorece a colocalização, que coloca as VMs no mesmo datacenter para minimizar a latência do aplicativo.

Grupos de segurança de rede. Para restringir o tráfego de entrada, saída e dentro da sub-rede em uma rede virtual, é possível criar grupos de segurança de rede.

Grupos de segurança do aplicativo. Para definir políticas de segurança de rede refinadas baseadas em cargas de trabalho e centradas nos aplicativos, use grupos de segurança de aplicativo em vez de endereços IP explícitos. Você pode agrupar VMs por nome e proteger aplicativos filtrando o tráfego de segmentos confiáveis da sua rede.

Armazenamento do Azure. O armazenamento fornece persistência de dados para uma VM na forma de um disco rígido virtual. Recomendamos os discos gerenciados do Azure.

Recomendações

Essa arquitetura descreve a implantação pequena em nível de produção. As implantações variam de acordo com os requisitos de negócios, portanto, considere essas recomendações como um ponto de partida.

VMs

Em pools e clusters de servidor de aplicativos, ajuste o número de VMs com base nos seus requisitos. Para obter informações detalhadas sobre como executar o SAP NetWeaver em VMs, confira Guia de planejamento e implementação de Máquinas Virtuais do Azure. O guia também se aplica a implantações do SAP S/4HANA.

Para obter detalhes sobre o suporte da SAP para tipos de VM do Azure e métricas de taxa de transferência (SAPS), confira Nota SAP 1928533. Para acessar as notas SAP, você precisa de uma conta do SAP Service Marketplace. Para ver uma lista de VMs do Azure certificadas para o banco de dados HANA, confira o Diretório de Hardware SAP HANA Certificado e Suportado pela SAP.

SAP Web Dispatcher

O componente Web Dispatcher é usado para balanceamento de carga do tráfego da SAP entre os servidores de aplicativos SAP. Para obter a alta disponibilidade do SAP Web Dispatcher, o Azure Load Balancer implementa um cluster de failover ou a configuração paralela do Web Dispatcher. Para comunicações voltadas para a Internet, uma solução autônoma na rede de perímetro é a arquitetura recomendada para atender às questões de segurança. O Web Dispatcher Embedded no ASCS é uma opção especial. Se você usar essa opção, considere o dimensionamento adequado devido à carga de trabalho extra no ASCS.

Servidor front-end (FES) Fiori

Essa arquitetura contempla muitos requisitos e pressupõe que o modelo Fiori FES inserido seja usado. Todos os componentes de tecnologia são instalados no próprio sistema S/4, o que significa que cada sistema S/4 tem o launchpad Fiori. A configuração de alta disponibilidade para esse modelo de implantação é a do sistema S/4. Não há necessidade de clustering nem de VMs adicionais. Por esse motivo, o diagrama de arquitetura não mostra o componente FES.

Para obter uma descrição das principais opções de implantação (inserida ou hub, dependendo dos cenários), confira Opções de implantação do SAP Fiori e recomendações de cenário do sistema. Por questões de simplicidade e desempenho, as versões de software entre os componentes da tecnologia Fiori e os aplicativos S/4 são estreitamente acopladas. Essa configuração faz com que uma implantação de hub seja adequada apenas a alguns raros casos de uso.

Se você usar a implantação do Hub FES, o FES será um componente complementar para a pilha clássica do SAP NetWeaver ABAP. Configure a alta disponibilidade da mesma forma que você protege uma pilha de aplicativos ABAP de três camadas com funcionalidade clusterizada ou de vários hosts: use uma camada de banco de dados de servidor em espera, uma camada ASCS clusterizada com NFS de alta disponibilidade para armazenamento compartilhado e, pelo menos, dois servidores de aplicativos. O tráfego tem a carga balanceada por meio de um par de instâncias do Web Dispatcher que podem ser clusterizadas ou paralelas. Para aplicativos Fiori voltados para a Internet, é recomendável a implantação de um hub FES na rede de perímetro. Use o Firewall de Aplicativo Web do Azure no Gateway de Aplicativo como um componente crítico para desviar ameaças. Use o Microsoft Entra ID com SAML para autenticação de usuário e SSO para SAP Fiori.

Para obter alguns exemplos de design de entrada/saída voltados para a Internet, confira Conexões de Internet de entrada e saída para SAP no Azure.

Pool de servidores de aplicativos

Para gerenciar grupos de logon para servidores de aplicativos ABAP, é comum usar a transação SMLG para balancear a carga de usuários de logon, usar SM61 para grupos de servidores do lote, usar RZ12 para grupos de RFC (Remote Function Call) e assim por diante. Essas transações usam o recurso de balanceamento de carga no servidor de mensagens do Central Services para distribuir sessões de entrada ou cargas de trabalho entre o pool de servidores de aplicativos SAP que manipulam o tráfego de RFC e SAP GUIs.

Cluster do SAP Central Services

Você pode implantar o Central Services em uma única VM quando o SLA (contrato de nível de serviço) de disponibilidade da VM de instância única do Azure atender aos seus requisitos. No entanto, a VM se torna um potencial SPOF (ponto único de falha) para o ambiente SAP. Para uma implantação do Central Services altamente disponível, use ou NFS em Arquivos do Azure, ou o serviço Azure NetApp Files e um cluster do Central Services.

Outra opção é usar Discos compartilhados do Azure para ter alta disponibilidade. No SLES 15 SP1 e posterior ou no SLES para Aplicativos SAP, você pode configurar um cluster do Pacemaker usando os Discos compartilhados do Azure para Linux.

Como alternativa, um compartilhamento de arquivos NFS pode ser usado para o armazenamento compartilhado do cluster do Linux.

Em uma implantação do Azure, os servidores de aplicativos se conectam aos serviços centrais altamente disponíveis por meio dos nomes de host virtual dos Serviços Centrais ou serviços ERSs. Esses nomes de host são atribuídos à configuração de IP de front-end do cluster do balanceador de carga. Um Load Balancer dá suporte a vários IPs de front-end, portanto, o Central Services e os VIPs (IPs virtuais) ERS podem ser configurados para um balanceador de carga.

Agora, o suporte ao cluster do Linux para a instalação de vários SIDs do ASCS no Azure foi disponibilizado para o público geral. O compartilhamento de um cluster de disponibilidade entre vários sistemas SAP simplifica o cenário SAP.

Rede

Essa arquitetura usa uma topologia hub-spoke, em que a rede virtual hub atua como um ponto central de conectividade para uma rede local. Os spokes são redes virtuais emparelhadas com o hub. Você pode usar os spokes para isolar cargas de trabalho. O tráfego flui entre o datacenter local e o hub por meio de uma conexão de gateway.

NICs (adaptadores de interface de rede)

Implantações tradicionais locais da SAP implementam vários NICs por computador para separar o tráfego administrativo do tráfego de negócios. No Azure, a rede virtual é uma rede definida pelo software que envia todo o tráfego pela mesma malha de rede. Portanto, é desnecessário usar vários NICs por questões de desempenho. No entanto, se sua organização precisar separar o tráfego, você poderá implantar várias NICs por VM, conectar cada NIC a uma sub-rede diferente e usar os grupos de segurança de rede para impor diferentes políticas de controle de acesso.

As NICs do Azure dão suporte a vários IPs. Esse suporte se alinha à prática recomendada pela SAP de usar nomes de host virtual para instalações, conforme descrito na nota SAP 962955. Para acessar as notas SAP, você precisa de uma conta do SAP Service Marketplace.

Sub-redes e grupos de segurança de rede

Essa arquitetura divide o espaço de endereço da rede virtual em sub-redes. Você pode associar cada sub-rede a um grupo de segurança de rede que define as políticas de acesso para a sub-rede. Coloque servidores de aplicativo em uma sub-rede separada. Ao fazer isso, você pode protegê-los mais facilmente por meio do gerenciamento das políticas de segurança de sub-rede, em vez dos servidores individuais.

Quando você associa um grupo de segurança de rede a uma sub-rede, o grupo de segurança de rede se aplica a todos os servidores na sub-rede e oferece controle refinado sobre os servidores. Configure grupos de segurança de rede usando o portal do Azure, o PowerShell ou a CLI do Azure.

Alcance Global do ExpressRoute

Se o ambiente de rede incluir dois ou mais circuitos do ExpressRoute, o Alcance Global do ExpressRoute poderá ajudar a reduzir os saltos de rede e diminuir a latência. Essa tecnologia é um emparelhamento de rota BGP (Border Gateway Protocol) configurado entre dois ou mais circuitos do ExpressRoute para unir dois domínios de roteamento do ExpressRoute. O Alcance Global reduz a latência quando o tráfego de rede percorre mais de um circuito do ExpressRoute. No momento, ele está disponível apenas para emparelhamento privado em circuitos do ExpressRoute.

Atualmente, não há listas de controle de acesso à rede ou outros atributos que podem ser alterados no Alcance Global. Portanto, todas as rotas aprendidas por um determinado circuito do ExpressRoute (do local e do Azure) são anunciadas no emparelhamento do circuito com o outro circuito do ExpressRoute. Recomendamos que você estabeleça a filtragem de tráfego de rede local para restringir o acesso aos recursos.

ExpressRoute FastPath

O FastPath implementa as trocas do Microsoft Edge no ponto de entrada da rede do Azure. O FastPath reduz os saltos de rede para a maioria dos pacotes de dados. Consequentemente, o FastPath reduz a latência de rede, aprimora o desempenho do aplicativo e é a configuração padrão para novas conexões do ExpressRoute com o Azure.

Para circuitos existentes do ExpressRoute, entre em contato com suporte do Azure para ativar o FastPath.

O FastPath não dá suporte ao emparelhamento de rede virtual. Se outras redes virtuais estiverem emparelhadas com aquela que está conectada ao ExpressRoute, o tráfego da rede local para outras redes virtuais spoke será enviado para o gateway de rede virtual. A solução alternativa é conectar todas as redes virtuais ao circuito do ExpressRoute diretamente.

Balanceadores de carga

O SAP Web Dispatcher lida com o balanceamento de carga do tráfego HTTP(S) a um pool de servidores de aplicativos SAP. Esse balanceador de carga de software oferece serviços de camada de aplicativo (chamados de camada 7 no modelo de rede ISO) que estão aptos para terminação SSL e outras funções de descarregamento.

O Load Balancer é um serviço de camada de transmissão de rede (camada 4) que faz o balanceamento do tráfego usando um hash de cinco tuplas dos fluxos de dados. O hash se baseia no IP de origem, na porta de origem, no IP de destino, na porta de destino e no tipo de protocolo. O Load Balancer é usado nas configurações de cluster para direcionar o tráfego para a instância de serviço primária ou para o nó íntegro em caso de falha. Recomendamos usar o Azure Standard Load Balancer para todos os cenários do SAP. É importante observar que o Standard Load Balancer é seguro por padrão, e nenhuma VM por trás dele tem conectividade de saída com a Internet. Para habilitar a Internet de saída nas VMs, você deve ajustar a configuração do Standard Load Balancer.

Para o tráfego de clientes do SAP GUI que se conectam a um servidor SAP via protocolo DIAG ou RFC, o servidor de mensagens do Central Services faz o balanceamento da carga por meio de grupos de logon do servidor de aplicativos SAP. Nenhum balanceador de carga extra é necessário.

Armazenamento

Alguns clientes usam o Armazenamento Standard para seus servidores de aplicativos. Como os discos gerenciados padrão não têm suporte, conforme indicado na nota SAP 1928533, é recomendável usar o Azure Managed Disks Premium ou o Azure NetApp Files em todos os casos. Uma atualização recente da nota SAP 2015553 exclui o uso de armazenamento HDD padrão e armazenamento SSD padrão para alguns casos de uso específicos.

Uma vez que os servidores de aplicativos não hospedam dados de negócios, também é possível usar os discos premium menores P4 e P6 para ajudar no gerenciamento de custos. Para entender como o tipo de armazenamento afeta o SLA de disponibilidade da VM, confira SLA para máquinas virtuais. Para cenários de alta disponibilidade, os recursos de Disco compartilhado do Azure estão disponíveis no Armazenamento de Disco Ultra do Azure e no SSD Premium do Azure. Para saber mais, confira Azure Managed Disks.

Você pode usar discos compartilhados do Azure com o Windows Server, SLES 15 SP 1 e posteriores ou SLES para SAP. Quando você usa um disco compartilhado do Azure em clusters Linux, o disco compartilhado do Azure serve como um SBD (dispositivo de blocos STONITH). Ele oferece uma votação de quórum em uma situação de particionamento de rede de cluster. Esse disco compartilhado não tem um sistema de arquivos e não dá suporte a gravações simultâneas de várias VMs membros do cluster.

O Azure NetApp Files tem funcionalidades internas de compartilhamento de arquivos para NFS e SMB.

Para cenários de compartilhamento NFS, o Azure NetApp Files fornece disponibilidade para compartilhamentos NFS que podem ser usados para volumes /hana/shared, /hana/data e /hana/log. Para ver a garantia de disponibilidade, confira SLA do Azure NetApp Files. Se você usar compartilhamentos NFS baseados no Azure NetApp Files para os volumes /hana/data e /hana/log, será preciso usar o protocolo NFS v4.1. Para o volume /hana/shared, há suporte para o protocolo NFS v3.

Para o armazenamento de dados de backup, é recomendável usar as camadas de acesso aos arquivos e esporádico do Azure. Essas camadas de armazenamento são maneiras econômicas para armazenar dados de longa vida útil que são acessados com pouca frequência. Você também pode considerar o uso da camada standard do Azure NetApp Files como um destino de backup ou a opção de backup do Azure NetApp Files. Para um disco gerenciado, a camada de dados de backup recomendada é a camada de acesso esporádico ou de arquivo do Azure.

O Armazenamento de Disco Ultra e a camada de desempenho ultra do Azure NetApp Files reduzem consideravelmente a latência do disco e beneficiam os aplicativos críticos ao desempenho e os servidores de banco de dados SAP.

O SSD Premium v2 do Azure foi projetado para cargas de trabalho críticas de desempenho, como o SAP. Confira Implantar um SSD Premium v2 para obter informações sobre os benefícios dessa solução de armazenamento e suas limitações atuais.

Considerações sobre o desempenho

Os servidores de aplicativos SAP se comunicam constantemente com os servidores de banco de dados. Para aplicativos críticos ao desempenho que são executados em qualquer plataforma de banco de dados, incluindo o SAP HANA, habilite o Acelerador de Gravação para o volume de log se você estiver usando o SSD Premium v1. Isso pode melhorar a latência de gravação de log. O SSD Premium v2 não usa o Acelerador de Gravação. O Acelerador de Gravação está disponível para VMs da série M.

Para otimizar as comunicações entre servidores, use a Rede Acelerada. A maioria dos tamanhos de instância de VM de uso geral e otimizados para computação que têm duas ou mais vCPUs oferece suporte à Rede Acelerada. Em instâncias que suportam hyperthreading, instâncias de VM com quatro ou mais vCPUs dão suporte à Rede Acelerada.

Para obter detalhes sobre os requisitos de desempenho do SAP HANA, confira a nota SAP 1943937 – Ferramenta de verificação de configuração de hardware. Para acessar as notas SAP, você precisa de uma conta do SAP Service Marketplace.

Para obter altas IOPS e taxas de transferências de largura de banda de disco, as práticas comuns na otimização de desempenho do volume de armazenamento se aplicam ao layout de armazenamento. Por exemplo, ao combinar vários discos para criar um volume de disco distribuído, você poderá aprimorar o desempenho de E/S. Ao habilitar o cache de leitura do conteúdo de armazenamento que raramente é alterado, você pode aprimorar a velocidade de recuperação de dados. Para obter recomendações sobre configurações de armazenamento para vários tamanhos de VM ao executar o SAP HANA, confira Configurações de armazenamento de máquina virtual do Azure no SAP HANA.

O SSD Premium v2 do Azure foi projetado para cargas de trabalho críticas de desempenho, como o SAP. Confira Tipos de disco gerenciado do Azure para saber mais sobre seus benefícios, limitações e cenários de uso ideais.

O Armazenamento de Disco Ultra é uma nova geração de armazenamento que atende ao IOPS intensivo e às demandas de largura de banda de transferência de aplicativos como o SAP HANA. Você pode alterar dinamicamente o desempenho de discos ultra e configurar de modo independente métricas como IOPS e MB/s sem reinicializar sua VM. Recomendamos o Armazenamento de Disco Ultra, quando disponível, em vez do Acelerador de Gravação.

Alguns aplicativos SAP exigem comunicação frequente com o banco de dados. A latência de rede entre as camadas do aplicativo e do banco de dados, devido à distância, pode afetar negativamente o desempenho do aplicativo. Os grupos de posicionamento por proximidade do Azure definem uma restrição de posicionamento para VMs implantadas em conjuntos de disponibilidade. Na construção lógica de um grupo, a colocação e o desempenho são favorecidos em relação à escalabilidade, à disponibilidade e ao custo. Os grupos de posicionamento por proximidade podem aprimorar muito a experiência do usuário para a maioria dos aplicativos SAP. Para scripts e utilitários disponíveis no GitHub para grupos de posicionamento de proximidade, confira Grupos de posicionamento por proximidade do Azure.

Não há suporte para o posicionamento de um NVA (dispositivo virtual de rede) entre as camadas de aplicativo e de banco de dados de qualquer pilha de aplicativos SAP. O NVA requer uma quantidade significativa de tempo para processar pacotes de dados. Consequentemente, ele diminui inaceitavelmente o desempenho do aplicativo.

Também recomendamos considerar o desempenho ao implantar recursos com zonas de disponibilidade, o que pode melhorar a disponibilidade do serviço, conforme descrito posteriormente neste artigo. Considere criar um perfil de latência de rede claro entre todas as zonas de uma região de destino. Essa abordagem ajuda você a decidir sobre o posicionamento do recurso para latência mínima entre zonas. Para criar esse perfil, execute um teste implantando pequenas VMs em cada zona. As ferramentas recomendadas para o teste incluem PsPing e Iperf. Após o teste, remova essas VMs. Para obter uma ferramenta de teste de latência de rede de domínio público que você pode usar, confira Teste de latência de zona de disponibilidade.

O Azure NetApp Files tem recursos de desempenho exclusivos que possibilitam ajustes em tempo real que atendem às necessidades dos ambientes SAP mais exigentes. Para ver as considerações de desempenho a serem lembradas ao usar o Azure NetApp Files, confira Dimensionamento do banco de dados HANA no Azure NetApp Files.

Considerações sobre escalabilidade

Na camada de aplicativos SAP, o Azure oferece uma ampla gama de tamanhos de VM para escala horizontal e vertical. Para obter uma lista inclusiva, confira "Aplicativos SAP no Azure: produtos e tipos de VM do Azure com suporte" na nota SAP 1928533. Para acessar as notas SAP, você precisa de uma conta do SAP Service Marketplace. Mais tipos de VM estão sendo continuamente certificados para que você possa ampliar ou reduzir verticalmente na mesma implantação de nuvem.

Na camada de banco de dados, essa arquitetura executa aplicativos SAP HANA S/4 em VMs do Azure que podem escalar verticalmente até 24 terabytes (TB) em uma instância. Se sua carga de trabalho exceder o tamanho máximo da VM, você poderá usar uma configuração de vários nós para até 96 TBs (4 x 24) para aplicativos OLTP (processamento de transações online). Para obter mais informações, confira Diretório de hardware SAP HANA certificado e suportado.

Considerações sobre disponibilidade

A redundância de recursos é o tema geral em soluções de infraestrutura altamente disponíveis. Para SLAs de disponibilidade de VM de instância única para vários tipos de armazenamento, confira SLA para máquinas virtuais. Para aumentar a disponibilidade do serviço no Azure, implante recursos de VM com Conjuntos de Dimensionamento de Máquinas Virtuais com orquestração, zonas de disponibilidade ou conjuntos de disponibilidade flexíveis.

Nessa instalação distribuída do aplicativo SAP, a instalação básica é replicada para obter a alta disponibilidade. O design de alta disponibilidade varia para cada camada da arquitetura.

Abordagens de implantação

No Azure, a implantação da carga de trabalho SAP pode ser regional ou zonal, dependendo dos requisitos de disponibilidade e resiliência dos aplicativos SAP. O Azure fornece diferentes opções de implantação, como Conjuntos de Dimensionamento de Máquinas Virtuais com orquestração (FD=1), zonas de disponibilidade e conjuntos de disponibilidade flexíveis para melhorar a disponibilidade dos recursos. Para obter uma compreensão abrangente das opções de implantação disponíveis e sua aplicabilidade em diferentes regiões do Azure (inclusive entre zonas, em uma única zona ou em uma região sem zonas), confira Arquitetura e cenários de alta disponibilidade para SAP NetWeaver.

Web Dispatcher na camada de servidores de aplicativos

Você pode obter alta disponibilidade usando instâncias redundantes do Web Dispatcher. Para obter mais informações, confira SAP Web Dispatcher na documentação da SAP. O nível de disponibilidade depende do tamanho do aplicativo que está por trás do Web Dispatcher. Em implantações pequenas com poucas questões de escalabilidade, você pode colocalizar o Web Dispatcher com as VMs ASCS. Dessa forma, você economiza na manutenção independente do sistema operacional e ganha alta disponibilidade ao mesmo tempo.

Central Services na camada de servidores de aplicativos

Para alta disponibilidade do Central Services em VMs Linux do Azure, use a extensão de alta disponibilidade apropriada para a distribuição Linux selecionada. É costume colocar os sistemas de arquivos compartilhados em armazenamento NFS altamente disponível usando o SUSE DRBD ou o Red Hat GlusterFS. Para fornecer um NFS altamente disponível e eliminar a necessidade de um cluster NFS, você pode usar outras soluções econômicas ou robustas, como NFS em Arquivos do Azure ou Azure NetApp Files. Apenas como uma observação, os compartilhamentos do Azure NetApp Files podem hospedar os dados e os arquivos de log do SAP HANA. Essa configuração habilita o modelo de implantação de expansão do HANA com nós em espera, enquanto o NFS em Arquivos do Azure é bom para compartilhamento de arquivos que não residem em banco de dados altamente disponível.

O NFS em Arquivos do Azure agora dá suporte aos compartilhamentos de arquivos altamente disponíveis para SLES e RHEL. Essa solução funciona bem para compartilhamentos de arquivos altamente disponíveis, como os do /sapmnt, /saptrans em instalações SAP.

O Azure NetApp Files dá suporte à alta disponibilidade do ASCS no SLES. Para obter informações detalhadas sobre a alta disponibilidade do ASCS no RHEL, confira SIOS Protection Suite para Linux.

O Azure Fence Agent aprimorado está disponível para o SUSE e o Red Hat e fornece failover de serviço significativamente mais rápido que a versão anterior do agente.

Outra opção é usar Discos compartilhados do Azure para ter alta disponibilidade. No SLES 15 SP 1 e posteriores ou no SLES para SAP, você pode configurar um cluster do Pacemaker usando discos compartilhados do Azure para obter alta disponibilidade.

No Azure Standard Load Balancer, você pode habilitar a porta de alta disponibilidade e evitar a necessidade de configurar regras de balanceamento de carga para muitas portas SAP. Em geral, se você habilitar o recurso DSR (retorno de servidor direto) ao configurar um balanceador de carga, as respostas do servidor às consultas do cliente poderão ignorar o balanceador de carga. Esse recurso também é conhecido como IP Flutuante. O balanceador de carga pode ser local ou estar no Azure. Essa conexão direta impede que o balanceador de carga se torne um gargalo no caminho da transmissão de dados. Para o ASCS e os clusters de BD HANA, é recomendável habilitar o DSR. Se as VMs no pool de back-end exigirem conectividade de saída pública, mais configuração será necessária.

Para o tráfego de clientes do SAP GUI que se conectam a um servidor SAP via protocolo DIAG ou RFC, o servidor de mensagens do Central Services faz o balanceamento da carga usando grupos de logon do servidor de aplicativos SAP. Nenhum balanceador de carga extra é necessário.

Servidores de aplicativos na camada de servidores de aplicativos

Você pode obter alta disponibilidade pelo tráfego de balanceamento de carga dentro de um pool de servidores de aplicativos.

Camada ASCS

Assim como na camada de servidores de aplicativos, a solução de alta disponibilidade HANA comumente implantada para Linux é o Pacemaker.

Camada de banco de dados

A arquitetura neste guia descreve um sistema de banco de dados SAP HANA altamente disponível que consiste em duas VMs do Azure. O recurso de replicação de sistema nativo da camada de banco de dados fornece o failover manual ou automático entre nós replicados:

• Para failover manual, implante mais de uma instância do HANA e use a HSR.
• Para failover automático, use a HSR e a HAE (extensão de alta disponibilidade) do Linux para sua distribuição Linux. O HAE Linux fornece os serviços de cluster para os recursos do HANA, detecção de eventos de falha e orquestração do failover de serviços problemáticos para o nó íntegro.

Implantar VMs em zonas de disponibilidade

Zonas de disponibilidade podem aumentar a disponibilidade do serviço. Zonas são locais fisicamente separados em uma região específica do Azure. Eles melhoram a disponibilidade da carga de trabalho e protegem os serviços de aplicativos e VMs contra interrupções de datacenter. As VMs em uma única zona são tratadas como se estivessem em um único domínio de falha ou atualização. Quando a implantação por zona é selecionada, as VMs na mesma zona são distribuídas para domínios de falha e atualização com base no melhor esforço.

Nas regiões do Azure com suporte para esse recurso, pelo menos três zonas estão disponíveis. No entanto, a distância máxima entre datacenters nessas zonas não é garantida. Para implantar um sistema SAP de várias camadas entre zonas, você precisa conhecer a latência de rede dentro de uma zona e entre zonas de destino e o quão sensíveis seus aplicativos implantados são para a latência de rede.

Leve essas considerações em conta ao decidir implantar recursos em zonas de disponibilidade:

• Latência entre VMs em uma zona
• Latência entre VMs em zonas escolhidas
• Disponibilidade dos mesmos serviços do Azure (tipos de VM) nas zonas escolhidas.

Exemplo de implantação ativa/passiva

Neste exemplo de implantação, o status ativo/passivo refere-se ao estado do serviço de aplicativo dentro das zonas. Na camada do aplicativo, os quatro servidores de aplicativos ativos do sistema SAP estão na zona 1. Outro conjunto de quatro servidores de aplicativos passivos é interno na zona 2, mas está desligado. Eles são ativados apenas quando são necessários.

Os clusters de dois nós para os Central Services e o banco de dados são estendidos em duas zonas. Se a zona 1 falhar, o Central Services e os serviços de banco de dados serão executados na zona 2. Os servidores de aplicativos passivos na zona 2 são ativados. Com todos os componentes desse sistema SAP colocalizados na mesma zona, a latência de rede é minimizada.

Exemplo de implantação ativa/ativa

Em uma implantação ativa/ativa, dois conjuntos de servidores de aplicativos são criados em duas zonas. Em cada zona, dois servidores de aplicativos em de cada conjunto ficam inativos, ou desligados. Como resultado, há servidores de aplicativos ativos em ambas as zonas em operações normais.

Os serviços de ASCS e de banco de dados são executados na zona 1. Os servidores de aplicativos na zona 2 podem ter latência de rede mais longa quando se conectarem ao ASCS e aos serviços de banco de dados devido à distância física entre zonas.

Se a zona 1 ficar offline, o ASCS e os serviços de banco de dados farão failover para a zona 2. Os servidores de aplicativos inativos podem ser colocados online para fornecer capacidade total para o processamento de aplicativos.

Considerações de DR

Cada camada na pilha de aplicativos SAP usa uma abordagem diferente para fornecer proteção contra DR. Para obter estratégias de recuperação de desastres e detalhes de implementação, consulte Visão geral de recuperação de desastres e diretrizes de infraestrutura para carga de trabalho SAP e Diretrizes de recuperação de desastres para aplicativos SAP.

Considerações de custo

Use a Calculadora de Preços do Azure para estimar os custos.

Para obter mais informações, confira a seção de custo em Estrutura Bem Projetada do Microsoft Azure.

VMs

Essa arquitetura usa VMs que executam o Linux para as camadas de gerenciamento, aplicativos SAP e banco de dados.

Há várias opções de pagamento para VMs em geral:

• Para cargas de trabalho sem tempo previsível de conclusão ou consumo de recursos, considere a opção de pagamento conforme o uso.

• Considere usar as Reservas do Azure se você puder se comprometer a usar uma VM durante um período de um ou três anos. As reservas de VM podem reduzir significativamente os custos. Você pode pagar apenas 72% do custo de um serviço de pagamento conforme o uso.

• Use VMs spot do Azure para executar cargas de trabalho que podem ser interrompidas e não exigem conclusão em um período predeterminado ou SLA. O Azure implantará VMs spot quando houver capacidade disponível e as evitará quando precisar da capacidade novamente. Os custos associados às VMs spot são menores do que para outras VMs. Considere as VMs spot para estas cargas de trabalho:

  • Cenários de computação de alto desempenho, trabalhos de processamento em lote ou aplicativos de renderização visual.
  • Ambientes de teste, incluindo cargas de trabalho de integração contínua e entrega contínua
  • Aplicativos sem estado em grande escala

• As Instâncias de Máquinas Virtuais Reservadas do Azure podem reduzir seu custo total de propriedade combinando as taxas de Instâncias de Máquinas Virtuais Reservadas do Azure com uma assinatura de pagamento conforme o uso para que você possa gerenciar custos em cargas de trabalho previsíveis e variáveis. Para obter mais informações sobre essa oferta, confira Instâncias de Máquinas Virtuais Reservadas do Azure.

Para obter uma visão geral dos preços, confira Preços de máquinas virtuais Linux.

Load Balancer

Neste cenário, os balanceadores de carga do Azure são usado para distribuir o tráfego para as VMs na sub-rede da camada de aplicativos.

Você é cobrado apenas pelo número de regras de saída e balanceamento de carga configuradas. As regras NAT (conversão de endereços de rede) de entrada são gratuitas. Não há cobrança por hora para o Standard Load Balancer quando nenhuma regra está configurada.

ExpressRoute

Nessa arquitetura, o ExpressRoute é o serviço de rede usado para criar conexões privadas entre uma rede local e redes virtuais do Azure.

Toda a transferência de dados de entrada é gratuita. Toda a transferência de dados de saída é cobrada com base em uma taxa pré-determinada. Para obter mais informações, confira os Preços do Azure ExpressRoute.

Considerações sobre gerenciamento e operações

Para ajudar a manter seu sistema funcionando em produção, considere os pontos a seguir.

Centro do Azure para soluções SAP

O Centro do Azure para soluções SAP é uma solução de ponta a ponta que permite criar e executar sistemas SAP como uma carga de trabalho unificada no Azure e fornece uma base mais direta para inovação. Além disso, a experiência de implantação guiada do Centro do Azure para soluções SAP cria os componentes de computação, armazenamento e rede necessários para executar seu sistema SAP. Em seguida, ela ajuda a automatizar a instalação do software SAP de acordo com as práticas recomendadas da Microsoft. Você pode aproveitar os recursos de gerenciamento para sistemas SAP novos e existentes baseados no Azure. Para obter mais informações, confira Centro do Azure para soluções SAP.

Backup

É possível fazer backup dos dados do SAP HANA de diversas maneiras. Após a migração para o Azure, continue usando as soluções de backup que você já tem. O Azure fornece duas abordagens nativas para backup. Você pode fazer backup do SAP HANA em VMs ou usar o Backup do Azure no nível do arquivo. O Backup do Azure tem certificação BackInt pela SAP. Para obter mais informações, confira Perguntas frequentes sobre o Backup do Azure e Matriz de suporte para backup de bancos de dados SAP HANA em VMs do Azure.

Gerenciamento de identidades

Use um sistema de gerenciamento de identidade centralizado para controlar o acesso a recursos em todos os níveis:

• Forneça acesso aos recursos do Azure por meio do RBAC (controle de acesso baseado em função) do Azure.

• Conceda acesso a VMs do Azure por meio do protocolo LDAP, Microsoft Entra ID, Kerberos ou outro sistema.

• Ofereça suporte ao acesso de dentro dos próprios aplicativos por meio dos serviços fornecidos pela SAP ou use o OAuth 2.0 e o Microsoft Entra ID.

Monitoramento

Para maximizar a disponibilidade e o desempenho de aplicativos e serviços no Azure, use o Azure Monitor, uma solução abrangente para coletar e analisar a telemetria dos ambientes locais e de nuvem e para agir com base nela. O Azure Monitor mostra o desempenho de seus aplicativos, além de identificar de maneira proativa os problemas que os afetam e os recursos dos quais eles dependem. Para aplicativos SAP executados no SAP HANA e em outras soluções de banco de dados importantes, confira Azure Monitor para soluções SAP para saber como o Azure Monitor para SAP pode ajudar a gerenciar a disponibilidade e o desempenho dos serviços SAP.

Considerações de segurança

O SAP tem o próprio UME (mecanismo de gerenciamento de usuários) para controlar o acesso e a autorização baseados em função no aplicativo e nos bancos de dados SAP. Para obter detalhes, consulte Segurança do SAP HANA - Uma visão geral.

Para melhorar a segurança da rede, considere usar uma rede de perímetro com um NVA para criar um firewall na frente da sub-rede do Web Dispatcher e dos pools de servidores front-end Fiori. O custo da transferência de dados é um motivo para colocar servidores front-end ativos que executam aplicativos Fiori na mesma rede virtual que os sistemas S/4. A alternativa é colocá-los na rede de perímetro e conectá-los ao S/4 por meio de um emparelhamento de rede virtual.

Para a segurança da infraestrutura, os dados são criptografados em trânsito e em repouso. A seção "Considerações sobre segurança" do SAP NetWeaver nas máquinas virtuais do Azure – Guia de planejamento e implementação contém informações sobre a segurança de rede que se aplica ao S/4HANA. Esse guia também especifica as portas de rede para abrir nos firewalls a fim de permitir a comunicação do aplicativo.

Para criptografar discos de VM Linux, você tem várias opções, conforme descrito na Visão geral da criptografia de disco. Para criptografia de dados em repouso do SAP HANA, é recomendável usar a tecnologia de criptografia nativa do SAP HANA. Para obter suporte da criptografia de disco do Azure em distribuições, versões e imagens específicas do Linux, confira Criptografia de disco do Azure para VMs Linux.

Para criptografia de dados em repouso do SAP HANA, é recomendável usar a tecnologia de criptografia nativa do SAP HANA.

Comunidades

As comunidades podem responder a perguntas e ajudar você a configurar uma implantação bem-sucedida. Considere estes recursos:

• Como executar aplicativos SAP no blog Microsoft Platform
• Suporte da comunidade do Azure
• Comunidade do SAP
• Stack Overflow SAP

Colaboradores

Esse artigo é mantido pela Microsoft. Ele foi escrito originalmente pelos colaboradores a seguir.

Autor principal:

• Ben Trinh | Arquiteto Principal

Para ver perfis não públicos do LinkedIn, entre no LinkedIn.

Próximas etapas

Para obter mais informações e exemplos de cargas de trabalho SAP que usam algumas das mesmas tecnologias que essa arquitetura, confira estes artigos:

• Implantar o SAP S/4HANA ou o BW/4HANA no Azure
• Planejamento e implementação de Máquinas Virtuais do Azure para SAP NetWeaver
• Usar o Azure para hospedar e executar cenários de carga de trabalho do SAP

Recursos relacionados

• Executar cargas de trabalho de produção do SAP usando um Oracle Database no Azure