Executar o SAP NetWeaver no Windows no Azure

Este guia apresenta um conjunto de práticas comprovadas para executar o SAP NetWeaver em um ambiente do Windows, no Azure, com alta disponibilidade. O banco de dados é o AnyDB, o termo da SAP para qualquer DBMS (gerenciador de banco de dados) com suporte, além do SAP HANA.

Arquitetura

O diagrama a seguir mostra o SAP NetWeaver em um ambiente Windows.

Baixe um Arquivo Visio dessa arquitetura.

Este guia descreve um sistema de produção. O sistema é implantado com tamanhos específicos de VM (máquina virtual) que podem ser alterados para acomodar as necessidades da sua organização. O sistema pode ser reduzido a uma única VM. Neste guia, o layout de rede está bastante simplificado para demonstrar os princípios arquitetônicos. Ele não se destina a descrever uma rede corporativa completa.

Workflow

Redes virtuais. O serviço Rede Virtual do Azure conecta os recursos do Azure entre si com segurança avançada. Nessa arquitetura, a rede virtual se conecta a uma rede local por meio de um gateway do Azure ExpressRoute que é 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. A rede virtual hub é usada para serviços compartilhados, como o Azure Bastion e o backup.

Emparelhamento de rede virtual. Essa arquitetura usa uma topologia de rede hub e spoke com várias redes virtuais emparelhadas. Essa topologia fornece segmentação de rede e isolamento para serviços que são implantados no Azure. O emparelhamento permite conectividade transparente entre redes virtuais emparelhadas por meio da rede backbone da Microsoft. Ele não incorre em uma penalidade de desempenho se implantado em uma região. A rede virtual é dividida em sub-redes separadas para cada camada: aplicativo (SAP NetWeaver), banco de dados e serviços compartilhados, como Bastion e uma solução de backup de terceiros.

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

• SAP NetWeaver. A camada de aplicativo usa VMs Windows para execução de SAP Central Services e servidores de aplicativos SAP. Para alta disponibilidade, as VMs que executam os Central Services são configuradas em um cluster de failover do Windows Server. Elas têm suporte dos compartilhamentos de arquivos do Azure ou discos compartilhados do Azure.

• AnyDB. A camada de banco de dados executa AnyDB como o banco de dados, que podem ser Microsoft SQL Server, Oracle ou IBM Db2.

• Serviço Bastion. Os administradores usam uma VM de segurança aprimorada chamada de bastion host para se conectar a outras VMs. Normalmente, ela faz parte dos serviços compartilhados, como serviços de backup. Se o protocolo SSH e o protocolo RDP forem os únicos serviços usados para administração do servidor, um host do Azure Bastion é uma boa solução. Se você usa outras ferramentas de gerenciamento, como o SQL Server Management Studio ou o SAP Frontend, use um jumpbox tradicional autoimplantado.

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

Balanceadores de carga. Para distribuir o tráfego para VMs na sub-rede da camada de aplicativos SAP para alta disponibilidade, é recomendável usar um Azure Standard Load Balancer. Observe que o Standard Load Balancer fornece um nível 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. Para alta disponibilidade de aplicativos SAP baseados na Web, use o SAP Web Dispatcher integrado ou outro balanceador de carga disponível comercialmente. Baseie sua seleção em:

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

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

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

• SAP Central Service (ASCS) do Advanced Business Application Programming (ABAP)
• Servidor de Replicação Enfileiramento (ERS)

O SKU Standard também dá suporte a clusters SAP de identificador de vários sistemas (multi-SID). Em outras palavras, vários sistemas SAP no Windows podem compartilhar uma infraestrutura comum de alta disponibilidade para economia de custos. Avalie as economias de custo 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 pode ser usado no gerenciamento do tráfego para seus aplicativos Web. Os balanceadores de carga tradicionais operam na camada de transporte (camada OSI 4 - TCP e UDP). Eles roteiam o tráfego com base no endereço IP e na porta de origem para um endereço IP e uma porta de destino. Com o Gateway de Aplicativo, é possível tomar decisões de roteamento com base em outros atributos de uma solicitação HTTP, como o caminho de URI ou os cabeçalhos de host. Esse tipo de roteamento é conhecido como balanceamento de carga da camada de aplicativo (camada OSI 7).

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

