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

  • Artigo

Além da implantação das diferentes camadas de arquitetura do SAP nos conjuntos de disponibilidade do Azure, as Zonas de Disponibilidade do Azure também podem ser usadas para implantações de carga de trabalho SAP. 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. Esse mapa mostra quais regiões já fornecem ou fornecerão Zonas de Disponibilidade.

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

  • Camada de aplicativo SAP, que pode ser de uma a algumas dezenas de VMs. 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 DBMS para manter a latência de rede em uma janela aceitável
  • 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 DBMS 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. 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 DBMS, onde protegemos duas VMs por conjunto de disponibilidade, o alinhamento com domínios de falha impede que ambas as VMs acabem no mesmo hardware de host.
  • Ao implantar VMs por meio de Zonas de Disponibilidade do Azure e escolher zonas diferentes (máximo de três possíveis), implantará as VMs nos diferentes locais físicos e, com isso, adicionará proteção contra problemas de energia, resfriamento ou rede que afetam o(s) dataceter(s) da zona como um todo. 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 DBMS 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áquina virtual com orquestração flexível para carga de trabalho SAP. O conjunto de dimensionamento de máquina virtual fornece agrupamento lógico de máquinas virtuais gerenciadas por plataforma. A orquestração flexível do conjunto de dimensionamento de máquina virtual fornece a opção de criar o conjunto de escala dentro de uma região ou estendê-lo entre zonas de disponibilidade. Ao criar, o conjunto de escala flexível dentro de uma região com platformFaultDomainCount>1 (FD>1), as VMs implantadas no conjunto de escala seriam distribuídas entre o número especificado de domínios de falha na mesma região. Por outro lado, a criação do conjunto de escala flexível entre zonas de disponibilidade com platformFaultDomainCount=1 (FD=1) distribuiria as máquinas virtuais em diferentes zonas e o conjunto de escala também distribuiria VMs em diferentes domínios de falha dentro de cada zona com base no melhor esforço. Para carga de trabalho SAP, somente o conjunto de dimensionamento flexível com FD=1 é suportado. A vantagem de usar conjuntos de escala flexíveis com FD=1 para implantação zonal cruzada, em vez da implantação tradicional da zona de disponibilidade, é que as VMs implantadas com o conjunto de escala seriam distribuídas entre diferentes domínios de falha dentro da zona da maneira mais esforçada. Para obter mais informações, consulte o guia de implantação do conjunto de dimensionamento flexível para carga de trabalho SAP.

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

Ao usar as Zonas de Disponibilidade, considere o seguinte:

  • A latência máxima de ida e volta de rede entre a Zonas de Disponibilidade do Azure é declarada nas Regiões e zonas de disponibilidade do documento.
  • 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.
  • As Zonas de Disponibilidade não são uma solução ideal de DR. Desastres naturais podem causar danos extensos em algumas regiões do mundo, incluindo danos graves a infraestruturas de energia. As distâncias entre várias zonas podem não ser suficientemente grandes para constituir uma solução de DR apropriada.
  • A latência de rede entre Zonas de Disponibilidade não é a mesma em todas as regiões do Azure. Em alguns casos, você pode implantar e executar a camada de aplicativo do SAP em diferentes zonas, pois a latência da rede de uma zona para a VM do DBMS ativo é aceitável. Porém, em algumas regiões do Azure, a latência entre a VM do DBMS ativo e uma instância do aplicativo SAP, quando implantada em diferentes zonas, pode não ser aceitável para os processos empresariais do SAP. Nesses casos, as arquiteturas de implantação precisam ser diferentes, com uma arquitetura ativa/ativa para o aplicativo ou uma arquitetura ativa/passiva quando a latência de rede entre zonas é muito alta.
  • Ao decidir onde usar as Zonas de Disponibilidade, baseie sua decisão na latência de rede entre as zonas. A latência de rede desempenha um papel importante em duas áreas:
    • A latência entre as duas instâncias de DBMS que precisam ter replicação síncrona. Quanto maior a latência de rede, maior a probabilidade de afetar a escalabilidade da sua carga de trabalho.
    • 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 DBMS 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 DBMS ou em uma zona diferente.

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:

  • Use o Azure Managed Disks ao implantar em Zonas de Disponibilidade do Azure.
  • O mapeamento de enumerações de zona para as zonas físicas é fixado por assinatura do Azure. Se você estiver usando assinaturas diferentes para implantar seus sistemas de SAP, precisará definir as zonas ideais para cada assinatura. Se você quiser comparar o mapeamento lógico de diferentes assinaturas, considere o script Avzone-Mapping
  • Não é possível implantar conjuntos de disponibilidade do Azure em uma Zona de Disponibilidade do Azure, a menos que use o Grupo de Posicionamento de Proximidade do Azure. A maneira como você pode implantar a camada do DBMS do SAP e os serviços centrais entre as zonas e, ao mesmo tempo, implantar a camada de aplicativo SAP usando conjuntos de disponibilidade e ainda atingir proximidade às VMs está documentada no artigo Grupos de Posicionamento de Proximidade do Azure para latência de rede ideal com aplicativos SAP. Se não estiver usando grupos de posicionamento por proximidade do Azure, você precisará escolher uma dessas opções como estrutura de implantação para máquinas virtuais.
  • Não é possível usar um Azure Basic Load Balancer para criar soluções de cluster de failover baseadas no Cluster de Failover do Windows Server ou no Linux Pacemaker. Em vez disso, use a SKU do Azure Standard Load Balancer.

Combinação ideal para as Zonas de Disponibilidade

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 DBMS são distribuídos entre duas zonas. O número de VMs que executa a camada de aplicativo SAP é implantado em números pares nas mesmas duas zonas. Se uma VM do DBMS 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 DBMS ativa e as instâncias do aplicativo são executadas. Essa arquitetura é a arquitetura preferida para implantar entre zonas.
  • Ativa/passiva: o par de VMs que executa o ASCS/SCS e o par de VMS que executa a camada do DBMS são distribuídos entre duas zonas. O número de VMs que executam a camada de aplicativo SAP é implantado em uma das Zonas de Disponibilidade. Você executa a camada de aplicativo na mesma zona que a instância ativa do ASCS/SCS e do DBMS. Você usará essa arquitetura de implantação se a latência de rede entre as diferentes zonas for muito alta para executar a camada de aplicativo distribuída entre as zonas. Em vez disso, a camada de aplicativo SAP precisa ser executada na mesma zona que a instância ativa do ASCS/SCS e/ou DBMS. Se uma VM do ASCS/SCS ou DBMS 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. Em algumas das regiões do Azure, essa arquitetura é a única arquitetura viável quando você deseja usar Zonas de Disponibilidade. Se não puder aceitar o impacto potencial de um ASCS/SCS ou VMS do DBMS fazendo failover para a zona secundária, talvez seja melhor permanecer com implantações de conjunto de disponibilidade

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 DBMS 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 DBMS nas duas zonas do DBMS 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. 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 DBMS.
  • 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.)

Ao tomar essas decisões, considere também as recomendações de latência de rede do SAP, conforme documentado na nota do SAP #1100926.

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 de DBMS, 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 e para sua replicação síncrona de DBMS. 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 não é muito grande.

A natureza da arquitetura SAP é que, a menos que você a configure de forma diferente, os usuários e trabalhos em lotes podem ser executados em diferentes instâncias do aplicativo. O efeito colateral desse fato com a implantação ativa/ativa é que os trabalhos em lotes podem ser executados por qualquer instância do aplicativo SAP, independentemente de serem executados na mesma zona do DBMS 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 DBMS 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.

As regiões do Azure em que essa implantação ativa/ativa é possível sem grandes diferenças significativas no tempo de execução e na taxa de transferência na camada de aplicativo implantada em diferentes Zonas de Disponibilidade são:

  • Leste da Austrália (duas das três zonas)
  • Sul do Brasil (as três zonas)
  • Índia Central (as três zonas)
  • EUA Central (todas as três zonas)
  • Leste da Ásia (as três zonas)
  • Leste dos EUA (duas das três zonas)
  • Leste dos EUA 2 (todas as três zonas)
  • Centro-Oeste da Alemanha (as três zonas)
  • Israel Central (todas as três zonas)
  • Itália Norte (duas das três zonas)
  • Coreia Central (as três zonas)
  • Polónia Central (as três zonas)
  • Catar Central (as três zonas)
  • Norte da Europa (todas as três zonas)
  • Leste da Noruega (duas das três zonas)
  • África do Sul Norte (dois dos três)
  • Centro-Sul dos EUA (as três zonas)
  • Sudeste da Ásia (as três zonas)
  • Suécia Central (as três zonas)
  • Norte da Suíça (as três zonas)
  • Norte dos EAU (as três zonas)
  • Sul do Reino Unido (duas das três zonas)
  • Oeste da Europa (duas das três zonas)
  • Oeste dos EUA 2 (todas as três zonas)
  • Oeste dos EUA 3 (as três zonas)

A lista de regiões fornecida não ajuda você como cliente a testar a carga de trabalho e decidir se uma arquitetura de implantação ativa/ativa é possível.

Regiões do Azure em que a arquitetura de implantação ativa/ativa do SAP entre zonas talvez não seja possível:

  • Canadá Central
  • França Central
  • Leste do Japão

Porém, talvez funcione para sua carga de trabalho individual. Portanto, você deve fazer testes antes de escolher uma arquitetura. O Azure está trabalhando constantemente para aprimorar a qualidade e a latência das redes. As medidas realizadas anos atrás podem não refletir mais as condições atuais.

Dependendo do que você está disposto a tolerar nas diferenças de tempo de execução, outras regiões não listadas também podem estar qualificadas.

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

Active/Active zone deployment

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 de DBMS do SAP é bastante intensiva. Portanto, o cenário ativo/ativo pode aumentar os custos.

Implantação ativa/passiva

Caso não consiga encontrar um delta aceitável entre a latência de rede dentro de uma zona e a latência do tráfego de rede entre zonas, implante uma arquitetura que tenha um caráter 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 o DBMS 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 DBMS ativo ou não, em transações comerciais e tarefas em lote.

As regiões do Azure onde esse tipo de arquitetura de implantação em diferentes zonas pode ser preferível são:

  • Canadá Central
  • França Central
  • Leste do Japão
  • Leste da Noruega
  • Norte da África do Sul

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

Active/Passive zone deployment

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

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 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

Recomendamos que você use uma configuração como essa apenas em determinadas circunstâncias. Por exemplo, você pode usá-la quando os dados não podem deixar a região do Azure por motivos de segurança ou conformidade.

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

Combined high-availability DR in zones

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

  • Você está pressupondo que há uma distância significativa entre as instalações que hospedam uma zona de disponibilidade ou é forçado a permanecer 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 de DBMS e 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 DBMS, 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 de aplicativo de controle de qualidade 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 DBMS, você precisa usar a SKU padrão do Azure Load Balancer. O Load Balancer básico não funciona entre as zonas.
  • 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 Armazenamento Premium do Azure, o Armazenamento SSD Ultra ou ANF não dão suporte a qualquer tipo de replicação de armazenamento entre zonas. Para implantações do DBMS, contamos com métodos de banco de dados para replicar dados entre zonas
  • 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: