Connettività degli endpoint pubblici per le macchine virtuali usando Load Balancer Standard di Azure negli scenari a disponibilità elevata SAP

  • Articolo

L'obiettivo di questo articolo è quello di descrivere le configurazioni che consentiranno la connettività in uscita agli endpoint pubblici. Le configurazioni saranno principalmente nel contesto della disponibilità elevata con Pacemaker per SUSE/RHEL.

Se si usa Pacemaker con l'agente di isolamento di Azure in una soluzione a disponibilità elevata, le macchine virtuali dovranno avere connettività in uscita all'API di gestione di Azure. Questo articolo presenta varie opzioni per poter scegliere quella più adatta allo scenario in uso.

Panoramica

Quando si implementa disponibilità elevata per soluzioni SAP tramite il clustering, uno dei componenti necessari è Azure Load Balancer. Azure offre due SKU di Load Balancer: Standard e Basic.

Azure Load Balancer Standard offre alcuni vantaggi rispetto a Load Balancer Basic. Può essere usato, ad esempio, in più zone di disponibilità di Azure, offre funzionalità di monitoraggio e registrazione migliori per semplificare la risoluzione dei problemi e presenta una latenza ridotta. La funzionalità "porte a disponibilità elevata", inoltre, copre tutte le porte, eliminando la necessità di elencare ogni singola porta.

Esistono alcune differenze importanti tra lo SKU Basic e lo SKU Standard di Azure Load Balancer, la prima delle quali è la gestione del traffico in uscita verso l'endpoint pubblico. Per un'analisi comparativa completa tra lo SKU Basic e lo SKU Standard di Load Balancer, vedere Confronto tra gli SKU di Load Balancer.

Se vengono inserite macchine virtuali senza indirizzi IP pubblici nel pool back-end di Load Balancer Standard interno ad Azure (nessun indirizzo IP pubblico), non sarà presente alcuna connettività in uscita verso gli endpoint pubblici, a meno che non venga eseguita una configurazione aggiuntiva.

Se a una macchina virtuale viene assegnato un indirizzo IP pubblico o se la macchina virtuale si trova nel pool back-end di un'istanza di Load Balancer con indirizzo IP pubblico, sarà presente invece connettività in uscita verso gli endpoint pubblici.

I sistemi SAP contengono spesso dati aziendali riservati. È raramente accettabile che le macchine virtuali che ospitano sistemi SAP siano accessibili tramite indirizzi IP pubblici. Al tempo stesso, tuttavia, esistono scenari in cui è necessaria la connettività in uscita dalla macchina virtuale verso endpoint pubblici.

Tra gli scenari che richiedono l'accesso a un endpoint pubblico di Azure è possibile includere, ad esempio:

  • L'agente di isolamento di Azure richiede l'accesso a management.azure.com e login.microsoftonline.com
  • Azure Backup
  • Azure Site Recovery
  • Uso del repository pubblico per l'applicazione di patch al sistema operativo
  • Flusso di dati di un'applicazione SAP, che può richiedere la connettività in uscita a un endpoint pubblico

Se la distribuzione SAP in uso non richiede la connettività in uscita verso endpoint pubblici, non è necessario implementare alcuna configurazione aggiuntiva. È sufficiente creare un'istanza di SKU Azure Load Balancer Standard interno per lo scenario di disponibilità elevata da gestire, supponendo che non sia necessaria connettività in ingresso dagli endpoint pubblici.

Nota

Se vengono inserite macchine virtuali senza indirizzi IP pubblici nel pool back-end di Load Balancer Standard interno ad Azure (nessun indirizzo IP pubblico), non sarà presente alcuna connettività Internet in uscita, a meno che non venga eseguita una configurazione aggiuntiva per consentire il routing a endpoint pubblici.
Se invece le macchine virtuali hanno indirizzi IP pubblici o si trovano già nel pool back-end di Azure Load Balancer con indirizzo IP pubblico, sarà già presente connettività in uscita verso endpoint pubblici.

Leggere prima i documenti seguenti:

Opzione 1: Azure Load Balancer Standard esterno aggiuntivo per le connessioni in uscita a Internet

Per ottenere connettività in uscita verso endpoint pubblici senza consentire connettività in ingresso alle macchine virtuali da un endpoint pubblico, è possibile creare una seconda istanza di Load Balancer con indirizzo IP pubblico, aggiungere le macchine virtuali al pool back-end della seconda istanza e definire solo regole in uscita.
Usare Gruppi di sicurezza di rete per controllare gli endpoint pubblici accessibili per chiamate in uscita dalla macchina virtuale.
Per altre informazioni, vedere lo Scenario 2 nel documento Connessioni in uscita.
La configurazione avrà un aspetto simile al seguente:

Controllo della connettività verso endpoint pubblici con i gruppi di sicurezza di rete

Considerazioni importanti

  • Per ottenere connettività in uscita a un endpoint pubblico e ottimizzare i costi, è possibile usare un'istanza di Load Balancer pubblico aggiuntiva per più macchine virtuali della stessa subnet.
  • Usare Gruppi di sicurezza di rete per controllare gli endpoint pubblici accessibili dalle macchine virtuali. È possibile assegnare il gruppo di sicurezza di rete alla subnet o a ogni macchina virtuale. Laddove sia possibile, usare Tag di servizio per ridurre la complessità delle regole di sicurezza.
  • Load Balancer Standard di Azure con un indirizzo IP pubblico e regole in uscita consente l'accesso diretto a un endpoint pubblico. Se i requisiti di sicurezza aziendali prevedono che tutto il traffico in uscita passi attraverso una soluzione aziendale centralizzata per il controllo e la registrazione, è possibile che con questo scenario non sia possibile soddisfare tali requisiti.

Suggerimento

Laddove sia possibile, usare Tag di servizio per ridurre la complessità del gruppo di sicurezza di rete.

Passaggi di distribuzione

  1. Crea servizio di bilanciamento del carico

    1. Nel portale di Azure fare clic su Tutte le risorse, Aggiungi e quindi cercare Load Balancer
    2. Fare clic su Crea
    3. Nome di Load Balancer MyPublicILB
    4. Selezionare Pubblico come Tipo e Standard come SKU
    5. Selezionare Crea indirizzo IP pubblico e specificare MyPublicILBFrondEndIP come nome
    6. Per Zona di disponibilità selezionare Con ridondanza della zona
    7. Fare clic su Rivedi e crea e quindi su Crea

  2. Creare il pool back-end MyBackendPoolOfPublicILB e aggiungere le macchine virtuali.

    1. Selezionare la rete virtuale
    2. Selezionare le macchine virtuali e i relativi indirizzi IP e aggiungerli al pool back-end

  3. Creare regole in uscita.

     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. Creare regole del gruppo di sicurezza di rete per limitare l'accesso a specifici endpoint pubblici. Se è già presente un gruppo di sicurezza di rete, è possibile modificarlo. L'esempio seguente illustra come consentire l'accesso all'API di gestione di Azure:

    1. Passare al gruppo di sicurezza di rete
    2. Fare clic su Regole di sicurezza in uscita
    3. Aggiungere una regola per Negare tutti gli accessi in uscita a Internet.
    4. Aggiungere una regola a Consentire l'accesso ad AzureCloud, con priorità inferiore rispetto alla priorità della regola che nega l'accesso a Internet.

    Le regole di sicurezza in uscita avranno un aspetto simile al seguente:

    Connessione in uscita con la seconda istanza di Load Balancer con IP pubblico

    Per altre informazioni sui gruppi di sicurezza di rete di Azure, vedere Gruppi di sicurezza di rete.

Opzione 2: Firewall di Azure per le connessioni in uscita a Internet

Un'altra soluzione per ottenere connettività in uscita a endpoint pubblici, senza consentire la connettività in ingresso alle macchine virtuali da endpoint pubblici, è quella di usare il Firewall di Azure, un servizio gestito con disponibilità elevata predefinita che può estendersi a più zone di disponibilità.
Sarà anche necessario distribuire una route definita dall'utente associata alla subnet in cui sono distribuite le macchine virtuali e Azure Load Balancer che punti al Firewall di Azure, in modo da instradare il traffico attraverso il firewall.
Per informazioni dettagliate su come distribuire il Firewall di Azure, vedere Distribuire e configurare il Firewall di Azure.

L'architettura avrà un aspetto analogo al seguente:

Connessione in uscita con il Firewall di Azure

Considerazioni importanti

  • Il Firewall di Azure è un servizio cloud nativo con disponibilità elevata predefinita e supporto per la distribuzione a livello di zona.
  • Richiede una subnet aggiuntiva che deve essere denominata AzureFirewallSubnet.
  • Se si trasferiscono set di dati di grandi dimensioni in uscita dalla rete virtuale in cui si trovano le macchine virtuali SAP verso una macchina virtuale che si trova in un'altra rete virtuale o in un endpoint pubblico, potrebbe non essere una soluzione conveniente. Uno scenario di questo tipo può essere, ad esempio, la copia di backup di grandi dimensioni su reti virtuali diverse. Per informazioni dettagliate, vedere Prezzi del servizio Firewall di Azure.
  • Se la soluzione firewall aziendale non è il servizio Firewall di Azure e i requisiti di sicurezza aziendali prevedono che tutto il traffico in uscita passi attraverso una soluzione aziendale centralizzata, questa soluzione potrebbe non essere pratica.

Suggerimento

Laddove sia possibile, usare Tag di servizio per ridurre la complessità delle regole del Firewall di Azure.

Passaggi di distribuzione

  1. La procedura di distribuzione presuppone che sia già stata definita la rete virtuale e la subnet per le macchine virtuali.

  2. Creare una subnet AzureFirewallSubnet nella stessa rete virtuale in cui sono distribuite le macchine virtuali e Load Balancer Standard.

    1. Nel portale di Azure passare alla rete virtuale: Fare clic su Tutte le risorse, cercare la rete virtuale, fare clic sulla rete virtuale e selezionare Subnet.
    2. Fare clic su Aggiungi subnet. Specificare AzureFirewallSubnet come nome. Immettere l'intervallo di indirizzi appropriato. Salvare.

  3. Creare il servizio Firewall di Azure.

    1. Nel portale di Azure selezionare Tutte le risorse e fare clic su Aggiungi, Firewall, Crea. Selezionare Gruppo di risorse (selezionare lo stesso gruppo di risorse in cui si trova la rete virtuale).
    2. Immettere il nome per la risorsa Firewall di Azure, ad esempio MyAzureFirewall.
    3. Selezionare Area di Azure e almeno due zone di disponibilità, allineate con le zone di disponibilità in cui sono distribuite le macchine virtuali.
    4. Selezionare la rete virtuale in cui sono distribuite le macchine virtuali SAP e Load Balancer Standard di Azure.
    5. Indirizzo IP pubblico: Fare clic su Crea e immettere un nome, ad esempio MyFirewallPublicIP.

  4. Creare una regola del Firewall di Azure per consentire la connettività in uscita verso specifici endpoint pubblici. L'esempio seguente illustra come consentire all'API di gestione di Azure di accedere a un endpoint pubblico.

    1. Selezionare Regole, Raccolta regole di rete e fare clic su Aggiungi raccolta regole di rete.
    2. Nome: MyOutboundRule, specificare la priorità e selezionare l'azione Consenti.
    3. Servizio: Nome ToAzureAPI. Protocollo: selezionare Tutti. Indirizzo di origine: immettere l'intervallo per la subnet, in cui vengono distribuite le macchine virtuali e Load Balancer Standard ad esempio: 11.97.0.0/24. Porte di destinazione: digitare *.
    4. Salvare
    5. Quando si è ancora all'interno del servizio Firewall di Azure, selezionare Panoramica. Prendere nota dell'indirizzo IP privato del Firewall di Azure.

  5. Creare una route al Firewall di Azure

    1. Nel portale di Azure selezionare Tutte le risorse e fare clic su Aggiungi, Tabella di routing, Crea.
    2. Immettere il nome MyRouteTable e selezionare la sottoscrizione, il gruppo di risorse e il percorso (corrispondente al percorso della rete virtuale e del firewall).
    3. Salvare

    La regola del firewall sarà simile al diagramma che mostra l'aspetto del firewall.

  6. Creare una route definita dall'utente dalla subnet delle macchine virtuali all'indirizzo IP privato di MyAzureFirewall.

    1. Dalla tabella di routing fare clic su Route. Selezionare Aggiungi.
    2. Nome della route: ToMyAzureFirewall; prefisso dell'indirizzo: 0.0.0.0/0. Tipo hop successivo: selezionare Appliance virtuale. Indirizzo hop successivo: immettere l'indirizzo IP privato del firewall configurato: 11.97.1.4.
    3. Salvare

Opzione 3: Uso di proxy per le chiamate Pacemaker all'API di gestione di Azure

È possibile usare il proxy per consentire chiamate di Pacemaker all'endpoint pubblico dell'API di gestione di Azure.

Considerazioni importanti

  • Se è già presente un proxy aziendale, è possibile usarlo per instradare le chiamate in uscita verso gli endpoint pubblici. In questo modo, le chiamate in uscita verso endpoint pubblici passeranno attraverso il punto di controllo aziendale.
  • Assicurarsi che la configurazione del proxy consenta la connettività in uscita all'API di gestione di Azure: https://management.azure.com e https://login.microsoftonline.com
  • Verificare che sia presente una route dalle macchine virtuali al proxy
  • Il proxy gestirà solo chiamate HTTP/HTTPS. Se le chiamate in uscita a endpoint pubblici dovranno essere eseguite attraverso protocolli diversi, ad esempio RFC, sarà necessaria una soluzione alternativa
  • La soluzione proxy deve essere a disponibilità elevata per evitare instabilità nel cluster Pacemaker
  • A seconda della posizione del proxy, è possibile che venga introdotta latenza aggiuntiva nelle chiamate dall'agente di isolamento di Azure all'API di gestione di Azure. Se il proxy aziendale è ancora in locale, mentre il cluster Pacemaker si trova in Azure, misurare la latenza e valutare se questa soluzione è adatta alle proprie esigenze
  • Se non è già disponibile un proxy aziendale a disponibilità elevata, questa opzione non è consigliata perché il cliente potrebbe dover sostenere complessità e costi aggiuntivi. Tuttavia, se si decide di distribuire una soluzione proxy aggiuntiva per consentire la connettività in uscita da Pacemaker all'API pubblica di gestione di Azure, assicurarsi che il proxy sia a disponibilità elevata e che la latenza dalle macchine virtuali al proxy sia bassa.

Configurazione di Pacemaker con un proxy

Sono disponibili molte soluzioni proxy sul mercato. Istruzioni dettagliate per la distribuzione del proxy esulano quindi dall'ambito di questo documento. Nell'esempio seguente si presuppone che il proxy stia rispondendo a MyProxyService e ascoltando la porta MyProxyPort.
Per consentire a Pacemaker di comunicare con l'API di gestione di Azure, seguire questa procedura in tutti i nodi del cluster:

  1. Modificare il file di configurazione di Pacemaker /etc/sysconfig/pacemaker e aggiungere le righe seguenti (tutti i nodi del cluster):

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

  2. Riavviare il servizio Pacemaker in tutti i nodi del 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

Altre opzioni

Se il traffico in uscita viene instradato tramite proxy firewall basato su URL di terze parti:

  • se si usa l'agente di recinzione di Azure assicurarsi che la configurazione del firewall consenta la connettività in uscita all'API di gestione di Azure: https://management.azure.com e https://login.microsoftonline.com
  • se si usa l'infrastruttura di aggiornamento cloud pubblico di Azure per l'applicazione di aggiornamenti e patch, vedere Infrastruttura di aggiornamento cloud pubblico di Azure 101

Passaggi successivi