Il blocco del fornitore è un concetto ben noto per le tecnologie di database. Con l'aumento dell'utilizzo del cloud, questo blocco si è esteso anche ai fornitori di cloud. Possiamo definire il vendor lock-in come un lock-in proprietario che rende un cliente dipendente da un fornitore per i suoi prodotti o servizi. A volte questo blocco non significa che non puoi cambiare il fornitore/fornitore, ma potrebbe essere un'attività costosa o dispendiosa in termini di tempo.
PostgreSQL, una tecnologia di database open source, non ha di per sé il problema del vendor lock-in, ma se stai eseguendo i tuoi sistemi nel cloud, è probabile che dovrai farcela quel problema prima o poi.
In questo blog condivideremo alcuni suggerimenti su come evitare il blocco del cloud PostgreSQL e vedremo anche come ClusterControl può aiutare a evitarlo.
Suggerimento n. 1:verifica le limitazioni o le restrizioni del provider di servizi cloud
I fornitori di servizi cloud generalmente offrono un modo semplice e intuitivo (o anche uno strumento) per migrare i dati nel cloud. Il problema è che quando si desidera lasciarli può essere difficile trovare un modo semplice per migrare i dati a un altro provider o a una configurazione in loco. Questa attività di solito ha un costo elevato (spesso basato sulla quantità di traffico).
Per evitare questo problema, devi sempre controllare prima la documentazione e le limitazioni del provider di servizi cloud per conoscere le restrizioni che potrebbero essere inevitabili al momento della partenza.
Suggerimento n. 2:pianificare in anticipo l'uscita da un provider cloud
Il miglior consiglio che possiamo darti è di non aspettare fino all'ultimo minuto per sapere come lasciare il tuo provider cloud. Dovresti pianificarlo con largo anticipo in modo da poter conoscere il modo migliore, più veloce e meno costoso per uscire.,
Poiché questo piano molto probabilmente dipende dai tuoi requisiti aziendali specifici, il piano sarà diverso a seconda che tu possa programmare le finestre di manutenzione e se l'azienda accetterà eventuali periodi di inattività. Pianificandolo in anticipo, eviterai sicuramente il mal di testa a fine giornata.
Suggerimento n. 3:evita di utilizzare prodotti esclusivi di provider di servizi cloud
Il prodotto di un provider cloud funzionerà quasi sempre meglio di un prodotto open source. Ciò è dovuto al fatto che è stato progettato e testato per funzionare sull'infrastruttura del provider di servizi cloud. Le prestazioni saranno spesso notevolmente migliori rispetto alla seconda.
Se devi migrare i tuoi database a un altro provider, avrai il problema del blocco della tecnologia poiché il prodotto del provider cloud è disponibile solo nell'ambiente del provider cloud corrente. Ciò significa che non sarai in grado di migrare facilmente. Probabilmente puoi trovare un modo per farlo generando un file dump (o un altro metodo di backup), ma probabilmente avrai un lungo periodo di inattività (a seconda della quantità di dati e tecnologie che desideri utilizzare).
Se utilizzi Amazon RDS o Aurora, Azure SQL Database o Google Cloud SQL, (per concentrarti sui provider cloud più utilizzati al momento) dovresti considerare di verificare le alternative per migrarlo a un open source Banca dati. Con questo, non stiamo dicendo che dovresti migrarlo, ma dovresti sicuramente avere un'opzione per farlo se necessario.
Suggerimento n. 4:archivia i backup su un altro provider cloud
Una buona pratica per ridurre i tempi di inattività, sia in caso di migrazione che di ripristino di emergenza, non è solo quella di archiviare i backup nello stesso posto (per motivi di ripristino più rapido), ma anche di archiviare i backup in un provider cloud diverso o anche on-premise.
Seguendo questa pratica quando devi ripristinare o migrare i tuoi dati, devi solo copiare i dati più recenti dopo che il backup è stato ripristinato. La quantità di traffico e il tempo saranno notevolmente inferiori rispetto alla copia di tutti i dati senza compressione durante la migrazione o l'evento di errore.
Suggerimento n. 5:utilizza un modello multi-cloud o ibrido
Questa è probabilmente l'opzione migliore se vuoi evitare il blocco del cloud . L'archiviazione dei dati in due o più posti in tempo reale (o il più vicino possibile al tempo reale) ti consente di migrare in modo rapido e puoi farlo con il minor tempo di inattività possibile. Se hai un cluster PostgreSQL in un provider cloud e hai un nodo di standby PostgreSQL in un altro, nel caso in cui sia necessario cambiare provider, puoi semplicemente promuovere il nodo di standby e inviare il traffico a questo nuovo nodo PostgreSQL primario.
Un concetto simile viene applicato al modello ibrido. Puoi mantenere il tuo cluster di produzione nel cloud, quindi puoi creare un cluster di standby o un nodo di database in locale, che genera una topologia ibrida (cloud/on-prem) e, in caso di errore o necessità di migrazione, puoi promuovere il nodo di standby senza alcun blocco del cloud poiché stai utilizzando il tuo ambiente.
In questo caso, tieni presente che probabilmente il provider cloud ti addebiterà il traffico in uscita, quindi in caso di traffico intenso, mantenere questo metodo funzionante potrebbe generare un costo eccessivo per l'azienda.
Come ClusterControl può aiutare a evitare il lock-in di PostgreSQL
Per evitare il lock-in PostgreSQL, puoi anche utilizzare ClusterControl per distribuire (o importare), gestire e monitorare i tuoi cluster di database. In questo modo non dipenderai da una tecnologia o da un provider specifico per mantenere i tuoi sistemi attivi e funzionanti.
ClusterControl ha un'interfaccia utente intuitiva e facile da usare, quindi non è necessario utilizzare una console di gestione del provider cloud per gestire i database, devi solo effettuare il login e avrai un panoramica di tutti i cluster di database nello stesso sistema.
Ha tre diverse versioni (inclusa una versione gratuita per la comunità). Puoi comunque utilizzare ClusterControl (senza alcune funzionalità a pagamento) anche se la tua licenza è scaduta e ciò non influirà sulle prestazioni del tuo database.
Puoi distribuire diversi motori di database open source dallo stesso sistema e solo Per utilizzarlo sono necessari l'accesso SSH e un utente privilegiato.
ClusterControl può anche aiutare nella gestione del sistema di backup. Da qui, puoi pianificare un nuovo backup utilizzando diversi metodi di backup (a seconda del motore di database), comprimere, crittografare, verificare i tuoi backup ripristinandoli in un nodo diverso. Puoi anche archiviarlo in più posizioni diverse contemporaneamente (incluso il cloud).
L'implementazione multi-cloud o ibrida è facilmente realizzabile con ClusterControl utilizzando il Replica da cluster a cluster o la funzione Aggiungi slave di replica. Devi solo seguire una semplice procedura guidata per distribuire un nuovo nodo o cluster di database in una posizione diversa.
Conclusione
Poiché i dati sono probabilmente la risorsa più importante per l'azienda, molto probabilmente vorrai mantenere i dati il più controllati possibile. Avere un cloud lock-in non aiuta su questo. Se ti trovi in uno scenario di blocco del cloud, significa che non puoi gestire i tuoi dati come desideri e questo potrebbe essere un problema.
Tuttavia, il blocco del cloud non è sempre un problema. È possibile che tu stia eseguendo tutto il tuo sistema (database, applicazioni, ecc.) nello stesso provider cloud utilizzando i prodotti del provider (Amazon RDS o Aurora, database SQL di Azure o Google Cloud SQL) e non stai cercando migrando qualsiasi cosa, invece, è possibile che tu stia sfruttando tutti i vantaggi del provider cloud. Evitare il blocco del cloud non è sempre un must poiché dipende da ciascun caso.
Ci auguriamo che il nostro blog ti sia piaciuto condividendo i modi più comuni per evitare un blocco del cloud PostgreSQL e come ClusterControl può essere d'aiuto.
