Newsgroup: it.comp.reti.locali
Titolo: Ridondanza switch

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.

 di attivare RSTP sugli edge?
Non supportano LACP? Sarebbe l'ideale.
Ciao
Luca
-- 
Luca Sasdelli
Microsoft MVP - Server, Security

 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.

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

 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...

 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.


 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?

 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

 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.

 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.


 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 :)

 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?

 Ma perchè non software? Non puoi gestirlo via software?
Nei circuiti veloci mi fido poco delle soluzioni software.


 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.

 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? :-)


 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.

 '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

 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.

 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.


 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....

 (a parità di tipologia di traffico).
Esattamente.


 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

 Ci sono prove comparative di Extreme
Scusa: Foundry Networks.


 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......

 Oppure questa problematica capita solo su switch managed tipo cisco?
Cisco, 3Com, HP, Netgear, AT, D-link e cosi' via.


 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.

 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.


 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.

 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.


 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.

 Gli switch Cisco sono completamente gestiti dal software
In quale secolo, di preciso?

 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

 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.