Compartilhar via

Configurações de carga de trabalho do SAP com Zonas de Disponibilidade do Azure

  • Artigo

A implantação das diferentes camadas de arquitetura SAP em Zonas de Disponibilidade do Azure é a arquitetura recomendada para implantações de carga de trabalho SAP no Azure. Uma Zona de Disponibilidade do Azure é definida como "locais físicos exclusivos em uma região. Cada zona é composta de um ou mais datacenters equipados com energia, resfriamento e rede independentes". As Zonas de Disponibilidade do Azure não estão disponíveis em todas as regiões. Para saber as regiões do Azure que fornecem Zonas de Disponibilidade, verifique o mapa de regiões do Azure. O artigo lista quais regiões fornecem Zonas de Disponibilidade. A maioria das regiões do Azure que estão equipadas para hospedar cargas de trabalho SAP maiores estão fornecendo Zonas de Disponibilidade. Novas regiões do Azure estão fornecendo Zonas de Disponibilidade desde o início. Algumas das regiões mais antigas estavam ou estão sendo modernizadas com Zonas de Disponibilidade.

A partir da arquitetura típica do SAP NetWeaver ou do S/4HANA, você precisa proteger três camadas diferentes:

  • A Camada de aplicativo SAP, que pode ser uma a algumas dúzias de VMs (Máquinas Virtuais). Tente minimizar a chance de as VMs serem implantadas no mesmo servidor host. Essas VMs também devem estar em uma proximidade aceitável à camada de banco de dados para manter a latência de rede em uma janela aceitável
  • A camada SAP ASCS/SCS que representa um ponto único de falha na arquitetura do SAP NetWeaver e do S/4HANA. Normalmente, você examina duas VMs que deseja abranger com uma estrutura de failover. Portanto, essas VMs devem ser alocadas em diferentes domínios de falha de infraestrutura
  • Camada do banco de dados do SAP, que também representa um ponto único de falha. Nos casos usuais, ele consiste em duas VMs cobertas por uma estrutura de failover. Portanto, essas VMs devem ser alocadas em diferentes domínios de falha de infraestrutura. As exceções são implantações escaláveis do SAP HANA, em que mais de duas VMs podem ser usadas

As principais diferenças entre implantar as VMs críticas por meio de conjuntos de disponibilidade ou Zonas de Disponibilidade são:

  • A implantação com um conjunto de disponibilidade dispõe as VMs no conjunto em uma única zona ou datacenter (o que for aplicável para a região específica). Como resultado, a implantação com o conjunto de disponibilidade não é protegida contra problemas de energia, resfriamento ou rede que afetem os datacenters da zona como um todo. Com conjuntos de disponibilidade, também não há alinhamento forçado entre uma VM e seus discos. Significa que os discos podem estar em qualquer datacenter da região do Azure, independentemente da estrutura zonal da região. Pelo lado positivo, as VMs são alinhadas com os domínios de atualização e de falha dentro dessa zona ou datacenter. Especificamente para a camada SAP ASCS ou do banco de dados em que protegemos duas VMs por conjunto de disponibilidade, o alinhamento com domínios de falha impede que ambas as VMs estejam terminando no mesmo hardware de host.
  • Ao implantar VMs por meio de Zonas de Disponibilidade do Azure e escolher zonas diferentes (no máximo três possíveis), as VMs serão implantadas nos diferentes locais físicos e, com isso, será aumentada a proteção contra problemas de energia, resfriamento ou rede que afetam os datacenters da zona como um todo. As VMs e seus discos relacionados também são colocados na mesma Zona de Disponibilidade. No entanto, ao implantar mais de uma VM da mesma família de VMs na mesma Zona de Disponibilidade, não há nenhuma proteção para essas VMs que ficam no mesmo host ou no mesmo domínio de falha. Como resultado, a implantação por meio de Zonas de Disponibilidade é ideal para a camada de ASCS e de banco de dados do SAP, onde normalmente examinamos duas VMs em cada uma. Para a camada de aplicativo SAP, que pode ser drasticamente mais do que duas VMs, talvez seja necessário retornar a um modelo de implantação diferente (confira mais adiante).

O objetivo de uma implantação em Zonas de Disponibilidade do Azure deve ser abranger a falha de uma única VM crítica ou capacidade de reduzir o tempo de inatividade para a aplicação de patches de software em um crítico e proteger-se de problemas de infraestrutura maiores que podem afetar a disponibilidade de um ou vários datacenters do Azure.

Como outra funcionalidade de implantação de resiliência, o Azure introduziu Conjuntos de dimensionamento de máquinas virtuais com orquestração flexível para carga de trabalho SAP. O conjunto de dimensionamento de máquinas virtuais fornece agrupamento lógico de máquinas virtuais gerenciadas pela plataforma. A orquestração flexível do conjunto de dimensionamento de máquinas virtuais oferece a opção de criar o conjunto de dimensionamento dentro de uma região ou estendê-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 entre zonas de disponibilidade com platformFaultDomainCount=1 (FD=1) distribuiria as máquinas virtuais em diferentes zonas e o conjunto de dimensionamento também distribuiria VMs em diferentes domínios de falha dentro de cada zona com base no melhor esforço. 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 obter mais informações, confira o guia de implantação do conjunto de dimensionamento flexível para a carga de trabalho do SAP.

Considerações sobre a implantação em Zonas de Disponibilidade

Ao usar as Zonas de Disponibilidade, considere o seguinte:

  • Mais informações sobre Zonas de Disponibilidade do Azure são apresentadas no documento Regiões e zonas de disponibilidade.
  • A latência da viagem de ida e volta da rede observada não é necessariamente uma indicação da distância geográfica real dos datacenters que compõem as diferentes zonas. A latência de ida e volta da rede também é influenciada pelas conectividades de cabo e pelo roteamento dos cabos entre esses diferentes datacenters.
  • Se você usar Zonas de Disponibilidade como solução de recuperação de desastre de pequena distância, tenha em mente que sofremos desastres naturais causando danos generalizados em diferentes regiões do mundo, incluindo danos pesados e generalizados às infraestruturas de energia. As distâncias entre várias zonas podem nem sempre ser grandes o suficiente para compensar desastres naturais tão maiores.
  • A latência de rede entre Zonas de Disponibilidade não é a mesma em todas as regiões do Azure. Mesmo em uma região do Azure, as latências de rede entre as diferentes zonas podem variar. Embora, mesmo na pior hipótese, a replicação síncrona no nível do banco de dados com base na Replicação do Sistema HANA ou no SQL Server Always On funcionará sem afetar a escalabilidade da carga de trabalho.
  • Ao decidir onde usar as Zonas de Disponibilidade, baseie sua decisão na latência de rede entre as zonas. A latência da rede desempenha um papel importante em duas áreas:
    • A latência entre as duas instâncias dos bancos de dados que precisam ter replicação síncrona. Com base em operações muito bem-sucedidas dos maiores sistemas NetWeaver e S/4HANA entre zonas com latências de rede mais altas (menos de 1,5 milissegundos), essa consideração pode ser negligenciada
    • A diferença na latência de rede entre uma VM que executa uma instância de diálogo do SAP na zona com a instância do banco de dados ativo e uma VM semelhante em outra zona. Conforme essa diferença aumenta, a influência sobre o tempo de execução de processos de negócios e de tarefas em lote também aumenta, dependendo de eles serem executados na zona com o banco de dados ou em uma zona diferente (consulte mais adiante neste artigo).
  • A latência de rede com Zonas de Disponibilidade do Azure, mesmo nas maiores zonas, é suficientemente baixa para executar processos de negócios do SAP. Até agora, só vimos alguns casos excepcionais em que os clientes precisavam colocar a camada de aplicativo SAP e a camada de banco de dados em uma única coluna de rede do datacenter.

Ao implantar VMs do Azure em Zonas de Disponibilidade e estabelecer soluções de failover na mesma região do Azure, há algumas restrições:

Combinação ideal para as Zonas de Disponibilidade

A menos que você configure a atribuição de processo de negócios com funcionalidades SAP como Grupos de Logon, Grupos de Servidores RFC, Grupos de Servidores em Lote e processos de negócios semelhantes podem ser executados nas diferentes instâncias de aplicativo em sua camada de aplicativo SAP. O efeito colateral desse fato é que os trabalhos em lotes podem ser executados por qualquer instância do aplicativo SAP, independentemente de serem executados na mesma zona da instância do banco de dados ativo ou não. Se a diferença na latência de rede entre as zonas diferentes for pequena em comparação com a latência de rede em uma zona, a diferença nos tempos de execução de trabalhos em lotes pode não ser significativa. No entanto, quanto maior a diferença de latência de rede em uma zona em comparação com o tráfego de rede entre zonas, maior será o impacto no tempo de execução dos trabalhos em lotes se eles forem executados em uma zona sem a instância do banco de dados ativa. Dependerá de você como cliente decidir quais diferenças são aceitáveis no tempo de execução. E, com isso, qual é a latência de rede tolerável para o tráfego de zonas cruzadas para sua carga de trabalho. Do ponto de vista técnico, as latências de rede entre Zonas de Disponibilidade do Azure em uma região do Azure funcionam para a arquitetura do NetWeaver, S/4HANA ou outros aplicativos SAP. Também cabe a você, como cliente, potencialmente atenuar essas diferenças usando os conceitos SAP de Grupos de Logon, Grupos de Servidores RFC, Grupos de Servidores em Lote e similares quando você decide por um dos conceitos de implantação que estamos introduzindo neste artigo.

Para implantar um sistema SAP NetWeaver ou S/4HANA entre zonas, há dois padrões de arquitetura que você pode usar:

  • Ativa/ativa: o par de VMs que executa o ASCS/SCS e o par de VMs que executa a camada do banco de dados são distribuídos entre duas zonas. As VMs que executam a camada de aplicativo SAP são implantadas em números pares nas mesmas duas zonas. Se uma VM do banco de dados ou ASCS/SCS estiver fazendo failover, algumas das transações abertas e ativas poderão ser revertidas. No entanto, os usuários permanecem conectados. Na verdade, não importa em qual das zonas a VM do banco de dados ativa e as instâncias do aplicativo são executadas. Essa arquitetura é a arquitetura preferida para implantar entre zonas. Nos casos em que as latências de rede entre zonas estão causando diferenças maiores ao executar processos de negócios, você pode usar funcionalidades como Grupos de Logon SAP, Grupos de Servidores RFC, Grupos de Servidores em Lote e similares para rotear a execução dos processos de negócios para instâncias de diálogo específicas que estão na mesma zona com a instância do banco de dados ativo
  • Ativa/passiva: o par de VMs que executa o ASCS/SCS e o par de VMs que executa a camada do banco de dados são distribuídos entre duas zonas. As VMs que executam a camada de aplicativo SAP são implantadas em uma das Zonas de Disponibilidade. Você executa a camada de aplicativo na mesma zona que a ASCS/SCS ativa e a instância do banco de dados. Você pode usar essa arquitetura de implantação se considerar a latência de rede entre as diferentes zonas como muito alta. E com isso causando diferenças intoleráveis no runtime de seus processos de negócios. Ou se você quiser usar implantações da Zona de Disponibilidade como implantações de recuperação de desastre de curta distância. as zonas. Se uma VM do ASCS/SCS ou do banco de dados fizer failover para a zona secundária, você poderá encontrar uma latência de rede maior e, com ela, uma redução de taxa de transferência. Você também precisará fazer failback da VM com o failover anterior o quanto antes para voltar aos níveis de taxa de transferência anteriores. Se ocorrer uma interrupção de zona, será preciso fazer failover da camada de aplicativo para a zona secundária. Uma atividade que os usuários enfrentam como desligamento completo do sistema.

Portanto, antes de decidir como usar as Zonas de Disponibilidade, é preciso determinar:

  • A latência de rede entre as três zonas de uma região do Azure. Saber a latência de rede entre as zonas de uma região permitirá que você escolha as zonas com a menor latência de rede no tráfego de rede entre zonas.
  • A diferença entre a latência entre VMs em uma das zonas, de sua escolha, e a latência de rede em duas zonas de sua escolha.
  • Uma determinação indicando se os tipos de VM que você precisa implantar estão disponíveis nas duas zonas selecionadas. Com alguns SKUs de VMs, você pode encontrar situações em que alguns SKUs estão disponíveis em apenas duas das três zonas.

Latência de rede entre zonas e dentro delas

Para determinar a latência entre as diferentes zonas, é preciso:

  • Implantar a SKU da VM que você deseja usar para sua instância do banco de dados nas três zonas. Certifique-se de que a Rede Acelerada do Azure esteja habilitada ao executar essa medição. A rede acelerada é a configuração padrão há algum tempo. No entanto, verifique se ela está habilitada e funcionando
  • Ao encontrar as duas zonas com menos latência de rede, implante outras três VMs da SKU da VM que você deseja usar como VM da camada de aplicativo nas três Zonas de Disponibilidade. Meça a latência de rede em relação às duas VMs do banco de dados nas duas zonas que você selecionou.
  • Use niping como uma ferramenta de medição. Essa ferramenta de SAP é descrita nas notas de suporte do SAP #500235 e #1100926. Trate a classificação de latência de rede na Nota SAP #1100926 como orientação aproximada. Latências de rede maiores que 0,7 milissegundos não significam que o sistema não funcionará tecnicamente ou que os processos empresariais não estão satisfazendo seus SLAs individuais. A observação não se destina a declarar o que tem suporte ou não com suporte do SAP e/ou da Microsoft. Concentre-se nos comandos documentados para medições de latência. Como o ping não funciona nos caminhos de código da Rede Acelerada do Azure, não é recomendável usá-lo.

Você não precisa executar esses testes manualmente. Você pode encontrar um Teste de Latência da Zona de Disponibilidade de procedimento do PowerShell que automatiza os testes de latência descritos.

Com base nas medições e na disponibilidade de suas SKUs de VM em diferentes Zonas de Disponibilidade, você precisa tomar as algumas decisões:

  • Definir as zonas ideais para a camada do banco de dados.
  • Determinar se você deseja distribuir sua camada ativa de aplicativo do SAP em uma, duas ou em todas as três zonas, com base nas diferenças de latência de rede na zona versus entre as zonas.
  • Determinar se você deseja implantar uma configuração ativa/passiva ou uma configuração ativa/ativa do ponto de vista do aplicativo. (Essas configurações são explicadas mais adiante neste artigo.)

Importante

As medições e decisões que você toma são válidas para a assinatura do Azure usada ao fazer as medições. Se você usar outra assinatura do Azure, o mapeamento de zonas enumeradas poderá ser diferente. Como resultado, você precisa repetir as medidas ou descobrir o mapeamento da nova assinatura em relação à assinatura antiga com a ferramenta script Avzone-Mapping.

Importante

Espera-se que as medições descritas anteriormente forneçam resultados diferentes em todas as regiões do Azure que dão suporte a Zonas de Disponibilidade. Mesmo quando seus requisitos de latência de rede forem os mesmos, talvez seja necessário adotar estratégias de implantação distintas em diferentes regiões do Azure, já que a latência de rede entre as zonas pode diferir. Em algumas regiões do Azure, a latência de rede entre as três zonas diferentes pode ser muito diferente. Em outras regiões, a latência de rede entre as três zonas diferentes pode ser mais uniforme. A afirmação de que sempre há uma latência de rede de um ou dois milissegundos não está correta. A latência de rede entre Zonas de Disponibilidade nas regiões do Azure não pode ser generalizada.

Implantação ativa/ativa

Essa arquitetura de implantação é chamada ativa/ativa porque você implanta os servidores de aplicativo SAP ativos em duas ou três zonas. A instância do SAP Central Services que usa a replicação de enfileiramento é implantada entre duas zonas. O mesmo vale para a camada do banco de dados, que é implantada nas mesmas zonas que o SAP Central Service. Ao considerar essa configuração, você precisa encontrar as duas Zonas de Disponibilidade em sua região que oferecem uma latência de rede entre zonas aceitável para sua carga de trabalho. Também é preciso ter certeza de que o delta entre a latência de rede nas zonas selecionadas e a latência de rede entre zonas é aceitável para sua carga de trabalho.

Um esquema simplificado de implantação ativa/ativa entre duas zonas pode ser semelhante a:

Implantação de zona ativa/ativa

As seguintes considerações se aplicam a essa configuração:

Importante

Neste cenário ativo/ativo, os encargos para o tráfego entre zonas se aplicam. Verifique o documento Detalhamento de Preços da Largura de Banda. A transferência de dados entre a camada de aplicativo SAP e a camada do banco de dados do SAP é bastante intensiva. Portanto, o cenário ativo/ativo pode aumentar os custos.

Implantação ativa/passiva

Se você não conseguir encontrar uma configuração que reduza o delta potencial em runtime de processos de negócios SAP ou se quiser implantar uma configuração de recuperação de desastre de curta distância, você poderá implantar uma arquitetura que tenha um caractere ativo/passivo do ponto de vista da camada de aplicativo SAP. Defina uma zona ativa, que é a zona em que você implantará a camada de aplicativo completa e onde tentará executar a instância do banco de dados ativo e a instância do SAP Central Services. Com essa configuração, você garante que não haja variações extremas de tempo de execução, dependendo se uma tarefa é executada na zona com a instância do banco de dados ativo ou não, em transações comerciais e tarefas em lote.

O layout básico da arquitetura é semelhante a este:

Implantação de zona ativa/passiva

As seguintes considerações se aplicam a essa configuração:

  • Não é possível implantar conjuntos de disponibilidade em Zonas de Disponibilidade do Azure. Para mitigação, você pode usar grupos de posicionamento por proximidade do Azure, conforme o artigo Grupos de posicionamento por proximidade do Azure para obter a latência de rede ideal com aplicativos SAP.
  • Ao usar essa arquitetura, monitore o status de perto e tente manter as instâncias do banco de dados e do SAP Central Services ativas na mesma zona da sua camada de aplicativo implantada. Se ocorrer um failover do SAP Central Service ou da instância do banco de dados, verifique se você pode fazer failover manual de volta para a zona da camada de aplicativo SAP implantada com a máxima rapidez possível.
  • Para os balanceadores de carga dos clusters de failover do SAP Central Services e da camada do banco de dados, você precisa usar a SKU padrão do Azure Load Balancer. O Load Balancer básico não está funcionando entre as zonas.
  • Você precisa implantar a versão zonal do Gateway do ExpressRoute, Gateway de VPNe Endereços IP Públicos Padrão para obter a proteção zonal desejada.
  • A rede virtual do Azure que você implantou para hospedar o sistema SAP com suas sub-redes é ampliada entre as zonas. Não é necessário ter redes virtuais separadas para cada zona.
  • Em todas as máquinas virtuais implantadas, você precisa usar Azure Managed Disks. Não há suporte para discos não gerenciados em implantações de zona.
  • O SSD Premium do Azure v2, o Armazenamento SSD Ultra ou o Azure NetApp Files não dão suporte a nenhuma replicação de armazenamento síncrono entre zonas. Para implantações do banco de dados, contamos com métodos de banco de dados para replicar dados entre zonas.
  • O SSD Premium v1, que dá suporte à replicação zonal síncrona entre Zonas de Disponibilidade, não foi testado com a carga de trabalho do banco de dados SAP. Portanto, a replicação zonal síncrona configurável do SSD Premium do Azure v1 precisa ser considerada como sem suporte para cargas de trabalho do banco de dados SAP.
  • Para compartilhamentos SMB e NFS com base nos Arquivos Premium do Azure, é oferecida a redundância zonal com replicação síncrona. Confira neste documento a disponibilidade de ZRS para Arquivos Premium do Azure na região em que você deseja fazer a implantação. O uso de compartilhamentos NFS e SMB replicados em zonas é totalmente compatível com implantações de camada de aplicativo SAP e clusters de failover de alta disponibilidade para serviços centrais do NetWeaver ou do S/4HANA. Os documentos que abrangem esses casos são:
  • A terceira zona é usada para hospedar o dispositivo SBD se você criar um cluster SUSE Linux Pacemaker e usar dispositivos SBD em vez do Agente de Isolamento do Azure. Ou para instâncias de aplicativo adicionais.
  • Você deve implantar VMs inativas na zona passiva (de um ponto de vista do banco de dados) para poder iniciar os recursos do aplicativo para o caso de uma falha de zona. Outra possibilidade é usar o Azure Site Recovery, que pode replicar VMs ativas para VMs inativas entre zonas.
  • Você deve investir em automação que permita iniciar automaticamente a camada de aplicativo SAP na segunda zona caso ocorra uma interrupção de zona.

Configuração combinada de alta disponibilidade e recuperação de desastre

