MaxScale – un proxy per i Database MariaDB e MySQL

Maxscale - Proxy per MariaDB & Mysql

Maxscale – Proxy per MariaDB & Mysql

MaxScale è il nuovo database proxy server open source sviluppato da MariaDB Corporation Ab.

MaxScale nasce con un concetto di proxy alla base, ma con una filosofia ed un approccio “database centrico” ed una architettura a plugin estremamente configurabile.

Per chi si fosse perso i precedenti articoli riguardanti i Proxy Server, ricordiamo che, un proxy, è un server che fa da intermediario in una connessione, ossia esso riceve le richieste da un client e le reindirizza verso altri server che sono i destinatari delle richieste. In altre parole un proxy funziona come un centralinista: riceve la chiamata del cliente  e la gira al primo operatore libero.
Per capire meglio cosa e’ in grado fare elenchiamo alcune delle sue funzionalità principali quali:

  • controllo della disponibilità del Database (monitoring)
  • load balancing
  • analisi della query in ingresso per capire se indirizzarla su una specifica tipologia di server

tutto questo, e molto altro ancora.

MaxScale si può inserire in modo trasparente tra l’applicativo e il server MySQL, esattamente come fa un proxy web tra il nostro browser e il sito che stiamo cercando di visitare.
Grazie ad un proxy è possibile avere:

  • Ridondanza: usando più di un database dietro al proxy, poiche’ un solo server non fornisce l’affidabilità e l’alta disponibilità in caso di down di una macchina.
  • Diminuizione dei costi di infrastruttura: perché generalmente due server piccoli sono meno costosi che un unico server molto performante.

Per migliorare la spiegazione ora vedremo due tipi di database proxy server:

I proxy di livello trasporto come HAProxy (di cui abbiamo piu’ volte parlato in altri articoli).
I proxy di livello applicativo come MaxScale
HAProxy: un proxy efficiente, rapido e funzionale

Fino ad oggi tra i proxy più usati in ambito MySQL Cluster è l’HAProxy che lavora ad un livello più basso (livello 4: trasporto). HAproxy pero’ non conosce nulla di MySQL e si occupa quindi soltanto di bilanciare le connessioni tra i server. Haproxy e’ molto veloce, leggero ed efficente, tuttavia questo tipo di bilanciamento è fatto senza che il proxy sia a conoscenza di cosa sta smistando. Questo rende il sistema meno efficente poiché un server può ricevere molte richieste pesanti, mentre altri server possono essere scarichi. Quindi l’HAProxy non è la scelta vincente in tutti i casi.

MaxScale: e’ un proxy che in configurazioni di questo tipo può fare cose incredibili

MaxScale lavora a livello più alto (livello 7: applicativo) e, monitorando i server riesce a capire cosa sta succedendo all’interno dell’infrastruttura. Conoscendo il protocollo MySQL può intervenire manipolando il traffico tra client e server. Ecco alcune delle sue principali funzionalità:

  • Filtro delle query al database
  • Gestione del routing: instradamento delle richieste a uno o più database server
  • Modifica delle query al volo prima che raggiungano il database
  • Possibilità di nascondere la struttura interna dell’infrastruttura lasciando un singolo punto d’accesso.
  • Alta affidabilità e scalabilità del sistema
  • Possibilità di spostare un database dal server locale ad un server esterno senza modificare la configurazione delle applicazioni
  • Divide automaticamente le scritture sul server MASTER e le letture su uno o più database SLAVE.
  • MaxScale può fornire un Load Balacing delle connessioni senza bisogno di utilizzare applicazioni o CMS che prevedano questa funzionalità. Questo significa che CMS come Joomla! o WordPress possono trarre i benefici usando una replicazione Master/Slave per rendere scalabile il proprio sito.

Caratteristiche di MaxScale

Il punto di forza di MaxScale è sicuramente la sua modularità che permette una notevole libertà adattandosi a molti casi d’uso. MaxScale è :

  • Modulare: un sistema di moduli ne definisce le funzionalità
  • Estendibile: è possibile applicare più filtri anche in cascata
  • Flessibile: i moduli e i filtri possono essere aggiunti dinamicamente

I moduli base di MaxScale

