Compartilhar via

SAP S/4HANA com 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 (HA) que dá suporte à recuperação de desastre (DR) no Azure. As informações do Fiori aplicam-se somente a aplicativos S/4HANA.

Arquitetura

Diagrama de arquitetura que mostra o SAP S/4HANA para máquinas virtuais Linux em um conjunto de disponibilidade do Azure.

Baixe um arquivo do Visio dessa arquitetura.

Observação

Para implantar essa arquitetura, verifique se você tem o licenciamento necessário para produtos SAP e quaisquer outras tecnologias que não sejam da Microsoft.

Este guia descreve um sistema de produção típico. Essa arquitetura usa vários tamanhos de VM (máquina virtual). Para acomodar as necessidades da sua organização, você pode ajustar os tamanhos ou reduzir essa configuração para uma única VM.

Neste guia, o layout de rede é simplificado para demonstrar princípios arquitetônicos. Ele não representa 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 os recursos do Azure uns aos outros com segurança aprimorada. 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 entre si. Essa topologia fornece segmentação de rede e isolamento para serviços que são implantados no Azure. "O peering conecta redes de forma transparente através da rede de backbone da Microsoft e não há perda de desempenho se implementado em uma única região." Sub-redes separadas são usadas para cada camada, incluindo a camada de aplicativo (SAP NetWeaver) e a camada de banco de dados e para componentes compartilhados, como a caixa de salto e o Active Directory do Windows Server.

VMs. Essa arquitetura organiza as VMs que executam o Linux em grupos para a camada de aplicativo e a camada de banco de dados das seguintes maneiras:

  • 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 HA do Central Services no Azure que é executado nas VMs Linux, é necessário um serviço de compartilhamento de arquivos de rede altamente disponível, como Compartilhamentos de arquivos NFS (Network File System) em Arquivos do Azure, Azure NetApp Files, servidores NFS 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 como um dispositivo de isolamento para obter HA.

  • SAP HANA. A camada de banco de dados usa duas ou mais VMs Linux em um cluster para obter HA 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 do sistema e facilitar o failover automático. Você deve usar um mecanismo de isolamento baseado em armazenamento ou na nuvem para ajudar a garantir que o sistema com falha seja isolado ou desligado para evitar um cluster particionado. Em implantações de expansão do HANA, você pode obter HA de 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 VM usando seu navegador e o portal do Azure ou usando o SSH (Secure Shell) nativo ou o cliente RDP (Remote Desktop Protocol) instalado em seu computador local. Se apenas RDP e SSH forem usados para administração, considere usar o Azure Bastion. 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 aplicativo SAP para aumentar a disponibilidade, use o Azure Standard Load Balancer. O Load Balancer Standard 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 o aplicativo HA baseado na Web da SAP, utilize o SAP Web Dispatcher incorporado ou outro balanceador de carga comercialmente disponível. Baseie sua seleção em:

  • Seu tipo de tráfego, como tráfego HTTP ou tráfego da interface gráfica do usuário (GUI) SAP.
  • Os recursos de rede necessários, como a terminação SSL (Secure Sockets Layer).

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

  • ABAP (Advanced Business Application Programming) SAP Central Services (ASCS)
  • Servidor de replicação enfileiramento

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). Esse recurso permite que vários sistemas SAP no SLES ou RHEL compartilhem uma infraestrutura de HA comum para ajudar a reduzir os custos. É recomendável avaliar a economia de custos e evitar colocar muitos sistemas em um cluster. O Azure dá suporte a até 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, conhecida como Camada 4 de Interconexão de Sistemas Abertos (OSI), usando o Protocolo de Controle de Transmissão e o Protocolo de Datagrama do Usuário. 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. O Gateway de Aplicativo pode tomar decisões de roteamento com base em atributos adicionais de uma solicitação HTTP, como o caminho do identificador uniforme de recursos ou cabeçalhos de host. Esse tipo de roteamento é conhecido como camada de aplicativo ou balanceamento de carga da camada 7 da OSI. O S/4HANA fornece serviços de aplicativo Web por meio da Fiori. Você pode balancear a carga desse front-end Fiori, que consiste em aplicativos Web, usando o Gateway de Aplicativo. Se você usar endereços IP públicos, verifique se eles usam o SKU de endereço IP Padrão. Evite o SKU de endereço IP básico porque ele está planejado para descontinuação em 30 de setembro de 2025.

Porta de Entrada. 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 ajudar a reduzir a latência, use o Alcance Global do ExpressRoute ou o ExpressRoute FastPath.

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 ajuda a impor a colocação, garantindo que as VMs sejam implantadas no mesmo datacenter. Essa configuração reduz a distância física entre os recursos para minimizar a latência do aplicativo.

Observação

Para obter uma estratégia de configuração atualizada, consulte as opções de configuração para minimizar a latência de rede com aplicativos SAP. Este artigo descreve as possíveis compensações na flexibilidade de implantação quando você otimiza um sistema SAP para latência de rede.

NSGs (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 NSGs.

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 Microsoft Azure. O armazenamento fornece persistência de dados para uma VM na forma de um disco rígido virtual. Recomendamos que você use 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.

Máquinas Virtuais (VMs)

Em pools e clusters de servidor de aplicativos, ajuste o número de VMs com base nos seus requisitos. Para obter mais informações 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 mais informações sobre o suporte do SAP para tipos de VM do Azure e para métricas de taxa de transferência, consulte a nota do SAP 1928533. Para acessar as notas SAP, você precisa de uma conta do SAP Service Marketplace. Para obter uma lista de VMs certificadas do Azure para o banco de dados do HANA, consulte o diretório de hardware sap HANA certificado e com suporte do 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 HA do SAP Web Dispatcher, o Azure Load Balancer implementa o 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 aos requisitos de segurança. O Dispatcher web inserido no ASCS é uma configuração avançada. Se você usar essa configuração, considere o dimensionamento adequado devido à carga de trabalho extra no ASCS.

Servidor front-end (FES) Fiori

Essa arquitetura atende a vários requisitos e pressupõe que você use o modelo Fiori FES incorporado. Todos os componentes de tecnologia são instalados diretamente no sistema S/4, portanto, cada sistema S/4 tem seu próprio launchpad Fiori. O sistema S/4 gerencia a configuração de HA para esse modelo de implantação. Essa abordagem remove a necessidade de clustering ou VMs extras. Por esse motivo, o diagrama de arquitetura não inclui o componente FES.

Para obter mais informações sobre opções de implantação, consulte as opções de implantação do SAP Fiori e as recomendações de paisagem 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 torna uma implantação de hub adequada para apenas alguns casos de uso específicos.

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 HA da mesma maneira que você protege uma pilha de aplicativos ABAP de três camadas que tenha recursos clusterizados ou de vários hosts. Use uma camada de banco de dados de servidor de contingência, uma camada ASCS em cluster com HA NFS para armazenamento compartilhado e pelo menos dois servidores de aplicação. 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 Aplicações Web do Azure no Gateway de Aplicativo como um componente crítico para mitigar ameaças. Use o Microsoft Entra ID com Security Assertion Markup Language para autenticação de usuário e autenticação única para SAP Fiori.

Diagrama de arquitetura que mostra o fluxo de dados entre a Internet e duas redes virtuais, uma com SAP Fiori e outra com SAP S/4HANA.

Baixe um arquivo do Visio dessa arquitetura.

Para obter mais informações, consulte Conexões de entrada e de saída da Internet para SAP no Azure.

Pool de servidores de aplicativos

Para gerenciar grupos de logon para servidores de aplicativos ABAP, use os seguintes códigos de transação:

  • SMLG: balanceamento de carga para usuários de logon.
  • SM61: Gerenciar grupos de servidores em lotes.
  • RZ12: gerenciar grupos RFC (chamada de função remota).

Essas transações dependem da funcionalidade de balanceamento de carga no servidor de mensagens dos Serviços Centrais para distribuir sessões de entrada e cargas de trabalho no pool de servidores de aplicativos SAP que gerenciam o tráfego de GUI e RFC do SAP.

Cluster dos Serviços Centrais do SAP

O SAP Central Services contém uma única instância do servidor de mensagens e o serviço de replicação de enfileiramento. Ao contrário dos processos de trabalho dos servidores de aplicativos, esses componentes são pontos únicos de falha na pilha de aplicativos SAP. 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. Se o SLA exigir maior disponibilidade, você precisará implantar esses serviços em um cluster de HA. Para obter mais informações, consulte Serviços Centrais na camada de servidores de aplicativos.

Rede

Essa arquitetura usa uma topologia hub-spoke em que a rede virtual do hub serve como um ponto central de conectividade com 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.

Placas de interface de rede

Implantações tradicionais de SAP locais implementam várias NICs (placas de interface de rede) por máquina para separar o tráfego administrativo do tráfego de negócios. No Azure, a rede virtual é uma rede definida pelo software que roteia todo o tráfego por meio de uma única malha de rede. Como resultado, você não precisa de várias NICs por motivos de desempenho. Se sua organização precisar separar o tráfego, você poderá implantar várias NICs para cada VM, conectar cada NIC a uma sub-rede diferente e, em seguida, usar NSGs para ajudar a impor políticas de controle de acesso diferentes.

As NICs do Azure dão suporte a vários endereços IP. Esse suporte está alinhado com a prática que o SAP recomenda de usar nomes de host virtual para instalações na nota sap 962955.

Sub-redes e NSGs

Essa arquitetura divide o espaço de endereço da rede virtual em sub-redes. Você pode associar cada sub-rede a um NSG que define as políticas de acesso para a sub-rede. Coloque servidores de aplicativo em uma sub-rede separada. Essa abordagem facilita a segurança dos servidores de aplicativos gerenciando as políticas de segurança da sub-rede em vez dos servidores individuais.

Quando você associa um NSG a uma sub-rede, o NSG aplica-se a todos os servidores dentro da sub-rede e fornece controle refinado sobre os servidores. Configure NSGs usando o portal do Azure, o Azure 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á ajudá-lo a reduzir os saltos de rede e reduzir a latência. Essa tecnologia é um emparelhamento de rota 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 atravessa mais de um circuito do ExpressRoute. Ele está disponível apenas para emparelhamento privado em circuitos do ExpressRoute.

O Alcance Global não dá suporte a alterações em listas de controle de acesso à rede ou outros atributos. Todas as rotas aprendidas por um circuito ExpressRoute, seja no local ou no Azure, são anunciadas por meio de emparelhamento de circuito para outros circuitos ExpressRoute. Recomendamos que você configure a filtragem de tráfego de rede local para restringir o acesso aos recursos.

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. Como resultado, o FastPath reduz a latência de rede, melhora 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 uma rede virtual conectada ao ExpressRoute for emparelhada com outras redes virtuais, o tráfego da rede local para as outras redes virtuais spoke será roteado por meio do gateway de rede virtual. Para resolver esse problema, conecte todas as redes virtuais diretamente ao circuito do ExpressRoute.

Balanceadores de carga

O SAP Web Dispatcher manipula o balanceamento de carga do tráfego HTTP e HTTPS para um pool de servidores de aplicativos SAP. Esse balanceador de carga de software fornece serviços de camada de aplicação, conhecidos como camada 7 no modelo de rede ISO, que são capazes de realizar a 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 é baseado em um endereço IP de origem, porta de origem, endereço IP de destino, porta de destino e 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. É recomendável usar o Standard Load Balancer para todos os cenários SAP. O Load Balancer Standard é 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 (Dynamic Information and Action Gateway) 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, recomendamos que você use o SSD Premium do Azure ou o Azure NetApp Files em todos os cenários. Uma atualização recente da Nota SAP 2015553 exclui o uso do armazenamento HDD Standard do Azure e do armazenamento SSD Standard do Azure 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 aplicativos SAP, é altamente recomendável usar o SSD do Azure v1, O SSD v2 ou o Ultra Disks. Para entender como o tipo de armazenamento afeta o SLA de disponibilidade da VM, consulte SLAs para serviços online. Para cenários de HA, 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 os discos gerenciados do Azure e os tipos de disco gerenciado do Azure.

Você pode usar discos compartilhados do Azure com Windows Server, SLES 15 SP1 e posterior ou SLES para SAP. Quando você usa um disco compartilhado do Azure em clusters do Linux, o disco compartilhado do Azure funciona como um dispositivo de isolamento para bloquear nós com falhas. Ele oferece uma votação de quorum em um cenário de particionamento de rede em 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 HA para compartilhamentos NFS que podem ser usados para volumes /hana/shared, /hana/data, e /hana/log. Para obter a garantia de disponibilidade, consulte Acordos de Nível de Serviço (SLAs) para serviços on-line. Se você usar compartilhamentos NFS baseados no Azure NetApp Files para volumes /hana/data e volumes /hana/log , será necessário 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. Além disso, considere usar a 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 em Disco Ultra e a camada Ultra do Azure NetApp Files reduzem significativamente a latência de disco e melhoram o desempenho de aplicativos críticos e servidores de banco de dados SAP.

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

Considerações sobre desempenho

Os servidores de aplicativos SAP se comunicam constantemente com os servidores de banco de dados. Para aplicativos críticos ao desempenho 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ê usar o SSD Premium v1. Essa abordagem 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 hyper-threading, instâncias de VM com quatro ou mais vCPUs oferecem suporte à rede acelerada.

Você deve otimizar a pilha TCP/IP do Linux e os buffers no adaptador de rede para obter um desempenho consistente. Siga as configurações recomendadas pela Microsoft. Por exemplo, você ajustará itens como:

  • Parâmetros do kernel para otimizar buffers de memória de leitura e gravação
  • Controle de congestionamento BBR (largura de banda de gargalo e tempo de propagação de ida e volta)
  • Ajustar parâmetros TCP para trazer melhor consistência e taxa de transferência
  • Buffers de anel NIC para TX/RX

Para obter mais informações sobre os requisitos de desempenho do SAP HANA, consulte a nota do SAP 1943937.

Para obter operações de entrada/saída altas por segundo (IOPS) e taxa de transferência de largura de banda de disco, siga as práticas comuns para otimização de desempenho do volume de armazenamento. Por exemplo, combinar vários discos para criar um volume de disco em faixas pode melhorar o desempenho de E/S (entrada/saída). Habilitar o cache de leitura no conteúdo de armazenamento que é alterado com pouca frequência também pode acelerar a recuperação de dados. Para obter mais informações, confira Configurações de armazenamento de máquina virtual do Azure no SAP HANA.

O SSD Premium v2 foi projetado para cargas de trabalho críticas ao desempenho, como o SAP. Para obter mais informações sobre seus benefícios, limitações e cenários de uso ideal, consulte os tipos de disco gerenciado do Azure.

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 forma independente métricas como IOPS e MBps sem reinicializar sua VM. Recomendamos que você use o Armazenamento em Disco Ultra em vez do Acelerador de Gravação quando possível.

Alguns aplicativos SAP exigem comunicação frequente com o banco de dados. Devido à distância, a latência de rede entre as camadas do aplicativo e do banco de dados 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. Dentro do constructo lógico de um grupo, a colocação e o desempenho são favorecidos em relação à escalabilidade, disponibilidade e custo. Os grupos de posicionamento por proximidade podem aprimorar muito a experiência do usuário para a maioria dos aplicativos SAP.

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 que você considere o desempenho ao implantar recursos com zonas de disponibilidade, o que pode melhorar a disponibilidade do serviço. Considere a criação de 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 em vez disso, consulte o teste de latência da zona de disponibilidade.

O Azure NetApp Files tem recursos de desempenho exclusivos que permitem o ajuste em tempo real para atender às necessidades dos ambientes SAP mais exigentes. Para considerações de desempenho ao usar o Azure NetApp Files, consulte Dimensionamento do banco de dados HANA no Azure NetApp Files.

Considerações sobre escalabilidade

Na camada de aplicativo SAP, o Azure fornece uma ampla gama de tamanhos de VM para escalar verticalmente e escalar horizontalmente. Para obter uma lista completa, consulte aplicativos SAP no Azure: produtos com suporte e tipos de VM do Azure na Nota SAP 1928533. Mais tipos de VM são continuamente certificados, permitindo que você aumente ou reduza a capacidade na mesma implantação de nuvem.

Na camada de banco de dados, essa arquitetura executa aplicativos SAP S/4HANA 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 (quatro instâncias de 24 TB) para aplicativos de processamento de transações online. Para obter mais informações, consulte o diretório de hardware do SAP HANA certificado e com suporte.

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 SLAs para serviços online. Para aumentar a disponibilidade do serviço no Azure, implante recursos de VM usando conjuntos de dimensionamento de máquinas virtuais do Azure, que fornecem orquestração flexível, zonas de disponibilidade e conjuntos de disponibilidade.

O modelo de implantação de conjuntos de disponibilidade regionais do Azure é uma opção com suporte. No entanto, recomendamos que você adote conjuntos de dimensionamento de máquinas virtuais no modelo de zonas de disponibilidade para novas implantações SAP, a fim de melhorar a disponibilidade e aumentar a flexibilidade de implantação.

Nesta instalação distribuída do aplicativo SAP, a instalação base é replicada para obter HA. Para cada camada da arquitetura, o design de HA 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áquinas Virtuais com orquestração flexível (uma configuração de domínio de falha), zonas de disponibilidade e conjuntos de disponibilidade, para aprimorar a disponibilidade dos recursos.

À medida que as implantações de clientes no Azure cresceram ao longo dos anos, a Microsoft aprimorou os modelos de implantação de VM do Azure para incluir Conjuntos de Dimensionamento de Máquinas Virtuais para ajudar a garantir a elasticidade e a resiliência da nuvem. Considerando as opções de implantação disponíveis, é altamente recomendável usar a implantação zonal do conjunto de dimensionamento flexível do Azure para todas as novas implantações. Para obter mais informações sobre a implantação entre zonas, em uma única zona e em regiões sem zonas, consulte a arquitetura e os cenários de HA para SAP NetWeaver.

Web Dispatcher na camada de servidores de aplicativos

Você pode obter HA usando instâncias redundantes do Web Dispatcher. Para obter mais informações, consulte o SAP Web Dispatcher. O nível de disponibilidade depende do tamanho do aplicativo que está por trás do Web Dispatcher. Em implantações pequenas que têm poucas preocupações de escalabilidade, você pode colocar o Web Dispatcher com as VMs do ASCS. Essa abordagem ajuda você a economizar na manutenção do sistema operacional independente e obter HA ao mesmo tempo.

Central Services na camada de servidores de aplicativos

Para HA do Central Services em VMs Linux do Azure, use a extensão de HA adequada para a distribuição Linux selecionada. É comum colocar sistemas de arquivos compartilhados em armazenamento NFS altamente disponível usando o Dispositivo de Bloco Replicado Distribuído do SUSE 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 nos Arquivos do Azure ou no Azure NetApp Files. 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 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 /sapmnt e /saptrans em instalações do SAP.

O Azure NetApp Files oferece suporte à HA de ASCS no SLES. Para obter mais informações sobre ASCS em HA rhel, consulte SIOS Protection Suite para Linux.

O agente de proteção Azure melhorado está disponível para SUSE e Red Hat e proporciona uma transição de serviço muito mais rápida do que a versão anterior do agente.

Outra opção de isolamento é usar discos compartilhados do Azure para o dispositivo de isolamento. No SLES 15 SP1 ou SLES para SAP 15 SP1 e posterior, você pode configurar um cluster do Pacemaker usando discos compartilhados do Azure. Essa opção é simples e não requer uma porta de rede aberta como o agente de cerca do Azure.

Uma configuração mais simples e recentemente suportada do Pacemaker no SLES 15 e posterior é HA SAP NetWeaver com montagem simples e NFS em VMs SLES para Aplicativos SAP. Nessa configuração, os compartilhamentos de arquivos SAP são retirados do gerenciamento de cluster, o que torna mais simples operar. Use essa configuração de HA para todas as novas implantações.

Para gerenciar ainda mais os custos de um grande cenário SAP, o cluster Linux oferece suporte à instalação ASCS multi-SID no Azure. O compartilhamento de um cluster de disponibilidade entre vários sistemas SAP simplifica o cenário SAP e reduz os custos de operação.

No Standard Load Balancer, você pode habilitar a porta de HA 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 os clusters de banco de dados ASCS e HANA, recomendamos que você habilite a DSR. Se as VMs no pool de back-end exigirem conectividade de saída pública, novas configurações serão necessárias.

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 HA balanceando o tráfego em um pool de servidores de aplicativos.

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 HA) do Linux para sua distribuição Linux. Linux HAE fornece serviços de cluster para recursos do HANA, detecta eventos de falha e orquestra a transferência dos serviços defeituosos para um nó saudável.

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 atualização ou falha. 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 que dão suporte a esse recurso, no mínimo três zonas estão disponíveis. 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 saber a latência de rede dentro de uma zona e entre zonas direcionadas 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 ou tipos de VM nas zonas escolhidas

