Conectividade de ponto final público para Máquinas Virtuais com o Azure Balanceador de Carga Standard em cenários de elevada disponibilidade do SAP

  • Artigo

O âmbito deste artigo é descrever as configurações, que irão permitir a conectividade de saída para pontos finais públicos. As configurações encontram-se principalmente no contexto de Elevada Disponibilidade com o Pacemaker para SUSE/RHEL.

Se estiver a utilizar o Pacemaker com o agente de vedação do Azure na sua solução de elevada disponibilidade, as VMs têm de ter conectividade de saída à API de gestão do Azure. O artigo apresenta várias opções que lhe permitem selecionar a opção mais adequada para o seu cenário.

Descrição Geral

Ao implementar elevada disponibilidade para soluções SAP através do clustering, um dos componentes necessários é Balanceador de Carga do Azure. O Azure oferece dois SKUs de balanceador de carga: padrão e básico.

O balanceador de carga standard do Azure oferece algumas vantagens sobre o balanceador de carga Básico. Por exemplo, funciona em zonas de Disponibilidade do Azure, tem melhores capacidades de monitorização e registo para facilitar a resolução de problemas e a latência reduzida. A funcionalidade "Portas HA" abrange todas as portas, ou seja, já não é necessário listar todas as portas individuais.

Existem algumas diferenças importantes entre o SKU básico e o SKU padrão do balanceador de carga do Azure. Um deles é o processamento do tráfego de saída para o ponto final público. Para obter a comparação completa do balanceador de carga do SKU Básico versus Standard, veja Balanceador de Carga comparação de SKU.

Quando as VMs sem endereços IP públicos são colocadas no conjunto de back-end do balanceador de carga do Azure Standard (sem endereço IP público), não existe conectividade de saída para pontos finais públicos, a menos que seja efetuada uma configuração adicional.

Se for atribuído um endereço IP público a uma VM ou se a VM estiver no conjunto de back-end de um balanceador de carga com endereço IP público, terá conectividade de saída para pontos finais públicos.

Os sistemas SAP contêm frequentemente dados empresariais confidenciais. Raramente é aceitável que as VMs que alojam sistemas SAP sejam acessíveis através de endereços IP públicos. Ao mesmo tempo, existem cenários que requerem conectividade de saída da VM para os pontos finais públicos.

Exemplos de cenários que requerem acesso ao ponto final público do Azure são:

  • O Agente do Azure Fence requer acesso a management.azure.com e login.microsoftonline.com
  • Azure Backup
  • Azure Site Recovery
  • Utilizar o repositório público para corrigir o sistema operativo
  • O fluxo de dados da aplicação SAP pode exigir conectividade de saída para o ponto final público

Se a implementação do SAP não necessitar de conectividade de saída para pontos finais públicos, não precisa de implementar a configuração adicional. É suficiente para criar Balanceador de Carga do Azure de SKU padrão internos para o seu cenário de elevada disponibilidade, assumindo que também não há necessidade de conectividade de entrada a partir de pontos finais públicos.

Nota

Quando as VMs sem endereços IP públicos são colocadas no conjunto de back-end do balanceador de carga do Azure Standard (sem endereço IP público), não haverá conectividade à Internet de saída, a menos que seja efetuada uma configuração adicional para permitir o encaminhamento para pontos finais públicos.
Se as VMs tiverem endereços IP públicos ou já estiverem no conjunto de back-end do Balanceador de Carga do Azure com endereço IP público, a VM já terá conectividade de saída para pontos finais públicos.

Leia primeiro os seguintes artigos:

Opção 1: Balanceador de Carga Standard externos adicionais do Azure para ligações de saída à Internet

Uma opção para alcançar a conectividade de saída aos pontos finais públicos, sem permitir a conectividade de entrada à VM a partir do ponto final público, é criar um segundo balanceador de carga com endereço IP público, adicionar as VMs ao conjunto de back-end do segundo balanceador de carga e definir apenas regras de saída.
Utilize Grupos de Segurança de Rede para controlar os pontos finais públicos, que estão acessíveis para chamadas de saída da VM.
Para obter mais informações, veja Cenário 2 no documento Ligações de saída.
A configuração teria o seguinte aspeto:

Controlar a conectividade a pontos finais públicos com Grupos de Segurança de Rede

Considerações importantes

  • Pode utilizar uma Balanceador de Carga Pública adicional para várias VMs na mesma sub-rede para alcançar a conectividade de saída ao ponto final público e otimizar o custo
  • Utilize Grupos de Segurança de Rede para controlar quais os pontos finais públicos que estão acessíveis a partir das VMs. Pode atribuir o Grupo de Segurança de Rede à sub-rede ou a cada VM. Sempre que possível, utilize etiquetas de serviço para reduzir a complexidade das regras de segurança.
  • O Balanceador de carga padrão do Azure com endereço IP público e regras de saída permite o acesso direto ao ponto final público. Se tiver requisitos de segurança empresarial para que todo o tráfego de saída passe através de uma solução empresarial centralizada para auditoria e registo, poderá não conseguir cumprir o requisito com este cenário.

Dica

Sempre que possível, utilize etiquetas de serviço para reduzir a complexidade do Grupo de Segurança de Rede.

Passos da implementação

  1. Criar Balanceador de Carga

    1. No portal do Azure , clique em Todos os recursos, Adicionar e, em seguida, procure Balanceador de Carga
    2. Clique em Criar
    3. Balanceador de Carga Nome MyPublicILB
    4. Selecione Público como Um Tipo, Standard como SKU
    5. Selecione Criar endereço IP Público e especifique como um nome MyPublicILBFrondEndIP
    6. Selecionar Zona Redundante como Zona de disponibilidade
    7. Clique em Rever e Criar e, em seguida, clique em Criar

  2. Crie o conjunto de back-end MyBackendPoolOfPublicILB e adicione as VMs.

    1. Selecione a Rede virtual
    2. Selecione as VMs e os respetivos endereços IP e adicione-as ao conjunto de back-end

  3. Criar regras de saída.

     az network lb outbound-rule create --address-pool MyBackendPoolOfPublicILB --frontend-ip-configs MyPublicILBFrondEndIP --idle-timeout 30 --lb-name MyPublicILB --name MyOutBoundRules  --outbound-ports 10000 --enable-tcp-reset true --protocol All --resource-group MyResourceGroup

  4. Crie regras de grupo de Segurança de Rede para restringir o acesso a Pontos Finais Públicos específicos. Se existir um Grupo de Segurança de Rede existente, pode ajustá-lo. O exemplo abaixo mostra como ativar o acesso à API de gestão do Azure:

    1. Navegar para o Grupo de Segurança de Rede
    2. Clique em Regras de Segurança de Saída
    3. Adicione uma regra a Negar todo o Acesso de saída à Internet.
    4. Adicione uma regra para Permitir o acesso ao AzureCloud, com prioridade inferior à prioridade da regra para negar todo o acesso à Internet.

    As regras de segurança de saída teriam o seguinte aspeto:

    Ligação de saída com o Segundo Balanceador de Carga com IP público

    Para obter mais informações sobre grupos de segurança de Rede do Azure, veja Grupos de Segurança .

Opção 2: Azure Firewall para ligações de saída à Internet

Outra opção para alcançar a conectividade de saída para pontos finais públicos, sem permitir a conectividade de entrada à VM a partir de pontos finais públicos, é com Azure Firewall. Azure Firewall é um serviço gerido, com Elevada Disponibilidade incorporada e pode abranger vários Zonas de Disponibilidade.
Também terá de implementar a Rota Definida pelo Utilizador, associada à sub-rede onde as VMs e o balanceador de carga do Azure são implementados, apontando para a firewall do Azure, para encaminhar o tráfego através do Azure Firewall.
Para obter detalhes sobre como implementar Azure Firewall, veja Implementar e Configurar Azure Firewall.

A arquitetura teria o seguinte aspeto:

Ligação de saída com Azure Firewall

Considerações importantes

  • O Azure Firewall é um serviço nativo da cloud, com Elevada Disponibilidade incorporada e suporta a implementação zonal.
  • Requer sub-rede adicional com o nome AzureFirewallSubnet.
  • Se a transferência de conjuntos de dados grandes sair da rede virtual onde estão localizadas as VMs SAP, para uma VM noutra rede virtual ou para um ponto final público, poderá não ser uma solução económica. Um desses exemplos é copiar cópias de segurança grandes em redes virtuais. Para obter detalhes, veja Azure Firewall preços.
  • Se a solução de Firewall empresarial não for Azure Firewall e tiver requisitos de segurança para que todo o tráfego de saída passe apesar da solução empresarial centralizada, esta solução poderá não ser prática.

Dica

Sempre que possível, utilize as Etiquetas de serviço para reduzir a complexidade das regras de Azure Firewall.

Passos da implementação

  1. Os passos de implementação partem do princípio de que já tem a Rede virtual e a sub-rede definidas para as suas VMs.

  2. Crie a Sub-rede AzureFirewallSubnet na mesma Rede Virtual, onde o VMS e o Balanceador de Carga Standard são implementados.

    1. Em portal do Azure, navegue para o Rede Virtual: Clique em Todos os Recursos, Procure o Rede Virtual, Clique no Rede Virtual, Selecione Sub-redes.
    2. Clique em Adicionar Sub-rede. Introduza AzureFirewallSubnet como Nome. Introduza o Intervalo de Endereços adequado. Guarde.

  3. Criar Azure Firewall.

    1. Em portal do Azure selecione Todos os recursos, clique em Adicionar, Firewall, Criar. Selecione Grupo de recursos (selecione o mesmo grupo de recursos, onde está o Rede Virtual).
    2. Introduza o nome do recurso Azure Firewall. Por exemplo, MyAzureFirewall.
    3. Selecione Região e selecione, pelo menos, duas Zonas de disponibilidade, alinhadas com as Zonas de disponibilidade onde as VMs estão implementadas.
    4. Selecione a sua Rede Virtual, onde estão implementadas as VMs SAP e o Balanceador de Carga Standard do Azure.
    5. Endereço IP Público: clique em criar e introduza um nome. Por exemplo , MyFirewallPublicIP.

  4. Crie Azure Firewall Regra para permitir a conectividade de saída a pontos finais públicos especificados. O exemplo mostra como permitir o acesso ao ponto final público da API de Gestão do Azure.

    1. Selecione Regras, Coleção de Regras de Rede e, em seguida, clique em Adicionar coleção de regras de rede.
    2. Nome: MyOutboundRule, introduza Prioridade, selecione Ação Permitir.
    3. Serviço: nome paraAzureAPI. Protocolo: selecione Qualquer. Endereço de Origem: introduza o intervalo da sub-rede, onde as VMs e Balanceador de Carga Standard são implementadas por exemplo: 11.97.0.0/24. Portas de destino: introduza *.
    4. Guardar
    5. Como ainda está posicionado no Azure Firewall, selecione Descrição Geral. Anote o Endereço IP Privado do Azure Firewall.

  5. Criar rota para Azure Firewall

    1. Em portal do Azure selecione Todos os recursos e, em seguida, clique em Adicionar, Tabela de Rotas, Criar.
    2. Introduza Nome MyRouteTable, selecione Subscrição, Grupo de recursos e Localização (correspondendo à localização da rede virtual e da Firewall).
    3. Guardar

    A regra de firewall teria o seguinte aspeto: diagrama que mostra o aspeto da firewall.

  6. Crie a Rota Definida pelo Utilizador a partir da sub-rede das suas VMs para o IP privado de MyAzureFirewall.

    1. À medida que estiver posicionado na Tabela de Rotas, clique em Rotas. Selecione Adicionar.
    2. Nome da rota: ToMyAzureFirewall, Prefixo de endereço: 0.0.0.0/0. Tipo de salto seguinte: selecione Aplicação Virtual. Endereço do próximo salto: introduza o endereço IP privado da firewall que configurou: 11.97.1.4.
    3. Guardar

Opção 3: Utilizar o Proxy para chamadas do Pacemaker à API de Gestão do Azure

Pode utilizar o proxy para permitir chamadas do Pacemaker para o ponto final público da API de gestão do Azure.

Considerações importantes

  • Se já existir um proxy empresarial implementado, pode encaminhar chamadas de saída para pontos finais públicos através do mesmo. As chamadas de saída para pontos finais públicos passarão pelo ponto de controlo empresarial.
  • Confirme que a configuração do proxy permite a conectividade de saída à API de gestão do Azure: https://management.azure.com e https://login.microsoftonline.com
  • Confirme que existe uma rota das VMs para o Proxy
  • O proxy processará apenas chamadas HTTP/HTTPS. Se for necessário fazer chamadas de saída para o ponto final público através de protocolos diferentes (como RFC), será necessária uma solução alternativa
  • A solução Proxy tem de estar altamente disponível, para evitar instabilidade no cluster do Pacemaker
  • Dependendo da localização do proxy, pode introduzir latência adicional nas chamadas do Agente do Azure Fence para a API de Gestão do Azure. Se o proxy empresarial ainda estiver no local, enquanto o cluster do Pacemaker estiver no Azure, meça a latência e considere se esta solução é adequada para si
  • Se ainda não existir um proxy empresarial de elevada disponibilidade, não recomendamos esta opção, uma vez que o cliente estaria a incorrer em custos e complexidade adicionais. No entanto, se decidir implementar uma solução de proxy adicional, com o objetivo de permitir a conectividade de saída do Pacemaker para a API pública da Gestão do Azure, confirme que o proxy está altamente disponível e que a latência das VMs para o proxy é baixa.

Configuração do Pacemaker com o Proxy

Existem muitas opções de Proxy diferentes disponíveis no setor. As instruções passo a passo para a implementação do proxy estão fora do âmbito deste documento. No exemplo abaixo, partimos do princípio de que o proxy está a responder a MyProxyService e a escutar a porta MyProxyPort.
Para permitir que o pacemaker comunique com a API de gestão do Azure, execute os seguintes passos em todos os nós de cluster:

  1. Edite o ficheiro de configuração do pacemaker /etc/sysconfig/pacemaker e adicione as seguintes linhas (todos os nós de cluster):

    sudo vi /etc/sysconfig/pacemaker
# Add the following lines
http_proxy=http://MyProxyService:MyProxyPort
https_proxy=http://MyProxyService:MyProxyPort

  2. Reinicie o serviço pacemaker em todos os nós de cluster.

  • SUSE

    # Place the cluster in maintenance mode
sudo crm configure property maintenance-mode=true
#Restart on all nodes
sudo systemctl restart pacemaker
# Take the cluster out of maintenance mode
sudo crm configure property maintenance-mode=false

  • Red Hat

    # Place the cluster in maintenance mode
sudo pcs property set maintenance-mode=true
#Restart on all nodes
sudo systemctl restart pacemaker
# Take the cluster out of maintenance mode
sudo pcs property set maintenance-mode=false

Outras opções

Se o tráfego de saída for encaminhado através de terceiros, o proxy de firewall baseado em URL:

  • Se utilizar o agente do Azure Fence, confirme que a configuração da firewall permite a conectividade de saída à API de gestão do Azure: https://management.azure.com e https://login.microsoftonline.com
  • se estiver a utilizar a infraestrutura de atualização da cloud pública do Azure do SUSE para aplicar atualizações e patches, veja Infraestrutura de Atualização da Cloud Pública do Azure 101

Passos seguintes