DIACONO - Introduzione alla progettazione di un Data Center

Introduzione alla progettazione
di un Data Center complesso
Domenico Diacono
INFN-Bari
[email protected]
Corsi intensivi per APM GARR - Bari, Napoli,
Reggio Calabria, Catania
TIA
• La Telecommunications Industry Association nell’Aprile del 2005 ha
rilasciato il documento
TIA-942 Telecommunications Infrastructure Standard for Data Centers
progettato per essere usato fin dalle prime fasi della progettazione, ed
approvato dall’American National Standard Institute (ANSI)
• ANSI/NECA/BICSI 002 Data Center Design and Implementation Best
Practices
• La TIA-942 copre le seguenti aree:
1.
2.
3.
4.
Organizzazione dello spazio e layout del DC
Infrastruttura di cablaggio
Livelli di ridondanza ed affidabilità
Impatto ambientale
Site space and layout
Site space and layout
• Una corretta allocazione degli spazi deve garantire una riallocazione
semplice al crescere del DC: si tratta quindi di trovare un equilibrio
tra i costi iniziali e le previsioni di espansione futura.
• Il DC dovrebbe contenere una quantità ragionevole di «white
space» flessibile, lo spazio circostante dovrebbe anche essere
considerato in vista di una espansione.
• TIA-942 individua delle aree funzionali, che aiutano alla
sistemazione delle apparecchiature seguendo uno schema standard
a stella: seguire questa traccia permette di costruire un DC capace
di assorbire le crescite future con minimo downtime.
Functional area: ER
• Una o più Entrance Room (ER):
– E' uno spazio nel quale gli apparati di accesso del
fornitore di connettività (GARR?) si interfacciano con il
sistema di cablaggio interno del data center.
– Lo standard raccomanda si tratti di una stanza a parte,
in modo che un accesso per manutenzione possa
essere effettuato senza accedere all'interno della
computer room, che ospita i server di calcolo.
– Se viene realizzata all’interno della computer room
viene consolidata con la MDA
Functional area: MDA
• Una Main Distribution Area (MDA):
– La Main Distribution Area è uno spazio centrale nel quale è sistemato il punto
di distribuzione del cablaggio strutturato dell'intero datacenter.
– All'interno ospita i router e gli switch di core per LAN e SAN, e il Main Cross
Connect (MC), che può includere l'Horizontal Cross Connect (HC) nel caso in
cui le aree di calcolo siano servite direttamente dalla MDA.
– Questo spazio è l'hub della infrastruttura di cablaggio dell'intero DC, e come
tale contiene i router di core, gli switch di core della LAN, gli switch di core
della SAN.
– TIA-942 presenta la architettura cross-connect come la best-practice per
l'MDA: in questo sistema di patching centrale, tutti gli elementi di rete usano
dei cavi che hanno connessioni permanenti, terminate una volta per tutte.
Cross Connect
Tutte le operazioni possono essere effettuate sulle patch, facili da maneggiare e
intercambiabili, senza toccare il cablaggio orizzontale fatto da cavi permanenti già fissati
e terminati.
Questo schema permette anche di modificare rapidamente la rete, agendo sui pannelli
di distribuzione.
Cross Connect
• Lower operating costs:
Se confrontato con altre soluzioni, il cross-connect riduce il tempo
necessario per la manutenzione (aggiunta di schede, movimentazione di
circuiti, upgrade sw).
• Improved reliability and availability:
Le connessioni permanenti proteggono i cavi da attività quotidiane che li
possono danneggiare. Le operazioni Moves, Adds and Changes (MAC)
vengono eseguite solo sulle patch e non sul backplane di apparati di
routing e switching. Con le patch inoltre è possibile isolare facilmente un
circuito di rete.
• Competitive Advantage:
Un sistema Cross-Connect permette di effettuare rapidi cambiamenti allo
schema della rete. La connessione di un nuovo servizio può avvenire
mediante il plug di una patch, invece che con la posa di nuove connessione
cablate. Quindi è possibile avere un nuovo servizio più velocemente.
Functional Area: HDA
• Una o più Horizontal Distribution Area (HDA):
– È il punto di distribuzione del cablaggio orizzontale che
porta i cavi alla equipment distribution area.
– Come nella MDA lo standard prevede che ci siano rack
separati per fibre, UTP e cavi coassiali, e raccomanda di
prevedere switch e patch-panels per facilitare le operazioni
MAC.
– Il numero di connessioni in una HDA dovrebbe essere
limitato a 2000, il numero di HDA presenti dipende dal
cablaggio e dalla grandezza del DC (almeno una per piano)
Functional Area: EDA
• Una o più Equipment Distribution Area (EDA):
– Il cablaggio orizzontale termina con dei patch
panel nella EDA, che ospita i rack del DC.
– Lo standard prescrive l'installazione alternata di
rack e cabinet per la creazione di corridoi freddi e
corridoi caldi.
Functional Area: ZDA
• Una o più Zone Distribution Area (ZDA):
– La ZDA è un punto di connessione intermedio, opzionale,
nel cablaggio orizzontale tra HDA ed EDA.
– Agisce come punto di consolidamento del cablaggio, per
aggiungere flessibilità alla configurazione della rete, o
come zona dove far risiedere mainframe o server che non
possono essere usati con i patch panel.
– All'interno di una HDA è ammessa una sola ZDA, con un
massimo di 288 connessioni.
– La ZDA non contiene cross connect o apparati attivi.
Backbone and Horizontal Cabling
• Il cablaggio di backbone all'interno del DC collega MDA, HDA ed ER
• Il cablaggio orizzontale fornisce connettività tra HDA, ZDA ed EDA: collega
la HC nella MDA o nella HDA alle prese ospitate nella EDA o ZDA.
• Per ridondanza è possibile installare del cablaggio di backbone opzionale
tra le HDA.
• Ogni area funzionale deve essere situata nel DC in modo che il cablaggio di
backbone e quello orizzontale non eccedano le massime lunghezze
consentite dalla tecnologia.
• La massima distanza orizzontale è 90m indipendente dal media type. Se
non esiste una HDA la massima distanza in un DC è 300m se si usa la fibra
ottica, e 100m per il cablaggio in rame
Supporto alle functional areas
• Tutte le aree qui identificate potrebbero
essere confinate in stanze fisicamente
separate tra loro (ma anche no).
• Nel caso si tratti di stanze chiuse, ognuna di
esse deve essere supportata da HVAC
(Heating, Ventilation e Air Conditioning), PDU,
e accesso al sistema UPS.
Reduced Topology
La Main Cross Connect e la Horizontal Cross Connect possono essere
consolidati in una singola MDA, e quel punto il disegno del datacenter
potrebbe ridursi:
Cabling Infrastructure
Star Topology
Il cablaggio non strutturato (ossia punto-punto con jumpers) rende le operazioni MAC
(Moves, Adds and Changes) molto più complesse.
La architettura Cross Connect, e l'uso di appropriati adattatori, permette di accomodare
nella topologia a stella anche sistemi pensati per topologie differenti (ring, bus o tree)
Media riconosciuti
• Standard singlemode fibre
• 62.5 and 50μm multimode fibre
• Laser-optimised 50μm multimode fibre
(recommended)
• 75-ohm coaxial cable (recommended for E-1, E-3, and
T-3 circuits)
• 4-Pair Category 6 UTP and ScTP cabling (Cat 6*
recommended)
Raccomandazioni
• Per il backbone si raccomanda la fibra multimodale da 50μm laseroptimized, perchè supporta velocità di rete maggiori su lunghe
distanze ed è più economica della singlemode.
• Per l'horizontal cabling si raccomanda di installare il media di più
alta capacità possibile, in modo da ridurre la necessità di rifare il
cablaggio in futuro.
• Altre raccomandazioni riguardano la necessità che i cavi per la
comunicazione e per l'elettricità vengano separati, che ci sia una
protezione per l'eccessiva curvatura delle fibre, che lo spazio sia
sufficiente a manovrare agilmente le connessioni, che tutti i cavi
siano dotati di label identificative.
Tiered reliability
Ridondanza
• TIA-942 definisce 4 "Tier", che si riferiscono a 4 livelli possibili di
ridondanza, corrispondenti ai tier ratings definiti dal Uptime Institute:
1.
2.
3.
4.
•
Tier 1 - Nessuna ridondanza (Disponibilità 99.671%)
Tier 2 - Componenti ridondanti, ma singolo path (Disponibilità 99.741%)
Tier 3 - Componenti ridondanti, path multipli, un singolo path attivo
(Disponibilità 99.982%)
Tier 4 - Componenti ridondanti tutti attivi, path multipli (Disponibilità
99.995% ossia downtime inferiore a 30 minuti per anno)
I requirements di un Tier superiore includono quelli dei Tier inferiori, e
possono essere specificati separatamente (e possono essere diversi) per
ogni singolo componente del DC: sistemi elettrici, strutturali, meccanici. Il
Tier di un DC è pari al Tier inferiore tra quelli di tutti i suoi sottosistemi
Ridondare la MDA se non si
usano stanze separate non
ha senso.
La SDA e la MDA dovrebbero
essere in stanze separate,
servite da diversi impianti
antincendio, diverse PDU, e
diverso HVAC
Ridondanza
• N - base: Il sistema rispetta i requisiti di base e NON ha ridondanza
• Ridondanza N+1: Esiste una unità addizionale, un modulo, un path,
un sistema in aggiunta a quelli minimi richiesti per soddisfare i
requisiti di base. La rottura o la manutenzione di una singola unità,
path o modulo non ha effetto sulle operazioni del DC
• Ridondanza N+2: Come la precedente con 2 unità addizionali
• Ridondanza 2N: Per ogni sistema richiesto ne esiste una copia
funzionante.
• Ridondanza 2(N+1): Ci sono due completi (N+1) sistemi per ogni
sistema N richiesto dai requisiti minimi.
Tier 1: Basic 99.671%
•
Non c'è ridondanza, i path sono singoli e i componenti non sono replicati (N)
•
Per l'alimentazione elettrica si consiglia di evitare la presenza di moduli, e di porre
N=1 per non diminuire la disponibilità complessiva.
•
Un T1 è suscettibile di interruzioni causate sia da attività pianificate che non
pianificate. Può non avere un UPS, o un generatore ausiliario; se ha un UPS si tratta
di un sistema singolo, ed esistono molti SPoF.
•
L'infrastruttura deve essere spenta completamente ogni anno per manutenzione
preventiva e riparazioni.
•
Una situazione di emergenza richiede spesso lo spegnimento totale, così come una
operazione umana sbagliata può comportare lo shutdown dei sistemi.
•
Annual downtime: 28.8h
Tier 2: Redundant Components
99.741%
• La presenza di componenti ridondanti rende meno probabile
l'interruzione dei servizi sia per attività pianificate che non
pianificate.
• E' presente un pavimento flottante, c'è l'UPS ed il generatore di
emergenza, di capacità N+1. Il carico arriva al 100% di N.
• Elettricità e raffreddamento hanno path singoli.
• La manutenzione delle linee di alimentazione e di altre parti della
struttura del sito richiede lo shutdown del DC.
• Annual downtime: 22h
Tier 3: Concurrently Maintainable
99.982%
•
Un data center di questo tipo ha più path, di cui uno solo attivo. Questo vuol dire
che è sempre essere possibile fermare uno solo dei path senza problemi per
effettuare manutenzione preventiva e programmata, riparazioni ed aggiornamento
di componenti, aggiunta e rimozione di componenti, testing ed altro.
•
Ad esempio se si usa acqua raffreddata, devono essere presenti due circuiti.
•
I carichi elettrici singoli sono alimentati da commutatori statici, quelli a doppia
entrata da due distinte PDU
•
Attività non programmate, come errori nelle operazioni o malfunzionamenti,
possono ancora causare uno shutdown del DC.
•
Il carico sui sistemi non deve eccedere il 90% di N, la ridondanza dei sistemi è N+1
•
Annual downtime: 1.6h
Tier 4 : Fault tolerant
99.995%
• I path multipli sono attivi contemporaneamente: è possibile ogni
tipo di manutenzione programmata senza interrompere
l'operazione del DC, e il sito può sostenere una failure non
programmata o un errore umano senza impatto sulle operazioni.
• Questo vuol dire, ad esempio elettricamente, che ci sono due
sistemi di UPS, ognuno in ridondanza N+1, che alimentano i server
con doppia o singola alimentazione (con interruttori automatici).
(2*(N+1))
• L'unica sorgente di downtime è l'allarme incendio o il power off di
emergenza.
• Annual downtime: 0.04h
source: http://www.eci.com/blog/40-a-refresher-on-data-center-tiers.html
Logical layers
Architettura Logica
• Non esiste uno standard accettato come la TIA,
l'architettura logica varia a seconda delle preferenze,
ma alcune "best practices" possono essere fornite.
• In generale è possibile suddividere la logica in quattro
strati:
1.
2.
3.
4.
Core
Aggregation
Access
Storage
Logical layers
• Core: fornisce la connettività ad alta velocità tra il data center e
l'esterno, e gestisce il traffico tra gli switch di aggregazione. Non ha
SPoF. Vi transita tutto il traffico in entrata ed uscita dal DC
• Aggregation: è il punto in cui tutti i server possono condividere
applicazioni come firewall, cache, load balancer, intrusion detection
ecc…Lo strato di aggregazione è il punto di transizione tra lo strato
di accesso, con switch L2, e lo strato di core con switch L3. Vi
transita tutto il traffico Server-to-Server.
• Access: Il punto di collegamento alla rete dei server. Nel modello
multi tier si divide in sottosistemi separate.
• Storage: Switch Fiber Channel e altri device di storage
Multi Tier Model
• Il modello di DC multi tier è plasmato intorno alla fornitura
di applicazioni web. Il modello prevede sw in esecuzione
sulla stessa macchina ma in processi separati, che
comunicano via IPC, o sw in esecuzione su macchine
separate che comunicano attraverso la rete.
• In quest’ultimo caso alla separazione logica tra i diversi Tier
applicativi corrisponde la separazione logica tra diversi
gruppi di server, disposti in aree differenti del DC:
– Front-end: web server, DNS, FTP (interfaccia utente)
– Application: layer di collegamento (business logic)
– Back-end: DB e connessione alla SAN (storage server)
Multi Tier Model
• Resilienza: un server può essere messo in manutenzione
mentre la sua funzione viene espletata da un altro server
dello stesso strato logico. Si ottiene mediante il load
balancing del traffico attraverso i tier.
• Sicurezza: un attaccante può compromettere un web server
senza per questo accedere ai server applicativi o di storage.
Si ottiene mediante firewall che filtrano il traffico attraverso
i tier.
• Isolamento: è anche possibile isolare del tutto i tier
mediante reti su switch differenti o mediante VLAN (che
riduce la complessità della rete)
La tabella naturalmente non esaurisce ogni possibilità, ma indica solo una strada. Proviamo ad
esempio a capire come tradurre l'architettura logica delle slide precedenti in una architettura
fisica del piccolo data center sotto. Dato che si tratta di un DC piccolo usiamo la reduced
topology (MDA, ZDA, EDA)
Implementing TIA-942
• Segmentiamo il DC basandoci sulla topologia logica vista prima:
1.
2.
3.
Gli switch di core LAN e gli switch di aggregazione, nonchè gli switch SAN
vengono posti nella MDA (core layer)
Lo strato di accesso viene diviso nelle tre zone front-end, application, e backend (access layer)
Lo storage viene sistemato in una zona separata. (storage layer)
• Ogni zona userà una soluzione MoR per il cablaggio e all'interno di ogni
zona avremo connessioni ToR.
• La EDA fornirà le connessioni per ogni rack e la ZDA fornirà le connessioni
a ciascuna EDA.
• Le ZDA termineranno nella MDA, in un main cross connect MC
Un ulteriore step consiste nel determinare quante fibre prevedere in ogni connessione.
Questo calcolo sarà influenzato dalla ridondanza che si vuole ottenere, sia nelle ZDA che
nelle EDA.
Il modello multi-tier è il più usato nei DC commerciali, perchè supportato nativamente da
architetture come .NET o Java 2 Enterprise Edition, usate da ERP come quelli di Oracle.
Server cluster model
• Questo modello è più comunemente associato agli
ambienti High Performance Computing (HPC), grid,
High Throughput Computing (HTC), calcolo parallelo.
• Le architetture SW che supportano questo modello
logico sono tipicamente basate su applicazioni custom,
a volte proprietarie.
• Tutti i cluster comunque sono caratterizzati
dall’aggregare molte CPU apparendo all’utenza come
un singolo sistema ad alte prestazioni
Logical overview
• Front end: interfacce IP usate per accedere dall’esterno al cluster,
quindi forniscono l’accesso ad un application server e permettono
di sottomettere e recuperare dei job.
• Master nodes: sono responsabili della gestione dei nodi di calcolo,
e sono gli unici che comunicano con l’esterno. Ospitano il
middleware necessario alla gestione delle risorse, allo scheduling
dei job, al monitoring dello stato dei nodi di calcolo.
• High speed back end: è la rete di comunicazione tra master node e
compute node e tra i compute node stessi. Tipicamente richiede
bassa latenza e alta banda (10gbE, Infiniband)
• Compute nodes: eseguono le operazioni CPU intensive
• Storage path: rete di collegamento, tramite Eth o FC, alla SAN.
• Common File system: il cluster deve usare un file system parallelo
comune ai nodi di calcolo (PVFS, LUSTRE,GPFS)
•
•
•
•
•
•
CotS server hardware
GigE or 10GigE Eth
Low Latency Hardware
Non blocking or low-over-subscribed switch fabric
Mesh/partial mesh connectivity
Jumbo frame support
ECMP (from wikipedia)
• Equal-cost multi-path routing (ECMP) is a routing strategy where next-hop
packet forwarding to a single destination can occur over multiple "best
paths" which tie for top place in routing metric calculations. Multipath
routing can be used in conjunction with most routing protocols, since it is
a per-hop decision that is limited to a single router. It potentially offers
substantial increases in bandwidth by load-balancing traffic over
multiple paths; however, there can be significant problems in its
deployment in practice.[1] RFC 2991 discusses multipath routing in
general.
• In 2014 the Institute of Electrical and Electronics Engineers (IEEE)
incorporated Equal Cost Multiple Paths (ECMP) or IEEE standard 802.1Qbp
into IEEE 802.1Q-2014) for Shortest Path Bridging. Specifying the forward
and reverse paths used for unicast and multicast traffic in shortest path
bridging as symmetric insuring flows on deterministic paths, resolving
configuration complexities, management functionality and performance
issues within original standards implementations.[2] [3][4][5][6]
DMZ
DMZ
• Chi accede ai servizi offerti all'esterno non deve essere in
nessun modo in grado di raggiungere le macchine di calcolo
all'interno del laboratorio o del Datacenter.
• La rete separata sulla quale i server risiedono è detta anche
rete demilitarizzata o DMZ, in analogia alla parte di
territorio che divide due nazioni e non appartiene a
nessuna delle due. La DMZ
1.
2.
non è sicura come la rete interna
non è insicura come Internet.
• I server nella DMZ hanno quindi
1.
2.
connettività limitata verso server specifici della rete interna
connettività limitata verso l'esterno
DMZ
source: http://v.gd/PpMaNO
Perchè usarla? Se si ospita un server accessibile dall'esterno l'intera rete è a rischio, quindi ci
sono tre soluzioni: affidarlo in outsourcing, ospitarlo SUL firewall ammesso che sia possibile, o
appunto isolarlo in modo che una sua compromissione non pregiudichi l'intera rete.
Indirizzamento IP
• La DMZ è una rete separata, sia dalla LAN che dal
firewall, e quindi ha bisogno di reti IP separate.
• Può usare IP pubblici o privati, a seconda della
configurazione dei firewall. Se usa i primi bisogna
partizionare la rete pubblica avuta dal GARR, se i
secondi il firewall deve usare il NAT (port forwarding)
• Se si usa un solo switch sulla rete interna, è possibile
ricavare la DMZ mediante VLAN tagging.
Anche se sembra complicato in realtà si semplifica la vita, perchè è possibile avere una sola
regola di filtraggio per tutti i computer nella DMZ, quando invece se si fossero mantenuti nella
rete interna ci sarebbe stato bisogno di un filtraggio ad hoc per ogni server.
ATTENZIONE: Usare sempre il principio del MINIMO PRIVILEGIO
La precedente configurazione "back to back" è la più sicura, ma ha bisogno di due firewall
separati, uno veloce verso internet (packet filter) ed uno più lento verso la LAN (application layer
filtering), con due configurazioni differenti
Questa configurazione "three legged firewall" necessita invece di un solo firewall con tre
interfacce di rete, che però diventa un SPoF per i vostri servizi e fa tutto il lavoro dei due firewall
visti prima.
WAN->DMZ ok
WAN->LAN blocked
LAN->DMZ ok
LAN->WAN ok
DMZ->LAN filtered
DMZ->WAN filtered
DMZ security
• Accesso non autenticato o anonimo
– Web server
• Accesso autenticato
– Sito aziendale (scolastico?) intranet
• La sicurezza degli host è molto più importante che nella LAN
1.
2.
3.
4.
5.
6.
Tutti i servizi non necessari vanno disabilitati
I servizi necessari vanno eseguiti con il minor numero di privilegi
possibile
Devono essere usate password sicure
Bisogna disabilitare account utenti non necessari
Il sistema deve essere aggiornato con le ultime patch di sicurezza
Bisogna abilitare un log degli accessi
pfsense
• https://www.pfsense.org/ (ISO da 84M)
• https://doc.pfsense.org/index.php/Main_Page
• HW requirements:
–
–
–
–
CPU: 1Ghz
RAM: 1GB
USB flash drive or 1GB HD or 1GB Flash card
Intel NIC up to 1Gbps
• Se si usano caratteristiche avanzate (come VPN o Captive Portal), le
richieste di CPU e RAM aumentano
• pfsense con 3 interfacce:
1.
2.
3.
NAT (internet)
Host only (LAN)
Internal network (DMZ)
192.168.56.100
192.168.2.100
admin
pfsense
Regole del firewall
• Le regole sulle interfacce si applicano in INGRESSO:
questo vuol dire che se mi metto sulla interfaccia di
rete guardando la DMZ, allora la regola si applica per il
traffico che ESCE dalla rete DMZ ed ENTRA nel firewall
• Quelle che seguono sono delle regole di esempio
• E' possibile scriverle in modo più maneggevole usando
gli aliases, gruppi di host reali, reti o porte ai quali
vengono applicate le stesse regole di firewall
ToR or EoR?
Switch locations
ToR Pros and Cons
•
•
•
•
•
•
•
Dal rack partono pochi cavi quindi la complessità del cablaggio è limitata e minore
il costo.
E' possibile aggiornare la connessione tra gli switch senza alterare il cablaggio
verso i server
L'aggiornamento del DC è modulare.
Può essere difficile scalare all'interno del singolo rack oltre un certo numero di
porte, determinato dalla capacità degli switch 1U/2U
C'è bisogno di molti switch, ognuno da gestire indipendentemente
Il numero di porte usato in ogni rack può variare molto, è possibile avere switch
sottoutilizzati.
Una espansione non programmata all'interno del singolo rack può rivelarsi molto
complicata.
EoR Pros and Cons
•
•
•
•
•
•
•
•
•
Le espansioni sono generalmente molto semplici: basta aggiungere una scheda allo switch di
aggregazione
Gli switch di aggregazione permettono una ridondanza pressochè totale (N+1 o N+N) con failover
immediati
La distribuzione dei server nei rack del DC non è limitata dal numero di porte disponibili nello
switch ToR
C'è un solo switch da gestire
La latenza della rete, dovuta al passaggio attraverso più switch, viene ridotta.
Server che parlano molto tra loro possono essere connessi alla stessa scheda di aggregazione,
qualsiasi sia il loro rack di appartenenza.
Sono richiesti più cavi e più lunghi: se si tratta di rame la complessità aumenta grandemente
Aggiornare la velocità della rete del DC può essere molto difficile, perchè bisogna rimpiazzare un
grande numero di cavi lunghi
Se si usa la fibra bisogna prevedere che i server usino schede di rete apposite.
Network problems
Oversubscription
•
Gli strati logici superiori sono generalmente oversubscribed: l'oversubscription esiste quando la
banda massima teorica di cui hanno bisogno gli apparati collegati ad uno switch supera la banda
massima teorica disponibile in uplink, ammesso ovviamente che il backplane sia non-blocking.
•
Si esprime come il rapporto dell'input sull'output (ad esempio 3:1) oppure come una percentuale,
calcolata come (1-(#input/#output)), ad esempio 1-1/3= 67%
•
Tipicamente :
–
–
–
altri server nello stesso rack 1:1
Uplink da switch ToR da 2:1 a 20:1
(32x10Gb down, 8X10Gb up = 4:1 oversubscription)
Core routers 240:1
•
Attenzione: non si tratta di una caratteristica negativa per-se, la rete può essere anche pensata
così fin dall'inizio. Bisogna tener presente che si tratta del caso peggiore possibile per la rete. Se
non tutti i server saturano la loro connessione allora potrebbe essere disponibile anche la banda
totale del link al singolo server.
•
Per cercare di rimediare in genere si mantengono i servizi che parlano tra loro in un ramo singolo, il
che implica che non è possibile muovere arbitrariamente i server nei rack.
Oversubscribed network
• Supponiamo di voler realizzare una rete con OS 3:1, usando uno
switch TOR line-speed, 32-port 40GbE. Ogni porta 40Gb QSFP può
essere divisa in 4 10Gb SFP+ usando un cavo splitter. Quanti
downlink verso i server e uplink verso lo strato superiore devono
essere usati?
• Il conteggio delle porte di uplink viene determinato dividendo il
numero totale di porte dello switch per la somma del numero di
input ed output preso dal rapporto di OS. Nel caso in esempio
32/(1+3) = 8
• Le rimanenti 24 porte a 40 possono essere splittate in 96 porte a 10
Oversubscribed network
• Lo switch di accesso si collega poi in uplink agli switch di
aggregazione per completare il "Fat Tree".
• Il numero di "spine" switch che sono necessari si
determinano contando il numero totale di uplink a 40Gb da
tutti i "leaf" switch e dividendo per 32 (il numero di porte
che stiamo supponendo disponibile). Gli uplink vengono poi
divisi in modo simmetrico tra gli spine switch.
• Se ad esempio si sono 8 leaf del tipo che abbiamo visto, con
quindi 8 link di uplink, potremmo usare 2 switch di spine
(da ogni leaf partono 4 link verso ciascun spine),
supportando 8x24x4 = 768 server.
Non blocking Fat Tree
• Con lo stesso switch è possibile costruire un Fat Tree non bloccante,
quindi privo di oversubscription, semplicemente usando 16 porte a
40 in uplink e 16 porte splittate per la connessione dei server: la
banda in entrata deve essere uguale a quella in uscita.
• Il cluster a due livelli non bloccante quindi supporta
(4switchx16portex4server) 256 server che parlano tra loro a 10Gb
wire speed, usando 6 switch da 32 porte a 40Gb.
Perchè questo setup funzioni naturalmente gli switch devono essere di livello 3, ed essere capaci
di usare un protocollo di routing per determinare la topologia della rete (OSPF, IS-IS, BGP).
Inoltre per poter usare contemporaneamente i path ridondanti deve essere supportato ECMP
(STP usa solo un path).
Fat switch 
• Ma… invece di avere un fat tree con n switch di m
porte, è possibile avere un solo switch con n x m porte!
• Il pattern di cablaggio è molto più semplice: ogni server
si collega direttamente allo switch centrale, e i cablaggi
tra edge e core sono fatti direttamente all'interno dello
switch. È uno sviluppo "estremo" della EoR.
• Ad esempio RECAS, ha uno switch centrale a 10 Gb a
doppio chassis, con 480 porte (scalabile a 576). La rete
fisica di RECAS sarà la base per eseguire OpenStack.
Altri problemi
• Un servizio che viene usato pesantemente può
influenzare altri servizi
• Se uno switch di accesso si rompe il carico sugli altri
aumenta
• Sotto utilizzo: in un Tier 3 o 4 molti path non vengono
usati
• Muovere un server con un suo IP in una differente zona
di un DC può essere molto complesso e comportare la
riconfigurazione di un gran numero di apparati.
Cooling
Bassa densità
Si usa in questo caso un sistema di corridoi
caldi e corridoi freddi: l'aria fredda viene
fornita attraverso il pavimento, davanti al
rack, quella calda torna alle unità di
raffreddamento
L'obiettivo della progettazione è ridurre la
miscelazione dei flussi caldi e freddi di aria.
Si arriva ad incrementare così del 20%
l'efficienza del tradizionale design che non
teneva conto di tale miscelazione.
Media densità
Per aumentare il calore dissipato si separano completamente i
flussi d'aria. La soluzione può essere adottata anche in DC che
hanno già in funzione una soluzione a bassa densità.
Alta densità
Si aggiungono dei raffreddatori nei punti di maggior
riscaldamento (porte refrigerate o condizionatori inRow)
APC è stata pioniera nelle soluzioni inRow.
Knuerr(Rittal) vende sistemi autocontenuti.
SDN
Software Defined Network
Quale bisogno realmente soddisfano? Storage e nodi di calcolo
diventano sempre più virtuali, non così la rete.
• Le reti su Ethernet&IP sono "semplici", facili da maneggiare e
gestire, ma caratteristiche aggiuntive come ACL, VLAN, DPI (deep
packet inspection), NAT firewall le complicano notevolmente.
• Il problema è che questa complessità è il sintomo di fondamenti
strutturalmente deboli.
• Siamo troppo vicini al livello zero, nelle reti tradizionali si ragiona in
quel che in programmazione potrebbe essere il linguaggio
macchina.
Analogia con la programmazione
• Dal linguaggio macchina, complesso, estremamente vicino
all'hardware, si è passati a linguaggi di programmazione strutturata,
che contengono astrazioni come file system, virtual memory, data
type astratti, ed infine ai linguaggi moderni ad oggetti/interfacce.
C'è stato un cammino verso l'astrazione e l'incremento della
semplicità. Fino ad ora questo non è successo con le reti.
• Le interfacce sono l'istanziazione delle astrazioni: schermano il
programma ed il programmatore dai dettagli sottostanti, e
permettono di programmare in modo modulare.
• NON rimuovono la complessità, ma la nascondono: si affronta la
complessità una volta per tutte, e poi si riutilizza quel lavoro
Astrazione nelle reti: data plane
• Che astrazioni si usano nel networking?
• I layer (IP TCP) sono le principali astrazioni (data plane).
– Ottime per quanto riguarda lo schermo dei meccanismi inferiori: IP
best effort delivery, TCP reliable byte stream: non si sa come ma cosa
succede.
– Pessime per quanto riguarda l'interfaccia: IP è embedded nella
architettura di TCP, che funziona solo su indirizzi IP, quindi non posso
usare i due strati in modo DAVVERO indipendente.
• Ma non esiste una astrazione del control plane: non ci sono blocchi
di controllo modulari che permettano di gestire la rete, e di
aggiungere e creare nuovi controlli se è necessario. Ogni volta che
c'è bisogno di un nuovo controllo bisogna inventare qualcosa di
nuovo, tipicamente un nuovo protocollo che viaggi su IP.
Control vs Data plane
• Control plane: è lo strato applicativo dove vengono prese le
decisioni di routing (L3) o forwarding (L2), basandosi sui protocolli
di routing conosciuti. Qui si decide dove inviare un pacchetto in
transito attraverso un router, qui risiede tutta la logica della rete. Il
Control plane sa DOVE indirizzare i pacchetti.
• Data plane: è dove le azioni decise dal control plane avvengono.
Comprende ad esempio le tabelle di routing, le tabelle ARP, le VLAN
ecc. Qui a seconda delle decisioni prese dal Control plane i
pacchetti vengono indirizzati al next hop di competenza, l'unica
cosa che il data plane conosce è COME indirizzare un pacchetto ad
una interfaccia.
• Management plane: CLI
Source Ivan Pepelnjak NIL Data Communications
Astrazione: control plane
• Come controlliamo ora le reti? Definiamo un nuovo
protocollo da zero (cfr. routing), oppure un nuovo
meccanismo di controllo (cfr. traffic engineering), o
lasciamo che sia l'operatore ad imporre manualmente dei
controlli, ad esempio delle ACL.
• Se si vuole semplificare la gestione il nuovo tipo di controllo
dovrà soddisfare tre requisiti:
– Deve poter controllare l'intero datapath IP
– Deve sopravvivere alle incertezze delle WAN
– Deve poter configurare ogni device di rete (switch, router, ACL)
Astrazione nelle reti
• Con le tecnologie tradizionali questa semplificazione semplicemente non
si può fare. Sarebbe come se per fare un programma un programmatore
dovesse specificare le locazioni di memoria di ogni singolo bit, gestire
qualsiasi errore interno di comunicazione, e il tutto con un linguaggio
molto povero: mancano le interfacce di alto livello.
• In programmazione quel che si fa è tipicamente ridefinire il problema
usando un livello di astrazione maggiore per la memoria, delle primitive di
comunicazione affidabili, un linguaggio potente.
• Perché non fare la stessa cosa per il network? A questo bisogno
rispondono le SDN.
• Le SDN non sono quindi un ulteriore meccanismo di rete, ma una
istanziazione di una astrazione, volta a fare in modo che la gestione della
rete sia più semplice, e fatta di mattoni fondamentali con una chiara
interfaccia.
Source: SDN Approach to Large Scale Global Data Centers - Rakesh Saha, Amit Agarwal
Ogni elemento di rete ha la stessa interfaccia di configurazione, management e controllo.
Esiste un solo punto di accesso alla configurazione della rete, il controller SDN, non più le
centinaia di punti di accesso corrispondenti ai vari elementi di rete tradizionali. L'interfaccia
è inoltre indipendente dal vendor.
Una visione GLOBALE della rete del DC permette di usare in modo efficiente la banda
disponibile, e di rendere la rete flessibile e capace di supportare nuove esigenze: le decisioni
possono essere prese a livello applicativo sulla base di fattori interni o completamente
esterni alla rete stessa (come orario o occupazione di banda)
La parte cablata del DC viene realizzata una volta per tutte, ma la capacità della rete SDN di
ridefinire la topologia degli accessi permette (o permetterebbe) di realizzare delle reti
dedicate ad un particolare utente o progetto, tra loro del tutto isolate (Network As An
Infrastructure o Network As A Service)
In generale un controller si costruisce un modello della rete man mano che i device vi si
connettono.
Network Functions Virtualization (NFV)
• Le SDN permettono
l'implementazione delle
NFV: gli elementi funzionali
della rete sono virtualizzati,
e possono essere distribuiti
su più device o hypervisor.
• NFV non è dipendente dalle
SDN. Gli elementi
virtualizzabili possono essere
ad esempio load balancers,
firewalls, IDS, Routers.
• SDN+NFV+Cloud promette di
dare una grande flessibilità:
si tratta di verificarne le
prestazioni.
Openflow
• Openflow è una delle possibili interfacce per il controllo remoto degli
apparati di rete SDN.
• Per avere una idea pratica di come funziona ho simulato un ambiente di
test nel quale eseguire openflow. La macchina virtuale mininet si scarica
da
http://mininet.org/
username:
password:
mininet
mininet
• Dato che sarà necessario aprire wireshark all'interno della macchina
virtuale, ma facendo apparire il display sulla propria macchina, bisogna
usare una connessione ssh con tunnel X. La funzionalità della connessione
si uò provare con xterm. L'indirizzo da contattare è quello della macchina
virtuale, che deve avere una interfaccia host-only
Terminologia
• OpenFlow Controller: il controller è la parte "superiore" della
interfaccia OpenFlow; la distribuzione di riferimento include un
controller che si comporta come uno switch ethernet intelligente, in
combinazione con uno switch OpenFlow. È possibile scriverne di
diversi
• OpenFlow Switch: la parte "inferiore" della interfaccia OpenFlow; la
distribuzione di riferimento ne include uno in user-space. Open
vSwitch è un altro switch software, che però gira in kernel space.
Molti vendor forniscono pezzi di ferro compatibili.
• dpctl: utility command line di interazione con OpenFlow
• Mininet: piattaforma di emulazione che crea una rete openflow
virtuale.
La prima rete openflow
La rete è formata dal controller C0 , che parla
allo switch OpenFlow S1 tramite interfaccia di
loopback 127.0.0.1 sulla porta 6633.
Nella realtà il collegamento tra S e C deve
essere fatto su una rete dedicata (secure
channel)
Allo switch sono collegati su due interfacce i
due host H1 ed H2.
Per far partire questa rete minimale di test,
nella finestra ssh con la quale siamo collegati
alla macchina:
mininet@mininet-vm:~$ sudo mn
I due host sfruttano per l'emulazione i
network namespaces, e hanno quindi le reti
separate.
Network namespace
• Una installazione di Linux condivide un singolo insieme di interfacce di
rete e di righe nella tabella di routing.
• Ogni NetNS ha le proprie schede di rete, la propria tabella di routing, i
propri IP, la propria /proc/net, le proprie porte…
• Potete fare le prove seguenti su una qualsiasi macchina Linux recente
(anche sulla garrx):
– Per creare il namespace garrx:
mininet@mininet-vm:~$ sudo ip netns add garrx
– Per avere una lista dei namespace:
mininet@mininet-vm:~$ sudo ip netns list
NetNS
• Al network namespace (NetNS) bisogna adesso assegnare le interfacce, e
configurarle in modo che funzionino.
• Al NetNS si possono aggiungere solo interfacce virtuali (veth#): si tratta di
interfacce che si possono usare solo in coppia, e sono connesse tra loro
come con un filo diretto: ciò che entra in una esce dall'altra, e ogni
interfaccia appare come una comune porta ethernet al so e ai sw.
– Prima si crea una coppia:
mininet@mininet-vm:~$ sudo ip link add veth0 type
veth peer name veth1
mininet@mininet-vm:~$ sudo ip link list
• Le due interfacce appaiono, nel namespace DEFAULT. Ora per collegare il
namespace garrx al DEFAULT:
– Aggiungere una delle due interfacce all'interno:
mininet@mininet-vm:~$ sudo ip link set veth1 netns
garrx
mininet@mininet-vm:~$ sudo ip link list
Garrx netns
•
Dall'output dell'ultimo comando è scomparsa veth1
– Per vederla nuovamente bisogna eseguire il comando nel namespace garrx:
mininet@mininet-vm:~$ sudo ip netns exec garrx ip link list
•
Per configurare l'interfaccia nel namespace garrx:
– mininet@mininet-vm:~$ sudo ip netns exec garrx ifconfig veth1
10.1.1.1/24 up
•
Comandi utili a verificare che tutto sia a posto:
–
–
–
–
–
•
mininet@mininet-vm:~$
mininet@mininet-vm:~$
mininet@mininet-vm:~$
mininet@mininet-vm:~$
mininet@mininet-vm:~$
sudo
sudo
sudo
sudo
sudo
ip
ip
ip
ip
ip
addr list
netns exec garrx ip addr list
netns exec garrx ifconfig
route list
netns exec garrx ip route list
Come ci si aspetta la rete non è raggiungibile, perché non è collegata al namespace
di default:
– mininet@mininet-vm:~$ sudo ping 10.1.1.1
Peer
Ma al namespace di default è collegata veth0, che è unita al suo
peer veth1.
– mininet@mininet-vm:~$ sudo ifconfig veth0
10.1.1.2/24 up
– mininet@mininet-vm:~$ sudo ping 10.1.1.1
– mininet@mininet-vm:~$ sudo ip netns exec
garrx ping 10.1.1.2
• Infine il collegamento con l'esterno e quindi la rete fisica
volendo si fa con un bridge, o un linux bridge standard o
uno switch openflow o un open vSwitch. Non lo proviamo
perché l'interfaccia eth1 è già collegata al bridge Vbox.
Mininet default network
• Tornando alla rete di default (sudo mn), dal prompt di mininet si
possono ottenere molte informazioni:
mininet>
mininet>
mininet>
mininet>
mininet>
mininet>
mininet>
mininet>
help
nodes
dump
net
h1 ping h2
xterm h1
pingall
iperf
• Avrete senz'altro notato che il primo ping impiega un tempo
considerevolmente maggiore degli altri. Non è un caso.
• La spiegazione risiede nel funzionamento di OpenFlow: per sapere come
indirizzare il primo pacchetto lo switch deve interrogare il controller, che è
l'unico che conosce la topologia della rete. I pacchetti successivi invece
vanno direttamente da h1 allo switch ad h2.
Introducing openflow
mininet> exit
mininet@mininet-vm:~$ sudo mn –c
Per ispezionare i pacchetti e capire cosa sta succedendo apriamo un'altra
sessione sulla macchina virtuale, con tunnel X, e apriamo wireshark.
mininet@mininet-vm:~$ sudo wireshark &
Nella casella filter mettiamo la stringa of, per indicare che vogliamo vedere
solo i pacchetti openflow, e facciamo partire la cattura solo sulla interfaccia
lo. Si vedono soplo echo request e reply tra controller e switch
Facciamo ripartire mininet secondo uno schema della rete con 1 controller e
4 host:
mininet@mininet-vm:~$ sudo mn --topo=single,4
mininet> nodes
mininet> dump
mininet> net
wget
• Su wireshark all'inizio si vedono solo i pacchetti di OFP echo request e
reply
• Su H4 server web minimale con python:
mininet> h4 python –m SimpleHTTPServer 80 &
• Su H1 la richiesta della pagina di indice:
mininet> h1 wget 10.0.0.4
• Infine blocchiamo l'acquisizione con wireshark
• Se si vogliono vedere i flow installati
mininet> dpctl dump-flows
S1 manda il pacchetto al controller C0
o per intero oppure indicando un ID di
buffer interno nel quale il pacchetto viene
conservato
Da H1 parte il pacchetto SYN di richiesta
Packet IN
della connessione verso H4. Se si trattasse di
SYN (port 80) OR
uno switch tradizionale verrebbe indirizzato verso
Buffer ID = 279
H4. Ma in S1, dato che si tratta del primo pacchetto
non c'è una regola (flow entry) che dica come
indirizzare il pacchetto (table miss)
il secondo installa una entry nella
C0
manda
a S1 un
Packet OUT
flow
table che,
basandosi
sui e/o
un
Flow
Mod.eIlmask,
primopermette
dice cosaa
campi
match
fare
quello
specifico
pacchetto
S1 dicon
sapere
come
indirizzare
pacchetti simili al nostro SYN
FLOW MOD
Packet& OUT
Match
Mask
Buffer
ID 80)
= 279
SYN
(port
OR
Idle Timeout=60
Buffer
ID = 279
Hard Timeout=0
Action=forward
port 4
Priority=0
Action=forward port 4
FLOW ENTRY H1->H4 port 80
Wget
SYN (port 80)
Wget
SYN (port 80)
Packet-IN
Flow mod mask & action
Controller remoto
• È anche possibile usare un controller remoto, presente su un'altra
macchina, e con una differente implementazione.
• Apriamo ad esempio due finestre sulla macchina virtuale mininet. Sulla
prima facciamo partire, in ascolto sull'indirizzo di rete, il controller POX
(una implementazione in Python) che realizza uno switch l2 learning
mininet@mininet-vm:~$ cd pox
mininet@mininet-vm:~/pox$ python ./pox.py
forwarding.l2_learning
• Sulla seconda finestra facciamo partire la rete di default di mininet,
indicando come controller remoto quello in ascolto sull'indirizzo IP esterno
della macchina.
mininet@mininet-vm:~$ sudo mn
--controller=remote,ip=192.168.56.101,port=6633
The learning switch "brain" associated with a single OpenFlow switch.
When we see a packet, we'd like to output it on a port which will
eventually lead to the destination. To accomplish this, we build a
table that maps addresses to ports.
We populate the table by observing traffic. When we see a packet
from some source coming from some port, we know that source is out
that port.
When we want to forward traffic, we look up the destination in our
table. If we don't know the port, we simply send the message out
all ports except the one it came in on. (In the presence of loops,
this is bad!).
Controller remoto
• A questo punto lo switch si è collegato al controller, e il ping
funziona:
mininet> h1 ping h2
• Se si interrompe l'esecuzione del controller, si vede che come
detto in precedenza, il ping continua perché i pacchetti non
devono più passare per il controller, essendo stata installata nella
tabella di flow dello switch la relativa entry
• In questa versione del controller esiste però un tempo massimo di
vita dell'entry, scaduto il quale questa viene rimossa anche se il
traffico continua. Ad un certo punto quindi il traffico viene
interrotto.
Load Balancing using openFlow
• pox/pox/misc/ip_loadbalancer implementa un semplice
load balancer che istruisce lo switch ad inviare richieste di
connessione HTTP provenienti dai client da h3 fino ad h6,
indirizzate a 10.0.1.1, verso i due server h1 ed h2
• Il setup del laboratorio vede quindi uno switch e 6 macchine
collegate.
Load Balancing
• Lanciamo il controller su una sessione aperta su mininet:
– mininet@mininet-vm:~/pox$ ./pox.py log.level --DEBUG
misc.ip_loadbalancer --ip=10.0.1.1
--servers=10.0.0.1,10.0.0.2
• Su un'altra sessione, attenzione al tunnel X, lanciamo la simulazione della
topologia di rete:
– mininet@mininet-vm:~$ sudo mn --topo single,6 --mac
--arp --controller=remote
• Ora apriamo i terminali grafici sugli host
– mininet> xterm h1 h2 h3 h4 h5 h6
• Facciamo partire i due server web:
– H1: root@mininet-vm:~# python -m SimpleHTTPServer 80
– H2: root@mininet-vm:~# python -m SimpleHTTPServer 80
Load Balancing
• A questo punto su ogni terminale da h3 a h6
possiamo lanciare il comando seguente, e verificare
sulle finestre di h1 ed h2 che il load balancing stia
effettivamente funzionando:
• H3-6: root@mininet-vm:~# wget 10.0.1.1
• Se si vogliono vedere i flow installati
• mininet> dpctl dump-flows
OpenDaylight is an open platform for network programmability to enable SDN and create a solid foundation for
NFV for networks at any size and scale.
For those looking to manage their networks using OpenDaylight, there is deeper integration with OpenStack,
including significant improvements in the Open vSwitch Database Integration project, and a technology preview of
advanced OpenStack features such as Security Groups, Distributed Virtual Router and Load Balancing-as-a-Service.
SAN
SAN
• Una SAN (Storage Area Network) è una rete il cui scopo primario è
trasferire i dati tra gli elementi di storage (block storage, tape
library, Blu Ray Juke box) e i computer di calcolo.
• Consiste di:
–
–
–
–
una infrastruttura di comunicazione, che fornisce le connessioni fisiche
uno strato di gestione, che organizza le connessioni
un insieme di elementi di storage
dei computer che si occupano della pubblicazione dei dati
• Una SAN in altre parole è una rete specializzata ad alta velocità, che
collega storage e server, eliminando la tradizionale connessione
dedicata tra storage e server, e il concetto collegato che il server
gestisca lo storage. Se i client parlano tra loro con la LAN, i server
parlano agli storage di backend con la SAN.
iSCSI
Perchè la SAN?
• CLUSTER: in tutti i tipi di cluster (HPC, HA, LVS) i server hanno
bisogno di accedere ad uno storage condiviso tra i nodi di calcolo.
Spesso si usa un block storage che viene formattato con un file
system cluster-aware (OCFS2, Lustre, GPFS, GFS) o con LVM.
• CAPACITÀ: gli storage usati per la SAN riescono a servire
contemporaneamente un gran numero di client fornendo capacità
non disponibili per i server (dell'ordine dei Petabyte). Naturalmente
c'è anche la possibilità di usare file system distribuiti (CEPH,
HadoopFS, GoogleFS)
• VELOCITÀ: I bus locali non arrivano alla velocità di una SAN : FC
arriva a 16Gb/sec, iSCSI a 40Gb/sec, FCoE a 10Gb/sec. su singola
fibra
Vantaggi della SAN
• Lo storage è indipendente dalle applicazioni, e
accessibile tramite diversi data path per aumentarne la
disponibilità ed affidabilità.
• Dato che la gestione dello storage è demandata su una
rete dedicata, i server sono alleggeriti da questo lavoro.
• La gestione dello storage è centralizzata
• E' possibile in modo relativamente facile prevedere un
backup anche geografico dei dati
Connettività
• SCSI (Small Computer System Interface) è uno standard ANSI
(American National Standard Institute). Si tratta di un bus di
comunicazione parallelo, che esiste in un grande numero di varianti.
• Gli standard SCSI definiscono sia lo standard di collegamento fisico,
sia lo standard logico che i disk device devono soddisfare. Questo
standard logico è il CSS (Common Command Set).
• La progressione dello standard SCSI ha portato alla definizione del
modello FC (Fibre Channel). FC è una interfaccia seriale,
implementata sopratutto con cavi in fibra ottica.
SCSI
• L'interfaccia SCSI è stata per molto tempo il modo
convenzionale e server-centrico di connettere tra loro
le periferiche in un ambiente client/server. Era dotata
di cavi dedicati, e permetteva di mettere in cascata,
fino a 15 device su un bus di comunicazione. L'ultimo
device andava sempre "terminato".
• Con il termine SCSI ci si riferisce anche ad un protocollo
di comunicazione, che specifica i comandi che un
server e dei device collegati possono usare per
scambiarsi su un bus di comunicazione dei blocchi di
dati.
Limitazioni dello SCSI
• La scalabilità era un problema: praticamente i 15 device si
riducevano a non più di 5, per limitazioni sulle performance dovute
alla condivisione del bus di comunicazione.
• I cavi erano costosi ed ingombranti.
• C'erano problemi di affidabilità: l'accesso ai dati era perso nel caso
si fosse persa la connessione ad uno qualsiasi dei device sul bus.
Inoltre la riconfigurazione di uno dei device sul bus comportava la
necessità di spegnere l'intero bus.
• La velocità e la latenza erano limitate dall'architettura stessa scelta
per la comunicazione (8 – 16 bit in parallelo)
• La distanza dei cavi era limitata a 12 metri
• La condivisione di device tra più host era seriamente limitata dal
meccanismo usato, che prevedeva che prima e durante la
trasmissione di dati sul bus non transitasse nulla per permettere al
protocollo la determinazione dell'host abilitato a trasmettere…
Fibre Channel Protocol è un mapping dello SCSI su Fibre Channel, iSCSI su TCP/IP.
Fibre Channel over IP è un protocollo pensato per estendere la SAN sui network IP
(nuovo protocollo iFCP)
FCoE funziona con le tradizionali schede di rete, gestendo il traffico FC a livello datalink, e usando frames Ethernet per incapsulare, instradare e trasportare frames FC
attraverso una rete Ethernet da uno switch con porte FC e un device collegato ad un
altro switch simile.
iSCSI: è un protocollo di trasporto che trasporta i comandi SCSI da un initiator ad un
target, di fatto muovendo richieste SCSI standard usando TCP/IP.
Con iSCSI è possibile implementare delle SAN basate su connessioni IP, e quindi che
consentono ai client di usare la stessa tecnologia sia per la rete esterna che per quella
di storage.
FCP (Fiber Channel Protocol) è il protocollo di interfaccia di SCSI su FC.
FCIP è anche noto come FC tunnelling, e permette la trasmissione di informazioni FC
su rete ethernet, di nuovo permettendo di costruire una SAN basata su IP. La
connessione è gestita quindi interamente da TCP/IP e permette una estensione
geografica.
FC
• Con il termine Fibre Channel ci si riferisce a tutta una serie di
concetti e tecnologie legate insieme, che permettono agli host di
vedere i device (ad esempio gli storage) come locali.
• FC ha le caratteristiche di una rete, quindi supporta più protocolli, e
una ampia varietà di device. Come in altre reti, l'informazione viene
inviata in pacchetti strutturati, o frames, e i dati vengono serializzati
prima di essere trasmessi. Al contrario di altre reti però
l'architettura FC richiede un significativo apporto dell'hardware per
ottenere alte velocità.
• FC usa generalmente fibre ottiche per la trasmissione del segnale.
Terminologia
• Qualsiasi sia la topologia della rete FC, le informazioni sono
scambiate tra due nodi, il mittente (detto initiator) e il destinatario
(detto target).
• Un nodo può essere un computer come un PC o un server, oppure
una periferica come un disco, o una libreria di nastri, o una
videocamera.
• Tra i nodi vengono scambiati frame di informazione, la cui struttura
è definita da un protocollo.
• Ovviamente initiator e target per parlare devono condividere il
protocollo di comunicazione, ma la rete può supportare diversi
protocolli contemporaneamente.
Topologia
• point to point: è la topologia più semplice, e viene
usata quando ci sono solo due nodi, e due rimarranno
sempre. Non c'è condivisione della rete, quindi la
connessione può usare tutta la banda disponibile. FC è
full duplex, quindi un link a 4Gbps può avere
simultaneamente in trasmissione e ricezione 400MBps
• switched fabric: l'ampiezza di banda completa è
disponibile per ogni porta dello switch, ed è possibile
aumentare facilmente il numero di host e device che
utilizzano la SAN.
Indirizzamento
• Ma come si riconoscono tra loro i device? Ogni device in un
ambiente FC ha la sua identità univoca, chiamata
WorldWide Name (WWN). Si tratta di un identificativo
simile al MAC per le chede ethernet.
• Ogni porta ha il suo WWPN (Port Number), ed ogni device
nella SAN è identificato dal suo WWNN (Node Name).
• Dato che questi campi identificativi sono di 64 bit, e quindi
pongono problemi al routing veloce, esiste un indirizzo a 24
bit delle porte FC che viene usato per lo switching e la
costruzione di SAN. E' anzi proprio lo switch che assegna
questi indirizzi a 24 bit, e mantiene la corrispondenza tra
questi e il WWN del device collegato.
iSCSI
• La terminologia e la topologia di iSCSI mutuano molto
di quanto visto per FC.
• La parte fisica si poggia su ethernet, e quindi su comuni
switch, la parte logica prevede la trasmissione dei
comandi SCSI su ethernet tra un initiator ed un target,
identificato da un ID dal target.
• I target e gli initiator iSCSI possono essere costruiti
tramite software Linux, e funzionano piuttosto bene:
non hanno bisogno di HW particolare, e si riescono ad
ottenere facilmente 10Gbits.
Terminologia
• Initiator: è il sw che si trova sulle macchine client e permette di effettuare
il mounting delle LUN.
• Target: il software presente sui sistemi iSCSI che devono esportare delle
LUN.
• iqn: è l'identificativo univoco che rappresenta un nodo in una rete iSCSI.
• IP: ogni nodo deve avere un indirizzo IP per ogni singola porta.
Solitamente si usa la porta TCP 3260
• LUN: come in FC, le LUN sono mappate attraverso gli iqn
• multipath: per aumentare la banda a disposizione o gestire il failover si
può usare l'aggregazione di canali tramite il multipath.
File server
• Non è necessario avere costosi sistemi HW per realizzare un
File Server che possa servire il vostro laboratorio o i vostri
uffici.
• Anche una macchina capace di montare più dischi
contemporaneamente, come ad esempio un vecchio PC in
formato tower al quale si aggiunge RAM fino a 8G, può
essere trasformato in un file server RAID con l'aiuto di un
software adeguato.
• Uno di questi sw è freenas (www.freenas.org) , ma ce ne
sono vari similari (nas4free, openmediavault, openfiler…)
Esempio
• Per fare pratica potete installare freenas su una macchina
virtuale, sulla quale andremo ad installare 3 dischi
aggiuntivi
• La caratteristica principale di FreeNAS, che me lo fa
preferire a soluzioni alternative, è l'uso "sotto il cofano" di
FreeBSD e del porting su tale sistema operativo di ZFS
• ZFS è sia un files system, sia un logical volume manager,
progettato dalla SUN Microsystem per sistemi professionali
e portato prima su BSD e poi su Linux
• ZFS supporta protezioni contro la corruzione dei dati, check
continuo della integrità, riparazione automatica,
compressione, snapshot, cloni COW, RAID-Z e NFSv4 ACL
FreeNAS su VBox
Per poter usare l'interfaccia grafica, impostare la scheda di rete su host only,
(parla sulla rete 192.168.56), Intel PRO 1000 Desktop
FreeNAS su VBox
Una volta terminata l'installazione spegnere la macchina e rimuovere il disco
di installazione.
FreeNAS su VBox
Dalla stessa interfaccia aggiungere un controller SATA e tre dischi virtuali
dinamici da 12 Gb
FreeNAS su VBox
Dalla stessa interfaccia aggiungere un controller SATA e tre dischi virtuali
dinamici da 12 Gb
FreeNAS su VBox
Al termine dei tentativi di inizializzazione dell'IP, si arriva ad una console
simile alla seguente.
FreeNAS su VBox
Bisogna impostare l'indirizzo di rete con l'opzione 1.
A "Reset Network Configuration" rispondere no e proseguire con il resto delle
domande, impostando l'indirizzo 192.168.56.2/24, senza IPv6.
Riavviare quindi la macchina e reimpostare la password di root
FreeNAS su VBox
A questo punto si può puntare il browser del proprio pc all'indirizzo della
macchina virtuale ed entrare con username root e password impostata.
Uscite dal wizard di configurazione dello storage.
Storage
Storage
Extent
• In iSCSI il target virtualizza qualcosa e la presenta come
un device al client. Quel qualcosa può essere un "file
extent" o un "device extent".
1. Il device extent virtualizza un disco fisico non formattato,
un controller RAID, oppure un volume ZFS.
2. Il file extent permette di esportare una porzione di un
volume ZFS, con il vantaggio di poter avere più
esportazioni separate per ogni volume.
• Virtualizzare un volume ZFS ha senso in quanto sfrutta
le caratteristiche di cache in lettura e scrittura del
filesystem, nel caso non si abbia un controller avanzato
a disposizione.
Extent
Aggiungiamo un extent. Dopo aver premuto OK dovrebbe comparire nell'albero a
sinistra.
Initiators
Portals
Un portale specifica gli indirizzi IP e i numeri di porta che devono essere usati per la
connessione al target. Possono essere specificati anche più indirizzi IP, per aumentare
la disponibilità o partizionare l'accesso fornendo servizi differenti su diverse interfacce
di rete.
Target Global Configuration
• Qui vengono impostati una serie di valori validi per tutti i
target del sistema. Possono essere usati per ottimizzare la
connessione in particolari ambienti, nel nostro caso
ovviamente lasciamo tutto così com'è.
• Passiamo quindi ad aggiungere il target, che verrà
esportato via iSCSI. A questo proposito notiamo che un
target iSCSI è un block device come un qualsiasi disco. Se
deve essere usato da più di un initiator deve esistere uno
strato software (VMFS, LVM clustered) che permetta l'uso
contemporaneo. Se viene formattato con un filesystem
ordinario bisogna fare in modo che un solo initiator alla
volta possa montarlo con privilegi di lettura e scrittura.
Target
Associazione
Infine facciamo partire il servizio da Services->Control Services
initiator
root@garrx-VirtualBox:~# iscsiadm -m discovery -t sendtargets -p
192.168.168.1
192.168.168.1:3260,1 iqn.2011-03.org.example.istgt:mytarget
root@garrx-VirtualBox:~# iscsiadm -m node --targetname iqn.201103.org.example.istgt:mytarget -p 192.168.168.1 --login
Logging in to [iface: default, target: iqn.201103.org.example.istgt:mytarget, portal: 192.168.168.1,3260]
(multiple)Login to [iface: default, target: iqn.201103.org.example.istgt:mytarget, portal: 192.168.168.1,3260] successful.
root@garrx-VirtualBox:~# dmesg
...
[ 3726.607072] sd 3:0:0:0: [sdb] Attached SCSI disk
Ora nella macchina è disponibile un nuovo disco, sdb, che posso formattare ed usare:
root@garrx-VirtualBox:~#
root@garrx-VirtualBox:~#
root@garrx-VirtualBox:~#
root@garrx-VirtualBox:~#
cfdisk /dev/sdb
mkfs.ext4 /dev/sdb1
mkdir /iscsi
mount /dev/sdb1 /iscsi
• https://manuais.iessanclemente.net/images/9/9f/Tia942.pdf
• http://www.adckcl.com/in/en/library/white_papers/enterprise/40
1260in.pdf
• http://www.aeit-taa.org/Documenti/Chloride-1-Data-Centre-TCDBZ.pdf
• http://www.cse.wustl.edu/~jain/cse570-13/ftp/m_03dct.pdf
• http://clusterdesign.org/fat-trees/
• http://www.herts.ac.uk/__data/assets/pdf_file/0017/45350/datacentre-standards.pdf
• http://www.excitingip.com/2802/data-center-network-top-ofrack-tor-vs-end-of-row-eor-design/
• http://www.ieee802.org/3/hssg/public/nov06/diminico_01_1106.
pdf
• http://www.graybar.com/documents/zone-distribution-in-the-data-center.pdf
•
https://uptimeinstitute.com/
•
http://www.cisco.com/c/en/us/td/docs/solutions/Enterprise/Data_Center/DC_Infr
a2_5/DCInfra_1.html
•
http://www.techrepublic.com/article/solutionbase-strengthen-network-defensesby-using-a-dmz/
•
http://lutung.lib.ums.ac.id/freebsd/pfSense/docs/dmz.html
•
http://en.community.dell.com/techcenter/high-performancecomputing/b/general_hpc/archive/2012/07/02/designing-scalable-10gb-ethernetnetworks-part-1
• http://en.wikipedia.org/wiki/Equal-cost_multi-path_routing
•
http://www.climaveneta.com/IT/Download/View/930.dl
•
https://agenda.infn.it/getFile.py/access?contribId=21&sessionId=7&resId=0&mate
rialId=slides&confId=9201