Database machine, soluzioni di tipo “open” (it)

10 minuti tempo di lettura

Este post también está disponible en Español

Il supporto per i workload generati da database di grandi dimensioni richiede spesso architetture specializzate o DB machine.
Consideriamo la seguente definizione di DB machine secondo Wikipedia
“Un DB machine o processore di back-end è un hardware specializzato che memorizza e recupera dati da un database. Un DB machine è appositamente progettato per l’accesso al database con i server di front-end strettamente accoppiati (tighly coupled) da un canale ad alta velocità mentre i server di database sono accoppiati liberamente (loosely coupled) attraverso la rete. Il front-end riceve i dati e li visualizza, il back-end, d’altra parte, analizza e memorizza i dati provenienti dai processori di front-end. Un DB machine fornisce prestazioni superiori, incremento della memoria host, maggiore sicurezza per i database e costi di produzione ridotti”.

È chiaro che il termine chiave che definisce  un DB machine è “soluzione integrata” hardware (server, rete, storage) e software (DBMS). Secondo questa definizione, ci sono 2 possibili implementazioni: un appliance software preconfigurato con l’hardware necessario per eseguire tale software (proposta tipica del fornitore DBMS) o un appliance hardware preconfigurato con il software necessario per essere eseguito su tale hardware (tipica proposta hardware del fornitore).

Anche se a prima vista le due architetture possono sembrare simili, ognuna di esse presenta vantaggi e svantaggi e le implicazioni della loro implementazione in un data center sono molto diverse.

db machine open - definition
db machine open – definition

In questo post analizzeremo entrambe le architetture con l’idea di fornire alcuni spunti di riflessione per orientarsi nella decisione di quale “appliance” rappresenta un’architettura valida in base ai requisiti applicativi e di business.

Le sfide di un DBMS nel data center

 Performance: la prima sfida che un DBA deve affrontare è ottenere le “massime prestazioni possibili” dal database. Il motivo è semplice: un DB performante genera un “valore di business” maggiore ed evita il malcontento da parte dei clienti interni. Mantenere un DB efficiente è uno dei compiti più dispendiosi in termini di tempo per il DBA. Il “tuning” di un DB varia dall’implementazione di parametri a livello di DB, a livello del sistema operativo, la creazione e la manutenzione degli indici, ottimizzazioni al codice SQL, ecc.

Disponibilità e protezione dei dati: in termini di disponibilità e protezione dei dati i database mission-critical necessitano di una disponibilità più rigorosa e SLO (Service Level Objectives). I problemi più comuni includono guasti ai dischi, danneggiamento dei dati, connettività, esigenze di aggiornamenti software senza interruzioni del servizio, ecc.

db machine open - dbms challenges
db machine open – dbms challenges

Creazioni di copie e “provisioning” di nuovi ambienti: tutti i DB richiedono la creazione e la manutenzione di una serie di copie (snap) o cloni per il backup ma anche per supportare diversi processi di business (reporting, creazione e aggiornamento di ambienti di test e sviluppo, ecc.). Il provisioning di nuovi ambienti tramite la copia dei dati è un compito che deve essere fatto in modo rapido e agile per non causare ritardi nelle attività di sviluppo delle applicazioni a causa dell’indisponibilità dell’infrastruttura.

Riduzione dei costi: OpEx e CapEx sono anche una sfida. Il costo di licenza di un software DBMS aumenta con il numero di core delle CPU. Le difficoltà o meno di integrare un appliance con il resto dell’infrastruttura esistente nel data center aumenta il CapEx. A seconda del grado di modularità e scalabilità del appliance, l’acquisizione di più hardware o software aumenta i costi di OpEx e CapEx.

Appliance software + hardware vs appliance hardware + software

Per semplicità useremo come sinonimi DB machine proprietario = appliance proprietario (proposta del fornitore DBMS) e DB open = appliance open (proposta fornitore hardware).

Un DB machine aperto che includa il miglior sistema di storage sul mercato + la migliore tecnologia di network + la migliore tecnologia di server consentono di eseguire un DB con le massime prestazioni, protezione e facilità d’uso possibili? In altre parole, in quale misura è possibile confrontare un DB machine aperto con un DB machine proprietario?

Analizziamo per prima cosa le performance, uno dei “driver” più importanti nella scelta di una DB machine.

Prestazioni: a grandi linee, un DB machine proprietario utilizza alcune caratteristiche speciali a livello di software che non è possibile eseguire su un “appliance aperto” (il fornitore del software di DB non consente la loro implementazione). Queste caratteristiche speciali sono state sviluppate per rendere l’appliance proprietario un sistema estremamente veloce nell’esecuzione di alcuni codici SQL. Ora, se sono le caratteristiche speciali che rendono veloce un appliance proprietario ci si può chiedere:

  • queste caratteristiche speciali sono sempre utilizzate negli appliance propietari?
  • è possibile in qualche modo ad un appliance open coprire questo divario di prestazioni con funzionalità hardware o software?
db machine open - performance
db machine open – performance

C’è solo un modo per accedere ai dati il più velocemente possibile ed è NON ACCEDERE o almeno evitare il più possibile di eseguire I/O nel back-end (anche se questo è di tipo Flash). Per ottenere il massimo delle prestazioni un’applicazione necessita chi i dati che servono a costruire il working-set si trovino già a un certo livello di cache nel percorso dei dati, in teoria quanto più vicino alla CPU dei server meglio è.

Per carichi di workload casuali (OLTP) non è possibile anticipare quali dati debbano essere in memoria, l’accesso è di per sé di natura random. Ciò significa che per un carico di lavoro OLTP tanto un appliance proprietario quanto un appliance open, configurati con la stessa quantità di cache, avranno comportamenti prestazionali simili. Negli ambienti OLTP, un livello di prestazione più elevato o più basso dipende dal numero di “hit” nella cache, un valore direttamente correlato alla quantità di cache disponibile, la frequenza di accesso agli stessi dati (“re-hit”) e la posizione spaziale delle informazioni (LoR-Locality of Reference).

 Per i carichi di lavoro di tipo DWH è possibile aumentare le prestazioni se i dati necessari al working-set possono essere “predisposti” nella cache prima che sia necessario recuperarli dal back-end. Negli ambienti DWH, in alcuni DB machine proprietari ci sono delle funzionalità speciali in grado, a seconda della complessità dell’istruzione SQL, di leggere i dati in anticipo dal back-end (storage) e di inviarlo al front-end (server). Questo tipo di accesso sequenziale preventivo (scan) implementato nel appliance proprietario può essere considerato simile agli algoritmi di “prefetch” che alcuni sistemi di storage evoluti utilizzano da molto tempo. In un appliance open quando il sistema di archiviazione riconosce un I/O di tipo sequenziale anticipa (“prefetch”) la lettura di più dati e li invia alla sua cache evitando così ai server la necessità di accedere ai dischi. Mentre è corretto dire che gli algoritmi di prefetch dello storage di un DB machine open sono agnostici nei confronti del tipo di applicazione e possono leggere più dati di quanto strettamente necessario al working-set, questo può influenzare un uso maggiore o minore della cache, ma non influenza una maggiore o minore performance delle applicazioni.

Si potrebbe inoltre affermare che, dal punto di vista delle prestazioni predisporre i dati a livello della cache del sistema di storage, cosa che succede in un appliance open, non sia lo stesso di predisporre dei dati a livello della cache dei server (prerogativa di un appliance propietario). Nel secondo caso i dati sono più vicini all’applicazione, non c’è una SAN in mezzo e quindi si dovrebbe ottenere migliori prestazioni grazie alla latenza più bassa. Tuttavia dobbiamo considerare che la latenza è funzione della distanza che un segnale deve attraversare. Una SAN utilizza una tecnologia a fibra ottica, dove il segnale viaggia ad una velocità vicina a quella della luce. Pertanto, per una distanza di pochi metri la latenza introdotta dalla SAN, se configurata correttamente, è irrilevante (< 0,5 microsecondi) e l’accesso alla RAM dei server o la DRAM dello storage non rappresenta una grande differenza.

DB Machine proprietario vs DB Appliance aperto, altre considerazioni

Per quanto riguarda le caratteristiche di affidabilità, protezione dei dati, facilità d’uso e inclusione nel data center; un’appliance open è paragonabile ad un’appliance propietario?

Affidabilità, RAS (caratteristiche enterprise)

RAS definisce le caratteristiche dei sistemi enterprise, caratteristiche che vanno oltre l’elevata disponibilità e oltre la semplice ridondanza dei componenti. RAS significa operazioni e upgrade senza interruzioni, ed essere sempre online. Su alcune appliance proprietarie operazioni quali gli upgrade di software (patch) possono essere eseguite solo in modalità seriale, aggiornando gruppi di componenti parziali alla volta e solo se il back-end adotta una protezione dati multipla (RAID > 2).

Al contrario, in un appliance “best-of-breed” open di classe enterprise, le attività di aggiornamento software della “parte dati” non presentano nessuna di queste complicazioni e si è in grado di eseguire gli aggiornamenti in un tempo < 5 secondi e senza alcun impatto sulle prestazioni o sul servizio.

Al seguente link trovate una descrizione dettagliata delle funzionalità RAS

Protezione dei dati (replica locale e remota)

In un appliance proprietario le funzionalità di protezione dei dati (replica) sono in genere interamente basate sul software del DBMS. In molti di questi sistemi i meccanismi di replica remota supportano la copia di un singolo DB, o istanza, alla volta. Se l’appliance contiene diversi DB e si verifica un disastro a livello dell’intero DB machine o data center non sarà facile ottenere nel sito di Disaster Recovery tutti i DB nella stessa situazione che era presente nel sito di produzione (coerenza temporale globale).
Al contrario, i sistemi di storage di un DB open dispongono di meccanismi hardware di protezione dei dati estremamente più efficienti.
Ciò significa avere la flessibilità necessaria per gestire qualsiasi livello di servizio, applicazione o gruppi di applicazioni correlati, indipendentemente dalla quantità o dal modo in cui l’ambiente cambia. La replica hardware consente inoltre di ridurre la larghezza di banda richiesta per mezzo della compressione e deduplica sulla linea.

db machine open - additional considerations
db machine open – additional considerations
Gestione e integrazione con altri componenti nel data center

Appliance open significa anche la possibilità di eseguire altre applicazioni fisiche o virtuali congiuntamente al sistema DBMS e, soprattutto, evitare il lock-in con la piattaforma sottostante. Un DB machine open è facilmente integrabile con altri componenti presenti nel Data Center e permette di aggiungere componenti computazionali o di storage separatamente a seconda delle necessità

Per quanto riguarda la gestione, numerosi plug-in consentono la visione unificata del DBMS con il DB machine open oltre che la gestione automatica dei meccanismi di copia.

Per concludere

In determinate circostanze, quando vengono eseguite specifiche funzionalità speciali, un DB machine proprietario può fornire prestazioni migliori.

Per quanto riguarda le prestazioni, le caratteristiche speciali delle DB machine proprietarie sono applicabili quasi esclusivamente all’ambito DWH e non hanno alcun effetto sui workload di tipo OLTP (random).

db machine open - takeaway notes

db machine open – takeaway notesI DB machine proprietari sono difficili da integrare con altri componenti all’interno di un data center e non offrono la possibilità di consolidamento di workload applicativi o sistemi operativi misti.

I nuovi sviluppi nel campo dello storage flash come NVMe, SCM e NVMeoF consentono ad un appliance open di offrire una larghezza di banda molto maggiore rispetto a quanto un’applicazione SQL è in grado di generare.

Un DB appliance open beneficia dei continui sviluppi di server, CPU, networking, storage (best-of-breed), previene il lock-in e facilita l’aggiornamento indipendente a seconda delle necessità dei componenti computazionali o capacitivi.

Quando un DB machine open è configurato seguendo una “reference architecture”, dal punto di vista della validazione e del supporto questo tipo di architetture può essere paragonata ad un appliance proprietario.

db machine open - big picture
db machine open – big picture
Per conoscere di più:

Dell EMC Ready Solutions for Business Applications
Dell EMC Soluzioni Convergenti

Este post también está disponible en: Español (Spagnolo)