MySQL Tech Tour 2016 - Database-as-a-Service con MySQL e Oracle Openstack
0 likes483 views
In occasione dell’Oracle MySQL Tech Tour 2016, il TechAdvisor Daniele Marcocci ha illustrato come Oracle OpenStack e MySQL Enterprise Edition permettono di realizzare un DBaaS funzionale e produttivo. Nella sessione introduttiva sono stati trattati i seguenti punti: - Capiamo l’architettura - Approfondimenti - Database-as-a-Service Per saperne di più, scaricate le slide e guardate il video della presentazione del nostro TechAdvisor su http://www.par-tec.it/database-as-a-service-con-mysql-e-oracle-openstack
Ad
More Related Content
Viewers also liked (20)
Similar to MySQL Tech Tour 2016 - Database-as-a-Service con MySQL e Oracle Openstack (20)
Ad
More from Par-Tec S.p.A. (20)
Ad
MySQL Tech Tour 2016 - Database-as-a-Service con MySQL e Oracle Openstack
- 1. partita iva e codice fiscale: 12938200156 c.c.i.a.a. milano n.1599095 registro imprese 12938200156 capitale sociale € 2.418.433,00 i.v. direzione e sede legale via campanini 6 20124 milano tel: +39 02/66.732.1 – fax: +39 02/66.732.300 unità operativa p.zza san benedetto da norcia 33 00071 pomezia (rm) tel: +39 06/9826.9600 – fax: +39 06/9826.9680 Daniele Marcocci, Senior System Engineer Oracle MySQL Tech Tour, 10 e 12 Maggio 2016 Database-as-a-Service con MySQL e Oracle OpenStack
- 3. 3 Architettura di esempio Per approfondimenti: http://docs.openstack.org/openstack-ops/content/example_architecture.html Il diagramma rappresenta una tipica infrastruttura di produzione che include: • 2 x Controller node in HA • 4 x Compute node indipendenti • 2 x Network node in HA • 4 x Storage node
- 4. 4 Architettura di esempio Per approfondimenti: http://docs.openstack.org/openstack-ops/content/example_architecture.html Il diagramma rappresenta una tipica infrastruttura di produzione che include: • 2 x Controller node in HA • 4 x Compute node indipendenti • 2 x Network node in HA • 4 x Storage node CONTROLLER NODE Sono i nodi che garantiscono il funzionamento dell’intera infrastruttura. Espongono la dashboard e tutte le API, erogano i servizi di identity e gestiscono in HA il database di back- end per i servizi. I controller sono connessi alla rete di gestione interna e alla rete esterna/pubblica.
- 5. 5 Architettura di esempio Per approfondimenti: http://docs.openstack.org/openstack-ops/content/example_architecture.html Il diagramma rappresenta una tipica infrastruttura di produzione che include: • 2 x Controller node in HA • 4 x Compute node indipendenti • 2 x Network node in HA • 4 x Storage node COMPUTE NODE Sono i nodi che eseguono fisicamente le VM. Ogni nodo esegue anche il virtual switch L2 di Neutron. I compute node sono connessi alle due reti principali dell’infrastruttura: quella dedicata al traffico delle VM e quella ad uso interno.
- 6. 6 Architettura di esempio Per approfondimenti: http://docs.openstack.org/openstack-ops/content/example_architecture.html Il diagramma rappresenta una tipica infrastruttura di produzione che include: • 2 x Controller node in HA • 4 x Compute node indipendenti • 2 x Network node in HA • 4 x Storage node STORAGE NODE Sono i nodi che memorizzano tutti i dati della piattaforma, comprese le immagini ed i volumi persistenti. In questa architettura lo storage di back-end è gestito da GlusterFS. Gli storage node sono connessi esclusivamente alla rete interna.
- 7. 7 Architettura di esempio Per approfondimenti: http://docs.openstack.org/openstack-ops/content/example_architecture.html Il diagramma rappresenta una tipica infrastruttura di produzione che include: • 2 x Controller node in HA • 4 x Compute node indipendenti • 2 x Network node in HA • 4 x Storage node NETWORK NODE Sono i nodi che gestiscono l’intero ambiente di virtual networking della piattaforma, fornendo accesso alle VM da e verso le reti pubbliche. I network node sono connessi a tutte le reti dell’infrastruttura OpenStack e alle eventuali appliance fisiche compatibili.
- 9. 9 La gestione della multi-tenancy Le componenti core di OpenStack sono progettate per isolare dei set di risorse in strutture dette tenant o project. I permessi degli utenti afferenti a un tenant sono definiti mediante un classico modello role-based (RBAC). Per ogni tenant è possibile impostare dei controlli di quota che limitino: • il numero di istanze che possono essere lanciate (Nova); • la quantità di core e RAM allocabili (Nova); • il numero di oggetti o lo spazio totale utilizzabile (Swift); • Il numero di snapshot, volumi o lo spazio totale utilizzabile (Cinder); • il numero di floating IP e fixed IP assegnabili alle istanze (Nova). N.B. Il termine project risale alle prime versioni di OpenStack. Con l’introduzione di Keystone è stato adottato il termine tenant. I due termini sono attualmente interscambiabili. VLAN Volumi Istanze Utenti e chiaviImmagini
- 10. 10 Lo storage Ephemeral storage Block storage Object storage Usato per… Eseguire l’OS e disporre di spazio temporaneo Aggiungere storage persistente ad una VM Memorizzare dati, incluse le immagini delle VM Acceduto via… Un filesystem Un device a blocchi che può essere partizionato, formattato e montato dall’OS API REST Accedibile da… Dentro la VM Dentro la VM Ovunque Gestito dal modulo… Nova Cinder Swift Persiste finché… La VM è in esecuzione Viene cancellato dall’utente Viene cancellato dall’utente La dimensione è determinata da… Scelta del flavor da parte dell’amministratore Specifiche dell’utente in fase di setup Disponibilità dello spazio fisico Caso d’uso Disco primario: 10GB Disco secondario: 20-160GB Disco da 1TB Decine di TB OpenStack supporta tre macro-tipologie di storage che possono essere combinate o utilizzate singolarmente per rispondere a delle esigenze molto specifiche:
- 11. 11 Suddivisione logica del cloud OpenStack è nato per gestire migliaia di nodi distribuiti in più datacenter e aree geografiche. Tali risorse possono essere ripartite in quattro aggregazioni logiche: Perché creare queste ripartizioni? Le motivazioni possono essere molteplici: considerazioni legali sulla posizione fisica dei dati, latenza dei servizi su base geografica, licensing, logiche di HA e DR per garantire la continuità a fronte di disastri naturali e così via. Cells e Regions ripartiscono l’intero cloud in installazioni distinte di Compute che condividono solo alcuni elementi (es. Keystone). Availability zones e Host aggregates servono invece a ripartire una singola installazione di Compute.
- 13. 13 Partiamo dalle basi: cos’è un DBaaS? BACK TO BASICS: IL CONCETTO DI “AS-A-SERVICE” Indicando “qualcosa-as-a-Service” si intende dire che quel qualcosa è erogato da un’infrastruttura centralizzata – tipicamente un cloud – che soddisfa uno o più di questi requisiti: • attivazione on-demand • elasticità • pay-per-use → spesso non adottato per motivi commerciali (es. non piace all’utente finale) DEFINIAMO IL DBAAS È un servizio gestito da un cloud provider, pagato sulla base di un profilo scelto e/o dell’utilizzo fatto, che offre l’accesso ad un database engine per memorizzare i dati di un’applicazione. CHI RIMANE FUORI Le classiche installazioni monolitiche con un database per singolo utente NON sono DBaaS. Delle VM tradizionali con a bordo il DBMS NON sono DBaaS ma hosted database. Tutto ciò che richiede l’intervento manuale di un operatore per la prima configurazione e la manutenzione ordinaria NON è catalogabile come DBaaS.
- 14. 14 Quali opzioni a disposizione? 1 2 3 OpenStack Trove Un application catalog Progetto custom (con o senza OpenStack)
- 15. 15 Un esempio di DBaaS nato come progetto custom SAN Operations e MarketingUtente finale SQL SQL REST SQL HTTPS HTTPS CSV via SFTP CUSTOMER PORTAL ADMIN PORTAL BILLING PLATFORM ORCHESTRATOR DWH - REPORT DB HOST SILVER DB HOST GOLD DB HOST PLATINUM SQL via wrapper TCP Quasi due anni prima dell’uscita di Trove progettammo una piattaforma di DBaaS per uno dei principali service provider in Italia. Il funzionamento era del tutto analogo a ciò che oggi è quasi diventato lo standard.
- 16. 16 Un esempio di DBaaS nato come progetto custom SAN Operations e MarketingUtente finale SQL SQL REST SQL HTTPS HTTPS CSV via SFTP CUSTOMER PORTAL ADMIN PORTAL BILLING PLATFORM ORCHESTRATOR DWH - REPORT DB HOST SILVER DB HOST GOLD DB HOST PLATINUM SQL via wrapper TCP Quasi due anni prima dell’uscita di Trove progettammo una piattaforma di DBaaS per uno dei principali service provider in Italia. Il funzionamento era del tutto analogo a ciò che oggi è quasi diventato lo standard. VM Distro Linux supportata (OS) Istanza 1 Istanza 2 Istanza n Ogni VM esegue un container per ogni istanza di MySQL e il nostro agent di mgmt che espone le interfacce RESTful per l’amministrazione. Shared libraries Mgmt Agent Istanza 3
- 17. 17 Trove vs. Murano Trove Murano Presentato con la release Icehouse (Aprile 2014) Liberty (Ottobre 2015) Ultima versione (su Mitaka) 5.0 2.0 A cosa serve? Istanziare dei database relazionali e non, SQL e NoSQL. Istanziare interi ambienti (stack Heat) indipendentemente dal tipo di applicazione. Esiste una versione enterprise? Si, attualmente offerta solo da Tesora Si, è inclusa in Oracle OpenStack Pro Offre il supporto ai principali database engine e include funzionalità native per l’HA e il disaster recovery. È agnostico rispetto all’applicazione e all’ambiente e offre un catalogo di applicazioni pronto all’uso. Contro Le funzionalità sono limitate ai database supportati e non coprono diversi casi d’uso. Alcune specifiche funzionalità per i database vanno ricreate mediante script e configurazioni ad hoc. Facciamo un classico confronto all’americana…
- 18. 18 Murano in action Murano gestisce il deployment di ambienti complessi mediante l’orchestrazione di una serie di task che coinvolgono numerosi servizi OpenStack: Keystone, Glance, Heat e Horizon.
- 19. 19 Murano in action Murano gestisce il deployment di ambienti complessi mediante l’orchestrazione di una serie di task che coinvolgono numerosi servizi OpenStack: Keystone, Glance, Heat e Horizon. HTTP Horizon Murano Python Client Murano Dashboard 1 L’utente sceglie un’applicazione da Horizon e la componente web di Murano invia la richiesta al Murano Python Client
- 20. 20 Murano in action Murano gestisce il deployment di ambienti complessi mediante l’orchestrazione di una serie di task che coinvolgono numerosi servizi OpenStack: Keystone, Glance, Heat e Horizon. Murano API HTTPHTTP Horizon Murano Python Client Murano Dashboard 2 Il Murano Python Client inoltra la richiesta via REST al Murano API server
- 21. 21 Murano in action Murano gestisce il deployment di ambienti complessi mediante l’orchestrazione di una serie di task che coinvolgono numerosi servizi OpenStack: Keystone, Glance, Heat e Horizon. Murano API Murano Engine Heat HTTPHTTP AMQP HTTP Horizon Murano Python Client Murano Dashboard 3 Il Murano Engine prende in carico la richiesta dalla coda di lavorazione, crea un template Heat e lo invia all’Heat Engine per l’esecuzione
- 22. 22 Murano in action Murano gestisce il deployment di ambienti complessi mediante l’orchestrazione di una serie di task che coinvolgono numerosi servizi OpenStack: Keystone, Glance, Heat e Horizon. Murano API Murano Engine Heat Servizi OpenStack HTTPHTTP AMQP HTTP HTTP Horizon Murano Python Client Murano Dashboard 4 Il modulo Heat contatta i servizi core di OpenStack (es. Nova, Glance, Neutron) per istanziare l’environment richiesto da Murano
- 23. 23 Murano in action Murano gestisce il deployment di ambienti complessi mediante l’orchestrazione di una serie di task che coinvolgono numerosi servizi OpenStack: Keystone, Glance, Heat e Horizon. Murano API Murano Engine Heat Servizi OpenStack HTTPHTTP AMQP HTTP HTTP AMQP Istanza Nova Murano Agent Horizon Murano Python Client Murano Dashboard 5 Il Murano Engine contatta il Murano Agent a bordo delle singole istanze Nova per completare le configurazioni richieste
- 24. 24 Murano in action Murano gestisce il deployment di ambienti complessi mediante l’orchestrazione di una serie di task che coinvolgono numerosi servizi OpenStack: Keystone, Glance, Heat e Horizon. Murano API Murano Engine Heat Servizi OpenStack HTTPHTTP AMQP HTTP HTTP AMQP Istanza Nova Murano Agent Horizon Murano Python Client Murano Dashboard 6 Ad ogni step completato viene inviata una notifica alla Dashboard per far si che l’utente sia aggiornato sullo stato dell’environment richiesto
- 25. 25 Anatomia di un Application Package per Murano Un application package è un file zip di pochi KB che contiene la descrizione degli oggetti e gli script per istanziare l’ambiente applicativo - N.B. il package non contiene l’applicazione! Gli elementi essenziali sono tre: logo.png manifest.yaml Per l’inserimento del pacchetto nel catalogo delle applicazioni ui.yaml Con la struttura del form web per la configurazione da Horizon classes Con il codice per la configurazione dell’applicazione (istanza Nova o immagine Docker)
- 26. 26 Non solo OpenStack: aggiungiamo Docker alla ricetta La macchina virtuale include l’intero stack, dall’OS alle applicazioni. • PRO: elevato livello di personalizzazione e isolamento • CONTRO: overhead computazionale e gestionale, portabilità limitata, ridondanza delle licenze Il singolo container esegue un’istanza di un’immagine che include l’applicazione, le librerie condivise e le dipendenze. • PRO: overhead ridotto, ottimizzazione delle licenze, elevato grado di portabilità • CONTRO: condivisione del kernel, nessun meccanismo nativo di HA
- 27. 27 Non solo OpenStack: aggiungiamo Docker alla ricetta
- 28. Demo DBaaS
- 29. 29 Schema del laboratorio Il nostro laboratorio è composto da due nodi indipendenti che svolgono tutte le funzioni primarie di OpenStack: Compute, Controller, Network. OSP1 OSP2 Internal Par-Tec Network Tenant di test
- 31. direzione e sede legale via campanini 6 20124 milano tel: +39 02/66.732.1 – fax: +39 02/66.732.300 unità operativa p.zza san benedetto da norcia 33 00071 pomezia (rm) tel: +39 06/9826.9600 – fax: +39 06/9826.9680 Grazie per l’attenzione!