Ecco i 5 moduli che costituiscono il cuore di MaxScale:

  • Protocol: da la possibilità di utilizzare più protocolli es. MySQL client, http, telnet;
    I client si connettono a MaxScale anziché al database MySQL senza accorgersi della differenza. Possono usare le stesse librerie di connessione utilizzate fino ad ora: es. MySQL client o MariaDB client
  • Authentication: il sistema di autenticazione permette ai client di accedere a MaxScale usando le credenziali presenti sui server di Backend;
    MaxScale non ha un sistema di autenticazione o un database di utenti. Vengono utilizzati gli stessi utenti presenti sui database di backend, caricati all’avvio dell’applicazione
  • Monitor: legge la configurazione dello stato del sistema direttamente dai server di backend;
    Viene utilizzato per capire in ogni momento lo stato di tutti i database di backend collegati a MaxScale. In questo modo è possibile sapere qual’è il server Master e quanti Slave stanno replicando correttamentei dati. Il monitor può essere utilizzato per controllare un Galera Cluster.
  • Router: smista le connessioni a uno o più database di backend;
    Dirige il traffico dal client ai server utilizzando una regola specifica denominata connection routing
  • Filter e logging: i filtri permettono di modificare le query oppure di scrivere un file di log con tutte le richieste e le risposte ricevute;
    Tra i più potenti strumenti messi a disposizione di MaxScale ci sono sicuramente i filtri che permettono di effettuare operazioni avanzate sulle query senza modificare il comportamento dell’applicazione, 1) processando query SQL e risultati, 2) utilizzando una semplice regex, 3)  analizzando, modificando o rifiutando le query, 4) mettendo più filtri in cascata

Non resta che testare di persona, magari con un ambiente ad hoc con Docker e Vagrant.

 

MaxScale DB Proxy scalabile

 

MaxScale DB Proxy Server

MaxScale DB Proxy Server

Il suo nome per esteso e’ “MariaDB MaxScale” ed è il nuovo database proxy server open source sviluppato da MariaDB Corporation Ab.

In pratica  MaxScale ci permetta di avere database ad alte prestazioni, in grado di consentire la costruzione di architetture flessibili. Ecco nel dettaglio le sue caratteristiche e funzionalità principali.

 

Innanzitutto ricordiamo a tutti che, un proxy è un server che fa da intermediario in una connessione: riceve le richieste da un client e le reindirizza verso altri server che sono i destinatari delle richieste. In altre parole un proxy è un mezzo per deviare una connessione tra due computer in modo da non collegarli direttamente. Un proxy funziona, nella sua pratica, come un centralinista: riceve la chiamata da chi vuole telefonare e la gira all’interno desiderato.

MaxScale si può inserire in modo trasparente tra l’applicativo e il server MySQL, esattamente come fa un proxy web tra il nostro browser (es. Chrome) e il sito che stiamo cercando di visitare.

Grazie ad un proxy è possibile avere:

  • Ridondanza: usando più di un database dietro al proxy. Un solo server non fornisce l’affidabilità e l’alta disponibilità in caso di down di una macchina.
  • Diminuizione dei costi di infrastruttura: perché generalmente due server piccoli sono meno costosi che un unico server molto performante.

Vedremo ora due tipologie di database proxy server:

I proxy di livello trasporto come HAProxy
I proxy di livello applicativo come MaxScale

HAProxy: un proxy efficiente, rapido e funzionale

Fino ad oggi il proxy più usato in ambito MySQL è l’HAProxy che lavora ad un livello più basso (livello 4: trasporto). HAproxy non conosce nulla di MySQL e si occupa solo di bilanciare le connessioni tra più server. E’ molto veloce, leggero ed efficente, tuttavia questo bilanciamento è fatto senza conoscere cosa sta smistando. Questo rende il sistema meno efficente poiché un server può ricevere molte richieste pesanti, mentre altri server possono essere scarichi. Quindi l’HAProxy non è la scelta vincente in tutti i casi.

MaxScale: un proxy che può fare cose incredibili

MaxScale lavora a livello più alto (livello 7: applicativo), monitorando i server riesce a capire cosa sta succedendo all’interno dell’infrastruttura. Conoscendo il protocollo MySQL può intervenire manipolando il traffico tra client e server. Ecco alcune delle sue principali funzionalità:

  • Filtro delle query al database
  • Gestione del routing: instradamento delle richieste a uno o più database server
  • Modifica delle query al volo prima che raggiungano il database
  • Possibilità di nascondere la struttura interna dell’infrastruttura lasciando un singolo punto d’accesso.
  • Alta affidabilità e scalabilità del sistema
  • Possibilità di spostare un database dal server locale ad un server esterno senza modificare la configurazione delle applicazioni
  • Divide automaticamente le scritture sul server MasterR e le letture su uno o più database Slave.

MaxScale può fornire un Load Balacing delle connessioni senza bisogno di utilizzare applicazioni o CMS che prevedano questa funzionalità. Questo significa che CMS come WordPress o Joomla possono trarne dei benefici, usando una replicazione Master/Slave per rendere scalabile il proprio sito.

Caratteristiche di MaxScale

Il punto di forza di MaxScale è sicuramente la sua modularità che permette una notevole libertà adattandosi a molti casi d’uso, infatti MaxScale è:

  • Modulare: un sistema di moduli ne definisce le funzionalità
  • Estendibile: è possibile applicare più filtri anche in cascata
  • Flessibile: i moduli e i filtri possono essere aggiunti dinamicamente

I moduli base di MaxScale

Quelli elencati qui sotto sono i 5 moduli che costituiscono il cuore di MaxScale:

  • Protocol: da la possibilità di utilizzare più protocolli es. MySQL client, http, telnet
  • Authentication: il sistema di autenticazione permette ai client di accedere a MaxScale usando le credenziali presenti sui server di Backend
  • Monitor: legge la configurazione dello stato del sistema direttamente dai server di backend
  • Router: smista le connessioni a uno o più database di backend
  • Filter e logging: i filtri permettono di modificare le query oppure di scrivere un file di log con tutte le richieste e le risposte ricevute.

1. Protocollo di connessione
I client si connettono a MaxScale anziché al database MySQL senza accorgersi della differenza. Possono usare le stesse librerie di connessione utilizzate fino ad ora: es. MySQL client o MariaDB client.

2. Autenticazione
MaxScale non ha un sistema di autenticazione o un database di utenti. Vengono utilizzati gli stessi utenti presenti sui database di backend, caricati all’avvio dell’applicazione.

3. Monitor
Viene utilizzato per capire in ogni momento lo stato di tutti i database di backend collegati a MaxScale. In questo modo è possibile sapere qual’è il server Master e quanti Slave stanno replicando correttamentei dati.

4. Router
Dirige il traffico dal client ai server utilizzando una regola specifica:

  • Connection routing: normale router di connessione ad un database
  • Read/Write Split router: smista le richieste di scrittura sul Master e le richieste di lettura su uno degli Slave collegati

5. Filtri e log delle query
Tra i più potenti strumenti messi a disposizione di MaxScale ci sono sicuramente i filtri che permettono di effettuare operazioni avanzate sulle query senza modificare il comportamento dell’applicazione:

  • Processando query SQL e risultati
  • Utilizzando una semplice regex
  • Analizzando, modificando o rifiutando le query
  • Mettendo più filtri in cascata

Insomma, da questo primo articolo, si deduce che le potenzialita’ sono tutte a favore di MaxScale

 

#MaxscaledbproxyserverMysql

Couchbase = CouchDB + Membase

Couchbase NoSQL

Couchbase NoSQL

Scopriamo perche’ grandi aziende come Ebay,PayPal, LinkedIn, Viber hanno scelto Couchbase.
Stupiscono le sue incredibili performance e di quanto sia piu’ veloce di MongoDB e Cassandra .

Innanzitutto
Il mondo informatico e’ come non mai in continuo fermento ed evoluzione, questi continui cambiamenti a volte sono difficili da seguire ma, spesso portano novita’ interessanti come Couchbase NoSQL. Ma di cosa si tratta ??
Nel variegato mondo dei database NoSQL da qualche tempo c’è una novità: CouchDB e Membase, insieme alle relative società, si sono unite, dando luogo a un unico prodotto e una sola azienda, entrambi chiamati Couchbase.

#Couchbase = CouchDB + Membase
Quest’ultimo unisce le caratteristiche salienti dei predecessori da cui trae origine, ereditando lo storage ad oggetti su disco di CouchDB e le capacità di caching in memoria di Membase.
Interessante e’ anche la possibilità di utilizzare la stessa tecnologia anche su piattaforme mobili, ottenendo con il minimo sforzo la sincronizzazione dei dati fra il dispositivo mobile e il data center grazie alla tecnologia di sincronizzazione dei dati tipica di CouchDB.

In questo primo articolo vedremo i passi necessari per l’installazione di CouchBase su piattaforma Linux-Ubuntu .

PS: l’installazione di un sistema di questo tipi non e’ per PC casalignhi infatti le richieste minime sono nell’ordine di:
Minimum number of processors required : 4 cores
Minimum RAM required  : 4 GB

Innanzitutto, occorre scaricare la versione piu’ appropriata al vostro sistema operativo, a questo link. Io ho scelto la “couchbase-server-enterprise_3.0.2-ubuntu12.04_amd64.deb”
Quindi lanciare il seguente comando :

# sudo dpkg -i couchbase-server-enterprise_3.0.2-ubuntu12.04_amd64.deb

ed al termine dell’installazione, verificare che tutto e’ andato correttamente, digitando nel browser, questo link

http://127.0.0.1:8091/

e seguite la procedura di Setup……, una volta ultimata il primo login come Amministratori sara’ automatico e vi ritroverete direttamente all’interno della console di gestione del DB. Complimenti  il primo step e’ stato ultimato con successo.

Se durante l’installazione non avete cambiato nulla avrete notato che i file di gestione/configurazione del DB sono stati salvati in /opt/couchbase/………/ – Per fare lo shutdown e lo startup, digitare questi comandi

# sudo /etc/init.d/couchbase-server start
# sudo /etc/init.d/couchbase-server stop

Per ogni ulteriore dettaglio nella configurazione per ora vi rimando alla documentazione ufficiale che potete trovare a questo LINK .

Per il momento e’ tutto, spero che queste poche righe abbiano destato l’interesse verso una soluzione DB ad alte prestazioni interessante qual’e’ CouchBase.
Bis Bald, a presto!

CouchDB conosciamolo meglio

couchDBQuesto articolo e’ la continuazione della precedente “Introduzione a CouchDB” per cui riprenderemo alcune informazioni di base gia viste per poi allargare alcuni importanti concetti ed aspetti che riguardano questo interessantissimo documentale via HTTP.


Apache CouchDB
e’ un moderno documentale, document-oriented, richiamabile semplicemente con l’HTTP e che al tempo stesso offre le piu’ avanzate funzionalita’ di replicazione dati e di ricerca in parallelo (Map/Reduce).

Caratteristiche

Scritto in: Erlang
Punto principale: Consistenza DB consistency, facilità d’uso
Licenza: Apache
Protocolli: HTTP/REST
Replicazione bidirezionale continua o ad-hoc con individuazione dei conflitti, replicazione master-master
MVCC – le operazioni di scrittura non bloccano le letture
Sono disponibili le versioni precedenti dei documenti
Progettazione crash-only (reliable)
Necessità di compattazioni nel tempo
Viste: embedded map/reduce
Viste formattate: lists & shows
Possibilità di validazione server-side dei documenti
Possibile autenticazione
Aggiornamenti real-time attraverso _changes (!)
Gestione degli allegati e, CouchApps (standalone js apps)
libreria jQuery inclusa
Utilizzo ideale: Per accumulazione dei dati con cambi occasionali sui quali vengono eseguite query predefinite. Situazioni in cui la gestione delle versioni è importante.
Per esempio: CRM, sistemi CMS. Situazioni in cui la replicazione master-master è una caratteristica interessante (ad esempio multisito).

In CouchDB non esistono tabelle. Il contenuto informativo è suddiviso in diversi database che fungono da contenitori di documenti con strutture potenzialmente disomogenee tra di loro. Il documento è il fulcro di questo software (e di quelli che come lui condividono l’approccio document-oriented).
Un documento è formato da un insieme di coppie chiave-valore.
A differenza dei database relazionali CouchDB non possiede il concetto di schema e quindi ogni documento in ogni database può essere strutturato in modo diverso dagli altri.

Le uniche due chiavi obbligatorie sono:
_id serve per identificare univocamente il documento (è comparabile, semanticamente, alla chiave primaria dei database relazionali)
_rev viene utilizzata per la gestione delle revisioni, ad ogni operazione di modifica infatti la chiave “_rev” viene aggiornata (questo meccanismo è alla base della prevenzione dei conflitti
in fase di salvataggio su CouchDB).

Questo accorgimento permette inoltre di poter interrogare il DBMS su versioni del documento non più attuali in quanto, con un approccio simile a quello di Subversion, CouchDB mantiene memoria di ogni revisione, da quella iniziale alla più recente.

L’altra grande differenza rispetto ai tradizionali RDBMS è il meccanismo di gestione delle query. Nei database relazionali una volta specificate e popolate le tabelle è possibile eseguire query utilizzando un linguaggio conosciuto come SQL (ne esistono vari dialetti ma il concetto non cambia nell’essenza);
a fronte di una query il RDBMS utilizza indici interni e le proprie relazioni per costruire in tempo reale una tabella di risultato (che può, nelle query più semplici, essere un sottoinsieme della tabella di partenza).

Questa soluzione riesce ad essere performante in quanto i dati sono strutturati con questo preciso scopo; inoltre il database non deve conoscere a priori le query che verranno eseguite ma può rispondere a qualsiasi interrogazione, purché sia stilata usando SQL valido.

Consistenza dei dati e replicazione

CouchDB non utilizza alcun meccanismo di locking ma sfrutta l’MVCC (Multiversion Concurrency Control): ogni modifica di un oggetto ne crea una nuova versione. Le versioni precedenti non vengono cancellate. Se due modifiche vanno in conflitto poiche’ accedono allo stesso documenti, la seconda riceve un errore in save. L’applicazione deve riprendere l’ultima versione del documento e rieseguire l’UPDATE.
L’isolamento e’ mantenuto solo a livello di un singolo documento, questa e’ una notevole semplificazione, rispetto alla complessa logica transazionale di altri database, ma consente l’ottimizzazione, la parallelizzazione e la distribuzione dei dati in modo semplice. A livello di accesso al file di dati ogni singola modifica ad un documento rispetta le proprieta ACID (Atomic Consistent Isolated Durable) con la serializzazione delle modifiche sui documenti e la scrittura sincrona sul disco.

Piu’ database CouchDB possono essere collegati tra loro in modo molto semplice. I database vengono aggiornati tra loro con una replicazione peer-to-peer incrementale implementata nativamente nell’engine. CouchDB permette una replicazione bidirezionale asincrona, utilizza un meccanismo automatico di risoluzione dei conflitti e fornisce una eventual consistency tra i database. Se i database sono ospitati su nodi differenti si ottiene con questo la distribuzione dei dati.
La replicazione di CouchDB puo’ essere utilizzata sia per sincronizzare database locali che per complesse configurazioni con sharding dei dati.

Per lavorare su CouchDB esiste anche la possibilita’ di installare CouchApp, in pratica una serie di script che permettono di costruire completi applicazioni stand-alone per il database usando solo HTML e JavaScript. Poiche’ il database stesso risponde in HTTP e’ possibile concentrare su un solo nodo (eventualmente replicabile) la classica pila applicativa web a tre livelli.

CouchDB si e’ cosi’ rapidamente imposto sul mercato, diventando uno tra i piu’ usati database non relazionali. In pratica i due piu’ diffusi NoSQL documentali sono CouchDB e MongoDB: entrambi sono velocissimi (memorizzano i dati in BSON/JSON), sono scalabili in modo nativo su piu’ nodi e non forniscono un’interfaccia SQL.

Per una documentazione piu’ dettagliata si rimanda al sito ufficiale di Apache CouchDB.

 

Per ora e’ tutto, alla prossima e, buon divertimento!

GreenSQL ora su AWS

Greensql_AWSbigGreenSQL offerta Database Secutiry su Amazon Web Services (AWS)

9 Luglio 2014, GreenSQL, azienda leader nelle soluzioni di sicurezza dei dati (DB), ha annunciato al mondo la disponibilita’ di una soluzione appositamente pensata per la piattaforma AWS, per l’appunto ” GreenSQL per AWS ” pronta a dare tutta la potenza ed i livelli di sicurezza certificati da GreenSQL sia in locale che ora anche nel Cloud.

Le caratteristiche principali sono le seguenti :

  • Versione del prodotto (ad oggi) 2.6.7
  • Sistema Operativo Linux / Unix, Linux Amazon 2.014,03
  • Architettura64-bit Amazon Macchina Image (AMI)
  • Servizi AWS AmazonEC2, AmazonEBS


Descrizione del prodotto
(alcuni interessanti video si possono trovare sul canale Youtube di GreenSQL)

GreenSQL fornisce soluzioni avanzate di sicurezza per database, proteggendoli da attacchi di SQL injection (ad esempio SSN, numeri di carte di credito, e-mail, password amministrative ecc…), mascherando i dati sensibili e monitorando costantemente la veridicita’ dei dati di accesso degli utenti che dovranno soddisfare vari livelli di conformita’ a normative quali PCI e HIPAA. Una volta installato come front-end delle vostre applicazioni web nel Cloud, GreenSQL sara’ in grado di mimetizzare perfettamente e proteggere le applicazioni, i database ed i dati in essi contenuti, questo poiche’ GreenSQL e in grado di individuare automaticamente e mascherare i dati sensibili memorizzati nel database.

Inoltre e’ in grado di:

– bloccare in tempo reale tutte le SQL injection rilevate;  

–  monitorare le attività sul database eseguite dagli amministratori di sistema e dai DBA

– attuare la separazione delle funzioni creando le regole base per le restrizioni di accesso ai dati filtrando ed accoppiando le utenze ad apposite liste d’indirizzi IP geografici ….

Se quello che avete letto vi incuriosisce e volete saperne di piu’ in merito vi invito a leggere gli articoli precedenti su GreenSQL quali :