Opções de configuração para minimizar a latência da rede com aplicativos SAP

Os aplicativos SAP baseados na arquitetura SAP NetWeaver ou SAP S/4HANA são sensíveis à latência da rede entre a camada de aplicativos SAP e a camada de banco de dados SAP. Essa sensibilidade é o resultado da maior parte da lógica de negócios em execução na camada de aplicativo. Como a camada de aplicativo SAP executa a lógica de negócios, ela emite consultas para a camada de banco de dados com alta frequência, a uma taxa de milhares ou dezenas de milhares por segundo. Na maioria dos casos, a natureza dessas consultas é simples. Muitas vezes, eles podem ser executados na camada de banco de dados em 500 microssegundos ou menos.

O tempo gasto na rede para enviar essa consulta da camada de aplicativo para a camada de banco de dados e receber o resultado enviado de volta tem um grande impacto no tempo necessário para executar os processos de negócios. Essa sensibilidade à latência da rede é o motivo pelo qual você pode querer atingir determinada latência mínima de rede em projetos de implantação SAP. Consulte SAP Note #1100926 - FAQ: Network performance para obter diretrizes sobre como classificar a latência da rede.

Em muitas regiões do Azure, o número de datacenters cresceu. Ao mesmo tempo, os clientes, especialmente para sistemas SAP high-end, estão usando famílias de VM mais especiais, como a família Mv2 ou Mv3 e mais recentes. Esses tipos de máquina virtual do Azure nem sempre estão disponíveis em cada um dos datacenters que coletam em uma região do Azure. Esses fatos podem criar oportunidades para otimizar a latência da rede entre a camada de aplicativos SAP e a camada SAP DBMS.

O Azure fornece diferentes opções de implantação para cargas de trabalho SAP. Para o tipo de implantação escolhido, você tem opções para otimizar a latência da rede, se necessário. Informações detalhadas sobre cada opção são descritas detalhadamente nas seguintes seções deste artigo:

• Grupos de Colocação de Proximidade
• Conjunto de dimensionamento de máquina virtual com orquestração flexível

Grupos de Colocação de Proximidade

Os grupos de posicionamento de proximidade permitem o agrupamento de diferentes tipos de VM em uma única coluna vertebral de rede, garantindo uma baixa latência de rede ideal entre eles. Quando a primeira VM é implantada no grupo de posicionamento de proximidade, essa VM fica vinculada a uma coluna de rede específica. Como todas as outras VMs que serão implantadas no mesmo grupo de posicionamento de proximidade, essas VMs são agrupadas sob a mesma coluna de rede. Por mais atraente que essa perspetiva pareça, o uso da construção introduz algumas restrições e armadilhas também:

• Você não pode assumir que todos os tipos de VM do Azure estão disponíveis em todos e quaisquer datacenters do Azure ou em cada coluna de rede. Como resultado, a combinação de diferentes tipos de VM dentro de um grupo de posicionamento de proximidade pode ser severamente restringida. Essas restrições ocorrem porque o hardware de host necessário para executar um determinado tipo de VM pode não estar presente no datacenter ou sob a coluna de rede à qual o grupo de posicionamento de proximidade foi atribuído
• Ao redimensionar partes das VMs que estão dentro de um grupo de posicionamento de proximidade, você não pode assumir automaticamente que, em todos os casos, o novo tipo de VM está disponível no mesmo datacenter ou sob a coluna da rede à qual o grupo de posicionamento de proximidade foi atribuído
• À medida que o Azure descomissiona o hardware, ele pode forçar determinadas VMs de um grupo de posicionamento de proximidade para outro datacenter do Azure ou outra coluna de rede. Para obter detalhes sobre este caso, leia o documento Grupos de colocação de proximidade

Os cenários em que os grupos de posicionamento de proximidade podem ser usados para otimizar a latência da rede:

• Você deseja implantar os recursos críticos de sua carga de trabalho SAP em diferentes zonas de disponibilidade e, por outro lado, precisa que as VMs da camada de aplicativo sejam espalhadas por diferentes domínios de falha usando conjuntos de disponibilidade em cada uma das zonas. Neste caso, como descrito mais adiante no documento, os grupos de colocação de proximidade são a cola necessária.
• Você implanta a carga de trabalho SAP com conjuntos de disponibilidade. Onde a camada de banco de dados SAP, a camada de aplicativo SAP e VMs ASCS/SCS são agrupadas em três conjuntos de disponibilidade diferentes. Nesse caso, você deseja garantir que os conjuntos de disponibilidade não estejam espalhados por toda a região do Azure, pois isso pode, dependendo da região do Azure, resultar em latência de rede que pode afetar negativamente a carga de trabalho do SAP.
• Você usa grupos de posicionamento de proximidade para agrupar VMs para obter a menor latência de rede possível entre os serviços hospedados nas VMs. Por exemplo, a latência dentro de uma zona de disponibilidade sozinha não atende aos requisitos do aplicativo.

Quanto ao cenário de implantação #2, em muitas regiões, especialmente regiões sem zonas de disponibilidade e na maioria das regiões com zonas de disponibilidade, a latência da rede independente de onde as VMs aterrissam é aceitável. Embora existam algumas regiões do Azure que não podem fornecer uma experiência suficientemente boa sem colocar os três conjuntos de disponibilidade diferentes sem o uso de grupos de posicionamento de proximidade.

O que são grupos de colocação de proximidade?

Um grupo de posicionamento de proximidade do Azure é uma construção lógica. Quando um grupo de posicionamento de proximidade é definido, ele é vinculado a uma região do Azure e a um grupo de recursos do Azure. Quando as VMs são implantadas, um grupo de posicionamento de proximidade é referenciado por:

• A primeira VM do Azure implantada sob uma coluna de rede com muitas unidades de computação do Azure e baixa latência de rede. Essa coluna de rede geralmente corresponde a um único datacenter do Azure. Você pode pensar na primeira máquina virtual como uma "VM de escopo" que é implantada em uma unidade de escala de computação com base em algoritmos de alocação do Azure que são eventualmente combinados com parâmetros de implantação.
• Todas as VMs subsequentes implantadas que fazem referência ao grupo de posicionamento de proximidade serão implantadas na mesma coluna de rede da primeira máquina virtual.

Para reduzir o risco dos itens acima, é recomendável usar a opção de intenção ao criar o grupo de posicionamento de proximidade. A opção de intenção permite listar os tipos de VM que você pretende incluir no grupo de posicionamento de proximidade. Esta lista de tipos de VM será usada para encontrar o melhor datacenter que hospeda esses tipos de VM. Se esse datacenter for encontrado, o PPG será criado e terá escopo para o datacenter que atende aos requisitos de SKU da VM. Se não houver esse datacenter encontrado, a criação do grupo de posicionamento de proximidade falhará. Você pode encontrar mais informações na documentação PPG - Use intent to specify VM sizes. Esteja ciente de que as situações reais de capacidade não são levadas em conta nas verificações acionadas pela opção de intenção. Consequentemente, poderão ainda verificar-se erros de atribuição baseados na insuficiente capacidade disponível.

Um único grupo de recursos do Azure pode ter vários grupos de posicionamento de proximidade atribuídos a ele. Mas um grupo de posicionamento de proximidade pode ser atribuído a apenas um grupo de recursos do Azure.

Para obter mais informações e exemplos de implantação de grupos de posicionamento de proximidade, consulte a documentação disponível.

Grupos de posicionamento de proximidade com implantações zonais

É importante fornecer uma latência de rede razoavelmente baixa entre a camada de aplicativo SAP e a camada DBMS. Na maioria das situações, uma implantação zonal sozinha atende a esse requisito. Para um conjunto limitado de cenários, uma implantação zonal sozinha pode não atender aos requisitos de latência do aplicativo. Essas situações exigem o posicionamento da VM o mais próximo possível e permitem uma latência de rede razoavelmente baixa, um grupo de posicionamento de proximidade do Azure pode ser definido para esse sistema SAP.

Evite agrupar vários sistemas de produção ou não produção SAP em um único grupo de colocação de proximidade. Evite pacotes de sistemas SAP porque quanto mais sistemas você agrupar em um grupo de posicionamento de proximidade, maiores serão as chances:

• Que você precisa de um tipo de VM que não esteja disponível na coluna de rede à qual o grupo de posicionamento de proximidade foi atribuído.
• Esses recursos de VMs não convencionais, como VMs da série M, podem eventualmente não ser atendidos quando você precisar expandir o número de VMs em um grupo de posicionamento de proximidade ao longo do tempo.

Com base em muitas melhorias implantadas pela Microsoft nas regiões do Azure para reduzir a latência da rede dentro de uma zona de disponibilidade do Azure, as diretrizes de implantação ao usar grupos de posicionamento de proximidade para implantações zonais têm a seguinte aparência:

A diferença em relação à recomendação dada até agora é que as VMs de banco de dados nas duas zonas não fazem mais parte dos grupos de posicionamento de proximidade. Os grupos de posicionamento de proximidade por zona agora têm escopo com a implantação da VM executando as instâncias SAP ASCS/SCS. Isso também significa que, para as regiões onde as zonas de disponibilidade são coletadas por vários datacenters, a instância ASCS/SCS e a camada de aplicativo podem ser executadas sob uma coluna de rede e as VMs de banco de dados podem ser executadas sob outra coluna de rede. Embora com as melhorias de rede feitas, a latência de rede entre a camada de aplicativo SAP e a camada DBMS ainda deve ser suficiente para um desempenho e taxa de transferência suficientemente bons. A vantagem dessa nova configuração é que você tem mais flexibilidade para redimensionar VMs ou mudar para novos tipos de VM com a camada DBMS e/ou a camada de aplicativo do sistema SAP.

Para o caso especial de usar os Arquivos NetApp do Azure para o ambiente DBMS e a funcionalidade relacionada aos Arquivos NetApp do Azure do grupo de volumes de aplicativos do Azure NetApp Files para SAP HANA e sua necessidade para grupos de posicionamento de proximidade, verifique os volumes do documento NFS v4.1 no Azure NetApp Files for SAP HANA.

Grupos de posicionamento de proximidade com implantações de conjunto de disponibilidade

Nesse caso, a finalidade é usar grupos de posicionamento de proximidade para colocar as VMs que são implantadas por meio de diferentes conjuntos de disponibilidade. Nesse cenário de uso, você não está usando uma implantação controlada em diferentes zonas de disponibilidade em uma região. Em vez disso, você deseja implantar o sistema SAP usando conjuntos de disponibilidade. Como resultado, você tem pelo menos um conjunto de disponibilidade para as VMs DBMS, VMs ASCS/SCS e VMs da camada de aplicativo. Como não é possível especificar no momento da implantação de uma VM um conjunto de disponibilidade E uma zona de disponibilidade, não é possível controlar onde as VMs nos diferentes conjuntos de disponibilidade serão alocadas. Isso pode resultar em algumas regiões do Azure que a latência de rede entre VMs diferentes ainda pode ser muito alta para fornecer uma experiência de desempenho suficientemente boa. Assim, a arquitetura resultante seria parecida com:

Neste gráfico, um único grupo de colocação de proximidade seria atribuído a um único sistema SAP. Este PPG é atribuído aos três conjuntos de disponibilidade. O grupo de posicionamento de proximidade é então definido como escopo implantando as primeiras VMs da camada de banco de dados no conjunto de disponibilidade do DBMS. Esta recomendação de arquitetura aloca todas as VMs sob a mesma coluna vertebral de rede. Está introduzindo as restrições mencionadas anteriormente neste artigo. Portanto, a arquitetura de grupo de colocação de proximidade deve ser usada esparsamente.

Combine conjuntos de disponibilidade e zonas de disponibilidade com grupos de posicionamento de proximidade

Um dos problemas ao usar zonas de disponibilidade para implantações de sistemas SAP é que não é possível implantar a camada de aplicativos SAP usando conjuntos de disponibilidade dentro da zona de disponibilidade específica. Você deseja que a camada de aplicativo SAP seja implantada nas mesmas zonas que as VMs SAP ASCS/SCS. Fazer referência a uma zona de disponibilidade e a um conjunto de disponibilidade ao implantar uma única VM não é possível até agora. Mas apenas implantando uma VM instruindo uma zona de disponibilidade, você perde a capacidade de garantir que as VMs da camada de aplicativo estejam espalhadas por diferentes domínios de atualização e falha.

Usando grupos de posicionamento de proximidade, você pode ignorar essa restrição. Aqui está a sequência de implantação:

• Crie um grupo de posicionamento de proximidade.
• Implante sua VM âncora, recomendada como a VM ASCS/SCS, fazendo referência a uma zona de disponibilidade.
• Crie um conjunto de disponibilidade que faça referência ao grupo de posicionamento de proximidade do Azure. (Consulte o comando mais adiante neste artigo.)
• Implante as VMs da camada de aplicativo fazendo referência ao conjunto de disponibilidade e ao grupo de posicionamento de proximidade.

Em vez de implantar a primeira VM, como demonstrado na seção anterior, você faz referência a uma zona de disponibilidade e ao grupo de posicionamento de proximidade ao implantar a VM:

New-AzVm -ResourceGroupName "ppgexercise" -Name "centralserviceszone1" -Location "westus2" -OpenPorts 80,3389 -Zone "1" -ProximityPlacementGroup "collocate" -Size "Standard_E8s_v4"

Uma implantação bem-sucedida dessa máquina virtual hospedaria a instância ASCS/SCS do sistema SAP em uma zona de disponibilidade. Nesse caso, a VM e o VHD base da VM e os discos de armazenamento em bloco do Azure potencialmente montados são alocados na mesma zona de disponibilidade. O escopo do grupo de posicionamento de proximidade é fixado a uma das espinhas da rede na zona de disponibilidade definida.

Na próxima etapa, você precisa criar os conjuntos de disponibilidade que deseja usar para a camada de aplicativos do seu sistema SAP.

Defina e crie o grupo de posicionamento de proximidade. O comando para criar o conjunto de disponibilidade requer uma referência adicional ao ID do grupo de posicionamento de proximidade (não ao nome). Você pode obter a ID do grupo de posicionamento de proximidade usando este comando:

Get-AzProximityPlacementGroup -ResourceGroupName "ppgexercise" -Name "collocate"

Ao criar o conjunto de disponibilidade, você precisa considerar parâmetros adicionais ao usar discos gerenciados (padrão, a menos que especificado de outra forma) e grupos de posicionamento de proximidade:

New-AzAvailabilitySet -ResourceGroupName "ppgexercise" -Name "ppgavset" -Location "westus2" -ProximityPlacementGroupId "/subscriptions/my very long ppg id string" -sku "aligned" -PlatformUpdateDomainCount 3 -PlatformFaultDomainCount 2 

Idealmente, você deve usar três domínios de falha. Mas o número de domínios de falha suportados pode variar de região para região. Neste caso, o número máximo possível de domínios de falha para as regiões específicas é dois. Para implantar suas VMs de camada de aplicativo, você precisa adicionar uma referência ao nome do conjunto de disponibilidade e ao nome do grupo de posicionamento de proximidade, conforme mostrado aqui:

New-AzVm -ResourceGroupName "ppgexercise" -Name "appinstance1" -Location "westus2" -OpenPorts 80,3389 -AvailabilitySetName "myppgavset" -ProximityPlacementGroup "collocate" -Size "Standard_E16s_v4"

O resultado dessa implantação é:

• Um serviço central para seu sistema SAP localizado em uma zona de disponibilidade específica.
• Uma camada de aplicativo SAP localizada por meio de conjuntos de disponibilidade na mesma coluna de rede que a VM ou VMs dos serviços SAP Central (ASCS/SCS).

Alterar as configurações do grupo de posicionamento de proximidade de um sistema existente

Se você implementou grupos de posicionamento de proximidade a partir das recomendações fornecidas até agora e deseja se ajustar à nova configuração, poderá fazê-lo com os métodos descritos nestes artigos:

• Implante VMs em grupos de posicionamento de proximidade usando a CLI do Azure.
• Implante VMs em grupos de posicionamento de proximidade usando o PowerShell.

Você também pode usar esses comandos para casos em que está recebendo erros de alocação em casos em que não é possível mover para um novo tipo de VM com uma VM existente no grupo de posicionamento de proximidade.

Conjunto de dimensionamento de máquina virtual com orquestração flexível

Para evitar as limitações associadas ao grupo de posicionamento de proximidade, é aconselhável implantar a carga de trabalho SAP em zonas de disponibilidade usando o conjunto de escala flexível com FD=1. Essa estratégia de implantação garante que as VMs implantadas em cada zona não fiquem restritas a um único datacenter ou coluna de rede, e todos os componentes do sistema SAP, como bancos de dados, ASCS/ERS e camada de aplicativo, tenham escopo dentro de uma zona. Com todos os componentes do sistema SAP sendo definidos no nível zonal, a latência da rede entre os diferentes componentes de um único sistema SAP deve ser suficiente para garantir um desempenho e rendimento satisfatórios. O principal benefício dessa nova opção de implantação com conjunto de escala flexível com FD=1 é que ela oferece maior flexibilidade no redimensionamento de VMs ou na mudança para novos tipos de VM para todas as camadas do sistema SAP. Além disso, o conjunto de escala alocaria VMs em vários domínios de falha dentro de uma única zona, o que é ideal para executar várias VMs da camada de aplicativo em cada zona. Para obter mais informações, consulte Conjunto de dimensionamento de máquina virtual para documento de carga de trabalho SAP.

Em um ambiente de não-produção ou não-HA, é possível implantar todos os componentes do sistema SAP, incluindo o banco de dados, ASCS e camada de aplicativo, dentro de uma única zona usando um conjunto de escala flexível com FD=1.

Opções de implantação recomendadas anteriormente

Esta seção inclui detalhes sobre as opções de implantação recomendadas anteriormente para otimizar a latência da rede para SAP. Com os novos recursos e o crescimento do Azure ao longo do tempo, os detalhes nesta seção só devem ser aplicados em casos raros.

Grupos de posicionamento de proximidade para todo o sistema SAP com implantações zonais

O uso do grupo de posicionamento de proximidade que recomendamos até agora parece neste gráfico.

Você cria um grupo de posicionamento de proximidade (PPG) em cada uma das duas zonas de disponibilidade em que implantou seu sistema SAP. Todas as VMs de uma zona específica fazem parte do grupo de posicionamento de proximidade individual dessa zona específica. Você começa em cada zona com a implantação da VM DBMS para definir o escopo do PPG e, em seguida, implanta a VM ASCS na mesma zona e PPG. Em uma terceira etapa, você cria um conjunto de disponibilidade do Azure, atribui o conjunto de disponibilidade ao PPG com escopo e implanta a camada de aplicativo SAP nele. A vantagem desta configuração era que todos os componentes estavam bem alinhados sob a mesma coluna vertebral da rede. A grande desvantagem é que sua flexibilidade no redimensionamento de máquinas virtuais pode ser limitada.

Com base em muitos aprimoramentos implantados pela Microsoft nas regiões do Azure para reduzir a latência da rede em uma zona de disponibilidade do Azure, as diretrizes de implantação atuais para implantações zonais neste artigo existem.

Grupos de posicionamento de proximidade e instâncias grandes do HANA

Se alguns de seus sistemas SAP dependerem de Instâncias Grandes do HANA para a camada de banco de dados, você poderá experimentar melhorias significativas na latência da rede entre a unidade de Instâncias Grandes do HANA e as VMs do Azure ao usar unidades de Instâncias Grandes do HANA implantadas em linhas ou carimbos da Revisão 4. Uma melhoria é que as unidades HANA Large Instances, à medida que são implantadas, são implantadas com um grupo de posicionamento de proximidade. Você pode usar esse grupo de posicionamento de proximidade para implantar suas VMs de camada de aplicativo. Como resultado, essas VMs serão implantadas no mesmo datacenter que hospeda sua unidade HANA Large Instances.

Para determinar se sua unidade de Instâncias Grandes do HANA é implantada em um carimbo ou linha da Revisão 4, verifique o artigo Controle de Instâncias Grandes do HANA do Azure por meio do portal do Azure. Na visão geral de atributos da unidade HANA Large Instances, você também pode determinar o nome do grupo de posicionamento de proximidade porque ele foi criado quando a unidade HANA Large Instances foi implantada. O nome que aparece na visão geral de atributos é o nome do grupo de posicionamento de proximidade no qual você deve implantar suas VMs de camada de aplicativo.

Em comparação com os sistemas SAP que usam apenas máquinas virtuais do Azure, quando você usa instâncias grandes do HANA, tem menos flexibilidade para decidir quantos grupos de recursos do Azure usar. Todas as unidades de Instâncias Grandes do HANA de um locatário de Instâncias Grandes do HANA são agrupadas em um único grupo de recursos, conforme descrito neste artigo. A menos que você implante em locatários diferentes para separar, por exemplo, sistemas de produção e não produção ou outros sistemas, todas as suas unidades HANA Large Instances serão implantadas em um locatário HANA Large Instances. Este inquilino tem uma relação um-para-um com um grupo de recursos. Mas será definido um grupo de colocação de proximidade separado para cada uma das unidades individuais.

Como resultado, as relações entre grupos de recursos do Azure e grupos de posicionamento de proximidade para um único locatário serão as mostradas aqui:

Próximos passos

Confira a documentação:

• Cargas de trabalho SAP no Azure: lista de verificação de planeamento e implementação
• Implementar VMs em grupos de colocação por proximidade com a CLI do Azure
• Implantar VMs em grupos de posicionamento de proximidade usando o PowerShell
• Considerações para a implantação do DBMS de Máquinas Virtuais do Azure para cargas de trabalho SAP