Newsgroup: it.comp.reti.locali
Titolo: Data center & Rack

Ciao a tutti.
In settimana dovrebbero arrivare 2 armadi APC netshelter SX 42U.
Uno sarà dedicato esclusivamente al networking (patch panel+switch
+router+firewall etc) e l'altro esclusivamente ai server.
Poichè non vorrei ritrovarmi nella stessa situazione attuale (2 rack
molto incasinati con i cavi), avete qualche consiglio su come
strutturare il cablaggio nell'ottica di una futura espansione con un
3° armadio per server?
Al momento i 20-25 server presenti (tutti 1U) sono dotati di 3 schede
di rete (2 in trunk tra loro per i dati, 1 per il backup).
Pensavo ad una soluzione simile a questa:
4 patchpanel (4 per evitare di dover ricablare l'armadio all'aggiunta
del 24° server) da 24 porte su entrambi gli armadi (in questo modo
collego i 2 armadi tra loro)
dentro l'armadio server, collego ogni interfaccia alla relativa porta
del patch panel (tramite patchcord)
mentre dentro l'armadio networking collego ogni porta del patchpanel
al relativo switch e dagli switch entro nei 2 router.
E' corretto un approccio del genere o forse è meglio evitare i patch
panel e collegare direttamente server->switch tra i 2 armadi tramite
dei patchcord?
Tramite i patchpanel, se un giorno dovessi spostare i 2 armadi, dovrei
ricablare completamente le connessioni (a meno che non esistano
patchpanel con ingressi RJ sia frontali che posteriori ed in quel caso
basterebbe sostituire i cavi con quelli più lunghi)
Nel caso fosse corretta la soluzione con patchpanel, dove mi
consigliate di posizionarli? Tutti in alto occupando le prime 4U
oppure 2U in alto e 2U al centro per separare un po le cose? (19
server + 19 server)
Altra questione: i patch panel, meglio posizionarli posteriormente al
rack (e coprire il buco frontale con i pannelli) oppure posizionare
tutto frontalmente? Posizionarli frontalmente non mi sembra molto
sensato in quanto i server arrivano con i 3 cavi di rete dietro al
rack, quindi dovrei riportare tutti i cavi davanti (e poi, nel rack
attuale che andrò a sostituire, non mi si chiude la porta a causa
della curvatura dei cavi collegati al patch panel).
Grazie in anticipo.
Alessandro.

Ciao
1) centro stella usato per connettere direttamente i server.
in questo caso c'è poco da fare, patch panel dietro il rack sopra in
alto o a metà, in base a cosa è montato, i cavi vanno al rack del
network sul corrispettivo panel, fine
di solito l'elettricista incanala i cavi su un tubo corrugato
flessibile, lasciando abbondante scorta (molto abbondante), in modo
che se si deve spostare l'armadio è semplice farlo.
2) server connessi a switch connessi al centro stella
in questo caso hai molte più possibilità.
puoi installare lo switch direttamente nel rack dei server, collegando
solo gli uplink al centro stella.
in ogni caso l'elettricista mi passa un panel full tra gli armadi
(perche prevenire è meglio che curare) sempre con scorta abbondante e
con i cavi nel tubo corrugato.
piccole accortezze
tieni presente che a meta di solito c'è la console (davanti) e il kvm
switch dietro.
attenzione ai cavi del kvm, lascia stare quelli economici sono grossi
e rigidi, creano solo problemi.
personalmente mi trovo molto bene con avocent. il massimo sono i
modulari
2 sk di rete per server, bilancia i cavi sui panel, server 1, sk1 sul
panel 1, mentre per la sk2 usi il panel 2
bilancia anche le alimentazioni sulle mtu, in modo che puoi spegnerne
una senza spegnere i server.
per sk di backup cosa intendi, una sk "spenta" pronta a sostiture una
guasta, o una sk  separata per la gestione dei backup/salvataggi?
dato che in questo caso hai sicuramente una rete separata, allora
cablala direttamente sul rack dei server.
Ciao

 Ciao
Ciao e grazie.
P.S:
mi consigli un armadio da 600 o da 750mm di larghezza? Opterei per 
quello da 750, meglio un po più di spazio inutilizzato che non averne 
abbastanza per i cavi...
P.P.S: nel caso di server connessi a switch connessi al centro stella
tu dici di posizionare lo switch del rack nel rack stesso. Sempre 
posteriormente vero? Quindi in sostanza tutto il networking 
'obbligatorio' nel rack dei server deve/dovrebbe essere posizionato dietro?

 modulari
Ho guardato il sito avocent.
Devo dire che sono molto interessanti e nemmeno troppo costosi.
Pensavo di acquistare 3 avocent 2015 (o una roba del genere) da 16 porte 
l'uno, 2 dei quali, in cascata vanno nel rack dei server frontalmente 
(in questo modo copro i patchpanel che saranno sulla stessa unità ma nel 
dietro) e con un singolo cavo di rete li collego al 3° avocent situato 
nel rack per il networking.

'obbligatorio' nel rack dei server deve/dovrebbe essere posizionato dietro?
si, io di solito faccio cosi, il cablaggio ringrazia, poi al capo ced
devi spiegare perche ha speso 10M Euro di net,  e lui vede solo i
filler, ma questo è un'altro discorso ;)



ottima scelta ;)

 filler, ma questo è un'altro discorso ;)
Be, i filler sono ordinati. Meglio vedere i filler che vedere un 
gomitolo di cavi non trovi?

 10/100/1000, tra l'altro solo l2.
Non so che hai visto tu, ma io intendo questo: 
http://tinyurl.com/229x2t
Non è gigabit. ha 4 porte in fibra ma non è gigabit (non mi serve, la 
lina dati è 10mbit!)

gomitolo di cavi non trovi?
ovvio, il discorso è che uno che ha speso 10M euro in switch ecc
vorrebbe anche vederli, mettendoli dietro non sono a vista, e quindi
il capoced di solito protesta. 



quindi stai installando un isp.
e i server sono tutti webserver, non hai distinto dei server in base
alle applicazioni, db, servizi vari, ecc in questo caso devi avere
anche banda tra i server.
curiosita mia, non avete pensato ai server blade ??
Ciao



 curiosita mia, non avete pensato ai server blade ??
Strutturare un data center blade, oltre ai costi iniziali molto molto
molto superiori (tieni conto che ho già 20 server da riciclare insieme
ad altro materiale, non sto facendo tutto da zero) richiede alcune
tipologie di servizi, tra cui san in fibra o quant'altro per i dati
che attualmente non sono prensenti.
Il processo di ristrutturazione è più o meno il seguente:
1- ridondare tutto o il più possibile.
2- per poter fare il punto 1, devo cambiare switch e topologia di rete
3- per il punto 3, devo cambiare gli armadi, dato che quelli attuali
sono talmente incasinati e mal progettati da essere inutilizzabili
Fatti i 3 punti, e dopo aver ristrutturato il datacenter in maniera
'ottimale' si può procedere con la fase 4 ovvero: aggiungere un
ulteriore armadio predisposto per i blade assieme ad un armadio per la
san.
Per fare i blade dovrei acquistare comunque tutti gli armadio nuovi,
acquistare una san, rimpiazzare il core switch, ridondare mezzo mondo
etc etc etc. E dovrei farlo tutto in una volta il che è impensabile
senza spegnere tutto per qualche giorno. Invece con le mie 3 fasi,
riesco a ristrutturare tutto senza interrompere di molto la fornitura
dei servizi. (giusto il tempo di staccare una cavo alla volta dai
vecchi switch e metterlo nei nuovi)

 bobine, non mi sembra il caso.
Niente flottante qui. I cavi devono passare sul tetto del rack nelle 
apposite canaline APC.

 Osta, solo 6 gruppi, io ne devo aggregare 48 di porte !!! O sbaglio?
Mi rispondo da solo. Posso anche non aggregare le porte lato switch se 
lo faccio lato server.
Se va giů uno switch, resta comunque l'altro dato che entrambi gli 
switch sono collegati allo stesso server ed allo stesso core.
Anche perchč i cisco 3560 costano piů di 2500euro l'uno.

 euro come core attuale anche a costo di buttarli via tra qualche mese.
Una via di mezzo no?
Pigli dei 2960 (che costano piuttosto poco, tutto sommato), che per ora
usi come useresti gli zyxel, e che quando piglierai un apparato di
classe core/distribution "serio" (37xx, 65xx, quello che ti pare) vai ad
usare in trunk con quest'ultimo, come switch di armadio (chiamiamoli
"access" che fa più fico)...
- --
Skull & Bones (ER6n Silver)
Neo:  I know Sendmail!
Morpheus:  Show me.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (Darwin)
iD8DBQFGI3rT8THo01J+SBERAhrDAJ9HlmWdSi53kibuN6hqVr53wcKUFACdH9Gd
DSiGdoVmtTfogXxl1TMHrrw=
=T2HR
-----END PGP SIGNATURE-----

 "access" che fa più fico)...
WS-C2960-48TT-L
Ma non sono stackable...
Teoricamente, non dovrebbe essere necessario in quanto il bonding dovrei 
gestirlo direttamente dal server.
Ma il 2960, lo intendi come core, lasciando nel rack gli zyxel oppure 
fare sia core che rack sempre con il 2960? Nel caso di core, mi 
basterebbero 24 porte al momento (543 euro)


 basterebbero 24 porte al momento (543 euro)
Se vuoi ipotizzare una soluzione "riciclabile", se non intendi andare a
spendere troppo per tutta la infrastruttura, e se vuoi andare su Cisco,
e se non hai bisogno di gigabit ovunque, perchè no?
Attualmente lo usi come ti pare, come useresti uno switch-etto della mutua.
Quando decidi di passare ad una struttura più scalata e complessa, metti
a fare da centro stella una coppia di 3750G-24T: li usi per il routing
tra le VLAN,, li tieni in ridondanza con un'opportuna gestione di STP
per L2 e via HSRP per L3.
Nei rack ci cacci dei 2960, le cui porte gigabit vai ad usare per il
trunk di uplink (uno per ogni 3750).
E' una soluzione
- - tutto sommato poco costosa
- - funziona piuttosto bene (ho clienti dove questa soluzione è fatta con
  lo stampino)
- - è pienamente ridondata
- - scala piuttosto bene
Tutto IMHO, eh..
- --
Skull & Bones (ER6n Silver)
Neo:  I know Sendmail!
Morpheus:  Show me.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (Darwin)
iD8DBQFGI4Oh8THo01J+SBERAolAAJ93c7xfWggViM5MXA8j9ILSzsjEvQCfRGxQ
myjTHwT1IAuLwS1NFVTKAME=
=jhv4
-----END PGP SIGNATURE-----

 - - scala piuttosto bene
Pienamente ridondata. Ok per lo STP del core, ma gli switch del rack, si 
  'autoridondano' (passami il termine penoso) grazie al bondig 
realizzato direttamente sui server o sbaglio?
P.S: domanda da neofita: che nome prendono gli switch del rack collegati 
al core? Se non erro hai detto 'access' prima....

 al core? Se non erro hai detto 'access' prima....
E' la strutturazione/nomenclatura che professa Cisco, quantomeno.
Dividi la struttura in 3 livelli, definiti access, distribution e core.
Access ci attacchi solo server e applichi le prime policy (tipo: sta su
questa VLAN, accetto solo questo mac-address, ecc), e hanno uplink verso
i distribution.
Distribution mette in comunicazione i singoli switch access, e applichi
le policies rimanenti (ACL nelle comunicazioni tra VLAN, di norma).
Mantiene uplink verso i core.
Core fa il meno possibile ma cerca di farlo velocemente, quindi niente
ACL o roba del genere. Serve a fare da tramite nelle comunicazioni tra i
singoli distribution.
La struttura a 3 livelli la mantieni solitamente per reti più grosse, di
dimensione geografica (MAN, per dire, o campus complessi), dove il
traffico tra i singoli distribution è corposo, e quindi i "core"
rappresentano oggetti volti alla prestazione pura...
Nel tuo caso, di fatto distribution e core collassano in un unico
oggetto, nella struttura che ipotizzate.
- --
Skull & Bones (ER6n Silver)
Neo:  I know Sendmail!
Morpheus:  Show me.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (Darwin)
iD8DBQFGI4s98THo01J+SBERAshQAKCP7a7YEpn20n0k2TWvw6FT59iVVQCeMe6L
X9JHD/4PIrZ2uNx6tnxmAao=
=IKmi
-----END PGP SIGNATURE-----

 oggetto, nella struttura che ipotizzate.
A si, come ho scritto sopra. (non avevo ancora letto questa frase).
Comunque, per tornare un po più in topic, la struttura che è stata 
ipotizzata può andare bene anche per te?
Ricapitolando:
1 rack per networking dove ci stanno i router ed i core switch (con 
tutte le apparecchiature frontali).
1 rack per i server, con frontalmente le eventuali KVM, e posteriormente 
(in alto) i 2 access switch ridondati tramite bonding sui server. In 
aggiunta, sempre dietro e sempre in alto, lo switch di backup che 
viaggia per conto suo, collegato sempre al rack networking (non al core 
switch però).
Niente patchpanel in quando faccio tutto con uplink degli switch.
Il motivo di questo lungo (ed istruttivo) thread era appunto quello di 
evitare di ritrovarmi con un datacenter pieno di cavi arrotolati come 
spaghetti solo perchè le apparecchiature sono disposte male.

 spaghetti solo perchè le apparecchiature sono disposte male.
Tanto accade lo stesso... :-D
Di meno, ma accade...
- --
Skull & Bones (ER6n Silver)
Neo:  I know Sendmail!
Morpheus:  Show me.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (Darwin)
iD8DBQFGI5ul8THo01J+SBERAv/LAJ0U1/wz8x1JYkS+3uazDzayIkt7DgCgzfio
PEcfiVfu+f5tW78J6EDFLu4=
=nIc4
-----END PGP SIGNATURE-----

 Di meno, ma accade...
Vuoi forse venire a vedere qui? :)

 Vuoi forse venire a vedere qui? :)
Posso portare la macchina fotografica? :-D
- --
Skull & Bones (ER6n Silver)
Neo:  I know Sendmail!
Morpheus:  Show me.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (Darwin)
iD8DBQFGI6Ip8THo01J+SBERAiisAJ44mhVTqJyOL9gmAoQfg2nRdQmsqACdGc1E
K4H8eKUg4oy7O8dI79rCCU4=
=RVvO
-----END PGP SIGNATURE-----

 Posso portare la macchina fotografica? :-D
Porta anche una bella memory card su cui salvare le migliaia di foto che 
farai.
A prima vista, da davanti, è tutto in perfetto ordine (a parte la porta 
che non si chiude quindi è stata tolta), ma appena parti dietro vedi che 
  i cavi sono troppi e lo spazio troppo poco.
A te le conclusioni. Ed ecco perchè devo ristrutturare tutto.

mi hai tolto le parole da bocca, pardon le dita dalla tastiera
;)

Osta, solo 6 gruppi, io ne devo aggregare 48 di porte !!! O sbaglio?
stavo pensando al teaming/bonding e agli switch...
quando configuri il teaming puoi configurare la sk virtuale con le 2
sk il load balancing, oppure la 2° come backup della prima.
nel tuo caso, cosa succede se le configuri in load balancing??
i dati vengono trasmessi tramite entrambe le sk a due switch diversi
che poi devono smistare il tutto.
mi sa che stressi abbastanza il link dati tra gli switch. inoltre
verifica che l'aggregazione delle porte sia possibile anche tra
dispositivi diversi, non sarebbe la prima volta che vedo queste
funzioni abilitatre solo per le porte dello switch e non per quelli
collegati.
Ciao

Anche perchč i cisco 3560 costano piů di 2500euro l'uno.
mai visto vendere cisco a prezzo di listino. 
fatti fare un'offerta, ventilando il passagio a un centro stella ;)

 fatti fare un'offerta, ventilando il passagio a un centro stella ;)
Prezzo di listino? Questo è il prezzo da rivenditore mica di listino...
Listino = il doppio circa.

 collegati.
Non ne ho idea, comunque, su consiglio di skull, metto nei rack 2 cisco 
2960 da 48porte + 2 uplink giga in rame. (perň non nascondo che la fibra 
per l'uplink fa figo, molto molto figo)
e temporaneamente come core 2 2960 da 24 porte. In futuro, avendo gli 
uplink giga provenienti dai rack, posso sostituire il core con dei 37xx 
o 45xx gigabit in modo da aumentare la comunicazione intervlan.
Ritornado al discorso del "fa figo", avendo tutti gli uplink in fibra, 
dovrei anche avere uno switch 24 porte in fibra. Dal prezzo 
improponibile. Perň giusto per sognare: cisco fa switch 24/48 porte 
fibra? Giusto per vedere....

 per l'uplink fa figo, molto molto figo)
Se non erro, ci sono 2960 che hanno N (2? 4?) porte "ibride"
gigabit_rame/SFP.
Quindi intanto le puoi usare in rame, ed in un secondo momento inserire
un modulo SFP fibra di tua scelta e "far il figo"... :-P
- --
Skull & Bones (ER6n Silver)
Neo:  I know Sendmail!
Morpheus:  Show me.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (Darwin)
iD8DBQFGJIoG8THo01J+SBERAgD5AJ9QHhNiReLSPtqRmM7vf3RHQkpmfQCgsPw8
jkOdQf00E9Lh/zC/tASJOg0=
=UNmy
-----END PGP SIGNATURE-----

 andando a prendere un doc qualunque sulle vlan.
VTP è un protocollo che provvede a propagare il database delle vlan,
appunto. Se non lo usi, ogni switch ha un database locale...
- --
Skull & Bones (ER6n Silver)
Neo:  I know Sendmail!
Morpheus:  Show me.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (Darwin)
iD8DBQFGJIr98THo01J+SBERAju+AJ9npUXnSzqXaUcLaf5ZE62QLDUE9ACfUDxv
SvlN257kzQKulbpTnXpFTK8=
=bIuN
-----END PGP SIGNATURE-----

 un modulo SFP fibra di tua scelta e "far il figo"... :-P
Ma nei 2960 i moduli inseribili mi pare siano al massimo 1.
Da 4 porte. ne mancano altre 20....

 appunto. Se non lo usi, ogni switch ha un database locale...
Ecco appunto.
Allora le vlan dei rack č piů sensato gestirle nello switch rack.
Questo stavo dicendo ieri.

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Alessandro wrote:

Eppure son convinto di avere un 2960 con 20 porte Gbit rame + 4 miste
SFP/rame.
Non ho idea se ci sia un oggetto analogo anche per porte rame da 100...
Comunque tieni presente che al di là delle 1-2 porte fibra sugli switch
di rack, devi metter in conto che ti ritrovi un core interamente fibra.
Anche questo molto figo, ma i costi diventano alti (tra il differente
modello dello switch e il costo dei moduli, credo anche un 300% rispetto
alla soluzione "full rame").
Vedi tu...
- --
Skull & Bones (ER6n Silver)
Neo:  I know Sendmail!
Morpheus:  Show me.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (Darwin)
iD8DBQFGJI/18THo01J+SBERAsBOAJ4gI+wvUC4bE2mwJcakSGIlxM9nngCcCoOR
mJSfYLIieBoU39VdI/MNwY0=
=2D5a
-----END PGP SIGNATURE-----

 Allora le vlan dei rack è più sensato gestirle nello switch rack.
Eh, mica detto... :-P
Dipende da come desideri organizzare le VLAN e da cosa ti prefiggi di
ottenere da esse.
Facciamo un esempio che capita. Ad un certo punto, per questioni di
mancanza di spazio, per staffe balorde che non entran nell'armadio
attuale, per esigenze peculiari di alimentazione o per qualunque altra
ragione plausibile, ti ritrovi a mettere in un armadio diverso da quello
attuale un server che avresti dovuto mettere lì.
La VLAN su cui lo devi piazzare (diciamo la 37) è la stessa su cui hai
già N server attestati.
Che fai?
1) Metti il server nel rack 2 ma colleghi le NIC allo switch del rack 1
2) Metti il server in rack 2 su una VLAN distinta e fai degli
ingroppamenti da saltimbanco con routing/NAT e cazzilli vari per
"proiettarla" sulla VLAN dove doveva stare...
3) Hai la stessa VLAN sia sui rack che sul core, e trunk tra tutti gli
switck: attesti la macchina alla VLAN 37 dello switch del rack 2 e non
devi fare null'altro...
Chiaro che fino a che le VLAN da gestire sono al più una dozzina, e
- -soprattutto- gli switch son pochi, puoi anche creare le VLAN sui
singoli apparati alla bisogna, badando di garantire la coerenza solo per
le VLAN per cui tale coerenza serve.
Sennò, devi avere un meccanismo centralizzato che crea le VLAN su tutti
gli apparati...
Questo lo puoi fare -appunto- con scripting, oppure con VTP (che fa
anche molto altro... troppo altro, IMHO...).
Nothing more...
- --
Skull & Bones (ER6n Silver)
Neo:  I know Sendmail!
Morpheus:  Show me.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (Darwin)
iD8DBQFGJJT88THo01J+SBERAjBFAJ0RAnAIY6KoKn/3NayfDPS/jwNFQwCgxXp6
cWn4lLkN3x5Buikjo1H4cGA=
=n1GX
-----END PGP SIGNATURE-----

 Vedi tu...
Lo so che è impensabile, volevo solo vedere i prezzi. Giusto per curiosità.
Perchè effettivamente il core in fibra sarebbe bellissimo (ma non voglio 
farlo e non lo farò mai)

Ciao

il mio era un semplice suggeriento non sapendo a quale versione ti
riferisci ;)
Ciao

 devi fare null'altro...
Scusa, ma nel rack 2 avrò i miei bei cisco con rispettive vlan.
Quindi il server sulla U37, sarà dentro la vlan 37 del rack2.
Per quale motivo dovrei aver bisogno di attestare un server presente sul 
rack 2 in una vlan presente sul rack 1.
Attesto la 37 del rack2 e, se proprio devo unirle a quelle del rack1, le 
unisco tramite il core.
Il core, è in grado di 'identificare' con che vlan escono i server dallo 
switch vero?!?
Le gestisco dai vari access, poi quando arrivano al core, il core 
sicuramente è in grado di vedere di quale vlan fa parte il server e 
quindi lo unisco agli altri.


fibra? Giusto per vedere....
consiglio spassionato, la fibra è bella, la fibra è buona, ma ogni
tanto è una rogna.
nel senso che la fibra ha molti vantaggi rispetto al rame, ma ha anche
qualche sfiga in più di cui devi tener conto.
e il costo non è l'unico ;)
ps per mia esperienza la fibra la incanali _sempre_ nel corrugato, ti
eviti molti problemi 

> anche molto altro... troppo altro, IMHO...).
- --
Skull & Bones (ER6n Silver)
Neo:  I know Sendmail!
Morpheus:  Show me.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (Darwin)
iD8DBQFGJKB58THo01J+SBERAoovAJ4yRETUXr05gO/VCzbirnQXhLbXjgCfXFnL
gUnq4s00HXcqLjxHQNY/DcM=
=DLTF
-----END PGP SIGNATURE-----

>> anche molto altro... troppo altro, IMHO...).
Se poi lo scripting non dovesse andare piů bene, implementeri tutto 
tramite VTP.