Executar SAP BW/4HANA para máquinas virtuais do Linux no Azure

Azure Bastion
Azure Managed Disks
Máquinas Virtuais do Azure
Rede Virtual do Azure
SAP HANA em Instâncias Grandes do Azure

O exemplo a seguir se concentra especificamente na camada de aplicativo do SAP BW/4HANA. Ele é adequado para um ambiente de produção de pequena escala do SAP BW/4HANA no Azure, em que a alta disponibilidade é uma prioridade.

Arquitetura

A arquitetura de referência mostra um conjunto de práticas comprovadas para executar o SAP HANA em um ambiente de expansão de alta disponibilidade que oferece suporte à recuperação de desastres no Azure.

Baixe um Arquivo Visio dessa arquitetura.

Componentes

Essa arquitetura faz uso das seguintes tecnologias:

  • A VNet (Rede Virtual) do Azure conecta com segurança os recursos do Azure uns aos outros e a um ambiente local. Nessa arquitetura, diversas VNets são emparelhadas em conjunto.

  • As máquinas virtuais Linux são usadas para a camada de aplicativo, incluindo:

    • O pool de servidores do SAP BOBJ (BusinessObjects).
    • O pool do SAP Web Dispatcher.
    • O pool de servidores de aplicativos.
    • O cluster do SAP Central Services.
  • Os balanceadores de carga direcionam o tráfego para máquinas virtuais na sub-rede do aplicativo. Para a alta disponibilidade, este exemplo usa o SAP Web Dispatcher e o Azure Standard Load Balancer. Esses dois serviços também dão suporte à extensão de capacidade por expansão, mas também é possível usar o Gateway de Aplicativo do Azure ou outros produtos de parceiros, dependendo do tipo de tráfego e da funcionalidade necessária, como término e encaminhamento de SSL (Secure Sockets Layer).

  • Os NSGs (grupos de segurança de rede) anexados a uma sub-rede ou aos NICs (cartões de interface de rede) em uma máquina virtual. Os NSGs são usados para restringir o tráfego de entrada, de saída e interno da sub-rede na rede virtual.

  • O Azure Bastion fornece acesso seguro por meio do portal do Azure a máquinas virtuais executadas no Azure, sem usar um jumpbox e o endereço IP público associado. Esse mecanismo limita a exposição à Internet.

  • Azure Managed Disks. Discos de armazenamento Premium ou Ultra são recomendados. Esses tipos de armazenamento fornecem persistência de dados para máquinas virtuais com a carga de trabalho SAP.

  • O Azure NetApp Files dá suporte ao armazenamento compartilhado com o uso de um cluster. Ele também é compatível com o armazenamento compartilhado quando você precisa de um armazenamento de alto desempenho capaz de hospedar dados e arquivos de log do SAP HANA. O Azure NetApp Files é totalmente gerenciado e escalonável o suficiente para atender às demandas da maioria dos aplicativos. Ele oferece desempenho bare metal, latência abaixo de milissegundos e gerenciamento de dados integrado para suas cargas de trabalho corporativas complexas nos seguintes:

    • SAP HANA.
    • Computação de alto desempenho.
    • Aplicativo de LOB.
    • Compartilhamentos de arquivos de alto desempenho.
    • Infraestruturas de área de trabalho virtual.
  • O Power BI permite que os usuários acessem e visualizem dados do SAP BW/4HANA na área de trabalho do Windows. A instalação requer o Conector do SAP BW (implementação 2.0).

    O Microsoft Power BI Desktop importa dados de diversas fontes SAP, como o SAP BW/4HANA, para análise e visualização. Ele também complementa o SAP BusinessObjects Universe, oferecendo um contexto de negócios ou uma camada semântica sobre as informações brutas.

  • O Backup do Azure é uma solução de proteção de dados certificada pelo SAP Backint para o SAP HANA em implantações de instância única com capacidade de expansão. O Backup do Azure também protege as Máquinas Virtuais do Azure com cargas de trabalho gerais.

  • O Azure Site Recovery é recomendado como parte de uma solução automatizada de recuperação de desastre para uma implantação de aplicativos SAP NetWeaver multicamadas. A matriz de suporte detalha os recursos e as restrições desta solução.

