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 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 máquina virtual (VM) que você pode alterar para acomodar as necessidades de sua organização. O sistema pode ser reduzido 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.

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 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 de hub é usada para serviços compartilhados, como o Bastião do Azure 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 e isolamento de rede para serviços 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 do Windows para executar os SAP Central Services e os servidores de aplicativos SAP. Para alta disponibilidade, as VMs que executam os Serviços Centrais são configuradas em um cluster de failover de servidor do Windows. Eles são suportados por 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 pode ser Microsoft SQL Server, Oracle ou IBM Db2.

• Serviço de bastião. Os administradores usam uma VM de segurança aprimorada chamada de host bastion para se conectar a outras VMs. Normalmente, faz parte de serviços compartilhados, como serviços de backup. Se o protocolo SSH (Secure Shell Protocol) e o protocolo RDP (Remote Desktop Protocol) forem os únicos serviços usados para administração do servidor, um host do Bastião do Azure será uma boa solução. Se você usar outras ferramentas de gerenciamento, como o SQL Server Management Studio ou o SAP Frontend, use uma caixa de salto tradicional e autoimplantada.

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 na rede virtual, sem a necessidade de configurar uma solução DNS personalizada.

Balanceadores de carga. Para distribuir o tráfego para VMs na sub-rede da camada de aplicativo SAP para alta disponibilidade, recomendamos que você use um balanceador de carga padrão do Azure. Observe que um balanceador de carga padrão fornece um nível de segurança por padrão. As VMs que estão atrás de um balanceador de carga padrão 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 padrão do balanceador de carga. 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).

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.

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

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

O SKU padrão também oferece 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 economizar 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 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).

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

Grupos de segurança do aplicativo. Para definir diretivas de segurança de rede refinadas e baseadas em carga de trabalho centradas em aplicativos, use grupos de segurança de aplicativos em vez de endereços IP explícitos. Os grupos de segurança de aplicativos 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 com base nos 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 Planejamento e implementação de máquinas virtuais do Azure para SAP NetWeaver.

Para obter detalhes sobre o suporte SAP para tipos de VM do Azure e métricas de taxa de transferência (SAPS), consulte a nota SAP 1928533. Para acessar as notas do 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 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, consulte 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 lote e RZ12 para grupos de chamada de função remota (RFC), também balanceam 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 os Serviços Centrais 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. Recomendamos que você use 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 dos Serviços Centrais usando um cluster de failover de servidor do Windows com Arquivos do Azure. Essa solução também oferece suporte a um cluster do Windows com discos compartilhados usando um disco compartilhado do Azure como o volume compartilhado do cluster. Se você preferir usar discos compartilhados, recomendamos que use discos compartilhados do Azure para configurar um cluster de failover do Windows Server para cluster do SAP Central Services.

Há também produtos parceiros como o SIOS DataKeeper Cluster Edition da SIOS Technology Corp. Esse complemento replica o conteúdo de discos independentes conectados aos nós de cluster 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 de cluster, o software de cluster usará votos de quorum para selecionar um segmento da rede e seus serviços associados para servir como o cérebro do cluster fragmentado. O Windows oferece muitos modelos de quorum. Essa solução usa o Cloud Witness porque é 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 uma votação de quorum de cluster.

Em uma implantação do Azure, os servidores de aplicativos se conectam aos Serviços Centrais altamente disponíveis usando os nomes de host virtual dos serviços 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 oferece suporte a vários IPs front-end, portanto, os IPs virtuais (VIPs) ASCS e ERS podem ser vinculados 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 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 do 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 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 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 de Rota Expressa para fazer a ponte de dois domínios de roteamento de Rota Expressa. 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.

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 foi projetado 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 para 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 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. 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 Balanceador de Carga do Azure é um serviço de camada de transmissão de rede (camada 4) que equilibra o tráfego usando um hash de cinco tuplas dos 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. Em implantações SAP no Azure, 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 que você use 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. Eles não permitem conectividade de saída, a menos que você a configure explicitamente.

Para o tráfego de clientes SAP GUI que se conectam a um servidor SAP via protocolo DIAG ou RFC, o servidor de mensagens dos Serviços Centrais equilibra a carga 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 do SAP, você precisa de uma conta do SAP Service Marketplace. Recomendamos que você use 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. Assim, você também pode usar os discos premium P4 e P6 menores para ajudar a minimizar os custos. Ao fazer isso, você pode se beneficiar do SLA de VM de instância única se tiver uma instalação de 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 do SSD Premium do Azure e o Armazenamento em 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 pelo Cloud Witness para manter o quorum com um dispositivo em uma região remota do Azure, longe da região primária onde o cluster reside.

Para o armazenamento de dados de backup, recomendamos as camadas de acesso aos arquivos e esporádico do Azure. Esses níveis de armazenamento fornecem uma maneira econômica de armazenar dados de longa duração 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 alta IOPS e taxa de transferência.

O Ultra Disk Storage reduz consideravelmente a latência do disco. Como resultado, ele beneficia aplicativos críticos de desempenho, como os servidores de banco de dados SAP. Para comparar opções de armazenamento em bloco no Azure, consulte 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 o Oracle e também quando hospeda dados de aplicativos.

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 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 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 alta IOPS e taxa de transferência de disco, 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, você pode posicionar vários discos juntos para criar um volume de disco distribuído para melhorar 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 Ultra Disk Storage está disponível para aplicativos com uso intensivo de E/S. Quando esses discos estiverem disponíveis, nós os recomendamos sobre o armazenamento premium do Write Accelerator . Você pode aumentar ou diminuir individualmente métricas de desempenho, como IOPS e MBps, sem precisar reinicializar.

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

Não há suporte para o posicionamento de um dispositivo virtual de rede (NVA) entre o aplicativo e as camadas 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 de proximidade, que definem uma restrição lógica nas VMs implantadas em conjuntos de disponibilidade. Os grupos de posicionamento de proximidade favorecem a co-localização e o desempenho em detrimento da escalabilidade, disponibilidade ou 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 do SAP, consulte 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. Seu objetivo é melhorar a disponibilidade do serviço. Mas a implantação de recursos entre zonas pode aumentar a latência, portanto, tenha em mente as 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 forem concluídos, remova as VMs que você usou para teste. 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 aplicativos SAP, o Azure oferece uma ampla variedade de tamanhos de VM para expansão e expansão. Para obter uma lista inclusiva, consulte SAP note 1928533 - SAP Applications on Azure: Supported Products and Azure VM Types. Para acessar as notas do SAP, você precisa de uma conta do SAP Service Marketplace.

Você pode escalar os servidores de aplicativos SAP e os clusters dos Serviços Centrais para cima e para baixo. Você também pode dimensioná-los para fora ou para dentro 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, 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.

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áquina Virtual com orquestração flexível (FD=1), zonas de disponibilidade e conjuntos de disponibilidade, para aprimorar 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), consulte 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 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, recomendamos uma solução autônoma na rede de perímetro, que também é conhecida como DMZ, 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.

Central Services na camada de servidores de aplicativos

A alta disponibilidade dos Serviços Centrais é implementada com um cluster de failover de servidor do Windows. 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, recomendamos que você use discos compartilhados do Azure para configurar um cluster de failover de servidor do Windows para o SAP Central Services. Para obter um exemplo de implementação, consulte Cluster 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.
  • Abstraia 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, poderá 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 (Direct Server Return), que também é chamado de IP flutuante. Isso fornece uma maneira de as respostas do servidor ignorarem 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. Recomendamos que você habilite o DSR para o ASCS e clusters de 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 de software de cluster, SAP Web Dispatcher ou balanceador de carga do Azure. 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 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 nativa da camada de banco de dados fornece 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. Ele foi projetado para melhorar a disponibilidade da carga de trabalho e proteger 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 falha. Quando você seleciona a implantação zonal, 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 que dão suporte a várias zonas, pelo menos três zonas estão disponíveis. 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 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/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 é 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 os serviços de 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 agora 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. 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 Serviços Centrais 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 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 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.

Se você 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

Os bancos de dados são cargas de trabalho críticas que exigem um RPO (Recovery Point Objective, objetivo de ponto de recuperação) baixo 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 oferecer 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 os Serviços de Domínio Active Directory (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 LDAP (Lightweight Directory Access Protocol), ID do Microsoft Entra, 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, 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 para soluções SAP 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 orientações detalhadas sobre segurança de aplicativos, consulte o Guia de segurança do SAP NetWeaver.

Para obter mais segurança de rede, considere usar uma rede de perímetro que use um NVA para criar um firewall na frente da sub-rede para o 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, consulte 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 de aplicativos.

Você pode usar a Criptografia de Disco do Azure para criptografar discos de VM do 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 ajudá-lo a controlar e gerenciar os segredos e chaves de criptografia de disco em sua assinatura do Key Vault. Os dados nos discos de VM são criptografados em repouso no armazenamento do Azure.

Para criptografia de dados em repouso, a TDE (criptografia de dados transparente) do SQL Server criptografa arquivos de dados do SQL Server, do Banco de Dados SQL do Azure e do 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 (visualização). 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 orientações de implantação, consulte 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 restritos de VM vCPU para reduzir os custos de licenciamento de software cobrados por vCPU.

VMs

Essa arquitetura usa VMs para a camada de aplicativo e a camada de banco de dados. A camada SAP NetWeaver usa VMs do 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 caixas de salto 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 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 predeterminado ou um SLA. 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, consulte Instâncias de máquina virtual reservadas do Azure.

Load Balancer

Nesse cenário, o balanceador de carga é usado para distribuir o tráfego para 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 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.

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 para 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:

• 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