Compartilhar via

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 necessários sem concluir um longo ciclo de aquisição. No entanto, a execução da carga de trabalho SAP no Azure requer conhecimento sobre as opções disponíveis e um 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 IaaS (infraestrutura como serviço) e PaaS (plataforma como serviço) do Azure são combinadas para oferecer as melhores opções para uma implantação bem-sucedida de todo o seu cenário empresarial SAP.

Este artigo complementa a documentação do SAP e as notas do SAP, 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, usaremos 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 nas tecnologias tradicionais ABAP (Advanced Business Application Programming) ou Java, ou pode ser um aplicativo que não se baseia no SAP NetWeaver, como o SAP BusinessObjects.
  • Ambiente SAP: vários componentes SAP agrupados logicamente para executar uma função de negócios, como desenvolvimento, garantia de qualidade, treinamento, recuperação de desastre 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 DBMS (sistema de gerenciamento de banco de dados) 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 no Azure. No entanto, você pode operar sistemas diferentes em um cenário SAP no Azure ou no local.

Recursos

O ponto de entrada da 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ê encontrará links para outros artigos que abordam o assunto:

  • Especificidades da carga de trabalho SAP para armazenamento, rede e opções com suporte.
  • Guias do DBMS do SAP para vários sistemas DBMS no Azure.
  • Guias de implantação do SAP, manuais e automatizados.
  • Detalhes sobre a alta disponibilidade e recuperação de desastre 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 pré-requisitos, o processo de instalação e detalhes sobre funcionalidades específicas do SAP, é importante ler cuidadosamente a documentação e os guias do SAP. Este artigo aborda apenas tarefas específicas do software SAP instalado e operado em uma VM (máquina virtual) do Azure.

As seguintes notas do SAP formam a base das diretrizes do Azure para implantações do 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 que usam o Oracle Database
2233094 DB6: aplicativos SAP no Azure que usam 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 NVA (Dispositivos Virtuais de Rede) para SAP no Azure

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

Cenários

Os serviços SAP costumam ser considerados uns dos 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. Normalmente, uma empresa pensa cuidadosamente sobre qual provedor de nuvem escolher para executar esses processos de negócios comercialmente críticos.

O Azure é a plataforma de nuvem pública ideal para aplicativos SAP e processos de negócios comercialmente críticos. A maioria dos softwares SAP atuais, incluindo os sistemas SAP NetWeaver e SAP S/4HANA, podem ser hospedados na infraestrutura do Azure atualmente. O Azure oferece mais de 800 tipos de CPU e VMs que têm vários terabytes de memória.

Para obter descrições dos cenários com suporte e de alguns cenários sem suporte, confira Cenários com suporte à VMs para o SAP no 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 sucesso os sistemas SAP no IaaS do Azure ou no IaaS em geral, é importante entender as diferenças significativas entre as ofertas de nuvens privadas tradicionais e as ofertas de IaaS. Um host tradicional ou terceirizado adapta a infraestrutura (rede, armazenamento e tipo de servidor) à carga de trabalho que o cliente quer hospedar. Em uma implantação de IaaS, é responsabilidade do cliente ou do parceiro avaliar a carga de trabalho potencial e escolher os componentes Azure corretos 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 para as VMs do Azure que você escolheria para seus produtos SAP.
  • Determine quais versões de DBMS em VMs específicas terão suporte para produtos SAP.
  • Avalie se é necessário fazer o upgrade ou atualizar o ambiente SAP para se alinhar às versões necessárias do sistema operacional e do DBMS para obter uma configuração com suporte.
  • Avalie se você precisa migrar para sistemas operacionais diferentes para implantar no Azure.

Os detalhes sobre os componentes SAP com suporte no Azure, as unidades de infraestrutura do Azure e as versões do sistema operacional e do DBMS relacionadas são explicados em Software SAP com suporte para implantações do Azure. O conhecimento obtido ao avaliar o suporte e as dependências entre as versões do SAP, as versões do sistema operacional e as versões do DBMS tem um impacto substancial em seus esforços para mover seus sistemas SAP para o Azure. Você aprenderá se há esforços significativos de preparação envolvidos, por exemplo, se é necessário atualizar a versão do SAP ou alternar para um sistema operacional diferente.

Primeiras etapas para planejar uma implantação

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

As primeiras etapas para planejar uma implantação na nuvem pública são trabalhar com as equipes de conformidade e segurança da sua organização para definir as condições limites para a implantação de cada tipo de carga de trabalho SAP ou processo de negócios. O processo pode ser demorado, mas é fundamental concluir as bases.

Se sua organização já implantou software no Azure, o processo poderá ser fácil. Se a sua empresa estiver mais no início do percurso, talvez sejam necessárias discussões mais amplas para descobrir as condições de limite, as condições de segurança e a arquitetura corporativa que permitem 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 lhe ajudar a planejar suas necessidades de conformidade, confira Ofertas de conformidade da Microsoft.

Planejar a segurança

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

Organizar recursos do Azure

Junto com a análise de segurança e conformidade, se você ainda não tiver feito essa tarefa, planeje como organizar seus recursos do Azure. O processo inclui tomar decisões sobre:

  • Uma convenção de nomenclatura usada para cada recurso do Azure, como para VMs e grupos de recursos.
  • Um design de assinatura e grupo de gerenciamento para sua carga de trabalho SAP, como, por exemplo, se várias assinaturas devem ser criadas por carga de trabalho, por camada de implantação ou para cada unidade de negócios.
  • Uso do Azure Policy em toda a empresa para assinaturas e grupos de gerenciamento.

Para lhe ajudar a tomar as decisões certas, vários 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 houver contratos e regras em vigor para conformidade, segurança e organização de recursos do Azure é que você 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 será implantada 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 é um conjunto 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 de armazenamento, ou que executam a funcionalidade de rede.

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

Nem todas as regiões do Azure oferecem os mesmos serviços. Dependendo do produto SAP que você quer executar, dos requisitos de dimensionamento e do sistema operacional e DBMS necessários, é possível que uma determinada região não ofereça os tipos de VM necessários para o 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 VMs são implantadas em apenas um subconjunto de regiões do Azure.

Ao começar a planejar e pensar em quais regiões escolher como região primária e, eventualmente, como região secundária, é preciso 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 aos tipos de armazenamento do Azure que você pode configurar para replicar em uma região emparelhada. Para obter detalhes, confira Redundância de armazenamento em uma região secundária.

Os tipos de armazenamento que dão 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 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.

Ao verificar as regiões emparelhadas e os serviços que deseja usar em suas regiões primária ou secundária, é 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 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 pareada como região secundária ou de recuperação de desastres e precisa configurar parte da replicação de dados por conta própria.

Zonas de disponibilidade

Várias regiões do Azure usam zonas de disponibilidade para separar fisicamente os locais em uma região do Azure. Cada zona de disponibilidade é composta por um ou mais datacenters equipados com energia, resfriamento 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 DBMS do SAP 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 os 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 os datacenters e a distância entre as zonas de disponibilidade do Azure evoluem. A latência de rede muda conforme a infraestrutura muda.

Siga as diretrizes 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 seus requisitos, 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 falhas está intimamente relacionado à infraestrutura física contida nos datacenters. Embora uma folha 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 para implantar suas VMs em diferentes domínios de falha, de modo que você possa atender aos requisitos de SLAs de disponibilidade. No entanto, você não tem controle direto sobre a distribuição de domínios de falha em uma unidade de escala do Azure (um conjunto de centenas de nós de computação ou nós de armazenamento e rede) nem sobre a 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, será necessário atribuir um conjunto de disponibilidade do Azure às VMs no momento da implantação. Para obter mais informações, confira 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 composto por 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 as VMs no momento da implantação em 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, será necessário atribuir um conjunto de disponibilidade do Azure às VMs no momento da implantação. Para obter mais informações, confira Conjuntos de disponibilidade.

Diagrama que ilustra domínios de atualização e domínios de falha.

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 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, confira 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 nem o conjunto de disponibilidade podem ser atribuídos a uma VM.

É possível combinar conjuntos de disponibilidade e zonas de disponibilidade se você usar grupos de posicionamento por proximidade.

Ao definir os conjuntos de disponibilidade e tentar combinar várias VMs de diferentes famílias de VMs em um conjunto de disponibilidade, você poderá encontrar problemas que impeçam você de incluir um tipo específico de VM em um conjunto de disponibilidade. O motivo é que o conjunto de disponibilidade está associado 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. Ao tentar 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 poderá ocorrer se você estiver redimensionando VMs. Se você tentar mover uma VM para fora da família Edsv5 e 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, desligue todas as VMs que estão em seu conjunto de disponibilidade e redimensione-as para que possam ser executadas no outro tipo de máquina de host. Para obter informações sobre SLAs de VMs implantadas em um conjunto de disponibilidade, confira 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 pela plataforma. Você tem uma opção para criar um conjunto de dimensionamento dentro da região ou ampliá-lo entre zonas de disponibilidade. Ao criar o conjunto de dimensionamento flexível em uma região com platformFaultDomainCount>1 (FD>1), as VMs implantadas no conjunto de dimensionamento seriam distribuídas por um número especificado de domínios de falha na mesma região. Por outro lado, a criação do conjunto de dimensionamento flexível nas zonas de disponibilidade com platformFaultDomainCount=1 (FD=1) distribuiria as VMs na zona especificada e o conjunto de dimensionamento também distribuiria as VMs em diferentes domínios de falha dentro da zona da melhor maneira possível.