Observação

Não recomendamos zonas de disponibilidade para DR. Um site de recuperação de desastre deve estar a pelo menos 160 km do local primário para considerar desastres naturais. A distância exata entre datacenters não pode ser garantida.

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 somente quando necessário.

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 colocados 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 cada conjunto estão ativos. 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 conectam aos serviços ASCS e 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 de DR

Cada camada na pilha de aplicativos SAP usa uma abordagem diferente para fornecer proteção contra DR. Para estratégias de DR e informações sobre implementação, consulte Visão geral de DR e diretrizes de infraestrutura para cargas de trabalho SAP e diretrizes de DR para aplicativos SAP.

Observação

Se houver um desastre regional que cause um evento de failover em massa para muitos clientes do Azure em uma região, a capacidade de recurso da região de destino não será garantida. Assim como todos os serviços do Azure, o Site Recovery continua adicionando recursos. Para obter as informações mais recentes sobre a replicação do Azure para Azure, confira a matriz de suporte.

Para ajudar a garantir a capacidade de recurso disponível para uma região de DR, use a reserva de capacidade sob demanda. O Azure permite que você combine o desconto de reserva de instância com sua reserva de capacidade para reduzir os custos.

Considerações de custo

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

Para obter mais informações, consulte a otimização de custo do Azure Well-Architected Framework.

Máquinas Virtuais (VMs)

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

Existem várias opções de pagamento para VMs:

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

  • Considere usar 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 economizar até 72% em comparação com as opções de pagamento conforme o uso.

  • Use spot VMs do Azure para executar cargas de trabalho que podem ser interrompidas e não exigem a conclusão dentro de um período predeterminado ou um SLA. O Azure implantará VMs spot quando houver capacidade disponível e as evitará quando precisar da capacidade novamente. Os custos de VMs spot são menores do que 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áquina Virtual Reservadas do Azure podem reduzir seu custo total de propriedade combinando taxas de 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 saber mais, confira Instâncias de Máquinas Virtuais Reservadas do Azure.

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

Balanceador de carga

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 de 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, consulte Preços do ExpressRoute.

Considerações sobre gerenciamento e operações

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

Soluções do Azure Center para 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. A experiência de implantação guiada do Centro do Azure para SAP cria os componentes de computação, armazenamento e rede necessários para executar seu sistema SAP. Em seguida, você pode 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.

Cópia de segurança

É possível fazer backup dos dados do SAP HANA de diversas maneiras. Depois de migrar para o Azure, continue a usar as soluções de backup existentes que tiver. 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 possui a 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.

Observação

Somente implantações de contêiner único ou implantações em escala vertical do HANA dão suporte a instantâneos de armazenamento do Azure.

Gerenciamento de identidades

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

Monitorização

Para maximizar a disponibilidade e o desempenho de aplicativos e serviços no Azure, use o Azure Monitor. O Azure Monitor fornece uma solução abrangente para coleta, análise e ação com base na telemetria dos seus ambientes de nuvem e locais. O Azure Monitor mostra o desempenho dos 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 seu próprio mecanismo de gerenciamento de usuário para controlar o acesso e a autorização baseados em função dentro do aplicativo SAP e dos bancos de dados. Para obter mais informações, consulte a visão geral de segurança do SAP HANA.

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. Para minimizar os custos de transferência de dados, implante servidores front-end ativos que hospedam aplicativos Fiori na mesma rede virtual que os sistemas S/4. Como alternativa, você pode configurar esses servidores front-end na rede de perímetro, o que aproveita o emparelhamento de rede virtual para estabelecer conectividade com os sistemas S/4.

Para a segurança da infraestrutura, os dados são criptografados em trânsito e em repouso. Para obter informações sobre a segurança de rede que se aplica ao S/4HANA, consulte Segurança para seu cenário sap.

Para criptografar discos de VM do Linux, você tem várias opções. 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 Azure Disk Encryption para VMs Linux.

Observação

Não use a criptografia de dados em repouso do HANA e o Azure Disk Encryption no mesmo volume de armazenamento. Para HANA, prefira usar a criptografia de dados do HANA sobre a criptografia do lado servidor de armazenamento em disco do Azure. O uso de chaves gerenciadas pelo cliente pode afetar a taxa de transferência de E/S.

Comunidades

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

Contribuidores

A Microsoft mantém este artigo. Os colaboradores a seguir escreveram este artigo.

Autor principal:

Para ver perfis não públicos no 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 os seguintes artigos: