Planejar e implementar uma implantação SAP no Azure

  • Artigo

No Azure, as organizações podem obter os recursos e serviços de nuvem de que precisam sem concluir um longo ciclo de compras. Mas executar sua carga de trabalho SAP no Azure requer conhecimento sobre as opções disponíveis e planejamento cuidadoso para escolher os componentes e a arquitetura do Azure para potencializar sua solução.

O Azure oferece uma plataforma abrangente para executar seus aplicativos SAP. As ofertas de infraestrutura como serviço (IaaS) e plataforma como serviço (PaaS) do Azure combinam-se para oferecer opções ideais para uma implantação bem-sucedida de todo o cenário empresarial SAP.

Este artigo complementa a documentação SAP e o SAP Notes, as principais fontes de informações sobre como instalar e implantar o software SAP no Azure e em outras plataformas.

Definições

Ao longo deste artigo, usamos os seguintes termos:

  • Componente SAP: uma aplicação SAP individual como SAP S/4HANA, SAP ECC, SAP BW ou SAP Solution Manager. Um componente SAP pode ser baseado em tecnologias ABAP (Advanced Business Application Programming) ou Java tradicionais, ou pode ser um aplicativo que não é baseado no SAP NetWeaver, como o SAP BusinessObjects.
  • Ambiente SAP: vários componentes SAP que são agrupados logicamente para executar uma função de negócios, como desenvolvimento, garantia de qualidade, treinamento, recuperação de desastres ou produção.
  • Cenário SAP: todo o conjunto de ativos SAP no cenário de TI de uma organização. O cenário SAP inclui todos os ambientes de produção e não produção.
  • Sistema SAP: A combinação de uma camada de sistema de gerenciamento de banco de dados (DBMS) e uma camada de aplicativo. Dois exemplos são um sistema de desenvolvimento SAP ERP e um sistema de teste SAP BW. Em uma implantação do Azure, essas duas camadas não podem ser distribuídas entre o local e o Azure. Um sistema SAP deve ser implantado no local ou implantado no Azure. No entanto, você pode operar diferentes sistemas em um cenário SAP no Azure ou localmente.

Recursos

O ponto de entrada para a documentação que descreve como hospedar e executar uma carga de trabalho SAP no Azure é Introdução ao SAP em uma máquina virtual do Azure. No artigo, você encontra links para outros artigos que abrangem:

  • Especificidades da carga de trabalho SAP para armazenamento, rede e opções suportadas.
  • Guias SAP DBMS para vários sistemas DBMS no Azure.
  • Guias de implementação SAP, manuais e automatizados.
  • Detalhes de alta disponibilidade e recuperação de desastres para uma carga de trabalho SAP no Azure.
  • Integração com SAP no Azure com outros serviços e aplicações de terceiros.

Importante

Para obter pré-requisitos, o processo de instalação e detalhes sobre funcionalidades específicas do SAP, é importante ler atentamente a documentação e os guias do SAP. Este artigo aborda apenas tarefas específicas para software SAP instalado e operado em uma máquina virtual (VM) do Azure.

As seguintes Notas SAP formam a base da orientação do Azure para implantações SAP:

Número da nota Título
1928533 Aplicativos SAP no Azure: produtos suportados e dimensionamento
2015553 SAP no Azure: Pré-requisitos de suporte
2039619 Aplicativos SAP no Azure usando o banco de dados Oracle
2233094 DB6: Aplicativos SAP no Azure Usando IBM DB2 para Linux, UNIX e Windows
1999351 Solução de problemas do Monitoramento Avançado do Azure para SAP
1409604 Virtualização no Windows: monitoramento aprimorado
2191498 SAP no Linux com Azure: monitoramento aprimorado
2731110 Suporte de Network Virtual Appliances (NVA) para SAP no Azure

Para obter as limitações gerais padrão e máximas de assinaturas e recursos do Azure, consulte Limites de assinatura, cotas e restrições de serviço e assinatura do Azure.

Cenários

Os serviços SAP geralmente são considerados entre os aplicativos mais críticos em uma empresa. A arquitetura e as operações dos aplicativos são complexas, e é importante garantir que todos os requisitos de disponibilidade e desempenho sejam atendidos. Uma empresa normalmente pensa cuidadosamente sobre qual provedor de nuvem escolher para executar esses processos de negócios críticos para os negócios.

O Azure é a plataforma de nuvem pública ideal para aplicativos e processos de negócios SAP críticos para os negócios. A maioria dos softwares SAP atuais, incluindo os sistemas SAP NetWeaver e SAP S/4HANA, pode ser hospedada na infraestrutura do Azure atualmente. O Azure oferece mais de 800 tipos de CPU e VMs com muitos terabytes de memória.

Para obter descrições de cenários suportados e alguns cenários sem suporte, consulte SAP em cenários suportados por VMs do Azure. Verifique esses cenários e as condições indicadas como sem suporte ao planejar a arquitetura que deseja implantar no Azure.

Para implantar com êxito sistemas SAP no Azure IaaS ou no IaaS em geral, é importante entender as diferenças significativas entre as ofertas de nuvens privadas tradicionais e ofertas de IaaS. Um host ou terceirizador tradicional adapta a infraestrutura (rede, armazenamento e tipo de servidor) à carga de trabalho que um cliente deseja hospedar. Em uma implantação de IaaS, é responsabilidade do cliente ou parceiro avaliar sua carga de trabalho potencial e escolher os componentes corretos do Azure de VMs, armazenamento e rede.

Para coletar dados para planejar sua implantação no Azure, é importante:

  • Determine quais produtos e versões SAP são suportados no Azure.
  • Avalie se as versões do sistema operacional que você planeja usar são suportadas com as VMs do Azure que você escolheria para seus produtos SAP.
  • Determine quais versões de DBMS em VMs específicas são suportadas para seus produtos SAP.
  • Avalie se é necessário atualizar ou atualizar seu cenário SAP para alinhar com o sistema operacional e as versões DBMS necessárias para obter uma configuração suportada.
  • Avalie se você precisa migrar para sistemas operacionais diferentes para implantar no Azure.

Os detalhes sobre os componentes SAP suportados no Azure, as unidades de infraestrutura do Azure e as versões relacionadas do sistema operativo e do DBMS são explicados no software SAP suportado para implementações do Azure. O conhecimento que você obtém ao avaliar o suporte e as dependências entre versões SAP, versões do sistema operacional e versões do DBMS tem um impacto substancial em seus esforços para mover seus sistemas SAP para o Azure. Você aprende se há esforços significativos de preparação envolvidos, por exemplo, se precisa atualizar sua versão SAP ou mudar para um sistema operacional diferente.

Primeiros passos para planejar uma implantação

A primeira etapa no planejamento da implantação não é procurar VMs disponíveis para executar aplicativos SAP.

As primeiras etapas para planejar uma implantação são trabalhar com as equipes de conformidade e segurança em sua organização para determinar quais são as condições de limite para implantar qual tipo de carga de trabalho SAP ou processo de negócios em uma nuvem pública. O processo pode ser demorado, mas é fundamental para ser concluído.

Se a sua organização já tiver implantado software no Azure, o processo pode ser fácil. Se sua empresa estiver mais no início da jornada, discussões maiores podem ser necessárias para descobrir as condições limite, as condições de segurança e a arquitetura corporativa que permite que determinados dados SAP e processos de negócios SAP sejam hospedados em uma nuvem pública.

Planejar a conformidade

Para obter uma lista de ofertas de conformidade da Microsoft que podem ajudá-lo a planejar suas necessidades de conformidade, consulte Ofertas de conformidade da Microsoft.

Planejar a segurança

Para obter informações sobre preocupações de segurança específicas do SAP, como criptografia de dados para dados em repouso ou outra criptografia em um serviço do Azure, consulte Visão geral da criptografia do Azure e Segurança para seu cenário SAP.

Organizar os recursos do Azure

Juntamente com a revisão de segurança e conformidade, se você ainda não tiver feito essa tarefa, planeje como você organiza seus recursos do Azure. O processo inclui a tomada de decisões sobre:

  • Uma convenção de nomenclatura que você usa para cada recurso do Azure, como para VMs e grupos de recursos.
  • Um design de grupo de gerenciamento e assinatura para sua carga de trabalho SAP, como se várias assinaturas devem ser criadas por carga de trabalho, por camada de implantação ou para cada unidade de negócios.
  • Utilização da Política do Azure em toda a empresa para subscrições e grupos de gestão.

Para ajudá-lo a tomar as decisões certas, muitos detalhes da arquitetura corporativa são descritos no Azure Cloud Adoption Framework.

Não subestime a fase inicial do projeto em seu planejamento. Somente quando você tiver contratos e regras em vigor para conformidade, segurança e organização de recursos do Azure deverá avançar no planejamento da implantação.

As próximas etapas são o planejamento do posicionamento geográfico e a arquitetura de rede que você implanta no Azure.

Geografias e regiões do Azure

Os serviços do Azure estão disponíveis em regiões separadas do Azure. Uma região do Azure é uma coleção de datacenters. Os datacenters contêm o hardware e a infraestrutura que hospedam e executam os serviços do Azure disponíveis na região. A infraestrutura inclui um grande número de nós que funcionam como nós de computação ou nós de armazenamento, ou que executam a funcionalidade de rede.

Para obter uma lista de regiões do Azure, consulte Geografias do Azure. Para obter um mapa interativo, consulte Infraestrutura global do Azure.

Nem todas as regiões do Azure oferecem os mesmos serviços. Dependendo do produto SAP que você deseja executar, seus requisitos de dimensionamento e do sistema operacional e DBMS de que você precisa, é possível que uma região específica não ofereça os tipos de VM necessários para seu cenário. Por exemplo, se você estiver executando o SAP HANA, geralmente precisará de VMs das várias famílias de VMs da série M. Essas famílias de VM são implantadas em apenas um subconjunto de regiões do Azure.

À medida que você começa a planejar e pensar em quais regiões escolher como região primária e, eventualmente, região secundária, você precisa investigar se os serviços necessários para seus cenários estão disponíveis nas regiões que você está considerando. Você pode saber exatamente quais tipos de VM, tipos de armazenamento do Azure e outros serviços do Azure estão disponíveis em cada região em Produtos disponíveis por região.

Regiões emparelhadas do Azure

Em uma região emparelhada do Azure, a replicação de determinados dados é habilitada por padrão entre as duas regiões. Para obter mais informações, consulte Replicação entre regiões no Azure: continuidade de negócios e recuperação de desastres.

A replicação de dados em um par de regiões está vinculada a tipos de armazenamento do Azure que você pode configurar para replicar em uma região emparelhada. Para obter detalhes, consulte Redundância de armazenamento em uma região secundária.

Os tipos de armazenamento que suportam a replicação de dados de região emparelhada são tipos de armazenamento que não são adequados para componentes SAP e uma carga de trabalho DBMS. A usabilidade da replicação de armazenamento do Azure é limitada ao Armazenamento de Blobs do Azure (para fins de backup), compartilhamentos e volumes de arquivos e outros cenários de armazenamento de alta latência.

À medida que procura regiões emparelhadas e os serviços que pretende utilizar nas suas regiões primárias ou secundárias, é possível que os serviços do Azure ou tipos de VM que pretende utilizar na sua região primária não estejam disponíveis na região emparelhada que pretende utilizar como região secundária. Ou você pode determinar que uma região emparelhada do Azure não é aceitável para seu cenário devido a motivos de conformidade de dados. Para esses cenários, você precisa usar uma região não emparelhada como uma região secundária ou de recuperação de desastres, e você mesmo precisa configurar parte da replicação de dados.

Zonas de disponibilidade

Muitas regiões do Azure usam zonas de disponibilidade para separar fisicamente locais dentro de uma região do Azure. Cada zona de disponibilidade é composta por um ou mais datacenters equipados com alimentação, refrigeração e rede independentes. Um exemplo de como usar uma zona de disponibilidade para melhorar a resiliência é implantar duas VMs em duas zonas de disponibilidade separadas no Azure. Outro exemplo é implementar uma estrutura de alta disponibilidade para seu sistema SAP DBMS em uma zona de disponibilidade e implantar o SAP (A)SCS em outra zona de disponibilidade, para que você obtenha o melhor SLA no Azure.

Para obter mais informações sobre SLAs de VM no Azure, verifique a versão mais recente dos SLAs de Máquinas Virtuais. Como as regiões do Azure se desenvolvem e se estendem rapidamente, a topologia das regiões do Azure, o número de datacenters físicos, a distância entre datacenters e a distância entre as zonas de disponibilidade do Azure evoluem. A latência da rede muda à medida que a infraestrutura muda.

Siga as orientações em configurações de carga de trabalho SAP com zonas de disponibilidade do Azure ao escolher uma região que tenha zonas de disponibilidade. Determine também qual modelo de implantação zonal é mais adequado para suas necessidades, a região escolhida e sua carga de trabalho.

Domínios de falha

Os domínios de falha representam uma unidade física de falha. Um domínio de falha está intimamente relacionado à infraestrutura física contida nos datacenters. Embora uma lâmina ou rack físico possa ser considerado um domínio de falha, não há um mapeamento direto um-para-um entre um elemento de computação física e um domínio de falha.

Ao implantar várias VMs como parte de um sistema SAP, você pode influenciar indiretamente o controlador de malha do Azure para implantar suas VMs em diferentes domínios de falha, para que possa atender aos requisitos de SLAs de disponibilidade. No entanto, você não tem controle direto da distribuição de domínios de falha em uma unidade de escala do Azure (uma coleção de centenas de nós de computação ou nós de armazenamento e rede) ou da atribuição de VMs a um domínio de falha específico. Para manobrar o controlador de malha do Azure para implantar um conjunto de VMs em diferentes domínios de falha, você precisa atribuir um conjunto de disponibilidade do Azure às VMs no momento da implantação. Para obter mais informações, consulte Conjuntos de disponibilidade.

Domínios de atualização

Os domínios de atualização representam uma unidade lógica que define como uma VM em um sistema SAP que consiste em várias VMs é atualizada. Quando ocorre uma atualização de plataforma, o Azure passa pelo processo de atualização desses domínios de atualização, um a um. Ao distribuir VMs no momento da implantação por diferentes domínios de atualização, você pode proteger seu sistema SAP contra possíveis períodos de inatividade. Semelhante aos domínios de falha, uma unidade de escala do Azure é dividida em vários domínios de atualização. Para manobrar o controlador de malha do Azure para implantar um conjunto de VMs em diferentes domínios de atualização, você precisa atribuir um conjunto de disponibilidade do Azure às VMs no momento da implantação. Para obter mais informações, consulte Conjuntos de disponibilidade.

Diagram that depicts update domains and failure domains.

Conjuntos de disponibilidade

As VMs do Azure dentro de um conjunto de disponibilidade do Azure são distribuídas pelo controlador de malha do Azure em diferentes domínios de falha. A distribuição em diferentes domínios de falha é para evitar que todas as VMs de um sistema SAP sejam desligadas durante a manutenção da infraestrutura ou se ocorrer uma falha em um domínio de falha. Por padrão, as VMs não fazem parte de um conjunto de disponibilidade. Você pode adicionar uma VM em um conjunto de disponibilidade somente no momento da implantação ou quando uma VM é reimplantada.

Para saber mais sobre os conjuntos de disponibilidade do Azure e como os conjuntos de disponibilidade se relacionam com domínios de falha, consulte Conjuntos de disponibilidade do Azure.

Importante

As zonas de disponibilidade e os conjuntos de disponibilidade no Azure são mutuamente exclusivos. Você pode implantar várias VMs em uma zona de disponibilidade específica ou em um conjunto de disponibilidade. Mas nem a zona de disponibilidade quanto o conjunto de disponibilidade podem ser atribuídos a uma VM.

Você pode combinar conjuntos de disponibilidade e zonas de disponibilidade se usar grupos de posicionamento de proximidade.

Ao definir conjuntos de disponibilidade e tentar misturar várias VMs de diferentes famílias de VMs em um conjunto de disponibilidade, você pode encontrar problemas que o impedem de incluir um tipo de VM específico em um conjunto de disponibilidade. O motivo é que o conjunto de disponibilidade está vinculado a uma unidade de escala que contém um tipo específico de host de computação. Um tipo específico de host de computação pode ser executado somente em determinados tipos de famílias de VMs.

Por exemplo, você cria um conjunto de disponibilidade e implanta a primeira VM no conjunto de disponibilidade. A primeira VM que você adiciona ao conjunto de disponibilidade está na família de VMs Edsv5. Quando você tenta implantar uma segunda VM, uma VM que está na família M, essa implantação falha. O motivo é que as VMs da família Edsv5 não são executadas no mesmo hardware de host que as VMs da família M.

O mesmo problema pode ocorrer se você estiver redimensionando VMs. Se você tentar mover uma VM da família Edsv5 para um tipo de VM que esteja na família M, a implantação falhará. Se você redimensionar para uma família de VMs que não pode ser hospedada no mesmo hardware de host, deverá desligar todas as VMs que estão em seu conjunto de disponibilidade e redimensioná-las todas para poder ser executado no outro tipo de máquina host. Para obter informações sobre SLAs de VMs implantadas em um conjunto de disponibilidade, consulte SLAs de máquinas virtuais.

Conjuntos de dimensionamento de máquinas virtuais com orquestração flexível

Os conjuntos de dimensionamento de máquinas virtuais com orquestração flexível fornecem um agrupamento lógico de máquinas virtuais gerenciadas por plataforma. Você tem a opção de criar um conjunto de dimensionamento dentro da região ou estendê-lo entre zonas de disponibilidade. Ao criar, a escala flexível definida dentro de uma região com platformFaultDomainCount>1 (FD>1), as VMs implantadas no conjunto de escala seriam distribuídas entre o número especificado de domínios de falha na mesma região. Por outro lado, a criação do conjunto de escala flexível entre zonas de disponibilidade com platformFaultDomainCount=1 (FD=1) distribuiria VMs em zonas especificadas e o conjunto de escalas também distribuiria VMs em diferentes domínios de falha dentro da zona com base no melhor esforço.

Para carga de trabalho SAP, apenas o conjunto de escala flexível com FD=1 é suportado. A vantagem de usar conjuntos de escala flexíveis com FD=1 para implantação entre zonas, em vez da implantação tradicional da zona de disponibilidade, é que as VMs implantadas com o conjunto de escala seriam distribuídas entre diferentes domínios de falha dentro da zona de uma maneira de melhor esforço. Para saber mais sobre a implantação da carga de trabalho SAP com conjunto de escalas, consulte o guia de implantação flexível em escala de máquina virtual.

Ao implantar uma carga de trabalho SAP de alta disponibilidade no Azure, é importante levar em conta os vários tipos de implantação disponíveis e como eles podem ser aplicados em diferentes regiões do Azure (como entre zonas, em uma única zona ou em uma região sem zonas). Para obter mais informações, consulte Opções de implantação de alta disponibilidade para carga de trabalho SAP.

Gorjeta

Atualmente, não há uma maneira direta de migrar a carga de trabalho SAP implantada em conjuntos de disponibilidade ou zonas de disponibilidade para uma escala flexível com FD=1. Para fazer a mudança, você precisa recriar a VM e o disco com restrições de zona dos recursos existentes em vigor. Um projeto de código aberto inclui funções do PowerShell que você pode usar como exemplo para alterar uma VM implantada no conjunto de disponibilidade ou na zona de disponibilidade para um conjunto de escala flexível com FD=1. Uma postagem de blog mostra como modificar um sistema SAP HA ou não-HA implantado no conjunto de disponibilidade ou na zona de disponibilidade para um conjunto de escala flexível com FD=1.

Grupos de colocação de proximidade

A latência da rede entre VMs SAP individuais pode ter implicações significativas para o desempenho. O tempo de ida e volta da rede entre os servidores de aplicativos SAP e o DBMS, especialmente, pode ter um impacto significativo nos aplicativos de negócios. Idealmente, todos os elementos de computação que executam suas VMs SAP estão localizados o mais próximo possível. Essa opção não é possível em todas as combinações, e o Azure pode não saber quais VMs manter juntas. Na maioria das situações e regiões, o posicionamento padrão atende aos requisitos de latência de ida e volta da rede.

Quando o posicionamento padrão não atende aos requisitos de ida e volta da rede em um sistema SAP, os grupos de posicionamento de proximidade podem atender a essa necessidade. Você pode usar grupos de posicionamento de proximidade com as restrições de local da região do Azure, zona de disponibilidade e disponibilidade definidas para aumentar a resiliência. Com um grupo de posicionamento de proximidade, é possível combinar a zona de disponibilidade e o conjunto de disponibilidade enquanto define diferentes domínios de atualização e falha. Um grupo de colocação de proximidade deve conter apenas um único sistema SAP.

Embora a implantação em um grupo de posicionamento de proximidade possa resultar no posicionamento mais otimizado para latência, a implantação usando um grupo de posicionamento de proximidade também tem desvantagens. Algumas famílias de VMs não podem ser combinadas em um grupo de posicionamento de proximidade ou você pode ter problemas se redimensionar entre famílias de VMs. As restrições de famílias, regiões e zonas de disponibilidade de VM podem não oferecer suporte à colocalização. Para obter detalhes e saber mais sobre as vantagens e os desafios potenciais de usar um grupo de posicionamento de proximidade, consulte Cenários de grupo de posicionamento de proximidade.

As VMs que não usam grupos de posicionamento de proximidade devem ser o método de implantação padrão na maioria das situações para sistemas SAP. Esse padrão é especialmente verdadeiro para implantações zonais (uma única zona de disponibilidade) e interzonais (VMs distribuídas entre duas zonas de disponibilidade) de um sistema SAP. O uso de grupos de posicionamento de proximidade deve ser limitado a sistemas SAP e regiões do Azure quando necessário apenas por motivos de desempenho.

Rede do Azure

O Azure tem uma infraestrutura de rede que mapeia para todos os cenários que você pode querer implementar em uma implantação SAP. No Azure, você tem os seguintes recursos:

  • Acesso aos serviços do Azure e acesso a portas específicas em VMs que os aplicativos usam.
  • Acesso direto a VMs via Secure Shell (SSH) ou RDP (Windows Remote Desktop) para gerenciamento e administração.
  • Comunicação interna e resolução de nomes entre VMs e pelos serviços do Azure.
  • Conectividade local entre uma rede local e redes do Azure.
  • Comunicação entre serviços implantados em diferentes regiões do Azure.

Para obter informações detalhadas sobre rede, consulte Rede Virtual do Azure.

Projetar redes geralmente é a primeira atividade técnica que você realiza quando implanta no Azure. O suporte a uma arquitetura corporativa central como o SAP frequentemente faz parte dos requisitos gerais de rede. Na etapa de planejamento, você deve documentar a arquitetura de rede proposta com o máximo de detalhes possível. Se você fizer uma alteração posteriormente, como alterar um endereço de rede de sub-rede, talvez seja necessário mover ou excluir recursos implantados.

Redes virtuais do Azure

Uma rede virtual é um bloco de construção fundamental para sua rede privada no Azure. Você pode definir o intervalo de endereços da rede e separá-lo em sub-redes de rede. Uma sub-rede de rede pode estar disponível para uso de uma VM SAP ou pode ser dedicada a um serviço ou finalidade específica. Alguns serviços do Azure, como a Rede Virtual do Azure e o Gateway de Aplicativo do Azure, exigem uma sub-rede dedicada.

Uma rede virtual atua como um limite de rede. Parte do design necessário quando você planeja sua implantação é definir a rede virtual, as sub-redes e os intervalos de endereços da rede privada. Não é possível alterar a atribuição de rede virtual para recursos como placas de interface de rede (NICs) para VMs depois que as VMs são implantadas. Fazer uma alteração em uma rede virtual ou em um intervalo de endereços de sub-rede pode exigir que você mova todos os recursos implantados para uma sub-rede diferente.

Seu projeto de rede deve atender a vários requisitos para a implantação do SAP:

  • Nenhum dispositivo virtual de rede, como um firewall, é colocado no caminho de comunicação entre o aplicativo SAP e a camada DBMS de produtos SAP por meio do kernel SAP, como S/4HANA ou SAP NetWeaver.
  • As restrições de roteamento de rede são impostas por NSGs (grupos de segurança de rede) no nível da sub-rede. Agrupe IPs de VMs em grupos de segurança de aplicativos (ASGs) que são mantidos nas regras do NSG e forneça agrupamentos de permissões de função, camada e SID.
  • As VMs de aplicativos e bancos de dados SAP são executadas na mesma rede virtual, dentro das mesmas sub-redes ou de sub-redes diferentes de uma única rede virtual. Use sub-redes diferentes para VMs de aplicativos e bancos de dados. Como alternativa, use aplicativos dedicados e ASGs DBMS para agrupar regras aplicáveis a cada tipo de carga de trabalho na mesma sub-rede.
  • A rede acelerada é habilitada em todas as placas de rede de todas as VMs para cargas de trabalho SAP, quando tecnicamente possível.
  • Garanta acesso seguro para dependência de serviços centrais, incluindo resolução de nomes (DNS), gerenciamento de identidades (domínios do Ative Directory do Windows Server/ID do Microsoft Entra) e acesso administrativo.
  • Fornecer acesso a e por terminais públicos, conforme necessário. Os exemplos incluem para gerenciamento do Azure para operações do ClusterLabs Pacemaker em alta disponibilidade ou para serviços do Azure como o Backup do Azure.
  • Use várias NICs somente se elas forem necessárias para criar sub-redes designadas que tenham suas próprias rotas e regras NSG.

Para obter exemplos de arquitetura de rede para implantação SAP, consulte os seguintes artigos:

Considerações de rede virtual

Algumas configurações de rede virtual têm considerações específicas a serem observadas.

  • Não há suporte para a configuração de dispositivos virtuais de rede no caminho de comunicação entre a camada de aplicativos SAP e a camada DBMS de componentes SAP usando o kernel SAP, como S/4HANA ou SAP NetWeaver.

    Os dispositivos virtuais de rede em caminhos de comunicação podem facilmente duplicar a latência da rede entre dois parceiros de comunicação. Eles também podem restringir a taxa de transferência em caminhos críticos entre a camada de aplicativos SAP e a camada DBMS. Em alguns cenários, os dispositivos virtuais de rede podem fazer com que os clusters Linux do Pacemaker falhem.

    O caminho de comunicação entre a camada de aplicativo SAP e a camada DBMS deve ser um caminho direto. A restrição não inclui regras ASG e NSG se as regras ASG e NSG permitirem um caminho de comunicação direta.

    Outros cenários em que os dispositivos virtuais de rede não são suportados são:

  • Não há suporte para segregação da camada de aplicativo SAP e da camada DBMS em diferentes redes virtuais do Azure. Recomendamos que você segregue a camada de aplicativo SAP e a camada DBMS usando sub-redes dentro da mesma rede virtual do Azure em vez de usar redes virtuais do Azure diferentes.

    Se você configurar um cenário sem suporte que segrega duas camadas do sistema SAP em redes virtuais diferentes, as duas redes virtuais deverão seremparelhadas.

    O tráfego de rede entre duas redes virtuais emparelhadas do Azure está sujeito a custos de transferência. Todos os dias, um enorme volume de dados que consiste em muitos terabytes é trocado entre a camada de aplicativos SAP e a camada DBMS. Você pode incorrer em custos substanciais se a camada de aplicativo SAP e a camada DBMS forem segregadas entre duas redes virtuais do Azure emparelhadas.

Resolução de nomes e serviços de domínio

Resolver o nome do host para o endereço IP através do DNS é muitas vezes um elemento crucial para a rede SAP. Você tem muitas opções para configurar o nome e a resolução de IP no Azure.

Muitas vezes, uma empresa tem uma solução de DNS central que faz parte da arquitetura geral. Várias opções para implementar a resolução de nomes no Azure nativamente, em vez de configurar seus próprios servidores DNS, são descritas em Resolução de nomes para recursos em redes virtuais do Azure.

Assim como acontece com os serviços DNS, pode haver um requisito para que o Ative Directory do Windows Server seja acessível pelas VMs ou serviços SAP.

Atribuição de endereço IP

Um endereço IP para uma NIC permanece reivindicado e usado durante toda a existência da NIC de uma VM. A regra aplica-se à atribuição de IP dinâmico e estático. Permanece verdadeiro se a VM está em execução ou está desligada. A atribuição de IP dinâmico é liberada se a NIC for excluída, se a sub-rede for alterada ou se o método de alocação mudar para estático.

É possível atribuir endereços IP fixos a VMs dentro de uma rede virtual do Azure. Os endereços IP geralmente são reatribuídos para sistemas SAP que dependem de servidores DNS externos e entradas estáticas. O endereço IP permanece atribuído, até que a VM e sua NIC sejam excluídas ou até que o endereço IP não seja atribuído. Você precisa levar em conta o número total de VMs (em execução e paradas) ao definir o intervalo de endereços IP para a rede virtual.

Para obter mais informações, consulte Criar uma VM que tenha um endereço IP privado estático.

Nota

Você deve decidir entre alocação de endereço IP estático e dinâmico para VMs do Azure e suas NICs. O sistema operacional convidado da VM obterá o IP atribuído à NIC quando a VM for inicializada. Você não deve atribuir endereços IP estáticos no sistema operacional convidado a uma NIC. Alguns serviços do Azure, como o Backup do Azure, dependem do fato de que pelo menos a NIC primária está definida como DHCP e não como endereços IP estáticos dentro do sistema operacional. Para obter mais informações, consulte Solucionar problemas de backup de VM do Azure.

Endereços IP secundários para virtualização de nomes de host SAP

A NIC de cada VM do Azure pode ter vários endereços IP atribuídos a ela. Um IP secundário pode ser usado para um nome de host virtual SAP, que é mapeado para um registro DNS A ou um registro PTR DNS. Um endereço IP secundário deve ser atribuído à configuração IP da NIC do Azure. Um IP secundário também deve ser configurado dentro do sistema operacional estaticamente porque os IPs secundários geralmente não são atribuídos por meio do DHCP. Cada IP secundário deve ser da mesma sub-rede à qual a NIC está vinculada. Um IP secundário pode ser adicionado e removido de uma NIC do Azure sem parar ou deslocalizar a VM. Para adicionar ou remover o IP primário de uma NIC, a VM deve ser deslocalizada.

Nota

Em configurações IP secundárias, o endereço IP flutuante do balanceador de carga do Azure não é suportado. O balanceador de carga do Azure é usado por arquiteturas de alta disponibilidade SAP com clusters Pacemaker. Nesse cenário, o balanceador de carga habilita os nomes de host virtual SAP. Para obter orientações gerais sobre como usar nomes de host virtual, consulte SAP Note 962955.

Azure Load Balancer com VMs executando SAP

Um balanceador de carga normalmente é usado em arquiteturas de alta disponibilidade para fornecer endereços IP flutuantes entre nós de cluster ativos e passivos. Você também pode usar um balanceador de carga para uma única VM para manter um endereço IP virtual para um nome de host virtual SAP. Usar um balanceador de carga para uma única VM é uma alternativa ao uso de um endereço IP secundário em uma NIC ou ao uso de várias NICs na mesma sub-rede.

O balanceador de carga padrão modifica o caminho de acesso de saída padrão porque sua arquitetura é segura por padrão. As VMs que estão atrás de um balanceador de carga padrão podem não ser mais capazes de alcançar os mesmos pontos de extremidade públicos. Alguns exemplos são um ponto de extremidade para um repositório de atualização do sistema operacional ou um ponto de extremidade público dos serviços do Azure. Para obter opções para fornecer conectividade de saída, consulte Conectividade de ponto de extremidade público para VMs usando o balanceador de carga padrão do Azure.

Gorjeta

O balanceador de carga básico não deve ser usado com nenhuma arquitetura SAP no Azure. O balanceador de carga básico está programado para ser desativado.

Várias vNICs por VM

Você pode definir várias vNICs (placas de interface de rede virtual) para uma VM do Azure, com cada vNIC atribuída a qualquer sub-rede na mesma rede virtual que a vNIC primária. Com a capacidade de ter vários vNICs, você pode começar a configurar a separação de tráfego de rede, se necessário. Por exemplo, o tráfego do cliente é roteado através da vNIC principal e algum tráfego de administrador ou back-end é roteado através de uma segunda vNIC. Dependendo do sistema operacional e da imagem usada, as rotas de tráfego para NICs dentro do sistema operacional podem precisar ser configuradas para roteamento correto.

O tipo e o tamanho de uma VM determinam quantas vNICs uma VM pode ter atribuído. Para obter informações sobre funcionalidade e restrições, consulte Atribuir vários endereços IP a VMs usando o portal do Azure.

Adicionar vNICs a uma VM não aumenta a largura de banda de rede disponível. Todas as interfaces de rede compartilham a mesma largura de banda. Recomendamos que você use várias NICs somente se as VMs precisarem acessar sub-redes privadas. Recomendamos um padrão de design que dependa da funcionalidade NSG e que simplifique os requisitos de rede e sub-rede. O design deve usar o menor número possível de interfaces de rede e, idealmente, apenas uma. Uma exceção é a expansão do HANA, na qual uma vNIC secundária é necessária para a rede interna do HANA.

Aviso

Se você usar várias vNICs em uma VM, recomendamos que use uma sub-rede da NIC primária para lidar com o tráfego de rede do usuário.

Rede acelerada

Para reduzir ainda mais a latência de rede entre VMs do Azure, recomendamos que você confirme se a rede acelerada do Azure está habilitada em todas as VMs que executam uma carga de trabalho SAP. Embora a rede acelerada esteja habilitada por padrão para novas VMs, de acordo com a lista de verificação de implantação, você deve verificar o estado. Os benefícios da rede acelerada são o desempenho e as latências de rede muito melhorados. Use-o ao implantar VMs do Azure para cargas de trabalho SAP em todas as VMs suportadas, especialmente para a camada de aplicativos SAP e a camada SAP DBMS. A documentação vinculada contém dependências de suporte em versões do sistema operacional e instâncias de VM.

Conectividade no local

A implantação do SAP no Azure pressupõe que uma arquitetura de rede central em toda a empresa e um hub de comunicação estejam em vigor para habilitar a conectividade local. A conectividade de rede local é essencial para permitir que usuários e aplicativos acessem o cenário SAP no Azure para acessar outros serviços da organização central, como DNS central, domínio e infraestrutura de gerenciamento de patches e segurança.

Você tem muitas opções para fornecer conectividade local para sua implantação do SAP no Azure. A implantação de rede na maioria das vezes é uma topologia de rede hub-spoke, ou uma extensão da topologia hub-spoke, uma WAN virtual global.

Para implantações SAP locais, recomendamos que você use uma conexão privada pela Rota Expressa do Azure. Para cargas de trabalho SAP menores, regiões remotas ou escritórios menores, a conectividade VPN local está disponível. Usar a Rota Expressa com uma conexão VPN site a site como um caminho de failover é uma combinação possível de ambos os serviços.

Conectividade à Internet de entrada e saída

Seu cenário SAP requer conectividade com a Internet, seja para receber atualizações do repositório do sistema operacional, para estabelecer uma conexão com os aplicativos SAP SaaS em seus pontos de extremidade públicos ou para acessar um serviço do Azure por meio de seu ponto de extremidade público. Da mesma forma, você pode ser solicitado a fornecer acesso para seus clientes a aplicativos SAP Fiori, com os usuários da Internet acessando serviços fornecidos pelo seu cenário SAP. Sua arquitetura de rede SAP exige que você planeje o caminho para a Internet e para quaisquer solicitações recebidas.

