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.