Para a carga de trabalho SAP, há suporte apenas para o conjunto de dimensionamento flexível com FD=1. A vantagem de usar conjuntos de dimensionamento 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 dimensionamento seriam distribuídas por diferentes domínios de falha dentro da zona da melhor maneira possível. Para saber mais sobre a implantação da carga de trabalho SAP com conjunto de escalas, confira o 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, confira 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 uma escala flexível com FD=1. Para alternar, você precisa recriar a VM e o disco com restrições de zona de 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 em um conjunto de disponibilidade ou zona de disponibilidade para um conjunto de escala flexível com FD=1. Uma postagem no blog mostra como modificar um sistema SAP HA ou sem HA implantado em um conjunto de disponibilidade ou 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 pode ter um impacto significativo nos aplicativos de negócios. O ideal é que todos os elementos de computação que executam suas VMs SAP estejam 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 devem ser mantidas 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 por proximidade podem atender a essa necessidade. Você pode usar grupos de posicionamento por proximidade com as restrições de local da região do Azure, da zona de disponibilidade e do conjunto de disponibilidade para aumentar a resiliência. Com um grupo de posicionamento por proximidade, é possível combinar a zona de disponibilidade e o conjunto de disponibilidade e, ao mesmo tempo, definir diferentes domínios de atualização e falha. Um grupo de posicionamento por proximidade deve conter apenas um único sistema SAP.

Embora a implantação em um grupo de posicionamento por proximidade possa resultar no posicionamento mais otimizado em termos de latência, a implantação usando um grupo de posicionamento por 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 as famílias de VM. As restrições de famílias de VM, regiões e zonas de disponibilidade podem não dar suporte à colocação. Para obter detalhes e saber mais sobre as vantagens e os possíveis desafios de usar um grupo de posicionamento por proximidade, confira Cenários de grupo de posicionamento por proximidade.

As VMs que não usam grupos de posicionamento por 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 entre zonas (VMs distribuídas entre duas zonas de disponibilidade) de um sistema SAP. O uso de grupos de posicionamento por 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 talvez você queira 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 por meio do SSH (Secure Shell) ou do RDP (Área de Trabalho Remota) do Windows para gerenciamento e administração.
  • Comunicação interna e resolução de nomes entre VMs e 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 mais informações sobre a rede virtual, confira Rede virtual do Azure.

O projeto de rede geralmente é a primeira atividade técnica que você realiza ao implantar o Azure. O suporte a uma arquitetura de empresa central, como o SAP, frequentemente faz parte dos requisitos gerais de rede. No estágio de planejamento, documente a arquitetura de rede proposta com o máximo de detalhes possível. Se você fizer uma alteração em um momento posterior, 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 separar o intervalo em sub-redes de rede. Uma sub-rede de rede pode estar disponível para ser usada por 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 ao planejar sua implantação é definir a rede virtual, as sub-redes e os intervalos de endereços de rede privada. Você não pode alterar a atribuição de rede virtual para recursos como NICs (cartões de interface de rede) para VMs depois que as VMs forem 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 design de rede deve atender a vários requisitos para 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 o S/4HANA ou o 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 permissões por função, camada e SID.
  • As VMs do aplicativo SAP e do banco de dados são executadas na mesma rede virtual, dentro das mesmas sub-redes ou diferentes de uma única rede virtual. Use sub-redes diferentes para VMs de aplicativo e banco de dados. Como alternativa, use o aplicativo dedicado e os ASGs do DBMS para agrupar regras aplicáveis a cada tipo de carga de trabalho na mesma sub-rede.
  • A rede acelerada é habilitada em todos os cartões de rede de todas as VMs para cargas de trabalho SAP, sempre que tecnicamente possível.
  • Verifique o acesso seguro à dependência de serviços centrais, incluindo para DNS (resolução de nomes), gerenciamento de identidade (domínios do Windows Server Active Directory/ID do Microsoft Entra) e acesso administrativo.
  • Forneça acesso a e por pontos de extremidade públicos, conforme necessário. Os exemplos incluem 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 forem necessárias para criar sub-redes designadas que tenham suas próprias rotas e regras de NSG.

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

Considerações sobre a rede virtual

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

  • 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 dos componentes SAP usando o kernel SAP, como o S/4HANA ou o 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 fazer com que os clusters do Pacemaker Linux 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 as regras ASG e NSG se elas permitirem um caminho de comunicação direta.

    Outros cenários em que não há suporte para dispositivos virtuais de rede são:

  • Não há suporte para a segregação da camada de aplicativo SAP e da camada de DBMS em diferentes redes virtuais do Azure. É recomendável separar a camada de aplicativo SAP e a camada de DBMS usando sub-redes dentro da mesma rede virtual do Azure, em vez de usar redes virtuais diferentes 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 deverão ser emparelhadas.

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

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

A resolução do nome do host para o endereço IP por meio do DNS é geralmente um elemento crucial para a rede SAP. Você tem várias opções para configurar a resolução de nomes e IPs no Azure.

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

Assim como nos serviços de DNS, pode ser necessário que o Windows Server Active Directory 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 a atribuição de IP dinâmica e estática. Isso permanece verdadeiro independentemente de a VM estar em execução ou 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 ou fixos às 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 permanecerá atribuído até que a VM e sua NIC sejam excluídas ou até que o endereço IP seja desatribuído. Leve em consideração 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, confira Criar uma VM que tenha um endereço IP privado estático.

Observação

Você deve decidir entre a 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. Não se deve atribuir endereços IP estáticos a uma NIC no sistema operacional convidado. Alguns serviços do Azure, como o Backup do Azure, dependem do fato de que pelo menos a NIC primária esteja configurada para DHCP e não para endereços IP estáticos no sistema operacional. Para obter mais informações, confira Solucionar problemas de backup de VM do Azure.

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

Cada NIC de VM do Azure pode ter vários endereços IP atribuídos a ela. Um IP secundário pode ser usado para um nome do host virtual do SAP, que é mapeado para um registro DNS A ou registro DNS PTR. 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 estaticamente no sistema operacional, pois os IPs secundários geralmente não são atribuídos por meio do DHCP. Cada IP secundário precisa ser da mesma sub-rede à qual a NIC está associada. Um IP secundário pode ser adicionado e removido de uma NIC do Azure sem parar ou desalocar a VM. Para adicionar ou remover o IP primário de uma NIC, a VM deve ser desalocada.

O Azure Load Balancer é usado por arquiteturas de alta disponibilidade do SAP com clusters do Pacemaker. Nesse cenário, o balanceador de carga habilita os nomes de host virtual do SAP. Para obter diretrizes gerais sobre como usar nomes de host virtual, confira a nota do SAP 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. O uso de 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 Standard Load Balancer modifica o caminho de acesso de saída padrão porque sua arquitetura é segura por padrão. As VMs que estão por trás de um Standard Load Balancer 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, confira Conectividade de ponto de extremidade público para VMs usando o Azure Standard Load Balancer.

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 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árias 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 pela vNIC primária e parte do tráfego administrativo ou de back-end é roteado por uma segunda vNIC. Dependendo do sistema operacional e da imagem que você usa, as rotas de tráfego para NICs dentro do sistema operacional podem precisar ser configuradas para o roteamento correto.

O tipo e o tamanho de uma VM determina quantas vNICs uma VM pode ter atribuída. Para obter informações sobre funcionalidade e restrições, confira 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. Todos os adaptadores de rede compartilham a mesma largura de banda. É recomendável o uso de várias NICs somente se as VMs precisarem acessar sub-redes privadas. É recomendável um padrão de design que dependa da funcionalidade do NSG e que simplifica os requisitos de rede e sub-rede. O design deve usar o menor número possível de interfaces de rede e, idealmente, apenas um. Uma exceção é a escalabilidade horizontal 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, é recomendável o uso da sub-rede de uma NIC primária para lidar com o tráfego de rede do usuário.

Redes aceleradas

Para reduzir ainda mais a latência de rede entre as VMs do Azure, é recomendável confirmar 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 um desempenho de rede e latências muito aprimorados. Use-a 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 DBMS do 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 e de 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 os usuários e as aplicações acessem o cenário SAP no Azure, a fim de acessar outros serviços centrais da organização, como o DNS central, o domínio, e a infraestrutura de gerenciamento de segurança e patches.

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

Para implantações locais do SAP, é recomendável o uso de uma conexão privada do Azure ExpressRoute. Para cargas de trabalho SAP menores, regiões remotas ou escritórios menores, a conectividade local do VPN está disponível. O uso do ExpressRoute com uma conexão VPN site a site como um caminho de failover é uma combinação possível de ambos os serviços.

