apr 292011
 

Uno dei principali problemi con cui un amministratore di server deve combattere è lo spam.
Purtroppo il fenomeno dello spam non è in diminuzione, anzi, e per combatterlo dobbiamo attrezzarci armandoci di infinita pazienza: difatti le regole antispam che un SysAdmin può applicare sono molteplici e scegliere quali applicare è un compromesso che non soddisferà mai la totalità degli utenti.

Un filtro molto utile che porta pochi problemi è il greylist. Questo sistema si basa su un principio ancora valido: lo spammer, per monetizzare, deve avere subito riscontro di quante mail sono arrivate a destinazione, pertanto se una consegna fallisce non sarà più ritentata. In maniera totalmente opposta funzionano i server tradizionali: se il server del destinatario ha un problema temporaneo, il mail server mittente riproverà ad inviare l’email successivamente.

Nella pratica, quando un server su cui funzona il greylisting è attivo riceve una email, viene controllata la “tripletta” formata da email mittente/indirizzo IP mittente/email destinatario per vedere se è la prima volta che accade questo evento. Se è la prima volta, l’email viene respinta con un errore temporaneo e la ricezione rimane bloccata per un tempo predefinito (solitamente 1 minuto), altrimenti, se non è la prima volta e se il minuto di blocco dal primo invio è passato, l’email viene accettata.

Se si hanno più mail server in ricezione (MX) è importantissimo che tutti siano configurati con il greylisting, altrimenti il sistema risulta inefficace. Inoltre tutti i server MX devono utilizzare un unico database per memorizzare le triplette, altrimenti si corre il rischio di continuare a respingere le mail.

Una implementazione del greylisting che soddisfa questi requisiti è sqlgrey: difatti questo sistema memorizza le triplette su un database SQL che pertanto può essere condiviso tra i server MX.

Vediamo come configurare il servizio: nella nostra installazione utilizzeremo un server MySQL centralizzato all’indirizzo mysql.dominio.local e un mirror locale del datatabase configurato come slave con la classica replica MySQL in modo da minimizzare il carico di lavoro sul master. Con questa configurazione tutte le query in scrittura andranno sul master, mentre le query in lettura (più numerose e dispendiose) saranno solo locali.

Innanzi tutto modifichiamo il file di configurazione /etc/sqlgrey/sqlgrey.conf:

/etc/sqlgrey/sqlgrey.conf
reconnect_delay = 5
max_connect_age = 24
awl_age = 32
group_domain_level = 10
db_type = mysql
db_name = sqlgrey
db_host = mysql.dominio.local
db_port = default
db_user = sqlgrey
db_pass = PasswordSQLgrey
db_cluster = on
read_hosts=localhost
db_cleanup_hostname = localhost
admin_mail = server@domino.local
greymethod = classc

Una cosa importante in questa configurazione è il fatto che abbiamo settato il greymethod a classic: è il metodo più tranquillo, in grado di generare il minor numeri di blocchi.
Difatti questo valore può essere settato a full che memorizza l’ip del mittente, classic che memorizza l’intera classe C (/24) e smart che memorizza l’intera classe C se non riesce a fare il reverse lookup. In pratica, così facendo, saremo certi che se un mittente utilizza più server per la spedizione in round robin, non corra il rischio di rimanere bloccato in un “circolo vizioso”

Quindi creiamo il database sul server MySQL:

# mysql -u root -p
mysql> create database sqlgrey ;
mysql> grant all on sqlgrey.* to sqlgrey@'%' identified by 'PasswordSQLgrey';

e la copia locale:

# mysql -u root -p
mysql> create database sqlgrey ;
mysql> grant all on sqlgrey.* to sqlgrey@'localhost' identified by 'PasswordSQLgrey';

Tralascio la configurazione della replica master/slave: in quest’articolo potete trovare le istruzioni per configurare la replica master/master.

Infine modifichiamo il file /etc/postfix/main.cf aggiungendo la seguente riga:

...
smtpd_recipient_restrictions =
....
check_policy_service inet:127.0.0.1:2501,
...

Il mio consiglio è di utilizzare il greylisting come ultimo controllo, lasciando prima quelli più performanti in modo da evitare inutili query sul database.

apr 272011
 

MooseFS è un filesystem  di rete che può essere montato attraverso il protocollo FUSE, con il quale è possibile creare uno storage ridondato e scalabile utilizzando una batteria di “commodity server” (cioè PC senza particolari caratteristiche di potenza).

Il sistema si compone di 3 elementi: il master server che fungerà da proxy e che ha la “mappa” delle posizione di tutti i dati all’interno del cluster, il metalogger server con una copia della “mappa” del server principale che può essere promosso a master in caso di necessità e una serie di “chunk server” che formetanno il vero e proprio storage.

Riguardo all’hardware, è consigliato avere due server robusti sia in termini di tolleranza ai guasti sia in termini di quantità di RAM per il master e il metalogger, mentre i chunk hanno bisogno, ovviamente, solo di parecchio spazio su disco.

In questo howto, installeremo un sistema semplificato formato solamente da un master e un chunk.

Partiamo da una installazione pulita della vostra distribuzione Linux preferita e installate i tools per la compilazione.

Quindi scarichiamo i sorgenti e scompattiamoli:

wget http://pro.hit.gemius.pl/hitredir/id=0sWa0S8ft4sTAHF1bGAAEZPcP3ziyq7f9SdhoQf7oeT.c7/url=moosefs.org/tl_files/mfscode/mfs-1.6.20-2.tar.gz
tar zxvf mfs-1.6.20-2.tar.gz
cd mfs-1.6.20-2

E creiamo un utente per eseguire il demone:

useradd moose

Installazione del master server
Sul master server, per comodità, installeremo anche l’opzione di mount del filesystem, per cui è necessario avere installato FUSE.
Su Gentoo è possibile installare il pacchetto con:

emerge sys-fs/fuse

Ora passiamo alla compilazione dei sorgenti. Innanzi tutto lanciamo il comando configure con le dovute opzioni:

./configure --disable-mfschunkserver --enable-mfsmount --with-default-user=moose --with-default-group=moose

Quindi passiamo alla compilazione vera e propria con:

make && make install

A questo punto il pacchetto è installato in /usr/local in modo da essere isolato dal resto del setup.

E’ necessario creare il file di configurazione /usr/local/etc/mfsmaster.cfg; io sono partito da quello di default.

/usr/local/etc/mfsmaster.cfg
WORKING_USER = moose
WORKING_GROUP = moose
SYSLOG_IDENT = mfsmaster
LOCK_MEMORY = 0
NICE_LEVEL = -19

EXPORTS_FILENAME = /usr/local/etc/mfsexports.cfg

DATA_PATH = /usr/local/var/mfs

BACK_LOGS = 50

REPLICATIONS_DELAY_INIT = 300
REPLICATIONS_DELAY_DISCONNECT = 3600

MATOML_LISTEN_HOST = *
MATOML_LISTEN_PORT = 9419

MATOCS_LISTEN_HOST = *
MATOCS_LISTEN_PORT = 9420

MATOCU_LISTEN_HOST = *
MATOCU_LISTEN_PORT = 9421

CHUNKS_LOOP_TIME = 300
CHUNKS_DEL_LIMIT = 100
CHUNKS_WRITE_REP_LIMIT = 1
CHUNKS_READ_REP_LIMIT = 5

REJECT_OLD_CLIENTS = 0

Inoltre bisogna creare il file con gli export /usr/local/etc/mfsexports.cfg. Io ho semplicemente tutto a tutti in lettura e scrittura:

/usr/local/etc/mfsexports.cfg
*			/	rw,alldirs,maproot=0
*			.	rw

Infine, trattandosi di una nuova installazione, bisogna creare il metadata:

mv /usr/local/var/mfs/metadata.mfs.empty /usr/local/var/mfs/metadata.mfs

A questo punto avviamo il servizio master e la console di stato con:

/usr/local/sbin/mfsmaster
/usr/local/sbin/mfscgiserv

Ricordiamoci di aggiungerlo all’avvio automatico, ad esempo modificando il file rc.local o /etc/conf.d/local.start a seconda della distrinuzione in uso.

Attraverso il servizio mfscgiserv si ha a disposizione una interfaccia web per controllare lo stato del proprio cluster storage. Ecco qui di seguito alcuni screenshot per stuzzicavi l’appetito.

Installazione del Chunk Server
Innanzi tutto formattiamo una partizione del nostro disco e montiamola in una directory dedicata

mke2fs -j /dev/sda4
mount /dev/sda4 /public

Ora passiamo alla compilazione di moose:

./configure --disable-mfsmaster --disable-mfsmount --with-default-user=moose --with-default-group=moose
make
make install

Assegnamo all’utente moose i privilegi di scrittura:

chown -R moose:moose /public

Creiamo il file di configurazione del demone:

/usr/local/etc/mfschunkserver.cfg
WORKING_USER = moose
WORKING_GROUP = moose
SYSLOG_IDENT = mfschunkserver
LOCK_MEMORY = 0
NICE_LEVEL = -19

DATA_PATH = /usr/local/var/mfs

MASTER_RECONNECTION_DELAY = 5

BIND_HOST = *
MASTER_HOST = master
MASTER_PORT = 9420

MASTER_TIMEOUT = 60

CSSERV_LISTEN_HOST = *
CSSERV_LISTEN_PORT = 9422

HDD_CONF_FILENAME = /usr/local/etc/mfshdd.cfg
HDD_TEST_FREQ = 10

e il file mfshdd.cfg con l’elenco dei dischi condivisi:

/usr/local/etc/mfshdd.cfg
/public

e avviamo il demone con:

/usr/local/sbin/mfschunkserver

Dato che sul master abbiamo installato anche il mfsmount, possiamo collaudare il funzionamento montando il disco con:

mfsmount /mnt/moose/ -H 192.168.0.100 -P 9421

Nel prossimo Howto aggiungeremo a questo setup un metalogger server attraverso il quale garantiremo alta affidabilità al master.

apr 262011
 

Pacemaker è un tool in grado di aiutarci nella configurazione e nella gestione di un cluster formato da due o più server. Difatti Pacemaker è un pacchetto in grado di comunicare con i due sistemi di alta affidabilità più diffusi in Linux: Heartbeat e Pacemaker.

In questo articolo abbiamo già analizzato come configurare un cluster utilizzando pacemaker in collaborazione con heartbeat; in quest’articolo, invece, useremo corosync al posto di heartbeat.

Innanzi tutto installiamo pacemaker e corosync sui due server che comporranno il cluster. In questo esempio utilizzerò come distribuzione Gentoo, ma qualsiasi altra va bene.

emerge pacemaker

In Gentoo corosync è una dipendenza di pacemaker, pertanto verrò installato automaticamente.
La configurazione di corosync è all’interno del file /etc/corosync/corosync.conf

/etc/corosync/corosync.conf
compatibility: whitetank

totem {
	version: 2
	secauth: off
	threads: 0
	interface {
		ringnumber: 0
		bindnetaddr: 192.168.0.100 # <------Sostituire l'ip del server
		mcastaddr: 226.94.1.1
		mcastport: 5405
	}
}

logging {
	fileline: off
	to_stderr: no
	to_logfile: yes
	to_syslog: yes
	logfile: /var/log/cluster/corosync.log
	debug: off
	timestamp: on
	logger_subsys {
		subsys: AMF
		debug: off
	}
}

amf {
	mode: disabled
}

aisexec {
    user: root
    group: root
}

service {
    name: pacemaker
    ver: 0
}

Riportiamo questa configurazione sul secondo server, ovviamente modificando l’indirizzo IP e avviamo il demone su entrambi i server:

/etc/init.d/corosync start

Dopo qualche minuto il cluster dovrebbe essere attivo:

crm_mon -1 | grep Online
Online: [ server01 server02 ]

Ora possiamo utilizzare l’interfaccia crm di Pacemaker per creare le risorse condivise.
Innanzi tutto configuriamo i parametri di default:

crm configure
property no-quorum-policy=ignore
property stonith-enabled=false
property default-resource-stickiness=1000
commit
bye

Ora, ad esempio, configuriamo un ip condiviso:

crm configure
primitive lan_ip IPaddr params ip=192.168.0.250 cidr_netmask="255.255.255.0" nic="eth0" op monitor interval="40s" timeout="20s"
commit
bye

Infine settiamo il nodo “master” come preferito:

crm configure
location master_pref lan_ip 100: master
commit
bye
apr 222011
 

Quando si ha a che fare con più server, sicuramente prima o poi nascerà l’esigenza di avere un unico posto dove salvare i propri dati, in modo da poterci accedere contemporaneamente da più server. Questo è uno dei problemi più difficili da affrontare quando si progetta un sistema di server, in quanto esistono moltissimi metodi per arrivare allo scopo ma ciascuno ha le sue peculiarità che lo rendono più o meno adatto ad essere sfruttato in determinate applicazioni.
Diciamo che fare un confronto non è cosa semplice, anche perchè in alcuni casi è possibile avere situazioni ibride di due sistemi concatenati (ad es. NFS su GlusterFS)

NFS
NFS è il sistema di condivisione file classico del modo Unix: è senza ombra di dubbio il più usato, il più conosciuto ed il più semplice da implementare. Per quanto riguarda il funzionamento, il server NFS ha accesso ad uno spazio fisico a blocchi che può essere formattato utilizzando un qualsiasi FileSystem con funzionalità POSIX. Il server NFS ha il compito di gestire l’accesso contemporaneo ai dati contenuti all’interno del dispositivo a blocchi, oltre ovviamente a gestire i permessi utente. I client NFS (gli altri server della rete) potranno montare la directory condivisa (in gergo esportata) come se fosse un disco locale, un po’ come avviene con la condivisione di windows CIFS/SAMBA.
I punti a favore di questo sistema sono senza dubbio la facilità di implementazione, la stabilità del protocollo e, tutto sommato, discrete velocità di rete.
I punti debili di questo sistema sono la totale impossibilità di scalare “on line” aggiungendo nuovo storage nel momento in cui se ne ha la necessità, il fatto di avere un SPoF (Single Point of Failure) costituito dal server NFS che è suscettibile a guasti e che rischia di sovraccaricarsi in maniera considerevole all’aumentare di richieste di rete.

OCFS2 e GFS
OCFS2 e GFS sono due FileSystem concettualemente simili in quanto prevedono nativamente l’accesso contemporaneo ai file: OCFS2 è sviluppato da Oracle mentre GFS2 è sviluppato da RedHat. La teoria di funzionamento è identica: ogni server che ha accesso allo storage deve avere attivo un demone che dialoga continuamente con gli altri server in modo da conoscere esattamente lo stato dello storage. Il disco condiviso viene montato in locale deve essere formattato con il suo filesystem, non è possibile utilizzare un filesystem tradizionale (ext3, xfs, ecc); la cosa interessante è che, trattandosi della formattazione di un disco, questo può essere di qualsiasi tipo, basta che sia accessibile da tutti i server: quindi può essere un disco di rete iSCSI o AoE, ma anche una partizione locale replicata su un secondo server attraverso DRBD8 configurato in modalità Attivo/Attivo o un disco FireWire collegato a più server.
Da un confronto tra i due filesystem, GFS è il più semplice da configurare dato che utilizza i tools di alta affidabilità di RedHat, mentre OCFS2 è più macchinoso. OCFS2 è però nettamente più veloce anche se non supporta le quote in nessun modo (è una delle cose in implementazione).
I maggiori pregi di questo sistema è che non serve un server che faccia da tramite e quindi non si ha un SPoF e le prestazioni sono le migliori in assoluto (specie con OCFS2).
Il difetto principale, deriva direttamente dal pregio: non avendo un server che gestisce la condivisione dei file, ogni nuovo nodo che entra a far parte del cluster comporta un riconfigurazione di tutto il cluster. Anche la scalabilità del sistema è relativa: anche ammettendo di avere un dispositivo di storage che consente di “aggiungere dischi”, è necessario eseguire un resize della partizione con rischi, annessi e connessi.

I figli di FUSE
FUSE è l’acronimo di File System in Userspace ed è un nuovo metodo di utilizzo di dispositivi di rete. Molti filesystem di nuova generazione utilizzano questo sistema per gestire i dischi di rete. L’utilizzo di un ulteriore layer per la comunicazione tra disco e client va nella direzione opposta rispetto all’utilizzo di un filesystem cluster come OCFS2 o GFS, cosa che porta una maggiore flessibilità e stabilità a discapito di una leggera perdita in termini di prestazioni.
Analizziamo due filesystem che fanno affidamento a FUSE: GlusterFS e MooseFS.

GlusterFS
GlusterFS è un filesystem che in questo momento va molto “di moda”. Consente di unire più “commodity computer” per realizzare un cluster di storage server: è possibile realizzare uno stripe (unire lo storage di più server, simile concettualmente al raid 0) o un mirror (avere lo stesso dato copiato su più server, simile concettualmente al RAID 1). Lo storage ove viene creato il filesystem Gluster è, come per NFS, un filesystem comune (EXT3, XFS, ecc,)
Una volta creato lo storage, è possibile accedevi sia utilizzando il protocollo NFS, sia il protocollo CIFS (Samba), sia, come dicevo pocanzi, usando il protocollo nativo attraverso FUSE: questo sistema è quello che garantisce le migliori performance.
Il pregio maggiore di questo protocollo è a mio avviso che non esiste alcun SPoF: tutti i server sono autoritativi allo stesso modo, quando un client monta la partizione attraverso FUSE seve specificare un server, ma poi la comunicazione avviene direttamente con tutto il cluster. Altro pregio è la diffusione: essendo molto diffuso e mantenuto, è anche molto stabile.
Il difetto maggiore a mio avviso è la complessità concettuale: Gluster è formato da tanti layer ciascuno dei quali assove una sua funzione: comprenderli e tarali non è semplicissimo e l’ordinaria manutenzione (aggiungere un nodo ecc.) è spesso fonte di problemi. Le prestazioni del sistema sono buone in lettura se configurato in modalità mirror (le letture possono avvenire contemporaneamente da più nodi), però in scrittura non sono esaltanti.

MooseFS
Operativamente è simile a GlusterFS in quanto condivide FUSE per il montaggio dei dischi in rete, MooseFS è però diverso in quanto a sistema di gestione che lo rende simile a Openstack Swift. In Moose, a differenza di Gluster, i nodi non sono paritetici, ma si compone di un Master Server, un Metalogger server (che può essere promosso a Master in caso di guasto) e di X nodi dati.
Il Master fa da Proxy e conosce esattamente dove sono salvati i dati all’interno dei nodi dati; i dati possono essere replicati su un numero arbitrario di zone in modo da avere sia un sistema tollerante ai guasti sia un sistema di lettura parallelo. Purtroppo, al contrario di OpenStack Swift, anche le scritture avvengono in parallelo, cosa che di fatto lo rende un po’ lento in questo frangente.
Due cose interessanti di questo FileSystem sono l’interfaccia web per il controllo dello stato del cluster e il plugin appena rilasciato per l’integrazione diretta con OpenNebula.
Il principale pregio di questo sistema è la facilità di implementazione e di scalabilità, unita a una velocità generale di tutto rispetto.
Il principale difetto è la quantità di server necessari ad implementare un sistema funzionante: almeno 3 per ambienti di test, almeno 5 per ambienti in produzione.

Ceph
Ceph è l’ultimo Filesystem che prendiamo in considerazione. Diciamo che promette bene e, non a caso, è stato già introdotto nella mainline del kernel linux. Ultima cosa che mi sarei aspettato, quindi, è di avere problemi di sorta, cosa che puntualmente è avvenuta cercando di creare un ambiente misto di nodi a 32 e a 64 bit.
Concettualmente è simile a MooseFS, però introduce due feature interessanti: il driver nel kernel è in grado di lavorare a diretto contatto con lo storage del cluster, senza quindi necessitare di FUSE, pertanto dovrebbe garantire prestazioni superiori; inoltre introduce un proxy in grado di esporre una interfaccia REST API compatibile con Amazon S3.
Diciamo che è ancora un prodotto giovane e, a causa delle limitazioni di gioventù, non ho potuto sperimentarlo in maniera approfondita, peranto ritornerò a provarlo sicuramente in futuro.

apr 182011
 

Abbiamo visto in un precedente articolo come avere due server MySQL in replica circolare per avere un sistema MySQL completamente ridondato. In questo articolo utilizzeremo altri due strumenti OpenSource attraverso i quali riusciremo sia a bilanciare il carico, sia ad otternere una migliore sicurezza di funzionamento del sistema.

Premettiamo una cosa: oltre ai due nodi in replica circolare, è possibile aggiungere X nodi slave in modo da scalare all’infinito il sistema. E’ importante però che ci siano soli due nodi Master-Master, mentre gli altri dovranno essere solo slave: effettueremo il bilanciamento del carico solo per le query in lettura (e queste possono essere tranquillamente inviate ad un qualsiasi slave), mentre avremo in realtà un solo master attivo, l’altro fungerà da slave e diventerà master solo nel caso in cui il primo guastarsi.

MySQL MMM
MySQL MMM è un utile sistema di script in Perl in grado di gestire un sistema di più server MySQL in replica semplicemente “giocando” con gli indirizzi IP. Si ha un demone che gira sul controller e un agent che gira su ogni server; il controller dialoga con gli agent per verificarne il funzionamento e, in caso affermativo gli assegna un indirizzo IP valido. Nel caso in cui un agent dovesse avere problemi, l’indirizzo IP viene spostato dal controller su un agent funzionante.

Facciamo un esempio per chiarirci le idee. Ammettiamo di avere un sistema formato da questi 5 server:
192.168.50.101 db1 (Master 1)
192.168.50.102 db2 (Master 2)
192.168.50.103 db3 (Slave 1)
192.168.50.104 db4 (Slave 2)
192.168.50.150 Controller

Configureremo MySQL MMM per smistare automaticamente gli indirizzi IP 192.168.50.221/222/223/224 per gestire la lettura e l’IP 192.168.50.220 per la scrittura. Su tutti i server MySQL sarà presente il file /etc/mysql_mmm/mmm_common.conf:

/etc/mysql-mmm/mmm_common.conf
active_master_role                      writer

<host default>
cluster_interface               eth1

 pid_path                        /var/run/mmm_agentd.pid
 bin_path                        /usr/lib/mysql-mmm/

 replication_user                replication
 replication_password            replication_password

 agent_user                      mmm_agent
 agent_password                  agent_password

</host>

<host db1>
 ip                              192.168.50.201
 mode                            master
 peer                            db2
</host>

<host db2>
 ip                              192.168.50.202
 mode                            master
 peer                            db1
</host>

<host db3>
 ip                              192.168.50.203
 mode                            slave
</host>

<host db4>
 ip                              192.168.50.204
 mode                            slave
</host>

<role writer>
 hosts                           db1, db2
 ips                             192.168.50.220
 mode                            exclusive
</role>

<role reader>
 hosts                           db1, db2, db3, db4
 ips                             192.168.50.221, 192.168.50.222, 192.168.50.223, 192.168.50.224
 mode                            balanced
</role>

Su ciascun agent dovrà essere inoltre presente il file /etc/mysql_mmm/mmm_agent.conf

/etc/mysql-mmm/mmm_agent.conf
include mmm_common.conf
this db1

Ovviamente sostituiremo db1 con il nome sel server assegato nel file mmm_common corrispondente all’indirizzo ip.

Inoltre bisognerà creare dei nuovi utenti all’interno della console di MySQL:

mysql -p -u root
GRANT REPLICATION CLIENT                 ON *.* TO 'mmm_monitor'@'192.168.50.%' IDENTIFIED BY 'monitor_password';
GRANT SUPER, REPLICATION CLIENT, PROCESS ON *.* TO 'mmm_agent'@'192.168.50.%'   IDENTIFIED BY 'agent_password';
GRANT REPLICATION SLAVE                  ON *.* TO 'replication'@'192.168.50.%' IDENTIFIED BY 'replication_password';

Sul controller, invece, modificheremo il file /etc/mysql-mmm/mmm_mon.conf:

include mmm_common.conf

	ip					127.0.0.1
	pid_path				/var/run/mmm_mond.pid
	bin_path				/usr/lib/mysql-mmm/
	auto_set_online				15
	status_path				/var/lib/misc/mmm_mond.status
	ping_ips				192.168.50.201, 192.168.50.202, 192.168.50.203, 192.168.50.204

	monitor_user				mmm_monitor
	monitor_password			monitor_password

debug 0

Bene, a questo punto avremo sempre disponibili gli IP 192.168.50.221/222/223/224 per effettuare query in lettura (anche se ci fosse solo un server attivo) e l’IP 192.168.50.220 a cui indirizzare le query in scrittura. Bene come fare? Ci viene in aiuto MySQL Proxy.

MySQL Proxy
MySQL Proxy è un pacchetto che permette di fare molte cose, ma in questa situazione lo utilizzeremo sul controller semplicemente per smistare le query in lettura sugli IP 192.168.50.221/222/223/224 e le query in scrittura sull’IP 192.168.50.220.
Per farlo basterà avviare il demone con le seguenti opzioni:

--proxy-address=:3306 --proxy-backend-addresses=192.168.50.220:3306 --proxy-read-only-backend-addresses=192.168.50.221:3306 --proxy-read-only-backend-addresses=192.168.50.222:3306 --proxy-read-only-backend-addresses=192.168.50.223:3306 --proxy-read-only-backend-addresses=192.168.50.224:3306 --log-use-syslog --log-level=warning  --admin-address=192.168.50.150:4041 --admin-password=passwordAmministratore

Bene ora nelle applicazioni sarà sufficiente configurare come server MySQL l’indirizzo IP 192.168.50.150 e il nostro proxy si occuperà di gestire il nostro cluster,