Azure Application Gateway

Paco Sepulveda
AWS
July 5, 2020

In un post precedente, abbiamo parlato di Azure Load Balancer: http://azurebrains.com/2019/02/07/azure-load-balancer/ come strumento per distribuire richieste tra più macchine virtuali o servizi di Azure.

 

Azure Load Balancer può distribuire il carico usando sia gli indirizzi IP di origine/destinazione sia le porte. D'altra parte, Azure Application Gateway è in grado di distribuire il carico in base ai 7 livelli del modello OSI. Con questo, saremo in grado, ad esempio, di distribuire il carico in base all'URL di destinazione delle richieste.

Di seguito possiamo vedere un diagramma di questa funzionalità:

 

 

Dietro il nostro gateway applicazione, abbiamo due server Web che forniscono pagine diverse. Il primo per il dominio "Adatum" e il secondo per il dominio "Contoso". Application Gateway ha un unico indirizzo IP pubblico sul quale riceverà le richieste dei client. La richiesta verrà inviata al server Adatum o al server Contoso in base alle regole definite.

 

Azure Application Gateway include anche funzionalità come: terminazione SSL o WAF (Web Application Firewall), di cui parleremo in diversi post.

 

Questa volta implementeremo una struttura come quella mostrata nel diagramma precedente, su cui avremo 2 server Web (istanze di Ubuntu Virtual Machines con Apache installato), che faranno parte del back-end di Application Gateway. Creeremo le regole richieste in modo da presentare una petizione a www.adatum.com, verrà inviato al Server 1 e al momento della presentazione di una petizione a www.contoso.com, la petizione verrà invece inviata al Server 2.

Abbiamo già un gruppo di risorse chiamato RG-AppGW e due macchine virtuali Ubuntu.

Su queste macchine virtuali (macchine virtuali) abbiamo già installato Apache e personalizzato il file index.html.

 

Sulla stessa rete virtuale su cui stiamo distribuendo l'infrastruttura, creeremo una sottorete che verrà utilizzata dal gateway applicazione, un intervallo di 28 bit è sufficiente per questo.


Quindi, possiamo procedere alla creazione del gateway applicazione. Nel farlo troveremo 4 diverse opzioni: Standard, Standard V2, WAF e WAF V2.

Gli SKU V2 hanno funzionalità come il ridimensionamento automatico, la ridondanza tra più zone di disponibilità, i miglioramenti delle prestazioni tra gli altri che possiamo verificare sul seguente link: https://docs.microsoft.com/en-us/azure/application-gateway/application-gateway-autoscaling-zone-redundant

Inoltre, la modalità di fatturazione con gli elementi v2 è stata modificata; ora, non dipende dalla quantità di istanze o dalle sue dimensioni, ma dal suo utilizzo.

Sulla regione che useremo per fare le nostre implementazioni i prezzi sono:

 

 

Dove ogni unità di capacità equivale a 50 connessioni al secondo con un certificato RSA TLS a 2048 bit o 2500 connessioni persistenti con una larghezza di banda di 2,22 Mbps ciascuna.

 

 

 Creeremo il gateway applicazione con le seguenti impostazioni:

Seleziona Pubblico come tipo di indirizzo IP con frontend.

Successivamente, aggiungiamo Server 1 come nostro primo target back-end.

Quindi Server 2 come secondo target:


Finiremo con questo:

E aggiungiamo le regole necessarie per la distribuzione del traffico:

Aggiungiamo una regola per www.adatum.com:

Impostiamo il tipo di listener come: "Siti multipli" perché ospiteremo sia adatum.com che contoso.com dietro il Gateway.

 

Quindi definiamo un'impostazione HTTP per questa regola:

Insieme a una destinazione back-end, ovvero Server 1 in questo caso:

Facciamo lo stesso per Server 2:

 

Fatto ciò, saremo in grado di distribuire Application Gateway, che richiederà un paio di minuti.

Al fine di verificare il corretto funzionamento delle regole e poiché non possediamo né i domini adatum.com né contoso.com per reindirizzarli al nostro gateway applicazione, possiamo modificare il nostro file hosts. Se disponiamo di un computer Windows, dobbiamo modificare il file in% systemroot% \ System32 \ drivers \ etc, quindi aggiungeremo le righe successive sostituendo l'IP con quella del nostro gateway applicazione.

 

In questo modo, possiamo essere sicuri che il traffico verrà reindirizzato al server back-end corretto in base all'URL della richiesta:

Possiamo anche monitorare l'attività di bilanciamento del carico delle applicazioni.

 

 

Translated by Josué Padilla.


Paco Sepulveda

En febrero hará 19 años que trabajo como consultor y formador freelance.

Actualmente soy responsable de redes y seguridad en una empresa que ofrece servicios de telemedicina para los hospitales de la Comunidad de Madrid y para el Ejército y la Armada. Para esta empresa he implementado toda la infraestructura cloud.

Trabajo por las mañanas impartiendoel MCSE de Azure en Tajamar y también imparto ocasionalmente formación a medida para empresas en arquitectura de sistemas, redes y seguridad.

Tengo las siguientes certificaciones:

– LPIC-1 y LPIC-2

– ITIL v3 Foundation

– Cisco CCAI, CCNA, CCNP e IINS

– Microsoft: MCT, MCSE Cloud Platform and Infrastructure, MCSA Windows Server 2012 y 2016, MCSE Private Cloud.

La primera certificación de Microsoft la obtuve en 2009 con el MCSE Windows Server 2003 y después el MCITP Windows Server 2008.

Related Posts

Newsletter ItalyClouds.com

Thank you! Your submission has been received!

Oops! Something went wrong while submitting the form