Ridondanza switch

[Alessandro]

Ciao a tutti.
La situazione è la seguente:

due rack 42U con in testa a ciascuno 2 Procurve 2626.

I due rack dovranno fare capo ad una coppia di Procurve 3500 gigabit
(non ricordo il modello esatto) che fungeranno da centro stella al
quale saranno connessi due router cisco 2800 verso internet.

La domanda:
per avere massima ridondanza (connessione ad internet a parte),
pensavo di fare quanto segue:

i server di ogni armadio (massimo 20 per ogni armadio) saranno
connessi mediante due ethernet in bonding (active/passive) ai due
switch di testa rack.

I due switch di testa rack saranno connessi tra loro tramite un trunk
a 2gbit mediante le due porte gigabit presenti in ogni switch.

Ogni coppia di switch sarà connessa al centro stella mediante un trunk
formato da 2 porte 10/100.

Così facendo ho ridondanza a livello di ethernet sui server, a livello
di switch, a livello di collegamenti sugli switch ed anche a livello
di router e di centrostella.

Quello che non mi convince è avere l'interconnessione col centro
stella a 200mbit...
Un po pochino.

Secondo voi, meglio avere il trunk tra i due switch a 200mbit (posso
arrivare anche a 400mbit collegando 4 porte per ogni switch) e fare
l'uplink con il centro stella a 2gbit oppure tenere i 2gbit di
interconnessione e 200mbit per il centro stella? (non posso collegare
il centro stella a 400mbit con 4 porte perchè non ho così tante porte
libere nei 3500)

Ad un a prima analisi, il trunk di interconnessione tra i due 2626 di
ogni armadio serve nel caso dovesse andare giù un collegamentro tra il
server e lo switch o tra il router e lo switch (lo switch rimanendo in
piedi non farebbe 'switchare' la ethernet ne nel server ne nel router)

I server non sono molto indipendenti tra loro, sicuramente in un
armadio ci saranno server database che dovranno comunicare con dei
server per applicativi presenti nell'altro il che mi fa dubitare sulle
performances del trunk verso il centro stella.

Credo che la soluzione migliore (ma sui 2626 non mi pare sia
attuabile) sia quella di fare i trunk nel seguente modo:

2626 -> centro stella: 1 porta gigabit + 1 porta 10/100 (totale
1100mbit)
2626 -> 2626: 1 porta gigabit + 3 porte 10/100 (totale 1300mbit).

Any hint per evitare colli di bottiglia ed evitare, preferibilmente,
di attivare RSTP sugli edge?
La rete è composta da soli due livelli (edge + centro stella) e
attivare RSTP mi sembra un po esagerato.

Su cosa puntare, sul trunk tra i due switch o il trunk verso il centro
stella?

Grazie.

[Luca Sasdelli [MVP]]

Post by Alessandro
I due switch di testa rack saranno connessi tra loro tramite un trunk
a 2gbit mediante le due porte gigabit presenti in ogni switch.

Quindi non si tratta di uno stack.

Post by Alessandro
l'uplink con il centro stella a 2gbit

Questa; se gli switch non sono stackabili, il trunk fra gli switch di
testa serve a poco. Meglio far gestire il tutto all'STP (o meglio LACP)
con il centro stella.

Post by Alessandro
server per applicativi presenti nell'altro il che mi fa dubitare sulle
performances del trunk verso il centro stella.

Fossi in te, penserei ad una soluzione un po' meglio pianificata, es.
tutto su due 48 porte gigabit in stack fra loro, con le connessioni in
bonding spalmate sui due switch dello stack, cosi' se si pianta uno
switch non hai interruzione di servizio.

Inoltre, con uno switch da 96 porte (2x48) potresti contare su una
banda passante sicuramente ai massimi teorici, anche se e'
raccomandabile usare switch in grado di gestire questo tipo di
traffico, es. Enterasys, Nortel o Extreme. Il resto non ce la fa.

Post by Alessandro
Any hint per evitare colli di bottiglia ed evitare, preferibilmente,
di attivare RSTP sugli edge?

Non supportano LACP? Sarebbe l'ideale.

Ciao
Luca

[Alessandro]

Post by Luca Sasdelli [MVP]
Quindi non si tratta di uno stack.

Non sono stackable i 2626

Post by Luca Sasdelli [MVP]

Post by Alessandro
l'uplink con il centro stella a 2gbit

Questa; se gli switch non sono stackabili, il trunk fra gli switch di
testa serve a poco. Meglio far gestire il tutto all'STP (o meglio LACP)
con il centro stella.

Cioe? Credo di aver un po di confusione in testa in quanto il progetto
attuale è cambiato rispetto a quello a cui avevo pensato inzialmente.

La soluzione che hai esposto è valida solo con 4 livelli:
server, switch edge, centro stella, router.

Giusto?

perchè inizialmente si pensava di ridondare una rete a livello di
switch con soli 3 livelli:
router, switch, server, ed in tal caso, supponendo che salti la
ethernet0 del cisco:

il cisco fa lo switch sulla ethernet rimasta, cambiando, di
conseguenza, lo switch di riferimento.
il server, però, continua a comunicare con la ethernet originale,
collagata la vecchio switch.
Senza il trunk tra i due switch router e server non comunicano più.

Con 4 livelli, se salta la ethernet nel router, il router continua
comunicare con l'altro switch di centro stella, il quale sarà
collegato
ugualmente a entrambi gli switch di rack rendendo inutile il trunking
tra le porte.

Se è così, tutto mi è chiaro.

(giusto per la cronaca e per togliermi ogni dubbio dalla mente, per
evitare il livello di centro stella e connettere direttamente
il router ad un singolo armadio (supponiamo che il secondo armadio non
esista), il trunk tra gli switch per il motivo esposto sopra è
fondamentale giusto?)

Post by Luca Sasdelli [MVP]
Fossi in te, penserei ad una soluzione un po' meglio pianificata, es.
tutto su due 48 porte gigabit in stack fra loro, con le connessioni in
bonding spalmate sui due switch dello stack, cosi' se si pianta uno
switch non hai interruzione di servizio.

Perchè 48? I server non superano i 18-20 per armadio.

Post by Luca Sasdelli [MVP]
Inoltre, con uno switch da 96 porte (2x48) potresti contare su una
banda passante sicuramente ai massimi teorici, anche se e'
raccomandabile usare switch in grado di gestire questo tipo di
traffico, es. Enterasys, Nortel o Extreme. Il resto non ce la fa.

Non ho tutta questa necessità di prestazioni.
Attualmente il cliente è su un 48 porte (10/100) non ridondato e per
di più
D-Link.

Post by Luca Sasdelli [MVP]
Non supportano LACP? Sarebbe l'ideale.

Si lo supportano, ma per i motivi esposti sopra (doppio progetto
cambiato nel giro di pochi giorni, sono andato in palla)
L'importante è che si possa mettere in piedi una rete ridondata senza
tirare in ballo STP, il quale andrebbe configurato e mi porterebbe
via del tempo.

[Luca Sasdelli [MVP]]

Post by Alessandro
Cioe? Credo di aver un po di confusione in testa in quanto il progetto
attuale è cambiato rispetto a quello a cui avevo pensato inzialmente.

In pratica sarei per privilegiare la banda verso il centro stella a
runtime, piuttosto che il link, che funzionerebbe solo in emergenza.

Post by Alessandro
il router ad un singolo armadio (supponiamo che il secondo armadio non
esista), il trunk tra gli switch per il motivo esposto sopra è
fondamentale giusto?)

Esatto.

Post by Alessandro
Perchè 48? I server non superano i 18-20 per armadio.

Pero' hai detto che sono dual-homed, per cui avrai 40 nodi per armadio.
Dicevo di sostituire il tutto usando un solo centro stella a 96 porte,
meglio se realizzato con uno stack per via della ridondanza a livello
di unita'. In questo modo si semplifica tutta la gestione delle
ridondanze e si massimizza la banda passante del sistema.

Post by Alessandro
L'importante è che si possa mettere in piedi una rete ridondata senza
tirare in ballo STP, il quale andrebbe configurato e mi porterebbe
via del tempo.

LACP gia' lo fa, dato che gestisce da solo sia STP, sia 802.3ad.

Ciao
Luca

[Alessandro]

Post by Luca Sasdelli [MVP]
In pratica sarei per privilegiare la banda verso il centro stella a
runtime, piuttosto che il link, che funzionerebbe solo in emergenza.

Inizialmente pensavo anche io alla stessa cosa.
Poi però ho detto: in caso di emergenza 100mbit o 200mbit mi sembrano
un po pochini.
Tenendo conto che saranno a pieno carico 20 server ovvero 2000mbit,
veicolarli tutti in
un trunk da 200 è come non avere ridondanza.
Dubito che 2gbit entrino in 200mbit, anche se mooolto lentamente.

Post by Luca Sasdelli [MVP]

Post by Alessandro
il router ad un singolo armadio (supponiamo che il secondo armadio non
esista), il trunk tra gli switch per il motivo esposto sopra è
fondamentale giusto?)

Esatto.

Ok, quindi nel primo caso il trunk è fondamentale, nel secondo, quello
che si andrà ad attuare con 2 rack
il trunk non serve perchè entrambi gli switch di rack saranno sempre
collegati al centro stella.
Dovrebbero andare giù due collegamenti alla volta per aver necessità
di trunking ovvero il collegamento con il router ed
il collegamento con un centro stella lato edge.

Post by Luca Sasdelli [MVP]
Pero' hai detto che sono dual-homed, per cui avrai 40 nodi per armadio.

No.
20 server dualhomed = 20 porte per uno switch + 20 porte per un altro
switch.

Tenendo conto che 20 nodi saranno sempre down in condizioni normali.

Post by Luca Sasdelli [MVP]
Dicevo di sostituire il tutto usando un solo centro stella a 96 porte,
meglio se realizzato con uno stack per via della ridondanza a livello
di unita'. In questo modo si semplifica tutta la gestione delle
ridondanze e si massimizza la banda passante del sistema.

96 porte in stack ovvero 2 switch da 48.
Sono comunque troppi perchè tra i due armadi esco con due uplink
gigabit ovvero 2 porte per ogni armadio.
In totale 4 porte (considerando i due armadi).

In sostanza, ogni armadio necessita di 2 porte, se gli armadi fossero
più di 12 sarebbero necessarie 48 porte
ma finchè rientro entro i 12 (e ci sono dentro di molto), avrei porte
inutilizzate.

Tieni conto che le due porte di ogni rack sono riferite ad un singolo
switch, questo significa che avrò due switch di centro stella
da 24 porte l'uno per avere totale ridondanza.

Post by Luca Sasdelli [MVP]

Post by Alessandro
L'importante è che si possa mettere in piedi una rete ridondata senza
tirare in ballo STP, il quale andrebbe configurato e mi porterebbe
via del tempo.

LACP gia' lo fa, dato che gestisce da solo sia STP, sia 802.3ad.

Conosco un po LACP, o per lo meno quanto indicato dal manuale HP, ma
non mi pare ci sia scritto che gestisca da solo STP.

Aggregando le porte in una unica porta logica, stp non è necessario in
quanto non ci sarebbe ridondanze.

Però nel caso di struttura a 4 livelli come quella che andrò a fare,
io avrò:

NON posso usare LACP sugli edge e sui centro stella in quanto NON
essendo in stack, lacp non sarebbe in grado di aggregare le porte di
due switch distinti.

Non si generano dei loop così facendo? Ogni switch avrà due uplink...

[Luca Sasdelli [MVP]]

Post by Alessandro
No.
20 server dualhomed = 20 porte per uno switch + 20 porte per un altro
switch.

Ragionavo in termini complessivi, ovvero 20 server dualhomed per due
armadi, *tutti* facenti capo al medesimo switch. In soldoni, eliminare
i 5 switch attuali e fare tutto nel centro stella con uno stack di due
macchine da 48 x 10/100/1000Mbps.

Post by Alessandro
Conosco un po LACP, o per lo meno quanto indicato dal manuale HP, ma
non mi pare ci sia scritto che gestisca da solo STP.

In genere negli switch LACP sovrintende a STP, poiche' deve poterne
gestire il funzionamento sui membri dei trunk.

Ciao
Luca

[Alessandro]

Post by Luca Sasdelli [MVP]

Post by Alessandro
No.
20 server dualhomed = 20 porte per uno switch + 20 porte per un altro
switch.

Ragionavo in termini complessivi, ovvero 20 server dualhomed per due
armadi, *tutti* facenti capo al medesimo switch. In soldoni, eliminare
i 5 switch attuali e fare tutto nel centro stella con uno stack di due
macchine da 48 x 10/100/1000Mbps.

Be, ma così facendo la soluzione è meno scalabile.
Se un giorno dovesse arrivare un terzo armadio, rimarrei senza prese.
Invece, nel mio caso, basterebbe acquistare altri 2 hp 2626 (che hanno
garanzia a vita quindi in
futuro potrei usarli come soprammobili) e connetterli al centro stella
attuale.

La soluzione senza edge ma solo con un unico grosso switch non mi ha
mai convinto.
Sia per il costo del grosso switch (che va comprato subito, e non solo
in caso di necessità) sia per
l'affidabilità che deve avere tale switch. Nella mia soluzione, se si
dovesse rompere un 2626 da 24 porte
potrei correre al mediaworld (esempio banale) e comprare uno switch da
50 euro da rimpiazzare per 1 giorno.

Se si rompe il centrostella modulare (dato che comprare un 48 porte
quando ne userò da subito 40 non è motlo furbo)
resto a piedi fino alla sostituzione. Senza contare che il 48 porte
modulare costa come 10 24 porte non modulari.

i 10 24 porte li compro a mandate di 2 a 2, il 48 porte lo compro
subito.

E' proprio un problema logistico-economico del cliente.

Post by Luca Sasdelli [MVP]
In genere negli switch LACP sovrintende a STP, poiche' deve poterne
gestire il funzionamento sui membri dei trunk.

Io pensavo di collegare ciascun 2626 ad entrambi i centrostella, ma le
due porte uscenti da ciascun 2626
non possono essere messe in trunk (ne statico ne LACP) in quanto
dall'altra parte (il centro stella) non ci sarebbe
alcun trunk da configurare (il 2626 arriva su ogni centrostella
mediante una sola porta)

In questo modo, senza LACP, non si verificherebbero dei loop?

[Luca Sasdelli]

Post by Alessandro
Be, ma così facendo la soluzione è meno scalabile.

No: se leggi bene parlavo di 2 switch da 48 porte stackabili.

Post by Alessandro
Se un giorno dovesse arrivare un terzo armadio, rimarrei senza prese.

Aggiungi un componente allo stack (in genere fino ad 8). Ci sono in
giro sistemi modulari con bus stack da 40Gbps e oltre.
Lo stack e' nato proprio per ovviare alle problematiche del modulare
che indichi.

Ciao
Luca

[Alessandro]

Post by Luca Sasdelli
No: se leggi bene parlavo di 2 switch da 48 porte stackabili.
Aggiungi un componente allo stack (in genere fino ad 8). Ci sono in
giro sistemi modulari con bus stack da 40Gbps e oltre.
Lo stack e' nato proprio per ovviare alle problematiche del modulare
che indichi.

O capito cosa intendi.
La soluzione è sicuramente corretta, ma se provo a dire di cambiare i
4 2626 attuali ed il centro stella quelli mi uccidono.
Sopratutto quando uno solo dei due switch necessari supera di molto le
3500 euro.

Devo trovare il modo di ridondare la rete con gli switch attuali.
Chiaro che potendo spostare tutto dagli edge attuali al centro stella
il mio post non avrebbe avuto ragione di esistere.
Il problema da cui non riesco ad uscire è come collegare i 2626 al
centrostella senza creare loop e preferibilmente senza usare RSTP che
non conosco.

[Luca Sasdelli [MVP]]

Post by Alessandro
Il problema da cui non riesco ad uscire è come collegare i 2626 al
centrostella senza creare loop e preferibilmente senza usare RSTP che
non conosco.

La ridondanza puoi gestirla con STP o (meglio) LACP; certamente ti
occorre affidarti ad un protocollo che eviti il formarsi di loop.

Se tutti i tuoi switch supportano LACP, ti consiglio di dare
un'occhiata a questo protocollo; in teoria fa tutto da solo (trunking,
ridondanza), ma possono verificarsi delle incompatibilita' fra marche
diverse. Se puoi fare qualche prova, almeno puoi vedere se affidarti
completamente a questa soluzione.

In alternativa puoi usare STP/RSTP, che pero' non funziona di concerto
con il trunking, per cui, nel tuo caso, porta a creare colli di
bottiglia.

Se LACP non fosse applicabile e STP/RSTP fosse troppo lento durante il
failover, non vedo una via d'uscita efficace.

Tempo fa cercavo delle NIC multiporta con la gestione hardware di
LACP/802.3ad ma non ho trovato nulla; se esistesse un componente del
genere, si potrebbe mettere insieme una macchina con Vyatta
www.vyatta.com e integrarla al centro stella.

Ciao
Luca

[Alessandro]

Post by Luca Sasdelli [MVP]

Post by Alessandro
Il problema da cui non riesco ad uscire è come collegare i 2626 al
centrostella senza creare loop e preferibilmente senza usare RSTP che
non conosco.

La ridondanza puoi gestirla con STP o (meglio) LACP; certamente ti
occorre affidarti ad un protocollo che eviti il formarsi di loop.

Continuo a non capire in che modo LACP possa aiutarmi.
Stando a quanto dice google ed a quanto dice il manuale HP, LACP
permette
di aggregare due porte formando una unica porta virtuale.
Dal punto di vista dello switch quindi non sarebbe un percorso doppio
ma un singolo collegamento ridondante.
Il mio problema non è ridondare il collegamento tra lo switch A e lo
switch B con più cavi ed aggregarne la banda
ma bensi quello di collegare, mediante due canali singoli lo switch A
allo switch B ed allo switch C.
LACP in questo caso non può funzionare in quanto switch B e switch C
sono due unità distinte, non stackable
e quindi LACP non potrebbe aggregare un bel nulla.

Se il centrostella fosse in stack (Stackwise cisco e no stack virtuale
HP) allora potrei fare quello che dici
in quanto lato centrostella potrei aggregare via LACP le porte
posizionate su due switch distinti ma connessi tra
loro mediante stack.

Purtroppo non ho questa possibilità.
Devo mettere in piedi due collegamenti distinti, graficamente intendo
la classica configurazione con i 4 cavi incrociati.

LACP proprio non vedo dove possa essere utile.

Post by Luca Sasdelli [MVP]
Se tutti i tuoi switch supportano LACP, ti consiglio di dare
un'occhiata a questo protocollo; in teoria fa tutto da solo (trunking,
ridondanza), ma possono verificarsi delle incompatibilita' fra marche
diverse. Se puoi fare qualche prova, almeno puoi vedere se affidarti
completamente a questa soluzione.

Si lo supportano e sono tutti dello stesso fornitore ma per i motivi
di cui sopra non penso sia utilizzabile.

Post by Luca Sasdelli [MVP]
In alternativa puoi usare STP/RSTP, che pero' non funziona di concerto
con il trunking, per cui, nel tuo caso, porta a creare colli di
bottiglia.

Perchè no?
Dovrei fare un trunk tra i due canali, poi RSTP vedrebbe tale trunk
come una singola porta.
Se internamente al trunk dovesse andare giù un link, rimarrebbe
comunque attivo l'altro e RSTP non dovrebbe
cambiare alcuna topologia di rete.

Post by Luca Sasdelli [MVP]
Se LACP non fosse applicabile e STP/RSTP fosse troppo lento durante il
failover, non vedo una via d'uscita efficace.

STP non lo considero nemmeno, 50 secondi son troppi.
RSTP ha convercenza molto minore, dicono interno ai 2 secondi, direi
che è una possibile alternativa.

Quello che non so, è se deve essere configurato o meno.
Ho letto un po ovunque che al 99.9% dei casi basta attivarlo (una riga
di conf, massimo due) ed i parametri
che mette in automatico sono già corretti.
Se così fosse, potrei fare tutti i miei collegamenti con RSTP attivo
senza dovermi preoccupare troppo di cosa
mettere in trunk o meno.

Se invece non dovesse essere così facile allora:
1) hai qualche howto o guida che spieghi bene come mettere in piedi
RSTP?
2) probabilmente dovrò optare per altre strade. non posso proporre al
cliente una soluzione che non conosco.
Non sarebbe professionale e non è proprio nel mio stile. In caso di
problemi poi, chi li risolve?

Post by Luca Sasdelli [MVP]
Tempo fa cercavo delle NIC multiporta con la gestione hardware di
LACP/802.3ad ma non ho trovato nulla; se esistesse un componente del
genere, si potrebbe mettere insieme una macchina con Vyattawww.vyatta.come integrarla al centro stella.

Be, almeno 2 macchine....
Ma perchè non software? Non puoi gestirlo via software?

[Luca Sasdelli [MVP]]

Post by Alessandro
Stando a quanto dice google ed a quanto dice il manuale HP, LACP
permette
di aggregare due porte formando una unica porta virtuale.

Piu' di due; spesso almeno quattro. Gestisce sia l'aggregazione di
porta che la ridondanza in caso di guasto.

Post by Alessandro
ma bensi quello di collegare, mediante due canali singoli lo switch A
allo switch B ed allo switch C.

Non credo si possa fare. Probabilmente ti conviene gestire la faccenda
da un lato con il bonding e dall'altro con RTSP sul centro stella,
lasciando gli switch di testa fuori da questa cosa. Comunque, e' uno
scenario che personalmente non mi piace.

Post by Alessandro
Quello che non so, è se deve essere configurato o meno.

Basta dare due diversi costi del path.

Post by Alessandro
Se così fosse, potrei fare tutti i miei collegamenti con RSTP attivo
senza dovermi preoccupare troppo di cosa
mettere in trunk o meno.

Questo si'.

Post by Alessandro
Be, almeno 2 macchine....
Ma perchè non software? Non puoi gestirlo via software?

Nei circuiti veloci mi fido poco delle soluzioni software.

Ciao
Luca

[Alessandro]

Post by Luca Sasdelli [MVP]
Piu' di due; spesso almeno quattro. Gestisce sia l'aggregazione di
porta che la ridondanza in caso di guasto.

Si si chiaro. Avevo semplificato volutamente.

Post by Luca Sasdelli [MVP]
Non credo si possa fare. Probabilmente ti conviene gestire la faccenda
da un lato con il bonding e dall'altro con RTSP sul centro stella,
lasciando gli switch di testa fuori da questa cosa. Comunque, e' uno
scenario che personalmente non mi piace.

Quello che dicevo io non si può fare già lo so. Si può solo in caso di
stack 'vero'.

Be, gli switch di testa saranno gestiti con il bonding, solo uno
switch sarà attivo, l'altro sta li ad aspettare.
Poi da ogni switch di testa partiranno due cavi gigabit (NON LACP per
i motivi di cui sopra: gli switch di centro non sono stack)
che andranno uno al primo centrostella e l'altro al secondo
centrostella.

La rete così facendo e ridondata, ma la limitazione in uplink è di
1gbit non potendo aggregare porte.
Così facendo, però, si formeranno dei loop che posso bloccare con
RSTP.

Post by Luca Sasdelli [MVP]

Post by Alessandro
Quello che non so, è se deve essere configurato o meno.

Basta dare due diversi costi del path.

Be, non è fondamentale giusto? I path hanno lo stesso costo nel mio
caso. I path sono identici, tutti collagano tutti allo stessa maniera.


Quindi o trovo il modo di fare uno stack tra i centrostella e quindi
lavoro con LACP (sia in testa rack che al centro stella) e lascio RSTP
spento
oppure lavoro SENZA trunking LACP ma attivo per forza RSTP per evitare
loop.

Dovrei aver chiarito tutto.
Purtroppo, nel mio caso, devo usare RSTP dato che i centri stella non
li posso cambiare con switch stackable.


La soluzione non piace molto neanche a me, anche se tecnicamente non è
sbagliata, semplicemente non è la migliore.
Preferirei la tua soluzione con gli unici centrostella stackable (o a
chassis) ma:

1) il posto in cui devo fare sto lavoro potrà contenere AL MASSIMO 8
armadi (limiti fisici, il 9 non ci sta) per un totale, quindi di 16
switch 2626 di testa
2) a pieno regime, con 8 armadi (non ci arriveranno *MAI*) avrò: 16
switch da 300 euro e 2 centrostella da 2000. Totale: 6800 euro per 160
server ed un totale di 192 porte 10/100

La tua soluzione, invece, prevede un doppio switch stackable dal costo
(del singolo e non la coppia) pari a tutta la mia soluzione precedente
(euro più euro meno) per avere solo 48 porte.

E' vero, è una soluzione più performate, la tua, ma non posso proporre
una ferrari ad un cliente che al momento ha un solo switch 10/100 di
classe 'mediaworld'. Non so se mi spiego.....

Intanto cambio la topologia, facendo livelli multipli con
centrostella, poi in futuro, si potranno cambiare i due switch di
centro tenendo conto che gli HP attuali e previsti hanno garanzia a
vista quindi saranno sempre riciclabili.

[Luca Sasdelli [MVP]]

Post by Alessandro
La rete così facendo e ridondata, ma la limitazione in uplink è di
1gbit non potendo aggregare porte.
Così facendo, però, si formeranno dei loop che posso bloccare con
RSTP.

Esatto.

Post by Alessandro
Be, non è fondamentale giusto? I path hanno lo stesso costo nel mio
caso. I path sono identici, tutti collagano tutti allo stessa maniera.

Si', ma dando un path cost diverso puoi definire a priori il trunk
primario e quello secondario, cosa che semplifica un tantino se per
caso RSTP dovesse avere qualche "incertezza" sulla scelta.

Post by Alessandro
1) il posto in cui devo fare sto lavoro potrà contenere AL MASSIMO 8
armadi (limiti fisici, il 9 non ci sta) per un totale, quindi di 16
switch 2626 di testa

Quindi, potenzialmente, 160 server in bonding = 320 porte. Ci vorra'
uno stack di 8 macchine da 48, ma si puo' fare. E' anche pensabile un
mix di macchine sia fastethernet che gigabit sul medesimo stack, tanto
per tagliare un po' i costi.

Post by Alessandro
una ferrari ad un cliente che al momento ha un solo switch 10/100 di
classe 'mediaworld'. Non so se mi spiego.....

Classe "mediaworld" con 40 server ed una prospettiva di averne fino a
160? A parte che, con tutta probabilita', gia' con 3-4 macchine da 48
e' possibile avere una special quotation da uno dei tre brand che
indicavo, ma forse e' meglio se metti costui davanti al fatto che ti
sta chiedendo una configurazione fault-tolerant (critico) su gigabit
(critico), con decine di server (critico) su una rete un po' da
equilibrismi.

Post by Alessandro
centro tenendo conto che gli HP attuali e previsti hanno garanzia a
vista quindi saranno sempre riciclabili.

Si', questo e' vero, ma a me sembra che il tuo Cliente stia viaggiando
su binari non coerenti: compra la Ferrari e ci va sullo sterrato? :-)

Ciao
Luca

[Alessandro]

Post by Luca Sasdelli [MVP]
Classe "mediaworld" con 40 server ed una prospettiva di averne fino a
160? A parte che, con tutta probabilita', gia' con 3-4 macchine da 48
e' possibile avere una special quotation da uno dei tre brand che
indicavo, ma forse e' meglio se metti costui davanti al fatto che ti
sta chiedendo una configurazione fault-tolerant (critico) su gigabit
(critico), con decine di server (critico) su una rete un po' da
equilibrismi.

No, lo switch attuale è mediaworld.
Quelli che propongo io non sono enterasys, ma non sono nemmeno
mediaworld.
Gli HP vanno bene, hanno meno funzioni dei cisco ma costano anche 4
volte meno.

La rete non deve essere gigabit, questo l'hai detto tu.
Io prendo switch 10/100 più che abbondanti.
Il mio problema, inizialmente, era se fare o meno un trunk gigabit
verso il centrostella e verso i router internet o se preferire
un trunk tra gli switch di testa gigabit e 200mbit verso il
centrostella.
Tutto qui.

Ma alla fine farò dei semplici uplink (non posso fare trunk) gigabit
verso il centro stella e niente trunk tra gli switch di testa.

Post by Luca Sasdelli [MVP]
Si', questo e' vero, ma a me sembra che il tuo Cliente stia viaggiando
su binari non coerenti: compra la Ferrari e ci va sullo sterrato? :-)

Non vuole comprare la Ferrari. E' quello che stavo cercando di dire.
Tu proponi Enterasys o simili, soluzione unica con almeno 2 in stack
da 48 porte.
Quella è una Ferrari.
Per il cliente attuale è troppo.

Una via di mezzo è la scelta di HP (che ripeto, non fanno schifo, sono
ottimi switch) che han garanzia a vita
e la realizzazione di una topologia 'seria' sostituendo l'attuale
switch mediaworld.

In futuro, dopo aver fatto la topologia di rete come si deve, si può
eventualmetne pensare a degli switch di classe superiore.

Io credo che bisogna prima fare le fondamenta. E fare le fondamenta
considerato la situazione attuale del cliente significa
prendere degli switch più seri ed affiancarli ad una struttura
multilivello come si deve.

[ObiWan]

Post by Alessandro
Una via di mezzo è la scelta di HP (che ripeto, non fanno schifo, sono
ottimi switch) che han garanzia a vita e la realizzazione di una

topologia

Post by Alessandro
'seria' sostituendo l'attuale switch mediaworld.

gli HP vanno bene... se devi gestire traffico di tipo "office" con
volumi
non "importanti", in caso contrario si "siedono" e le prestazioni degli
HP non sono neanche lontanamente comparabili con quelle fornite
dai brand suggeriti da Luca; se proprio vuoi risparmiare senza però
rinunciare alle prestazioni, potresti anche orientarti su switches SMC
(si .. anche quelli hanno garanzia A VITA); considera che implementare
tutto usando degli switches non all'altezza e poi "ripensare agli switch
in un secondo momento" significa non solo far spendere molto di più
al cliente, ma fornirgli una prima soluzione già sottodimensionata e
che presenterà una serie di problemi, non ultimo quello relativo alle
performances generali

come ha già tentato di dirti più volte Luca... ripensaci !

ciao

[Alessandro]

Post by ObiWan
gli HP vanno bene... se devi gestire traffico di tipo "office" con
volumi
non "importanti", in caso contrario si "siedono" e le prestazioni degli
HP non sono neanche lontanamente comparabili con quelle fornite
dai brand suggeriti da Luca; se proprio vuoi risparmiare senza però
rinunciare alle prestazioni, potresti anche orientarti su switches SMC
(si .. anche quelli hanno garanzia A VITA); considera che implementare
tutto usando degli switches non all'altezza e poi "ripensare agli switch
in un secondo momento" significa non solo far spendere molto di più
al cliente, ma fornirgli una prima soluzione già sottodimensionata e
che presenterà una serie di problemi, non ultimo quello relativo alle
performances generali
come ha già tentato di dirti più volte Luca... ripensaci !

Considera che l'uso che ne dovranno fare è di tipo office, come tu
dicevi.
Hanno molti applicativi da usare via web da remoto.
Una sorta di webfarm ma con scopi 'privati'.
La limitazione è data sempre dalla banda internet che è ovviamente ben
inveriore dai 100mbit di ogni switch.
Ora, probabilmente mi sbaglierò, ma se da fuori arriva un traffico che
nei picchi può essere di 8mbit (due linee da 4mbit)
dubito di saturare gli switch.

Per gli SMC dovrei trovare un rivenditore ma dubito abbiano il costo
di 300-350 euro per un 100mbit da 24porte + 2 giga.

Considera che le prestazioni HP sono quasi equivalenti (se non uguali
del tutto) a cisco.
E con cisco ci sono progettate quasi tutte le farm in italia. Se tali
farm non hanno problemi di traffico sicuramente io ne avrò ancora
meno.

Di certo non utilizzerei HP per connettere una SAN ethernet in cui la
banda passante è tutto oppure connettere più server tra loro che
spostano grossi volumi di dati.

[Luca Sasdelli [MVP]]

Post by Alessandro
E con cisco ci sono progettate quasi tutte le farm in italia. Se tali
farm non hanno problemi di traffico sicuramente io ne avrò ancora
meno.

Forse c'e' un motivo per cui molte farm stanno migrando da Cisco a
Extreme o Enterasys. Del resto, ai corsi per CCNA o CCDA, sono gli
stessi uomini Cisco ad ammettere che i loro switch sono poco
performanti.

Post by Alessandro
Di certo non utilizzerei HP per connettere una SAN ethernet in cui la
banda passante è tutto oppure connettere più server tra loro che
spostano grossi volumi di dati.

Nemmeno Cisco ce la fa :-)
Gli switch Cisco sono completamente gestiti dal software, col risultato
che basta qualche feature pack e la banda passante scende in verticale.

Ciao
Luca

[Alessandro]

Post by Luca Sasdelli [MVP]
Forse c'e' un motivo per cui molte farm stanno migrando da Cisco a
Extreme o Enterasys. Del resto, ai corsi per CCNA o CCDA, sono gli
stessi uomini Cisco ad ammettere che i loro switch sono poco
performanti.

Poco performanti cosa significa?
A quanto si saturano?
Ed il problema è dello switch o delle singole porte?
Cioè, uno switch con connessi 10 server, si satura nello stesso tempo
rispetto allo stesso switch con le 24 porte al completo?
(a parità di tipologia di traffico).

Post by Luca Sasdelli [MVP]

Post by Alessandro
Di certo non utilizzerei HP per connettere una SAN ethernet in cui la
banda passante è tutto oppure connettere più server tra loro che
spostano grossi volumi di dati.

Nemmeno Cisco ce la fa :-)
Gli switch Cisco sono completamente gestiti dal software, col risultato
che basta qualche feature pack e la banda passante scende in verticale.

Ben appunto, non lo farei mai.
Ma non è questo il caso.

Se la connessione esterna ad internet è MASSIMO 8 mbit, potrò mai
riuscire a saturare gli switch?
Dubito fortemente.

Anche se il cliente avesse due connessioni da 34 o 50 mbit l'una
dubiterei riuscirebbe a saturare gli switch.

Il traffico interno tra i server, come dissi nel post originale, è
presente, ma giusto query sql tra un server con applicativi web e il
rispettivo server mysql.

Ai voglia a fare query per saturare uno switch....

[Luca Sasdelli [MVP]]

Post by Alessandro
Poco performanti cosa significa?
A quanto si saturano?

Al 40% della banda passante aggregata nominale: questo e' lo standard
dichiarato e insegnato ai corsi di certificazione. Il grosso guaio e'
che questa "norma" viene osservata da quasi tutti i produttori di
switch, che si allineano ben volentieri a questo livello.

Post by Alessandro
Ed il problema è dello switch o delle singole porte?

E' proprio del *core* dello switch, nemmeno dello switching fabric.
Il fatto di usare IOS per la configurabilita' determina un lavoro
prettamente di CPU; Enterasys, Extreme e Nortel producono switch con
quasi tutto il path dei frame gestito hardware proprio per questo.

Ci sono prove comparative di Extreme che mostrano switch Cisco la cui
banda passante aggregata, a seconda dei feature pack installati, scende
da alcune decine di Gbps a 3.

Post by Alessandro
Cioè, uno switch con connessi 10 server, si satura nello stesso tempo
rispetto allo stesso switch con le 24 porte al completo?
(a parità di tipologia di traffico).

Esattamente.

Ciao
Luca

[Luca Sasdelli [MVP]]

Post by Luca Sasdelli [MVP]
Ci sono prove comparative di Extreme

Scusa: Foundry Networks.

Ciao
Luca

[Alessandro]

Post by Luca Sasdelli [MVP]

Post by Alessandro
Cioè, uno switch con connessi 10 server, si satura nello stesso tempo
rispetto allo stesso switch con le 24 porte al completo?
(a parità di tipologia di traffico).

Esattamente.

Quindi dei 100mbit per porta ne potrei usare solo 40?

Io con un dlink semimanaged via web, dei 100mbit ne uso 80-88.
E lo posso testimoniare con un trasferimento di un file da un pcA ad
un pcB che copia
a bene 10-11mbit.

considera l'overhead tcpip

Oppure questa problematica capita solo su switch managed tipo cisco?
Perchè in tal caso, gli HP hanno 1/10 di features rispetto a
cisco......

[Luca Sasdelli [MVP]]

Post by Alessandro
Quindi dei 100mbit per porta ne potrei usare solo 40?

E' un valore *medio*, per giunta annunciato; non so quanto possa essere
40, oppure 50 ... Comunque si riferisce al traffico aggregato di tutta
la macchina, per cui prendiamo i 24Gbps dichiarati dal vendor e
consideriamo di poter contare con sicurezza solo su 10Gbps, da
ripartire fra tutte le conversazioni in atto in un dato istante.

Post by Alessandro
Io con un dlink semimanaged via web, dei 100mbit ne uso 80-88.

Devi fare il conto complessivo, es. 24 porte 100Mbps tutte con lo
stesso carico nel medesimo istante; e' una valutazione di banda
aggregata, non di velocita'.

Post by Alessandro
Oppure questa problematica capita solo su switch managed tipo cisco?

Cisco, 3Com, HP, Netgear, AT, D-link e cosi' via.

Ciao
Luca

[Alessandro]

Post by Luca Sasdelli [MVP]
Devi fare il conto complessivo, es. 24 porte 100Mbps tutte con lo
stesso carico nel medesimo istante; e' una valutazione di banda
aggregata, non di velocita'.

Prima hai detto che 10 porte si saturano ugualmente come se fossero
24.
Se uno switch ha 24porte da 100mbit per un totale di 24gbit di banda
passante,
supponendo che al 50% si satura, io potrei sempre contare su 12gbit
disponibili
ovvero 100mbit per 12 porte.

[Luca Sasdelli [MVP]]

Post by Alessandro
Se uno switch ha 24porte da 100mbit per un totale di 24gbit di banda
passante,
supponendo che al 50% si satura, io potrei sempre contare su 12gbit
disponibili
ovvero 100mbit per 12 porte.

Beh, a parte l'errore x10 ;-) (100Mbps x 12 = 1.2Gbps, non 12Gbps), e'
piu' o meno quello che accade nella maggior parte degli switch in
commercio.
Cio' non deve apparire una scorrettezza da parte dei fabbricanti: Cisco
(e altri) osservano il proprio installato, considerano il traffico
medio e da quei numeri estraggono questi dati. Tutto sta nel prenderne
atto e dimensionare le macchine considerando anche questo non
indifferente aspetto.

Ciao
Luca

[Alessandro]

Post by Luca Sasdelli [MVP]
Beh, a parte l'errore x10 ;-) (100Mbps x 12 = 1.2Gbps, non 12Gbps), e'
piu' o meno quello che accade nella maggior parte degli switch in
commercio.
Cio' non deve apparire una scorrettezza da parte dei fabbricanti: Cisco
(e altri) osservano il proprio installato, considerano il traffico
medio e da quei numeri estraggono questi dati. Tutto sta nel prenderne
atto e dimensionare le macchine considerando anche questo non
indifferente aspetto.

Errore a parte, quindi 10 porte si saturano più difficilmente rispetto
a 24.
Tu prima hai detto il contrario.

Però, resto sulla mia tesi: non devo collegare una san in fibra, ma
semplicemente dei server che eseguono query mysql.
Sono più che convinto che non arriverò MAI nemmeno a META' del valore
effettivo di banda.

Anche perchè poi per saturare lo switch bisogna che tutti i server
facciano traffico pesante, costantemente, fino a saturarlo.
La natura di applicativi web rende pressochè impossibile questa cosa
in quanto non si tratta di straming costante ma tante piccole
sessioni.
E tra una sessione e l'altra lo switch si libera.

[Luca Sasdelli [MVP]]

Post by Alessandro
Errore a parte, quindi 10 porte si saturano più difficilmente rispetto
a 24.

Non ti seguo.
Lo switch ha a disposizione una certa potenza di calcolo;
semplicemente, non e' sufficiente a servire tutte le porte nei picchi
di traffico. Pertanto, in uno switch da 24 porte, probabilmente se ne
usi solo 10 potrai sfruttare convenientemente la banda del backpklane;
se ne usi 24, no.

Post by Alessandro
Tu prima hai detto il contrario.

Sicuro? Probabilmente non mi sono espresso bene :)

Post by Alessandro
Sono più che convinto che non arriverò MAI nemmeno a META' del valore
effettivo di banda.

Ma infatti e' cosi', e i dati di Cisco sotto questo punto di vista sono
realistici.

Post by Alessandro
Anche perchè poi per saturare lo switch bisogna che tutti i server
facciano traffico pesante, costantemente, fino a saturarlo.

E' quello che accade presso i nostri Clienti, da cui la scelta di
costruttori di switch con gestione hardware del trasporto dei frames.

Ciao
Luca

[Alessandro]

Post by Luca Sasdelli [MVP]
Sicuro? Probabilmente non mi sono espresso bene :)
Cioè, uno switch con connessi 10 server, si satura nello stesso tempo
rispetto allo stesso switch con le 24 porte al completo?
(a parità di tipologia di traffico).
Esattamente.
E' quello che accade presso i nostri Clienti, da cui la scelta di
costruttori di switch con gestione hardware del trasporto dei frames.

Allora ricominciamo da zero.

Ho aperto il thread chiedendo consigli su una topologia di switch (e
non sulla marca/modello)
Ho anche aggiunto che in un rack ci saranno server ad uso web
(applicativi web)
l'altro armadio invece è composto prevalentemente da server database.

I due armadi dovranno dovranno comunicare tra loro, mediante query
sql.

Io ero indeco se fare un trunk verso il centrostella (e quindi verso
internet e verso l'altro armadio) a gigabit oppure
mettere in trunk i due switch tra loro via gigabit.

Considerata la tipologia di traffico che dovrò affrontare, considerata
la situazione attule: switch da supermercato
inserire degli HP con una struttura topologia a centrostella è
sicuramente un passo avanti.

Poi uno può essere o non essere concorde su marca e modello, ma
partendo dalle caratteristiche della mia rete
e consigliare enterasys o switch di fascia superiore a quella
enterprise (reputo i cisco fascia enterprise) mi sembra
più che un consiglio un modo per sviare un utente dal suo reale scopo.

Ripeto l'uso sarà web (applicativi web) quindi è pressochè impossibile
saturare i 100 mbit di ogni singola porta data la natura
del traffico HTTP.

Se lo scopo del cliente fosse stato quello di trasferire grosse moli
di dati da una parte all'altra allora o fare streaming pesante e
costante
non avrei sicuramente scelto hp ma avrei puntato a switch più
performanti.

[whiplash]

Post by Luca Sasdelli [MVP]
Nemmeno Cisco ce la fa
Gli switch Cisco sono completamente gestiti dal software

In quale secolo, di preciso?

[Luca Sasdelli]

Post by whiplash
In quale secolo, di preciso?

:-)
Per conservare la versatilita' di IOS, gli switch Cisco processano gran
parte del traffico dei frames sulla CPU, che gestisce anche il
funzionamento dello switching fabric. A seconda del carico di CPU,
possono esserci piu' o meno vistose cadute di prestazioni. Inoltre,
alcuni feature pack richiedono un upgrade della RAM proprio per questa
ragione.

Gli switch basati principalmente su hardware usano array di ASIC che
svolgono da soli i compiti di base, mentre la CPU deve solo
inizializzarne e monitorarne i parametri. Naturalmente e' piu'
difficile avere una configurabilita' fine-grained come Cisco.

Ciao
Luca

[whiplash]

Post by Luca Sasdelli

Post by whiplash
In quale secolo, di preciso?

:-)
Per conservare la versatilita' di IOS, gli switch Cisco processano gran
parte del traffico dei frames sulla CPU

A me risulta che anche i 2960 facciano switching in ASIC.
La cattiva fama di Cisco era più legata a router che effettivamente
facevano tutto in software, e si vedeva.

[ObiWan]

Post by Alessandro
Per gli SMC dovrei trovare un rivenditore

http://www.smc.com/index.cfm?event=whereToBuy&localeCode=EN_ITA

Post by Alessandro
ma dubito abbiano il costo di 300-350 euro
per un 100mbit da 24porte + 2 giga.

scegli un modello, guarda i datasheet

http://www.smc.com/index.cfm?event=viewCategory&localeCode=EN_ITA&cid=8

e poi guardati i prezzi

[ObiWan]

Post by Alessandro
O capito cosa intendi.

la "H" questa sconosciuta :) ... vabbè

Post by Alessandro
La soluzione è sicuramente corretta, ma se provo a dire di cambiare
i 4 2626 attuali ed il centro stella quelli mi uccidono.
Sopratutto quando uno solo dei due switch necessari supera di molto
le 3500 euro.

prova a metter giù un minimo di documentazione che spieghi per bene
le motivazioni relative a tale acquisto ed i benefici che ne deriveranno
nel tempo, enfatizzando il fatto che l'investimento si ammortizzerà nel
tempo garantendo di risparmiare tempo e denaro e permettendo una
maggiore espandibilità futura della rete senza costi aggiuntivi :)