Open City Platform: IaaS installazione automatica Cristina Aiftimiei, INFN-CNAF 25/09/2015 Quest'opera è distribuita con Licenza Creative Commons Attribuzione - Non commerciale - Condividi allo stesso modo 3.0 Italia.

Architettura piattaforma OCP 24/09/ OCP IaaS adapter Disaster Recovery as a Service (DRaaS) Real Environment (VM infrastructure, HW, network) IaaS / PaaS Management Flexible Resource Management Cloud to Cloud (C2C) Cloud to Ground (C2G) Service Composition Orchestrator brokering Queue system Openstack Native API Recipe (HEAT) API Lifecycle Engine API Monitoring engine PaaS layer API Cloud Formation as a Service (CFaaS) Billing engine App store Citizen's Marketplace Reusable components App Management Portal Authentication - Authorization - accounting API App API PRISMA ESB interface iPaaS Layer API mysql Postgre s SQL RDF Open Data Services RC Open Data Services RC Opendata from external source Open data engine Appserver IAAS providers

Livello IaaS di OCP La strato IaaS di OCP è basato su OpenStack  Modello di sviluppo open source oCon dipendenze di tipo open source oPuò essere eseguito su piattaforme interamente open source (ad es. Linux)  Processo di sviluppo aperto oDesign summit ogni 6 mesi, in cui gli sviluppatori ricevono requisiti e scrivono le specifiche per la release successiva  Comunità aperta oDecisioni prese con modello del tacito assenso oTutti i processi sono documentati e trasparenti La versione di “produzione” OCP è Juno, rilasciata a ottobre 2014, (  La versione successiva, chiamata Kilo, 30 aprile /09/ OCP IaaS

Novità in Juno Features & Bug risolti  342 nuove features integrate nel software di Juno  3,219 bugs risolti durante il ciclo di rilascio di Juno (6 mesi); 10% in più rispetto ad Icehouse  Driver e plugin - 97 drivers e plugins supportati Neutron L3 agent  Prima di Juno oEra possibile avere Network Node multipli per dividere il carico, con diversi router virtuali su diversi nodi oNon era possibile HA o ridondanza dei nodi oTutto il traffico era passante per un unico punto:  Il Network Node era un single point of failure. In caso di problem non era più possibile il traffico verso l’esterno e quello east-west tra le VM  Il rounting centralizzato provocava un collo di bottiglia nel flusso di traffico  In Juno oHigh Availability del Network Node  Il router viene assegnato a due l3-agent, uno attivo e uno passivo  Neutron--server gestisce l’assegnazione di un Virtual IP all’istanza attiva 4 OCP IaaS

Scenari d’uso ipotizzati per IaaS OCP (2/3) IaaS small cluster con High Availability (HA) Quando la quantità di utenti o di risorse da gestire non è molto grande è possibile procedere con una installazione completa e perfettamente funzionante anche non impegnando un numero di nodi troppo grande (4 o 5). Suddivisione risorse:  2 server fisici per cluster MySQL + RabbitMQ (3 VM), HA proxy server (2 VM), cloud controller + network node (2 VM)  2-3 server fisici per nodi Nova (compute nodes) e file system ridondato via Cinder o Swift. 5 OCP IaaS

IaaS – scenario HA 24/09/ OCP IaaS

Suddivisione Risorse  3 server fisici/virtuali per cluster MySQL/Percona + RabbitMQ, HA proxy server oPercona XtraDB Cluster –soluzione open-source di alta disponibilità active/active ed elevata scalabilità per il clustering MySQL®Percona XtraDB Cluster oHAProxy - soluzione gratuita, molto veloce e affidabile che offre elevata disponibilità, bilanciamento del carico, e proxy per applicazioni TCP e HTTP-basedHAProxy oKeepalived – fornisce servizi semplici e robusti per load-balancing e alta disponibilità di sistemi e infrastrutture basate su Linux.Keepalived oRabbitMQ - clustering nativoRabbitMQ  "As of Red Hat Enterprise Linux OpenStack Platform 5 (Icehouse release), RabbitMQ replaces QPid as the default (and recommended) Message Broker."  soluzione per deployment con risorse limitate. Medio-piccolo (<=13 hypervisor/compute) oRequisiti:  8G RAM (Mongo + Mysql), 4CPU (MySQL+ Rabbit), disco ~ G  1 server di frontend, fisico/virtuale, per Foreman & Puppet-master e Zabbix (monitoring)Zabbix oRequisiti:  8G RAM, 4CPU  2 server fisici per OpenStack Controller & Network node oRequisiti:  32G RAM, 8CPU  N server per nodi OpenStack Nova (compute nodes)  3 server o spazio disco disponibile su 3 Compute Node – per Storage oCEPH - sistema di storage unificato, distribuito progettato per prestazioni eccellenti, affidabilità e scalabilità; una soluzione per Object Storage, Block Storage, FileSystem distribuitoCEPH oGlusterFS – network filesystem scalabile, che permette l'utilizzo di hardware comune off-the-shelf, è possibile creare soluzioni di storage distribuiti per lo streaming media, l'analisi dei dati, e di altri compiti data-and- bandwidth-intensive.GlusterFS 24/09/ OCP IaaS

Suddivisione Risorse (2) 2 server fisici per OpenStack Controller & Network node  I Controller in HA active/active  Network: oactive/active il DHCP-agent oL3-agent hot-standby reciproci, Neutron usa “chance-scheduler”  Requisiti: o8CPU (16 per Keystone), 32G RAM, oMacchine fisiche per prestazioni maggiori, dpdv network oShared FS tra I Controller per Glance (per snapshots >=1TB)!!  Se CEPH – possiamo mettere CEPH come Glance backend oStoreage - non locale, non NFS – single-point-of-failure oConfigurazione Rete:  Una rete privata Management – privata (sia O.S che provisioning, rete di accesso a SharedFS ) data-plane neutron (communicazione tunnel Gre, Net -> Compute tra di loro) – privata – jumbo-frame abbilitati, MTU>1500  Una rete publica: API endpoint Floating IP Neutron 24/09/ OCP IaaS

Suddivisione Risorse (3) Compute  Requisiti rete: o1 bond – traffico di neutron, privata, piu’ banda per lo shared FS (CEPH)  Apparati supportano bonding + jumboframe o1 pubblica – per connetersi esternamente per le varie installazioni di O.S Shared FS  Scelta CEPH oAl momento industry standard per O.S o99% di quello che serve a O.S. – storage VM, per imaginie e volumi, CEPH lo supporta nativamente, pronto, senza config speciali oLeggermente piu’ semplice da config, resiliente ai crash  Faccile management (e setup) oSe in futuro Cinder e/o Swift  “gratis” con CEPH –servizio apparte di CEPH (parla il protocollo Swift, non serve avere per forza Swift) 24/09/ OCP IaaS

Metodi di installazione IaaS OCP ha valutato differenti metodi di installazione IaaS. La scelta di quale adottare da parte delle Regioni sperimentatrici dipende da fattori come  grado di familiarità con OpenStack  interesse ad approfondire la configurazione  necessità di configurazioni particolari, etc. 1.Installazione e configurazione manuale (“hard core”). 2.Installazione con tool di automazione data center come Puppet e/o Foreman. 3.Installazione semi-automatica (con interfaccia grafica) attraverso il tool Fuel. 10 OCP IaaS

Installazione e configurazione manuale Stato dei lavori:  Al momento sono disponibili le guide di installazione per il deployment multi-nodo con o senza HA  Le versioni successive delle guide - configurazioni avanzate oabilitazione del supporto SSL per la dashboard e l’identity service, crittografia dei block device, etc.  Le guide sono state testate e verificate anche da team diversi Davide Salomoni, 3/12/ OCP IaaS

Installazione con tool di automazione (1) Puppet  strumento che ha lo scopo di automatizzare le procedure all’interno di un data center  mette a disposizione dei moduli per l’installazione e la configurazione automatica di OpenStack. Una volta definita la configurazione in Hiera, un componente aggiuntivo di Puppet che permette la configurazione in maniera gerarchica, l’agente avvierà il processo d’installazione e configurazione. Al termine del processo sarà prodotto un report  Eventuali errori possono essere dovuti solo a errata (o a mancanza di) configurazione. Davide Salomoni, 3/12/ OCP IaaS

Installazione con tool di automazione (2) E’ possibile gestire l’installazione di OpenStack attraverso Puppet anche via interfaccia grafica, con l’utilizzo del tool Foreman.  Utilizzo di un interfaccia web unica per fare provisioning di hosts linux (Redhat, CentOS, Ubuntu, Debian, Suse) e gestire sia i moduli puppet che i componenti openstack;  Facilità di installazione di componenti openstack usando i moduli stackforge onon è necessaria una conoscenza profonda di OpenStack per installarlo e configurarlo; Davide Salomoni, 3/12/ OCP IaaS

Installazione con tool di automazione - Status Documentazione:  p/wiki p/wiki Codice   Project tracking & roadmap  p/issues p/issues Davide Salomoni, 3/12/ OCP IaaS

Ambiente testbed Regione Marche - Small Cluster in HA 24/09/ OCP IaaS I network node sono server fisici Gli hypervisor avranno 2TB ciascuno di spazio SAN (totale 6TB) invece di spazio sui dischi locali, e 4 schede Gigabit (di cui 2 fasciate) invece che le 2 richieste Per i servizi sono state ipotizzate 2 macchine fisiche su cui installare un hypervisor KVM (preferibilmente Proxmox). Complessivamente:  2 server Hypervisor KVM totale 16 CPU-core, 64 GB RAM su cui ospitare: o3 VM con 2 VCPU e 8 GB RAM per cluster MySQL e RabbitMQ o2 VM con 1 VCPU e 2 GB RAM per HA proxy server  2 server con 8 (V)CPU e 32 GB RAM ciascuno per Controller+Network node  3 server totale 48 CPU-core, 192 GB RAM, TB HD, su cui ospitare i Compute node e il file system ridondato per Cinder e/o Swift

BACKUP SLIDES 24/09/ OCP IaaS

Novità in Icehouse/Juno (2) Identita’ Federata  In Icehouse ouna o più cloud OpenStack possono integrarsi con un Identity Provider oSingle sign-on su diverse cloud oAsserzioni SAML trasformate in attributi Keystone (che agisce da Service Provider)  In Juno oCritica per poter usare cloud ibride oKeystone di una cloud privata diventa IdP e keystone di altre cloud private/pubbliche diventa SP oAttributi Keystone trasformati in asserzioni SAML Glance  Aggiunto metadata service  Gestione di metadati aggiuntivi per diversi servizi OpenStack  Definiti come coppie chiave/valore  Le proprietà possono essere raggruppate in namespace, associati a uno o più tipi di risorsa (Image, Flavor, Volume, etc.) Neutron L3 agent  Prima di Juno oEra possibile avere Network Node multipli per dividere il carico, con diversi router virtuali su diversi nodi oNon era possibile HA o ridondanza dei nodi oTutto il traffico era passante per un unico punto:  Il Network Node era un single point of failure. In caso di problem non era più possibile il traffico verso l’esterno e quello east-west tra le VM  Il rounting centralizzato provocava un collo di bottiglia nel flusso di traffico  In Juno oHigh Availability del Network Node  Virtual Router Redundancy Protocol (VRRP)  Il router viene assegnato a due l3-agent, uno attivo e uno passivo  Keepalived gestisce l’assegnazione di un Virtual IP all’istanza attiva oDistributed Virtual Router (DVR)  Funzionalità dell’ l3-agent sui Compute node 17 OCP IaaS

Novità in Icehouse/Juno (3) Nova  In Juno: oSi può far partire una VM corrotta con una immagine diversa dalla originale oScheduling  Permette l’evacuazione completa di un nodo  I nodi di destinazione delle istanze sono scelte dallo scheduler Trove  In Icehouse oSupporto a MySQL singola istanza oSupporto sperimentale per DB NoSQL oVM con porta MySQL aperta e accesso dell’utente al server oPoco usabile da esperienze INFN  In Juno oSupporto a MySQL cluster con Galera oSupporto a PostgreSQL oSupporto iniziale modalità cluster per MongoDB oFunzionalità di backup e restore solo su Swift Ceilometer  Miglioramenti nelle performance  Metering di nuovi servizi di rete: oLBaaS, FWaaS e VPNaaS Heat  Rollback di deployment falliti oPrima bisognava cancellare gli elementi dello stack  Amministratori possono delegare utenti per la creazione di certe risorse (come autoscaling) 18 OCP IaaS

Novità in Icehouse/Juno (4) Horizon  Icehouse oMigliore usabilità  Possibilità di editare inline i valori nelle tabelle  Filtri di ricerca meno generici  Menu di navigazione più estendibile oNova  Live Migration  Gestione di host aggregation e availability zone oCinder  Estensione di un volume  Creazione di un volume come copia di un altro oCeilometer  Report dell’uso giornaliero per tenant visibile agli amministratori oSupporto per RBAC (Role Based Control Access)  Per Glance e Cinder  Si possono implementare regole di accesso alle risorse più fini dei semplici ruoli "member" e "admin“  E’ possibile ad esempio definire se un utente può creare, accedere, o cancellare immagini  Juno oNova  Mostra ad un utente le eventuali azioni svolte da altri utenti sulle VM del tenant  Evacuazione di un hypervisor  Live migration di tutte le VM da un hypervisor agli altri oMigliorato il supporto per RBAC (role based control access)  Per compute, network e orchestration (oltre che per Glance e Cinder come già in IceHouse) oNeutron  Possibilità di configurare i router con DVR  Possibilità di usare L3 agent HA 19 OCP IaaS 24/09/2015