Newsgroup: it.comp.os.linux.sys
Titolo: ldirectord

Sto avendo problemi con ldirectord (keepalived fa la stessa cosa):
Oct  6 12:45:31 x ldirectord[15897]: Added virtual server: 
127.0.0.1:1234
Oct  6 12:45:31 x ldirectord[15897]: Quiescent real server: 
1.2.3.4:1234
 
(
127.0.0.1:1234
) (Weight set to 0)
Oct  6 12:45:31 x ldirectord[15897]: Quiescent real server: 
1.2.3.4:1234
 
(
127.0.0.1:1234
) (Weight set to 0)
Oct  6 12:45:31 x ldirectord[15897]: Restored real server: 
1.2.3.5:1234
 
(
127.0.0.1:1234
) (Weight set to 1)
Ovvero, ldirectord identifica correttamente che uno dei server non
funziona e lo butta fuori dal cluster impostandone prioritï¿œ pari a 0.
Perï¿œ io non vedo nessuna porta 1234 in ascolto sul server locale:
# netstat -na | grep LISTEN | grep -c "
127.0.0.1:1234
"
0
Nei log non ho nessun errore che mi possa far capire come mai
non viene creato il virtual server.
-- 
Non tocca a noi dominare tutte le maree del mondo,
il nostro compito ï¿œ di fare il possibile per la
salvezza degli anni nei quali viviamo,
sradicando il male dai campi che conosciamo.

 Perï¿œ io non vedo nessuna porta 1234 in ascolto sul server locale:
Nemmeno configurando a manina ipvs riesco a mettere in piedi il
servizio virtuale. Semplicemente "se ne sbatte" e nonostante
ipvsadm mi dica che il servizio ï¿œ attivo con tanto di realserver
in bilanciamento, non ho nessuna porta bindata a qualche ip sulla
macchina con ipvs in esecuzione.


 macchina con ipvs in esecuzione.
Che tipo di packet forwarding stai utilizzando? direct routing?
Se è così, il servizio sul server remoto sta ascoltando anche su localhost?
 
-- 
Vide

  server remoto
aka real server
-- 
Vide

 Se è così, il servizio sul server remoto sta ascoltando anche su localhost?
Si, DR, ma il problema non è sul server remoto, bensì su quello
locale.
Se non ho in ascolto LVS sulla macchina locale, come fa a bilanciare?
-- 
Non tocca a noi dominare tutte le maree del mondo,
il nostro compito è di fare il possibile per la


 Se non ho in ascolto LVS sulla macchina locale, come fa a bilanciare?
Se ricordo bene il director non ha niente "in ascolto" nel significato 
classico del termine. L'importante e' che ipvsadm mostri i corretti 
realserver per ogni VIP che gestisci.

 realserver per ogni VIP che gestisci.
A me sembrava il contrario, l'ho usato una volta tempo fa e non
ho preso appunti, mannaggi a me.
Comunque sia, non funziona, nonostante ipvsadmin mostri gli IP
corretti.


 corretti.
Allora vai di tcpdump (sia sul director che sul realserver) e vedi che 
succede. Potresti anche lasciare solo il realserver che ti interessa 
associato al VIP e vedere se le richieste vengono forwardate correttamente. 
E' difficile dire di piu' senza maggiori informazioni.

 E' difficile dire di piu' senza maggiori informazioni.
gi� fatto con tcpdump, non vedo nulla in uscita nel dal director
ne in ingresso sul realserver.
# mysql -u utente --password=password -h 127.0.0.1
ERROR 2003 (HY000): Can't connect to MySQL server on '127.0.0.1' (111)
e parallelamente non vedo nulla con tcpdump.
(nemmeno con IP pubblici funziona, per cui non � un problema di
loopback)
-- 
Non tocca a noi dominare tutte le maree del mondo,
il nostro compito � di fare il possibile per la


 Se non ho in ascolto LVS sulla macchina locale, come fa a bilanciare?
Tu conosci la differenza tra un proxy e un lvs, vero? :-D

 ERROR 2003 (HY000): Can't connect to MySQL server on '127.0.0.1' (111)
Stai usando 127.0.0.1 come VIP?
Se ti connetti al realserver direttamente (usando il RIP, non il VIP) 
funziona?
Il realserver e' configurato correttamente per non rispondere ad ARP? Ha il 
VIP assegnato (probabilmente come secondario su loopback)?

 Se non ho in ascolto LVS sulla macchina locale, come fa a bilanciare?
Ti assicuro che lo fa perfettamente lo stesso, dato che il re-routing lo fa 
prima
-- 
Vide

 Tu conosci la differenza tra un proxy e un lvs, vero? :-D
Yes, quindi hai appena confermato che è normale che
non esista il binding ip/porta sul director.
:-)


 VIP assegnato (probabilmente come secondario su loopback)?
Si, ma non è tanto questo il problema.
Se il problema fosse sul real server, vedrei almeno una parte di
traffico in ingresso sul realserver e poi da li qualche casino.
Invece io non vedo nulla, ne in uscita dal director, ne in ingresso
sul realserver.
-- 
Non tocca a noi dominare tutte le maree del mondo,
il nostro compito è di fare il possibile per la


 sul realserver.
Ultime cartucce: e' attivato il forwarding sul director (anche se non 
giurerei che e' necessario)? Il director ha una route verso l'IP sorgente? 
Mi sembra vagamente di ricordare che se non c'era, lui droppava il 
pacchetto, a meno di aggiungerla o disattivare l'rp_filter. Ripeto: e' tutto 
a memoria, non ho la possiblita' di controllare gli appunti da qui, ma *mi 
pare* di avere avuto qualche problema a causa di queste cose (back in the 
2.4 days, quindi parecchio tempo fa).

 Il director ha una route verso l'IP sorgente? 
Si.


 sul realserver.
E se provassi a usare un IP diverso da 127.0.0.1 come VIP?
-- 
Vide

 E se provassi a usare un IP diverso da 127.0.0.1 come VIP?
Già provato, non cambia niente.
La sfiga mi perseguita, io devo mettere in failover due server
mysql. I server sono in sola lettura, le query di insert son
fatte da altri server e non mi importa di ridondarli.
Sto provando anche mysql-proxy.
Si connette solo al primo nodo passato come argomento, ad esempio
io ho questo script:
# cat /usr/local/bin/avvia_proxy.sh
#!/bin/sh
killall -9 mysql-proxy
SLAVE="1.2.3.4 1.2.3.5 1.2.3.6"
for i in $SLAVE; do
    ADDR="--proxy-backend-addresses=$i:3306 $ADDR"
done
mysql-proxy --admin-address=:1337 $ADDR &
#
se lo avvio il proxy va su, accetta connessioni sulla porta
4040, ma solo sul primo server, ovvero 1.2.3.4.
Se spengo 1.2.3.4, mysql-proxy continua a cercare di contattare
lui, come se non si accorgesse della sua irraggiungibilità:
# mysql -h 127.0.0.1 -P 4040 -u utente --password=password -e "SHOW 
DATABASES;"
network-mysqld-proxy.c.3709: connect(
1.2.3.4:3306
) failed: Connection 
refused
ERROR 2013 (HY000): Lost connection to MySQL server at 'reading initial 
communication packet', system error: 0
Va a finire che invece di puntare ad un failover mi
tocca usare le repliche su ciascun nodo....


 # netstat -na | grep LISTEN | grep -c "
127.0.0.1:1234
" 0
Per questo ti meriteresti una lapidazione.
Comunque se gli slave sono nattati, devono avere come default gateway il 
director. Ancora non te l'avevano detto.

 director. Ancora non te l'avevano detto.
Non sono nattati e sono perfettamente raggiungibili, sia in un verso
(director->slave e mio_pc->slave) sia nell'altro (slave->director e 
slave->mio_pc)
-- 
Non tocca a noi dominare tutte le maree del mondo,
il nostro compito è di fare il possibile per la


 fatte da altri server e non mi importa di ridondarli.
Quindi nessuno mi consiglia cosa usare per creare un failover
in sola lettura di due nodi mysql in replica master-slave?
Non mi importa il bilanciamento, ho solo la necessità che le
query in lettura siano garantite: se muore un nodo, devo poter
interrogare ugualmente il secondo nodo rimasto attivo.
Pdns non mi permette di definire due nodi mysql in failover,
per cui devo ridondare il server per conto mio e far puntare
pdns al "cluster"

 pdns al "cluster"
Io cercherei di capire perche' non funziona LVS prima di mettere in piedi
cose piu' complicate...
ah: il kernel ha il supporto LVS, modulare o built-in?

 ah: il kernel ha il supporto LVS, modulare o built-in?
Sono su debian lenny, ed ho installato LVM tramite
apt-get install keepalived ldirectord
(li ho installati entrambi per fare prove).
In maniera analoga, ho installato due bilanciatori per dei
server web e funzionano perfettamente.
Se poi non ci fosse il supporto del kernel, si riuscirebbe
ugualmente a configurare ipvsadm ?
Io vedo, con ipvsadm -L una configurazione attiva e funzionante.

 in sola lettura di due nodi mysql in replica master-slave?
Io uso LVS e mi funziona perfettamente, quindi cosa vuoi che ti consigli? :P
-- 
Vide