[openMosix-it] Re: test su nodi con più porte ethernet

[Mirko Caserta]

On Mon, 7 Apr 2003 09:02:19 -0400
"Premoli, Roberto [IT/0425]" <roberto.premoli@pharmacia.com> wrote:

> Non so di cosa tu stia parlando, (iptable, UDP, etc)

http://www.iptables.org/

netfilter (aka iptables) è la nuova funzionalità di filtraggio dei pacchetti IP
nei kernel 2.4 che è andata a sostituire le ipchains dei kernel 2.2.

Serve fondamentalmente per fargli fare cose del tipo: 

- se questo pacchetto arriva da eth0, è di tipo UDP ed è destinato alla porta
3456 su eth1, allora fallo passare

- se questo pacchetto è di tipo ICMP, buttalo via e dimenticalo!

- se questo pacchetto è di tipo TCP, proviene da eth0 ed è destinato ad eth1
sulla porta 22 allora fallo passare

- se questo pacchetto è di tipo TCP, proviene da eth1 ed è destinato a eth0
fallo passare tramite NAT/Masquerading

- ecc ecc ecc

iptables è moolto configurabile: gli esempi che ti ho fatto sono tra i più
banali che si possano immaginare. Tuttavia con iptables si possono fare cose
davvero complesse ed il sistema non ne risente più di tanto in termini di
carico sulla CPU e altre risorse (almeno per quanto riguarda test da me
effettuati con il mio vecchio clusterino oM composto di 3 nodi).

UDP è un'alternativa al protocollo TCP. Sono entrambi protolli che si occupano
del "controllo" dei dati ma TCP è "stream-oriented", mentre UDP è
"message-driven". In altre parole, quando fai telnet o ssh o scp o ftp, stai
usando TCP perché hai bisogno di un protocollo che possa supportare un flusso
bidirezionale (full/duplex qualcuno direbbe) di dati. TCP si preoccupa per te
di mantenere una connessione costante tra due punti della rete e si assicura
che i dati viaggino senza errori.

UDP invece viene usato in protocolli come DNS, TFTP, ecc perché per sua natura
è incline a perdersi ;) In altre parole un pacchetto UDP è un messaggio
completo che è destinato da un punto ad un altro della rete. Non ti assicura
alcuna affidabilità ma è molto più veloce del TCP in certi casi perché non ha
tutto l'overhead di dover stabilire una connessione costante, controllare il
flusso dei dati, ecc.

UDP è una specie di cartolina dove tu scrivi un messaggio e non sai se
riceverai una cartolina di risposta. Ad esempio quando usi il DNS per tradurre
il nome di una macchina in un indirizzo IP, quello che succede dietro le quinte
è che la tua macchina invia un pacchetto UDP sulla porta 53 (se non ricordo
male) del tuo server DNS con un messaggio del tipo: "che indirizzo IP ha la
macchina openmosix.sourceforge.net?". Se tutto va bene, il tuo server DNS ti
risponderà con un pacchetto UDP che conterrà il messaggio:
"openmosix.sourceforge.net è un alias per projects.sourceforge.net. ed ha come
indirizzo IP 66.35.250.209".

> auto eth0
> iface eth0 inet static
>     address 192.168.68.14
>     netmask 255.255.255.0
>     network 192.168.68.0
>     broadcast 192.168.68.255
>     up route add -host 192.168.68.15 dev eth0

Aha, stai usando Debian vedo ;)
 
> ...snippone...
> tratta di una connessione peer-to-peer e inoltre la comunicazione avviene=
 a
> 200Mb/s in quanto vengono usati tutti e 8 i fili del cavo di rete incroci=
ato
> in un unico senso di trasmissione. Concludendo, ogni nodo dispone di una
> connessione a 200Mb/s verso tutti e tre gli altri nodi in contemporanea.=
 

Oh, sei sicuro di questa cosa? E' la prima volta che la sento. Forse non ho
capito bene cosa vuoi dire/fare. Forse non ho mai usato un cavo "cross" in vita
mia? ;-)
 
> sono solo un utente che crede di avere avuto una buona idea.

Spesso sono gli utenti che hanno le migliori idee perché non si fanno tutte le
pippe mentali che uno sviluppatore super-esperto si farebbe ;-)

> Se pensi che abbia scritto delle inesattezze (tra poche ore lo sapro'
> direttamente, perche' faremo le prove!) ti prego di dirmelo, ogni
> suggerimento e' bene accetto.

No, da quello che ho letto mi sembra che tu abbia le idee molto chiare e la
configurazione a occhio e croce mi sembra corretta. Ti chiedevo soltanto di
provare anche ad usare le 3 schede di rete di ogni macchina come fossero 3
canali di comunicazione diversi, ognuno per una certa funzionalità del cluster
(come da mio msg precedente). Ti ho chiesto di fare questa prova perché ho
letto più volte che i cluster di certe proporzioni usano questa tecnica dei
canali differenziati per ottenere prestazioni migliori. Ma forse è solo una mia
pippa mentale ;-)

Ciao e buon lavoro,
  Mirko