Business continuity su Snowflake

 

Nel contesto aziendale, garantire la business continuity a livello operativo è diventato un obiettivo sempre più condiviso e cruciale tanto quanto mantenere una solida stabilità finanziaria.

Quanto sono preparate le aziende a recuperare dati e processi in caso di disastro? In questo articolo vedremo come rivalutare i piani di business continuity nel processo di modernizzazione e adozione delle migliori pratiche, ovvero il cross-cloud e cross-region replication e failback.

Come sappiamo, Snowflake è considerato una fully managed data platform costruita e pensata per il cloud.

Possiamo utilizzare la piattaforma per una molteplicità di funzioni e workloards, tra cui:

• data science
• data warehousing
• data lakes

È disponibile su 3 cloud provider: AWS, Azure e Google Cloud, con funzionalità identiche su tutte e tre.

Le altre soluzioni multi-cloud platform presenti sul mercato non prevedono la stessa flessibilità di Snowflake: i dati sono sì disponibili su più piattaforme ma non sono facili da spostare e questo non fa altro che creare silos all’interno delle aziende.

Snowflake è differente, infatti grazie alla componente Snowgrid, consente alle organizzazioni di avere un’esperienza unica e connessa tra team e sedi distribuiti in più parti del mondo, favorendo una migliore collaborazione e unificando la governance per rispettare le normative e replicare facilmente i dati e tutti quegli elementi utili a favorire una maggiore continuità aziendale.

Come mitigare il rischio di possibili failures?

Osserviamo ora più nello specifico come le aziende possono far fronte a diversi scenari:

Customer Error

Ci troviamo nel caso in cui un utente Snowflake potrebbe accidentalmente cancellare o alterare i dati. Per far fronte a questo scenario, Snowflake prevede due features principali:

• Time-Travel: funzionalità che consente di accedere e recuperare facilmente i dati in un determinato momento nel tempo. Snowflake permette infatti di “viaggiare indietro nel tempo” e visualizzare i dati come erano in un momento specifico nel passato, rendendo più semplice il ripristino di dati persi o la correzione di errori, tramite la funzione di undrop.
• Fail-Safe: garantisce una finestra di 7 giorni (non configurabile) durante la quale i dati possono essere ancora recuperati e ripristinati. Questo periodo inizia immediatamente dopo la fine del periodo del Time Travel.

Single Instance Failure

Questo è il caso in cui ad esempio una virtual machine fallisce in alcuni data center. Per questo tipo di scenario Snowflake ha costruito delle Built-in Redundancies, che prevede una redundancy tripla per servizi critici e dei retries automatici per le parti delle queries non andate a buon fine.

Zone Failure

Ci troviamo ora nel caso di una failure più estrema: quella legate alle availability zones.

Anche in questo caso Snowflake ha costruito delle Built-in Redundancies, che permettono di usare le Availability Zones su AWS, Azure o GCP. Nelle Regions in cui le Availability Zones non sono disponibiliti, Snowflake si serve degli Availability Sets su Azure.

Region / Multi-Region Failure

Continuiamo ad ipotizzare scenari ancora più estremi come quelli delle Region o Multi-Region Failure.

In questo caso Snowflake prevede come soluzione:

• Cross-Region Database Replication
• Cross-Region Database Failover / Client Redirect

Cross-Cloud & Region Replication

Si tratta delle soluzioni fornite da Snowflake che proteggono dallo scenario di failure più estremo nel cloud.

3 scenari possibili:

• Stressed Exit: consiste nella possibilità di recedere da un accordo di esternalizzazione, a seguito di un failure (è il caso in cui subentra la necessità di uscire da un determinato cloud provider verso un altro). La replica può far quindi parte dell’exit-strategy di un’organizzazione;
• Disaster Recovery: Un altro scenario è quello del Disaster Recovery e Business Continuity, scenari nei quali ci si può proteggere contro le disruption a livello di cloud o di region, utilizzando il Replication e Failover;
• Data Sharing / Locality: contesto nel quale si possono condividere i dati su più cloud e favorire una collaborazione tra più team ****

Per creare una replica dei propri dati è un’operazione semplice, eseguibile con uno script SQL, e si può anche schedulare con quale frequenza si vogliono replicare i dati attraverso la creazione di una TASK:

CREATE DATABASE ... AS REPLICA OF ...;

CREATE TASK refresh_NW_DB_task
	WAREHOUSE = mywh
	SCHEDULE = '1 minute'
AS
	ALTER DATABASE ... REFRESH;

Come funzionano il Database Replication e il Failover?

Attraverso due features principali le organizzazioni che si affidano a Snowflake possono implementare strategie di successo per assicurare la business continuity:

1. Database Replication & Failover – che assicura che i dati siano ridondanti attraverso le cloud region ed è possibile configurare un numero illimitato di repliche. Nel caso di un outage/disaster si può identificare e designare quella replica che sarà usata come database primario

💡 Il Failover e failback sono feature che sono disponibili nella versione Snowflake Business Critical edition o superiore.

     

Architecture details Modern Building Glass facade Business background2. Client Redirect – permette di reindirizzare le connessioni dei clienti agli account Snowflake in region diverse per assicurare la business continuity e far fronte al disaster recovery, o quando si migra l’account in un’altra regione o piattaforma cloud.

Queste due features hanno diversi vantaggi tra cui:

• maggiore resilienza grazie al cross-cloud
• un ripristino possibile in minuti
• limitare la perdita di dati a pochi minuti
• la possibilità di performare Disaster Recovery drills

Vediamo nel dettaglio ogni features:

1. Database Replication

Il database replication può essere attivato per qualsiasi database permanente o transient esistente. Come menzionato in precedenza, abilitando la replica si va a designare il database come database primario e un qualsiasi numero di database in un account può essere designato come database primario. Allo stesso modo, un database primario può essere replicato verso un numero qualsiasi di account dell’organizzazione. Ciò comporta la creazione di un database secondario come replica di un database primario specificato in ciascuno degli account di destinazione.

Aspetti di questa feature riguardano:

• Cross-Cloud & Cross Region
• Zero Performance Impact su Database Primario: la replica è infatti asincrona, c’è alcun tipo di impatto a livello di performance nel workload sul database primario;
• Perdita di dati ridotta: la prima volta che si andranno a replicare i dati verrà effettuato una replica di tutti i dati, mentre le volte successive verrano eseguiti semplicemente dei refresh incrementali (incremental refreshes). La replica sarà per cui più veloce e più frequente. Inoltre se si imposta un limite massimo di perdita di dati a 10 minuti si dovrà fare in modo che la replica dei dati venga eseguita ogni 10 minuti.
• Sicurezza: i dati sono infatti criptati at-rest e in-transit. La replica è inoltre compatibile con il Tri-secret secure.
• Efficace in termini di costi: i due componenti di costi di Snowflake sono il compute-cost e il data-transfer. Snowflake permette infatti di dare il controllo all’utente di decidere quale database replicare e di conseguenza tenere sotto controllo i costi.

2. Database Failover

In caso di interruzione massiccia dei servizi cloud in una determinata regione o per uno specifico cloud provider, i clienti possono eseguire il fail over dei database verso una regione o un cloud provider per assicurare la continuità delle operazioni aziendali.

Anche qui si tratta di un’operazione semplicissima ed eseguibile in pochi click. Nel momento infatti in cui si va a designare un database come primario, si esegue un’operazione sui metadati su Snowflake.

Attraverso questo script SQL è inoltre possibile abilitare il Failover per un database primario:

ALTER DATABASE … ENABLE FAILOVER TO ACCOUNTS

Per maggiori indicazioni, vi suggeriamo di consultare la documentazione a questo link.

3. Client Redirect

Vediamo ora più nello specifico in cosa consiste questa feature.

Lo scopo di questa funzionalità è di mostrare un URL di connessione sicuro per i database Snowflake, indipendentemente dall’account Snowflake in cui risiedono.

Sebbene sia ancora necessario rendere un database secondario come primario in modo manuale, questa funzionalità elimina la necessità di aggiornare manualmente l’URL utilizzato dalle connessioni client e dalle applicazioni.

Il nome host nell’URL di connessione è composto dal nome dell’organizzazione e dal nome dell’oggetto di connessione, oltre al dominio comune: organization_name-connection_name.snowflakecomputing.com.

L’amministratore dell’account determina l’account da utilizzare assegnando un account che funga da connessione primaria.

Il Client Redirect:

• È supportato da diversi Snowflake Clients, tra cui Snowsight e Snowflake Classic Console, così come Pythonm JDBC, ODBC, Go, Node.js, Snowflake UI
• In caso di interruzione del servizio nella regione in cui si trova la connessione primaria, reindirizza la connessione del client a un account che memorizza una connessione secondaria.
• Supporta il PrivateLink, tra cui AWS PrivateLink, Azure Private Link, or Google Cloud Private Service Connect

Nel prossimo articolo vedremo assieme alcune delle best practices per assicurare la business continuity nelle organizzazioni.

Per ulteriori informazioni vi invitiamo a visualizzare questo webinar di Snowflake.

Per ulteriori domande su Snowflake vi invitiamo a contattarci all’indirizzo: info@theinformationlab.it Speriamo che questo articolo vi abbia incuriosito e che continuiate a seguire il nostro blog. Alla prossima!