Grupos de segurança do aplicativo. Para definir políticas de segurança de rede refinadas baseadas em cargas de trabalho que são centralizadas nos aplicativos, use grupos de segurança de aplicativo em vez de endereços IP explícitos. Os grupos de segurança de aplicativo fornecem uma maneira de agrupar VMs por nome e ajudam a proteger aplicativos filtrando o tráfego de segmentos confiáveis da rede.

Gateway. Um gateway conecta redes distintas, estendendo sua rede local para a rede virtual do Azure. Recomendamos que você use o ExpressRoute 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 ou aumentar a taxa de transferência, considere o Alcance Global do ExpressRoute e o ExpressRoute FastPath, conforme discutido posteriormente neste artigo.

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 diferem de acordo com os requisitos de negócios, portanto, considere essas recomendações como um ponto de partida.

VMs

Em pools e clusters de servidor de aplicativos, ajuste o número de VMs com base nos seus requisitos. Para obter informações detalhadas sobre como executar o SAP NetWeaver em VMs, confira Planejamento e implementação de Máquinas Virtuais do Azure para SAP NetWeaver.

Para obter detalhes sobre o suporte da SAP para tipos de VM do Azure e métricas de taxa de transferência (SAPS), confira a Nota SAP 1928533. Para acessar as notas SAP, você precisa de uma conta do SAP Service Marketplace.

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 alta disponibilidade para o componente Web Dispatcher, o Load Balancer é usado para implementar o cluster de failover de instâncias do Web Dispatcher ou a configuração paralela do Web Dispatcher. Para obter uma descrição detalhada da solução, confira Alta disponibilidade do SAP Web Dispatcher.

Pool de servidores de aplicativos

A transação SAP SMLG é comumente usada para gerenciar grupos de logon para servidores de aplicativos ABAP e para balancear a carga de usuários de logon. Outras transações, como SM61 para grupos de servidores em lotes e RZ12 para grupos RFC (remote function call), também equilibram a carga de usuários de logon. Essas transações usam o recurso de balanceamento de carga no servidor de mensagens do SAP Central Services para distribuir sessões de entrada ou cargas de trabalho entre o pool de servidores de aplicativos SAP para tráfego RFC e GUIs do SAP.

Cluster do SAP Central Services

Essa arquitetura executa o Central Services em VMs na camada de aplicativo. Os Serviços Centrais são um possível SPOF (ponto único de falha) quando implantados em uma só VM. Para implementar uma solução de alta disponibilidade, use um cluster de compartilhamento de arquivo ou um cluster de disco compartilhado.

Para compartilhamentos de arquivos altamente disponíveis, há várias opções. É recomendável usar os compartilhamentos de Arquivos do Azure como compartilhamentos SMB (Server Message Block) ou NFS (Network File System) totalmente gerenciados, nativos da nuvem. Uma alternativa aos Arquivos do Azure é o Azure NetApp Files, que fornece compartilhamentos NFS e SMB de alto desempenho.

Você também pode implementar os compartilhamentos de arquivos altamente disponíveis nas instâncias do Central Services usando um cluster de failover do Windows Server com Arquivos do Azure. Essa solução também dá suporte a um cluster do Windows com discos compartilhados usando um disco compartilhado do Azure como o volume compartilhado de cluster. Se você preferir usar discos compartilhados, é recomendável usar os discos compartilhados do Azure para configurar um cluster de failover do Windows Server para o cluster dos SAP Central Services.

Também há produtos de parceiros, como o SIOS DataKeeper Cluster Edition da SIOS Technology Corp. Esse complemento replica o conteúdo de discos independentes anexados aos nós de cluster do ASCS e, em seguida, apresenta os discos como um volume compartilhado de cluster para o software de cluster.

Se você usar o particionamento de rede do cluster, o software de cluster usará votos de quorum para selecionar um segmento da rede e seus serviços associados para atuar como o cérebro do cluster fragmentado. O Windows oferece muitos modelos de quorum. Essa solução usa a Testemunha de Nuvem, pois é mais simples e fornece mais disponibilidade do que uma testemunha de nó de computação. A testemunha de compartilhamento de arquivos do Azure é outra alternativa para fornecer um voto de quorum do cluster.

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

Rede

Essa arquitetura usa uma topologia hub-spoke. A rede virtual hub atua como um ponto central da conectividade com uma rede local. Os spokes são redes virtuais que se emparelham com o hub e isolam as cargas de trabalho SAP. 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)

As NICs habilitam toda a comunicação entre as VMs em uma rede virtual. 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, não é necessário usar várias NICs por motivos de desempenho. No entanto, se sua organização precisa separar o tráfego, você pode implantar vários NICs por VM e conectar cada NIC a uma sub-rede diferente. Em seguida, você pode usar grupos de segurança de rede para impor políticas de controle de acesso diferentes.

As NICs do Azure dão suporte a vários IPs. Esse suporte está em conformidade com a prática recomendada pela SAP de usar nomes de host virtual para instalações. Para ver uma descrição completa, confira a nota SAP 962955. Para acessar as notas SAP, você precisa de uma conta do SAP Service Marketplace.

Sub-redes e grupos de segurança de rede

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

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

Alcance Global do ExpressRoute

Se o ambiente de rede incluir duas ou mais conexões do ExpressRoute, o Alcance Global do ExpressRoute poderá ajudar você a reduzir os saltos de rede e a latência. Essa tecnologia é um emparelhamento de rota BGP (Border Gateway Protocol) configurado entre duas ou mais conexões 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 uma conexão do ExpressRoute. No momento, ele está disponível apenas para emparelhamento privado em circuitos do ExpressRoute.

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

ExpressRoute FastPath

O FastPath foi desenvolvido para melhorar o desempenho do caminho de dados entre sua rede local e sua rede virtual. Quando habilitado, o FastPath envia o tráfego de rede diretamente às máquinas virtuais na rede virtual, ignorando o gateway.

Para todas as novas conexões do ExpressRoute com o Azure, o FastPath é a configuração padrão. Para circuitos existentes do ExpressRoute, entre em contato com suporte do Azure para ativar o FastPath.

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

Balanceadores de carga

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

O Azure Load Balancer é um serviço de camada de transmissão de rede (camada 4) que faz o balanceamento do tráfego usando um hash de cinco tuplas dos fluxos de dados. O hash se baseia no IP de origem, na porta de origem, no IP de destino, na porta de destino e no tipo de protocolo. Em implantações SAP no Azure, 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. Se as VMs no pool de back-end exigirem conectividade de saída pública ou se forem usadas em uma implantação de zona do Azure, o Standard Load Balancer exigirá configurações adicionais porque elas são seguras por padrão. Elas não permitem conectividade de saída, a menos que você a configure explicitamente.

Para o tráfego de clientes do SAP GUI que se conectam a um servidor SAP via protocolo DIAG ou RFC, o servidor de mensagens do Central Services faz o balanceamento da carga por meio de grupos de logon do servidor de aplicativos SAP. Para esse tipo de configuração, você não precisa de outro balanceador de carga.

Armazenamento

Algumas organizações usam o armazenamento padrão para seus servidores de aplicativos. Não há suportes para discos gerenciados padrão. Confira a nota do SAP 1928533. Para acessar as notas SAP, você precisa de uma conta do SAP Service Marketplace. É recomendável usar discos gerenciados premium 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.

Servidores de aplicativos não hospedam dados comerciais. Sendo assim, você pode usar os discos premium P4 e P6 menores para ajudar a minimizar os custos. Ao fazer isso, você poderá se beneficiar do SLA da VM de instância única se tiver uma instalação da pilha SAP central.

Para cenários de alta disponibilidade, você pode usar compartilhamentos de arquivos do Azure e discos compartilhados do Azure. Os discos gerenciados SSD Premium do Azure e o Armazenamento de Disco Ultra do Azure estão disponíveis para discos compartilhados do Azure, e o SSD Premium está disponível para compartilhamentos de arquivos do Azure.

O Armazenamento também é usado pela Testemunha de Nuvem para manter o quorum com um dispositivo em uma região remota do Azure longe da região primária em que reside o cluster.

Para o armazenamento de dados de backup, recomendamos as camadas de acesso aos arquivos e esporádico do Azure. Essas camadas de armazenamento são uma maneira econômica de armazenar dados de longa vida útil que são acessados com pouca frequência.

O armazenamento em disco do SSD Premium v2 do Azure foi projetado para cargas de trabalho críticas de desempenho, como sistemas de processamento de transações online que precisam consistentemente de latência inferior a milissegundos combinada com IOPS e taxa de transferência altas.

O Armazenamento de Disco Ultra reduz consideravelmente a latência do disco. Como resultado, ele beneficia aplicativos críticos ao desempenho, como os servidores de banco de dados SAP. Para comparar opções de armazenamento em bloco no Azure, confira Tipos de disco gerenciado do Azure.

Para um armazenamento de dados compartilhado de alta disponibilidade e alto desempenho, use o Azure NetApp Files. Essa tecnologia é particularmente útil para a camada de banco de dados quando você usa Oracle e também quando hospeda dados do aplicativo.

Considerações sobre o desempenho

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

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

Para obter IOPS e taxas de transferências de disco altas, siga as práticas comuns na otimização de desempenho do volume de armazenamento, que se aplicam ao layout de armazenamento do Azure. Por exemplo, é possível posicionar vários discos juntos para criar um volume de disco distribuído de modo a aprimorar o desempenho de E/S. Habilitar o cache de leitura do conteúdo de armazenamento que raramente é alterado melhora a velocidade de recuperação de dados.

O SSD Premium v2 oferece um desempenho superior ao dos SSDs Premium e geralmente é mais barato. Você pode definir um SSD Premium v2 com qualquer tamanho com suporte que preferir e executar ajustes granulares no desempenho sem tempo de inatividade.

O Armazenamento de Disco Ultra está disponível para aplicativos com uso intensivo de E/S. Onde esses discos estiverem disponíveis, aconselhamos usá-los em vez do armazenamento premium do Acelerador de Gravação. Você pode aumentar ou diminuir individualmente as métricas de desempenho, como IOPS e MBps, sem precisar reiniciar.

Para saber como otimizar o armazenamento do Azure para cargas de trabalho SAP no SQL Server, confira Planejamento e implementação de máquinas virtuais do Azure para SAP NetWeaver.

Não há suporte para o posicionamento de um NVA (dispositivo virtual de rede) entre as camadas de aplicativo e de banco de dados para qualquer pilha de aplicativos SAP. Essa prática introduz um tempo de processamento significativo para pacotes de dados, o que leva a um desempenho inaceitável do aplicativo.

Grupos de posicionamento por proximidade

Alguns aplicativos SAP exigem comunicação frequente com o banco de dados. A proximidade física das camadas de aplicativo e de banco de dados afeta a latência de rede, o que pode afetar negativamente o desempenho do aplicativo.

Para otimizar a latência de rede, você pode usar grupos de posicionamento por proximidade, que definem uma restrição lógica nas VMs implantadas em conjuntos de disponibilidade. Os grupos de posicionamento por proximidade favorecem a colocação e o desempenho em detrimento à escalabilidade, à disponibilidade ou ao custo. Eles podem aprimorar muito a experiência do usuário para a maioria dos aplicativos SAP. Para obter scripts disponíveis no GitHub da equipe de implantação SAP, veja Scripts.

Zonas de disponibilidade

As zonas de disponibilidade fornecem uma maneira de implantar VMs em datacenters, que são locais fisicamente separados em uma região específica do Azure. Sua finalidade é aprimorar a disponibilidade do serviço. Mas a implantação de recursos entre zonas pode aumentar a latência, portanto, lembre-se das considerações de desempenho.

