Partilhar via

Carga de trabalho SAP em cenários de máquinas virtuais do Azure suportados

  • Artigo

Projetar a arquitetura de sistemas SAP NetWeaver, Hybris Business one ou S/4HANA no Azure abre muitas oportunidades diferentes para várias arquiteturas e ferramentas a serem usadas para chegar a uma implantação escalável, eficiente e altamente disponível. Embora dependente do sistema operacional ou DBMS usado, há restrições. Além disso, nem todos os cenários com suporte local são suportados da mesma maneira no Azure. Este documento conduzirá as configurações de não alta disponibilidade com suporte e as configurações e arquiteturas de alta disponibilidade usando exclusivamente VMs do Azure.

Nota

O serviço HANA Large Instance está no modo sunset e não aceita mais novos clientes. Ainda é possível fornecer unidades para clientes existentes do HANA Large Instance. Para obter alternativas, verifique as ofertas de VMs do Azure certificadas pelo HANA no Diretório de Hardware do HANA. Para cenários que eram e ainda são suportados para clientes HANA Large Instance existentes com HANA Large Instances, consulte o artigo Cenários suportados para HANA Large Instances.

Restrições gerais da plataforma

O Azure tem várias plataformas além das chamadas VMs nativas do Azure que são oferecidas como serviço primário. HANA Large Instances, que está no modo sunset é uma dessas plataformas. O Azure VMware Services é outro desses serviços primários. Os Serviços VMware do Azure em geral não são suportados pela SAP para hospedar a carga de trabalho SAP. Consulte a nota de suporte SAP #2138865 - SAP Applications on VMware Cloud: Supported Products and VM configurations para obter mais detalhes sobre o suporte VMware em diferentes plataformas.

Além do Ative Directory local, o Azure oferece um serviço SaaS gerenciado do Ative Directory com os Serviços de Domínio Microsoft Entra (AD tradicional gerenciado pela Microsoft) e o Microsoft Entra ID. Os componentes SAP hospedados no sistema operacional Windows geralmente dependem do uso do Windows Ative Directory. Neste caso, o Ative Directory tradicional, tal como está alojado no local por si, ou os Serviços de Domínio Microsoft Entra (ainda em teste). Mas esses componentes SAP não podem funcionar com o ID nativo do Microsoft Entra. O motivo é que ainda existem lacunas maiores na funcionalidade entre o Ative Directory em seu formulário local ou seu formulário SaaS (Serviços de Domínio Microsoft Entra) e o ID nativo do Microsoft Entra. Essa dependência é a razão pela qual as contas do Microsoft Entra não são suportadas para aplicativos baseados no SAP NetWeaver e no S/4 HANA no sistema operacional Windows. As contas tradicionais do Ative Directory precisam ser usadas nesses cenários.

Serviço AD Aplicativos suportados baseados em SAP NetWeaver e S/4 HANA no sistema operacional Windows
Ative Directory do Windows local Suportado
Microsoft Entra Domain Services Suportado
Microsoft Entra ID Não suportado

O acima não afeta o uso de contas do Microsoft Entra para cenários de logon único (SSO) com aplicativos SAP.

Configuração de 2 camadas

Considera-se que uma configuração SAP de 2 camadas é construída a partir de uma camada combinada do DBMS SAP e da camada de aplicativos executados no mesmo servidor ou unidade VM. A segunda camada é considerada a camada de interface do usuário. Para uma configuração de 2 camadas, o DBMS e a camada de aplicativos SAP compartilham os recursos da VM do Azure. Como resultado, você precisa configurar os diferentes componentes de forma que esses componentes não compitam por recursos. Você também precisa ter cuidado para não sobrescrever os recursos da VM. Essa configuração não fornece nenhuma alta disponibilidade, além dos contratos de Nível de Serviço do Azure dos diferentes componentes do Azure envolvidos.

Uma representação gráfica de tal configuração pode se parecer com:

Configuração simples de 2 camadas

Tais configurações são suportadas com Windows, Red Hat, SUSE e Oracle Linux para os sistemas DBMS do SQL Server, Oracle, DB2, maxDB e SAP ASE para casos de produção e não produção. Para SAP HANA como DBMS, o SAP suporta esse cenário, conforme indicado na nota SAP #1953429. Até agora, nenhuma das distros Linux forneceu documentação HA suficiente para configurar e operar um cluster Pacemaker em tal configuração. Como resultado, esse tipo de configuração é suportado no Azure apenas para casos que não são de produção e que não exigem um cluster de failover de alta disponibilidade.

Para todas as combinações de OS/DBMS suportadas no Azure, este tipo de configuração é suportado. No entanto, é obrigatório que você defina a configuração do DBMS e dos componentes SAP de forma que os componentes DBMS e SAP não compitam por recursos de memória e CPU e, com isso, excedam os recursos físicos disponíveis. Isso precisa ser feito restringindo a memória que o DBMS tem permissão para alocar. Você também precisa limitar a memória estendida do SAP em instâncias de aplicativos. Você também precisa monitorar o consumo de CPU da VM em geral para garantir que os componentes não estejam maximizando os recursos da CPU.

Nota

Para sistemas SAP de produção, recomendamos configurações adicionais de alta disponibilidade e eventual recuperação de desastres, conforme descrito mais adiante neste documento

Configuração de 3 camadas

Nessas configurações, você separa a camada de aplicativo SAP e a camada DBMS em VMs diferentes. Você geralmente faz isso para sistemas maiores e por motivos de ser mais flexível nos recursos da camada de aplicativos SAP. Na configuração mais simples, não há alta disponibilidade além dos contratos de Nível de Serviço do Azure dos diferentes componentes do Azure envolvidos.

A representação gráfica tem a seguinte aparência:

Diagrama que mostra uma configuração simples de 3 camadas.

Esse tipo de configuração é suportado no Windows, Red Hat, SUSE e Oracle Linux para os sistemas DBMS do SQL Server, Oracle, Db2, SAP HANA, maxDB e SAP ASE para casos de produção e não produção. Para simplificar, não fizemos distinção entre SAP Central Services e instâncias de diálogo SAP na camada de aplicativos SAP. Nessa configuração simples de 3 camadas, não haveria proteção de alta disponibilidade para o SAP Central Services.

Nota

Para sistemas SAP de produção, recomendamos configurações adicionais de alta disponibilidade e eventual recuperação de desastres, conforme descrito mais adiante neste documento

Várias instâncias de DBMS por VM

Nesse tipo de configuração, você hospeda várias instâncias de DBMS por VM do Azure. A motivação pode ser ter menos sistemas operacionais para manter e com isso custos reduzidos. Outras motivações são ter mais flexibilidade e mais eficiência compartilhando recursos de uma VM maior ou unidade de instância grande HANA entre várias instâncias DBMS. Até agora, essas configurações estavam aparecendo principalmente para sistemas que não eram de produção.

Uma configuração como essa pode se parecer com:

Várias instâncias de DBMS em uma unidade

Este tipo de implantação de DBMS é suportado para:

Ao executar várias instâncias de banco de dados em um host, você precisa certificar-se de que as diferentes instâncias não estão competindo por recursos e, assim, excedem os limites de recursos físicos da VM. Isso é especialmente verdadeiro para a memória, onde você precisa limitar a memória que qualquer uma das instâncias que compartilham a VM pode alocar. Isso também pode ser verdade para os recursos da CPU que as diferentes instâncias de banco de dados podem consumir. Todos os sistemas de banco de dados mencionados têm configurações que permitem limitar a alocação de memória e os recursos da CPU em um nível de instância. Para ter suporte para essa configuração para VMs do Azure, espera-se que os discos ou volumes usados para os dados e arquivos de log de log/refazer dos bancos de dados gerenciados pelas diferentes instâncias sejam separados. Ou, em outras palavras, dados ou arquivos de log de log/refazer de bancos de dados gerenciados por diferentes instâncias do DBMS não devem compartilhar os mesmos discos ou volumes.

Nota

Para sistemas SAP de produção, recomendamos configurações adicionais de alta disponibilidade e eventual recuperação de desastres, conforme descrito mais adiante neste documento. Não há suporte para VMs com várias instâncias de DBMS com as configurações de alta disponibilidade descritas posteriormente neste documento.

Várias instâncias de diálogo SAP em uma VM

Em muitos casos, várias instâncias de diálogo foram implantadas em servidores bare metal ou até mesmo em VMs executadas em nuvens privadas. A razão para tais configurações era adaptar determinadas instâncias de diálogo SAP a determinadas cargas de trabalho, funcionalidades de negócios ou tipos de carga de trabalho. A razão para não isolar essas instâncias em VMs separadas foi o esforço de manutenção e operações do sistema operacional. Ou, em muitos casos, os custos, caso o hoster ou operador da VM esteja solicitando uma taxa mensal por VM operada e administrada. No Azure, um cenário de hospedagem de várias instâncias de diálogo SAP em uma única VM é suportado para fins de produção e não produção nos sistemas operacionais Windows, Red Hat, SUSE e Oracle Linux. O PHYS_MEMSIZE de parâmetros do kernel SAP, disponível em kernels Windows e Linux modernos, deve ser definido se várias instâncias do SAP Application Server estiverem sendo executadas em uma única VM. também é aconselhável limitar a expansão da memória estendida SAP em sistemas operacionais, como o Windows, onde o crescimento automático da memória estendida SAP é implementado. Isso pode ser feito com o parâmetro em/max_size_MBde perfil SAP.

Na configuração de 3 camadas, onde várias instâncias de diálogo SAP são executadas dentro das VMs do Azure, as VMs podem ter a seguinte aparência:

Diagrama que mostra uma configuração de 3 camadas em que várias instâncias de diálogo SAP são executadas em VMs do Azure.

Para simplificar, não fizemos distinção entre SAP Central Services e instâncias de diálogo SAP na camada de aplicativos SAP. Nessa configuração simples de 3 camadas, não haveria proteção de alta disponibilidade para o SAP Central Services. Para sistemas de produção, não é recomendado deixar o SAP Central Services desprotegido. Para obter detalhes sobre as chamadas configurações multi-SID em torno das instâncias centrais do SAP e a alta disponibilidade dessas configurações multi-SID, consulte as seções posteriores deste documento.

Proteção de alta disponibilidade para a camada SAP DBMS

Ao procurar implantar sistemas de produção SAP, você precisa considerar o tipo hot standby de configurações de alta disponibilidade. Especialmente com o SAP HANA, onde os dados precisam ser carregados na memória antes de serem capazes de recuperar o desempenho e a escalabilidade completos, a recuperação de serviços do Azure não é uma medida ideal para alta disponibilidade.

Em geral, a Microsoft suporta apenas configurações de alta disponibilidade e pacotes de software descritos nos cenários de carga de trabalho SAP. Você pode ler a mesma declaração na nota SAP #1928533. A Microsoft não fornecerá suporte para outras estruturas de software de terceiros de alta disponibilidade que não sejam documentadas pela Microsoft com a carga de trabalho SAP. Nesses casos, o fornecedor terceirizado da estrutura de alta disponibilidade é a parte de suporte para a configuração de alta disponibilidade que precisa ser envolvida por você como cliente no processo de suporte. As exceções serão mencionadas neste artigo.

Em geral, a Microsoft dá suporte a um conjunto limitado de configurações de alta disponibilidade em VMs do Azure ou unidades de Instâncias Grandes do HANA.

Para VMs do Azure, as seguintes configurações de alta disponibilidade são suportadas no nível DBMS:

Importante

Para nenhum dos cenários descritos acima, oferecemos suporte a configurações de várias instâncias DBMS em uma VM. Significa que, em cada um dos casos, apenas uma instância de banco de dados pode ser implantada por VM e protegida com os métodos de alta disponibilidade descritos. A proteção de várias instâncias de DBMS no mesmo cluster de failover do Windows ou do Pacemaker NÃO é suportada neste momento. Além disso, o Oracle Data Guard é suportado apenas para instâncias únicas por casos de implantação de VM.

Vários sistemas de banco de dados permitem hospedar vários bancos de dados em uma instância DBMS. Como no SAP HANA, vários bancos de dados podem ser hospedados em vários contêineres de banco de dados (MDC). Para casos em que essas configurações de vários bancos de dados estão funcionando em um recurso de cluster de failover, essas configurações são suportadas. As configurações sem suporte são casos em que vários recursos de cluster seriam necessários. Quanto às configurações em que você definiria vários Grupos de Disponibilidade do SQL Server, em uma instância do SQL Server.

Configuração de HA do DBMS

Dependendo do DBMS e/ou dos sistemas operacionais, componentes como o balanceador de carga do Azure podem ou não ser necessários como parte da arquitetura da solução.

Especificamente para o maxDB, a configuração de armazenamento precisa ser diferente. Com o maxDB, os dados e os arquivos de log precisam estar localizados no armazenamento compartilhado para configurações de alta disponibilidade. Somente para maxDB, o armazenamento compartilhado é suportado para alta disponibilidade. Para todos os outros DBMS, pilhas de armazenamento separadas por nó são as únicas configurações de disco suportadas.

Outras estruturas de alta disponibilidade são conhecidas por existirem e também são executadas no Microsoft Azure. No entanto, a Microsoft não testou essas estruturas. Se você quiser criar sua configuração de alta disponibilidade com essas estruturas, precisará trabalhar com o provedor desse software para:

  • Desenvolver uma arquitetura de implantação
  • Implantação da arquitetura
  • Apoio à arquitetura

Importante

O Microsoft Azure Marketplace oferece uma variedade de dispositivos flexíveis que fornecem soluções de armazenamento sobre o armazenamento nativo do Azure. Esses dispositivos flexíveis também podem ser usados para criar compartilhamentos NFS que, teoricamente, poderiam ser usados nas implantações de expansão do SAP HANA onde um nó em espera é necessário. Devido a vários motivos, nenhum desses dispositivos de software de armazenamento é suportado para qualquer uma das implantações de DBMS pela Microsoft e SAP no Azure. Implantações de DBMS em compartilhamentos SMB não são suportadas neste momento. As implantações de DBMS em compartilhamentos NFS são limitadas a compartilhamentos NFS 4.1 em Arquivos NetApp do Azure.

Alta disponibilidade para SAP Central Service

O SAP Central Services é um segundo ponto único de falha da sua configuração SAP. Como resultado, você também precisaria proteger esses processos dos Serviços Centrais. A oferta suportada e documentada para a carga de trabalho SAP é a seguinte:

Das soluções listadas, você precisa de um relacionamento de suporte com a SIOS para dar suporte ao produto e se envolver diretamente com a Datakeeper SIOS se forem encontrados problemas. Dependendo da forma como licenciou o sistema operativo Windows, Red Hat e/ou SUSE, também poderá ter de ter um contrato de suporte com o seu fornecedor de SO para ter suporte total das configurações de alta disponibilidade listadas.

A configuração também pode ser exibida como:

Configuração de HA DBMS e ASCS

No lado direito dos gráficos, o SAP Central Services altamente disponível é mostrado. Além de ter os serviços SAP Central protegidos com uma estrutura de cluster de failover que pode fazer failover em cenários de falha. Há uma necessidade de um compartilhamento NFS ou SMB altamente disponível, ou um disco compartilhado do Windows para garantir que o sapmnt e o diretório de transporte global estejam disponíveis independentemente da existência de uma única VM. Algumas das soluções adicionais, como o Windows Failover Cluster Server e o Pacemaker, exigirão um balanceador de carga do Azure para direcionar ou redirecionar o tráfego para um nó íntegro.

Na lista mostrada, não há menção ao sistema operacional Oracle Linux. O Oracle Linux não suporta o Pacemaker como uma estrutura de cluster. Se você deseja implantar seu sistema SAP no Oracle Linux e precisa de uma estrutura de alta disponibilidade para Oracle Linux, você precisa trabalhar com fornecedores terceirizados. Um dos fornecedores é o SIOS com seu Protection Suite for Linux que é suportado pelo SAP no Azure. Para obter mais informações, leia a nota SAP #1662610 - Detalhes do suporte para o SIOS Protection Suite for Linux para obter mais detalhes.

Armazenamento suportado com os cenários do SAP Central Services listados acima

Como apenas um subconjunto de tipos de armazenamento do Azure está fornecendo compartilhamentos NFS ou SMB altamente disponíveis, essa qualidade para uso em nossos cenários de cluster do SAP Central Services, uma lista de tipos de armazenamento suportados

  • O Servidor de Cluster de Failover do Windows com o Servidor de Arquivos de Expansão do Windows pode ser implantado em todos os tipos de armazenamento nativos do Azure, exceto Arquivos NetApp do Azure. No entanto, a recomendação é usar o Armazenamento Premium devido a contratos de nível de serviço superiores em taxa de transferência e IOPS.
  • O Servidor de Cluster de Failover do Windows com SMB nos Arquivos NetApp do Azure é suportado nos Arquivos NetApp do Azure. Os compartilhamentos SMB hospedados nos serviços de Arquivo Premium do Azure também são suportados para esse cenário. Os Arquivos Padrão do Azure não são suportados
  • O Servidor de Cluster de Failover do Windows com disco compartilhado do Windows baseado em SIOS Datakeeper pode ser implantado em todos os tipos de armazenamento nativos do Azure, exceto Arquivos NetApp do Azure. No entanto, a recomendação é usar o Armazenamento Premium devido a contratos de nível de serviço superiores em taxa de transferência e IOPS.
  • SUSE ou Red Hat Pacemaker usando compartilhamentos NFS no Azure NetApp Files são suportados.
  • SUSE ou Red Hat Pacemaker usando compartilhamentos NFS no Azure Premium Files usando LRS ou ZRS s suportados. Os Arquivos Padrão do Azure não são suportados
  • O SUSE Pacemaker usando uma drdb configuração entre duas VMs é suportado usando tipos de armazenamento nativos do Azure, exceto Arquivos NetApp do Azure. No entanto, recomendamos usar um dos serviços primários com Arquivos Premium do Azure ou Arquivos NetApp do Azure.
  • O Red Hat Pacemaker usado glusterfs para fornecer compartilhamento NFS é suportado usando tipos de armazenamento nativos do Azure, exceto Arquivos NetApp do Azure. No entanto, recomendamos usar um dos serviços primários com Arquivos Premium do Azure ou Arquivos NetApp do Azure.

Importante

O Microsoft Azure Marketplace oferece uma variedade de dispositivos flexíveis que fornecem soluções de armazenamento sobre o armazenamento nativo do Azure. Esses dispositivos de software de armazenamento também podem ser usados para criar compartilhamentos NFS ou SMB que, teoricamente, também poderiam ser usados nos SAP Central Services clusterizados de failover. Essas soluções não são suportadas diretamente para a carga de trabalho SAP pela Microsoft. Se você decidir usar essa solução para criar seu compartilhamento NFS ou SMB, o suporte para a configuração do SAP Central Service precisará ser fornecido pelo terceiro proprietário do software no dispositivo de armazenamento.

Clusters de failover do SAP Central Services Multi-SID

Para reduzir o número de VMs necessárias em grandes cenários SAP, o SAP permite executar instâncias SAP Central Services de vários sistemas SAP diferentes na configuração de cluster de failover. Imagine casos em que você tem 30 ou mais sistemas de produção NetWeaver ou S/4HANA. Sem clustering multi-SID, essas configurações exigiriam 60 ou mais VMs em 30 ou mais configurações de cluster de failover do Windows ou Pacemaker. A implantação de vários serviços centrais SAP em dois nós em uma configuração de cluster de failover pode reduzir significativamente o número de VMs. No entanto, a implantação de várias instâncias de serviços SAP Central em uma única configuração de cluster de dois nós também tem algumas desvantagens. Os problemas relacionados a uma única VM na configuração do cluster se aplicam a vários sistemas SAP. A manutenção no SO convidado em execução na configuração do cluster requer mais coordenação, uma vez que vários sistemas SAP de produção são afetados. Ferramentas como o SAP LaMa não suportam clustering multi-SID em seu processo de clonagem de sistema.

No Azure, há suporte para uma configuração de cluster multi-SID para o sistema operacional Windows com ENSA1 e ENSA2. A recomendação é não combinar a arquitetura mais antiga do Enqueue Replication Service (ENSA1) com a nova arquitetura (ENSA2) em um cluster multi-SID. Detalhes sobre tal arquitetura estão documentados nos artigos

Para SUSE, um cluster multi-SID baseado em Pacemaker também é suportado. Até agora, a configuração é suportada para:

  • Um máximo de cinco instâncias SAP ASCS/SCS
  • A antiga arquitetura de gelo do servidor de replicação enqueue (ENSA1)
  • Configurações de cluster Pacemaker de dois nós

A configuração está documentada em Guia multi-SID de alta disponibilidade para SAP NetWeaver em VMs do Azure no SUSE Linux Enterprise Server for SAP para aplicativos SAP

Um cluster multi-SID com o servidor de Replicação Enqueue tem a aparência esquemática

Diagrama que mostra um cluster multi-SID com o servidor de replicação Enqueue.

Cenários de expansão do SAP HANA

Os cenários de expansão do SAP HANA são suportados para um subconjunto das VMs do Azure certificadas pelo HANA, conforme listado no diretório de hardware do SAP HANA. Todas as VMs marcadas com 'Sim' na coluna 'Clustering' podem ser usadas para expansão OLAP ou S/4HANA. As configurações sem espera são suportadas com os tipos de Armazenamento do Azure de:

  • Azure Premium Storage v1, incluindo o acelerador Azure Write para o volume /hana/log
  • Armazenamento Premium do Azure v2
  • Disco Ultra
  • Azure NetApp Files

As configurações de expansão do SAP HANA para OLAP ou S/4HANA com nó(s) em espera são suportadas exclusivamente com NFS compartilhado hospedado nos Arquivos NetApp do Azure.

Para obter mais informações sobre configurações exatas de armazenamento com ou sem nó de espera, verifique os artigos:

Cenário de recuperação de desastres

Há uma variedade de cenários de recuperação de desastres que são suportados. Definimos arquiteturas de desastre como arquiteturas, que devem compensar uma região completa do Azure saindo da grade. Isso significa que precisamos que o destino de recuperação de desastres seja uma região diferente do Azure como destino para executar seu cenário SAP. Separamos métodos e configurações em camada DBMS e camada não-DBMS.

Camada DBMS

Para a camada DBMS, há suporte para configurações que usam os mecanismos de replicação nativos do DBMS, como Always On, Oracle Data Guard, DB2 HADR, SAP ASE Always-On ou HANA System Replication. nesses casos, é obrigatório que o fluxo de replicação seja assíncrono, em vez de síncrono, como em cenários típicos de alta disponibilidade implantados em uma única região do Azure. Um exemplo típico dessa configuração de recuperação de desastres DBMS suportada é descrito no artigo Disponibilidade do SAP HANA em regiões do Azure. O segundo gráfico nessa seção descreve um cenário com HANA como exemplo. Os principais bancos de dados suportados para aplicativos SAP podem ser implantados em tal cenário.

há suporte para usar uma VM menor como instância de destino na região de recuperação de desastres, uma vez que essa VM não enfrenta todo o tráfego de carga de trabalho. Ao fazer isso, você precisa ter em mente as seguintes considerações:

  • Tipos de VM menores não permitem que muitos discos sejam conectados do que VMs menores
  • VMs menores têm menos taxa de transferência de rede e armazenamento
  • O redimensionamento entre famílias de VMs pode ser um problema quando as VMs diferentes são coletadas em um Conjunto de Disponibilidade do Azure ou quando o redimensionamento deve acontecer entre a família M-Series e a família Mv2 de VMs
  • Consumo de CPU e memória para a instância de banco de dados sendo capaz de receber o fluxo de alterações com atraso mínimo e recursos de CPU e memória suficientes para aplicar essas alterações com atraso mínimo aos dados

Mais detalhes sobre limitações de diferentes tamanhos de VM podem ser encontrados na página Tamanhos de VM

Outro método suportado de implantação de um destino DR é ter uma segunda instância DBMS instalada em uma VM que execute uma instância DBMS não produtiva de uma instância SAP que não seja de produção. Isso pode ser um pouco mais desafiador, pois você precisa descobrir o que na memória, recursos da CPU, largura de banda de rede e largura de banda de armazenamento é necessário para as instâncias de destino específicas que devem funcionar como instância principal no cenário de DR. Especialmente no HANA, é altamente recomendável configurar a instância que funciona como destino de DR em um host compartilhado para que os dados não sejam pré-carregados na instância de destino de DR.

Nota

O uso do Azure Site Recovery não foi testado para implantações de DBMS sob a carga de trabalho SAP. Como resultado, não é suportado para a camada DBMS de sistemas SAP neste momento. Não há suporte para outros métodos de replicações da Microsoft e SAP que não estão listados. O uso de software de terceiros para replicar a camada DBMS de sistemas SAP entre diferentes regiões do Azure precisa ser suportado pelo fornecedor do software e não será suportado pelos canais de suporte da Microsoft e SAP.

Camada não-DBMS

Para a camada de aplicativos SAP e eventuais compartilhamentos ou locais de armazenamento necessários, os dois cenários principais são usados pelos clientes:

  • Os destinos de recuperação de desastres na segunda região do Azure não estão sendo usados para fins de produção ou não produção. Nesse cenário, as VMs que funcionam como destino de recuperação de desastres idealmente não são implantadas e a imagem e as alterações nas imagens da camada de aplicativos SAP de produção são replicadas para a região de recuperação de desastres. Uma funcionalidade que pode executar essa tarefa é o Azure Site Recovery. O Azure Site Recovery dá suporte a um cenário de replicação do Azure para o Azure como este.
  • Os destinos de recuperação de desastres são VMs que estão realmente em uso por sistemas que não são de produção. Todo o cenário SAP está espalhado por duas regiões diferentes do Azure, com sistemas de produção geralmente em uma região e sistemas de não produção em outra região. Em muitas implantações do cliente, o cliente tem um sistema de não-produção que é equivalente a um sistema de produção. O cliente tem instâncias de aplicativos de produção pré-instaladas na camada de aplicativos que não são sistemas de produção. Em um evento de failover, as instâncias que não são de produção seriam encerradas, os nomes virtuais das VMs de produção seriam movidos para as VMs que não eram de produção (depois de atribuir novos endereços IP no DNS) e as instâncias de produção pré-instaladas estariam começando

Clusters do SAP Central Services

Os clusters do SAP Central Services que usam discos compartilhados (Windows), compartilhamentos SMB (Windows) ou compartilhamentos NFS são um pouco mais difíceis de replicar. No lado do Windows, a Replicação de Armazenamento do Windows é uma solução possível. No Linux, o rsync é uma solução viável. Além disso, a replicação entre regiões dos Arquivos NetApp do Azure é uma solução viável.

Cenário sem suporte

Há uma lista de cenários, que não são suportados para a carga de trabalho SAP em arquiteturas do Azure. Não suportado significa que a SAP e a Microsoft não são capazes de fornecer suporte para essas configurações e precisam adiar para um eventual terceiro envolvido que forneceu software para estabelecer tais arquiteturas. Duas das categorias são:

  • Aparelhos de armazenamento: Existem vários aparelhos de armazenamento no mercado. Alguns dos fornecedores oferecem documentação própria sobre como usar seus dispositivos de software de armazenamento no Azure relacionados ao software SAP. O suporte de configurações ou implantações que envolvam tais dispositivos de software de armazenamento precisa ser fornecido pelo fornecedor do dispositivo de software de armazenamento. Este fato também é manifestado na nota de suporte SAP #2015553
  • Estruturas de alta disponibilidade: apenas o Pacemaker e o Cluster de Failover do Windows Server têm suporte para estruturas de alta disponibilidade para carga de trabalho SAP no Azure. Como mencionado anteriormente, a solução do SIOS Datakeeper é descrita e documentada pela Microsoft. No entanto, os componentes do SIOS Datakeeper precisam ser suportados através do SIOS como o fornecedor que fornece esses componentes. A SAP também listou outras estruturas certificadas de alta disponibilidade em várias notas da SAP. Alguns deles também foram certificados pelo fornecedor terceirizado do Azure. No entanto, o suporte para configurações usando esses produtos precisa ser fornecido pelo fornecedor do produto. Diferentes fornecedores têm diferentes integrações nos processos de suporte SAP. Você deve esclarecer qual processo de suporte funciona melhor para o fornecedor específico antes de decidir usar o produto com configurações SAP implantadas no Azure.
  • Não há suporte para clusters de disco compartilhados em que os arquivos de banco de dados residem nos discos compartilhados, exceto para maxDB. Para todos os outros bancos de dados, a solução suportada é ter locais de armazenamento separados em vez de um compartilhamento SMB ou NFS ou disco compartilhado para configurar cenários de alta disponibilidade

Outros cenários que não são suportados são cenários como:

  • Cenários de implantação que introduzem uma latência de rede maior entre a camada de aplicativo SAP e a camada de DBMS SAP, como no NetWeaver, S/4HANA e.g. Hybris. Isto inclui:
    • Implantando uma das camadas no local enquanto a outra camada é implantada no Azure
    • Implantando a camada de aplicativo SAP de um sistema em uma região do Azure diferente da camada DBMS
    • Implantar uma camada em datacenters que estão colocalizados no Azure e a outra camada no Azure, exceto quando esse padrão de arquitetura é fornecido por um serviço nativo do Azure
    • Implantando dispositivos virtuais de rede entre a camada de aplicativos SAP e a camada DBMS
    • Usando armazenamento hospedado em datacenters colocalizados no datacenter do Azure para a camada de DBMS do SAP ou o diretório de transporte global do SAP
    • Implantando as duas camadas com dois fornecedores de nuvem diferentes. Por exemplo, implantando a camada DBMS no Oracle Cloud Infrastructure e a camada de aplicativo no Azure
  • Configurações de cluster HANA Pacemaker de várias instâncias
  • Configurações de cluster do Windows com discos compartilhados através de SOFS ou SMB em bancos de dados ANF para SAP suportados no Windows. Em vez disso, recomendamos o uso de replicação nativa de alta disponibilidade dos bancos de dados específicos e o uso de pilhas de armazenamento separadas
  • Implantação de bancos de dados SAP suportados em Linux com arquivos de banco de dados localizados em compartilhamentos NFS sobre ANF, exceto SAP HANA, Oracle em Oracle Linux e DB2 em Suse e Red Hat
  • Implantação de Oracle DBMS em qualquer outro SO convidado que não Windows e Oracle Linux. Consulte também a nota de suporte SAP #2039619

Cenário(s) que não testamos e, portanto, não temos experiência com lista como:

  • Azure Site Recovery replicando VMs de camada DBMS. Como resultado, recomendamos o uso da funcionalidade de replicação assíncrona nativa do banco de dados para uma possível configuração de recuperação de desastres

Passos Seguintes

Leia as próximas etapas no planejamento e implementação de Máquinas Virtuais do Azure para SAP NetWeaver