Planejar e implementar uma implantação do 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 se combinam para oferecer opções ideais para uma implantação bem-sucedida de todo o cenário corporativo SAP.

Este artigo complementa a documentação do 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: um aplicativo 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. A estrutura do SAP inclui todos os ambientes de produção e de não produção.
  • Sistema SAP: A combinação de uma camada de sistema de gerenciamento de banco de dados (SGBD) e uma camada de aplicação. 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:

  • Especificações de carga de trabalho SAP para armazenamento, rede e opções compatíveis.
  • Guias de DBMS SAP para vários sistemas DBMS no Azure.
  • Guias de implantação SAP, tanto manuais quanto automatizados.
  • Detalhes de alta disponibilidade e recuperação de desastres para uma carga de trabalho SAP no Azure.
  • Integração com o SAP no Azure com outros serviços e aplicativos de terceiros.

Importante

Para obter os pré-requisitos, o processo de instalação e os detalhes sobre a funcionalidade específica do SAP, é importante ler atentamente a documentação e os guias do SAP. Este artigo aborda apenas tarefas específicas para o 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 observação Title
1928533 Aplicativos SAP no Azure: Produtos com suporte 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 o IBM Db2 para Linux, UNIX e Windows
1999351 Solução de problemas de monitoramento aprimorado do Azure para SAP
1409604 Virtualização no Windows: Monitoramento Avançado
2191498 SAP no Linux com o Azure: Monitoramento Avançado
2731110 Suporte de Network Virtual Appliances (NVA) para SAP no Azure

Para obter as limitações padrão e máximas gerais de assinaturas e recursos do Azure, consulte Limites, cotas e restrições de assinatura e serviço 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 SAP e processos de negócios 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 com suporte e alguns cenários que não são suportados, consulte SAP em cenários com suporte de 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 os sistemas SAP na IaaS do Azure ou na IaaS em geral, é importante entender as diferenças significativas entre as ofertas de nuvens privadas tradicionais e as 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 têm suporte no Azure.
  • Avalie se as versões do sistema operacional que você planeja usar têm suporte 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 o upgrade ou a atualização do cenário SAP é necessário para alinhar com o sistema operacional e as versões de DBMS necessárias para obter uma configuração compatível.
  • Avalie se você precisa mover para sistemas operacionais diferentes para implantar no Azure.

Os detalhes sobre os componentes SAP com suporte no Azure, unidades de infraestrutura do Azure e versões relacionadas do sistema operacional e versões do DBMS são explicados no software SAP com suporte para implantaçõ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ê descobre se esforços significativos de preparação estão envolvidos, por exemplo, se você 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 de 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 sua organização já implantou software no Azure, o processo pode ser fácil. Se sua empresa está mais no início da jornada, discussões maiores podem ser necessárias para descobrir as condições de 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 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 recursos do Azure

Juntamente com a revisão de segurança e conformidade, se você ainda não tiver feito essa tarefa, planeje como organizar 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 assinatura e gerenciamento 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.
  • Uso em toda a empresa da Política do Azure para assinaturas e grupos de gerenciamento.

Para ajudá-lo a tomar as decisões certas, muitos detalhes da arquitetura corporativa são descritos na Estrutura de Adoção de Nuvem do Azure.

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, você deve avançar seu planejamento de implantação.

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

Regiões e geografias 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, dos requisitos de dimensionamento e do sistema operacional e DBMS necessários, é possível que uma região específica não ofereça os tipos de VM necessários para o 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.

Ao começar a planejar e pensar sobre 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, confira Replicação entre regiões no Azure: continuidade dos 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 oferecem suporte à 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 de 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 você verifica se há regiões emparelhadas e os serviços que deseja usar em suas regiões primárias ou secundárias, é possível que os serviços do Azure ou os tipos de VM que você pretende usar em sua região primária não estejam disponíveis na região emparelhada que você deseja usar como uma 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 em uma região do Azure. Cada zona de disponibilidade é composta por um ou mais datacenters equipados com energia, refrigeração e rede independentes. Um exemplo de uso de uma zona de disponibilidade para aprimorar a resiliência é a implantação de 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 de 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 a implantar suas VMs em diferentes domínios de falha, para que você 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 espalhar VMs no momento da implantação por diferentes domínios de atualização, você pode proteger seu sistema SAP contra possíveis tempos 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 em 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 impedir 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 e 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 impedem a inclusão de 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 VM.

Por exemplo, você cria um conjunto de disponibilidade e implanta a primeira VM no conjunto de disponibilidade. A primeira VM adicionada 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áquina virtual 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 uma opção para criar um conjunto de escala dentro da região ou estendê-lo entre zonas de disponibilidade. Ao criar, o conjunto de escala flexível 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 pela zona especificada e o conjunto de escala também distribuiria VMs entre diferentes domínios de falha dentro da zona com base no melhor esforço.

Para carga de trabalho SAP, somente o conjunto de dimensionamento flexível com FD=1 é suportado. A vantagem de usar conjuntos de escala flexíveis com FD=1 para implantação zonal cruzada, 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 da maneira mais esforçada. Para saber mais sobre a implantação de carga de trabalho SAP com conjunto de escala, consulte Guia de implantação de escala de máquina virtual flexível.

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.

Dica

Atualmente, não há uma maneira direta de migrar a carga de trabalho SAP implantada em conjuntos de disponibilidade ou zonas de disponibilidade para escala flexível com FD=1. Para fazer a alternância, você precisa recriar a VM e o disco com restrições de zona a partir de recursos existentes no local. 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 posicionamento por proximidade

A latência de 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 de 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 ao definir diferentes domínios de atualização e falha. Um grupo de posicionamento 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 VM não podem ser combinadas em um grupo de posicionamento de proximidade ou você pode ter problemas se redimensionar entre famílias de VM. As restrições de famílias de VM, regiões e zonas de disponibilidade podem não oferecer suporte à colocation. 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 Windows Remote Desktop (RDP) para gerenciamento e administração.
  • Comunicação interna e resolução de nomes entre VMs e por 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 ao implantar no Azure. O suporte a uma arquitetura corporativa central como a 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 uma VM SAP usar 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 ao planejar sua implantação é definir a rede virtual, as sub-redes e os intervalos de endereços de 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 dos 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 ASGs (grupos de segurança de aplicativos) mantidos nas regras NSG e forneça agrupamentos de função, camada e SID de permissões.
  • As VMs de aplicativo e banco de dados SAP são executadas na mesma rede virtual, dentro das mesmas sub-redes ou de diferentes sub-redes de uma única rede virtual. Use sub-redes diferentes para VMs de aplicativo e banco de dados. Como alternativa, use ASGs de aplicativo dedicado e 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 o acesso seguro para dependência de serviços centrais, inclusive para resolução de nomes (DNS), gerenciamento de identidades (domínios do Active Directory do Windows Server/ID do Microsoft Entra) e acesso administrativo.
  • Forneça acesso a e por pontos de extremidade públicos, conforme necessário. Os exemplos incluem para o 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 sobre a 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 aplicativo SAP e a camada DBMS de componentes SAP usando o kernel SAP, como S/4HANA ou SAP NetWeaver.

    Soluções de virtualização de rede em caminhos de comunicação podem facilmente dobrar a latência de rede entre dois parceiros de comunicação. Eles também podem restringir a taxa de transferência em caminhos críticos entre a camada do aplicativo SAP e a camada do DBMS. Em alguns cenários, os dispositivos virtuais de rede podem causar falha nos clusters Linux do Pacemaker.

    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 nos quais os dispositivos virtuais de rede não são suportados são:

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

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

    O tráfego de rede entre duas redes virtuais do Azure emparelhadas 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 de 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 por meio do DNS geralmente é um elemento crucial para a rede SAP. Você tem muitas opções para configurar a resolução de nome e 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 Active 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 se aplica à 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 será liberada se a NIC for excluída, se a sub-rede for alterada ou se o método de alocação for alterado para estático.

É possível atribuir endereços IP fixos a VMs em 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 geral 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.

Observação

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 nome 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 registro PTR DNS. Um endereço IP secundário deve ser atribuído à configuração de IP da NIC do Azure. Um IP secundário também deve ser configurado no sistema operacional estaticamente porque os IPs secundários geralmente não são atribuídos por meio de 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 realocar a VM. Para adicionar ou remover o IP primário de uma NIC, a VM deve ser desalocada.

Observação

Em configurações de IP secundário, 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 do Pacemaker. Nesse cenário, o balanceador de carga habilita os nomes de host virtual SAP. Para obter orientação geral 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 conseguir mais 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.

Dica

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 placas de interface de rede virtual (vNICs) 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 primária 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 talvez precisem ser configuradas para o 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 você use a sub-rede de uma NIC primária para manipular o tráfego de rede do usuário.

Redes aceleradas

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 melhores. Use-o ao implantar VMs do Azure para cargas de trabalho SAP em todas as VMs com suporte, especialmente para a camada de aplicativo SAP e a camada de DBMS SAP. A documentação vinculada contém dependências de suporte em versões do sistema operacional e instâncias de VM.

Conectividade 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 o DNS central, o domínio e a infraestrutura de gerenciamento de segurança e patch.

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 no Azure ExpressRoute. 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 de saída e entrada da Internet

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, talvez seja necessário fornecer acesso para seus clientes a aplicativos SAP Fiori, com usuários da Internet acessando serviços fornecidos pelo seu cenário SAP. Sua arquitetura de rede SAP exige que você planeje o caminho em direção à Internet e 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 melhores práticas.

VMs do Azure para as cargas de trabalho SAP

Algumas famílias de VMs do Azure são especialmente adequadas para cargas de trabalho SAP e algumas mais especificamente para uma carga de trabalho do SAP HANA. A maneira de encontrar o tipo de VM correto e sua capacidade de oferecer suporte à sua carga de trabalho SAP é descrita em O que o software SAP tem suporte para implantações do Azure. Além disso, o SAP Note 1928533 lista todas as VMs certificadas do Azure e seus recursos de desempenho, conforme medido pelo benchmark e limitações do SAP Application Performance Standard (SAPS), se 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 com suporte, você precisa verificar se esses tipos de VM estão disponíveis em uma região específica com base em 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)
  • Recursos 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 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 preferir usar:

  • Um modelo de precificação 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 precificação à vista

Para obter informações detalhadas sobre os 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 os preços e a flexibilidade dos planos de poupança de um e três anos e das instâncias reservadas, consulte estes artigos:

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

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

O Azure também oferece a opção de usar um host dedicado. O uso de 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 destina-se especificamente a 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 planos de manutenção e aplicação de patches de infraestrutura 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 do 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 todas as camadas de um cenário SAP (sandbox, desenvolvimento, pré-produção e produção) sincronizadas usando as mesmas versões de patches e atualizações durante o período de tempo de atualização.

VMs de geração 1 e geração 2

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 VMs de geração 1 e geração 2 no Azure.

Quando você implanta uma VM, a imagem do sistema operacional escolhida determina se a VM será uma VM de 1ª ou 2ª geração. As versões mais recentes de todas as imagens do sistema operacional para 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 da 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.

Observação

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 mais recentes do Azure para SAP são compatíveis com a geração 2 ou estão limitadas apenas à geração 2. Atualmente, algumas famílias de VMs oferecem suporte apenas a VMs de geração 2. 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 é a geração 1 ou apenas a 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 é 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 nos compartilhamentos NFS (Network File System) ou SMB (Server Message Block) conectados. Discos de dados, compartilhamentos NFS ou compartilhamentos SMB que originalmente foram atribuídos a uma VM de 1ª geração podem ser anexados a uma VM de nova geração 2.

Algumas famílias de VMs, como a série Mv2, suportam apenas a geração 2. O mesmo requisito pode ser verdadeiro para novas famílias de VM no futuro. Nesse cenário, uma VM de geração 1 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 geração 2 para a família de VMs escolhida, consulte a Nota SAP 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 na taxa de transferência de disco e rede, o número de discos que podem ser conectados, 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.

Observação

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 cotas descritas na documentação representam os valores máximos teóricos atingíveis. O limite de desempenho de IOPS por disco pode ser alcançado com valores de entrada/saída (E/S) pequenos (por exemplo, 8 KB), mas pode não ser alcançado com valores de E/S grandes (por exemplo, 1 MB).

Como as VMs, os mesmos limites de desempenho existem 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 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 lhe dar uma ideia geral dos requisitos de E/S no lado do SGBD. 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 na Nota 1928533 do SAP. O foco deve estar na VM do DBMS primeiro porque a camada do banco de dados é a camada em um sistema SAP NetWeaver que não se expande na maioria das implantações. Por outro lado, 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 de Instâncias Grandes do HANA

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

Observação

O serviço de Instâncias Grandes do HANA está no modo sunset e não aceita novos clientes. O fornecimento de unidades para clientes existentes de Grandes Instâncias do HANA ainda é possível.

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 arquivos com outros aplicativos, 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 dispensá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 os tornam ideais para arquivos de swap/página do sistema operacional.

Nenhum aplicativo ou dados não dispensá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 é /dev/sdb device, /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 do Azure NetApp. Se esses serviços não estiverem disponíveis nas regiões escolhidas ou se não estiverem disponíveis para a arquitetura da solução, as alternativas serão fornecer compartilhamentos de arquivos NFS ou SMB de aplicativos autogerenciados baseados em VM 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 frequentemente 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 ID do sistema SAP (SID), por paisagem 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.

Observação

Se você usar os Arquivos do Azure para seus compartilhamentos de rede, recomendamos que você use um ponto de extremidade privado. No caso improvável de uma falha zonal, o cliente NFS redireciona automaticamente para uma zona íntegra. Você não precisa 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 aspectos 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 usuário final e serviços de logon ú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 aspectos a serem abordados, 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ção geral do Azure:

Proteger 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 definidas 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ções) ou um sistema de detecção de intrusão (IDS) de sua escolha para monitorar e agir sobre atividades suspeitas na rede.

Dica

Ative NSGs somente no nível da sub-rede. Embora os NSGs possam ser ativados no nível da sub-rede e no nível da 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 excepcionais e quando necessário.

Pontos de extremidade privados para serviços

Muitos serviços de 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 de extremidade privados são uma interface de rede dentro de 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 de PaaS selecionados são acessados de forma privada por meio do IP dentro da rede. Dependendo da configuração, o serviço pode ser potencialmente definido para se comunicar somente 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árias 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 os encargos incorridos com o uso do 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 são incluídas nas informações de preços de um serviço.

Criptografia

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 por 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 de seus requisitos de segurança corporativa. As opções de criptografia do Azure incluem:

  • Criptografia do lado do armazenamento (SSE) PMK (SSE-PMK)
  • Chave gerenciada pelo cliente SSE, SSE-CMK)
  • Criptografia dupla em repouso
  • 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.

Observação

Atualmente, não use criptografia baseada em host em uma VM que esteja na família VM 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 a Criptografia de Disco do Azure. A Criptografia de Disco do Azure envolve criptografia em execução dentro das VMs SAP usando CMKs do Cofre de Chaves do Azure. Para Linux, a Criptografia de Disco do Azure não oferece suporte às imagens do sistema operacional usadas para cargas de trabalho SAP. A Criptografia de Disco do Azure pode ser usada em sistemas Windows com cargas de trabalho SAP, mas não combina a Criptografia de Disco do Azure com a criptografia nativa do banco de dados. Recomendamos que você use a criptografia nativa de banco de dados em vez da Criptografia de Disco do Azure. Para obter mais informações, consulte a próxima seção.

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, examine 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 criptografia gerenciada pelo cliente não pode ser exagerada. Sem chaves de criptografia, recursos criptografados como discos são 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 com suporte para uma implantação SAP NetWeaver ou 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 de 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 do DBMS podem ser criptografados implicitamente quando a criptografia do banco de dados é ativada. Consulte a seguinte documentação SAP para saber como habilitar e usar a criptografia de banco de dados transparente:

Entre em contato com a SAP ou com 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 podem ficar inacessíveis e você pode perder dados. Considere cuidadosamente como proteger as chaves. Permitir o acesso às chaves somente por usuários ou serviços privilegiados.

A criptografia de transporte ou comunicação pode ser aplicada a conexões do SQL Server entre os 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 com um front-end da Web. Consulte a documentação do fornecedor de 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 exibiçã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 SIEM (gerenciamento de eventos de informações de segurança) 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 VMs SAP

SAP Note 2808515 for Linux e SAP Note 106267 for Windows descrevem requisitos e práticas recomendadas ao usar 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.

Alta 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 o reparo de serviço. 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 suportadas diretamente pela Microsoft no Azure. Qualquer outra estrutura de alta disponibilidade não é suportada pela Microsoft e precisará de design, detalhes de implementação e suporte de operações do fornecedor. Para obter mais informações, consulte Cenários com suporte para SAP no Azure.

Recuperação de 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 de 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 de 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. Revise a matriz de suporte para verificar se sua arquitetura pode usar essa solução.
  • Backup de dados e logs do banco de dados SQL Server e SAP HANA . Ele inclui suporte para tecnologias de replicação de banco de dados, como replicação do sistema HANA ou SQL Always On, e suporte entre regiões para regiões emparelhadas.
  • Backup de compartilhamento de arquivos por meio do Arquivos do Azure. Verifique o suporte para NFS ou SMB e outros detalhes de configuração.

Como alternativa, se você implantar o Azure NetApp Files, as opções de backup estarão disponíveis no nível de 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 usa software de terceiros. Uma opção é usar os serviços com o Armazenamento do Azure, inclusive usando o 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 .

Dica

Certifique-se de que sua estratégia de backup inclua a proteção da automação de 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 Objective, objetivo de tempo de recuperação) e o RPO (Recovery Point Objective, objetivo de ponto de recuperação) oferecidos pela solução e se ele corresponde ao design e às necessidades do BCDR.

Migração do 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 e tecnologias nativas de sistema operacional e DBMS disponíveis. A equipe de projeto da sua organização e os representantes do lado do 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 a equipe principal 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ção 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 será muito alta. A maioria dos sistemas SAP ocupados não atenderá à taxa de alteração permitida pelas ferramentas de migração. Os problemas podem não ser vistos ou descobertos até a migração da 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 larga escala. Uma metodologia comprovada de migração SAP é contar com ferramentas de replicação DBMS ou 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. As estruturas de implantação automatizadas, como o Centro do Azure para soluções SAP 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 do DBMS, como replicação do sistema HANA, backup e restauração do DBMS ou ferramentas de migração SAP, usa o conhecimento técnico estabelecido do seu sistema SAP.

  • Ampliaçã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 da VM, considere elementos de armazenamento como discos individuais para aumentar a taxa de transferência com intermitência sob demanda e níveis de desempenho 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 gerenciados do Azure não podem ser reduzidos em tamanho e que a redução no tamanho, nas camadas de desempenho e nos 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 banco 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 a Rota Expressa ou uma VPN pode levar a gargalos:

    • Os dados de migração usam muita largura de banda e interferem no acesso do usuário às cargas de trabalho em execução no Azure.
    • Os gargalos de rede locais, 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 oferecer suporte a 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.

Dica

No estágio 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 serem consideradas antes e durante a implantação do SAP no Azure.

Extensão da 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 host SAP. As notas SAP podem se referir à extensão como Monitoring Extension ou Enhanced monitoring. No Azure, é 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 para SAP

Operar 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 por meio de um canal de rede de criptografia pela Internet ou por meio de uma conexão VPN privada com o 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 entrada e saída da Internet para SAP no Azure.

Próximas etapas