Amazon RDS
ABC

Amazon RDS e' un servizio in Cloud per ospitare database. Amazon RDS e' il riferimento dei servizi di Cloud Database per completezza dell'offerta, ricchezza di funzionalita', e presenza sul mercato.

Con RDS possono essere ospitati database di tecnologie differenti (eg. MySQL, PostgreSQL, Oracle, ...) con dimensioni facilmente adattabili e scalabili a tutte le necessita'. Su RDS sono disponibili una serie di servizi di gestione (eg. backup, monitoring, security, upgrade) che semplificano le incombenze del DBA con evidenti risparmi e minori rischi.

I vantaggi dei database in Cloud sono tali che da piu' esperti e' stato previsto un forte trend di crescita delle basi dati in Cloud in generale e di Amazon RDS in particolare.

Questo documento introduttivo presenta alcuni aspetti di RDS: Introduzione, Database Instance Class, Database Engine, Versioni supportate, Installazione e configurazione, Gestione, Monitoring, Regioni, AZ ed HA, Aurora, Licensing, ...

L'argomento e' molto ampio e richiederebbe una trattazione molto piu' lunga di questa paginetta... per maggiori informazioni e' sicuramente utile l'ottima documentazione online, disponibile anche in italiano, di cui abbiamo riportato i principali link nei paragrafi seguenti.

Introduzione

Amazon RDS (Relational Database Service) fornisce il servizio di database gestito in Cloud.

Anche se utilizza una piattaforma comune dal punto di vista del networking, della accessi, delle API (Application Program Interface), ... il servizio di Cloud Database RDS (Relational Database Service) e' molto differente da EC2 (Amazon Elastic Compute Cloud: il servizio Web che fornisce l'elaborazione). Infatti non si hanno a disposizione VM (Virtual Machine) complete ma unicamente basi dati gia' installate e configurate. Inoltre sono disponibili una serie di servizi integrati (installazione, backup, update/upgrade, monitoring, tuning/sizing, ...) che riducono in modo significativo le attivita' del DBA.

Tutte le basi dati vengono gestite in modo semplice e consistente dalla console grafica oppure con la CLI AWS oppure con le API RDS.
Il DBA del cliente ha un accesso amministrativo alla base dati ma in realta' non puo' eseguire qualsiasi comando come su un sistema locale. Non potendo accedere al sistema operativo sottostante non si ha la possibilita' di eseguire controlli esterni, lanciare script, impostare crontab, ... mentre e' necessario utilizzare le interfacce preposte per questi compiti. Anche accedendo alla base dati i GRANT non sono sono totali perche' i diritti piu' elevati sono riservati alle utenze di gestione di AWS. Anche se puo' sembrare un limite in realta' con gli utenti amministrativi e' possibile eseguire tutte le normali attivita' di gestione e semplicemente non e' piu' necessaria alcuna attivita' sistemistica esterna al database.

Oltre ad una gestione semplificata l'altro grande vantaggio e' la scalabilita' della piattaforma che puo' crescere o diminuire a seconda delle esigenze consentendo risparmi spesso molto significativi.

Riassumendo ecco l'elenco dei servizi forniti da Amazon RDS ed importanti per chi si occupa del TCO: scalabilita', alta affidabilita', backup, installazione DBMS, patch DBMS, installazione OS, patch OS, manutenzione server, rete/storage/elettricita'/condizionamento/...

Database Instance Class

La dimensione conta. Lo sanno tutti e piu' e' grande piu' si paga.

Amazon RDS supporta tre tipi DB instance class ottimizzate in modo differente: standard, memory optimized e burstable performance. Ad esempio le classi db.m5d e db.m4 sono standard, db.x1 e db.r5b sono memory optimized ed infine db.t3 e db.t2 sono burstable performance. A questa va aggiunta una scala che e' molto ampia: db.m5d.large, db.m5d.xlarge, ... db.m5d.24xlarge. La scelta dipende dal tipo di carico e dalle prestazioni che si vogliono ottenere. Non e' semplice effettuare subito la scelta giusta, ma e' sempre possibile cambiare ed arrivare per approssimazioni successive.

Oltre alle prestazioni dei processori naturalmente sono molto importanti le prestazioni dello storage. Anche per lo storage RDS supporta tre tipologie: General Purpose SSD, Provisioned IOPS, Magnetic (o Standard). In questo caso la scelta generalmente e' GP SSD a meno di esigenze particolari. Per la dimensione infine e' molto semplice: si va da 20 GiB a 64 TiB.
Le dimensioni massime, sia in termini di storage che di capacita' elaborativa dei database in RDS sono veramente molto elevate e praticamente non sono mai un limite dal punto di vista tecnico.

Sia per l'instance class che per per lo storage vale quanto anticipato: piu' e' grande piu' si paga!
Naturalmente conta anche il tempo: infatti per le istanze "spente" si paga solo lo storage mentre per le CPU viene conteggiato ogni secondo (con un minimo di 10 minuti) [NdA le tariffe sono pero' espresse per ora]. Il conteggio dei costi e' complesso e tiene conto di diversi fattori, maggiori dettagli si trovano sulla documentazione ufficiale.

Non tutte le instance class AWS sono disponibili per tutti i database... i tecnici Amazon ha scelto le combinazione piu' adatte a seconda del database relazionale utilizzato. In effetti tutte le combinazioni HW/configurazione presenti in RDS sono ben bilanciate ed adatta al carico dei database relazionali. Ma quali sono i database relazionali disponibili su RDS? Continuate a leggere!

Database Engine

Con RDS sono disponibili le seguenti tecnologie o Database Engine:

• MySQL e' il noto database Open Source. E' stato il primo disponibile su RDS.
• Oracle e' il famoso database commerciale di Oracle Corp.
• SQL Server e' il diffuso database di Microsoft.
• PostgreSQL e' il completo database Open Source.
• MariaDB e' il piu' noto fork di MySQL.
• Aurora e' un'implementazione, ottimizzata per il Cloud e clusterizzata, compatibile con alcuni Database Open Source, in particolare:
  • Aurora MySQL
  • Aurora PostgreSQL

Si tratta dei piu' diffusi database relazionali... ma quali versioni sono disponibili? Continuate a leggere!

Versioni supportate

Orientarsi nel labirinto delle versioni disponibili e supportate per ogni database non e' semplice. Ogni vendor ha le sue modalita' con tempi di rilascio differenti e modalita' di upgrade specifiche. RDS rende disponibili con regolarita' gli aggiornamenti scegliendo quelli piu' significativi e, qualche volta, introducendo ulteriori patch.
RDS semplifica il compito del DBA rendendo disponibili i principali update ed automatizzando la loro applicazione, naturalmente a seconda del database engine e del tipo di upgrade. Poiche' e' piu' facile da fare da interfaccia grafica che da descrivere non riportatiamo ulteriori dettagli...

La tabella seguente riporta le versioni attualmente supportate di ogni database engine su RDS:

Naturalmente la tabella precendente e' in costante variazione... controllate questo documento per gli ultimi aggiornamenti anche sui diversi motori: MySQL, Oracle, SQL Server, PostgreSQL, MariaDB.

Ora sappiamo cosa offre RDS, ma come si installa un nuovo database? Continuate a leggere!

Installazione e configurazione

L'installazione di un DB Engine su RDS non richiede alcuna competenza tecnica specifica e si effettua solo con qualche click (le competenze servono... ma non per installare ;-). Anche la configurazione iniziale della base dati, che tipicamente richiede competenze specifiche sul motore, e' molto semplificata. Infatti RDS imposta in automatico i principali parametri di tuning in modo ottimizzato a seconda dell'Instance Type scelto.

L'impostazione dei DB Parameter Group o un sizing preciso richiedono competenze DBA, ma in molti casi le impostazioni di default sono adeguate per la maggioranza delle configurazioni [NdA e la flessibilita' nella scelta delle classi di istanze aiuta a correggere eventuali errori].