A Microsoft não compartilha qualquer informação sobre a distância geográfica entre as instalações que hospedam diferentes Zonas de Disponibilidade do Azure na região do Azure. Ainda assim, alguns clientes estão utilizando as zonas para realizar uma configuração de alta disponibilidade (HA) e de recuperação de desastre combinada (DR de curta distância) que promete um objetivo de ponto de recuperação (RPO) zero. Um RPO zero significa que você não perderá nenhuma transação de banco de dados confirmada, mesmo em casos de recuperação de desastre.

Observação

Se você usar Zonas de Disponibilidade como solução de recuperação de desastre de pequena distância, tenha em mente que sofremos desastres naturais causando danos generalizados em diferentes regiões do mundo, incluindo danos pesados e generalizados às infraestruturas de energia. As distâncias entre várias zonas podem nem sempre ser grandes o suficiente para compensar desastres naturais tão maiores.

Consulte um exemplo de como essa configuração pode ser:

Combinação de recuperação de desastres e alta disponibilidade em zonas

As seguintes considerações se aplicam a essa configuração:

  • Você está assumindo que há uma distância significativa entre as instalações que hospedam uma Zona de Disponibilidade. Ou você é forçado a ficar em uma determinada região do Azure. Não é possível implantar conjuntos de disponibilidade em Zonas de Disponibilidade do Azure. Para compensar, você pode usar grupos de posicionamento por proximidade do Azure, conforme documentado no artigo Grupos de Posicionamento de Proximidade do Azure para latência de rede ideal com aplicativos SAP.
  • Ao usar essa arquitetura, monitore o status de perto e tente manter as instâncias do banco de dados e do SAP Central Services ativas na mesma zona da sua camada de aplicativo implantada. Se ocorrer um failover do SAP Central Service ou da instância do banco de dados, verifique se você pode fazer failover manual de volta para a zona da camada de aplicativo SAP implantada com a máxima rapidez possível.
  • Você deve ter instâncias de aplicativo de produção pré-instaladas nas VMs que executam as instâncias do aplicativo de QA ativas.
  • No caso de uma falha de zona, desligue as instâncias do aplicativo QA e inicie as instâncias de produção. Você precisa usar nomes virtuais para as instâncias do aplicativo para que isso funcione.
  • Para os balanceadores de carga dos clusters de failover do SAP Central Services e da camada do banco de dados, você precisa usar a SKU padrão do Azure Load Balancer. O Load Balancer básico não está funcionando entre as zonas.
  • Você precisa implantar a versão zonal do Gateway do ExpressRoute, Gateway de VPNe Endereços IP Públicos Padrão para obter a proteção zonal desejada.
  • A rede virtual do Azure que você implantou para hospedar o sistema SAP com suas sub-redes é ampliada entre as zonas. Não é necessário ter redes virtuais separadas para cada zona.
  • Em todas as máquinas virtuais implantadas, você precisa usar Azure Managed Disks. Não há suporte para discos não gerenciados em implantações de zona.
  • O SSD Premium do Azure v2, o Armazenamento SSD Ultra ou o Azure NetApp Files não dão suporte a nenhuma replicação de armazenamento síncrono entre zonas. Para implantações do banco de dados, contamos com métodos de banco de dados para replicar dados entre zonas.
  • O SSD Premium v1, que dá suporte à replicação zonal síncrona entre Zonas de Disponibilidade, não foi testado com a carga de trabalho do banco de dados SAP. Portanto, a replicação zonal síncrona configurável do SSD Premium do Azure v1 precisa ser considerada como sem suporte para cargas de trabalho do banco de dados SAP.
  • Para compartilhamentos SMB e NFS com base nos Arquivos Premium do Azure, é oferecida a redundância zonal com replicação síncrona. Confira neste documento a disponibilidade de ZRS para Arquivos Premium do Azure na região em que você deseja fazer a implantação. O uso de compartilhamentos NFS e SMB replicados em zonas é totalmente compatível com implantações de camada de aplicativo SAP e clusters de failover de alta disponibilidade para serviços centrais do NetWeaver ou do S/4HANA. Os documentos que abrangem esses casos são:
  • A terceira zona é usada para hospedar o dispositivo SBD se você criar um cluster SUSE Linux Pacemaker e usar dispositivos SBD em vez do Agente de Isolamento do Azure.

Próximas etapas

Apresentamos abaixo algumas próximas etapas para implantar em Zonas de Disponibilidade do Azure: