ATLAS PRIN Roma 1 status Alessandro De Salvo

ATLAS PRIN Roma 1 - status Alessandro De Salvo 18 -06 -2014 A. De Salvo – 18 giugno 2014

Cloud facilities @ Roma 1 § Cloud Computing per servizi o elaborazione dati § Due sistemi di cloud separati (uno di produzione e uno di development) con Open. Stack 2014. 1 (codename Icehouse) § VLAN-based § Network node connessioni a 10 Gbps § Compute nodes connessioni a 1 Gbps § Infrastruttura condivisa di storage basata su gluster (3. 4) § Accesso standard via FUSE § Accesso privilegiato tramite libgfapi, pieno supporto in Open. Stack tramite i volumi cinder § Lo storage gluster è ulteriormente condiviso con la sede di Napoli, con replica sincrona via WAN (vedi il talk di Napoli sul prototipo di Tier 2 distribuito) § Prototipo di cluster Ceph disponibile e in attesa di primo utilizzo 2

Cloud facilities @ Roma 1 [2] 3

Cloud facilities @ Roma 1 [3] § Gestione integrata delle macchine tramite Foreman/Puppet § Istanza di Foreman/Puppet centrale, usata sia per le macchine reali che per le macchine nella cloud § Intregrazione tra Foreman e cloud-init tramite un plugin sviluppato ad-hoc, a partire da un modulo iniziale del CERN § Istanza di Foreman utilizzabile anche per altri siti di italiani, ove necessario § Installazione dei sistemi di cloud tramite moduli preparatori custom di puppet + packstack § I moduli puppetlabs-openstack hanno ancora dei problemi di stabilità § Inizialmente utilizzavamo quei moduli, facendone estensioni customizzate 4

Status § Infrastruttura di calibrazione di ATLAS migrata su Open. Stack § Lo splitter di calibrazione è stato integrato nella Cloud § Servizi di calibrazione (DB, Web. Interface, Submission facilities) § Accesso alle code locali LSF § Accesso alle altre facility locali di Roma (squid, NFS shares, ecc) § Test per integrazione degli squid di Frontier § Test di utilizzo dei servizi LBaa. S (Load-Balancer as a Service) di Open. Stack § Qualche problema di stabilità e di performance in haproxy, in quanto Frontier invia moltissimi pacchetti di piccole dimensioni § Haproxy può essere configurato per girare in multi-process mode, seppur perdendo la possibilità di connessioni persistenti § Per fare questo bisogna editare i file di python di Open. Stack, in quanto è HARDWIRED nel codice!!! 5

Status [2] § Test di utilizzo dell’autoscaling § Alcuni servizi possono giovare dell’autoscaling, in combinazione con l’LBaa. S § Squid § DB cluster nodes § Web services § UI/WN ? § … § Sono stati iniziati i test preliminari per l’utilizzo di questa feature § Il meccanismo funziona (dopo aver risolto un baco introdotto dalla configurazione di packstack, che inserisce un endpoint sbagliato in heat. conf) § Facilmente integrabile con puppet per la (ri)configurazione on-the-fly § Up-scaling funzionante in modo ottimale § Down-scaling non triviale, soprattutto per macchine interattive § Non è possibile definire a priori quale macchina verrà spenta dal down-scaling 6

Plans § Storage § Test di gluster 3. 5 [09/2014] § Test di Ceph [12/2014] § Test di sincronizzazione in WAN con aumento di latenza (Tier-2 distribuito NA-RM) [07/2014] § Infrastruttura di cloud § Finalizzazione dei test con LBaa. S e Auto. Scaling [09/2014] § Applicazione dei concetti di cui sopra a servizi reali, quali squid, DB cluster nodes, web services e nodi interattivi [12/2014] § Estensione della cloud mono-cella al Tier-2 distribuito [08/2014] § Estensione della cloud in un ambiente multi-cella (Tier-2 distribuito NA-RM) [12/2014] 7