SAP S/4HANA no Linux no Azure

Este guia apresenta um conjunto de práticas comprovadas para executar o S/4HANA e o Suite no HANA em um ambiente de alta disponibilidade que oferece suporte à recuperação de desastres (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. Essa arquitetura é implantada com tamanhos de máquina virtual (VM) que você pode alterar para acomodar as necessidades de 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 de rede é bastante simplificado para demonstrar princípios arquitetônicos. Ele não se destina a descrever uma rede corporativa completa.

A arquitetura usa os seguintes componentes. 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 uns aos outros. 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 emparelhadas. Essa topologia oferece segmentação e isolamento de rede para serviços implantados no Azure. O emparelhamento conecta redes de forma transparente por meio da rede de backbone da Microsoft e não incorre em 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 Active 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 de arquitetura inclui o pool de servidores 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 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 dos 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 no SLES for SAP Applications, 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 do sistema HANA (HSR) é usada para replicar conteúdo entre sistemas HANA primários e secundários. O clustering do Linux é usado para detectar falhas de 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 cérebro dividido 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 os nós de espera do HANA usando os Arquivos do Azure NetApp sem o componente de cluster do Linux.
  • Dimensione sem nós de espera usando o armazenamento premium do Azure. Use o cluster Linux para failover.

• Bastião do Azure. 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 no computador local. Se apenas RDP e SSH forem usados para administração, o Bastião do Azure 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 autoimplantada tradicional.

Serviço 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 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 aplicativo SAP para alta disponibilidade, recomendamos que você use 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 atrá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 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.
• Os serviços de rede necessários, como a terminação SSL (Secure Sockets Layer).

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

• Programação Avançada de Aplicativos de Negócios (ABAP) SAP Central Service (ASCS)
• 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 oferece 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 reduzir custos. Recomendamos que você avalie a economia de custos e evite 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 você pode usar para gerenciar o tráfego para seus aplicativos Web. Os balanceadores de carga tradicionais operam na camada de transporte (camada 4 OSI - 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 Gateway de Aplicativo 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. Esse tipo de roteamento é conhecido como balanceamento de carga da camada de aplicativo (camada OSI 7). O S/4HANA oferece serviços de aplicação web através da 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 para uma rede virtual do Azure. O Azure ExpressRoute é o serviço recomendado do Azure 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 posteriormente neste artigo.

Gateway com redundância de zona. Você pode implantar gateways de Rota Expressa ou VPN (rede virtual privada) em 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 posicionamento por proximidade. Esse grupo lógico coloca uma restrição em VMs que são implantadas em um conjunto de disponibilidade ou em um conjunto de dimensionamento de máquina virtual. Um grupo de posicionamento de proximidade favorece a co-localizaçã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-rede em uma rede virtual, você pode criar grupos de segurança de rede.

Grupos de segurança do aplicativo. Para definir diretivas 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 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 servidores de aplicativos, ajuste o número de VMs com base em seus requisitos. Para obter informações detalhadas sobre como executar o SAP NetWeaver em VMs, consulte 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 do SAP, você precisa de uma conta do SAP Service Marketplace. Para obter uma lista de VMs certificadas do Azure para o banco de dados HANA, consulte SAP Certified and Supported SAP HANA Hardware Directory.

SAP Web Dispatcher

O componente Web Dispatcher é usado para balanceamento de carga de 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 atender às preocupaçõ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 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 clustering 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 de hub, dependendo dos cenários — consulte Opções de implantação do SAP Fiori e recomendações de cenário do sistema. Para simplicidade e desempenho, as versões de software entre os componentes da tecnologia Fiori e os aplicativos S/4 são firmemente acopladas. Essa configuração faz uma implantação de hub que se encaixa apenas em alguns casos de uso estreitos.

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 que tenha capacidade de cluster 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 de carga por meio de um par de instâncias do Web Dispatcher que podem ser clusterizadas ou paralelas. Para aplicativos Fiori voltados para a Internet, recomendamos 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, consulte 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 em lote, usar RZ12 para grupos de RFC (chamada de função remota) 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 do 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 SPOF (Single Point of Failure, ponto único de falha) para o ambiente SAP. Para uma implantação de Serviços Centrais altamente disponível, use o 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 do 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 ERSs. Esses nomes de host são atribuídos à configuração de IP de front-end do cluster do balanceador de carga. O Load Balancer oferece suporte a vários IPs de front-end, 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 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 de hub atua como um ponto central de conectividade com uma rede local. Os spokes são redes virtuais emparelhadas 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.

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 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 diretivas de controle de acesso diferentes.

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 962955 da SAP. Para acessar as notas do 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 de 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 gerenciando as diretivas 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 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 ExpressRoute Global Reach poderá ajudá-lo a reduzir os saltos de rede e a reduzir a latência. Essa tecnologia é um emparelhamento de rota 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 da Rota Expressa. No momento, ele está disponível apenas para emparelhamento privado em circuitos do ExpressRoute.

No momento, não há listas de controle de acesso à rede ou outros atributos que possam 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 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 da Rota Expressa 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 uma conectada à Rota Expressa, o tráfego de rede da rede local para as outras redes virtuais faladas 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. Este balanceador de carga de software oferece serviços de camada de aplicativo (conhecidos como camada 7 no modelo de rede ISO) que são capazes de 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 equilibra o tráfego usando um hash de cinco tuplas de fluxos de dados. O hash é baseado 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 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 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 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 Standard Load Balancer .

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 o Armazenamento Standard 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 da nota SAP 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 em 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. Esse disco compartilhado não tem um sistema de arquivos e não oferece 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 /hana/sharedvolumes /hana/datae /hana/log , . 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 de arquivamento 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 desempenho ultra do Azure NetApp Files reduzem consideravelmente a latência do disco e beneficiam os aplicativos críticos de 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. 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 sobre o desempenho

Os servidores de aplicativos SAP se comunicam constantemente com os servidores de banco de dados. Para aplicativos críticos de desempenho que são executados em qualquer plataforma de banco de dados, incluindo o SAP HANA, habilite o Write Accelerator 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 oferecem 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, consulte SAP note 1943937 - Hardware Configuration Check Tool. Para acessar as notas do 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 de 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 em 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 v2 do Azure 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 demandas intensivas de IOPS e 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 independentemente 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.

Alguns aplicativos SAP exigem comunicação frequente com o banco de dados. A latência de rede entre as camadas de aplicativo e 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 co-localizaçã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 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, consulte Teste de latência de zona de disponibilidade.

O Azure NetApp Files tem 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 serem consideradas ao usar os Arquivos do Azure NetApp, consulte Dimensionamento do banco de dados do HANA em Arquivos do Azure NetApp.

Considerações sobre escalabilidade

Na camada de aplicativos SAP, o Azure oferece uma ampla variedade de tamanhos de VM para expansão e expansão. Para obter uma lista inclusiva, consulte "Aplicativos SAP no Azure: produtos com suporte e tipos de VM do Azure" na Nota 1928533 do SAP. Para acessar as notas do 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 compatível.

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, 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.

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áquina Virtual com orquestração flexível (FD=1), zonas de disponibilidade e conjuntos de disponibilidade, para aprimorar 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), 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.

Central Services 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. É 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 sobre Arquivos do Azure ou Arquivos do Azure NetApp. Como uma observação lateral, 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 em expansão do HANA com nós em espera, enquanto o NFS sobre Arquivos do Azure é bom para compartilhamento de arquivos não de 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. 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 oferece suporte à alta disponibilidade do ASCS no SLES. Para obter informações detalhadas sobre ASCS na alta disponibilidade do RHEL, consulte SIOS Protection Suite para 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 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 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 impede que o balanceador de carga se torne um gargalo no caminho da 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 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 o tráfego de carga em 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 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 do HANA e use o HSR.
• Para failover automático, use HSR e HAE (High Availability Extension) 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

As zonas de disponibilidade podem melhorar 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 as VMs contra paralisaçõ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 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 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 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 é criado na zona 2, mas é 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, 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 co-localizados 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.

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 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 online para fornecer capacidade total para o 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 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, 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 o uso de 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 à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 integração contínua e cargas de trabalho de entrega contínua
  • Aplicativos sem estado em grande escala

• As Instâncias de Máquina Virtual Reservadas do Azure podem reduzir seu custo total de propriedade combinando as taxas de Instâncias de Máquina Virtual Reservadas do Azure com uma assinatura pré-paga 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.

Load Balancer

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

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

ExpressRoute

Nessa arquitetura, a Rota Expressa é 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 seguintes pontos.

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, ele 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, consulte Centro do Azure para soluções SAP.

Backup

Você pode fazer backup dos 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ê possui. 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 pela SAP pela BackInt. 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.

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 LDAP (Lightweight Directory Access Protocol), ID do Microsoft Entra, Kerberos ou outro sistema.

• Ofereça suporte ao acesso 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, analisar e atuar na 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 eles 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

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 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 é 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 peering 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 de segurança" do SAP NetWeaver no Guia de Planejamento e Implementação de Máquinas Virtuais do Azure 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 do 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 que você use a 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 que você use a tecnologia de criptografia nativa do SAP HANA.

Comunidades

As comunidades podem responder a perguntas e ajudá-lo 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 - Brasil | 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 dessa arquitetura, consulte 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 SAP usando um banco de dados Oracle no Azure