Proteja sua rede virtual usando regras NSG, usando tags de serviço de rede para serviços conhecidos e estabelecendo roteamento e endereçamento IP para seu firewall ou outro dispositivo virtual de rede. Todas essas tarefas ou considerações fazem parte da arquitetura. Os recursos em redes privadas precisam ser protegidos por firewalls de Camada 4 e Camada 7 de rede.

Os caminhos de comunicação com a internet são o foco de uma arquitetura de boas práticas.

VMs do Azure para cargas de trabalho SAP

Algumas famílias de VMs do Azure são especialmente adequadas para cargas de trabalho SAP e outras mais especificamente para uma carga de trabalho SAP HANA. A maneira de encontrar o tipo de VM correto e sua capacidade de dar suporte à sua carga de trabalho SAP é descrita em Qual software SAP é suportado para implantações do Azure. Além disso, o SAP Note 1928533 lista todas as VMs do Azure certificadas e seus recursos de desempenho, conforme medido pelo benchmark e limitações do SAP Application Performance Standard (SAPS), se forem aplicáveis. Os tipos de VM certificados para uma carga de trabalho SAP não usam provisionamento excessivo para recursos de CPU e memória.

Além de examinar apenas a seleção de tipos de VM suportados, você precisa verificar se esses tipos de VM estão disponíveis em uma região específica com base nos Produtos disponíveis por região. Pelo menos tão importante quanto isso é determinar se os seguintes recursos para uma VM se ajustam ao seu cenário:

  • Recursos de CPU e memória
  • Largura de banda de operações de entrada/saída por segundo (IOPS)
  • Capacidades de rede
  • Número de discos que podem ser anexados
  • Capacidade de usar determinados tipos de armazenamento do Azure

Para obter essas informações para uma família e um tipo de FM específicos, consulte Tamanhos para máquinas virtuais no Azure.

Modelos de preços para VMs do Azure

Para um modelo de preços de VM, você pode escolher a opção que prefere usar:

  • Um modelo de preços pré-pago
  • Um plano reservado ou de poupança de um ano
  • Um plano reservado ou de poupança de três anos
  • Um modelo de preços spot

Para obter informações detalhadas sobre preços de VM para diferentes serviços, sistemas operacionais e regiões do Azure, consulte Preços de máquinas virtuais.

Para saber mais sobre a precificação e a flexibilidade de planos de poupança de um e três anos e instâncias reservadas, consulte estes artigos:

Para obter mais informações sobre preços spot, consulte Máquinas Virtuais do Azure Spot.

Os preços para o mesmo tipo de VM podem variar entre regiões do Azure. Alguns clientes se beneficiam da implantação em uma região do Azure menos dispendiosa, portanto, as informações sobre preços por região podem ser úteis enquanto você planeja.

O Azure também oferece a opção de usar um host dedicado. Usar um host dedicado oferece mais controle dos ciclos de aplicação de patches para os serviços do Azure. Você pode agendar a aplicação de patches para dar suporte à sua própria programação e ciclos. Esta oferta é especificamente para clientes que têm uma carga de trabalho que não segue o ciclo normal de uma carga de trabalho. Para obter mais informações, consulte Hosts dedicados do Azure.

O uso de um host dedicado do Azure é suportado para uma carga de trabalho SAP. Vários clientes SAP que desejam ter mais controle sobre os patches de infraestrutura e os planos de manutenção usam hosts dedicados do Azure. Para obter mais informações sobre como a Microsoft mantém e corrige a infraestrutura do Azure que hospeda VMs, consulte Manutenção para máquinas virtuais no Azure.

Sistema operacional para VMs

Quando você implanta novas VMs para um cenário SAP no Azure, seja para instalar ou migrar um sistema SAP, é importante escolher o sistema operacional correto para sua carga de trabalho. O Azure oferece uma grande seleção de imagens do sistema operacional para Linux e Windows e muitas opções adequadas para sistemas SAP. Você também pode criar ou carregar imagens personalizadas de seu ambiente local ou pode consumir ou generalizar a partir de galerias de imagens.

Para obter detalhes e informações sobre as opções disponíveis:

Planeje uma infraestrutura de atualização do sistema operacional e suas dependências para sua carga de trabalho SAP, se necessário. Considere o uso de um ambiente de preparo de repositório para manter todos os níveis de um cenário SAP (sandbox, desenvolvimento, pré-produção e produção) sincronizados usando as mesmas versões de patches e atualizações durante o período de tempo de atualização.

VMs de 1ª e 2ª gerações

No Azure, você pode implantar uma VM como geração 1 ou geração 2. O suporte para VMs de geração 2 no Azure lista as famílias de VMs do Azure que você pode implantar como geração 2. O artigo também lista as diferenças funcionais entre as VMs de geração 1 e 2 no Azure.

Quando você implanta uma VM, a imagem do sistema operacional escolhida determina se a VM será uma VM de geração 1 ou 2. As versões mais recentes de todas as imagens do sistema operacional SAP disponíveis no Azure (Red Hat Enterprise Linux, SuSE Enterprise Linux e Windows ou Oracle Enterprise Linux) estão disponíveis nas gerações 1 e 2. É importante selecionar cuidadosamente uma imagem com base na descrição da imagem para implantar a geração correta de VM. Da mesma forma, você pode criar imagens personalizadas do sistema operacional como geração 1 ou geração 2, e elas afetam a geração da VM quando a VM é implantada.

Nota

Recomendamos que você use VMs de geração 2 em todas as suas implantações SAP no Azure, independentemente do tamanho da VM. Todas as VMs do Azure para SAP mais recentes são compatíveis com a geração 2 ou estão limitadas apenas à geração 2. Atualmente, algumas famílias de VMs suportam apenas VMs de 2ª geração. Algumas famílias de VM que estarão disponíveis em breve podem suportar apenas a geração 2.

Você pode determinar se uma VM é de geração 1 ou apenas de geração 2 com base na imagem do sistema operacional selecionada. Não é possível alterar uma VM existente de uma geração para outra.

Alterar uma VM implantada da geração 1 para a geração 2 não é possível no Azure. Para alterar a geração de VM, você deve implantar uma nova VM que seja a geração desejada e reinstalar o software na nova geração de VM. Essa alteração afeta apenas a imagem VHD base da VM e não tem impacto nos discos de dados ou compartilhamentos NFS (Network File System) ou SMB (Server Message Block) anexados. Discos de dados, compartilhamentos NFS ou compartilhamentos SMB que foram originalmente atribuídos a uma VM de 1ª geração podem ser anexados a uma VM de 2ª geração.

Algumas famílias de VMs, como a série Mv2, suportam apenas a geração 2. O mesmo requisito pode ser válido para novas famílias de VMs no futuro. Nesse cenário, uma VM de 1ª geração existente não pode ser redimensionada para funcionar com a nova família de VMs. Além dos requisitos de geração 2 da plataforma Azure, seus componentes SAP podem ter requisitos relacionados à geração de uma VM. Para saber mais sobre os requisitos da 2ª geração para a família de VMs escolhida, consulte SAP Note 1928533.

Limites de desempenho para VMs do Azure

Como uma nuvem pública, o Azure depende do compartilhamento de infraestrutura de forma segura em toda a sua base de clientes. Para habilitar o dimensionamento e a capacidade, os limites de desempenho são definidos para cada recurso e serviço. No lado da computação da infraestrutura do Azure, é importante considerar os limites definidos para cada tamanho de VM.

Cada VM tem uma cota diferente em disco e taxa de transferência de rede, o número de discos que podem ser anexados, se ela tem armazenamento temporário local que tem sua própria taxa de transferência e limites de IOPS, tamanho da memória e quantas vCPUs estão disponíveis.

Nota

Ao tomar decisões sobre o tamanho da VM para uma solução SAP no Azure, você deve considerar os limites de desempenho para cada tamanho de VM. As quotas descritas na documentação representam os valores máximos teóricos alcançáveis. O limite de desempenho de IOPS por disco pode ser alcançado com pequenos valores de entrada/saída (E/S) (por exemplo, 8 KB), mas pode não ser alcançado com grandes valores de E/S (por exemplo, 1 MB).

Como as VMs, existem os mesmos limites de desempenho para cada tipo de armazenamento para uma carga de trabalho SAP e para todos os outros serviços do Azure.