Os administradores precisam de um perfil de latência de rede claro entre todas as zonas de uma região de destino antes de determinar o posicionamento do recurso com latência mínima entre zonas. Para criar esse perfil, implante pequenas VMs em cada zona para teste. As ferramentas recomendadas para esses testes incluem PsPing e Iperf. Quando os testes estiverem concluídos, remova as VMs que foram usadas para esse fim. Como alternativa, considere o uso de uma ferramenta de verificação de latência entre zonas do Azure.

Considerações sobre escalabilidade

Para a camada de aplicativo SAP, o Azure oferece uma ampla gama de tamanhos de VM para escalar e horizontal e verticalmente. Para obter uma lista inclusiva, confira a Nota SAP 1928533 – Aplicativos SAP no Azure: produtos e tipos de VM do Azure com suporte. Para acessar as notas SAP, você precisa de uma conta do SAP Service Marketplace.

Você pode dimensionar os servidores de aplicativos SAP e os clusters dos Central Services para cima e para baixo. Também é possível dimensioná-los horizontalmente alterando o número de instâncias que você usa. O banco de dados AnyDB pode ser escalado e reduzido verticalmente, mas não pode ser escalado horizontalmente. O contêiner do banco de dados SAP para AnyDB não dá suporte à fragmentação.

Considerações sobre disponibilidade

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

Com o 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 (FD=1), zonas de disponibilidade e conjuntos de disponibilidade para melhorar a disponibilidade de recursos. Para obter uma compreensão abrangente das opções de implantação disponíveis e sua aplicabilidade em diferentes regiões do Azure (inclusive entre zonas, em uma única zona ou em uma região sem zonas), confira Arquitetura e cenários de alta disponibilidade para SAP NetWeaver.

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.

Web Dispatcher na camada de servidores de aplicativos

O componente Web Dispatcher é usado como um balanceador de carga para tráfego da SAP entre os servidores de aplicativos SAP. Para obter a alta disponibilidade do SAP Web Dispatcher, o Load Balancer implementa o cluster de failover ou a configuração paralela do Web Dispatcher.

Para comunicações voltadas para a Internet, é recomendável uma solução autônoma na rede de perímetro, que também é conhecida como DMZ, para resolver as questões de segurança.

O Web Dispatcher Embedded no ASCS é uma opção especial. Se você usar essa opção, considere o dimensionamento adequado devido à carga de trabalho extra no ASCS.

Central Services na camada de servidores de aplicativos

A alta disponibilidade do Central Services é implementada com um cluster de failover do Windows Server. Quando o armazenamento de cluster para o cluster de failover é implantado no Azure, você pode configurá-lo de duas maneiras: como um disco compartilhado clusterizado ou como um compartilhamento de arquivos clusterizado.

• Recomendamos que você use os Arquivos do Azure como compartilhamentos SMB ou NFS totalmente gerenciados, nativos de nuvem. Outra opção é usar o Azure NetApp Files, que fornece NFS de classe empresarial e compartilhamentos SMB de alto desempenho.

• Há duas maneiras de configurar clusters com discos compartilhados no Azure. Primeiro, é recomendável usar os discos compartilhados do Azure para configurar um cluster de failover do Windows Server para o SAP Central Services. Para obter um exemplo de implementação, confira Cluster do ASCS usando discos compartilhados do Azure. Outra maneira de implementar um disco compartilhado clusterizado é usar o SIOS DataKeeper para executar as seguintes tarefas:

  • Replicar o conteúdo de discos independentes anexados aos nós de cluster.
  • Abstrair as unidades como um volume compartilhado de cluster para o gerenciador de cluster.

  Para obter detalhes sobre a implementação, consulte Clustering do SAP ASCS no Azure com SIOS.

Se você usar o Standard Load Balancer, será possível habilitar a porta de alta disponibilidade. Ao fazer isso, você pode evitar a necessidade de configurar regras de balanceamento de carga para várias portas SAP. Além disso, ao configurar os balanceadores de carga do Azure, habilite o DSR (Retorno de Servidor Direto), que também é chamado de IP Flutuante. Com isso, é possível fazer com que as respostas do servidor ignorem o balanceador de carga. Essa conexão direta impede que o balanceador de carga se torne um gargalo no caminho da transmissão de dados. É recomendável habilitar o DSR para os clusters do ASCS e do banco de dados.

Serviços de aplicativo na camada de servidores de aplicativos

A alta disponibilidade dos servidores de aplicativo SAP é obtida pelo tráfego de balanceamento de carga dentro de um pool de servidores de aplicativos. Você não precisa do software de cluster, SAP Web Dispatcher ou Azure Load Balancer. O servidor de mensagens SAP pode balancear a carga do tráfego do cliente para os servidores de aplicativos definidos em um grupo de logon do ABAP pela transação SMLG.

Camada de banco de dados

Nessa arquitetura, o banco de dados de origem é executado em AnyDB – um DBMS como SQL Server, SAP ASE, IBM Db2 ou Oracle. O recurso de replicação nativo da camada de banco de dados fornece o failover manual ou automático entre nós replicados.

Para obter detalhes de implementação sobre sistemas específicos de banco de dados, consulte Implantação de DBMS de Máquinas Virtuais do Azure para SAP NetWeaver.

VMs implantadas em zonas de disponibilidade

Uma zona de disponibilidade consiste em um ou mais datacenters. Ela foi projetada para melhorar a disponibilidade da carga de trabalho e proteger os serviços de aplicativos e VMs contra interrupções de datacenter. As VMs em uma única zona são tratadas como se estivessem em um único domínio de falha. Quando você seleciona a implantação por zona, as VMs na mesma zona são distribuídas para domínios de falha com base no melhor esforço.

Nas regiões do Azure compatíveis com várias zonas, pelo menos três zonas são disponibilizadas. Mas a distância máxima entre datacenters nessas zonas não é garantida. Para implantar um sistema SAP multicamadas entre zonas, você precisa conhecer a latência de rede dentro de uma zona e entre zonas de destino. Você também precisa saber o quão sensíveis os aplicativos implantados são à latência de rede.

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

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

Exemplo de implantação ativa/inativa

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

Os clusters de dois nós para os Central Services e os serviços de 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 agora 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. Dentro de cada zona, dois servidores de aplicativos em cada conjunto de servidores estão inativos porque estão desligados. Como resultado, há servidores de aplicativos ativos em ambas as zonas durante operações normais.

Os Central Services e os serviços 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 Central Services e aos serviços de banco de dados devido à distância física entre as zonas.

Se a zona 1 ficar offline, os Central Services e os serviços de banco de dados farão failover para a zona 2. Você pode colocar os servidores de aplicativos inativos online para fornecer capacidade total para o processamento de aplicativos.

Considerações de DR

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

Considerações sobre gerenciamento e operações

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

Centro do Azure para soluções SAP

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

Se precisar de mais controle sobre eventos de manutenção ou isolamento de hardware, para desempenho ou conformidade, considere implantar suas VMs em hosts dedicados.

Backup

Bancos de dados são cargas de trabalho críticas que exigem um baixo RPO (objetivo de ponto de recuperação) e retenção de longo prazo.

• Para SAP no SQL Server, uma abordagem é usar o Backup do Azure para fazer backup de bancos de dados do SQL Server executados em VMs. Outra opção é usar instantâneos dos Arquivos do Azure para fazer backup de arquivos de banco de dados do SQL Server.

• Para o SAP no Oracle/Windows, consulte a seção "Backup/restauração" na Implantação do DBMS da VM do Azure para SAP.

• Para outros bancos de dados, consulte as recomendações de backup de seu provedor de banco de dados. Se o banco de dados der suporte ao VSS (Serviço de Cópias de Sombra de Volume) do Windows, use instantâneos do VSS para backups consistentes com aplicativos.

Gerenciamento de identidades

Use um sistema centralizado de gerenciamento de identidades, como o Microsoft Entra ID e o Active Directory Domain Services (AD DS) para controlar o acesso aos recursos em todos os níveis:

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

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

Dê suporte ao acesso dentro dos próprios aplicativos usando os serviços que o SAP fornece. Ou use OAuth 2.0 e Microsoft Entra ID.

Monitoramento

Para maximizar a disponibilidade e o desempenho de aplicativos e serviços no Azure, use o Azure Monitor, uma solução abrangente para coletar e analisar a telemetria dos ambientes locais e de nuvem e para agir com base nela. O Azure Monitor mostra o desempenho 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 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 diretrizes detalhadas de segurança do aplicativo, confira o Guia de Segurança do SAP NetWeaver.

Para mais segurança de rede, considere usar uma rede de perímetro que usa um NVA para criar um firewall na frente da sub-rede do Web Dispatcher.

Você pode implantar uma NVA para filtrar o tráfego entre redes virtuais, mas não colocá-lo entre o aplicativo SAP e o banco de dados. Além disso, verifique as regras de roteamento configuradas na sub-rede e evite direcionar o tráfego para um NVA de instância única. Isso pode levar a tempo de inatividade de manutenção e a falhas de rede ou do nó clusterizado.

Para a segurança da infraestrutura, os dados são criptografados em trânsito e em repouso. Para obter informações sobre segurança de rede, confira a seção "Recomendações de segurança" em Planejamento e implementação de Máquinas Virtuais do Azure para SAP NetWeaver. Este artigo também especifica as portas de rede que você precisa abrir nos firewalls para permitir a comunicação do aplicativo.

Você pode usar o Azure Disk Encryption para criptografar discos de VM Windows. Esse serviço usa o recurso BitLocker do Windows para fornecer criptografia de volume para o sistema operacional e os discos de dados. A solução também funciona com o Azure Key Vault para ajudar você a controlar e gerenciar os segredos e chaves de criptografia de disco em sua assinatura do Key Vault. Os dados nos discos da VM são criptografados em repouso no armazenamento do Azure.

Para a criptografia de dados inativos, a TDE (Transparent Data Encryption) criptografa arquivos de dados do SQL Server, Banco de Dados SQL do Azure e Azure Synapse Analytics. Para obter mais informações, consulte Implantação de DBMS das Máquinas Virtuais do Azure SQL Server para SAP NetWeaver.

Para monitorar ameaças de dentro e fora do firewall, considere implantar o Microsoft Sentinel (versão preliminar). A solução fornece detecção e análise contínuas de ameaças para sistemas SAP implantados no Azure, em outras nuvens ou no local. Para obter diretrizes de implantação, confira Implantar o monitoramento de ameaças para SAP no Microsoft Sentinel.

Como sempre, gerencie atualizações e patches de segurança para proteger seus ativos de informações. Considere usar uma abordagem de automação de ponta a ponta para essa tarefa.

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.

Se sua carga de trabalho exigir mais memória e menos CPUs, considere usar um dos tamanhos de VM de vCPU restritos para reduzir os custos de licenciamento de software, que são cobrados por vCPU.

VMs

Essa arquitetura usa VMs para a camada de aplicativo e a camada de banco de dados. A camada do SAP NetWeaver usa VMs Windows para executar serviços e aplicativos SAP. A camada de banco de dados executa AnyDB como o banco de dados, como SQL Server, Oracle ou IBM DB2. As VMs também são usadas como jumpboxes para gerenciamento.

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 pagar conforme o uso.

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

Use as VMs spot do Azure para executar cargas de trabalho que podem ser interrompidas e não exigem a conclusão em 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 associados às VMs spot são menores do que para outras VMs. Considere as VMs spot para estas cargas de trabalho:

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

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

Load Balancer

Neste cenário, o Load Balancer é usado para distribuir o tráfego para as VMs na sub-rede da camada de aplicativo.

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

ExpressRoute

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

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

Comunidades

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

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

Colaboradores

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

Autor principal:

• Ben Trinh | Arquiteto Principal

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

Próximas etapas

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

• Planejamento e implementação de Máquinas Virtuais do Azure para SAP NetWeaver
• Usar o Azure para hospedar e executar cenários de carga de trabalho do SAP

Recursos relacionados

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