L’Università di Pisa investe da anni in tecnologie e infrastrutture di rete e può contare su circa 3000 Km di fibra di proprietà, la connettività del progetto GARR-X, un backbone a 10G in MPLS/BGP e l’accesso per la maggior parte degli utenti a 100Mb/s. Tuttavia alla fine del 2012 l’organizzazione dei servizi e della rete all’in- terno del campus era legata ad un modello organizzativo dell’Ateneo dove ogni struttura godeva di autonomia nel gestire le proprie risorse. Questa situazione ha determinanto negli anni un’elevata disomogenità dei servizi e un’eccessiva frammentazione delle risorse sia sul piano tecnico che sul piano amministrativo. Nel 2013 in se- guito alla necessità di razionalizzare le risorse dell’Ateneo è sorta l’esigenza di riprogettare la connettività e i meccanismi di erogazione dei servizi. La presentazione illustra il modello e gli aspetti tecnici del nuovo Servi- zio di Connettività d’Ateneo, in cui l’automazione per una rete vasta e complessa come qeulla dell’Università di Pisa svolge un ruolo determinante. Il servizio di connettività d’Ateneo (SCA) offre connettività (Wired/Wireless ) e servizi correlati a tutte le strut- ture universitarie ed ai data center dell’Ateneo. Il nuovo modello organizzativo è un sistema composto da 7 Ac- cess Provider e un Carrier: ogni access provider si occupa di gestire la connettività e i servizi per il proprio bacino di utenti, il carrier si occupa di erogare la connettività, fornire le infrastrutture di gestione ed erogazio- ne dei servizi a tutti gli access provider. L’università è stata suddivisa in 7 bacini d’utenza uno per ogni Access Provider, in ogni area è stato definito un dominio di routing nel quale transita il traffico proveniente dalle strut- ture afferenti. Gli apparati di distribuzione su cui insistono i domini di routing sono magliati tra di loro e con i due router che costituiscono il backbone. Ogni router d’area viene affiancato da un nodo delegato ad erogare i servizi secondo una logica multi-tenant. L’infrastruttura dei servizi di rete (a.k.a. progetto belfagor), consiste di una piattaforma cloud privata i cui nodi sono connessi da un anello in fibra ottica con protezione ERPS, su cui transita esclusivamente traffico di ma- nagement dell’infrastruttura stessa. Ogni componente dell’anello è costituita da due swtich in stack e due nodi della piattaforma di cloud computing basata su KVM/openstack. Ogni nodo di computing esegue le istanze vir- tuali nelle quali sono configurati e attivi i servizi in rapporto 1:1, una istanza un servizio. Si può pensare ai servizi come a delle vere e proprie App, il cui contesto di esecuzione è la piattaforma di cloud, che insieme agli strumenti di automazione effettua il provisioning dei servizi relativi ad un’area specifica. Le App/Servizi sono idempotenti ovvero non avendo necessità di storage persistente possono essere ricreate infinite volte senza perd

1. Servizio di Connettività d’Ateneo
Network and services provisioning automation
rossella caputo
rossella.caputo@unipi.it
paolo de rosa
paolo.de.rosa@unipi.it
enrico bernardini
enrico.bernardini@unipi.it

2. Agenda
• Motivazioni
• Network & Services Infrastructure
• Automated Provisioning
• Criticità e miglioramenti

3. Motivazioni

4. ICT @ UniPi in numeri
• ~ 62.000 Studenti
• ~ 2500 Dipendenti
• 110 Edifici da connettere
• ~ 250 Km di canalizzazioni
• ~ 3000 Km di fibra sul territorio
• ~ 280 Access Point
• ~ 700 apparati di accesso
• ~ 5000 dispositivi VOIP
• 15 sedi remote fuori città
• Connettività per enti esterni

5. Organizzazione ICT
Prima del 19 Settembre 2012 il settore ICT era suddiviso in :
• 48 Dipartimenti
• 11 Facoltà
• 10 Strutture amministrative
Ogni struttura organizzava la connettività e i servizi ICT
in autonomia oppure poteva usufruire di un sistema
centralizzato gestito dal centro Ser.R.A.
Ciò ha determinato:
• disomogeneità nella gestione e utilizzo della rete
• maggior carico lavorativo per le piccole strutture
• difficoltà a stabilire buone pratiche per l’uso comune
delle risorse

6. Organizzazione ICT
L’Ateneo è stato riorganizzato in :
• 20 Dipartimenti
• 15 Centri, Sistemi e altre strutture
L’area ICT viene organizzata in 7 poli
per la gestione dei servizi informatici,
che si spartiscono gli utenti delle 35
strutture dell’Ateneo. Un’unica
Direzione ICT

7. Obiettivo
All’inizio del 2013 viene chiesto di riprogettare la connettività
in funzione del nuovo modello organizzativo, semplificando
l’infrastruttura esistente e razionalizzando processi e risorse.

8. Nasce S.C.A.
Servizio di Connettività d’Ateneo
L’insieme di infrastrutture tecnologiche e di regole tecniche, per lo sviluppo, la
condivisione, l’integrazione e la diffusione del patrimonio informativo e dei dati
dell'Università, necessarie per assicurare l’interoperabilità di base ed evoluta e la
cooperazione applicativa dei sistemi informatici e dei flussi informativi, garantendo
la sicurezza, la riservatezza delle informazioni, nonché la salvaguardia e l’autonomia
del patrimonio informativo di ciascuna componente dell'Ateneo.

9. Network & Services Infrastructure
a.k.a. progetto belfagor

10. Requisiti I
• Modello organizzativo simile a GARR
• Autonomia nella gestione dei servizi
• Strumenti di gestione condivisi
• Accesso alla rete autenticato

11. Requisiti II
• Affidabilità del servizio
• Robustezza dell’infrastruttura
• Scalabilità (es. progetto scuole, enti esterni, etc )
• Flessibilità del modello (da afferenza amministrativa a
geografica)
• Segregazione (un polo un dominio di routing)

12. GARR-X Prima del 2013
Torricelli Fibonacci
Cisco NAC
Auth GW
131.114.242.1
Same Broadcast domain
A
131.114.242.6
Ingegneria
B
131.114.242.7
Rete Autentica Capitive Portal
131.114.242.0/24
DNS, DHCP,
RADIUS, LDAP
Dip. di Informatica
DNS, DHCP, Radius, etc
131.114.2.0/24
Distribution
Backbone

13. GARR-X Nuovo modello
Torricelli Fibonacci
Same Broadcast domain
A
131.114.242.6
Ingegneria
B
131.114.242.7
Rete Autentica 802.1x
131.114.242.0/24
Port-Based Auth
802.1x
Dip. di Informatica
Distribution
Backbone
Services
ERP
Port-Based Auth
802.1x
Port-Based Auth
802.1x

14. TORing
Anello in fibra alternativo al traffico
di produzione
n.2 EX 4200 24T VC
n.2 Dell R420 (8 Cores, 40GB RAM)
Ethernet Ring Protection
G.8032v2
Compute Node 1
ring0: 172.19.0.2
Compute Node 2
ring0: 172.19.0.3
VMs
ringU: 172.19.1.100 (management)
monoid: 131.114.138.100 (services)
VMs
ringU: 172.19.1.101 (management)
monoid: 131.114.138.101 (services)
Polo 1
Polo 6
Polo 5
Polo 3
Polo 2
Polo 4

15. S.C.A. Rack
~90.000 € una tantum
~3000 € /anno
~6000 utenti
24 rack units
4 kw
1U
2U
3U
4U
5U
6U
7U
8U
9U
10U
11U
12U
13U
14U
15U
16U
17U
18U
19U
20U
21U
22U
23U
24U
Cisco 5500 Series Wireless Controller
Model 5508
RP SP USB1 USB2 EN EN 1 2 3 4 5 6 7 8 PS1 PS2 SYS ACT
Cisco ISE 3315 Series
Identity Services Engine
ReWritable
Out Of Band EX 2200
Router di Polo MX 240
TORing EX 4200
WLC 5500
Cisco ISE 3315 Series
Identity Services Engine
ReWritable
NAC Appliance
OpenStack Nodes
UPS Units

16. Automated Provisioning

17. Provisioning
Possiamo descrivere i servizi (DNS, DHCP, radius, etc ) come delle
applicazioni formate da due componenti: la configurazione del servizio
che determina il comportamento dell’applicazione e il contesto di
esecuzione in cui l’applicazione viene eseguita.
Il processo di provisioning si preoccupata di rendere disponibile le
applicazioni agli amministratori, creando il contesto di esecuzione e
applicando la configurazione prevista per quel particolare servizio.

18. Provisioning Model
• Robusto (comportamento ragionevole in situazioni
impreviste)
• Processi asincroni
• Operazioni idempotenti

19. Provisioning Tools
• Versioning - GIT Repository (OpenSource)
• Virtualizzazione - OpenStack (OpenSource)
• Configuration Management I - Ansible (OpenSource)
• Configuration Management II - IPControl (Commerciale)

20. Virtualizzare
Perché Come
• Consolidamento
Hardware
• Automazione
• Technology agnostic
• Multitenant
• Programmable (Api)
• Community based
20

21. Virtualizzare
• Debian wheezy
• Virtualizzazione KVM
• Openstack Icehouse

22. Architettura
Ethernet Ring Protection
G.8032v2
VMs
ringU: 172.19.1.100 (management)
monoid: 131.114.138.100 (services)
VMs
ringU: 172.19.1.101 (management)
monoid: 131.114.138.101 (services)
Polo 1
Polo 6
Polo 5
Polo 3
Polo 2
Polo 4
Polo 4
Network Compute
Polo 5
Network Compute
Polo 3
Network Compute
Polo 2
Network Compute
Polo 1
Network Compute
Polo NOC
Storage
Controller Controller

23. Architettura
• Rete semplice ma centrale
• La virtualizzazione deve garantire la continuità di
servizio
• Il contesto di esecuzione localizzato in qualunque
nodo, si predilige il nodo locale.

24. Configuration Management I
• Semplice (YAML, no programming)
• Agentless (solo SSH )
• Una buona comunità di sviluppo
• Network oriented

25. Configuration Management I

26. Cosa fa Ansible ?
• Configura apparato di accesso dei nodi di computing
• Crea le istanze virtuali utilizzando OpenStack API
• Configura le istanze create (network, syslog, nagios,
etc)

27. Provisioning Workflow
1 Launch the book
Compute
Node 1
Compute
Node 2
OpenStack
Controller
Switch
Ring Node
VM
VM
0 Push the book
1 Using hooks
nova_compute:
2 Create Instances
3 configure the network
4 configure instances

28. Configuration Management II
• Gestione dello spazio di indirizzamento IPv4 e IPv6
• Configurazioni DNS e DHCP integrata con IPAM
• Logica multi tenant per risorse e funzioni
• Conforme al modello di provisioning e al software
utilizzato (ISC DHCP, BIND9, etc)
• Deploy delle configurazioni dei servizi
• Web user interface

29. Configuration Management II
Prodotto D.D.I Commerciale di BT

30. Services
Per ogni polo:
Modello Active/Active
• n.2 Ldap Replicas
• n.2 Radius
• n.2 DHCP (internal failover)
• n.2 DNS Cache
• n.2 LOG Rounting

31. Admin Side
• Interfaccia web D.D.I. da cui gestire le configurazioni ed
effettuarne il deploy
• Interfaccia OpenStack per la gestione delle regole di
firewall e per riavviare o ricreare le istanze
• Accesso in console alle istanze virtuali ed apparati
• Strumenti di monitoring

32. Admin side
Tipologie di accesso
L2/L3 VPN
802.1x
Guest
Captive portal
No auth (server)
Network Devices
Networking
Node
Compute
Node
Building Switch
Floor Switch
Router di Polo
VPN Services Switch
Polo Admin
IPControl Dashboard
OpenStack Dashboard
Ansible Dashboard

33. Criticità e sviluppo

34. Criticità
• Single Point of Failure (Router)
• Formazione del personale
• Complessità

35. Miglioramenti
• Automazione del livello di distribuzione (SDN)
• Automazione del processo di installazione di Openstack
• Utilizzo dei container (Dockers) al posto di KVM
• Meccanismi di High Availability per i servizi

36. Fine

37. Domande ?