Ao planejar e escolher VMs para usar em sua implantação SAP, considere estes fatores:

  • Comece com os requisitos de memória e CPU. Separe os requisitos do SAPS para alimentação da CPU na parte DBMS e nas partes do aplicativo SAP. Para sistemas existentes, o SAPS relacionado ao hardware que você usa com frequência pode ser determinado ou estimado com base nos benchmarks de aplicativos padrão SAP existentes. Para sistemas SAP recém-implantados, conclua um exercício de dimensionamento para determinar os requisitos SAPS para o sistema.

  • Para sistemas existentes, a taxa de transferência de E/S e IOPS no servidor DBMS devem ser medidas. Para novos sistemas, o exercício de dimensionamento para o novo sistema também deve dar uma ideia geral dos requisitos de E/S no lado do DBMS. Se você não tiver certeza, eventualmente precisará realizar uma prova de conceito.

  • Compare o requisito SAPS para o servidor DBMS com o SAPS que os diferentes tipos de VM do Azure podem fornecer. As informações sobre o SAPS dos diferentes tipos de VM do Azure estão documentadas no SAP Note 1928533. O foco deve ser na VM DBMS primeiro, porque a camada de banco de dados é a camada em um sistema SAP NetWeaver que não se expande na maioria das implantações. Em contrapartida, a camada de aplicativos SAP pode ser expandida. Os guias individuais de DBMS descrevem as configurações de armazenamento recomendadas.

  • Resuma suas descobertas para:

    • O número de VMs do Azure que você espera usar.
    • Família de VMs individuais e SKUs de VM para cada camada SAP: DBMS, (A)SCS e servidor de aplicativos.
    • Medidas de taxa de transferência de E/S ou requisitos calculados de capacidade de armazenamento.

Serviço HANA Large Instances

O Azure oferece recursos de computação para executar um banco de dados HANA grande em expansão ou expansão em uma oferta dedicada chamada SAP HANA em Instâncias Grandes do Azure. Esta oferta estende as VMs que estão disponíveis no Azure.

Nota

O serviço HANA Large Instances está no modo sunset e não aceita novos clientes. Ainda é possível fornecer unidades para clientes existentes de instâncias grandes do HANA.

Armazenamento para SAP no Azure

As VMs do Azure usam várias opções de armazenamento para persistência. Em termos simples, as VMs podem ser divididas em tipos de armazenamento persistente e temporário ou não persistente.

Você pode escolher entre várias opções de armazenamento para cargas de trabalho SAP e para componentes SAP específicos. Para obter mais informações, consulte Armazenamento do Azure para cargas de trabalho SAP. O artigo aborda a arquitetura de armazenamento para cada parte do SAP: sistema operacional, binários de aplicativos, arquivos de configuração, dados de banco de dados, arquivos de log e rastreamento e interfaces de arquivo com outros aplicativos, sejam armazenados em disco ou acessados em compartilhamentos de arquivos.

Disco temporário em VMs

A maioria das VMs do Azure para SAP oferece um disco temporário que não é um disco gerenciado. Use um disco temporário apenas para dados descartáveis. Os dados em um disco temporário podem ser perdidos durante eventos de manutenção imprevistos ou durante a reimplantação da VM. As características de desempenho do disco temporário tornam-nos ideais para arquivos de permuta/página do sistema operacional.

Nenhum aplicativo ou dados não descartáveis do sistema operacional devem ser armazenados em um disco temporário. Em ambientes Windows, a unidade temporária é normalmente acessada como unidade D. Em sistemas Linux, o ponto de montagem geralmente é o dispositivo /dev/sdb, /mnt ou /mnt/resource.

Algumas VMs não oferecem uma unidade temporária. Se você planeja usar esses tamanhos de VM para SAP, talvez seja necessário aumentar o tamanho do disco do sistema operacional. Para obter mais informações, consulte SAP Note 1928533. Para VMs que têm um disco temporário, obtenha informações sobre o tamanho do disco temporário e os limites de IOPS e taxa de transferência para cada série de VMs em Tamanhos para máquinas virtuais no Azure.

Não é possível redimensionar diretamente entre uma série de VMs que tenha discos temporários e uma série de VMs que não tenha discos temporários. Atualmente, um redimensionamento entre duas dessas famílias de VM falha. Uma resolução é recriar a VM que não tem um disco temporário no novo tamanho usando um instantâneo de disco do sistema operacional. Mantenha todos os outros discos de dados e a interface de rede. Saiba como redimensionar um tamanho de VM que tenha um disco temporário local para um tamanho de VM que não tenha.

Compartilhamentos e volumes de rede para SAP

Os sistemas SAP geralmente exigem um ou mais compartilhamentos de arquivos de rede. Os compartilhamentos de arquivos normalmente são uma das seguintes opções:

  • Um diretório de transporte SAP (/usr/sap/trans ou TRANSDIR).
  • Volumes SAP ou volumes sapmnt ou saploc compartilhados para implantar vários servidores de aplicativos.
  • Volumes de arquitetura de alta disponibilidade para SAP (A)SCS, SAP ERS ou um banco de dados (/hana/shared).
  • Interfaces de arquivo que executam aplicativos de terceiros para importação e exportação de arquivos.

Nesses cenários, recomendamos que você use um serviço do Azure, como Arquivos do Azure ou Arquivos NetApp do Azure. Se esses serviços não estiverem disponíveis nas regiões escolhidas ou se não estiverem disponíveis para sua arquitetura de solução, as alternativas são fornecer compartilhamentos de arquivos NFS ou SMB de aplicativos baseados em VM autogerenciados ou de serviços de terceiros. Consulte SAP Note 2015553 sobre limitações ao suporte SAP se você usar serviços de terceiros para camadas de armazenamento em um sistema SAP no Azure.

Devido à natureza muitas vezes crítica dos compartilhamentos de rede, e porque eles geralmente são um único ponto de falha em um design (para alta disponibilidade) ou processo (para a interface de arquivo), recomendamos que você confie em cada serviço nativo do Azure para sua própria disponibilidade, SLA e resiliência. Na fase de planejamento, é importante considerar estes fatores:

  • Design de compartilhamento NFS ou SMB, incluindo quais compartilhamentos usar por SID (ID do sistema) SAP, por cenário e por região.
  • Dimensionamento de sub-rede, incluindo o requisito de IP para pontos de extremidade privados ou sub-redes dedicadas para serviços como Arquivos NetApp do Azure.
  • Roteamento de rede para sistemas SAP e aplicativos conectados.
  • Uso de um ponto de extremidade público ou privado para Arquivos do Azure.

Para obter informações sobre requisitos e como usar um compartilhamento NFS ou SMB em um cenário de alta disponibilidade, consulte Alta disponibilidade.

Nota

Se você usar os Arquivos do Azure para seus compartilhamentos de rede, recomendamos que use um ponto de extremidade privado. No caso improvável de uma falha zonal, o cliente NFS redireciona automaticamente para uma zona íntegra. Não é necessário remontar os compartilhamentos NFS ou SMB em suas VMs.

Segurança para o seu cenário SAP

Para proteger sua carga de trabalho SAP no Azure, você precisa planejar vários aspetos de segurança:

  • Segmentação de rede e a segurança de cada sub-rede e interface de rede.
  • Criptografia em cada camada dentro do cenário SAP.
  • Solução de identidade para acesso administrativo e de utilizador final e serviços de início de sessão único.
  • Monitoramento de ameaças e operações.

Os tópicos deste capítulo não são uma lista exaustiva de todos os serviços, opções e alternativas disponíveis. Ele lista várias práticas recomendadas que devem ser consideradas para todas as implantações SAP no Azure. Há outros aspetos a serem cobertos, dependendo da sua empresa ou dos requisitos de carga de trabalho. Para obter mais informações sobre design de segurança, consulte os seguintes recursos para obter orientações gerais do Azure:

Proteja redes virtuais usando grupos de segurança

O planejamento do cenário SAP no Azure deve incluir algum grau de segmentação de rede, com redes virtuais e sub-redes dedicadas apenas a cargas de trabalho SAP. As práticas recomendadas para definição de sub-rede são descritas em Rede e em outros guias de arquitetura do Azure. Recomendamos que você use NSGs com ASGs dentro de NSGs para permitir conectividade de entrada e saída. Quando você cria ASGs, cada NIC em uma VM pode ser associada a vários ASGs, para que você possa criar grupos diferentes. Por exemplo, crie um ASG para VMs DBMS, que contém todos os servidores de banco de dados em seu cenário. Crie outro ASG para todas as VMs (aplicativo e DBMS) de um único SID SAP. Dessa forma, você pode definir uma regra NSG para o ASG geral do banco de dados e outra regra mais específica apenas para o ASG específico do SID.

Os NSGs não restringem o desempenho com as regras que você define para o NSG. Para monitorar o fluxo de tráfego, você pode, opcionalmente, ativar o log de fluxo NSG com logs avaliados por um SIEM (Information Event Management, gerenciamento de eventos de informação) ou um sistema de deteção de intrusão (IDS) de sua escolha para monitorar e agir em atividades suspeitas da rede.

Gorjeta

Ative NSGs somente no nível da sub-rede. Embora os NSGs possam ser ativados no nível de sub-rede e no nível de NIC, a ativação em ambos é muitas vezes um obstáculo na solução de problemas de situações ao analisar restrições de tráfego de rede. Use NSGs no nível da NIC somente em situações excecionais e quando necessário.

Pontos finais privados para serviços

Muitos serviços PaaS do Azure são acessados por padrão por meio de um ponto de extremidade público. Embora o ponto de extremidade de comunicação esteja localizado na rede back-end do Azure, o ponto de extremidade é exposto à Internet pública. Os pontos finais privados são uma interface de rede dentro da sua própria rede virtual privada. Por meio do Azure Private Link, o ponto de extremidade privado projeta o serviço em sua rede virtual. Os serviços PaaS selecionados são então acessados de forma privada através do IP dentro da sua rede. Dependendo da configuração, o serviço pode ser configurado para se comunicar apenas por meio de ponto de extremidade privado.

O uso de um ponto de extremidade privado aumenta a proteção contra vazamento de dados e, muitas vezes, simplifica o acesso de redes locais e emparelhadas. Em muitas situações, o roteamento de rede e o processo para abrir portas de firewall, que geralmente são necessários para pontos de extremidade públicos, são simplificados. Os recursos já estão dentro da sua rede porque são acessados por um ponto de extremidade privado.

Para saber quais serviços do Azure oferecem a opção de usar um ponto de extremidade privado, consulte Serviços disponíveis de Link Privado. Para NFS ou SMB com Arquivos do Azure, recomendamos que você sempre use pontos de extremidade privados para cargas de trabalho SAP. Para saber mais sobre as cobranças incorridas ao usar o serviço, consulte Preços de ponto de extremidade privado. Alguns serviços do Azure podem, opcionalmente, incluir o custo com o serviço. Essas informações estão incluídas nas informações de preços de um serviço.

Encriptação

Dependendo de suas políticas corporativas, a criptografia além das opções padrão no Azure pode ser necessária para suas cargas de trabalho SAP.

Criptografia para recursos de infraestrutura

Por padrão, os discos gerenciados e o armazenamento de blob no Azure são criptografados com uma chave gerenciada pela plataforma (PMK). Além disso, traga sua própria criptografia de chave (BYOK) para discos gerenciados e o armazenamento de blob é suportado para cargas de trabalho SAP no Azure. Para criptografia de disco gerenciado, você pode escolher entre diferentes opções, dependendo dos requisitos de segurança corporativos. As opções de criptografia do Azure incluem:

  • Criptografia do lado do armazenamento (SSE) PMK (SSE-PMK)
  • Chave gerenciada pelo cliente SSE-SSE (SSE-CMK)
  • Encriptação dupla inativa
  • Criptografia baseada em host

Para obter mais informações, incluindo uma descrição da Criptografia de Disco do Azure, consulte uma comparação das opções de criptografia do Azure.

Nota

Atualmente, não use criptografia baseada em host em uma VM que esteja na família de VMs da série M ao executar com Linux devido a uma possível limitação de desempenho. O uso da criptografia SSE-CMK para discos gerenciados não é afetado por essa limitação.

Para implantações SAP em sistemas Linux, não use o Azure Disk Encryption. A Criptografia de Disco do Azure envolve a criptografia executada dentro das VMs SAP usando CMKs do Cofre de Chaves do Azure. Para Linux, o Azure Disk Encryption não oferece suporte às imagens do sistema operacional usadas para cargas de trabalho SAP. O Azure Disk Encryption pode ser usado em sistemas Windows com cargas de trabalho SAP, mas não combine o Azure Disk Encryption com criptografia nativa de banco de dados. Recomendamos que você use a criptografia nativa do banco de dados em vez da Criptografia de Disco do Azure. Para obter mais informações, veja a secção seguinte.

Semelhante à criptografia de disco gerenciado, a criptografia de Arquivos do Azure em repouso (SMB e NFS) está disponível com PMKs ou CMKs.

Para compartilhamentos de rede SMB, analise cuidadosamente os Arquivos do Azure e as dependências do sistema operacional com versões SMB, pois a configuração afeta o suporte à criptografia em trânsito.

Importante

A importância de um plano cuidadoso para armazenar e proteger as chaves de criptografia se você usar a criptografia gerenciada pelo cliente não pode ser exagerada. Sem chaves de criptografia, recursos criptografados, como discos, ficam inacessíveis e podem levar à perda de dados. Considere cuidadosamente proteger as chaves e o acesso às chaves apenas para usuários ou serviços privilegiados.

Criptografia para componentes SAP

A criptografia no nível SAP pode ser separada em duas camadas:

  • Criptografia DBMS
  • Criptografia de transporte

Para criptografia DBMS, cada banco de dados suportado para uma implantação do SAP NetWeaver ou do SAP S/4HANA oferece suporte à criptografia nativa. A criptografia de banco de dados transparente é totalmente independente de qualquer criptografia de infraestrutura em vigor no Azure. Você pode usar SSE e criptografia de banco de dados ao mesmo tempo. Quando você usa criptografia, o local, o armazenamento e a guarda das chaves de criptografia são extremamente importantes. Qualquer perda de chaves de criptografia leva à perda de dados porque você não será capaz de iniciar ou recuperar seu banco de dados.

Alguns bancos de dados podem não ter um método de criptografia de banco de dados ou podem não exigir uma configuração dedicada para habilitar. Para outros bancos de dados, os backups DBMS podem ser criptografados implicitamente quando a criptografia de banco de dados é ativada. Consulte a seguinte documentação do SAP para saber como habilitar e usar a criptografia transparente do banco de dados:

Entre em contato com a SAP ou seu fornecedor de DBMS para obter suporte sobre como habilitar, usar ou solucionar problemas de criptografia de software.

Importante

Não se pode exagerar o quão importante é ter um plano cuidadoso para armazenar e proteger suas chaves de criptografia. Sem chaves de criptografia, o banco de dados ou o software SAP pode ficar inacessível e você pode perder dados. Considere cuidadosamente como proteger as chaves. Permitir o acesso às chaves apenas por utilizadores ou serviços privilegiados.

A criptografia de transporte ou comunicação pode ser aplicada a conexões do SQL Server entre mecanismos SAP e o DBMS. Da mesma forma, você pode criptografar conexões da camada de apresentação SAP (conexão de rede segura SAPGui ou SNC) ou uma conexão HTTPS para um front-end da Web. Consulte a documentação do fornecedor dos aplicativos para habilitar e gerenciar a criptografia em trânsito.

Monitoramento e alerta de ameaças

Para implantar e usar soluções de monitoramento e alerta de ameaças, comece usando a arquitetura da sua organização. Os serviços do Azure fornecem proteção contra ameaças e uma visão de segurança que você pode incorporar ao seu plano geral de implantação do SAP. O Microsoft Defender for Cloud atende ao requisito de proteção contra ameaças. O Defender for Cloud normalmente faz parte de um modelo de governança geral para uma implantação inteira do Azure, não apenas para componentes SAP.

Para obter mais informações sobre soluções de gerenciamento de eventos de informações de segurança (SIEM) e SOAR (resposta automatizada de orquestração de segurança), consulte Soluções Microsoft Sentinel para integração SAP.

Software de segurança dentro de SAP VMs

O SAP Note 2808515 para Linux e o SAP Note 106267 para Windows descrevem os requisitos e as práticas recomendadas quando você usa scanners de vírus ou software de segurança em servidores SAP. Recomendamos que você siga as recomendações do SAP ao implantar componentes SAP no Azure.

Elevada disponibilidade

A alta disponibilidade do SAP no Azure tem dois componentes:

  • Alta disponibilidade da infraestrutura do Azure: alta disponibilidade de serviços de computação (VMs), rede e armazenamento do Azure e como eles podem aumentar a disponibilidade do aplicativo SAP.

  • Alta disponibilidade do aplicativo SAP: como ele pode ser combinado com a alta disponibilidade da infraestrutura do Azure usando a recuperação de serviços. Um exemplo que usa alta disponibilidade em componentes de software SAP:

    • Uma instância SAP (A)SCS e SAP ERS
    • O servidor de banco de dados

Para obter mais informações sobre alta disponibilidade para SAP no Azure, consulte os seguintes artigos:

O Pacemaker no Linux e o cluster de failover do Windows Server são as únicas estruturas de alta disponibilidade para cargas de trabalho SAP que são diretamente suportadas pela Microsoft no Azure. Qualquer outra estrutura de alta disponibilidade não é suportada pela Microsoft e precisará de detalhes de design, implementação e suporte de operações do fornecedor. Para obter mais informações, consulte Cenários suportados para SAP no Azure.

Recuperação após desastre

Muitas vezes, os aplicativos SAP estão entre os processos mais críticos para os negócios em uma empresa. Com base em sua importância e no tempo necessário para estar operacional novamente após uma interrupção imprevista, os cenários de continuidade de negócios e recuperação de desastres (BCDR) devem ser cuidadosamente planejados.

Para saber como atender a esse requisito, consulte Visão geral da recuperação de desastres e Diretrizes de infraestrutura para carga de trabalho SAP.

Backup

Como parte de sua estratégia BCDR, o backup para sua carga de trabalho SAP deve ser parte integrante de qualquer implantação planejada. A solução de backup deve abranger todas as camadas de uma pilha de soluções SAP: VM, sistema operacional, camada de aplicativo SAP, camada DBMS e qualquer solução de armazenamento compartilhado. O backup para serviços do Azure que são usados por sua carga de trabalho SAP e para outros recursos cruciais, como criptografia e chaves de acesso, também deve fazer parte do seu design de backup e BCDR.

O Backup do Azure oferece soluções PaaS para backup:

  • Configuração de VM, sistema operacional e camada de aplicativo SAP (redimensionamento de dados em discos gerenciados) por meio do Backup do Azure para VM. Analise a matriz de suporte para verificar se sua arquitetura pode usar essa solução.
  • Backup de dados e log do banco de dados SQL Server e SAP HANA . Ele inclui suporte para tecnologias de replicação de banco de dados, como replicação de sistema HANA ou SQL Always On, e suporte entre regiões para regiões emparelhadas.
  • Backup de compartilhamento de arquivos por meio dos Arquivos do Azure. Verifique o suporte para NFS ou SMB e outros detalhes de configuração.

Como alternativa, se você implantar os Arquivos NetApp do Azure, as opções de backup estarão disponíveis no nível do volume, incluindo a integração do SAP HANA e do Oracle DBMS com um backup agendado.

As soluções de Backup do Azure oferecem uma opção de exclusão suave para evitar exclusão mal-intencionada ou acidental e para evitar a perda de dados. A exclusão suave também está disponível para compartilhamentos de arquivos que você implanta usando os Arquivos do Azure.

As opções de backup estão disponíveis para uma solução que você mesmo cria e gerencia, ou se você usa software de terceiros. Uma opção é usar os serviços com o Armazenamento do Azure, inclusive usando armazenamento imutável para dados de blob. Essa opção autogerenciada atualmente seria necessária como uma opção de backup DBMS para alguns bancos de dados como SAP ASE ou IBM Db2.

Use as recomendações nas práticas recomendadas do Azure para proteger e validar contra ataques de ransomware .

Gorjeta

Certifique-se de que sua estratégia de backup inclua a proteção da automação da implantação, chaves de criptografia para recursos do Azure e criptografia de banco de dados transparente, se usada.

Backup entre regiões

Para qualquer requisito de backup entre regiões, determine o RTO (Recovery Time Objetive, objetivo de tempo de recuperação) e o RPO (Recovery Point Objetive, objetivo de ponto de recuperação) oferecidos pela solução e se ele corresponde ao design e às necessidades do BCDR.

Migração SAP para o Azure

Não é possível descrever todas as abordagens e opções de migração para a grande variedade de produtos SAP, dependências de versão, sistema operacional nativo e tecnologias DBMS disponíveis. A equipe de projeto da sua organização e os representantes do seu provedor de serviços devem considerar várias técnicas para uma migração suave do SAP para o Azure.

  • Teste o desempenho durante a migração. Uma parte importante do planejamento de migração SAP é o teste de desempenho técnico. A equipe de migração precisa permitir tempo e disponibilidade suficientes para que o pessoal-chave execute testes técnicos e de aplicativos do sistema SAP migrado, incluindo interfaces e aplicativos conectados. Para uma migração SAP bem-sucedida, é fundamental comparar o tempo de execução pré e pós-migração e a precisão dos principais processos de negócios em um ambiente de teste. Use as informações para otimizar os processos antes de migrar o ambiente de produção.

  • Use os serviços do Azure para migração SAP. Algumas cargas de trabalho baseadas em VM são migradas sem alterações para o Azure usando serviços como o Azure Migrate ou o Azure Site Recovery, ou uma ferramenta de terceiros. Confirme diligentemente se a versão do sistema operacional e a carga de trabalho SAP executada são suportadas pelo serviço.

    Muitas vezes, qualquer carga de trabalho de banco de dados não é intencionalmente suportada porque um serviço não pode garantir a consistência do banco de dados. Se o tipo DBMS for suportado pelo serviço de migração, a taxa de alteração ou rotatividade do banco de dados geralmente é muito alta. Os sistemas SAP mais ocupados não atingirão a taxa de alteração permitida pelas ferramentas de migração. Os problemas podem não ser vistos ou descobertos até a migração de produção. Em muitas situações, alguns serviços do Azure não são adequados para migrar sistemas SAP. O Azure Site Recovery e o Azure Migrate não têm validação para uma migração SAP em grande escala. Uma metodologia comprovada de migração SAP é confiar na replicação DBMS ou em ferramentas de migração SAP.

    Uma implantação no Azure em vez de uma migração de VM básica é preferível e mais fácil de realizar do que uma migração local. Estruturas de implantação automatizadas, como o Azure Center for SAP solutions e a estrutura de automação de implantação do Azure, permitem a execução rápida de tarefas automatizadas. Para migrar seu cenário SAP para uma nova infraestrutura implantada usando tecnologias de replicação nativas DBMS, como replicação de sistema HANA, backup e restauração de DBMS ou ferramentas de migração SAP, use conhecimento técnico estabelecido do seu sistema SAP.

  • Expansão da infraestrutura. Durante uma migração SAP, ter mais capacidade de infraestrutura pode ajudá-lo a implantar mais rapidamente. A equipe do projeto deve considerar aumentar o tamanho da VM para fornecer mais CPU e memória. A equipe também deve considerar a expansão do armazenamento agregado de VM e da taxa de transferência de rede. Da mesma forma, no nível de VM, considere elementos de armazenamento, como discos individuais, para aumentar a taxa de transferência com níveis de bursting e desempenho sob demanda para SSD Premium v1. Aumente os valores de IOPS e taxa de transferência se você usar o SSD Premium v2 acima dos valores configurados. Amplie os compartilhamentos de arquivos NFS e SMB para aumentar os limites de desempenho. Lembre-se de que os discos de gerenciamento do Azure não podem ser reduzidos em tamanho e que a redução em tamanho, camadas de desempenho e KPIs de taxa de transferência pode ter vários tempos de resfriamento.

  • Otimize a rede e a cópia de dados. A migração de um sistema SAP para o Azure sempre envolve a movimentação de uma grande quantidade de dados. Os dados podem ser backups ou replicação de bancos de dados e arquivos, uma transferência de dados de aplicativo para aplicativo ou uma exportação de migração SAP. Dependendo do processo de migração usado, você precisa escolher o caminho de rede correto para mover os dados. Para muitas operações de movimentação de dados, usar a Internet em vez de uma rede privada é o caminho mais rápido para copiar dados com segurança para o armazenamento do Azure.

    Usar o ExpressRoute ou uma VPN pode causar gargalos:

    • Os dados de migração usam muita largura de banda e interferem no acesso do usuário a cargas de trabalho em execução no Azure.
    • Os gargalos de rede no local, como um firewall ou limitação de taxa de transferência, geralmente são descobertos apenas durante a migração.

    Independentemente da conexão de rede usada, o desempenho da rede de fluxo único para uma movimentação de dados geralmente é baixo. Para aumentar a velocidade de transferência de dados em vários fluxos TCP, use ferramentas que possam suportar vários fluxos. Aplique técnicas de otimização descritas na documentação do SAP e em muitas postagens de blog sobre este tópico.

Gorjeta

Na etapa de planejamento, é importante considerar todas as redes de migração dedicadas que você usará para grandes transferências de dados para o Azure. Os exemplos incluem backups ou replicação de banco de dados ou o uso de um ponto de extremidade público para transferências de dados para o armazenamento do Azure. O impacto da migração nos caminhos de rede para seus usuários e aplicativos deve ser esperado e mitigado. Como parte do seu planejamento de rede, considere todas as fases da migração e o custo de uma carga de trabalho parcialmente produtiva no Azure durante a migração.

Suporte e operações para SAP

Algumas outras áreas são importantes a considerar antes e durante a implantação do SAP no Azure.

Extensão de VM do Azure para SAP

A Extensão de Monitoramento do Azure, o Monitoramento Avançado e a Extensão do Azure para SAP referem-se a uma extensão de VM que você precisa implantar para fornecer alguns dados básicos sobre a infraestrutura do Azure ao agente de host SAP. As notas SAP podem se referir à extensão como Extensão de monitoramento ou Monitoramento avançado. No Azure, ele é chamado de Extensão do Azure para SAP. Para fins de suporte, a extensão deve ser instalada em todas as VMs do Azure que executam uma carga de trabalho SAP. Para saber mais, consulte Extensão de VM do Azure para SAP.

Suporte SAProuter for SAP

A operação de um cenário SAP no Azure requer conectividade de e para o SAP para fins de suporte. Normalmente, a conectividade é na forma de uma conexão SAProuter, seja através de um canal de rede de criptografia pela internet ou através de uma conexão VPN privada para SAP. Para obter as práticas recomendadas e um exemplo de implementação do SAProuter no Azure, consulte seu cenário de arquitetura em Conexões de Internet de entrada e saída para SAP no Azure.

Próximos passos