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

A implantação das diferentes camadas de arquitetura SAP nas 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 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. O artigo lista quais regiões fornecem zonas de disponibilidade. A maioria das regiões do Azure que estão equipadas para hospedar uma carga de trabalho SAP maior 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 foram ou estão em processo de adaptação com zonas de disponibilidade.

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

• A camada de aplicação SAP, que pode ser de uma a algumas dezenas de máquinas virtuais (VM). 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 de banco de dados mantenham a latência da rede em uma janela aceitável
• A 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
• A camada de banco de dados SAP, 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) datacenter(s) 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. No lado positivo, as VMs são alinhadas com domínios de atualização e falha dentro dessa zona ou datacenter. Especificamente para o SAP ASCS ou camada de banco de dados, onde protegemos duas VMs por conjunto de disponibilidade, o alinhamento com domínios de falha evita 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), 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) datacenter(s) da zona como um todo. As VMs e seus discos relacionados também são colocados na mesma zona de disponibilidade. 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 o SAP ASCS e a camada de banco de dados, 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 (veja 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 contra 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 por um 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 interzonal, 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:

• Mais informações sobre as Zonas de Disponibilidade do Azure são apresentadas 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.
• Se você usa as Zonas de Disponibilidade como solução de DR de pequena distância, lembre-se de que tivemos desastres naturais que causaram danos generalizados em diferentes regiões do mundo, incluindo danos pesados e generalizados em infraestruturas de energia. As distâncias entre as várias zonas podem nem sempre ser suficientemente grandes para compensar essas catástrofes naturais de maior dimensão.
• A latência de rede nas Zonas de Disponibilidade não é a mesma em todas as regiões do Azure. Mesmo dentro de uma região do Azure, as latências de rede entre as diferentes zonas podem variar. Embora mesmo na pior das hipóteses, 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 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 banco 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 executando uma instância de diálogo SAP na zona com a instância de banco de dados 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 banco de dados ou em uma zona diferente (consulte mais adiante neste artigo).
• A latência de rede com as Zonas de Disponibilidade do Azure, mesmo nas zonas maiores, é suficientemente baixa para executar processos de negócios SAP. Até agora, vimos apenas alguns casos excecionais em que os clientes precisavam colocalizar a camada de aplicativos SAP e a camada de banco de dados sob uma única coluna de rede de datacenter.

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 de banco de dados SAP 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 Linux. Em vez disso, você precisa usar a SKU do Balanceador de Carga Padrão do Azure.
• Você precisa implantar a versão zonal do ExpressRoute Gateway, VPN Gateway e endereços IP públicos padrão para obter a proteção zonal desejada.

A combinação ideal de Zonas de Disponibilidade

A menos que você configure a atribuição do processo de negócios com funcionalidades SAP como Grupos de Logon, Grupos de Servidores RFC, Grupos de Servidores em Lote e similares, os processos de negócios podem ser executados nas diferentes instâncias de aplicativos em toda a camada de aplicativos SAP. O efeito colateral desse fato é que os trabalhos em lote podem ser executados por qualquer instância de aplicativo SAP, independentemente de serem executadas na mesma zona com a instância de banco de dados ativa 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 em que a instância do banco de dados não esteja 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. Puramente de um ponto de vista técnico, as latências de rede entre as Zonas de Disponibilidade do Azure dentro de uma região do Azure funcionam para a arquitetura do NetWeaver, S/4HANA ou outros aplicativos SAP. Também cabe a você, como cliente, mitigar essas diferenças usando os conceitos SAP de Grupos de Logon, Grupos de Servidores RFC, Grupos de Servidores em Lote e similares quando você decidir por um dos conceitos de implantação que estamos apresentando neste artigo.

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 de banco de dados são distribuídos em duas zonas. As VMs que executam a camada de aplicativos SAP são implantadas em números pares nas mesmas duas zonas. Se um banco de dados ou uma VM 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 do banco de dados ativo e as instâncias do aplicativo são executadas. Essa arquitetura é a arquitetura preferida para implantação em 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 SAP Logon Groups, RFC Server Groups, Batch Server Groups 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 de banco de dados ativa
• Ativo/passivo: o par de VMs que executam ASCS/SCS e o par de VMs que executam a camada de banco de dados são distribuídos em duas zonas. As VMs que executam a camada de aplicativo SAP são implantadas em uma das zonas de disponibilidade. Execute a camada de aplicativo na mesma zona que o ASCS/SCS ativo e a instância do banco de dados. Você pode usar essa arquitetura de implantação se considerar a latência de rede nas diferentes zonas como muito alta. E com isso causando diferenças intoleráveis no tempo de execução de seus processos de negócios. Ou se você quiser usar implantações de zona de disponibilidade como implantações de DR de curta distância. as zonas. Se um ASCS/SCS ou VM de banco de dados 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.

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 de banco de dados 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 de banco de dados nas duas zonas selecionadas.
• Use niping como uma ferramenta de medição. Esta ferramenta, da SAP, está descrita nas notas de suporte SAP #500235 e #1100926. Trate a classificação de latência de rede no SAP Note #1100926 como uma orientação aproximada. Latências de rede superiores a 0,7 milissegundos não significam que o sistema não vai funcionar tecnicamente ou que os processos de negócios não estão satisfazendo seus SLAs individuais. A nota não se destina a declarar o que é suportado ou não pela SAP e/ou Microsoft. 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 de banco de dados.
• 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.)

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 é implantada entre duas zonas. O mesmo vale para a camada de banco de dados, que é 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. 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 é aceitável para sua carga de trabalho.

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

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

• Não usando o Grupo de Posicionamento de Proximidade do Azure, você trata as Zonas de Disponibilidade do Azure como domínios de falha para todas as VMs porque os conjuntos de disponibilidade não podem ser implantados nas Zonas de Disponibilidade do Azure.
• Se você quiser combinar implantações zonais para a camada de banco de dados e serviços centrais, mas quiser usar conjuntos de disponibilidade do Azure para a camada de aplicativo, precisará usar grupos de proximidade do Azure conforme descrito no artigo Grupos de posicionamento de proximidade do Azure para latência de rede ideal com aplicativos SAP.
• Para os balanceadores de carga dos clusters de failover do SAP Central Services e da camada de banco de dados, você precisa usar o Balanceador de Carga do Azure SKU Padrão. O Basic Load Balancer não está funcionando entre zonas.
• Você precisa implantar a versão zonal do ExpressRoute Gateway, VPN Gateway e 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, juntamente com suas sub-redes, é estendida entre zonas. Você não precisa de redes virtuais e sub-redes separadas para cada zona.
• Para todas as máquinas virtuais implantadas, você precisa usar os Discos Gerenciados do Azure. Não há suporte para discos não gerenciados para implantações zonais.
• O SSD Premium do Azure v2, o armazenamento Ultra SSD ou os Arquivos NetApp do Azure não oferecem suporte a nenhuma replicação de armazenamento síncrono entre zonas. Para implantações de banco de dados, dependemos de métodos de banco de dados para replicar dados entre zonas.
• O SSD Premium v1, que suporta replicação zonal síncrona em zonas de disponibilidade, não foi testado com a carga de trabalho do banco de dados SAP. Portanto, a replicação síncrona zonal do SSD Premium do Azure v1 precisa ser considerada como não suportada para cargas de trabalho de banco de dados SAP.
• Para compartilhamentos SMB e NFS baseados em Arquivos Premium do Azure, a redundância zonal com replicação síncrona é oferecida. Verifique neste documento a disponibilidade do ZRS para Arquivos Premium do Azure na região em que você deseja implantar. O uso de compartilhamentos NFS e SMB replicados zonais é totalmente suportado com implantações de camada de aplicativo SAP e clusters de failover de alta disponibilidade para serviços centrais NetWeaver ou S/4HANA. Os documentos que abrangem estes casos são:
  • Elevada disponibilidade do SAP NetWeaver em VMs do Azure no SUSE Linux Enterprise Server com NFS nos Ficheiros do Azure
  • Elevada disponibilidade de Máquinas Virtuais do Azure para SAP NetWeaver no Red Hat Enterprise Linux com Azure NetApp Files para as Aplicações SAP
  • Alta disponibilidade para SAP NetWeaver em VMs do Azure no Windows com o Azure Files Premium SMB para aplicativos SAP
• 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 Esgrima do Azure. Ou para mais instâncias de aplicativos.
• Para obter consistência de tempo de execução para processos de negócios críticos, você pode tentar direcionar determinados trabalhos em lote e usuários para instâncias de aplicativos que estão na zona com a instância de banco de dados ativa usando grupos de servidores em lote SAP, grupos de logon SAP ou grupos RFC. No entanto, no processo de failover zonal, você precisaria mover manualmente esses grupos para instâncias em execução em VMs que estão na zona com a VM de banco de dados ativa.
• Talvez você queira implantar instâncias de diálogo inativas em cada uma das zonas.

Implantação ativa/passiva

Se não conseguir encontrar uma configuração que reduza o delta potencial no tempo de execução dos processos de negócios SAP ou se quiser implantar uma configuração de recuperação de desastres de curta distância, 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 a instância de banco de dados ativa e a instância do SAP Central Services. Com essa configuração, você precisa garantir que não tenha variações extremas de tempo de execução, dependendo se um trabalho é executado na zona com a instância de banco de dados ativa ou não, em transações comerciais e trabalhos em lote.

O layout básico da arquitetura tem esta aparência:

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

• Os conjuntos de disponibilidade não podem ser implantados nas Zonas de Disponibilidade do Azure. Para atenuar, você pode usar os grupos de posicionamento de 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, você precisa monitorar o status de perto e tentar manter a instância de banco de dados ativa e as instâncias do SAP Central Services na mesma zona da camada de aplicativo implantada. Se houve um failover do SAP Central Service ou da instância do banco de dados, você deve ter certeza de que pode fazer failover manualmente na zona com a camada de aplicativo SAP implantada o mais rápido possível.
• Para os balanceadores de carga dos clusters de failover do SAP Central Services e da camada de banco de dados, você precisa usar o Balanceador de Carga do Azure SKU Padrão. O Basic Load Balancer não está funcionando entre zonas.
• Você precisa implantar a versão zonal do ExpressRoute Gateway, VPN Gateway e 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, juntamente com suas sub-redes, é estendida entre zonas. Você não precisa de redes virtuais separadas para cada zona.
• Para todas as máquinas virtuais implantadas, você precisa usar os Discos Gerenciados do Azure. Não há suporte para discos não gerenciados para implantações zonais.
• O SSD Premium do Azure v2, o armazenamento Ultra SSD ou os Arquivos NetApp do Azure não oferecem suporte a nenhuma replicação de armazenamento síncrono entre zonas. Para implantações de banco de dados, dependemos de métodos de banco de dados para replicar dados entre zonas.
• O SSD Premium v1, que suporta replicação zonal síncrona em zonas de disponibilidade, não foi testado com a carga de trabalho do banco de dados SAP. Portanto, a replicação síncrona zonal configurável do SSD Premium do Azure v1 precisa ser considerada como não suportada para cargas de trabalho de banco de dados SAP.
• Para compartilhamentos SMB e NFS baseados em Arquivos Premium do Azure, a redundância zonal com replicação síncrona é oferecida. Verifique neste documento a disponibilidade do ZRS para Arquivos Premium do Azure na região em que você deseja implantar. O uso de compartilhamentos NFS e SMB replicados zonais é totalmente suportado com implantações de camada de aplicativo SAP e clusters de failover de alta disponibilidade para serviços centrais NetWeaver ou S/4HANA. Os documentos que abrangem estes casos são:
  • Elevada disponibilidade do SAP NetWeaver em VMs do Azure no SUSE Linux Enterprise Server com NFS nos Ficheiros do Azure
  • Elevada disponibilidade de Máquinas Virtuais do Azure para SAP NetWeaver no Red Hat Enterprise Linux com Azure NetApp Files para as Aplicações SAP
  • Alta disponibilidade para SAP NetWeaver em VMs do Azure no Windows com o Azure Files Premium SMB para aplicativos SAP
• 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 Esgrima do Azure. Ou para instâncias de aplicativos adicionais.
• Você deve implantar VMs inativas na zona passiva (do ponto de vista do banco de dados) para que possa iniciar os recursos do aplicativo em caso de falha de zona. Outra possibilidade pode ser usar o Azure Site Recovery, que é capaz de replicar VMs ativas para VMs inativas entre zonas.
• Você deve investir em automação que permita iniciar automaticamente a camada de aplicativos SAP na segunda zona se ocorrer uma interrupção zonal.

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 (DR de curta distância) 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.

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

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 permanecer em uma determinada região do Azure. Os conjuntos de disponibilidade não podem ser implantados nas Zonas de Disponibilidade do Azure. Para compensar isso, você pode usar os grupos de posicionamento de 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, você precisa monitorar o status de perto e tentar manter a instância de banco de dados ativa e as instâncias do SAP Central Services na mesma zona da camada de aplicativo implantada. Se houve um failover do SAP Central Service ou da instância do banco de dados, você deve ter certeza de que pode fazer failover manualmente na zona com a camada de aplicativo SAP implantada o mais rápido possível.
• Você deve ter instâncias de aplicativo de produção pré-instaladas nas VMs que executam as instâncias ativas do aplicativo de QA.
• Em um caso de falha zonal, desligue as instâncias do aplicativo de controle de qualidade e inicie as instâncias de produção. Você precisa usar nomes virtuais para as instâncias do aplicativo para fazer isso funcionar.
• Para os balanceadores de carga dos clusters de failover do SAP Central Services e da camada de banco de dados, você precisa usar o Balanceador de Carga do Azure SKU Padrão. O Basic Load Balancer não está funcionando entre zonas.
• Você precisa implantar a versão zonal do ExpressRoute Gateway, VPN Gateway e 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, juntamente com suas sub-redes, é estendida entre zonas. Você não precisa de redes virtuais separadas para cada zona.
• Para todas as máquinas virtuais implantadas, você precisa usar os Discos Gerenciados do Azure. Não há suporte para discos não gerenciados para implantações zonais.
• O SSD Premium do Azure v2, o armazenamento Ultra SSD ou os Arquivos NetApp do Azure não oferecem suporte a nenhuma replicação de armazenamento síncrono entre zonas. Para implantações de banco de dados, dependemos de métodos de banco de dados para replicar dados entre zonas.
• O SSD Premium v1, que suporta replicação zonal síncrona em zonas de disponibilidade, não foi testado com a carga de trabalho do banco de dados SAP. Portanto, a replicação síncrona zonal configurável do SSD Premium do Azure v1 precisa ser considerada como não suportada para cargas de trabalho de banco de dados SAP.
• Para compartilhamentos SMB e NFS baseados em Arquivos Premium do Azure, a redundância zonal com replicação síncrona é oferecida. Verifique neste documento a disponibilidade do ZRS para Arquivos Premium do Azure na região em que você deseja implantar. O uso de compartilhamentos NFS e SMB replicados zonais é totalmente suportado com implantações de camada de aplicativo SAP e clusters de failover de alta disponibilidade para serviços centrais NetWeaver ou S/4HANA. Os documentos que abrangem estes casos são:
  • Elevada disponibilidade do SAP NetWeaver em VMs do Azure no SUSE Linux Enterprise Server com NFS nos Ficheiros do Azure
  • Elevada disponibilidade de Máquinas Virtuais do Azure para SAP NetWeaver no Red Hat Enterprise Linux com Azure NetApp Files para as Aplicações SAP
  • Alta disponibilidade para SAP NetWeaver em VMs do Azure no Windows com o Azure Files Premium SMB para aplicativos SAP
• 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 Esgrima do Azure.

Próximos passos

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

• Agrupar uma instância SAP ASCS/SCS em um cluster de failover do Windows usando um disco compartilhado de cluster no Azure
• Preparar a infraestrutura do Azure para alta disponibilidade SAP usando um cluster de failover do Windows e compartilhamento de arquivos para instâncias SAP ASCS/SCS