Cette section décrit la fonctionnalité de basculement de base de données pour les dispositifs exécutant la version 9.0.0 ou une version ultérieure. Pour ces dispositifs, le basculement est entièrement automatisé, sauf lorsqu'un dispositif du fournisseur de services s'arrête de manière inattendue, auquel cas il existe toujours un processus manuel.

Note : Cette section s'applique uniquement aux dispositifs exécutant la version 9.0.0 ou une version ultérieure. Pour plus d'informations sur les dispositifs plus anciens, reportez-vous à la section Basculement de base de données - Dispositifs hérités.

Basculement automatisé

La fonctionnalité de basculement automatisé comprend les éléments suivants.
  • Connexion à une source de données unique : tous les dispositifs utilisent désormais une connexion de source de données unique qui est mise en proxy via le nouveau service pgbouncer. Le service pgbouncer est un pool de connexions qui maintient les connexions aux bases de données Postgres sous-jacentes tout en fournissant un point de connexion unique pour les services du dispositif à utiliser. Il gère également toutes les migrations de base de données principale et de basculement. Il est automatiquement mis à jour pour pointer vers la nouvelle base de données principale, ce qui permet une transition fluide entre les bases de données principales.
  • Basculement contrôlé de la base de données principale lors de l'arrêt ou du redémarrage du dispositif : lors d'un arrêt ou d'un redémarrage initié par un invité de la base de données principale actuelle, le rôle principal est migré vers l'autre dispositif de la paire HA d'une manière contrôlée. Cela entraîne uniquement une interruption mineure du fonctionnement des dispositifs, ce qui affecte principalement les connexions de poste de travail via le portail Blast (Web). Les connexions de poste de travail effectuées via Horizon Client ne sont pas affectées. Il y a également une brève période d'indisponibilité d'horizonadmin et les utilisateurs qui demandent une connexion de poste de travail pendant le basculement peuvent obtenir une erreur indiquant qu'aucun poste de travail n'est disponible (mais une nouvelle tentative ultérieure devrait leur permettre de se connecter à un poste de travail).
  • Basculement automatique de la base de données principale en cas d'échec inattendu du dispositif du locataire : les pannes de base de données principale sont désormais automatiquement détectées et une demande aux dispositifs du fournisseur de services est envoyée en suivant pour vérifier que le dispositif est bien indisponible. Le processus de basculement est ensuite initié après un délai de trois minutes. Ce nouveau processus de basculement est moins gênant que l'ancien processus de basculement et laisse le cluster slony dans un état de réplication normal par la suite. Aucune réinitialisation de slony n'est requise après un basculement.
Ces fonctionnalités sont prises en charge par les services décrits ci-dessous.
Service Description Emplacement du journal Remarques
pgbouncer Pool de connexions qui répartit les connexions de base de données entre les services de plate-forme et Postgres. /var/log/pgbouncer/
  • Les connexions à la base de données Postgres à l'aide de la commande psql passent désormais par défaut par pgbouncer, ce qui vous permet de vous connecter à la base de données principale, quel que soit le dispositif que vous utilisez. Pour vous connecter à une instance de base de données spécifique, utilisez les indicateurs -h et -p avec psql. Vous devez également spécifier le port 6432 pour vous connecter directement à la base de données Postgres. Par exemple :
    psql -U admin -h ‹Appliance_IP› -p 6432 fdb
  • Vous pouvez vérifier la configuration de pgbouncer dans /etc/pgbouncer/pgbouncer.ini pour vérifier qu'elle pointe vers les dispositifs appropriés. Les chaînes de connexion en haut du fichier doivent pointer vers l'instance principale actuelle de slony. Si ce n'est pas le cas, un redémarrage du dispositif résoudra le problème.
Dbmonitor Service de surveillance qui effectue les actions suivantes :
  • Détecte les pannes de la base de données principale et initie le nouveau processus de basculement.
  • Détecte les modifications apportées au nœud principal slony causées par le basculement contrôlé ou le réabonnement, et met à jour pgbouncer avec la nouvelle adresse de la base de données principale en conséquence.
 /var/log/dbmonitor/
Basculement Le script s'exécute lors de l'arrêt et effectue le basculement. /var/log/desktone/slony-services
Réabonnement Le script s'exécute au démarrage pour effectuer le réabonnement. /var/log/desktone/slony-services

Basculement manuel du dispositif du fournisseur de services

Si un dispositif du fournisseur de services subit un arrêt inattendu, vous pouvez effectuer un basculement manuel en effectuant les étapes ci-dessous sur l'autre dispositif du fournisseur de services.
  1. Exécutez le script failover-slony-master (situé dans /usr/local/desktone/scripts/) en tant qu'utilisateur racine : 
    failover-slony-master <database type> '<database password>'
    dans lequel <database type> est fdb, edb ou avdb.
  2. Assurez-vous que le fichier pgbouncer.ini pointe vers l'adresse IP frontale du dispositif actuel :
    /usr/local/desktone/scripts# grep '<IP address>' /etc/pgbouncer/pgbouncer.ini
  3. Rechargez le service pgbouncer : 
    service pgbouncer reload
  4. Vérifiez l'état de l'instance principale et la réplication en exécutant la commande slony-status :
    /usr/local/desktone/scripts# slony-status <org #>