Il TechAdvisor Michelangelo Uberti spiega come realizzare un servizio di Database-as-a-Service basato su MySQL e Docker. I punti trattati durante la presentazione sono: - DB-as-a-Service: la semplicità del concept - I possibili approcci - Architettura di alto livello - Focus sul Management Agent - Orchestration at work - Da cgroups a Docker - Le sfide principali - Quale futuro? Per saperne di più, scaricate le slide e guardate il video della presentazione del nostro TechAdvisor su http://www.par-tec.it/dbaas-con-docker-un-caso-di-studio

1. #osd2015
DBaaS con Docker: un caso di studio
Michelangelo Uberti, Marketing Analyst

2. Par-­Tec e Red Hat: 10 anni di successi
Par-­Tec è un software & infrastructure system integrator che si distingue per:
• la proposizione al mercato di servizi professionali altamente qualificati e soluzioni innovative
• il rispetto degli standard e l’adozione di tecnologie open source
L’avventura col cappello rosso è iniziata 10 anni fa con l’adozione del GFS, la
specializzazione su RHEL e l’evoluzione verso il middleware e la più recente Cloud
Infrastructure.
Il nostro attuale rapporto con Red Hat?
Red Hat Premier Business Partner con specializzazione Datacenter Infrastructure

3. DB-­as-­a-­Service: la semplicità del concept
I macro-­obiettivi del progetto
Semplicità
d’uso
Provisioning
immediato
Accesso via console
web e client TCP
Fatturazione
Flat e Pay-­per-­use (to be)
Orientato alla
vendita massiva
L’idea del Cliente (correva l’anno 2012…)
Offrire un servizio di database remoto che garantisse:
• accesso via internet mediante strumenti e protocolli standard
• condivisione multi-­tenant delle risorse computazionali
• gestione dell’infrastruttura centralizzata

4. I possibili approcci: Single vs. Multi-­instance
Single-­instance
1 istanza : 1 VM
Multi-­instance
n istanze : 1 VM
PRO
• Controllo completo di OS e DBMS.
• Dimensionamento puntuale della VM.
• Estremamente personalizzabile dal
punto di vista applicativo.
• Adatto a chi dispone delle competenze
interne.
• Semplicità di gestione da parte dell’utilizzatore finale.
• Nessun onere relativo al patch mgmt, backup, etc.
• Tempi e costi di provisioning ridotti.
• Fruizione via web e client SQL compatibile.
• Fatturazione Flat e (in futuro) Pay-­per-­use.
• Orientato alla vendita massiva.
CONTRO
• Inadatta ad utenti privi di competenze
sistemistiche.
• Il servizio è più esposto a rischi di
sicurezza legati alla gestione da parte
dell’utente finale.
• Richiede una VM per ogni Cliente.
• Inadatto ad utenti che richiedono configurazioni fuori
standard.
• Inizialmente non prevedeva configurazioni in HA e
replica.

5. I possibili approcci: perché non usare Trove?
Perché reinventare l’acqua calda anziché scegliere Trove?
• Il nostro progetto è nato nell’estate del 2012, la prima release pubblica di Trove è stata rilasciata
in OpenStack Havana a fine 2013
• Trove richiede OpenStack (you don’t say?)
• Trove è progettato per erogare database single-­tenant, perciò mantiene un rapporto 1:1 tra
machine instance e database instance
Trove is Database as a Service for OpenStack. It's designed to run entirely on
OpenStack, with the goal of allowing users to quickly and easily utilize the features
of a relational or non-­relational database without the burden of handling complex
administrative tasks.
”
“

6. Architettura di alto livello
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
TCP

7. 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
TCP
Architettura di alto livello
VM
(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

8. 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
TCP
Architettura di alto livello
Il Customer Portal consente all’utente finale di:
• gestire il proprio contratto
• connettersi al db da un’interfaccia web-­based
L’Admin Portal è dedicato alla gestione della
piattaforma da parte del Marketing e delle Operations.

9. 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
TCP
Architettura di alto livello
Il SQL Proxy consente all’utente connettere i client e le
proprie applicazioni mediante connessione SQL-­compatibile.
L’obiettivo del wrapper è filtrare tutti i comandi amministrativi,
proteggere l’utente da sé stesso e semplificare il rilascio di
nuove funzionalità.

10. 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
TCP
Architettura di alto livello
Il DWH-­Report è il database centralizzato che
contiene i dati di configurazione e tutte le metriche di
funzionamento utilizzabili ai fini della fatturazione.
Disporre di dati puntuali è utile a tutti:
• il Marketing può progettare dei profili migliori
• l’utente può verificare l’adeguatezza del profilo scelto

11. 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
TCP
Architettura di alto livello
Il Platform Orchestrator è il punto di contatto tra i
sistemi di provisioning esterni e la piattaforma.
Trasforma ogni richiesta in una serie di comandi per gli
agent a bordo dei DB Host, istanzia nuovi container e
nuovi DB Host.

12. Focus sul Management Agent
POST /dbaas/v1/instancecreate/
{
'user': 'mario.rossi',
'profile': 'gold',
'port': '12345',
'wwid': 'disk-wwid',
}
cgcreate –g memory,blkio,cpu,cpuset:gold
…
mount /dev/mapper/dbdataXXXp1 /data/mariorossi-1
…
cgexec mysql_install_db –datadir /data/mariorossi-1
…
È la componente che traduce dei comandi di alto livello in task complessi eseguiti sui DB Host, ad es:
• Creazione di un nuovo container
• Riconfigurazione e dismissione di un container esistente
• Migrazione e upgrade di profilo
• Gestione del processo mysqld (start, stop, restart, etc.)

13. Orchestration at work

14. Orchestration at work
L’utente acquista il profilo Gold del DBaaS offerto dal provider.
Il suo contratto viaggia all’interno della catena di delivery.

15. Orchestration at work
DBaaS Platform
La richiesta arriva al Platform Orchestrator della nostra piattaforma

16. Orchestration at work
DBaaS Platform
L’Orchestrator interroga il DWH-­Report per verificare la disponibilità di slot per il profilo Gold

17. Orchestration at work
DBaaS Platform
Oops, gli slot Gold sono finiti!
Lancia una nuova VM di tipo Gold, la aggiunge al pool di DB Host e crea i nuovi slot sul DWH-­Report

18. Orchestration at work
DBaaS Platform
Gli slot Gold sono disponibili!
Riserva uno slot, lancia il nuovo container sul DB Host di riferimento e aggiorna i dati sul DWH-­Report

19. Orchestration at work
DBaaS Platform
Il Platform Orchestrator completa il task e restituisce le informazioni alla catena di delivery.
Alla fine del processo l’utente riceve una mail con IP, porta e credenziali d’accesso.

20. Da cgroups a Docker
VERSIONE 1 VERSIONE 2
cgroups + selinux Docker
La limitazione delle risorse assegnate al
processo mysqld e la separazione del
contesto di sicurezza era gestita mediante la
configurazione manuale di cgroups + selinux.
La versione di MySQL era identica per tutte le
istanze all’interno della stessa VM.
L’istanza di MySQL viene eseguita in un
container dedicato, il quale gestisce
nativamente la limitazione delle risorse e del
namespace.
Potenzialmente, ogni istanza potrebbe usare
una diversa versione di MySQL.

21. Da cgroups a Docker: un esempio concreto
cgroups + selinux Docker
cd /sys/fs/cgroup/memory/gold/
echo 1 > memory.oom_control
echo 10 > memory.swappiness
echo 1000000000 > memory.limit_in_bytes
…
chcon -R --reference /template/mariorossi-1
/volume-path
…
Docker run …
--memory=1g
--cgroup-parent=gold
--oom-kill-disable=true
--memory-swappiness=10
--name=mariorossi-1
--user=mariorossi-1
dbaas-gold …

22. Le sfide principali (alcune delle tante…)
• Gestione dei log delle istanze di database
• Gestione della concorrenza nell’accesso all’I/O
• Performance tuning di Linux e MySQL su istanze multiple, es:

23. Quale futuro?
VERSIONE 1 VERSIONE 3
cgroups + selinux Docker
VERSIONE 2
Whatelse?
Ipotesi per la v3:
• Fatturazione pay-­per-­use
• Scelta della versione di MySQL in fase di provisioning
• HA dei container, ad es. con Kubernetes e Atomic Host
• Snapshot autogestiti per gestire eventuali attività distruttive o backup
• Integrazione con Trove?

24. #osd2015
Thank you
Michelangelo Uberti, Marketing Analyst