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

Além da implantação das diferentes camadas de arquitetura 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 dentro de uma região. Cada zona é composta por um ou mais datacenters equipados com energia, refrigeração e rede independentes". As Zonas de Disponibilidade do Azure não estão disponíveis em todas as regiões. Para regiões do Azure que fornecem Zonas de Disponibilidade, verifique o mapa de regiões do Azure. Este mapa irá mostrar-lhe quais as regiões que fornecem ou são anunciadas para fornecer Zonas de Disponibilidade.

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

  • Camada de aplicação SAP, que pode ser de uma a algumas dezenas de VMs. Você deseja minimizar a chance de VMs serem implantadas no mesmo servidor host. Você também deseja que essas VMs em uma proximidade aceitável com a camada DBMS mantenham a latência da rede em uma janela aceitável
  • Camada SAP ASCS/SCS que representa um único ponto de falha na arquitetura SAP NetWeaver e S/4HANA. Você geralmente examina duas VMs que deseja cobrir com uma estrutura de failover. Portanto, essas VMs devem ser alocadas em diferentes domínios de falha de infraestrutura
  • Camada SAP DBMS, que também representa um único ponto 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 em expansão do SAP HANA, nas quais mais de duas VMs podem ser usadas

As principais diferenças entre a implantação de suas VMs críticas por meio de conjuntos de disponibilidade ou zonas de disponibilidade são:

  • Implantar com um conjunto de disponibilidade é alinhar as VMs dentro do conjunto em uma única zona ou datacenter (o que se aplica à região específica). Como resultado, a implantação por meio do conjunto de disponibilidade não é protegida por problemas de energia, resfriamento ou rede que afetam o(s) dataceter(s) da zona como um todo. No lado positivo, as VMs são alinhadas com domínios de atualização e 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 das Zonas de Disponibilidade do Azure e escolher zonas diferentes (máximo de três possíveis), vai implantar as VMs nos diferentes locais físicos e, com isso, adiciona proteção contra problemas de energia, resfriamento ou rede que afetam o(s) dataceter(s) da zona como um todo. No entanto, à medida que você implanta mais de uma VM da mesma família de VMs na mesma zona de disponibilidade, não há proteção contra essas VMs que acabam 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 SAP ASCS e DBMS, onde geralmente examinamos duas VMs cada. Para a camada de aplicativos SAP, que pode ser drasticamente mais de duas VMs, talvez seja necessário recorrer a um modelo de implantação diferente (consulte mais adiante)

Sua motivação para uma implantação nas Zonas de Disponibilidade do Azure deve ser que você, além de cobrir a falha de uma única VM crítica ou a capacidade de reduzir o tempo de inatividade para aplicação de patches de software em uma VM crítica, queira se proteger de problemas de infraestrutura maiores que possam 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áquinas virtuais fornece agrupamento lógico de máquinas virtuais gerenciadas por plataforma. A orquestração flexível do conjunto de dimensionamento de máquina virtual oferece a opção de criar o conjunto de escala dentro de uma região ou estendê-lo entre zonas de disponibilidade. Ao criar, a escala flexível definida 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, apenas o conjunto de escala flexível com FD=1 é suportado. A vantagem de usar conjuntos de escala 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 escala seriam distribuídas entre diferentes domínios de falha dentro da zona de uma maneira de melhor esforço. Para obter mais informações, consulte o guia de implantação do conjunto de escala flexível para carga de trabalho SAP.

Considerações para implantação em zonas de disponibilidade

