Editar

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. A arquitetura usa conjuntos 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 em requisitos de negócios (RTO, 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 a um ambiente local por meio de um gateway de VPN (rede virtual privada) implantado no hub de uma topologia de rede 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. Ele não incorre em uma penalidade de desempenho se implantado em uma região.

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. Os gateways do Azure ExpressRoute ou da VPN podem ser implantados em zonas para proteção 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 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 as notas SAP, você precisa de uma conta do SAP Service Marketplace.)

Máquinas virtuais

Essa arquitetura usa VMs (Máquinas Virtuais). Para a camada de aplicativos SAP, as VMs são implantadas para todas as funções de instância - despachante da Web 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 as notas SAP, você precisa de uma conta do SAP Service Marketplace.)

Grupos de posicionamento de proximidade (PPG). Para otimizar a latência de rede, você pode usar grupos de posicionamento de proximidade, que favorecem a colocação, o que significa que as máquinas virtuais estão no mesmo datacenter para minimizar a latência do aplicativo. Eles podem aprimorar muito a experiência do usuário para a maioria dos aplicativos SAP. Devido a possíveis restrições com PPGs, a adição do AvSet de banco de dados ao PPG do sistema SAP deve ser feita de forma esparsa e somente quando necessário devido a latência entre o aplicativo SAP e o tráfego de banco de dados. 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 ampliadas para as maiores disponíveis com uma simples 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 máquinas virtuais e Arquivos do Azure NFS ou Arquivos do Azure NetApp para quaisquer requisitos de armazenamento compartilhado NFS, 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

  • Armazenamento certificado para SAP. Semelhante aos tipos de VM certificados para uso SAP, consulte os detalhes na nota 2015553 SAP e na nota 2039619 SAP.
  • Projeto de armazenamento para SAP em Oracle. Você pode encontrar um design de armazenamento recomendado para SAP no Oracle no Azure em Máquinas Virtuais do Azure, implantação do Oracle DBMS para carga de trabalho SAP. Este artigo fornece orientações específicas sobre o layout do sistema de arquivos, recomendações de dimensionamento de disco e outras opções de armazenamento.
  • Armazenando arquivos do banco de dados Oracle. No Linux, os sistemas de arquivos ext4 ou xfs precisam ser usados para banco de dados, NTFS para implantações do Windows. O Oracle ASM também é suportado para implantações Oracle para Oracle Database 12c Release 2 e superior.
  • Alternativas aos discos gerenciados. Como alternativa, você pode usar o Azure NetApp Files para o banco de dados Oracle. Para obter mais informações, consulte a nota 2039619 do SAP e a documentação do Oracle no Azure . Os volumes NFS dos Arquivos do Azure não se destinam a armazenar arquivos do Banco de Dados Oracle, ao contrário dos Arquivos NetApp do Azure.
  • O SSD Premium v2 do Azure foi projetado para cargas de trabalho críticas de desempenho, como o SAP. Consulte Implantar um SSD Premium v2 para obter os benefícios desta solução de armazenamento e suas limitações atuais.

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 SAP pode ser regional ou zonal, dependendo dos requisitos de disponibilidade e resiliência dos aplicativos SAP. 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.

Balanceadores de cargaAzure 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, mas não são eficazes para DR. 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

Essa arquitetura utiliza ferramentas nativas do Oracle sem qualquer configuração 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 3 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 de 3ª parte, respectivamente.

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, data center 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 ao(s) respectivo(s) serviço(s). 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

  • SBD somenteSUSE-Linux (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. O RedHat não oferece suporte a nenhuma implementação SBD no Azure e, portanto, essa opção só está disponível para o sistema operacional SUSE SLES.
  • 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. 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 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.O Azure forneceu e manteve scripts para bancos de dados Oracle, para facilitar as ações Oracle antes e após a execução do 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 ajudá-lo a configurar uma implantação bem-sucedida. Considere estes recursos:

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