Executar o SAP NetWeaver em 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 é AnyDB, o termo SAP para qualquer sistema de gerenciamento de banco de dados suportado (SGBD) além do SAP HANA.

Arquitetura

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

Transfira um ficheiro do Visio desta 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 da sua organização. O sistema pode ser reduzido a uma única VM. Neste guia, o layout da rede é muito simplificado para demonstrar os princípios da arquitetura. Não se destina a descrever uma rede empresarial completa.

Fluxo de Trabalho

Redes virtuais. O serviço de Rede Virtual do Azure conecta recursos do Azure entre si com segurança aprimorada. Nessa arquitetura, a rede virtual se conecta a uma rede local por meio de um gateway de Rota Expressa do Azure 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 do 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-and-spoke com várias redes virtuais que são emparelhadas juntas. Essa topologia fornece segmentação e isolamento de rede para serviços implantados no Azure. O emparelhamento permite uma conectividade transparente entre redes virtuais emparelhadas através da rede de backbone da Microsoft. Ele não incorre em uma penalidade de desempenho se implantado em uma única 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 o SAP Central Services e servidores de aplicativos SAP. Para alta disponibilidade, as VMs que executam os Serviços Centrais são configuradas em um cluster de failover do servidor 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 host bastião para se conectar a outras VMs. Normalmente, faz parte de serviços compartilhados, como serviços de backup. Se o SSH (Secure Shell Protocol) e o RDP (Remote Desktop Protocol) forem os únicos serviços usados para administração de servidor, um host do Azure Bastion é 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 de DNS privado. O DNS Privado do Azure fornece um serviço DNS confiável e seguro para sua rede virtual. O DNS Privado do Azure gerencia e resolve nomes de domínio na rede virtual, sem a necessidade de configurar uma solução DNS personalizada.

Balanceadores de carga. Para distribuir o tráfego para VMs na sub-rede da camada de aplicativo SAP para alta disponibilidade, recomendamos que você use 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 a sua seleção em:

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

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

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

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

O Standard SKU também suporta clusters SAP de identificador multissistema (multi-SID). Em outras palavras, vários sistemas SAP no Windows podem compartilhar uma infraestrutura comum de alta disponibilidade para economizar custos. Avalie a economia de custos e evite colocar muitos sistemas em um cluster. O Azure não suporta mais de cinco SIDs por cluster.

Gateway de aplicativo. O Gateway de Aplicativo do Azure é um balanceador de carga de tráfego da Web que você pode usar para gerenciar o tráfego para seus aplicativos Web. Os balanceadores de carga tradicionais operam na camada de transporte (camada OSI 4 - TCP e UDP). Eles roteiam o tráfego com base no endereço IP de origem e na porta para um endereço IP e uma porta de destino. O Application Gateway pode tomar decisões de roteamento com base em atributos adicionais de uma solicitação HTTP, como o caminho do URI ou cabeçalhos de host. Este tipo de encaminhamento é conhecido como balanceamento de carga da camada de aplicação (camada OSI 7).

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 de aplicativos. Para definir políticas 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 sua rede.

Gateway. Um gateway conecta redes distintas, estendendo sua rede local para a rede virtual do Azure. Recomendamos que você use a Rota Expressa para criar conexões privadas que não passem 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 ExpressRoute Global Reach e o ExpressRoute FastPath, conforme discutido mais adiante 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 uma pequena implantação 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 de servidores de aplicativos e clusters, ajuste o número de VMs com base em suas necessidades. Para obter informações detalhadas sobre como executar o SAP NetWeaver em VMs, consulte 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 SAP note 1928533. Para acessar as notas SAP, você precisa de uma conta do SAP Service Marketplace.

SAP Web Dispatcher

O componente Web Dispatcher é usado para balancear a carga do tráfego SAP entre os servidores de aplicativos SAP. Para obter alta disponibilidade 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 balanceiam 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 GUIs SAP e tráfego RFC.

Cluster SAP Central Services

Essa arquitetura executa os Serviços Centrais em VMs na camada de aplicativo. Os Serviços Centrais são um potencial ponto único de falha (SPOF) quando são implantados em uma única VM. Para implementar uma solução altamente disponível, use um cluster de compartilhamento de arquivos ou um cluster de disco compartilhado.

Para compartilhamentos de arquivos altamente disponíveis, há várias opções. Recomendamos que você use os compartilhamentos do Azure Files 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 do servidor Windows com os 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 do cluster. Se preferir usar discos compartilhados, recomendamos usar 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 SIOS DataKeeper Cluster Edition da SIOS Technology Corp. Este complemento replica o conteúdo de discos independentes que estão 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 quórum 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 quórum. 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 quórum 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 IP front-end do cluster do balanceador de carga. O Load Balancer suporta 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 do hub atua como um ponto central de conectividade com uma rede local. Os raios são redes virtuais que fazem par com o hub e isolam as cargas de trabalho do SAP. O tráfego flui entre o datacenter local e o hub por meio de uma conexão de gateway.

Placas de interface de rede (NICs)

As NICs permitem toda a comunicação entre VMs em uma rede virtual. As implantações SAP locais tradicionais implementam várias NICs por máquina para segregar o tráfego administrativo do tráfego comercial.

No Azure, a rede virtual é uma rede definida por software que envia todo o tráfego através da mesma malha de rede. Portanto, não é necessário usar várias NICs por motivos de desempenho. Mas se sua organização precisar segregar o tráfego, você poderá implantar várias 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 diferentes diretivas de controle de acesso.

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 obter um esboço completo, consulte 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 os servidores de aplicativos em uma sub-rede separada. Ao fazer isso, você pode protegê-los mais facilmente gerenciando as políticas de segurança da sub-rede em vez dos servidores individuais.

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

Alcance Global do ExpressRoute

Se o seu ambiente de rede incluir duas ou mais conexões de Rota Expressa, o Alcance Global da Rota Expressa pode ajudá-lo a reduzir os saltos e a latência da rede. Essa tecnologia é um emparelhamento de rotas BGP (Border Gateway Protocol) configurado entre duas ou mais conexões de Rota Expressa para fazer a ponte entre dois domínios de roteamento de Rota Expressa. O alcance global reduz a latência quando o tráfego de rede atravessa mais de uma conexão de Rota Expressa. Atualmente, está disponível apenas para emparelhamento privado em circuitos de Rota Expressa.

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

ExpressRoute FastPath

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

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

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

Balanceadores de carga

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

O Azure Load Balancer é um serviço de camada de transmissão de rede (camada 4) que equilibra o tráfego usando um hash de cinco tuplas dos fluxos de dados. O hash é baseado em IP de origem, porta de origem, IP de destino, porta de destino e tipo de protocolo. Em implantações SAP no Azure, o Balanceador de Carga é usado em configurações de cluster para direcionar o tráfego para a instância de serviço principal ou para o nó íntegro se houver uma falha.

Recomendamos que você use o 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 Balanceador de Carga Padrão 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 armazenamento padrão para seus servidores de aplicativos. Não há suporte para discos gerenciados padrão. Consulte a nota SAP 1928533. Para acessar as notas 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.

Os servidores de aplicativos não hospedam dados corporativos. 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 central de pilha SAP.

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 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 pelo Cloud Witness para manter o quórum 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 legal e de arquivamento 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 SSD Premium v2 do Azure foi concebido para cargas de trabalho críticas em termos de desempenho, como sistemas de processamento de transações online que necessitam consistentemente de latência inferior a milissegundos combinada com IOPS e débito elevados.

O Ultra Disk Storage reduz significativamente 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 de bloco no Azure, consulte Tipos de disco gerenciado do Azure.

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

Considerações de 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 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, as instâncias de VM com quatro ou mais vCPUs suportam Rede Acelerada.

Para obter IOPS e taxa de transferência de disco altas, siga as práticas comuns na otimização do 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. A ativação da cache de leitura no conteúdo de armazenamento alterado com pouca frequência melhora a velocidade de obtenção de dados.

SSD Premium v2 oferece maior desempenho do que SSDs Premium e geralmente é mais barato. Pode definir um disco SSD Premium v2 para qualquer tamanho suportado que preferir e fazer ajustes granulares ao desempenho sem tempo de inatividade.

O armazenamento em disco Ultra está disponível para aplicativos com uso intensivo de E/S. Quando esses discos estiverem disponíveis, recomendamos 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 colocação de proximidade

Algumas aplicações SAP requerem uma comunicação frequente com a base de dados. A proximidade física do aplicativo e das camadas do banco de dados afeta a latência da rede, o que pode afetar negativamente o desempenho do aplicativo.

Para otimizar a latência da 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 colocalização e o desempenho em detrimento da escalabilidade, disponibilidade ou custo. Eles podem melhorar muito a experiência do usuário para a maioria dos aplicativos SAP. Para scripts que estão 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 dentro de uma região específica do Azure. O 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 poderem 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 você usou para teste. Como alternativa, considere usar uma ferramenta de verificação de latência entre zonas do Azure.

Considerações de escalabilidade

Para a camada de aplicativos SAP, o Azure oferece uma ampla variedade de tamanhos de VM para expansão e dimensionamento. Para obter uma lista inclusiva, consulte SAP note 1928533 - SAP Applications on Azure: Supported Products and Azure VM Types. Para acessar as notas SAP, você precisa de uma conta do SAP Service Marketplace.

É possível dimensionar os servidores de aplicativos SAP e os clusters dos Serviços Centrais para cima e para baixo. Você também pode dimensioná-los ou alterando o número de instâncias usadas. O banco de dados AnyDB pode ser dimensionado para cima e para baixo, mas não é dimensionado. O contêiner de banco de dados SAP para AnyDB não suporta fragmentação.

Considerações de disponibilidade

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

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 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 (incluindo entre zonas, dentro de uma única zona ou em uma região sem zonas), consulte Arquitetura e cenários de alta disponibilidade para SAP NetWeaver.

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

Web Dispatcher na camada de servidores de aplicativos

O componente Web Dispatcher é usado como um balanceador de carga para o tráfego 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 satisfazer as preocupações de segurança.

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

Serviços Centrais na camada de servidores de aplicativos

A alta disponibilidade dos Serviços Centrais é implementada com um cluster de failover do servidor 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 da nuvem. Outra maneira é usar o Azure NetApp Files, que fornece compartilhamentos NFS e SMB de alto desempenho de classe empresarial.

• 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 do servidor Windows para 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:

  • Replique o conteúdo de discos independentes conectados aos nós do cluster.
  • Abstraia as unidades como um volume compartilhado de cluster para o gerenciador de cluster.

  Para obter detalhes de implementação, consulte Clustering SAP ASCS on Azure with 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 para as respostas do servidor ignorarem o balanceador de carga. Essa conexão direta evita que o balanceador de carga se torne um gargalo no caminho de transmissão de dados. Recomendamos que você habilite o DSR para o ASCS e clusters de banco de dados.

Serviços de aplicativos na camada de servidores de aplicativos

A alta disponibilidade para os servidores de aplicativos 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 o 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 base 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 de banco de dados específicos, consulte Implantação do 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 VMs contra interrupçõ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.

Em 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 da rede dentro de uma zona e entre as zonas de destino. Você também precisa saber o quão sensíveis seus aplicativos implantados são à latência da rede.

Leve estas considerações em consideração ao decidir implantar recursos em zonas de disponibilidade:

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

Exemplo de implantação ativa/inativa

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

Os clusters de dois nós para os Serviços Centrais e 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 colocalizados na mesma zona, a latência da rede é minimizada.

Exemplo de implantação ativa/ativa

Em uma implantação ativa/ativa , dois conjuntos de servidores de aplicativos são criados em duas zonas. 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 as operações normais.

Os Serviços Centrais e os serviços de banco de dados são executados na zona 1. Os servidores de aplicativos na zona 2 podem ter maior latência de rede quando se conectam aos Serviços Centrais 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 on-line para fornecer capacidade total para processamento de aplicativos.

Considerações sobre DR

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

Considerações sobre gerenciamento e operações

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

Azure Center for SAP solutions

O Azure Center for SAP solutions é uma solução ponto a ponto que permite criar e executar sistemas SAP como uma carga de trabalho unificada no Azure e proporciona uma base mais integrada de inovação. Além disso, a experiência de implantação guiada do Centro do Azure para soluções SAP cria os componentes de computação, armazenamento e rede necessários para executar seu sistema SAP. Em seguida, ele ajuda você a automatizar a instalação do software SAP de acordo com as práticas recomendadas da Microsoft. Pode tirar partido das capacidades de gestão para sistemas SAP novos e existentes do Azure. Para obter mais informações, consulte Central do Azure para soluções SAP.

Se você precisar de mais controle sobre eventos de manutenção ou isolamento de hardware, seja 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 Objetive, 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 do Azure Files para fazer backup de arquivos de banco de dados do SQL Server.

• Para SAP em Oracle/Windows, consulte a seção "Backup/restauração" em Azure VM DBMS Deployment for SAP.

• Para outros bancos de dados, consulte as recomendações de backup para 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 VSS para backups consistentes com o aplicativo.

Gestão de identidades

Use um sistema centralizado de gerenciamento de identidades, como o Microsoft Entra ID e os Serviços de Domínio Ative Directory (AD DS), para controlar o acesso aos recursos em todos os níveis:

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

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

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

Monitorização

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

Considerações de segurança

A SAP tem seu próprio mecanismo de gerenciamento de usuários (UME) para controlar o acesso e a autorização baseados em funções dentro do aplicativo SAP e dos bancos de dados. Para obter orientações detalhadas sobre segurança de aplicativos, consulte SAP NetWeaver Security Guide.

Para obter 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 para o Web Dispatcher.

Você pode implantar um NVA para filtrar o tráfego entre redes virtuais, mas não o coloque 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 falhas de rede ou de nó clusterizado.

Para 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 do aplicativo.

Você pode usar a Criptografia de Disco do Azure para criptografar discos de VM do Windows. Este serviço utiliza a funcionalidade BitLocker do Windows para fornecer encriptação de volume para o sistema operativo e os discos de dados. A solução também funciona com o Azure Key Vault para ajudá-lo a controlar e gerenciar as chaves e segredos de criptografia de disco em sua assinatura do cofre de chaves. Os dados nos discos de VM são criptografados em repouso em seu 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 de máquinas virtuais do Azure do SQL Server para SAP NetWeaver.

Para monitorar ameaças de dentro e de fora do firewall, considere implantar o Microsoft Sentinel (visualização). A solução fornece deteção e análise contínuas de ameaças para sistemas SAP implantados no Azure, em outras nuvens ou localmente. Para obter diretrizes de implantação, consulte Implantar 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ção. Considere o uso de uma abordagem de automação de ponta a ponta para essa tarefa.

Considerações de custos

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

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

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

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

Use VMs spot do Azure para executar cargas de trabalho que podem ser interrompidas e não exigem conclusão dentro de um período de tempo predeterminado ou de um SLA. O Azure implanta VMs spot quando há capacidade disponível e as remove quando precisa da capacidade de volta. Os custos associados a VMs spot são menores do que para outras VMs. Considere VMs spot para estas cargas de trabalho:

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

As Instâncias de Máquina Virtual Reservadas do Azure podem reduzir o custo total de propriedade combinando as taxas das Instâncias de Máquina Virtual Reservadas do Azure com uma assinatura paga conforme o uso, para que você possa gerenciar custos em cargas de trabalho previsíveis e variáveis. Para obter mais informações, consulte Instâncias de máquina virtual reservadas do Azure.

Balanceador de Carga

Nesse cenário, o Balanceador de Carga é usado para distribuir tráfego para VMs na sub-rede da camada de aplicativo.

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

ExpressRoute

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

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

Comunidades

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

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

Contribuidores

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

Autor principal:

• Ben Trinh - Brasil | Arquiteto Principal

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

Próximos passos

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

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

Recursos relacionados

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