Bilanciare numerosi View Connection Servers con HAProxy

0 Flares Twitter 0 Facebook 0 LinkedIn 0 Email -- 0 Flares ×

Quando siamo in presenza di installazioni medio-grandi, è possibile distribuire il carico di lavoro sui VMware View Connection Server aggiungendone di ulteriori grazie al ruolo “Replica”. Tuttavia, il bilanciamento o il failover tra di essi non è direttamente disponibile nel software. Per distribuire i client View tra i vari server, è necessario utilizzare un bilanciatore esterno.

VMware ha il suo modo di realizzare il bilanciamento, utilizzando le funzioni di balancing di VCNS (VMware vCloud Networking & Security, precedentemente noto come vShield Edge). Tuttavia, mi sono sempre trovato più a mio agio con HAProxy. Questo programma usa una quantità minima di memoria, e possiede funzioni interessantissimi come SSL offloading, differenti algoritmi di bilanciamento e altro ancora.

HAProxy può essere eseguito su una singola macchina linux, per bilanciare differenti server alle sue spalle, ma per configurazioni in alta disponibilità ovviamente è necessario utilizzare almeno 2 nodi, con un indirizzo IP virtuale che verrà gestito da un altro grande programma, Keepalived. Per le mie installazioni, uso solitamente CentOS 6, quindi questo tutorial sarà basato su questa distribuzione linux. La rete d’esempio prevede queste macchine e indirizzi IP:

hostnameIP AddressNote
lb1.domain.local192.168.1.162Load Balancer 1, master
lb2.domain.local192.168.1.163Load Balancer 2, slave
view.domain.local192.168.1.170Virtual IP gestito dai balancers
view01.domain.local192.168.1.165View Connection Server
view02.domain.local192.168.1.166View Connection Server (Replica)

HAProxy può operare sia con 1 o più connessioni di rete, in questo esempio tutti i server saranno connessi alla stessa rete.

Per prima cosa, dobbiamo attivare il repository Extra Packages for Enterprise Linux (EPEL), che contiene i pacchetti per HAProxy e Keepalived. Installiamo le info su EPEL in YUM:

e installiamo HAproxy e Keepalived:

Editiamo la configurazione di Keepalived in modo che assomigli alla seguente:

 

Una rapida spiegazione dei parametri principali che vedete qui:

  • Keepalived utilizza VRRP per gestire l’indirizzo IP virtuali condiviso dai balancers. VRRP è un sistema attivo/passivo, quindi in un dato momento il virtual IP è in ascolto su un solo balancer. Questo rende l’uso di Keepalived più “network friendly”, evitando configurazioni dedicate su switches o routers
  • la configurazione vera e propria di VRRP è contenuta in uno script di controllo che verifica lo stato di HAProxy; questo è vitale per avere una configurazione funzionante. Non c’è utilità infatti nell’avere il virtual IP in ascolto su un balancer dove per qualche motivo HAProxy è morto. Quindi, se il controllo di HAProxy dovesse fallire, lo script sposterà il virtual IP all’altro balancer, dove HAProxy è in esecuzione.
  • La priorità sarà impostata a 101 sul nodo master, e 100 su tutti gli slaves. Ricordatevi di cambiare questo parametro quando copiate la configurazione sui nodi slaves.
  • Per proteggere la comunicazione tra i nodi, è meglio utilizzare una password. Questa chiave pre-condivisa dovrà essere impostata uguale su tutti i balancers.
Prima di poter caricare il virtual IP e testarlo, ci sono alcune ulteriori configurazioni da fare. Per prima cosa, aggiungete questa riga in fondo al file /etc/sysctl.conf:

e applicate il nuovo parametro eseguendo:

Dobbiamo poi aggiungere delle configurazioni su iptables, abilitando in particolare il supporto per il multicast broadcast:

Quindi, una regola per il protocollo VRRP:

In aggiunta, aggiungeremo le regole corrispondenti per il traffico che vogliamo bilanciare. Per View ho inserito HTTP e HTTPS (tecnicamente è necessario solo https, ma creeremo una regola in HAProxy per redirigere le chiamate http verso https):

finalmente, possiamo salvare la configurazione di iptables in modo che venga riapplicata ad ogniriavvio, e avviamo Keepalived:

Una volta configurati tutti i balancers, possiamo vedere il virtual IP in ascolto sul nodo master:

Se eseguiamo lo stesso comando su un nodo slave, vedremo solo l’IP fisico di quel nodo. Potete testare facilmente il virtual IP: iniziate a pingarlo, e arrestate il servizio keepalived sul nodo master. Potreste vedere un ping perso (a seconda della velocità dell’infrastruttura di rete sottostante), dopodichè le risposte ai ping ricominceranno ad arrivare dal nodo slave. Una volta riavviato il master, questo riprenderà il controllo del virtual IP.

Bene! Passiamo ora alla configurazione di HAProxy:

Guardiamo in dettaglio le ultime tre sezioni, dato che la parte precedente sono configurazioni generali:

  • “frontend unsecured” è un semplice redirect, intercetta ogni tentativo di connessione su porta 80 (http) e la redirige su porta 443 (https). In questo modo anche gli utenti svogliati che dimenticano di scrivere https nell’url avranno una connessione corretta invece di un errore 404.
  • “frontend secured” è il vero frontend. E’ in ascolto sul virtual IP, sulla porta 443. Se voleste utilizzare un certificato SSL per l’hostname “view.domain.local”, potete utilizzare OpenSSL per creare una certificate request, e una volta ottenuto il certificato sotto forma di file PEM, salvarlo su entrambi i balancers e togliere il commento per abilitarne l’uso
  • backend “view” contiene le configurazioni dei server bilanciati. Il metodo di bilanciamento è “source”: ogni IP sorgente verrà sempre indirizzato verso lo stesso Connection Server fintanto che quello stesso Connection Server sarà attivo (il parametro “check port 443” è usato proprio per verificare che View sia in ascolto). Source è una buona configurazione se si hanno connessioni provenienti da numerosi indirizzi IP, come nel caso dei client View. Fate attenzione se le connessioni dovessero essere instradate da sistemi come NAT o simili, perchè ridurrebbero di molto il numero di IP sorgenti rendendo “source” molto meno efficace.

Una volta che tutto è configurato, rendiamo l’avvio di HAProxy e Keepalived automatico, e avviamo HAProxy:

Saremo in grado adesso di connetterci a https://view.domain.local e vedere uno dei View Connection servers.

4 thoughts on “Bilanciare numerosi View Connection Servers con HAProxy

  1. Salve,
    ottimo articolo molto interessante e Le chiedo il seguenti tre consigli (il mio fine sarebbe di suddividere il carico su 2 connection servers e potersi collegare con lo stesso indirizzo view.dominio.it sia con il dns interno (con ip privato) sia con il dns esterno con ip pubblico):
    1.nella mia situazione ho tutte le VM su un’unica SAN per cui le 2 HAproxy sarebberero 2 VM che se cadono si fermano entrambe nello stesso momento, per cui chiedo se non faccio prima a configurare un solo HAproxy su una VM (senza keepalived). Chiedo un Suo parere.
    2. inoltre avevo pensato ad una architettura del genere:
    VM con security server (con NAT sull’IP pubblico a cui ci si connette con il nome su dns pubblico view.dominio.it) collegato alla VM con HAproxy (alla quale ci si connette con nome http://www.dominio.it configurato con ip privato sul DNS interno alla LAN (AD) ed infine collegate le 2 VM con i 2 connection servers.
    3.con HAproxy è possibile suddividere il carico sui due connection servers? Non solo passare ad un connection in quanto l’altro non è più raggiungibile?
    Grazie in anticipo
    Saluti
    Enrico

    • Salve Enrico,
      1. se tutte le VM sono sulla stessa SAN bisogna mettere in HA tutto lo stack, non solo HAproxy. Anche i connection servers e la san stessa.
      2. non è chiarissimo il disegno, forse è meglio una mail che un post…
      3. ci sono alcune modalità di configurazione per gestire le connessioni in modo bilanciato

      Luca.

  2. Ciao,
    ti faccio anche io i complimenti per l’ottimo ed interessante articolo .
    Solo un dettaglio: come mai hai usato il parametro “check port 443” che controlla se la porta è in ascolto anzichè “ssl-hello-chk” che effettua una verifica più completa?

    Saluti

    Fabio

  3. Perchè non conoscevo questo comando!
    Grazie del suggerimento, lo provo appena posso e nel caso aggiorno l’articolo 🙂

    Luca.

Comments are closed.