Alternativas

  • Para ajudar a proteger os arquivos de host global do SAP para o SAP Central Services e o diretório de transporte SAP, implante servidores NFS (Network File System) em uma configuração de cluster de failover.

  • O SIOS Protection Suite, disponível no Azure Marketplace, pode ser usado para proteger os arquivos de host globais para o Central Services, em vez de o NFS ou o Azure NetApp Files.

  • O Gateway de Aplicativo do Azure é um balanceador de carga de tráfego da Web. Em um serviço, ele fornece terminação de SSL, um serviço de WAF (Firewall de Aplicativo Web) e outros recursos úteis de alta disponibilidade e escalabilidade. Algumas implantações do SAP o usaram como gateway para o front-end do SAP Fiori em cenários de produção.

Detalhes do cenário

O SAP BW/4HANA é uma solução de data warehouse corporativa que foi projetada para a nuvem e otimizada para a plataforma SAP HANA. O exemplo a seguir se concentra especificamente na camada de aplicativo do SAP BW/4HANA. Ele é adequado para um ambiente de produção de pequena escala do SAP BW/4HANA no Azure, em que a alta disponibilidade é uma prioridade.

Esta carga de trabalho de exemplo também se baseia em duas arquiteturas de referência do SAP no Azure: o SAP NetWeaver (Windows) para AnyDB em máquinas virtuais e o SAP S/4HANA para máquinas virtuais Linux no Azure. Uma abordagem de implantação semelhante é usada para cargas de trabalho do SAP BW/4HANA. A camada de aplicativo é implantada usando máquinas virtuais que podem ser alteradas em tamanho para acomodar as necessidades de sua organização.

O layout de rede foi simplificado para demonstrar os princípios de arquitetura recomendados para uma implantação corporativa do Azure com base em uma topologia hub-spoke.

Observação

Muitas considerações de implantação se aplicam ao implantar cargas de trabalho SAP no Azure. Para saber mais ideias e informações, confira a lista de verificação de planejamento e implantação do SAP no Azure.

Para obter detalhes sobre a camada de persistência de dados, veja o seguinte:

Possíveis casos de uso

Esse cenário é relevante para os seguintes casos de uso:

  • Implantação da camada de aplicativo do SAP separada da camada DBMS

  • Cenários de DR (recuperação de desastre)

  • Implantações da camada de aplicativo do SAP

Recomendações

Essa arquitetura foi projetada para alta disponibilidade, escalabilidade e resiliência. Para obter os melhores resultados no Azure, considere as recomendações nesta seção. Além disso, muitas das recomendações para executar o SAP S/4HANA no Azure também se aplicam às implantações do SAP BW/4HANA. Para obter detalhes sobre o SAP S/4HANA no Azure, confira a arquitetura de referência.

Máquinas virtuais

Para obter detalhes sobre o suporte do SAP para tipos de máquina virtual do Azure e métricas de taxa de transferência (SAPS), veja a Nota do SAP 1928533, "Aplicativos SAP no Azure: produtos e tipos de máquina virtual do Azure com suporte". (Para acessar esta nota e outras do SAP, é necessário ter uma conta do SAP Service Marketplace.)

Para saber se um tipo de máquina virtual foi certificado para implantações escaláveis do SAP HANA, confira a coluna "Expansão" no Diretório de hardware do SAP HANA.

Pool de servidores de aplicativos

No pool de servidores de aplicativos, é possível ajustar o número de máquinas virtuais com base em seus requisitos. O Azure é certificado para executar o SAP BW/4HANA no Red Hat Enterprise Linux e no SUSE Linux Enterprise.

Para gerenciar grupos de logon para servidores de aplicativos ABAP, é comum usar a transação SMLG que balanceia a carga de diferentes grupos, como:

  • Usuários de logon.
  • SM61 para grupos de servidores em lote.
  • RZ12 para grupos RFC.

Essas transações usam o recurso de balanceamento de carga no servidor de mensagens do 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

Este exemplo mostra um cluster altamente disponível que usa o Azure NetApp Files como uma solução de armazenamento de arquivos compartilhados. A alta disponibilidade do cluster do Central Services requer armazenamento compartilhado. O Azure NetApp Files fornece uma opção simples e altamente disponível para que não seja necessário implantar uma infraestrutura de cluster Linux. Uma alternativa é configurar um serviço NFS altamente disponível.

Também é possível implantar o Central Services em uma única máquina virtual com discos gerenciados Premium e obter um SLA de disponibilidade de 99,9%.