Conectividade com a Internet de entrada e saída

Seu ambiente 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 SaaS do SAP 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, pode ser necessário fornecer acesso aos seus clientes aos 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 para a Internet e para as solicitações de entrada.

Proteja sua rede virtual usando regras NSG, usando marcas 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 de rede 4 e 7.

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 VM 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 correto de VM e sua capacidade para dar suporte à carga de trabalho SAP está descrita em Qual software SAP tem suporte para implantações do Azure. Além disso, a nota do SAP 1928533 lista todas as VMs certificadas do Azure e seus recursos de desempenho medidos pelo parâmetro de comparação SAPS (SAP Application Performance Standard) e suas limitações, caso se apliquem. 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 o mais importante é determinar se os seguintes recursos para uma VM se encaixam em 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 um tipo e família de FM específicos, confira Tamanhos para máquinas virtuais no Azure.

Modelos de preços para VMs do Azure

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

  • Um modelo de preços pago conforme o uso
  • Um plano de economia ou de reserva de um ano
  • Um plano de economia ou de reserva de três anos
  • Um modelo de preço de spot

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

Para saber mais sobre os preços e a flexibilidade dos planos de economia de um ano e três anos e das instâncias reservadas, confira estes artigos:

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

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

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 patch para os serviços do Azure. Você pode agendar a aplicação de patch para dar suporte a sua própria agenda e ciclos. Essa oferta destina-se 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, confira Hosts dedicados do Azure.

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

Sistema operacional para VMs

Ao implantar 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 de sistemas operacionais para Linux e Windows e muitas opções adequadas para sistemas SAP. Você também pode criar ou carregar imagens personalizadas do 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 ambiente SAP (área restrita, desenvolvimento, pré-produção e produção) sincronizadas, usando as mesmas versões de patches e atualizações durante o período de atualização.

VMs de geração 1 e 2

No Azure, você pode implantar uma VM como geração 1 ou 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 de geração 2 no Azure.

Ao implantar 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 de 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 tanto na geração 1 quanto na geração 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

É recomendável usar VMs de geração 2 em todas suas implantações SAP no Azure, independentemente do tamanho da VM. Todas as VMs do Azure mais recentes para SAP são compatíveis com a geração 2 ou estão limitadas apenas à geração 2. Algumas famílias de VM atualmente dão suporte apenas a VMs de geração 2. Algumas famílias de VM que estarão disponíveis em breve poderão dar suporte apenas à geração 2.

É possível determinar se uma VM é da geração 1 ou apenas da 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 geração.

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

Algumas famílias de VM, como a série Mv2, dão suporte apenas à geração 2. O mesmo requisito pode ser verdadeiro para novas famílias de VM no futuro. Nesse cenário, uma VM da geração 1 existente não pode ser redimensionada para trabalhar 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 que você escolher, confira a nota do SAP 1928533.

Limites de desempenho para VMs do Azure

Como uma nuvem pública, o Azure depende do compartilhamento de infraestrutura de maneira segura em toda a sua base de clientes. Para habilitar a escala 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 da VM.

Cada VM tem uma cota diferente de taxa de transferência de disco e rede, o número de discos que podem ser anexados, se ela tem armazenamento temporário local com seus próprios limites de taxa de transferência e IOPS, tamanho de 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, considere os limites de desempenho para cada tamanho de VM. As cotas descritas na documentação representam os valores teóricos máximos alcançáveis. O limite de desempenho de IOPS por disco pode ser alcançado com valores de E/S (entrada/saída) pequenos (por exemplo, 8 KB), mas pode não ser alcançado com valores de E/S grandes (por exemplo, 1 MB).

Assim 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 a serem usadas na implantação do SAP, considere estes fatores:

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

  • Para os sistemas existentes, a taxa de transferência de E/S e o IOPS no servidor DBMS devem ser medidos. Para novos sistemas, o exercício de dimensionamento do novo sistema também deve lhe 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 de 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 do SAP 1928533. O foco deve estar primeiro na VM do DBMS, porque a camada do banco de dados é a camada em um sistema SAP NetWeaver que não é escalada horizontalmente na maioria das implantações. Por outro lado, a camada do aplicativo SAP pode ser escalada horizontalmente. Os guias individuais do DBMS descrevem as configurações de armazenamento recomendadas.

  • Resumir 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 de capacidade de armazenamento calculados.

Serviço do HANA em Instâncias Grandes

O Azure oferece recursos de computação para executar um banco de dados HANA grande com escalabilidade vertical ou horizontal 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 do HANA em Instâncias Grandes está no modo de suspensão e não aceita novos clientes. Ainda é possível fornecer unidades para clientes existentes do HANA em Instâncias Grandes.

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 persistentes e temporários ou não persistentes.

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, confira Armazenamento do Azure para cargas de trabalho SAP. O artigo aborda a arquitetura de armazenamento de cada parte do SAP: sistema operacional, binários de aplicativos, arquivos de configuração, dados de banco de dados, arquivos de log e de rastreamento e interfaces de arquivos com outros aplicativos, sejam eles 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 o tornam ideal para arquivos de troca/página do sistema operacional.

Nenhum aplicativo ou dado de sistema operacional que não seja descartável deve ser armazenado 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, confira a nota do SAP 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 VM em Tamanhos para máquinas virtuais no Azure.

Você não pode 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, ocorre uma falha ao redimensionar entre duas dessas famílias de VM. 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 o tamanho de uma VM que tem um disco temporário local para um tamanho de VM que não tem.

Compartilhamentos e volumes de rede para SAP

Os sistemas SAP geralmente exigem um ou mais compartilhamentos de arquivos de rede. Normalmente, os compartilhamentos de arquivos 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 arquivos que executam aplicativos de terceiros para importação e exportação de arquivos.

Nesses cenários, é recomendável usar um serviço do Azure, como os Arquivos do Azure ou oAzure NetApp Files. Se esses serviços não estiverem disponíveis nas regiões escolhidas, ou se não estiverem disponíveis para a arquitetura da sua solução, as alternativas serão fornecer compartilhamentos de arquivos NFS ou SMB a partir de aplicativos autogerenciados baseados em VM ou de serviços de terceiros. Confira a nota do SAP 2015553 sobre as limitações ao suporte do SAP se você usar serviços de terceiros para camadas de armazenamento em um sistema SAP no Azure.

Devido à natureza geralmente crítica dos compartilhamentos de rede, e como eles costumam ser um ponto único de falha em um design (para alta disponibilidade) ou processo (para a interface de arquivo), é recomendável confiar 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 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 o Azure NetApp Files.
  • Roteamento de rede para sistemas SAP e aplicativos conectados.
  • Uso de um ponto de extremidade privado ou público para os Arquivos do Azure.

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

Observação

Se você usar os Arquivos do Azure para compartilhamentos de rede, é recomendável usar um ponto de extremidade privado. No caso improvável de uma falha na zona, seu cliente NFS será redirecionado automaticamente para uma zona íntegra. Não é necessário montar novamente os compartilhamentos NFS ou SMB em suas VMs.

Segurança para 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 ao usuário final e administrativo e serviços de logon único.
  • Monitoramento de ameaças e operações.

Os tópicos neste capítulo não são uma lista completa 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 do SAP no Azure. Há outros aspectos a serem abordados dependendo dos requisitos de sua empresa ou carga de trabalho. Para obter mais informações sobre o design de segurança, confira os seguintes recursos para obter diretrizes gerais sobre o Azure:

Proteja as redes virtuais usando grupos de segurança

O planejamento do seu cenário SAP no Azure deve incluir algum grau de segmentação de rede, com redes e sub-redes virtuais dedicadas apenas às cargas de trabalho SAP. As melhores práticas para definição de sub-rede são descritas em Rede e em outros guias de arquitetura do Azure. É recomendável usar NSGs com ASGs dentro de NSGs para permitir a conectividade de entrada e saída. Ao criar 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 do 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 somente 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 ativar opcionalmente o log de eventos de fluxo do NSG com os logs avaliados por um SIEM (gerenciamento de eventos e informações de segurança) ou IDS (sistema de detecção de intrusões) de sua escolha para monitorar e agir sobre atividades de rede suspeitas.

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 costuma ser um obstáculo em situações de solução de problemas ao analisar restrições de tráfego de rede. Use NSGs no nível da NIC apenas 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 de back-end do Azure, o ponto de extremidade está 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 Link Privado do Azure, o ponto de extremidade privado projeta o serviço em sua rede virtual. Os serviços de PaaS selecionados são acessados privadamente por meio do IP dentro de sua rede. Dependendo da configuração, o serviço pode ser definido para se comunicar somente por meio do 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 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, confira Serviços disponíveis do Link Privado. Para NFS ou SMB com Arquivos do Azure, é recomendável sempre usar pontos de extremidade privados para cargas de trabalho SAP. Para saber mais sobre os encargos incorridos usando o serviço, confira Preços de ponto de extremidade privado. Alguns serviços do Azure podem incluir opcionalmente o custo com o serviço. Essas informações estã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 podem ser necessárias para suas cargas de trabalho SAP.

Criptografia para recursos de infraestrutura

Por padrão, os discos gerenciados e o armazenamento de blobs no Azure são criptografados com um PMK (chave gerenciada por plataforma). Além disso, há suporte para a criptografia BYOK (Bring Your Own Key) para discos gerenciados e armazenamento de blobs para cargas de trabalho SAP no Azure. Para criptografia de disco gerenciado, você pode escolher entre opções diferentes, dependendo de seus requisitos de segurança corporativa. As opções de criptografia do Azure incluem:

  • PMK da SSE (Criptografia do Serviço de Armazenamento) (SSE-PMK)
  • Chave gerenciada pelo cliente da SSE (SSE-CMK)
  • Criptografia dupla em repouso
  • Criptografia baseada em host

Para obter mais informações, incluindo uma descrição do Azure Disk Encryption, confira uma comparação das opções de criptografia do Azure.

Observação

Atualmente, não use a criptografia baseada em host em uma VM da família de VMs da série M quando estiver sendo executada 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 do SAP em sistemas Linux, não use o Azure Disk Encryption. O Azure Disk Encryption envolve a execução de criptografia dentro das VMs SAP usando CMKs do Azure Key Vault. Para Linux, o Azure Disk Encryption não dá 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 combina o Azure Disk Encryption com a criptografia nativa do banco de dados. É recomendável usar a criptografia nativa do banco de dados em vez do Azure Disk Encryption. Para obter mais informações, consulte a próxima seção.

Semelhante à criptografia de disco gerenciado, a criptografia dos Arquivos do Azure inativos (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 as 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 superestimada. Sem chaves de criptografia, os recursos criptografados, como discos, ficam inacessíveis e podem levar à perda de dados. Considere cuidadosamente proteger as chaves e o acesso às chaves somente para usuários ou serviços privilegiados.

Criptografia para componentes SAP

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

  • Criptografia de DBMS
  • Criptografia de transporte

Para a criptografia de DBMS, cada banco de dados com suporte a uma implantação do SAP NetWeaver ou do SAP S/4HANA oferece suporte à criptografia nativa. A criptografia transparente de banco de dados é totalmente independente de qualquer criptografia de infraestrutura que esteja em vigor no Azure. Você pode usar a SSE e a criptografia de banco de dados ao mesmo tempo. Ao usar criptografia, a localização, o armazenamento e a segurança das chaves de criptografia são extremamente importantes. Qualquer perda de chaves de criptografia leva à perda de dados, pois não será possível iniciar ou recuperar o banco de dados.

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

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

Importante

É muito importante ter um plano cuidadoso para armazenar e proteger suas chaves de criptografia. Sem chaves de criptografia, o banco de dados ou software SAP pode estar inacessível e você pode perder dados. Considere cuidadosamente como proteger as chaves. Permita o acesso às chaves somente por usuários ou serviços privilegiados.

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

Monitoramento e alertas 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 pode ser incorporada ao seu plano geral de implantação do SAP. O Microsoft Defender para Nuvem atende ao requisito de proteção contra ameaças. Normalmente, o Defender para Nuvem faz parte de um modelo de governança geral para toda a implantação do Azure, não apenas para os componentes SAP.

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

Software de segurança dentro de VMs do SAP

A nota do SAP 2808515 para Linux e a nota do SAP 106267 para Windows descrevem os requisitos e melhores práticas ao usar verificações de vírus ou software de segurança em servidores SAP. É recomendável 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 dos 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ço. Um exemplo que usa alta disponibilidade em componentes de software SAP:

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

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

O Pacemaker no Linux e o clustering de failover do Windows Server são as únicas estruturas de alta disponibilidade para cargas de trabalho SAP que têm suporte direto da Microsoft no Azure. Qualquer outra estrutura de alta disponibilidade não tem suporte da Microsoft e precisará de design, detalhes de implementação e suporte de operações do fornecedor. Para obter mais informações, confira Cenários com suporte para SAP no Azure.

Recuperação de desastre

Geralmente, 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 voltar a operar após uma interrupção imprevista, os cenários de BCDR (continuidade dos negócios e recuperação de desastres) devem ser cuidadosamente planejados.

Para saber como atender a esse requisito, confira Visão geral da recuperação de desastres e diretrizes de infraestrutura para a carga de trabalho do 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 aplicativos SAP, camada de DBMS e qualquer solução de armazenamento compartilhado. O backup dos serviços do Azure usados pela carga de trabalho SAP, assim como de outros recursos críticos como chaves de criptografia e 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. Examine a matriz de suporte para verificar se sua arquitetura pode usar essa solução.
  • Backup de log e dados do banco de dados do SQL Server e do SAP HANA. Isso inclui suporte para tecnologias de replicação de banco de dados, como a replicação do sistema HANA ou o 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 o Azure NetApp Files, 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 reversível para evitar exclusão mal-intencionada ou acidental e evitar perda de dados. A exclusão reversível também está disponível para compartilhamentos de arquivos implantados usando os Arquivos do Azure.

As opções de backup estão disponíveis para uma solução que você cria e gerencia por conta própria 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. Atualmente, essa opção autogerenciada seria necessária como uma opção de backup de DBMS para alguns bancos de dados, como SAP ASE ou IBM Db2.

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

Dica

Verifique se sua estratégia de backup inclui a proteção da automação da implantação, das chaves de criptografia dos recursos do Azure e da criptografia transparente do banco de dados, se usada.

Backup entre regiões

Para qualquer requisito de backup entre regiões, determine o RTO (objetivo de tempo de recuperação) e o RPO (objetivo de ponto de recuperação) oferecidos pela solução e se eles correspondem ao seu projeto e às suas necessidades de 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 de sistema operacional nativo e DBMS disponíveis. A equipe de projeto da sua organização e representantes do seu lado do provedor de serviços deve considerar várias técnicas para uma migração tranquila do SAP para o Azure.

  • Desempenho de teste durante a migração. Uma parte importante do planejamento de migração do SAP é o teste de desempenho técnico. A equipe de migração precisa ter 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 bem-sucedida do SAP, é fundamental comparar o runtime pré-migração e pós-migração, além da 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 a migração do SAP. Algumas cargas de trabalho baseadas em VM são migradas sem alterações para o Azure usando serviços como Migrações para Azure ou Azure Site Recovery ou uma ferramenta de terceiros. Confirme diligentemente se a versão do sistema operacional e a carga de trabalho SAP executadas têm suporte do serviço.

    Muitas vezes, qualquer carga de trabalho de banco de dados não tem suporte intencional porque um serviço não pode garantir a consistência do banco de dados. Se o tipo de DBMS tiver suporte para o serviço de migração, a taxa de alteração ou de rotatividade do banco de dados frequentemente será muito alta. Os sistemas SAP mais ocupados não atenderão à taxa de alteração que as ferramentas de migração permitem. 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 as Migrações para Azure não têm validação para uma migração SAP em larga escala. Uma metodologia de migração SAP comprovada é depender da replicação do DBMS ou das ferramentas de migração SAP.

    Uma implantação no Azure em vez de uma migração básica de VM é preferível e mais fácil de realizar do que uma migração local. 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 a replicação do sistema HANA, backup e restauração do DBMS ou ferramentas de migração SAP, é necessário um conhecimento técnico estabelecido do seu sistema SAP.

  • Escalar verticalmente a infraestrutura. Durante uma migração do SAP, ter mais capacidade de infraestrutura pode lhe ajudar a implantar mais rapidamente. A equipe do projeto deve considerar a possibilidade de escalar verticalmente o tamanho da VM para fornecer mais CPU e memória. A equipe também deve considerar escalar verticalmente o armazenamento agregado da VM e a 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 bursting sob demanda e camadas de desempenho para SSD Premium v1. Aumente os valores de IOPS e taxa de transferência se você usar a 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 no tamanho, as camadas de desempenho e os KPIs de taxa de transferência podem ter vários tempos de resfriamento.

  • Otimizar cópia de dados e rede. Migrar um sistema SAP para o Azure sempre envolve mover uma grande quantidade de dados. Os dados podem ser backups de banco de dados e arquivos ou replicação, 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 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.
    • Gargalos de rede locais, como um firewall ou limitação de taxa de transferência, geralmente são descobertos somente durante a migração.

    Independentemente da conexão de rede usada, o desempenho de rede de fluxo único para um movimento de dados geralmente é baixo. Para aumentar a velocidade de transferência de dados em vários fluxos TCP, use ferramentas que podem dar suporte a vários fluxos. Aplique técnicas de otimização descritas na documentação do SAP e em muitas postagens no 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. Exemplos incluem backups ou replicação de banco de dados ou 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 atenuado. Como parte do 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 de considerar 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 do SAP podem à 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, confira Extensão da VM do Azure para SAP.

Suporte do SaProuter para SAP

Operar um cenário SAP no Azure requer conectividade de e para SAP para fins de suporte. Normalmente, a conectividade está 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 para obter um exemplo de implementação do SAProuter no Azure, confira o cenário de arquitetura em Conexões de entrada e de saída para o SAP no Azure.

Próximas etapas