Naturalmente non mi sono fidato... quindi ho controllato i principali parametri di tuning per diversi database (MySQL, PostgreSQL, Oracle) su diverse classi di istanze e bisogna ammettere che gli ingegneri di Amazon hanno fatto un ottimo lavoro... sono veramente pochi i casi in cui e' necessario personalizzare le configurazioni.
Rispetto alle versioni on-premise cambiano alcuni parametri e sopratutto la modalita' di configurazione che risulta molto semplice ed uniforme per tutte le basi dati. I piu' esperti noteranno che alcuni parametri non sono configurabili ma questo e' perche' vengono calcolati in base all'Instance Class (ovviamente una SGA Oracle o gli shared_buffer di PostgreSQL dipendono dalle risorse disponibili sul sistema).

Simili ai Parameter Group sono gli Option Group che consentono di specificare componenti aggiuntivi per i database. E' la modalita' su RDS con cui e' possibile attivare plugin MySQL (eg. Audit plugin) o specifiche Oracle Option. L'unico Engine che non utilizza gli Option Group e' PostgreSQL poiche' vengono utilizzate le extension che si attivano direttamente con l'SQL.

Per accedere alla base dati si utilizzano i programmi client piu' tipici del motore scelto senza particolari differenze rispetto ad un'installazione on-premises. Dal punto di vista del networking viene utilizzato il Virtual Private Cloud (VPC) perche' il flat network e' oramai deprecato. E' sufficiente utilizzare l'indirizzo di Endpoint e la porta corretta per connettersi alla base dati. Per MySQL e Postgres e' anche disponibile l'RDS Proxy.

Accessi

La configurazione degli accessi di rete e' costituita principalmente dal VPC (Amazon Virtual Private Cloud) assegnato all'utente AWS. Se l'istanza deve essere acceduta da Internet viene associato un gateway, definita una route table, le ACL, ... Sono argomenti che non trattiamo in questa paginetta che e' rivolta alle basi dati, ma che comunque sono facilmente configurabili con i wizard della console AWS:

Dal punto di vista dell'accesso applicativo alla base dati non presenta differenze rispetto all'utilizzo di un'istanza on premises! Ad esempio con Postgres:

psql testdb --user=test --host=aws-testdb-01-cluster.cluster-cenqbl6969p.eu-central-1.rds.amazonaws.com
Password for user test: 
psql (13.3, server 12.7)
SSL connection (protocol: TLSv1.2, cipher: ECDHE-RSA-AES256-GCM-SHA384, bits: 256, compression: off)

In pratica e' sufficiente utilizzare l'endopoint dell'istanza come host nella stringa di connessione. La stessa cosa vale per tutti gli Engine RDS: indirizzo e porta sono sufficienti per il collegamento (naturalmente per le porte conviene utilizzare i default: 3306 per MySQL/MariaDB, 5432 per PostgreSQL 1433 per SQL Server e 1521 per Oracle).
Deve essere ricordato che con Aurora sono disponibili piu' endpoint per l'accesso in lettura/scrittura e per l'accesso in sola lettura.

Superpoteri

Conoscete SYS/SYSTEM/postgres/root/... Dimenticateli! Siamo in Cloud ed e' tutto diverso...

Non c'e' alcun accesso al sistema operativo: i file di configurazione non si utilizzano e vengono utilizzati i Parameter Group, i file di log sono accessibili da console o da CLI.
Non esiste l'utente amministrativo che puo' fare tutto; o meglio esiste, a volte con un nome diverso ma e' riservato ad RDS. Quello che viene assegnato al momento della creazione di un'istanza e' un master user. Questo utente e' quello del DBA con tutti i privilegi necessari per amministrare l'istanza.
Cosa non puo' fare un Master ? Non puo' accedere al file system, non ha accesso alle viste piu' interne, ... i dettagli dipendono dall'Engine ma in generale sono notevoltemente ridotte le possibilita' sistemistiche mentre sono garantite tutte le funzionalita' applicative.
Tutti gli altri utenti applicativi (schema owner, end user, ...) vengono creati normalmente da SQL seguendo le best pratices dell'Engine utilizzato.

E' consigliato utilizzare per ogni DBA un accesso IAM (Identity and Access Management).

Gestione

La gestione di un'istanza RDS e' differente rispetto a quella di un'istanza on-premises ma e' anche terribilmente semplice!

Per avviare un'istanza dalla console di gestione scegliere Databases quindi scegliere l'istanza di interesse e da Actions scegliere Start.

Si utilizza la stessa semplice interfaccia praticamente con le stesse funzionalita' per tutti i database RDS. La console permette di effettuare tutte le normali attivita' di gestione compresa la modifica di un'istanza e l'ugrade di una minor release.
Quando la modifica richiede un riavvio e' possibile eseguirlo immediatamente oppure farlo eseguire automaticamente alla successiva finestra di manutenzione.

Le stesse funzionalita' sono richiamabili anche da AWS CLI ed RDS API.

Monitoring

Sono molteplici le possibilita' di monitoraggio dei servizi RDS: l'instance status fornisce alcune informazioni riassuntive, le recommendations forniscono suggerimenti (eg. un aggiornamento di minor release), l'Enhanced Monitoring riporta le statistiche del sistema ospite (eg. uso di CPU, memoria) i database logs riportano il contenuto dei log la cui configurazione e' analoga a quella dei sistemi on-premise, ...

Ma lo strumento piu' ricco di informazioni e' sicuramente il Performance Insights. Performance Insights raccoglie e mantiene, per il periodo indicato, una serie di metriche relative al database ed al sistema ospite. La dashboard riporta fino a 10 differenti metriche che vengono scelte tra quelle piu' significative.

La maggioranza delle metriche del database sono specifiche del motore (eg. MySQL, Postgres) ma sono disponibili anche alcune metriche non native ovvero aggiunte da Amazon a quelle standard del database.

Per completezza va infine ricordato che sono disponibili ulteriori strumenti di monitoraggio come: CloudWatch, EventBridge, CloudTrail, ...

Quando il gioco si fa duro... allora entrano in gioco le competenze verticali sui singoli database: serve un DBA Postgres per un DB Postgres ed un DBA Oracle per un DB Oracle! La raccolta dei dati ogni minuto e la scelta delle metriche a volte non sono sufficienti per alcune diagnosi fini sulla base dati. In questi rari casi e' possibile utilizzare gli strumenti di gestione tipici della base dati o query ad hoc per indirizzare e risolvere il problema.
E' comunque innegabile che gli strumenti di monitoraggio forniti da AWS sono molto completi e di semplice interpretazione.

Alta affidabilita'

Per vedere come e' implementata l'HA (High Availability, ovvero l'alta affidabilita') su RDS abbiamo bisogno di conoscere l'architettura e la nomeclatura di AWS.

Per ottimizzare gli accessi AWS ha una serie di impianti distribuiti in tutto il mondo. Ogni localita' e' detta Region (eg. us-east-1 in Virginia, us-west-2 in Oregon, eu-south-1 in Italia a Milano). In ogni Region sono generalmente presenti piu' Availability Zones (AZs) che sono implementate con alimentazioni, reti, strutture indipendenti per garantire un'elevata alta affidabilita'.

Quando viene scelto di creare un'istanza RDS Multi-AZ vengono allocate in realta' due distinte istanze su due AZ differenti nella stessa Region e con storage separati. Le applicazioni vengono indirizzate dal DNS all'istanza Primary mentre l'istanza Secondary resta in Standby. La replica dei dati e' sincrona ed avviene a livello di disco sui volumi EBS (Elastic Block Store). In caso di problemi (o per un test) un trigger attiva l'istanza secondaria ed il DNS viene aggiornato per fornire un immediato ripristino delle funzionalita'. Quanto riportato vale per le istanze RDS MySQL, PostgreSQL, MariaDB ed Oracle; per Aurora l'implementazione e' differente e con un livello superiore di distribuzione dei dati ed una maggiore affidabilita', come vedremo nel seguito.

Amazon garantisce uno SLA contratturale per le istanze RDS Multi-AZ con una disponibilita' di uptime del 99.95% anche se l'architettura e' tale da fornire un'affidabilita' maggiore.

Aurora

Aurora e' un servizio RDS compatibile con MySQL o PostgreSQL ottimizzato per la replica dei dati e l'utilizzo in Cloud.
Un'istanza Aurora e' compatibile da punto di vista applicativo al database di riferimento ma presenta aspetti architetturali specifici. Lo storage e' mantenuto su SSD in volumi replicati su tre differenti AZ in una singola Region. Un cluster Aurora e' costituito da un'istanza primaria che effettua operazioni sia di lettura che di scrittura e da instanze di replica (fino a 15) che accedono allo stesso storage in sola lettura.

Anche se l'architettura tecnica e' differente, dal punto di vista applicativo generalmente non si presentano difficolta' rispetto alla corrispondente versione di database. Aurora aumenta in modo significativo l'HA di una configurazione. Aurora, con alcuni tipi di carico, fornisce un significativo miglioramento delle prestazioni [NdA pero' vi sono anche casi in cui Aurora non presenta vantaggi prestazionali ed altri in cui e' presente un rallentamento rispetto ad un'istanza RDS].

Amazon garantisce due differenti SLA contratturali per le istanze Aurora a seconda che si tratti di un cluster su una o su piu' zone. l'Aurora Multi-AZ SLA prevede una disponibilita' di uptime del 99.99%, l'Aurora Single-AZ SLA prevede una disponibilita' di uptime del 99.9%.

Licensing

Questo capitolo riguarda solo alcune delle tecnologie disponibili su RDS. Infatti la maggioranza dei DB offerti su RDS ha una licenza Open Source o e' stata sviluppata da Amazon e quindi non ha necessita' di una licenza.
Gli aspetti dei costi di licensing sono relativi a SQL Server di Microsoft ed all'RDBMS Oracle.

Il costo della licenza di Microsoft SQL Server e' incluso in quello dell'istanza RDS. Il proprietario della licenza e' AWS ed il cliente finale non deve acquisire altre licenze. Le Edition di Microsoft SQL Server disponibili sono: Enterprise, Standard, Web, Express. Non e' disponibile la Developer Edition, che puo' essere installata su un server EC2 ma non su RDS.

Con Oracle RDBMS sono disponibili due differenti modelli: License Included (come per SQL Server) e Bring-Your-Own-License (BYOL) in cui e' possibile afferire una propria licenza acquistata in precedenza da Oracle Corp. Le Edition di Oracle disponibili su RDS dipendono dal licensing:

• BYOL: Enterprise Edition (EE), Standard Edition Two (SE2), Standard Edition One (SE1), Standard Edition (SE)
• License Included: Standard Edition Two (SE2), Standard Edition One (SE1) [NdE SE1 non e' piu' disponibile]

Per utilizzare la BYOL bisogna possedere la corretta Oracle Database license ed il Software Update License&Support per la DB instance class e per Oracle Database Edition scelte.

A seconda del tipo di licenza sono disponibili Instance Class differenti.

Varie ed eventuali

Il documento Your server stinks! e' sempre aggiornato sui rilasci delle release dei diversi database (PostgreSQL, MySQL, MariaDB, Oracle, SQL Server e dei servizi RDS.
E' di recente introduzione [NdA 2023-11] la possibilita' di installare e gestire con RDS un database IBM Db2.

E' disponibile un documento che descrive in modo specifico Aurora PostgreSQL. Aurora PostgreSQL fornisce alcune utili estensioni come l'Aurora Pg Query Plan Management.

Titolo: Amazon RDS ABC
Livello: Medio (2/5)
Data: 14 Febbraio 2021 ❤️
Versione: 1.0.1 - 31 Ottobre 2023 🎃
Autore: mail [AT] meo.bogliolo.name