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

Azure ExpressRoute
SAP HANA on Azure Large Instances
Azure Virtual Machines
Azure Virtual Network
Azure NetApp Files

Esta arquitetura de referência mostra um conjunto de práticas comprovadas para executar um SAP NetWeaver de alta disponibilidade com o Oracle Database no Azure. Os princípios de arquitetura são agnósticos ao sistema operacional, no entanto, a menos que especificado de outra forma, a arquitetura é assumida como baseada em 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 em Oracle no Azure.

Baixe um arquivo do Visio desta arquitetura e arquiteturas relacionadas.

Nota

Para implantar essa arquitetura de referência, você precisa do licenciamento apropriado de produtos SAP e outras tecnologias que não sejam 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, em uma implantaçã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 (RTO (Recovery Time Objetive, objetivo de tempo de recuperação), RPO (Recovery Point Objetive, objetivo de ponto de recuperação), expectativas de tempo de atividade, função do sistema) e potencialmente reduzidos a uma única VM. O layout da rede é simplificado para demonstrar os princípios de arquitetura desse ambiente SAP e não se destina a descrever uma rede corporativa completa.

Rede

Redes virtuais. O serviço de Rede Virtual do Azure conecta recursos do Azure entre si com segurança aprimorada. Nessa arquitetura, a rede virtual se conecta ao local por meio de um gateway de rede virtual privada (VPN) implantado no hub de uma topologia hub-spoke. Os aplicativos SAP e o banco de dados estão contidos em sua própria rede virtual falada. As redes virtuais são subdivididas 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 os servidores de aplicativos em uma sub-rede separada e os servidores de banco de dados em outra. Isso permite protegê-los mais facilmente gerenciando as políticas de segurança da 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-and-spoke com várias redes virtuais que são emparelhadas juntas. Essa topologia fornece segmentação e isolamento de rede para serviços implantados no Azure. O emparelhamento permite uma conectividade transparente entre redes virtuais emparelhadas através da rede de backbone da Microsoft.

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

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

Grupos de segurança de aplicativos. Para definir políticas de segurança de rede refinadas dentro de seus NSGs com base em cargas de trabalho centradas em aplicativos, use grupos de segurança de aplicativos em vez de endereços IP explícitos. Eles permitem agrupar VMs por nome e ajudam a proteger aplicativos filtrando o tráfego de segmentos confiáveis da sua rede.

Placas de interface de rede (NICs). As placas de interface de rede permitem toda a comunicação entre máquinas virtuais em uma rede virtual. As implantações SAP locais tradicionais implementam várias NICs por máquina para segregar o tráfego administrativo do tráfego comercial.

No Azure, a rede virtual é uma rede definida por software que envia todo o tráfego através da mesma malha de rede. Portanto, não é necessário usar várias NICs por motivos de desempenho. Mas se sua organização precisar segregar o tráfego, você poderá implantar várias 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 diferentes políticas de controle de acesso 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 obter um esboço completo, consulte a nota SAP 962955. (Para acessar as notas SAP, você precisa de uma conta do SAP Service Marketplace.)

Máquinas virtuais

Essa arquitetura usa máquinas virtuais (VM). Para a camada de aplicativos 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 nos seus requisitos. 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 da Oracle, máquinas virtuais são usadas, tanto para o banco de dados Oracle quanto para VMs de observador Oracle. As VMs de observação nessa arquitetura são menores em comparação com os servidores de banco de dados reais.

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

Grupos de Colocação 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 de proximidade. Para tais 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, adicionar o banco de dados AvSet ao PPG do sistema SAP deve ser feito de forma esparsa e apenas quando necessário. Para obter mais detalhes sobre os cenários de uso para PPGs, consulte 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 da geração 1 ou 2. As VMs de 2ª geração suportam os principais recursos que não estão disponíveis para VMs de 1ª geração. Particularmente para bancos de dados Oracle muito grandes, isso é importante, já que algumas famílias de VMs, como Mv2 ou Mdsv2 , são suportadas apenas como VMs Gen2. Da mesma forma, a certificação SAP on Azure para algumas VMs mais recentes pode exigir que elas sejam apenas Gen2 para suporte total, mesmo que o Azure permita ambas elas. Veja detalhes em SAP Note 1928533 - SAP Applications on Microsoft Azure: Produtos suportados e tipos de VM do Azure.

Como todas as outras VMs que suportam SAP permitem a escolha apenas de Gen2 ou Gen1+2 seletivamente, recomenda-se 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 autorizadas a executar VMs Gen1.

Armazenamento

Essa arquitetura usa discos gerenciados do Azure para máquinas virtuais e compartilhamentos de arquivos do Azure ou Arquivos NetApp do Azure para qualquer requisito de armazenamento compartilhado do Network File System (NFS), como volumes sapmnt e NFS de transporte 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

Elevada 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 seguintes componentes são usados.

No Azure, a implantação da carga de trabalho 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, dentro de uma única zona ou em uma região sem zonas), consulte Arquitetura e cenários de alta disponibilidade para SAP NetWeaver.

Balanceadores de carga. O Azure Load Balancer é usado para distribuir 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 SKU padrão. O balanceador SKU básico não suporta 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.

Nota

As zonas de disponibilidade oferecem suporte à alta disponibilidade (HA) intrarregião, mas não são eficazes para recuperação de desastres (DR). As distâncias entre zonas são demasiado curtas. As regiões DR típicas devem estar a pelo menos 100 milhas de distância da região primária.

Componentes específicos do Oracle. As VMs do Oracle Database 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 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 ou 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 observadoras 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 Oracle nativas sem qualquer 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 respetivo fornecedor de terceiros, respectivamente.

Oracle RAC. Atualmente, o Oracle Real Application Cluster (RAC) não é 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 interrupções de serviço em rack, datacenter ou regionais.

Nível 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 potencial ponto único de falha (SPOF) quando são implantados em uma única 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 respetiva VM. Como isso está fortemente ligado com a 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 os respetivos 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 neste pool de clusters. As VMs usam essas montagens SBD para emitir votos e, assim, alcançar quórum para decisões de agrupamento. A arquitetura contida nesta página NÃO contém 1 ou 3 VMs SBD adicionais.
  • Azure Fence Agent. 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 respetiva escolha de cluster. Os gerenciadores de cluster certificados do Azure de terceiros também podem ser utilizados para fornecer alta disponibilidade dos serviços centrais SAP.

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

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

O Embedded Web Dispatcher no (A)SCS é uma opção especial. Você deve levar 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 satisfazer as preocupações de segurança.

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

Para a parte do aplicativo SAP, consulte os detalhes no guia de arquitetura Run SAP NetWeaver in Windows on Azure.

Considerações

Recuperação após 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 desta arquitetura e arquiteturas relacionadas.

Cada camada arquitetônica na pilha de aplicativos SAP usa uma abordagem diferente para fornecer proteção contra DR. Para obter estratégias de DR 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 meio de vários meios:

  • Backup do Azure. Os scripts fornecidos e mantidos pelo Azure for Oracle Database e pelo Azure Backup for Oracle atendem aos requisitos de backup.
  • Armazenamento do Azure. Usando backups de banco de dados baseados em arquivos, 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, Azure Blob ou Azure Files. Consulte Detalhes documentados sobre como obter backups de dados e logs Oracle.
  • Soluções de backup de terceiros 3rd. Consulte a arquitetura do seu provedor de armazenamento de backup, oferecendo suporte ao Oracle no Azure.

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

Contribuidores

Este artigo é mantido pela Microsoft. Foi originalmente escrito pelos seguintes contribuidores.

Autor principal:

Próximos passos

Comunidades

As comunidades podem responder às suas perguntas e ajudá-lo a configurar uma implementação com êxito. 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: