[openMosix-it] Re: connessioni 3 nic
Giancarlo del Rossi
openmosix@democritos.it
Mon, 7 Apr 2003 16:26:52 +0200
Ciao a tutti
Sicuramente è vero che utilizzerai tutti e otto i pin del cavo (quindi un
ampliamento della banda) ma come la metti per il traffico di broadcast che
viene triplicato per ogni host ???
Se posso permettermi di darti un consiglio, sicuramente ridurrei il range di ip
per ogni nic (attualmente su 255 ) portando la subnet a 255.255.255.248
utilizzando cosi al massimo 6 host disponibili (8 totali escluso rete e broadcast).
In merito al relativo incremento rispetto ad una rete a 100 mb generica ho
qualche dubbio, poichè non credo che sposterai grandi q.ta di dati per le
trasmissioni del cluster, e quindi non avrai un incremento proporzionale alla
complessita di gestione e hardware coinvolto.
Forse è interessante considerare la migrazione a 1000 mb dato il basso costo dei
nic su rame (66 euro iva inclusa), operazione che a breve integrerò nel piccolo
cluster 4 nodi presso la ns azienda.
In ogni caso l'idea è interessante e sono curioso di vedere i risultati.
Saluti
ps è possibile allegare una tabella di routing di uno degli host ??
Grazie
Giancarlo del Rossi
> Message: 7
> From: "Premoli, Roberto [IT/0425]" <roberto.premoli@pharmacia.com>
> To: "'openmosix@democritos.it'" <openmosix@democritos.it>
> Date: Mon, 7 Apr 2003 09:02:19 -0400
> Subject: [openMosix-it]
> =?iso-8859-1?Q?RE=3A_=5BopenMosix-it=5D_Re=3A_test_su_nodi_con?=
> =?iso-8859-1?Q?_pi=F9_porte_ethernet?=
> Reply-To: openmosix@democritos.it
>
>
> Non so di cosa tu stia parlando, (iptable, UDP, etc): brutta cosa
> l'ignoranza (mia) :-(.
>
> Comunque ti allego uno stralcio del documento che ho scritto, nella sp=
> eranza
> che ti sia
> chiarificatore di quello che stiamo combinando....
>
> inizio
> stralcio**************************************************************=
> ******
> ***********
> CASO 14: COMBINAZIONE FINALE
> Piu' complesso =E8 l'ultimo caso dove occorre attivare su ogni nodo pi=
> =F9 di una
> scheda di rete.
> Ora entriamo nel vivo di questa serie di test, cio=E8 verificheremo se=
> e
> quanto sar=E0 l'incremento prestazionale del cluster in funzione
> dell'aumentare delle schede di rete attive, e di conseguenza la veloci=
> t=E0 di
> connessione tra i nodi.
> riporto qui la struttura delle connessioni, il nodo A e' il master il =
> numero
> di fianco ad ogni nodo indica il numero finale dell'indirizzo di rete
> 192.168.68.x del nodo.
>
>
>
> STELLA A QUATTRO NODI
>
> 14 A-eth0-------eth0-B 15 CONNESSIONI:
> (Nodo.punto_rete<->Nodo.punto_rete)
> |\ /| A.eth0<->B.eth0
> e e e e A.eth1<->C.eth0
> t t t t A.eth2<->D.eth0
> h h h h B.eth1<->C.eth1
> 1 2 1 2 B.eth2<->D.eth1
> | \ / | C.eth2<->D.eth2
> | \ / |
> | \ / |
> | \ |
> | / \ |
> | / \ |
> | / \ |
> e e e e
> t t t t
> h h h h
> 0 1 0 1
> |/ \|
> 16 C-eth2-------eth2-D 17
>
> Qui di seguito il contenuto del file /etc/network/interface dei 4 nodi=
> :
>
> Nodo A (master)
> 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
>
> auto eth1
> iface eth1 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.16 dev eth1
>
> auto eth2
> iface eth2 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.17 dev eth2
>
>
>
> Nodo B
> auto eth0
> iface eth0 inet static
> address 192.168.68.15
> netmask 255.255.255.0
> network 192.168.68.0
> broadcast 192.168.68.255
> up route add -host 192.168.68.14 dev eth0
>
> auto eth1
> iface eth1 inet static
> address 192.168.68.15
> netmask 255.255.255.0
> network 192.168.68.0
> broadcast 192.168.68.255
> up route add -host 192.168.68.16 dev eth1
>
> auto eth2
> iface eth2 inet static
> address 192.168.68.15
> netmask 255.255.255.0
> network 192.168.68.0
> broadcast 192.168.68.255
> up route add -host 192.168.68.17 dev eth2
>
>
>
>
> Nodo C
> auto eth0
> iface eth0 inet static
> address 192.168.68.16
> netmask 255.255.255.0
> network 192.168.68.0
> broadcast 192.168.68.255
> up route add -host 192.168.68.14 dev eth0
>
> auto eth1
> iface eth1 inet static
> address 192.168.68.16
> netmask 255.255.255.0
> network 192.168.68.0
> broadcast 192.168.68.255
> up route add -host 192.168.68.15 dev eth1
>
> auto eth2
> iface eth2 inet static
> address 192.168.68.16
> netmask 255.255.255.0
> network 192.168.68.0
> broadcast 192.168.68.255
> up route add -host 192.168.68.17 dev eth2
>
>
>
> Nodo D
> auto eth0
> iface eth0 inet static
> address 192.168.68.17
> netmask 255.255.255.0
> network 192.168.68.0
> broadcast 192.168.68.255
> up route add -host 192.168.68.14 dev eth0
>
> auto eth1
> iface eth1 inet static
> address 192.168.68.17
> netmask 255.255.255.0
> network 192.168.68.0
> broadcast 192.168.68.255
> up route add -host 192.168.68.15 dev eth1
>
> auto eth2
> iface eth2 inet static
> address 192.168.68.17
> netmask 255.255.255.0
> network 192.168.68.0
> broadcast 192.168.68.255
> up route add -host 192.168.68.16 dev eth2
>
>
>
> In questo modo abbiamo ottenuto che un nodo abbia un SOLO indirizzo IP=
> e
> tutti i suoi punti rete utilizzino quell'unico indirizzo IP. Esaminiam=
> o con
> attenzione la configurazione (per esempio) del punto_rete eth0 del NOD=
> O A
> (master):
> 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
>
> Le prime sei righe sono facilmente comprensibili, mentre l'ultima e'
> l'istruzione "magica": infatti traducendola in italiano significa: "tu=
> tte e
> solo le comunicazioni che dal nodo A sono diretti al nodo B devono par=
> tire
> dal punto rete eth0 (del nodo A) e devono arrivare al punto rete eth0 =
> (del
> nodo B)". In questo modo non avvengono collisioni superflue in quando =
> si
> tratta di una connessione peer-to-peer e inoltre la comunicazione avvi=
> ende a
> 200Mb/s in quanto vengono usati tutti e 8 i fili del cavo di rete incr=
> ociato
> in un unico senso di trasmissione. Concludendo, ogni nodo dispone di u=
> na
> connessione a 200Mb/s verso tutti e tre gli altri nodi in contemporane=
> a.
> fine
> stralcio**************************************************************=
> ******
> *********
>
> Non sono un kernel hacker, un amministratore di rete (magari!) o un
> utilizzatore di C:
> sono solo un utente che crede di avere avuto una buona idea.
> 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 accet=
> to.
> Ciao, roberto
>
>
>
> >Roberto, ti posso suggerire di fare anche dei test riguardo una coset=
> ta?
>
> >Siccome mi pare di aver capito che hai 3 schede di rete per macchina,=
> hai
> >intenzione di usare iptables per instradare i pacchetti a seconda del=
> tipo
> >sulle varie schede di rete?
>
> >Ad esempio, parlando di 3 schede di rete per nodo:
>
> >1) migrazione dei processi su UDP
> >2) oMFS su TCP
> >3) amministrazione dei nodi (omdiscd/ssh/scp/ecc)
>
> >Secondo quanto riportato su
> http://howto.ipng.be/openMosixWiki/index.php/FAQ
> >
> >-- tagliuzza qua --
> >Which ports does openMosix use?:
> >
> >According to Moshe, "openMosix uses only UDP protocol ports in the ad=
> dress
> >range of 5000-5700."
> >
> >From the souce code :
> >
> >in linux/include/linux/mfs_socket.h define MFS_MAIN_PORT 0xD302 This =
> port
> is in
> >"network byte order" so its hex value is 02D3 and its decimal value i=
> s 723
> >Protocol used TCP
> >
> >in linux/hpc/comm.c define MIG_DAEMON_PORT 0x3412 decimal value 4660
> Protocol
> >used TCP
> >
> >define INFO_DAEMON_PORT 0x3415 decimal value 5428 Protocol used UDP
> >-- tagliuzza qua --
> >
> >Non mi ricordo se ne avevamo gi=E0 parlato, comunque sarei curioso di=
> sapere
> cosa
> >verrebbe fuori usando una tale configurazione.
> >
> >Ciao, Mirko.
>
>
>
> This communication is intended solely for the use of the addressee and=
> may contain information that is legally privileged, confidential or e=
> xempt from disclosure. If you are not the intended recipient, please =
> note that any dissemination, distribution, or copying of this communic=
> ation is strictly prohibited. Anyone who receives this message in err=
> or should notify the sender immediately and delete it from his or her =
> computer.
>
>
> --__--__--
>
> Message: 8
> Date: Mon, 07 Apr 2003 16:07:08 +0200
> From: Christian Zoffoli <merlin@studiobz.it>
> To: openmosix@democritos.it
> Subject: Re: [openMosix-it] Myrinet M2L-SW16 & openMosix
> Reply-To: openmosix@democritos.it
>
> Stefano Cozzini wrote:
> > Mah... io per 50 euro me la comprerei...
>
> per quanto mi riguarda penso che procedero' con le gigabit intel
> ...magari in configurazione IANS.
> Se qualcuno e' interessato agli switch myrinet di cui si e' parlato, ce
> ne sono alcuni in vendita su ebay.com (uno dei quali e' nuovo).
>
>
> Christian
>
>
> --__--__--
>
> Message: 9
> Date: Mon, 07 Apr 2003 16:14:11 +0200
> From: Christian Zoffoli <merlin@studiobz.it>
> To: openmosix@democritos.it
> Subject: Re: [openMosix-it] Re: test su nodi con =?ISO-8859-1?Q?pi=F9_p?=
> =?ISO-8859-1?Q?orte_ethernet?=
> Reply-To: openmosix@democritos.it
>
> Mirko Caserta wrote:
> > On Mon, 7 Apr 2003 07:54:23 -0400
> > "Premoli, Roberto [IT/0425]" <roberto.premoli@pharmacia.com> wrote:
> >
> >
> >>Niente "channel bonding".
> >>Si tratta di un meccanismo in cui ogni nodo ha
> >>una connessione di rete diretta con gli altri 3 nodi:
> >>ecco uno schema:
> >>
> >> A------B
> >> |\ /|
> >> | \ / |
> >> | \/ |
> >> | /\ |
> >> | / \ |
> >> |/ \|
> >> C------D
> >
> >
> > Roberto, ti posso suggerire di fare anche dei test riguardo una cosetta?
> >
>
> ...se hai voglia e se le tue schede sono Intel, potresti provare anche
> IANS di Intel (una loro implementazione di channel bonding) ...tuttavia
> rimane la mia perplessita' circa l'occupazione del bus di sistema.
> Una gigabit nel sistema non e' uno scherzo, soprattutto se montate su
> schede madri classiche (...in ambito x86 toglierei da questa categoria
> solamente le serverworks).
>
> Sarei molto curioso di vedere dei test comparativi tra cluster su hw x86
> e magari qualche dual-core PowerPC.
>
> Christian
>
>
> --__--__--
>
> Message: 10
> Date: Mon, 7 Apr 2003 16:10:08 +0200
> From: Mirko Caserta <mirko@mcaserta.com>
> To: openmosix@democritos.it
> Subject: [openMosix-it] Re: test su nodi con =?ISO-8859-1?Q?pi=F9?= porte
> ethernet
> Reply-To: openmosix@democritos.it
>
> 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) =E8 la nuova funzionalit=E0 di filtraggio dei pacc=
> hetti IP
> nei kernel 2.4 che =E8 andata a sostituire le ipchains dei kernel 2.2.
>
> Serve fondamentalmente per fargli fare cose del tipo:=20
>
> - se questo pacchetto arriva da eth0, =E8 di tipo UDP ed =E8 destinato alla=
> porta
> 3456 su eth1, allora fallo passare
>
> - se questo pacchetto =E8 di tipo ICMP, buttalo via e dimenticalo!
>
> - se questo pacchetto =E8 di tipo TCP, proviene da eth0 ed =E8 destinato ad=
> eth1
> sulla porta 22 allora fallo passare
>
> - se questo pacchetto =E8 di tipo TCP, proviene da eth1 ed =E8 destinato a =
> eth0
> fallo passare tramite NAT/Masquerading
>
> - ecc ecc ecc
>
> iptables =E8 moolto configurabile: gli esempi che ti ho fatto sono tra i pi=
> =F9
> banali che si possano immaginare. Tuttavia con iptables si possono fare cose
> davvero complesse ed il sistema non ne risente pi=F9 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 =E8 un'alternativa al protocollo TCP. Sono entrambi protolli che si occ=
> upano
> del "controllo" dei dati ma TCP =E8 "stream-oriented", mentre UDP =E8
> "message-driven". In altre parole, quando fai telnet o ssh o scp o ftp, stai
> usando TCP perch=E9 hai bisogno di un protocollo che possa supportare un fl=
> usso
> 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=E9 per sua n=
> atura
> =E8 incline a perdersi ;) In altre parole un pacchetto UDP =E8 un messaggio
> completo che =E8 destinato da un punto ad un altro della rete. Non ti assic=
> ura
> alcuna affidabilit=E0 ma =E8 molto pi=F9 veloce del TCP in certi casi perch=
> =E9 non ha
> tutto l'overhead di dover stabilire una connessione costante, controllare il
> flusso dei dati, ecc.
>
> UDP =E8 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 tradu=
> rre
> il nome di una macchina in un indirizzo IP, quello che succede dietro le qu=
> inte
> =E8 che la tua macchina invia un pacchetto UDP sulla porta 53 (se non ricor=
> do
> 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=E0 con un pacchetto UDP che conterr=E0 il messaggio:
> "openmosix.sourceforge.net =E8 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 ;)
> =20
> > ...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.=
> =20
>
> 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? ;-)
> =20
> > sono solo un utente che crede di avere avuto una buona idea.
>
> Spesso sono gli utenti che hanno le migliori idee perch=E9 non si fanno tut=
> te 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=E0 del cl=
> uster
> (come da mio msg precedente). Ti ho chiesto di fare questa prova perch=E9 ho
> letto pi=F9 volte che i cluster di certe proporzioni usano questa tecnica d=
> ei
> canali differenziati per ottenere prestazioni migliori. Ma forse =E8 solo u=
> na mia
> pippa mentale ;-)
>
> Ciao e buon lavoro,
> Mirko
>
>
>
> --__--__--
>
> _______________________________________________
> openMosix mailing list
> openMosix@democritos.it
> http://www.democritos.it/mailman/listinfo/openmosix
>
>
> End of openMosix Digest
>
--
Giancarlo del Rossi
System Administrator
EnterMED s.r.l - Via libertà 56 - 90143 Palermo
+39917303009 - +3991305023
-------------------------------------------------
This mail sent through IMP: http://horde.org/imp/