Editar

Compartilhar via

Implantação do SAP no Azure usando um banco de dados Oracle

Azure ExpressRoute
SAP HANA em Instâncias Grandes do Azure
Máquinas Virtuais do Azure
Rede Virtual do Azure
Azure NetApp Files

Essa arquitetura de referência mostra um conjunto de práticas comprovadas para executar um SAP NetWeaver de alta disponibilidade com Oracle Database no Azure. Os princípios de arquitetura são independentes do sistema operacional, no entanto, a menos que especificado de outra forma, a arquitetura é assumida como baseada no Linux.

O primeiro diagrama mostra uma arquitetura de referência para SAP no Oracle no Azure. Recomendamos que você implante em duas zonas de disponibilidade.

Diagrama da arquitetura de um sistema SAP de produção no Oracle no Azure.

Baixe um arquivo do Visio dessa arquitetura e arquiteturas relacionadas.

Observação

Para implantar essa arquitetura de referência, você precisa do licenciamento apropriado de produtos SAP e outras tecnologias que não são da Microsoft.

Componentes

Esta arquitetura de referência descreve um sistema de produção SAP típico em execução no Oracle Database no Azure, numa implementação altamente disponível para maximizar a disponibilidade do sistema. A arquitetura e seus componentes podem ser personalizados com base nos requisitos de negócios (objetivo de tempo de recuperação (RTO), objetivo de ponto de recuperação (RPO), expectativas de tempo de atividade, função do sistema) e potencialmente reduzidos a uma única VM. O layout de rede é simplificado para demonstrar os princípios da arquitetura desse ambiente SAP e não descreve uma rede corporativa completa.

Rede

Redes virtuais. O serviço Rede Virtual do Azure conecta os recursos do Azure entre si com segurança avançada. Nessa arquitetura, a rede virtual se conecta ao local por meio de um gateway de VPN (rede virtual privada) implantado no hub de uma topologia hub-spoke. Os aplicativos e o banco de dados SAP estão contidos em sua própria rede virtual falada. As redes virtuais são subdividida em sub-redes separadas para cada camada: aplicativo (SAP NetWeaver), banco de dados e serviços compartilhados (como o Azure Bastion).

Essa arquitetura subdivide o espaço de endereço da rede virtual em sub-redes. Coloque servidores de aplicativos em uma sub-rede separada e servidores de banco de dados em outra. Isso permite que você os proteja mais facilmente gerenciando as diretivas de segurança de sub-rede em vez dos servidores individuais e separa claramente as regras de segurança aplicáveis aos bancos de dados dos servidores de aplicativos.

Emparelhamento de rede virtual. Essa arquitetura usa uma topologia de rede hub e spoke com várias redes virtuais emparelhadas. Ela proporciona segmentação de rede e isolamento para serviços implantados no Azure. O emparelhamento permite conectividade transparente entre redes virtuais emparelhadas por meio da rede backbone da Microsoft.

Gateway com redundância de zona. Um gateway conecta redes distintas, estendendo sua rede local para a rede virtual do Azure. Recomendamos que você use o ExpressRoute para criar conexões privadas que não passam pela Internet pública, mas você também pode usar uma conexão site a site. Use gateways de VPN ou do Azure ExpressRoute com redundância de zona para se proteger contra falhas de zona. Confira Gateways de rede virtual com redundância de zona para entender as diferenças entre uma implantação com zonas e uma implantação com redundância de zona. Vale a pena mencionar aqui que os endereços IP usados precisam ser do SKU Standard para uma implantação de zona dos gateways.

Grupos de segurança de rede. Para restringir o tráfego de entrada, saída e intra-sub-rede na rede virtual, crie grupos de segurança de rede (NSGs) que por sua vez são atribuídos a sub-redes específicas. As sub-redes do banco de dados e do aplicativo são protegidas com NSGs específicos da carga de trabalho.

Grupos de segurança do aplicativo. Para definir políticas de segurança de rede refinadas dentro de seus NSGs baseados em cargas de trabalho que são centralizadas nos aplicativos, use grupos de segurança de aplicativo em vez de endereços IP explícitos. Eles permitem que você agrupe VMs por nome e ajudam a proteger aplicativos filtrando o tráfego de segmentos confiáveis da rede.

NICs (Placas de interface de rede). Os cartões de adaptador de rede permitem toda a comunicação entre máquinas virtuais em uma rede virtual. Implantações tradicionais locais da SAP implementam vários NICs por computador para separar o tráfego administrativo do tráfego de negócios.

No Azure, a rede virtual é uma rede definida pelo software que envia todo o tráfego pela mesma malha de rede. Portanto, não é necessário usar várias NICs por motivos de desempenho. No entanto, se sua organização precisa separar o tráfego, você pode implantar vários NICs por VM e conectar cada NIC a uma sub-rede diferente. Em seguida, você pode usar grupos de segurança de rede para impor políticas de controle de acesso diferentes em cada sub-rede.

As NICs do Azure dão suporte a vários IPs. Esse suporte está em conformidade com a prática recomendada pela SAP de usar nomes de host virtual para instalações. Para ver uma descrição completa, confira a nota SAP 962955. (Para acessar o SAP Notes, você precisa de uma conta do SAP Service Marketplace.)

Máquinas virtuais

Essa arquitetura usa VMs (Máquinas Virtuais). Para a camada de aplicativo SAP, as VMs são implantadas para todas as funções de instância - Web Dispatcher e servidores de aplicativos - tanto os serviços centrais SAP (A)SCS e ERS, quanto os servidores de aplicativos (PAS, AAS). Ajuste o número de máquinas virtuais com base em suas necessidades. O guia de planejamento e implementação de Máquinas Virtuais do Azure inclui detalhes sobre a execução do SAP NetWeaver em máquinas virtuais.

Da mesma forma, para todos os fins do Oracle, as máquinas virtuais são usadas, tanto para o Banco de Dados Oracle quanto para as VMs de observadores Oracle. As VMs de observador nessa arquitetura são menores em comparação com os servidores de banco de dados reais.

  • vCPUs VMs restritas. Para potencialmente economizar custos no licenciamento da Oracle, considere a utilização de VMs com restrição de vCPU
  • Famílias de VM certificadas para SAP. Para obter detalhes sobre o suporte da SAP para tipos de máquina virtual do Azure e métricas de taxa de transferência (SAPS), consulte Nota SAP 1928533. (Para acessar o SAP Notes, você precisa de uma conta do SAP Service Marketplace.)

Grupos de posicionamento de proximidade (PPG). Quando as máquinas virtuais são implantadas em zonas de disponibilidade, a latência dentro da zona geralmente é ideal para aplicativos SAP. Em raras situações em que a latência entre o banco de dados e as máquinas virtuais do aplicativo precisa ser reduzida, você pode usar grupos de posicionamento por proximidade. Para essas situações, os PPGs garantem a colocação, o que significa que as máquinas virtuais estão no mesmo datacenter para minimizar a latência do aplicativo. Devido a possíveis restrições com PPGs, a adição do banco de dados AvSet ao PPG do sistema SAP deve ser feita de forma esparsa e somente quando necessário. Para saber mais sobre os cenários de uso de PPGs, confira a documentação vinculada.

Máquinas virtuais de 2ª geração (Gen2). O Azure oferece a opção ao implantar VMs se elas devem ser de geração 1 ou 2. As VMs da Geração 2 dão suporte a recursos importantes que não estão disponíveis nas VMs da Geração 1. Especialmente para bancos de dados Oracle muito grandes, isso é importante, pois algumas famílias de VM, como Mv2 ou Mdsv2, só têm suporte como VMs Gen2. Da mesma forma, a certificação SAP no Azure para algumas VMs mais recentes pode exigir que elas sejam apenas Gen2 para suporte total, mesmo que o Azure permita ambos. Confira mais detalhes na Nota SAP 1928533 – Aplicativos SAP no Microsoft Azure: produtos e tipos de VM do Azure com suporte

Como todas as outras VMs que suportam SAP permitem a escolha de apenas Gen2 ou Gen1+2 seletivamente, é recomendável implantar todas as VMs SAP como Gen2, mesmo que os requisitos de memória sejam muito baixos. Mesmo as menores VMs, uma vez implantadas como Gen2, podem ser dimensionadas para as maiores disponíveis com uma simples operação de desalocação e redimensionamento. As VMs Gen1 só podem ser redimensionadas para famílias de VMs com permissão para executar VMs Gen1.

Armazenamento

Essa arquitetura usa discos gerenciados do Azure para VMs e compartilhamentos de arquivos do Azure ou Arquivos do Azure NetApp paraNFS quaisquer requisitos de armazenamento compartilhado como volumes NFS de transporte sapmnt e SAP. As diretrizes para implantação de armazenamento com SAP no Azure estão em detalhes no guia de tipos de armazenamento do Azure para carga de trabalho SAP

Alta disponibilidade

A arquitetura anterior descreve uma implantação altamente disponível, com cada camada de aplicativo contida em duas ou mais máquinas virtuais. Os componentes a seguir são usados.

No Azure, a implantação da carga de trabalho do SAP pode ser regional ou zonal, dependendo dos requisitos de disponibilidade e resiliência dos aplicativos SAP e da região selecionada. O Azure fornece diferentes opções de implantação, como Conjuntos de Dimensionamento de Máquina Virtual com orquestração flexível (FD=1), zonas de disponibilidade e conjuntos de disponibilidade para aumentar a disponibilidade de recursos. Para obter uma compreensão abrangente das opções de implantação e sua aplicabilidade em diferentes regiões do Azure (inclusive entre zonas, em uma única zona ou em uma região sem zonas), consulte Arquitetura e cenários de alta disponibilidade para SAP NetWeaver.

Load balancers. Azure Load Balancer é usado para distribuir o tráfego para máquinas virtuais nas sub-redes SAP. Ao incorporar o Azure Load Balancer em uma implantação zonal do SAP, certifique-se de selecionar o balanceador de carga de SKU padrão. O balanceador de SKU básico não oferece suporte à redundância zonal.

Considere os fatores de decisão ao implantar VMs entre zonas de disponibilidade para SAP. O uso de grupos de posicionamento de proximidade com uma implantação de zona de disponibilidade precisa ser avaliado e usado apenas para VMs de camada de aplicativo.

Observação

As zonas de disponibilidade dão suporte à alta disponibilidade dentro da região (HA), mas não são eficazes para DR (recuperação de desastres). As distâncias entre as zonas são muito curtas. As regiões de DR típicas devem estar a pelo menos 160 km da região primária.

Componentes específicos do Oracle. As VMs do Banco de Dados Oracle são implantadas em um conjunto de disponibilidade ou em zonas de disponibilidade diferentes. Cada VM contém sua própria instalação do software de banco de dados e do armazenamento de banco de dados local da VM. Configure a replicação síncrona do banco de dados por meio do Oracle Data Guard entre os bancos de dados para garantir a consistência e permitir tempos de serviço RTO & RPO baixos em caso de falhas individuais. Além das VMs de banco de dados, VMs adicionais com o Oracle Data Guard Observer são necessárias para uma configuração de failover de início rápido do Oracle Data Guard. As VMs de observador Oracle monitoram o status do banco de dados e da replicação e facilitam o failover do banco de dados de forma automatizada, sem a necessidade de qualquer gerenciador de cluster. O gerenciamento de replicação de banco de dados pode ser realizado usando o Oracle Data Guard Broker para facilitar o uso.

Para obter detalhes sobre a implantação do Oracle Data Guard, consulte a documentação do Oracle Data Guard no Azure.

Essa arquitetura utiliza ferramentas nativas da Oracle sem nenhum software de cluster real ou a necessidade de um balanceador de carga na camada de banco de dados. Com o Oracle Data Guard Fast-Start Failover e a configuração SAP, o processo de failover é automatizado e os aplicativos SAP se reconectam ao novo banco de dados primário caso ocorra um failover. Existem várias soluções de cluster de terceiros como alternativa, como o SIOS Protection Suite ou o Veritas InfoScale, cujos detalhes de implantação podem ser encontrados na documentação do respectivo fornecedor.

Oracle RAC. O Oracle Real Application Cluster (RAC) não é atualmente certificado ou suportado pela Oracle no Azure. No entanto, as tecnologias e a arquitetura do Oracle Data Guard para alta disponibilidade podem fornecer ambientes SAP altamente resilientes com proteção contra rack, datacenter ou interrupções regionais de serviço.

Camada NFS. Para todas as implantações SAP altamente disponíveis, é necessário usar uma camada NFS resiliente, fornecendo volumes NFS para diretório de transporte SAP, volume sapmnt para binários SAP, bem como volumes adicionais para instâncias (A)SCS e ERS. As opções para fornecer uma camada NFS são:

Cluster de serviços centrais SAP. Essa arquitetura de referência executa os Serviços Centrais em VMs discretas. Os Serviços Centrais são um possível SPOF (ponto único de falha) quando implantados em uma só VM. Para implementar uma solução altamente disponível, é necessário um software de gerenciamento de cluster que automatize o failover de instâncias (A)SCS e ERS para a respectiva VM. Como isso está fortemente ligado à solução NFS escolhida

A solução de cluster escolhida requer um mecanismo para decidir, em caso de indisponibilidade de software ou infraestrutura, qual VM deve servir aos respectivos serviços. Com o SAP no Azure, duas opções estão disponíveis para a implementação baseada em Linux do STONITH - como lidar com VM ou aplicativo que não responde

  • SUSE-Linux-only SBD (STONITH Block Device) - usando uma ou três VMs adicionais que servem como exportações iSCSI de um dispositivo de bloco pequeno, que é acessado regularmente pelas VMs membros do cluster reais, duas VMs (A)SCS/ERS nesse pool de cluster. As VMs usam essas montagens SBD para votar e, assim, obter quórum para decisões de cluster. A arquitetura contida nesta página NÃO contém 1 ou 3 VMs SBD adicionais.
  • Agente de isolamento do Azure. Sem utilizar VMs adicionais, a API de gerenciamento do Azure é usada para verificações regulares da disponibilidade da VM.

Os guias vinculados na seção de camada NFS contêm as etapas e o design necessários para a respectiva escolha de cluster. Os gerenciadores de cluster certificados pelo Azure de terceiros também podem ser utilizados para fornecer alta disponibilidade dos Serviços Centrais do SAP.

Pool de servidores de aplicativos SAP. Dois ou mais servidores de aplicativos em que a alta disponibilidade é alcançada por solicitações de balanceamento de carga por meio do servidor de mensagens SAP ou de despachantes da Web. Cada servidor de aplicativos é independente e não há balanceamento de carga de rede necessário para esse pool de VMs.

Pool do SAP Web Dispatcher. O componente Web Dispatcher é usado como um balanceador de carga para tráfego da SAP entre os servidores de aplicativos SAP. Para obter a alta disponibilidade do SAP Web Dispatcher, o Azure Load Balancer implementa o cluster de failover ou a configuração paralela do Web Dispatcher.

O Web Dispatcher Embedded no SCS é uma opção especial. Leve em conta o dimensionamento adequado devido à carga de trabalho adicional no (A)SCS.

Para comunicações voltadas para a Internet, recomendamos uma solução autônoma na rede de perímetro (também conhecida como DMZ) para atender a preocupações de segurança.

Windows - Implantações de IIS. Este documento, como prefaciado no início, é focado principalmente com implantações baseadas em Linux. Para uso com o Windows, os mesmos princípios de arquitetura se aplicam e não há diferenças de arquitetura com o Oracle entre Linux e Windows.

Para obter parte do aplicativo SAP, consulte os detalhes no guia de arquitetura Executar o SAP NetWeaver no Windows no Azure.

Considerações

Recuperação de desastre

O diagrama a seguir mostra a arquitetura de um sistema SAP de produção no Oracle no Azure. A arquitetura fornece DR e usa zonas de disponibilidade.

Diagrama que mostra uma arquitetura de um sistema SAP de produção no Oracle no Azure.

Baixe um arquivo do Visio dessa arquitetura e arquiteturas relacionadas.

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

Backup

O backup para Oracle no Azure pode ser obtido por vários meios:

  • Backup do Azure. Os scripts fornecidos e mantidos pelo Azure para o Oracle Database e o Backup do Azure para Oracle atendem aos requisitos de backup.
  • Armazenamento do Azure. Usar backups de banco de dados baseados em arquivo, por exemplo, agendados com as ferramentas BR da SAP, para serem armazenados e versionados como arquivos/diretórios nos serviços de armazenamento do Azure Blob NFS, Blob do Azure ou Arquivos do Azure. Veja detalhes documentados sobre como obter backups de dados e logs do Oracle.
  • Soluções de backup de terceiros. Consulte a arquitetura do seu provedor de armazenamento de backup, com suporte ao Oracle no Azure.

Para VMs que não são de banco de dados, o Backup do Azure para VM é recomendado para proteger VMs de aplicativos SAP e infraestrutura envolvente, como o SAP Web Dispatcher.

Colaboradores

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

Autor principal:

Próximas etapas

Comunidades

As comunidades podem responder a perguntas e ajudar você a configurar uma implantação bem-sucedida. Considere estes recursos:

Consulte o seguinte artigo para obter mais informações e exemplos de cargas de trabalho SAP que usam algumas das mesmas tecnologias: