SAP S/4HANA em Linux no Azure

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

Arquitetura

Transfira um ficheiro do Visio desta arquitetura.

Este guia descreve um sistema de produção comum. Essa arquitetura é implantada com tamanhos de máquina virtual (VM) que você pode alterar para acomodar as necessidades da sua organização. Para atender às suas necessidades de negócios, você pode reduzir essa configuração a uma única VM.

Neste guia, o layout da rede é muito simplificado para demonstrar os princípios da arquitetura. Não se destina a descrever uma rede empresarial completa.

A arquitetura usa os seguintes componentes. Alguns serviços partilhados 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 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 que são emparelhadas juntas. Essa topologia oferece segmentação e isolamento de rede para serviços implantados no Azure. O emparelhamento conecta redes de forma transparente através da rede de backbone da Microsoft e não incorre em uma penalidade 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 para serviços compartilhados, como a caixa de salto e o Ative Directory do Windows Server.

VMs. Essa arquitetura usa VMs que executam o 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 front-end Fiori, o pool SAP Web Dispatcher, o pool de servidores de aplicativos e o cluster SAP Central Services. Para alta disponibilidade dos Serviços Centrais no Azure em execução em 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, Arquivos NetApp do Azure, servidores NFS (Network File System) clusterizados ou SIOS Protection Suite para Linux. Para configurar um compartilhamento de arquivos altamente disponível para o cluster de Serviços Centrais 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 for SAP Applications, você pode usar discos compartilhados do Azure em um cluster 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 em expansão. A replicação do sistema HANA (HSR) é usada para replicar o conteúdo entre sistemas HANA primários e secundários. O cluster Linux é usado para detetar falhas do sistema e facilitar o failover automático. Um mecanismo de vedação 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 divisão cerebral do cluster. Nas implantações em expansão do HANA, você pode obter alta disponibilidade do banco de dados usando uma das seguintes opções:

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

• Azure Bastion. Esse serviço permite que você se conecte a uma máquina virtual usando seu navegador e o portal do Azure ou por meio do cliente SSH ou RDP nativo 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ê usar outras ferramentas de gerenciamento, como o SQL Server Management Studio ou um front-end SAP, use uma caixa de salto tradicional autoimplantada.

Serviço de DNS privado. O DNS Privado do Azure fornece um serviço DNS confiável e seguro para sua rede virtual. O DNS Privado do Azure gerencia e resolve nomes de domínio na 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 aplicativo SAP para alta disponibilidade, recomendamos que você use o Balanceador de Carga Padrão do Azure. 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 Balanceador de Carga Padrão. Você também pode usar o Gateway 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 a sua seleção em:

• Seu tipo de tráfego, como HTTP ou SAP GUI.
• Os serviços de rede de que necessita, como a terminação SSL (Secure Sockets Layer).

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

• Programação Avançada de Aplicações Empresariais (ABAP) SAP Central Service (ASCS)
• Enqueue Replication Server (ERS)

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

O Standard Load Balancer também suporta clusters SAP de identificador multissistema (multi-SID). Em outras palavras, vários sistemas SAP no SLES ou RHEL podem compartilhar uma infraestrutura comum de alta disponibilidade para reduzir custos. Recomendamos que você avalie a economia de custos e evite colocar muitos sistemas em um cluster. O Azure não suporta 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 você pode usar para gerenciar o 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 de origem e na porta para um endereço IP e uma porta de destino. O Application Gateway pode tomar decisões de roteamento com base em atributos adicionais de uma solicitação HTTP, como o caminho do URI ou cabeçalhos de host. Este tipo de encaminhamento é conhecido como balanceamento de carga da camada de aplicação (camada OSI 7). O S/4HANA oferece serviços de aplicação web através do Fiori. Você pode balancear a carga desse front-end Fiori, que consiste em aplicativos Web, usando o Application Gateway.

Gateway. Um gateway conecta redes distintas e estende sua rede local a 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 ExpressRoute Global Reach e o ExpressRoute FastPath são opções de conectividade discutidas mais adiante neste artigo.

Gateway redundante de zona. Você pode implantar gateways de Rota Expressa ou VPN (rede virtual privada) entre zonas para se proteger 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 zonal baseada na mesma zona de disponibilidade.

Grupo de colocação de proximidade. Esse grupo lógico impõe uma restrição às VMs implantadas em um conjunto de disponibilidade ou em um conjunto de dimensionamento de máquina virtual. Um grupo de posicionamento de 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 intra-sub-rede em uma rede virtual, você pode criar grupos de segurança de rede.

Grupos de segurança de aplicativos. Para definir políticas de segurança de rede refinadas baseadas em cargas de trabalho e centradas em aplicativos, use grupos de segurança de aplicativos 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 uma pequena implantação 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 de servidores de aplicativos e clusters, ajuste o número de VMs com base em suas necessidades. Para obter informações detalhadas sobre como executar o SAP NetWeaver em VMs, consulte o 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 SAP para tipos de VM do Azure e para métricas de taxa de transferência (SAPS), consulte SAP Note 1928533. Para acessar as notas SAP, você precisa de uma conta do SAP Service Marketplace. Para obter uma lista de VMs do Azure certificadas para o banco de dados HANA, consulte SAP Certified and Supported SAP HANA Hardware Directory.

SAP Web Dispatcher

O componente Web Dispatcher é usado para balancear a carga do tráfego SAP entre os servidores de aplicativos SAP. Para obter 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 satisfazer as preocupações de segurança. O Embedded Web Dispatcher 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 Fiori (FES)

Essa arquitetura atende a muitos requisitos e pressupõe que o modelo Fiori FES incorporado seja usado. Todos os componentes da tecnologia são instalados no próprio sistema S/4, o que significa que cada sistema S/4 tem sua própria plataforma de lançamento Fiori. A configuração de alta disponibilidade para esse modelo de implantação é a do sistema S/4 — não são necessários clusters ou VMs extras. 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 — incorporadas ou concentradas, dependendo dos cenários — consulte Opções de implantação do SAP Fiori e recomendações do cenário do sistema. Para simplicidade e desempenho, as versões de software entre os componentes da tecnologia Fiori e os aplicativos S/4 estão intimamente acopladas. Essa configuração cria uma implantação de hub que se adapta apenas a alguns casos de uso restritos.

Se você usar a implantação do hub FES, o FES será um componente complementar à pilha ABAP clássica do SAP NetWeaver. Configure a alta disponibilidade da mesma forma que protege uma pilha de aplicativos ABAP de três camadas com capacidade de clusterização ou multihost: 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 é balanceado por meio de um par de instâncias do Web Dispatcher que podem ser agrupadas ou paralelas. Para aplicativos Fiori voltados para a Internet, recomendamos uma implantação de 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, consulte Conexões de entrada e saída da Internet 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 em lote, usar RZ12 para grupos de chamada de função remota (RFC) e assim por diante. Essas transações usam o recurso de balanceamento de carga que está no servidor de mensagens dos Serviços Centrais para distribuir sessões de entrada ou cargas de trabalho entre o pool de servidores de aplicativos SAP que lidam com GUIs SAP e tráfego RFC.

Cluster SAP Central Services

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

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

Como alternativa, você pode usar um compartilhamento de arquivos NFS para o armazenamento compartilhado do cluster 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 ERS. Esses nomes de host são atribuídos à configuração IP front-end do cluster do balanceador de carga. O Load Balancer suporta vários IPs frontend, portanto, os Serviços Centrais e os IPs virtuais (VIPs) do ERS podem ser configurados para um balanceador de carga.

O suporte de cluster Linux para instalação multi-SID ASCS no Azure agora está disponível ao público em 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, onde a rede virtual do hub atua como um ponto central de conectividade com uma rede local. Os porta-vozes são redes virtuais que fazem par com o hub. Você pode usar os raios para isolar cargas de trabalho. O tráfego flui entre o datacenter local e o hub por meio de uma conexão de gateway.

Placas de interface de rede (NICs)

As implantações SAP locais tradicionais implementam várias NICs por máquina para segregar o tráfego administrativo do tráfego comercial. No Azure, a rede virtual é uma rede definida por software que envia todo o tráfego através da mesma malha de rede. Portanto, o uso de várias NICs é desnecessário para considerações de desempenho. No entanto, se sua organização precisar segregar o tráfego, você poderá implantar várias NICs por VM, conectar cada NIC a uma sub-rede diferente e usar 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 está alinhado com a prática recomendada pela SAP de usar nomes de host virtual para instalações, conforme descrito na nota 962955 da SAP. 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çamento 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 os servidores de aplicativos em uma sub-rede separada. Ao fazer isso, você pode protegê-los mais facilmente gerenciando as políticas de segurança da 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 dentro da 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 seu ambiente de rede incluir dois ou mais circuitos de Rota Expressa, o Alcance Global da Rota Expressa pode ajudá-lo a reduzir os saltos de rede e diminuir a latência. Essa tecnologia é um emparelhamento de rotas BGP (Border Gateway Protocol) configurado entre dois ou mais circuitos de Rota Expressa para fazer a ponte entre dois domínios de roteamento de Rota Expressa. O alcance global reduz a latência quando o tráfego de rede atravessa mais de um circuito de Rota Expressa. Atualmente, está disponível apenas para emparelhamento privado em circuitos de Rota Expressa.

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

ExpressRoute FastPath

O FastPath implementa 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. Como resultado, o FastPath reduz a latência da rede, melhora o desempenho do aplicativo e é a configuração padrão para novas conexões de Rota Expressa com o Azure.

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

O FastPath não oferece suporte ao emparelhamento de rede virtual. Se outras redes virtuais estiverem emparelhadas com uma conectada à Rota Expressa, o tráfego de rede da sua rede local para as outras redes virtuais spoke será enviado para o gateway de rede virtual. A solução alternativa é conectar todas as redes virtuais ao circuito ExpressRoute diretamente.

Balanceadores de carga

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

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

Para o tráfego de clientes SAP GUI que se conectam a um servidor SAP por meio do protocolo DIAG ou RFC, o servidor de mensagens dos Serviços Centrais equilibra a carga por meio de grupos de logon do servidor de aplicativos SAP. Nenhum balanceador de carga extra é necessário.

Armazenamento

Alguns clientes usam armazenamento padrão para seus servidores de aplicativos. Como não há suporte para discos gerenciados padrão, conforme indicado na nota 1928533 da SAP, recomendamos o uso de discos gerenciados premium do Azure ou Arquivos NetApp do Azure em todos os casos. Uma atualização recente do SAP observa 2015553 exclui o uso de armazenamento HDD padrão e armazenamento SSD padrão para alguns casos de uso específicos.

Como os servidores de aplicativos não hospedam dados corporativos, você também pode usar os discos premium P4 e P6 menores para ajudar a gerenciar custos. Para entender como o tipo de armazenamento afeta o SLA de disponibilidade da VM, consulte SLA para máquinas virtuais. Para cenários de alta disponibilidade, os recursos de disco compartilhado do Azure estão disponíveis no SSD Premium do Azure e no Armazenamento de Disco Ultra do Azure. Para obter mais informações, consulte Discos gerenciados do Azure.

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

Os Arquivos NetApp do Azure têm funcionalidades internas de compartilhamento de arquivos para NFS e SMB.

Para cenários de compartilhamento NFS, os Arquivos NetApp do Azure fornecem disponibilidade para compartilhamentos NFS que podem ser usados para /hana/shared, /hana/datae /hana/log volumes. Para obter a garantia de disponibilidade, consulte SLA para arquivos NetApp do Azure. Se você usar compartilhamentos NFS baseados em Arquivos NetApp do Azure para os /hana/data volumes e /hana/log , precisará usar o protocolo NFS v4.1. Para o /hana/shared volume, o protocolo NFS v3 é suportado.

Para o armazenamento de dados de backup, recomendamos que você use as camadas de acesso legal e arquivado do Azure. Esses níveis de armazenamento são maneiras econômicas de armazenar dados de longa duração que são acessados com pouca frequência. Você também pode considerar o uso da camada padrão 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 legal ou de arquivamento do Azure.

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

O SSD Premium do Azure v2 foi projetado para cargas de trabalho críticas de desempenho, como o SAP. Consulte 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 de desempenho

Os servidores de aplicativos SAP se comunicam constantemente com os servidores de banco de dados. Para aplicativos de desempenho crítico executados em qualquer plataforma de banco de dados, incluindo SAP HANA, habilite o Acelerador de Gravação para o volume de log se estiver usando o SSD Premium v1. Isso pode melhorar a latência de gravação de log. 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 oferecem suporte à Rede Acelerada. Em instâncias que suportam hyperthreading, as instâncias de VM com quatro ou mais vCPUs suportam Rede Acelerada.

Para obter detalhes sobre os requisitos de desempenho do SAP HANA, consulte SAP note 1943937 - Hardware Configuration Check Tool. Para acessar as notas SAP, você precisa de uma conta do SAP Service Marketplace.

Para obter alta taxa de transferência de IOPS e largura de banda de disco, as práticas comuns na otimização do desempenho do volume de armazenamento se aplicam ao layout de armazenamento. Por exemplo, se você combinar vários discos para criar um volume de disco distribuído, poderá melhorar o desempenho de E/S. Ao habilitar o cache de leitura no conteúdo de armazenamento que muda com pouca frequência, você pode aumentar 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, consulte Configurações de armazenamento de máquina virtual do SAP HANA Azure.

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

O Ultra Disk Storage é uma nova geração de armazenamento que atende às intensas IOPS 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 métricas de forma independente como IOPS e MB/s sem reinicializar sua VM. Quando o Ultra Disk Storage estiver disponível, recomendamos o Ultra Disk Storage em vez do Write Accelerator.

Algumas aplicações SAP requerem uma comunicação frequente com a base 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 de proximidade do Azure definem uma restrição de posicionamento para VMs implantadas em conjuntos de disponibilidade. Dentro da construção lógica de um grupo, a colocalização e o desempenho são favorecidos em relação à escalabilidade, disponibilidade e custo. Os grupos de posicionamento de proximidade podem melhorar 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, consulte Grupos de posicionamento de proximidade do Azure.

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

Também recomendamos que você considere o desempenho ao implantar recursos com zonas de disponibilidade, o que pode melhorar a disponibilidade do serviço, conforme descrito mais adiante neste artigo. Considere a criação de um perfil claro de latência de rede 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, consulte Teste de latência da zona de disponibilidade.

Os Arquivos NetApp do Azure têm recursos de desempenho exclusivos que possibilitam o ajuste em tempo real que atende às necessidades dos ambientes SAP mais exigentes. Para obter considerações de desempenho a ter em mente ao usar arquivos NetApp do Azure, consulte Dimensionamento para banco de dados HANA em arquivos NetApp do Azure.

Considerações de escalabilidade

Na camada de aplicativos SAP, o Azure oferece uma ampla variedade de tamanhos de VM para escalonamento e expansão. Para obter uma lista inclusiva, consulte "Aplicativos SAP no Azure: produtos suportados e tipos de VM do Azure" no SAP Note 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 aumentar ou diminuir a escala 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 ser dimensionadas 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, consulte Diretório de hardware SAP HANA certificado e suportado.

Considerações de 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, consulte SLA para máquinas virtuais. Para aumentar a disponibilidade do serviço no Azure, implante recursos de VM com Conjuntos de Dimensionamento de Máquina Virtual com orquestração flexível, zonas de disponibilidade ou conjuntos de disponibilidade.

Nesta instalação distribuída do aplicativo SAP, a instalação base é replicada para obter alta disponibilidade. Para cada camada da arquitetura, o design de alta disponibilidade varia.

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áquina Virtual com orquestração flexível (FD=1), zonas de disponibilidade e conjuntos de disponibilidade, 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 (incluindo entre zonas, dentro de uma única zona ou em uma região sem zonas), consulte 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, consulte SAP Web Dispatcher na documentação do 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 preocupaçõ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.

Serviços Centrais na camada de servidores de aplicativos

Para alta disponibilidade dos Serviços Centrais em VMs Linux do Azure, use a extensão de alta disponibilidade apropriada para a distribuição Linux selecionada. É comum 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 sobre Arquivos do Azure ou Arquivos NetApp do Azure. Como observação lateral, os compartilhamentos do Azure NetApp Files podem hospedar os arquivos de log e dados do SAP HANA. Essa configuração habilita o modelo de implantação em expansão do HANA com nós em espera, enquanto o NFS sobre Arquivos do Azure é bom para compartilhamento de arquivos não banco de dados altamente disponível.

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

Os Arquivos NetApp do Azure dão suporte à alta disponibilidade de ASCS no SLES. Para obter informações detalhadas sobre o ASCS na alta disponibilidade do RHEL, consulte SIOS Protection Suite for Linux.

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

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

No Balanceador de Carga Padrão do Azure, 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 de retorno direto do servidor (DSR) 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 no Azure. Essa conexão direta evita que o balanceador de carga se torne o gargalo no caminho de transmissão de dados. Para os clusters de banco de dados ASCS e HANA, recomendamos que você habilite 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 SAP GUI que se conectam a um servidor SAP via protocolo DIAG ou RFC, o servidor de mensagens dos Serviços Centrais equilibra a 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 equilibrando a carga do tráfego dentro de um pool de servidores de aplicativos.

Nível ASCS

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

Camada de base 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 do sistema nativo da camada de banco de dados fornece failover manual ou automático entre nós replicados:

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

Implantar VMs em zonas de disponibilidade

As zonas de disponibilidade podem melhorar a disponibilidade do serviço. As zonas referem-se a locais fisicamente separados dentro de 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 do datacenter. As VMs em uma única zona são tratadas como se estivessem em um único domínio de atualização ou falha. Quando a implantação zonal é 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 que dão suporte a 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ê deve conhecer a latência da rede dentro de uma zona e entre as zonas de destino, e quão sensíveis seus aplicativos implantados são à latência da rede.

Leve estas considerações em consideração 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 do aplicativo dentro das zonas. Na camada de aplicativos, todos os quatro servidores de aplicativos ativos do sistema SAP estão na zona 1. Outro conjunto de quatro servidores de aplicativos passivos é construído na zona 2, mas é desligado. Eles são ativados apenas quando são necessários.

Os clusters de dois nós para os Serviços Centrais e o banco de dados são estendidos em duas zonas. Se a zona 1 falhar, os Serviços Centrais 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 deste sistema SAP colocalizados na mesma zona, a latência da 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 cada conjunto estão inativos ou desligados. Como resultado, há servidores de aplicativos ativos em ambas as zonas em operações normais.

O ASCS e os serviços de banco de dados são executados na zona 1. Os servidores de aplicativos na zona 2 podem ter maior latência de rede quando se conectam ao ASCS e aos serviços de banco de dados devido à distância física entre as 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 on-line para fornecer capacidade total de processamento de aplicativos.

Considerações sobre DR

Cada camada na pilha de aplicativos SAP usa uma abordagem diferente para fornecer proteção contra DR. Para obter estratégias de DR 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 custos

Utilize a calculadora de preços do Azure para prever os custos.

Para obter mais informações, veja a secção de custos Well-Architected Framework do Microsoft Azure.

VMs

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

Existem 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 pré-pago.

• Use VMs spot do Azure para executar cargas de trabalho que podem ser interrompidas e não exigem conclusão dentro de um período de tempo ou SLA predeterminado. O Azure implanta VMs spot quando há capacidade disponível e as remove quando precisa da capacidade de volta. Os custos associados a VMs spot são menores do que para outras VMs. Considere 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 integração contínua e cargas de trabalho de entrega contínua
  • Aplicações sem estado de grande escala

• As Instâncias de Máquina Virtual Reservadas do Azure podem reduzir o custo total de propriedade combinando as taxas das Instâncias de Máquina Virtual Reservadas do Azure com uma assinatura paga 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, consulte Instâncias de máquina virtual reservadas do Azure.

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

Balanceador de Carga

Nesse cenário, os balanceadores de carga do Azure são usados para distribuir tráfego para VMs na sub-rede da camada de aplicativo.

Você será cobrado apenas pelo número de regras de balanceamento de carga e saída configuradas. As regras de 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, a Rota Expressa é o serviço de rede usado para criar conexões privadas entre uma rede local e as 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, consulte Preços do Azure ExpressRoute.

Considerações sobre gerenciamento e operações

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

Azure Center for SAP solutions

O Azure Center for SAP solutions é uma solução ponto a ponto que permite criar e executar sistemas SAP como uma carga de trabalho unificada no Azure e proporciona uma base mais integrada de 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, ele ajuda a automatizar a instalação do software SAP de acordo com as práticas recomendadas da Microsoft. Pode tirar partido das capacidades de gestão para sistemas SAP novos e existentes do Azure. Para obter mais informações, consulte Central do Azure para soluções SAP.

Backup

Você pode fazer backup de dados do SAP HANA de várias maneiras. Depois de migrar para o Azure, continue usando todas as soluções de backup existentes que você tenha. 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 é certificado BackInt pela SAP. Para obter mais informações, consulte Perguntas frequentes sobre o Backup do Azure e Matriz de suporte para backup de bancos de dados SAP HANA em VMs do Azure.

Gestão de identidades

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

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

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

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

Monitorização

Para maximizar a disponibilidade e o desempenho de aplicativos e serviços no Azure, use o Azure Monitor, uma solução abrangente para coletar, analisar e agir em telemetria de seus ambientes locais e de nuvem. O Azure Monitor mostra o desempenho dos aplicativos e identifica proativamente os problemas que os afetam e os recursos dos quais dependem. Para aplicativos SAP executados no SAP HANA e em outras soluções de banco de dados importantes, consulte Azure Monitor for SAP solutions para saber como o Azure Monitor for SAP pode ajudá-lo a gerenciar a disponibilidade e o desempenho dos serviços SAP.

Considerações de segurança

A SAP tem seu próprio mecanismo de gerenciamento de usuários (UME) para controlar o acesso e a autorização baseados em funções dentro do aplicativo e 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 o uso de uma rede de perímetro que use um NVA para criar um firewall na frente da sub-rede para o Web Dispatcher e os pools de servidores front-end Fiori. O custo da transferência de dados é uma razão 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 através de um emparelhamento de rede virtual.

Para segurança da infraestrutura, os dados são criptografados em trânsito e em repouso. A seção "Considerações de segurança" do SAP NetWeaver on Azure Virtual Machines – Guia de Planejamento e Implementação contém informações sobre segurança de rede que se aplicam ao S/4HANA. Esse guia também especifica as portas de rede a serem abertas nos firewalls para permitir a comunicação do aplicativo.

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

Para criptografia de dados em repouso do SAP HANA, recomendamos o uso da tecnologia de criptografia nativa do SAP HANA.

Comunidades

As comunidades podem responder às suas perguntas e ajudá-lo a configurar uma implementação com êxito. Considere estes recursos:

• Executando aplicativos SAP no blog da plataforma Microsoft
• Suporte da Comunidade do Azure
• Comunidade SAP
• SAP de estouro de pilha

Contribuidores

Este artigo é mantido pela Microsoft. Foi originalmente escrito pelo seguinte colaborador.

Autor principal:

• Ben Trinh - Brasil | Arquiteto Principal

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

Próximos passos

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

• Implantar o SAP S/4HANA ou 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 SAP

Recursos relacionados

• Executar cargas de trabalho de produção SAP usando um banco de dados Oracle no Azure