Considere o seguinte ao usar zonas de disponibilidade:

  • A latência máxima de ida e volta da rede entre as Zonas de Disponibilidade do Azure é declarada no documento Regiões e zonas de disponibilidade.
  • A latência de ida e volta da rede não é necessariamente indicativa da distância geográfica real dos datacenters que formam as diferentes zonas. A latência de ida e volta da rede também é influenciada pelas conexões de cabo e pelo roteamento dos cabos entre esses diferentes datacenters.
  • As zonas de disponibilidade não são uma solução de DR ideal. As catástrofes naturais podem causar danos generalizados em regiões do mundo, incluindo danos pesados nas infraestruturas elétricas. As distâncias entre várias zonas podem não ser suficientemente grandes para constituir uma solução adequada de DR.
  • A latência de rede nas 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 SAP em diferentes zonas porque a latência de rede de uma zona para a VM DBMS ativa é aceitável. Mas em algumas regiões do Azure, a latência entre a VM DBMS ativa e a instância do aplicativo SAP, quando implantada em zonas diferentes, pode não ser aceitável para processos de negócios SAP. Nesses casos, a arquitetura de implantação precisa ser diferente, com uma arquitetura ativa/ativa para o aplicativo ou uma arquitetura ativa/passiva em que a latência da rede entre zonas é muito alta.
  • Ao decidir onde usar as zonas de disponibilidade, baseie sua decisão na latência da rede entre as zonas. A latência da rede desempenha um papel importante em duas áreas:
    • Latência entre as duas instâncias de DBMS que precisam ter replicação síncrona. Quanto maior a latência da rede, maior a probabilidade de afetar a escalabilidade da sua carga de trabalho.
    • A diferença na latência de rede entre uma VM executando uma instância de diálogo SAP na zona com a instância DBMS ativa e uma VM semelhante em outra zona. À medida que essa diferença aumenta, a influência no tempo de execução de processos de negócios e trabalhos em lote também aumenta, dependendo se eles são executados na zona com o DBMS ou em uma zona diferente.

Quando você implanta VMs do Azure em zonas de disponibilidade e estabelece soluções de failover na mesma região do Azure, algumas restrições se aplicam:

  • Você deve usar os Discos Gerenciados do Azure ao implantar nas Zonas de Disponibilidade do Azure.
  • O mapeamento de enumerações de zona para as zonas físicas é fixo com base na assinatura do Azure. Se você estiver usando assinaturas diferentes para implantar seus sistemas SAP, precisará definir as zonas ideais para cada assinatura. Se você quiser comparar o mapeamento lógico de suas 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 SAP DBMS e os serviços centrais entre zonas e, ao mesmo tempo, implantar a camada de aplicativos SAP usando conjuntos de disponibilidade e ainda obter proximidade das VMs está documentada no artigo Azure Proximity Placement Groups for optimal network latency with SAP applications. Se você não estiver usando grupos de posicionamento de proximidade do Azure, precisará escolher um ou outro como uma estrutura de implantação para máquinas virtuais.
  • Não é possível usar um Balanceador de Carga Básico do Azure para criar soluções de cluster de failover com base no Clustering de Failover do Windows Server ou no Pacemaker do Linux. Em vez disso, você precisa usar a SKU do Balanceador de Carga Padrão do Azure.

A combinação ideal de Zonas de Disponibilidade

Se você quiser implantar um sistema SAP NetWeaver ou S/4HANA entre zonas, há dois padrões de arquitetura que podem ser implantados:

  • Ativo/ativo: O par de VMs que executam ASCS/SCS e o par de VMS que executam a camada DBMS são distribuídos em duas zonas. O número de VMs que executam a camada de aplicativos SAP é implantado em números pares nas mesmas duas zonas. Se uma VM DBMS ou ASCS/SCS estiver fazendo failover, algumas das transações abertas e ativas poderão ser revertidas. Mas os usuários continuam conectados. Na verdade, não importa em qual das zonas a VM DBMS ativa e as instâncias do aplicativo são executadas. Essa arquitetura é a arquitetura preferida para implantar em zonas.
  • Ativo/passivo: O par de VMs que executam ASCS/SCS e o par de VMS que executam a camada DBMS são distribuídos em duas zonas. O número de VMs que executam a camada de aplicativos SAP é implantado em uma das zonas de disponibilidade. Execute a camada de aplicativo na mesma zona que a instância ASCS/SCS e DBMS ativa. Você usa essa arquitetura de implantação se a latência de rede nas diferentes zonas for muito alta para executar a camada de aplicativo distribuída pelas zonas. Em vez disso, a camada de aplicativo SAP precisa ser executada na mesma zona que a instância ASCS/SCS e/ou DBMS ativa. Se uma VM ASCS/SCS ou DBMS fizer failover para a zona secundária, você poderá encontrar latência de rede mais alta e, com isso, uma redução da taxa de transferência. E é necessário fazer failback da VM com failover anterior o mais rápido possível para voltar aos níveis de taxa de transferência anteriores. Se ocorrer uma interrupção zonal, a camada de aplicativo precisará ser transferida para a zona secundária. Uma atividade que os usuários experimentam 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 você não puder aceitar o impacto potencial de um failover de ASCS/SCS ou DBMS VMS 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, você precisa determinar:

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

Latência de rede entre e dentro de zonas

Para determinar a latência entre as diferentes zonas, você precisa:

  • Implante a SKU de VM que você deseja usar para sua instância DBMS em todas as três zonas. Certifique-se de que a Rede Acelerada do Azure está ativada quando efetuar esta medição. Rede acelerada é a configuração padrão desde alguns anos. No entanto, verifique se está ativado e a funcionar
  • Quando você encontrar as duas zonas com a menor latência de rede, implante outras três VMs da SKU da VM que você deseja usar como a VM da camada de aplicativo nas três Zonas de Disponibilidade. Meça a latência da rede em relação às duas VMs DBMS nas duas zonas DBMS selecionadas.
  • Use niping como uma ferramenta de medição. Esta ferramenta, da SAP, está descrita nas notas de suporte SAP #500235 e #1100926. Concentre-se nos comandos documentados para medições de latência. Como o ping não funciona através dos caminhos de código da Rede Acelerada do Azure, não recomendamos que você o use.

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

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

  • Defina as zonas ideais para a camada DBMS.
  • Determine se você deseja distribuir sua camada de aplicativo SAP ativa em uma, duas ou todas as três zonas, com base nas diferenças de latência de rede na zona versus entre zonas.
  • Determine 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, também leve em consideração as recomendações de latência de rede da SAP, conforme documentado na nota #1100926 da SAP.

Importante

As medidas e decisões que você toma são válidas para a assinatura do Azure que você usou quando fez as medições. Se você usar outra assinatura do Azure, o mapeamento de zonas enumeradas pode ser diferente para outra assinatura do Azure. Como resultado, você precisa repetir as medidas ou descobrir o mapeamento da nova assinatura realitve para a assinatura antiga a ferramenta Avzone-Mapping script.

Importante

Espera-se que as medições descritas anteriormente forneçam resultados diferentes em cada região do Azure que dá suporte a Zonas de Disponibilidade. Mesmo que seus requisitos de latência de rede sejam os mesmos, talvez seja necessário adotar estratégias de implantação diferentes em diferentes regiões do Azure porque a latência de rede entre zonas pode ser diferente. 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 da rede entre as três zonas diferentes pode ser mais uniforme. A afirmação de que há sempre uma latência de rede entre 1 e 2 milissegundos não está correta. A latência de rede nas Zonas de Disponibilidade nas regiões do Azure não pode ser generalizada.

Implantação ativa/ativa

Essa arquitetura de implantação é chamada de ativa/ativa porque você implanta seus servidores de aplicativos SAP ativos em duas ou três zonas. A instância do SAP Central Services que usa replicação enqueue será implantada entre duas zonas. O mesmo vale para a camada DBMS, que será implantada nas mesmas zonas do SAP Central Service. Ao considerar essa configuração, você precisa encontrar as duas zonas de disponibilidade em sua região que oferecem latência de rede entre zonas aceitável para sua carga de trabalho e sua replicação síncrona de DBMS. Você também quer ter certeza de que o delta entre a latência de rede dentro das 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 os trabalhos em lote podem ser executados nas diferentes instâncias do aplicativo. O efeito colateral desse fato com a implantação ativa/ativa é que os trabalhos em lote podem ser executados por qualquer instância de aplicativo SAP, independentemente de serem executadas na mesma zona com o DBMS ativo ou não. Se a diferença na latência da rede entre as zonas de diferença for pequena em comparação com a latência da rede dentro de uma zona, a diferença nos tempos de execução dos trabalhos em lote pode não ser significativa. No entanto, quanto maior for a diferença de latência de rede dentro de uma zona, em comparação com o tráfego de rede entre zonas, o tempo de execução dos trabalhos em lote pode ser mais afetado se o trabalho for executado em uma zona onde a instância DBMS não está ativa. Cabe a você, como cliente, decidir quais são as diferenças aceitáveis no tempo de execução. E com isso qual é a latência de rede tolerável para tráfego entre zonas para a sua carga de trabalho.

Regiões do Azure onde essa implantação ativa/ativa pode ser possível sem grandes diferenças significativas no tempo de execução e na taxa de transferência dentro da camada de aplicativo implantada em diferentes zonas de disponibilidade, lista como:

  • Austrália Leste (duas das três zonas)
  • Brasil Sul (as três zonas)
  • Índia Central (as três zonas)
  • Centro dos EUA (as três zonas)
  • Ásia Oriental (as três zonas)
  • Leste dos EUA (duas das três zonas)
  • Leste dos EUA2 (as três zonas)
  • Alemanha Centro-Oeste (as três zonas)
  • Israel Central (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)
  • Qatar Central (as três zonas)
  • Norte da Europa (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 Asiático (as três zonas)
  • Suécia Central (as três zonas)
  • Suíça Norte (as três zonas)
  • EAU Norte (as três zonas)
  • Sul do Reino Unido (duas das três zonas)
  • Europa Ocidental (duas das três zonas)
  • Oeste US2 (as três zonas)
  • Oeste dos EUA3 (as três zonas)

A lista de regiões fornecida não permite que você, como cliente, teste sua carga de trabalho para decidir se uma arquitetura de implantação ativa/ativa é possível.

Regiões do Azure onde a arquitetura de implantação SAP ativa/ativa entre zonas pode não ser possível, liste como:

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

Embora para sua carga de trabalho individual, pode funcionar. Portanto, você deve testar antes de decidir por uma arquitetura. O Azure está constantemente a trabalhar para melhorar a qualidade e a latência das suas redes. As medições 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 se qualificar.

Um esquema simplificado de uma implantação ativa/ativa em duas zonas pode ter esta aparência:

Active/Active zone deployment

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

Importante

Neste cenário ativo/ativo, aplicam-se taxas para tráfego entre zonas. Verifique o documento Detalhes de preços de largura de banda. A transferência de dados entre a camada de aplicação SAP e a camada DBMS SAP é bastante intensiva. Portanto, o cenário ativo/ativo pode contribuir para os custos.

Implantação ativa/passiva

Se não for possível encontrar um delta aceitável entre a latência da rede dentro de uma zona e a latência do tráfego de rede entre zonas, você poderá implantar uma arquitetura que tenha um caractere ativo/passivo do ponto de vista da camada de aplicativos SAP. Você define uma zona ativa , que é a zona onde você implanta a camada de aplicativo completa e onde tenta executar o DBMS ativo e a instância do SAP Central Services. Com essa configuração, você precisa ter certeza de que não tem variações extremas de tempo de execução, dependendo se um trabalho é executado na zona com a instância DBMS ativa ou não, em transações comerciais e trabalhos 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 tem esta aparência:

Active/Passive zone deployment

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

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

A Microsoft não compartilha informações sobre distâncias geográficas entre os recursos que hospedam diferentes Zonas de Disponibilidade do Azure em uma região do Azure. Ainda assim, alguns clientes estão usando zonas para uma configuração combinada de HA e DR que promete um RPO (Recovery Point Objetive, objetivo de ponto de recuperação) de zero. Um RPO de zero significa que você não deve perder nenhuma transação de banco de dados comprometida, mesmo em casos de recuperação de desastres.

Nota

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

Aqui está um exemplo de como essa configuração pode parecer:

Combined high-availability DR in zones

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

Próximos passos

Aqui estão algumas próximas etapas para implantação nas Zonas de Disponibilidade do Azure: