Installation et configuration de la haute disponibilité HA
Les instructions fournies ci-dessous vous aident à mettre en oeuvre le diagramme de la rubrique précédente. Elles sont destinées aux administrateurs PostgreSQL et aux utilisateurs implémentant un déploiement de PostgreSQL haute disponibilité.
Pour référence, la rubrique
Exemple de déploiement d'une architecture HA PostgreSQL avec Pgpool-II contient un exemple de procédure indiquant les téléchargements, les séquences de ligne de commande et les scripts utilisés pour implémenter cette solution.
Documents de référence
Avant d'installer PostgreSQL, lisez et comprenez tous les documents d'installation et de configuration, y compris la documentation relative aux logiciels prérequis. Il est important de comprendre et d'appliquer les paramètres appropriés, y compris les recommandations de sécurité.
Les liens suivants fournissent des informations utiles concernant l'installation et la configuration de PostgreSQL haute disponibilité à l'aide de la réplication en streaming et de Pgpool-II pour la gestion des noeuds.
Installation de PostgreSQL et création d'un nouveau rôle utilisateur dans PostgreSQL
Les instructions d'installation et de configuration de PostgreSQL sont fournies dans le guide d'installation de ThingWorx. Consultez le guide d'installation de la version de ThingWorx à déployer. Les mêmes tâches d'installation et de configuration doivent être effectuées sur les trois noeuds PostgreSQL.
Configuration et exécution du script de base de données PostgreSQL
Les instructions permettant de créer la base de données dans PostgreSQL sont fournies dans le guide d'installation de ThingWorx. Consultez le guide d'installation de la version de ThingWorx à déployer. Les mêmes tâches d'installation et de configuration doivent être effectuées sur les trois noeuds PostgreSQL.
Configuration et exécution du script de schéma du fournisseur de données/modèles
Les instructions permettant de créer le schéma ThingWorx dans PostgreSQL sont fournies dans le guide d'installation de ThingWorx. Consultez le guide d'installation de la version de ThingWorx à déployer. Les mêmes tâches de configuration doivent être effectuées sur les trois noeuds PostgreSQL.
Création d'un utilisateur de réplication sur tous les noeuds PostgreSQL
Créez un utilisateur PostgreSQL pour gérer les tâches de réplication sur tous les noeuds. Vous devez utiliser le même nom d'utilisateur et le même mot de passe.
Ajout des paramètres de réplication sur tous les noeuds PostgreSQL
La table suivante contient les paramètres PostgreSQL qui contrôlent ses services de réplication.
 |
Les valeurs présentes dans la colonne Configuration reflètent l'exemple de déploiement de l'architecture de référence, mais peuvent être modifiées selon l'environnement. Pour la plupart des paramètres de la table ci-dessous, les liens sont fournis pour vous aider à déterminer les valeurs de configuration appropriées pour votre environnement.
|
|
Paramètre
|
Configuration
|
Description
|
|---|---|---|
|
listen_addresses
|
'*'
|
Permet d'être à l'écoute sur toutes les interfaces réseau. Dans certains cas, s'il existe plusieurs interfaces réseau, il est préférable de limiter ce paramètre à des interfaces réseau spécifiques.
|
|
Port
|
5432
|
Il s'agit du numéro de port par défaut.
|
|
max_connections
|
150
|
Dans PostgreSQL, la valeur par défaut est 100. Dans ThingWorx, le paramètre par défaut est également 100 (maxpoolsize). Augmentez ce nombre en fonction du nombre total de connexions simultanées attendues dans la base de données. Cette valeur doit toujours être supérieure à celle du paramètre maxpoolsize du fichier platform-settings.json pour ThingWorx.
|
|
shared_buffers
|
1024MB
|
Optimisation des performances (facultatif). Définit la quantité de mémoire utilisée par le serveur de base de données pour les tampons de mémoire partagée. Il est recommandé de définir ce paramètre à 1/4 de la mémoire disponible sur la machine. Reportez-vous à la page Web
Resource Consumption, section Memory (en anglais).
|
|
work_mem
|
32MB
|
Optimisation des performances (facultatif). Spécifie la quantité de mémoire à utiliser pour les opérations de tri interne et les tables de hachage avant l'écriture dans les fichiers disque temporaires. Reportez-vous à la page Web
Resource Consumption, section Memory (en anglais). Faites défiler jusqu'à work_mem.
|
|
maintenance_work_mem
|
512MB
|
Optimisation des performances (facultatif). Spécifie la quantité maximale de mémoire à utiliser pour les opérations de maintenance. Reportez-vous à la page Web
Resource Consumption, section Memory (en anglais). Cette option apparaît juste après work_mem.
|
|
wal_level
|
enum
|
Optimisation des performances (facultatif). Spécifie la quantité maximale de mémoire à utiliser pour les opérations de maintenance. Reportez-vous à la page Web
Write Ahead Log, section Settings (en anglais).
|
|
synchronous_commit
|
le
|
Reportez-vous à la page Web
Write Ahead Log, section Settings (en anglais) et faites défiler jusqu'à synchronous_commit (enum).
|
|
archive_mode
|
le
|
|
|
archive_command
|
'cd'
|
Reportez-vous à la page Web
Write Ahead Log, section Archiving (en anglais) et faites défiler jusqu'à archive_command (string).
|
|
max_wal_size
|
10
|
Reportez-vous à la page Web
Write Ahead Log (en anglais), et cliquez sur le lien ARCHIVING. Faites défiler jusqu'à max_wal_size (integer). Pour plus d'informations sur la configuration WAL, reportez-vous à la page Web
WAL Configuration (en anglais) de la documentation de PostgreSQL 10.
|
|
synchronous_standby_names
|
node1, node2 ou node2, node0 ou node0, node1
|
Dans une liste séparée par une virgule, ajoutez l'élément "nom_application" des autres noeuds, comme indiqué dans les fichiers recovery.conf. Voir synchronous_commit à la section Settings de la page Web
Write Ahead Log (en anglais).
|
|
hot_standby
|
true/false
|
Pour plus d'informations sur ce mode, reportez-vous à la page Web
Hot Standby (en anglais).
|
|
fsync
|
le
|
Reportez-vous à la page Web
Write Ahead Log, section Settings (en anglais) et faites défiler jusqu'à fsync.
|
|
checkpoint settings
|
Pour plus d'informations sur les paramètres de point de contrôle, reportez-vous à la page Web
Checkpoints (en anglais).
|
Etablissement des scripts start_replication et retargetMaster
Sur chaque noeud, établissez un script permettant d'activer les services de réplication et assurez-vous que le noeud PostgreSQL est synchronisé avec le système.
Sur chaque noeud, établissez également un script permettant de créer et d'implémenter un fichier recovery.conf. Le fichier recovery.conf doit contenir les modifications nécessaires pour déterminer le noeud maître et le noeud de secours pour la défaillance en cours.
Ajustement des paramètres de connexion externes sur tous les noeuds PostgreSQL
Modifiez les paramètres de chaque fichier pg_hba.conf pour permettre à l'utilisateur et à la base de données de stocker les données ThingWorx auxquelles accéder depuis l'adresse IP. Cette adresse IP se connectera à la base de données.
|
|
Pour plus d'informations sur le fichier pg_hba.conf, reportez-vous à la page Web
The pg_hba.conf File de la documentation de PostgreSQL 10 (en anglais).
Redémarrage des services PostgreSQL pour lancer la réplication
Redémarrez tous les noeuds PostgreSQL dans un ordre précis pour déterminer le noeud maître (démarré en premier), le noeud de secours principal (démarré en deuxième) et le troisième noeud (démarré en dernier).
Pour le noeud maître, démarrez les services PostgreSQL.
Pour le noeud de secours principal, exécutez d'abord le script start_replication pour le synchroniser avec le noeud maître. Démarrez ensuite les services PostgreSQL.
Pour le deuxième noeud de secours, exécutez d'abord le script start_replication pour le synchroniser avec le noeud de secours principal. Démarrez ensuite les services PostgreSQL.
Installation des noeuds Pgpool-II
Avant d'installer Pgpool, lisez et comprenez tous les documents d'installation, y compris la documentation relative aux logiciels prérequis. Il est important de comprendre et d'appliquer les paramètres appropriés, y compris les recommandations de sécurité.
Les informations concernant Pgpool-II sont disponibles en téléchargement à l'adresse suivante :
Pour obtenir des instructions sur l'installation de Pgpool-II, consultez la documentation de votre système d'exploitation. La même version de Pgpool-II doit être installée sur tous les noeuds pour pouvoir exécuter les services Pgpool-II.
Configuration des noeuds Pgpool-II
La table suivante contient les paramètres à modifier pour une installation Pgpool-II. Tous les paramètres Pgpool-II se trouvent dans le fichier pgpool.conf. Ces propriétés et ces valeurs doivent être ajoutées à tous les noeuds Pgpool-II.
|
Paramètre
|
Valeur
|
Description
|
||
|---|---|---|---|---|
|
listen_addresses
|
'*'
|
Sélectionnez des valeurs qui permettent au fournisseur de modèles de l'application ThingWorx de se connecter à Pgpool-II, qu'il soit ou non sur le même serveur.
|
||
|
port
|
5432
|
Port TCP pour écouter les connexions client.
|
||
|
pcp_listen_address
|
*
|
Filtre IP/d'hôtes pour les connexions PCP (Port Control Protocol) (* autorise tout)
|
||
|
pcp_port
|
9898
|
Port TCP pour écouter les connexions PCP.
|
||
|
backend_hostname
backend_port
backend_weight
backend_data_directory
backend_flag
|
<ip of backend#>
<numéro de port du back-end>
1
/var/lib/postgresql/10.x/main
ALLOW_TO_FAILOVER
|
Définissez ces valeurs de configuration back-end pour chacun de vos trois noeuds (un maître et deux de secours). Par exemple, backend_hostname0 est votre noeud maître, backend_hostname1 est le noeud de secours principal, etc. Pour plus d'informations, consultez la
documentation en ligne de PostgreSQL.
|
||
|
enable_pool_hba
|
le
|
Active pool_hba.conf.
|
||
|
master_slave_mode
|
le
|
Ceci indique à Postgres que vous utilisez la réplication maître/de secours.
|
||
|
load_balance_mode
|
off
|
|
||
|
master_slave_sub_mode
|
stream
|
Ceci indique à Pgpool-II d'utiliser la réplication en streaming PostgreSQL standard.
|
||
|
replication_mode
|
off
|
N'utilisez pas la réplication de Pgpool-II. Utilisez plutôt la réplication en streaming PostgreSQL standard.
|
||
|
sr_check_period
|
10
|
Délai de réplication en streaming (en secondes).
|
||
|
sr_check_user
|
replicator
|
Utilisateur de la réplication en streaming.
|
||
|
sr_check_password
|
replicator
|
Mot de passe de l'utilisateur de la réplication en streaming.
|
||
|
sr_check_database
|
postgres
|
Base de données de réplication en streaming.
|
||
|
health_check_user
|
postgres
|
Utilisateur du contrôle de l'intégrité du basculement.
|
||
|
health_check_password
|
postgres
|
Mot de passe de l'utilisateur du contrôle de l'intégrité du basculement.
|
||
|
health_check_database
|
postgres
|
Base de données du contrôle de l'intégrité du basculement.
|
||
|
failover_command
|
/etc/pgpool2/failover.sh %d %h %D %m %H %R %M %P
|
Pour plus d'informations sur ce paramètre, consultez la section failover_command ci-dessous.
Consultez également les exemples de scripts suivants dans l'annexe C :
• failover.sh
• retargetMaster_001.sh
• retargetMaster_002.sh
• retargetMaster_003.sh
|
||
|
num_init_children
max_pool
max_child_connections
superuser_reserved_connections
|
Paramètres de réglage des performances. Ces paramètres sont associés aux fonctions de mise en pool de connexions de Pgpool-II. Assurez-vous de fournir le nombre de connexions requises au démarrage pour répondre à vos besoins de débit les plus élevés, mais aussi de ne pas dépasser le nombre maximal de connexions des noeuds de base de données PostgreSQL. Reportez-vous à la section relative aux pools du manuel (voir lien ci-dessus) pour obtenir des suggestions ainsi que des formules de calcul de valeurs.
|
Configuration du script de basculement PostgreSQL
Créez un script de basculement dans chaque noeud Pgpool-II que le service Pgpool-II appellera si une défaillance est détectée. Ce script doit contenir la logique et les tâches à effectuer en cas de défaillance d'un noeud PostgreSQL.
Mise à jour de la configuration PCP
Mettez à jour le fichier pool_hba.conf afin de reconnaître tous les serveurs ThingWorx.
Pour les requêtes de ThingWorx à PostgreSQL, Pgpool-II se connecte aux noeuds PostgreSQL à l'aide des informations d'identification de ThingWorx pour conserver les privilèges et restrictions d'accès établis. Le fichier pool_hba.conf utilise le même format, et les mêmes méthodes et options d'authentification (md5, approbation, etc.) que le fichier pg_hba.conf.
Pour plus d'informations sur la configuration du fichier pool_hba.conf, rendez-vous à l'adresse suivante :
Mise à jour de l'authentification du client
Mettez à jour le fichier pool_hba.conf afin de reconnaître tous les serveurs ThingWorx.
Pour les requêtes de ThingWorx à PostgreSQL, Pgpool-II se connecte aux noeuds PostgreSQL à l'aide des informations d'identification de ThingWorx pour conserver les privilèges et restrictions d'accès établis. Le fichier pool_hba.conf utilise le même format, et les mêmes méthodes et options d'authentification (md5, approbation, etc.) que le fichier pg_hba.conf.
Pour plus d'informations sur la configuration du fichier pool_hba.conf, rendez-vous à l'adresse suivante :
Configuration de Pgpool-II pour le basculement
Dans les configurations haute disponibilité, Pgpool-II fonctionne dans une configuration active/passive, généralement avec un noeud Pgpool-II actif et un noeud de secours. Pgpool-II fournit le processus de surveillance qui contrôle l'intégrité des noeuds et active le noeud de secours en cas de défaillance du noeud principal.
Pour plus d'informations sur la configuration du service de surveillance, consultez la documentation de Pgpool (
http://www.pgpool.net/docs/latest/en/html/example-watchdog.html, en anglais).
La table suivante contient les paramètres et les valeurs à prendre en compte lors de la configuration du service de surveillance dans Pgpool-II. Ces paramètres et valeurs doivent être ajoutés au fichier pgpool.conf de chaque noeud Pgpool-II.
|
Paramètre
|
Valeur
|
Description
|
|---|---|---|
|
use_watchdog
|
le
|
Active la surveillance dans Pgpool-II.
|
|
wd_hostname
|
'{IP address of this Pgpool-II node}'
|
Nom d'hôte ou adresse IP de ce service de surveillance.
|
|
wd_port
|
9000
|
Numéro de port de ce service de surveillance.
|
|
delegate_IP
|
'{Virtual IP address to access PostgreSQL}'
|
Adresse IP virtuelle utilisée par les clients pour accéder à PostgreSQL (via Pgpool-II).
|
|
ifconfig_path
|
/etc/pgpool2
|
Chemin absolu du répertoire contenant les commandes ou les scripts if_up_cmd et if_down_cmd.
|
|
if_up_cmd
|
'ifup.sh $_IP_$ <eni id of Pgpool node>'
|
Commande émise lorsque Pgpool-II tente d'afficher l'interface IP virtuelle avec l'adresse delegate_IP. Vous pouvez récupérer l'ID eni du noeud Pgpool-II en vous connectant à la console d'administration EC2 et en accédant à votre instance Pgpool-II. Dans sa description dans la console, localisez l'entrée Network interfaces, cliquez sur eth0, puis localisez l'ID d'interface. Utilisez-le pour $<eni id of Pgpool node>.
|
|
if_down_cmd
|
'ifdown.sh $_IP_$ <eni id of Pgpool node>'
|
Commande émise lorsque Pgpool-II tente de réduire l'interface IP virtuelle avec l'adresse delegate_IP. Reportez-vous au paramètre if_up_cmd pour obtenir l'ID eni du noeud Pgpool-II.
|
|
arping_path
|
/usr/bin
|
Chemin d'installation du package iputils-arping.
|
|
arping_cmd
|
arping -U $_IP_$ -w 1
|
Commande arping utilisée pour vérifier les adresses IP.
|
|
heartbeat_destination0
|
'{IP address of the other Pgpool-II node}'
|
Adresse IP par rapport à laquelle le contrôle de pulsation est effectué ; valeur du paramètre other_pgpool_hostname0.
|
|
heartbeat_destination_port0
|
9694
|
Utilisez la valeur par défaut.
|
|
heartbeat_device
|
'eth0'
|
Carte réseau pour l'adresse IP pour les communications de pulsation.
|
|
other_pgpool_hostname0
|
'{IP address of the other Pgpool-II node}'
|
Adresse IP de l'autre instance de serveur Pgpool-II.
|
|
other_pgpool_port0
|
5432
|
Port d'écoute utilisé par l'autre noeud Pgpool-II.
|
|
other_wd_port0
|
9000
|
Port d'écoute utilisé par l'autre fonctionnalité de surveillance Pgpool-II.
|