Mise à l'échelle des clusters PostgreSQL Scalingo avec<br/> un mode de veille active, la restauration à un instant donné et plus encore

Nous sommes heureux d'annoncer que les clusters PostgreSQL sont désormais disponibles sur Scalingo, ajoutant une haute disponibilité à notre offre actuelle à nœud unique et introduisant de nouvelles capacités à Scalingo PostgreSQL.

Clusters PostgreSQL sur Scalingo

Lorsque vous provisionnez un cluster PostgreSQL sur Scalingo, nous démarrons deux nœuds PostgreSQL. L'un des nœuds est désigné comme leader et l'autre comme suiveur. Chaque fois qu'une donnée est insérée sur le leader, elle est immédiatement répliquée sur le suiveur. Grâce à cette configuration de réplication, si un nœud échoue pour une raison quelconque, votre base de données restera accessible, avec un court temps d'arrêt.

Du point de vue du client (généralement votre application), il y a un seul point d'entrée vers le cluster, appelé la passerelle, qui gère l'équilibrage de charge entre tous les nœuds du cluster. Ainsi, la variable d'environnement injectée dans le contexte de votre application contient toujours un seul nom de domaine :

postgres://<nom_utilisateur>:<mot_de_passe>@dbhost.scalingo.com:12345/<nom_base_donnees>.

TLS Partout

Comme d'habitude, la sécurité de la communication avec la base de données et entre les membres du cluster est notre priorité absolue. Nous avons ajouté TLS pour tous les niveaux de communication :

• de l'application à la passerelle,

• de la passerelle au leader,

• du leader au suiveur,

• entre l'orchestrateur du cluster (Patroni) et sa base de données (etcd)

De plus, par défaut, votre base de données n'est pas accessible depuis l'extérieur du réseau de Scalingo. Pour la rendre accessible de partout dans le monde, vous devez d'abord forcer la communication TLS pour vous connecter au cluster PostgreSQL.

Nouveau Paramétrage des Sauvegardes

Avec cette nouvelle configuration, nous sommes en mesure d'offrir deux façons de sauvegarder les données de votre base de données.

Sauvegardes À Demande

Vous pouvez demander à la plateforme une sauvegarde qui sera effectuée sur le nœud suiveur (si vous êtes sur un plan Business, sur le nœud leader sinon) en utilisant l'outil standard pg_dump. Cela effectue une sauvegarde complète de votre base de données et produit une série de commandes SQL que vous pouvez exécuter pour obtenir une copie de la base de données à l'état où la sauvegarde a été effectuée.

Les sauvegardes à la demande sont effectuées de manière asynchrone. Vous pouvez les lister avec le tableau de bord web, la CLI ou l'API. Elles sont limitées en nombre total et en nombre maximum par jour. Par exemple, si votre plan autorise 15 sauvegardes au total et que vous avez déjà demandé 15 sauvegardes à la demande, la prochaine fois que vous en demanderez une, votre sauvegarde à la demande la plus ancienne sera supprimée.

Les sauvegardes à la demande peuvent être automatisées quotidiennement. Vous pouvez spécifier votre heure préférée de la journée à laquelle la sauvegarde sera déclenchée.

Récupération à un Instant T, alias PITR

Nous avons ajouté une nouvelle manière de sauvegarder les données PostgreSQL qui permet de faire une Récupération à un Instant T (PITR). Nous utilisons l'outil pgBackRest pour y parvenir. Nous faisons une sauvegarde complète PITR de la base de données chaque semaine, et entre deux sauvegardes PITR, nous suivons les journaux de modifications anticipées (WAL). Le WAL contient toutes les instructions de modification. En rejouant le WAL à partir d'une sauvegarde PITR jusqu'à une date spécifique, nous sommes en mesure de reconstruire l'état de la base de données à cette date.

PITR assure une durabilité forte de vos données.

Voici la mise à jour sur votre tableau de bord de base de données pour mettre en avant ces deux nouveautés :

Mise à Jour de la Procédure de Mise à Niveau de Version

La procédure pour effectuer une mise à niveau de version de votre cluster est presque identique. Nous devons d'abord arrêter tous les nœuds de la base de données avant d'exécuter pg_upgrade sur les données du leader. Ensuite, les nœuds sont redémarrés en utilisant la nouvelle version majeure.

Lorsque le nœud principal est complètement démarré, il est temps de mettre à jour les extensions que vous avez activées. Dernier point mais non des moindres, il est obligatoire de prendre une nouvelle sauvegarde PITR. Celle prise sur la version majeure précédente est incompatible avec la nouvelle version. Cela a un effet secondaire important : il est impossible d'utiliser une date antérieure à la mise à niveau majeure pour une récupération à un instant donné.

Notez que nous travaillons encore à une meilleure manière de mettre à niveau une version majeure de PostgreSQL qui réduit le temps d'arrêt de votre base de données.

Comment Profiter de la Haute Disponibilité de PostgreSQL ?

Cette fonctionnalité est disponible dans le cadre des nouveaux plans pour votre base de données. Si vous démarrez une nouvelle base de données, vous serez invité à choisir un plan. Tous les plans Business incluent un cluster avec trois nœuds détenant les données et deux nœuds passerelles. La première version prête du cluster est 10.9-1. C'est la première révision de Scalingo de la version 10.9 de PostgreSQL.

Pour une base de données existante, obtenir un cluster nécessite quelques étapes. D'abord, mettez à niveau vers la dernière version 10.9-1. Cela démarrera votre base de données avec une configuration à nœud unique (c'est-à-dire une instance PostgreSQL dans son propre réseau privé avec une seule passerelle). Ensuite, vous pouvez changer le plan dans la section "Addons" de votre application pour choisir un plan Business. Votre base de données migrera en douceur d'une configuration à nœud unique à une configuration hautement disponible.

Après avoir mis à niveau votre plan vers un plan Business, votre base de données est hautement disponible et Scalingo garantit une disponibilité de 99.99 % de votre base de données. De plus, la mise à jour vers une version plus récente est réalisée avec un temps d'arrêt très limité, voir la section ci-dessus sur la "procédure de mise à niveau de version".

Vous n'avez pas à vous soucier de la portabilité des données : votre base de données PostgreSQL est complètement standard (les images Docker de base sont open source) et vous pouvez récupérer toutes vos données en les interrogeant ou en téléchargeant une sauvegarde.

Nouvelle Grille Tarifaire Introduisant les Plans Business

Les anciens plans à nœud unique sont désormais disponibles sous la nouvelle catégorie de plans Démarrage tandis que l'ancien Niveau gratuit est maintenant disponible sous le nom Sandbox.

Il y a 3 catégories de prix :

• Sandbox contient seulement 1 plan et ne doit être utilisé que pour des fins de développement. Aucun SLA n'est proposé pour ce plan.

• Plans de Démarrage proposent le déploiement de cluster à nœud unique (pas de haute disponibilité) mais tous incluent des sauvegardes quotidiennes automatiques.

• Plans Business sont ceux que vous recherchez si vous faites du production : cluster à tous les niveaux et disponibilité améliorée.

Vous trouverez la nouvelle grille tarifaire ci-dessous :

À partir d'aujourd'hui, tous les anciens plans sont renommés avec le préfixe "Démarrage" et "Niveau gratuit" est renommé "Sandbox".

Si vous avez des questions ou des remarques concernant les nouveaux plans tarifaires ou la nouvelle fonctionnalité de cluster, n'hésitez pas à nous contacter. Nous aimerions avoir vos retours !

Aspects Techniques

Afin de faire fonctionner les clusters PostgreSQL de manière magique, nous avons bénéficié du travail réalisé en collaboration avec le cluster Elasticsearch et le cluster Redis. Voici la configuration réseau pour le cluster PostgreSQL :

Lorsque votre application interroge la base de données PostgreSQL, elle entre dans le réseau privé par un point d'entrée unique, appelé Gateway en interne, transmettant les requêtes au leader PostgreSQL. Pour éviter que cette passerelle ne soit un point de défaillance unique, une deuxième est démarrée en tant que secours en cas de défaillance de la première. Nous assurons le mécanisme de secours avec LinK, un gestionnaire d'IP virtuel. Actuellement, ces passerelles sont des serveurs HAProxy.

Pour augmenter la sécurité de votre cluster, les nœuds sont initialisés dans un réseau privé dédié basé sur VXLAN avec l'aide de SAND, un service autonome gérant les réseaux superposés.

Bien que PostgreSQL intègre certains mécanismes pour garantir la réplication, donc une mise en place à haute disponibilité, il est plus facile d'utiliser un logiciel tel que Patroni pour configurer un cluster PostgreSQL à haute disponibilité. Patroni, anciennement connu sous le nom de Governor, est un modèle que nous avons utilisé pour simplifier la tâche de mise en place de la haute disponibilité avec PostgreSQL. Il ajoute une API HTTP pour modifier la configuration de PostgreSQL sans avoir besoin de redémarrer l'instance (pour la plupart des paramètres). Il facilite également la tâche de configuration d'une récupération à un instant T de la base de données.

Photo par Maxim Medvedev sur Unsplash