As máquinas virtuais usadas para os servidores de aplicativos dão suporte a diversos endereços IP por NIC. Este recurso dá suporte à prática recomendada pela SAP de usar nomes de host virtual para instalações, conforme descrito na Nota do SAP 962955. Os nomes de host virtual separam os serviços SAP dos nomes de host físico e facilitam a migração de serviços de um host físico para outro. Esse princípio também se aplica a máquinas virtuais na nuvem.

Os servidores de aplicativos são conectados ao Central Services altamente disponível no Azure por meio dos nomes de host virtual do Central Services ou dos serviços de ERS. Esses nomes de host são atribuídos à configuração de IP de front-end do cluster do balanceador de carga. Um balanceador de carga dá suporte a muitos IPs de front-end. Os VIPs (IPs virtuais) do Central Services e do ERS podem ser vinculados a um balanceador de carga.

Instalação multi-SID

O Azure também dá suporte à alta disponibilidade em uma instalação multi-SID dos clusters Linux e Windows que hospedam o Central Services (ASCS/SCS). Para obter detalhes sobre a implantação em um cluster do Pacemaker, confira a documentação do Azure multi-SID para o seguinte:

Grupos de posicionamento por proximidade

Esta arquitetura de exemplo também usa um grupo de posicionamento por proximidade para reduzir a latência de rede entre máquinas virtuais. Esse tipo de grupo impõe uma restrição de local às implantações de máquinas virtuais e minimiza a distância física entre elas. O posicionamento do grupo varia da seguinte forma:

  • Em uma instalação de SID único, é necessário colocar o Central Services e todos os servidores de aplicativos no grupo de posicionamento por proximidade ancorado pelo banco de dados SAP HANA.

  • Em uma instalação multi-SID, você tem a liberdade de associar o Central Services e os servidores de aplicativos a qualquer grupo de posicionamento por proximidade único ancorado por contêineres SAP HANA de diferentes SIDs.

Backup de banco de dados

O SAP BW/4HANA foi desenvolvido para a plataforma de banco de dados do SAP HANA. O Azure oferece as três seguintes opções de escalabilidade e implantação:

Armazenamento

Este exemplo usa discos gerenciados Premium para o armazenamento não compartilhado dos servidores de aplicativos. Ele também usa o Azure NetApp Files para armazenamento compartilhado de cluster.

O SSD Premium v2 do Azure foi projetado para cargas de trabalho críticas de desempenho, como o SAP. Consulte Implantar um SSD Premium v2 para obter informações sobre os benefícios e as limitações atuais da solução de armazenamento.

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 em bloco no Azure, consulte Tipos de disco gerenciado do Azure.

Não há suporte para discos gerenciados padrão, conforme indicado na Nota do SAP 1928533. O uso do armazenamento padrão não é recomendado para nenhuma instalação do SAP.

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

Rede

Embora não seja necessário, é comum implantar uma topologia hub-spoke para fornecer isolamento lógico e limites de segurança para um cenário do SAP. Para obter mais detalhes de rede, confira a Arquitetura de referência do SAP S/4HANA.

A VNet do hub atua como um ponto central de conectividade com uma rede local. Os spokes são VNets que fazem peering com o hub e podem ser usados para isolar cargas de trabalho. O tráfego flui entre o datacenter local e o hub por meio de uma conexão de gateway.

A maioria das implementações de clientes inclui um ou mais circuitos do ExpressRoute que conectam redes locais ao Azure. Para uma demanda de largura de banda de rede menor, a VPN é uma alternativa de baixo custo.

Considerações

Essas considerações implementam os pilares do Azure Well-Architected Framework, que é um conjunto de princípios de orientação que podem ser usados para aprimorar a qualidade de uma carga de trabalho. Para obter mais informações, confira Microsoft Azure Well-Architected Framework.

Eficiência de desempenho

A eficiência do desempenho é a capacidade de dimensionar sua carga de trabalho para atender às demandas colocadas por usuários de maneira eficiente. Para saber mais, confira Visão geral do pilar de eficiência de desempenho.

O SAP BW/4HANA foi projetado para tarefas de data warehousing em tempo real. Os servidores de aplicativos SAP mantêm comunicações constantes com os servidores de banco de dados, portanto, minimizar a latência das máquinas virtuais do aplicativo para o banco de dados contribui para um melhor desempenho do aplicativo. O cache de disco e o posicionamento do servidor são duas estratégias que ajudam a reduzir a latência entre esses dois componentes.

Para aplicativos de desempenho crítico executados em qualquer plataforma de banco de dados, incluindo o SAP HANA, use discos gerenciados Premium e habilite o Acelerador de Gravação para o volume de log. O Acelerador de Gravação está disponível para máquinas virtuais da série M e melhora a latência de gravação. No entanto, quando a opção estiver disponível, use discos gerenciados Ultra no lugar de discos Premium sem o Acelerador de Gravação. Os recursos de disco Ultra continuam sendo aprimorados. Para ver se esses discos atendem aos seus requisitos, examine as informações mais recentes sobre o escopo de serviço dos discos Ultra. Faça isso especialmente se sua implementação incluir recursos de resiliência do Azure, como conjuntos de disponibilidade, zonas de disponibilidade e replicação entre regiões.

Para ajudar no desempenho reduzindo a distância física entre os aplicativos e o banco de dados, use um grupo de posicionamento por proximidade, conforme mencionado anteriormente. Scripts e utilitários estão disponíveis no GitHub.

Para otimizar as comunicações entre servidores, use a Rede Acelerada, que está disponível para máquinas virtuais com suporte, incluindo D/DSv2, D/DSv3, E/ESv3, F/FS, FSv2 e Ms/Mms. Em todas as implementações do SAP, a Rede Acelerada é necessária, especialmente quando o Azure NetApp Files é usado.

Para obter alta E/S por segundo e taxa de transferência de largura de banda de disco, siga as práticas comuns de otimização do desempenho do volume de armazenamento que se aplicam ao layout de armazenamento do Azure. Por exemplo, a combinação de vários discos em conjunto para criar um volume de discos distribuídos melhora 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.

Escalabilidade

Esta arquitetura de exemplo descreve uma implantação pequena em nível de produção com flexibilidade de dimensionamento de acordo com os requisitos.

Na camada de aplicativo do SAP, o Azure oferece uma ampla variedade de tamanhos de máquina virtual para expansão e dimensionamento. Para obter uma lista completa, confira a Nota do SAP 1928533. À medida que continuamos a certificar mais tipos de máquinas virtuais, é possível aumentar ou diminuir a capacidade de expansão na mesma implantação de nuvem.

Disponibilidade

A redundância de recursos é o tema geral em soluções de infraestrutura altamente disponíveis. Se sua organização tiver um SLA menos rigoroso, use máquinas virtuais de instância única com discos Premium, que oferecem um SLA de tempo de atividade.

Para maximizar a disponibilidade do aplicativo, é possível implantar recursos redundantes em um conjunto de disponibilidade ou em Zonas de Disponibilidade. Para saber mais, veja a Arquitetura de referência do SAP S/4HANA.

Essa arquitetura faz com que as máquinas virtuais desempenhem a mesma função em um conjunto de disponibilidade. Ela ajuda a atender aos SLAs protegendo você contra o tempo de inatividade causado pela manutenção da infraestrutura do Azure e por interrupções não planejadas. São necessárias duas ou mais máquinas virtuais por conjunto de disponibilidade para obter um SLA mais alto.

Azure Load Balancer

O Azure Load Balancer é um serviço de camada de transmissão de rede (camada 4). Nas configurações de cluster, o Balanceador de Carga do Azure direciona o tráfego para a instância do serviço primário ou para o nó íntegro se houver uma falha. Recomendamos usar o Azure Standard Load Balancer para todos os cenários do SAP. Ele oferece implementação de segurança integrada e bloqueia o tráfego de saída do pool de back-end, a menos que você habilite a conectividade de saída com pontos de extremidade públicos. Além disso, você também pode usar um Gateway NAT do Azure para obter conectividade de saída.

Além disso, se você decidir implantar cargas de trabalho SAP nas Zonas de Disponibilidade do Azure, o Standard Load Balancer terá reconhecimento de zona.

Web Dispatcher

Neste projeto de exemplo, o SAP Web Dispatcher é usado simplesmente como um mecanismo de balanceamento de carga HTTP(s), para o tráfego SAP entre os servidores de aplicativos SAP. Para obter alta disponibilidade para o componente Web Dispatcher, o Azure Load Balancer implementa o cluster de failover ou a configuração paralela do Web Dispatcher. Veja SAP Web Dispatcher na documentação do SAP.

Como um balanceador de carga de software, o Web Dispatcher oferece serviços de camada extra que podem fazer terminação de SSL e outras funções de descarregamento. Esses serviços de camada são conhecidos como camada 7 no modelo de rede ISO.

Nenhum outro balanceador de carga é necessário para o tráfego de clientes da GUI do SAP que conectam um servidor SAP por meio do protocolo DIAG ou RFC (Remote Function Calls). O servidor de mensagens do Central Services balanceia a carga por meio de grupos de logon no servidor de aplicativos SAP.

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 Azure Load Balancer implementa o cluster de failover ou a configuração paralela do Web Dispatcher.

Para comunicações com a Internet, uma solução autônoma em uma DMZ seria a arquitetura recomendada para atender às preocupações de segurança.

O Embedded Web Dispatcher no ASCS é uma opção especial, e é preciso levar em consideração o dimensionamento adequado devido à carga de trabalho extra no ASCS.

Serviços Centrais

Para proteger a ASCS (disponibilidade do SAP Central Services) em máquinas virtuais Linux do Azure, é necessário usar a HAE (extensão de alta disponibilidade) apropriada para sua distribuição Linux selecionada. A HAE fornece componentes de software de cluster Linux e de integração específicos do sistema operacional para implementação.

Para evitar um problema de divisão de cluster, configure o fencing do nó de cluster usando um SBD (dispositivo de bloco STONITH) iSCSI, como mostra o exemplo a seguir. Também é possível usar o Azure Fence Agent. O Azure Fence Agent aprimorado fornece failover de serviço muito mais rápido em comparação com a versão anterior do agente para ambientes do Red Hat e do SUSE.

Outros servidores de aplicativos na camada de servidores de aplicativos

Para obter alta disponibilidade para os servidores de aplicativos SAP primários e para outros servidores de aplicativos, balanceie a carga do tráfego dentro do pool de servidores de aplicativos.

Recuperação de desastre

O Azure dá suporte a diversas opções de recuperação de desastre, de acordo com seus requisitos. Os servidores de aplicativos SAP não contêm dados de negócios, portanto, é possível criar servidores de aplicativos SAP em uma região secundária antes de desligá-los. As atualizações de software do servidor de aplicativos SAP e as alterações de configuração devem ser replicadas no lado da recuperação de desastre manualmente ou com base em um agendamento. É possível criar uma máquina virtual na região de recuperação de desastre para executar a função do Central Services, que também não mantém dados corporativos. Para obter detalhes, confira a Arquitetura de referência do SAP S/4HANA.

Monitoramento

Para maximizar a disponibilidade e o desempenho de aplicativos e serviços, use o Azure Monitor, que inclui o Azure Log Analytics e o Azure Application Insights e fornece ferramentas sofisticadas para coletar e analisar a telemetria. Ele pode ajudá-lo a maximizar o desempenho e a disponibilidade de seus recursos e aplicativos locais e na nuvem. Você pode usar o Azure Monitor para monitorar anomalias de infraestrutura e aplicativos, enviar alertas para administradores e automatizar reações a condições predefinidas.

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. O Azure Monitor para SAP fornece um conjunto inicial abrangente de métricas e telemetria para monitoramento. As definições de métrica são armazenadas como consultas SQL em JSON e podem ser modificadas para atender aos seus requisitos. O conjunto inicial de métricas está disponível no GitHub aqui.

Backup

Para o SAP ASCS e servidores de aplicativos, recomendamos usar o Backup do Azure a fim de proteger o conteúdo da máquina virtual. O Backup do Azure fornece backups independentes e isolados para ajudar a proteger sua empresa contra a destruição acidental de dados originais. Os backups são armazenados em um cofre dos Serviços de Recuperação que oferece gerenciamento interno de pontos de recuperação. A configuração e a escalabilidade são simples, os backups são otimizados e você pode fazer uma restauração com facilidade, conforme necessário.

O backup da camada de banco de dados varia de acordo com a implantação do SAP HANA em máquinas virtuais ou em Instâncias Grandes do Azure. Confira as considerações de gerenciamento e operações do SAP HANA em máquinas virtuais Linux.

Segurança

A segurança fornece garantias contra ataques deliberados e o abuso de seus dados e sistemas valiosos. Para saber mais, confira Visão geral do pilar 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 saber mais, confira o Guia de segurança do SAP BW∕4HANA.

A Arquitetura de referência do SAP S/4HANA fornece outras considerações de segurança de infraestrutura que se aplicam ao SAP BW/4HANA.

Colaboradores

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

Autor principal:

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

Próximas etapas

Saiba mais sobre as tecnologias dos componentes:

Explorar arquiteturas relacionadas: