ݺߣ

ݺߣShare a Scribd company logo

MySQL Tech Tour 2015 - Soluzioni di alta disponibilità con MySQL

•
•
Par-Tec S.p.A.
Par-Tec S.p.A.

Il TechAdvisor Michelangelo Uberti fornisce una panoramica generale inerente le soluzioni di alta disponibilità con MySQL. I punti trattati durante la presentazione sono: - Presentazione dell’offerta Par-Tec dedicata a MySQL Enterprise - Cause, effetti e reali esigenze di HA - Funzionamento, benefici e limiti dei principali approcci: - Replica di database - Cluster attivo/passivo - Cluster attivo/attivo: shared-nothing Per saperne di più, scaricate le slide e guardate il video della presentazione del nostro TechAdvisor su http://www.par-tec.it/soluzioni-di-alta-disponibilita-con-mysql

1 of 19
Download to read offline
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 Michelangelo Uberti, Marketing Analyst MySQL Tech Tour Rome, 29 aprile 2015 Soluzioni di alta disponibilità con MySQL
Introduzione
3 Chi è Par-Tec La collaborazione con Oracle è iniziata 5 anni fa ma ha origini lontane: l’attuale business unit di Roma, ex Babel, è nata nel 1994 come braccio armato di Sun Microsystems sul mercato delle telco italiane. Il nostro attuale rapporto con Oracle? Gold Partner con specializzazione su MySQL 5 Par-Tec S.p.A. è un software & infrastructure system integrator che da oltre 15 anni: • eroga servizi professionali altamente qualificati • progetta di soluzioni cross-market innovative e personalizzate • è attivamente impegnato nella diffusione delle tecnologie open source
4 I nostri Clienti
5 La nostra offerta di servizi dedicata a MySQL Per invitarvi a provare MySQL Enterprise Edition abbiamo predisposto tre pacchetti promozionali adatti alle diverse fasi del processo di adozione. Assistenza in fase di progettazione, installazione e configurazione della vostra nuova infrastruttura basata su MySQL Enterprise Edition. COSA INCLUDE: • Licenza MySQL Enterprise Edition con uno sconto sul listino. • Pacchetto di 5gg di servizi professionali ad una tariffa dedicata. ADOPTION PACK Migrazione assistita dei servizi mission-critical dalla vostra attuale piattaforma per sfruttare rapidamente tutti i vantaggi di MySQL Enterprise Edition. COSA INCLUDE: • Licenza MySQL Enterprise Edition con uno sconto sul listino. • Pacchetto di servizio a prezzi e condizioni personalizzate. MIGRATION PACK Servizi professionali on-site e da remoto per consolidare e far evolvere la vostra infrastruttura basata su MySQL Community o Enterprise. COSA INCLUDE: • Pacchetto di 20gg di servizi professionali ad un prezzo imperdibile. • Training personalizzato (opzionale) del vostro team tecnico. SUPPORT PACK
Parliamo di High Availability
7 Le cause di un disservizio 80% 20% • Processi inadeguati • Errore umano • Disastri ambientali • Problemi hw/sw Fonte: Gartner
8 Iniziamo col ragionare sulle esigenze Tutti i progetti necessitano di una configurazione in HA? • Il DB sarà alla base di un servizio mission-critical? • Quali sono vincoli di business da considerare? • Quanto vi costa un disservizio? Tutti i servizi richiedono una disponibilità del 99,999%? • Analizzate gli SLA del servizio • Valutate sempre RTO e RPO • Occhio al budget! E’ vero che non c’è una soluzione giusta o sbagliata? • Ogni approccio risponde ad una esigenza specifica • La scelta dipende anche dall’ambiente operativo • Considerate sempre l’impatto sulle applicazioni
9 Costoecomplessità Capiamo come soddisfare le aspettative 9 36,5gg 9. 3,65gg 9 8,76hr 9 52,56min 9 5,26min % Replica di database Cluster A/P Shared nothing Windows Cluster Solaris Cluster Oracle Clusterware Oracle VM Ricordate che uptime ≠ availability e che la manutenzione programmata incide sulla disponibilità!
10 HA con MySQL: panoramica delle opzioni supportate MySQL Replication MySQL Fabric Oracle VM Template Oracle Clusterware Solaris Cluster Windows Cluster DRBD MySQL Cluster App Auto-Failover ✘ ✔ ✔ ✔ ✔ ✔ ✔ ✔ Data Layer Auto-Failover ✘ ✔ ✔ ✔ ✔ ✔ ✔ ✔ Platform Support All All Linux Linux Solaris Windows Linux All Clustering Mode Master + Slaves Master + Slaves A/P A/P A/P A/P A/P Multi-master Failover Time N/A Secs Secs + Secs + Secs + Secs + Secs + < 1 Sec Scale-out Reads ✔ ✘ ✘ ✘ ✘ ✘ ✔ Cross-shard operations N/A ✔ N/A N/A N/A N/A N/A ✔ Transparent routing ✘ For HA ✔ ✔ ✔ ✔ ✔ ✔ Shared Nothing ✔ ✔ ✘ ✘ ✘ ✘ ✔ ✔ Storage Engine InnoDB+ InnoDB+ InnoDB+ InnoDB+ InnoDB+ InnoDB+ InnoDB+ NDB Single Vendor Support ✔ ✔ ✔ ✔ ✔ ✘ ✔ ✔
11 Replica di database Principio di funzionamento • È l’approccio più comune per implementare l’HA in MySQL • È disponibile out-of-the-box con tutte le versioni di MySQL • È il modo più semplice per ridurre il rischio di perdita dei dati • Dalla 5.6 implementa anche le procedure automatiche di failover Come funziona? Duplica i dati da un “master” ad uno o più “slave” Session Dump I/O Master Database Slave Database Binary Log Relay Log SQL
12 Replica di database Disponibilità e scalabilità Chi ha detto che la replica serve solo a duplicare i dati? Master Pool di slave Web / App Server N.B. Il routing delle query deve essere gestito dal connettore o dalla logica applicativa Scale-out! Scritture Letture
13 Replica di database Modalità di replica Asincrona • Modalità di default • Il master conferma la commit all’applicazione e solo dopo invia i dati agli slave. PRO E CONTRO: • Nessuna latenza • Rischio di inconsistenza dei dati Semi-sincrona • Disponibile da MySQL 5.5 • Il master attende che almeno uno slave abbia ricevuto i dati prima di confermare la commit all’applicazione. PRO E CONTRO: • Latenza contenuta • Nessuna perdita di dati (MySQL 5.7) Sincrona • Solo con MySQL Cluster • Il Transaction Coordinator attende che gli altri data nodes coinvolti abbiano scritto le modifiche sulle repliche del/dei fragment per completare il commit. PRO E CONTRO: • Latenza maggiore • Nessuna perdita di dati Come monitorare le repliche? MySQL Replication Monitor
14 Replica di database Come superarne i limiti con MySQL Fabric • Alta disponibilità reale – Failover automatico – Il routing automatico delle query lo rende trasparente alle applicazioni • Scale-out via sharding (opzionale) – Sharding automatico – Include i tool per il resharding • Connettori nativi – Ruotano le query al server giusto – Nessun proxy = nessun collo di bottiglia – Già disponibili per PHP, Python, PERL, .NET e Java Fabric-aware Connectors Applications … Read-slaves HA Group Read-slaves HA Group MySQL Fabric Controller Queries
15 Cluster A/P Principio di funzionamento • Duplicare i dati può non bastare • L’HA non può affidarsi alla sola logica applicativa, per ridurre il downtime è necessario automatizzare le procedure di failover • Tali operazioni devono essere trasparenti per le applicazioni Come funziona? C’è un solo server attivo, gli altri sono in standby Oracle VM server pool SAN iSCSI/FC Oracle VM Oracle VM Approccio basato sulla virtualizzazione: Oracle VM Template for MySQL EE • Pienamente supportato, tutto incluso • Migrazione delle VM a caldo • Riavvio automatico delle VM • Bilanciamento delle risorse • Gestione integrata della rete Oracle VM Manager
16 Cluster A/P Approccio tradizionale su Windows e Linux Windows Server Linux App Virtual IP Quorum Data Bin SAN Windows Cluster App Virtual IP • Utilizza MySQL su Windows Cluster • Dati e quorum risiedono su SAN (iSCSI o FC) • Cluster gestito via snap-in di Windows • Disservizio ridotto sync • Consente di usare hw commodity • Non richiede fisicamente storage condiviso • La replica sincrona garantisce sicurezza • Stack open source, maturo e affidabile Servizi Cluster manager Pacemaker Corosync Pacemaker Corosync
17 Cluster A/A – Shared nothing Principio di funzionamento • Le soluzioni con replica di database hanno diversi limiti: – non vanno oltre il 99,9% – scalano bene sulle letture, decisamente meno sulle scritture – la consistenza non è sempre certa (errori umani, crash, ecc.) – il conflitto non è gestito (multi-master) • I cluster A/P hanno diversi limiti: – non vanno oltre il 99,99% – non sfruttano completamente l'hardware aggiuntivo (no scalabilità) Un’architettura shared nothing è un’architettura distribuita in cui ogni nodo è auto-sufficiente e indipendente dagli altri perché non ci sono elementi contesi (es. storage) e quindi single point of failure Come funziona? Cosa si intende per shared nothing?
18 Cluster A/A – Shared nothing MySQL Cluster • Si basa su tre tipi di nodi: – Application node – Data node – Management node • Nasce per scalare: – Multi-master – Auto-sharding – Nodi indipendenti – Geo-replica • Disponibilità a 5 nove – Nessuna risorsa condivisa – Self-healing + on-line operations • Supporta SQL + NoSQL • Richiede hw commodity MySQL Cluster Data Nodes Data Layer Application Layer Management Layer MySQL Cluster Management Nodes Clients …
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!

More Related Content

MySQL Tech Tour 2015 - Soluzioni di alta disponibilità con MySQL

  • 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 Michelangelo Uberti, Marketing Analyst MySQL Tech Tour Rome, 29 aprile 2015 Soluzioni di alta disponibilità con MySQL
  • 3. 3 Chi è Par-Tec La collaborazione con Oracle è iniziata 5 anni fa ma ha origini lontane: l’attuale business unit di Roma, ex Babel, è nata nel 1994 come braccio armato di Sun Microsystems sul mercato delle telco italiane. Il nostro attuale rapporto con Oracle? Gold Partner con specializzazione su MySQL 5 Par-Tec S.p.A. è un software & infrastructure system integrator che da oltre 15 anni: • eroga servizi professionali altamente qualificati • progetta di soluzioni cross-market innovative e personalizzate • è attivamente impegnato nella diffusione delle tecnologie open source
  • 5. 5 La nostra offerta di servizi dedicata a MySQL Per invitarvi a provare MySQL Enterprise Edition abbiamo predisposto tre pacchetti promozionali adatti alle diverse fasi del processo di adozione. Assistenza in fase di progettazione, installazione e configurazione della vostra nuova infrastruttura basata su MySQL Enterprise Edition. COSA INCLUDE: • Licenza MySQL Enterprise Edition con uno sconto sul listino. • Pacchetto di 5gg di servizi professionali ad una tariffa dedicata. ADOPTION PACK Migrazione assistita dei servizi mission-critical dalla vostra attuale piattaforma per sfruttare rapidamente tutti i vantaggi di MySQL Enterprise Edition. COSA INCLUDE: • Licenza MySQL Enterprise Edition con uno sconto sul listino. • Pacchetto di servizio a prezzi e condizioni personalizzate. MIGRATION PACK Servizi professionali on-site e da remoto per consolidare e far evolvere la vostra infrastruttura basata su MySQL Community o Enterprise. COSA INCLUDE: • Pacchetto di 20gg di servizi professionali ad un prezzo imperdibile. • Training personalizzato (opzionale) del vostro team tecnico. SUPPORT PACK
  • 6. Parliamo di High Availability
  • 7. 7 Le cause di un disservizio 80% 20% • Processi inadeguati • Errore umano • Disastri ambientali • Problemi hw/sw Fonte: Gartner
  • 8. 8 Iniziamo col ragionare sulle esigenze Tutti i progetti necessitano di una configurazione in HA? • Il DB sarà alla base di un servizio mission-critical? • Quali sono vincoli di business da considerare? • Quanto vi costa un disservizio? Tutti i servizi richiedono una disponibilità del 99,999%? • Analizzate gli SLA del servizio • Valutate sempre RTO e RPO • Occhio al budget! E’ vero che non c’è una soluzione giusta o sbagliata? • Ogni approccio risponde ad una esigenza specifica • La scelta dipende anche dall’ambiente operativo • Considerate sempre l’impatto sulle applicazioni
  • 9. 9 Costoecomplessità Capiamo come soddisfare le aspettative 9 36,5gg 9. 3,65gg 9 8,76hr 9 52,56min 9 5,26min % Replica di database Cluster A/P Shared nothing Windows Cluster Solaris Cluster Oracle Clusterware Oracle VM Ricordate che uptime ≠ availability e che la manutenzione programmata incide sulla disponibilità!
  • 10. 10 HA con MySQL: panoramica delle opzioni supportate MySQL Replication MySQL Fabric Oracle VM Template Oracle Clusterware Solaris Cluster Windows Cluster DRBD MySQL Cluster App Auto-Failover ✘ ✔ ✔ ✔ ✔ ✔ ✔ ✔ Data Layer Auto-Failover ✘ ✔ ✔ ✔ ✔ ✔ ✔ ✔ Platform Support All All Linux Linux Solaris Windows Linux All Clustering Mode Master + Slaves Master + Slaves A/P A/P A/P A/P A/P Multi-master Failover Time N/A Secs Secs + Secs + Secs + Secs + Secs + < 1 Sec Scale-out Reads ✔ ✘ ✘ ✘ ✘ ✘ ✔ Cross-shard operations N/A ✔ N/A N/A N/A N/A N/A ✔ Transparent routing ✘ For HA ✔ ✔ ✔ ✔ ✔ ✔ Shared Nothing ✔ ✔ ✘ ✘ ✘ ✘ ✔ ✔ Storage Engine InnoDB+ InnoDB+ InnoDB+ InnoDB+ InnoDB+ InnoDB+ InnoDB+ NDB Single Vendor Support ✔ ✔ ✔ ✔ ✔ ✘ ✔ ✔
  • 11. 11 Replica di database Principio di funzionamento • È l’approccio più comune per implementare l’HA in MySQL • È disponibile out-of-the-box con tutte le versioni di MySQL • È il modo più semplice per ridurre il rischio di perdita dei dati • Dalla 5.6 implementa anche le procedure automatiche di failover Come funziona? Duplica i dati da un “master” ad uno o più “slave” Session Dump I/O Master Database Slave Database Binary Log Relay Log SQL
  • 12. 12 Replica di database Disponibilità e scalabilità Chi ha detto che la replica serve solo a duplicare i dati? Master Pool di slave Web / App Server N.B. Il routing delle query deve essere gestito dal connettore o dalla logica applicativa Scale-out! Scritture Letture
  • 13. 13 Replica di database Modalità di replica Asincrona • Modalità di default • Il master conferma la commit all’applicazione e solo dopo invia i dati agli slave. PRO E CONTRO: • Nessuna latenza • Rischio di inconsistenza dei dati Semi-sincrona • Disponibile da MySQL 5.5 • Il master attende che almeno uno slave abbia ricevuto i dati prima di confermare la commit all’applicazione. PRO E CONTRO: • Latenza contenuta • Nessuna perdita di dati (MySQL 5.7) Sincrona • Solo con MySQL Cluster • Il Transaction Coordinator attende che gli altri data nodes coinvolti abbiano scritto le modifiche sulle repliche del/dei fragment per completare il commit. PRO E CONTRO: • Latenza maggiore • Nessuna perdita di dati Come monitorare le repliche? MySQL Replication Monitor
  • 14. 14 Replica di database Come superarne i limiti con MySQL Fabric • Alta disponibilità reale – Failover automatico – Il routing automatico delle query lo rende trasparente alle applicazioni • Scale-out via sharding (opzionale) – Sharding automatico – Include i tool per il resharding • Connettori nativi – Ruotano le query al server giusto – Nessun proxy = nessun collo di bottiglia – Già disponibili per PHP, Python, PERL, .NET e Java Fabric-aware Connectors Applications … Read-slaves HA Group Read-slaves HA Group MySQL Fabric Controller Queries
  • 15. 15 Cluster A/P Principio di funzionamento • Duplicare i dati può non bastare • L’HA non può affidarsi alla sola logica applicativa, per ridurre il downtime è necessario automatizzare le procedure di failover • Tali operazioni devono essere trasparenti per le applicazioni Come funziona? C’è un solo server attivo, gli altri sono in standby Oracle VM server pool SAN iSCSI/FC Oracle VM Oracle VM Approccio basato sulla virtualizzazione: Oracle VM Template for MySQL EE • Pienamente supportato, tutto incluso • Migrazione delle VM a caldo • Riavvio automatico delle VM • Bilanciamento delle risorse • Gestione integrata della rete Oracle VM Manager
  • 16. 16 Cluster A/P Approccio tradizionale su Windows e Linux Windows Server Linux App Virtual IP Quorum Data Bin SAN Windows Cluster App Virtual IP • Utilizza MySQL su Windows Cluster • Dati e quorum risiedono su SAN (iSCSI o FC) • Cluster gestito via snap-in di Windows • Disservizio ridotto sync • Consente di usare hw commodity • Non richiede fisicamente storage condiviso • La replica sincrona garantisce sicurezza • Stack open source, maturo e affidabile Servizi Cluster manager Pacemaker Corosync Pacemaker Corosync
  • 17. 17 Cluster A/A – Shared nothing Principio di funzionamento • Le soluzioni con replica di database hanno diversi limiti: – non vanno oltre il 99,9% – scalano bene sulle letture, decisamente meno sulle scritture – la consistenza non è sempre certa (errori umani, crash, ecc.) – il conflitto non è gestito (multi-master) • I cluster A/P hanno diversi limiti: – non vanno oltre il 99,99% – non sfruttano completamente l'hardware aggiuntivo (no scalabilità) Un’architettura shared nothing è un’architettura distribuita in cui ogni nodo è auto-sufficiente e indipendente dagli altri perché non ci sono elementi contesi (es. storage) e quindi single point of failure Come funziona? Cosa si intende per shared nothing?
  • 18. 18 Cluster A/A – Shared nothing MySQL Cluster • Si basa su tre tipi di nodi: – Application node – Data node – Management node • Nasce per scalare: – Multi-master – Auto-sharding – Nodi indipendenti – Geo-replica • Disponibilità a 5 nove – Nessuna risorsa condivisa – Self-healing + on-line operations • Supporta SQL + NoSQL • Richiede hw commodity MySQL Cluster Data Nodes Data Layer Application Layer Management Layer MySQL Cluster Management Nodes Clients …
  • 19. 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!