PostgreSQL
 sql >> Base de données >  >> RDS >> PostgreSQL

Comment éviter le verrouillage du fournisseur PostgreSQL Cloud

Vendor lock-in est un concept bien connu pour les technologies de bases de données. Avec l'augmentation de l'utilisation du cloud, ce verrouillage s'est également étendu pour inclure les fournisseurs de cloud. Nous pouvons définir le verrouillage du fournisseur comme un verrouillage exclusif qui rend un client dépendant d'un fournisseur pour ses produits ou services. Parfois, ce verrouillage ne signifie pas que vous ne pouvez pas changer de fournisseur/fournisseur, mais cela peut être une tâche coûteuse ou chronophage.

PostgreSQL, une technologie de base de données open source, n'a pas le problème de verrouillage du fournisseur en soi, mais si vous exécutez vos systèmes dans le cloud, vous devrez probablement faire face à ce problème à un moment donné.

Dans ce blog, nous partagerons quelques conseils sur la façon d'éviter le verrouillage du cloud PostgreSQL et nous verrons également comment ClusterControl peut aider à l'éviter.

Conseil n° 1 :Vérifiez les limitations ou les restrictions du fournisseur de cloud

Les fournisseurs de cloud proposent généralement un moyen simple et convivial (ou même un outil) pour migrer vos données vers le cloud. Le problème est que lorsque vous souhaitez les quitter, il peut être difficile de trouver un moyen simple de migrer les données vers un autre fournisseur ou vers une configuration sur site. Cette tâche a généralement un coût élevé (souvent basé sur la quantité de trafic).

Pour éviter ce problème, vous devez toujours d'abord consulter la documentation et les limitations du fournisseur de cloud pour connaître les restrictions qui peuvent être inévitables lors du départ.

Conseil n° 2 :Planifiez à l'avance la sortie d'un fournisseur de cloud

La meilleure recommandation que nous puissions vous donner est de ne pas attendre la dernière minute pour savoir comment quitter votre fournisseur de cloud. Vous devez le planifier longtemps à l'avance afin de savoir quel est le meilleur moyen, le plus rapide et le moins cher de sortir., 

Parce que ce plan dépend très probablement des besoins spécifiques de votre entreprise, le plan sera différent selon que vous pouvez planifier des fenêtres de maintenance et si l'entreprise accepte les périodes d'indisponibilité. En le planifiant à l'avance, vous éviterez certainement un mal de tête en fin de journée.

Astuce n° 3 :évitez d'utiliser des produits exclusifs de fournisseur de cloud

Le produit d'un fournisseur de cloud fonctionnera presque toujours mieux qu'un produit open source. Cela est dû au fait qu'il a été conçu et testé pour fonctionner sur l'infrastructure du fournisseur de cloud. Les performances seront souvent bien meilleures que la seconde.

Si vous devez migrer vos bases de données vers un autre fournisseur, vous rencontrerez un problème de verrouillage technologique, car le produit du fournisseur de cloud n'est disponible que dans l'environnement actuel du fournisseur de cloud. Cela signifie que vous ne pourrez pas migrer facilement. Vous pouvez probablement trouver un moyen de le faire en générant un fichier de vidage (ou une autre méthode de sauvegarde), mais vous aurez probablement une longue période d'indisponibilité (selon la quantité de données et de technologies que vous souhaitez utiliser).

Si vous utilisez Amazon RDS ou Aurora, Azure SQL Database ou Google Cloud SQL, (pour vous concentrer sur les fournisseurs de cloud les plus utilisés actuellement), vous devriez envisager de vérifier les alternatives pour le migrer vers une source ouverte base de données. Avec cela, nous ne disons pas que vous devriez le migrer, mais vous devriez certainement avoir la possibilité de le faire si nécessaire.

Astuce n° 4 :stockez vos sauvegardes sur un autre fournisseur de cloud

Une bonne pratique pour réduire les temps d'arrêt, que ce soit dans le cas d'une migration ou d'une reprise après sinistre, consiste non seulement à stocker les sauvegardes au même endroit (pour des raisons de récupération plus rapide), mais également à stocker les sauvegardes dans un autre fournisseur de cloud ou même sur site.

En suivant cette pratique lorsque vous devez restaurer ou migrer vos données, il vous suffit de copier les dernières données après la reprise de la sauvegarde. La quantité de trafic et le temps seront considérablement inférieurs à la copie de toutes les données sans compression lors de la migration ou de l'événement d'échec.

Conseil n°5 :Utilisez un modèle multi-cloud ou hybride

C'est probablement la meilleure option si vous voulez éviter le verrouillage du cloud . Stocker les données à deux endroits ou plus en temps réel (ou aussi près que possible du temps réel) vous permet de migrer rapidement et vous pouvez le faire avec le moins de temps d'arrêt possible. Si vous avez un cluster PostgreSQL dans un fournisseur de cloud et que vous avez un nœud de secours PostgreSQL dans un autre, au cas où vous auriez besoin de changer de fournisseur, vous pouvez simplement promouvoir le nœud de secours et envoyer le trafic vers ce nouveau nœud PostgreSQL principal.

Un concept similaire est appliqué au modèle hybride. Vous pouvez conserver votre cluster de production dans le cloud, puis vous pouvez créer un cluster de secours ou un nœud de base de données sur site, qui génère une topologie hybride (cloud/sur site), et en cas de panne ou de nécessité de migration, vous pouvez promouvoir le nœud de secours sans aucun verrouillage du cloud puisque vous utilisez votre propre environnement.

Dans ce cas, gardez à l'esprit que le fournisseur de cloud vous facturera probablement pour le trafic sortant. Par conséquent, en cas de trafic important, le maintien de cette méthode pourrait générer un coût excessif pour l'entreprise.

Comment ClusterControl peut aider à éviter le verrouillage PostgreSQL

Afin d'éviter le verrouillage de PostgreSQL, vous pouvez également utiliser ClusterControl pour déployer (ou importer), gérer et surveiller vos clusters de bases de données. De cette façon, vous ne dépendrez pas d'une technologie ou d'un fournisseur spécifique pour maintenir vos systèmes opérationnels.

ClusterControl a une interface utilisateur conviviale et facile à utiliser, vous n'avez donc pas besoin d'utiliser une console de gestion de fournisseur de cloud pour gérer vos bases de données, il vous suffit de vous connecter et vous aurez un vue d'ensemble de tous vos clusters de bases de données dans le même système.

Il existe trois versions différentes (dont une version gratuite pour la communauté). Vous pouvez toujours utiliser ClusterControl (sans certaines fonctionnalités payantes) même si votre licence a expiré et cela n'affectera pas les performances de votre base de données.

Vous pouvez déployer différents moteurs de base de données open source à partir du même système, et uniquement Un accès SSH et un utilisateur privilégié sont requis pour l'utiliser.

ClusterControl peut également vous aider à gérer votre système de sauvegarde. À partir de là, vous pouvez planifier une nouvelle sauvegarde en utilisant différentes méthodes de sauvegarde (selon le moteur de base de données), compresser, chiffrer, vérifier vos sauvegardes en les restaurant dans un nœud différent. Vous pouvez également le stocker dans plusieurs emplacements différents en même temps (y compris le cloud).

L'implémentation multi-cloud ou hybride est facilement réalisable avec ClusterControl en utilisant le Réplication de cluster à cluster ou la fonction Ajouter un esclave de réplication. Il vous suffit de suivre un simple assistant pour déployer un nouveau nœud ou cluster de base de données à un endroit différent.

Conclusion

Étant donné que les données sont probablement l'atout le plus important de l'entreprise, vous voudrez probablement garder les données aussi contrôlées que possible. Avoir un verrouillage du cloud n'aide pas à cela. Si vous êtes dans un scénario de verrouillage du cloud, cela signifie que vous ne pouvez pas gérer vos données comme vous le souhaitez, et cela pourrait être un problème.

Cependant, le verrouillage du cloud n'est pas toujours un problème. Il est possible que vous exécutiez tout votre système (bases de données, applications, etc.) dans le même fournisseur de cloud en utilisant les produits du fournisseur (Amazon RDS ou Aurora, Azure SQL Database ou Google Cloud SQL) et que vous ne recherchiez pas migrer quoi que ce soit, au lieu de cela, il est possible que vous profitiez de tous les avantages du fournisseur de cloud. Éviter le verrouillage du cloud n'est pas toujours indispensable, car cela dépend de chaque cas.

Nous espérons que vous avez apprécié notre blog partageant les moyens les plus courants d'éviter un verrouillage du cloud PostgreSQL et comment ClusterControl peut vous aider.