Un pizzico di nostalgia mi porta su queste pagine e risveglia un torpore di scrittura che andava avanti ormai da un po’ troppo tempo. Messi da parte i giorni delle intrepide (come lo stambecco ubuntiano) avventure libanesi, le guide da paladino della giustizia e i consigli da “mi manda raitre”, mi ributto a capofitto su ciò che mi viene meglio: raccontare il “come si fa” quotidiano di chi, incidentalmente, si diletta a fare il mio stesso mestiere.

La guida che leggerete è sicuramente particolare, quantomeno interessante e difficile da trovare in lingua italiana: questi i motivi per cui mi decido a scriverla.
L’architettura che andremo a realizzare è basata su Squid, il popolare proxy-cache server opensource, e vedremo come questo potentissimo amico riesce a dare il meglio di se e a stupire anche nelle architetture più complesse. L’obiettivo, infatti, è quello di installare un sistema di proxy-caching distribuito in parent-child configuration, integrando l’oggetto “child” con un antiviral engine proprietario come Symantec Scan Engine, e con un sistema di autenticazione ldap-based. Ma andiamo con ordine.

Bookmark It

Leggo sul forum di CentOs a questo indirizzo una guida che mi è stata molto utile e che riporto in italiano aggiornata e corretta sul mio blog. L’oggetto del contendere è come “trasformare” la vostra Red Hat Enterprise Linux 5 in una CentOs 5.

Prima di procedere rispondiamo innanzitutto ad alcune domande come ad esempio “Cos’è CentOs, in cosa si differenzia dall’enterprise Red Hat e soprattutto perchè dovremo trovarci di fronte ad una tale necessità.

Bookmark It

In questo documento vedremo come effettuare load balancing su tomcat utilizzando il nuovo mod_proxy_balancer di Apache HTTPD 2.2. Si da per scontato che il lettore abbia un minimo di familiarità con i prodotti Apache Httpd e Apache Tomcat, e con il concetto di clustering e, di conseguenza, di bilanciamento di carico.

Bookmark It

Allora il punto era questo.

Ho un server fisico supermegacarrozzato dove ci infilo le macchine virtuali che mi chiedono continuamente. L’ultima richiesta era fantastica:

Ci servono 2 virtual machines per comporre un cluster, e altre tre per comporre un altro cluster. Fai te, basta che ce le metti a disposizione.

Guardo gli ip address statici a disposizione e…mmm…mi sa che non bastano…o se bastano li finisco…e se li finisco poi sono cavoli. E poi come lo simuli per benino un cluster in questa maniera?

E allora l’ingegno, l’aiuto del fido xen e la potenza di Linux mi hanno risolto il problema.

Ho creato le cinque macchine virtuali, con indirizzi di rete interna in classe 192.168.1.0/24. Sulla macchina host ho aggiunto due indirizzi statici su due interfacce virtuali in eth0 (eth0:1 e eth0:2 per capirci) e sull’eth1 del server (interfaccia fisica si intende) ho messo un indirizzo della stessa sottoclasse delle vm.

Una volta startate, le virtuali erano in sottorete con la macchina host. Quindi un solo indirizzo ip statico settato fisicamente su una eth virtuale del server host, diventava una specie di Virtual-IP perfetto per i rispettivi nodi del rispettivo cluster. Fantastico.

A quel punto era necessario dare accesso ai ragazzi alle macchine virtuali…e come fare? Vabbè domanda scema e risposta semplice: un paio di dnat facevano al caso mio. Più o meno scrivendo questo per cluster a due nodi:

iptables -t nat -A PREROUTING -i eth0 -d XXX.XXX.XXX.XXX -p tcp -m tcp –dport 22 -j DNAT –to-destination 192.168.1.2
iptables -t nat -A PREROUTING -i eth0 -d XXX.XXX.XXX.XXX -p tcp -m tcp –dport 222 -j DNAT –to-destination 192.168.1.3

e questo per il cluster a tre nodi:

iptables -t nat -A PREROUTING -i eth0 -d YYY.YYY.YYY.YYY -p tcp -m tcp –dport 22 -j DNAT –to-destination 192.168.1.12
iptables -t nat -A PREROUTING -i eth0 -d YYY.YYY.YYY.YYY -p tcp -m tcp –dport 222 -j DNAT –to-destination 192.168.1.13
iptables -t nat -A PREROUTING -i eth0 -d YYY.YYY.YYY.YYY -p tcp -m tcp –dport 2222 -j DNAT –to-destination 192.168.1.14

Questo per portare l’accesso ssh sulle macchine di backend passando dai rispettivi ip statici ai nodi in rete “interna”, ovviamente dopo aver abilitato il listening dell’ssh anche sulle porte interessate dal destination nat.

Difficile? Ma no! semplicissimo e molto divertente!!!

Bookmark It