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

Cloud facilities @ Roma1 Cloud Computing per servizi o elaborazione dati Due sistemi di cloud separati (uno di produzione e uno di development) con OpenStack 2014.1 (codename Icehouse) VLAN-based Network node con connessioni a 10 Gbps Compute nodes con connessioni a 1 Gbps Infrastruttura condivisa di storage basata su gluster (3.4) Accesso standard via FUSE Accesso privilegiato tramite libgfapi, pieno supporto in OpenStack 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 Tier2 distribuito) Prototipo di cluster Ceph disponibile e in attesa di primo utilizzo 2

Cloud facilities @ Roma1 [2] 3

Cloud facilities @ Roma1 [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 OpenStack Lo splitter di calibrazione è stato integrato nella Cloud Servizi di calibrazione (DB, WebInterface, 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 LBaaS (Load-Balancer as a Service) di OpenStack 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 OpenStack, in quanto è HARDWIRED nel codice!!! 5

Status [2] Test di utilizzo dell’autoscaling Alcuni servizi possono giovare dell’autoscaling, in combinazione con l’LBaaS 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 Infrastruttura di cloud 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 LBaaS e AutoScaling [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